Kategori arşivi: Proje Yönetimi

Proje Yönetimi ile ilgili yazılar

PMP Hazırlık – Çevik Yaklaşımlar – Kanban

Kanban nedir?

1940’ların sonlarında Toyota, ABD süpermarketlerini incelemeye başladı. Müşterilerin genellikle o anda ihtiyaç duyduklarını (ne fazla ne az) aldıklarını fark ettiler. Müşteriler ertesi gün geri gelip ihtiyaç duyduklarını tekrar alabileceklerini biliyorlardı.Toyota’nın gözlemleri, envanteri algılamanın yeni bir yolunu ateşledi. Artık bilgisayar sistemleri ve envanter yazılımlarının kullanımı ile bir sistemin yalın ve tam zamanında olması daha kolaydı. Toyota bu yaklaşımı fabrikaya taşıyarak Kanban sistemini yarattı.

Kanban, üretim sistemi, süreçler veya faaliyetlerin sırasını ve gerekli talimatları gösteren bir model yarattı. Böylece herkes süreci nasıl yöneteceğini ve yönetmek için talimatların ne olduğunu görebiliyordu.

Kanban yöntemi, bireylerin faaliyetlerinden ziyade müşteriye ve onların ihtiyaçlarına hizmet eden işe odaklanmayı vurgular. Ayrıca, Kanban’ın ilkeleri, değişiklik yönetimi ve hizmet sunumu ilkelerinden başlayarak oldukça basittir. Değişim yönetimi ilkesi, tamamen mevcut süreçleri anlamak, rollere, sorumluluklara ve iş ünvanlarına saygı duymakla ilgilidir. Sürekli olarak iyileştirmeleri takip etmeye ve değişim yoluyla gelişmeye ve organizasyondaki rolleri ne olursa olsun her seviyede liderliği uygulamaya teşvik etmeye odaklanılır. Kanban uyarlanabilir liderliği yansıtır.

Hizmet sunumu tarafında önemli olan müşteriyi gerçekten anlamak, ihtiyaç duyduğu ve beklediği şeye odaklanmaktır. Bunu yapmak için, hem müşteri hem de işletme için sonuçları iyileştirmek için politikalarınızı kurumsal olarak sürekli olarak geliştirmeniz gerekir. Bunu yapabilmek için, işi yönetmek ve ekibin kendi kendine organize olmasına izin vermek gerekir. Böylece kendi kendini organize olan ve yöneten çapraz işlevli ekipler ortaya çıkar.

Kanban’da iki araç vardır: Kanban kartı ve Kanban panosu. Kanban kartları, üretim tesisi içindeki malzemeleri taşıma veya tedarikçiden üretim tesisine malzeme alma ihtiyacını işaret eder.

Kanban system: how does it work in logistics? - Mecalux.com

Çevik metodolojide en çok kullanılan Kanban panosudur. Kanban Panoları, birikmiş iş yığınından devam eden işe (Work-in-progress-WIP) yapılan veya dağıtılan işi temsil eden yüzme havuzundaki kulvarlara benzeyen şeritlere sahip beyaz tahtalardır. İş öğelerini veya Kanban kartlarını temsil etmek için Post-it’ler kullanılır. Kanban Panosu fiziksel veya sanal olabilir.

Kanban board - Wikipedia

Kanban panosu yalnızca yapılması gereken, yapılmakta olan işin görsel bir temsili olmayıp birden fazla paydaşla bilgi paylaşmanın en popüler yollarından biridir.

Kanban, bir çekme sistemini temsil eder. Diğer iş tamamlandığında iş yapılmak için çekilir. Çevik yaklaşımlarda ürün-iş biriktirme listelerinin, müşteri ihtiyaç ve isteklerinin dinamik ve sürekli değiştiğini biliyoruz. Ürün sahibi, çekme sistemini kullanarak, bir öğe tamamlandıktan sonra hangi iş biriktirme listesi öğelerinin yapılması gerektiğini belirleyebilmektedir. Ekip, sprint veya yinelemede başarabilecekleri işi seçer. İş tamamlandığında kabul aşamasına geçer ve diğer işler yapılmak için çekilir. İş tamamlanmış kabul edildiğinde, diğer işe başlanır.

Scrum Panosu, Kanban panosuna çok benzer, ancak ikisi arasında bazı belirgin farklılıklar vardır. Scrum panosu aynı çekme sistemini kullanır, ancak sürekli olarak yeni işlerin çekilmesi yerine, bir sprint sırasında ekibin o sprint sırasında üzerinde çalışmayı seçtikleri dışında hiçbir ek öğe eklenemez.

What is Scrum Board? | Online Agile Scrum Board - Zoho Sprints

Scrum Panosu, sprint boyunca soldan sağa hareket eden iş akışının mükemmel bir görsel temsilidir ve herkesi işin üstünde tutar. Hem okunması hem de kullanımı kolay olduğunda bilgi radyatörü (bilgi yayma aracı) olarak kullanılır. Tüm iş ve sprint bittiğinde, bir sonraki sprint sırasında yapılacak yeni iş seçildiğinde Scrum tahtası sıfırlanır. İkisi arasındaki diğer fark, Scrum panoları sprintte gerçekleştirilebilecek iş miktarını temsil etmek için destanları, kullanıcı hikayelerini ve hikaye puanı atanmış görevleri kullanır. Hikaye puanları işin boyutunu temsil eder. Kanban panoları gibi, Scrum panoları da düzenli olarak güncellenirler.

Kanban’ın Altı İlkesi

  1. İş akışını görselleştirmek
  2. Devam eden işi sınırlamak
  3. Akışı yönetmek
  4. Politikaları açık hale getirmek
  5. Geri bildirim döngülerini uygulamak
  6. İşbirliği içinde ve denemeler yaparak geliştirmek

Kanban’ın altı ilkesi, iş akışını anlamayı sağlar, iş ilerledikçe tutarlı geri bildirim ve iyileştirmeye izin verir.

  1. İş Akışını Görselleştirmek: İş akışının şu anda nasıl olduğunu ve yürütüleceğini belirleyen işi ve ilkeleri görmek gerekir. Süreci yinelemeli olarak iyileştirir, gerekli değişiklikleri benimsemeye yardımcı olur ve etkisiz değişikliklerden öğrenmeyi sağlar. Kanban panoları iş akışını önde ve merkezde tutarlar ve nereden başladığınız ve nerede bittiğinizin haritasını gösterirler. İş akışı anlaşıldıktan sonra, daha iyi ve optimize edilmiş iş akışı için değişiklik yapılabilir. Kanban panosu her zaman görüş alanı içindedir ve yapılması gereken iş veya hangi işin tamamlandığı konusunda soru işareti bırakmaz. Beyin görsel sunumları metni işlemekten 60.000 kat daha hızlı işler ve Kanban/Scrum panoları hızlı tempolu çevik ortamlarda oldukça değerlidir.
  2. Devam Eden Çalışmayı Sınırlamak: Devam eden çalışmayı sınırlamak Kanban’ın can alıcı noktasıdır. Hiç kimse çok fazla veya çok az iş üstlenmez. Devam Eden Çalışma, çekme sistemi aracılığıyla sınırlandırılırsa ve iş akışının bir kısmına veya tamamına uygulanırsa, iş akışındaki her adım sınırlandırılır. Yeni iş, yalnızca mevcut kapasite yeterli olduğunda bir sonraki adıma “çekilir”. Devam Eden Çalışmayı sınırlamak, birçok çevik metodoloji ve çerçevenin ortak noktasıdır.
  3. Akışı Yönetmek: Süreç veya ürünleri iyileştirmek için değişiklik gerekli olsa da, bazen çok fazla değişiklik süreç akışına zarar verebilir. Akışı etkili bir şekilde yönetmek, yalnızca değişiklik anlaşıldıktan sonra süreçte değişiklikler yaratmaktan geçer. Değişikliğin sonuçlarının projenin diğer alanları üzerindeki tüm etkileri değerlendirilmelidir. Akışı yönetmek ve yalnızca gerçekten gerekli olan değişiklikleri uygulamak, işlerin verimli bir şekilde ilerlemesini sağlar ve süreçteki israfı ortadan kaldırır.
  4. Politikaları Açık Hale Getirmek: Herkes tarafından iyi bilinen kural ve politikalara sahip olmak gerekir. Herkes politika ve prosedürleri veya yapılanın tanımını anlarsa, gerektiğinde süreçteki rasyonel değişikliklerin daha iyi uygulanması veya daha etkili olması mümkündür.
  5. Geri Bildirim Döngülerini Uygulamak: Geri bildirim yoluyla durumu daha iyi anlamak, süreci ve sonucu iyileştirir. Devam eden etkili iletişim tüm çevik yaklaşımlarda ortak noktadır. Görsel iş akışı, kendi kendini yöneten ve kendi kendine organize olan ekiplerin tümü, etkili geri bildirim için çok önemlidir. Ozmotik iletişim PMP sınavında karşınıza çıkabilir. Kişilerin bilmek istedikleri veya bilmeleri gereken konulardaki konuşmalara kulak misafiri olmaları anlamına gelir. Ozmotik iletişim, etkili bir bilgi aktarımı yoludur.
  6. İşbirliği İçinde ve Denemeler Yaparak Geliştirmek: Sürekli iyileştirme anlamına gelen Japonca Kai ve Zen kelimelerinin birleşiminden oluşan Kaizen kelimesi projelerde işbirliğinin ve denemeler yaparak sürekli iyileştirmenin altını çizer.

