Proje ve Ürün Yönetimi Arasındaki Köprü

Modern organizasyonlarda projeler artık tek başına ele alınan, izole çalışmalar değildir. Günümüzde projelerin büyük bir bölümü, daha uzun vadeli ve sürekli değer üretmesi beklenen bir yapının, yani bir ürünün parçası olarak yürütülmektedir. PMBOK® Guide 8, bu gerçeği açıkça kabul eder ve proje yöneticilerinden ürün odaklı bir bakış açısı geliştirmelerini bekler.

Bu yazıda, PMBOK® Guide 8’in 2.3 numaralı bölümünde ele alınan Product Management Considerations başlığı çerçevesinde, proje ve ürün yönetimi arasındaki ilişkiyi, bu ilişkinin organizasyonel stratejiye etkisini ve proje yöneticileri açısından neden kritik olduğunu inceleyeceğiz.


Ürün Yönetimi Nedir ve Neden Önemlidir?

Ürün yönetimi, bir ürün veya hizmetin yalnızca geliştirilmesini değil; fikir aşamasından başlayarak pazara sunulmasını, büyümesini, olgunlaşmasını ve sonunda emekliye ayrılmasını kapsayan bütünsel bir yönetim yaklaşımıdır. Bu süreç boyunca insanlar, veriler, süreçler ve iş sistemleri entegre şekilde yönetilir.

PMBOK® Guide 8’in vurguladığı temel nokta şudur:

Projeler, ürün yaşam döngüsü boyunca değer yaratmak için kullanılan geçici araçlardır. Bu nedenle bir projenin varlık nedeni, kendi başına “bitirilmesi” değil, hizmet ettiği ürünün değerini artırmasıdır.


Ürün Yaşam Döngüsü ve Projelerin Rolü

Her ürün, belirli evrelerden geçer. Genellikle bu evreler; tanıtım, büyüme, olgunluk ve gerileme veya emeklilik olarak ele alınır. Ürün yönetimi, bu döngünün tamamından sorumludur.

Proje yönetimi açısından kritik olan nokta, ürün yaşam döngüsünün herhangi bir aşamasında ortaya çıkan yeni ihtiyaçların projeler aracılığıyla karşılanmasıdır. Yeni bir fonksiyon geliştirmek, mevcut kapasiteyi artırmak veya bir problemi çözmek için projeler başlatılır. Proje sona erdiğinde ürün yaşamaya devam eder; ancak projenin başarısı, ürünün o evrede yarattığı iş değeri ile ölçülür.


Disiplinler Arası Bağımlılık: Büyük Resmi Görmek

PMBOK® Guide 8, portföy, program, proje ve ürün yönetimini birbirinden bağımsız yapılar olarak ele almaz. Aksine, bu disiplinlerin organizasyonel stratejiyle uyumlu şekilde birlikte çalışmasını zorunlu görür.

Ürün yönetimi ürün vizyonunu ve stratejik yönü belirler. Portföy yönetimi, hangi ürünlere ve girişimlere yatırım yapılacağına karar verir. Program ve proje yönetimi ise bu stratejik kararları somut çıktılara dönüştürür. Proje yöneticisi için bu yapı, yalnızca “ne yapılacağını” değil, “neden yapıldığını” da anlamayı mümkün kılar.


Ürün ve Proje Yönetimi Arasındaki Entegrasyon Modelleri

PMBOK® Guide 8, ürün ve proje yönetimi arasındaki ilişkiyi beş temel model üzerinden açıklar. Bazı durumlarda ürün yaşam döngüsü içinde program yönetimi ön plana çıkar ve birden fazla proje ortak bir ürün hedefi doğrultusunda koordine edilir. Bazı durumlarda ise ürün yaşam döngüsünün belirli bir aşamasında tekil projeler başlatılır.

