Çevik Yöntemlerde Toplantılar

İş hayatında toplantı yapmamış olan var mı? Bence yoktur, tüm iş ortamlarında kısa, uzun; az, çok; resmi, gayri-resmi toplantılar yapılır. Kimi zaman tüm günümüz toplantılarda geçer. Eğer yapmamız gereken başka işler varsa, toplantıya katıldığımız için keyfimiz kaçar, zaman zaman da toplantıyı düzenleyene içten içe kızarız. Hatta bir kısmımız toplantıların verimsiz ve gereksiz olduğunu düşünür. Kimi zaman da gereksiz ve detay konulara girilerek asıl amaçtan uzaklaşılır. Bazen konu uzar, istenen noktaya ulaşılamaz ve süresini aşar. Bazı rutin toplantılarda ise gündem olmasa bile toplanılır ve pek de bir sonuç alınmadan ayrılınır.

Toplantıyı niye yaparız? Fikirleri paylaşmak, bilgilenmek, bilgilendirmek, ikna etmek, ikna olmak, karar vermek... Bu amaçlara ulaşabilmek için çevik yöntemlerde de toplantı yapılır. Çevik yöntemleri daha önce farklı başlıklarda ele almıştık (İlgili Makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi, Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde Test Yönetimi, Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği). Çevik yöntemlerde çalışmaların etkin olması, gereksiz iş yapılmaması hepimizin bildiği üzere ön plandadır. Toplantılar da aynı prensiplere göre organize edilmiştir: ihtiyaç kadar, belli hedeflere dönük ve zaman sınırlı (time-boxed). Uygulanan çevik yöntemler farklı bile olsalar, temel toplantıları benzerdir ve şöyle özetlenebilir:

• Vizyon Toplantısı: Buradaki amaç, çalışmaya konu ürünle ve projeyle ilgili vizyonun konulması, bu vizyon için gidilmesi gereken yolun ana hatlarının belirlenmesidir.
• Sürüm (Release) Planlama Toplantısı: Sürüm içinde ele alınacak konuların belirlenmesi, önceliklerin değerlendirilmesi amacıyla yapılır.
• İterasyon Planlama Toplantısı: İterasyona başlarken yapılan bu toplantıda, o iterasyonda hangi işlerin, kimler tarafından yapılacağı takım olarak belirlenir. Temelde bu toplantı iki aşamalıdır. İlk bölümde "ne yapılacak" sorusuna karşılık aranır, ikinci bölümde "nasıl yapılacak" sorusuna yanıt verilir. Yarım gün veya tam gün olabilir. Süre baştan belirlenmiş olmalıdır.
• Günlük Ayaküstü (Daily Stand-up) Toplantı: 15 dakika ile sınırlı bu toplantıda, takım üyelerinin her biri kısaca "dün ne yaptım?", "bugün ne yapacağım?", "önümdeki engeller nedir?" sorularını yanıtlar. Toplantı ayaküstü ve sabah ilk iş olarak yapılır.
• İterasyon Gözden Geçirme Toplantısı: İterasyon sonunda tamamlanan çalışmaların demosunun yapılması, Müşteri veya Ürün Sahibi'nin görüşlerinin alınması amacıyla düzenlenir. Kabulü yapılan iş maddeleri kullanıma sunulmak üzere hazırlanır. Kabul edilmeyenler ise Talep Listesi'ne (Product Backlog) iade edilir.
• Retrospektifler: Hem İterasyon sonunda hem de Sürüm sonunda yapılır. Retrospektif başlığını daha önce etraflıca ele almıştık (İlgili Makale: Çevik Yöntemlerde Retrospektif).
• Talep Listesi Sadeleştirme (Product Backlog Refinement): Bu toplantıda Talep Listesi'nin üzerinden geçilerek büyük konular küçük parçalara ayrılır. İhtiyaç kalmayan talepler ayıklanır. 

Farklı çevik yöntemlerde isimler farklı olabilir. Örneğin Scrum'da iterasyonun özel adı Sprint'tir. Sprintler içindeki toplantı akışı yandaki şekilde olduğu gibi döngüseldir. Günlük Scrum Toplantısı, Sprint içinde tekrarlanır ta ki Gözden Geçirme Toplantısı'na kadar.

Tüm bu toplantılara herkes davet edilmez. Kime ihtiyaç varsa onlar davet edilir. Örneğin Retrospektifler, Takım içinde yapılır. Sürüm ve İterasyon Planlama Toplantıları'nda Ürün Sahibi, Çevik Takım olmazsa olmazdır. Çevik Proje Yöneticisi süreci takip etmek amacıyla katılır. Diğer paydaşları ihtiyaç olmadıkça toplantıya dahil etmemek verim için gereklidir. Toplantının zaman ve kapsam yönetimi konularında Çevik Proje Yöneticisi aktif rol oynar. Konuşulan içeriğe ise müdahale etmez. Dolayısıyla gereksiz detaylar ve uzayan toplantıların önüne geçilir. Toplantıların süre sınırlı olması, hedefe dönük olması, ilgisiz katılımcıların davet edilmemiş olması, hem verimi hem de toplantılarla ilgili motivasyonu arttırır.

   

Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği

Çevik yöntemlerin müşteri ve temsilcisi ile teknik ekiplerin bir arada çalışmasını beklediğini hepimiz biliyoruz. Bu temellere göre çevik bir projedesiniz ve ekiple müşteriyi bir araya getirmeyi başardınız. Eskiden kalma ön yargılar sürdüğü ve ekip kaynaşamadığı sürece yine istenen sonuca ulaşmanız mümkün olmayacaktır. Ekibin üyeleri bireysel olarak ne kadar iyi olurlarsa olsunlar, birlikte çalışamadıkları zaman başarılı olmak hayal olacaktır.  Peki nasıl birlikte çalışma ortamı yaratılabilir

Birlikte çalışabilmenin anahtarı güvendir. Güven arttıkça işbirliği artacaktır. İşbirliğinin artması demek verimliliğin artması, ekibin etkinliğinin ve hızının artması ve de işin kalitesinin yükselmesi demektir. Peki güven nasıl sağlanır?

Güven için ilk adım empatiden geçiyor. Türkçe’ye duygudaşlık olarak çevriliyor. Benim anladığım
anlamı ise kendinizi başka birisinin yerine koyabilme ve onun gözünden anlama ve hissedebilme. Özellikle projelerde farklı rollerde çalışan insanlar birbirlerinin durumunu anlamakta zorluk çekebiliyor. Eğer herhangi bir yapıcı adım da atılmazsa “biz-siz” veya “biz-diğerleri” sınıflamaları ortaya çıkıyor. Bunun sonucunda da şöyle şikayetler artıyor:

• “Biz çok çalıştık, diğerleri çalışmadı.”
• “Biz haksızlığa uğradık.”
• “Bizim dediğimiz olmalı! Yoksa kendiniz yaparsınız.”
•  “Diğerleri işini iyi yapmadığı için kalitesiz oldu.”
•  “Diğerleri hata yaptılar ondan gecikti.”
•  “Biz olmadan bu iş olmazdı.”

Biz-siz algısının en keskin olduğu noktalarda empati kurulabilmesi en çok faydayı sağlayacaktır. Peki nerelerde empati gereklidir?

İlki müşteri-programcı arasında. Müşterinin gözünde genelde  programcılar, bahaneler üreten, disiplinli çalışmayan, denileni yapmayan, çoğu zaman iyi dinlemeyen, tembel ve zaman zaman da şımarık kişiler olarak canlanıyor.  Programcılar gözünde ise genelde müşteriler, ne istediğini tam bilmeyen, devamlı fikrini değiştiren, öngörüsü yeterli olmayan, teknolojiden bihaber, şikayet etmekten memnuniyet duyan ve zaman zaman da patronluk taslayan kişiler olarak canlanıyor.

İkincisi programcı-testçi arasında. Programcı gözünde genelde testçiler, bir türlü isteneni yapamayan, en ufak zorlukta bayrak kaldıran, denileni anlamayan, katı, tembel ve genelde programcı olmayı başaramamış kişiler olarak canlanıyor. Testçiler gözünde programcılar, işi bitirmeden teste sunan, aceleci, dikkatsiz, test ekibinin zamanından kullanan ve genelde burnu havada kişiler olarak canlanıyor.

Bu ön yargıları aşıp empati oluşturabilmenin bir kaç aşaması bulunuyor:

·       İlk adım elbette bir arada çalışmaktan geçiyor. Bir arada çalışma ister istemez iletişimi artıracak ve birbirini daha iyi anlama şansı verecektir.

