Müzakere Teknikleri

Hepimiz her gün iletişim halindeyiz. İletişim bir parçası da müzakere, tam da bu noktada farklı teknikler bulunuyor. Bunları uygulayarak avantajlı duruma geçmek mümkün. Ya da bu tekniklerin size uygunlandığını fark edip, doğru yanıtı vererek avantajlı hale gelmek de mümkün J Tabi yolunda giden ve üzerinde görüşülen konuda yoğunlaşılmış iletişimlerde bunları kullanmanın anlamı yok. Şimdi bunlara yakından bakalım:

•  Açık Artırma: Sizin sahip olduğunuz bir şeye birden fazla talip varsa, bunları aynı ortamda bir araya getirmek rekabet yaratacaktır. Resmi olmasa bir açık artırma ortamı yaratmış olursunuz. Rekabete konu olan şeyden ziyade rekabeti kazanma dürtüsü harekete geçecektir. Bu da sizin yararınıza olacaktır J
•  Tek Seçenek: Karşı tarafı sunulan tekliften başka alternatif olmadığını ikna etmeye dayanır. Çokça duyduğumuz “abi elimde bu son kaldı, başka yok” veya “bu civarda başka bulamazsın” buna güzel örneklerdir.
• Umacı: Burada karşı tarafın sunduğu küçük bir pürüz büyütülüp, görüşme sonunda daha ciddi bir imtiyaz koparmak için kullanılır.
• Blöf: bunu anlatmaya gerek yok sanırım J
• Çok Katmanlı Karar: Karşı tarafın sunduğu teklifi kendi tarafınızda daha üst düzey bir yetkili ile paylaşma ve ondan gelen gelen yeni imtiyaz talebini ileterek yeni avantajlar sağlamaya dayanır. Tipik örnek “eşime bir sorayım” J
• Zaman Sınırı: Karşı tarafa zaman limiti vererek karar vermeye zorlamaya dayanır.  Örneğin “kampanyanın bitiş tarihi Salı, sonra bunlara zam gelecek” J
• Kaçınma: Sunulan bir teklife fiziksel olarak olumsuz tepki vermeye dayanır. Örneğin mimiklerle veya nefes vererek. Bu şekilde teklifin absürt olduğu hissettirilir. Karşı taraf teklifini revize etme ihtiyacı hisseder J
• İyi Adam / Kötü Adam: karşı taraftla müzakerede, bir kişinin zor talepler ortaya koyması, sert davranması, diğerinin makul görünmesi, uzlaşmaya yakın durmasına dayanır. Bu taktik, “iyi polis/kötü polis” olarak da bilinir.
• Yüksek Top / Düşük Top: Satan veya alan konumuna göre değişir. Eğer alan tarftaysanız, çok düşük bir teklif sunulur, eğer satan taraftaysanız fiyatı yüksek tutarsınız. Bu şekilde karşı tarafın durumunu teklife göre ayarlamasını beklersiniz. Bunun bir riski var, sunduğunuz teklif karşı tarafa müzakerenin boşa zaman harcandığını düşündürebilir ve müzakereden vazgeçebilir.
• Kemirme: Müzakerenin sonunda ek birkaç şey daha istemeye dayanır. Karşı taraf biran önce sonuçlanmasını istiyorsa, buna hayır demeyecektir.
• Bilgiye Boğma: Karşı taraf eğer müzakere edilen konuda uzman değilse, onu teknik bilgiye boğarak anlaşma noktasına getirmek ve yönlendirmek mümkündür.

Geniş Açıdan Proje Yaşam Döngüsü

Bu makalede proje yaşam döngüsünü ele alacağız. Özellikle birden fazla proje potansiyeli olan iş yerlerinde proje seçiminden başlayıp, proje tamamlandıktan sonra hedeflenen sonucun ortaya çıkıp çıkmadığını belirleyene kadar proje yaşam döngüsü devam edecektir.

Projeler nasıl ortaya çıkar? Elbette bir fikirle J Fikir geliştirilip potansiyel bir proje haline geldiğinde, gerçek bir proje yapılıp yapılmaması gerektiğini belirlemek gerekecektir. Bu amaçla, proje çerçevesini ortaya koymak, ön analiz hazırlamak, varsayım ve kısıtları belirlemek gerekecektir. Ön analizden sonra sıra projelerin maliyetlerini çıkarmaya ve getirilerini belirlemeye gelecektir. Bu amaçla fizibilite çalışması hazırlanacaktır. Fibilite çalışmasını ülkemiz şirketlerinde pek bulunmayan ancak aslında olması gereken Kurumiçi Finansman (Controlling) bölümünce bağımsız olarak hazırlaması gerekmektedir. İşi talep eden birimin hazırlaması tarafsız olmasını önleyebilir. Projenin yasal zorunluluk sebebiyle yapılması veya pazarda stratejik avantaj sağlayacak  olması durumunda buna ilişkin bilgiler de belirtilmelidir.

Ön hazırlıkları tamamlanan projeler üst yönetimin oluşturduğu Projeler Yönetim Kurulu’nun önüne gelmelidir. Bu kurul tüm projeleri, fizibilitelerini ele alıp inceleyerek tüm projeler içinde önceliklendirme yapması gerekmektedir. Bu çalışma Masterplan’ın çatısını oluşturur. Masterplan’da kurum için öncelikli işlere kaynak ayrılarak projeleri açılır. Projelerin kendi içlerindeki izleme ve kontrol çalışmalarının yanında, Masterplan da takip edilerek üst yönetimin projelerin gidişatını ortalama 2 haftalık peryotlarla izlemesi ve oluşan sıkıntılara müdahele etmesi gerekmektedir. Tamamlanan projelerin ürün sahibi birimlere devri yapılmalıdır.

Proje Yönetim Kurulu, proje kapansa bile ürün sahibi bölümlerin proje sonrası faaliyetlerini takip eder, proje sonucu oluşan ürün veya hizmetin fizibilitede belirlenen katkıyı sağlayıp sağlamadığı izlenmeye devam edilir. Ülkemizde, maalesef bu kısım atlanır. Yapılan proje yatırımının ne kattığı yeterince irdelenmez.

Risk Yanıtlama Stratejileri

Bu makalede riskin tanımını yapmayacağız, tanım için Risk Türleri makalesini inceleyebilirsiniz. Elimizde listelenmiş bir risk listesi (register) var, peki bu riskleri nasıl yanıtlayacağız. Risk yanıtlarını planlamak risk yönetiminin bir parçası. Tehdit ve fırsatları yanıtlama yolları elbette birbirinden farklı. Tehditler için temel olarak üç yol bulunuyor, bunlar:

1. Kaçınma (avoid): Riskten kaçınma, riskin oluşmasını engelleme olarak açıklayabiliriz.
2. Transfer (transfer): Riski başkasına transfer etme, riskin yönetimini başkasına bırakma olarak düşünebiliriz.
3. Etkisini Azaltma (mitigate): Riskin etkisini azaltmak için yapılacakları belirleme ve uygulama yoluyla olası negatif etkilerinden en az zararla kurtulma olarak değerlendirebilirsiniz.

Fırsatlar için de temel olarak üç yol bulunuyor, bunlar:

1. Kamçılama (exploit): Riski kamçılayarak riskin olası faydaların en fazla yararlanma yolunu aramadır.
2. Paylaşma (share): Riski paylaşarak oluşma olasılığını ve sonuçta elde edilecek faydayı artırmadır.
3. Geliştirme (enhance): Riskin etkisi artırma yoluyla sonuçta elde edilecek faydayı artırmadır.

Hem fırsat hem de tehditler için kullanılabilecek ortak bir yol da kabullenme (accept) olarak adlandırılıyor. Kabullendiğiniz zaman riski bilip olası etkilerini sineye çekmeye hazır oluyorsunuz J

Her bir risk için yanıtlama stratejinizi belirledikten sonra taktiksel seviyedeki planınızı yaparak stratejinizi nasıl uygulayacağınıza karar vermeniz gerekiyor.

Risk Türleri

Riskin tanımını birçok yerde görmüş olabilirsiniz. Tekrarlamak gerekirse risk, pozitif veya negatif sonucu olan belirsiz olay veya durum. Risk deyince çoğu zaman negatif olasılıklar düşünülür. Aslında pozitif olasılıklar da risktir J Riskin iki boyutu vardır: olasılık ve etki. Bunları çarpınca riskin olası etkisi ortaya çıkar. Elbette tüm riskleri matematiksel olarak olasılık ve etki yönünden değerlendirmek mümkün olmayabilir. Riskin negatif olanına “tehdit” deriz, pozitif olanına ise “fırsat” deriz. Riskin en önemli özelliği gerçekleşmemiş olmasıdır. Eğer gerçekleşirse risk olmaktan çıkar. Tehdit gerçekleşirse sorun (issue, problem) haline gelir, fırsat gerçekleşirse fayda (benefit) haline gelir.

Tespit edilen riskler için risk karşılama planı (risk response plan) yapılır. Her bir riskin sahibi belirlenir (risk owner). Riskle ilgili niteliksel (qualitative) ve niceliksel (quantitative) analiz yapılır. Niteliksel risk analizi risk seviyesinde yapılır. Niceliksel risk analizi ise proje seviyesinde yapılır, riskin olası tüm proje üzerindeki etkileri belirlenir.

Bir risk için hazırladığınız karşılama planı yeni risk doğuruyorsa buna “ikincil risk (secondary risk)” denir.

Risksiz proje olmaz J Hatta projeler için ortak riskler vardır, projenizde riskleri tespit etmekte zorlanıyorsanız, bunlardan başlamak işinize yarayabilir.

Düzeltici ve Önleyici Faaliyet

Örnekle başlamak istiyorum bugün, hatta kışın çok oluşan bir durum: İlk senaryomuzda kışın yerler kar buz, arabayla gidiyoruz yaz lastikleri takılı halde, önümüze bir başka araba çıktı, frene bastık ve doğal olarak duramadık çarptık. Arabayı tamir ettirdik ve eski haline geldi. İkinci senaryomuzda kışlık lastiklerimiz takılı vaziyette seyrediyoruz, aynı durum yaşandı frene bastık ve durduk, kaza olmadı. Bunlardan hangisi düzeltici hangisi önleyici faaliyettir? Cevap açık değil mi. Hangisi daha akılcı ve az maliyetli? Bunun da cevabı açık.

Projelerde bu tür durumlarla çokça karşılaşıyoruz. Maalesef projelerde düzeltici faaliyetlerle ağırlık kazanıyor. Düzeltici faaliyet ile re-aktif davranırsınız, istenmeyen durum oluşur siz de çözmeye çalışırsınız. Önleyici faaliyet ise pro-aktiftir, istenmeyen durumun oluşmasına fırsat vermezsiniz.

Her iki faaliyet de istenmeyen durumun analiz edilmesiyle, problemin sebebinin ortaya konulması ve çözülmesiyle sonuca ulaşır. Farkları ilkinde durum oluştuktan sonra çözüm aranır, ikincisinde potansiyel soruna çözüm aranır. Üretim süreçlerinde bu konu oldukça ciddi ele alınır, proje yönetiminde ise henüz hakettiği karşılığı bulamamıştır.

Bu arada her ikisinde de sorun çözülür ama maliyeti farklı olur. Maliyet farkı bazen dramatik olabilir. Seçim sizin J

Altın Kaplama (Gold Plating)

İlginç bir konumuz var bugün dostlar: altın kaplama. Metal endüstrisinde bir terim olsa da proje yönetiminde de kullanılan bir terimdir. Özet olarak proje kapsamında yer almayan, talep edilmemiş bir özelliğin proje çıktısı ürüne eklenmesidir. İstenmeyen bir özellikse neden yapılıyor diye sorarsanız, alttaki sebepler fikir verebilir:

• Bu özelliğin harika bir fikir olduğunu düşünen ekip üye(ler)inin olması
•  Bu özelliğin temel olarak zaten yapılması gerektiğini düşünen ekip üye(ler)inin olması
• Bu özelliği ekleyerek yöneticisine/müşteriye kendini ispatlamaya çalışan ekip üye(ler)inin olması
• Bu özelliği eklemeye yetecek boş vakti olan ekip üye(ler)inin olması
• Bu özelliği ekleyerek dikkatleri var olan hatalardan uzaklaştırmak isteyen ekip üye(ler)inin olması

Peki altın kaplama yapıldı, sonuçları ne olur:

• Proje maliyeti yükselir. Ne yazık ki gelir aynı oranda yükselmez J
•  Kapsam enflasyonu yaratır, istenen ve istenmeyen kapsamlar birbirine karışır.
• Beklendiği gibi risk artar.
• Müşterinin memnuniyet çıtası yükselebilir, başka özellikler de istemesinin önü açılır. Ya da tam tersi olur, müşteri memnun olmayabilir ve yapılanları istemez. Çalışma boşa gidebilir.

Altın kaplama projeler için iyi bir yaklaşım değildir, kaçınmak gerekir. Özellikle proje yöneticilerinin bu konuda dikkatli olmaları ve belirlenen kapsam ile yapılan işin uyumunu yakından izlemeleri gerekmektedir.

Projelerde Başarı Etkenleri

Değerli dostlar, uzun bir aradan sonra yeni bir yazıyla karşınızdayım. Kimi projeler başarılı olurken kimileri de başarız oluyor. Başarılılar neden başarılı diye bakıldığı zaman başarıya giden yolda bazı etkenlerin olduğu ortaya çıkıyor. Hepimizin ayrı ayrı başarı etkenleri tespitlerimiz olmuştur. Tüm projeler için bakıldığında alttaki resim ortaya çıkıyor:

