Kaldığımız yerden devam edelim. Bu yazıyı kısa tutup, “in your face March mirmirik” diyelim.

En son “Yazılımcı / Uzman yazılımcı” konusunda ahkam kesmiştim. Bu konuda ve öncesindeki “Stajyer” ve “Jr. Yazılımcı” konularında yazdıklarımda hala haklı olduğumu düşünüyorum. Bu konularda fikrimi değiştirecek bir gelişme göremedim geçtiğimiz dönemde. Bu yazının konusu da “Teknik lider” ya da “Ekip lideri” adı verilen titre ile ilgili olsun. İçimi bir dökeyim. Oradaydım, bu işi de yaptım.

4. Teknik Lider, Ekip Lideri

Gerçekler: Ekip lideri / teknik lider kavramlarına bir açıklık getirmekte fayda var. Benim fikrimce, ekip lideri kod yazmayan, teknik konulara mümkün olduğu kadar uzak duran, daha çok ekibinin İK problemleri ve projelerin yürütülmesi ile uğraşan birisiyken; teknik lider tam tersine yazılımın mimarisi hakkında da söz sahibi olup, ilgili “core” kodları yazan, yazılımın ana şeklini oluşturan ve bu konularda da haleflerine yol gösterici olan kişidir. Evet, sevgili ülkemizde bu iki titre de ramazan çadırlarında dağıtılan yemeklere dönmüş olsa da, bu benim kişisel görüşüm. Yine önceki konuda belirttiğim, herkesin “senior olması” gibi kendisinden 1 ya da 2 yıl tecrübesiz herhangi iki kişi ile birlikte çalışan çoğu arkadaşım ya “ekip lideri” ya da “teknik lider” ve hatta çoğu zaman her ikisi birden oluyor.  Liderlik başlı başına çalışılması, üzerinde akıl yürütülmesi, ciddi anlamda “pişilmesi” gereken ve sosyal tarafı da ağır basan bir kavram iken hem ekibin hem de teknik gelişmelerin lideri olan arkadaşlar ile karşılaştıkça gözlerim doluyor (Tamamen yalan. Profesyonel bir empati yoksunu olarak hiç bir şey hissetmiyorum tabi ki).

Gereken: Benim, ekip ve teknik liderlik kavramları ile ilgili görüşüm şu şekilde görselleştirilebilir sanırım:

‘Teknik Lider‘ dediğimiz kişi daha çok ekibin içinde olan ve geliştirmeye de yardımcı, ‘Ekip Lideri‘ ise geliştirme ekibinin görev tanımlarının biraz daha dışındaki bir kişi. Tabi ki teknik lider iş birimleri ile konuşuyor ve tabi ki ekip lideri de geliştirme ekibi ile dirsek temasında. Ancak her iki işi de yüklenmeye çalışınca -ya da işte, üst yönetim tarafından yükletilince- işler sarpa sarabiliyor. Atılması gereken adımların çoğunun yönetim kademesinden gelmesine inanıyorum yine. Tamam, uzman yazılımcı arkadaşlar yine liderlik için kendilerini zorlasın ama onlardaki yatkınlık seviyesini ölçemeyen ya da farkına varamayan yönetim kademesinin sırf “title dağıtmak ile” geleceğe yatırım yapmadığını bilmesinde fayda var.

Kişisel eklenti: Çoğu zaman gördüğüm şu oldu. Şirkette uzun yıllardır bir projede çalışan arkadaşın niyeti/isteği/yeteneği göz ardı edilip sırf bir “title” vermek için, ekip lideri ünvanı veriliyor. Kadın (ya da adam) aslında teknik olarak profesyonel iken, üzerine bir de uğraşması gereken ve hiç de zevk almadığı onlarca İK problemi de ekleniyor. Bu durumun da iki çetrefilli derdi var. Teknik anlamdaki birisinin ne yazık ki “sosyal becerileri” biraz düşük olabiliyor (bende öyleydi diye herkeste olmak zorunda değil ama dediğim gibi: ‘gördüğüm bu’). Ekip lideri dediğimiz arkadaş da, proje yönetim, İK konuları, yönetimsel konularda doyurucu olsa bile, teknik konulara #muffinbey‘in kırmızı ete duyduğu sevgi kadar uzakta durmayı seçebiliyor. Bu konu da hem onun geliştirme ekibi içindeki saygınlığını yerle bir ediyor hem de ekibi olması gerektiği gibi yönetemediği için verim kaybına sebep oluyor.

