Ürün Yönetimi Süreçleri #1
Üretim Yönetimi Sürecinde Yaşadıklarım
Her geçen yıl yeni bir çırak olarak işe başlıyor olsam da aslına bakarsak uzun zamandır birçok ürünün yönetim sürecinde yer aldım. Tabiki en kıymetlileri kendi ürünlerimdi. Sorumluluğun büyük çoğunluğunun benim üzerimde olması ve uygulayarak öğrenme süreçlerini, düşünmeden ekosistemdeki bilgilere tercih ettiğimden birçok şey öğrendim. %80 ininde başarısız oldum bir sonraki çalışmamda başarılı olabilmek için.🚀
İlk deneyimimde planlama, süreç yönetim modeli falan olması gereken şudur dediğiniz ne varsa işte onların hiçbiri yoktu. Ne yapılması gerekiyorsa onu yapıyorduk. Aslına bakarsanız elimizde çıktı alacağımız ürünün tasarımı dahi yoktu. Tabi süreçte sıkıntılar yaşadıkça siz gelişime mecbur kalıyorsunuz. Ben de kaldım. Bu sefer görevleri listeledik ve sıra sıra yapılması gerekenleri yapmaya koyulduk. Merhaba waterfall.😄 (Bkcğz. Şelale Yöntemi)
Ancak hepsinden önemlisi bir aşama geriye gitmemiz bir başka sorun yaşıyorduk. Arayüz çıktılarına gözüm takılıyordu ve cidden “bir piksel aşağı” gibi bir durum kesinlikle değildi. Müşterilerimize para versek yine de kullanmazlardı. Ürünün sahip olması gereken özellik setini ve mevcut versiyonda yayına sunacağımız özelliklerin hangileri olacağını da belirlemiştik. Tam bu nokta “Ürün Tasarımı” (Product Design-UI UX Design) kavramı ile tanışmıştım. Tanışmak zorundaydım aslında çünkü kullanıcılar ve müşteriler modern teknoloji dünyasında arayüze adapte olamadıklarında ve deneyim odaklı bir tasarımla karşılaşmadıklarında yüksek oranda gitmeyi tercih ediyorlar. Ben de ekibin UI UX Designer’ı olmak için çalışmalara başladım. (Bu süreci anlattığım bir başka seri yapmayı planlıyorum.)🖌
Artık tasarımsal olarak neye ulaşacağımızı bildiğimiz ürünün özellik setini tasarımsal olarak prototiplendirebildiğimiz bir yapıya sahiptik. Hep bir adım ileriye gittiğimizde bunun en iyisi olduğunu hissetsem de aslında hep daha iyiye gitmem gerektiğini fark ediyordum. Ve fark ettik ki bir görev ölçümlenemez ve ölçeklenemez olduğunda özellikle zaman anlamında geriye düşüyorduk. Bunun için belli bir sürede herkesin yapabileceği görevleri belirlemesi tercihinde bulunduk. Yani A takım arkadaşım B tarihine kadar n adet görevi yapacak şeklinde belirledikten sonra bu görev listelerini görevleri yapacak arkadaşlara iletiyordum. Ancak anladımki başkasının yapacağı bir işin süresini sizin belirliyor olmanız çokta mantıklı değilmiş. Ayrıca bu süreci yönetmek için excel ile can çekişmemize de hiç gerek yokmuş.✋
Hatalarımızdan beslendiğimiz bu yolculukta ürünler değişse de değişmese de süreci iyileştirdiğimi düşünüyordum. Tabi bu halen hata yapmadığım ya da daha iyisini yapamayacağım anlamına gelmiyordu. Artık görevleri görevi yapacak kişilerin seçmesine ve olabildiğince makul sayıda görev süre ilişkisi kurulmasını sağlamaya çalışıyordum. Herkes aynı süreyi baz alarak koşmalıydı (bkcğz. sprint) ancak görevler hem o kişinin o periyottaki durumuna hem de ürünün versiyonlanma planına uygun olarak gitmeliydi. Bunun için görevleri ekibe paylaşılması için açmadan gruplamaya başladım. Tüm görevleri yine şeffaf bir şekilde görüyorduk ve tüm detayları biliyorduk ancak özelliklerin önceliklendirilmesini bu şekilde sağlamıştık. Bazı şeyleri de zamanında doğru yaptık.💪
Bu sefer yepyeni bir şey ile karşılaştık. Selam yeni sorun. Görevleri yetişmediği periyotlar oluyordu. Sonradan çalışırken bir yazı da okuduğum gibi bazen teknik borç hanesine bir şeyler yazmak gerekir. Ancak bu tip durumlarda bir sonraki periyota mı sarkma olacaktı? O görev için tahmin edilen süre yanlış mı tahmin edilmişti? Yoksa yazılımsal bir sorun mu vardı? Bu işi yapan ekip arkadaşım yeterli özveriyi göstermiyor muydu? O periyotta yaşadığı kişisel bir sebepten dolayı da gecikme yaşanmış olabilir miydi? Bir anda aklımda beliren birçok soru oluştu ve cevapları tek başıma düşünerek bulamazdım. Bu yüzden bu periyotta süreci ilerletirken tüm ekiple düzenli bir iletişim ve birbirimizi bilgilendirme mekanizması belirledik. Böylece A kişisi o hafta hasta olduğundan dolayı mı yoksa beklenmedik bir sorun ile karşılaştığından mı görev aksamıştı biliyorduk. Daha önce hiç iletişim kurmuyor muyduk? Elbette kuruyorduk ancak doğru iletişim ve şeffaflıkla artık gerçek nedenlere ulaşabiliyordum 🙅♂
Bu periyot bir aylık olduğunda çok uzun, bir hafta olduğunda çok kısa oluyordu. Ama ben özellikle yazılım ekibine daha büyük bir özgürlük alanı verip, bu yaylada rahatça koşabilmelerini istiyordum. 4 ay sonrası için belirlenmiş bir son tarihin olduğu bir periyot dahi belirledim. Evet yine teknik borç hanesi çok kalabalıktı. Ama hatanın farklı versiyonlarına dediğimiz tecrübe bu şekilde daha kaliteliydi. İki hafta için herkesin görevlerini alması sürekli olarak herkesin birbirini bilgilendirdiği bir yapının akış, işleyiş ve tamamlama açısından daha iyi olduğunu anladım 2️⃣
Bu ve bir sürü hata ve doğru ile birlikte geliştirdiğim her üründe daha çevik bir ilerleme ortamını yaratmaya çalışıyorum. Oldukça çok düşünülmesi gereken var. Bu da değinilmesi nokta yani yazılması gereken yazı demek. Giriş yazısında daha genel bir anlatımda bulundum ve sonrasında da deneyimlerimi paylaştığım daha çok detayına inen ve birlikte düşünmemizi sağlamak istediğim içerikler üretmek istiyorum.✍️
Müşterileriniz bizim geliştirmek için büyük çaba harcadığınız pek çok şeyle ilgilenmiyor olsalar da hepimiz benzer sorunları yaşadık veya yaşıyoruz. Benim sahip olduğum inanç hiçbir kalıp metodun bir ekip kültürüne doğrudan uymayacağı yönünde. Kendinize uyan esnek ancak çevik ürün geliştirme rehberini oluşturun. Bir sonraki yazıda bu konuya değineceğimden dolayı tekrardan buluşuncaya dek, sevgiyle kalın..
