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.

Bir önce yazdığım yazıda, Türkiye’deki bir yazılımcının kariyer adımlarından Stajyer ve Jr. Yazılımcı konularında ahkam kesmiş, samimi özgeçmişimi de yazı içine ekleyeceğimi belirtmiş, azıcık içinde bulunduğumuz yönetim/sosyal çevre durumlarına çemkirmiş ve devamının Eylül’de geleceğini yazmıştım. Hakkında onlarca şarkı olan Eylül ayı geldiğine göre sözümüzde duralım o zaman. Hazır sözümüzde dururken de, şu çalsın arka planda(Rakı opsiyonel ama tavsiye edilir):

https://www.youtube.com/watch?v=ZFobOUv942k

Bu yazıdaki planım, bir öncekinde belirttiğim adımlardan “Yazılımcı” ve “Uzman / Senior yazılımcı” kavramlarını bir arada almak. Bu konuda biraz doluyum açıkçası. Sonrasında da “Teknik lider / mimar” ve “Takım/ekip yöneticisi” titrelerini kendi görüş açıma göre yorumlamak var aklımda ama bu büyük ihtimalle Ekim Mırmırık’ına kalacak. “IT Yöneticisi” ve “CTO/CIO” kavramlarını da Kasım Mırmırık’ına “sallayarak” üstümden atma niyetim var açıkçası. Bu arada şunu özellikle tekrarlamak istiyorum. Burada yazdıklarım sadece ve sadece benim görüşlerim. Ne benim çalışma/işbirliği ya da ortaklığı yaptığım şirketleri ve çalışanlarını, ne önceden çalışmış olduğum şirketleri(ve çalışanlarını) ne de eş/sevgili/eski sevgili/tanıdık/dost/akraba/arkadaş/komşularımı bağlar. Tüm fikirler, kişisel deneyimlerim ve görüşlerimdir.

Neyse…
Başlayalım!

3. Yazılımcı / Uzman yazılımcı

Gerçekler: Bu iki ünvanı birleştirme sebebim aslında Türkiye’de (özellikle son iki yıldır) ‘yazılımcı’ bulamamam ile ilgili. Herkes ya çok işin başında(Jr.) ya da çoktan uzman seviyeye(Sr.) erişmiş durumda! Arada kalan bir arkadaş yok! Bir zamanlar ünvanım öyle gibi görünse de, geçmişime baktığımda kendimi bir konuda “uzmanlaşmış” göremiyorum nedense. Yönetim kademesine adım attığımda, kendimi geçmiş işlerim ile ilgili “uzman” sanmam büyük bir yanılgıydı. Şu anda gördüğüm de bir çok yazılım geliştirici arkadaşta aynı durum söz konusu. Aynı şirkette 1-1.5 yıl geçirmiş bir çok kişi maaş görüşmeleri ya da yeni iş görüşmelerinde mutlaka “uzman” olarak devam etmek istiyorlar. Bunun suçunu da ne yazık ki yine ikiye bölüyorum. Hep o şikayet konusu olan Y ve Z kuşağı ile şirketlerin yönetimsel beceriksizlikleri. Türkiye’de şirketlerin bir çoğu hala 1970 kuşağındaki babalarımızdan gördüğümüz şirket yönetim anlayışında işliyor. Üzgünüm ki, buna yazılım şirketleri de dahil. Y veya Z kuşağının anlayış / beklenti veya yaşanmışlık farklılıklarını hesaba katmadan, sadece daha fazla para ve “ünvan” ile şirket bağımlılığı yaratabileceğini (hala) düşünen yüzlerce şirket yöneticisi var. Aynı şekilde, Y/Z kuşağındaki arkadaşlar da bir önceki yazıda anlattığım gibi stajyerliğini “çakma” yaparak, Jr. döneminde sadece ezbere dayalı, iki Google araması ile çözülecek sorunları çözerek geçirmiş olmalarına rağmen kendilerini bulunmaz hint kumaşı sanıyorlar. Şu karikatür için -her ne kadar işvereni haksız görsem de- özür dileyemeyeceğim arkadaşlar…

Gereken: Yazılım süreçleri danışmanlığı yaptığım bir şirkette, “Dünyanın parasını döküyoruz, adam/kadın hala ‘o iş öyle olmaz’ diye itiraz ediyor” cümlesini duydum. “Improvements” konu başlığında yönetici aleyhine “kırmızı” madde olarak yerini aldı. Bir yönetici olarak bana gelen “o iş öyle olmaz” itirazı, en güzel ve en yerinde tartışma konusu aslında. Çünkü bu sorunun karşılığı olan “nasıl olur peki? İkna et beni” cümlesinin karşılığını verebilecek bir uzman yazılımcı varsa, o kişi aklı çalışan birisidir. 10 yıl boyunca C# yazmış olması bir kişiyi uzman yapmayabilir. “İkna edebilir misin beni?” sorusunun karşılığını ne kadar verebildiği ve ne kadar veriye dayalı ikna kabiliyeti olduğu belli eder uzmanlığını. Bir konuya veriler ile itiraz edebilmek, düşünebilmek ile ilgilidir ve yazılım uzmanlığı aslında herhangi bir programlama dilinde kaç yıldır kod yazabildiğiniz ile ilgili değildir. O yıllar sadece, o spesifik dildeki uzmanlığınızı/ezberinizi gösterir. MS Word kullanmak gibi düşünün(ben asla MS Word ya da MS Excel uzmanı olamadım örneğin [denedim!]. Hala içinde hem “portrait” hem de “landscape” sayfalar olan doküman yaratmakta ya da özel bir pivot oluşturmada Google araması yapıyorum).

