Blogumu Kendi Domainime Taşıdım

Bu blogu kendi domain'im olan https://mucahit.io adresine taşıdım.

The Mythical Man-Month

Frederic Brooks'un The Mythical Man-Month kitabı yazılım geliştirme literatüründe klasik kitaplardan birisidir. Yazılım geliştirmede insan faktörü, kültür, sorunlar, kariyer, organizasyon vs. bir çok konuda bu kitaba referans verildiğini, bir çok kişi tarafından "must read" olarak belirtildiğini görebilirsiniz.

Ben bir kaç defa kitabı okumaya yeltendim ancak yarıda bıraktım, dili yabancı geldi anlamakta zorlandım, bahsedilen konuların günümüze yansımalarını bulmakta zorlandım. Sonunda kitabı bitirmeye karar verdim, bunu yaparken de benimle aynı durumda olan insanlara kitap hakkında genel bir intiba vermek adına özet bazı notlar almaya çalıştım.

Sonuç olarak geldiğim nokta kitabı baştan sona okumak çok gerekli değil. Günümüzde de yaşanılan, en azından daha üst düzeyde yaşandığını düşündüğüm bazı sorunlara değinen bölümleri okumak yeterli. Kitabın 17. bölümünde önceki bölümlerde bahsedilen konular maddeler halinde verilmiş, kitap'da nereyi okumalıyım sorusuna cevap bulmak adına ilk önce o bölüm de okunabilir.

Kitabın ilk versiyonu 1975 yılında basılmış, günümüzdeki teknoloji, yönetim, pazarlama gibi alanların geldikleri nokta itibariyle kitabın güncelliğini kaybettiğini düşünenler olduğu gibi, kitapdaki bahsedilen özellikle insan ile ilgili sorunların hala geçerli olduğunu düşünenler de var bu da zaten kitabın hala popüler olmasının temel nedenlerinden birisi. Yani bugün yaşadığımız, belki de kendimize özel zannettiğimiz bir çok problem, 40yıl, belki 50-60yıl önce de, belki bizler henüz hayata bile gelmeden önce de yaşanıyordu ve insanlar bu problemleri çözmek için kafa yoruyordu, bugün hala kafa yoruyor. Neymiş bu değişmeyen sorunlar veya bunların kaynakları diye bakınca da ilk sırada insan'ı görüyorsunuz. 40yılda teknoloji çok değişti ama görünen o ki teknolojideki insan faktörü o kadar değişmemiş.

Kitap'ın yazılma amacı Brooks tarafından "Yazılım geliştirmeyi yönetmek neden bu kadar zor?" sorusuna cevap vermek olarak belirtiliyor.

Kitabın bölümlerini özet olarak anlatmaya çalışacağım.

"The Tar Pit" bölümünde yazılım projeleri bir bataklığa giren ve orada yavaş yavaş batan hayvanlara benzetiliyor. Yazılım projelerinin bu sorununu çözmek için öncelikle problemi anlamalıyız denip, sistem programlama'nın ne olduğu, yazılım geliştirmenin kefiyli ve kederli, zor yanları başlıkları altında üç ana konuya değiniliyor.

Brooks, "bu kadar süre ne yapıyorlar ki ben bu yazılımı çok daha kısa sürede yazarım" diyen kişilerin ürettiği yazılımlar ile kurumsal olarak üretilen yazılımlar ve sistem yazılım ürünlerinin arasındaki bazı farklara değiniyor. Bu farklar ciddi oranda maliyetleri değiştiren, üç katına, dokuz katına çıkaran farklar. Bir yazılımın ürün olabilmesi için yapılması gereken bazı şeyler; genel geçer olmasının sağlanması, testinin yapılmış olması, dökümantasyonunun yapılmış olması, güncellemelerinin yapılabilmesi, yapılması. Bu tarz gereksinimler, aynı fonksiyonlara sahip olsa bile bunların olmadığı bir yazılımdan üç kat daha fazla maliyet çıkmasına neden olabilecek gereksinimlerdir. Eğer bir sistemin bir bileşeni olacak şekilde yazılım üretmeniz gerekiyor ise burada da arayüzler, entegrasyonlar gibi konulara dikkat etmeniz gerekiyor, bunlar da kendi başına olan(stand-alone) bir yazılımda üç kat daha fazla maliyet çıkarabilecek gereksinimler. Birden fazla yazılım bileşeninden bir ürün ortaya çıkaracaksanız da maliyetiniz dokuz katına kadar çıkabilir.

Yazılım üretmenin kefiyli yanları:

1. Bir şeyler tasarlayıp, yapmanın, üretmenin verdiği keyif.
2. Diğer insanlara faydalı bir şeyler yapmanın verdiği keyif.
3. Karmaşık bir puzle'ın bir birine kenetlenmiş hareketli parçalarına benzeyen sanal nesnelere biçim vermenin ve onların beraber çalışmasını izlemenin, ürettikleri sonuçları değiştirebilmenin büyüsü.
4. Sürekli öğrenmenin verdiği keyif.

Yazılım üretmenin kederli, zor yanları:

1. Yaptığınız işi mükemmel yapmak ya da mükemmeleştirmek zorundasınız, hata yaptığınızda veya küçüçük bir şeyi eksik yaptığınızda her şey durabiliyor.
2. İnsanların bir birlerine bağımlılıkları. Bir insanın amacının, kaynaklarının, bilgisinin diğer insanlara sıkı sıkıya bağlı olması, sizin kendi işinizin şartlarını, amacınızı çoğu zaman kendi başınıza belirleyememeniz. Başkalarının yazdığı, kötü yazılmış, testleri olmayan, dökümantasyonu olmayan kodları kullanmak, o kodları düzeltmek zorunda olmak gibi.
3. Büyük şeyler tasarlamak eğlenceli ancak bazen gizlenmiş küçük bir hatayı bulmak için, zahmetli, sıkıcı, zorlayıcı şekilde saatlerce çalışmanız gerekebilir.
4. Projenin sonlarına doğru hataları bulmanın daha zor olması ve debugging ile daha çok zaman geçirilmesi.
5. Uzun zamandır üzerinde çalışılan ürün henüz tamamlanmadan demode olması, yeni fikirlerin yeni yaklaşımların ortaya çıkması.

Kitaba ismini de veren "The Mythical Man-Month" bölümü yazılım maliyetlendirmedeki sorunlardan bahsediyor. Burada eleştirilen temel konular süre ve insan'ın bir birinin eş değeriymiş gibi görülmesi, yani teoride; bir ay on adam eşittir on adam/ay, yarım ay yirmi adam eşittir on adam ay olması, ancak pratikte bu iki durumun bir birine eşit olmadığı. Bir diğer konu ise bu mantalite ile geç kalan yazılım projelerini yetiştirmek için projeye daha fazla insan konulması.

Projelerde neden bu kadar çok takvimsel problemler yaşanıyor?

1. Maliyetlendirme yaparken genellikle yanlış bir yaklaşım olarak herşeyin iyi gideceğini varsayıyoruz. Yazılımcıların çoğu maliyetlendirme konusunda fazla iyimser kalıyor.
2. Efor ve ilerlemeyi bir birine karıştırıyoruz, adam ve ay'ın bir birinin yerine geçebilir olduğu kabullenmesi ile maliyetlendirme yapıyoruz. Dokuz ayda doğacak bir çocuğu dokuz kadının bir ayda doğuramayacağı gerçeğini çoğu zaman kaçırıyoruz.
3. Verdiğimiz maliyetler çok fazla belirsizlik içeriyor ve yazılım yöneticileri bunu kabullenmede ve yönetmede çok başarılı değiller.
4. Takvimdeki ilerleme iyi bir şekilde gözlemlenemiyor. Diğer mühendislik dallarındaki bu konuda rutin şeyler yazılım mühendisliğinde radikal yenilikler olarak görülüyor.
5. Takvimde geri kalınmaya başlandığında bu soruna geleneksel ve doğal cevap daha fazla adam gücü eklemek oluyor. Bu yangına benzin dökmek gibi sorunları daha da büyütüyor. Daha fazla yangın daha fazla benzin gibi sonu yok olma ile biten bir süreç başlıyor.

"The Surgical Team" bölümünde özellikle genç yöneticilerden işitilen şöyle bir şikayet konu ediniliyor: Yüzlerce programcının olduğu bir projeden ise birinci sınıf, yetkin insanlardan oluşan küçük bir takımın tercih edilmesi. Ancak bu küçük takım çok büyük projelerin gerçekleştirilmesine yetmeyecektir veya böyle küçük bir takımın büyük bir projeyi gerçekleştirmesi yıllarca sürecektir.

Küçük takımlar olsun ancak büyük projeleri nasıl yapacağız problemine çözüm olarak Harlan Mills'in "surgical team" önerisi sunuluyor. Öneri şu şekilde: Büyük işlerin her bir parçası bir takım tarafından ele alınsın ancak bu takım her bir elemanının işin bir parçasını alıp yapması şeklinde değil, bir cerrahi ekip gibi, işin ana sorumlusu ve yapanı bir cerrah var ve ona yardımcı olan, onun işini daha iyi yapabilmesini, daha rahat olabilmesini dolayısı ile daha üretken olabilmesini sağlayan diğer insanlar var şeklinde organize olsun.

