Temel Prensipleri kullanarak sorun çözmek

Çözmeye çalıştığımız problemi anlamak ve doğru problemi doğru yöntemle çözmek için temel prensipleri kullanmak

Yaptığım bir çok mülakatta görüştüğüm adaylara tecrübelerini daha iyi anlamak için genellikle ucu açık sorular sormayı tercih ediyorum. Böylece verecekleri cevaba göre tecrübelerini anlamaya çalışıyorum. Doğrusunu söylemek gerekirse mühendislik problemlerinde verilebilecek en güzel cevaplardan birisi, “duruma göre değişir”.

“Bu proje için hangi veritabanını kullanmalıyım?” — duruma göre değişir.

“Scrum mı yoksa Kanban mı kullanmalıyız?” — duruma göre değişir.

“Hangi dille yazmalıyız?” — duruma göre değişir.

Ancak bazen çalıştığınız firmadaki normallere öyle alışırsınız ki, her sorunun çözümü sanki orada kullandığınız yöntemler ya da teknolojilerle en iyi şekilde çalışır diye düşünürsünüz.

Hatta işin daha da kötüsü firmanızda çözmeye çalıştığınız her problemi mevcut araçlarla ya da firmaya yerleşmiş ön yargılarla çözmeye çalışabilirsiniz. Bir çok yazılımcı çözmeye çalıştığı problemi başkaları nasıl çözmüş diye araştırır ve günün sonunda bulduğu başka çözümlerden birini birebir kullanmaya başlar. Bu tarz hazır çözümler çoğunlukla bir şekilde çalışacağı gibi sonucunda ortaya çıkacak yan etkiler sizin organizasyonunuza ya da problemi çözmeye çalıştığınız sistemin dinamiklerine göre değişecektir. Dolayısıyla başkası öyle yapıyor diye birebir uygulamaya çalıştığınız herhangi bir model ya da çözüm muhtemelen derdinize derman olmayabilir.

Yukarıda anlattıklarıma uyan iki tane çok sık karşılaştığım örneği paylaşmak istiyorum. Birincisi teknik olan, yazılım ekiplerinin mikroservisler hakkında çok fazla makale okuyup, twitter’da tartışmaları okuduktan sonra bunu uygulamaya çalışması ve bir diğeri de organizasyonel olan, çevikleşmek adına Scrum’ı ya da daha da kötüsü SAFe‘i direkt uygulamaya çalışan kurumsal firmalar.

Bu örneklerin detayına girmeyeceğim, eminim siz de karşılaşmışsınızdır. Ben size Spotify modelini kendi dinamiklerine göre uyarlamadan uygulamaya çalışan başka bir firmadan bahsedeceğim. Firmanın adını bu yazıda paylaşmayacağım. Ancak sizlere o firmada bu modeli düşüncesizce uygulamanın sonuçlarını kısaca anlatmak istiyorum.

Bir hızlı büyüme (Hyperscale) macerası

Anlatacağım firmanın adı Şirket Ltd olsun. Aslında değil, ama firmadan izin almadığım için ismini paylaşmam doğru olmayacaktır. Maceranın başında Şirket Ltd. iş modeli gereği küçük kar marjlarına sahip 50 kişilik bir firmaydı. Yani çıktısının büyük bir kısmı, işinin doğası gereği maliyetini ancak karşılıyor, karşılığında %1’den daha az kar ediyordu. Hikayemiz bu 50 kişilik küçük firmanın, yatırımcıları vizyonuna ikna edip 200 milyon dolar yatırım almasıyla başlıyor. Daha önce bahsetmiştim, yatırımcıların nihai amacı yatırım yaptıkları firmanın büyümesi ve günün sonunda geleneksel yatırım araçlarından kazanacakları %10-20 getiriden çok daha fazlasını kazanmaya çalışmaktır. Örneğin yatırımını x5 ya da x10 yapan erken dönem yatırımcıları sektörde görmek çok olasıdır. Her neyse, bu yatırımcılar da aynı iştahla bu erken dönem 200 milyon dolar yatırımı milyarlara çıkartmayı istedikleri için Şirket Ltd’ye belki de hayal bile edemeyecekleri kadar büyük bir büyüme hedefi veriyorlar. Bunun üzerine firma bence ilk hatalarından birini yapıyor ve büyüme aşamasına girerken daha önce bu hacimlerde büyümeyi tecrübe etmemiş bir yönetici kadrosu hazırlıyor. Belki o anda çalışanlar açısından bakarsak, firmaya emek vermiş kişileri yönetim kadrolarında önemli rollere getiriyorlar ve dışarıdan sadık çalışanlarını ödüllendiriyorlar gibi görülebilir. Ancak bence bu tarz büyük ve hızlı gerçekleşecek organizasyon ölçeklenmelerin maliyeti ve riski çok fazla olacağı için nihai hedefin ne olduğunu çok iyi bilip ona uygun bir strateji ile ilerlemek daha akılcı bir yol olarak düşünülmelidir. Yani bunu tecrübe etmiş, daha önce başarmış ya da başaramamış ama en azından bu süreç içerisinden geçmiş birilerinin bu işin liderliğini alması hem firma hem de firmadaki çalışanlar açısından kritik öneme sahiptir.