·       İkinci önemli adım retrospektiflerin birlikte yapılabilmesi, bu konuda daha önce bir yazım bulunuyor (İlgili Makale: Çevik Yöntemlerde Retrospektif).

·       Üçüncü önemli adım ise iki tarafın birbirine talepleri dışında projeye ilişkin yaşadıkları zorlukları ve yönetmeye çalıştıkları durumları da açık yüreklilikle anlatabilmesi. Örneğin müşterinin yeni bir talebi ortaya çıktığında bunun neden ortaya çıktığı, bunu programcının önüne getirmeden önce neler yapıldığı, nasıl basitleştirilmeye çalışıldığı da anlatılırsa programcı da durumu ve müşteriyi daha iyi anlayacağı için daha farklı yaklaşabilecektir.

·       Dördüncü adım, herkesin kendi rolüne göre hedefler konulması yerine herkesi kapsayacak proje hedefinin ön plana çıkarılması, bireysel hedeflere ulaşmanın ödüllendirmede geri plana alınmasıdır. Örneğin programcı işini iyi yapsa bile ortaya çıkan ürün başarılı olamamışsa, kendisinin de başarılı sayılamayacağının hissettirilmesi.

·       Beşinci adım, birlikte yemek. Yemeği ekibin birlikte yemesi, ekip içi iletişimde arkadaşlık imkanlarını da artıracak, birbirini anlamaya katkı yapacaktır. Ne sıklıkla olacağına ekiple karar vermek en sağlıklısı olacaktır.

·       Altıncı adım, ekip devamlılığı. Eskiden İnsan Kaynakları politikaları personel devamlılığını sağlamak üzere optimize edilirdi. Artık bu yeterli değil, ekiplerin de devamlılığının sağlanabilmesi gerekiyor. Aynı ekibin sıradaki projelerde de birlikte çalışması hem çalışılan konudaki tecrübenin artmasına hem de ekipiçi güven ve işbirliğinin güçlenmesine fayda sağlayacaktır. Önümüzdeki yıllarda bu konunun daha çok önem kazanacağını düşünüyorum.

Sonuç olarak çevik yöntemlerin meyvelerini alabilmek için birlikte çalışmayı başarabilmek, takıma dönüşmek ve takımlara özgü güven ve işbirliğini tesis etmek gerekiyor. 

Çevik Yöntemlerde Retrospektif

Retrospektif (kimi yerlerde “geçmişe bakış” olarak geçiyor, TDK sitesinde tanımlı olduğu için bu haliyle kullanıyorum), çevik yöntemlerde daha önce yapılanların değerlendirildiği bir aşama olarak karşımıza çıkıyor. Özellikle iterasyon retrospektifi sık duyulan ancak içeriği hakkında fazla bilgi bulunmayan bir kavram. Bugün bu konuyu ele alıp “neden yapıyoruz”, “nasıl yapıyoruz”, “nelere dikkat etmeliyiz” sorularını yanıtlamaya çalışacağız.

Çevik yöntemlerde retrospektifin çıkış noktası hiçbir sürecin mükemmel olmadığı, iyileştirilebilecek yönleri olduğu gerçeğidir. İyinin daha iyisi hep vardır. Ayrıca değişime ayak uydurabilmek için her zaman geçmişte yapılanları inceleyip ders çıkarmak gerekir. Esasında sadece çevik yöntemlerle sınırlı değildir bu yaklaşım, tüm projelerinizde ve proje dışı işlerinizde geçmişe bakıp değerlendirme yaparak dersler çıkarmak ve iyileştirme yapmak mümkündür.

İterasyon retrospektifi en bilinen türüdür, iterasyon sonunda yapılır ve tüm ekibin katılımı istenir. Bunun dışında sürüm (release, çevik yöntemlerdeki anlamı tam da sürüm değil aslında, buna uygun başka Türkçe kelime önerisi varsa ve iletebilirse çok memnun olurum ) retrospektifi, proje retrospektifi de yapılır. Zamanı önceden planlanmamış sürpriz retrospektifler yapmak da mümkündür. Retrospektif yaparken izlenebilecek adımları altta iletiyorum, bunlar zorunlu olmamakla birlikte faydayı artırdığı tecrübe edilmiştir:

• Temel Talimat: Retrospektifler kişileri eleştirmek veya başarısızlıkları ortaya dökmek için yapılmaz. Bilakis herkesin tüm gayreti ile çalıştığı varsayımı üzerine hangi iyileri daha iyi yapabileceğimize dönük yapılır. Bunun altını net bir şekilde çizecek ve ekibi motive edecek bir “cümle” temel talimat olur. Herkesin bu talimatta mutabık kalması gerekir. Retrospektifin bu temel talimata göre yönetilmesi gerekir. Örneğin “Amacımız bağcı dövmek değil, üzüm yemek, daha iyi üzümleri yiyebilmek için buradayız. Lütfen kimseyi eleştirmeden sadece nasıl daha iyi üzüm yiyebileceğimiz üzerine düşünüp görüşlerinizi aktarın.”
• Beyin Fırtınası: Herkesin temel talimatta mutabık kalmasının ardından  bu aşamaya geçilir. Bu bölüm açık uçlu sorularla başlatılabilir. Sorulara gelen yanıtlarla kendiliğinden derinleşecektir.  Önemli tespitlerin herkesin görebileceği bir yere örneğin yazı tahtasına yazılması sonraki aşamalar için faydayı sağlayacaktır. Alternatif olarak bu bölüme başlarken yazı tahtasına sırasıyla şunlar ve istenirse ilave başlıklar yazılır: Eğlenceli/ Sıkıcı, Kolay/ Karmaşık, Benzer/ Farklı. Sonrasında bütün ekip üyelerinden bu başlıklara girebilecek konularla ilgili bu iterasyona ait deneyimleri istenir. Tüm ekip, öncelikle kendi önündeki kağıtlara yazar. Hangi deneyimleri artırıp neleri azaltmak istedikleri sorulur, bunlar da yazılır. Sonrasında sırasıyla herkesin görüşlerini açıklaması istenir. Aynı fikirde olunan konulara + eklenir.  Artırılması istenenlerin nasıl yapılabileceği sorularak konular tartışmaya açılır. Böylelikle iyilerin neler olduğu ve nasıl daha iyi olabilecekleri ekip tarafından ortaya konur.
• Sessizlik: Bu aşamada herkes susarak yazılanlarla ilgili ve bir sonraki iterasyonda nelerin iyileştirilebileceği ile ilgili düşünür. Fikirlerin tüm ekip tarafından anlaşılması ve hazmedilmesi için bu aşama çok önemlidir. Bu yapılmazsa toplantıda çok konuşan kişilerin sürüklediği dengesiz ve ekibin tamamını içine alamayan bir sonuç ortaya çıkar. Söz gümüşse sükut altındır sözü bu aşamayı çok güzel tarif eder.
• Oylama: Bu aşamada herkes tahtada yazılmış konulardan bir tanesini seçerek bir sonraki iterasyonda iyileştirilmek üzere işaretler. Çoğunluğun seçtiği konu tüm ekibin bir sonraki iterasyonda odağı olur.
• Odaklanma: Seçilen konuya tüm ekip odaklanarak nasıl iyileştirilebileceğine dair yeni görüşlerini belirtir.  Bir sonraki iterasyonda bu konudaki iyileştirme ekibin tamamı tarafında anlaşılıp kabul edilebilecek bir hedef cümlesine dönüştürülür.

Retrospektiflerde dikkat edilecek konulardan ilki tüm ekibin katılımdır. Tüm ekip üyelerinin konuşup görüş vermesi ve aktif katılımı, yapılan değerlendirmeyi daha da değerli kılacaktır.  Orada olmayan ekip üyeleri haliyle sonraki iterasyonun amacını kaçırması olasıdır.

Diğer dikkat edilmesi gereken konu retrospektif esnasında kişisel suçlama veya eleştirilere fırsat verilmemesidir. Eğer buna fırsat verilirse konu kolaylıkla çığırından çıkıp karşılıklı eleştiri boyutuna taşınabilir.

Son konu da retrospektifin süresinin sabit tutulmasıdır (time-boxing) ki bu da sürecin uzayıp konunun dağılmasını önleyecektir.

Başarılı retrospektifler çevik yöntemlerde (ilgili makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi, Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde Test Yönetimi ) ilerlemenin anahtarıdır. Retrospektiflerin iyileşmeye katkı yaptığı ekip tarafından görüldükçe, retrospektiflere olan motivasyon da artacaktır.  

Çevik Yöntemlerde Test Yönetimi

