30 saniyede özet

Proje belirli bir değişimi gerçekleştirir ve tamamlanır. Ürün, bir kullanıcı veya müşteri ihtiyacını karşılayan çözüm olarak yaşam döngüsü boyunca yönetilir. Operasyon, hizmetin günlük olarak güvenilir biçimde sürmesini sağlar. Yeni abonelik altyapısına geçiş proje, abonelik yönetimi çözümü ürün, faturaların düzenli oluşturulması operasyondur. Aynı ekip bu çalışmaların tümüne katılabilir; yine de hedefleri, kararları ve başarı ölçütleri farklıdır. Ayrımın amacı organizasyona yeni kutular eklemek değildir. Hangi sorumluluğun ne zaman biteceğini, hangisinin devam edeceğini ve hangi sonucun kim tarafından izleneceğini açıklamaktır.

Neden önemli?

Bir sistem zamanında yayımlanabilir, fakat kullanıcıların işini kolaylaştırmayabilir. Proje ekibi teslimatı tamamlayıp başka işe geçtiğinde kullanım sorunları ortada kalabilir. Operasyon ekibi sistemi ayakta tutar; ancak kullanıcı deneyimini veya ticari etkisini geliştirme yetkisine sahip olmayabilir. Ürün sorumluluğu tanımlanmamışsa, çalışan bir sistemin neden yeterli değer üretmediği sahipsiz bir soruya dönüşür.

Tersi de mümkündür. Sürekli geliştirme yapan bir ürün ekibi, eski sistemden zorunlu geçiş gibi tamamlanması gereken bir çalışmayı belirsiz süreyle sürdürebilir. İşletim ekipleri günlük sorunlara yetişirken kalıcı iyileştirmeleri erteleyebilir. Bu durumlarda yalnızca daha fazla çalışan atamak yeterli olmaz. Önce işin hangi yönetim yaklaşımını gerektirdiği ve neyin öncelikli olduğu belirlenmelidir.

Üst yönetim açısından ayrım, kaynak kararlarını daha anlaşılır hale getirir. Geçiş için ayrılan bütçe belirli bir değişimi finanse eder. Ürün kapasitesi, müşteri ihtiyacına göre devam eden geliştirmeyi destekler. Operasyon kapasitesi ise hizmetin sürekliliğini korur. Bunları tek kalemde düşünmek, zorunlu işletim yükünün yeni yatırım kapasitesi sanılmasına veya ürünün bakım ihtiyacının unutulmasına yol açabilir.

Terim nedir?

Proje, kendine özgü bir sonuç üretmek için yürütülen geçici çalışmadır. Geçici olması, kısa sürmesini gerektirmez. Tanımlı bir tamamlanma noktasının bulunması gerekir. Eski müşteri kayıtlarının yeni sisteme aktarılması, veri doğruluğunun kontrol edilmesi ve eski sistemin kapatılması bu tür bir çalışmadır. Kapsam ve kabul ölçütleri, hangi koşullarda tamamlandığını gösterir.

Ürün, belirli bir ihtiyacı karşılayan mal, hizmet veya dijital çözüm olabilir. Yalnızca dış müşterilere satılan yazılımlar ürün değildir; çalışanların kullandığı iç çözümler de ürün olarak yönetilebilir. Ürün yönetimi, kimin hangi sorununu çözmeye odaklanılacağını ve çözümün nasıl gelişeceğini belirler. Ürün sonsuza kadar yaşamak zorunda değildir; başlatılması, geliştirilmesi ve gerektiğinde sonlandırılması yaşam döngüsünün parçalarıdır.

Operasyon, tekrar eden işlerle hizmetin devamlılığını sağlar. Ödeme işlemlerini izlemek, destek taleplerini karşılamak ve günlük üretimi yürütmek buna örnektir. Operasyonda da iyileştirme ve öğrenme vardır. Ayrım, operasyonun değişmediği anlamına gelmez. Sürekli işletim ile belirli bir değişimi hayata geçiren sınırlı çalışmanın farklı sorumluluklar taşıdığını anlatır.