Bir problem karşısındaki çözümü değerlendirebilip, o çözümün uygulamaya ne kadar uyabileceğini tartmak, araştırma yapmak, veriler üzerinde analiz yapmak, sonuca varmak, o sonucun işe yaramayacağını görebilmek ve işe yarar bir alternatif çözüm üretebilmek; her uzmanlıkta olduğu gibi, “yazılım uzmanlığı” ünvanında da değerlidir. Bu değeri bir de “itiraz edebilme cesareti” ile birleştirebilirseniz, uğraşınız sizi “Teknik Lider”liğe de hazırlar. İnce noktayı bir daha belirteyim ki “abi ben de mükemmel itiraz ediyorum da, kovdular yahu” tarzı mesajların önüne şimdiden geçeyim. İtiraz noktasının sonrasında gerçekten ispatlanabilir, bilimsel metodlar ile gerçekliği gösterilebilir veriler sunabiliyorsanız anlamlı ve mantıklı olursunuz. Diğer türlü her şeye itiraz eden huysuz şirinden farkınız kalmaz. İki ünvan öncesine dönersek, matematik ve algoritmalar konularına eğilmeniz gereken zaman ile ilgili hala bir şeyler yapabilirsiniz. Okuyun, araştırın, meraklı olun ve öğrenin. Yüzlerce ücretsiz internet kursu, binlerce ücretsiz kitap var internette. Aklınızın gözünü açın. Okuyun, araştırın ve öğrenin lütfen. Bu zamandaki üniversiteler tabi ki “öğrenme” ve “sorgulama” konularında basiretsiz kalacaklar üst otoriteye biat ettikleri yüzünden ama, geleceğinizi düşünüyorsanız tek düşünceye esir olmayın, soru sormayı, aklın ve bilimin yolunu bulmaya çalışın. Önümüzdeki yüz yıl geçmiş fantastik hikayelerinin değil, aklın ve bilimin yüz yılı olacak. Kendinizi buna göre hazırlayın.

Kişisel eklenti: Kendimi “yazılım uzmanı” olarak gördüğüm zamanlar sanırım proje yönetimine geçiş öncesi dönemlerime rastlıyor. 2005-2007 gibi işte. Her şeyi en iyi bilen, assembly ve pascal dillerinde kod yazarken, internetin TR’de doğuşuna şahitlik etmiş bir yazılımcıydım sonuçta. Backend – frontend – DB – tasarım ve mimari konularında sabaha kadar tartışabilecek bilgiye sahiptim. Byte değil bit hesabı yapıyordum kullandığım değişkenlerde. Onlarca proje başarmış, bir yarısı kadar da batırmıştım (proje batırma konusu ayrı yazı konusu olsun, çok değerlidir). Bu etrafta gezinen proje yöneticileri ve / veya ekip yöneticileri ne iş yapıyorlardı ki gelip benimle “iş” konusunda tartışma cesaretine sahip olabiliyorlardı…

Şu anda düşündüğümde, tabi ki bu fikirlerim komik geliyor. “İş” konusunda bilgim o kadar azdı ki… Teknik konulardaki bilgilerim ne kadar yüksek olursa olsun, iş konusunda kocaman bir sıfırdım ve “iş” için çok farklı disiplinlerden, çok farklı şeyler öğrenmem gerekiyordu. Bir değişkenin bellekte tutacağı yerin bir “word” ya da bir “bit” olmasını bilmek, 6 ay sonrasının getirilerindeki “forecast” değerleri için çok da önemli olmayabiliyordu bazı durumlarda. Ben ise “forecast” kelimesini duymuş olmama rağmen, yeni öğreniyordum… “İş” öğrenmem gerekiyordu, işi öğrenmem için ise kendimi biraz daha pişirmem ve “teknik ekip lideri” pozisyonuna koşmam gerekiyordu.

Geri kalan hikaye ve görüşler Ekim Mırmırık’ının olsun (“in your face October Mırmırık” diyeyim ben de Ağustos’taki gibi.)

Biterken çalıyordu:

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

