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.

Birikimli Akış Diyagramı

Birikimli Akış Diyagramı (Cumulative Flow Diagram) iş maddelerini durumlarına göre takip etmeye yarayan bir yoldur. Hangi işin hangi durumda olduğunu belirlemek, işlerin ilerleme hızını, bitecek iş miktarını ve kalan iş miktarını görmenin en kolay yoludur. İşin alabileceği durumları net olarak belirlemek ilk aşamadır. Gri durumlar olmaması gerekir, bir iş ya bir durumdadır ya diğerinde ve hangi durumda olduğu ve bir durumdan diğerine nasıl geçebileceği net kurallarla belirlenmiş olmalıdır. İşlerin durumlar arası geçiş süreleri hızın ölçülmesine olanak verir. Hangi durumlarda iyileştirme potansiyeli olduğu da kendiliğinden ortaya çıkacaktır. Durumlar için standart bir liste yoktur, farklı projeler veya operasyonel işler için farklı durumlar tanımlanabilir. 

Kanban ve üretim süreçlerinden çıkan bu yaklaşım, zamanla başka sektörlere ve proje dünyasına da yayılmıştır. Projeleri izlemek için kullanılabilecek en önemli göstergelerden birisidir ve iyileştirme potansiyellerini görme yönünden önemli katkısı olmaktadır.

Ozmotik İletişim

Ozmotik iletişim (Osmotic Communication) son zamanlarda özellikle çevik projelerde gündeme gelen yeni bir kavram. Bu iletişim aynı odada birlikte çalışan ekipler için özellikle geçerli. Temel yaklaşımı ortamda konuşulanlara kulak kabartma olarak belirtilebilir. İleşimi etkileşimli yapmak yerine duyduklarınızın kendiliğinden size ulaşmasıyla, iletişim tek kanallı olarak gerçekleşir. Doğrudan veya dolaylı olarak ilgilendiğiniz konularla ilgili etrafta olup bitenin farkında olmayı kolaylaştırır. Bilginin ekibe daha homojen dağılmasına önemli katkı yapar. Küçük ekiplerle daha etkin olan bu iletişimde genellikle ilgilendiğiniz bir konu konuşuluyorsa konuşmaya dahil olmak da mümkün olur. İlgilenmediğiniz konuları yok sayarak işinizle ilgilenmeye devam edersiniz. Ekibin büyük olması, istenen katkının ortaya çıkmasını zorlaştırabilir.

Aynı odada çalışmak ve ortamda konuşmanın olması bazı insanların rahatsız olması veya konsantre olmasını olumsuz etkileyebilir diye düşünebilirsiniz. Yapılan araştırmalarda insanların bu yönden genel olarak rahatsız olmadıkları yönünde. En önemli olumsuz geri bildirim ise özel işler veya görüşmelerin tüm ekip tarafından duyulması, bu da konuşanı ve dinleyeni rahatsız edebilir. Buna çözüm olarak, aynı odada çalışanlar için bir toplantı odası veya bölümü ile konuşan kişiyi diğer çalışanlardan uzakta bulunmayı olanaklı hale getirmesi önerilebilir. Buna genellikle "özel bölüm" veya "mağara" isimleri veriliyor. Bu sayede ekip üyelerine hem genel hem de özel alan yaratılmış oluyor.  Tabi kendi odası olan ekip üyelerini bu şekilde çalışmaya ikna etmek çok kolay olmayacaktır.  

Kanban ile Proje Yönetimi

Japonya'da Toyota Üretim Sistemi'nden doğan Kanban, esas olarak kart/işaret anlamındadır. Üretimde çığır açan, büyük ölçekli fabrikaların çoğunda bilinen, az ya da çok kullanılan operasyonel bir yaklaşımdır. Anında üretim (Just-In Time) ile birlikte stok maliyetini azaltan, ürün ve yedek parça takibini kolaylaştıran bu yaklaşım, son zamanlarda teknoloji projeleri ile de anılmaya başlandı.

