Neredeydim, ne oldu?

2018 Mayıs ayında, uzun yıllardır arkadaşım olan ve her yıl gösterime giren yeni nesil Star Wars filmlerinin geceleri yapılan ilk gösterimini beraber izlediğim sevgili Barış Sarıalioğlu ile birlikte bir hayali gerçekleştirmek için adım attık. Bu oldu. Emekliliğimi alacağımı düşündüğüm ve bu yola da baş koyduğum TesterYou isimli firmanın bir neferiyim ben artık. Tüm gecem ve gündüzüm sadece burada. Genelde tüm yazılım yaşam döngüsündeki süreçlere, özelde ise yazılım test süreçlerine danışmanlık ve eğitmenlik yaptığımız bir oluşum kurduk. Çok güzel oldu. Daha da güzel olacak.

Hem bu işin getirdiği yeni öğrenmeler, hem de alışkanlığımdan dolayı yaptığım okumalar ve araştırmalarda, karşılaştığım şey tekrar şu oldu. Yazılım dünyasının kalite anlamında çok fazla eksiği var ve bu eksikliklerin ana unsuru da, bu geliştirmeyi yapan bizler ve bizlerin sahip olduğu rasyonel olmayan tutum ve tavırlarımız. Evrimimiz bizleri bu güne kadar getirdi ve en azından dünyaya hükmeden “en zeki” canlı türü olarak sağ kalabildik. Gelişen teknolojiyi yarattık, kullanır hale geldik ve geliştirmeye de devam ediyoruz. Bakılan açılara göre “çok şanslı bir çağda” ya da “tamamen şanssız bir çağda” yaşıyoruz. Yazılım yaşam döngüsündeki kişiler olarak (analistinden son kullanıcısına, geliştiricisinden proje yöneticisine, ‘creative ajans görevlisinden’ CTO’suna kadar herkes bu döngüde diye düşünelim), bu geliştirmelere ayak uydurmaya çalışıyor, işimizi ‘en iyi şekilde’ yapmaya çalışıyoruz. Ama hala bir şeyler tam da olması gerektiği gibi olmuyor. Bunun sebebi sadece süreçte kurallar olmaması, kurallara uymamak, araç eksikliği olamaz diye düşünüyorum. Yazılım geliştirme işinde her ne kadar “sayısal” iş yapılsa da,  insan dediğimiz canlı türü, savanada canlı kalmak için 200.000 yıldır geliştirdiği beyinsel becerilerin etkisi altında hala. Bu etkilerin izlerinin yazılım dünyasında ne kadar etkili olduğunu merak ettiğimden, altta yatan “insan faktörü” konusunda daha fazla araştırma yapmaya karar verdim. Bazı bulgularımı İngilizce olarak şirketimizin sitesinde bir blog post olarak yayınladım. Bu yazı da, hem onun Türkçeleştirilmiş hem de daha kişiselleştirilmiş hali olacak. Başlayalım bakalım…

Yazılım Kalitesi

Yıllar içinde, yazılımın kalitesinin ve doğru çalışmasının onaylanması sayılan testler, sadece son dakikada “bug” bulup bunları raporlamaktan, “hata meydana gelmeden önce önleme”ye doğru evrilmiş durumda. Bunda, yoğunlukla kullanılan “Waterfall” proje yönetim metodolojisinden “Agile” yönetim süreçlerine geçişin de etkisi çok büyük. Hala tersini yapan bir çok yazılım evi/birimi de var ama, gelişme gözle görülür bir şekilde iyi yönde.  Yazılım geliştirme yaşam döngüsünün (SDLC¹) analiz gibi ilk safhalarında başlayan testler, hem kalitenin artmasını sağlamakta, hem de ürünün piyasa başarısızlığını engelleyecek adımları atmaya yardımcı olmakta. Yazılım yaşam döngüsü içindeki hemen herkes (analistler, geliştiriciler, proje yöneticilerileri, test uzmanları ve üst düzey yöneticiler), testlerin, henüz geliştirme bile başlamadan önceki zamanlarda başlaması konusunda hemfikir.