Hobi olarak gördüğüm 1990-1998 arası zamanlarımı saymazsak, 1998 yılında profesyonel olarak başlayıp, uzun yıllar sürdürdüğüm yazılım geliştiricilik maskesini çıkartıp, işin daha çok analiz kısmına ve proje yönetimine girmeye başlamam 2007 yılına dayanıyor. Restoranın mutfağından çıkıp içeride oturan müşteriler ile birebir ilgilenmeye başlayalı 10 yıl kadar olmuş(Restaurant, şef ve aşçı ve yazılım ekipleri arasındaki benzeşimlerin geçtiği yazı “Bir CTO işe alım yapıyor” adında 2014’te yazılmıştı). Neredeyse 20 yıldır, çatışmalarım, yanlışlarım, bilgisizlikle hareket ettiğim zamanlar olmasına rağmen çalıştığıma, iş ile ilgili konularda gerektiği gibi davrandığıma, özel hayatımdan da ödün verdiğime ve şu anki mutlu iş hayatıma kavuştuğuma inanıyorum. Bu yüzden “yazılımcıdan yönetime geçiş” konusunda biraz ahkam kesme hakkı görüyorum kendimde.

Yönetim süresi kapsamında, öncelikle uluslararası bir bankadaki yazılım grubunda teknik proje yöneticiliği (ki iş için aktif olarak kod yazdığım son dönemdi), sonrasında da zamanının en başarılı yazılım firmalarından birisinde sırasıyla proje yöneticiliği, IT takım yöneticiliği ve IT yöneticiliği yaptım. Devam eden yıllarda, öncelikle, ana işi yazılım üretim tarafının dışındaki bir e-ticaret firmasında ve sonrasında uluslararası bir ödeme ve para gönderim şirketinde IT direktörlüğü görevlerinde bulundum. Tamamını bırakıp kendi işime sarılmam ve Türkiye’deki girişim firmalarına destek vermeye başlamam da 2 yıl kadar olmuş. Bu geçen sürede deneyimlediğim Türkiye’de yazılımcıdan yöneticiliğe geçiş sürecinin neden sancılı olduğunu ilk elden görme fırsatım oldu. Bu iki yazı, benim “samimi olan”  özgeçmişim olacak (Neden özgeçmişime döndüğümü inanın ben de çok bilmiyorum. Devam edeyim bakalım, bağlayacağım bir şekilde)

Hayatı bir ve sıfırlar ile geçmiş kişiyi alıp, ona “hadi bakalım sen şimdi bu yazılım işlerinden yavaş yavaş elini eteğini çek, ekip bu, onlara liderlik et, al bak şu işi geliştir, ekip yarat, gençleri eğit ve onları yönet” denilince, hele bir de “ego” yüksekse ve bir de “title” verilmişse durum ilk başta şöyle olabiliyor:

Kendimizi kuzeydeki kral gibi hissederken, gözden kaçırılan bir çok şey oluyor. Bendeki sorun teknik anlamda doyuma ulaştığımı ve çok iyi kod yazdığımı sanmam, bunun ekip yönetimi için yeterli olacağını düşünmem ve sanırım yönetim kademesindeki bir kişide olması gerektiğinden çok daha fazla egoya sahip olmamdı. Her şeyi kendi yapmaya alışmış, en küçük detaya kadar ben bilirim fikrindeki, her teknik şeye burnunu sokan ve tam bir “mikro-management” yönetim sürdüren birisinin, yönetimsel problemlerin tümünün birden altından kalkamayacağı aşikar aslında. Zor yollardan öğrendim bunu. Bir kaç konuya dikkat edilmezse, aşağıdaki duruma gelmek inanın ki bir ay bile sürmüyor:

Sevdiğimiz ve saydığımız sevgili Jon Snow’un konuya özgü iki durumunun da tam olarak içinde bulundum ilk zamanlarımda. Tecrübe kazanmam, alışkanlıklarımı ve yöntemlerimi değiştirmem gereken onlarca durum vardı. Olaylara teknik gözle bakan bir insandım ve benden iş geliştirme, ekip yönetimi ya da aylık yönetim kurulu raporları gibi “boş işler(!)” bekleniliyordu. Ben bunlara gerektiği şekilde adapte olamamıştım. Bu konulardaki sosyal becerilerim çok iyi değildi. Onlarca sorun üzerime geliyor, teknik konulara benden daha yetkin arkadaşlar ekipte olmasına rağmen illa ki burnumu sokuyor, C-Level adı verilen üst yönetim ile (bana göre) mantıksız davranışları yüzünden tartışıyor, ekibi kendi başına bırakıp, o sorunlar ile birebir boğuşmaya çalışıyordum. Ekip de başlarında düzgün bir yönetici olmadığı için kendi bildiğini okuyup müşteri / kullanıcı isteklerine plansızca “dalıyordu”. Cahil olduğum bir alanda kendimi eğitmem gerekiyordu.

Bir yazılımcının bir şirkete girip de, ilk profesyonel kodunu yazmasından, CTO ünvanını almasına kadar geçen sürede (eğer ki tercih bu yönde ise), aşağıdaki adımların her birisinin çok önemli olduğuna inanıyorum. Her adımı/ünvanı belki ayrı yazı konusu yapmak gerekir, ancak anlatmak istediklerime zemin olması için, özeti bu iki yazıda vereyim. Aşağıdaki ünvanların aslında bizim ülkemizde dağıtıldığı kadar kolay harcanmaması gerektiğine inanıyorum. Bu yazı dizisinde de bu tezimi savunacağım. Arada onlarca ara katman / ünvan yer alabilse de, genelde bir yazılımcının iş hayatındaki basamakları şu şekilde oluyor Türkiye’de (Ülkeyi özellikle belirtiyorum çünkü yurtdışında farklılıklar olabiliyor):