Aşağıdakiler, Kanban bakış açısına yönelik kilit noktalardır;

  • Kanban, işi kolayca yönetmenin ve devam eden işi sınırlı tutmanın bir yoludur.
  • Devam eden iş ve iş akışı Kanban panosunda sunulur.
  • Kanban kartı, yapılan iş tamamlandıkça Devam Eden Çalışmanın çeşitli aşamalarından geçecektir.
  • Kanban’a genellikle çekme sistemi denir.
  • Kanban, belirli bir çerçeveden ziyade sürekli iyileştirmeler modelidir.
  • Kanban, Scrum ve XP gibi birçok Çevik metodolojiye dahil edilebilir.

 

PMP Hazırlık – Çevik Yaklaşımlar – Ekstrem Programlama(XP)

What Is Extreme Programming?. A complete overview of XP | by Pratyaksh Jain  | Inheaden | Medium

XP’nin temel değeri önce basitliktir. XP ekipleri ek ve gereksiz özelliklerden kurtulmak, israftan kaçınmak, işleri basit tutmak ve müşteri gereksinimlerini karşılamak için işe yarayabilecek en basit çözümü bulmaya odaklanırlar. Scrum gibi, XP de proje boyunca değişiklikler bekler ve XP ekibi değişikliği memnuniyetle karşılar.

XP’de son teslim tarihlerine sahip projeler, teslimatı oluşturmak için gereken süre konusunda gerçekçi değildir ve proje ekibine ek stres yaratır. Son teslim tarihi, XP ekibinin gereğinden fazla çalışmasına, baskı altında kalmasına ve yenilik yapmaktan korkmasına neden olabilir.

XP, zaman sınırlamalı yaklaşımında haftalık döngüler ve üç aylık sürüm döngüleri tercih edilir. Scrum’daki sprint gibi haftalık döngü yinelemeli gerçekleştirilir. Her haftanın ilk gününde ekip, neler başarıldığını tartışmak, hafta boyunca gerçekleştirilecek öncelikli kullanıcı hikayelerini seçmek ve seçilen kullanıcı hikayelerini nasıl oluşturacağına karar vermek için toplanır. Bu yaklaşım, sprint planlamasına benzer, ancak tipik sprint’ten daha kısadır. Üç aylık döngü sürümdür ve müşterinin gereksinimleri önceliklendirmesine göre haftalık döngülerde planlanır ve güncellenir. Temel olarak, her haftanın başarıları, her çeyrekte neyin piyasaya sürüleceğini belirlemeye yardımcı olur.

XP’de Slack kavramı, süre yetmezse haftalık döngüden çıkarılabilecek bazı düşük seviyeli gereksinimleri listeye ekleyerek oluşturulur. İşler sorunsuz gidiyorsa, proje ekibi için yük oluşturmayacak düşük seviyeli gereksinimler haftalık döngüye eklenebilirler.

XP’de On Dakikalık Yapı kavramı, yazılan kodun derleme ve test etmek için on dakikalık bir zaman diliminde tamamlanabileceği anlamına gelir. On dakikalık süre, ekibi otomatikleştirilmiş derleme yaklaşımı oluşturmaya, sık sık test etmeye ve sürekli entegrasyonu izlemeye teşvik eder. Sürekli entegrasyon, kod geliştirildiğinde veya değiştirildiğinde gerçekleşir. Ardından entegrasyon hatalarını bulmak ve düzeltmek için kod hemen test edilir.

XP, önce test planlama yaklaşımını izler. Önce test planlandığında, programcılar gerekli testi geçmek için kodun nasıl yazılması gerektiğini bilirler.

eXtreme Programming (XP) – An Agile Framework – StillGeek

XP, yaşam döngüsü boyunca planlama ve geri bildirim döngülerini içerir;

XP Projesini Planlamak

  • Kullanıcı hikayeleri yazılır.
  • Sürüm planı oluşturulur.
  • Sık, küçük sürümler için planlar geliştirilir.
  • Proje yinelemelere bölünür.
  • Her yineleme, bir yineleme planlama oturumu ile başlar.

XP Projesini Yönetme

  • Bir arada bulunan ekipler uygun çalışma ortamında çalışır.
  • Sürdürülebilir bir çalışma hızı oluşturulur.
  • Gün, 15 dakikalık ayaküstü toplantı ile başlar.
  • Proje ekibinin hızı düzenli ölçülür.
  • Ekip üyeleri diğer rollerde bilgi sahibi olacak şekilde eğitilir.
  • Retrospektifler, XP’deki sorunların çözülmesine yardımcı olur.

Tasarım

  • İşler basit tutulur.
  • Projenin hızlı ve kolay anlaşılması için sistem metaforu oluşturulur.
  • Yapılacak işler, sorumluluklar ve işbirliği kartları hazırlanarak, sistem tasarlanır.
  • Spike(mümkün olan en basit çözüm) yinelemeleri, riskleri ele almak için kullanılır.
  • İstenene kadar özellik ve işlev eklenmez.
  • Kodun temizlenmesi anlamına gelen refactor, proje boyunca gerçekleşir.

Kodlama

  • Müşteri rolüne ihtiyaç vardır.
  • Tüm kodlama için standartlar oluşturulur.
  • Önce birim testleri yazılır.
  • Programcılar eşli programlama (aynı işi bilen iki kişi) yapar.
  • Kod sık sık entegre edilir.
  • Tüm kodlar ekibe aittir, herhangi bir programcı kodu gözden geçirebilir veya düzenleyebilir.

Test yapmak

  • Tüm kodlar için birim testleri yapılır.
  • Tüm kodlar yayınlanmadan önce birim testini geçmelidirler.
  • Koddaki hatalar, yeni testlerin oluşturulmasını gerektirebilir.
  • Kabul testi gereklidir, sonuçlar izlenir ve paylaşılır.