Test kavramı, yetenekleri, bilgi, beceri ve kabiliyetleri ölçme veya sınama olarak tanımlanıyor ve hepimizin aşina olduğu bir konu. Hem günlük hayatımızda hem de profesyonel iş hayatımızda çeşitli sebeplerle kendimiz veya ürettiklerimiz teste tabi tutuluyor. Matematik testi, zeka testi, kişilik testi, dayanaklılık testi, zemin testi, kandaki şeker testi, bakteri üreme testi, araç çarpışma testi, birim test, sistem testi, stres testi, regresyon (türkçesi bağlanım olarak geçiyor, kullanımı yaygın değil) testi, kullanıcı kabul testi vb. Hepsinde bir ölçme veya sınama söz konusu.

Test yapmazsak ne olur? Fatura öderiz. En temel örnek otomobil üreticilerinin bir hata tespit edip bazen yüzbinlerce aracını geri çağırmaları ve hem prestij hem de para kaybetmeleri. Bunu genişletmek mümkün: yıkılan yapılar, çalışmayan makineler, hatalı çalışan kodlar, sağlık sorunları, zararlı yiyecek/içecekler vb.

Testin esas amacı durumu anlama veya önlem alma veya düzeltme/iyileştirme olabiliyor. Tüm yazılım projelerinde olduğu gibi çevik yöntemlerde (ilgili makaleler: Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde İş Analizi, Çevik Yöntemleri Uygulayabilmek) de testin önemi büyük. Bu önem de hatadan mümkün olduğunca arındırılmış kod üretebilmek ve bu sayede kullanım esnasında sorunsuz çalışmasını sağlayabilmekten ileri geliyor.

İster yazılım olsun ister başka bir endüstri test yönetiminde iki prensip çok işe yarıyor:

• İlki testi mümkün olduğu kadar erken aşamada yapmak veya başlatmak. Çünkü hata ne kadar erken fark edilirse düzeltme maliyeti o kadar düşük olacaktır. 
• İkincisi testi mümkün olan en geniş kapsam sağlayacak şekilde planlamak. Çünkü atlanan bir bölümde ortaya çıkacak bir hata, o kısmın test edilmesine ayrılacak maliyetten kat be kat yüksek olacaktır.

Yazılım projelerinde bu prensiplerden yola çıkılarak kod geliştirirken birim test; bileşenleri birleştirirken entegrasyon testi; birleştirilmiş ürünün çalışmasını görmek için sistem testi; son kullanıcıya göstermek için kabul testi; hataların düzeltilmesi esnasında farklı yerlerin etkilenip etkilenmediğini görmek için regresyon testi; performans beklentisinin karşılanıp karşılanmadığını görmek için performans testi planlanır. Bunların bazıları projeye ve ihtiyaca göre yapılmayabilir.

En kıymetli ve en az maliyetli test adımı olan birim testler maalesef genelde çok hafif geçilir veya atlanır. Çevik yöntemlerde tam da bu soruna bir çözüm öneriliyor Test Güdümlü Geliştirme (ingilizcesi Test Driven Development, Test Kontrollü Geliştirme de kullanılıyor). Burada amaç test durumlarına göre geliştirmeyi yapmak ve kodun testi geçecek kadar geliştirilmesini zorunlu kılmak. Temel adımları:

• Düşün (Think): Kodun ne yapması gerektiğini düşünüp bunları listeleyin.
• Kırmızı Çizgi (Red Bar): Testi listedeki fonksiyonlardan bir veya birkaçı için yazın. Mümkünse 5 satır veya daha az olsun.  
• Yeşil Çizgi (Green Bar): Testi geçecek kadar kod yazın ve testi geçin. 
• Kod Düzenleme (Refactor): Testi geçen kodu fonksiyonalitesini bozmadan iyileştirin. Fonksiyonun bozulup bozulmadığını gerekli yerlerde bir önceki adıma dönüp testi tekrarlayarak kontrol edin.
• Tekrar (Repeat): İyileştirilmiş koda ulaşınca, yeni bir fonksiyonalite için başa dönüp döngüye devam edin. Döngüden çıkış koşulu, listelenen fonksiyonalitelerin bitmesi.

Yukarıdaki yaklaşım ile önce testi sonra bu testi geçecek kodu yazarak önemli bir sıra değişikliği yapılıyor. Bu sayede henüz kodlama aşamasında bir çok hata tespit edilerek ortadan kaldırılıyor. İlk başlarda kodlama hızını düşürdüğü düşünülse de toplamda projeye hız katacaktır. Ayrıca buna alışan yazılımcıların hızlarının arttığı gözlenmektedir.

Test Güdümlü Geliştirme yanında kullanıcı hikayesi (ilgili makale: Çevik Yöntemlerde İş Analizi) yazılırken bunların arkasına testinin nasıl yapılacağının da yazılması gereklidir. Bu sayede geliştirilirken hangi durumlarda kullanılacağı ve nasıl test edileceği de biliniyor olacaktır. Hatta geliştirme aşamasında bunlar yukarıdaki döngüde Kırmızı Çizgi aşamasına da dahil edilebilecektir.

Bu kadar teste gerek var mı derseniz, yanıtım kesinlikle evet olacaktır. İyi test edilmemiş her iş faturasını er geç ödetir. Son söz olarak teste ayrılan zaman asla boşa gitmez, mutlaka bir faydası olacaktır, ya prestij ya para ya da emek kaybını önleyecektir.

Çevik Yöntemlerde Ekip Liderliği

Çevik yöntemlerle (ilgili makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi ) ilgili önemli başlıklardan birisi ekip yönetimidir. Kimi zaman çevik yöntemlerde ekibin kendi başına tüm işi yaptığı, kararlarını kendi içinde aldığı, lidere de ihtiyaç duymadığı düşünülse de çevik yöntemlerde liderlik bir ihtiyaçtır. Klasik yönetim tarzlarının başarılı olamadığı, ekibe direktif verici yaklaşımların uygulanamadığı, ekibin kendi içinde karar alabildiği çevik yaklaşımlarda ekip yönetimi da haliyle farklı olacaktır. Peki çevik ekiplerle çalışırken nasıl davranacağız, nasıl liderlik yapacağız? Bu sorunun yanıtı arayacağız.

Eğer proje yönetiminden geliyorsak ve çevik bir ekibe liderlik yapmamız bekleniyorsa işi planlayıp plana göre takip etme alışkanlığından vazgeçmemiz gerekiyor. Çevik yöntemlerin dinamik planlama yapısı içinde ekibin planlamaya aktif katılmasına müsaade etmemiz ve proje boyunca planı revize etmemiz gerekiyor. Hatta en hassas olduğumuz kapsam yönetimi ve değişiklik yönetimi konularında bildiklerimizi bir kenara bırakmamız ve kapsamın projenin sonuna kadar değişmesine izin vermemiz gerekiyor. Başarı ölçümüzü müşteriye katma değer sunan ve çalışan uygulamalar olarak değiştirmemiz gerekiyor.

Eğer teknik yöneticilikten geliyorsak, direktif verici ve sıkı kontrole dayanan yönetim tarzını bir kenara bırakmamız gerekiyor. Ekibe yöneticilik yapmaktan vazgeçmemiz, liderlik özelliklerimizi ön plana çıkarmamız gerekiyor.

Çevik yöntemlerde başarılı liderlerin diğer liderlerle birçok ortak noktası var (ilgili makaleler: Liderlikte Enerji, Takım Formasyonu ve Liderlik, Mükemmeliyetçilik ve Liderlik, İnsan Nasıl Yönetilir?) bu yazıda onlara değinmeyeceğiz. Çevik yöntemlere özel ve önemli beceriler neler diye baktığımızda, alttaki başlıkların öne çıktığını görüyoruz:

• Ekibe koçluk yapma: Ekip üyelerinin kendilerini ve değerlerini tanıyarak potansiyellerini ortaya çıkarmalarına yardımcı olmak. 
• Ekip içi işbirliğini teşvik etme: Çevik yöntemlerde ekibin bir arada olması, birlikte çalışması ve işin sorumluluğunu hep birlikte üstlenmeleri sebebiyle iş birliğini ve yardımlaşmayı öne çıkarmak ve de teşvik etmek.
• Problemleri ekiple birlikte çözme: Problemleri çözümleriyle beraber sunmak veya kendi başına çözmek yerine ekiple birlikte çözülmesi için ortak aklı harekete geçirmek.
• Yaptıkları ve davranışlarıyla örnek olma: Liderliğin olmazsa olmazı olan hem kişiliği hem de yaptıkları ile ekibe ilham vermek.
• Yapılan çalışmanın müşteriye katacağı değeri ön plana çıkarma: Esas üretimin çalışan yazılım ve bunun müşteriye katacağı değer olduğunun altını gerekli noktalarda çizmek.
• Bürokrasi ve engelleri kaldırma: Ekibin dış etkenlere en az maruz kalması ve işlere odaklanabilmeleri için kurum içi bürokrasi ve engelleri temizlemek ve ekibin önünü açmak.
• Her detaya karışmama: Ekibin ne yapılması gerektiğini bilen, iyi niyetli ve çalışkan bireylerden oluştuğunu kabul etmek. Ekibe hareket alanı bırakmak. Yapılan işlerin tüm detaylarına hakim olmaya çalışmamak.