1. Stajyer
2. Junior yazılımcı
3. Yazılımcı
4. Uzman / Senior yazılımcı
5. Teknik lider / mimar
6. Takım/ekip yöneticisi
7. IT yöneticisi
8. CTO / CIO (İkisi eş değer görülse de farklar büyük aslında)
9. CEO?

Bunların ilk ikisini, kendi kişisel deneyimlerim ile bu yazıda ele almaya çalışacağım. Diğer adımlar/ünvanlar da diğer yazı konusu olarak kalsın(“in your face September mirmirik”).

1. Stajyer

Gerçekler: Ülkemizde stajyer, fotokopi çeken, getir götür işleri yapan ya da sadece staj defteri imzalatmak için “fake” görev alan kişi gibi görülüyor çoğu zaman. Konunun işveren ve işçi olmak üzere iki tarafı var. Stajyer olan, staj dönemini sadece zorunlu bir görev olarak gördüğü için pek ciddiye almıyor ve baştan savma bir zaman geçirip, bitse de gitsek fikrinde oluyor. İşveren ise ucuz (ücretsiz/bedava) işçi bulduğunu düşünerek hiç bir yatırım yapmadan ne kadar sömürsem kardır mantığında kalıyor.

Gereken: Stajyer tarafında bu sürecin tam bir gerçek ortam deneyimi olduğu bilinci yükselmeli, işveren de staj yapmaya geleni iyi bir çekirdekten yetişen kadrolu elemanı olarak görmeli. Eğitim ve bilgi birikiminin arttırılmasına yönelik olarak stajyeri konumlandırmalı ve ona mentor desteği sağlayarak kadrosunu zenginleştirmeli. Stajyer arkadaş da, son sınıf değil daha 3. sınıftan başlayarak stajın onun hayatına yön verecek bir zaman dilimi olduğunu kabul etmesi ve işe sarılması gerekli. Dediklerimin kulağa hoş geldiğini ve “boş” gibi algılandığının farkındayım. Ülkemizdeki durum yüzünden bu dediklerim çok akıl karı değil gibi. Ama bunları yapmamaya, günü kurtarmaya devam ettikçe sürdürülebilir bir iş deneyimi yaşayamayacağımız gibi, on yıl sonrasında devam eden bir işimiz bile olmayabilir. Yani kısacası, sevgili üniversite ve lise öğrencileri… Lütfen stajınızı size kadrolu elemanmışsınız gibi davranan bir yerde, öğrenimlerinizi devam ettirebileceğiniz bir şirkette, iyi bir ekip ile ve de işe çok sarılarak yapın. Şirket sahiplerinin vergi yükü ile bu kadar ezildiği bir ülkede “lütfen stajyerlerinize iyi imkanlar sunun” demem abes olsa da, stajyerlere “biz eğittik gitti başka yerde sefasını sürecek” kişi gözü ile bakmayın ve kadrolu eleman yetiştirebilmek için seçim yapın.

Kişisel eklenti: Lisede sanayi stajımı Balıkesir’de çok sevdiğim bir “Commodore/Amiga/PC oyunları satışı” yapan(o yıllardakiler iyi bilir) ve aynı zamanda da samimi müşterilerinden oluşan küçük bir ekip ile “Pascal dilinde yazılım yapıp satan” bir şirkette (HCS) yapmıştım. Oradaki ekip ve dostluklar asla unutulmaz. Öğrendiklerim, gördüklerim ve bir bilgisayar yazılımının nasıl da bir “yaratım” işi olduğunu anlamam burası sayesinde oldu. Assembly’de kendimi geliştirdim, BBS ile ilk “modem” bağlantımı da burada yaptım. Elektronik devreler ve tasarımları konusunda tam bir saha çalışması yapma imkanı da buldum(Biraz fazla RS-232 kartı yakmış olabilirim). Sabah “dükkanı” açıp yer de sildim, vitrin de düzenledim. Bunlar şimdiki ev temizliğimi yaparken de çok işe yarıyor

Üniversitedeki ilk stajımı ise zamanının iyi bankalarından birisi olan Esbank’ta, AS/400 sistemleri yanında PC / internet yazılımları da üreten bir ekip ile yapmıştım. İkinci (son sınıf) stajımı ise zaten yarı-zamanlı olarak çalıştığım Coretech firmasında tamamladım. Bankaya girişim içerideki tanıdık olan sevgili Serkan abimin özgeçmişimi ilgili kişilere iletmesi sayesinde oldu. İki staj sürem de resmi olarak 20 iş günü olmasına rağmen, lisede 4 ay, üniversitede ise 3 ay kadar çalışmıştım (Coretech dönemini zaten bir çalışan olduğum için saymıyorum). Öğrenebildiğim kadar öğrenmeye çalışmış, yeni onlarca yöntem ve bilgi edinmiş, merak tatmini sağladığım için mutlu olmuştum.