XP’nin en önemli unsuru iletişimdir. XP, Scrum gibi, yüz yüze iletişime önem verir. Etkili iletişim erken ve sık geri bildirim almayı sağlar. Bu sayede erken ve hızlı başarısız olma avantajı yakalanır. Ekip hızlı ve erken başarısız olduğunda, neyin işe yarayıp yaramadığına dair geri bildirim alırlar, ayarlamalar yapabilir ve projede ilerleyebilirler. XP, çalışanların deneyip başarısız olmaları için güvenli bir ortam gerektirir. Olumsuz bir geri bildirim yoktur. Eğer yapılan işe yaramadıysa, ekip neyin işe yaramadığını bilir ve ceza korkusu olmadan devam edebilirler.

XP’de basit, kolay anlamına gelmez. Basit, aşırı mühendislik yapmamak, karmaşık kod oluşturmamak, doğrudan ve uygulaması kolay bir çözüm tasarlamak anlamına gelir. XP’de, müşteri gereksinimlerini karşılamak için işe yarayacak en basit şey hedeflenir.

Scrum’da, ekipler bir sonraki sprintte gelişme ve daha iyi çalışma fırsatı için sprint retrospektif yaparlar. XP, anında geri bildirim yoluyla benzer bir konsepte sahiptir. Geri bildirim yargılayıcı değil yapıcı olmalı ve ekibe daha iyi kararlar verme konusunda rehberlik etmelidir. Geri bildirim verirken ekip üyeleri saygılı, dürüst olmalı ve neyin işe yarayıp neyin yaramadığına odaklanmalıdır. Geri bildirimler, suçlamak için fırsat değil, projede ilerlemek için fırsattırlar.

Erken, hızlı ve sık sık başarısız olmak için cesarete ihtiyaç vardır. Geliştiriciler deneme yaptıklarında ekipteki herkes tarafından görülebilir. Ekip, kodu açıkça paylaşır, birbirlerinin kodunu düzeltme yetkisine sahiptirler. Eşli Programlamada bir kişi geliştirici olarak çalışır ve yanında kodu geliştirmesini izleyen bir kişi vardır. İkinci programcı hataları yakalamaya yardımcı olur, iyileştirmeler sunar ve programcıya ihtiyaç duyduğunda yardımcı olur. Programlayan kişiye sürücü, yardım eden kişiye yönlendirici denir. Sürücü ve yönlendirici her 1,5 ila 3 saatte bir rol değiştirir.

Etkili iletişim kurmak, eşli programlamayla birlikte çalışmak ve yeni yaklaşımlar denemek için ekip üyeleri birbirlerine saygı duymalıdırlar. XP, projenin başarısı veya başarısızlığından herhangi bir kişinin değil herkesin sorumlu olduğu kavramını benimser. Herkes farklı çalışır, ancak ekiple birlikte çalışmak gerekir.

What Is Extreme Programming (XP)? - Values, Principles, And Practices

XP Rolleri ve Sorumlulukları

XP projesinde PMP sınavı için bilmeniz gereken sekiz rol vardır. Bunları derinlemesine bilmeniz gerekmez, ancak sorumluluklarını bilmeli ve projede her rolün ne yaptığını anlayabilmelisiniz;

  • Müşteri veya ürün sahibi – Bu rol, scrum’daki ürün sahibi gibi, iş değerlerini temsil etmekten, kullanıcı hikayeleri yazmaktan, gereksinimleri önceliklendirmekten ve programcıların kullanıcı hikayelerinin değerini anlamalarına yardımcı olmaktan sorumludur. Bu rol müşteri gibi hareket eder. Müşterinin neye değer verdiğine ve projeden ne beklendiğine dair iyi bir içgörüye ihtiyaçları vardır.
  • Koç – XP koçu, ekip üyelerine XP yaklaşımı konusunda koçluk yapar, işlerin ilerlemesini sağlar, projenin çalışmasını denetler ve ekip geri bildirimlerine dayalı olarak süreç iyileştirmelerinin uygulanmasına yardımcı olur. Koç, proje yöneticisi ile aynı şey değildir, ancak proje faaliyetlerinin koordine edilmesine yardımcı olur, herkesin kurallara uymasını ve katkıda bulunmasını sağlar.
  • Programcı – Kodu müşterinin gereksinimlerini karşılayacak şekilde yazandır. Kullanıcı hikayelerini tamamlamak için gereken görevleri belirlerler ve birim testleri yaparlar.
  • Testçi – Programcıların oluşturduğu kod üzerinde işlevsel testler gerçekleştirirler. Fonksiyonel testler, entegrasyon testleri olarak da adlandırılır ve programcıların yaptığı birim testlerinden farklıdır. Testçi, test sonuçlarını belgeler.
  • İzleyici – Bu rolün bazı proje yönetimi görevleri vardır, çünkü kişi projede işlerin “yolda” olduğunu doğrulamak için iş atamalarını izleyecektir. İşler beklendiği gibi gitmezse, kişi belirli görevleri yapmak için plan yapacaktır. İzleyici ayrıca proje ilerlemesini raporlamak için programcılar, koç ve müşteri ile bir araya gelir.
  • Risk İzleyici – Projelerdeki, riskleri, kötü sonuçları ve projeyle ilgili sorunları izler. Projenin başarısını tehdit edebilecek durumlar hakkında sık sık iletişim kurar. Rolün amacı, projenin sağlığı konusunda dürüstlüğü ve şeffaflığı sağlamaktır.
  • Yönetici – Projeyi söz verildiği gibi teslim etmekten sorumludur. Yönetici, proje müşterisine durumu iletmekten, sürüm planlaması için toplantıları planlamaktan ve genellikle kontrol etmekten sorumludur.
  • Sponsor – Projeye kaynak sağlayandır.

XP ekipleri yüz yüze iletişim ve ozmotik iletişim (konuşulanlara kulak kabartmak) kurarlar. XP rollerine bazen genelleme uzmanları denebilir. Bir rolün yalnızca bir şey yapmaktan ziyade birden fazla şey yapabileceği anlamına gelir.

PMP sınavında dikkat edilmesi gereken sürdürülebilir tempodur. Ekip, ürün iş biriktirme listesini incelerken, en üstteki en önemli öğelerle başlayacak ve ekip, tamamlama sürecinde(döngüde) kaç hikaye noktası tamamlayabileceklerini belirleyecektir. Yeni döngülerde, daha fazla iş yapmaya teşvik edilmezler. Bu fazla mesaiye ve uzun çalışma saatlerine yol açar ve sürdürülebilir değildir. Hız bir ekibin yinelemede ne kadar iş yapabileceğidir, bu yüzden tek tip ve sürdürülebilir olmalıdır.

PMP Sınavında, senaryo bazlı sorular proje çalışmasını tanımlayabilir, projenin tamamladığı işin türüne göre çevik veya öngörücü olduğuna dair bilgiler verecektir.

PMP sınavında dikkat etmeniz gereken tüm çevik proje yönetimi kavramlarının benzerlikleri vardır:

  • İletişim şeffaf ve dürüst olmalıdır.
  • Değişim memnuniyetle karşılanır ve beklenir.
  • Proje gereksinimlerine değerine göre öncelik verilir.
  • Ekip ve paydaşlar işbirliği yapar.
  • Asgari düzeyde yeterli belge olmalıdır.

Türkçe eğitimler

İngilizce eğitimler

PMP Hazırlık – Çevik Yaklaşımlar – Scrum

Scrum Images | Free Vectors, Stock Photos & PSD

En yaygın çevik yaklaşımdır. Sadece süreçler veya proje yönetimi için bir çerçeve olmayıp ürün yönetiminin bir özelliğidir. Projeyi, “Bitti Tanımı”na doğru ilerletmek için yinelemeli yaklaşımı tercih eden çevik bir yaklaşımdır. Proje, paydaşların en önemliden en az önemliye doğru gereksinimlerini sprint adı verilen yinelemelerle gerçekleştirmeye dayanır.