Her alanda olduğu gibi çevik yöntemlerde de iyi liderlik için eğitim ve tecrübe gerekir. Eğitim, zaten konuyu öğrenmek için gerekli, bunu tartışmaya gerek yok. Tecrübe ile kastedilen işi yıllarca aynı şekilde yapma değil, değişikliklere, farklı ekiplere, farklı tekniklere duyarsız kalmadan değişerek gelişmedir. Çevik yöntemler doğası gereği dinamik bir ortam sunuyor, müşteriden gelen değişikliklere yeşil ışık yakılıyor. Haliyle ekip liderinin de değişime ve gelişime açık olmasını beklemek gerekiyor.

Çevik Yöntemlerde İş Analizi

Çevik (agile) yöntemleri çoğumuz duymuşuzdur.  BT'de yaygın olan çevik yöntemler (ilgili makale: Çevik Yöntemleri Uygulayabilmek) ile ilgili hemen aklımıza hızlı şekilde kodlama gelir. Hep yazılım tarafındaki katkısı ve hızı düşünülür. Aslında çevik yöntemlere bu hızı kazandıran özelliklerden birisi hiç şüphesiz çevik iş analizidir. Peki çevik yöntemler içinde iş analizi nasıl yapılır? Bu sorunun yanıtını arayacağız.

Çevik manifestoda karmaşık dokümantasyon, uzun süreçler, müşteri ile sözleşme pazarlıkları ve katı planlar kabul görmüyor. Bunun yerine çalışan yazılım, etkileşim, müşteri ile işbirliği ve değişime ayak uydurabilme ön plana çıkarılıyor. Bunun karşılığını iş analizinde bulmak mümkün. Birçok dokümandan oluşan kimi zaman yüzlerce sayfayı bulan ve çoğu zaman da okunmayan dokümanlar yerine "Kullanıcı Hikayesi" (User Story) kavramı öne çıkıyor. Kullanıcı hikayesi ise müşteri veya kullanıcı için değerli olan özellik veya kabiliyet olarak özetlenebilir. Her bir özelliği/kabiliyeti ayrı ayrı olmak üzere kartlara yazarak bunların hem planlamada, hem detayları hatırlamada hem de test aşamasında kullanılması sağlanır.


Örnekler:

• Kullanıcı şifre ve kullanıcı adı ile sisteme giriş yapar.
• Kullanıcı x ekranından y verisini girer.
• Kullanıcı z verisini bilgisayarına kaydeder.
• ...

Teknik gereksinimler, altyapı ihtiyaçları gibi müşteriye anlamlı olmayan konular kullanıcı hikayelerinde yer almaz. "Uygulama Java'da yazılır." veya "Spring çatısı kullanılır" gibi bilgiler müşteri için anlamlı değildir.

Bir diğer konu da çok genel ve yüzeysel kullanıcı hikayelerinin yanıltıcı olabileceğidir, örneğin "Kullanıcı sisteme girip işlem yapabilir" gibi. Burada kullanıcının ne tür işlemler yapacağı, neleri yapamayacağı gibi konular havada kalmaktadır. Müşteri için anlamlı olan tüm kabiliyetlerin, teker teker yazılması en ideal yoldur. Yazılanların mümkün olduğu kadar atomik olması, planlamayı ve test işlerini kolaylaştıracaktır. Kullanıcı hikayesinin bağımsız, tahmin edilebilir ve test edilebilir olması da hem planlamayı hem de testi kolaylaştıracaktır. Eğer uygulamayı kullanacak birden fazla tipte kullanıcı varsa bu kullanıcılara göre tasniflenerek kullanıcı hikayesi yazılması en sağlıklısı olacaktır.

Kullanıcı hikayesini, müşteri veya müşteri adına ekipte yer alan iş analisti yazabilir. Yazılanların önceliklendirilmesi de yine müşteri veya onun temsilcisi tarafından yapılır. Her bir kullanıcı hikayesinin maliyeti (story points) işin büyüklüğü ve karmaşıklığı da dikkate alınarak yazılımcılar tarafından belirlenir. Sürüm ve iterasyon aşamalarında bu maliyetler, öncelikler ve yazılım hızı (iterasyon başına düşen ortalama story points) dikkate alınarak planlama yapılır. İterasyona giren kullanıcı hikayelerine dokunulmaz, dışında kalanlarla ilgili müşteri öncelik değiştirebilir veya yenilerini ekleyebilir.

İterasyon boyunca çalışılan kullanıcı hikayeleri için kabul testleri (acceptance testing) senaryoları kartların arkalarına yazılabilir. Bu şekilde istenen neydi, nasıl test edilecek bilgileri tek yerde toplanır. Tabi test için çeşitli araçlar kullanılan kurumlarda araca da girişi yapılabilir.

İterasyonla testi tamamlanıp kullanıma sunulan maddeler iş listesinden (çevik yöntemlerde ingilizcesi burndown chart, türkçe bilişim sözlüklerinde tam karşılığı bulunmuyor) düşülür. Proje boyunda yeni talepler de gelebileceği düşünüldüğünde genel trendi azalan ancak zaman zaman da yeni taleplerle artan bir grafik ortaya çıkar.

Sonuç olarak çevik yöntemlerde iş analizi önemini korur. Buradaki amaç uzun dokümanlar yerine ihtiyaçları basit, anlaşılır, kodlanabilir ve test edilebilir kullanıcı hikayelerine dönüştürmek ve bunları etkin şekilde kullanabilmektir.

Çevik Yöntemleri Uygulayabilmek

Son yıllarda özellikle BT sektöründe çokça duyulan ve popüler olan terimlerden biri de çevik (agile) yöntemler. Çıkışı 1950'lere dayanan bu yaklaşım 1960'larda 1-2 haftalık iterasyonlar ve kısmi çözümlerle hızlı  sonuçlar alınması şeklinde uygulanıyor.  1980'lerde Scrum ortaya çıkıyor. Burada da rugby oyunundaki toplu hücum toplu savunmadan esinlenilerek toplucu tüm işin yapılması temel felsefeyi oluşturuyor. 1990'lara gelindiğinde XP (extreme programming, ilgili makale: XP Nedir?), DSDM (Dynamic Systems Development Method) ortaya çıkarak çeşitli yerlerde kullanılmaya başlıyor. 2001'e gelindiğinde ünlü Çevik Manifesto yayınlanıyor, özetle:

• Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
• Kapsamlı dökümantasyondan ziyade çalışan yazılıma
• Sözleşme ve pazarlıklarından ziyade müşteri ile işbirliğine
• Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye

önem verilmesi olarak belirtiliyor. Scrum, XP, DSDM, FDD (Feature Driven Development), Crystal, LSD (Lean Software Development) ve diğer çevik yöntemler detayda bazı farklılıklar gösterseler de genel olarak yukarıdaki manifestoya uygun yaklaşımlardır.  

Temel itibariyle tüm projelerde çevik yöntemler uygulanabilir. Yukarıdaki manifestoyu baz alarak yaklaştığınız sürece tüm projeleri çevik tipte ele alabilirsiniz. Projeleri birkaç haftalık iterasyonlar olarak küçük parçalara bölerek yönetirseniz ve iterasyon sürelerini sabit tutarsanız (time-boxing) çevik yaklaşımın temel prensiplerini kullanabilirsiniz. Peki nasıl uygulayabiliriz? Aklınıza gelen bazı temel engelleri ve bunlara çevik dünyanın verdiği yanıtları alttaki şekilde özetleyebiliriz:

Çevik yöntemlerde dokümantasyonu nasıl yaparım? İterasyonlar içinde teslimatlar arasında dokümanları da tanımlayabiliriz. Dokümantasyonda aşırıya kaçmamak asgari yeter seviyede (barely sufficient) yapmak çevik yöntemlerin tercihidir. İstenirse dokümantasyon için ayrıca bir iterasyon (hand-off) ayrılabilir.

Kalite süreçlerini nasıl işletirim? Kalite süreçlerinde istenenleri, iterasyonlar içinde iş maddesi veya iterasyon sonunda kabul kriteri olarak planladığımızda kalite ekibiniz de memnun olacaktır.

