Çevik Yöntemlere Dönüşüm

Çevik yöntemleri son dönemde sıkça duyuyorsunuz, hatta etrafınızdaki şirketlerden dönüşüm yapanları veya deneyenleri görüyorsunuz. Çevik yöntemlerin kendi kurumunuza da faydalı olacağını düşünüyorsunuz, ancak endişeleriniz var. Aklınızda sorular uçuşuyor:

•  “Dönüşüme nereden başlamalıyım?”
• “Neleri değiştirmeliyim?”
• “Kimleri dahil etmeliyim?”
• “Nasıl yaygınlaştırmalıyım?”
• “Eski alışkanlıklara dönüşü nasıl engellemeliyim? Dönüşümü nasıl kalıcı hale getirebilirim?”
• “Nerede durmalıyım?”
• “Sözde çevik noktasında kalır mıyım?”“Özde çevik olabilecek miyim?”
• “Dönüşümün faydasını ne zaman görürüm?”

Çevik yöntemlere dönüşüm genellikle “hızlı kod yazmaya” başlamak olarak algılanıyor ve IT ekipleri ile sınırlı kalıyor. Özellikle üst yönetim, müşteri ve diğer paydaşlara yeterince anlatılmadığı için yeterince anlaşılamıyor.Dolayısıyla destek alamadığı ve istenen sonuçların ortaya çıkmadığı durumlara çok sık rastlanıyor. Halbuki dönüşüm için müşteri ve üst yönetimin tam desteği olmazsa olmaz. Onlara nelerin nasıl değişeceğini ve sonuçlarının nasıl olacağını anlatmak ve de tam desteklerini almak dönüşümün ilk adımlarından birisi olmalı.

Dönüşümler genellikle kurum çapında geniş katılımlı eğitimlerle başlıyor, eğitimlerde ideal yapılar anlatılıyor. Eğitimden sonra insanlar çevik yaklaşımları beğeniyorlar ancak kendi çalışmalarına nasıl uygulayabileceklerini göremiyorlar. Aradan zaman geçince ve uygulama fırsatı bulamayınca eğitimdeki bilgileri de unutuyorlar.Her ekibin farklı dönüşüm deneyimi oluyor. Kimi tam dönüşemeden iki arada bir derede kalıyor. Yöntemlerini anlatırken de şöyle cümleler kullanıyorlar “çevik ama...”. 

Okuduklarımdan, gözlemlediklerimden ve deneyimlerimden derlediğim birkaç dönüşüm tavsiyesine bu yazıda yer vermek isterim:

• Çevik yöntemlere dönüşümün de bir proje olması ve hatta çevik bir proje olması. Dönüşüm için bir takım kurulması ve yaşayan bir iş listesi (product backlog) oluşturulması.
• Uygulamanın pilot ekiplerle başlatılması ve kademeli olarak yaygınlaştırılması.
• Çevik yöntemlerdeki rollerin iyi anlatılması ve doğru role doğru kişinin getirilmesi (İlgili Makale:Çevik Yöntemlerdeki Rollere Uygun Profiller).
• Planlanan eğitimlerin iki aşamalı olması. İlk aşamada genel çevik yöntemleri içeren bir program, ikinci aşamada ise kurumdaki çevik uygulamanın nasıl olacağının anlatıldığı bir program. Pilot seçilen ekiplerin iki eğitimi de alması ve ardından ekibe dahil edilecek koç ile uygulamanın başlatılması.
•  Farklı takımların deneyimlerini birbiri ile paylaşabilmesi için ortamlar yaratılması.
•  Retrospektiflerin mutlaka etkin yapılması, ekiplerin de gelişim fırsatlarını görmelerinin sağlanması (İlgili Makale:Çevik Yöntemlerde Retrospektif).
•  Tüm ekiplerin çevik yöntemlere geçişinin zorlanmaması. İsteyen, gönüllü olan, müşterileri ve işleri uygun olan takımlardan başlanması süreci kolaylaştırabilir.
• Sabırlı olunması, dönüşümün en az 2 yıla yayılması. Özellikle verimliliğin artması, üretim hızının yükselmesi için acele edilmemesi gerekiyor.
•  Dönüştükten sonra durulmaması, çevik yöntemleri daha etkin kullanabilmenin yollarının araştırılması. Bu noktada Kai-zen felsefesi ve bu felsefede olan “mükemmel yoktur, daha iyisi vardır” yaklaşımı benimsenebilir.