İlk zamanlarda daha çok manuel olarak yapılan testler, gelişen teknoloji ile birlikte onlarca araç tarafından desteklenir hale gelmiş, otomasyon araçları ile iş yükünden tasarruf edilmiş, süreç iyileştirmeleri ile daha güvenilir düzeye getirilmeye çalışılmıştır. Artık geliştiriciler, “test” konusunda daha eğitimli ve bilinçli, ürün yöneticileri (ve proje yöneticileri) test etmenin önemini önceye göre daha iyi kavramış durumda. Tüm bu gelişmeler karşısında ise hala bir gerçek var: Ürün, kullanıcı kabul testine(UAT²) geldiğinde ya da daha da kötüsü piyasa çıktıktan sonra onlarca bug barındırmakta ve ürün ve üretici şirket imajı da bu durumdan çok kötü etkilenmekte. İki soru hala aktif olarak şirketin koridorlarında dolaşmakta: Neden böyle oldu ve bu kimin suçu?

Akıllı olan ekipler, böyle bir durumda kendi test süreçlerini kontrol eder, hangi noktada ne tür eksiklikleri olduğunu anlamaya çalışır, performans ya da otomasyona yönelik test araçlarını kullanılıyorlarsa da, o araçları kalibre eder, tüm bunlara bağlı olarak da belki ekip üyelerine daha fazla eğitim verme yönünde seçim yapar. Daha da akıllı hareket eden ekip üyeleri ise bunların tümünün üstüne bir de kendi içlerine, o bizi onbinlerce yıl hayatta tutmuş olan beyinsel işleyişlerimize bakar: Bilişsel önyargılarımız!

Bilişsel Önyargı

Vikipedi Türkçe sayfası (evet, 2019 yılında sadece VPN ile girilebiliyor hala), bilişsel önyargıyı, “diğer insanlar ve durumlar hakkında mantıksız olabilecek çıkarım sapmaları için kullanılan bir kalıptır. Bireyler ellerindeki mevcut girdiler neticesinde kendi nesnel sosyal gerçekliklerini yaratırlar. Öznel girdi yerine, bir bireyin kendi yarattığı sosyal gerçeklik inşası sosyal dünyadaki davranışlarını da dikte edebilir. Böylece, bilişsel eğilimler bazen algısal bozulma, yanlış yargı, mantıksız yorumlama ya da geniş anlamıyla mantıksızlığa (irrasyonalite) yol açabilir.” olarak tanımlamakta. Uzun lafın kısası: “kendi bilinciniz ile oluşturduğunuz önyargılar, sizlerin mantıklı davranışlarınızı kısıtlayabiliyor ve yanlış eğilimlerde bulunabiliyorsunuz“. Ya da bu süslü cümleleri “anneye anlatır gibi” anlatmak istersek; “her birimiz, insan beyninin işleyişi yüzünden, mantıksız ve farkında olmadığımız davranışlar içinde bulunabiliyoruz“.

Eğer bu son cümleye karşı çıkıyorsanız size bir sürprizim var. Buna karşı çıkıyor olmanızın sebebi, “yanılgı kör noktası” (bias blind spot) denilen bilişsel önyargınızdan kaynaklanıyor olabilir. Başkalarının önyargılı davranışlarını, kendi davranışlarımıza göre çok daha hızlı görebilme kusurudur belki de.

Yazılımın testi benim gözümde hem bir sanat hem de bilim olan bir meslektir; temel olarak yazılım özellikleriyle ilgili seçimleri yapma, seçimleri gözden geçirme, değerlendirme ve sonuç çıkarma üzerine oluşan bir meslek. Yazılım testi mesleği ayrıca testleri oluşturma, uygulama ve test sonuçlarının analizi aşamaları boyunca bilişsel önyargıya çok fazla maruz kalmaktadır.

Yazılım test süreçlerini, testleri ve kalite ekiplerini etkileyebilecek birçok bilişsel önyargı türü olduğunu düşünüyorum. Bu konuda yapılacak araştırmaların hem yazılım hem de yazılımcıların kalitesini olumlu ölçüde değiştireceğine inanıyorum. Ben küçük bir katkı olarak, yeni işimizdeki danışmanlık hizmetlerimiz sırasında karşılaştığımız ikisini yazının devamında özetlemeye çalıştım.

1. Doğrulama Yanlılığı (Confirmation Bias)