Çevik için birçok farklı yaklaşım olsada, tüm çevik yaklaşımlar sprintler, yinelemeler veya artışlarla çalışır. Artış, her sprintte geliştirilen kullanılabilir ürün veya ürünlerdir. Artış, nihai ürünün potansiyel olarak kullanılabilir bir parçasıdır. Her artış, önceki artışlara eklenir. Bir tren düşünün; her artış, trene eklenen başka bir yük vagonudur.

Yinelemeler aynı zamanda sprintlerdir ve geçmişte tamamlanmış olanların üzerine inşa edilirler, ürünü bir bütün olarak iyileştirir ve/veya geliştirirler. Örneğin, bir resmin taslağını çizdiğinizi ve ardından taslağı iyileştirdiğinizi, taslağın üzerini boyadığınızı, taslağı yeniden boyadığınızı ve resim mükemmelleşene kadar devam ettiğinizi hayal edebilirsiniz. Yinelemelerin arkasındaki fikir: tamamladığınız şeyi yinelersiniz. Diğer bir örnek web sitesi oluşturup, ekip ve ürün sahibi gördükten sonra ek özellikler eklemek vb.

Süreç

1 – Vizyon beyanı yapılır. Vizyon ifadesi, hedefleri ve projenin neden var olduğunu açıklar. Projenin amacını ve projenin getirdiği değeri ön planda tutan basit bir belgedir. Vizyon ifadesinin, iyi olarak kabul edilmesi için beş unsuru içermesi gerekir;

  • Projenin açık tanımı
  • Açık ve basit bir dil
  • Kuruluşun beklediği değer ile uyum
  • Proje ile ilgili gerçekçi beklentiler
  • Kısa ve net

2 – Ürün Yol Haritası hazırlanır. Ürün sahibi, Scrum Master ve Scrum ekibi ile birlikte ürün yol haritası geliştirmek için birlikte çalışır. Ürün yol haritası, paydaşlara baştan sona projedeki teslimatların nasıl teslim edileceğini gösterir. Aynı zamanda Scrum ekibi için yol göstericidir. Ürün sahibinin onaylaması için hangi koşulların yerine getirilmesi gerektiğini, bileşenlerin neler olduğunu ve projenin sonucunu açıklar.

3 – Ürün Sahibi, Ürün iş biriktirme listesini hazırlar. Ürün sahibi, iş değerine ve beklenen değere göre ürün biriktirme listesini öncelik sırasına koyar. Değişiklik istendiğinde, ürün sahibi değişikliği değerlendirir, onaylarsa ürün iş biriktirme listesine ekler ve yeniden önceliklendirir. Böylelikle Sürüm Planı hazırlanmış olur.

4- Önceliklendirilmiş ürün iş biriktirme listesindeki öğeler Kullanıcı Hikayelerine dönüştürülürler. Kullanıcı Hikayeleri rol bazlı olarak istenilen fonksiyon veya işlevi açıklayan kısa notlardır. Kullanıcının, istenen özelliği nasıl kullanacakları ve kullandıklarında elde edecekleri değer hakkında kısa bir açıklamadır. Örneğin bir satış elemanı olarak daha fazla satış yapabilmek için uygulama üzerinden sipariş girmek istiyorum. Kullanıcı hikayeleri bir rol, işlev ve değer formülünü takip eder. Örneğin, “Bir <rol> olarak, <işlev> istiyorum, böylece <değeri> gerçekleştirebilirim”. Kullanıcı hikayeleri yapışkan notlara veya dizin kartlarına yazılır ve hikaye kartları olarak adlandırılır.

Kullanıcı hikayeleri, ekipteki herkes tarafından kolay anlaşılmalıdır. Kullanıcı hikayeleri ürün sahibi tarafından oluşturulur ve ürün iş biriktirme listesine girerler. Kullanıcı hikayelerinin önceliklendirilmesinden ürün sahibi sorumludur. Her kullanıcı hikayesi değer yaratmalıdır.

Kullanıcı hikayeleri aşağıdaki özellikleri içermelidir;

  • Bağımsız – Ürün iş biriktirme listesinde herhangi bir sırada önceliklendirilebilir.
  • Pazarlık edilebilir – Ekip ve ürün sahibi, maliyet ve işlev konusunda ödün verebilir.
  • Değer Kullanıcı hikayesi eyleminin değeri açıktır.
  • Tahmin edilebilir – Gerçekleştirmek için gereken çaba tahmin edilebilir.
  • Küçük – Bir yinelemede tamamlanabilmelidir.
  • Test edilebilir – Sonuçlar, tamamlanma ve doğruluk açısından test edilebilir.

5 – Scrum’da, teslimatlar, sprintlerde ortaya çıkarılır. Sprintler iki ila dört hafta sürebilir. Her sprintin başlangıcında, ürün sahibi, scrum master ve scrum ekibi, sprintte gerçekleştirilecek çalışmaları planlamak üzere bir araya gelirler. Sprint planlama toplantısı, ürün iş listesine ve scrum ekibinin ne kadar iş başarabileceklerine odaklıdır. Scrum ekibi, kullanıcı hikayeleri gözden geçirirler. En değerli kullanıcı hikayelerini belirler, sprint sırasında kaç kullanıcı hikayesini tamamlayabileceklerini belirlemeye çalışırlar. Sprint planlama toplantısının amacı ekibin başarabileceklerini düşündükleri iş parçası üzerinde hemfikir olmalarını sağlamaktır.

Scrum ekibi, ürün iş biriktirme listesindeki kullanıcı hikayelerine bakıp, kullanıcı hikayelerinin ne kadar büyük veya küçük olduğunu belirlemeleri ve kullanıcı hikayesinin boyutuna göre hikayelere puan atamaları gerekir. Hikaye ne kadar büyükse, o kadar fazla hikaye puanı alır. Hikaye puanı veya hikaye noktası, gerçekleştirilecek hikayeleri büyükten küçüğe boyutlandırmaya yarar.

Kullanıcı hikayesi boyutlandırma tamamen görecelidir. Scrum ekibinin bir yinelemede ne kadar iş veya hikaye noktası tamamlayabileceklerini tahmin etmesine yardımcı olur. Her bir kullanıcı hikayesi, işi yapmak için gereken çaba, karmaşıklık ve süreye göre boyutlandırılır, ancak bu kesin bir süre tahmini olmayıp, scrum ekibinin gerçekçi bir şekilde tamamlayabilecekleri iş miktarının kaba bir tahminidir.

Kullanıcı hikayesi boyutlandırması zordur, bu nedenle iyi bir yaklaşım tercih edilmelidir. Örneğin, tişört boyutları, fibonacci serisi vb. Boyutlandırmanın doğru olduğundan ve aynı zamanda tek tip olduğundan emin olmak gerekir.

Yakınlık tahmini yapılıyorsa ürün sahibi, scrum ekibi ve scrum master bir araya gelirler. Tahminler, ürün iş biriktirme listesinin en üstünden başlayarak geçmiş projeler veya benzer çalışmalar gibi bazı kanıtlanmış referans noktaları ile başlar. İlk sprintlerde, scrum ekibinin ne kadar iş tamamlayabileceğini tahmin etmek zordur. Zamanla tahmin normalleşecektir. Hikayeler, hikaye noktaları kullanılarak boyutlandırılır. Ekip, bir sprintte kaç hikaye puanı tamamlayabileceklerini tahmin eder. Ürün iş biriktirme listesinden seçilen hikayeler, sprint iş biriktirme listesi haline gelir. Her yeni sprintte scrum ekibinin kaç puan tamamlayabileceklerini tahmin etmede yardımcı olur.

6 – Sprint için seçilen kullanıcı hikayeleri sprint iş listesi olarak tanımlanır. Sprint iş listesi oluşturulduktan sonra değişmez. Sprint iş listesi, ekibin sprint hedefi oluşturmasına yardımcı olur. Her sprint, sprint planlama sürecini tekrar eder ve bu toplantı, dört haftalık bir sprint için genellikle sekiz saat sürer.