Ürün yönetimi bazen portföy seviyesinde ele alınırken, bazen de bir program veya proje kapsamında daha dar bir odakla uygulanır. Ayrıca bir ürünün yaşam döngüsü, birden fazla program ve projeye yayıldığında disiplinler arası koordinasyon daha da kritik hale gelir. Bu modellerin tamamı, proje yöneticisinin çalıştığı bağlamı doğru okumasını gerektirir.


Strateji ile Uygulamanın Birlikte Çalışması

Ürün yönetimi ile proje yönetimi arasındaki güçlü iş birliği, başarılı sonuçların temelidir. Ürün yönetimi pazar ihtiyaçlarını ve müşteri beklentilerini tanımlarken, proje yönetimi bu stratejinin nasıl, ne zaman ve hangi kaynaklarla hayata geçirileceğini planlar.

Bu iki disiplin arasında yeterli hizalanma olmadığında, projeler zamanında ve bütçe içinde tamamlanmış olsa bile beklenen iş değeri ortaya çıkmayabilir. Entegre bir yaklaşım ise hem operasyonel verimliliği artırır hem de ürünün pazardaki başarısını destekler.


Kritik Roller: Ürün Sahibi ve İş Analisti

Ürün ve proje yönetimi arasındaki boşluğu dolduran iki önemli rol öne çıkar: Ürün Sahibi ve İş Analisti. Ürün Sahibi, ürün birikim listesini yöneterek ekibin en yüksek değeri üreten işlere odaklanmasını sağlar. İş Analisti ise iş ihtiyaçlarını analiz eder, gereksinimleri tanımlar ve belgeler.

Bu roller sayesinde proje kapsamı, organizasyonun gerçek ihtiyaçlarıyla uyumlu hale gelir ve paydaşlar arasında sürekli bir hizalanma sağlanır. PMBOK® Guide 8, bu rollerin doğru konumlandırılmasının hem ürün hem de proje başarısı için kritik olduğunu açıkça vurgular.


Sonuç: Projeler Sprinttir, Ürünler Maraton

Ürün yönetimi uzun vadeli bir yolculuktur; projeler ise bu yolculuk boyunca atılan planlı ve bilinçli adımlardır. PMBOK® Guide 8, proje yöneticilerinden artık yalnızca teslimat odaklı değil, değer ve ürün odaklı düşünmelerini beklemektedir.

Proje yöneticileri olarak teslim ettiğimiz çıktının, ürünün geleceğine ve organizasyonel stratejiye nasıl hizmet ettiğini anlamak zorundayız. Çünkü biz sadece projeleri tamamlamıyoruz; ürünlerin sürdürülebilir başarısını mümkün kılıyoruz.

18- Sprintin Detaylı İncelemesi

Bir sprint, potansiyel olarak sunulabilir bir ürün artırımının oluşturulduğu, bir ay veya daha kısa bir süreye sahip zaman kutusudur.

Sprintlerin yapısında şu mantık esastır. Önümüzdeki 1 ay içinde ne yapacağımızı düşünmek mi daha kolaydır, yoksa bütün bir sene içinde yapılacaklarınızı düşünmek mi? Tabii ki, kısa vadeli bir plan yapıp, sonucu gördükten sonrasını tekrar planlamak çok daha kolaydır. Bu sayede, planlama için ayırdığınız çaba da daha az olacaktır.

Sprintin amacı, Scrum takımının belirli bir hedefe odaklanmasını sağlamaktır. Sprintler, küçük de olsa, bir şeyi başarmak için kullanılır. Ekibin dikkatinin dağılmasına izin vermeden ve kesinti yaşamadan proje hedefine odaklanmalarını sağlar.

Bir şirkette, aynı anda yürüyen farklı projeler olduğunu varsayın. Ekip üyeleri, gün içinde bu farklı projelere dağılmış durumdayken, ortaya çıkan herhangi bir sonuç olmayacaktır. Scrum yaklaşımında, ekip üyeleri tek bir projeye odaklanır ve en azından, küçük de olsa, bir değer üretmek için çalışırlar.