Kanban, yeni bir organizasyon yapısı, yeni bir üretim modeli, yeni bir proje yaklaşımı ortaya koymaz. Elinizde olanı alır küçük adımlarla iyileştirmenin yolunu açar. Kanban'da iddialı ve dramatik değişikliklere yer yoktur, elinizde olanın değerli olduğunu ve bunun iyileştirilebileceğini varsayar. İyileştirme yolunda da büyük ve tek bir adım yerine küçük ve devamlı adımları tercih eder. Bununla beraber hiçbir sistemin mükemmel olmadığını, daha iyisinin mutlaka olduğunu kabul eder.

• Temel prensiplerinden bir tanesi, "akışı görünür kılmak"tır. Üretim sistemlerinde bunu yapabilmek kolaydır, ancak teknoloji projelerinde üretilen değeri/bilgiyi ve buna bağlı süreci görünür kılmak kolay değildir. bunun yerine akışı ön plana çıkarmak ve onu görünür kılmak önemlidir. 
• Diğer önemli nokta ise akışa alınacak girdileri kontrol etmektir. Üretim sistemlerinde bunun yansıması tedarik sürecinin iyileştirilmesi ve anında üretime yaklaşılmasıdır. Teknoloji projelerinin girdisi, ham madde değildir, burada önemli olan üretim sürecine alınacak olan taleplerdir.
• Akışı görünür kıldıktan sonra en önemli aşama akışı izlemek ve iyileştirilebilecek noktaları tespit etmektir. Burada küçük ve devamlı iyileştirme adımları devreye girer.
• Akışa ait süreç kurallarının belirgin hale getirilmesi hangi işin neden yapıldığını anlamaya ve iyileştirme potansiyelini anlamaya yardımcı olur.
• İyileştirme potansiyelinin uzlaşı ile belirlenmesi ve uygulanması en can alıcı adımdır. Bu yolla birlikte çalışma ve ekip ruhu ortaya çıkarılır.

Kanban'ı daha iyi anlamak ve teknoloji projelerine uyarlamak ileride daha da önem kazanacaktır. Yakın gelecekte teknoloji projelerinin, istenen ürünleri ortaya çıkarırken üretim yollarını da iyileştirmesi, verimli ve etkin hale getirmesi de gerekecektir.

Kanban için alttaki bağlantı başlangıç için ideal:

http://en.wikipedia.org/wiki/Kanban

Çevik Yöntemler

Proje yönetiminde farklı yollar ve yöntemler de artık gündemde. Projelerde doğruya ve başarıya götüren tek bir yol olmadığı artık bilinen bir gerçek. Metotlar ve yollar temelde aynı olsa da uygulama biçimleri değişebiliyor. son zamanlarda gündeme gelen Çevik (Agile) yaklaşımlar, geri planda kalmış ama önemi yüksek olan konuları tekrar hak ettikleri yere getiriyor. Özellikle yazılım proje yönetiminde gündemde olan Çevik yaklaşımların, aslında genele de uyarlanabilecek prensipleri çok olmakla beraber; bireyleri, iletişimi, müşteri ile işbirliğini, basitliği, son ürünü ve değişime ayak uydurmayı ön plana çıkarması bu yaklaşımın kuvvetli olduğu noktaları ortaya koyuyor. Kalabalık bir süreç zincirine bağlı kalmak, çok fazla dokümantasyon yapmak, sıkı kontrat yönetimi ve proje planına katı bağlılık hem müşteriyi, hem ekibi ve hem de proje yöneticisini zaman zaman çok zorluyor. Bazen katı kurallar insanların çalışabileceği alanları çok daraltıyor, üretkenliği ve yaratıcılığı geri plana itebiliyor. Hatta müşteriyi karşı tarafta görmeye bile sebep olabiliyor. Çevik yöntemlerin güçlü olduğu ve öne çıkardığı prensiplerle ileride daha fazla sayıda sektörde ve projede yer alacağını, aynı zaman daha fazla esnekliğe ve uyarlamaya olanak verecek olan Uyarlanabilir Proje Yönetimi (Adaptive Project Management) kavramının ön plana çıkacağını düşünüyorum.