Kullanıcı hikayeleri bir sprintte tamamlanamayacak kadar büyük olmamalıdır. Hikaye büyükse ayrıştırılması ve sprintte gerçekleştirilebilecek boyuta indirgenmesi gerekebilir.

7- Planlama sonrası projede kimin ne yapacağını ve bundan sonra neyin yapılmasının önemli olduğunu belirleyen scrum master değil ekiptir. Scrum ekipleri kendi kendine organize organize olurlar. Ne yapacaklarını söylemesi için scrum mastera bakmazlar. Scrum master’ın rolü ekibe koçluk yapmaktır. Scrum yöneticisi, ekibin kimin hangi görevi yapacağını belirlemesine, koordine olmasına ve iş üzerinde kontrol sağlamalarına yardımcı olur. Proje ilerledikçe, scrum master desteğine ihtiyaç azalır, ekip kendi kendine liderlik eder.

Uzun sprintler risklidir çünkü müşteri incelemesi ve etkileşimini geciktirir. Ürün sahibi ve müşteri sprintin sonuna kadar herhangi bir değer görmez veya alamaz. Ekibin değişmesi (istifa vb.) sprint süresini etkiler. Sprint sırasında ekip üyelerinin değiştirilmesi önerilmez ancak uzun sprintin ortasında ekipten ayrılan veya yeni katılan insanlar yeni riskler ve problemler yaratırlar. Örneğin, işi öğrenme, ekiple kaynaşma, iletişim zorlukları vb.

8 – Scrum’da her sabah ekibin sprint hedefleri ile ilgili performansını değerlendirebileceği toplantı yapılır. Günlük toplantılar, sprint boyunca her gün aynı saatte ve aynı yerde gerçekleşir. Günlük toplantıda ekip üç soruyu yanıtlar:

  • Son görüşmemizden beri ne başardın?
  • Sonraki günlük toplantımızdan önce ne başaracaksın?
  • İlerlemenin önünde engeller var mı?

9 – Sprint’in sonunda, scrum ekibinin sprintte tamamlananları gözden geçirdiği toplantı olan sprint incelemesi yapılır. Sprint incelemesinde yalnızca tamamlanan çıktılar gösterilir. Çıktı, Bitti Tanımını karşılamıyorsa, ürün iş biriktirme listesinde tekrar önceliklendirilmesi için ürün sahibine iletilir. Proje müşterisi sprint incelemesi sırasında değişiklik talep edebilir. Müşteri çıktıyı gördüğünde, nelerin mümkün olduğunu görecek ve elde etmeyi umduğu değeri iyileştirmek için yeni fikirleri olabilecektir. Bu değişiklikleri scrum ekibi memnuniyetle karşılar.

Scrum ekibinin sprintte tamamladığı hikaye noktalarının sayısına hız denir. Başlangıç için hız tahmin edilemez olabilir, ancak zamanla takımın hızı sabit hale gelecektir.

10 – Sprintin sonunda Sprint retrospektif adı verilen geçmiş sprint sırasında neyin iyi gittiğine ya da iyi gitmediğine dair öğrenilen dersler toplantısı yapılır. Toplantının amacı, ürünü ve projeyi geliştirmek için fırsatlar aramaktır. Ürün sahibi, scrum ekibi ve scrum master, projenin iletişimini, başarılarını ve başarısızlıklarını şeffaf bir şekilde incelemek ve gözden geçirmek için toplantıya katılırlar. Amaç kimseyi suçlamak değil, sprintin kazançlarını ve kayıplarını dürüstçe tartışmaktır. Retrospektif, scrum ekibinin bir sonraki sprintte yapacağı proje çalışmasını geliştirmesine yardımcı olur.

Türkçe eğitimler

İngilizce eğitimler

 

Projelerde Maliyet Yönetimini Planlamak

7 Key Elements to Include in your Cost Management Plan - PM Tips

Maliyet Yönetimi Planı, projelerde maliyet yönetimine sistematik bir yaklaşım geliştirmek için hazırlanır. Maliyet Yönetimi Planı, temel tanımları, terminolojiyi, tahmin türlerini, tahmin araçlarını ve maliyet planlama ve kontrol süreci adımlarını açıklar. Projede maliyet bilinci kültürünün oluşturulmasına yardımcı olur.

Organizasyonlar aşağıdaki konularda bütçe belirlerler;

  • Üst Yönetimi – Organizasyonel hedefler ve stratejiler için gerekli bütçe
  • Fonksiyonel yöneticiler – İşlevsel bütçe
  • Proje – Proje bütçesi

Kötü maliyet planlaması ve kontrolü şirketin kaynaklarının yanlış ve kötüye kullanım riskini artırır.

Proje Yöneticisi, maliyet yönetimi planını hazırlamadan önce, kendi organizasyonunun mali politikalarını, mali yapısı ve proje ile ilgili politikaları hakkında bilgi sahibi olmalıdır.

Mali politikalar, maliyet planlamanın temel unsurlarını belirler. Örneğin, proje sürecinde hangi tür maliyet tahminlerinin kullanılacağı ve hangi amaçla kullanılacağı gibi soruların yanıtları, organizasyonun mali politikalarına bağlıdır. Maliyetlere, emek ve genel gider oranlarının eklenip eklenmeyeceği vb. netleştirilmelidir.

Maliyet planlama yaklaşımı, büyük ölçüde planlayıcının bakış açısına, deneyime ve organizasyon kültürüne bağlıdır. Örneğin, yeni bir ürün için üretim maliyeti tahmini geliştirilirken, üretim süreci, malzeme tedarik stratejisi, sürdürülebilirlik vb. konuların dikkate alması gerekir. Bunların her biri maliyet unsurudur. Üretim, dış kaynakla yapılacaksa, yüklenicinin üretim süreci, tesis ve malzeme tedarik stratejisi doğrultusunda maliyet yaklaşımı belirlenecektir.

Maliyet yönetimi planı, maliyet tahminlerini ve maliyet temel çizgisini içerir. Projenin nihai maliyetinin hangi gerçeklere ve varsayımlara dayalı olduğu değerlendirilmelidir. Bu değerlendirme ve sonuçları, kapsamın doğruluğu, mevcut tahmin verilerinin kalitesi, projenin aşamaları, planlama süresi, tahmincinin bakış açısı ve deneyimi, istenen doğruluk, mevcut tahmin araçları vb. faktörlere bağlı olacaktır. Bu faktörler tanımlanarak maliyet yönetimi planı hazırlanır.

Maliyet yönetimi planı tamamlandıktan sonra, maliyetleri ve riskleri değerlendirmek gerekir. Maliyet yönetimi planı birden fazla amaca hizmet edebilir. Örneğin, alınan fonların takibi, nakit akışı vb. Maliyet yönetimi planı teklif veya sözleşme için temel teşkil edebilir. Bazı durumlarda, maliyet tahminleri, doğruluklarını ve güven düzeyini artırmak için diğer maliyet yönetimi planlarıyla karşılaştırılır.

Geliştirme Adımları

Maliyet yönetimi planı zaman çizelgesiyle birlikte ele alınmalıdır. Proje aktivitelerini tamamlamak için gerekli olan kaynakların ve harcayacakları eforun dikkate alınması ile gerçekçi maliyetlere ulaşılabilir, nakit akışı yönetilebilir.

Risklerin değerlendirilmesi olası değişikliklerin ve yaratacağı ek planlanmamış maliyetler için uygun maliyet tahmini oluşturmayı amaçlar. Beklenmedik Durum Yedeği olarak adlandırılan bu miktar, proje risklerini maliyet olarak yansıtmayı sağlar.