Tanım: Doğrulama yanlılığı ya da teyit yanlılığı, kişilerin kendi inançlarını, düşüncelerini ve varsayımlarını destekleyen ya da teyit eden bilgileri kayırma, dikkate alma ve öne çıkarma eğilimidir. Bu yanlılığa sahip kişiler inançlarına, düşüncelerine ve varsayımlarına ters düşen, karşı duran, onlarla çelişen bilgileri ihmal etme, yok sayma eğilimi gösterir.

Genelde oluşturulan test senaryolarının “Pozitif Testler” üzerinden gitmesine yol açtığını görüyoruz. Yazılan test senaryoları çoğunlukla, yazılmış olan “analiz” ya da “gereksinim” dokümanlarına bağlı olduğu ve analiz dokümanları da çoğunlukla pozitif ifadeler içerdiği için -doğal olarak- sistemin “ne yapması gerektiğine” daha çok odaklanıyoruz. Pozitif test bizim aklımızdaki senaryoyu da doğrular nitelikte olacağı için, test için kullandığımız verileri bile “doğru sonuç vermesi” için değiştirebiliyoruz.

Bir konuda geçmiş deneyimlerimiz doğrultusunda fikrimizin ve belirli bir örgüdeki “bakış açımızın” olmaması neredeyse imkansız. Bunu yazılım testleri sırasında kendi dünya görüşümüze ve bakış açımıza uygun arayışlar ile yapıyoruz. Hesap makinesi yazılımını düşünün. Gereksinim dokümanında, ekrandaki iki alana girilen rakamların toplanılarak bir “label”‘da sonucun gösterilmesi gerektiği yazıyor diyelim. İki tane textbox var ve biz doğal olarak gidip oraya “nümerik değer” yazıyoruz. Çünkü zihnimiz yıllarca, hesaplamanın rakamlar üzerinden yapıldığını öğrenmiş durumda. Rakamları girip de sonuca baktığımızda ve doğru toplama yapıldığını görünce de testten geçmiş olduğunu varsayıyoruz.

Benzer şekilde, gereksinim dokümanındaki “şifrenin en az 8 karakter olmalıdır” isteği için, test senaryosuna “şifrenin en az 8 karakterli olması gerektiğini” test edecek adımı koyuyoruz ve “olması gerekeni doğruluyoruz. Peki ya en fazla kaç karakter koyabiliyoruz? Veri tabanı oraya 1024 karakter eklesek de izin verecek mi?

2. Sürü Psikolojisi (Bandwagon Effect)

Tanım: Bir yığın kurallar ve koşullar dizisiyle temellenmiş belirli inançların, bir grup, topluluk, ülke vs.’nin (siz bunu IT ekibi ya da agile ekip olarak da düşünün) insanları arasında yayılmasına verilen addır.

Ortak tutuma başvurma safsatası ile de ilişkili olan bu kolaycılık görüşümüz, genelde ekiplerin içindeki otoriter ve yetkin kişilerin fikirlerinin ekip içinde kabul görmesi ve yaygınlaşması ile kendini ortaya çıkardığını gözlemledim. Sprint planlama toplantılarınızdaki “Story Point”‘lerin belirlenmesini düşünebilirsiniz. Ekip içinde yeniyseniz, ne kadar bilgili ve tecrübeli olduğumuza bakmaksızın baskın görüşe doğru yönleniyoruz. “Büyük çoğunluk bu şekilde düşünüyorsa, büyük ihtimalle ben yanılıyorumdur” gibi davranıyor beynimiz. Bu da yanlış bile olsa bazı kararlara katılımımızı sağlıyor.

Benzer şekilde, ekip içinde bir modülün / fonksiyonun hata çıkarmayacağına dair yaygın bir inanış varsa bu modül üzerinde yazılan ya da koşulan test sayısı da düşmekte. Bulunan hatalar bile, baskın inanış bunun aksini söylediği için, kimi zaman göz ardı edilebilmekte (yine, “büyük ihtimalle ben yanlış bir şey yaptım” görüşü baskın geliyor test eden kişiye).

Test uzmanı bir arkadaşta gördüğüm bir davranış biçimi de şu şekilde oldu. Bir ekipte yeni olan test uzmanı, grup içinde kabul edilebilirliliğini arttırmak için, kendisine “bunu bug olarak raporlama, ben hallederim” şeklindeki telkinlere uymaya başlayıp, aslında yazılımın kalitesinden ve ekip içindeki test olgunluğunun yükselmesinden taviz verdi. Ekibin performans ölçüm kriterlerinden birisini “bulunan bug sayısı” olarak koymak, bu türden yanlışlıklara da yol açabiliyor.

