Projeler Nasıl Fiyatlandırılır ve Kapsam Sürünmesi Nasıl Yönetilir

Fiyatlandırmaya sihirli bir şekilde doğru bir fiyat teklifi oluşturmanıza izin verecek bazı bilimsel yaklaşımlar olduğunu öne süren gerçekçi olmayan makaleler okuduğunuza eminim. Ayrıca kapsam kaymasından her ne pahasına olursa olsun kaçınılması gerektiğine inandırılmış olabilirsiniz, ancak gerçek dünyada bu her zaman olacaktır.

Bu saçma oyunu oynamayı bırakmanın ve projeleri kumardan daha az, daha çok sağlam ve güvenilir bir süreç gibi bir şekilde yürütmeye başlamamızın zamanı geldi.

abartıyor muyum? Olabilir ama dijital projelerde çoğu zaman işlerin nerelerde yanlış gittiğine bakalım.

Proje Sürecimizle İlgili Sorunlar

Tecrübelerime göre, herhangi bir sektördeki çoğu kuruluş projeleri yaklaşık olarak aynı şekilde yürütür:

1. Yönetimden biri bir projenin tamamlanmasını istiyor. Ne yazık ki, bu istek genellikle çıktılar açısından ayrıntılardan yoksundur ve yalnızca belirsiz hedeflere sahip olma eğilimindedir.
2. Projeyi ayrıntılı olarak tanımlamak ve kapsamına karar vermek için bir paydaş komitesi toplanır.
3. Ayrıntılı kapsam daha sonra onu inşa edecek ekibe alınır ve ne kadar süreceğini ve ne kadara mal olacağını tahmin etmeleri istenir.
4. Proje, zamanında ve bütçe dahilinde teslimatı vurgulayarak şartnameye teslim edilir. Sonuç olarak, dürbün sürüngen düşman olur.
5. Proje teslim edilir ve herkes görev listesindeki bir sonraki projeye geçer.

Bu yaklaşım, özellikle dijital projeler için ideal olmaktan uzaktır. Dijital, kullanıcı davranışı hakkında bize benzeri görülmemiş bir geri bildirim sağlar ve değişiklikleri (fiziksel ürünlere kıyasla) uygulamayı nispeten kolaylaştırır. Ancak, kapsam tanımlandıktan ve bir teklif sağlandıktan sonra proje kilitlenir ve proje ilerledikçe herkes değişiklik yapmaya isteksiz olur.

Yine de kaçınılmaz olarak, esas olarak paydaşların neyin inşa edileceğine dair farklı yorumlara sahip olmaları veya projenin ortasında kritik unsurların yanlış olduğunu fark etmeleri nedeniyle kapsam değişiyor.

Gerçekte, kapsam kaymasında yanlış bir şey yoktur . Esnek kalmak ve daha fazlasını öğrendikçe uyum sağlamak, mükemmel dijital hizmetler oluşturmanın temelidir. Sorun kapsam kaymasında değil, projeleri yürütme şeklimizde.

Ne yazık ki, teslim tarihleri ​​ve maliyetler üzerinde anlaşmaya varıldığı için, bu değişiklikleri bu kısıtlamalar dahilinde sunmaya çalışıyoruz ve bu da köşelerin kesilmesine neden oluyor.

İlk etapta zaman çizelgeleri ve maliyetler doğru değildi. Dijital projeler karmaşıktır ve genellikle uzmanların ve paydaşların birlikte çalışmasını içerir. Sonuç olarak, doğru bir şekilde tahmin etmek çok zor.

Doğru tahmin için metodolojiler öneren birçok makale okudum. Ancak, gerçek dünyada neredeyse tüm durumlarda pratik değildirler, çünkü esas olarak uygulanmaları çok zaman alır. Bir projeyi tahmin etmek sezgiye, deneyime ve eğitimli bir tahmine bağlıdır!

Herhangi bir zamanda bu alanda çalışmış olan herkesin size söyleyeceği gibi, çoğu tahmin bir kurgu eseridir . Genellikle doğru çözümün ne olduğunu veya kullanıcıların buna nasıl yanıt verebileceğini belirlemek için bile yeterince önceden bilgi sahibi değiliz. Bu nedenle, tüm bir projeyi önceden doğru bir şekilde tahmin etmek imkansızdır.