Risklerin analiz edilmesi ve beklenmedik durum yedeklerinin belirlenmesinde maliyetler düşük tutulmaya çalışılır.

İkinci adımda maliyet tahmini ile ilgili detaylar belirlenir. Ör. Para birimi, tahmin detay seviyesi vb. Örneğin aynı para birimi üzerinden tahmin yönetimi, kontrolü ve karşılaştırmayı kolaylaştırır. Tahmin türü parasal olmayıp sadece efor (kişi/gün) üzerinden yapılabilir.

Bir sonraki adımda maliyet planlama süreci tanımlanarak, tüm paydaşların iletişim kurmaları için ortak bir dil sağlanmaya çalışılır.

Maliyet planlama süreci beklenen ayrıntı düzeyine göre farklılık gösterir, ancak temel adımlar benzerdir. Maliyet planlamasını planlamakla başlamak yeniden çalışmayı en aza indirir, toplam çabayı azaltır. İlk olarak, tahminleri yapacakları ve uygun tahmin formatını belirlemek gerekir. Tahmin yapmaya yönelik zaman sınırlaması (ör. 3 gün içinde vb.) ve tahmin inceleme/değerlendirme ayrıntıları, beklenen kesinlik vb. belirlenmesi çok önemlidir. Maliyeti planlamanın da maliyeti olduğu unutulmamalıdır.

Maliyet tahminlerinin doğru yapılması için tahmin yapılacak aktivitenin doğru tanımlanması gerekir. Açık, net ve anlaşılır aktivitelerin, uygulanabilir çözümleri ve çıktılarının tahmin kalitesine etkisi büyüktür. Belirsizliklerin ve varsayımların açıklığa kavuşturulması, sözleşmelerden ve standartlardan kaynaklanan kısıtlamaların belirlenmesi gerekir.

Bir sonraki adımda doğrudan ve dolaylı maliyetler için tahmin üretilir. Tahmin ile ilgili algoritma olması gerekir. Örneğin;

  • İşçilik maliyeti = Miktar × (saat ∕ birim) × (TL ∕ saat)
  • İşçilik maliyeti = 200 birim üretim × (5 saat ∕ ürün) × (100 TL ∕ saat)
  • İşçilik maliyeti = 100,000 TL

İşçilik ücretleri genel giderleri içerir, malzeme vb. maliyetler eklenir.

Maliyetler belirlendikten sonra doğrulanmaları gerekir. Uzman görüşü veya geçmiş proje kayıtları kullanılabilir.

Gözden geçirme sonrasında proje başlangıcında belirlenen bütçeyi aşım söz konusu ise iyileştirme yapılır. Finansal Limit Uzlaşması yapılarak proje maliyetleri verilen bütçe ile uyumlaştırılır.

Hazırlanan bütçe ilgili paydaşlarla paylaşılabilir.

Proje maliyet planlaması proje tamamlanana kadar sürer. Tüm gerçekleşen maliyetler toplanır, analiz edilir, maliyet planıyla karşılaştırılır ve projenin ileri safhalarına yönelik iyileştirmeler yapılır.

İpuçları

  • Proje kapsamı ile ilgili olarak müşteri ve tüm paydaşların ihtiyaçlarını ve ürün tanımlarını netleştirmek için sorular sorun.
  • Maliyet planlama sürecini takip edin. Hiçbir adımı atlamayın. Eğer süreç çalışmıyorsa, değiştirin.
  • “Sayısallaşmıyor” zihniyeti değiştirin. Projede büyük resmi görmeye çalışın ve gösterin.
  • Her şeyi belgeleyin. Varsayımları, referansları, kaynakları, kapsam dışı durumları vb. çalışmalarınıza dahil edin
  • Süreç dahilinde yapılacak denetimler, tahminin kalitesini artırır.
  • Başlangıç tahminlerinin değişeceği neredeyse kesindir. Değişiklikleri kayıt altına alın ve geleceğe yönelik planlamayı sürdürün.
  • Tahmini işi yapacaklardan alın ve verdikleri taahhütü tutturmaları için destekleyin.

Türkçe eğitimler

İngilizce eğitimler

 

Çevik Projelerde Tedarikçi Anlaşmaları

How to draft an agreement? - A primer - iPleaders

Uyarlanabilir(çevik) projelerde sözleşme müzakerelerinden çok işbirliğine değer vermek, pazarlık yapıl(a)mayacağı anlamına gelmez. Taraflar için için neyin iyi olduğunu kazanan-kaybeden zihniyetiyle değil, kazanan-kazanan ilkesi ile müzakere etmek gerekir.

Sözleşmelerdeki çok katmanlı yapılar

Garantilerin, anlaşmazlık durumunda çözüm yöntemlerinin ve ek talep/değişiklik yönetimi vb. konuların sözleşmeye konmasına izin verilmelidir. Hizmet verme oranları ve ihtiyaç duyulan kaynaklar vb. değişebilecek öğeler sözleşmede yer almalıdır. Proje kapsamı, zaman çizelgesi ve bütçe gibi çevik bileşenler için yapılacak çalışmalar belirtilmelidir. Bu yaklaşım her iki tarafa esneklik sağlar ve proje için bazı sınırlar koyar.

  • Teslim edilen değeri vurgulamak – Sözleşmeleri, projede değişebilecek belirli kilometre taşları ve çıktılar üzerinde yapılandırmak yerine, değer odaklı öğelere odaklanılabilir.
  • Sabit fiyat artışları – Sözleşmede, kullanıcı hikayelerine değer atanarak, tamamlanan kullanıcı hikaye puanlarına göre fiyatlandırma yapılabilir. Bu sayede, müşterinin tedarik bütçesini nereye harcadığı konusunda daha fazla kontrol sahibi olmasını sağlar. Aynı zamanda satıcının değişmesi muhtemel olan sabit ücret riskinden kaçınmasını sağlar.
  • Aşılmaması gereken sınırlamalar – Bu yaklaşımla, ürün biriktirme listesinin değişebileceği, ancak satıcının önceden tanımlanmış sınırlı bir miktara kadar çalışma saatleri sattığı anlayışıyla, tedarik edilen iş gerekli bütçe ayrılabilir. Bu adil yaklaşımda her iki taraf da riski paylaşır.
  • Teşvik ve Ceza – Bu yaklaşım, satıcıya ürünü beklenenden daha erken teslim etmesi için teşvik sunarken proje beklenenden daha geç tamamlandığında, saat başına daha düşük ödeme şeklinde bir ceza sunabilir.
  • Erken iptal – Örneğin satıcı projenin yüzde 50’sini tamamladığında müşteri projenin geri kalanına ihtiyacı olmadığını belirlerse, müşteri kalan bakiyeden daha az bir kapanış ücreti ödeyebilir. Müşteri, teslim edilen işten daha fazlasını öder, satıcı yapmak zorunda olmadığı iş için gelir elde eder.
  • Dinamik kapsam – Sabit ücretli sözleşmelerde müşterinin projede önceden tanımlanmamış konularda ek talep yapmasına izin verir. Müşterinin proje kapsamını çevik bir biçimde değiştirmesine olanak tanıyın ancak ya ek iş için ek ücretlendirme ya da işin kalanında kapsamı daraltın.
  • Ekip Büyüklüğü – Basitçe satıcı, çevik proje ekibinin harcadığı emek ve zamanı satar. Sözleşmede kaynak kısıt olarak yer alırsa bu kısıta uygun süre ve bütçe belirlenir. Müşteri işi hızlandırmak vb. ek gereksinimlerle geldiğinde ekip büyütmenin bedeli ve etkilerinin yansıtılacağı sözleşmeye eklenebilir.
  • Birden Fazla Satıcı – Projenin birden fazla tedarikçisi olabilir. Bit tedarikçinin diğerleri ile olan etkileşimi ve ilgili beklentiler sözleşmeye yansıtılmalıdır.

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Takvimler

