Geleceği Yazanlar

Günümüz dijital dünyasında, makinelerin dillerini anlayarak, makinelere daha fazla işi daha az maliyetle ve ölçekli yaptırmadan geçiyor.

Geçmişte binlerde, onbinlerce kişinin yapacağı işi artık işlemci kapasitesi ve kodlar sayesinde çok daha hızlı ve tekrarlı yapabiliyoruz.

Müşteri ile son etkileşim kurduğumuz noktalarda artık mobil cep telefonlarının içerisine giriyor.

Ön uç ve arka uç geliştiricileri, yayılım ortamına göre farklı platform geliştiricileri (Android, IOS), farklı dilleri kullanarak aynı işleri yapmaya çalışanlar, bunları altyapıda ölçeklemeye çalışan artık ekiplerimiz var.

Bu tür sistemleri çalıştırmaya başladığınızda, işletim için network ve güvenlik operasyon merkezleri, sibergüvenlik, bunları işinizin doğasına göre, güvende tuttuğunuzu söyleyen sertifikasyonlar artık hayatımızın parçaları.

Artık geleceği yazanlardan bahsediyoruz. Bunlar kimi zaman geleceği hayal ettiren, vizyon yazıcıları, kimi zaman o vizyonu hayata geçiren, kod yazıcıları, hikaye yazıcıları, ilişkileri kurucuları, sözleşme yazıcıları, deneyim tasarlayıcılar.

Bunları bir arada tutmak için kültür yazıcıları oluştu ve oluşmaya devam ediyor.

VUCA dünyasında, gelecek belirsiz ve ancak geleceği hayal etmek, onları test etme, hata yapma, hatalardan öğrenmek ile yollarımızı bulabiliyoruz.

Artık işlerimiz laboratuvar ortamında, sürekli deneme ve test etmeden geliyor. O nedenle geleneksel şelale methodları artık işimizi çözmüyor. O nedenle çevik yöntemler ile o işlerin çalışıp çalışmadığını test etme ihtiyacımız oluşuyor.

Tabii bu Dünya’yı geçmişten gelen zihin haritalarımız ile yürütmeye çalıştığımızda da, o Dünya’nın ihtiyaçlarının karşılamaktan uzak kalıyoruz.

Geçenlerde okuduğum bir medium blogunda, bir yazılımca sorulabilecek en kötü sorunun “Ne zaman bitireceksin?” sorusu olduğunu yazıyor.

Gerçekten de ayrı dünyaların insanı olmamak, empati ile takım kurabilmek bu yeni dünya düzenini anlamaktan geçiyor.

Geleneksel zihin haritamızda, bu sorunun neyi var diyebilirsiniz. Yöneticilerin işlerinin ne zaman yapıldığını bilmesi onların görevi değil mi diyeceksiniz?

Takımların değer yaratmak üzerine aynı hedeflere odaklandığında, sorması gereken sorular, ekip arkadaşım ve takımım için ne yapabilirim sorusuna evrilebiliyor.

Kendinizi o geliştiricinin yerine koyun. Konuyu iş birimi olarak müşteri ihtiyaçlarını ne kadar derinden anladınız. İş önceliklerinizi, getirilerinizi ne kadar hesapladınız ve ne kadar temiz ve açık bir şekilde takıma bunu anlatıyorsunuz.

Yazacak birçok kodunuz var. Kodun, dokumanlarını oluşturuyorsunuz. Test edilmemiş kullanıcı API’larınız var. Yanınızdaki arkadaşınız kodun bir diğer kısmında değişiklikler yapmış ve sizde bu kodlar ile birleştirmeye çalışıyorsunuz.

Test ortamında sorunlar olduğunu biliyorsunuz. Oradaki kodları düzeltmeye çalışıyorsunuz ve ekipteki doğru kişiye adreslemeye çalışıyorsunuz.

Tüm bu karmaşıklıklar arasında, bunların problemsiz şekilde toparlanması için bir alternatif arıyorsunuz. Ne olduğunu bilmediğiniz, ancak hissettiğiniz bir çok şeyin ters gidebileceğini biliyorsunuz. Ancak yine de umudunuzu kaybetmemeye çalışıyorsunuz. Wright kardeşlerin ilk uçuş denemesindeki gibisiniz.

Tahmin ettiğiniz süre sonrasında, kullanıcı API’larının güncel olmadığını, slack mesajları, e-postalarda yalvararak iş yaptırdığınızı, tüm bunların içerisindeki dağınıklık, karmaşıklık ve belirsizlik içerisinde savaşacaksınız.

Sizce de bu durum fazla değil mi? Oyundan düşmemek için, takımın birbirini anlaması ve empati yapması, takım olabilmesi bu nedenle kritiktir.

Siz bir takım üyesi olarak neden bu sorunun kötü olduğunu anladınız mı? Bu durum öfke ve nefret yaratmaz mı?

Bu sorunun temelinde, yazılım geliştirme süreçlerinizin üretime benzer şekilde olduğunu varsayılmasından kaynaklanır.

Ancak bugünün yazılım geliştirme süreçleri öngörülebilir adımlardan oluşmuyor. Dallar, döngüler, çıkmazlar ve bunlar arasındaki karmaşık ağlar.

