Açıldı, Kullanımdan Çıktı: Ekiplerin Kullanmayı Bıraktığı Proje Yönetimi Özellikleri
Zaman Takibi: Birçok ekip, zaman takibi özelliklerini gerçek proje ilerleme ihtiyaçlarıyla yeterince örtüşmediği için terk ediyor.
Özel Sütunlar: Aşırı sayıda özel sütun, iş akışlarını karmaşıklaştırabilir ve genel ekip verimliliğini ve netliğini azaltabilir.
Görev Bağımlılıkları: Görev bağımlılıkları, bakım zorlukları ve gerçek dünyadaki aksaklıklar nedeniyle uygulamada çoğu zaman başarısız olur.
Aşırı Otomasyon: Karmaşık otomasyon ekiplerin kafasını karıştırabilir; bu da güvensizliğe ve amaçlanan iş akışlarından uzaklaşmaya yol açar.
Basitlik Kazanır: Basit ve etkili yöntemlere dönmek, karmaşık özelliklere kıyasla çoğu zaman daha iyi proje yönetimi sonuçları sağlar.
Proje yönetimi araçları, karmaşık işlere düzen getirmek üzere tasarlanmış özelliklerle doludur. Ancak daha fazla özellik her zaman daha iyi sonuçlar anlamına gelmez. Her büyüklükteki ekipte aynı durum tekrar tekrar yaşanır: Gelecek vadeden bir özellik etkinleştirilir, birkaç hafta çalışır ve sessizce terk edilir. Geriye, kullanımı eskisinden daha zor bir sistem ve kendi geçici çözümlerini geliştirmiş bir ekip kalır.
Sahada, kurulum sırasında kullanışlı görünen ancak uygulamada başarısız olan özelliklerle karşılaşan birkaç uzmana ne düşündüklerini sorduk. İşte iyisi, kötüsü ve en kötüsü.
Zaman Takibinin Vaadi (Ve Neden Başarısız Olduğu)
Yerleşik zaman takibi, Jira gibi araçlarda en sık etkinleştirilen ve terk edilen özelliklerden biridir. Thrive Agency'de Talep Yaratma Başkan Yardımcısı olan Aaron Whittaker, çoğu ekibin yaptığı nedenlerle Jira'nın yerleşik iş günlüğünü etkinleştirdi. "Ücretli medya, SEO ve içerik çalışmalarındaki çabanın nasıl dağıtıldığını anlamanın pratik bir yolu gibi göründüğü için etkinleştirdik," diyor. "Amaç, kampanya zaman çizelgeleri için daha net raporlama ve daha iyi planlamaydı."
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Ancak özellik hiçbir zaman benimsenmedi. Whittaker, özelliğin ölçtükleriyle ekiplerin gerçekte bilmeye ihtiyaç duydukları arasındaki temel uyumsuzluğa dikkat çekiyor. "Bu özellik ilerlemeyi değil, saatleri takip ediyor," diye açıklıyor. "Reklam optimizasyonu veya açılış sayfası güncellemeleri için beş ya da altı saat kaydetmek, performansın iyileşip iyileşmediğini veya işin tamamlanmaya yaklaşıp yaklaşmadığını söylemiyor."
Manuel veri girişi gerekliliği işleri daha da kötüleştirdi. Özelliği 170'ten fazla iş kaleminde yaklaşık bir ay çalıştırdıktan sonra, yalnızca yaklaşık 55'inde kullanılabilir kayıt vardı ve bunlar da tutarlı değildi. Whittaker, "Zaman kaydetmek, gün boyunca birden fazla göreve girip çıkmak anlamına geliyordu ve bu da odağımızı sürekli bölüyordu," diyor. "Bir süre sonra, gerçekten yardımcı olan bir şey değil, yapmak zorunda olduğunuz bir iş gibi hissettirmeye başladı."
Zaman kaydetmek, gün boyunca birden fazla göreve girip çıkmak anlamına geliyordu ve bu da odağımızı sürekli bölüyordu. Bir süre sonra, gerçekten yardımcı olan bir şey değil, yapmak zorunda olduğunuz bir iş gibi hissettirmeye başladı.
Ekibi bu özelliği bıraktı ve basit bir pano tabanlı iş akışına geri döndü. "Zaman takibi, kurulum sırasında kullanışlı görünüyordu ancak gerçek iş akışlarında zaten sahip olduğumuz görünürlüğü tekrarladı ve teslimatı iyileştirmeden ek yük getirdi."
Özel İş Akışı Sütunları: Esnekliğin Bir Yüke Dönüşmesi
Özel sütunlar, iyi süreç düşüncesinin doğal bir uzantısı gibi görünür. Outreach.io'nun Kurucusu ve CEO'su Scott Davis, bu özelliğin hızla kontrolden çıkabileceğini zor yoldan öğrendi. "Birkaç yıl önce iş akışımızda şeffaflık sağlamak için Jira scrum panolarında 'özel sütun ekle' özelliğini etkinleştirdik," diyor. "Özelliği bir dakikadan kısa sürede etkinleştirdik. Onu görünmez bir ek yüke dönüştürmemiz ise haftalar sürdü."
Özelliği bir dakikadan kısa sürede etkinleştirdik. Onu görünmez bir ek yüke dönüştürmemiz ise haftalar sürdü
Devam Ediyor ve Tamamlandı arasındaki tek bir "Doğrulanacak" sütunu olarak başlayan şey hızla çoğaldı. Davis, "Farkına varmadan her ekip için bir inceleme sütunu oluşmuştu," diyor; Ürün ekibi paydaş onayı için bir sütun, QA ekibi ise ek kontrol için başka bir sütun ekledi. "Her scrum panosu diğerinden farklı görünüyordu ve panolar arasında gezinmek kolay değildi. İnsanlar bir iş biletini nasıl ilerleteceklerini anlayabilmek için pano yapılandırmalarını kontrol etmek zorunda kalıyordu."
Maliyet verilerde ortaya çıktı. Davis, "Ekibimizin yüksek hacimli sprintler sırasındaki döngü süresi ortalama 8 günden 10,75 güne sürekli yükseldi; bunun temel nedeni, her ek özel durum alanının anlamının belirsiz olmasıydı," diye açıklıyor. "Retrospektif geri bildirim metriklerimiz 'durum adlarını tartışarak boşa harcanan zaman' ifadeleriyle doluydu."
Sütunları özelleştirmeyi düşünen her ekip için tavsiyesi şu: "Eklenen her sütunu teknik borç olarak değerlendirin. İyi bir rol disiplini ve varsayılanlardan sapmak için geçerli bir neden olmadan, varsayılan iş akışını değiştirmek yerine işi ölçeklendirmek daha zor hale gelir. Çoğu ekip birkaç sprint sonrasında bu ek sütunları sessizce kaldıracaktır."
Görev Bağımlılıkları: Teoride Düzenli, Pratikte Bozuk
Görev bağımlılıkları, herhangi bir proje yönetimi aracındaki en cazip özelliklerden biridir. Mantık sağlamdır: Gecikmelerin otomatik olarak ortaya çıkmasını ve doğru tepkileri tetiklemesini sağlamak için görevleri birbirine bağlarsınız. Ancak pratikte bu özellik, gerçek dünyadaki değişkenliğin ağırlığı altında çökmeye eğilimlidir.
Born to Move'un Kurucusu ve CEO'su Dmitrii Malashkin, proje zaman çizelgelerini güncel ve kontrol altında tutmak için Asana'da — ve daha sonra monday.com'da — bağımlılıkları ve gelişmiş görev tamamlama otomasyonlarını uyguladı. "Gerçek şu ki ekibimiz, uygulamadan sonraki ilk haftanın ötesinde bunları hiçbir zaman gerçekten kullanmadı," diyor. Bunun nedeni oldukça açıktı: "Bağımlılıklarınızı ve otomasyonlarınızı sürdürmek, özellikle de zorunlu tutulmadığında, kimsenin yapması gerekmeyen veya aslında yapmak istemediği başlı başına bir iş."
Bağımlılıklarınızı ve otomasyonlarınızı sürdürmek, özellikle de zorunlu tutulmadığında, kimsenin yapması gerekmeyen veya aslında yapmak istemediği başlı başına bir iş.
Gerçek dünyadaki aksaklıklar ortaya çıktığında — eksik bir izin, son dakikada yapılan bir program değişikliği, müşterinin uygunluk durumuyla ilgili bir çakışma — zincir koptu. Malashkin şöyle açıklıyor: "Bu durum, tek bir arıza noktasının tüm bağımlılık zincirini bozmasına neden oluyor. İş akışı, insanlara genel durum güncellemesi taleplerinden oluşan bir yağmur göndermeye başlıyor ve bu da herkesin bunları sessize almasına yol açıyor." Sonuç, genel anlamda bildirim yorgunluğuydu.
Ekibi sonunda bu özellikten tamamen vazgeçti. "Proje yöneticilerimiz ve ekip liderlerimiz, çabaları koordine etmek ve daha fazla iş yapmak için temel çalışma yöntemleri olarak düz, hiyerarşik olmayan görev listelerine ve grup sohbetlerine geri döndü."
The Monterey Company'nin Başkanı Eric Turney de aynı tabloyu gördü. Şöyle diyor: "Gerçek iş akışlarıyla karşılaşınca işlevini yitirdiğini gördüğüm özellik, bir proje yönetimi aracındaki görev bağımlılıklarıdır. Öncelikler çok sık değiştiği, bakımı can sıkıcı olduğu ve sistem, hiç kimsenin güncel tutmak istemeyeceği kadar hızlı bir şekilde eskidiği için hiçbir zaman kalıcı olmadı." Ekibi daha basit sorumluluk dağılımına, net son teslim tarihlerine ve doğrudan iletişime geri döndü. "Özellik kurulum aşamasında akıllı görünüyordu, ancak gerçek hayatta bize yeterli kontrol sağlamadan yönetim yükü ekledi ve bunu haklı çıkaracak kadar fayda sunmadı."
[Görev bağımlılıkları] Öncelikler çok sık değiştiği, bakımı can sıkıcı olduğu ve sistem, hiç kimsenin güncel tutmak istemeyeceği kadar hızlı bir şekilde eskidiği için hiçbir zaman kalıcı olmadı.
Aşırı Otomasyon: Sistem Ekibin Aleyhine Çalıştığında
Otomasyon, modern proje yönetimi platformlarının en büyük satış noktalarından biridir — ve aşırıya kaçılması en kolay özelliklerden biridir. Global Sound Group Genel Müdürü Tom Jauncey, sık karşılaşılan bir tuzağı şöyle anlatıyor: "Kâğıt üzerinde iyi görünen ancak pratikte pek işe yaramayan şeylerden biri, monday.com gibi araçlarda her şeyi fazla otomatik hâle getirmemizdir. Bu, ekibin takip edemeyeceği kadar karmaşık bir hâle gelebilir."
Kâğıt üzerinde iyi görünen ancak pratikte pek işe yaramayan şeylerden biri, monday.com gibi araçlarda her şeyi fazla otomatik hâle getirmemizdir. Bu, ekibin takip edemeyeceği kadar karmaşık bir hâle gelebilir.
Otomasyon katmanları fazla arttığında ekipler ona güvenmeyi bırakır. Jauncey şöyle diyor: "İnsanlar sistemi görmezden gelmeye veya işleri kendi yöntemleriyle yapmaya başlıyor, çünkü sistemin anlaşılmasının çok zor olduğunu ya da onları engellediğini düşünüyorlar." Planlanan iş akışı ile gerçek iş akışı birbirinden uzaklaşır. "İşi planlama şeklimiz, planlama sırasında harika görünüyor. Ancak ekibin günlük çalışma biçimiyle gerçekten örtüşmüyor."
Ekibinin vardığı ders basitti: "İşleri yapmanın en iyi yolu, özelliklere sahip olan yöntem değil, insanların gerçekten kullandığı yöntemdir."
Yüzde Tamamlanma Alanları ve İlerleme Yanılsaması
Bazı özellikler fazla karmaşık oldukları için değil, fazla indirgemeci oldukları için başarısız olur. Kıdemli Proje Yöneticisi Nikita Patil Brennan, yüzde tamamlanma alanlarını bunun başlıca örneklerinden biri olarak gösteriyor. "MS Project/Asana'da görünen bir proje yönetimi özelliği, görevlerdeki tamamlanma yüzdesidir," diyor. "Bu, hikâyenin tamamını anlatmıyor — %71; çoğunlukla tamamlanmış görevleri, risk altındaki görevleri, engellenmiş görevleri vb. yansıtabilir." Tek bir sayı, ekiplerin harekete geçmek için ihtiyaç duyduğu bağlamı düzleştirir. İlerleme, sağlık durumuyla aynı şey değildir ve ikisini birbirinden ayıramayan bir metrik, hiç kimseye yararlı bilgi sunmaz.
[Görevlerdeki % tamamlanma] hikâyenin tamamını anlatmıyor — %71; çoğunlukla tamamlanmış görevleri, risk altındaki görevleri, engellenmiş görevleri vb. yansıtabilir.
More Articles
Fazla Vaatte Bulunan ve Beklentileri Karşılamayan Yapay Zekâ Özellikleri
Yapay zekâ özellikleri proje yönetimi platformlarında kullanıma sunuldukça, tanıtım performansı ile gerçek dünyadaki fayda arasındaki fark sürekli bir hayal kırıklığı kaynağı oldu. Kısmi Proje Yöneticisi ve Operasyon Danışmanı Megan Cotterman bunu bizzat deneyimledi. "Asana yapay zekâ işlevini ilk kullanıma sunduğunda bu deneyimi yaşadım," diyor. "Belirli bağlamlardaki belirli projeler hakkında sorular soruyordum ve aradığım şeyi bulmakta gerçekten çok zorlanıyordum."
[Asana yapay zekâsına] belirli bağlamlardaki belirli projeler hakkında sorular soruyordum ve aradığım şeyi bulmakta gerçekten çok zorlanıyordum.
Sorun Asana'ya özgü değil — bu, genel kullanım senaryoları için oluşturulmuş ancak gerçek proje verilerinin nasıl yapılandırıldığı ve arandığındaki özgüllük ve incelikler konusunda henüz eğitilmemiş yapay zekâ özellikleriyle ilgili daha geniş kapsamlı bir zorluğu yansıtıyor.
Temellere Dönüş — Sadelik Lehine Argüman
Her özellik kategorisinde, yeniden yolunu bulan ekipler bunu sadeleştirerek başardı. James Dyble, birçok uzmanın sonunda vardığı düşünceyi özetliyor. "Eskiden dijital görev yöneticilerini savunurdum; her şeyin bir uygulamada bulunması gerektiğine inanırdım," diyor. "Sonra kendimi tekrar tekrar kalem ve kâğıda uzanırken buldum."
Eskiden dijital görev yöneticilerini savunurdum; her şeyin bir uygulamada bulunması gerektiğine inanırdım. Sonra kendimi tekrar tekrar kalem ve kâğıda uzanırken buldum.
Çözümü dijital araçları tamamen terk etmek değil, onları ne amaçla kullandığı konusunda daha bilinçli olmaktı. "Artık karma bir yaklaşım benimsedim: Büyük projelerimi ve listelerimi dijital bir araçta tutuyorum, ancak günlük önceliklerimi basit bir yapışkan not kâğıdında yönetiyorum. İlerledikçe işleri işaretlemenin fiziksel eyleminde tatmin edici bir şey var."
En etkili proje yönetimi sistemi, en fazla özelliği etkinleştirilmiş olan değildir. Ekibin gerçekten kullanacağı sistemdir.
Bunun gibi daha fazla içgörü mü istiyorsunuz? Bu tür daha fazla uzmanın görüşlerini öğrenmek için ücretsiz bir DPM hesabı oluşturun.