Bugün yaptığım işten mutsuz olsam, ben kurumsal bir yere döneyim, her ay maaşımı rahat rahat alayım, emeklim/sgk’m olsun baş göz olayım, evlenip çoluk çocuğa karışayım bari desem “teknik liderlik” yapabilme kapasitem bunca yıllık iş birikimime rağmen yok örneğin. Bugün teknik liderlik yapabilecek durumda hiç değilim, çünkü “bilmiyorum”. Günümüzün teknolojik gelişmelerine çoğu yazılımcı arkadaşım kadar yatkın değilim ne yazık ki. Uzun yıllardır yazılım projelerinde “hands-on” görev almadım ve bu bana teknik bilgi anlamında çok şey kaybettirdi. Öylesine bir seçim ile, R, React, NodeJS, Python, jQuery kütüphaneleri ve/veya geliştirme dillerini, Docker/AWS yapılarının veya bu dillerin avantaj ve dezavantajlarını, küçük performans ipuçlarını kişisel olarak deneyimlemediğim için “teknik anlamda” ekipteki arkadaşlara çok şey katamam. Ama “ekip lideri” olarak hala işe yarayabilirim. Çünkü bu konuya diğerinden daha çok eğildim ve bu konuda kendimi de eğittim. Ekipteki hangi arkadaş erkek ya da kız arkadaşından ayrılmış, kimin evinde ev arkadaşı (ya da ailesi) ile ilgili bir problem var, hangi “manager” pozisyonundaki ekipteki kime ne şekilde baskı yapıyor, kimin iş yerindeki çay yapım saatleri ile ilgili bir sıkıntısı var sorularının cevabı bende olmak zorunda (dedikodu ile ilgili değil bunlar) ve bu konuların hiçbirisinin benim NodeJS sunucusunun nasıl başlatılabileceği ya da yeni bir Conda ortamının nasıl kurulabileceği ile ilgisi yok (zevkli konular, o ayrı).

Biterken çalıyordu:

The post Yazılımcı maskesini çıkarıp yönetici olmak / III appeared first on mirmirik.net.

Kovboy tarzı yazılımcı olmanın ve bu şekilde yazılım geliştirmenin kötü taraflarından üzerine sıklıkla bastırdıklarım özetle şunlar:

• Tek kişi kalmak, yalnız olmak
• Ekibe güvenmemek
• Test ya da dokümantasyona zaman ayırmamak
• Bilginin tek elde toplanması
• İşlerin gün geçtikçe yığılması
• Yığılmadan dolayı işlerde gecikmeler ve bug çıkması
• Bug-fix yapacak ya da işleri yetiştirecek kişinin aynı kişi olması
• [infinite loop]

Tüm bunları bir kovboy yazılımcı ile konuşursanız, size, kendisine zamansız ve eksik dokümante edilmiş istekler geldiğinden, isteklerin bilgisizce hazırlandığından, zaten sistemin ayakta kalmasının tek sorumlusunun kendisi olduğundan, ekipteki daha junior seviyedekilere işin nasıl yapılacağını anlatmaktansa kendisinin yapmasının çok daha hızlı olduğundan bahsedecektir. Kendisinin çevik metodolojiler için yanıp tutuştuğundan, yazılım geliştirme döngüsünde herhangi bir çevik yazılım geliştirme metodolojisi uygulanıyor olsa herşeyin güllük gülistanlık olacağından, ancak süregiden şirket politikası ve işlerin kritikliği sebebiyle bunun uygulanamayacağından da söz edecektir.

Bu durumda kendisine çevik metodolojilerin prensiplerini tekrar hatırlatmakta fayda var:

• En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
• Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.
• Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.
• İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
• Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.
• Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.
• Çalışan yazılım ilerlemenin birincil öçüsüdür.
• Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.
• Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
• Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
• En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
• Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Prensiplerde önemle tekrarlanan bir nokta var. Takım / ekip / birlikte çalışmak / takım oyuncusu olmak. Takım oyuncusu olmanın şartlarından birisi de aslında bilgi paylaşımının ve şeffaflığın arttırılması. Bilgi paylaşımında bulunmak ve şeffaflığı arttırmak için ise asıl yapılması gerekenin -kişisel deneyimlerden yola çıkarak- “profesyonel ego”dan kurtulmak olduğuna inanıyorum.