Birinci öğrendiğimiz dersi geçerek hikayeme devam ediyorum. Şirket ltd, gelen yatırım ve motivasyon ile birlikte büyümeye ve daha fazla yazılımcı ve operasyonel alanlarda çalışacak personel almaya devam ederken bir noktada artık ekiplerde yeni başlayanlar verimsiz günler geçirmeye başlıyorlar. Öyle ki, bazı yazımcıların bilgisayarları ellerine ulaşmadığı için günlerce bomboş duruyorlar. Bilgisayarları ellerine ulaştığı zaman da bu sefer IT departmanının onlara yetkilendirmeyi yapmasını bekliyorlar. Bunun elbette yönetim kadrosunun tecrübesizliği ile açıklamak mümkün. Ancak böyle diyerek geçmek muhtemelen biraz tembellik olacağı için sizlere ufak bir “iyisi nasıl olurdu” açıklamak istiyorum.

Eğer bir firma hızlı büyüme trendine girmeyi planlıyorsa bu muhtemelen ekiplerden habersiz bir şekilde olmaz. Yani bir gün yönetim kurulu gelip, yarın hızlı büyümeye başlıyoruz alın size para demez. Bunlar haftalarca gündemde olur ve yönetim kadrosunun bunu iyice düşünmesi ve planlaması için fırsat verilir. Şirket Ltd ekibi ne yazık ki bu zamanı sadece işe nasıl alacağız kısmında harcamış, gelen yazılımcıları nasıl ekiplere entegre edeceğiz, bilgisayarlarını göndermek için nasıl bir lojistik düzen kurmalıyız ve işler kötü giderse nasıl bunu çözebiliriz diye yeterince düşünmeden işin içine girmişler. Bunun iyi örneklerini çalıştığım diğer scale-up’larda şöyle gördüm;

• Uzaktan çalışmaya başlayacak kişilere gidecek bilgisayarların tek bir IT elemanının evinde ya da sadece ofiste değil, dağıtık bir depolama yöntemi ile saklanması ve belki de kargolanması gerekir. .

• Yöneticiler işe başlayacak elemanları için rollere özel yetkilendirme reçeteleri hazırlamalıdır. Örneğin IT ekibi, işe başlayacak bir veri bilimci ya da yazılımcı için hangi yerlere erişimi olması gerektiğini çok iyi bilecektir.

• Firma, departman ve takım seviyesinde oryantasyon programları planlanmalı ve bunlar ürünler gibi tekrar tekrar uygulanabilir olmalı. Hatta bu programlar her ay en az bir kere tekrar etmeye devam etmelidir.

• Özellikle her hafta toplu şekilde 50-70 kişi işe başlıyorsa o zaman bu sürecin daha iyi planlaması ve bunların düzenli anketlerle ölçülmesi gerekir. Hatta işe başlayanlardan alınacak geri bildirimlerle ayda 1 kere bu süreci elden geçirmek, gerekiyorsa dramatik değişiklikler yapmak da faydalı olacaktır. Çalıştığım başka bir firmada rekorumuz haftada en fazla 50’si yazılımcı 250 kişiyi işe başlatmak olmuştu. O süreçten aldığımız geri bildirim ve yaptığımız hataları tartışmak sonraki haftalarda bizi çok hızlandırmıştı. Hatta öyle ki, artık yeni işe başlayanları pazartesi günleri değil, salı günleri işe başlatıyor ve pazartesi günlerini hazırlıkla geçiriyorduk.