Bu kavramlar tamamen aynı düzlemde değildir. Ürün, değer sunan çözümü; proje, sınırlı bir değişimi gerçekleştirme biçimini; operasyon ise sürekli işletimi anlatır. Dolayısıyla bir ürünün içinde projeler yürütülebilir ve ürünün işletimi operasyon gerektirebilir. Ürün ekibi ayrıca her geliştirmeyi ayrı proje haline getirmeden düzenli iyileştirmeler yapabilir. Ayrım, bu ilişkileri birlikte görmeyi gerektirir.

Proje Yönetim Ofisi, kısaca PMO, kurumun bu ilişkiler için uygun planlama ve kontrol yaklaşımını oluşturmasına yardımcı olabilir. Geçiş projesinde tamamlanma koşullarını, ürün çalışmalarında hedeflenen etkileri, operasyonda hizmet sürekliliğini görünür kılar. Bunların koordinasyonu önemlidir; fakat aynı raporu her çalışmaya uygulamak anlamlı karşılaştırma sağlamaz.

Gerçek vaka: Salesforce Business Technology'nin ürün modeline geçişi

PwC'nin 14 Ekim 2024 tarihli vaka anlatımı, Salesforce'un iç teknoloji organizasyonu Business Technology'nin çalışma modelini ele alıyor. Önceki yaklaşımda çalışanlar ihtiyaç ortaya çıktıkça projeler etrafında bir araya getiriliyordu. Kaynak, bu yapının talepleri önceliklendirmeyi ve farklı işlevler arasında birlikte çalışmayı zorlaştırdığını belirtiyor.

Yeni modelde iş ihtiyaçlarıyla hizalanmış, önceden belirlenmiş ekipler üzerinden ürün odaklı çalışma benimsendi. Roller netleştirildi ve organizasyon yapısı bu yaklaşıma göre düzenlendi. PwC, dönüşümün işbirliğini ve operasyonel verimliliği geliştirdiğini bildiriyor.

Bu vakadan çıkarılabilecek ders, ürün odaklı çalışmanın yalnızca geliştirme toplantılarını değiştirmekle sınırlı olmadığıdır. İşin kim tarafından sahiplenildiği ve ekiplerin nasıl oluşturulduğu da önemlidir. Ancak kaynak, projelerin tamamen kaldırıldığını söylemiyor. Burada da böyle bir sonuç çıkarılmamalıdır. Vaka, dönüşümde görev alan danışmanlık şirketinin anlatımıdır; bildirilen sonuçları bağımsız bir değerlendirme gibi sunmak doğru olmaz.

Kaynak: PwC, Salesforce reinvents its business technology group with a customer-centric approach, 14 Ekim 2024.

Varsayımsal örnek: Abonelik ve faturalandırma sistemi

Abonelikle yazılım sunan bir şirketin eski faturalandırma altyapısını değiştireceğini düşünelim. Yeni altyapıya müşteri sözleşmelerinin taşınması, hesaplamaların kontrol edilmesi ve eski sistemin kapatılması proje olarak ele alınır. Projenin tamamlanması için teknik geçişin yanında finans ekibinin doğrulaması ve işletim sorumluluklarının kabulü de gerekir.

Müşterilerin paket seçmesi, aboneliğini değiştirmesi ve faturasını anlaması ise devam eden ürün alanıdır. Ürün ekibi kullanıcıların nerede zorlandığını araştırır, çözüm seçeneklerini değerlendirir ve iyileştirmelerin etkisini izler. Başarı yalnızca yeni ekranların yayımlanmasıyla açıklanamaz. Kullanıcıların işlemlerini tamamlayabilmesi gibi sonuçlara da bakılır.

