Büyük Teknoloji Şirketlerinde Projeler Nasıl Ship Edilir

Neden lansman yapmak zordur?

• Birçok kişi ship etmenin kolay bir iş olduğunu sanır, ancak varsayılan durum çoğu zaman lansmanın gecikmesi, iptal edilmesi ya da düşük kalite nedeniyle sorun çıkmasıdır.
• Tüm kodu yazmış veya tüm Jira biletlerini kapatmış olmak, otomatik olarak lansman yapıldığı anlamına gelmez. Lansman için birinin liderlik rolünü üstlenmesi gerekir.
• Lansman en yüksek öncelikli iş olmalıdır. Kullanıcı deneyimine (UX) aşırı odaklanmak, aksine lansmanı geciktirebilir.
• Bir projeyi başarıyla yayına almak için teknik bir lider ya da DRI (Directly Responsible Individual) gerekir. Bu rolü üstlenen bir mühendisin olduğu ekiplerin başarı olasılığı daha yüksektir.

Ship etmek nedir?

• Birçok mühendis ship etmeyi yalnızca kod dağıtımı veya özelliğin etkinleştirilmesi olarak düşünür, ancak büyük teknoloji şirketlerinde bunun tanımı farklıdır.
• Lansman, şirket içindeki önemli kişiler bunun “yayına alındığına” inandığında gerçekleşir. VP veya CEO memnun değilse, kod dağıtılmış olsa bile fiilen ship edilmiş sayılmaz.
• Bir proje kullanıcılar nezdinde büyük başarı elde eder veya gelir üretirse yayına alınmış sayılır; ancak kullanıcı tepkisi iyi olmasa bile liderlik memnunsa yine de lansman yapılmış kabul edilir.

İletişimin önemi

• Projenin hedefinin ne olduğunu net biçimde anlamak gerekir. Hedefe göre çalışma biçimi ve iletişim stratejisi değişir.
• Şirket liderliği, projenin teknik ayrıntılarını neredeyse hiç bilmez. Bu nedenle güveni korumak için doğru tahminler, sorun çözme ve uygun güncellemeler önemlidir.
• Güveni korumanın yolları:
• Geçmişte başarılı lansman deneyiminin olması avantaj sağlar.
• Kendinden emin bir tutum sergilemek gerekir.
• NASA görev kontrolü gibi profesyonel ve kısa biçimde iletişim kurmak gerekir.
• Günlük veya haftalık güncelleme başlıklarıyla proaktif şekilde bilgi vermek gerekir.

Prodüksiyon dağıtımındaki sorunları çözmek

• Sorunların çoğu beklenmedik ayrıntılardan kaynaklanır. Örneğin Memcached blok boyutu sorunları, trafik tahmini hataları veya hassas kullanıcı verileriyle ilgili meseleler olabilir.
• Sorunları hızlı çözmek için sistem hakkında derin teknik anlayış gerekir.
• Beklenen sorunlara hızlı yanıt verebilmeli ve bir sorunun ciddi olup olmadığını net biçimde açıklayabilmelisiniz.

Hemen şimdi yayına alınabilir mi?

• Kendinize “Bunu hemen şimdi yayına alabilir miyiz?” diye sormak önemlidir. Eğer yanıt hayırsa, bunun mümkün olması için neyin değişmesi gerektiğini düşünmelisiniz.
• Mümkün olduğunca erken geri bildirim alabilmek için feature flag'ler ve staging ortamı kullanılmalıdır.
• Lansmandan hemen önce teknik işleri azaltmalı ve bir sorun çıktığında hızla müdahale edebilecek şekilde hazırlanmalısınız.

Özet

• Lansman işi çok zordur ve en yüksek öncelik olarak ele alınmalıdır.
• Lansmanın anlamı yalnızca dağıtım değil, liderlik ekibinin memnun olmasıdır.
• Liderlik ekibinin güvenini kazanmak, başarılı bir lansmanın anahtarıdır.
• Sorunları öngörmek ve bunlara karşı yedek planlara sahip olmak önemlidir.
• Lansmandan hemen önce geliştirme işlerini azaltıp sorun çözmeye odaklanabilmek gerekir.
• Her zaman “Bunu hemen şimdi yayına alabilir miyiz?” sorusunu sormak gerekir.
• Korkuyu bırakıp cesaretli olmalısınız.

[GN⁺]

Hacker News yorumu

• "Shipping"in şirket içindeki sosyal bir kurgu olduğu gözlemi etkileyici. Önemli kişiler projenin tamamlandığına inandığında, proje tamamlanmış sayılıyor
• Bu yazı yazılım dağıtımıyla değil, yöneticileri memnun etmekle ilgili. Kullanıcılar nefret etse ve pazar alay etse bile yöneticiler beğeniyorsa, ürün ship edilmiş sayılıyor
• Sporda galibiyetin tüm sorunları çözmesi gibi, yazılımda da ship etmek tüm sorunları çözüyor. Kusursuz ürün yoktur ama erken ship ederseniz kullanıcılar memnun kalabilir
• Sorunları önleyen değil de sorunları çözen mühendislerin daha fazla takdir gördüğü durumlar olabiliyor. Sorunları önlemeye çalışırsınız ama liderler bunu fark etmeyebilir
• Büyük şirketlerde "ship etmek", yalnızca bir özelliği gerçeğe dönüştürmek değil, daha büyük bir bağlam içinde anlaşılmalı. Bazıları buna etik dışı diyebilir ama büyük şirketlerde bu bir tür "oyun"
• Çok sayıda proje ship etmiş ama somut örnek olmadığı için güvenmek zor. Gerçek proje örnekleri olsaydı anlamak daha kolay olurdu
• Bu yazı kendini öven bir blog spam'i
• Deneyimlerle örtüşüyor ama pratik tavsiye eksik. Liderliğin takdirini nasıl kazanacağınıza dair somut örnekler gerekli
• Büyük şirket deneyimimle farklılık gösteriyor. Yönetim desteği olmasa bile kullanıcı geri bildirimi veya metrikler olumluysa bu başarı sayılıyor. Küçük projeler de değerli olabilir
• İddiaları nicel ve nitel olarak temellendirmek gerekir ki güvenilir olsun. "Büyük şirkette ship etmek" çok geniş bir ifade ve daha somut açıklama gerekiyor

[signaling]

Etkileyici bir görüşten alıntı yaptım.

“Bazı insanlar yalnızca kendileri için teknik alanlar inşa etmek ya da hangi kademede olursa olsun kendilerinden üstte olanlardan övgü almak ister. "Oyunun oynanma şekli" budur. Bu oyunu oynamak eninde sonunda organizasyonun ölümüne yol açar ve zaten şirket yaşam döngülerinin olmasının nedeni de budur. Sonunda bu insanlar organizasyonu içeriden çürütür ve gerçekten fikir sahibi olan ya da işleri gerçekten sonuçlandırmak için optimize olan insanları dışarı iter.”

“Oyunu kazanmanın yolu, oyunu oynamamaktır”