Ürün odaklılık vs. Proje odaklılık

Bir ürün yöneticisinin (veya bu konuda bir organizasyonun) karşılaşacağı en büyük zorluklardan biri, düşünce ve kültürü proje seviyesinden ürün seviyesine yükseltme çabasıdır.

Proje Düşüncesi

Proje düşüncesi oldukça yaygındır. Birçok kişi, özellikle yazılım geliştirmede, kariyerlerinin çoğunu projelere ve proje yönetimine odaklanarak geçirdi. Büyük kuruluşların genellikle sadece proje yönetimine odaklanan PMO departmanları vardır. Şaşırtıcı değil, çünkü proje yönetimi çok uzun zaman oldu. Ve biz insanlar olarak projeler açısından düşünmeye eğilimliyiz: Yapmamız gereken şeyler.

Peki proje düşüncesi nedir?

Proje düşüncesinin odak noktası teslimdir. Bu, belirli özelliklerin veya yazılımların teslimi veya gerçekten herhangi bir şeyin teslimi olabilir. Uçaktan evlere. Odak noktası teslimat olduğundan, birincil ölçüm zaman çizelgesinde ve programdadır. Proje yönetimi özellikle çıktıya odaklanmıştır ve önceden zaman çizelgesini ne kadar doğru tahmin edebileceğimiz ve daha sonra belirtilen çıktıyı bu programda sunabildiğimizle ölçülür. Başarı büyük ölçüde önceden bir şeyin özelliklerini almak, yol boyunca kilometre taşları olan bir program oluşturmak ve daha sonra bu tarihleri ​​vurmak olarak tanımlanır.

Ürün Düşüncesi

Ürün düşüncesi temelde farklı bir yaklaşım gerektirir. Çıktıya odaklanmak yerine, ürün düşüncesi sonuca odaklanır.

Bu, proje düşüncesinin zihniyetinden önemli bir değişimdir. Zaman çizelgelerine ve tarihlere odaklanmak yerine, ulaşmak istediğimiz hedefe veya yapılacak işe odaklanıyoruz. Çıktıdan ziyade sonuca odaklandığımız için, teslimatın etrafında, en azından önceden, zaman kısıtlamaları koymak çok daha zordur. Öncelikle, hedefi nasıl başaracağımızı mutlaka bilmiyoruz. Bu tür düşünme, özellikle projelere ve proje yönetimine odaklanan çok zaman harcayan insanlar için oldukça değişebilir. Birçok kişi, düzenli olarak izleyebilecekleri yapılandırılmış zaman çizelgelerine ve zaman çizelgelerine sahip olmama konusundaki belirsizlikten rahatsızdır.

Faydalar

Peki, sonuçlara odaklanmak için proje zaman çizelgelerini bırakmanın faydaları nelerdir? Her şeyden önce, nasıl çalıştığımızdan ve oraya nasıl baktığımızdan bağımsız olarak sonuçta doğru sürdüğümüz sonuçtur. Bir ürün zihniyetinin temel yararı, sonuca daha verimli bir şekilde ulaşmamızı sağlamamızdır.

Bir proje zihniyetiyle, başlangıçta istenen sonuca nasıl ulaşacağımızı bildiğimizi varsayıyoruz. Bu varsayımdan yola çıkarak, bir proje planı ve gereksinimler ve kilometre taşlarıyla dolu bir zaman çizelgesi oluşturduktan sonra bu plan üzerinde uygulamaya başlıyoruz. Haklıysak ve başlangıçta varsaydığımız şeyin doğru çözüm olduğu ortaya çıkarsa, o zaman çok formdayız. Sadece planı uygularız ve sonuca ulaşırız.

Ama ya başlangıçta yanılmış olsaydık? Tespit ettiğimiz çözüm umduğumuz sonuca ulaşmazsa ne olur? Proje düşüncesi bizi her türlü belaya sokar. Bir planı harekete geçirdiğimizde, özellikle daha büyük organizasyonlarda, eksen etrafında dönüp değiştirmek çok zor olabilir. Tarihler belirlendikten ve herkes bir plan üzerinde anlaştığında, öğrenmek ve uyum sağlamak için elimizden gelenin en iyisini yapmamıza rağmen, genellikle herkesin zihninde yapışır. Ve bir randevuyu kaçırırsak, ekipler ve işletmeler için inanılmaz sorunlara neden olabilir.