2. Junior yazılımcı

Gerçekler: Herhangi bir üniversitenin herhangi bir bölümünden mezun olmuş ve herhangi bir yazılım kursundan herhangi bir konuyu bitirmiş herkes kendisini “yazılımcı” olarak adlandırıyor ne yazık ki. Bu gördüğüm, yaşadığım bir gerçek. Mütevazi davranan ve var olan bilgisini satmayı beceremeyen kişiler ise çoğunlukla elenip gidiyor arada (Ne lise mezunları vardı ki ben dahil bir çok “yazılımcıyı” cebinden çıkarıp, bir algoritmada size ters takla attırabiliyorlardı). Herhangi bir işe girmenin ilk yolunun parlak bir kariyer.net özgeçmişi olduğu devirler biraz geride kaldı. Bir önceki konuya bağlı olarak, staj döneminde katkı sağladığı projeler ile göz doldurmuş kişilerin bile bir yere girip de başarılı yazılımcı olmaları zorlaşıyor. Daha çok, tanıdık kişilerin referansları ile işler ilerletilmeye çalışılıyor. Bu noktada “tanıdıklık” kavramına açıklık getirmekte fayda var aslında. Tanışıklığın becerilerden ve “network” kaynaklı olması ile, “mahalledeki sevilen bir abimizin çocuğu” olması arasında çok fark var.

Gereken: Algoritmalar ve matematik konularına ilgi duyan, bir yazılımın sadece bir text dosyaya satırlar yazmaktan ibaret olmadığını bilen kişilerin çoğalması gerekiyor. Bu olgunluğu verecek olan da sadece üniversite değil (ki an itibari ile ülkemizdeki üniversiteleri düşününce iki elin parmaklarını geçmezler bu şekilde eğitim verenler). İçten gelen bir ilgi ve bilgi açlığı olması da kaçınılmaz. Bu ilginin uyandırılması ve gençlerin içindeki bilgisayar bilimleri sevgisinin açığa çıkarılması ne yazık ki yine ortaokul / lise eğitimlerine ve aileye kadar dayanıyor. İstenildiği kadar bilimsel eğitim peşinde koşmanın iyi olduğunu söyleyelim, herhangi bir hükümetin “ben evrim değil de, cihat öğreteceğim bundan sonra” demesi ile geleceğin kapkaranlık hale gelmesi hep olası. Atılması “gereken” adımların bireysel olarak değiştirilebilecek bir şey olmadığının anlaşılması da söz konusu olabilir. Kim bilir, belki de bireysel olarak da çok şey yapabiliriz!

Kişisel eklenti: Türkçe kelime olarak “junior” yerine ne koyacağımı çok bilemedim yıllardır. Hala da bilmiyorum. Staj dönemini başarı ile geçmiş, öğrenmeye devam etmiş, bilgi açlığına devam eden, üç-dört yazılım projesi geliştirilmesinde bir şekilde rol almış, süreçler ve yazılım yaşam döngüsü konusunda bilgi sahibi, algoritmaların ne kadar önemli olduğunu bilen ve önemseyen kişi gibi görüyorum ben. Ekip içinde olduğunu anlaması, kişisel hırslarını bir kenara koymaya başlaması gereken bir süre. Sosyal becerilerin geliştirilmesi için mükemmel zamanlama…Staj sonrasındaki ilk iş aslında. Kaynak kullanımı (bellek / disk / zaman) konusunda hassasiyeti olan, GitHub / Stackoverflow gibi oluşumları çoktan öğrenmiş olan, kendisine en az bir yıllık gelişme programı yapabilmiş olanlar benim gözümde ışık patlamalarına yol açıyor.

Ben Jr dönemimi üniversite 3. sınıfta yarı-zamanlı çalışmaya başladığım ve benim için hala bir okul olan Coretech’te geçirdim. Klasik hikaye… Internet Türkiye’ye yeni yayılmaya başlamış ve herkes her şeyi yapar halde. Müşterinin isteği öğrenilip, tahta başında DB tasarımı, Adobe Photoshop’ta tasarım. Sonrasında çıkan tasarımı kesip biçerek HTML hazırlama, JS ile sayfaya dinamiklik kazandırma, ASP ile sunucu kodlarının yazılımı, SP ve TRIGGER’lar ile DB desteği… Artık ne varsa işte! Bugünlerde “full-stack developer” diyorlar bu şekildeki çalışmaya galiba. Bu dönemin bendeki en büyük kazanımları, işlerin nasıl yürüdüğünü çok yakından görmüş olmam ve müşteri isteklerinin “asıl” olduğunu anlamaya başlamış olmam. Şansım, çalıştığım firmadaki “patronların” sabah 04:00’lere kadar bizler ile bir ufacık problem ile ilgili oturup bire bir çalışıyor olmaları ve hepsiyle “arkadaş” olmamız idi.

Yazının devamı, Eylül ayının Mırmırık’ına ait… Buradan çekileyim şimdilik!

Yazı biterken çalıyordu:

The post Yazılımcı maskesini çıkarıp yönetici olmak / I 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.

Buradaki sonucu şöyle de dile getirebilirsiniz. Yönettiğiniz/sorumlusu olduğunuz ya da içinde olduğunuz ekipteki kişilerin birlikte çalışma tecrübesi ne kadar yüksek ise, yaptığınız projenin başarıya ulaşma şansı da bu tecrübe ile doğru orantılı olarak artmaktadır. Ya da madem ekip yöneticisi sizsiniz, ekibinizi bir arada tutmak ve ekip içi uyumu yükse seviyeye getirmek en büyük amacınız olmalı. Konuyu sayısal veriler ile de örneklemeye çalışayım. Örnek olarak da piyasada 15 yıldır var olan bir yazılım şirketinde çalışan iki ayrı ekip bulunsun. İki ayrı IT ekibinin üyelerini de şu şekilde ele alalım(tamamen varsayıma dayalı verilerdir aşağıdakiler, araştırmaya ya da deneyime dayalı değildir)

EKİP 1.

1. Proje yöneticisi: Ekipte 2 yıldır bulunuyor, toplam piyasa tecrübesi 4 yıl.
2. İş analisti: Ekipte 4 yıldır bulunmakta toplam iş tecrübesi 5 yıl.
3. Senior yazılımcılar: Ekip içinde 2 adet var ve ekipte bulunma süreleri 3 yıl ve 7 yıl. Toplam tecrübeleri ise 8 yıl ve 11 yıl.
4. MidLevel yazılımcılar: Ekip içinde 5 adet var. Sırasıyla ekipteki zamanları; 3, 3, 4, 4 ve 5 yıl. Toplam iş tecrübeleri ise yine sırasıyla; 5, 5, 6, 7 ve 8 yıl.
5. Junior yazılımcılar:  Ekip içinde 3 adet var. Sırasıyla ekipteki zamanları; 6 ay, 1 yıl ve 1 yıl. Toplam iş tecrübeleri ise yine sırasıyla; 1, 1,5 ve 2 yıl.

EKİP 2.

1. Proje yöneticisi: Ekipte 6 aydır bulunuyor, toplam piyasa tecrübesi 8 yıl.
2. İş analisti: Ekipte 1 yıldır bulunmakta toplam iş tecrübesi 7 yıl.
3. Senior yazılımcılar: Ekip içinde 2 adet var ve ekipte bulunma süreleri 6 ay ve 1 yıl. Toplam tecrübeleri ise 12 yıl ve 15 yıl.
4. MidLevel yazılımcılar: Ekip içinde 5 adet var. Sırasıyla ekipteki zamanları; 1 ay, 2 ay, 6 ay, 10 ve 12 ay. Toplam iş tecrübeleri ise yine sırasıyla; 4, 7, 7, 9 ve 10 yıl.
5. Junior yazılımcılar:  Ekip içinde 3 adet var. Sırasıyla ekipteki zamanları; 1 ay, 1 ay ve 2 ay. Toplam iş tecrübeleri ise yine sırasıyla; 1,5, 2 ve 2,5 yıl.

Yukarıdaki verilere göre iş tecrübeleri ve ekip içindeki zamanlarını tabloya döktüğümüzde bizi şu karşılıyor:

* tüm sayılar “yıl” bazında verilmiştir.
* SSD, MSD, JSD arasındaki bilgi birikim farkları dikkate alınmamıştır.
* SSD: Senior software developer
* MSD: Mid-level software developer
* JSD: Junior-level software developer

Buradan görüldüğü gibi Ekip2’nin ciddi bir piyasa tecrübesi var. Toplam 85 yıllık bir bilgi birikimine karşı Ekip1’in 63,5 yıllık bir tecrübesi bulunmakta. Ekip2’nin toplam tecrübesi neredeyse Ekip1’in 1,5 katı(kesin sayı 1,33). Oysa buradaki en dikkat çekici ve aslında bu yazıya temel oluşturan araştırmanın iddiasına da konu olan rakam, ekip içindeki birlikte çalışma tecrübeleri. Ekip1 bu konuda Ekip2’nin neredeyse 6 katı kadar “birlikte çalışma tecrübesi”ne sahip(kesin rakam 6,37). Böyle iki ekip sunulduğunda başarıya ulaşma konusunda siz kimi seçersiniz? Bu sorunun çok net bir cevabı yok tabi. Sonuçta birlikte çalışma sürelerini arttırma amaçlı olarak 2. ekibe yatırım yapmak da karlı bir durum olabilir. Ancak bütçe/süre gibi kısıtlamalara bakıldığında ve yapılan araştırmaya güvenildiğinde, 1. ekibin çok daha başarılı olabileceği gibi bir sonuca ulaşılıyor.