Faturaların oluşturulması, başarısız ödeme işlemlerinin incelenmesi ve müşteri taleplerinin karşılanması operasyondur. Hizmet seviyesi anlaşması, beklenen hizmet koşullarını tanımlar; örneğin kritik sorunlara yanıt yaklaşımını açıklayabilir. Bu örnekte herhangi bir süre veya başarı oranı varsayılmamıştır. Hedefler şirketin ihtiyacına göre belirlenmelidir.

Geçiş sırasında kayıt aktarımı tamamlandığı halde tutarsız faturalar görülürse proje kabulü etkilenebilir. Geçişten sonra müşterilerin paket değişiminde zorlanması ürün iyileştirmesi gerektirebilir. Günlük bir ödeme kesintisi ise operasyonel müdahale ister. Aynı çözüm çevresinde oluşan bu işler, neden farklı sahiplik ve karar yollarına ihtiyaç olduğunu gösterir.

Yaygın üç hata

  1. Her geliştirmeyi ayrı proje olarak yönetmek

Küçük ürün iyileştirmeleri için sürekli ekip kurup dağıtmak, bilgi kaybına ve hazırlık yüküne yol açabilir. Önce kalıcı bir ürün sorumluluğunun gerekli olup olmadığı değerlendirilmelidir. Sınırlı değişim için proje yaklaşımı kullanılabilir; sürekli gelişen ihtiyacın her seferinde yeniden sahiplenilmesi beklenmemelidir.

  1. Yayını bütün sorumlulukların bittiği nokta saymak

Yayına çıkmak önemli bir teslimattır. Yine de destek, kullanım takibi ve fayda ölçümü devam eder. Proje kapanmadan önce sonucu kimin işleteceği, hangi açık işlerin kime aktarılacağı ve ürün etkisini kimin izleyeceği kararlaştırılmalıdır. Devir, yalnızca doküman göndermekle tamamlanmış sayılmamalıdır.

  1. Başarıyı tek ölçütle değerlendirmek

Takvim ve bütçe proje kontrolünde önemlidir; fakat ürünün müşteri ihtiyacını karşıladığını tek başına kanıtlamaz. Hizmetin erişilebilir olması da kullanıcıların ondan yararlandığını göstermez. Ortak iş hedefinin yanında her çalışma biçimine uygun ölçütler belirlenmeli ve bunların birbirini nasıl etkilediği açıklanmalıdır.

Mini uygulama: İş ve sorumluluk ayrımı şablonu

Tek bir girişim seçin ve içindeki işleri aşağıdaki sorularla değerlendirin. Girişimin tamamına tek etiket koymak yerine, gerektiğinde geçiş, geliştirme ve işletim işlerini ayrı ele alın.

İhtiyaç
Hangi kullanıcı veya iş sorunu ele alınıyor?
Sınırlı değişim
Tamamlandığında kapanabilecek hangi çalışma var?
Sürekli gelişim
Hangi ihtiyaç için ürün sorumluluğu devam edecek?
İşletim
Hizmetin sürmesi için hangi tekrar eden işler gerekiyor?
Sahiplik
Her çalışma ve sonucu için sorumlu kim?
Ölçüm
Teslimat, kullanıcı etkisi ve hizmet sürekliliği nasıl izlenecek?
Kapasite
Günlük işletimden sonra geliştirme için ne kadar zaman kalıyor?
Devir
Bilgi, erişim ve açık işler hangi koşullarda aktarılacak?

Son olarak proje kapanışından sonraki dönemi tartışın. Kullanıcı sorunları veya işletim giderleri arttığında kimin inceleme başlatacağı belli mi? Bu soru cevapsızsa, plan yalnızca teslimata odaklanmış olabilir. Sorumlulukların sürekliliğini açıklamak, yönetim modelinin işe yarayıp yaramadığını sınamak için pratik bir başlangıçtır.

İlgili terimler

Proje, Ürün Yönetimi, Project Management Office, Proje Yaşam Döngüsü, Product Lifecycle ve Sunset, Benefits Realization Management, Product Operations, Resource Capacity Planning, Project Governance, Outcome ve Output