Şirketimiz çağlayan modeli ile çalışılmasını tercih ediyor, ne yapabilirim? Çağlayan modelinde istenen çıktıları verdiğimiz sürece ekip içinde çevik yöntemlerle ilerlememize engel bir durum yoktur. Mümkün olduğu kadar müşterimizi işin içine katarak işbirliğini artırdığımızda çevik yaklaşımın meyvelerini yiyebiliriz.

Çevik yöntemlerde direkt kodlama yapabilir miyim? Çevik yöntemler kovboy kodlaması (cowboy coding) değildir. İşleri esnek bir plan dahilinde önceliklendirerek  yürütmemiz beklenmektedir. 

Çevik yöntemde kapsam, bütçe, zaman nasıl dengelenir? Sabit bütçe ve zaman olduğu varsayılarak kapsam serbest bırakılır. Müşterinin kapsamı yönetmesine izin verilir. Müşteri de kapsamı değiştirebildiği için mutlu olur. Çağlayan modelinde proje esnasında gelen değişiklik isteklerinin (change request) yerini ürün iş listesi (product back-log) alır.

Çevik yaklaşımda kapsam kontrolü nasıl yapılır? Ürün iş listesi ve bunun önceliklendirilmesi ile kapsam yönetilir. Burada kritik konu müşterinin fikrinin değiştirip iş listesinde henüz iterasyonu ve yazılım süreci başlamamış maddelerin önceliğini ve içeriği değiştirebilmesidir.  Eğer yeni madde ilave edilecekse karşılığında bir maddeyi çıkarmasını isteriz. Müşteri de vazgeçebileceği bir şey bulup bizi bu yükten kurtarır.

Ürün nasıl son haline getirilir? Ürünü toparlamak ve gerekli yerlerini düzenlemek için özel bir iterasyon (hardening, refactoring) planlayabiliriz.

Çevik yöntemlerde proje yöneticisi var mıdır? Elbette vardır, yöntemlere bağlı olarak adı değişebilir, örneğin Scrum Master, XP Koçu gibi. Klasik proje yönetiminden en büyük farkı ekibin işini kolaylaştırmak amacıyla ekibin önündeki engelleri ve bürokrasiyi kaldırmaya çalışır, ekibe yöneticilik yerine liderlik yapar. Sorun veya risk olan noktalarda devreye girer. Seçilen çevik yöntemin doğru uygulanmasını sağlar.

Çevik yaklaşımlardan maksimum fayda elde edilebilmesi için kurum olarak bu yöntemlerin benimsenmesi, üst yönetimin bu yolda tam destek sunması oldukça önemlidir. Müşterinin çalışmalara aktif katılımı da sonucu etkileyecektir.

Tüm projeler gibi çevik yaklaşımla yönetilen projeler de başarılı olmayı hedeflerler. Çevik yöntemlerde başarılı olabilmek için bol uygulama ve tecrübe çok önemlidir. Uygulama sayısı arttıkça hız kazanılması, eksikliklerin giderilmesi mümkün olur. Başarıyı etkileyen konular genel olarak diğer projelerle benzerlik gösterir (ilgili makale:Proje Başarı Kriterleri ve Proje İhtiyaç Analizi). Çevik yaklaşımın kendine özgü başarı anahtarları da vardır (ilgili makale: Çevik Yazılım Projelerinde Başarının Anahtarları Nelerdir?). 

Liderlikte Enerji

Herkesin enerji hakkında az çok bilgisi vardır. Hatta aklımıza hemen elektrik, doğal gaz, benzin gibi kavramlar da gelir. "Temiz enerji" ve "doğa dostu enerji" ise son yıllarda çokça duyduğumuz kelimeler, bunları da rüzgar tribünleri, güneş panelleri ile özdeşleştirmiş durumdayız. Fizikteki enerji tanımı cismin/sistemin iş yapabilme yeteneği olarak verilir; vardan yok yoktan var edilemez, dönüşür; çeşitli şekillerde bulunabilir; kinetik enerji, potansiyel enerji ise temel formlarıdır. Fizikteki bu tanımları kullanarak insandaki enerjiyi inceleyeceğiz. Liderlik elbette çok boyutlu bir kavram (ilgili makaleler: Takım Formasyonu ve Liderlik, Mükemmeliyetçilik ve Liderlik, İnsan Nasıl Yönetilir?, Başarılı bir CEO olur muydunuz?), bu yazıda sadece enerji açısından ele alacağız.

İnsandaki enerjiyi anlamak için süper kahramanlardan başlamakta fayda görüyorum. Enerji deyince aklıma ilk gelen atom karınca, yardım için oradan oraya koşturur, yorulmak nedir bilmez. Superman bile atom karıncanın yanında tembel kalır. En azından Clark Kent olunca dinlenme imkanı bulur :) Süper kahramanların enerjilerini nereden bulduklarını ise net değildir. Peki biz sıradan insanlara ne enerji verir?

• Yiyecekler 
• Renkler
• Müzik
• Kelimeler
• Düşünce ve duygular

Yiyecekler fiziksel enerjimizi sağlarlar, hepimizin bildiği ATP molekülü de bu süreçte anahtardır. Renkler ise duyguları harekete geçirerek enerji verir veya alır. Dinlediğiniz müzik eğer hoşunuza giden bir ritm içeriyorsa enerjinizi artıracaktır, beğenmediğimiz bir parça ise enerjimizi düşürecektir. Okuduğunuz, duyduğunuz ve söylediğiniz tüm kelimeler enerji içerir. İnsanların birbirlerine enerji aktarmalarını sağlar. Düşünce ve duygular da insanın enerji seviyesini ve enerjinin pozitif mi negatif olduğuna katkı yapacaktır. Hatta enerjimizi başka insanlara bazen kelimelerle, bazen bakışlarımızla bazen de duruşumuzla istesek de istemesek de aktarırız.

Liderler de ekiplerine enerji aktarır. Ekibin enerjisi sonuca yansır. Bu da yapılan işi, projeyi, uğraşı mutlaka etkiler. Liderdeki negatif enerji ekibe misliyle yansır, hem işe hem de ekip içi ilişkilere olumsuz etkiler. İyi liderlerin ise pozitif enerji yaymaları gerektiği söylenir. Peki liderler ne zaman pozitif enerji verirler?

• Çalışandaki potansiyeli anlamaya zaman ayırdığında: Bunun için çok iyi bir dinleyici olup (ilgili makale: Konuşma, Dinleme ve Proje Yönetimi) çalışanın hayallerini ve hedeflerini anlamak ve de hangi yöne kabiliyetleri olduğunu gözlemlemek gereklidir. Her insanın bir kabiliyeti, diğer insanlardan daha iyi yapabildiği bir şey vardır. Kimi insan bunun farkındadır, kimisi de farkında değildir. Farkında olmayanların keşfedebilmesi için liderlerin gözlemleri yardımcı olacaktır. İnsana eleştirel gözle yaklaşma, bir kusur bulma en kolayıdır. Kusursuz insan var mıdır dünyada? Maharet potansiyel bulmak ve bunu ortaya çıkarmaktadır.  
• Potansiyel  enerjiyi kinetik enerjiye çevirmeye destek olduğunda: Potansiyeli anladıktan sonra istek uyandırıp işe, oluşa yönelmesine yardımcı olmak, harekete geçmesine fırsat vermek gereklidir.  
• Çalışanlara koçluk, mentörlük yaptığında: Doğru budur diyerek insanların kabul etmesini beklemek en kolayı ancak en etkisiz olanıdır.  Bunun yerine çalışanlara ne yapacakları söylemeyip doğruyu bulmaları için kılavuzluk etmek ve gerekli yerlerde iyi sorular sorarak çalışanın kendiliğinden doğruları yakalamasına yardımcı olmak gelişim için iyi bir yaklaşımdır. 
• Çalışanların başarı ve başarısızlıklarını aynı olgunlukla karşıladığında: Başarısızlıkların da eğer nedenleriyle incelenirse çok iyi birer öğretmen ve de başarıya giden yolda kilometre taşları olduğunun bilinciyle yaklaşmak çalışanlara cesaret verecektir. Esas tehlike başarısız olmak değil başarısızlık korkusuyla hiçbir deneme yapmamaktır. Şu anda kullandığımız hemen hemen bütün araç gereçler onlarca bazen yüzlerce başarısız deneme ve bunlardan öğrenilenler sonucunda ortaya çıkmıştır. Eğer başarısız olmaktan korksaydı tüm insanlar, hala taş devrinde yaşıyor olurduk.
• Çalışanların katkı sağlamasına fırsat yarattığında: Her şeyi kendi bilip yapmak yerine ekibin de bir şeyler katmasına fırsat vermek, onların da yapılan işi sahiplenmelerini sağlayacaktır. Çorbada tuzu bulunan çorbadan daha çok lezzet alacaktır.
• Çalışanlarla birlikte öğrenmeye ve uygulamaya başladığında: Ekiple bir şeyler öğrenip bunu da hep birlikte uygulamak ekip ruhunu kuvvetlendirecektir.
• İlham verme ile değer vermeyi birlikte yapabildiğinde: Birçok kaynakta, liderlikte öne çıkartılan kavram ilham vermek ve etkileyerek peşinden sürüklemektir. Esasen değer vermek de en az ilham vermek kadar önemlidir, hele bu ikisini birlikte yapabiliyorsa işte o zaman gerçek anlamda lider olunabilir. Unutmamak gerekir ki "değer verildiğini hisseden değer katmak için çalışır".