• Üst yönetim desteği: Bu olmadan başarı varsa mucize yaşanmıştır J Üst yönetim desteği birkaç noktada özellikle gereklidir, ilki kaynakları verme. İnsan veya makine ilgili kaynakları projeye tahsis etmeden zaten proje yapılamaz. Bir diğeri zamanında gerekli onayları verme ve kararları alma. Onay ve kararlar olmadan projenin yol bulması mümkün değildir. Bir diğeri de kurum içi iletişimi sağlamadır.
• Kullanıcı (müşteri) katılımı: Burada önemli nokta projeyi yaptıran müşterinin ve kullanacak kişilerin ayrı ayrı mutlaka katılımı. Eğer kullanacak kişi olmazsa, yapılan ürün işe yaramayacaktır.
• Deneyimli proje yöneticisi ve üzerinde düşünülmüş bir proje yönetimi metodolojisi J
• Net hedefler: Bunu açıklamaya gerek yok sanırım.
• Standartlaşmış süreçler: Standartlaşmış ve hatta rafine edilmiş süreçler tekrarlanabilir başarının yolunu açıyor.
• Temel beklentileri sabitlemek: Bütün paydaşların temel beklentilerde uzlaşması ve aynı şeyleri bekliyor olmaları projenin yoldan çıkma riskini azaltacaktır.

McCabe Metriği

McCabe Metriği (Cyclomatic Complexity), bir yazılımdaki birbirinden lineer olarak bağımsız olan yolların sayısıdır. Bu şekilde ne kadar çok yol olursa o kadar çok hata riski vardır. Dolayısıyla lineer bağımsız yolların sayısını azaltmak hem yazılımın karmaşıklığını hem de hata riskini azaltır.

Satın Almada Önemli Noktalar

Günlük hayatımızda hemen her gün satın alma sürecinden geçeriz. Kimi zaman ekmek, kimi zaman ev, kimi zaman da başka bir kişisel ihtiyaç... Sadece bizler değil kurumlar da satın alma yaparlar. Hatta satın almayla ilgili her kurumun kendine özgü yaklaşımı vardır. Dahası bazı şirketlerde bu konuya özel büyük bölümler bile kurulmuştur. Satın alma süreçlerinde işinize yarayabilecek bazı ipuçlarını paylaşmak isterim:

• Satın alacağınız ürünün özelliklerini öyle belirleyin ki hem net olarak ne istediğiniz belli olsun ve gelen teklifler karşılaştırılabilsin; hem de ürünü satan firmaların ihtiyaca yönelik daha iyi çözümlerine açık olsun ve daha akılcı çözümlerin size ulaşamadan elenmesinin önüne geçebilin. Örneğin “elma” satın almak istiyorsanız, bunu yazın ama size farklı tür elmaların sunulmasının önünü kapatmayın, belki de düşünmediğiniz kadar iyi bir elma teklif edilebilir J
• Teklif verecek firmaların ne istediğinizi anlamasına izin verin.
• En az 3 teklif alın ve kıyaslayın.
•  Ağırlıklandırma ve eleme kriterleriniz net ve sayısal olsun ki duygusal seçimlerin önü kapansın.
• Satın almayı ürünün sabit fiyatı (fixed price) ile yapmak akılcıdır, ancak bazen mümkün değildir. Böyle durumlarda hedef maliyet belirlemek ve hedefi aşan maliyeti, ürünü/hizmeti sağlayan firma ile paylaşmak da iyi bir çözüm olabilir.
• Satın alma kontratını kapatmadan önce ürün/hizmet kabulü yapın ve bunun kriterlerini kontratın yapılması aşamasında belirleyin.

Herkese iyi satın almalar, keyifli projeler

Çok Odaklı Tasarım

Tüm yeni işlerde sektörü ne olursa olsun mutlaka tasarım yapılır. İster inşaat, ister otomotiv, ister IT, ister tarım, ister finans, mutlaka bir tasarım ile yola çıkılır. Bu kimi zaman yazılı çizili olur, kimi zaman bir kişinin kafasındadır, kimi zaman da bilgisayar dosyası olur. Tasarımı nasıl yaptığınıza elbette karışamayız J mutlaka herkesin kendine göre bir yolu yöntemi vardır. Bununla beraber tasarıma yaklaşımınıza yeni bir açı getirmek isterim.

Son zamanlarda duyulmaya başlayan, Çok Odaklı Tasarımdan (set-based design) bahsedeceğim bugün. Tasarımı bir ihtiyaca cevap olarak yaparız ve ihtiyacı karşılamaya odaklanırız. En iyi sonucu verecek tasarımı bulduktan sonra onun üzerinde ilerleriz, işte buna Nokta Odaklı Tasarım (point-based design) deniyor. Bu birçok durumda işe yaramış ve yaramaya devam edecek. Öte yandan çok hızlı değişen bir dünyada değişen ihtiyaçlarla birlikte yaşıyoruz. Bu hızlı değişim, karşılamak istediğimiz ihtiyacın biz tasarım ve üretim aşamalarındayken değişmesini olası kılıyor. Bu değişime ayak uydurabilmek için tasarımınızın mümkün olan en geniş yelpazeye cevap verebilir yapıda olması gerekiyor. Bir başka deyişle, sadece verilen ihtiyaca odaklanıp Nokta Odaklı Tasarım yaptığınız anda alternatif tasarımları da öldürmüş oluyorsunuz. Bu da aslında ileride oluşabilecek potansiyel ihtiyaçları karşılamakta güçlük çekme ve bazen yenibaştan tasarım yapma sonucunu doğuruyor. Burada püf nokta mümkün olan en geniş tasarım setini hazırlamak ve bu setin üretimde verilecek kararları mümkün olan en geç zamana kadar ertelenmesi ve alternatfilerin de yaşaması şeklinde özetlenebilir. Bu sayede silip yeniden yapmak yerine uyarlamak ve en az maliyetle işin altıdan kalkmak mümkün olabiliyor. Yaklaşım oldukça mantıklı, denemeye değer. Herkese keyifli tasarımlar, iyi projeler. 

Takım Formasyonu ve Liderlik

Hepimiz öyle veya böyle bir takımın parçasıyız. Projelerde hepimiz proje takımlarıyla çalışıyoruz. Proje bazlı takımlar, kuruluyor, çalışıyor, işlerini bitiriyor ve dağılıyor. Bütün takımların aslında aynı aşamalardan geçerek şekillendiğini biliyor muydunuz? Bruce Tuckman’ın bu konuyu ele alan teorisine göre tüm takımlar aynı evrelerden geçiyor, bunlar: Şekillenme (Forming), Çatışma (Storming), Durulma (Norming), Üretme (Performing), Dağılma (Adjourning). Şekillenme aşamasında ekip üyeleri birbirini tanımaya çalışır. Çatışma aşamasında takım üyeleri, takıma kendini kabul ettirmeye çabalar, bu esnada ağırlıkla baskın takım üyelerinin başını çektiği çatışmalar olur. Durulma aşamasında ekip birbirini tanımış ve kabullenmiştir; üretkenlik artmaya başlar. Üretme aşamasında artık ekip en verimli aşamaya gelmiştir ve işe odaklanmıştır. Dağılma evresinde ise işlerin tamamlanması ile takımın üyelerinin eski durumlarına dönmesi gerçekleşir. Takımın bulunduğu duruma göre ihtiyaçları farklıdır, duruma göre farklı liderlik stilleri ile çalışmak en etkin sonuca götürür:

• Şekillenme aşamasında direktif verici liderlik takımı doğru yöne kanalize eder. Takım üyeleri ne yapılması gerektiğini bilmediği için özellikle taktiksel detayların ekibe net olarak gösterilmesi beklenir.
• Çatışma aşamasında dinleyen ve çatışmaların çözümüne motive eden liderlik en etkin sonuca götürür.
• Durulma aşamasında artık takım arasında uyum yükselmiştir, taktiksel amaçlar anlaşılmıştır, bu noktada takımı motive etmek için iddialı hedefler sunulması gerekir. Liderin detaylarla ilgilenmekten çok ileriyi gösteren konumda olması gerekir.
•  Üretme aşamasında de durulma aşamasındaki takıma olduğu gibi hedefler verilmesi en etkin sonucu verir. Bu aşamada liderlik stilinin direktif verici olmaktan çok delege edici yönü ağır basmalıdır.
• Dağılma aşamasında takım üyelerine mutlaka teşekkür edilmeli ve yeni çalışmalar için motive edilmelidir.

Proje takımlarında da bu aşamaları hep birlikte yaşıyoruz. Özellikle takımın iyi gözlenmesi ve hangi evrede olduğuna bağlı olarak doğru yaklaşım ile ekibin motive edilmesi projenize mutlaka katkı sağlayacaktır. Uyumlu takımlar ve üretken projelerde görev almanız dileğiyle.

Risksiz Proje Olur Mu?

Riskin ne olduğunu hepimiz az çok biliyoruz. Projelerin de risklerle dolu olduğunu biliyoruz. Risksiz proje olur mu? Elbette olmaz J Peki tüm projelerde ortak riskler olduğunu biliyor musunuz? Burada bahsettiklerimiz negatif riskler bu arada. DeMarco ve Lister (Waltzing with Bears, 2003) bu konuyu araştırmış ve sektörü ne olursa olsun tüm projelerde ortak riskler olduğunu saptamışlar. Bunlardan en önemli olanları burada ele alacağız.

• En başta kusurlu tahmin: Projeye veya işe başlarken buzdağının altı görülemediği için, olması gerekenden çok daha iyimser tahminler verilmesi. Bunu çoğumuz görmüşüzdür. Bazen üst yönetimin de baskısıyla gayet iyimser süre ve maliyet tahminleri ortaya çıkar. Ne yazık ki bu projelerdeki en temel risktir.
•  Paydaşlar arası uzlaşı eksikliği: Projedeki farklı tarafların farklı beklentileri ve bu konuda tam bir uzlaşı olmadan projenin hayatına başlaması diğer bir risktir. Beklentileri karşılanmayan taraflar ilerleyen aşamalarda projeye olan desteği kesecektir ve bazı engeller ortaya çıkaracaktır. Tabi ki en kritik paydaş müşteridir, ve onunla uzlaşı önemlidir, bununla beraber diğer paydaşların da beklentilerinin tam olarak anlaşılması ve uzlaşılması olmazsa olmazdır.
•  Kapsam kayması: Projeye başlanırken belirlenen kapsamın öyle veya böyle proje boyunca değişmesi bir başka temel risktir. Proje bütçesi ve süresi kapsamdaki değişimden payını genellikle negatif yönde alacaktır.
• Eleman kaybı: Proje ekibindeki elemanlardan bir veya daha fazlasının işten ayrılması da önemli bir başka risk kaynağıdır. İşten ayrılan eleman beraberinde proje boyunca edindiği bilgi ve tecrübeyi de götürecektir. Yerine yeni kaynak verilse bile bu bilgi ve tecrübeden yoksun olduğu için bir adım geriden başlayacaktır. Proje de işlerdeki gecikme olarak bu riskin gerçekleşmesiyle oluşan sorundan payını alacaktır.
• Üretkenlik dalgalanması: Proje ekibinin üretkenliğinin çeşitli nedenlerle dalgalanması, proje planını gerçekleştirmeyi zorlaştıran bir başka önemli risktir.

Bu riskleri bilmek ve yeni projelere bunu bilerek başlamak bazı avantajlar sağlayacaktır. Riskle birlikte alınacak önlemleri de en baştan belirlemek bu risklerin etkisini azaltmaya veya kaçınmaya katkı sağlacayaktır. Negatif riskleri az ve keyifli projeler yönetmeniz dileğiyle.

Çevik Yazılım Projelerinde Başarının Anahtarları Nelerdir?

Başarının ne olduğunu düşündünüz mü? Hangi durumlarda kendinizi veya işinizi başarılı olarak değerlendirirsiniz? Herkesin kendine göre bir başarı tanımı vardır. Genel bir tanım bulmak gerekirse, Standish’in tanımına bakabiliriz, bütçe sınırları içinde ve istenen özelliklerle ürün sunabilmedir. Başarının farklı boyutları vardı: kurumsal başarı, teknik başarı ve kişisel başarı. Gerçek anlamda başarı bu üç boyutunda kesişimi olandır. Kurumsal başarının olmadığı bir ortamda kişisel başarının bir anlamı yoktur. Tam tersi kişisel başarının olmadığı bir ortamda tek başına kurumsal başarı yetersiz olacaktır. Bu yazıda bu üç başarının birlikte ortaya çıkması için gerekli olan anahtarlardan bahsediyoruz.

Projelerde başarının anahtarları birçok yerde yazılmış anlatılmıştır. Çevik Yazılım Geliştirme (Agile Development) yapılan projelerde başarının olmazsa olmazlarını altta listeledim:

·         Yönetim desteği: Yönetimin destek olmadığı bir çalışmanın kurum içinde destek görmesi ve başarılı olması mümkün değildir.

·         Ekip uyumu: Ekip üyelerinin uyumlu çalışabilmesi, birbirini tamamlar özellikler ile donanmış olmaları çok önemlidir.

·         Aynı lokasyona toplanmış ekip: Ekip üyelerinin aynı ortamda çalışması, sorularını doğrudan (telefon, eposta, vb gerek kalmadan) sorabilmeleri büyük avantaj sağlar.

·         Ekiple aynı ortamda ve birlikte çalışan müşteri: Müşterinin de ekiple birlikte olduğu, ekibin sorularına anında yanıt verebildiği bir ortam, proje süresini oldukça kısaltacaktır.

·         İdeal ekip büyüklüğü: Ekibin 4-6 teknik personel ve diğer personelden oluşması en idealidir.  

Bu ön koşulları oluşturduktan sonra, başarıya giden yolda en önemli ekibin nokta güçlü tasarım yetkinliğidir. Tasarımların sağlamlığı ileride oluşabilecek potansiyel sorunları önlemede, çıkabilecek yeni talepleri karşılamada en önemli yardımcı olacaktır. Arkadaşlık ve bağlılık olan bir ekip ortamı oluşturulması da başarıya giden yolda bir diğer yardımcı olacaktır. Seçilen yazılım dilinin yeniden düzenlemeye (refactoring) elverişli olması da iyileştirme çalışmalarına dolayısıyla  başarıya katkı yapacaktır. Agresif teslim tarihleri bir noktaya kadar ekibi motive etse de ulaşılması imkansız hedeflerin yarattığı stres, hedeflenen süreyi kısaltmak yerine uzatmaktadır (McConnell 1996). Ulaşılabilir ama iddialı hedefler konulması da ekibi motive etmektedir. Herkese başarılı projeler, keyifli çalışmalar...

XP nedir?