Ancak bir ürün zihniyeti ile, öğrenip adapte olabiliyoruz. Tarihler ve dönüm noktaları üzerine kurulu değiliz, daha ziyade öğrenmeye ve sonuca ulaşmaya odaklandık. Bir şey işe yaramazsa veya müşteriler bir şeye iyi yanıt vermezse, bunu herkesin odak noktası olan güzel bir plan patlatmadan amaçladığımız sonuca göre hesaplayabilir, uyarlayabilir ve yine de çalışabiliriz.

En önemlisi, sorunlar ortaya çıktığında (ve kendiniz çocuk olmadıkça, her zaman ortaya çıkacaklar), ürün düşüncesi öğrenmemize ve uyum sağlamamıza ve elde etmeye çalıştığımız sonuca odaklanmamızı sağlar. Aksine, sorunlar ortaya çıktığında ve zaman çizelgesine odaklanarak proje düşüncesinde sıkışıp kaldığımızda, ilk tahminlerimizin neden yanlış olduğunu ve programa nasıl geri döneceğimizi belirlemeye çalışmak için sık sık sonsuz toplantılara çekiliriz. Bu, sonuçta kalite, iş-yaşam dengesi ve sonuçtan fedakarlıklara yol açar, çünkü başlangıçta üzerinde anlaştığımız çıktıyı sunmaya odaklanmamız gerekiyor (bu hala yapılacak doğru şey olup olmadığına bakılmaksızın).

Proje Örneği

Birçok kavramdan bahsediyoruz, bu yüzden bu noktaları daha iyi göstermek için bazı örneklere bakalım.

Bir projenin harika bir örneği bir evin inşasıdır. Eşim ve ben geçen sene evimizi inşa ettik. Kat planını seçme, evdeki tüm sonları ve detayları seçme ve daha sonra devam etmek için büyük miktarda para ödeyerek tüm süreci geçirdik.

Başladığımızda, inşaat yöneticimiz (kim kesinlikle mükemmeldi) bize tahmini bitiş tarihini verdi. Gelecekte yaklaşık 6 aydı. Açıkçası, bu tahminlere giren birçok şey var ve genellikle tarihleri ​​ortaya çıkaran şeyler ortaya çıkıyor, ancak bir evin inşası tanımlanmış girdilerle çok tekrarlanabilir bir süreç olduğundan, iyi bir inşaat yöneticisi plana hafta hafta bakabiliyor ve işi ne zaman tamamlamayı beklediklerini belirleyin.

Bizim evim yaklaşık bir hafta, bence bir boğa gözü gibi hissediyordu. Esnaflardan biri işlerini yaparken gecikti, böylece bazı dalgalanma etkileri olan birkaç gün geri döndü. Ama bu iyi. Bekleniyor. Bu tür inşaat projeleri söz konusu olduğunda, bunlar proje yönetimine yöneliktir. Herkes ne yapılması gerektiğini bilir ve insanları programa dahil tutmak gerçek bir anahtardır, özellikle de sadece üzerinde çalıştığımız ev değil, tüm gelişme.

Ürün Örneği

Ancak bu tür proje yönetimi her yerde çalışıyor mu? Hayır, öyle değil.

Yazılım geliştirmeyi inşaat olarak düşünmek istediğimiz kadar değil. Açıkça tanımlanmış planlar ve işler, ne kadar uğraştığımız önemli değil, ürün geliştirmeye dönüşmez. İyi tanımlanmış zaman çizelgelerinde büyük rahatlık olsa da, ürün geliştirme böyle yapmamalıyız.

Üzerinde çalıştığım bir üründe, kitlemizi genişletmeye ve ek kullanıcılara ulaşmaya devam etmek için tanımlamamız ve çözmemiz gereken önemli bir sorun var. Buna geleneksel yaklaşım gereksinimleri toplamak, işi kapsamlandırmak ve daha sonra özellikleri oluşturmak olacaktır. Ama organizasyonumdaki birçok insanın şaşkınlığına rağmen, bu tip tipik bir yaklaşım benimsemiyorum. Sorunu anladıktan sonra, özellikleri inşa etmekten üçüncü taraf yazılımları entegre etmeye kadar çözümleri araştırmaya çalıştım. Bunu yaptığım zaman, çözümün aslında hiçbir şey inşa etmek olmadığı anlaşıldı. Çözüm, yeni özellikler oluşturmak veya bir başkasının yazılımını entegre etmek yerine (bu durumda, öğrenciler için bir portföydü), öğrencilerden yapmalarını istediğimiz şeyi değiştirmekti. Portföy aracına odaklanmak yerine, onlardan portföy parçalarını oluşturmalarını isteyebilir ve daha sonra çalışmalarını sergilemek için istedikleri yazılım çözümünü kullanabiliriz. Herkese faydaları önemli olacaktır. Öğrenciler portföylerinin kontrolünü elinde tutacaklardı ve biz yazılım geliştirmekle ya da belirli bir satıcı kullanmakla bağdaşmazdık.

