Tag: scrum yaklaşımı

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.

13- “Tamamlandının Tanımı” Kavramına Detaylı Bakış

Bu derste, tamamlandının tanımı ifadesine biraz daha detaylı göz atacağız. Bir önceki videomuzda “Başlangıç Sayfası Oluşturma” öğesi için kabul kriterlerini tanımlamıştık.

Burada gördüğünüz ifadeler ise “Başlangıç Sayfası Oluşturma” adlı ürün birikim öğesi için daha detaylı hazırlanmış ve kriterleri gösteren bir örnektir. Yazılanların doğruluğu veya detay seviyesi önemli değildir. Bu örnek, yazılımla ilgili olduğu için, ekranda göreceğiniz ifadeler, bazılarınız için anlamsız olabilir. Bu ifadelerin sadece bir örnek olduğunu dersimiz boyunca unutmayınız.

Öncelikle, tamamlandının tanımı bir kontrol listesi gibi görünse de, Scrum literatürü içinde kontrol listesi ifadesi kullanılmaz. Bu durumu, doktorların veya avukatların kullandığı özel kelimeler gibi düşünebilirsiniz. Her disiplinin kendine özel kavramlarının olması normaldir. Önemli olan bu kavram yapısını bilmek ve diğer meslektaşlarla aynı dili konuşabilmektir.

Konumuza dönersek; bir ürün birikim öğesinin tamamlanmış olarak kabul edilmesi için aşağıdaki kriterlere uyması gerektiği gözükmektedir.

Bu listede ilk maddeye baktığımızda “Kabul Kriterlerinde belirtilen şartların sağlanması” ifadesi gözükmektedir. Bir önceki dersimizde, bu maddeler hakkında örnekler paylaşmıştık. Bu kriterler, genellikle ürünün nasıl gözükeceğini içeren özelliklerdir. Kabul kriterlerinin neler olduğunu görmek için 12.video olan Artırım ve Tamamlandının Tanımı adlı videoyu izlemenizi tavsiye ederiz.

Şu an ekranımızda ise ürünün etkin çalışabilmesi için uyulması gereken farklı kriterlerden de bahsedilmiştir. Bu kriterler, ürün sahibinin bilemeyeceği kriterler olabilir. Bu yüzden, bu kriterler, Scrum takımı tarafından hazırlanır.

Örneğin, hazırlanan kodun, uzman bir geliştirici tarafından gözden geçirilmesi kriteri, daha sonra oluşabilecek kusurları engelleyebilir ve deneyimsiz olan geliştirme ekibinin yeni şeyler öğrenmesini sağlayabilir.

Teknik dokümanın hazırlanmış olması ifadesi, ilgili sayfanın bilgi akışı veya süreç akışını gösteren içerikler olabilir. Bu bilgiler, baştan belgelenmediği takdirde, ve sistemin zamanla büyümesi durumunda, sistemin kontrolü imkansız hâle gelebilir.

Birim testinin geçmesi, hazırlanan fonksiyonun doğru çalışıp, çalışmadığını test etmek ve onaylamak iken, kabul testinden geçmek sistemin bir bütün olarak kabul edilebilir olmasıyla ilgili testlerdir.

Sistemin farklı web tarayıcıları üzerinden test edilmesi ve o tarayıcılarda da sorunsuz çalışması bir başka kriter olarak gözükmektedir. Benzer bir değerlendirme, mobil cihazlar için uygulanabilir. Oluşturduğumuz giriş sayfasının farklı cep telefonlarının ekranlarında nasıl gözüktüğü bir kabul kriteri olabilir.

Bütün bunlara ek olarak fonksiyonel olmayan gereksinimler altında performans, uygunluk ve güvenlik gibi kriterler tanımlanabilir ve üretilen birikim öğesinin bu kriterleri de sağlayıp, sağlamadığı denetlenmiş olur.

Bütün bu kriterlerin olumlu sonuç vermesi halinde, ilgili birikim öğesi “tamamlandı” olarak kabul edilmiş olacaktır.

Müşteri veya ürün sahibi, Sprint içinde geçen süreyi ve harcanan eforu sadece istenen ürünü üretmek olarak düşünmemelidir. Karmaşık bir projede, burada örnek olarak gözüken kabul kriterlerinin sayısı onlarca olabilir. Bu yüzden, Scrum ekipleri, ortaya çıkaracakları ürün birikim öğesinin bu kriterlere uyup uymadığını test etmek zorundadır. Bir projede, ekipleri acele ettirmek, diğer ifadeyle, az zamanda çok fazla şeyi talep etmek ve ekibe baskı kurmak, kalite kriterlerinin yeterince sağlanmadan ürünün teslim edilmesine sebep olur. Bu da, ortaya çıkan ürünün kalite sorunları yaşamasına, ve ekibin düzeltmeler yapmak için tekrar tekrar ürün üzerinde çalışmasına, neden olur.