Bunlardan başka  önemli noktalar da muhakkak var. Bence en önemli olan zorlukları görünce pes etmemek, dönüşüme azimle devam etmek ve de gerçekten uygulayabilmek (İlgili Makale:Çevik Yöntemleri Uygulayabilmek).

Savuşturmacı Kültür

Alttaki türden yanıtları sıkça duyuyor musunuz?

• “Bakarız”
• “Sonra yapalım”
•  “Daha zaman var”
• “Daha acil işler var”
•  “Yönetime sormak lazım”
•  “Bu konudan ben sorumlu değilim”
• "Buna ne gerek var”

Bu liste uzayıp gidebilir. Bu yanıtları alınca içinizden ne geçiyor, ne düşünüyosunuz? Karşımızdakinin bir şeyi yapabilecekken yapmadığını, işten kaçındığını veya ötelediğini, değil mi? Hatta bazen karşımızdakinin zamanının olduğunu, yetkisinin uygun olduğunu ve dahası kendi işi olduğunu bilsek bile bu yanıtı alıp şaşırdığımız oluyor. O kadar yaygın ki aile içi ilişkilerde, arkadaşlar arasında bile bu durumlara çok sık rastlanıyor. Esas itibariyle hem iş hayatında hem de günlük hayatımızda çokça karşılaştığımız durumlar bunlar. Literatürde tarayabildiğim kadarıyla bir sınıflamasını bulamadım ve Savuşturmacı Kültür adınının uygun olabileceğini düşündüm. Eğer bir yerde geçiyorsa ve atlamışsam kusura bakmayın ve lütfen beni de bilgilendirin.

Savuşturmacı Kültür’ün iki stratejisinin olduğunu düşünüyorum, ilki yukarıda örneklerini vermeye çalıştığım, “işi yapmama veya öteleme”, ikincisi ise “yapılmış gibi, olmuş gibi, doğruymuş gibi gösterme”. İkinci stratejide işle veya durumla ilgili sorulara gerçek dışı yanıtlar verme, olduğundan farklı ve iyi gösterecek bilgilendirmeler yapma esastır. Bir çalışanınıza işin durumunu sorduğunuzda aldığınız şu tür yanıtlar bu duruma örnek gösterilebilir:

•  “Bitmek üzere”
•  “Sorun yok”
•  “Risk yok
•  “Hallediyoruz”
•  “Yetişir”

Bu güzel bilgilendirmeler sonunda yönetici konumundaysanız içinize su serpilir, rahatlarsınız. Ama işin aslı öyle değildir ve nitekim işin sonunda beklenen sonuç ortaya çıkmaz, sorun olduğu da ancak duvara çarptıktan sonra ortaya çıkar.

 

İşin bitmemesi, gecikmesi veya hatalı olması durumunda da iyi bir bahane bulunması veya günah keçisi tespit edilip tüm sorumluluğun ona yüklenmesi  Savuşturmacı Kültür’ün tamamlayıcı savunma stratejisidir. Hatta çalışma boyunca “işi nasıl iyi ve zamanında yaparım?” sorusu değil “nasıl ikna edici bir bahane bulurum?”, “başarısızlığın sorumluluğunu neye bağlayabilirim?”,“kimi günah keçisi yapabilirim?” türünde sorular da zihinleri meşgul eder. İşin sonunda sorunun kaynağını sorduğunuzda hep başka birisi hatalıdır veya başka bir kurum işini iyi yapmamıştır.