XP (Extreme Programming) konusunda birçok yayın, kitap, makale vb. vardır, bir kısmını incelemiş olabilirsiniz. Hatta bunlar arasındaki nüans farklarını da görmüş olabilirsiniz. Genel olarak son yıllarda yurtdışında popülaritesi artan bu yaklaşım zamanla ülkemizde de öğrenilmeye ve kullanılmaya başlandı. XP’nin en temel özellikleri çevik ve hızlı olmasıdır. Diğer çevik yöntemler gibi Agile Manifesto’ya (agilemanifesto.org) bağlıdır. XP’den önemli bulduğum satır başları:

• Müşteri Rolü’nün sorumlulukları: Kullanıcı hikayelerini (user story) yazmak, önceliklendirmek, test senaryolarını yazmak ve testi yapmak.
• XP Koçu’nun sorumlulukları: Takım’ın XP pratiklerini uygulamasını takip sağlamak/takip etmek.
• XP Proje Yöneticisi’nin sorumlulukları: Takıma liderlik yapmak, takımı şirketiçi bürokrasiden ve yönetimden gelecek baskılardan uzak tutmak.
• Test Odaklı Geliştirme (Test Driven Development) uygulanır. Yazılımcıların birim testleri yazması ve uygulaması beklenir. Proje Yöneticisi, “bugün kaç test geçtin?” şeklinde sorularla gelişmeyi takip eder.
• Yazılımcılar çiftler şeklinde çalışır. Aynı ekrana iki kişi bakar.
• Zaman sınırlaması (time boxing) uygulanır. İterasyonların süreleri sınırlı ve bellidir, esnetilmez. Bu süreye sığan işler tamamlanır, diğerleri bir sonraki iterasyona bırakılır. Bu arada müşteri iterasyon dışında kalan işlerin sırasını değiştirebilir. Yeni iterasyonda en yüksek öncelikli olanlardan başlayarak, iterasyona sığacak kadar hikaye alınır ve çalışılır. İterasyona girmiş kullanıcı hikayesi üstünde değişiklik yapılamaz.

Değerleri:

•  İletişim
• Basitlik
• Geri bildirim
• Saygı
• Cesaret

Değerlerin hakkını vermek gerekiyor, gerçekten iletişimin kuvvetli olduğu, mümkün olan en basit (uyduruk anlamında değil J gereksiz ayrıntıların olmadığı yalın olan) haliyle çözüm üretildiği, ekipiçi geri bildirimin çalıştığı (yapıcı ve öğretici olan geri bildirimler her zaman katkı yapar), saygının sağlandığı ve ekip üyelerinin cesaretlendirildiği bir ortamda çalışmak hem ekip üyelerinin daha verimli olmasını hem de daha mutlu çalışmalarını sağlar.

Eğer çağlayan modeliyle çalışıyorsanız ve kurum kültürünüz tam XP uygulamasına izin vermiyorsa bile XP’nin faydalı yönlerinden yararlanmak, alabileceklerinizi projenize uygulamak mümkündür. Proje yönetiminin bilimden çok bir sanat olduğunu ve her proje yöneticisinin kendine özgü bir yolu olduğunu unutmadan, XP’de kendi tarzınızı oluşturmaya katkı sağlayacak noktalar bulacaksınız.

Değer Akış Analizi

Değer Akış Analizi'ni (Value Stream Mapping) duymuş olanlar vardır. Esas itibariyle bir yalın üretim (lean manufacturing) tekniğidir. Üretilmesi hedeflenen ürün veya servisin hazırlanabilmesi için gereken kaynak ve bilgi akışının çizilmesi ve analiz edilmesine dayanır. Tüm üretim süreçlerinde kullanılabilir. Proje yönetimi de ürün veya hizmet ortaya çıkarmayı hedefleyen bir üretim süreci olduğu için bu alanda da kullanılmaya başlanmıştır. Üretime ait tüm süreçleri, bilgi ve kaynak girdilerini göstererek işe başlanır. Aşama aşama ve oklarla süreç simüle edilir. Hangi süreçte neler olduğu belirtilir, analiz aşamasında hangi potansiyel kayıpların (zaman, kaynak vb.) yaşandığı da belirlenir. Kayıplar ve üretim sürecine katkısı olmayan aşamalar, “kayıp” olarak değerlendirilir. Bu kayıpları ortaya çıkartmak ve azaltmak bu tekniğin temel prensipleridir. Kayıpların azaltılması hem üretim sürecini hızlandırır hem de maliyetin düşürülmesine katkı sağlar. Projenizde ürün veya hizmeti ortaya çıkaracağı temel süreçler bu teknik ile görsel hale getirip, kayıpların belirlenerek asgariye indirilmesi projenizde hem zaman planı hem de maliyet planına uyma konusunda önemli katkılar sağlayacaktır.

Bu teknik için kalem ve kağıt yeterlidir. Ama araç olmadan yapamayanlardansanız, bazı yazılım paketleri de kullanılabilir: Visio, Dia vb. Yeni makalelerde görüşmek üzere.

Konuşma, Dinleme ve Proje Yönetimi

Proje yönetiminin önemli bir kısmının iletişim yönetimi olduğunu, dolayısıyla etkili konuşma ve dinlemenin proje yönetimine çok önemli katkıları olacağını her zaman hatırlamak gerekir.

Konuşmada verilen mesajın öncelikle beden diliyle, ikinci sırada ses tonuyla ve son sırada sözlediklerinizle aktarıldığını duymuş olabilirsiniz. Beden dilinizi etkili kullanabilmek, ses tonunuza hakim olmak sözlediklerinizin etkisini ve anlamanı karşı tarafa doğru iletmeniz için çok önemlidir. Proje yöneticilerinin dikkat etmesi gereken bir diğer konuşma kuralı da ilk konuşan olmamak, hep konuşan olmamaktır. Karşınızdaki insanların görüşlerini öncelikle açıklamasına izin vermek, konuşmadan önce dinlemek hem karşınızdakinin diyaloğa dahil olmasını sağlar, hem de konuşmanızı karşınızdakinin görüşlerine göre revize etme imkanı kazanma anlamına gelir. Hep konuşan karşısındakine fırsat vermeyen insanlarla kimse konuşmak istemez, proje yöneticilerinin konuştuklarından daha fazla dinleyen konumunda olması bu açıdan önemlidir. Proje ekibinin ve paydaşlarının görüşlerini açıklamalarına imkan tanımak projelerdeki sorun ve risklerin ortaya çıkması, beklentilerin netleştirilmesi ve projenin sağlığı açısından önemlidir.

Dinlemenin ne kadar önemli olduğu açıktır. Bu konuda birçok bilimsel çalışma yapılmış olmakla beraber Dinlemenin Seviyeleri (Whitworth, 2007) çalışması dinlemeyi 3 seviyede tanımlar:

• İçsel Dinleme (Seviye 1): Dinleyenin “karşıdakinin anlattığı konu bende hangi düşünceye karşılık geliyor”, “bu konu beni nasıl etkiler” arka plan düşünceleriyle yaklaştığı ve kendi “kişisel lensi” ile dinlediği seviyedir. En az etkili dinleme seviyesidir. Karşıdakinin ne anlatmaya çalıştığı yakalanamaz, gerçek anlamda iletişim yoktur.
• Odaklanmış Dinleme (Seviye 2): “Kişisel lens” in olmadığı, karşıdakinin ne söylediğine odaklanmış dinlemedir. Konuşan ve dinleyen arasında bir iletişimin kurulduğu seviyedir. 
• Genel Dinleme (Seviye 3): Dinleyenin Seviye 2’ye ek olarak ortamdaki tüm sinyalleri (konuşanın mimikleri, beden dili, ses tonu, diğer dinleyicilerin davranışları, ortam ısısı, ortamdaki nesneler vb.) aldığı seviyedir. En etkili dinleme şekli olup, geçek anlamda odaklanma gerektirir ve verilen mesajların tamamına yakınının yakalanmasının önünü açar.

Konuşma ve dinleme projedeki iletişim yönetiminin temelini oluşturur. Tüm sektörlerdeki tüm proje çeşitlerinde geçerli ve önemlidir.

Duygusal Zeka ve Proje Yönetimi

Duygusal Zeka (Emotional Intelligence), duygularınız ortaya çıktığında onları fark etme, ne olduğunu anlama ve en iyi nasıl kullanacağına karar verebilme yetisidir. Duygusal Zeka’sı yüksek olan insanlar duygusal insanlar değildir, duygularını fark edip kullanabilen insanlardır. Proje yönetiminin önemli bir kısmı iletişim (kimi kaynaklara göre proje yöneticisi, zamanının %90’ını iletişimle geçirir ) olduğu için, Duygusal Zeka ayrı bir önem kazanmaktadır. Kurulan iletişimlerde sonuç alabilmek için duygularınızın farkına varmak ve bunları kullanabilmek çok değerli bir avantaj sağlamaktadır. Proje ekibiyle veya projenin diğer paydaşlarıyla yapılan toplantılarda bu avantaj oldukça işe yarayacaktır. Örneğin kızacağınız bir durumla karşılaştınız ve kızdınız, normalde beklenen karşı tarafa kızdığınızı belli eden (bağırmak, saldırgan cümleler kurmak vb.) şekilde tepki vermenizdir. Eğer kızdığınızı tepkinizi vermeden önce fark edersiniz, kızgınlığınızı belli etmek yerine karşı tarafın beklemeyeceği bir tepki vererek karşı tarafı şaşırtma ve iletişimi yönlendirme şansınız olur. Duygusal Zeka’sı yüksek insanlar iyi iletişim kurarlar ve iletişimi yönlendirmeyi ve yönetebilmeyi başarabilirler. 

Kaçan Hatalar

Kaçan Hatalar (Escaped Defects), müşteri tarafından üretim ortamında tespit edilen hatalardır. Proje sürecindeki tüm kalite kontrol adımlarından kaçan ve müşteriye sunulan son üründe tespit edilen bu hatalar, maliyeti en yüksek olan hatalardır. Hata, ne kadar erken fark edilirse o kadar az maliyetle düzeltilir temel prensibiyle, kaçan hatalar aslında istenmeyen hatalardır. Proje kapsamında müşteriye sunulan her bir üründe çıkan hatalar ürün başına listelenir ve istatiksel olarak değerlendirebilir. Müşteri için hazırlanan başka talepler olması halinde kaçan hatalar da öncelikli olarak değerlendirilmeli ve müşteriye sunulan ürün paketleri içinde planlanarak en kısa sürede düzeltmeleri yapılmalıdır. 

Hatanın kaçmasına sebep olan durumlar ve kalite kontrol adımlarının iyileştirilmesi bu yolla yapılır. Ayrıca Kaçan Hata sayıları projelerin izlendiği metriklerden birisi olarak da kullanılabilir. Müşterinin tolere edebildiği seviyenin üzerine çıkmasına izin verilmemeli, devamlı azalan bir trend izlemesi için önlemler alınmalıdır.

Devir Süresi

Devir Süresi (Cycle Time) ürün özelliklerini verdikten sonra ürünün teslimine kadar geçen süredir.  Bu sürenin kısalması verimliliğin ve üretkenliğin arttığını gösterir. Otomotiv gibi oturmuş endüstrilerde, bir arabanın siparişi verildikten kaç gün sonra teslim edilebileceği net olarak söylenebilir. Yazılım geliştirme projelerinde ise devir süresi uzundur ki bazen yılları alabilir ve müşterinin bu sürede fikrini değiştirme veya üründen vazgeçme ihtimali de artmaktadır. Çevik yöntemlerle yazılım geliştiren projelerde ise bu süre haftalar mertebesine inmektedir. Bu da müşterinin memnuniyetini artıran önemli bir unsurdur. Devir süresini projelerde ölçmek ve yapılabilecek iyileştirmeleri tespit ederek bu sürenin azaltılmasını sağlamak hem maliyet azaltıcı hem de müşteri memnuniyeti artırıcı getirileri olan önemli bir çalışmadır.

Risk Bazlı Başak

Risk Bazlı Başak (Risk Based Spike) proje ekibinin bilgi sahibi olmadığı, bir işin karmaşıklığını anlamak ve yapılabilirliğini görmek amacıyla kullanılan bir yaklaşımdır. Bu yaklaşımın temeli, bilinmeyen veya riskli olan konuyu diğer etkenlerden izole ederek ve küçük boyutta yaparak veya deneyerek görmeye dayanır. Bilinmeyen konular hakkında konuşmak ve fikir yürütmek yerine onun basit halini yapmak ve gerçeği görmenin daha etkin olacağı düşüncesinden yola çıkmıştır. Teknik araştırma veya soruya yanıt bulmak amacıyla yapılan bir deney olarak da düşünülebilir. Ekibin yeni bir teknoloji veya ürünle tanışmasını sağlamak, büyük bir işin küçük ölçeklisini görmek, teknik riskleri görmek, fonksiyonel davranışı incelemek amaçlarıyla kullanılır. Çevik yazılım projelerinde popüler olmasına rağmen tüm projelerde kullanılabilir.  

Asgari Sunulabilir Özellik

Asgari Sunulabilir Özellik (Minimum Marketable Feature), adından da anlaşılacağı üzere sunulabilen özellik kümesinin içindekilerden asgari seviyede olanlarını işaret eder.  Biraz daha açmak gerekirse, proje kapsamında müşteriye sunabileceğiniz özellikler vardır. Bunun içinde arka plandaki teknik ve altyapısal bileşenler bulunmaz. Müşterinin görebildiği, kullanabildiği, ona değer katan özellikleri kasdediyoruz. Bu özelliklerin içinde sunulabilen en küçük altkümenin oluşturulması ve müşterinin kullanımına sunulabilir şekilde hazırlanmasına sonucu oluşan özellilere Asgari Sunulabilir Özellik denir. Bu özelliklerin müşteri için bir anlamı olması, işine yarayacak şekilde sunulması önemlidir. Örneğin, bir araba yaparken, açılır tavan böyle bir özelliktir. Açılır tavanın sadece elektrik aksamını sunmak, buna karşın diğer mekanik kısımlarını sunmamak müşteri için bir anlam ifade etmez. Elektrik aksamı işin en önemli ve zor kısmı da olsa, müşterinin kullanacağı özellik tam değildir ve müşteriye bir değer ifade etmez. Diğer bir öenmli noktada da sunulan özelliğin asgari olmasıdır. Birbirine bağlı olmayan farklı özellikleri aynı çatı altında birleştirmeye gerek yoktur. Örneğin açılır tavan ve yan hava yastılarını tek bir özellik olarak sunmanız, müşterinizi yine memnun etmeyecektir. Bu iki özellik birbirinden bağımsızdır ve ayrı ayrı sunulabilir.