Hepimiz hayatımızın bir parçasında lideriz. İş ortamında kimimiz CEO, Müdür, Proje Yöneticisi, Ekip Yöneticisi. Liderlik sadece iş ortamıyla da sınırlı değil elbette kimimiz spor takımı kaptanı, kimimiz dernek başkanı, kimimiz aile reisi, kimimiz abi/abla, kimimiz anne/baba. Her ne konuda liderlik yaparsak yapalım bizimle birlikte olan insanları dinliyor, anlıyor ve de değer veriyorsak, bizimle birlikte olan insanların tüm gayretiyle yapılana dahil olma, saygı ve de sevgisini kazanma şansına sahip oluruz. Ekip olmak sadece akıl işi değil aynı zamanda gönül işidir. Kalıcı başarıların anahtarı da işte budur.

Proje Yönetimi ve İletişim Kazaları

Proje yöneticisinin zamanının %90'ının iletişimle geçtiğini hep duyarız. Gerçekten de iletişim bu kadar önemli mi? Kesinlikle :) Bu konuda daha önce hazırladığım ve PMI TR'nin Ekim 2012 etkinliğinde kullandığım sunuma bağlantıdan ulaşabilirsiniz. İletişimin kazasız olması  (ilgili makale: İletişim Kazaları ) da proje başarısına doğrudan katkı yapacaktır.

Kazanılmış Değer Analizi ile Etkin Proje Yönetimi

25 Mart 2014 tarihinde PMI-TR'nin davetlisi olarak Ankara'da bir konuşma yaptım. Aktivitenin detayları duyuruda yer alıyor. Bilkent Cyberplaza'da Microsoft'un konuğu olduk. Katılım oldukça iyiydi. Ben çok keyif aldım, umarım dinleyenler de aynı düşüncelerle ayrılmıştır. Sunumumu paylaşmam istenmişti, bağlantıdan ulaşabilirsiniz. PMI-TR Ankara ekibine ve gönüllülerine bu vesileyle teşekkürlerimi iletiyorum.

İnsan Nasıl Yönetilir?

İnsanın tetkik edebileceği en önemli konunun yine insan olduğuna dair bir önerme vardır. Belli açılardan doğru olduğunu düşünüyorum. Elbette bir fizikçi karanlık maddenin, bir matematikçi Reimann hipotezinin veya bir mühendis yapay zekanın daha ilginç olduğunu söyleyebilir. Hepimizin uğraştığı alanla ilgili ilginç bulduğu bir konu olsa da ortak noktamız insanlardır. Çevremizdeki insanlarla az ya da çok iletişim halindeyizdir, onlarla var oluruz, hayatımızı anlamlı hale getiririz.
İnsan yönetmek için yönetici olmak gerekmez. Aslında farkına varsak da varmasak da her bir iletişimimizde çevremizdeki insanları yönetir ve aynı zamanda yönetiliriz. Tabi ki kendimizi de yönetiriz. Hayatta mutlu olmak, başarı kazanmak, sevilmek ve sayılmak hepimizin ortak istekleridir. Bunun yolu insanı yönetebilmekten geçer, hem kendimizi, hem de çevremizi... Yönetmekle kastettiğim "ben söylerim sen de yaparsın"  türü bir yaklaşım değil. Hem kendimizin hem çevremizdeki insanların farkında olmayı, onlarla ilgilenmeyi ve tanımayı temel alan bir yönetimden bahsediyorum. Çıkış noktasını Sokrates'ın ünlü "Ey insan kendini tanı" sözü çok güzel özetliyor. Kendini tanıma aşamalarında ilerleyen bir insanın soracağı temel sorulardan birkaçı:

• Ne yapmak istiyorum?
• Yapmak istediklerimi nasıl gerçekleştirebilirim?
• Nasıl bir hayat sürmek istiyorum?
• Hayallerim neler?

Tüm insanların istekleri, hedefleri ve hayalleri vardır. Sadece kendimizinkilere odaklanırsak ve iletişim halinde olduğumuz diğer insanlarınkini görmezden gelirsek, gelip geçici başarılar elde etsek de kalıcı başarılara ulaşamayız, sevilmeyiz, sayılmayız. Tam da bu noktada insan yönetmenin bence en önemli ve basit formülü Casson'ın dile getirdiği gibi çözümü sağlar: İnsanların çıkarlarını ve isteklerini de anlayıp bunları da içine alan kendi amacımızı da gerçekleştirebileceğimiz bir işbirliği çerçevesi oluşturmak. Sizinle işbirliği yapanlar da kendi amaçlarının anlaşılıp dikkate alındığını görürlerse emin olun daha iyi ve motive çalışacaklardır. Ortaya çıkan faydanın herkesin işine yaraması ve paylaşılması sonraki işbirlikleri için de zemin hazırlayacaktır.
Sizinle çalışmaya mecbur, emriniz altındaki kişilerle bu işbirliği çerçevesini kurabilirseniz, hem sadık hem de çalışkan bir ekibiniz olacaktır. Eğer onlara önem vermez, anlamak için çaba harcamazsanız, ilk zorlukta sizi yalnız bırakacaklar, ilk fırsatta işten ayrılacaklardır. İnsanlara onlardan üstün ve zeki olduğunuzu hissettirmeye çalışmanız, ise  tabloyu daha da kötüleştirir. Böyle liderler kendinden kötü insanların içinde mutlu hisseder ve mükemmel olduğunu düşünür (ilgili makale: Mükemmeliyetçilik ve Liderlik).
Birçok yönetici kendisinden daha zeki veya becerikli çalışanları ekibinde istemez. Böyle çalışanlardan korkar, kendi konumuna tehdit olarak algılar. Zeki ve becerikli çalışanlar yerine kendisine iltifat eden ve denilenleri yapıp ötesini düşünmeyenlerle yoluna devam etmeyi yeğler. Bu şekilde sözünü geçirebileceği, yönetebileceği (!) bir ekip kumaya çalışır. Aslında bu ekip yöneticiyi sevmez mecburen katlanır, durumu idare eder ve ilk fırsatta da gemiyi terk eder.
İnsan yönetme sanatında başarılı olmuş kişiler kendilerinden daha zeki veya becerikli insanlardan korkmaz. Onlarla işbirliği yaparak birlikte daha iyiye gidebileceklerini bilir ve hedeflerine ve başarılarına da ortak ederler.
İster CEO olun (ilgili makale: Başarılı bir CEO olur muydunuz?), ister işçi hiç fark etmez,  insan yönetmeyi bilenler hep bir adım ileri giderler. Ünlü Fransız düşünür Pascal'ın dediği gibi insan her telinden ses çıkan bir saz gibidir, bu sazı çalmayı bilenler hem kendilerinden hem de başkalarından ahenkli müzikler çıkarıp mutlu olur ve mutlu ederler; bilmeyenler ise hem kendilerinin hem de başka başkalarının akortlarını bozar ve sonuçta mutsuz olup mutsuz ederler.

Ürün ve Proje Yönetimi

Projeleri yapılış amacına göre iki farklı kategoride toplayabiliriz: Süreç ve Ürün. Süreç projelerine burada değinmeyeceğim, ayrıca bir yazıyı hak edecek kadar geniş bir kavram. Bu yazıda ürünün yaşam döngüsü ve projelerden bahsetmek istiyorum. Peki, ürün nedir? Ürünü hepimiz biliriz, kimi zaman gözle görülen, elle tutulan, kimi zaman görülemeyen tutulamayan ama var olan eserdir. Her ürünün bir yaşama ömrü vardır, o da tıpkı canlı varlıklar gibi, doğar, gelişir-değişir, olgunlaşır, geriler ve ömrünün tamamlayıp ölür. Ürünün yaşamını bu şekilde tanımlayan ürün yaşam döngüsü teorisi Raymond Vernon tarafından ortaya konmuştur.