Yazılım geliştirme, üretime göre bilimsel keşif veya buluş sürecine benziyor.

Her şeyin teorisini keşfetmek ne kadar alır? Belki yıllarca, belki de asla.

Sorunlar ile karşılaşmak, onlara çözüm önerileri getirmek, onları hayata geçirmek, test etmek, hata yapmak, hatalarından ders almak, öğrenme, tekrar yapma yolculuğundan geçiyor.

Bilimsel keşifler gibi, yazılım geliştirmede de öngörülemez, dağınık, engebeli, yan yollar, çıkmazlar ve bunları çözerken karşılaşacağınız kötü fikirler ile doludur.

Bu durumda, “Ne zaman bitireceksin?” sorusunun cevabı “Karmaşık” olur.

Karmaşık bir soruya belirli bir cevap vermeye zorlanan geliştirici, diğerlerine ümit veren, bir miktar uydurma bir cevap ile sorusunu soracaktır. Ancak geleneksel yönetici bu çok, bundan daha hızlı yapmanızı bekliyorum diyerek, yöneticiliğini gösterecektir. Hiyerarşik olarak ta, sohbet tabii efendim elimizden geleni yaparız ile bitecektir.

Yönetici kafasında, bu düşüncenin çok naif olduğu düşünülür. Ancak sorgulamakta fayda vardır. Zihin haritaları gereği, şirket liderlerin projelerin son teslim tarihlerini anlamaları gerektiğini savunurlar.

Tamam siz de haklısınız. Tabii ki efendim.

Projelerin tahminlerini belirlemek ve bir ekibin çalışmalarını izlemek yönetmek için gerekir. Bu görevden kaçamazsınız.

Bu durumda bu işte uslübü değiştirerek ve ekip olmak ile başlayabilirsiniz.

Bir işin geliştirmesinin tamamlanma süresini tahmin edemeyebilirsiniz ancak birleştirme görevlerini tahmin edebilirsiniz. Ekibinizin geçmişteki iş paketlerini tamamlama hızı size genel olarak tarihler ile ilgili bir dayanak olacaktır.

Net cevapları alacağınız değil, veri ile desteklenen burn down chartlar sizin bu konuda işinizi kolaylaştıracaktır.

İkinci olarak, psikolojik güvenlik ortamının yaratılması ve takımın ayakta tutulması için, yapacağımız ne kaldı? engelimiz ne? nasıl çözebiliriz? soruları ekibe, sizinleyim, birlikte bir takımız mesajı verecektir. Büyüme zihniyetine kavuşan ekipler, kendilerini daha iyi hissedeceklerdir.

Bu şekilde takım ve kültüre büyük katkı sağlamış olursunuz.

Ekipteki arkadaşlarınızın nerede olduğunu, ne tür problemler ile uğraştığını, neye ihtiyaç duyduğunu daha fazla duyma şansına sahip olursunuz. İşte burada aktif dinle ve egonu bir kenara bırak.

İşte bunu ekip duyduğunda, herkesin kafasında bu konudaki diğer oluşabilecek engeller belirmiş olur. Onları açıklık ile dinlerseniz, neyin ters gideceğine, ne ile ilgili engelleri kaldırmanız gerektiğine öncesinden anlamış olursunuz. Ekibin katılımını sağlamış, birlikte problemleri çözmüş, birlikte güzel işler başarmış, en önemlisi de ekip olmuş olursunuz. O nedenle, yazılım geliştirici ekiplerinde hiyerarşi çalışmıyor.

Onları anlamak için çabanız ve anlayışınız, onların zamanlarını alarak değil, onların bildiklerini öğrenerek ve bunları sohbetlerde anlatmak için öğrenmek değil, problemlere sizin yaratıcılığınızı da koyarak, aksiyon alma gerekliliğiniz bulunuyor. Bu şekilde takım olunacağı gibi, işlerin sonuç odaklı olarak teslimatlarını da garantilemiş olursunuz.

Tüm bunlara rağmen, yazılım geliştirmede tahminler imkansız anlamına gelmez. Muazzam belirsizlikler içerdiği anlamna gelir.

Bu belirsizliklere karşın, onun nasıl iletişiminin yapılacağını, nasıl korunacağını, nasıl sorumluluk alacağını düşünmek gerekiyor.

Tahminler dolu silahlardır. Dikkatli kullanmak gerektiğini, yöneticiler bilmek durumundadır.

Yazılım Geliştiricilerinizi sorgulamayı bırakın ve süreçleri, projeleri derin anlayan, engelleri ortadan kaldıracak takım arkadaşlarınızı arttırmaya bakın.

Kötü soruların geliştirme ekipleriyle ilişkinizi zehirlemesine izin vermeyin.

Suçu çaresiz geliştiricilere aktarmak için cevaplanamaz sorular sormayın.

Liderlik ekibinize, “ Bana bunu Cuma gününe kadar yaptıracağını söyledi . Benim hatam değil!” diyebilirsiniz ancak bu liderlik değildir. Günah keçisi aramaktır.

Ekibinizin ne yaptığını anlayın, size nasıl gittiğini anlatan ölçümleri anlayın ve “Ne zaman bitereceksiniz?” sorusunun dağarcığınızdan çıkartın.