Ne yazık ki, bu belirsizlik, proje kaçınılmaz olarak son teslim tarihini kaçırdığında ve bütçeyi aştığında, genellikle suçun adaletsiz bir şekilde dağıtılmasına yol açar.

Neyse ki, doğru tahminler sağlamanın ve yürütülen projeleri değiştirmeyi içeren kapsam kaymalarını yönetmenin bir yolu var. İşin sırrı, projeleri daha küçük parçalara bölmekte yatmaktadır. Bu yaklaşım, büyük ve karmaşık projeler üstlenmekten kaçınır.

Projeleri Bir Dizi Küçük Etkileşime Bölün

Bu noktada net olmam gerekiyor. İddialı çalışma programlarının yanlış olduğunu söylemiyorum. Önemli web sitelerinde ve genişleyen iş programlarında büyük müşteriler için çalışıyorum. Ancak, bu görevleri nadiren tek bir büyük proje olarak ele alıyorum. Bunun yerine, onları birer birer kapsadığım daha yönetilebilir projelere bölüyorum.

Bir müşteri (büyük veya küçük) bir dijital projeyi üstlenmek için bana yaklaştığında, genellikle aşağıdaki sırayla gerçekleşen dört aşamaya ayırırım:

1. keşif,
2. Alfa,
3. Minimum olarak uygulanabilir bir ürün,
4. Devam eden yineleme ve optimizasyon.

Her aşama, net çıktılarla ayrı bir etkileşimdir. Bu nedenle, tüm projeye değil, sadece ilk aşamaya bağlıyım. Bu, kapsam kaymasını tahmin etmeyi ve yönetmeyi çok daha kolay hale getirir.

Örneğin, yalnızca bir sonraki aşamanın kapsamını tanımlamanız gerekir. Bu, kapsam kaymasını daha iyi yönetmenize olanak tanır, çünkü önceki aşama tamamlandıktan sonra bir sonraki aşamayı tanımlarken buna uyum sağlayabilirsiniz .

Tüm bir çalışma programını tahmin etmek yerine, o programdaki bir sonraki projeyi tahmin ediyorsunuz. Ayrıca, daha doğru bir şekilde tahmin etmenize yardımcı olması için önceki aşamayı kullanabilirsiniz.

Her aşama, keşiften başlayarak bir sonraki aşamayı tanımlamaya ve tahmin etmeye yardımcı olur.

1. Keşif

Keşif aşamasında, projeyi doğrulamak için paydaşlarla birlikte çalışıyorum. Projenin genel boyutuna bağlı olarak, bu birkaç toplantı kadar basit olabilir veya tüm bir çalışma programı olabilir.

Tipik olarak, aşağıdakiler gibi unsurları içerir:

• kullanıcı araştırması yapmak;
• rekabeti analiz etmek;
• temel performans göstergelerinin belirlenmesi;
• başarının neye benzediğini tanımlamak;
• kısıtlamaları anlamak;
• paydaş görüşlerinin bir araya getirilmesi.

Buradaki fikir, keşif aşamasının, kullanıcı ihtiyaçları, iş hedefleri ve neyin yaratılması gerektiği dahil olmak üzere projenin daha bilinçli bir tanımını sunmasıdır.

En önemlisi, projenin gerekli değeri sağlayacağını doğrulayacaktır.

Daha sonra bu çıktıyı bir alfa aşamasında gereken işi tanımlamak ve tahmin etmek için kullanabiliriz. Bunu yapmak, tahminlerimizi daha doğru hale getirir ve ayrıca öğrendiklerimize göre kapsamı ayarlar.

2. Alfa

Alfa aşaması, dijital hizmetin (ister bir web uygulaması ister site olsun) nasıl çalışacağını tanımladığımız ve kullanıcıların bunu kullanırken olumlu bir deneyim yaşamasını sağladığımız aşamadır.

Bu genellikle bir prototipin oluşturulması yoluyla yapılır. Daha küçük projelerde bu, bazı tasarım modellerinden başka bir şey olmayabilir. Daha büyük projelerde, insanların deneyebileceği işlevsel bir prototip olabilir.