Peki bu cerrahi takımdaki anestezi uzmanı kim, hemşireler kim, iş bölümü nasıl yapılacak?

Cerrah: Mills bu kişiyi şef programcı olarak adlandırıyor. Sistemin gereksinimlerini tanımlayan/yöneten, tasarımı yapan, kodu yazan, testi yapan, dökümantasyon yapan bir kişi. Deneyimli, teknik yetenekleri üst seviyede.

Yardımcı Pilot: Cerrahın yaptığı tüm işleri yapabilen daha az deneyimli birisi. Cerrah'ın fikirlerini yorumlayabilecek, alternatif düşünceler ortaya koyabilecek, bazı durumlarda cerrah'ın hata yapmasını engelleyebilecek birisi.

Yönetici: Patron cerrah, kişiler, terfiler, para, lokasyon vs gibi konularda son söz onun ancak bunların hepsine yetişemeyeceği için bu işlerde yönetici takıma karşı bir ara yüz gibi davranır.

Editör: Dökümantasyondan cerrah sorumlu, editor cerrah tarafından üretilmiş draft dökümanları alır ve onları gözden geçirir gerekli düzenlemeleri yapar.

İki tane sekreter: Yönetici ve editor'un birer tane sekreteri vardır. Yönetici sekreteri proje yazışmalarını ve ürün ile ilişkili olmayan dökümanları yönetir.

Program Katibi: Takımın tüm teknik kayıtlarının bakımından sorumludur. Teknik kayıtlar makine kodu dosyaları ve insanların okuyabileceği dosyaları kapsar.

The Toolsmith(Tam bir türkçe karşılık bulamadım): Takım tarafından ihtiyaç duyulan utility servislerinin ve araçlarının yapılması, kurulması, bakımı gibi işlerden sorumludur.

Testçi: Test durumlarının hazırlanmasından ve koşulmasından sorumludur.

Programlama Dilinin Avukatı: Zor problemlerde kullanılan programlama dili ile nasıl çözümler üretilebileceğini bulan kimsedir.

Günümüzde tercih edilen self-organize, cross-functional takım gibi kavramlar ile bu önerinin ne kadar uyuştuğu tartışılır ancak o yıllarda büyük bir projeyi kontrollü şekilde götürebilmek ve takımın bir bütün gibi davranmasını sağlamak adına otoriteyi takım bazında bir kişide toplayan bu şekilde bir takım organizasyonu önerisi çıkmış.

"Aristocracy, Democracy, and System Design" bölümünün odak noktası "conceptual integrity", Türkçeye kavramsal bütünlük olarak çevrilebilir belki. Kavramsal bütünlük daha çok bir sistemin iç tasarımı ile ilgili. İç tasarımının aynı felsefe aynı mantık ile sanki tek bir elden çıkmış gibi uyumlu bir bütün olması.

Binaların kavramsal bütünlüğü ve bunu sağlayanın binanın tasarımının tek bir mimarın elinden çıkması örneği burada kullanılmış. Yazılımda aynı mantık ile ilerlemek ne kadar doğru sorusunun cevabı aranıyor. Yazılımda sistemi tasarlayan mimarlar ile sistemin gerçekleştirimini yapanları bir birinden ayırmamız bunu sağlar mı? Aristokrasi kısmı sistemi tasarlayan elit bir mimari grubunun bulunması için metafor olarak kullanılıyor. Demokraside ise sistemin tasarımı yatayda mimarlar, programcılar şeklinde dağılıyor. Yazar aristokrasinin, yani yatayda bir dağılma yerine dikey bir hiyerarşide tasarım ve gerçekleştirimi ayırmanın kavramsal bütünlüğü daha iyi sağlayacağını, uzun vadede projenin süresini kısaltacağını ve iletişimi daha kolay hale getireceğini savunuyor.

"The Second-System Effect" bölümünde bir mimarın ikinci sistemi genellikle en kötü tasarlanmış sistem olur tezi işleniyor. Birinci sistemin altından başarı ile kalkan mimar ikinci sistemde çok fazla açılabilir ve bu sistem çok karmaşık tasarlanmış(over design), çok fazla gereksiz fonksiyon içeren bir sistem olabilir.

"Passing the Word" bölümü daha önceki iki bölümde üzerinde durulan kavramsal bütünlük ile ilgili. Bir mimarın veya mimari grubun kararlarının bin kişilik bir ekipte herkes tarafından duyulduğundan, anlaşıldığından ve yapıldığından nasıl emin olunacak. Bunun ile ilgili kullanıcı bakış açısıyla sistemin özelliklerinin yazdığı bir dökümantasyon olması, ürünün formal ve formal olmayan tanımlarının standartlarının olması, düzenli olarak farklı gruplar ile toplantılar yapılması, mimari ekibe telefon ile gelen soru/cevapların kayıt altına tutulup yayınlanması, bağımsız bir ürün test ekibinin olması gibi öneriler sunulmuş.

"Why Did the Tower of Babel Fail?" bölümü babil kulesi projesinin başarısız olmasının nedenleri ile başlıyor. Hikayenin derinliğini tam olarak bilmemekle beraber tarihsel olarak babil kulesi inşa edilmişti diye biliyorum ancak yazar böyle bir metafor kullanıyor bu bölümde. Babil kulesi neden başarısız oldu; İletişim ve organizasyondaki sorunlar nedeniyle.

İletişim ve organizasyon büyük projelerinin başarısızlığındaki en büyük 2 etken. Bu iki konuda başarılı olabilmek için neler yapmak gerekiyor sorusuna cevap verilmeye çalışılıyor. Büyük bir proje içerisinde sağlıklı bir iletişim için önerilen çözümler; telefon görüşmeleri gibi informal yöntemler, düzenli toplantılar ve proje çalışma klavuzu(workbook). Proje çalışma klavuzuna özel bir önem verilerek bazı detaylar veriliyor. Bu klavuz proje ile ilgili tüm dökümantasyonların tutulduğu ortam ve burada üstesinden gelinmeye çalışılan iki sorun: Tüm proje ekibinin güncel klavuza ulaşmasının sağlanması ve klavuzun güncel tutulması.

