Özet
Geleneksel doğrusal proje yönetimi yaklaşımı sizi bütçenizi aşmış, yetersiz geliştirilmiş bir ürünle ve gecikmiş bir pazar lansmanıyla mı baş başa bıraktı? Çevik bir yaklaşım, birden fazla geri bildirim ve revizyon aşaması gerektiren karmaşık projelerde yöneticilere daha fazla esneklik, şeffaflık ve hesap verebilirlik sunar. Bu Çevik Proje Yönetimi sunumuyla, müşteri ihtiyaçlarına odaklanarak yinelemeli bir yaklaşımla proje başarısını en üst düzeye çıkarın.
Slayt Öne Çıkanlar
Çevik geliştirme sürecinde, bir yönetici gereksinimleri ve proje kısıtlarını alır, ekip olası çözümler geliştirir ve nihai onay veya ürün lansmanına kadar birden fazla yineleme yayınlar. (Slayt 7)
Scrum, yaygın olarak kullanılan bir çevik metodolojidir. Scrum'daki ekip rolleri, proje yönetim ekibindeki ana paydaşları ve sorumluları detaylandırmak için bir organizasyon şeması olarak sınıflandırılabilir. (Slayt 9)
Kanban panoları, iş yükü yönetimi ve ilerleme takibi için vazgeçilmezdir.Görselleştirmeleri, çevik yönetimde iş yükünü sınırlamak, iş akışlarını yönetmek ve olumlu geri bildirim döngüleri oluşturmak için kullanılabilir. (Slide 12)
Sonuç
Çevik proje yönetimi yöntemi, her büyüklükteki organizasyon tarafından kullanılabilir. Özellikle eski sistemlere sahip büyük organizasyonlarda, çevik yaklaşım geleneksel şelale modeline kıyasla daha verimli bir iş akışı sağlayabilir. Çevik yöntemle yöneticiler, ürün geliştirme ve proje organizasyonunda yinelemeli ve iş birliğine dayalı bir yaklaşım benimseyebilirler. Çevik yaklaşım, müşteri ihtiyaçlarına odaklanır ve gerçek pazar uyumuna sahip bir ürün oluşturmak için gereken kaynakları ve genel giderleri en aza indirir. Artan esneklik ve hızlı tempo, daha kısa teslim süreleri sağlar — bu da proje yöneticileri için büyük bir avantajdır.
Uygulama
Metodoloji
Çevik metodolojinin genel bir bakışını ve proje yönetiminde nasıl kullanıldığını anlatarak başlıyoruz. [related bracelet="agile"] ilk olarak yazılım geliştirme için daha yeni bir yaklaşım olarak geliştirilmiş olsa da, felsefesi proje yönetimi, ürün geliştirme ve hatta organizasyonel yönetim alanlarına da uyarlanmış ve uygulanmıştır.Herhangi bir ekibin hızlı yanıt verebilmesi ve kolayca uyum sağlayabilmesi için, çevik yöntem geleneksel şelale yöntemine kıyasla çok daha güçlü bir yöntem olabilir; çünkü şelale yönteminde görevler doğrusal bir sırayla tamamlanır.
Geleneksel ve çevik proje yönetimi yöntemleri arasında bazı temel farklar vardır. Çevik yaklaşım, ürün geliştirmeyi son kullanıcıya odaklayarak çoklu geri bildirim ve revizyon turlarıyla müşteri merkezlidir. Ayrıca esnektir; bu da onu, geleneksel modellerde karşılaşılan batık maliyet yanılgısından ayıran önemli bir noktadır. Bu yanılgı, yöneticilerin bir plan yapıldığı için, süreçte uyarı işaretleri çıksa bile plana sadık kalmaları gerektiğini düşünmelerine yol açar. Oysa çevik yaklaşım, paydaşlara ve katılımcılara gerektiğinde yön değiştirme, yeni bir yineleme oluşturma veya sıfırdan başlama fırsatı sunar. Geleneksel yöntem ise genellikle dokümantasyon ve zaman alan idari detaylara odaklanır; bu da ekip üyelerinin tamamlamak zorunda hissettiği, ancak maliyetli ek yük getiren işlerdir. Bu durum, üretken uygulama görevlerinden değerli saatlerin kolayca alınmasına neden olabilir.
Çevik yaklaşım, en kısa sürede çalışan çözümler ve maksimum iş değeri elde etmeyi hedefler.Çevik bir yaklaşımla yönetilen projeler genellikle daha kısa sürüm döngülerine sahiptir, bu da pazara sunma süresini hızlandırır. Bu nedenle çevik yöntem, özellikle ürün veya ürün özelliği geliştirme süreçlerinde oldukça uygundur. (Slide 3)
Avantajlar
Şimdi çevik yaklaşımın bazı temel avantajlarına geçiyoruz. Bunlar arasında önceliklerin daha iyi yönetilmesi, proje görünürlüğünün artması, ekip moralinin yükselmesi, iş ihtiyaçları ile BT arasında daha iyi uyum, verimlilikte artış ve pazara daha hızlı çıkış yer alır. Buradaki yüzdeler, bir proje yöneticisinin çevik yönteme geçişten sonra bu temel alanlarda nasıl bir gelişme olduğunu değerlendirmek için kullanabileceği düzenlenebilir grafiklerdir. (Slide 4)
Süreç
Çevik proje yönetimi süreci aşamalar halinde incelenebilir: ön hazırlık, projenin başlangıcı ve ilk gereksinim seti (burada bunları gereksinimler A olarak gruplayalım), bu ilk gereksinim seti için geri bildirim ve gereksinimler B, ardından geri bildirim ve gereksinimler C. Proje gereksinimleri, bazen her aşamada tamamlanacak görevler olarak da adlandırılır.
Ön hazırlık aşaması yalnızca çevik yönteme özgü değildir.Her projenin, yönetim metodolojisinden bağımsız olarak başlatılması için bir yol haritasına ihtiyacı vardır. Ön hazırlık aşaması, yöneticilerin ürün vizyonunu tanımladığı, projenin kapsamını belirlediği, gerekli ana görevleri, dış paydaşlarla yapılacak sözleşmeleri ve önerilen bir sürüm planını oluşturduğu aşama olabilir. Çevik yaklaşımın temel amacı yön değiştirmeye olanak tanımak olduğundan, orijinal sürüm planı daha çok gidilebilecek genel bir yol haritası niteliğindedir ve gerektiğinde uyarlanabilir.
Örneğin, bir e-ticaret sitesine canlı yayın alışveriş özelliği eklemek istiyorsunuz. Ön hazırlık aşaması, ürün vizyonunun geliştirilmesi ve mevcut web siteniz ve kullanıcı tabanınızla nasıl entegre edileceği, ilk canlı yayın içeriklerinde yer alacak yeteneklerle yapılacak ön sözleşmeler ve orijinal sürüm planınız ile özelliklerinizin belirlenmesi olacaktır.
Şimdi çevik süreci başlatıyor ve projenin "Grup A" gereksinimlerini gerçekleştirmeye koyuluyorsunuz. Bu Canlı Yayın özelliği için, Grup A gereksinimlerinizin kullanıcı arayüzünün nasıl çalışacağına dair düşük sadakatli bir wireframe oluşturmak olduğunu varsayalım.Wireframe geliştirme aşamasında, üç farklı versiyon oluşturmanız ve ardından birkaç kullanıcıya test ettirmek üzere düşük sadakatli bir prototip geliştirmeniz gerekecek.
Test grubunuzdan geri bildirim topladıktan sonra, bu geri bildirimleri "Grup B" gereksinimlerine entegre ederek bir sonraki iterasyonunuzu oluşturma zamanı gelmiştir. Bu noktadaki ilk görevlerinizden biri, çalışma sonuçlarını analiz etmek ve sentezlemek, bunları anlamlandırmak olabilir. Bir diğeri ise yazılım ekibiyle UX değişikliklerini tartışmak, düşük sadakatli prototipi güncellemek ve yeni bir geri bildirim turu için yüksek sadakatli mockuplar oluşturmaktır. Yeni bir kullanıcı grubunu geri bildirim için davet edin, ardından onların girdilerini sentezleyip "Grup C" gereksinimlerine entegre ederek süreci tekrarlayın ve ürünü piyasaya sürün.
Şimdi karşılaştırmak için, bu proje geleneksel modelle ve Çevik olmadan nasıl olurdu? Geliştirme ekibiniz kullanıcı arayüzünü çizer, yüksek sadakatli bir prototip oluşturur, bunu mükemmel versiyonu üretmek üzere yazılım ekibine gönderir ve tamamen bitmiş ürünü piyasaya sürerdi. Ancak bu noktada, kullanıcıların kafasının karıştığını fark edersiniz. Zincirin birçok halkası bir araya geldiği için değişiklik yapmak çok daha zor ve yavaş olurdu.Her küçük değişiklik için, başka birçok değişikliği de beraberinde getirebilir. Bu nedenle çevik yöntemler genellikle daha başarılı olur ve hatalar geri döndürülemez hale gelmeden önce tespit edilebilir.
Süreç detayları
Daha ayrıntılı bir çevik süreç, yaşam döngüsüne dahil olan personeli ayrıştırır. Proje, hem iç hem de dış paydaşlar, bir yönetici veya yatırımcı ya da geliştirme talebinde bulunan bir kullanıcı profili ile başlar. Talepleri iletilir ve ardından proje gereksinimlerine dönüştürülür. Proje gereksinimleri, proje veya ürün sahibi tarafından yönetilir. Bu ekip lideri, geliştirilecek ve dağıtılacak gereksinimler listesini yönetmek için kullanılacak raporları hazırlar. Bu örnekte üç ana sürüm bulunmaktadır. Her sürümün yayınlanmasından sonra, bir sonraki sürümden önce uygulanacak iyileştirme alanları (geri bildirimlere dayalı olarak) için bir birikmiş iş listesi oluşur. (Slide 6)
Scrum
Scrum, çevik proje yönetiminin yaygın bir yöntemidir. [related bracelet="scrum"] altı temel unsur içerir.İlk olarak, ürün backlog'u yani önceliklendirilmiş ve genellikle iş paketlerine bölünmüş gereksinimler listesidir. Scrum'ın bir diğer unsuru ise sprintlerdir; bu, işi belirli bir süreye (genellikle birkaç gün) böler ve belirli bir iş paketi üzerinde işlevsel bir sonuç elde etmek için yoğunlaşır.
Bu sprintler, ekibin sonucu sunup geri bildirim aldığı ve bu geri bildirimin bir sonraki sprinte entegre edildiği bir toplantıda gözden geçirilir. Ardından, işi daha küçük paketlere bölmek veya daha küçük ekiplere tahsis etmek ve her paket için kalan işleri belgelemek amacıyla bir sprint backlog'u kullanılır. Amaç, ürünü sürekli iyileştirme artışlarıyla şekillendirmek ve her sprintte potansiyel olarak sevk edilebilir bir işlevsellik elde etmektir. Son olarak, genellikle scrum master tarafından yönetilen günlük scrum toplantıları, her şeyin doğru yönde ilerlediğini teyit eder.
Psikografik profil segmentasyonu yapmak için müşterilerinizi yaşam tarzı, kişilik, değerler ve ilgi alanlarına göre ayırın. Örneğin, hedef müşterilerinizin kentsel profesyonel bir yaşam tarzını benimsediğini varsayalım. Kişilikleri meraklıdır ve yeni inovasyonlara, en son teknolojik ürünlere ilgi duyarlar.Onlar istikrarı, akıcılığı ve kullanım kolaylığını önemserler ve sanat ve eğlenceden teknolojiye kadar her alana ilgi duyarlar. Ancak, onları birleştiren ortak ilgi alanı, günlük görevleri daha kolay bir şekilde tamamlamaktır.
Diyelim ki bu görselleştirmeyi günlük scrum toplantınızda kullanmak istiyorsunuz. Aslında bu bilgileri düzenleyerek her bir unsurun altında gözden geçirmek istediğiniz detayları listeleyebilirsiniz. Örneğin, ürün backlog'u altında, madde işaretlerini henüz uygulanması gereken gereksinimlerle değiştirebilirsiniz. Sprint başlığı altında, sprintin mevcut durumunu özetleyebilirsiniz. Sprint backlog kartınız ise tamamlanması gereken işleri kapsayacaktır. (Slide 8)
Kanban
Bir diğer faydalı çevik yöntem ise Kanban'dır. [related bracelet="kanban"] yalın bir iş akışını not kartı formatında görselleştirir; sütunlar geliştirme sürecinin adımlarını, kartlar ise bireysel görevleri temsil eder. Kanban, sürecin topluca tanımlanması ve üzerinde uzlaşılan yönergelerle politikaları açık hale getirir ve düzenli toplantılar yoluyla sürekli iyileştirme için doğal bir geri bildirim döngüsü oluşturur.Ayrıca, Kanban darboğazların azaltılması yoluyla iş akışlarını yönetmeyi kolaylaştırır çünkü herkes zincirdeki tıkanıklığın nerede olduğunu görebilir. Ve devam eden işleri sınırlayarak çoklu görev yapmayı önlediği için, Kanban ekip üyelerinin aşırı yüklenmesini engeller.
Renkleri, bireysel ekip üyelerini ve onlara atanan görevleri temsil etmek için kullanabilirsiniz. Kanban panosu, bir görev birikimi, kabul edilen görevler ve uygulanacak, test edilecek ve ardından tamamlanacak görevlerden oluşur.
Canlı yayın alışveriş özelliğimizle, birikim daha önce tanımladığımız tüm görevleri içerir; örneğin, wireframe geliştirme, UX özellikleri ve yönetilmesi gereken yetenek veya test gruplarıyla yapılacak koordinasyonlar. Proje yöneticisi olarak, görevleri birikimden alıp bireysel ekip üyelerine atayacaksınız. Gördüğünüz gibi, ana yazılım geliştirici açık yeşil renkte olabilir. Burada yapılacaklar listesinde üç, devam edenlerde ise bir görevi var. Yetenek yönetiminden sorumlu olan iş ortaklıkları koordinatörü ise koyu yeşil renkte.Bu durumda, tüm yetenek kazanımıyla ilgili görevler tamamlanmıştır, çünkü test edip geri bildirimde bulunacak ve ardından lansmanda içerik yayınlayacak influencer'larla tüm sözleşmeler imzalanmıştır. (Slide 11)
Yol Haritası
Çevik bir yol haritası, birden fazla yıl boyunca ilerlemeyi takip etmek için bir proje zaman çizelgesi olarak kullanılabilir. Bu görselleştirmede, üç farklı iş akışı yıllar boyunca izlenebilir ve proje risk seviyesine göre renk kodludur. Proje [related bracelet="risk"] önemlidir çünkü bir projenin sürecini bozabilecek belirsiz olaylar veya koşullar olabilir. Olası sonuçların veya olası aksaklıkların farkında olmak, hem yöneticiyi hem de paydaşı daha iyi hazırlar.
Yüksek riskli projeler veya görevler için, dikkatinizi nereye odaklayacağınızı görebilir veya görev önceliklerini ayarlayarak başka bir önemli görevin tamamen yüksek riskli bir görevin başarısına bağlı olmasını engelleyebilirsiniz. İdeal olarak, yüksek riskli bir görevi takip eden bir görev, yüksek riskli görevin başarısından bağımsız olarak gerçekleştirilebilir.
Canlı yayın alışverişi özelliğimizde, içerik üreticilerinin kaydının gecikmesi, kullanıcı tabanınızı meşgul tutacak veya bu yeni özelliğin nasıl çalıştığını gösterecek yeterli içeriğin olmaması nedeniyle zayıf bir lansmana yol açabilir. Bir diğer yüksek riskli görev ise, içerik üreticilerinin içeriklerini yüklediği üretici panelinin oluşturulmasıdır. Eğer bu arka uç düzgün bir şekilde kurulmazsa, kimse içerik yükleyemez veya canlı yayınları izleyemez ve bu da lansmanınızı tamamen başarısız kılar. (Slide 13)
Alternatif olarak, çevik sürüm planı, proje yöneticilerinin farklı sürümler ve yayınlar arasında zaman çizelgelerini takip etmek için kullanabileceği bir başka yol haritası türüdür. Bu, görevleri ve ilerlemeyi yinelemeler boyunca izleyen daha çok aşama tabanlı bir görselleştirmedir ve projenin çeşitli aşamalarında hangi bilgileri takip etmek veya önemli paydaşlarla paylaşmak istediğinize bağlı olarak faydalı bir varyasyon olabilir.(Slide 15)