Resource Calendars in Exchange Online | Office 365

Proje Yönetiminde Zaman Çizelgesinin doğru hazırlanabilmesi için öncelikle çalışılan ve çalışılmayan zamanların belirlenmesi gerekir. Üç adet takvimi dikkate almamız gerekir;

  • Şirket Takvimi
  • Proje Takvimi
  • Kaynak Takvimi

Şirket Takvimi

Şirketin çalışılan ve çalışılmayan zamanlarını gösterir. Mesai saatleri, resmi tatiller, planlı duruşlar vb. takvimde çalışılmayan zaman olarak işaretlenmelidir.

Proje Takvimi

Proje ekibinin çalışmasının planlandığı günleri, tarihleri ve saatleri gösterir. Çoğunlukla şirket takvimi ile aynıdır. Ancak bazı projeler özelinde farklı çalışma zamanları seçilebilir. Örneğin projenin kritikliği sebebiyle haftanın 7 günü çalışma veya başka bir durumda projeye haftada bir gün ayırma vb.

Proje ekibinin günün hangi saatinde çalışacağını ve projenin hangi gün/saatte çalışmayacağını (örneğin tatiller vb.) gösterir.

Proje takvimi, proje ortamı ve kısıtlamalarından etkilenir. Örneğin, gün boyunca gürültülü çalışma varsa çalışma zamanı değiştirilir, asfalt atma projeleri yalnızca trafiğin az olduğu hafta sonları gerçekleştirilebilir vb.

Kaynak Takvimi

Kaynak Takvimi, belirli bir kaynağın (personel, makineler vb.) çalışacağı günleri, tarihleri ve saatleri gösterir.

Kaynakların birden fazla proje için aynı anda çalışması gerekebilir, belirli bir proje için kullanılabilirlik payları sınırlı olabilir veya personelin planlanmış tatili vb. olabilir.

Kaynak Takvimi, Kaynakların Sağlanması süreci sonrasında netleşir. Kaynaklar netleştikten sonra çalışma durumları doğrultusunda proje takviminde gerekli güncellemeler yapılır.

Proje Takvimi ve Kaynak Takvimleri, proje ortamındaki değişiklikleri ve proje ekibinin kullanılabilirliğini yansıtmak için planlama ve yürütme süreçleri sırasında sürekli olarak güncellenirler. Her iki takvim Proje Yöneticisinin Proje Zaman çizelgesini geliştirmesine yardımcı olur.

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Ürün Kırılım Yapısı(ÜKY)

The Four Phases of Project Management

Ürün geliştirme projelerinde ürün ve süreç bazlı planlama birlikte ele alınır. Bu yaklaşım, önce ürünün tanımlandığı ve ardından proje aktivitelerinin, teslimatların ve ürünü oluşturup teslim etmek için gereken kaynakların planlandığı bir yaklaşımdır.

ÜKY, nihai ürünü bileşenlerine ayırmaktır.

İş Kırılım Yapısı (İKY) gibi, ÜKY ürün ve bileşenleri arasındaki ilişkiyi temsil eden görsel bir sunumdur. İKY ve ÜKY farklı amaçlar için kullanılır. İkisi arasındaki temel fark, ÜKY’nin ürüne, İKY’nin ise ürünü yaratmak için gereken işlere odaklanmasıdır.

ÜKY, ürünü tasarlayacak ve geliştirecek ürün uzmanları ve çapraz fonksiyonel ekip üyeleri ile oluşturulur.

ÜKY, projenin en sonunda oluşturulacak ve geliştirilecek olan ürünün diyagramı çizerek başlatılır. Müşterinin beklentilerini karşılayan çözüm belirlenir. Çözüm yalnızca temel ürünü değil, aynı zamanda müşterinin beklentisini karşılamak için ihtiyaç duyulan, ürünün bir dizi etkinleştirici unsurunu da içerebilir. Örneğin telefon tasarlanıyorsa şarj aleti, kutusu vb.

Çözümün tamamının iki bölümden oluştuğu söylenebilir;

  1. Ürünün temel bileşenleri
  2. Ürünün etkinleştirici bileşenleri

Temel bileşenler, entegre edildiğinde fiziksel ürünü oluşturan somut öğelerdir. Sistem dilinde, entegre ürünün alt sistemleridir. Etkinleştirici bileşenler, ürünün müşterilerin beklentilerini karşılamasını sağlamak için ihtiyaç duyulan ek unsurlardır. Ürünün hem temel hem de etkinleştiren bileşenlerinin projenin planlamasına dahil edilmesi gerekir.

Ürün ile ilgili çözüm ayrıca bir yazılım platformu, kablosuz iletişim altyapısına arayüz, üretim, kalite güvencesi, müşteri desteği vb. ihtiyaç duyulan diğer önemli unsurları da içermelidir. Bunlar, ürün teslim edildiğinde müşteri ve kullanıcı memnuniyetini sağlamak için ihtiyaç duyulan, ürünün etkinleştirici bileşenleridir.

Hazırlama

  1. İKY’de olduğu gibi, ÜKY içinde birden fazla yapı(hiyerarşik, tablo, zihin haritası vb.) seçeneği mevcuttur. Hiyerarşik ve tablo yapısı İKY ile benzerdir.
  2. Karar verilen ÜKY yapısı ile ürün, bileşenlerine ve alt bileşenlerine ayırılır. En üst düzeyde (veya zihin haritasında ortada), ortaya çıkacak entegre ürün bulunur.
  3. Entegre ürü birincil bileşenlerine ayırılır. Mantıksal bir ayrıştırma noktasına (proje çıktısı) ulaşılana kadar her bileşen alt bileşenlerine ayrıştırılır.
  4. Süreç ilerledikçe, ÜKY’nin en alt seviyesinden yukarıya doğru ilerleyerek, her seviyedeki alt bileşenlerin, alt bileşen veya bileşeni oluşturmak için entegre olup olmadığı doğrulanmalıdır.
  5. Üst düzey ürün doğrulanana kadar bu işleme devam edilir. Doğrulama işlemi sırasında eksiklikler keşfedilirse, gidermek için ayrıştırma adımına geri dönülür.

ÜKY, projenin neyi yaratması gerektiğini açıklamak için kullanılır. Tam ölçekli proje planlaması başlamadan önce oluşturulmalıdır. Açıkçası, “nasıldan” önce “ne” gelmelidir.

Faydalar

  • Ürün geliştirme projelerinde ürün ve süreçlerin aynı anda ele alınmaması, bu iki çabanın birbirinden kopması ve hatta birbiriyle çelişmesine yol açabilir. Planlama hem neyin geliştirileceğine hem de nasıl geliştirileceğine odaklamalıdır.
  • ÜKY, proje yöneticisinin ürün ve projenin çeşitli bileşenlerini görselleştirmesine yardımcı olur.
  • Görsel temsil, çok karmaşık projeler için yapı ve düzen oluşturmaya yardımcı olur.
  • ÜKY kullanımında elde edilen ancak somut olmayan önemli bir fayda, ekip uyumunu artırmasıdır. ÜKY, planlama sürecinin başlarında, proje ekibinin oluşmaya başladığı zamanda oluşturulur. ÜKY’nin geliştirilmesi, ürün uzmanları arasında işbirliğine dayalı çalışmayı teşvik eder, öğrenme artar.

Hiyerarşik

Product breakdown structure - Wikipedia

Tablo

Work Breakdown Structure (WBS) 2022 | Project-Management

Zihin Haritası

Product Feature Mind Map | Creately

 

Türkçe eğitimler

İngilizce eğitimler

Sohbet: Agile Dünyada Proje Yönetim Gurularını Dinleyelim

Proje Yönetimi konusunda düşüncelerimizi paylaştık

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Güç

