Yönetim etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Yönetim etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

29 Nisan 2016

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

26 Nisan 2016

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.

08 Temmuz 2015

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.