Özet

Bilim insanlarına, araştırmacılara ve psikologlara göre karar verme sürecini kendimiz için kolaylaştıran, bizlerin günlük yaşamını etkileyen düzinelerce önyargı var. Bu önyargıların çoğu inanç oluşumunu, ticari ve ekonomik kararları ve genel olarak insan davranışını etkilemekte. Test uzmanları ve kalite ekibi üyeleri olarak, bu önyargıların üstesinden gelmenin kolay bir yolu da yok. Ne de olsa hepimiz insanız, robot değil. Yapabileceğimiz şey, bu önyargıları bilmek ve kabul etmek, irrasyonel davranışların sonuçları hakkında açık fikirli olmak ve şartların gerektirdiği şekilde değişiklik yapmaya istekli olmaktır.

Kısaltmalar, tanımlar

1. SDLC: Software Development Life Cycle, Yazılım Geliştirme Yaşam Döngüsü. Yazılımın, istek oluşma anından başlayıp, analiz, geliştirme, test ve piyasaya sürülmesi süreçlerinin tamamını kapsayan döngü.
2. UAT: User Acceptance Test, Kullanıcı Kabul Testi. Özne olarak yazılımdaki gereksinimleri ve istekleri belirleyen kişilerin geliştirici ekip ile birlikte yaptığı testler.
3. Test senaryosu: Uygulama parçasının doğru çalışması ve istenilenleri doğru yaptığının görülmesi için yazılan adımların ve her adım için beklenen çıktıların tutulduğu şablon.

Yararlanılan Kaynaklar