The Power of the Project Manager - PM Tips

Güç algısı, proje ekibinden yönetime ve tüm paydaşlara kadar diğer kişilerin sadece projeyi değil, aynı zamanda proje yöneticisini nasıl gördüğünü ve yaklaştığını ifade eder.

Aşağıda yer alan güç tanımları proje yöneticisinin bakış açısından çerçevelendirilmesine rağmen müşteriden proje sponsoruna kadar herhangi bir paydaş bu gücü elinde tutabilir. Bunların hepsi organizasyonların politik ortamının parçasıdır. Uygulanmakta olan gücü anlayabilmek, proje yöneticisi olarak projeyi ve sonuçlarını daha iyi yönetmeye yardımcı olur.

  • Konumsal güç – Proje yöneticisinin veya paydaşın gücü, sahip olduğu konumun bir sonucudur. Bu aynı zamanda resmi, yetkilendirilmiş ve meşru güç olarak da bilinir.
  • Bilgilendirme gücü – Proje yöneticisi veya paydaş, verinin toplanması ve bilginin dağıtımı üzerinde kontrole sahiptir.
  • Referans gücü – Proje yöneticisi veya paydaş, proje ekibinin onunla geçmiş deneyimleri nedeniyle saygı görür veya takdir edilir. Proje yöneticisinin veya paydaşın organizasyondaki güvenilirliği ile ilgilidir.
  • Durumsal güç – Proje yöneticisi veya paydaş, organizasyondaki belirli durumlardan dolayı güce sahiptir.
  • Kişisel veya karizmatik güç – Proje yöneticisi veya paydaş, başkalarının sevdiği sıcak bir kişiliğe sahiptir.
  • Güçten kaçınma – Proje yöneticisi veya paydaş harekete geçmeyi, dahil olmayı veya karar vermeyi reddebilmektedir.
  • Uzman gücü – Proje yöneticisi veya paydaş bir disiplinde derin becerilere ve deneyime sahiptir.
  • Ödüllendirme gücü – Proje yöneticisi veya paydaş proje ekibini ödüllendirebilir.
  • Cezalandırıcı veya zorlayıcı güç – Proje yöneticisi veya paydaş proje ekibini cezalandırabilir.
  • Etkileyici güç – Proje yöneticisi veya paydaş, etkileme yoluyla proje ekibi ve diğer paydaşların beğenisini kazanabilmektedir.
  • Baskıya dayalı güç – Proje yöneticisi veya paydaş, proje ekibinin proje çalışmasını gerçekleştirmesini sağlamak için seçeneklerini kısıtlayabilmektedir.
  • Suçluluğa dayalı güç – Proje yöneticisi veya paydaş, projeye uyum sağlamak için proje ekibini ve diğer paydaşları suçlu hissettirebilmektedir.

Proje yöneticisi paydaşa ve duruma göre gücünü ayarlayabilmeli, birlikte çalıştığı paydaşların güçlerinin ve olası etkilerinin farkında olmalıdır.

Türkçe eğitimler

İngilizce eğitimler

Projelerde Gereksinim Belirsizliklerini Yönetmek

Why and How to Embrace Uncertainty, According to Psych Experts. Nike.com

Projelerde paydaşların gereksinimleri toplanırken netliğin, eksiksizliğin ve gereksinim kalitesinin kontrol edilmesi gerekir.

Gereksinim incelemesinin amacı, gereksinimlerin en yüksek kalite düzeyine göre geliştirilmesini ve paydaşların gereksinimleri doğru, eksiksiz ve açık bir şekilde anlamasını sağlamaktır.

Dikkat Edilmesi Gerekenler

  • Gereksinimler, birden fazla yoruma açık olmamalıdır.
  • Gereksinimler için kullanılan terimler bir sözlükte tanımlanmalı ve tutarlı bir şekilde kullanılmalıdır.
  • Zayıf dilbilgisi kullanılmamalıdır.
  • “Eğer x olursa y yapılmalı” vb. ifadelerde tüm koşullar içerilmeli, açık bırakılmamalıdır.
  • Hızlı, kolay, son teknoloji, basit, nispeten, uygun ve mükemmel kelimeleri kullanılmamalıdır.
  • Yakında, neredeyse, en kısa zamanda, oldukça, daha fazla, çoğu, bazıları, benzer, sonunda ve yakın zamanda vb. kesin anlamı olmayan kelimeler kaldırılmalıdır.
  • “İleride tanımlanacaktır” ibaresi olmamalıdır.
  • Olması gereken, mümkünse, olabilir vb. isteğe bağlılığı tanımlayan sözcükler yer almamalıdır.
  • Gereksinimleri toplayan ekibin, ilgili kısaltmalar ve belirli terimlere yönelik bilgi sahibi olması önemlidir. Terimlerin kullanım alanına göre anlamlarının farklılaşabileceği unutulmamalıdır. Evrensel olmayan terimlerin örneklerle pekiştirilmesi gerekebilir.
  • Zayıf açıklamalar gereksinimlerde belirsizliğe yol açar. Nitel terimleri nicelleştirmeye çalışmak gerekir.
  • Mümkünse, diyagram, algoritma, tablo, kullanım senaryosu, kullanıcı öyküleri veya bir prototip kullanarak gereksinimin net olarak anlaşılması sağlanmaya çalışılmalıdır. Belirsizliği azaltmak ve kavrayışı artırmak için süreç ve veri akış diyagramları, algoritmaları kullanın.
  • Gereksinim kendi içinde karmaşıksa anlaşılmasını kolaylaştırmak için tablo kullanın. Tablolar, beklentilerin belirli tanımlar altında birden fazla koşul ile ele alınabilmesini sağlarlar.
  • Kullanı(m)cı senaryoları, sistem kullanımını ve bağlamını görselleştirmek kullanıcı deneyimini tanımlarken beklentilerin netleştirilmesini sağlar. Kullanıcı hikayeleri bir iki cümle ile kısaca gereksinimi açıklayabilir.

Gereksinimlerin belirsizliği iki adımda incelenebilir;

Adım 1: İlk belirsizlik incelemesi – Gereksinimi ilk alan kişi tarafından yapılır. Konu hakkında hiçbir şey bilmeyen biri olabilir. Bu incelemenin amacı, gereksinimin sıradan bir kişi tarafından açık ve anlaşılır olmasını sağlamaktır. Alan uzmanı olmadıkları için, açıkça yazılı olmayan konuları anlayamazlar.

Adım 2: İlk belirsizlik incelemesinden sonra konu uzmanı gereksinimi inceler. Gereksinimin eksiksiz ve doğru olmasını sağlamaya odaklanır, terimler incelenir ve netliği artırmak için diyagramlar, tablolar, kullanım senaryoları veya prototipler talep edilebilir.

Gözden geçiren tarafından yapılan yorumlar diğerlerinin görüşüne sunulabilir.

Gereksinimlerin netleştirilmesine harcanacak efor ileride yaşanacak problemlerin yaratacağı efordan az olacaktır.

Bu yaklaşımla, gereksinimleri olanlar ifade etme konusunda gelişeceklerdir.

Faydalar

  • Gereksinim belirsizliğini kontrol etmek, gereksinimlerin giderek netleşmesini sağlayacaktır.
  • Gereksinimleri ifade etmek için harcanan süre azalacaktır.
  • Erken geri bildirim daha yüksek kaliteli gereksinimlerle sonuçlanacaktır.
  • Hatalar daha erken fark edilerek giderilecek, maliyetler düşecektir.
  • Gereksinimleri incelemek, odaklanma ve zamanında geri bildirim sağlayacaktır.
  • Açık, özlü ve ölçülebilir gereksinimler, yeniden çalışmayı ve değersiz iş yapmayı azaltacaktır.

Türkçe eğitimler

İngilizce eğitimler