Durum ne olursa olsun, fikir, oluşturduğunuz dijital hizmeti görselleştirmektir.

Bunu üç nedenden dolayı yapıyoruz.

• İlk olarak, bir görselleştirme, tüm paydaşların yarattığınız şey hakkında ortak bir vizyona sahip olmasını sağlayacaktır . Bir belge birçok farklı şekilde yorumlanabilir, ancak bunu bir prototiple yapmak çok daha zordur.
• İkincisi, bir prototip, gözden kaçmış olabilecek herhangi bir şeyi tanımlamayı çok daha kolay hale getirecek, böylece ele alınması daha pahalı olduğunda kapsamın daha da aşağılara kaymasını önleyecektir.
• Son olarak, somut bir şeyimiz varsa, gerçek şeyi inşa etme pahasına gitmeden önce amaca uygun olduğundan emin olmak için kullanıcılarla test edebiliriz .

Kötü test edilirse, bir sonraki aşamadan önce bütçeyi bozmadan veya zaman çizelgesini bozmadan uyum sağlamak için hala yerimiz var.

Keşif aşamasında olduğu gibi, bir sonraki aşamada gereken işi tahmin etmek için alfayı kullanabiliriz. Neyin inşa edilmesi gerektiğine dair bir görselleştirmeye sahip olmak, ilgili tüm paydaşlar için gereken işi tahmin etmeyi çok daha kolay hale getirir. Ne inşa etmeleri istendiğini görebilirler.

Ek olarak, oluşturacağımız şeyi uyarlamak için alfa testinden öğrenilen dersleri kullanabilir, bir kez daha projeyi rayından çıkarmadan kapsamdaki değişiklikler için alan yaratabiliriz.

Alfaya sahip olduğumuzda, doğru olanı yaratacağımızı ve kullanıcıların buna olumlu yanıt vereceğini bilerek, güvenle yapıya geçebiliriz.

3. Asgari Uygulanabilir Ürün

Bu aşamaya "inşa" adını verirdim. Ancak, paydaşların yapıyı bitirmeyi projeyi tamamlamakla ilişkilendirdiğini gördüm. Gerçekte, mümkün olduğunca etkili olmalarını sağlamak için sürekli olarak yinelenmeleri gerektiğinden, dijital hizmetler asla yapılmaz.

Bu sorunu önlemek için bu aşamayı minimum geçerli ürün (MVP) olarak adlandırmaya başladım. Bu aşamada, dijital hizmetin ilk sürümünü oluşturuyor ve kullanıma sunuyoruz.

Minimum uygulanabilir ürün olarak bahsederek, lansman sonrası bir yineleme olacağını vurguluyoruz. Bu bize, lansman sonrasına kadar geri iterek kapsam kayması ve beklenmeyen karmaşıklıkla başa çıkmanın bir yolunu sağlar. Bu, projenin yolunda kalmasını ve ivmesini korumasını sağlar.

Kaçınılmaz olarak yapım sırasında bazı şeyleri lansman sonrasına kadar rafa kaldıracağız. Bu unsurlar daha sonra son aşamamızı tanımlamanın temeli haline gelir ve lansman sonrası optimizasyon için bir ilk tahmin yapmamızı sağlar.

4. Devam Eden Yineleme ve Optimizasyon

Lansman sonrası aşama, MVP'de ele almadığımız işlevsellik, karmaşıklık ve diğer sorunlarla ilgilenir. Bu iyileştirmeler listesinin kapsamı bu noktada nispeten kolaydır ve makul bir doğrulukla tahmin edilebilir.

Ancak, bu çalışmaya ek olarak, dijital hizmetlerin etkinliğini daha da iyileştiren sürekli bir izleme, yineleme ve test süreci olmalıdır.

Bu işin ne kadarını üstleneceğinizi tahmin etmek, dijital hizmetin boyutuna ve karmaşıklığına dayalı olmalıdır. Tahmininiz, projenin geri kalanına yapılan yatırımla da orantılı olmalıdır.

Projelerinizi bu dört aşamaya ayırarak ve her birini ayrı ayrı tamamlayarak, geleneksel proje yönetimi yaklaşımlarını kullanırken karşılaştığımız birçok zorluğu ortadan kaldıracaksınız.

