- Geliştiriciler hayır dediğinde buna karşılık vermek, ürün yöneticisi olarak otoritenizi ortaya koymanıza ve hedeflere ulaşmanıza yardımcı olur
- Teknik nedenlerle bir özelliğin önerilen süre içinde uygulanamayacağı söylendiğinde, doğru sorularla durumu aşmak mümkündür
1. Bu özelliği oluşturmak için başka teknik çözüm yolları var mı?
- Bir özelliği geliştirmenin birden fazla yolu vardır ve ilk denenen yöntem her zaman en iyisi değildir
- Geliştiriciler en yeni teknolojileri kullanarak etkileyici özellikler oluşturmak isteyebilir, ancak bu durum sadelik için optimizasyon yerine aşırı mühendisliğe yol açabilir
- Belirli bir teknoloji setine sahip geliştiriciler, kendi bilgi alanlarının dışında kalan daha basit çözümleri fark etmeyebilir
- Bu yüzden mühendisi teknik çözüm konusunda daha yaratıcı düşünmeye yönlendirmek faydalıdır
- Birlikte çalıştığım en iyi ürün yöneticilerinden bazıları, teknik ortam hakkında yeterli teknik içgörü ve bilgiye sahipti; bu sayede mühendislerin kalıpların dışında düşünmesini sağlayan içgörülü sorular sorabiliyorlardı
2. Bu kısıtlarla bir çözüm önermek zorunda olsaydınız, bunu nasıl yapardınız?
- Önerdiğiniz çözüme geliştiriciler itiraz ediyorsa, onlardan kendi çözümlerini istemeyi deneyin
- Geliştiriciler yaratıcılık ve inovasyonun zengin bir kaynağıdır; özelliğin daha basit bir sürümü olup olmadığını sorarak onlara yaratıcı düşünme fırsatı verebilirsiniz
- Sorunun özünü anladıklarında, geliştiriciler yaratıcı düşünebilir ve projenin kısıtları içinde çalışan çözümler bulabilir
3. Bu özellik için aşamalı bir yaklaşımı değerlendirebilir miyiz?
- Teknik karmaşıklık nedeniyle özelliğin uygulanamayacağını söylediklerinde, projeyi aşamalara bölüp farklı yayın tarihlerine yaymanın mümkün olup olmadığını sorun
- Tek seferde büyük vizyonu sunmak cazip gelebilir, ancak aşamalı yaklaşım daha iteratif ilerler ve somut sonuçları daha hızlı verir
- Öncelikler değişebilir; aşamalı yaklaşım, geliştiricilerle birlikte sıradaki eklenecek özellikleri uyarlamanıza imkân tanır
4. Bu işi mümkün kılmak için hangi engelleri kaldırabilir veya çözebiliriz?
- Bu, kaynak temelli itirazlara yönelik bir sorudur; geliştiriciler sınırlı kaynakları (ör. zaman veya mevcut geliştirici sayısı) gerekçe gösterdiğinde, onların zamanını açmak için proaktif biçimde işleri kaldırın
- Olası yollar: işi tamamen kaldırmak, geliştirici gerektirmeyen işleri sizin üstlenmeniz, diğer ekipler ve/veya üçüncü taraflarla iletişimi sizin yürütmeniz ya da sürecin sahipliğini alıp eski özellikleri devre dışı bırakarak işi kolaylaştırmanız
Sonuç
- Geliştiricilerin "olmaz" demesine karşılık vermek ve biraz zorlamak rahatsız hissettirebilir, ancak bu size daha fazla saygı kazandırabilir
- Mühendisin neden karşı çıktığını biraz daha derinlemesine anlamaya çalışmalı, gerekçeleri tek tek belirleyip ortadan kaldırmalısınız
- Bu soruların hepsi iyi sorulardır; çünkü mühendisin belirli bir özelliği uygularken karşılaşabileceği kendine özgü zorlukları ve kısıtları kabul eder
- Aynı zamanda, ekibe ve projeye yardımcı olmak için bizzat elinizi taşın altına koymaya, zorlu işleri üstlenmeye ya da gereksinimlere ve takvime göre uyum sağlamaya hazır olduğunuzu da açıkça gösterir
8 yorum
Sonuçta mesele, bunu nasıl uyumlu hâle getirdiğine bağlı.
Güzel içerik, teşekkürler.
Yukarıdakilerle sorarsan, gerçekten sadece yapmak istemediği için “hayır” diyenler hemen ayıklanır gibi.
PM/PO olarak proje iş birimi ile IT birimi arasında koordinasyon rolü üstlendiğimde bana yardımcı olan 2 yöntem vardı.
Elbette bunun ön koşulu, ister iş birimi ister IT birimi olsun, tarafların söyleneni anlayabiliyor olmasıdır.
Birincisi, aşamalı ilerlemek.
İkincisi, kapsamı küçültmek.
Bu iki yöntem.
İş birimi ya da IT biriminin proje yürütürken yaşadığı en büyük zorluk 'süre'dir.
Süre bellidir ve çoğu zaman iş hacmi o sürenin içine sığmayacak gibi görünür.
Böyle durumlarda işi 'aşamalı' yaparız. phase 1, 2, 3.. gibi sıralı bir takvimle. En önemli işlevleri phase 1'e, daha az önemli olanları phase 2'ye... bu şekilde.
Ama böyle aşamalı yapılamayan, yani tek seferde yayına alınması gereken projelerde ise
kapsamı 'süre'ye göre küçültmek gerekir. phase 1, 2, 3'e girecek şeyler arasından 'gerçekten gerekli işlevler' dışındakileri elemek gerekir.
Bu iki yöntemle, 'söyleneni anlayan iş birimi/IT birimi' ise çoğu zaman herkes hemfikir olur.
Çünkü projenin çöküp herkesin kendi yöneticisinden fırça yemesinden iyidir..
Eh işte.
Herkese kolay gelsin^^
PS:
Bir de son bir baharat var.
Yukarıdaki 2 yöntemi kullansanız da geliştiriciler çoğu zaman yine pek sıcak bakmıyor.
Böyle durumlarda
"Proje süresinin ortalarına doğru bir kez kontrol edelim. Daha fazla zamana ihtiyaç olacak gibi görünürse süre uzatımını ben üstlenirim"
dediğinizde geliştiricilerin yüzü çoğu zaman yumuşuyor.
Bu yüzden ortalara doğru kontrol ettiğimizde, ek süreye gerek olmayan durumlar %95 oluyordu.
Bir de geliştiriciler kodlamaya başladı mı çoğu zaman iş hızlı ilerliyor.
Geliştiricilerle koordinasyon gerektiren bir roldeki biri olarak, böyle konuşmalar yapabilen geliştiricilerle çalışmak isterdim. Şimdiye kadar hep önce olmaz diyen geliştiricilerle karşılaştığım için üzülüyorum. Oradan buradan ikna etmeye ve sorup soruşturmaya çalışınca da çoğu zaman aslında kendilerinin bilmediği bir yöntem olduğu ortaya çıkıyor...
Hahahahahaha içim acıdı..
Mühendislerin, "NO" demeden önce kendilerine sormaları gereken sorular.
Bana da kişinin kendine sorması için gerçekten çok iyi sorular gibi görünüyor.
Sonuçta onlar, mühendis olmadan önce insan. Mühendis olarak alışkanlık haline gelmiş bir “hayır” tavrının sorun olduğu konusunda hemfikirim; ancak PM/PO tarafı da böyle soruları aklında tutarsa bunun çok büyük bir katkısı olacağını düşünüyorum.