Bir kurumda Savuşturmacı Kültür ne kadar hakimse verimlilik ve etkinlik o kadar düşüktür. Kuruma sonradan katılanlar da ister istemez bu kültürün etki alanına girerler. Kimsenin iş yapmak istemediği, bunu da farklı bahanelerin arkasına saklanarak dolaylı dile getirdiği bir ortam oluşur. Yürüyen işler gereği gibi şeffaf raporlanmaz, tüm işlerin sorunsuz ilerlediği yanılgısı oluşturulur. Bu sorunsuz(!) işlerin sonuçlarındaki başarısızlıklar da hep başka bir etkene bağlanır veya yanlış kişilere fatura kesilir. Başarısızlığın sebeplerinin yanlış teşhis edilmesi sonucu ortaya çıkar ve yanlış tedaviler uygulanır. Bu tedavilerde istenen sonuçlar alınamaz ancak Savuşturmacı Kültür bu noktada da devreye girerek kök sebebe inilmesine izin vermez.

Bir çok kurumda Savuşturmacı Kültür’ün hakimiyeti bulunuyor ve maalesef farkına varılamıyor. Savuşturmacı Kültür’ün panzehirinin alttaki adımlardan geçtiğini düşünüyorum:

• Bahane üretme yerine Sorumluluk Alma: İşin yapılmaması için bahane üreten kişilerin teşvik edilmediği; sorumluluk alarak işleri yapma motivasyonu taşıyan kişilerin ödüllendirildiği bir çalışma ortamının oluşturulması.
• Yanlış raporlamalar ve manipülasyon yerine Şeffaflık: Yanlış, eksik veya yanlı raporlamaların, bilgilendirmelerin kabul edilmediği; sorunların/risklerin tespit edildiği anda şeffaf olarak aktarıldığı durumların kabul gördüğü iletişim ortamının sağlanması.
• Başkasını suçlama yerine Özeleştiri Yapabilme: Hatayı hep dışarıda aramanın, başkalarını suçlamanın uygun bulunmadığı; iğneyi kendine de batırmanın öneminin vurgulandığı özeleştiri alışkanlığının kazandırılması.

Çevik Yöntemlerdeki Rollere Uygun Profiller

Çevik yöntemlerdeki rollerden daha önce bahsetmiştik (İlgili Makale: Çevik Yöntemlerde Roller). Bu rollere uygun profiller neler? Kim hangi role daha uygun? Ürün Sahibi ve Çevik Proje Yöneticisi rollerinin altından kim kalkabilir? Herkes Geliştirme Takımı'nda yer alabilir mi? Bu yazıda bunlara değineceğiz.

• Geliştirme Geliştirme Takımı Üyesi Profili:

• Temel Çevik Yöntem Bilgisi: Çevik yöntemlerin bütün süreçlerini bilmesinde fayda var, ancak uzman seviyesinde olması beklenmiyor.
• İşbirliğine Yatkın ve Uyumlu: Takım içinde birlikte çalışmaya yatkın, takımın kalanı ile uyumlu ve ılımlı geçinebilmesi takımın ahengi için olmazsa olmaz bir özellik.
• Organize: Kendini organize edebilen bir takım kurabilmek için kişilerin de işlerini organize yürütebilmesi ve başkalarının arkalarını toplamasını beklememeleri gerekiyor.
• Pro-aktif: Harekete geçmek için bir sorun/engel oluşmasını beklemeyen veya motivasyon için başkasına ihtiyaç duymayan kişilikte olması gerekiyor.
• Yeterli Teknik Uzmanlık:  Çevik yöntemlerde teknik mükemmeliyet ön planda tutuluyor.  Hem sağlam ve esnek tasarım hem de hızlı üretim için teknik yeterlilik en temel ihtiyaç. Uzmanlık bazen hafife alınan bir kavram ne yazık ki. Bir konuda uzman olabilmek için o konuda yeterli bilgi ve tecrübe sahibi, konuyu farklı yönleriyle incelemiş, alternatifleri bilen, derinlemesine bilgi sahibi bir profilden bahsediyoruz.  Uzmanın sadece yapabilen değil, aynı zamanda en iyisini yapabilen olması gerekiyor.
• Takım oyuncusu: Çevik yöntemlerde bireysel başarıdan ziyade takım başarısı ön planda, tıpkı spor müsabakaları gibi takımın başarılı olmadığı durumlarda bireysel başarıdan da söz etmek mümkün değil. Dolayısıyla iyi takım oyuncusu olan profiller çevik yöntemlere daha yatkın olacaktır.
• Sorumluluk sahibi: Çevik yöntemlerde kimse takım üyelerine iş atamıyor, bilakis kendileri iş listesinden yapabileceklerini seçip sorumlu olduklarını o iterasyonda tamamlamaya çalışıyorlar. Dolayısıyla her takım üyesinin sorumluluk sahibi olması çok önemli.