Projeleri Yıkmak Neden İşe Yarar?

Projeleri bu şekilde parçalamanın dört önemli faydası vardır:

• Her aşama daha iyi tanımlanmıştır .
  Bir önceki aşamanın çıktıları her aşamayı tanımladığı için, net bir yön vizyonu olduğu anlamına gelir. Bu, paydaşların işlerin nereye gittiğini anlamasına yardımcı olur ve daha sonra kötü sürprizlerden kaçınır.
• Projeler daha doğru tahmin edilir .
  Örneğin, önemli sayıda bilinmeyene sahip önemli, belirsiz bir projeyi teslim etmenin ne kadar süreceğini tahmin etmek zorunda kalmak yerine, yalnızca bir sonraki aşamayı tahmin ediyor ve bunu önceki aşamanın çıktılarına dayanarak yapıyorsunuz.
• Daha iyi dijital hizmetlerle sonuçlanır .
  Proje fikirleri kullanıcılarla doğrulanıp test edildiğinden, nihai ürünün amaca uygun olacağından daha emin olabilirsiniz. Ayrıca, mümkün olan en iyi sonucu vermenizi sağlamak için kapsamı ve işlevselliği aşamalar arasında uyarlamaya olanak tanır.
• Daha az riskli bir yaklaşımdır .
  Dijital hizmeti devreye alan şirketin tüm projeyi önceden taahhüt etmesi gerekmez. Keşif aşaması projenin uygulanabilirliğini doğrulamakta başarısız olursa, küçük bir kayıpla projeden vazgeçilebilir. Aynı şekilde, alfa prototipi kullanıcılar tarafından iyi test edilmezse, işler çok pahalı hale gelmeden uyarlanabilir.

Bu son nokta, ilk kez bir dış tedarikçi kullanılıyorsa güven vericidir. Müşteri, teslim edip etmeyeceklerini bilmeden önemli bir proje için bir acenteye kaydolmak yerine, nasıl olduklarını görmek için onları bir keşif aşamasına dahil edebilir. Eğer iyilerse, onlarla çalışmaya devam edebilirler. Değilse, hiçbir şey kaybetmeden bulguları başka bir kuruma götürebilirler.

Bir ajans işletiyorsanız veya serbest çalışıyorsanız, bunun kulağa kötü bir fikir gibi geldiğini düşünebilirsiniz. Anlaşılır bir şekilde, tüm proje için bir müşteri kaydetmeyi tercih edersiniz. Ancak, müşteri bu kadar küçük bir başlangıç ​​yatırımı için risk aldıklarını hissetmediği için bu yaklaşımla birçok rekabetçi ihaleden kaçındım. Ayrıca çeşitli tedarikçilerle görüşme ihtiyacı da hissetmediler çünkü benden hoşlanmazlarsa kolayca geçiş yapabilirlerdi.

Ayrıca, bu aşamalı yaklaşımı kullanmak, bir sonraki sabit fiyatlı projenizin kapsamını belirlemeyi ve fiyatlandırmayı çok daha kolay hale getirecektir. Elbette, sihirli bir şekilde bir tahmin sağlamaz veya kapsam kaymasını önlemez. Bununla birlikte, bir seferde yalnızca bir parçanın kapsamını belirlediğiniz için tahmin etmeyi daha yönetilebilir hale getirecektir. Ayrıca, onu bastırmaya çalışmak yerine kapsam kayması ile çalışmanıza izin verecektir.

Bu yüzden benim tavsiyem, ister kurum içinde ister dışarıda, ister büyük ister küçük sahalarda çalışıyor olun, projeleri aşamalara ayırmadan tahmin etmeye ve kapsamlaştırmaya çalışmaktan vazgeçmenizdir. Bunun yerine, her seferinde bir aşamayı ele alın ve öğrendiklerinizi bir sonraki aşamayı bilgilendirmek için kullanın . Bunu yaparsanız, daha doğru bir tahminde bulunacak, öğrendiklerinize dayalı olarak uyum sağlamak için yeriniz olacak ve proje yönetiminin daha kolay olduğunu göreceksiniz.