30 yıldır, yazılım ürünü ve mühendislik liderlerine aynı sorular iş muadilleri tarafından sorulmaktadır:

• Ne inşa etmeliyiz?
• Bunun yerine neden bunu inşa ediyoruz?
• Özellik ne zaman gönderilecek?
• Kaça mal olacak?

Yazılım geliştirme neden ölçülebilir ve verimli olmaktan mazur gördüğümüz tek modern iş sürecidir? Yazılım endüstrisindeki çoğumuzun, yazılımın - yazılım geliştirme süreci dışında - herhangi bir süreci optimize edebileceğini düşünmesi ironik bir paradokstur.

Sonuç olarak, yazılımı zamanında ve bütçeyle göndermek norm değildir. McKinsey'e göre yazılım projelerinin %78'i gecikiyor, bütçeyi aşıyor veya hiç teslim edilmiyor. Ürün liderlerinin nihayet bu istatistiği tersine çevirmek için ihtiyaç duydukları araçlara sahip olması için Bloomfilter'ı kurduk .

Kara kutunun kapağını yırtmalıyız.

Yazılım geliştirme yıllar içinde çok gelişti. Projeleri daha küçük parçalara ayırdık ve yinelemeli hale getirdik, özel roller oluşturduk ve yeniden kullanılabilir bileşenlerden faydalandık. Kendi başlarına, bu yenilikler yazılım geliştirmeyi daha hızlı ve daha verimli hale getirdi. Ancak birlikte, hesap verebilirliği yaygınlaştırdılar ve optimize etmek şöyle dursun sürecin anlaşılmasını zorlaştırdılar.

İş "çevik" çalışmaz. İş liderlerinin üç aylık satış hedefleri, yıllık üretim hedefleri ve çok yıllı sermaye planları vardır. Bu planların ürün ekibiyle senkronize edilmesi gerekir - bu da "ne", "ne zaman" ve "ne kadar" gibi sürekli sorulara yol açar. İş, dolar ve sent dilinde çalışır. Sprintleri ve hikaye noktalarını ölçen panolar, saldırı ustaları ve mühendisler için harikadır, ancak iş-ürün işbirliğini daha kolay hale getirmezler.

Bu boşluğu doldurmak ürün liderlerine düşmüştür. Onları iş/ürün boşluğuna sıkıştırdık ve “gidin bunu düzeltin… çevirmenimiz olun” dedik. Bu imkansız bir iş. Aynı kişiden ürün vizyoneri, finans operatörü ve ekip kurucu talep ediyoruz.

Bir ürün liderinden yeni bir özelliğin durumu hakkında rapor vermesinin istendiği bir planlama toplantısı düşünün. Çoğu durumda, işlerin yolunda olup olmadığını görmek için mühendislik yöneticilerinden girdi toplarlar. Hatta bir proje izleme aracına bakabilirler. Ancak nihai olarak, tahminlere ve herkesin taahhütlerini yerine getireceği umuda dayalıdır.

Bu, ürün liderlerini etkilemek değildir. Riskleri tespit etmek ve güven düzeylerini ve öngörülebilirliği ölçmek için verileri kullanma yeteneği, eğer mevcut olsaydı, paha biçilmez olurdu (ipucu: bkz. Bloomfilter ).

Sosisin nasıl yapıldığını anladığımızda, sosis yapım sürecini geliştirebiliriz.

Bir süreci iyileştirmenin ilk adımı onu anlamaktır. Tıpkı şirketlerin satış kanallarını veya pazarlama hunilerini incelemeleri gibi, biz de gerçek zamanlı proje ilerlemesini, engelleri ve yatırımları görebilmeliyiz. Sürecin nerede raydan çıktığını, hangi faktörlerin raydan çıkmaya yol açtığını ve süreci daha öngörülebilir ve verimli hale getirmek için neler yapabileceğimizi anlamamıza yardımcı olacak nesnel verilere ihtiyacımız var. Olayları herkesin anlayacağı bir dilde ölçebilmeliyiz.

Bloomfilter'da, yazılım geliştirme yaşam döngüsü boyunca sistemlerden gelen zaman serisi verilerini okumak için süreç madenciliğini kullanırız. Buna temel geliştirme platformları — proje yönetimi araçları, kod havuzları, CI/CD platformları, tasarım araçları — ve iş bağlamı içeren diğer sistemler (CRM'ler, ERP'ler, HCM'ler vb.) dahildir. Bu bilgileri bir araya getirerek ve bağlamsallaştırarak, sürecin gerçekte nasıl çalıştığını görebilir, iyileştirme alanlarını belirleyebilir ve gelecek senaryolarını modelleyebiliriz.

Bu verilerle donanmış olan herkes, ortak bir nesnel gerçeklik görüşüne sahip olabilir. Projelerin durumu hakkında tahminde bulunmayı bırakabiliriz. Son teslim tarihlerini karşılayıp karşılamayacağımız konusundaki tahminlerimizden insan önyargısını kaldırabiliriz. İnsan yorumlaması, işbirliği ve karar verme ihtiyacı devam ediyor, ancak bunu paylaşılan bir hakikat ve anlayıştan yapabiliriz. Paylaşılan gerçek, güven ve daha iyi işbirliği yaratarak ürün ekipleri ile işletme arasındaki konuşmaları kökten değiştirir.

Sınır mevcut değil.

Süreçleri en çılgın hayal gücümüzün ötesinde optimize ederken yazılım geliştirmeyi geride bıraktığımızı fark eden ilk kişiler biz değiliz. Ancak, ürün yöneticilerinin hâlâ Excel ve Powerpoint durum güncellemelerini bir araya getirdiği gerçeğine bakılırsa, dünyanın kat etmesi gereken çok yol var.

Çözümün, geliştirici verimliliğini izlemeye çalışan başka bir araç olduğuna inanmıyoruz. Bir süreç problemini, "klavyedeki eller" veya "yazılan kod satırları" gibi Big Brother ölçütleri aracılığıyla bireylere bakıcılık yaparak çözebileceğiniz fikrini reddediyoruz. Kötü bir süreçte sıkışan büyük insanlar her zaman mücadele edeceklerdir.

Bu yolculuğa başladığımızdan beri, bize bunun çözülmesi gerçekten zor bir problem olduğu söylendi - ilginç problemler her zaman böyledir. Bu nedenle, mücadelenin hırsını karşılayacak deneyime sahip bir ekip oluşturduk. Ama aynı zamanda iğneyi biraz hareket ettirebilirsek, bunun dünyada muazzam miktarda iyilik yaratacağı da söylenmeye devam ediyor. Sabahları bizi ayağa kaldıran ve bizi çok heyecanlandıran şey budur.

Eğilimi tersine çevirdiğimizde işimizi yaptığımızı anlayacağız. Yazılım projelerinin %78'inin zamanında ve bütçenin altında teslim edildiği bir dünya hayal edin. En büyük tek hızlandırıcımız olan yazılım geliştirme hızlandırılırsa, toplum olarak daha kaç sorunu çözebileceğimizi bir düşünün.

Bu yolculukta bize katılmanızı memnuniyetle karşılarız. Önümüzde uzun bir yol var ve biz daha yeni başlıyoruz.

Andrew, Erik ve Bloomfilter ekibi

PS Yeni web sitemize göz atın !