• Ürün Sahibi Profili:
• Çevik Yöntem Uzmanı: Çevik yöntemleri iyi bilen, hem kendi hem de takımın sorumluluklarına hakim olması çalışmayı ve ürünü doğru yönlendirmede oldukça önemli. Ürün vizyonuna nasıl ulaşılacağını çevik yöntemlerin sağladığı yollarla belirlemesi gerekiyor.
• İş Alanı Uzmanı: İlgili ürünün iş modelini yapısını çok iyi bilmesi, rakipleri tanıması gerekiyor. Müşteriler ile teması olması ve onların hedeflerine de aşina olması elzem.
• İletişim ve Müzakere Becerileri: Hem müşteri hem de geliştirme takımı ile yapacağı görüşmelerde iletişim becerilerine çok ihtiyacı olacaktır. Gerekli noktalarda müzakere yapabilmesi de ihtiyaçlardan bir diğeri. 
• Pro-aktif: Tıpkı geliştirme takımı üyeleri gibi harekete geçmek için bir sorun/engel oluşmasını beklemeyen veya motivasyon için başkasına ihtiyaç duymayan kişilikte olması gerekiyor.
• Karar Verici: Ürünü doğru yönlendirebilmek doğru ve hızlı karar verebilmek bir diğer ihtiyaç duyulan özellik. Karar verirken alternatifleri görebilen ve en faydalıyı seçen bir yaklaşıma ihtiyaç duyuluyor. 
• Pragmatik: Yaptığı çalışmalarda ürünün faydasını ön planda tutan, vizyona katkısını takip eden bir yaklaşıma her zaman ihtiyaç olacaktır.

• Çevik Proje Yöneticisi:
• Çevik Yöntem Uzmanı: Çevik yöntemleri iyi bilen, hem kendi hem de takımın sorumluluklarına hakim olması çalışmayı doğru yönlendirmede oldukça önemli.
• Hizmet Eden Liderlik: Bu çok önemli bir kavram. Klasik yönetim tarzındaki iş ver-takip et (command and control) veya direktif verici liderlik anlayışları çevik yöntemlerde istenmiyor. Bunun yerine koçluk edebilen, takımın önünü açan liderlik anlayışı ön planda tutuluyor. Takımın zaten ne yapması gerektiğini bildiği, yöneticinin detaylara karışmasına gerek olmadığı farz ediliyor.
• Problem Çözme Becerileri: Takım içinde veya takımla paydaşlar arasındaki  iletişim kazalarında devreye girebilmesi bekleniyor. Ayrıca takımın getireceği farklı problemlerde doğru çözüme ulaşılmasını sağlaması gerekiyor. Her problemi çözmesi beklenmiyor, çözümün Takım tarafından bulunmasında katalizör rolü oynaması yeterli olacaktır.
• Motivasyon Verebilen: Motivasyon çok geniş bir kavram, burada beklenti takımın çalışma boyunca motivasyonunu koruyabilmesi için gerekli önlemleri alabilmesi.
• Koçluk Yapabilen: Takıma hizmet eden liderlik çerçevesinde yöneticilikten ziyade koçluk yapması ve takım üyelerinin gelişimini sağlaması oldukça önemli. Koçluk da geniş bir kavram.
• Erişilebilir, Konuşması Kolay: İletişim becerilerinin iyi olmasının yanında, takımın rahatlıkla ulaşabildiği, konuşmaktan çekinmeyeceği bir mizaçta olması çok fayda sağlayacaktır.

