“Software Engineering at Google” Kitabından Notlar — 1
Google daha önce Site Reliability Engineering kitabıyla devasa sistemlerini nasıl yönettiğini anlatmıştı. Software Engineering at Google kitabı ile de bu devasa sistemlerini nasıl geliştirdiğini, yazılım geliştirme organizasyonunu, süreçlerini, teknik ve pratiklerini ve daha da önemlisi liderlik anlayışını gayet güzel bir şekilde anlatıyor.
Kitabı okuyunca birçok yazılım geliştirme ekibinin çalıştığı kalabalık BT organizasyonlarının karşı karşıya kaldığı, kurumsallıktan ileri gelen problemlerin büyük ölçüde Google’da da yaşandığını görüyoruz. Yazılımcıların dilediğince teknoloji seçip dilediği gibi kod yazdığı bir startup değil, birçok kuralları, süreçleri olan, uygulama altyapı takımlarıyla merkeziyetçiliğin güçlü olduğu bir kurumsal yapı görüyoruz. Ama Google’ın geleneksel kurumsallardan farkı meseleleri mühendislik disiplini çerçevesinde ele alıp profesyonel bir şekilde çözmeye çalışması diyebiliriz. Bu da işe alım konusunda kalite ve yetkinlikten taviz vermeyip belki de alanında en iyi kişileri istihdam etmesiyle mümkün olabiliyor.
500 sayfayı aşkın hacimli bir kitap. Konuları Tez, Kültür, Süreçler ve Araçlar kısımları altında 25 bölümde ele alıyor. Her bir bölüm o konuda uzman kişiler tarafından kaleme alınmış. Kitap zaman zaman Google’da bu konuların nasıl yapıldığını anlatıyor, zaman zaman ise nasıl olması gerektiği hakkında genel bilgi veriyor. Kitapta birçok bağlantı ve kitap referansı var. Meraklısı için gayet doyurucu bir kitap diyebiliriz.
Kitabı okurken bazı yerlerin altını çizdim, notlar aldım. Bunların üzerinden geçerken bunları bir blog yazısına dönüştürmenin iyi olacağını düşündüm. Tez ve Kültür kısımları altındaki bölümlere ait notlarımı bu yazıyla yayınlıyorum. Geri kalan bölümleri de yakında yayınlamayı planlıyorum.
1. Yazılım Mühendisliği Nedir?
Yazarlar önsözde vurgulamaya başladıkları programlama ile yazılım mühendisliği arasında farkları bu bölümde daha da detaylandırıyor.
“Programlama” kod yazmak olarak tarif edilirken “yazılım mühendisliği” kod yazmanın yanı sıra bir organizasyonun bu kodun devreye alınması ve zaman içerisinde bakımının yapılabilmesi için kullandığı tüm araç ve süreçleri de içeriyor.
Kitap zaten genel olarak bir yazılım geliştirme organizasyonun kod yazarken dikkat etmesi gereken şu hususların altını çiziyor:
· Zaman ve Değişim
· Ölçek ve Verimlilik
· Fayda — Maliyet Değerlendirmesi
Zaman ve Değişim başlığı altında özellikle kodu güncel tutmanın önemi vurgulanıyor.
Yukarıdaki grafikte de görüleceği üzere öğrenci ödevleri veya bazı mobil uygulamalar gibi kısa ömürlü uygulamalarda güncellemelerin önemi çok düşükken uzun ömürlü yani kullanımının ne zaman sona ereceği bilinmeyen uygulamalarda kodun güncel tutulması oldukça önemlidir. Bu özellikteki uygulamaların nasıl güncel tutulacağı eğer en başından itibaren planlanmaz ise ileride bu geçişler çok daha sancılı olacaktır.
Kodun güncel tutulması sırasındaki zorluklara işaret eden ve kitap içerisinde sıkça atıfta bulunulan Hyrum Yasası¹ bu bölümde tarif ediliyor.
Hyrum Yasası
Bir API yeteri kadar kişi tarafından kullanıldığında, sisteminizin görülebilir tüm davranışlarına, sizin ne vaat ettiğinizden bağımsız olarak birileri tarafından bağımlı olunacaktır.
Örneğin bir Hash kümesini ele alalım, buradaki değerler arasında sırasıyla dolaşıldığında çıkan sonuçların alfabetik sırayla olduğu görülse bile bu davranışa bağımlı bir kod yazılmaması gerektiği uzmanlar tarafından bilinir. Ama Hyrum Yasası’na göre sizin taahhüt etmediğiniz ama başkaları tarafından görülebilen bu davranış mutlaka birileri tarafından kullanılmıştır ve siz bu davranışı değiştirirseniz birilerinin uygulamaları çalışamaz hale gelecektir.
“Çalışıyor” ve “doğru” iki farklı durumdur. Yani kısa ömürlü bir program için “çalışan” bir kod yeterli iken uzun ömürlü bir uygulama için “doğru” şarttır. Aynı şey zaman zaman “zekice” olarak ifade edilen kod parçaları için de geçerlidir.
Eğer mevzu bahis programlama ise “zekice” demek bir iltifat iken yazılım mühendisliğinde bir “suçlama”dır.
Ölçek ve Verimlilik başlığında yine Google tarafında yayınlanan Site Reliability Engineering kitabında ayrıntılı olarak ele alınan Google’ın üretim ortamı sisteminin büyüklüğü ve bunu nasıl yönettiğine kısa değinilip bunun yanı sıra bir organizasyonun insan kaynağının ve kod tabanın da ölçeklenebilmesi gerektiğine vurgu yapılıyor.
Yazılım mühendisliği gözü ile bakıldığında şu soruların önemi artıyor.
- Tüm kodunuzun derlenmesi ne kadar sürüyor?
- Tüm kod deponuzun kopyalanması ne kadar sürüyor?
- Kullandığınız dilin yeni versiyonuna geçmenizin maliyeti nedir?
Organizasyon büyüdükçe bu problemlerin hareketi engellememesi için işe yarar politikaların devreye sokulması gerektiğine işaret edilip yine kitap boyunca sıkça atıfta bulunulan Beyonce Kuralı² tanımlanıyor. Bu kurala göre eğer bir şeyi beğendiyseniz bununla ilgili bir CI testi yazmalısınız.
Altyapı ekipleri tarafından kodunuzda bir altyapı değişikliği yapılıp CI testleriniz başarılı bir şekilde çalıştırıldıktan sonra ortaya çıkacak kesintiler ve hatalar altyapı ekiplerinin sorumluluğunda olmuyor. Bu politika uygulanmaz ise herhangi bir altyapı değişikliği tüm takımların koordinasyonunu ve derinlemesine incelemesini gerektireceğinden pratikte yapılamaz hale geliyor.
Ayrıca bu bölümde mühendislerin soru sorup uzmanların cevaplayabildiği tartışma ve iletişim forumlarının çok işe yaradığı ifade ediliyor. Örneğin eğer Java ile kod yazan yüzlerce yazılımcınız varsa ve bir Java uzmanı istihdam eder ve soru cevap ortamını sağlarsanız belli bir süre sonra kaliteli kod yazan yüzlerce Java yazılımcınız olur.
Vurgulanan diğer önemli bir konu ise kodu derleyici versiyonu yükseltilmesi gibi altyapı değişikliklerinin kolay yapılabilmesine elverişli şekilde tutulması. Bunun için de değişikliklerin sık sık yapılması tavsiye ediliyor. İlk geçişler sancılı olsa da sonraki geçişler kolaylaşacaktır.
Fayda — Maliyet Değerlendirmesi başlığında ise finansal, donanım kaynağı, personel, sosyal ve fırsat maliyeti gibi farklı maliyet çeşitlerine değinilip kararların veriye ve argümana dayalı olması keyfi olmaması gerektiği söyleniyor.
Google’ın ilk yıllarında yazılımcılar kodlarını çoğunlukla kendi makinalarında derliyor. Makinaları çok kuvvetli olmasına rağmen kod büyüdükçe derleme süresi uzuyor. Dağıtık bir derleme sistemi kurularak bu sürenin kısaltıldığını, bu sistemin geliştirme ve işletim maliyeti ile yazılımcıların zaman maliyeti karşılaştırması bu analizlere örnek olarak gösteriliyor.
Ayrıca büyük yazılım organizasyonlarında sıklıkla karşılaşılan ortak bir kütüphanenin bir bağımlılık şeklinde doğrudan kullanımı ile kopyalanarak ihtiyaca göre özelleştirilmiş bir halinin kullanımının karşılaştırılması da bu kararlara örnek olarak veriliyor. Değiştirmeden bağımlılık olarak kullandığında hata veya güvenlik açıklarını tek bir noktadan yamanabilmesi gibi avantajları varken özelleştirilmesi durumunun da performans artışı veya ek özellik gibi avantajları olabiliyor.
Bu kararları her zaman veriye bağlı olarak alabilmek mümkün değil ama kararın büyük ölçüde veriye dayanmasını sağlamak gerekiyor. Ayrıca zaman içerisinde verinin yönü değişirse kararı değiştirmekten de çekinilmemesi gerekiyor.
2. Takımlarda Nasıl İyi Çalışılır?
Bu ve sonraki birkaç bölümde yazılım mühendisliğinin kültürel ve sosyal yönleri ele alınıyor. Öncelikle değiştirilmesi kişinin kontrolüne olan değişkenle başlanıyor. Bu değişken kişinin kendisidir.
İnsan tabiatı itibariyle mükemmel değildir. Eksik ve kusurludur. Kişinin kendi kusurlarının farkında olması, davranışlarını tevazu, saygı ve güven prensipleri etrafında şekillendirmesi enerjisini insan ilişkileri problemlerine değil daha iyi kodlar yazmaya harcamasına yol açacaktır.
Kodlardaki kusurların görüleceği endişesi ile kodlarını açmaktan çekinmenin veya tarihçeyi silmeye çalışmanın veya Linus Torvalds gibi deha olmaya çalışmanın yersizliğine dikkat çekiliyor.
Takım halinde çalışmanın ve bilgi paylaşmanın önemi vurgulanıyor ve Otobüs Faktörü adında yeni bir metafor tarif ediliyor.
Otobüs Faktörü: Projenizin tamamıyla yok olabilmesi için bir otobüsün çarpması gereken kişi sayısı.
Bir projede öneli noktalar sadece bir kişi tarafından biliniyorsa bu kişi otobüsün altından kalırsa proje başarısız olmuş demektir. Eğer iki kişi ise otobüs faktörü iki olmuş demektir.
Sosyal ilişkiler şu üç temel prensibe dayanır:
Tevazu: Dünya ne senin ne de kodunun etrafında dönüyor. Kusursuz değilsin.
Saygı: Birlikte çalıştığın insanlara değer vermelisin. Onlara kibar davranmalı, becerilerini ve başarılarını takdir etmelisin.
Güven: Başkalarının da doğru şeyleri yapabileceğine inanmalısın.
“Başarısızlık bir seçenektir” sözü Google’da en beğenilen sözlerden biridir. Hatanın ve başarısız olmanın cezalandırılmaması, risk almanın teşvik edilmesi gerekiyor.
Suçlamadan Post-Mortem Analizi Kültürü
Hatalardan öğrenebilmenin en iyi yolu kök neden analizinin yapılıp bir post-mortem dokümanının hazırlanmasıdır.
İyi bir post-mortem dokümanı şunları içermelidir:
· Olayın kısa bir özeti
· Olayın fark edilmesinden incelenip çözüme kavuşturulmasına kadar geçen aşamaların tarihçesi
· Olayın kök nedeni
· Etki ve hasarlar
· Problemin hemen çözülmesi için gerekli düzenlemeler
· Problemin tekrar yaşanmaması için yapılması gerekenler
· Öğrenilen dersler
Bu doküman herkesin erişimine açık bir şekilde yayınlanmalıdır ki başkaları da görsün ve aynı problem tekrar yaşanmasın.
Google ilk başlarda tevazu, saygı ve güven prensiplerine uygun davranışları ifade eden Googley tabirini kullanmaya başlamış. Fakat zaman içerisinde herkesin kendine göre yorumladığı görülünce “Googleyness” ın ne olduğu şu kurallara bağlanmış:
Belirsizlik durumunda başarılı olur: Çatışan mesaj ve yönergelerle başa çıkabilir, kaygan zeminlerde bile uzlaşabilir ve çözüm yolunda ilerleyebilir.
Geri bildirime değer verir: Nazik bir şekilde geri bildirim alacak ve verecek alçak gönüllülüğe sahiptir. Geri bildirimin kişisel ve takım gelişiminde ne kadar değerli olduğunu bilir.
Statükoya meydan okur: Başkaları direnç gösterse bile iddialı hedefler belirler ve o yolda ilerler.
Kullanıcıya öncelik verir: Google ürünlerinin kullanıcılarına saygı duyar ve onlarla empati kurar. Onların menfaatine olacak işler yapar.
Takıma değer verir: Takım arkadaşlarına saygı duyar ve onlarla empati kurar. İstenmesine ihtiyaç duymadan onlara yardımcı olur, takım ruhunu besler.
Doğru olanı yapar: Yaptığı her işte güçlü bir ahlak hissine sahiptir; takımın ve ürünün menfaatini korumak için zor veya rahatsız edici kararları almaktan çekinmez.
3. Bilgi Paylaşımı
Her kurum kendi işini ve uğraştığı problemleri internetteki rastgele birilerinden daha iyi bilir. Dolayısıyla ortaya çıkan problemlerin ve soruların ilk önce kurum içinde cevaplanması gerekir. Bu da sağlıklı bir bilgi paylaşımı ortamının içeride tesis edilmesi ile mümkündür.
Öğrenme Engelleri
Psikolojik olarak güvende hissetmeme: İnsanların risk almaktan ve hata yapmaktan korktukları, bu nedenle cezalandırıldıkları ortamlarda paylaşım kültürü yerine korku kültürü ve gizleme eğilimi hâkim olur.
Bilgi adacıkları: Bilginin aralarında iletişim olmayan farklı birimlerde kümelendiği, ortak kaynakların olmadığı ortamlarda her birim kendi yoğurt yiyiş şeklini geliştirir.
Bilginin tek bir kişide toplanması.
Ya hep ya hiç uzmanlığı: Bazı çalışanların her şeyi bilip, diğerlerinin hiçbir şey bilmemesi. Bilenlerin bilmeyenlere aktarım yapmazsa bilenlerin bilgisi sürekli artarken bilmeyenler olduğu yerde saymaya devam eder.
Papağanlık: Kodun veya iş yapış tekniklerinin arka plandaki mantığın ve maksadın anlaşılmadan olduğu gibi taklit edilmesi.
Hayaletli mezarlıklar: Dokunmaya ve değiştirmeye korkulan kodlar.
Bu engellerin ortadan kaldırılması için Google’ın şunları yapıyor:
Psikolojik Ortamın Tesis Edilmesi
“Noogler” (new Googler) denilen yeni başlayanlara bir mentör atanır. Bu mentör kendi ekibinden biri olmadığı gibi yöneticisi de değildir. Başka bir ekipten bir mentör atanır ki yeni başlayan soru sorarken kendini daha rahat hissetsin.
Çalışanların grup ilişkilerinde soru sormaktan ve öğrenmekten çekinmemeleri için şu davranışlardan uzak durulması gerekir:
· “Şunu bilmediğine inanamıyorum” şeklindeki küçümseyici ifadeler
· Bilgiçlik taslamak
· Konudan bağımsız araya girip farklı fikirler ileri sürmek
· “Bunu babaannem bile yapar” gibi aslında arka planda belli bir grubun aşağılandığı ifadeler
Yeni bir şey öğrenilirken bu şeyin arkasındaki mantığı, böyle yapılmasının sebeplerini de anlamaya çalışmak gerekir.
Örneğin yazılımcılarının ayrıldığı eski bir kod devir alındığında karmaşık ve kötü yazıldığından şikâyet etmek yerine biraz vakit ayırarak derinlemesine incelemeli, niye böyle yazıldığını anlamaya çalışmalıdır.
Bire bir soru cevapla öğrenme yolu verimsiz olduğu için soruların grup konuşmaları ve eposta listeleri şeklinde sorulması Google içinde yaygın bir yöntem. Bu yazışmalar arşivleniyor ve sonradan arama yapılabiliyor.
Bu aşamada Google’da birçok şeyin eposta ile yönetildiğini, çalışanların her gün yüzlerce eposta aldığını, yeni başlayanların günlerce bu epostaları filtrelemek ve gruplamakla uğraştığını görüyoruz.
Ayrıca StackOverFlow benzeri YAQS isimli bir iç soru cevap sisteminin kullanıldığını görüyoruz.
Çalışanlar isteyenlerin sorularını yüz yüze konuşarak cevaplayabildikleri ofis saatleri belirleyebiliyor. Bu saatlerde bir araya gelip konuşabiliyorlar.
engEdu (Engineering Education) ve g2g (Googler2Googler) gibi programlarla teknoloji konuşmaları ve kurum içi eğitimler yapılıyor.
Kişilerin bilgi paylaşımını teşvik etmek için terfi ve özlük haklarında da bu konunun dikkate alınması gerekiyor. Google’da özellikle üst kademe terfilerinde paylaşım ve etki alanı genişliği konularının önemli bir faktör olduğuna değiniliyor. Ayrıca yönetimin müdahil olmadığı, sadece çalışanların görüşleri ile bazı çalışanlara prim gibi maddi teşvikler verilebiliyor.
Dokümantasyon ve her konudaki rehber yoluyla bilgi aktarımı da oldukça yaygın ve daha geniş olarak ilerleyen bölümlerde ele alınıyor.
Herhangi bir konuda güncel kalmak ve yeniliklerden haberdar olmak için EngNews(engineering news), Ownd (gizlilik ve güvenlik haberleri), Google’s Greatest Hits (önemli kesinti ve problemler) gibi haber bültenleri mevcut.
Google’da ileride ayrı bir bölümde anlatılacağı üzere çok sistematik kod gözden geçirme süreçleri bulunuyor. Her değişikliğin bir okunabilirlik onayı alması gerekiyor. Bir yazılım dilinin inceliklerini, o dilde doğru şekilde ve bakımı yapılabilir kod yazabilen kişilere (Google’ın yaklaşık %1–2’lik bir kısmına tekabül ediyor) okunabilirlik sertifikası veriliyor. Herhangi bir değişikliğin okunabilirlik onayını sadece bu kişiler verebiliyor.
Her kurumda olduğu gibi Google’da da kod gözden geçirme süreçlerini gereksiz ve vakit kaybı olarak gören mühendisler de yok değil. Fakat Google’da bu konuda yapılan çalışmalar okunabilirliğin kod kalitesinde ve mühendislik üretim hızında net bir artışa yol açtığını ortaya koymuş.
4. Eşitlik İçin Mühendislik
Bu bölümde hem işe alım süreçlerinde hem de ürün tasarlarken farklı etnik, cinsiyet, sosyal grupların göz önünde bulundurulması gerektiği ele alınıyor. Google bu konuda kendisinin de istenilen seviyede olmadığını anlatıyor ve zaman içerisinde kendilerinin de öğrendiklerini aktarıyor.
Bir dönem Google Photos uygulamasındaki görüntü tanıma algoritmasının siyahileri goril olarak sınıflandırdığını örnek olarak veriyor.
5. Bir Takıma Nasıl Liderlik Edilir?
Yönetici insanlara liderlik ederken Teknik Lider teknik çalışmalara liderlik eder.
Yazılım takımlarında hem yönetici hem teknik lider bulunmakla beraber küçük takımlarda bu iki rol Yönetici Teknik Lider adıyla tek bir kişide birleşebiliyor.
Mühendislik takımlarına yazılım kökenli olmayan hatta yazılımdan anlamayan kişileri yönetici olarak atayan kurumların aksine Google en başından itibaren yazılım yöneticilerinin mühendislik kökenli olmasına karar vermiş.
Yönetici, ürünlerinin iş ihtiyaçlarını karşılamasından sorumlu olduğu gibi takımın performansından, verimliliğinden, teknik lider dâhil takım üyelerinin mutluluğundan da sorumludur.
Teknik lider ise teknik kararlardan, mimariden, teknoloji seçimlerinden, önceliklendirmeden, takımın üretim hızından ve proje yönetiminden (büyük takımlarda bu işten sorumlu ayrı bir kişi olabiliyor) sorumludur. Teknik lider kendisi de üretim yapabildiği gibi başka çalışanlara bu işi devretmesinin daha doğru olduğu ifade ediliyor.
Kod yazan, bug çözen veya bir tasarım dokümanı hazırlayan bir mühendis iseniz günün sonunda kendinizi somut bir şeyler yapmış sayabilirsiniz ama gününüzü “yönetim” faaliyetleri ile geçirdiyseniz gün sonunda dişe dokunur bir şey yapmadığınız hissine kapılabilirsiniz. Bu, yıllarını elma sayarak geçiren birisinin muz yetiştiriciliğe başladığında etrafında yetişen muzları görmeyip bugün hiç elma sayamadım demesine benzer.
Organizasyonlarda genel olarak çalışanlar yetersiz kaldığı bir pozisyona kadar terfi ederler. Google Peter Prensibi olarak adlandırılan bu problemi engellemek için terfi adaylarından mevcut pozisyonlarının gerektirdiğinden daha fazla performans göstermelerini ve beklentileri aşmalarını istiyor.
İyi kod yazan ve işinden memnun olan mühendisleri yöneticiliğe zorlamak doğru olmadığı gibi etki alanının genişleyebilmesi açısından yönetici olmak gereklidir. Tek başına yazacağınız iyi kod miktarı oldukça sınırlıyken iyi bir lider tarafından organize edilen bir takım çok daha fazla kod yazabilecektir.
Bir yönetici öncelikle yönetme içgüdüsüne karşı gelmeli, alçak gönüllülük, saygı ve güven dolu bir atmosfer tesisi ile hizmetkâr yönetici olmaya çalışmalıdır.
Yöneticilerin şu hataları sık yaptığı belirtiliyor:
· Zayıf kişilerin tercih edilmesi: Eğer bir yönetici bulunduğu pozisyonda kendini güvende hissetmiyorsa, çalışanlarının kendisine karşı tehdit teşkil etmemesi için daha zayıf kişileri istihdam etmeye çalışır. Yetersiz kişilerden oluşan bir takımın üretimi sınırlı olacağı gibi yöneticinin yokluğunda işler sarpa saracaktır. Aksine bir yönetici kendinden daha zeki, yetkin ve kendini zorlayacak kişileri tercih etmelidir.
· Başarısızların göz ardı edilmesi: Ekipte düşük performans sergileyen birisi olduğunda yöneticiler çoğu zaman dişlerini sıkar, başka yere bakar ve bu kişinin sihirli bir şekilde aniden yüksek performans sergilemeye başlamasını veya ayrılmasını umutla bekler. Bu sırada ekipteki diğer başarılı çalışanlar durumun çoktan farkındadır, çünkü onun yükünü de kendileri taşımaktadır. Bu durumda onlar da ayrılmaya başladıklarında sadece düşük performanslılardan oluşan bir takım elinizde kalır. Dolayısıyla böyle bir durumun göz ardı edilmeden hemen çözülmesi gerekir. Bu, aksak birini önce yürümeye sonra takımla birlikte koşmaya alıştırmaya benzer. Alçak gönüllülük, saygı ve güvenden taviz vermeden bir birer ilgi göstermek gerekir. Başarabileceğini düşündüğünüz küçük ve ölçülebilir bir takım işleri belli süreliğine bu kişiye atayıp, haftalık olarak birlikte değerlendirme yapmak gerekir. Eğer işler iyi gitmiyorsa çalışanın kendisi de artık bu durumun farkında olacak ve ayrılmaya karar verecektir.
· İnsani problemlerin göz ardı edilmesi: Google gibi yöneticilerin genellikle uzun yıllar teknik işler yapıp terfi ettiği kurumlarda yöneticilerin insan ilişiklerinden kaynaklı problemleri göz ardı edip teknik konulara yoğunlaşması yaygın bir durumdur. Bu tarz problemleri empati ile ele alıp, motivasyon kırmadan çözümler üretmelidir.
· Her kesin arkadaşı olmak: Düne kadar üyesi olduğu bir takımın teknik lideri ve yöneticisi olan birisi takım üyeleri ile olan arkadaşlık ilişkisini kaybetmemek için ekstra gayret sarf eder. Bu ciddi problemlere ve arkadaşlıkların bozulmasına yol açabilir. Eğer kariyerini etkileyecek bir pozisyondaysanız sıradan arkadaşça tavırlar karşı tarafta bir baskı gibi algılanabilir. Takımla çok sıkı bir arkadaş olmadan da iş birliği tesis edilebilir. Ekip üyeleriyle sosyal ilişkilerinin kurulabilmesi için birlikte yenilen öğlen yemekleri çoğu zaman yetecektir. Bazen de bir yakın arkadaşınızın yöneticisi olursunuz. Eğer bu arkadaşınız yeterli performans sergilemiyorsa durum iki taraf için de stresli bir hal alır. Bu durumlardan da mümkün olduğu kadar kaçınmalı ya da bu kişilerle olan ilişkilere özellikle dikkat etmelidir.
· İşe alım seviyesinden taviz vermek: Steve Jobs’ın dediği gibi “A sınıfı kişiler A sınıfı kişileri işe alırlar, B sınıfı ise C sınıfını”. Genellikle şirketler eğer 5 kişi alacaklarsa 40–50 kişi ile görüşüp gerekli kriterleri sağlamasalar bile aralarındaki en iyi 5 kişiyi alırlar. Oysa işe alım maliyetleri ne kadar fazla olursa olsan kötü bir çalışanın maliyetinden daha azdır.
· Takıma çocuk gibi davranmak: Takımınıza güvenmediğinizi göstermenin en kısa yolu onlara çocuk gibi davranmaktır. Mikroyönetim sergiliyorsanız, becerilerini küçümsüyor veya işlerinde sorumluluk almalarına izin vermiyorsanız onlara çocuk gibi davranıyorsunuz demektir. Çalışanlarınıza sadece iş konusunda değil diğer konularda da güvenmelisiniz. Örneğin Google’da çalışanların istedikleri zaman gidip kalem, defter, kablo, fare gibi ihtiyaçlarını temin edebilecekleri kabinler bulunur.
Yöneticilerin şu davranışları sergilemesi tavsiye ediliyor:
· Bencilliği terk edin: Takımıza güvenerek bir takım egosu oluşturmaya çalışın, eleştirileri kabul edin ve hatalarınız için özür dileyin.
· Bir Zen Üstadı olun: Organizasyon diyagramını birbiriyle ilişkili çarklar şeklinde düşünürsek yukarı doğru çıktıkça çarklar büyür ve dişli sayısı artar. CEO en fazla dişliye sahip en büyük çarktır. Bu çarkın bir kere dönmesi en aşağıdaki çalışanların çarklarının birçok kez dönmesine yol açar. Dolasıyla yöneticilerin meseleler karşısında soğukkanlılığını muhafaza etmelidir.
· Katalizör olun, kararları takımın fikir birliği ile almaya çalışın. (Bazen %100 fikir birliğine ulaşmak zor olabilir, böyle durumlarda da karar vermelisiniz.)
· Takımın önündeki teknik veya organizasyonel engelleri kaldırın.
· Öğretmen ve mentör olun: Sizin kısa sürede yapabileceğiniz bir işte çalışanınızın saatlerce vakit kaybetmesi can sıkıcı olsa da onun öğrenmesi için çaba sarf etmelisiniz.
· Açık hedefler verin: Çalışanların takımın hedeflerini ve misyonunu bilmesi önemlidir. Bu şekilde doğru yönde ilerler ve öncelikleri kendileri de değerlendirebilirler.
· Dürüst olun: Takımınıza söyleyemeyeceğiniz şeylerin olduğu hatta duymak istemedikleri şeyleri söylemek zorunda olduğunuz durumlarla karşı karşıya kalabilirsiniz. Bildiğiniz ama söylememeniz gereken durumlarda yalan söylememeli, cevabı bildiğinizi ama söylemekte serbest olmadığınızı iletmelisiniz. Bilmediğiniz bir konu ise bilmediğinizi açıkça ifade etmelisiniz. Bazen de bir kişiye kötü bir yanını söylemeniz gerekir. Böyle durumlarda “iltifat sandviçi” kullanmak yani önce övüp sonra kötü yanını söyleyip sonra tekrar övmek mesajın karşı tarafta algılanmasını zorlaştırabilir. Böyle durumlarda kırıcı olmadan durumu doğrudan ifade etmek daha isabetlidir.
· Mutluluğu ölçün: İyi liderler çoğunlukla psikolojiden anlarlar. Ekip üyelerinizin mutlu olup olmadığı takip etmeli, mutlu etmeye çalışmalısınız. Bunun için, sıkıcı işleri hep aynı kişiye vermek yerine ekip içine dağıtmak, ortak eğlenceli aktiviteler yapmak gibi yöntemler kullanılabilir. Ayrıca sık sık “bir ihtiyacın var mı” diye sorarak çalışanın verimliliğini ve mutluluğunu artıracak ihtiyaçlarını karşılamak gerekir.
Bunların yanında:
· İşleri devredin ama eliniz soğumasın
· Yerinize birilerini yetiştirin
· Duruma müdahale etmeniz gereken anı iyi bilin
· Takımınızı kaos ve belirsizlikten koruyun
· Takımınıza organizasyonel haberleri belirsizliği giderecek ama dikkatlerini de dağıtmayacak kadar verin
· İyi bir iş yaptıklarında bunu takıma bildirin
· Geri dönmesi kolay isteklere evet deyin
6. Yüksek Ölçekte Liderlik
Teknik liderlik ve yönetim basamaklarında yükseldikçe teknik detaylarla ilgilenme imkânı bulamaz daha sığ ama daha geniş bir perspektiften bakar hale gelirsiniz. Bu ilk başta moral bozucudur, ta ki bir lider olarak artık daha geniş bir etki alanına sahip olduğunuzu görene kadar.
Gerçekten iyi bir lider olmak için “Liderliğin Üç Süreklisini” kullanmak gerekiyor: Sürekli karar verici olun (always be deciding), sürekli bırakan olun (always be leaving), sürekli genişleyen olun (always be scaling).
Sürekli karar verici olun
Takım takımlarını yöneten biri olarak daha fazla karar vereceksiniz. Bu kararlar da genellikle açık bir çözümü olmayan veya çözümsüz gibi görünen problemler ile ilgili olacak. Fakat bu problemlerin de incelenmesi, yönetilmesi ve kontrol altında tutulması gerekir. Kod yazmak ağaç kesmeye benzetilir ise liderin görevi ormanı yukarıdan görüp mühendisleri önemli ağaçlara doğru yönlendirmeye benzetilebilir. Karar verirken önce görme engellerini, daha sonra kazanılacak ve kaybedilecek şeyleri belirlemeli sonra karar verip çözümü uygulamalısınız.
Bu problem ile uzun zamandır yaşayan ve artık farklı düşünemeyen insanlar olabilir. Siz yeni bir gözle sorular sorup farklı stratejiler belirleyebilirsiniz.
Önemli ve belirsiz problemlerin kesin bir çözümü genellikle olmaz. Her kararın yan etkileri vardır. Kararı verirken nelerin göz önünde bulundurulduğunu ve hangi yan etkilerinin olduğu herkese anlatmak karar verenin görevidir.
Sürekli bırakan olun
Lider olarak çözümü çoğu kez takımlarınızın çözümüne bırakmanız gerekir. Bu şekilde siz daha farklı problemlere vakit ayırabilirsiniz. Takımlarınız sizin yokluğunuzda da hareket edebilmelidir. Sizin göreviniz kendi başına giden bir takım inşa etmektir.
Sürekli genişleyen olun
Liderlik literatüründe “genişlemek” etkinin artırılması olarak ele alınırken burada liderin kendisi şahsı etrafında ele alınmaktadır. Zamanı, dikkati ve enerjisi bir liderin en değerli varlıklarıdır. Liderin genişleyebilmesi bu kaynaklarını verimli kullanabilmesi ile mümkündür.
İlk olarak acil işlerin sizi tüketmesine izin vermemeli, önemli işlere vakit ayırmalısınız. Unutmayın lider olarak sizin işiniz sadece sizin yapabileceğiniz işleri yapmaktır, ormandaki güzergâhı belirlemek gibi. Bunun için işleri olabildiğince devretmeli (delegasyon), strateji, kariyer planlaması gibi önemli işler için belirli vakitler ayırmalı, bunun için gerekirse iş takibi yazılımları kullanmalısınız.
İkincisi bir lider olarak zamanınızı ve dikkatinizi meşgul edecek bir sürü şey olacaktır. Ne kadar işlerinizi planlamaya, takip etmeye çalışırsanız çalışın bazı işleri yapamayacak, bazı topları düşüreceksiniz. Eğer bazı topların düşmesi kaçınılmazsa düşecek topların rastgele olmasındansa kasıtlı belirlenmesi daha iyidir. Şu tekniği deneyebilirsiniz: İşlerinizi üç gruba ayırın. Birincisi en alttaki acil veya önemli işleri içermeyen %20’lik grup. İkincisi bir miktar acil veya önemli olsa da çoğunlukla karışık olan ortadaki %60’lık grup. Üçüncüsü ise kesinlikle önemli olan en üst %20’lik grup. Toplam %80’lik diğer iki grubu bir kenara bırakarak bütün enerjinizi %20’lik önemli gruba ayırın. %60’lık gruptaki önemli işleri ekibinize aktarmasanız bile bunları otomatik olarak görüp ilgileneceklerdir. Bu grupta kalan bazı önemli işler de zaman içerisinde daha önem kazanıp %20’lik kısma yükseleceklerdir. Bu şekilde kısıtlı olan vakit ve ilginizi önemli işlere ayırabilirsiniz.
Enerjinizi korumak için ise:
· Zihinsel olarak da işlerden tamamen uzak kalabileceğiniz gerçek bir tatil yapın
· İşiniz bittiğinde eposta, iş bilgisayarı, telefon gibi size işe bağlayan şeyler ile de ilişkinizi kesin
· Hafta sonlarını iyi değerlendirin
· Gün içinde ara verin
· Kendinizi iyi hissetmediğiniz günlerde, yanlış kararlar almamak için gerekirse hastalık izni kullanın
7. Mühendislik Verimliliğinin Ölçülmesi
İşler büyüdüğünde bunu mümkün kılan mühendislik organizasyonunu da büyütmek gerekir. Fakat kişi sayısı doğrusal artarken iletişim maliyeti bunun karesiyle orantılı artar. Dolasıyla kaynakların verimliliğini artırmak gerekir.
Google’da mühendislik verimliliğini ölçmek için ayrı bir takım vardır. Bu takım yazılımcıların yanı sıra davranış bilimi veya bilişsel psikoloji gibi farklı sosyal bilimler alanından uzmanları da barındırır. Bu sayede sadece teknik konular değil işin insani, motivasyon, özlük hakları gibi yönleri de ele alınır.
Bu ekip üzerinde çalışacağı konuları sistematik bir yaklaşımla araştırır. Bu çalışma yöntemi Google’daki kod okunabilirliği vakası üzerinden anlatılmıştır. Farklı kısımlarda anlatıldığı üzere kod okunabilirliği süreci çerçevesinde yazılım geliştirme yaşam döngüsü içerisine birçok adım eklenmiştir. Bazı yazılımcılar tarafından bu adımlar üretim önündeki bir engel olarak görülür. Durumun gerçekten böyle olup olmadığı okunabilirlik konularından sorumlu ekibin önerisi ile üretim verimliliği ekibi tarafından ölçülmüştür.
İlk aşamada problemin gerçekten ölçülmeye değer olup olmadığı anlaşılmaya çalışılır. Ölçüm sonuçları olumlu veya olumsuz çıkabilir. Her iki sonuç için de bir aksiyon planının uygulanmasının mümkün olması önemlidir. Örneğin bir aracın veya sürecin verimliliğe etkisini ölçersiniz ama bunları değiştirmek çok maliyetli olacağı için verimliliği düşürdüğü ortaya çıkması durumunda bile bir şey yapamayacak durumda olabilirsiniz. Böyle durumlarda ölçüm yapmaya ihtiyaç yoktur.
İkinci adımda ölçüm için gerekli metrikler belirlenir. Google’da metrik belirlemek için Hedef/Sinyal/Metrik çerçevesi kullanılır. Hedefler ulaşılmak istenen sonuçlar iken sinyaller bu sonuçlara ulaştığınızın belirtileridir. Her bir sinyali ise bir metrik ile ölçersiniz.
Her bir araştırmanın sonunda verimliliği iyileştirme adımlarını içeren bir tavsiye listesi hazırlanır. Bu kullanılan bir araca yeni özelliklerin eklenmesi veya daha da hızlandırılması, dokümantasyonun artırılması, demode süreçlerin kaldırılması veya özlük haklarında değişiklikler gibi şeyler olabilir.
[1]: Bu kitabın da editörleri arasında olan Google’ın tecrübeli mühendisi Hyrum Wright tarafından ilk dile getirilmiş.
[2]: Beyonce’un “Single Ladies” şarkısında geçen “if you like it then you shoulda put a ring on it” cümlesinden ilham alınmış.