Gelelim bir de kişisel tecrübelere… Geçmişe bakınca, kişisel tecrübelerimin, bu araştırma sonucuna oldukça uygun olduğunu görüyorum. Birlikte daha uzun süre çalışan ekipler, geliştirdikleri projede çok daha başarılı olurken, toplam tecrübesi yüksek olan ekipler eğer birlikte çalışma deneyimleri yoksa/azsa projeyi gerektiği süre/bütçe içinde bitirememe durumu ile karşılaşabiliyorlar. Bunun sebebi, ekipte kimin neye ne kadar ilgisi ve bilgisi olduğunun tüm ekip içinde net bir şekilde biliniyor olması, süre planlaması yapılırken de bu bilginin %90 üzerinde bir başarı ile tahmin ediliyor olması olabilir.  Yani PM bir görevi bir yazılımcıya verirken, ondan aldığı sürenin doğruluğuna ne kadar güvenirse o kadar başarılı planlama yapacak ve proje planına ve verilen sözlere o kadar uyacaktır.

Kapanış notu: Yazılım ekiplerinde gördüğüm, bir kişinin ekibe ve dolayısı ile yapılan yazılıma/projeye direkt yardımı, ancak işe alımdan iki ay kadar sonra başlayabiliyor. Bu rakam alınan kişinin geçmiş tecrübesi ile çok da doğru orantılı olarak kısalmıyor. Yani yeni takım arkadaşının 10 yıllık piyasa tecrübesi olması, bu iki aylık süreyi iki güne indirmiyor. Süregelen bir projeye yeni katılan herhangi bir eleman için durum maalesef böyle. Bunun bir ayı ekibi ve çevreyi öğrenmek, diğer ayı da projenin/yazılımın detaylarına girmek ile geçiyor(sıra tabi ki bu şekilde değil, hatta sıra bile yok aslında). Projenin/yazılımın büyüklüğü ile doğru orantılı olarak bu rakamlar artış gösterebiliyor ancak ortalama süre bu.

The post IT ekibindeki toplam tecrübe appeared first on mirmirik.net.

Aşağıdaki görüşlerim ve uygulamalarım büyük bir olasılıkla insan psikolojisi ve bunu anlamak ile de ilişkili. Salt olarak bu kuralları doğru kabul etmek ve uygulamaya çalışmak ya empati yoksunluğunu ya da insan ilişkilerindeki çözülmesi çok zor olan ilişki ağlarını anlamamak ile ilgili olabilir. Burada yazılanları ofisinizde denemenizden sorumlu olmayacağımı tekrar söylemek istedim.

Gücünüzü öğrenin!

Her yeni konuma gelen gibi, ilk yaptığım şey kendi çevremi ve o çevredeki konumumu anlamaya çalışmaktı(bunu sadece iş yeri için sınırlamamak da lazım. Sosyal herhangi bir ortam için bu durum geçerlidir bu içgüdüsel davranış). Yeni çalışma ortamımda ilk önce çalışma arkadaşlarımı oluşturan ekipte kim neyi yapıyor ve kim hangi konulardan sorumlu araştırmasına girdim. Kulaktan dolma ve tahmin yürütme yerine bunu herkes ile birebir görüşerek yapmayı tercih ettim ki bence hem çalışma arkadaşlarınıza saygı duymanız hem de saygı görmeniz açısından en doğrusu bu. Üst yönetimin ekibinizdeki kişiler ile ilgili varsayımlarına tamamen kendinizi kaptırmanız(x şundan sorumlu, y şunu iyi bilir gibi) sizi hem önyargılı yapar hem de oluşan önyargılarınız yüzünden yanlış kaynak seçerek gerekli verimi alamaz ve belki de ileride ihtiyaç duyacağınız değişikliği yapamaz duruma gelirsiniz. Ekibinizin içindeki dinamikleri anlamazsanız, potansiyel dinamiği, sorumlu olduğunuz uygulama yararına yönlendirme şansınız olmaz. Varolan gücünüz, şirkette yöneticiler tarafından size verilen “title” ile ilgili olmaktan çok, ekip olarak sizin neyi başarabileceğiniz ile ilgili olduğuna inananlardanım maalesef. Bu yüzden “varolan güç” kavramı, benim için “ekip olarak neyi daha iyi yapabiliriz” sorusu ile bağlantılı. Bu gücü öğrenmenin en iyi yolu da ekip ile iyi iletişimden geçiyor.

Test edin!

Gücünüzü test etmenin en iyi yolu, güvenilir bulduğunuz bir projede değişim için gerekli gördüğünüz adımlardan bazılarını atmanızdır. Hani hep yürümeden önce emeklemek derler ya, onun gibi bir şey. Daha önce çalışmakta olduğunuz yerde başarıyla uygulanan bir sistem cidden mükemmel olabilir ama bunu şu anki yere “hemen” uygulamanız çok da mümkün değil aslında. Bunu kabullenin ve ufak adımlar ile başlayın. Önceki şirketimde projelerdeki planlamalar için uygulanan güzel bir sistem vardı. Bunu öncelikle ekip arkadaşlarım ile paylaştım ve onlara bu sistemin bize olacak faydalarını anlattım. Üst yönetime giderek bir projede kendi iş yapış yöntemimi uygulamak istediğimi ve bunun şirkete faydalı olabileceğini söyledim. Sonrasında da bu sistemi savunabileceğim verileri elde edebilmek için bir dolu soru sordum ekip arkadaşlarıma(x işi için sence kaç saat harcarız? Peki sence bunu da eklersek buna sence bizi ne kadar etkiler? Şöyle bir istek var y departmanından, sence yapmalı mıyız?). Daha sonra elimdeki tüm verileri test edeceğim projeye uyguladım ve projenin takibini de bu veriler doğrultusunda yaptım. Şansıma ilk deneme oldukça başarılı geçti ve hem ekip arkadaşlarım hem de işi isteyen departman ve yönetim sonuçtan memnun kaldı. Acemi şansı belki de ama matematik yalan söylemez.