Yukarıdakilere farklı özellikler de eklemek mümkün. Öte yandan bu profillerde çalışan bulmak kolay değil; bulunup bir araya getirilince mayanın tutacağının yani takım olunacağının garantisi de bulunmuyor. Bu konuda üst yönetimin desteği ve insan kaynakları politikalarının gözden geçirilmesi ile Takım Olmanın değerli kılınması kuşkusuz çok önemli. Takım olabilmek için de güven sağlanması ilk ve en önemli adım (İlgili Makale: Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği). Kişisel görüşüm bireysel başarıları destekleyen günümüz iş dünyasının zamanla değişeceği ve takım başarılarını ön plana çıkaran yaklaşımların er geç benimseneceği...

Çevik Yöntemlerde Roller

Çevik Yöntemleri farklı boyutları ile daha önce 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 Toplantılar). Bu yazıda rollerine değinmek istiyorum. Çevik Yöntemlerle çalışan takımlarda bildiğimiz hiyerarşik ve sorumlulukların çok net ayrıştırıldığı roller bulunmuyor. Bunun yerine daha az sayıda kişiden oluşan ve kendini organize edebilen takımlar kuruluyor. Farklı Çevik Yöntemlerde isimleri farklı olsa da benzer özellikler içeren alttaki temel roller mutlaka yer alıyor:

• Müşteri Temsilcisi veya Ürün Sahibi (Product Owner): Ürünü tarif eden, öncelikleri belirleyen ve yapılanları değerlendiren kişi. Ürün Sahibi'nin özellikleri:
• 1 kişi
• Müşteri ve diğer paydaşlarla iletişim
• 'Ne’ sorusuna odaklı
• İş maddelerinde son karar verici
• Ürün İş Listesi yönetimi ve önceliklendirilmesi
• Ürün vizyonunu belirlenmesi
• İterasyon sonunda ürün ve/veya özelliklik kabulü
• Yapılan işin ekonomikliği (ROI) takibi
• Geliştirme Takımı (Development Team): Farklı becerileri
  olan kişilerden oluşan, yazılımı, entegrasyonu ve birim testi yapabilen takım. Kimseden talimat beklemeden işlerini planlayıp ilerleyebilen, destek gereken noktaları ayırt edip eskale edebilme becerisine sahip. Geliştirme Takımı'nın özellikleri:
• 4-9 kişi
• Belirlenen kalite standartlarına uyulması
• ‘Nasıl’ sorusuna odaklı
• İterasyona alınacak işlerin seçilmesi ve gerçekleştirilmesi
• Kendini organize edebilir
• Farklı yetkinlikler içerebilir
• Çevik Proje Yöneticisi (Agile Project Manager): Takımın önünü açan, işin detaylarını
  yönetmeye çalışmayan lider kişi. Bildiğimiz Proje Yöneticisi işlevlerini yapmıyor. Örneğin zaman, kapsam, takvim ve kalite yönetiminden sorumlu değil. Çevik Proje Yöneticisi'nin özellikleri:
• 1 kişi
• İşlerin kolaylaştırılması
• Takıma gelebilecek dış etkilerin giderilmesi
• Takımın önündeki engellerin kaldırılması
• Müşteri ve diğer paydaşlarla iletişim
• Sürecin doğru işletilmesine odaklı
• Takıma hizmet eden liderlik profili

Yukarıdaki rollere sahip kişiler takım olarak çalıştıkları ve başarı/başarısızlık herkese ait olduğu için klasik ekiplere kıyasla iletişim ve verimlilik anlamında fark yaratabiliyor. Bu fark için Çevik Yöntemler'e üst yönetimin de destek vermesi ve takımın önünü açması tabi ki en önemli koşul. Bir çok yönetici için bu durum çok kolay değil, çünkü ekiplerine talimat vermeleri ve işleri kontrol etmeleri Çevik Yöntemler'de pek de istenmeyen bir durum. Hatta takımların kendi içinde organize olabileceğine birçok yönetici ilk aşamada inanmıyor bile... Üst yönetimin desteğini almak içinse çoğu zaman örnek projelerle Çevik Yöntemler'in çıktılarını somut olarak göstermek en iyi ikna yöntemi oluyor. 

Ç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.