Özetle, çevik yaklaşımlar, işlere başlamaktan ziyade bitirmeye odaklanır. Sprintleri çok küçük projeler olarak görebilirsiniz. Böylece, küçük zaman aralıklarında, müşterinin geri bildirimde bulunabileceği veya doğrudan kullanabileceği sonuçlar ortaya çıkarmak mümkün olacaktır.

Sprint esnasında Scrum takımı, baştan düşünmedikleri şeyleri fark edebilir. Diğer ifadeyle, Scrum Takımı, sprint hedefinin beklediklerinden daha büyük olduğunu anlarlarsa, ürün sahibi ile müzakere ederek, kapsamı azaltabilir, fakat kaliteden asla ödün veremezler. Kapsamın azalması, yeni fark edilen içeriklerin sonraki sprintlerde yapılmak üzere, ürün birikim öğesine eklenmesi anlamına gelecektir.

Benzer bir durum, Sprint süresi için de geçerlidir. Sprint süreleri, 1 aydan uzun olmayacak şekilde belirlenmelidir. Pratik uygulamada, sprint süreleri genellikle 2 hafta olarak tercih edilir. 2 haftalık döngülerle, uygulamaya konulma potansiyeli olan çıktılara ulaşmak, proje içinde bir rutin oluşturulmasını kolaylaştıracaktır.

Eğer sprint hedefinin, beklenenden daha büyük olduğu anlaşılırsa, sprint süresi uzatılmaz. Artan kapsam içeriği, sonraki sprintlere aktarılmak üzere ürün birikim öğesi olarak kaydedilir.

Sprint süresinin 2 hafta olması zorunlu değildir. Farklı sprint süreleri, proje boyunca kullanılabilir. Scrum ekibi ve ürün sahibi arasındaki müzakereler çerçevesinde, sprint süresine karar verilebilir.

Bununla birlikte, büyük bir projede farklı Scrum takımlarının, farklı sprint süreleri kullandığını düşünün. Birbirine entegre edilmesi gereken çıktıların, farklı zamanlarda üretilmesi proje ilerlemesinde düzensizlik yaratacaktır. Buna karşılık, ekiplerin ortak bir sprint süresi üzerinde anlaşarak sprintleri yürütmeleri, ekipler arasında senkronize çalışma şekli yaratacaktır.

17- Zaman Kutusu Nedir?

Scrum’da, zaman kutusu bir etkinliğin maksimum süresini ifade eder.

Örneğin, sprint planlama toplantısını ele alalım. Bu etkinlik, bir aylık sprint için 8 saate kadar zamanlanmış bir kutudur.

Scrum takımı, sprinti planlamak için tam olarak 8 saati kullanabilir. Eğer Scrum takımı toplantının amacına 6 saatte ulaşabilirse, bu çok daha iyi bir şeydir.

Hedeflenen sonuca ulaşılır ulaşılmaz sprint planalama etkinliği sona erer. Bekleyerek zaman kaybetmek için hiçbir sebep yoktur. Scrum, zaman ve kaynak israfını azaltmayı hedefler.

Scrum ekibinin zaman kutusunu aşmasına izin verilmez. Scrum ustası, Scrum Takımına zaman kutularının neden önemli olduğu ve zamanlarının nasıl daha iyi yönetileceği konusunda koçluk yapmalıdır.

Zaman kutuları neden önemlidir? Bunu bir örnekle açıklamaya çalışalım. Kısa süreliğine şehir dışına yolculuğa çıkacağınızı varsayın. 1 veya 2 gün için yapacağınız yolculuk için, hazırlık sürenizi düşünün. 1 günlük yolculuk için yanınıza alacağınız çanta küçüktür ve onu hazırlamak için yarım saat yeterli olacaktır. Buna karşılık, 1 haftalık şehir dışı yolculuğu için, bir valiz hazırlarken daha fazla zaman ayırırsınız. Çok daha uzun yolculuklar içinse bir kaç valiz hazırlamanız gerekeceğinden, hazırlık süreniz daha fazla olacaktır.