1. Yalansavar Web Sitesi (http://www.yalansavar.org)
2. Şebnem Özdemir, Buster Benson’un “Cognitive Bias Cheat Sheet” çevirisi (https://medium.com/@behavioralist/buster-bensonun-cognitive-bias-cheat-sheet-t%C3%BCrk%C3%A7e-versiyonu-22baf8e0a5)
3. 18 Cognitive Biases You Can Use for Conversion Optimization. Shanelle Mullin, October 15, 2015. (https://conversionxl.com/blog/cognitive-biases-in-cro/)
4. Wikipedia, List of cognitive biases yazısı, (https://en.wikipedia.org/wiki/List_of_cognitive_biases)
5. Fuqun Huang (June 21st, 2017). Human Error Analysis in Software Engineering, Theory and Application on Cognitive Factors and Risk Management, Fabio De Felice and Antonella Petrillo, IntechOpen, DOI: 10.5772/intechopen.68392. (https://www.intechopen.com/books/theory-and-application-on-cognitive-factors-and-risk-management-new-trends-and-procedures/human-error-analysis-in-software-engineering)
6. Oswald, Margit E.; Grosjean, Stefan (2004). “Confirmation Bias”. In Pohl, Rüdiger F. Cognitive Illusions: A Handbook on Fallacies and Biases in Thinking, Judgement and Memory. Hove, UK: Psychology Press. pp. 79–96. ISBN 978-1-84169-351-4. OCLC 55124398.
7. Kullanılan fotoğraf: Leonard von Bibra on Unsplash

The post Yazılım testlerinde bilişsel önyargılar 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.

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.

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.

Geçen süre boyunca yazılım geliştirici olarak göremediğim –daha doğrusu görmek ve anlamak bile istemediğim- onlarca sorun ile boğuştum. Yazılımcının kafasında yer alan ve dünya görüşünü de oldukça etkileyen sıfır ve bir ikilisinin gerçek hayata aslında ne kadar da uzak durduğuna daha ikna oldum belki de; bilemiyorum(Kendimi yalanlamak gibi olacak ama bence dünya hala sıfır ve bir. Bunu IT sektörü çalışanları dışında kimse de anlamıyor ne yazık ki). Yazılımcıların / IT çalışanlarının asosyal görülmesinin ya da tuhaf yaratıklar gözü ile bakılmasının bir sebebi de bu: Dünya algılarının diğer insanlardan farklı olması.

IT’nin mutfağından çıktığımda yeni ortama alışmam ilk başta çok zor geldi. Doğru matematiksel verileri doğru yöntemler ile istenilen şekilde işlerseniz, her zaman doğru sonucu bulabilirsiniz. Yani düşünseniz ya, “2+2 her zaman 4 sonucunu doğuruyor, şu müşteri neden bu 4’ün illa ki “IV” şeklinde yazılmasını istiyor ki? İkisi de aynı değil mi sonuçta?”(Bana 2+2≠4 ile gelmeyin, kalbinizi kırarım) Ya da daha sosyal ve yazılımcı tarafından hak verilmesi daha da zor bir örnek vereyim; “neden illa ki işe giriş çıkışlarımın takip edilmesi gerekiyor ve bu konudan sorumlu tutuluyorum, sonuçta bana verilen işi bana tanımlanan süre içinde bana anlatıldığı şekli ile yerine getiriyorum!” İşte bu son 7 yılda anladım ki; maalesef kazın ayağı öyle değil ve yazılımcılar aslında pek bir şey de bilmiyorlar gerçek dünyanın ihtiyaçlarına dair(böyle dedim diye alınmayın sevgili yazılımcı dostlarım; kendimden ve gördüklerimden örnek vererek genelleme yapıyorum aslında).

Konu daha da fazla dağılmadan geleyim başlığın açıklamalarına. Mutfaktan çıkıp da içeride oturan müşterinin karşısına geçmiştik değil mi en son?  Tamam. O zaman hemen şu aşağıdaki cümleleri/düşüncelerinizi bir kenara bırakmaya çalışın eski yazılımcı yeni yönetici dostlar(ben çok uzun zaman ikinci ve altıncı maddeyi beceremedim):

1. “Herkes beni ben olarak kabul etsin ve söylediklerimi bir kerede anlasın. Anlamazlarsa onların aptallığıdır”. Yok artık! Karşınızda yazdıklarınızı makine diline çeviren ve yapamadığı zaman size hatanın nereden kaynaklandığını gösteren bir yazılım derleyici yok. Karşınızda insan var ve iletişim dediğiniz nane bilgisayardaki gibi işlenmiyor(Sevgili abim Erhan Eroğlu’na saygılarımla). Söylemek istediğiniz, söylediğiniz, alınan ve algılanan adlı dört farklı sistem düşünün ve bu her sistem arası geçişte veri kaybı olduğunu kabul edin, daha rahat edersiniz. Sevdiğim bir tabir var teknolojide bilgi aktarımı ile ilgili; her zaman “anneye anlatır gibi” anlatın derdinizi. Açık, basit ve çok net olun. Sonra bu anlatımı sabır ile on defa daha yapın. Sonra bir on defa daha!
2. Asla ama asla yazılımın teknik detaylarına girmeyin. Bu artık sizin işiniz değil. (Bence şu şekilde interface yazın oradan türetirsiniz her ihtiyaç olan class’ı. Bir de şu şekilde tablo oluşturup şu şekilde çalışan bir SP çağırın.) Bu asla burnunuzu sokmayın demek değil. Yapılan işi anlamaya çalışmakta ya da işleri teknik anlamda da takip etmenizde hiç sorun yok aslında. Bir işin teknik olarak dert yaratacağını görmüş olabilirsiniz. Ama bunun yolu asla neyi nasıl olması gerektiğini çok bilmişlik taslayıp da anlatmak değil. Tartışmak, sağlam veriler ile karşılıklı doğru yolu bulmak.
3. “Bana verilen işi eksiksiz yapıyorum, bu yeterli olmalı” demeyin. Size iş verilmeyecek duruma gelmelisiniz. Siz iş üretmelisiniz.
4. “Bana söylenen bu, demek ki iş böyle olmalı” da demeyin. Çoğu zaman doğru gibi görülse de, aslında tam olarak öyle değil. Artık sizin göreviniz zaten size söylenmeyeni araştırmak, sorgulamak, bulmak, irdelemek ve bunların gerçekleşmesini sağlamak için akıllıca bir yöntem izlemek.
5. “Tüm istekler benim önüme yazılı olarak gelsin ben de bu yazılı doküman üstünde anlaşmaya varınca işe başlayayım “. Unutun bunu! Her ne kadar çalışılan kuruma bağlı olsa da, çoğu projede size eksiksiz ve PMI ya da CMII öngörülerindeki gibi bir istek listesi ile gelmeyecekler arkadaşlar. Zaten artık sizin işiniz bu dokümanı mükemmel hale getirmek. Unuttunuz mu? Siz artık yazılımcı değilsiniz, yazılımcılara iş verecek kişisiniz. O istek listesinin arzu ettiğiniz gibi mükemmel olmasını sağlamak sizin asli göreviniz.
6. “Ben zamanında her şeyi tek başıma yapıyordum, şimdi neden her görev ayrı olsun isteniliyor ki, JS de yazsın, web service de yaratsın, veri tabanına da baksın”. Bu daha çok ‘90’lı yıllarda yazılım dünyasına adım atmış ve internetin ilk sancılarını yaşamış kişilerde oluşan “kendini bir şey sanma” dürtüsünden dolayı meydana gelmekte. Saçmalamayın! Dünya çok değişti. Ekibinize yeni bir arkadaş katmak için yaptığınız görüşmeniz sırasında size bunların hepsini yapabileceğini söyleyen kişiler ile karşılaşırsanız iki durum vardır. Ya artık soyu tükenmekte olan çok ender bir tür ile karşı karşıyasınızdır ya da karşınızdaki kişi bahsi geçen tüm becerileri çok yüzeysel şekilde biliyordur ve aslında sizi çok daha zora sokacaktır. %97,32 ikinci seçenek çıkacaktır(Dikkat; küsuratlı sayı verdim).

Şimdilik burada durayım ve devamını sonraki yazıya bırakayım.

The post IT Yönetiminde Bebek Adımları – Alışkanlıklar appeared first on mirmirik.net.

Basit olarak bir ASP kodu, web sunucusuna gelen istege göre, sadece sunucunun ulasabildigi imkanlar ile, farkli sunum yapma imkani saglar. Bir veritabanindan bilgi alip bunu istemciye gönderebilir, kullanicidan/istemciden aldigi bilgilere göre dogrulamalar yapip sadece o kullaniciya özel islemler gerçeklestirebilir. Microsoft tabanli sistemlerde, kullanicidan gelen isteklerin -eger bu istek ASP uzantili bir dosyaya yönelik ise- degerlendirilip ‘derlendigi’ arabirimin adi ASP.DLL` dir. Burada ufak bir parantez açip sunu da eklemek isterim. Microsoft sunucu platformunun varsayilan kurulumunda IIS ile sadece ASP uzantili dosyalarda sunucu bazli kodlar çalistirilabilmektedir(.NET ve Vista gelisimlerini göz önünde bulundurmadim). Eger siz uzantisi ASP disinda bir dosyada sunucu bazli kod çalistirmak isterseniz -üzgünüm ama- maalesef bunu basaramazsiniz. Örnegin su kodu:

HTML uzantili bir sayfada belirtirseniz, elde edeceginiz tek sey su olur:

Microsoft sitesindeki .MSPX uzantili dosyalar a dikkatinizi çekerim). Bunun için IIS üzerinde yapmaniz gerekenleri suradaki resimde göstermeye çalistim. Bu resimdeki adimlari takip ederek sunlari yapmaniz gerekiyor

1. Istediginiz uzantidaki dosyayi çalistiracaginiz Web Uygulamasini seçip sag tiklayin ve çikan menüden ‘Properties’ seçin.

2. Uygulama özellikleri penceresindeki bölümden ‘Configuration’ dügmesine tiklayin.

3. Degisik uzantilarin varsayilan düzenlemelerinin yapilmis oldugu ‘Uygulama Ayarlari’ penceresi çikacak. Buradan ‘Add…’ butonuna tiklayin.

4. Sonunda istedigimiz yere ulasabildikten sonra ‘Executable’ sorgusunun oldugu yere bir önceki pencerede ‘.asp’ uzantisina iliskilendirilmis olan ASP.DLL dosyasinin tam yolunu yazin. Benim bilgisayarimda bu dosya ‘c:\windows\system32\inetsrv\asp.dll’ yolunda idi. ‘Extension’ kismina sunucu bazli kodunuzun çalismasini istediginiz uzantiyi önünde nokta olacak sekilde yazin. (örnegimizdeki ‘.mirmirik’). Daha sonra da ‘OK’ butonuna tiklayarak ve öncesinde açilmis olan pencerelere de ayni islemi uygulayarak çalismanizi tamamlayin.

Bu sayede artik su görüntüyü alabiliyor olmaniz gerekir:

The post ASP Uzantisi appeared first on mirmirik.net.