Asgari Sunulabilir Özellik, çevik yazılım projelerinde daha çok ön planda olmasına karşın tüm projelerde kullanılabilir. Bunun tahminlemesi için Geniş Bant Delphi, Planlama Pokeri, Benzeşme Tahmini yöntemleri kullanılabilir. 

Proje için Finans-2

İç Verim Oranı (Internal Rate of Return)

Net Bügünkü Değer’i sıfır yapan indirim oranıdır. Genellikle yıllık hesaplanır. Alttaki formüle göre NPV değerinin sıfır olmasını sağlayan r değerinin bulunması ile sağlanır. C değerleri, nakit akışını gösterir. N ise periyodu gösterir.

Peryot bilgisi genellikle yıl olarak verilir. C değerlerini de yıllık bazdaki nakit akışları olarak ele almak gerekir. Her yıl gerçekleşen net nakit akışı (nakit girdisi pozitif, çıktısı negatif) toplamı, o yıla ait C değerini oluşturur. Yukarıdaki denklemde tüm değerler yerine konduğunda tek bilinmeyen r değeri kalır. Bunu bulmak için numerik yaklaşımlar kullanılır, örneğin secant metodu gibi.

Elde edilen r değeri, projenin yapılabilir olup olmadığını değerlendirmede kullanılır. Eğer r değeri, sağlanan finansmanın maliyet oranından büyükse, proje yatırımı yapılabilir. Bunun anlamı projenin net getiri sağlayacağıdır. Eğer r değerinden küçükse, projenin net götürü sağlayacağı ve yapılmaması gerektiğidir.

Proje için Finans-1

Projelerin kattığı değeri hesaplarken veya projelerdeki satın alma kararlarını verirken temel bazı finans hesaplama yollarına başvurmak gerekir. Altta önemli olan birkaç terim incelencektir.

Net Bügünkü Değer (Net Present Value)

Para giriş ve çıkışlarının bügünkü net değerlerinin toplamıdır. Bügünkü değer (PV) hesaplamasında şu formül kullanılır:

Burada FV: gelecekteki ortaya çıkacak değeri, i: dönemlik faiz oranını, n: dönem sayısı gösterir.

Proje boyunca çeşitli para giriş ve çıkışları olacağı olacaktır. Bunların bügünkü değerlerinin toplamı net bügünkü değeri verir:

NPV değeri projenin ekonomik değerini ortaya koyar. NPV nin pozitif bir sayı çıkması, proje yatırımının pozitif geri dönüşü olduğunu ve yapılması gerektiğini; negatif bir değer çıkması, negatif geri dönüşü olduğunu ve yapılmaması gerektiğini gösterir. Sıfır olması ise yapılıp yapılmaması arasında fark olmadığı, ek bir değer katmadığı anlamına gelir.

Yatırım Geri Dönüşü (Return on Investment)

Yatırımdan gelen net kazancın yatırım masrafına oranını gösterir. Şu fomül kullanılır:

ROI değerinin 100 olması, yatırım maliyeti kadar kazanç elde ettiğinizi gösterir, 100 den büyük olması yatırımın karlı olduğunu ve yatırdığınızdan fazlasını kazandığınızı gösterir. Küçük olması ise yatırımınızın geri dönmediğini gösterir. Projelerin yapılıp yapılmaması kararını verirken bu hesaplamayı yapmak ve ROI değerine bakarak karar vermek akıllıca olacaktır.

Proje Tüzük Toplantısı

Tüzük Toplantısı (Chartering Session) proje paydaşlarını neyi, neden  ve nasıl yapacakları konusunda ortak bir noktaya getirmek, farklı hedefleri tekleştirmek, paydaşların birbirlerinden olan beklentilerini netleştirmek ve senkronizasyonu sağlamak amacıyla yapılan bir toplantıdır. Proje başlangıç aşamasında yapılması gerekmektedir. Tüm projelerde kullanılabilir. Başlatma (kick-off) toplantısından sonra yapılabilir. Ürün sahibi veya sponsorun hedeflenen ürünün ne olduğunu ve bu ürünün yaratacağı değerin ne olduğunu anlatması ila başlar. Sonrasın başarı kritilerleri belirlenir. Bu başarı kriterlerine ulaşabilmek için nasıl bir yol izleneceği belirlenir. Hedefin, beklenti ve başarı anlayışının ortak bir noktaya getirilmesi ile projedeki farklı algılamalar da en aza indirgenmiş olur. Ürün ihtiyacının ve değerinin ekip tarafından bilinmesi, yapılacak projeye olan ilgilinin artmasına katkı sağlar. Proje veya üründeki varsayım ve kısıtlar da bu aşamada konuşulup kayıt altına alınabilir.

Bilişim projelerinde özellikle çevik yönetilen projelerde yoğun olarak kullanılmakla beraber tüm projelerde uygulanabilir. Yukarıda belirlenen konular ile proje tüzüğü oluşturulması ve kayıt altına alınması da bu toplantının en önemli çıktısıdır. Projenin ilerleyen aşamalarında doğru hedefe gidilip gidilmediğinideğerlendirmek için tüzük en önemli yardımcı olacaktır.

Tel Kafes

Tel Kafes (Wireframe), özelde internet sitesi için sayfaların şematiği ve çizimi olarak düşünülebilir, detayda ise internet sitesinin iskeletini yansıtan görsel kılavuzdur. İnternet sitesinin içeriği, önyüz bileşenleri, navigasyon sistemi ve bunların bir arada nasıl çalıştığını gösteren bir plandır. Tel Kafes’te yazı sitili, renkler ve grafikler yoktur. Çünkü ana odağı internet sitesinin sunduğu fonksiyonlar, gösterdiği davranışlar ve içeriklerin öncelikleridir. Ne tür bilgilerin gösterileceği, sağlanan özelliklerin çeşitleri, bilgi ve özelliklerin öncelikleri, bilgilerin gösterimleriyle ilgili kurallar ve farklı senaryoların ekranlara olan yansımaları genellikle ele alınan konu başlıklarıdır.

İnternet siteleri dışında insan-akıllı cihaz (bilgisayar, cep telefonu, mobil cihazlar vb.) etkileşimi olan farklı uygulamalarda da kullanılabilir. Temel olarak üç bileşeni vardır: bilgi tasarımı, navigasyon tasarımı ve önyüz tasarımı. Tel Kafes, kalemle kağıda çizilebilir, yazı tahtasına çizilebilir veya bu iş için hazırlanmış özel bir uygulamada çizilebilir. 

Benzeşme Tahmini