Daha iyi sonuçlar elde edin!

Yöntem farklılığının başarı ile sonuçlanması sayesinde bazı şeylerin ilk etapta zahmetli olsa da daha iyi olabileceği fikri kabul görmeye başlayınca, yönteminizi tüm projelere yayın. İlk denemeniz sonucunda zaten öngördüğünüz iyileşmeyi gördüyseniz bir sonraki aşamaya geçin ve kendinize daha zorlu bir proje seçin. Yöntem değişikliğinden emin olmak ve bu değişikliğin uygulamanıza/şirketinize getireceği yararların ölçülebilir olduğunu ancak daha fazla veri ile elde edebilirsiniz. Korkmayın! Bir çok kişi yaptığınızın saçma olduğunu, zaman kaybettirdiğini, dün bitmesi gereken bir çok işin biriktiğini söyleyecektir ama yılmayın. İlk test verilerinizi önlerine atın ve bunun gücünüze güç kattığını unutmayın(güvenen ekip=güç). Bırakın bir kaç proje geciksin. Bu gecikmeleri de asla bahaneler arkasına saklamayın. Sorumluluğu mutlaka üstlenin. Yeni yöntemden dolayı gecikmeler/hatalar ortaya çıktığını ama zaman içinde düzeltilebileceğini anlatın. Buradaki “düzelecek zaman” konusunda şunu yapmanız da yardımcı olacaktır. Diyelim ki artık baskılara dayanamaz duruma geldiniz. Kolay bir projeye geri dönün ve onu gerçekleştirin. Eliniz hem daha da güçlenecek, hem de “zaman” kazanmış olacaksınız.

Elde ettiğiniz sonuçları paylaşın!

Yeni çalışma alışkanlığının sonuçlarının -alışması zor olsa dahi- matematiksel olarak daha iyi olduğuna ikna edebiliyorsanız önünüzdeki bir çok engel ortadan kalkacaktır(ki matematik yalan söylemez). Burada en önemli tutum aslında yöneticilerinizin tutumu. Türk çalışma mantığına alışmış, daha klasik yöntemleri tercih eden, günümüz söylemleri ile statükocu bir yönetim anlayışınız varsa bu adımı aşmanız çok daha zor olacaktır. Bu durumda matematiksel veriler cidden elinizi güçlendirecek ve işinizi hızlandıracaktır. Yaptığınız işlerin “ölçülebilir” veriler doğuruyor olması bu sebeple çok önemli. Daha önceden x zamanda yapılan y işi, yeni yöntemle x+4t zamanında gerçekleşiyor ama, bunun bakım maliyetinde ve gelmesi öngörülen işlerin uygulanma sürelerindeki kısalma sayesinde toplam geliştirme maliyeti 2 adam/ay kazandırıyor dediğinizde emin olun bir şeyleri başarabileceğinizi gösterirsiniz.

‘Yandaş’ toplayın(kaynak isteyin)!

Gerçekleştirdiğiniz projelerde, yaptığınız değişiklik sayesinde olumlu dönüşler oldukça, yeni yöntemleriniz daha çok saygı görecek ve kabul edilir olacaktır. Adice gelebilir yazınca ama, kendi tarafınıza çektiğiniz her kişi ile aslında yöntemi uygulamak isteyen “ekip” güçlenecek ve değişime bir adım daha yaklaşacaksınız. Yeni yöntemin her projeye uygulanması için üstünlüğünüzü lehinize çevirin. Her isteğe bunu uygulayabilmek için üst yönetime talepte bulunun. Eğer ki bunu elde edebilirseniz, bu durumda #1 numaralı adıma geri dönmeniz ve yeni gücünüzü öğrenmeniz yerinde olacak.

Değişimi gerçekleştirmek yazıldığı ya da anlatıldığı kadar kolay değil hiç bir zaman. “Bu böyle olmaz”, “bunu şöyle yap”, “ben bunun şöyle olmasını istiyorum” ya da “ben ne dersem o” tavrı ile karşılaşmanız özellikle Türkiye şartlarında çok olası. Önemli olan değiştirmek istediğiniz alışkanlıkların ne kadar yerleşik olduğunun farkına varmanız ve hangi noktaya müdahalede bulunabileceğinizi bilmeniz. Bu da bence iki temele dayanıyor. Değişimi gerçekleştireceğiniz ekibe ve ne kadar inatçı olduğunuza…

The post Alışkanlıkları değiştirmek appeared first on mirmirik.net.