Çıkartarak eklemenin erdemi
Yazılım geliştirmeye Marie Kondo'cu bir bakış
7 yıl önce ilk defa Londra’ya taşındığımızda uçakta bizimle birlikte sadece iki valiz gelmişti. 7 yıl boyunca ne olduysa evin temel ihtiyaçlarının yanı sıra eşyalarla dolu bir yığına dönüşüverdi. 7 yıl boyunca adeta evin eşya entropisi durmadan arttı ve sonunda bir kaosa dönüştü. Ne zaman eve üzerinde düz bir alana sahip bir eşya alsak, örneğin bir sehpa ya da üstü boş bir kitaplık, her zaman üstü dolmaya başladı. Üstü dolmaya başlayan zeminlerin tozunu almak gitgide zorlaştı ve kaos büyümeye devam etti. Ben buna “Düz zemin teorisi” diyorum. Evin dağınıklığı evde üzerine herhangi bir şey koyulabilecek düz alanla doğru orantılıdır. Halbuki tüm masa ve sehpaları biraz eğimli yapsalar bu sorunların hiçbiriyle karşılaşmayacaktık!!
Her neyse, sürekli bir şeyler eklemenin sadece bizim evin sorunu olmadığına eminim. Hatta bu yazıda sizleri evimin dertleriyle ilgili düşündürmek amacında da değilim doğrusu. O yüzden lafı daha fazla uzatmadan konuya gireyim.
“Subtract” kitabının yazarı Leidy Klotz, kitabının girişinde oğluyla lego oynadığı bir anısından bahsediyor. Oyun oynarken legolarla bir köprü yapma işine geliyorlar. Köprünün bir bacağı diğerinden kısa olduğunu fark ediyor ve Klotz arkasını dönüp başka bir lego parçasını aramaya koyuluyor. Eksik parçayı bulup döndüğünde oğlunun uzun bacaktan bir parça çıkartarak aynı sorunu çözdüğünü fark ediyor.
Bu yazıyı okuyan birçok kişinin buna benzer sorunlarla karşılaştığına ve aynı Klotz gibi yeni bir şeyler ekleyerek çözdüğüne eminim. Doğrusunu söylemek gerekirse, ben de farklı bir bakış açısında değilim. Ancak sizce bunu yaptığımızda ne gibi şeylerden ödün veriyoruz?
Özellikle konu ürün geliştirme olunca, problemi çözmek için eklenen her yeni özellik ileride birçok yan etkiyi de beraberinde getiriyor. Bu durumda harcamamız gereken zaman ve efor uzun vadede dezavantaja dönüşüyor.
Eklemek yerine çıkartmanın en güzel gündelik örneklerinden biri bence küçük çocuklar için geliştirilen bisikletler. Eğer benim gibi 30’lu yaşların sonuna geliyorsanız ve küçükken bisiklet kullandıysanız siz de benim gibi yan tekerlekleri olan bisikletlere binmiş olmalısınız. Ancak o zaman bunların dengelesini oturtmak, yokuş çıkmak işleri karıştırıyordu. Hatta öyle ki birçok defa bu bisikletlerden bile düştüğümü hatılıyorum. Benim beceriksizliğimi göz ardı edersek aslında bu o zaman yapılan tasarımın belki de doğru ya da güvenli olmadığı anlamına geliyor olabilir. Ancak şimdilerde bir çocuğunuz varsa ya da etraftaki çocukları gözlemlerseniz ek tekerlek takmak yerine tasarım olarak pedallardan vazgeçildiğini göreceksiniz. Yani tasarlayan firma, eklemek yerine klasik tasarımdan pedalları çıkartarak tasarımını daha güvenli ve eğlenceli hale getirmiş.
Ürün geliştirme süreçlerine baktığımızda, çoğu zaman içinde bulunduğumuz rekabet ya da firmada görünürlüğümüzü arttırma çabası bizi başka seçenekleri tercih etmekten hatta çoğu zaman başka seçeneklerin olasılığını tartışmaktan bile alıkoyuyor. Bunun bir sonucu olarak rekabeti ya da terfiyi kaçırma korkusuyla ya da bazen sadece meşguliyetin arkasına sığınarak yeterince sofistike olmayan sonuçlara gidiyoruz.
Son zamanlarda büyük teknoloji firmalarında tartışılan “terfi motivasyonu üzerine kurulu düzen” birçok firmada zaten yapılmış ürünlerin tekrar tekrar ortaya çıkmasına sebep olduğu görülmüş. Örneğin Google’un birden fazla mesajlaşma uygulaması geliştirmesi, ya da aynı özelliklere sahip birçok uygulamanın ortaya çıkması gibi.
Kitabın yazarı Klotz bir başka sebep olarak da “Meşguliyet tuzağından” bahsediyor. Az önce saydığım örneklerden bunun farkı insanın doğası gereği meşgul olmanın pozitif olarak algılanması olarak özetleyebiliriz. Yani “eğer ben meşgulsem ve çok çalışıyorsam muhtemelen doğru bir şey yapıyordumdur” algısı.
İşte bunların hepsi, bizi yeterince sofistike olmayan çözümlere iten sebeplerden bazıları. Bunun bedelini de sürekli dağınık, bakımını yapması zor ürünler ortaya koyarak ödüyoruz. Nihayetinde de fazla çalışıyoruz hatta belki de daha kötüsü fazla çalışılmasına sebep oluyoruz, stresle baş etmeye ve eskiden verdiğimiz kararların yarattığı yeni sorunları çözmeye çalışıyoruz. Eminim bir çoğunuz geliştirdiğiniz ürünlerde “Bu da bence çok işe yarar” diyerek eklediğiniz ancak sonra o üründe çalıştığınız süre boyunca kabusa dönüşen birçok karar vermiş olmalısınız. Siz işten ayrıldıktan sonra da arkanızdan gelen başka birisi bu özelliği üstlenip, hiç bir bağlama oturtamadan desteklemeye devam etmiştir. (bkz: Cargo Culting) Güzel bir yakın zaman örneği Twitter’da her tweet’in altına görünen “iPhone ile gönderildi” mesajı.
Peki bakış açımızı nasıl değiştirebiliriz?
Bakış açımı eklemeye odaklanmaktan, çıkartmaya odaklı bir hale getirmeye çalışırken en çok zorlandığım konu önyargılarımdan vazgeçmek oldu. Öyle ki, ekip arkadaşlarımın çözümlerini çok beğensem de çoğu zaman kendimi “Buradan ne çıkartırız?” diye düşünmeye zorladım ve sonrasında da uzun tartışmalarla karşımdakileri ikna etmeye çalıştım. Tabii ki bu ne ölçeklenebilir bir çözümdü, ne de her özelliğin karar vericisi ben olmak istiyordum.
Özellikle ekip liderliği yaptığınız bir konumdaysanız bunu uygulamaya sokmaya çalışırken ekibi sınamak yerine kendinizi yanlışla ekibe çözüm sunarken bulabilmeniz çok mümkün. Bu da haliyle ekibin kendi başına karar verebilme yetkinliğini riske atmaya başlamanız demek. Peki doğru çözüm nedir?
Benim kendi bulduğum çözüm öncelikle ekibin bakış açısını çıkartmaya ve tek bir soruna odaklanmaya itmek oldu. Çoğu zaman büyük resme göre çok genel bir çözüm bulmak harika bir fikir gibi gelebilir ancak eğer o genel çözümü uygulamak özel bir çözümden çok daha fazla vakit alacaksa bu durumda gidilen yol doğru olmayabilir. Tabii ki aksinin geçerli olduğu ve yatırım yapılmasını hak eden durumlar vardır. Ancak her bunu genellemek kesinlikle gereksiz bir masrafa sizi zorlayacaktır. Bunun için ekibin sorunları doğru tanımlamasına yardım etmek, hatta çoğu zaman onlardan “sorun tanımı” dokümanı istemek en önemli adımlardan birisi olabilir. Bu dokümanın amacı, “Bu sorun neden bir sorun?”, “Bunu şimdi çözmezsek ne kaybederiz?”, “İyi bir çözümü bulduğumuzu nasıl anlarız?” gibi sorulara cevap vermek. Böylece ekip çözmeye çalıştığı sorunu anlarken bir yönetici olarak onları sınama şansını yakalayabilirsiniz. Bu dokümanın bir başka avantajı da ekibin bu süreçte çözüm yöntemlerini tartışmak için yeterince zamanı olmasını sağlaması. Yani aslında sorunlar üzerinde çözümlerden daha fazla vakit geçirip böylece ekiplerin doğru sorunları çözmek için gerektiği kadar vakit ayırmalarını sağlayabilirsiniz.
Bu yöntemle belki de sorun olduğunu düşündüğümüz birçok yeni özelliği eklemekten vazgeçmeye başladık. Çünkü bu sorunları çözmek için yeterince geç olmadığına kanaat getirmeye başladık. Aynı Marie Kondo gibi, eğer size heyecan vermiyorsa ondan kurtulun.
Bunların hepsinden en önemlisi siz de bu yazıyı okuduğunuza göre artık çıkartarak eklemenin mümkün olduğunu biliyorsunuz. Bu da, artık sorunlara bu opsiyonu en başta düşünerek başlayabilirsiniz anlamına geliyor. Eğer gerçekten bakış açınızı değiştirmek istiyorsanız karşılaştığınız bir soruna, evinizin salonuna, dolabınızdaki fazla eşyalara bakarak “Buradan ne çıkartabilirim” diye kendinize sormalısınız. Eğer kendinizi bununla yeterince sınarsanız günün sonunda aslında ihtiyacınız olduğunu düşündüğünüz birçok şeyin kalabalık olduğunu göreceksiniz.
Eğer duymadıysanız, yazılım ekiplerinde çalışanlar için teknik liderlik eğitimi veriyorum. 7 kişilik kontenjanımız kaldı!