Egosunu yenebilmiş teknik bir kişinin, ekip ile birlikte daha çok büyüyeceğine ve hep hayalindeki rahat çalışma ortamına kavuşacağına dair inancım yüksek. Ego nasıl yok edilir konusu ise daha çok psikoloji ve sosyoloji alanlarının konusu. Hala kişisel hayatımda yüksek olduğuna inansam da, benim iş konusundaki egomu zayıflatmam şunları sağladı:

• Şirket içi bilgi paylaşımıma daha fazla zaman ayırdım,
• Ekibe yeni katılmış ya da daha önceden ekip içinde varolan arkadaşların teknik bilgilerini yükseltmek için çabalar oldum,
• Ekipteki arkadaşlarımın kendilerine güvenleri yükseldi,
• Üzerimdeki işleri dağıtabilmeyi başardım,
• Üretime aldığımız kodlarda çok daha az hata çıkmaya başladı,
• Müşterilerimizde şirketimize ve ekibimize karşı güven yükseldi ve zaman zaman yaptığımız hataların tolere edilmesi kolaylaştı
• Mesai sonrası boş zamanım oldu,
• Sosyal hayata daha çok zaman ayırabildim,
• Geceleri, aklımda o günkü ya da yarınki proje ile ilgili daha az endişe duydum ve daha rahat uyuyabildim.

Uzun lafın kısası, kovboy yazılımcı olmanın o iç daraltıcı dünyasından, ilk etapta egonuzu arkanızda bırakarak ve bu sayede takım oyuncusu olma yoluna adım atarak sıyrılabilirsiniz. Emin olun her şeyin en iyisini siz bilmiyorsunuz ve aslında vazgeçilmez değilsiniz.

Not: Yazıdaki fotoğraf, bir zamanlar kovboy filmlerinde oynayan ancak daha sonra ABD başkanlığına soyunan Ronald Reagan‘a ait.

The post Kovboyluktan vazgeçip takım oyuncusu olmak appeared first on mirmirik.net.