Organizasyon için: yetki ve sorumlulukların dağılımı bakış açısıyla ağaç yapısı hiyerarşiler tercih ediliyor ancak bu yapı iletişim anlamında yeterli olmuyor. İletişim temelli düşünürsek hiyerarşinin network şeklinde olması gerekiyor. Bunun için bir çok teknoloji gurubunda organizasyon komite, grup gibi oluşumları içerecek şekilde matrix organizasyon yapısında oluyor. "The Surgical Team" bölümden olduğu gibi bazı rollerden bahsedilmiş ve bu rollerden "producer": Organizasyonel olarak yönetim işleri ile uğraşan rol, ve technical director: Teknik olarak yönetim işleri uğraşan rol, rollerinin nasıl konumlanabileceği ile ilgili alternatifler("producer", "technical director"'un yöneticisidir veya tersi gibi) üzerinde durulmuş.

"Calling the Shot" bölümü yazılım maliyetlendirmesi ile ilgili. Burada bir yazılımın ortalama ne kadar instruction, statement içereceği ve bir yazılımcının ayda, yılda ne kadar bunlardan yazabileceği gibi temeller üzerinde duran bir kaç yaklaşım örnek verilmiş.

Benim fikrim: Günümüzde maliyetlendirme anlamında çok kullanılan yöntemler değil benim gördüğüm kadarıyla. Mesela üst seviye bir dil kullanırsanız instruction sayısı azalacağı için maliyetleriniz de düşecektir gibi bir sonuç var. Elbette bu bir etkendir ancak tek başına bir etken değildir, üst seviye bir dil kullansanız bile maliyetiniz alt seviyede kullanılan bir dile göre yüksek olabilir, proje, insan, ortam, müşteri gibi farklı etkenlerin devreye girmesiyle.

"Ten Pounds in a Five-Pound Sack" bölümü programların kullandığı memory ve disk alanlarının büyüklüklerinin maliyete etkisiyle ilgili. Kitabın yazıldığı yıllar donanımdaki memory, disk gibi kaynaklar günümüze oranla oldukça az ve çok pahalı olduğu için bir programın etkin bir şekilde memory ve disk kullanması yazılım geliştirmede günümüze oranla önemli bir etkendi. Günümüzde de hala bazı alanlarda(özellikle gömülü sistemlerde) bu konu önemli. Burada temel olarak bahsedilen konu programın performansı ve kullandığı kaynaklar arasındaki dengeyi, yani performans/maliyet dengesini iyi tutturmak.

"The Documentary Hypothesis" bölümü yazılım projelerinin dökümantasyon ihtiyaçları ile ilgili. Yazılım ürünlerinin veya yazılım projelerinin genel olarak hangi tip dökümanlara sahip olması gerektiği anlatılıyor.

Bahsedilen döküman tipleri;

1. Hedefin, amacın anlatılması
2. Yazılımın özelliklerinin anlatılması
3. Takvim
4. Bütçe
5. Organizasyon
6. Yerleşim
7. Maliyetler, tahminler, fiyatlar

Neden formal dökümanlara ihtiyaç duyarız sorusuna cevap olarak;

1. Alınan kararların yazılması gerekir,
2. Alınan kararların diğer kişiler ile iletilmesini sağlamak için döküman gerekir,
3. Yönetimsel dökümanlar yöneticiye bir veritabanı ve kontrol listesi verir

"Plan toThrow One Away" bölümü yazılım projelerinin kaçınılmaz gerçeği değişim ile ilgili. Bir yazılımın ilk versiyonunun kullanıcının istediği şekilde olması çok düşük bir ihtimal dolayısı ile bu yazılım eninden sonunda değişecek. Öncelikle bu değişimi istisnai bir durum olarak beklemekten ziyade bu işin bir gerçeği olarak kabul etmek gerekiyor, sonra da bu değişime planlama, tasarım, organizasyon seviyelerinde hazır olmak gerekiyor.

Sistemin değişime hazır olarak planlanması için moduler tasarım, moduller arası ara yüzlerin detaylı tanımı, kapsamlı dökümantasyon gibi kavramlar ön plana çıkarılmış.

Organizasyonun değişime hazır olması için iki konudan bahsedilmiş, birincisi yöneticinin işler kötüye gittiğinde duruma müdahale edebilecek iki veya üç tane üst seviyede programcıya yani kahramana sahip olması. Bir diğeri de yöneticilerin ve teknik insanların bir birleri arasında değişilebilir olmaları. Bu yüzden ünvan'ların kaldırılması gibi önerilen çözümler var.

Öncelikle yazılım projelerinde değişim'in bir gerçek'den ziyade bir sorun olarak görülmesi hala yaşadığımız bir problem. Bu gerçeğin görmezden gelinmesi ve planların, süreçlerin buna göre yapılması da daha büyük bir problem. Bunların çözümünde iki üç tane kahraman yazılım mühendisi kullanılması da hala günümüzde pratikte kullanılan yöntemlerden. İşin teorisinde, özellikle çevik yaklaşımlarda değişim kabul edilmiş bir gerçek ve buna göre değerler, prensipler ve pratikler modellenmiş durumda.

"Sharp Tools" bölümü yazılım geliştirmede kullanılan araçlar üzerinde. Burada anlatılanlar yazarın OS/360 projesi üzerinden anlatıldığı için günümüze bir eşleştirme yapmakta zorlandım. Donanım olarak bahsedilen araçlar; bilgisayarlar, simülatorlar, dökümantasyon için bilgisayarlardan bahsedilmiş. Üst seviye programlama dillerinin kullanımı ve interaktif programlama araçlarına da kısaca değinilmiş.

"The Whole and the Parts" bölümünde istenildiği gibi çalışan bir programı nasıl inşa etmek gerekir, bu program nasıl test edilmeli ve bu programın parçaları nasıl entegre edilmeli gibi sorulara cevap verilmeye çalışılıyor. Üç alt bölüm oluşturulmuş; hataları engellemek için tasarım, bileşen hata ayıklama ve sistem hata ayıklama şeklinde. Tasarım kısmında daha önceki bölümlerde bahsedilen kavramsal bütünlüğün sağlanması, kodlar yazılmadan önce test spesifikasyonlarının yazılması, top-down design gibi yöntemlerden bahsedilmiş. Top-design yöntemi yazılım üst seviyeden alt seviyeye doğru adım adım tasarlama olarak anlatılıyor.

Bileşen hata ayıklama yazılım geliştirme sırasında yapılan hata ayıklama yöntemlerini içeriyor, makine üzerinde hata ayıklama, memory dump'ları, snapshot'ları alma gibi yöntemlerden bahsedilmiş.

Sistem hata ayıklama bölümünde bir sisteme gireçek olan bileşeni sistem içinde test etmenin maliyeti yüksek olduğu için bileşenlerin mümkün olduğunda hatalardan arındırılmış olarak sisteme eklenmeleri gerektiği, sisteme kontrollü bir şekilde(sıra ile) bileşenlerin eklenmesi gerektiği gibi yöntemlerden bahsedilmiş.

"Hatching a Catastrophe" bölümü geç kalan yazılım projeleri ile ilgili. Bir projenin bir yıl geç kalmış durumda kalmaması için neler yapılabilir sorusu üzerinde duruyor. "Milestone" kavramı üzerinde duruluyor, milestone'ların proje planında somut olmasını tavsiye ediyor. Yani bir milestone ya bitmiştir ya bitmemiştir şeklinde bir yaklaşımı var. PERT(Program evaluation and review technique), critical path gibi proje yönetiminde günümüzde de kullanılan yöntemlerden bahsedilmiş. Organizasyonel anlamda da projenin geç kalmasını engellemek için rol karmaşalarından kurtulunması, halı'nın altına süpürülen bazı gerçeklerin olmaması öneriler arasında. Son olarak proje izleme grubu gibi ayrı bir grubun projenin ilerleyişini kontrol edip raporlamasının daha sağlıklı bir yöntem olduğundan bahsedilmiş.

"The Other Face" bölümü yazılım projelerindeki dökümantasyon ile ilgili. Yazılımın makineye değil kullanıcıya bakan yüzü olarak değerlendirildiği için bölümün başlığı diğer yüz şeklinde. Yazılımın bu diğer yüzünün de makineye bakan yüzü kadar önemli olduğuna vurgu yapılmış. Hangi dökümanlara ihtiyacımız var sorusunun cevabı olarak; Amaç, ortam, geçerli girdiler, beklenen çıktılar, fonksiyonlar, kullanılan algoritmalar, kullanım klavuzu, çalışma zamanları gibi alanlardan bahsedilmiş.

Nasıl dökümante etmeliyiz sorusuna flow-chart'lar kullanılması ve kendi içinde dökümantasyon barındıran programlar başlıkları altında cevap verilmeye çalışılmış. Kendi içinde dökümantasyon barındıran programdan kasıt düzgün isimlendirmeler ve kod içindeki yorumlar. Bu yöntemin avantajı olarak güncel ve kolay ulaşılabilir olması, dezavantajı olarak da kod büyüklüğünün artması gösterilmiş.

Günümüzde kod içinde "deodorant" olarak kullanılmayan, nasılı değil nedeni açıklayan yorumlar yazılması tavsiye ediliyor. Yaşayan dökümantasyondan, yaşayan ve çalıştırılabilen dökümantasyon(specifications, bdd, cucumber vs.) gibi kavramlara geçiş var.

"No Silver Bullet- Essence and Accident in Software Engineering" bölümü kitabın yazılım dünyasında en çok referans gösterilen bölümlerinden birisi muhtemelen. Burada anlatılan konu; Verimli, güvenli, basit yazılımları üretebilmek için diğer tüm yöntemlerin üzerine çıkan tek bir geliştirme, yönetim tekniğinin veya teknolojinin olmadığı. Yani tüm sorunlarınızı bir anda çözebilecek bir sihirli değnek yok yazılım dünyasında.

Peki neden böyle sorusuna cevap olarak yazılım projelerinin zorlayıcı ve kalıcı olduğu düşünülen zorluklarına değinilmiş. Bu zorluklardan bazıları; Neyin inşa edileceğine karar vermenin veya tamamıyla karar verebilmenin imkansız oluşu, karmaşıklık, yazılım projeleri geliştirilirken ve geliştirildikten sonra gelebilen sürekli değişiklik istekleri ve yazılım projelerini alt seviyede görsel olarak ifade edebilmenin imkansız oluşu.

Zaman içinde kurtarıcı olarak görülen bazı yazılım geliştirme yöntemlerinden, dillerinden ve bunlar ile ilgili bazı sorunlardan bahsedilmiş, bazıları; Nesneye dayalı programlama, Yapay zeka, Uzman sistemler, Otomatik programlama, Grafiksel programlama, kullanılan bilgisayarlar vs.

Genel geçer tüm problemleri çözen değil ama yazılım projelerindeki bazı zorlukların üzerinden gelmenizi sağlayacak bir kaç yönteme de değinilmiş; Gereksinimlerin sürekli iyileştirilmesi ve protype yöntemi, Incremental geliştirme(yazma ve inşa etme arasındaki fark) ve yetkin/güçlü tasarımcılara sahip olma.

Kitaptaki No Silver Bullet bölümü orjinal olarak 1986'da bir sempozyuma makale olarak gönderilmiş. Kitabın bu bölümünden sonraki bölümleri 1995 yılında kitabın 20.yılı anısına tekrar basıldığı zaman ekleniyor. No Silver Bullet "Refired" bölümü aradan geçen dokuz yılda No Silver Bullet(NSB olarak kısaltılmış) kavramının hangi noktada olduğunu yorumluyor. NSB'nin orjinal iddiasında on yıl diye bir kavram da geçiyor. Yani herhangi bir methodoloji on yıl boyunca kurtarıcı olamaz diye de düşünebiliriz. Bu bölümde aradan dokuz yıl geçti ne oldu ne bitti şeklinde ilerliyor. NSB kavramına gelen farklı kişilerden yorumlar'ın üzerinde duruluyor. Karmaşıklık, verimlilik, object oriented tasarım, yeniden kullanılabilirlik gibi kavramların geldiği noktalar hakkında yorumlar var.

Nihai olarak bu bölümde gelinen nokta, yazılım teknolojilerinde bu sihirli yöntemin gelmesini beklemeyin, gelmeyecek, dolayısı ile adım adım süreçlerinizi, projelerinizi iyileştirmeye bakın.

"Propositions of The Mythical Man-Month True or False?" bölümü kitabın 1975 yılında yazılmış 15 bölümünde, aradan geçen yirmi yılda(1995'de yazılıyor bu bölüm) kitabın değindiği konuların hangilerinin geçerliliğini koruduğu çıkarsamasını yapabilmek için özet bilgi veriyor. Bazı güncel yorumlar da dahil edilmiş. Aslında benim yukarıda yapmaya çalıştığımın biraz daha geniş kapsamlısı olarak düşünülebilir ancak maddeler olarak verilen cümleler arasındaki ilişkiyi kurmak çok kolay olmuyor.

"The Mythical Man-Month after 20 Years" bölümü 1995 yılı itibariyle yazılım dünyasında gelinen noktayı ve kitabdaki bazı bölümlerin neden hala geçerliliğini koruduğunu anlatıyor. Kitabın geçerliliğini koruması ile ilgili iki ana neden öne sürülmüş, birincisi yazılım geliştirme disiplilerinin yeterince hızlı gelişmediği, donanım teknolojilerinin daha önce hiç bir alanda görülmemiş kadar hızlı geliştiği ancak yazılım geliştirme disiplinlerinin bunun gerisinde kaldığı dolayısı ile yirmi yıl önce yaşanılan bazı sorunların hala geçerliliğini koruduğu söylenmiş. Bir diğer neden kitapda bahsedilen konuların bazıların doğrudan insanlar ile ilgili olması ve insan psikolojisinin ve davranışlarının da değişiklik göstermediği.

Bu bölümde, kavramsal bütünlük, mimarın rolü, waterfall modeli, iterative modeller, yazılımda insan faktörü gibi konulara güncel, yani 1995 yılı itibariyle, tekrar bakılmaya çalışılmış.

Bence kitapda gerçekten güncel anlamda, okurken bir şeyler hissedebileceğiniz bölümler; The Mythical Man-Month, The Second-System Effect, Plan to Throw One Away, No Silver Bullet- Essence and Accident in Software Engineering, "No Silver Bullet" Refired, Propositions of The Mythical Man-Month True or False?, The Mythical Man-Month after 20 Years.

Teknik Liderlik

Nedir teknik liderlik, neler yapar, nelerden sorumludur, nelere dikkat etmesi gerekir, zorlukları nelerdir, kişiye ve takıma avantajları dezavantajları nelerdir gibi konulardan bahsetmek istiyorum.

Öncelikle kabaca nasıl bir teknik liderden bahsedeceğimizi tanımlamak faydalı olacaktır çünkü benzer rolde ancak çok farklı pratiklerle/sorumluluklarla çalışanlar mevcut. Benim bahsedeceğim daha doğrusu olmasını istediğim teknik lider: Bir geliştirme takımından sorumlu lider ve zamanının en az üçte birini takım ile beraber kod yazarak geçiren kişidir.

Teknik liderliğe geçiş geliştirme takımının içindeki birisinin bu pozisyona geçmesine duyulan ihtiyaç ile olur. Bu geçişi tetikleyen ihtiyaç; takımın büyümesi(onshore veya Türkiye'de çok yaygın olmasa da offshore) ve kendi içinde teknik anlamda seknronizasyonu sağlayacak birisine ihtiyaç duyması, büyüyen takımın dış dünyaya karşı bir temsilciye ihtiyaç duyması, takımın sosyal/bireysel anlamda kendileri ile ilgilenecek birisine ihtiyaç duyması şeklinde sıralanabilir. Bu kapsamda teknik lider'in sorumluluklarını üç farklı kategoride değerlendirebiliriz: Teknoloji, insan ve paydaşlar.

Teknoloji anlamında teknik lider projenin ve takımın teknik/mimari vizyonundan sorumludur. Dolayısı ile ortada teknik bir vizyon olması gerekir. Bu sorumluluk teknik liderin takımdaki teknik olarak en yetkin, en derin bilgi sahibi kişi olduğu veya olması gerektiği anlamına gelmemeli, diğer sorumluluklara da değinince zaten bunun çok mümkün bir şey olmadığı anlaşılacak. En azından kişinin teknik liderlik sürecinin başında öyle ise bile sürecin devamında veya devam edebilmesi için öyle olmaması gerekir. Teknik lider projenin büyük resmine ve somut amaçlarına(müşteri beklentileri) hakim olmalı, projenin sınırlarını bilmeli, takımın teknik olarak yaptığı işleri, aldığı kararları da bu anlamda değerlendirmeli, takımı yönlendirmeli ve takımı projenin sınırlarının içinde tutmalıdır. Takımda ortak bir bakış açısı ve amacın oluşmasını ve bunun korunmasını sağlamalıdır.

Olumsuz bir teknik lider tanımını şöyle yapabiliriz: Projedeki önemli teknik kararları alır, onun onayı olmadan takım teknik olarak bir şeye karar veremez, yapamaz, takım ile beraber kod yazmaz, hatta hiç kod yazmaz, en son on yıl önce yazmıştır. Böyle bir teknik lider bariz bir şekilde yetkili ama sorumlu değildir, onun aldığı kararların olumsuz etkileri hep takıma yansır. Kendi yapamadığın bir şey hakkında sürekli karar veriyor olmak...Söylediğimi yap, yaptığımı değil...Bir takımın, fildişi kulede oturan bu mimara veya teknik lidere ihtiyacı yok(The Ivory Tower Architect, Architecture Astronaut)!

Teknik lider kod yazmadığı zaman hem takımın saygısını kaybeder hem de realiteden uzaklaşır, verdiği kararlar anlamsızlaşır. Dolayısı ile teknik lider her zaman işin içinde olmalı, ellerini kirletebilmeli yani kod yazabilmelidir ve sürekli olarak, kısa süreli de olsa kod yazmalıdır. Burada diğer işlerinden dolayı kendine bağımlılık oluşturmamak için teknik lider daha önemsiz tasklar üzerinde çalışabilir veya daha iyisi pair olarak kod yazabilir, böylece o olmadığında diğer pair kodu devam ettirebilir. Burada olumsuz bir örnek, tam zamanlı kod yazan teknik liderlerdir. Teknik liderin tek sorumluluğu teknik olmadığı için bu tarz çalışma şekli yönetilebilir değildir, işin insan ve paydaş ilişkileri boyutunu ıskalarsınız ve bir darboğaz olmaktan öteye gidemezsiniz.

Teknik lider proje planlanması ve takip edilmesi konusunda da rol alabilir. Burada user story'lerin çıkarılması/yönetilmesi, release planları, sprint planları, izleme/raporlama gibi konularda bilgi sahibi olmalıdır. Proje planlama/takip/yönetim kapsamındaki bazı işlerden teknik lider doğrudan sorumlu olabileceği gibi bazılarında da proje yöneticisi, analist gibi rollere destek olur.

Bir takımda developer iken teknik lider olmanın size getireceği temel avantajlardan birisi problemlerin çözümünde yeni şeyler deneme imkanını size bir miktar veriyor olmasıdır. Kafanızdaki çözümleri, teknik olarak yapmak istediğiniz şeyleri hayata geçirmek için artık biraz daha özgürsünüzdür. Tabii burada çok farklı parametreler olabilir, teknik lider'in fil dişi kule'de yaşayan mimar tarzında bir yöneticisi var ise işi biraz daha zor olabilir.

Teknoloji kısmını, büyük resim, teknik vizyon, kod yazmak şeklinde özetleyebilirim.

İşin insan boyutu belki de en zor olanı. Bir developer iken daha çok bilgisayar ile muhattapsınız, çalışırken karşılaştığınız problemlerin çoğunu bilgisayar üzerinden çözüyorsunuz, daha çok sadece kendi yaptığınız işe odaklısınız, dışarıya çok açık değilsiniz olmanız da gerekmiyor. Teknik liderliğe ilk geçişte, insan ilişkileri konusunda extreme yetenekleriniz yok ise, bu bilgisayar ile sorunları çözme konusunun gerçekten büyük bir mutluluk olduğunu anlayabilirsiniz. Çünkü artık siz takımdaki insanlardan da sorumlusunuz, onların her türlü sorunu, iş ile ilgili olsun veya olmasın, artık sizin de sorununuzdur. Ve insanların sorunları bilgisayarlar gibi ikili bir sistemde çözülmüyor, siyah/beyaz değil gri alanlar var, deterministik değil ve çok daha karmaşık. Teknik liderlik rolü muhtemelen beklediğinizden daha çok insan'a dönük bir rol olacaktır. İnsanlar ile yakından ilgilenmeyi istemiyorsanız veya bunu önemli görmüyorsanız muhtemelen teknik liderlik rolü size göre değil. Takım arkadaşlarınızla çalışırken onları öncelikle insan olarak görmüyorsanız zaten kaybetmişsiniz demektir.

Bir kaç tane insanın bir araya gelmesi bir takımı oluşturmaz, bu sadece bir grubu oluşturur, takım ortak bir amaç için çalışan insanlardan oluşur, etkili bir lider de bu ortak amaca doğru gitmek için takımdaki insanları senkronize/orkestre(align) eden kişidir.

Teknik liderin takımdaki insanların özelliklerinin farkında olması çok önemli. Söylediğiniz bir şeyi herkes farklı anlayabilir, herkesin daha iyi anladığı bir yöntem olabilir, kimisi sözlü, kimisi yazılı, kimisi görsel. Sizin de buna paralel olarak takımdaki insanların bu farklılıklarının farkında olup yanlış anlaşılmaların önüne geçmek için doğru iletişim yöntemlerini kullanmanız gerekir. Takımdaki herkes farklı bir konuda güçlü olabilir teknik liderin bu güçleri doğru şekilde yönlendirebilmesi gerekir.

Teknik lider olarak sizin takımdaki insanlara ilişkin temel sorumluluğuz aslında onların hem teknik hem de teknik olmayan konulardaki yetkinliklerinin seviyesini yukarıya çekmek. Bunun için de işbirliği, kolaylaştırıcılık, liderlik, yol göstericilik, mentorluk/danışmanlık/koçluk gibi kavramlar ön plana çıkıyor. Bir nevi onları yetiştirmelisiniz, kabuklarını kırmaları için desteklemelisiniz, cesaretlendirmelisiniz. Takımınızda en iyilerin olması için işe alım süreçlerinden başlamak üzere her seviyede takım ile bire bir ilgilenmeniz gerekiyor. Her zaman bir kulağınız takımda olmalı, olan bitenleri, insanların davranışlarını, konuşmalarını gözlemlemelisiniz. Geri bildirim konusuna önem vermelisiniz, insanları sık sık fikirleriniz ile beslemelisiniz, övgülerinizi esirgemeden herkesin içinde yapmalısınız. Ne kadar yetkin bir takımınız var ise karmaşık problemlerin üstesinden gelmek de o kadar kolay olacaktır, sizin eliniz o kadar rahatlayacaktır. Kararlarınızı ne kadar ortak verebiliyorsanız o kadar işi sahiplenen takımınız olur, sizi takımda bir darboğaz olmaktan kurtarır(siz yoksunuz takımda karar verilemiyor durumu). Sizi teknik lider yapan faktörlerden birisi zeki olmanız olabilir ancak bu her zaman sizin fikirlerinizin doğru olduğu anlamına gelmez. Dolayısı ile takım ile bir çözüm üzerinde tartışırken herkesin bir birini nazik bir şekilde dinlediğinden ve tüm alternatiflerin değerlendirildiğinden emin olunmalı. Burada delegasyon kavramı da ön plana çıkan diğer bir faktör, tek temas noktası olmaktan ne kadar kaçınırsanız, işlerin farklı kişilere delegasyonunu ne kadar başarılı yaparsanız ortak karar alma süreciniz de o kadar sağlıklı olacaktır ve bu sizin çok daha doğru konulara odaklanmanıza olanak sağlayacaktır. Her şeye yetemezsiniz, her şeyi kontrolünüz altında tutma takıntınız var ise bundan kurtulmalısınız. Bir teknik liderin veya mimarın değeri verdiği kararların sayısı ile ters orantılıdır diye düşünebiliriz.

Takımın gelişebilmesi için öğrenmenin çok aktif bir şekilde takım içinde benimsenmesi gerekir. Başarısızlıklar da öğrenme sürecinin doğal bir parçasıdır, dolayısı ile teknik lider takımda başarısızlıkların oluşmasına da izin vermelidir, insanlar hata yapmaktan korkmamalıdır, çünkü doğruya giden yol çoğu zaman ilk deneme; başarı, değildir, birinci deneme; başarısız, ikinci deneme; başarısız, üçüncü deneme; başarılı, şeklindedir. Ama siz başarısızlıklara izin vermezseniz o üçüncü denemeye hiçbir zaman ulaşamazsınız. Başarısızlıklar için emniyetli bir ortamın da olması gerekir ki insanlar korkmadan bir şeyler yapabilsin, deneyebilsin. Bunun için belki çalışırken eğlenebilmek, yaptığı işten zevk alabilmek gibi konular üzerinde kafa yormak gerekiyor. İletişim tarzını şiddet içermeyen, aşırı ciddiyet içermeyen bir seviyede korumak önemli. İnsanlar çekinmemeli, sizden de, bir fikrini beyan etmekten de. Takım arkadaşlarınız acaba söyleceğim şey çok mu saçma olur en iyisi söylemeyeyim gibi düşüncelere sahip olmamalı.

Bu kısmı insan odaklı olmak(insanlar önce, müşteri sonra), liderlik, kolaylaştırıcılık, delegasyon, iş birliği, saygı, tek takım ortak amaç şeklinde özetleyebilirim.

Paydaş ilişkilerindeki paydaşlardan kastım teknik olmayan paydaşlar, bunlar kendi firmanızdaki yöneticiler olabilir, müşteri olabilir. Teknik olmayan paydaş ilişkilerinde en temel nokta güven.

Yazılımın kalitesine çok fazla odaklanıp müşteri için değer teslim etmeyi çok umursamazsanız bu güven sarsılır. Biran önce değer teslim edeceğiz diye yazılımın kalitesini(yazılımda kalite nedir sorusuna da başka bir yazıda cevap aramaya çalışacağım) umursamaz iseniz de yaşanacak olan iç kalite sorunları hızlıca müşteriye dokunan dış kalite sorunlarına dönüşecektir ve güven yine sarsılacaktır. O yüzden teknik liderin bu dengeyi sağlaması, teknik borçları iyi takip edip iyi yönetebilmesi çok önemli. Teknik olmayan paydaşlar ile bu güven ilişkisinin tesis edilmesi zaman alacaktır, teknik liderin takıma ve teknik olmayan bu paydaşlara ayıracağı zamanı iyi ayarlaması gerekir. Teknik olmayan paydaşlar ile geçirilecek zaman, teknik liderin onlar için gerçekten önemli olan konuları daha iyi anlamasına olanak sağlayacaktır. Bu bilgiyle takımın kendisine dönük; istediği teknoloji kullanabilme, üst seviyelerde birim test kapsamı gibi konular ile son kullanıcıların sistemden beklentileri dengelenebilecektir.

Teknik lider zorlayıcı paydaşlar ile de uğraşmak durumunda kalabilir. Mesela bir kurumdaki transformasyon projesinde eski sistemde calışan bir paydaş bu sistemin değişmemesini, kendi işine bir tehdit olarak gördüğü için, isteyebilir. Ve yeni proje için zorluklar çıkarabilir. Bu tip durumlarda teknik liderin tek başına çözemeyeği daha üst seviyelerde çözülmesi gereken durumlar olabilir, önemli olan duygulara hakim olarak profesyonel davranabilmektir.

Teknik olmayan paydaşlar ile ilişkilerde anahtar kavramları güven ve denge olarak söyleyebiliriz.

Yazılım zanaatkarlığı(Software Craftsmanship) hareketinin arkasındaki temel fikirlerden birisi de, her bir bireyin kendi kariyerinden, yetişmesinden sorumlu olmasıdır, işvereniniz, lideriniz, yöneticiniz değil, kariyerinizden siz sorumlusunuz. Dolayısı ile bir teknik liderin sorumluluklarını sağlıklı bir şekilde yerine getirebilmesi için kendisine yatırım yapacak zaman ayırması çok önemli. Her türlü okuma, konferanslara/seminerlere konuşmacı/dinleyici olarak katılma, kullanıcı gruplarına dahil olma, bu kapsamda faaliyetler olarak düşünülebilir. Teknik liderin sadece kendisini değil etrafındaki insanları da geliştirmek gibi bir sorumluluğu olduğu için kendini geliştirme faaliyetlerine de bu gözle bakması gerekir. Mesela sadece kendisi için okumak ile anlatmak, paylaşmak için okumak arasında fark var.

İş yerindeki zamanın dışında da sağlıklı bir iş/hayat dengesine sahip olmanız önemlidir. Boş zamanlarınızda iş ile ilgili konulardan psikolojik olarak kopabilmeniz gerekir. İş, duygusal olarak sizi etkileyen temel faktör olursa, hayatınızdaki genel başarıyı duygusal olarak iş yerindeki bir projenin teslimatına bağlamak gibi saçma bir duruma düşebilirsiniz. Stres, uzun saatler çalışmak sizi işinizde daha etkisiz yapacaktır, ve bu takımınız için de kötü bir örnek olacaktır. Kendi güçlü ve zayıf yönlerinizin farkında olmanız ve davranışlarınızda, kendinize yapacağınız yatırımlarda bunu gözetmeniz gerekir.

Teknik liderlik rolüyle sizi zorlayacak bir diğer faktör de sık sık konudan konuya(context switching) geçiş yapmanız gerekeceğidir. Sık sık bölüneceksiniz, gün içinde çok farklı konular ile uğraşmak durumunda kalacaksınız. Bunlar için de kendinize iyi bir zaman yönetimi stratejisi geliştirmeniz gerekecektir. Zamanınızı nasıl yöneteceğinizi belirlemelisiniz. Task listeleri, kod yazma zamanları, mailleri okuma zamanları, toplantı katılımları vs. gibi konulara gününüzü nasıl böleceğinizi bilmelisiniz.

Takımınızın ve kendinizin neler yaptığını da mümkün olduğunca dışarıya(yöneticiniz,üst yönetim, paydaşlar) görünür kılmak size farklı seviyelerde fayda sağlayacaktır. Bazen gerçekten çok güzel şeyler başarsanız dahi bunlar görünür olmadığında size farklı yansımalar olabiliyor ve bunlar sizin ve takımınızın moral ve motivasyonunu etkileyebiliyor. Burada teknik liderin politik, pazarlamacı vs. gibi biraz daha farklı bir bakış açısına da sahip olması gerekiyor, yaptığı işleri küçümsememesi gerekiyor. Tabii bir yapıp beş yapmış gibi anlatan insanlar ile de karşılaşacaksınız. Bu tip insanlara karşı da teknik liderin biraz profesyonel sinirlere sahip olması gerekir.

Referans
[1] Patrick Kua, Talking with Tech Leads

Bakarsan Bağ Bakmazsan Dağ Olur

Kendi halinde, daha çok bilgisayar ile konuşan ve genellikle bilgisayar üzerinden çözülebilecek sorunları olan bir developer iken bir gün gelir şirket büyür, ekip büyür ve sana sen artık bu ekibin takım liderisin veya teknik liderisin derler. Geçiş genelde hızlı olur, ne bir eğitim ne bir hazırlık, kendi yolunu kendin bulacaksındır. Yöneticinin, ekip arkadaşlarının ve zamanla muhattap olmaya başladığın müşteri, iş birimi gibi diğer paydaşların senden beklentileri hakkında da kafanda bir şeyler yok ise işin daha da zordur. Bu işin giderek artan zorluğu sana sürekli bir yerlerde yanlış olduğunu düşündürür ama bir türlü bulamazsın, sürekli şikayet edersin dış etkenlerden ama çözüm yok. Kod yazmak istersin, sürekli birileri gelir bir şeyler sorar, kod yazmazsın takımın ne yapıp ettiği hakkında hiç bir fikrin olmaz, ekip arkadaşlarında işe karşı sendeki motivasyon yoktur, ne yapıyorum ben burada diye sorgulamaya başlarsın.

Kendi kendine doğru yolu bulmak gerçekten kolay değil. Bilgiye ulaşmak artık çok kolay evet ama neyi aradığını tam olarak bilmiyorsan bunun da sana bir faydası olmayacaktır. Ciddi anlamda sistematik bir sorgulama mantığına belki doğuştan sahip olman gerekir. Yanlış yapa yapa doğruları bulabilirsin, ama belki, ya bulamazsan, ya yıllarca saçma bir pozisyonda, ne yaptığını, ne yapacağını bilmeden, yaptığın şeyden bir haz almadan, bir şey anlamadan yaşarsan. Günün sonuna geldiğinde elinde hiç bir şey olmadığını hissedersin, maddi, manevi. Ne teknik bir birikimin vardır, artık cok eskilerde kalmışsındır, ne de tam anlamıyla bir yöneticisindir, ne de bugüne kadar anlamlı bir şeyler yaptığını, bir şeyler başardığını hissedersin. Kendi kendini kandırmaya çalışırsın ama nafile. Her işe koşturan, hepsini de yarım yamalak yapmaya çalışan birisinden öte bir şey değilsindir. Tamamen çalıştığın şirkete, projeye, müşteriyi özel bir insan olmuşsundur. Bu bağlamın dışına çıkmak korkutur seni.

Eğer henüz yolun başında olan ekip arkadaşların varsa, sadece kendine yazık etmekle kalmaz, liderlik ettiğin veya öyle sandığın o insanlara da yazık edersin. Büyümez onlar bir türlü istediğin gibi, dışı heybetli ama içi boş ağaçlar olurlar. Senin teknik anlamdaki yetkinliklerinin, bakış açının iyi olması yetmez onların büyümesi için. Çiçekler hakkında her türlü teorik bilgiyi bilen ama çiçekleri ile ilgilenmeyen bir bahçevan'ın çiçeklerinin büyümeyeceği gibi. Emek yok ise veya doğru yöne kanalize edilmiş emek yok ise sonuç da yoktur. Neden böyleler, niçin şunu yapmıyorlar, niçin bunu yapmıyorlar diye diye geçirirsin yılları. Özünde senin durumun ile onların durumu hakkında bir fark yoktur. Onlar da kendi kendilerine büyüyememişlerdir, kendi yollarını bulamamışlardır, tıpkı senin gibi. Ve senin için daha kötüsü; büyük olasılıkla, sen doğru yolu bulamadığın için onlar da bulamamıştır.

Fazla acımasız gelebilir bu bakış açısı, "onların da içinde yokmuş, onlar kendini düşünmüyorsa ben mi düşüneceğim" vs. diyebilirsin. Herkes kendi kariyerinden sorumlu evet ama sen ne yaptın, ne kadar çaba sarfettin, üç beş kelam edip, sürekli şikayet etmekten başka? "Tamam ben onlara gerektiği gibi davranamamış olabilirim, ama bana benim yöneticim gerektiği gibi davrandı, ben doğru yolu biliyordum da ona rağmen mi davranmadım, o zaman benim durumumdan da benim yöneticim sorumlu" diyebilirsin. Haklısın, bir çok parametre var burada ama ekibin başına konulan deneyimli birisi olarak senin doğru yolu bulma olasılığın ile onların bulma olasılığı arasında ciddi bir fark var.

Aradan yıllar geçti ve hala doğru yolu bulamamışsan, artık bu sektörden kopmak istiyorsun, ya başka bir iş yapayım ya da biran önce emekli olup evde oturayım şeklinde bir düşünce oluşuyor. Her gün ayağını süreyerek işe geliyorsun, sıkıntıdan patlıyorsun, iş yerindeki bazı insanlara katlanamıyorsun artık, yaptığın işin anlamsızlığı seni yiyip bitiriyor ama geçinmek için yapmak zorundasın katlanıyorsun gibi bir duruma giriyorsun.

Bir yandan da öyle saçma insanlar görüyorsun ki, bakış açıları, kaygıları senden çok farklı, senden çok daha umursamaz, senin yanlış yoldayım dediğin yolun on katı daha yanlış yoldalar ama onlar hallerinden gayet mutlu görünüyorlar, yöneticileri de mutlu, herkes mutlu yani. Senin bir şeyler yapayım, yapalım diye gösterdiğin çabanın onda birini bile göstermiyorlar, cahillik mutluluktur gibi bir şey...Bazen de bunlar tetikliyorlar seni, ben bu saçmalığın içinde kaybolmayacağım veya meydanı bu saçma insanlara bırakmayacağım diyorsun.

Ve bir gün geliyor bazı şeyleri daha iyi anlıyorsun, geçmişte nasıl yanlış yaptığını görüyorsun ve şimdi ne yapman gerektiği kafanda şekilleniyor. Ne kendin için ne de çalıştığın insanlar için artık çok geç denilemez hiç bir zaman, evet fark çok açılmış oluyor şüphesiz. Neredeyse her gün, her hafta farklı bir şeyler duyduğumuz sektörde, takibi bıraktığın anda gerilerde kalmaya başlıyorsun. Ve bir gün öyle bir noktaya geliyorsun ki, artık konuşulanları anlamıyorsun, kavramlardan, yöntemlerden, tekniklerden, dillerden, disiplinlerden, felsefelerden ve daha bir çok şeyden kopmuşsun. Ve hem senin hem de ekip arkadaşların için yapacak tek bir şey kalıyor, konfor bölgesinden uzaklaşmak ve daha çok çalışmak, okumak, öğrenmek, uygulamak. Aradaki farkı kapatmak için normal bir insandan daha çok çalışmak. Bu da bir çok şeyden feragat etmeyi gerektiriyor. Daha önce ne ile harcıyorsan o zamanları, onlardan. Uykuda, Internette, TV karşısında geçirilen, aslında heba edilen zamanlardan başlamak en mantıklısı belki. Başlamak, ciddi bir eşik enerjisi ve devam etmek, ciddi bir kararlılık gerektiriyor. Bunun için de nereye ulaşmak istediğin kafanda net olmalı. Beraber çalıştığın insanlara da artık başka davranman gerekiyor, onlar ile daha çok ilgilenmem, onlar için daha çok yönlendirici olman, onlar ile daha çok beraber çalışman gerekiyor. Çiçeklerle ilgilenmen gerekiyor yani, su, gübre, güneş, budama, zararlılar vs.

Bir Yazılımcının Kariyerinden Kim Sorumlu

Yazılım geliştiren insanlar özelinde sektörde geleceğe yönelik net bir planı olmayan çok fazla insan var, bu kategoriden kendimi de çok dışlamıyorum. İşi sadece yaşamını belirli seviyede devam ettirebilmek için belirli seviyede yapan insanlar, sadece iş. Her gün ayağını sürüye sürüye işe gitmek. Her sabah ofise girdiğinde biran önce akşam olsada eve gitsem düşüncesi. Her gün niye bu saçmalıklarla uğraşıyorum düşüncesi.

Normal mi, değil, özellikle doğrudan insana, insanın psikolojisine, yeteneklerine, işini sevmesine bağımlı olan yazılım geliştirme gibi bir sektörde. Sorumlu kim; yazılım mühendisi arkadaşlarla konuşursan çoğu zaman(insaflı bazıları dışında) kurum, yönetici, proje, müşteri vs. "İnsan odaklı değiller, bize yatırım yapmıyorlar, kendimizi geliştirmemize imkan tanımıyorlar, eğitime göndermiyorlar, güncel teknolojileri kullandırtmıyorlar...". Yöneticilerle konuşursan çoğu zaman(insaflı bazıları dışında) çalışanlar. "İşlerine önem vermiyorlar, disiplinli çalışmıyorlar, boşa çok vakit geçiriyorlar(İnternet, çay/kahve, telefon), verimli çalışmıyorlar". Dolayısı ile bu döngü kırılmıyor; mutsuz insanlar, başarısız projeler.

Bence herkes kendi kariyerinden sorumlu, bir yazılım geliştirici "4yıldır bu şirkette çalışıyorum ama bana çok fazla bir şey kattığını düşünmüyorum" diyorsa bunun tek sorumlusu kendisidir. İlk önce sen kendini düşünmüyorsan, kendi yapmak istediklerini, seni mutlu edecek, sana bir şey katacak şeyleri düşünmüyorsan bunu öncelikle çalıştığın şirketten beklemek büyük hata.

Çözüm; öncelikle insanın bazı değerleri, prensipleri olmalı ve bunlar ışığında gitmek istediği bir yol haritası kafasında her zaman olmalı, bu değerler, prensipler ve yol haritası elbette zaman içinde değişebilir ancak olmalı, diğer türlü kaybolursun. Çalıştığın şirket, yaptığın iş bunlarla uyumlu mu, değil ise uydurmak için bir şeyler yapabilir misin? Evet ise bunları yap. Yok denedin olmadıysa o zaman uyumlu bir işe bak. Kolay iş değiştirilebilen bir sektörde çalışıyoruz ancak sorun ülkemizdeki yazılım şirketlerinin kültürlerinin bir birlerine çok benzemesi ve sizin değer ve prensiplerinizde para ilk başta değilse sorun daha da büyüyor. O zaman yurt dışı alternatifleri akla gelmeye başlıyor.

Aradığınızı bulamayabilirsiniz ama çoğu zaman bulanlar arayanlar olduğu için aramak lazım. Bu tarz bir arayışın önündeki en büyük engellerden birisi de "comfort zone" denen şeyin kırılamaması. Bir kaç yıldır bir şirkette çalışıyorsunuz, yaptığınız işi sevmiyorsunuz, ama kurumsal bir şirket, çalışma ortamı nispeten rahat, çalışanlarla ilişkileriniz iyi...Bu size bir konfor sunuyor ve işinizi sevmemenize rağmen uzun zaman bu ortamda çalışıyorsunuz, ve bu istediğiniz şeyi yapmanıza engel olan bir faktör oluyor. Bu konfor kemikleşmeden kırmak gerekiyor, 3yıllık konfor ile 10yıllık konfor arasında ciddi bir fark var, hele işin içine aile vs. gibi kavramlar da girmiş ise.

Yapmak istediğinizi yapmak için çalışmazsanız istemeden yaptığınız şey sizin işiniz oluyor ve sürekli biran önce emekli olsam da kurtulsam bu işten düşüncesiyle çalışıyorsunuz.

Yazılım Geliştirme Ekibinin Bütünselliği

Bir yazılım geliştirme ekibi nasıl olmalıdır sorusuna yazılım projesinin bağlamına, müşterisine, karakterine vs. göre farklı farklı cevaplar verilebilir ancak çoğu zaman gözlemlediğim ve beni rahatsız eden bir yapılanma şekli çok yaygın; rollere göre kurulan ayrı ayrı ekipler. Mimari ekip, altyapı ekibi, tasarım ekibi, geliştirme ekibi, test ekibi, analiz ekibi, kalite ekibi vs. Bu ekiplerin hepsinin başında bir lider ve bu liderler de hiyerarşide bir üstte birine(proje yöneticisi, proğram yöneticisi, çözüm yöneticisi, direktör vs.) bağlılar. Burada beni rahatsız eden temel konu bu ekiplerin bir birlerinden ayrı olarak kendi işlerini yapabilecekleri varsayımı.

Bu yapılanma kültürü sanırım biraz da waterfall yazılım geliştirme mantalitesi kaynaklı. Projenin her aşaması(analiz, tasarım, geliştirme, test) ayrı ve büyük tek aktiviteler olarak yapılır ve bu aktiviteleri de konusunda uzman ayrı ekipler yapar. Etkileşim vardır ancak bürokrasi de vardır, liderler farklıdır, ayrı grup mantığı vardır, çatışma çıkma olasılığı yüksektir.

Bana yazılım geliştirme sürecinin iterativ, üst üste konularak ilerleme şeklinde olması daha anlamlı geldiği için ekibin de bir bütün olması, gerekli olan farklı yeteneklere(analiz, test, dba, programcı, mimar vs.) sahip bir bütün olması daha mantıklı geliyor. Çünkü o kadar da ayrı gayrı işler yapmıyoruz tasarım, geliştirme, test, analiz bunlar aralarında ciddi ve sürekli bir etkileşim olması gereken, bir birlerinin farklı bakış açılarına muhtaç aktiviteler. Hepimiz aynı gemideyiz hepimizin amacı aynı; çalışan, doğru yazılımı doğru şekilde üretmek. Bu amacın ayrı ayrı ekipler ile çok etkin bir şekilde gerçekleştirildiğini veya gerçekleştirilebileceğini çok sanmıyorum.

Bence hangi ekipdesin sorusuna bir çalışan test, analist, geliştirme vs. diye cevap veriyorsa orada bir sorun vardır, ancak x projesi, y projesi diye cevap veriyorsa doğru bir bakış açısı vardır. Burada uzmanlık sağlanması, aynı role sahip insanların bir arada olmasının teknik bilgi beceri acısından faydaları gibi konuları yazılım geliştirmenin dışında tutuyorum. Bunları sağlamak icin illaki yazılım geliştirme ekiplerini bölmek gerekmiyor.

"Tek Takım", "Tek Lider" gibi konular biraz daha açılabilir, üzerinde düşünülebilir konular. Örnek yapılanmalardan benim hoşuma gidenler Toyotanın şef mühendis mantığı ve spotify yazılım geliştirme ekiplerinin yapılanmaları var.

Yazılım Üreten Organizasyonlarda Merkezileşme

Organizasyonel anlamda merkezileşme'den kastım daha çok karar mekanizmaları bağlamında; onlarca, yüzlerce insanın her gün yaptığı işi etkileyen kararların 2-3 kişi tarafından alınması. Konu(Organizasyon, yönetim vs.) hakkında derinlemesine bilgi sahibi birisi değilim, bahsedeceğim bazı yönetimsel kavramları tam anlamıyla açıklayamayabilirim, ancak yazılım üreten şirketlerdeki bu çeşit politikalar, yazılım üreten insanlara ve yazılım projelerine bakış açıma çok uymuyor, dolayısı ile ben konuya merkeze insanı koyarak neden merkezileşmemeliyiz bakış açısıyla bakmaya çalışacağım, biraz beyin fırtınası tarzında olacak.

Belkide yönetimin teorisi hakkında biraz daha gerilere gitmek gerekiyor, bugün çoğumuzun maruz kaldığı bakış açısını anlayabilmek için. 20.yy başları, sanayi devriminin iyice oturması, kapitalizm'in alt kademe insanlar için acımasız şartları, sosyalizm'i doğuran şartlar...

Frederick Winslow Taylor fabrikalarda farklı seviyelerde(işci, başmühendis) çalıştıktan sonra ekonomik verimlilik konusuna kafa yoruyor. Ve Bilimsel Yönetim adı altında bazı pratikler geliştiriyor ve bunları 1911 yılında bir kitap ile yayınlıyor. Taylor'ın bakış açısı tamamen ekonomik verimlilik üzerine, bunu sağlamak için her yol mübah gibi bir bakış açısı var, yani insan ikinci planda. Ve insana/işcilere bakış açısı genellemeci; işçiler sorumsuzdur, onları sürekli kontrol etmezsen işi savsaklarlar, onlar işlerini nasıl daha etkin yapabileceklerini bilmezler, hepsinin ödül/ceza motivasyonu aynıdır vs. şeklinde. Bunları aşabilmek için önerdiği yöntem; işleri planlayan, işçileri sürekli kontrol eden, onlara ne yapacaklarını, nasıl yapacaklarını sürekli anlatan, işcilerin performansını ölçen birileri olmalı, bir üst akıl, daha dogrusu bir üst akıllılar grubu olmalı. Ancak bu birileri işçilerin yaptıkları işin en iyi, en verimli nasıl yapılabileceğini bilebilir, uygulatabilir.

Taylor'un yöntemleri kullanılıyor elbet, ancak 1930'lar ile birlikte insana olan bu bakış açısı yavaş yavaş terk ediliyor. Taylor bu çalışmalarıyla, endüstri mühendisliğinin babası olarak biliniyor.

Douglas McGregor 1960'larda bir iş yerinde yöneticinin çalışanlarına bakış açısını gösteren, bir birine zıt 2 teori geliştiriyor; Theory X ve Theory Y.

Theory X'e göre insanlar tembel ve yaptıkları işten mutsuzdurlar, sorumluluktan kaçarlar. Dolayısı ile bu insanların verilen işi yapabilmeleri için otoriter bir yönetim stili gereklidir. Bu insanları yakın mesafeden kontrol etmek ve gerekiyorsa ceza vermek gereklidir.

Theory Y'e göre insanlar çalışarak bir şeyler başarmayı isterler ve bundan bir haz alırlar. Gerekli şartlar sağlandığında her insan sorumluluk almayı ister, motive olup, kendi kendini kontrol edebilir.

Her iki teoriden birisine uyan insanlarla beraber çalışıyor olabilirsiniz, tüm insanlar X'dir veya tüm insanlar Y'dir diye bir ön kabullenme yok. Aslında önemli olan bu iki yaklaşımın da bu iki insan tipinin de farkında olmak ve ona göre davranmak. X olan bir insanı Y bakış açınızla yönetemezsiniz, Y olanı da X bakış açısıyla.

Aynı bağlamda Peter Drucker'ın 1959'larda ortaya attığı knowledge worker diye bir kavram var. Türkçeye bilgi çalışanı olarak çevrilebiliyor. Bu insanlar hayatlarını düşünerek kazanan insanlar, en azından ağırlıklı olarak, doktorlar, mühendisler, bilim adamları, mimarlar gibi. Bu insanlar sürekli belli bir rutinde iş yapmazlar, problem çözerler, farklı bakış açılarını, yaklaşımları düşünmek işlerinin bir parçasıdır.

Drucker bu tip insanlarla çalışıyorsanız, bunların kendi işlerinin eğitimini aldıklarını ve yaptıkları işi en iyi kendilerinin bildiğini kabul etmek zorundasınız diyor. Bilgi çalışanlarının yöneticilerinin de bilgi çalışanı olması veya geçmişte bilgi çalışanı olmuş olması gerekir. Bu insanların motivasyon faktörlerini genelleyemezsiniz, bireysel olarak bu insanlarla ilgilenmek zorundasınız, bireysel farkındalık ile bu insanları motive edebilirsiniz.

Drucker 21.yy'da kurumların en değerli varlıkları bilgi çalışanları ve onların verimlilikleri olacak şeklinde bir öngörüde de bulunmuş.

Benim bakış açıma göre biz yazılım/bilgisayar mühendisleri kesinlikle bir bilgi çalışanıyız dolayısı ile bilgimize, tecrübemize, iş yapış şeklimize saygı duyarak, değer vererek yönetilmeliyiz diye düşünüyorum. Ancak çoğu zaman Taylor'un çalışanlara bakış mantalitesi ile yönetildiğimizi düşünüyorum.

Yönetilme şeklimizin odağında insan olmalı. Eğer yönetilme şeklimizin odağında ekonomik verimlilik, süreçler, ürün, proje vs. olursa bunları sağlamak çok zor ancak yönetilme şeklimizin odağında insan olursa ekonomik verimlilik, düzgün süreçler, düzgün ürünler hepsi bunun bir çıktısı olacaktır.

Tabi bu tek başına yeterli bir bakış açısı olmayabiliyor, doğru insan diye bir kavram işin içine giriyor. Siz doğru insanlarla çalışmıyorsanız, bu insanları Theory X'e göre yöneterek zar zor bir çıktı alabiliyor olabilirsiniz, aynı insanları knowledge worker mantığı ile yönetirseniz kaos üretiyor olabilirsiniz.

Peki doğru insanı nasıl bulacağız, işin içine insan girince, kesin ifadeler tanımlar çok gercekci olmayabiliyor ancak öncelikle Theory Y'deki tanıma uygun insanları seçmeye çalışmanız gerekiyor. İki anahtar kelime öne çıkıyor, iletişim ve merak. Yazılım mühendisleri için birinci yetenek çoğu zaman zor ama belli bir kriterin üzerinde olmasını beklemeliyiz, mükemmel teknik yetenekleri olan ama iletişim anlamında özürlü olan birisi ile bir noktaya kadar çalışabiliyorsunuz, gerçek başarıların bir takım çalışmasından çıktığına inanıyorsanız bu insanlarla uzun vadeli çalışamıyorsunuz.

Eğer yazılım üretirken bilgi çalışanı insanlarla çalışıyorsanız onları standartlaştırmaya çalışmanız, onlardan bağımsız süreçler tasarlamaya çalışmanız size çok bir fayda vermeyecektir. Yıllarca yazılım üreten bir bilgi çalışanına, hayatında iki satır kod yazmamış birilerinin, sırf teorik bilgiye dayanarak, nasıl çalışacağını tarif etmeye çalışması ne organizasyona ne de çalışana faydası olan bir yöntem. Bilgi çalışanlarının iş yapma şekilleri üzerine olan fikirlerinin üzeri, sırf bilgi çalışanı olmayan yöneticilerinin kafasına uymuyor diye çiziliyorsa, işi yapan yani gerçek yazılımı üreten kendisi olmadığı halde ortalıkta sürekli en iyi ben bilirim kafası ile dolaşanlar varsa, o organizasyondan sağlıklı çıktılar beklemek de çok gerçekçi değil.

Bilgi çalışanlarının olduğu bir organizasyonda sürekli merkezi kararlar alıp bunu dayatmak, yeni bilgi çalışanlarının gelişmesini engellediği gibi, insanların bu kararlara taahhüt vermelerini(commitment, buy-in) de engelliyor. Sonuç olarak asıl amacı yazılım üretmek olan firmada, yazılım üretmesi gereken bilgi çalışanları yazılım üretmek dışındaki her şeye odaklanmak zorunda kalıyorlar. Dolayısı ile yazılım üretilmiyor, yönetimin teşhisi çok farklı noktalara oluyor, daha fazla mikro yönetim, daha fazla kontrol devreye giriyor, ve daha kaotik bir sona doğru gidiliyor.

Bahsettiğim bakış açısı değişikliği ve insanların buna doğru tepki vermesi tabiki bir anda olabilecek bir şey değil. Yıllar boyunca insanlarda oturmuş bir yönetme ve yönetilme kültürü var, sadece şuna dikkat çekmek istiyorum; yöneticilerin ciddi bir beyin gücüyle çalıştıklarının farkında olmaları ve bu beyin gücünü kullanabilmek için ne gerekiyorsa ona yapmaları gerekiyor. Nihayetinde bu bir vizyon meselesi yani yöneticinin bakış açısında, hedefinde bu olmalı ve attığı her adımda bu hedefi gözetmeli. Çalışanlarına, bu işi siz yapıyorsunuz, bu işin sorumlusu da yetkilisi de sizsiniz bakış açısını vermeli, yöneticinin bu bakış açısının farkında olan ve bu profile uymayan çalışanlar zaten uzun vadede orada tutunamayacaklardır.

Burada denetimsiz bir şekilde her şeyin çalışanlara delegasyonu anlaşılmasın, süreclerinizde elbette farklı seviyelerde raporlamalarınız, ölçümleriniz olacak. Bunlara göre şartlar değişmiş ise sürekli planlama yapmanız gerekecek. Denetim konusunda yapıcı mıyız yoksa yıkıcı/cezalandırıcı mıyız sorusunun sorulması gerekiyor.

Bu işi tarihsel bir süreçte halletmiş ve nihayetinde çok iyi noktalara gelmiş örnekler var; TPS(Toyota Production System) gibi, tabi biz japon değiliz, araba da üretmiyoruz. Ancak Japonlar bu mantalitelerini farklı ülkelerde kurdukları fabrikalarda da uygulayabiliyorlar, önemli olan nasıl bir değer ve prensipler kümenizin olduğu, pratikler sektörden sektöre, ülkeden ülkeye değişebilir.

Önemli olan insana ve yaptığımız işe bakış açımızın bize ne kattığını ne katmadığını ciddi anlamda sorgulamak, odağı doğru yere yani insana yani yazılım geliştirme döngüsündeki en önemli varlığa ve onların beraber çalışabilmesine(ekip ruhuna) çevirmek. Yazılım geliştirme işini yapan çalışanlara, sanat ve fikir eseri geliştiren bir çalışanmış bir ustaymış gibi bakmak gerekiyor. Bu kültürü oturtmak ve insanları da bu kültür içinde yetiştirmek gerekiyor. İnsanlara zaten karşılığında parasını alıyorlar eş...k gibi yapacaklar sığ düşüncesinden ziyade sanki onları oraya gönüllü toplamışsınız da bir şeyler yaptırmaya çalışıyormussunuz gibi yaklaşmak gerekiyor. Ama bunu bizim insanımız suistimal eder, hic bir şey üretemeyiz karşı çıkışlarını yapanlar acaba hayatlarında hiç bunu denediler mi merak ediyorum. Suistimal edenler çıkabilir ancak bunu genelleyemezsiniz, suistimal edenlerden kurtulursunuz yolunuza doğru insanlarla devam edersiniz.

Gerçekten mükemmel ürünler/projeler üretmek istiyorsak mükemmel insanlara ihtiyacımız var, mükemmel insanları çekmek ve onların bizimle kalmasını sağlamak için de mükemmel organizasyonlara ihtiyacımız var.

İnsanlara şunu söylettirebilmektir bence bir organizasyon için gerçek başarı; "Her sabah uyanıp işe giderken şunu biliyorum ki mükemmel insanlarla mükemmel bir ortamda çalışacağım ve anlamlı bir şeyler yapacağım/başaracağım..."

Büyüdükçe merkezileşen, merkezileşme gereği duyan bir organizasyon bence düzgün büyünmediğinin önemli bir göstergesidir.

Kendisini "management exorcist" olarak tanımlayan Niels Pflaeging'i Agile Turkey Submit 2014 konferansında dinlemiştim, bakış açısı hoşuma gitmişti. Organize for Complexity isimli bir kitabı var, kitap biraz sunum tadında, içinde epey görsel var ama vermeye çalıştığı mesajı gayet iyi veriyor.