Tabii bu kadar çok işe başlayan olmaya başladıktan sonra firmanın organizasyonunda yavaş yavaş çatlaklar ya da eskiden görülen ufak sorunların bir anda kocaman krizlere dönüştüğünü görebiliyorsunuz. Yani 50 kişi için çalışan süreçler artık çalışmamaya, işleri yavaşlatmaya hatta kimilerini işten soğutmaya sebep oluyor. Bu yüzden firmanın süreçlerini yönetmeye ihtiyacı vardı.

Spotify Modeline geçiş

O dönemlerde firmada yaşanan sorunların başında ekiplerin birbirine bağımlı olmaları, süreçlerin yavaş ilerlemesi ve ekiplerin sorumluluk alamaması geliyordu. Bunu çözmek için dahiyane bir çözüm olarak Spotify’ın kullanmadığı Spotify modelini uygulamayı tercih ettiler. Böylece sorun çözülmüştü, çünkü okudukları tüm makaleler onların bahsettiği sorunları çözeceğini söylüyordu.

• Ekiplere otonomi verilmesi

• İletişim sorunlarının giderilmesi

• Teknik yetkinliklere ait “guild”’lerle teknik paylaşımların yapılması

Bu vaatlerin hepsi yönetim kadrosunun çok hoşuna gitmişti ve ikna olmuşlardı. Böylece bunu kendi aralarında tartışıp, nasıl uygulanacağına karar verip büyük bir etkinlikle ekibe duyurdular.

Bu duyuru ile birlikte herkesin kafası karışmaya başladı. Zira işi yapan ekiplerin böyle bir değişiklik yapılacağından haberleri yoktu, kimse onlara bunun çalışıp çalışmayacağını sormamıştı. Üstelik bahsettikleri model ekiplerin iletişim sorunlarını gidermeyi planlarken birbirine bu kadar bağlı bir teknik altyapı ile uygulanması mümkün gelmiyordu. Yazılımcılardan birisi cesaretini topladı ve zor soruyu sordu.

— Ekip sayısını en az üç katı arttırmayı düşünüyorsunuz, aynı zamanda bu modele geçiyoruz ancak bizim altyapımız tek bir monolit yapı üzerinde çalışıyor. Ekipleri bu şekilde bölmek daha büyük bir probleme sebep olmaz mı?

— Evet çok haklısın, o yüzden mikro servis mimarisine geçiyoruz.

Hangisi daha kötü bilmiyorum. Bu önemli kararı soru sorulmasa öğrenmeyecek olmaları mı yoksa bu kararı verirken yazılımcılara bu fikri kimsenin sormamış olması mı? Her neyse, ekibin bu Spotify modeli uygulaması hem bir mikro servis dönüşümü hem de organizasyon değişimlerle birlikte firmayı büyük bir kaosa sürükleyeceği kesindi.

Spotify modeliyle birlikte hemen “tribe”lar oluşturuldu, ekipler bölündü, yeni takımların planı ve onların işe alım planları hayata geçmeye başladı. Arkasından ekiplerden birileri seçilip teknik “guild”’ler oluşturuldu. Her hafta toplanacaksınız ve herkes aynı teknolojilerden neler yaptığını konuşacak dedi. İlk başta yazılımcılarda değişimin ve büyümenin getirdiği bir heyecanla bu toplantılar çok başarılı ve akıcı geçti. Zaman içerisinde bu guild toplantılarının aslında herhangi bir şeyi düzeltmediği, önceliklendirmenin sadece ürün yöneticilerinin elinde olduğu ortaya çıkınca ekipler toplanmamaya başladı. Benzer şekilde mikro servis mimarisi hiç bir zaman gerçekten gerçekleşmedi çünkü ekibin önceliği her zaman kar marjını arttıracak öncelikli geliştirmeler oldu.

Yani aslında firmanın çözmeye çalıştığı gerçek problemin kar marjını arttırmak ve kullanıcı sayısını arttırmak olduğunu anladı.

Farklı nasıl yaklaşılabilirdi?