Red Kit’i hepimiz biliriz. Lucky Luke diye geçer İngilizcede. Morris olarak tanınan Belçikalı çizer Maurice De Bevere tarafından 1940 sonlarında yaratılmış ve dünya çapında ün sağlamıştır. Zor durumda kalan insanları kurtarır, karşılaştığı olayları gölgesinden bile hızlı çektiği silahı ve en büyük yardımcısı ve dünyanın en zeki atı olan Düldül ve dünyanın en aptal köpeği olan Rin Tin Tin ile çözer; tam son anda uçurumdan yuvarlanmak üzere olan posta arabasının yolunu değiştirir, kasabanın başına çok uzun zamandır bela olan çeteyi tam da artık kasabayı yok edeceklerken dağıtır, varolabilecek tüm sorunlar onun başına gelir, her şeyi çözdükten sonra da yine yalnız başına, gün batımına ve yeni sorunlarına doğru yoluna devam eder, takım oyuncusu değil, tek tabancadır. (Düldül’ün asıl adı Jolly Jumper’dır çizgi romanlarda. Rin Tin Tin’in çizimlerdeki adı da Rantanplan’dır, Türkçe diline gerçekte ünlü bir sinema oyuncusu haline gelmiş olan, I. Dünya Savaşı sırasında kurtarılmış bir Alman kurt köpeğinin adı olan Rin Tin Tin ile geçmiştir [#donotshopadopt]).

Tanınan ve sevilen bir kovboy olan Red Kit anolojisini vermemin sebebi, uzun zamandır bir kaç farklı yazılım ekibinde karşılaştığım bir durumun, bir zamanlar “kovboy yazılımcı” olmanın ve sonrasında da bir yönetici olarak bu kovboylar ile neler yaşanabileceğinin tecrübelerini paylaşmak.

Kovboy yazılımcı derken ilginç şapkalar takmalarını, mahmuzlu çizmeler ile etrafta dolaşmalarını, mataralarını yalaktan doldurmalarını kastetmiyorum. Yalnız olmalarından, bir ekip ile çalışamamalarından, devamlı sorunlar ile uğraşmalarından, bunun tercihleri olmasından ve aslında nişan almadan silahlarını çekip kalçalarından ateş etmelerinden bahsediyorum.

Önce çuvaldız…

Üniversite dönemimde az deneyimli bir yazılımcı olarak başladığım ilk işimde “kovboy” haline gelmem 1.5 ya da 2 yılımı almıştı. Birlikte çalıştığım arkadaşlarım ya da o zamanki şirketin sahibi olan iş arkadaşlarım (hiç bir zaman patron diye görmediğim için bu tabiri kullanıyorum) hatırlayacaklardır. Belirli konulardaki tüm bilgiler sadece bendeydi, sadece benim istediklerimi yapmaya veya yaptırmaya çalışıyordum, önemli projelerdeki en “core” kodları ben yazmıştım, işin ilk aşamasından müşteri teslimine kadar olan süreçte dediğim dedik inatçı birisi olmuş ve tüm seslere kulağımı tıkamıştım. Tüm yazılım ekibindeki arkadaşların yazdıkları kodları mutlaka ben gözden geçirmeliydim ki, çocuğum olarak gördüğüm projeler “kirlenmemiş” olsundu. Ekip arkadaşlarımı yönlendirmek, onlara güvenmek ve işleri onlarla paylaşıp düzgün iş çıkarmak yerine, egomu tatmine yönlenmiştim.

20-22 yaşlarındayken bunlar çok güzel duygulardı. Kendini önemli görmek, vazgeçilmez hissetmek… Hepsi bir şekilde ego tatmini yaşatıyordu. Sonrasında olanlar ise kendi yarattığım kompleksin ve egoistliğin sonuçlarıydı sadece. Öncelikle varolan eski işlerin operasyonel yüklerini çekemez hale geldim. Bug-fix ya da CR’lar ile uğraşmaktan sabahlara kadar klavye başında kalıyor, ne kendimi teknik anlamda istediğim kadar geliştirebiliyor ne de istediğim gibi yazılım üretebiliyordum. Her yaptığım şey yeni bir bug ya da operasyonel yük üretiyor, ya da projeye zarar getirip müşteri memnuniyetsizliği yaratıyordu. Tüm bunlar tabi ki her şeyi etkiliyor, bir çığ yığını gibi büyüyen işler altında boğuluyor ve iş memnuniyetsizliğim üst noktaya çıkıyordu. İşten sıkılıyordum, bana kendi hayatımı yaşamam için gerekli zaman kalmıyordu, gelen isteklerin sonu yoktu, herkes her şeyi bana soruyordu, en ufak bir problem oluştuğunda bile ya sorumlu ya da o çıkan sorunu çok acil çözmesi gereken kişi olarak ben biliniyordum. Bir çok kod test edilmeden canlı ortama aktarılıyordu. Ekibe yeni giren tüm arkadaşların sorumluluğu da vardı. Onların eğitimi ile geçireceğim sürede tabi ki iki satır kod yazmak daha mantıklıydı o zamanlar… Zaten onlar bu çömezlikleri ile ne bilebilirdi ki?

Buraya kadarki senaryoda var olan kişi şu anda IT ekibinizde mi sizin de? Bir şekilde projenin her şeyini bilen ve vazgeçilmez gibi görünen o kovboy ile çalışmak zorunda mısınız? Üstü iseniz gitmek ile tehdit etmeye varan iyileşmeler göstermiyor ve şirketin şu anki durumu için bu durum kötü mü görünüyor? Ya da o kişinin astı iseniz sizi her durumda eziyor ve yaptıklarınızı bir türlü beğenmiyor, size güvenmiyor mu? Her iki durumun da çözümü tam olarak yazının devamında demek isterdim…

Gelelim iğneye…

Sevgili kovboylar: Eğer öğrenimlerinizi ve kazanımlarınızı aktarmaz, iş bölümü yapmaz, en doğrusunu ben bilirim tavrınızı değiştirmez, sizin güveninizi isteyen ekibinize sorumluluk vermez, takım oyuncusu olmak yerine tek tabanca ilerlemekte ısrar ederseniz; bir yazılım projesinin, ekibinin baş aktörü olmak ve projenin ya da şirketin kuruluşundan bu yana işin içinde ve hatta başında olmak hiç bir meziyet ya da övünülecek bir şey değil. Bundan 8-10 yıl sonrasında open source neden tüm dünyayı ele geçirmiş olacak sanıyorsunuz? Paylaşmak, bilgi aktarımı, yönlendirici rolü üstlenmek, takımdaki daha az teknik yeterlilikteki arkadaşlar ile güven ilişkisinin kuvvetlendirilmesi, ekip çalışması kavramları emin olun sadece üst düzey yöneticilerin “şirkete kurumsal kimlik kazandırmak” için uydurduğu şeyler değil.

Evet haklısınız, proje için şu anda çok değerlisiniz. Projenin detaylarındaki o küçük iş kurallarını sadece siz biliyorsunuz ve sipariş modülünde yapılması gereken o ufak bug-fix, depo ve sipariş toplama için bundan bir yıl önce eklenen kuralı öyle bir ihlal ediyor ki, bunun çok dikkatli uygulanması lazım. Bu konuda da tabi ki henüz sekiz aydır ekibinizde çalışan yazılımcının yazacağı koda güvenemezsiniz, sizin yapmanız lazım (hem de bu kadar çok iş arasında). Aslında neden güvenemeyeceğinizi de biliyorsunuz. Sisteme az da olsa hakim olacak kadar kendisine yol gösterilmedi şimdiye kadar. Yaptığı her yanlışta “sen çekil ben yapayım” dediniz. Her yanlışını onu ezerek yüzüne vurdunuz ve her yaptığı değişikliği size göstermesini, sizin onayınız olmadan asla bir işe girişmemesini söylediniz kendisine.

Sizi daha çok ekip yönetimine yönlendirmeye çalışan yöneticinize de üstünüzdeki işlerin yoğunluğunu, sabahlara kadar çalışmalarınızı, bu şirket/proje için yaptığınız fedakarlıkları, hastayken bile sırf iş yürüsün diye gelip çalıştığınızı ve hiç bir kötü yorumu haketmediğinizi anlattınız.

Önünüzde iki yol var. Biri zahmetli ve zaman alacak olan süreç olan “iş dağıtımını öğrenmek” ve ekip yöneticisi olarak kariyerinizde ilerlemeye devam etmek, diğeri de kolay olan şu anki durumun devamını sağlamak. Zaten çoktan ekip yöneticisi olarak adlandırılmış olabilirsiniz, ancak hala tüm operasyonun yükünü “hands-on” olarak siz çekiyor, üstlerinizden gelen işleri içten içe saçma ya da zaman darlığından dolayı yapılamaz kabul edip buna karşı sayısal veriler ile üstünüzü ikna edemiyorsanız ekip yöneticiliğiniz sadece kağıt üstündedir. Daha kendinizi yönetemezken ekibi yönetiyor olarak görülmeniz çok da mantıklı görülmez.

Daha somut adımlar ile kovboyluktan nasıl vazgeçebileceğiniz ile ilgili bir sonraki yazıda ahkam kesmeyi planlıyorum. Şimdi gidip Dalton kardeşler ile uğraşmam lazım… O yazı çıkana kadar, sevgili Morris’i anmak lazım:

https://www.youtube.com/watch?v=B_EXFt4BSiY&t=40

The post Yazılım ekibindeki kahraman kovboy… appeared first on mirmirik.net.

Oldukça büyük ve ünlü bir restoran mutfağındaki aşçılık ve büyük ihtimalle şef aşçılık kariyeriniz sizi, bir şekilde, müşteriler ile daha fazla beraber olabildiğiniz “şef garsonluk” tarafına sürükledi. Artık mutfakta dönen her şeyden siz “ayrıca” sorumlusunuz. Gelen siparişlerin içerideki şef aşçıya iletilmesi, siparişin ne kadar sürede hazırlanması gerektiği, içeriğinin müşterinin istediği şekilde nasıl hazırlanabileceği ve bunu en hızlı nasıl ve kimin tarafından sunulabileceği tamamen sizin kontrolünüzde. Tabi ki bunların hepsi kasada oturan arkadaşınızın uyarıları ile şekillenmek zorunda. İşin en kötüsü de, bu restoranda menü falan yok. Sadece sizin “kırmızı et” yemekleri konusunda iyi olduğunuz biliniyor çevrede. Kimin ne zaman ve neyi nasıl isteyeceği tamamen deneyimlerinizden kaynaklı öngörülerinize bağlı.

İş hayatınızdaki “yazılımcı” ve büyük bir ihtimalle “yazılım takım yöneticisi” kariyeriniz bir şekilde, müşteriler ve şirket yöneticileri ile çok daha fazla birebir ilişki kurduğunuz “manager” pozisyonuna sizi sürükledi. Artık IT ekibi içinde dönen her şeyden çok daha fazla sorumlu hale geldiniz (Bir nevi, 1.49V üzeri DC ya da AC ile çalışan herşeyin sorumluluğu sizde). IT’den belirli bir zaman planına uygun olarak istenilen her şeyin, bir süzgeçten geçirilip yazılım takım yöneticisine iletilmesi, isteğin çıktısının ne olması gerektiği gibi konularda kafanızı oldukça yormanız gerekmekte. Bunları yaparken de finansal girdi ve çıktıları hesaba katıp, en uygun fiyatlı çözümü sunmanızın şart olduğunu da unutmamak gerekiyor.

İşlerin yetişemediğini, bir nevi gelen talepleri artık elinizdeki aşçılar ile karşılayamadığınızı farkettiğinizi ve çözüm olarak bir ya da iki aşçıyı daha ekibinize katmak olduğunu gördüğünüzü varsayalım. Elinizde sağlam veriler de var. Verileri analiz ettiniz ve bir iki ay içinde her akşam size gelen müşterilerin isteklerini, istedikleri süre içinde tam olarak karşılayamayacağınızı biliyorsunuz ve bu isteklerin daha da artacağını zaten görüyorsunuz. Bu durumda atılacak adımlar belli aslında. Bu durumu yöneticinize (büyük ihtimalle genel müdürünüze) bildirmek ve iyi bir aşçı arama sürecine girmek ya da bu kadar masa fazla, bunların sayılarını azaltmamız lazım demek. İkinci seçeneği seçmeniz mantıksal açıdan kolay yol olsa da, işletme açısından istenilen bir davranış olmayacaktır büyük ihtimalle. İlk seçeneğe dönelim. Eleman alalım…

Restoranlardaki işe alımların hangi süreçlerden geçtiğini kesin olarak bilmediğim için tabi ki o konuda ahkam kesmeye devam etmeyeceğim. Kendi bildiğim kısma döneyim. Artık birlikte çalıştığımız IT ekibine yeni bir çalışan katma konusunda sorumlu hale geldiğimize göre, bu konudaki deneyimleri anlatıyor olmanın zararı olmaz.

• Öncelikle, “eleman” değil, çalışma arkadaşı arayışı içinde olduğunuzu kabullenin. “Eleman” arayışından vazgeçin. İş arkadaşı arayın.
• İşverenlerinizin hayalindeki gibi mükemmel kişiliğe sahip, sabahtan akşama kadar yerinden kalkmadan çalışan, işyerinin “iş hedeflerini” %100 içselleştirmiş ve çok iyi derecede teknik bilgiye sahip insan arayışından vazgeçin. Öyle birisi yok. Onlara Artificial Intelligence adı da veriliyor ve Stephen Hawking’in de uyardığı gibi insanlığın sonu onlardan gelecek.
• İş görüşmelerinde patron gibi değil, çalışma arkadaşı gibi konuşun. Zamanınızın büyük bir kısmını birlikte geçireceksiniz. Eşiniz, çocuğunuz ya da kedileriniz ile çok daha az görüşüyorsunuz. Hadi çocuk neyse de, eşinizi seçerken bile “birlikte geçireceğiniz zamanın huzurlu olması” şartını aradığınızı unutmayın.
• Sinirli olduğunuz ya da çok neşeli olduğunuz gibi yüksek duygu durumlarınızda görüşme yapmaktan ve karar vermekten mümkünse kaçının.
• Çok bilindik ve klasik olacak ama sizin aradığınız teknik yeterlilik ile ilgili herşeyi tam olarak ve çok iyi bildiğini iddia eden kişileri işe almayın. Yalan söylüyorlar. Piyasada Photoshop ve 3DS uzmanı olup da SAP’de modül desteği verebilen, ABAP’ta kendisini aşmış ve .NET ile SQL Server’a, Python ile mongoDB’ye “takla attırmasını” bildiğini iddia eden bir çok CV var. *nix sistemlerde her daim bir root, Windows’ta ise Sys.Admin olmaları da büyük artı belki. Swift’te 10 yıllık tecrübeleri olması kendilerini bir adım öne çıkarsa da, Android’de sadece 8 yıllık tecrübeli olmaları sizi şüphelendirebilir. (İş arayanlara not: Bu tip bir özelliklerde birisini arayan bir iş ilanı görürseniz de o firmayı bir şekilde bloklayın)
• Dürüst olun görüşmede. Dürüst olmaktan kastım acımasızca dürüst olmak. Pembe bir tablo çizmeyin kesinlikle. Beyaz yalanlar bile söylememeye çalışın. Gerçekleşmesi çok düşük ihtimalde olan vaatlerde asla bulunmayın. Gücünüzün sınırlarında olan konularda istekler gelirse bunları ne kadar gerçekleştirebileceğinize bakın. Eğer gerçekleştiremeyeceğinize dair bir şüpheniz varsa bunu paylaşın. Sırf “eleman alımını gerçekleştirmek” ile siz bir üst makamın gözünde iyi görüneceksiniz diye insanları boş vaatler ile oyalamayın.
• Bilmediğiniz bir teknik alanda iş arkadaşı arayışı içindeyseniz, mutlaka o konuyu iyi bilen birisinden destek alın.
• Zaman zaman, ekip içindeki konum olarak daha alt düzeyde bulunan bir ekip arkadaşınızı da görüşmelere alın. Bu hem başvuran kişinin gireceği ekibi biraz daha nesnel tanımasına, hem de ekip içindeki arkadaşınızın IK konularında kendisini eğitmesine destek olacaktır. Örneğin bir Jr. Developer arıyorsanız, o güne kadar iş görüşmelerinde hep masanın diğer tarafında oturan bir Mid.Level Developer arkadaşınızı yanınızda bulundurun. Onun da soru sormasına fırsat verin.

Bu tavsiyelerim ya da hayallerim tabi ki benim her zaman yapmayı başarabildiğim şeylerden öte, yapmak istediklerim. Birçoğunu şimdiye kadar uygulayabildiğimi düşünüyorum ama tam anlamı ile her maddeyi gerçekleştirdiğimi söylemek “beyaz bir yalan” olur. Acımasızca dürüst olmadığım zamanlar oldu.

Şef aşçı olmak zor. Benim becerebileceğim bir şey değil. Sanırım bu yüzden yazılımcı oldum…

The post Bir CTO işe alım yapıyor! appeared first on mirmirik.net.

Bizler (teknik proje yöneticileri, mimari tasarımcılar, IT direktörleri, yazılım geliştirme müdürleri, iş analistleri, yazılımcılar), bilişim çalışanları olarak genelde sadece yaptığımız işin bizlere verdiği tatmin duygusu ile işlerimizi yapıyoruz. Bu ego tatminlerimiz gerektiği gibi olduğu müddetçe de yapılan işi olması gerektiğinden çok daha iyi yapıyor ve başarılı sayılıyoruz. İşin sonucunun şirketi nereye getireceği, ne şekilde satışları arttıracağı ya da şirket olarak tanınırlığımızı nereye getireceği ile pek ilgilenmiyoruz. Açıkçası, pek de umurumuzda değil aslında bunlar. Satışın ya da pazarlamanın isteklerini karşılayabilmek için sizler gibi düşünmemizi, tam olarak sizler gibi P&L⁵ gözetmemizi, müşteri memnuniyetini %100 seviyesinde tutmamızı ya da satış grafiğinin her zaman bir önceki döneme göre pozitif olarak büyüme trendinde olmasını hedeflediğimizi görmek istiyorsunuz. Cidden mi? Bunlar maalesef önemsediğimiz konularda üst sıralarda değil.

Kişisel olarak görüşüm, bundan 3 – 5 yıl sonrasındaki iş hayatında, pazarlamadan anlamayan ya da satış aktivitelerinin önemini kavrayamayan bir IT çalışanının başarılı olamayacağı yönünde. Bunun tam tersi de geçerli. Yani bir CMO⁶ eğer IT’yi ve getirilerini anlayamıyorsa, günün piyasasında iz bırakacak bir iş yapamayacaktır. Tabi bu sadece global olarak düşününce geçerli. Yoksa ülkemizi düşününce her yolun mübah olduğu ayrı bir gerçek. Buradaki 3-5 yılı ülkemiz için 12-15 yıl olarak düşünebiliriz. Yeter ki patron şirketleri 1980’li yıllarda kalmış olan alışkanlıklarını değiştirebilsin o zamana kadar.

Deneyimlerimden gördüğüm kadarıyla, bir IT çalışanının, pazarlama ya da satış ekibi ile aynı düşünce yapısında olması ile ilgili grafiği aşağıya ekledim. Buradaki “Umursama durumu”, IT çalışanının, pazarlama ya da satış ekibinin hedeflediği amacı yüzdesel olarak ne kadar içselleştirdiğini veriyor:

Şimdi, bir kaç acı gerçeği yazılı hale getirmeli sanırım bu grafik yardımı ile. Aşağıdaki maddelerde hem biz bilişim çalışanları için hem de pazarlama ya da satış ekibindeki arkadaşlar için bir şeyler var.

1. Üzgünüm ki, biz IT çalışanları henüz yeteri kadar “iş bilgisi” ile donatılmamış durumdayız.
2. Pazarlama ve satışın hedefleri ile, IT hedefleri(ego tatmini ile de doğru orantılı olarak) pek örtüşemiyor.
3. Yapılan işin şirkete sağlayacağı yarardan daha çok, teknik anlamda bizi ne kadar zorlayacağı ve bizlere ne kadar bilgi katacağı bazen çok daha önemli.
4. O andaki görevimiz ve sorumluluğumuz ne kadar fazla teknik bilgi birikimine ihtiyaç duyuyorsa, o kadar empatiden uzaklaşıyoruz.
5. Dünya üzerinde şu ana kadar geliştirilmiş ya da geliştirilmekte olan yazılımların kaynak kodları yüzlerce farklı dil ile yazılmış durumda. Lütfen bize “x firması bu işi 3 günde tamamlamış; ne kadar zor olabilir ki?” diye gelmeyiniz (bkz: List of programming languages.)
6. Hedeflerinizi matematiksel ifadeler kullanarak bize aktarabilirseniz, sizleri o kadar sever ve işi sahiplenebiliriz. Yoksa “bunu tüm müşterilerimiz istiyor” ya da “bunu yaparsak çok güzel atılımda olacağız” ifadeleri emin olun ki aramızdaki konuşmalarda bazen eğlence konusu olabiliyor.
7. En sevdiğim öngörü: “Bir kadın 9 ayda doğum yapabilir ama 9 kadın bir ayda doğum yapamaz”. Çalışan adam sayısını arttırıp, projelerin de buna doğru orantılı olarak sürelerinin daha kısalacağını söylemeyin lütfen, kalp kırıcı oluruz.
8. Sizlerin KPI’larınız ile bizlerin KPI’ları arasında çoğu zaman ciddi fark var. Satış cironuzu %20 arttırmayı hedefleyen bir proje fikrinizdeki size çok basit gelen bir fonksiyon için düşündüğünüz geliştirme zamanı, bizim aylık çözülen bug sayımızı inanılmaz ölçüde arttırabilir.
9. Şirket bütçesinde “cost” olarak büyük bir kalem olarak yer alıyoruz. Eminiz ki kuzeninizin bir tanıdığı bizlerin yaptığı işi 1/3 zamanda çok daha iyi yapabilir. Uygulamak zorunda olduğumuz süreçler ve uymamız gerektiğini söylediğimiz kurallar emin olun işi zora sokmak için değil, bir sonraki proje talebinizi daha hızlı karşılayabilmek için.
10. Yazının genelindeki “siz” ve “biz” ayrımını uzun bir süre kıramayacağız. Bunun bilincine vardığımız sürece ortak bir hedef için çok daha hızlı ilerleyebiliriz.

Kişisel fikrim: bundan 5 yıl sonra bence bir IT departmanına gerek bile kalmayacak şirket içinde(TR için bu süre iki katı). Pazarlamaya bağlı ufak bir destek ekibi olması yeterli olacak. Giderek gelişen cloud ortamı sayesinde hem “in-house” geliştirme yavaş yavaş ölecek, hem de teknik destek anlamında uğraşılması gereken konular çok azalacak. Pazarlamaya bağlı olacak bir iş analisti ve proje yöneticisi ile işlerin oldukça iyi ilerleyebileceğini düşünüyorum. Ancak o zamana kadar aramızı düzeltmek için iki tarafın da bazı ödünler vermesi gerekecek. Bizlerin “iş” anlamında bir şeyler öğrenmemiz ve şirketin hedeflerini daha çok içselleştirmemiz gerekiyor. Pazarlama ya da satış departmanları da mümkün olduğunca IT’nin süreçlerine anlam vermesi ve yönetime karşı bizleri de savunabilmesi iki taraf için de yararlı olacak gibi.

Evet; “pazar” doymak bilmeyen bir canavar ve her haftayı geçtim, her gün değişen kurallara göre oyunu oynamak zorundayız. Ama matematik hiç yalan söylemiyor. Matematik konusunda bizlere güvenin.

Ek okumalar:

3 things your CIO should know about marketing
Inside the Minds (and Personalities) of CIOs and CMOs
Are CIOs Destined to Work for the CMO?
Hey CIOs! Show Your CMO the Love
Güncelleme (29.08.2014):
Getting the CMO and CIO to work as partners

Kısaltmalar:

¹: Chief Technology Officer
²: Chief Information Officer
³: Bilişim Teknolojileri
⁴: Information Technology
⁵: Profit and Loss
⁶: Chief Marketing Officer

The post Bir CMO, IT hakkında ne bilmeli? appeared first on mirmirik.net.