Benzeşme Tahmini (Affinity Estimation), bir tahminleme yoludur. Genellikle IT projelerinde kullanılır, özellikle çevik yöntemlerle yazılım geliştirmede tercih edilir. Hem efor tahminlemesinde hem de büyüklük tahminlemesinde kullanılabilir. Bu tahminlemeyi büyük bir odada ve post-it yapıştırmaya uygun büyük bir yazı tahtası ile yapmak kolaylık sağlayacaktır. Yazı tahtasının sağ ucuna Çok Büyük (XL), sol ucuna Çok Küçük (XS) ifadeleri yapıştırılır. Toplantıya Ürün Yöneticisi ve tahminlemeyi yapacak konu uzmanları davet edilir. Uzmanlar, tahminleme yapılması gereken talepleri göre büyüklüğüne göre tahtaya uygun yere (Çok Büyük ve Çok Küçük arasında) yapıştırır. Eğer bir talebin netleştirilmesi istenirse Ürün Yönetcisi’ne sorulur. Soru işareti olan talep ayrı bir yere yapıştırılır. Tüm ekip üyeleri tahminlerini yapıştırdıktan sonra tüm ekibin tahtaya gelmesi ve diğerlerinin yapıştırdıklarını görmesine izin verilir. Tahminini değiştirmek isteyenler bu esnada kendi tahminlerini değiştirebilirler. Ekip üyelerinin birbiriyle konuşması bu esnada serbesttir. Tüm uzmanlar tahminlerini gözden geçirdikten sonra tahminlerin destelere ayrılması istenir. Bunun Fibonacci sayıları (1, 2, 3, 5, 8 vb.) veya elbise bedenni yaklaşımı (XS, S, M, L, XL vb.) kullanılabilir. Bu aşamadan sonra Ürün Yöneticisi, tahtaya gelerek tahminlerle ilgili görüşlerini (özellikle karmaşık bir talebin XS olarak destelenmesi vb. durumlar) farklı renk bir kalemle işaretler. Buna meydan okuma (challenge) denir. Bu esnada diğer ekip üyeleri çay-kahve arasına çıkabilir. Ekip geri gelince, Ürün Yöneticisi’nin işaretlediği maddeler tekrar konuşulur. Bu maddeler için yeniden tahminleme yapılır ve uzlaşı ile tahminin son halini alması beklenir. Koordinatör, son tahminlerin resmini çekerek kayıt altına alır.

Çok sayıda tahminlenmesi gereken talep varsa bu yöntem hız kazandırmaktadır. Detaylı tahminleme gereken noktalarda Planlama Pokeri veya Geniş Bant Delphi yöntemleri kullanılabilir. 

Planlama Pokeri

Planlama Pokeri (Planning Poker), bir tahminleme yoludur. Genellikle IT projelerinde kullanılır, özellikle çevik yöntemlerle yazılım geliştirmede tercih edilir. Hem efor tahminlemesinde hem de büyüklük tahminlemesinde kullanılabilir. Geniş Bant Delphi tekniğinin bir türevidir. Talepler listesi ve üzerinde bu iş için hazırlanmış sayıların olduğu kartlar listesi bu çalışmanın temel ihtiyaçlarıdır. Sayı kartlarında genellikle Fibonacci dizisine uygun veya onun türevi sayılabilecek sayılar yer alır, örneğin 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 99 veya 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 vb.  Bu temel ihtiyaçlara ek olarak geçen zamanı takip için kum saati veya benzeri bir saat tavsiye edilir. Planlama pokeri bir koordinatörün gönderdiği (tercihen proje yöneticisi) toplantı daveti ile başlar ve alttaki adımları içerir:

1. Toplantıya Koordinatör dışında konu ile ilgili uzmanlar ve Ürün Yöneticisi katılır. Koordinatör bu oyunu oynamaz yönlendirir.
2. Ürün Yöneticisi kısa bir ürün bilgilendirmesi yapar. Konu uzmanlarına soru sormaları için fırsat verilir. Özellikle varsayım ve risklerin ortaya çıkarılması önemlidir. Koordinatör bu esnada ortaya çıkan bilgileri kaydeder.
3. Konuşulan konuyla ilgili her bir uzman masaya bir kart bırakır, kartın sayı olan yüzü masaya bakar. Etraftaki diğer kişilere hangi sayıyı masaya koyduğunu söylememesi gerekmektedir.
4. Tüm ekip kartını masaya koyduktan sonra herkes aynı anda kartını açar.
5. En yüksek ve en düşük tahminleri veren kişilerin tahminlerinin sebebini açıklaması istenir.
6. Ekip kartını alır ve tüm ekip yeni kartını ortaya sürer, aynı anda kaldırılıp kontrol edilir. Eğer genel bir uzlaşı varsa kartların sayılarında, koordinatör bir sonraki maddeye geçilmesini sağlar. Eğer uzlaşı yoksa 4. ve 5. adımlar uzlaşı sağlanan kadar tekrar edilir.

Kartlardaki Fibonacci sayıları, uzmanların tahminlerini yaparken dikkatli olmasını zorunlu kılar. Örneğin 6 atmak isteyen bir uzman 5 veya 8 arasında karar vermek ve işin büyüklüğünü iki kere tartmak zorunda kalır.

Planlama Pokeri, tüm ekibin tahminlemeye katkı yapmasını sağlar. Sözel tahminlemede baskın kişiler nedeniyle sesini duyuramayan kişilerinde tahminini vermesini sağlar. Ayrıca konu uzmanının diğerleri ile tahminini kıyaslama ve değiştirmesine olanak verir. Bunun da katkısıyla Planlama Pokeri ile elde edilen tahminlerin her bir uzmandan ayrı ayrı tahmin alıp ortalamasını almaktan daha iyimser ve doğru olduğu bilimsel çalışmalarla ortaya konmuştur.

Geniş Bant Delphi ile Proje Tahminleme

Geniş Bant Delphi (Wide Band Delphi) tekniği ile projelerde büyüklük tahmini yapılması 1970lerden itibaren gündeme gelmiştir. Esas itibariyle Delphi tekniğinin bir türevi olan bu yöntemi bir koordinatör (tercihen proje yöneticisi) yönetir ve konu uzmanları katılırlar. Alttaki adımları içerir:

1. Koordinatör bir toplantı daveti ile ilgili uzmanları toplar ve onlara istenenler hakkında bilgilendirme yaparak tahminleme formu dağıtır.
2. Uzmanlar formu bireysel olarak doldurur ve tahminlerini yazıp koordinatöre verirler ve ekip dağılır.
3. Koordinatör ortaya çıkan tahminleri uzmanlarla paylaşır ve ekibi yeniden toplantıya çağırır.
4. Toplantıda tahminlerdeki farklılıklar konuşulur.
5. Uzmanlara yeniden formlar dağıtılıp, yeni tahminleri alınır. Eğer tahminler istendiği kadar yakın değilse, 3-5 adımlar tekrarlanır.

Tahminlemeyi yapacak ekibin çok kalabalık olmaması (ideali 3-7 kişi arası) önemlidir. Hem toplantıların verimi, hem de uzlaşının sağlanması sayıyla doğrudan ilgilidir. Farklı ekiplerin çalışması muhtemel işlerde tüm ekiplerden katılımcı alınması atlanmaması gereken bir detaydır. Uzmanların oluşturduğu tahmini ve varsayımlarını proje yöneticisi gözden geçirerek son haliyle proje tahminlerine yansıtır. Bu yöntem genel yaklaşımı sebebiyle, farklı projelerde kullanılabilir.