11- Sprint Kapsamı ve Sprint Hedefi

Scrum’ın en kafa karıştırıcı kısımlarından biri, sprint kapsamı ile sprint hedefi arasındaki farkı anlamaktır. Sprint hedefi sabit kalmakla beraber, sprint kapsamı müzakereye açık bir konudur. Bu dersimizde bu konuyu tüm yönleriyle ele alacağız.

Hemen basit bir örnekle konuyu netleştirmeye çalışalım. Bu hafta sonu evinizde temizlik yapmaya karar verdiğinizi varsayalım. Bu çerçevede, sprintin amacını, temiz bir yaşam alanına kavuşmak şeklinde tanımlayabiliriz. Kapsam, bu hedefe ulaşmak için yapmak istediğiniz çalışmanın ne olduğudur.- Örneğin, Elektrik süpürgesiyle yerleri tozunu almak, ardından yerleri nemli bezle silmek, çamaşırları yıkamak, camları silmek, mutfak dolaplarının içini temizlemek şeklinde detaylar oluşturulabilir. Amaç aynı kaldığı sürece sprintin kapsamı ekip tarafından müzakere edilebilir.

Hafta sonu işe giriştikten sonra, eğer belirlediğiniz kapsamın yetişmeyeceğini fark ederseniz, kapsamı daraltabilirsiniz. Örneğin, mutfak dolaplarının içini temizlemeyi bir sonraki sprint’e bırakma kararı verebilirsiniz. Bu durumda, kapsamınız biraz değişmiştir, fakat temiz bir yere ulaşma hedefinizde değişiklik olmamıştır.

Bu yüzden, sprintin bir hedefinin olması sizi odaklanmanız gereken konu üzerinde, sabit tutacaktır. Hedefe odaklandığınız takdirde, çalışma kapsamınızın içine hiç bir zaman “arabanızı temizlemek” gibi bir aktivite girmeyecektir.

Bununla birlikte, başta hiç düşünmediğiniz detaylar, bir anda karşınıza çıkabilir ve kimi zaman sprint kapsamını, hatta ürün birikim listesini etkileyebilir. Bunu da bir örnekle açıklayalım. Hafta sonu temizliğe başladınız ve oturma odasındaki resim albümlerinin tozunu alırken fark ettiniz ki, pek çok aile resmi, albümlere girmeden karışık bir biçimde büyükçe bir kutunun içinde duruyor. Resimleri tarih sırasına göre albüme dizme fikri aklınıza gelebilir. Fakat bu işi baştan hiç düşünmemiştiniz ve o hafta sonu yapılacak temizlik kapsamına dahil etmemiştiniz. İşin büyüklüğüne göre, diğer Scrum ekibinin değerlendirmesine de başvurarak bu işi mevcut sprintin kapsamına alabilir veya ürün sahibine öneride bulunup, fotoğraf albümlerinin düzenlenmesini yeni bir ürün birikim listesi öğesi olarak ekletebilirsiniz.

Sprint hedefine doğru ilerlerken kesinlikle vazgeçilmez olan kriter, kalitedir. Kapsam içinde yapılacak çalışmaların ulaşılması gereken sonuçları için kabul kriterleri tanımlanmalıdır. Kabul kriterleri hakkında detaylı bilgi sonraki videolarımızın içinde yer alacaktır. Kaliteden ödün vermeyecek şekilde ilerlemek, bazen kapsamdan feragat etmeyi gerektirebilir ve bu durum normaldir.

Bu konuyla ilgili olarak, proje yönetiminde şu iki kavram arasındaki ödünleşmeyi sürekli dikkate almak gerekir. Bir ürünün sınıfı, o ürünün içindeki özelliklerinin sayısını ifade etsin. Müşterinize yüksek sınıflı bir ürün teslim etmeye çalıştığınızı varsayalım. Fakat, sizi o kadar acele ettiriyorlar ki, bazı özelliklerin çalışıp, çalışmadığından emin olmadan, yani test etmeye zaman kalmadan, ürünü teslim ediyorsunuz. Özelliği fazla, fakat çalışıp, çalışmadığından emin olmadığınız bir ürünü, müşterinize teslim etseniz, içiniz rahat olur muydu?

Buna karşılık, özelliği az, ama en azından çalıştığından emin olduğunuz bir ürünü, müşterimize teslim etseniz içiniz daha rahat olurdu, elbette. Şunu lütfen unutmayalım; kaliteden ödün verilmediği takdirde kapsamı genişletmek çok kolaydır. Fakat kalite sorunu yaşayan bir ürün, proje ekibinin sürekli hata düzeltmek için efor ve zaman harcamasına sebep olacaktır.