Bu düşünceye asla proje düşüncesi ile gelemezdik. Bu çözüm, bir sonraki özelliği oluşturmak yerine soruna ve sonuca (uygulamamıza ek kullanıcılar almak) odaklandığım için ortaya çıktı. Bu tür bir sonuç tipik olarak ürün düşünmesinin sonucudur. Ve yol boyunca herhangi bir noktada gelebilir. Yukarıdaki örneğimde, herhangi bir geliştirme çalışması yapmaktan kaçındık. Ancak genellikle neyin işe yarayacağını anlamak için birkaç tasarım prototipi gerekebilir. Ya da hangi özelliklerin gerçekten istediğimiz sonucu doğuracağını öğrenmek için az miktarda geliştirme çalışması yapabiliriz. Sürecin neresinde öğrenirsek öğrenelim, kilit nokta, ön plana karar vermek ve bir proje planını takip etmek yerine yol boyunca öğrenmektir.

Doğru yol

Peki bunu nasıl yapacağız? Bir ürünü nasıl odaklarsınız? Tüm ürünler ve ürün yönetimi bir miktar proje yönetimi içerir. İşleri yolunda tutmalıyız ve maalesef paydaşlarımızın ve ortaklarımızın bazı tarihler veya taahhütler beklemeyeceği bir ortamda çalışabileceğimizi varsaymak gerçekçi değil.

Anahtar, taahhütleri ve proje planlarını ancak yüksek derecede güvenle yapabileceğimiz bir noktada yapmaktır. Dolayısıyla, önceden belirli bir yola girmek yerine, yaptığımızı doğruladıktan ve ne yapacağını gerçekten anlama şansımız olduğunda taahhüt ederiz. Genellikle bu bir sürat koşusu. Bu süreçte gerçekten geç gelebilir, ancak tahminlerin ve planların aslında bir şey ifade edebileceği noktadadır. Marty Cagan, Esinlenen: İnsanların Sevdiği Teknoloji Ürünleri Nasıl Oluşturulur adlı kitabında bu tür bağlılığa “yüksek bütünlük taahhüdü” diyor. Ekiplerin taahhütlerini sormadan önce uygun keşif ve araştırma yapmalarına izin veriyoruz.

Ayrıca, başkalarının ürün düşüncesinin yararını anlamalarına yardımcı olmamız gerekir. Birçok insanın tarih ve zaman çizelgesi istemesinin bir nedeni vardır. Bunun bir kısmı eski alışkanlıklardan kaynaklanıyor. Ancak iş ve bütçelerin gerekli olduğu zamanlar vardır. Bu nedenle, bu durumlarda zaman çizelgesinin işinin ne olduğunu anlamamız gerekir. Ürünü satmaya yardımcı olacaksa, odağı belirli özelliklerden daha üst düzey hikayeye dönüştürmeliyiz. Riski yönetmekse, belki de gerçek riskin bir tarihin eksik olmadığını anlamalarına yardımcı olmalıyız, hangi değeri sağlamaya çalıştığımızın işaretini tamamen kaçırıyor.

Günün sonunda, ürün geliştirmenin amacı, kullanıcılara ve müşterilere değer sunmaktır. Çoğu zaman, bu değeri ne sunacağını tam olarak bilmiyoruz. Ön plandaki doğru çözümleri bulabileceğimizi düşünmek, bazen yıllık planlama ve bütçeleme yaparsanız, bir yıl önceden, oldukça gerçekçi değildir. Proje düşüncesi, önden çözümler üretmeye ve daha sonra bir zamanlamaya karşı teslim etmeye odaklanırken, ürün düşüncesi sonuca odaklanmayı sürdürür. Bu, oldukça zor olabilen belirsizlik ve öğrenme ile bir miktar konfor içerir. Ancak, yalnızca zamanında çıktı değil, doğru sonuca ulaşmak istiyorsak, gerçekten çalışmanın tek yolu budur.