Zaman kutuları böyle çalışır. Ne kadar uzak geleceği planlamanız gerekiyorsa, ayırmanız gereken zaman da artar. Buna karşılık, planlamayla fazla zaman kaybedip, işlerin ilerlemesine de engel olmamanız gerekir. Örneğin, valizleri hazırlamaya gereğinden fazla zaman ayırırsanız, bu sefer de uçağı kaçırırsınız.

Scrum’da farklı etkinlikler için zaman kutularının olduğunu ileriki videolarımızda göreceğiz.

Özetlemek gerekirse, bir zaman kutusu bir etkinliğin minimum süresini değil, maksimum süresini ifade eder.

Her türlü etkinlik, etkinliğin amacına ulaşıldığı sürece, zaman kutusu sona ermeden sonlandırılabilir. Fakat, etkinliğin zaman kutusunu aşmasına izin verilmez.

Bu durum, sprintin kendisi hariç, tüm etkinlikler için geçerlidir. Sprint, özel bir durumdur. Planlanan işi, sprintin süresi bitmeden tamamlasanız bile, sprint daha erken bitmez. Bunun sebebi, oluşturmaya çalıştığımız rutinin bozulmasını engellemektir. Fazladan zamanınız kalmışsa eğer, ürün birikim listesinden daha fazla iş alıp, sprinte devam edersiniz. Ancak bu durum, çok nadiren görülür.

14- “Tamamlandının Tanımı” Ne Zaman Hazırlanır?

Scrum Takımı, Tamamlandının Tanımını ne zaman hazırlamalıdır? Scrum Kılavuzu bununla ilgili herhangi bir bilgi vermez, sadece bunun var olması gerektiğini ifade eder.

Bunun nedeni, Scrum’ın bir çerçeve olmasıdır. Adım adım ne yapmanız gerektiğini açıklayan bir metodoloji değildir.

Peki, bu durumda, Tamamlandının Tanımı ne zaman oluşturulmalıdır? Cevap, ne zaman isterseniz.

Çoğu zaman, insanlar her şeyin Scrum etkinliklerinden birinde olması gerektiğini düşünür ve bu doğru değildir.

Scrum Takımı, kendi içinde belirsizlikleri giderecek şekilde farklı toplantılar yapabilir. Bu, Scrum tarafından yasaklanmış değildir.

Scrum Takımının, ilk Sprint başlamadan önce Tamamlandının Tanımının ilk versiyonunu hazırlanmasında hiçbir sakınca yoktur. İlk hali, mükemmel veya nihai olmak zorunda değildir.

Zamanla ihtiyaçlar şekillendikçe veya kalite sorunları yaşandıkça, tamamlandının tanımı da gelişir. Özellikle, Retrospektif toplantılarında ekip deneyimlerini paylaşarak, Tamamlandının Tanımını iyileştirmek için önerilerde bulunabilirler.

Pratik açıdan bakıldığında, zorunlu olmadıkça, sprintin ortasında Tamamlandının Tanımını değiştirmek çok tercih edilen bir yöntem değildir. Bunu bir oyunun kurallarını oyun başladıktan sonra değiştirmek gibi düşünebilirsiniz. Kurallar, oyun başlamadan önce belirlenir. Eğer istenmeyen bir sonuç ile karşılaşılırsa, kurallar, oyun tekrar başlamadan önce oyuncular tarafından konuşulur, anlaşmaya varılır ve oyun ondan sonra başlar.

Tamamlandının Tanımını Sprint’in ortasında değiştirmek tahmin değerlerini ve tamamlandığı düşünülen işleri olumsuz etkileyebilir.

Video için Youtube kanalımı ziyaret edebilirsiniz.


Eğitimlerimiz için İstanbul Kurumsal Gelişim’in Web Sitesini Ziyaret Edebilirsiniz.


Youtube Üzerindeki Videolu Eğitimleri Buradan İnceleyebilirsiniz.


UDEMY Eğitimlerim