Ürüne bu yaşam döngüsü içinde bir veya genelde daha fazla proje de eşlik eder. Ancak ürün ve proje elbette aynı şey değildir ve ürün miadını tamamlamadan proje tamamlanabilir. 15 yıl boyunca çalıştığım projelerde gördüğüm en temel yanılgılardan biri özellikle müşteri ve üst yönetimin ürün ve projeyi özdeş görmesi, hatta ürün miadını doldurana kadar proje kapanışına sıcak bakılmamasıdır. Bu da projeyi yöneten bizler için çoğu zaman çıkmaz bir durum yaratmaktadır. Ayrıca planı sadece kağıt üzerinde olan projelerde (ilgili makale: Plansız Proje Olur mu?) bu çıkmaz daha da zorludur. Hatta kimi zaman bu durumu kabullenir ve çaresi olmadığını düşünürüz (ilgili makale: Öğrenilmiş Çaresizlik). Alttaki türden müşteri veya üst yönetim görüşleri duymuşsunuzdur: "Proje tamamlanmadı, çünkü

• ürün istediğimiz seviyede değil
• daha yapılacak yeni özellikler var
• ürün daha bitmedi"

Ürün ve proje yaşam döngülerinin aynı şeyler olmadığını, bir ürün için birden fazla proje gerektiğini anlatmışızdır. Böyle durumlarda çoğu zaman karşı tarafın şüpheli bakışlarına muhatap olup, "projeyi kapatıp işten sıyrılmak istiyor" düşüncelerine konu oluyoruz. Peki çıkış yolu nedir?  Ürün projelerini sınıflandırmak, bunu proje yönetim sürecinde tanımlamak ve şirketin genelinde kullanılır kılmak. Ürün projeleri genelde iki tipte ortaya çıkıyor:

• Yeni ürün projesi
• Ürün iyileştirme projesi

Yeni ürün projesi, adı üstünde çıktı olarak yeni bir ürün çıkaran proje. Örneğin, yeni bir otomobil, yeni bir deterjan, yeni bir bina, yeni bir yazılım... Ürün ortaya çıktıktan sonra bu proje kapatılıp operasyona devredilebilir. Operasyon esnasında da belli iyileşmeler sağlanabilir. Eğer ürünün yaşam döngüsündeki gelişme-değişme ihtiyacı yoğun ise belli bir noktada aynı ürün için ürün iyileştirme projeleri açılabilir. Örneğin, otomobilde makyaj (face-lift) projesi, deterjanda geliştirme projesi, binada restorasyon projesi, yazılımda iyileştirme projesi gibi. Bir ürün için birden fazla ürün geliştirme projesi açılabilir. Bunlar peşpeşe olabileceği gibi, arada operasyona devir yapılıp belli bir süre sonra da açılabilir.

Hangi aşamada ürün geliştirme projesi açılacağını, pazar, rekabet, kurumun kaynakları ve stratejisi belirler. Burada projeye gerçekten ihtiyaç olup olmadığını proje ihtiyaç analizi (ilgili makale: Proje Başarı Kriterleri ve Proje İhtiyaç Analizi) ile belirlemek gerekir. Zamanlaması iyi ve içeriği doğru düzenlenmiş ürün iyileştirme projeleri, ürünün yaşam süresini uzatır, rekabet etmesini kolaylaştırır.
Yeni ürün projesi ve ürün iyileştirme projelerinin yönetimlerinde de farklılıklar vardır. En temel fark kapsam yönetimiyle ilgilidir. Yeni ürün projelerinde ortada bir ürün olmadığı için hayaller ön plandadır. Bu tip projelerde mümkün olduğu kadar prototiplemeden yararlanılmalı,  örnek görülmeye çalışılmalı ve kapsam buna göre düzenlenmelidir. Bazı endüstrilerde bu yaklaşım yerleşiktir, örneğin yeni bir uçak için prototip yapılıp mutlaka rüzgar tünelindeki performansına bakılır. Ürün iyileştirme projelerinde ise ürün bellidir, ürünün neye ihtiyacı olduğu da az çok bellidir. Burada kritik nokta ise projeye başlarken kapsam iyi belirlenmeli ve ürün hayatta olduğu için proje esnasında doğacak yeni ihtiyaçları yönetmek için değişiklik yönetimi kuralları konusunda paydaşlarla el sıkışılmalıdır. Aksi duruma bir türlü tamamlanamayan bir kapsam listesi ile başbaşa kalınabilir.

Proje Başarı Kriterleri ve Proje İhtiyaç Analizi

Proje başarı üçgenini çoğumuz biliriz, bunun köşelerinde yer alan zaman, bütçe, kapsam ve ortadaki kalite projenin temel başarı kriteri olarak kabul edilir. Çoğu projede bunlar ölçümlenerek projenin başarılı mı başarısız mı olduğu tespit edilmeye çalışılır. Örneğin takvim hedeflerine uyulmuşsa, bütçe aşılmamışsa ve kapsam da tamamlanabilmişse ortada başarı vardır. Acaba? Gerçekten başarı bu kadar kolay mı?
Başka örneklerle açalım, size yeni bir ürün geliştirme için bir kapsam, bütçe ve hedef zaman verildi, siz de Proje Yöneticisi olarak ekibi kurup çalışmaya başladınız, uzun mesailer, zorlu aşamalar derken proje bitti, ürün hazır. Ama o da ne? Piyasaya sunulamıyor, çünkü müşteri olmazsa olmaz bir özelliği kapsamda söylemeyi unutmuş. Projeyi kapatmak istiyorsunuz ama onay verilmiyor, türlü bahanelerle yan çiziliyor, uzun müzakereler başlıyor. Siz bütçe kalmadığını, müşteri de bu haliyle ürünün hazır olmadığı defalarca anlatıyor. En sonunda sırf projeyi kapatabilmek için bu özelliği eklemeye de razı oluyorsunuz, ürün çıkıyor ama rakipler daha hızlı davrandığı için müşteri istediği satışa ve pazar payına ulaşamıyor ve mutsuz oluyor. İçten içe de bu kadar uzatmadan o özelliği ekleseydiniz bu kadar geç kalınmayacağını ve projenin başarısız olduğunu düşünüyor.
Bir başka örnek, bir ürüne yeni bir özellik ekleme projesi size ve ekibinize veriliyor. Çalışıp didinip "hedeflere" ulaşıyorsunuz, özellik ekleniyor, ama istenen faydayı sağlamıyor. Başka bir ekibin yaptığı başka bir özellik sizin eklediğinizi işlevsiz kılıyor. Müşteri yine mutsuz. Proje kağıt üzerinde başarılı ama beklenen katma değer yok.
Daha fazla örnek vermek mümkün.Projede başarıyı etkileyen birçok konu var (ilgili makaleler: Projelerde Başarı). Burada bahsettiğim durumlar daha çok kapsam, bütçe ve zaman yönünden başarılı olduğu halde başarısız olarak görülen projelerle ilgili. Siz de hevesle çalıştığınız ama kullanılmayan ürünler/kabiliyetler üreten projeler görmüş ve hayal kırıklığı yaşamışsınızdır. Burada projenin sadece kapsam, bütçe ve zaman yönetiminden ibaret olmadığı, asıl hedefin müşteri veya paydaşlara istenen katma değerin sağlanması olduğunu unutmamak gerekiyor. Müşterinin nihai hedefi kimi zaman pazar payında artış, kimi zaman satışta artış, kimi zaman rakiplerinden önce ürün çıkarmak, kimi zaman sektörde stratejik bir konum olabilir. Müşterinin arka planda düşündüğü strateji, taktik her ne ise o bilinmeden yapılan projede, istenen fayda sağlanamamakta; ne kadar "başarılı" dense de müşteri nezdinde projenin "başarısız" addedilmesine neden olmaktadır.
Bu noktada iki konu öne çıkıyor, ilki müşterinin proje sonrasında ortaya çıkan üründen/çalışmadan beklentilerinin ve statejik, taktiksel hedeflerinin iyi anlaşılıp proje hedeflerinin ve proje başarı kriterlerinin bunlara göre ayarlanması. İkincisi de müşterinin aslında tam neye ihtiyacı olduğunu anlamak için projenin açılışından önce bir "proje ihtiyaç analizi" çalışması yapılması. Proje ihtiyaç analizinde temel olarak alttaki soruların yanıtlanması açılacak projenin sağlığı açısından kritiktir:

• Proje istenen alandaki mevcut durum nedir? SWOT analizi sonuçları nelerdir? Örneğin piyasa payı, pazar büyüklüğü, ürünlerin ve rakiplerin özellikleri, tehditler, fırsatlar...
• Gidilmek istenen ana hedef ve tali hedefler nelerdir?
• Hedeflere gitmek için hangi enstrümanlar (ürün, süreç, kaynak vb.) mevcuttur?
• Yürüyen başka projeler var mıdır, bunların hedefleri nelerdir? Farklı proje hedefleri senkronize midir?
• İş modeli nedir? Hedeflenen iş akışları net midir?
• Fizibilite yapılmış mıdır? ROI, NPV vb. finansal veriler ortaya konmuş mudur) (ilgili makaleler: Finans )
• Çalışma ve proje modeli nedir? Yeni proje açılması gerçekçi bir seçenek midir? 
• Üründen beklentiler nelerdir?

Bu sorulara genel geçer yanıtlar almak da yeterli değil. Müşterinin sizi ikna edebilecek yanıtlar vermesi için sorularınızı açın. Siz de bir proje açılmasına ikna olduktan sonra proje açılışına geçin. Bu sayede hem müşteri beklentilerini size aktarmış olacak hem de "proje istiyorum" demenin ötesine geçerek sizi ve aynı zamanda kendini projenin gerçekten gerekli olduğuna ve doğru işin istendiğine ikna etmeye çalışacaktır. 

Özetle proje yönetimi sadece "işi doğru yapmak" değil aynı zaman "doğru işi yapmak" olarak düşünülmelidir. Proje ihtiyaç analizi de doğru işi başlatmak için bir enstrümandır.

Kazanılmış Değer Analizi Güvenilir mi?

Çoğumuzun duyduğu, bildiği üzere Kazanılmış Değer Analizi veya namı değer Earned Value Analysis (EVA veya EVM), projelerde sıkça kullanılan bir izleme yönetimidir. Bu yöntemin ne zaman güvenilir olduğunu tartışmadan önce kısaca ne olduğunu hatırlatmak isterim. Bilenler için tekrar olabilir, kısaca temel prensiplerini açıklamak isterim. Temel olarak projenin sağlık göstergesi kabul edilen iki parametre üretir, ilki Maliyet Performans Göstergesi veya CPI (Cost Performance Index). Bu parametre projenin herhangi bir andaki üretilmiş değer veya kazanılmış değer ile o değeri üretmek için ortaya konan gerçek maliyetin oranıdır, proje bütçe sağlık durumunu gösterir. Bu değer, her şey plana uygunsa 1.00 olur, planlanandan daha fazla maliyet oluşuyorsa payda büyüyeceği için 1'den küçük, eğer planlanandan daha az maliyetle ilerleniyorsa, 1'den büyük olur. Diğer parametre ise Takvim Performans Göstergesi veya SPI (Schedule Performance Index). Bu parametre, projenin herhangi bir andaki üretilmiş değer veya kazanılmış değer ile planlanan değerin oranıdır, proje takvim sağlık durumunu gösterir. Bu değer, herşey plana uygunsa 1.00 olur, planlanandan yavaş ilerleniyorsa payda büyüyeceği için 1'den küçük, eğer planlanandan daha hızlı ilerleniyorsa, 1'den büyük olur.

CPI ve SPI değerlerini Proje Yöneticisi kendisi mi hesaplar? Genelde hayır, proje yönetim aracı hesaplar, örneğin MS Project, RPM vb. Peki bu değerler güvenilir midir? Proje Yöneticisine bağlı. Hangi proje yönetim aracını kullanırsanız kullanın, EVA'nın özü olan "Kazanılmış Değer" (EV) hatalı olabilir. Çünkü araçlar, Kazanılmış Değer'in somut olarak ne olduğunu bilmedikleri için iş paketlerinde, EV'yi bulmak için kalan iş miktarını (Estimate To Complete-ETC) kullanırlar. Aşağıdan yukarı doğru iş kırılım yapısına göre değerler toplanarak projenin genel sağlığı gösterildiği için tam da bu noktada iki konu kritiklik kazanır, ilki iş paketlerinin yeterli ve anlamlı seviyede detaylı olması, ikincisi iş paketlerini atadığınız kişilerin bunlara efor/maliyet vb. girişlerini yaparken kalan iş miktarını da düşünerek gerekiyorsa ETC değerinin revize edilmesidir.

• İş paketlerini yeterli ve anlamlı kazanımlar detayında planladığınızda bunların tamamlanma durumu doğrudan projeye etki edecektir. Çok yüzeysel ve üst seviye yapılan planlarda, detayda tamamlanan işler EVA'ya bitmiş ve kazanılmış değer olarak yansımayacağı için üst seviyedeki planın tüm alt başlıklarının bitmesini beklemek durumunda kalır. Bu da projenin kazanılmış değerinin üst seviye işler bitene kadar gerçeği yansıtmaması anlamına gelir.
• Diğer konu olan ETC değerlerinin revize edilmesi de oldukça kritiktir, çünkü tamamlanan işin, toplam işin ne kadarına denk geldiğini hesaplayabilmek için ETC elzemdir. Eğer revize edilmezse, plandaki hali hesaplamaya katılacak ve ETC sıfırlandığı anda sanki değer kazanılmış gibi hesaplamaya dahil olacaktır, bu da ciddi bir yanılgı oluşturacaktır.

Yukarıda bahsettiğim detayların önemi CPI ve SPI değerleri 1 ve üzeri olduğu halde geciken veya bütçesini aşan projelerle veya dramatik değişimler içeren veya zikzaklar çizen CPI ve SPI grafikleri ile sabittir :) Kazanılmış Değer Analizi'nin güvenilir sonuçlar vermesi proje yöneticisinin doğru ve detaylı planlamasına ve de ekibin gelişmeleri bu plana doğru yansıtmasına bağlıdır.

Plansız Proje Olur mu?

Plansız proje olmaz dediğinizi duyar gibiyim, aslında bal gibi oluyor :) Peki nasıl? Plan neredeyse proje ile özdeşleşmiş bir kavram. Proje denince ilk aklımıza gelen plandır. Projelerde hepimiz plan yaparız. Hatta Proje Yöneticisinin yegane işinin plan yapmak olduğunu düşünen de vardır. Kimileri planı sadece zaman planı olarak görse de aslında plan gidilecek yolun haritasıdır. İyi bir proje planının zaman, bütçe, kalite, konfigürasyon, risk, tedarik, insan kaynağı, iletişim, eğitim vb. birçok alt planı içermesi beklenir. Bunları proje başında özene bezene yaparız. Plan ilgili kalite süreçlerinden geçirilir, ilgili yerlerden (müşteri, üst yönetim vb.) onayı alınır ve çalışmaya başlanır. İşte ne olursa bundan sonra olur, plan altta kendini bekleyen kaderlerden biriyle karşılaşır:

• Zaten bir ön şart ve zorunluluk için hazırlanmıştır plan. Örneğin şirket süreçleri gereği planın zorunlu olması veya müşteriye afili bir doküman verme gerekliliği gibi. Bu önşart geçilince artık bir kıymeti kalmaz, tozlu raflara terk edilir, unutulur, çalışmaya plansız devam edilir. Zaten plan değil pilav lazımdır :)
• Plan üst yönetim veya müşterinin raflarına konup gerektiğinde ekibi cezalandırmak için referans olarak hazırlanmıştır. İş istendiği gibi sonuçlanmayınca o raftan iner ve özellikle zaman ve bütçe planlarındaki sapmalar, ekibe fatura edilir. Diğer fonksiyonları yok gibidir. 
• Bir diğer seçenek de planın proje boyunca yaşamasıdır. Projede koşullar değiştikçe, yeni riskler/sorunlar çıktıkça, plan da adapte edilir, revizyonlar yapılır. Proje boyunca kılavuzluk görevine devam eder. Galiba bu şekilde hayatta kalabilen planlar azınlıkta, istatistiki bir çalışma yok ama gözlemim bu yönde.

Yukarıda saydığım ilk iki maddedeki planlar aslında görevini yapamayan, kılavuzluk edemeyen dokümantasyondan öteye geçemeyen planlardır. Burada Proje Yöneticisinin öğrenilmiş çaresizliği (ilgili makale: Öğrenilmiş Çaresizlik) de söz konusudur, hatta "ne yapalım bizim işimiz işe yaramasa da dokümantasyon yapmak" diye düşünen arkadaşlarımız da vardır. Risksiz proje olmaz (ilgili makale: Risksiz Proje Olur mu?) ama plansız proje olur :) Bu planlarla yapılan projelerde plan var diyebilir miyiz, bence hayır :)