Yukarıdaki örneğin çok kötü uygulanmış olduğunu biliyorum. Yani aslında belki de aynı modeli farklı bir şekilde uygulamaya koymuş olsaydı firma başarılı olabilirdi. Dramatize ederek anlatmaya çalıştığım asıl konu problemin tespitini iyi yapabilmek ve bunun için doğru çözümü belirlemenin önemi. Mesela bir yazılım problemini ele alalım. Herkes bir şekilde Nesneye Yönelik Programlamanın (OOP) ne kadar önemli olduğundan bahsediyor. Bu yüzden OOP kullanan bir çok firma olduğuna eminim. Peki çözmeye çalıştığımız asıl problem nedir? Gerçekten OOP kullanmayı gerektiriyor mu? OOP kullanmak bizim için vakit ya da zaman kaybı olacak mı?

Benzer şekilde büyük yazılım ekiplerinin birbirinden bağımsız çalışabilmesi için bir çok firmada mikro servis mimarisi kullanılıyorsa sadece bu genel yargı yüzünden geçmeyi düşünmemelisiniz. Ya da bütün firmalar scrum kullanıyormuş diye scrum kullanmak, herkes kanban yapıyor diye kanbana geçiş yapmak sorununuzu çözmeyeceği gibi organizasyonunuzu da gereksiz bir strese sokacaktır.

Bu yüzden gitmek istediğiniz hedefi varsayımlardan kurtarıp, küçük parçalara ayırmanız ve bunu yaparken de atomik en küçük parçaların her zaman doğruluğundan emin olduğunuz parçalar olmasına dikkat etmelisiniz. Benim tecrübeme göre bunu yapmanın bir kaç farklı adımı var;

1. Bir sorunla karşılaştığınızda sizden önce konuyu incelemiş ve yorum yapmış kişiler olabilir. Bu kişiler eğer sonuca verileri inceleyerek varmadılarsa fikirleri ve ürettikleri fikirler öznel olabilir. Bu yüzden problemi çözmeye çalışırken konuyu sorunu tamamen anlamadan başkalarının analizlerine güvenerek karar vermeyin. Dinlemekten zarar gelmez, ancak kararlarınızı başkalarının fikirleri üzerine kurmayın.

2. Sorunun semptomlarını ve oluşturduğu yan etkileri verilere bakarak değerlendirin. Örneğin, “uygulama çok takılıyor” ya da “kullanıcılar mutsuz” gibi söylemler gürültüden başka bir şey değil. Bunun yerine uygulamanın yüklenmesini ne kadar sürede yüklendiğini ölçebilirsiniz. Hatta uygulama ne zaman cevap vermeye başlıyor, hangi alanları ne kadar sürede yükleniyor gibi ekstra bilgilere de ihtiyacınız olacaktır. Unutmayın problemi yaratan atomik parçaları arıyoruz.

3. Problemi çözmeye başlamadan önce problemin ne olduğunu yazın. Böylece iletişimi daha kolay olacağı gibi, kendinizi de problemi “gerçekten” anlayıp anlamadığınız konusunda eleştirme şansı yakalamış olursunuz.

4. Problemi anlatan dokümanda sorunun çözülmesinin ne anlama geldiğini de çok iyi ifade etmeniz önemli. Böylece problemi çözerken hangi parametrelere göre optimizasyon yapacağınızı çok iyi anlatmalısınız.

Böylece çözmek istediğiniz problemi “First Principles Thinking” ile çözmeye yaklaşabilirsiniz. Bu şekilde yaklaştığınız problemlerde varsayımlardan uzaklaşarak çözüme ulaşmanız çok daha kolaylaşacağı gibi aynı zamanda başkalarını da bu şekilde bilgilendirerek onları da çözümün bir parçası haline getirebilirsiniz.

Bu sadece teknik problemlerde değil, organizasyonunuzla ilgili problemlerde de uygulanabilir. Burada karşılaşabileceğiniz en büyük zorluklardan birisi, ekibinizdeki sorunu anlamak için araştıracağınız semptomların öznel olmamasına harcayacağınız çaba olacaktır. Çünkü teknik problemler objektif ve deterministik olurken ekip problemleriniz çoğunlukla deterministik sonuçlar doğurmayacaktır. İlerleyen yazılarda organizasyonel sorunları ve bunları nasıl ölçümleyebileceğinizi anlatmaya çalışacağım.