Scrum Takımı, Tamamlandının Tanımını ne zaman hazırlamalıdır? Scrum Kılavuzu bununla ilgili herhangi bir bilgi vermez, sadece bunun var olması gerektiğini ifade eder.
Bunun nedeni, Scrum’ın bir çerçeve olmasıdır. Adım adım ne yapmanız gerektiğini açıklayan bir metodoloji değildir.
Peki, bu durumda, Tamamlandının Tanımı ne zaman oluşturulmalıdır? Cevap, ne zaman isterseniz.
Çoğu zaman, insanlar her şeyin Scrum etkinliklerinden birinde olması gerektiğini düşünür ve bu doğru değildir.
Scrum Takımı, kendi içinde belirsizlikleri giderecek şekilde farklı toplantılar yapabilir. Bu, Scrum tarafından yasaklanmış değildir.
Scrum Takımının, ilk Sprint başlamadan önce Tamamlandının Tanımının ilk versiyonunu hazırlanmasında hiçbir sakınca yoktur. İlk hali, mükemmel veya nihai olmak zorunda değildir.
Zamanla ihtiyaçlar şekillendikçe veya kalite sorunları yaşandıkça, tamamlandının tanımı da gelişir. Özellikle, Retrospektif toplantılarında ekip deneyimlerini paylaşarak, Tamamlandının Tanımını iyileştirmek için önerilerde bulunabilirler.
Pratik açıdan bakıldığında, zorunlu olmadıkça, sprintin ortasında Tamamlandının Tanımını değiştirmek çok tercih edilen bir yöntem değildir. Bunu bir oyunun kurallarını oyun başladıktan sonra değiştirmek gibi düşünebilirsiniz. Kurallar, oyun başlamadan önce belirlenir. Eğer istenmeyen bir sonuç ile karşılaşılırsa, kurallar, oyun tekrar başlamadan önce oyuncular tarafından konuşulur, anlaşmaya varılır ve oyun ondan sonra başlar.
Tamamlandının Tanımını Sprint’in ortasında değiştirmek tahmin değerlerini ve tamamlandığı düşünülen işleri olumsuz etkileyebilir.
Bu derste, tamamlandının tanımı ifadesine biraz daha detaylı göz atacağız. Bir önceki videomuzda “Başlangıç Sayfası Oluşturma” öğesi için kabul kriterlerini tanımlamıştık.
Burada gördüğünüz ifadeler ise “Başlangıç Sayfası Oluşturma” adlı ürün birikim öğesi için daha detaylı hazırlanmış ve kriterleri gösteren bir örnektir. Yazılanların doğruluğu veya detay seviyesi önemli değildir. Bu örnek, yazılımla ilgili olduğu için, ekranda göreceğiniz ifadeler, bazılarınız için anlamsız olabilir. Bu ifadelerin sadece bir örnek olduğunu dersimiz boyunca unutmayınız.
Öncelikle, tamamlandının tanımı bir kontrol listesi gibi görünse de, Scrum literatürü içinde kontrol listesi ifadesi kullanılmaz. Bu durumu, doktorların veya avukatların kullandığı özel kelimeler gibi düşünebilirsiniz. Her disiplinin kendine özel kavramlarının olması normaldir. Önemli olan bu kavram yapısını bilmek ve diğer meslektaşlarla aynı dili konuşabilmektir.
Konumuza dönersek; bir ürün birikim öğesinin tamamlanmış olarak kabul edilmesi için aşağıdaki kriterlere uyması gerektiği gözükmektedir.
Bu listede ilk maddeye baktığımızda “Kabul Kriterlerinde belirtilen şartların sağlanması” ifadesi gözükmektedir. Bir önceki dersimizde, bu maddeler hakkında örnekler paylaşmıştık. Bu kriterler, genellikle ürünün nasıl gözükeceğini içeren özelliklerdir. Kabul kriterlerinin neler olduğunu görmek için 12.video olan Artırım ve Tamamlandının Tanımı adlı videoyu izlemenizi tavsiye ederiz.
Şu an ekranımızda ise ürünün etkin çalışabilmesi için uyulması gereken farklı kriterlerden de bahsedilmiştir. Bu kriterler, ürün sahibinin bilemeyeceği kriterler olabilir. Bu yüzden, bu kriterler, Scrum takımı tarafından hazırlanır.
Örneğin, hazırlanan kodun, uzman bir geliştirici tarafından gözden geçirilmesi kriteri, daha sonra oluşabilecek kusurları engelleyebilir ve deneyimsiz olan geliştirme ekibinin yeni şeyler öğrenmesini sağlayabilir.
Teknik dokümanın hazırlanmış olması ifadesi, ilgili sayfanın bilgi akışı veya süreç akışını gösteren içerikler olabilir. Bu bilgiler, baştan belgelenmediği takdirde, ve sistemin zamanla büyümesi durumunda, sistemin kontrolü imkansız hâle gelebilir.
Birim testinin geçmesi, hazırlanan fonksiyonun doğru çalışıp, çalışmadığını test etmek ve onaylamak iken, kabul testinden geçmek sistemin bir bütün olarak kabul edilebilir olmasıyla ilgili testlerdir.
Sistemin farklı web tarayıcıları üzerinden test edilmesi ve o tarayıcılarda da sorunsuz çalışması bir başka kriter olarak gözükmektedir. Benzer bir değerlendirme, mobil cihazlar için uygulanabilir. Oluşturduğumuz giriş sayfasının farklı cep telefonlarının ekranlarında nasıl gözüktüğü bir kabul kriteri olabilir.
Bütün bunlara ek olarak fonksiyonel olmayan gereksinimler altında performans, uygunluk ve güvenlik gibi kriterler tanımlanabilir ve üretilen birikim öğesinin bu kriterleri de sağlayıp, sağlamadığı denetlenmiş olur.
Bütün bu kriterlerin olumlu sonuç vermesi halinde, ilgili birikim öğesi “tamamlandı” olarak kabul edilmiş olacaktır.
Müşteri veya ürün sahibi, Sprint içinde geçen süreyi ve harcanan eforu sadece istenen ürünü üretmek olarak düşünmemelidir. Karmaşık bir projede, burada örnek olarak gözüken kabul kriterlerinin sayısı onlarca olabilir. Bu yüzden, Scrum ekipleri, ortaya çıkaracakları ürün birikim öğesinin bu kriterlere uyup uymadığını test etmek zorundadır. Bir projede, ekipleri acele ettirmek, diğer ifadeyle, az zamanda çok fazla şeyi talep etmek ve ekibe baskı kurmak, kalite kriterlerinin yeterince sağlanmadan ürünün teslim edilmesine sebep olur. Bu da, ortaya çıkan ürünün kalite sorunları yaşamasına, ve ekibin düzeltmeler yapmak için tekrar tekrar ürün üzerinde çalışmasına, neden olur.
Artırım, ürünün yeni bir sürümüdür ve önceki tüm sprintlerden gelen artırımlara eklenir.
Bunu, tamamlanmış önceki tüm işlerin üzerine yerleştirilmiş bir yapı taşı gibi görebilirsiniz.
Geliştiriciler, her sprintte en az bir adet yeni ürün artırımı sağlamak için çalışır.
Her yeni artırım, ürünün geliştirilmiş ve kullanılabilir bir sürümüdür.
Artırımın, müşterinin kullanımına sunulma zamanına, yani yayınlanmasına, sadece ürün sahibi karar verir. Bununla birlikte, artırımın kendisi, test etme, belgeleme ve hatta diğer Scrum ekiplerinin yaptığı işlerle entegre etme gibi, herhangi bir ek çalışmaya ihtiyaç duymayacak şekilde, kullanılabilir olmalıdır.
Bir ürün birikim öğesi tamamlanmış olarak kabul edildiğinde, herkes tamamlanmış ifadesinin ne anlama geldiğini anlamalıdır.
Çoğunlukla “tamamlanmış” ifadesi için kalite yönetiminden bildiğimiz kabul kriterleri referans alınır.
Eğer 7. videoda başlattığımız örnekte, ilk ürün birikim öğemiz “Başlangıç sayfası oluşturmaktı. Sonraki bir videomuzda bu öğe için kullanıcı hikayesi yazmıştık. Bir başka videomuzda ise kabul kriterlerini tanımlamıştık.
Kurumun logosu sayfada gözükmeli.
Marketin bina görseli sayfad gözükmeli.
Şirketin adresi, telefon numarası ve email adresi sayfada gözükmeli.
Yine bir başka videomuzda, ekibin yönlendirmesiyle, ürün sahibi, kabul kriterlerinin içine şu iki maddeyi eklemişti.
Logo dijital olarak çizilmiş olmalıdır.
Binanın fotoğrafları profesyonel olarak çekilmiş olmalıdır.
Tam bu noktada lütfen dikkat. Kabul kriterleri hiç bir zaman subjektif ifadeler içeremez. Dikkat ederseniz, “Profesyonel fotoğraf çekimi” ifadesi bile yoruma açıktır. Bu yüzden, çekilecek fotoğrafların çözünürlüğü sayısal verilerle ifade edilmelidir. Amaç, çıkan sonucun ki bu örnekte çekilen fotoğrafların çözünürlüğü, yoruma açık olmaksızın, test edilebilir ve doğrulanabilir olmalıdır.
Her sprint, kalite planlamayı ve kalite kontrolü kendi içinde barındırır. Scrum ekibi, sprint sonlarında yapacakları retrospektif toplantısında öğrendikleri derslerden yola çıkarak, kaliteyi sürekli artırmanın yollarını arayacaklardır.
Scrum’ın en kafa karıştırıcı kısımlarından biri, sprint kapsamı ile sprint hedefi arasındaki farkı anlamaktır. Sprint hedefi sabit kalmakla beraber, sprint kapsamı müzakereye açık bir konudur. Bu dersimizde bu konuyu tüm yönleriyle ele alacağız.
Hemen basit bir örnekle konuyu netleştirmeye çalışalım. Bu hafta sonu evinizde temizlik yapmaya karar verdiğinizi varsayalım. Bu çerçevede, sprintin amacını, temiz bir yaşam alanına kavuşmak şeklinde tanımlayabiliriz. Kapsam, bu hedefe ulaşmak için yapmak istediğiniz çalışmanın ne olduğudur.- Örneğin, Elektrik süpürgesiyle yerleri tozunu almak, ardından yerleri nemli bezle silmek, çamaşırları yıkamak, camları silmek, mutfak dolaplarının içini temizlemek şeklinde detaylar oluşturulabilir. Amaç aynı kaldığı sürece sprintin kapsamı ekip tarafından müzakere edilebilir.
Hafta sonu işe giriştikten sonra, eğer belirlediğiniz kapsamın yetişmeyeceğini fark ederseniz, kapsamı daraltabilirsiniz. Örneğin, mutfak dolaplarının içini temizlemeyi bir sonraki sprint’e bırakma kararı verebilirsiniz. Bu durumda, kapsamınız biraz değişmiştir, fakat temiz bir yere ulaşma hedefinizde değişiklik olmamıştır.
Bu yüzden, sprintin bir hedefinin olması sizi odaklanmanız gereken konu üzerinde, sabit tutacaktır. Hedefe odaklandığınız takdirde, çalışma kapsamınızın içine hiç bir zaman “arabanızı temizlemek” gibi bir aktivite girmeyecektir.
Bununla birlikte, başta hiç düşünmediğiniz detaylar, bir anda karşınıza çıkabilir ve kimi zaman sprint kapsamını, hatta ürün birikim listesini etkileyebilir. Bunu da bir örnekle açıklayalım. Hafta sonu temizliğe başladınız ve oturma odasındaki resim albümlerinin tozunu alırken fark ettiniz ki, pek çok aile resmi, albümlere girmeden karışık bir biçimde büyükçe bir kutunun içinde duruyor. Resimleri tarih sırasına göre albüme dizme fikri aklınıza gelebilir. Fakat bu işi baştan hiç düşünmemiştiniz ve o hafta sonu yapılacak temizlik kapsamına dahil etmemiştiniz. İşin büyüklüğüne göre, diğer Scrum ekibinin değerlendirmesine de başvurarak bu işi mevcut sprintin kapsamına alabilir veya ürün sahibine öneride bulunup, fotoğraf albümlerinin düzenlenmesini yeni bir ürün birikim listesi öğesi olarak ekletebilirsiniz.
Sprint hedefine doğru ilerlerken kesinlikle vazgeçilmez olan kriter, kalitedir. Kapsam içinde yapılacak çalışmaların ulaşılması gereken sonuçları için kabul kriterleri tanımlanmalıdır. Kabul kriterleri hakkında detaylı bilgi sonraki videolarımızın içinde yer alacaktır. Kaliteden ödün vermeyecek şekilde ilerlemek, bazen kapsamdan feragat etmeyi gerektirebilir ve bu durum normaldir.
Bu konuyla ilgili olarak, proje yönetiminde şu iki kavram arasındaki ödünleşmeyi sürekli dikkate almak gerekir. Bir ürünün sınıfı, o ürünün içindeki özelliklerinin sayısını ifade etsin. Müşterinize yüksek sınıflı bir ürün teslim etmeye çalıştığınızı varsayalım. Fakat, sizi o kadar acele ettiriyorlar ki, bazı özelliklerin çalışıp, çalışmadığından emin olmadan, yani test etmeye zaman kalmadan, ürünü teslim ediyorsunuz. Özelliği fazla, fakat çalışıp, çalışmadığından emin olmadığınız bir ürünü, müşterinize teslim etseniz, içiniz rahat olur muydu?
Buna karşılık, özelliği az, ama en azından çalıştığından emin olduğunuz bir ürünü, müşterimize teslim etseniz içiniz daha rahat olurdu, elbette. Şunu lütfen unutmayalım; kaliteden ödün verilmediği takdirde kapsamı genişletmek çok kolaydır. Fakat kalite sorunu yaşayan bir ürün, proje ekibinin sürekli hata düzeltmek için efor ve zaman harcamasına sebep olacaktır.
Her sprint planlama toplantısında ürün sahibi, ürünün değerini, diğer ifadeyle kıymetini, artırmak için bir sonraki adımda yapılması gerekeni Scrum ekibine anlatır. Ve tüm Scrum ekibi, sonraki sprintin hedefini oluşturmaya odaklanır.
Scrum ekibi, ürün sahibi ile işbirliği yaparak, ürün birikim listesinin en üstünden başlayarak hangi öğelerin sprint birikim listesine ekleneceğine karar verecektir.
Ayrıca, sprint birikim listesi, ürün artışını sağlamak ve sprint hedefini gerçekleştirmek için bir plan içerir.
Tam bu noktada, ürün birikim listesi ile sprint birikim listesi arasındaki farkı anlamak için kısa bir açıklama yapalım.
Ürün birikim listesi, üründe olması gereken veya olabilecek fikirlerin veya özelliklerin sıralı bir listesidir. Sprint birikim listesi, her sprint’in başında sıfırdan oluşturulur ve mevcut sprint’te yapılacak ürün iş listesi öğelerini ve planı içerir. Sprint birikim listesindeki tüm öğeler, ürün birikim listesinden gelir.
Plan ise ortaya çıkacak fonksiyonun ve sprint hedefinin nasıl sağlanacağını açıklar. Plan, scrum ekibinin bir artış oluşturmasına izin veren ürün birikim listesi öğesinin ayrıştırılmasıdır. Ayrıştırma ile sprint içinde yapılacak aktiviteler tanımlanmış olur.
Ürün birikim listesi kalemleri, NE’yin teslim edileceğini açıklar. Plan, bunun NASIL olacağını ele alır. Sprint hedefi, sprintin NEDEN değerli olduğunu gösterir. Hepsi, sprint birikim listesinin bir parçasıdır.
Scrum ekibi, bir sprint için ürün birikim listesi öğelerini seçtiklerinde, neyin teslim edileceğine dair bir tahmin oluşturmuşlardır. Sprint için yapılan tahminler asla bir garanti, söz veya taahhüt değildir. Sprint sırasında beklenmedik şeyler olabilir.
Sprint birikim listesini, yalnızca sprint sırasında var olan geçici bir yapı olarak görüntüleyebilirsiniz. Her sprintin yeni bir sprint birikim listesi olacaktır. Sprint’in sonunda sprint birikim listesinde kalan herhangi bir bitmemiş iş, ürün birikim listesine geri konulacaktır.
Bundan sonra ne olması gerektiğine ürün sahibi karar verecektir. Ürün birikim listesi, ürün sahibinin sorumluluğundayken, sprint birikim listesinden, scrum ekibi sorumludur.
Ekip, sprint hedefine ulaşmak için, sprint boyunca gerekli gördükleri değişiklikleri yapabilir. Yapılması gereken işleri belirlediklerinde, sprint birikim listesine eklemeler de yapabilirler.
Sprint birikim listesinde kalan toplam iş, her gün en az bir kez yapılan toplantı ile takip edilir. Ekip üyeleri, sprint hedefine doğru ilerlemeyi takip etmekten sorumludur.
Scrum’da ürün birikim listesi, şeffaflık, denetim ve adaptasyon için fırsatlar sağlamak üzere tasarlanmış bir eserdir.
Ürün birikim listesi, üründe ihtiyaç duyulan her şeyin sıralı bir listesidir.
Birikim listesi, var olanlara ek, yeni özellikler, iyileştirmeler veya değişiklikler içerebilir.
Ürün birikim listesindeki her bir madde, ürün birikim öğesi olarak adlandırılır.
Bir birikim öğesinin, açıklaması, sırası, boyutu ve değeri gibi özellikleri tanımlanır. Ayrıca, işin tamamlanıp tamamlanmadığını test etmeye yardımcı olacak kabul kriterleri de yer almalıdır.
Ürün birikiminden sorumlu kişi, ürün sahibidir.
Ürün birikim listesinde değişiklik yapma faaliyetine ürün birikim yönetimi diyoruz.
Peki ürün birikim listesi tam olarak nasıl oluşturulur ve yönetilir?
Her şey, bir hedef veya vizyonla başlar.
Ürün sahibinin, ürünün ulaşması gereken hedefi tanımlaması beklenir.
Ürün sahibi, paydaşlarla sürekli işbirliği yaparak, piyasa koşullarını, rakipleri, yasal düzenlemeleri inceleyerek iş gereksinimlerini belirler.Ürün birikim listesinde sadece ve sadece ürün hedefine ulaşmamıza yardımcı olacak öğeler bulunmalıdır.
Ürün hedefi, ürün birikim listesi için bir taahhüttür. Bir seferde, sadece, bir ürün hedefi olmalıdır.
Ürün birikim listesini yönetmek, devam eden bir süreçtir. Ürün sahibi ise, ürün birikim listesinden sorumludur ve istediği zaman ürün birikim listesi öğelerinin sırasını değiştirebilir, yenilerini ekleyebilir veya var olanları çıkarabilir.
Ürün sahibinin, geliştirme ekibiyle yakın çalışması çok önemlidir. Ürün birikim listesi iyileştirme etkinliği sırasında, ürün sahibi ve geliştiriciler, büyük öğeleri daha küçük parçalara bölmek için işbirliği yapar. Öğeler, ne kadar küçük olursa, yönetimi ve kontrolü o kadar kolaylaşır.
Ayrıca, ürün birikim listesi üzerinde, öğelerin detaylarını, boyutunu ve sırasını belirlemek için de çalışacaklardır. Bir öğenin boyutu, işi yapma çabasının ne kadar büyük veya küçük olduğunu gösterir. Bir öğenin boyutunu bulma işlemine, boyutlandırma veya tahmin etme denir.
Ekip üyeleri, yani geliştiriciler, boyutlandırmadan sorumludur.
Ürün birikim listesi, ürün yaşadığı sürece mevcut olan bir belgedir. Ürünün kendisiyle birlikte büyür ve iş gereksinimlerine, pazar koşullarına, kanunlardaki değişikliklere ve buna benzer faktörlere göre içeriği değişir.
Ürün birikim öğlelerinin, bir sonraki sprint için seçime hazır oldukları kabul edilir. Bu, öğelerin bir sprint içine sığacak kadar küçük olduğu anlamına gelir. Böylece, ekip hemen bu gereksinimler üzerinde çalışmaya başlayabilecektir.
Sanal grupların başarılı işler çıkaracağına inancım çok eskilere dayanır.
1999 yılında firstname.lastname@example.org adlı sanal grubu kurmuştum. Sonra adı, email@example.com olmuştu. Yıllar içinde 1000 kişiden fazla üyesi olmuştu grubumuzun ama etkileşim çok sınırlı kalmıştı.
Yanlış hatırlamıyorsam 2008 yılında Google Groups’da Proje Yönetimi içerikli bir grup kurmuştum, sonrasında ilgilenemediğim için kapatmıştım ama Google Groups halen devam ediyormuş ve bakın ne buldum?
15 Kasım 2008’de PMI Türkiye Grubunun üyesiymişim ve o yıllarda yapılan kongre davetiye mesajları hala duruyor.
2010 Eylül ayında Linkedin üzerinden açtığım Proje Yönetimi grubundan şu anda 1900 üyesi var fakat sınırlı sayıda kişi paylaşım yapıyor.
Discord Kanal’ı herkese açıktır ve proje yönetimi temelinde herkes istediğini paylaşabilecektir. Umarım, proje yönetimine gönül verenler için faydalı olur.
Şimdilik ana başlıklar aşağıdaki gibi. Yeni kanal başlıkları için lütfen öneride bulunun.
Projelerde eğitim planı geliştirmenin ilk adımı, paydaşların ihtiyaç duyacağı gerekli becerileri belirlemektir.
Eğitimler, bilgi birikimi aktarmak, kabiliyet gelişimi sağlamak veya geçmiş deneyimleri aktarmak şeklinde olabilir.
Farklı paydaşların farklı eğitim ihtiyaçları olabilir. Bazıları, eğitimde öğrendiklerini hemen kullanırken, bazılar işi denetlemek için eğitimden yararlanıyor olabilir.
Proje ekip üyelerine verilecek eğitimler, projenin hedefleri şekillendikçe, netleşmeye başlar. Özellikle, müşterinin sektörüne yönelik kavramlar, iş yapış şekilleri, yasal kısıtlar, sektör dinamikleri gibi faktörler eğitimlerin içeriğini oluşturur. Özetle, proje ihtiyaçlarının anlaşılması, hangi konularda eğitim gerektiğinin belirlenmesi için ön koşuldur.
Eğitim, ekip üyelerinin yeni veya geliştirilmiş beceri, bilgi kazandığı bir etkinliktir. Konular, yönetim yaklaşımları, teknik veya farkındalığı artırıcı içerikler olabilir.
Eğitim birçok şekilde verilebilir. Kapsamlı bir liste olmasa da, bazı eğitim sunum modelleri şunlardır:
• Eğitmen liderliğindeki sınıf eğitimi
• Sanal sınıf eğitimi
• Kendi hızınızda e-öğrenme
• Belge incelemeleri
• Etkileşimli simülasyonlar
• İşbaşı eğitimi
Paydaşların eğitim ihtiyaçları ve öğrenme biçimleri farklı olacaktır ayrıca bütçe kısıtı da farklı öğrenme araçlarını gündeme getirecektir.
Son kullanıcı eğitimleri, yeni sisteme geçişe yakın zamanda yapılması gerektiğinden, zaman planlamada dikkatli olmak gerekir.
Eğitim Boşluk Analizi: Projenizin paydaş analizine dayanarak, mevcut becerileri ve gerekli becerileri nelerdir?
Müşterinin iş akışlarında ve rollerinde yapacağı değişiklikleri değerlendirerek eğitim eksikliklerini belirlemelisiniz.
Ekip üyeleri de, projeyi hızlandırmak veya proje ortamını daha detaylı anlamak için eğitim alabilir.
Bütün bu değerlendirmeler sonunda, eğitim planı hazırlanır; Bu planda hangi paydaşın, hangi konuda eğitim alması gerektiği, eğitimlerin ne zaman yapılacağı, eğitimin güncel tutulması için tekrar sıklığı gibi faktörler tanımlanır.
Eğitim Seçenekleri
Eğitmen liderliğinde eğitim: Sınıf veya sanal eğitim ortamında canlı eğitmen liderliğinde eğitim verme şeklidir.
Kendi hızınızda e-öğrenme: Öğrencilere çevrimiçi olarak sunulan ve genellikle zengin medya videosu, benzetilmiş laboratuvar egzersizleri içeren bir tarayıcı kullanılarak tüketilen e-öğrenme içeriğidir. Bu yaklaşımın en büyük faydası pek çok öğrenciye ulaşma imkanı olmasıdır.
Belge incelemeleri: Basit bilgi aktarımı için, ilgili belgeleri paylaşmak yeterli olabilir.
Proje personeli ve müşteri paydaşları için yapılacak eğitimlerin maliyetleri proje bütçesini hesaplarken mutlaka düşünülmelidir.
Bu maliyetler şunları içerebilir:
• İçerik oluşturma ve düzenleme maliyetleri
• İçerik barındırma ve dağıtım maliyetleri
• Eğitmen maliyeti
* Eğitim malzemesi çoğaltma ve dağıtma
• Eğitim salonu maliyetleri
Lojistik maliyetleri (konaklama, yiyecekler)
Proje yöneticisi zaman çizelgesi içinde , eğitim tarihi ve yerini duyurması gerekir.
Eğitimin paydaşlara yayınlanması, kayıt, kayıt onayı, hatırlatma mesajı gönderme ve paydaş katılımını doğrulamak için bir mekanizma kurmak gerekebilir.
Son kullanıcı eğitimlerinde, içeriğin hazırlanması ve eğitim verilmesi aktiviteleri, projenin kritik yolundaysa, projenin teslimini geciktirebileceği için zaman planına büyük özen gösterilmelidir.
Bir projede kullanılan metot ne olursa olsun (çevik veya öngörücü) projedeki faaliyetleri detaylı olarak tanımlamaktan ve o işlerin tamamlamaktan, ekip üyeleri sorumludur.
Çevik yaklaşımda, ekibin aktiviteleri tanımlaması ve işleri üstleniyor olması, ekibin kendi kendine organize olması olarak tanıtılır ve öngörücü yaklaşıma göre üstünlük olarak gösterilir.
Halbuki, öngörücü yaklaşımlarda da proje yöneticisinin tek başına aktiviteleri belirlemesi mümkün değildir. Proje yöneticisi, iş kırılım yapısını çıkardıktan (kapsamı belirledikten) sonra detay aktiviteler için ya takım liderlerinin, ya da ekip üyelerinin bilgi birikimine başvurmalıdır.
“Bir işin detayını en iyi bilen, o işi yapandır.”
Takım liderleri (veya ekip üyeleri), iş paketlerinin hedeflediği teslimata ulaşmak için aktiviteleri tanımlamalı, işlerin yapılış sıralarını oluşturmalı, kaynak ve süre tahmin etmeli ve bu detayları diğer iş paketlerinin arasına entegre etmelidir.
Pratiğe baktığımızda, pek çok şirkette, planlama eylemi, sadece proje yöneticisinin göreviymiş gibi algılanır ve bu yanlış algı, öngörücü yaklaşımın dezavantajı olarak gösterilir.
Hangi metot seçilirse seçilsin, planlamayı proje yöneticisininin tek başına yapması mümkün değildir.
Öngörücü veya çevik metot farketmeksizin, aktiviteleri detaylandırmaktan ekip üyeleri sorumludur.
Ayrıca, ekip üyeleri, işlerin ilerleme durumunu da düzenli olarak (yazılı veya sözlü) proje yöneticisine aktarılmalıdır ki, projenin mevcut durumu ve gelecek tahmini yapılabilsin.
SWOT Analizi, ürününüzü, ekibinizi, tedarikçilerinizi ve hatta kendinizi detaylı olarak anlamak için çok etkili bir araçtır.
Biz, bu değerlendirmeyi bir proje ekibi için ele alalım.
Güçlü Yönler (Strengths):
Projenizin içindeki, projeyi başarıya ulaştırmada yardımcı faktörler, sizin güçlü yönlerinizdir.
Birbirini çok uzun zamandır tanıyan bir ekibinizin olması,
Geçmiş projelerde bir arada çalışmış ekip üyelerinin olması,
Belirli bir konuda ortak eğitime katılmış ekip üyelerinin olması,
Projede üst yönetimin projenizi destekliyor olması,
gibi faktörleri Güçlü Yönler olarak düşünüp, yazabilirsiniz.
Proje boyunca güçlü yönlerinizin bozulmamasına dikkat etmeniz gerekiyor. Birbirini uzun zamandır bilen ekip üyeleri dağılırsa, bu durum, projeniz için Zayıf Yönünüz olarak karşınıza çıkacaktır.
Zayıf Yönler (Weakness):
Projenizin içindeki ve projenizin başarıya ulaşmasını zorlaştıran faktörler zayıf yönlerinizdir.
Birbiriyle ilk defa bir araya gelen ekip üyeleri,
Ekibin yeni bir metot veya araç kullanma ihtiyacı,
Proje yöneticisinin, proje yönetimi eğitimi almamış olması,
gibi faktörleri Zayıf Yönler olarak düşünüp, yazabilirsiniz.
Bu faktörleri, iyileştirmek için gerekli aktiviteleri belirleyip, proje planınızın içine dahil etmeniz gerekir. Zayıf yönleri, iyileştirmek için zaman ve para harcamalısınız.
Proje hedeflerinizi ortaya koyarken, bu faktörleri dikkate alarak, daha gerçekçi proje hedefi belirleyebilirsiniz. Bu faktörleri görmezden gelirseniz, proje hedefine ulaşma ihtimaliniz azalacak ve projeniz başarısız olarak görülecektir.
Fırsatlar (Opportunities):
Projenizin dışındaki ve projenizi başarıya ulaştırma ihtimalini artıran faktörler, sizin için Fırsat niteliğindedir.
Çıkacak bir kanunla, projenizin devlet desteği kapsamına girmesi,
Projede bazı ara ürünlerin, farklı pazarlara sunulabilir olması,
Bir akademik araştırmanın, projenizin süresini ve maliyetini azaltacak olması,
İşinde uzman bir tedarikçinin, proje risklerini üstlenebilmesi,
gibi tanımları fırsat olarak görüp, yazabilirsiniz.
Fırsatların, faydaya dönüşebilmesi için bir takım adımlar atmak gerekmektedir. Bu adımlar, temelde dört başlıkta değerlendirilir;
Yararlanma: Fırsatın oluşması durumunu garanti altına almayı hedefler.
Geliştirme: Fırsatın olma ihtimalini ve/veya yaratacağı etkiyi artırmayı hedefler.
Paylaşma: Bir başka firmayla fırsatı paylaşmayı hedefler.
Kabul etme: Fırsatın oluşmasını ummak ve herhangi bir aksiyon almama halidir.
Tehditler (Threats)
Projenizin dışındaki ve projenizi başarıya ulaştırma ihtimalini azaltan faktörler, sizin için tehdit niteliğindedir.
Çıkacak bir çevre koruma kanunu ile projenizin süresinin ve maliyetinin artması,
Bir rakip firmanın sizden önce ürünü piyasaya çıkarması,
Ekonomik sebeplerden proje maliyetlerinizin artması,
gibi maddeleri tehdit olarak görüp, yazabilirsiniz.
Tehditlerin, proje veya şirkete zarar vermemesi için yapılacaklar dört başlıkta değerlendirilir;
Kaçınma: Kapsamı daraltmak suretiyle riskli aktiviteleri ortadan kaldırmak.
Azaltma: Tehdidin olma ihtimalini ve/veya yaratacağı etkiyi azaltmayı hedefler.
Devretme: Riskli aktiviteyi bir başka firmaya aktarmaktır.
Kabul etme: Tehdidin etki gücü veya olasılığı az ise, herhangi bir eyleme geçmeme hali ile kabul etme stratejisi uygulanmış olur.
Proje ekibi içindeki sorumlulukların tanımlanması bir dizi faktöre bağlıdır. Bazı ekiplerde, ekip üyelerinin sorumlulukları açıkça delege edilir, bazılarında ise ekip kendi kendini organize olur ve ekip üyeleri kimin hangi işi yapacağına beraber karar verirler.
Bir sorumluluğu yerine getirmek için uygun bir kaynağın belirlenmesi aşağıdakilere faktörlere dayalıdır:
• Deneyim: Ekip üyesi, aktiviteyi gerçekleştirmek için gerekli deneyime sahip midir?
• Bilgi: Ekip üyesi, ilgili işi yapabilmesi için gerekli bilgiye sahip mi?
• Beceriler: Ekip üyesi gerekli becerilere sahip mi?
• Tutum: Ekip üyesinin işi yapmak için gerekli motivasyonu var mı?
• Uluslararası faktörler: Ekip üyesinin coğrafi yeri, saat dilimi ve iletişim ihtiyaçları göz önünde bulunduruldu mu?
Yeni bir ekip oluştururken, ekiple projenin amaç ve hedefleri, ekibin sorumlulukları ve gerekli roller ve beceriler hakkında bilgi paylaşmalısınız.
Açık iletişim ve etkili işbirliği, projenin başarısı açısından kritik öneme sahiptir.
Proje yöneticisi, proje bütçesinden sorumludur. Kaynak gereksinimleri, projenin ihtiyaçları, kaynak mevcudiyeti ve diğer faktörler göz önüne alındığında en uygun maliyetli kaynağı kullanarak projesini yönetmelidir.
Proje yöneticisinin projeye atanan ekip üyelerini, rollerini ve sorumluluklarını belgelemesi beklenir ve bir projede kaynak yönetim planı, proje organizasyon şemasını ve kaynak takvimlerini, kaynakların kapasitelerini içerir. Bu içerik, proje yönetim planının önemli bir bölümünü oluşturur.
Proje yöneticisi, proje bütçesinden ve ödemelerden sorumludur. Kaynak gereksinimleri, projenin ihtiyaçları, kaynak mevcudiyeti ve diğer faktörler göz önüne alındığında en uygun maliyetli kaynak kullanılarak karşılanmalıdır.
Proje yöneticisinin projeye atanan ekip üyelerini, rollerini ve sorumluluklarını belgelemesi beklenir ve bir proje ekibi dizini, proje organizasyon şemaları ve proje çizelgeleri içerebilir. Bu görevler proje yönetim planının önemli bir bölümünü oluşturur.
Örnek PMP Sınav Sorusu
Aşağıdakilerden hangisi aktivitelere kaynak atarken dikkat etmeniz gereken bir özellik değildir?
Proje ekibindeki herkesin birbirleriyle ilişki ve iletişim kurması için çeşitli kişilerarası beceriler vardır.
Kişilerarası ilişki becerileri projenin farklı dönemlerinde farklı ağırlıklarda kendini gösterir. Bu başlıkları bilmek ve yeri geldiğinde kullanmak paydaşları etkileyebilmek için proje yöneticisine avantajlar sunar.
Çatışma yönetimi
Çatışma yönetimi, bir çatışmanın olumsuz bir sonucunun ortaya çıkmasından önce müdahale etmeyi içerir.
Bir projenin yaşam döngüsü boyunca çatışmaları başarılı bir şekilde yönetmek zor olabilir.
Proje yöneticisi olarak, ortaya çıkan herhangi bir çatışmanın karar merkezi siz olacaksınız.
Çatışmanın nasıl ele alınacağını siz belirleyeceksiniz.
Amaç, çatışmanın olumlu şekilde sonuçlanmasını sağlamak ve bir öğrenme deneyimi kazanmak olmalıdır.
Kültürel farkındalık
Proje ekibinizdeki bireylerin farklı kültürel bakış açılarını ve inançlarını anlamak ve farkında olmak yanlış iletişim ve yanlış anlamaları azaltmaya yardımcı olacaktır.
Karar verme
Karar verme, bir sonuç elde etmek için çok önemli bir beceridir.
Karar verme yeteneği zor durumlarda sorumluluk üstlenme ve sonuçlarını savunabilmeyi içerir. Karar verme, aşağıdakiler de dahil olmak üzere bir dizi aşamaya ayrılabilir:
• Sorunu tanımlama
• Potansiyel çözümler üretmek
• Çözüm eylemlerinin planlanması
• Fikirleri eyleme geçirmek
• Çözüm değerlendirme planlaması
• Sonuçların ve süreçlerin değerlendirilmesi
Şeklinde sayabiliriz.
Kolaylaştırma
Kolaylaştırma teknikleri, bir araya getirilmiş bir gruba karar vermelerini veya çözüm bulmalarını sağlamak için kılavuzluk veya liderlik etme üzerine kullanılan becerilerdir.
Liderlik
Sonuç elde etmek için adım atma ve başkalarına yol gösterme yeteneğidir. Liderlik yetenekleri tecrübe sahibi olmak, insanlarla ilişkiler kurmak ve inisiyatif almak yoluyla kazanılır.
Toplantı yönetimi
Toplantıların verimli ve etkili bir şekilde yürütülebilmesi, projenin başlatılabilmesi, planlanabilmesi, yürütülebilmesi, başlatmada, planlamada, yürütmede, kontrolde ve hatta kapatılabilmesi için gerekli bilgileri toplarken faydalı olacaktır.
Müzakere
Müzakere, birden fazla kişi tarafından bir anlaşmaya veya karara varmak için kullanılan bir yaklaşımdır.
Başarılı bir şekilde müzakere edebilmek, bir proje sırasında ortaya çıkan sorunları ve çatışmaları nasıl çözeceğiniz üzerinde büyük bir etkiye sahip olacaktır.
İlişki Ağı Kurma
İş konuları hakkında bilgilerini genişletmek için insanlar arasındaki etkileşim oluşturma sürecidir. Kuruluş içinde, endüstride veya farklı profesyonel ortamlarda gerçekleştirilebilir.
Gözlemleme / Konuşma
Bir durumun veya sürecin nasıl ilerlediğine dair ilk elden bilgi edinmek için bireyleri günlük görevlerini yerine getirirken izlemeyi ve karşılıklı konuşmak suretiyle bilgi almayı ve vermeyi içeren tekniklerdir.
Hizmetkar Liderlik
Çevik ve diğer projelerde kullanılan, dinleyerek, koçluk yaparak ve ekip üyelerinin gelişmelerine izin veren bir ortam sağlayarak ekibin kendini tanımlamasını, kendini keşfetmesini ve öz farkındalığını teşvik eden bir liderlik türüdür.
Hizmetkar liderler ekibin çalışmasını kolaylaştırır, çalışma engellerini kaldırır, paydaşları süreçler konusunda eğitir ve ekibin başarısını kutlar.
Takım Oluşturma
Güçlü bir ekip oluşturmak zor olabilir, ancak sürekli destek ve işbirliği içinde çalışarak bir ekibin sorunlarını çözmek, kişiler arası sorunları ortadan kaldırmak, bilgi paylaşmak ve proje hedeflerini birleşik bir güç olarak ele almak için birlikte çalışılmasını sağlayabilirsiniz.
Takım oluşturma proje hedeflerine ulaşmada çok güçlü bir araçtır.