Garantili Arıza İçin 7 Faktör

Çalışanları takdir etmeyin, karmaşıklığı hafife almayın veya efsanelere güvenmeyin. Bu ve diğer faktörler dikkate alınırsa, projenizin başarısız olması garanti edilir.

Bunu biliyor musun? Proje yöneticisi haftalarca ve aylarca projesi hakkında rapor verir. Elbette klasik durum lambaları da eksik olmamalı. Ve bu sürekli yeşil renkte: her şey yolunda. Ancak bir gün trafik ışığı aniden kırmızıya döner! Sonuç olarak, sorumlular için çok tatsız bir işlem süreci başlar. Çoğu zaman ilk soru suçluya, ikincisi nedenlere ve sonra biri yalnızca olası çözümlere ayrılmıştır.

Aşağıda, başarısızlığı neredeyse garanti eden 7 tipik faktör bulunmaktadır.

Faktör 1: insan faktörünü göz ardı edin

Uzun yıllar boyunca bir geliştirici, proje yöneticisi, koç ve kriz yöneticisi olarak, kişiler arası gerilimlerin BT projelerini uygulamanın önündeki en büyük engel olduğunu gördüm. Tersine, çalışanlar arasındaki kimya doğrudur ve açık, hataya toleranslı bir iklim vardır, kritik durumlarda bile tüm zorluklara çözüm bulunabilir.

Çatışmadan kaçınmak insanın doğasında vardır. Bu nedenle, insanların (örn. proje yöneticisi) tamamen görmezden gelmesi veya çok uzun süre başka tarafa bakması doğaldır. Ancak çatışmalar genellikle kendiliğinden çözülmez. Araştırma, ılımlılık ve en azından değişim veya çözüm perspektifi olarak gereklidir.

Bazen bir çalışan için yeni bir iş gibi büyük etkisi olan küçük şeylerdir. Ancak, projeye yeniden barış getirmek için ekiplerin yeniden düzenlenmesi gibi daha büyük harcamalar genellikle gereklidir. Ancak en kötü alternatif insan faktörünü hiçe saymaktır.

Faktör 2: Çok büyük düşünün veya çok küçük yapın

Bazı şirketler bir projeyi devralır. Karmaşıklığı, riskleri ve muazzam personel ve maddi çabayı hafife alıyorlar. Maliyetleri ne olursa olsun, kuruluşum 100 çalışanı olan bir projeyi yönetebilir mi? Yeterli işimiz, toplantı odalarımız, ağ kapasitemiz, geliştirme sunucumuz vb. var mı?

Şirket, Sürekli Entegrasyon/Teslimat dahil olmak üzere bir geliştirme ve test yolu için büyük bir çevik geliştirme ekibinin gereksinimlerini karşılayabiliyor mu? Tahmin edilen bu tür sorular, iş gerekçesinin gerçekçi bir şekilde hesaplanmış olması gerekirdi. Devasa bir projenin başlamasından kısa bir süre önce ortaya çıkan sisteme şirketin iş modeline uymadığı için aslında ihtiyaç duyulmadığının netleştiğini birkaç kez gördüm. Ne yazık ki, daha önce kimse bunu fark etmemişti.

Başka bir tanınabilir model: Bir kahraman, örneğin prestij nedenleriyle veya çalışanları kullanmak için kesinlikle bir SW gerçekleştirmek istiyor ve maliyetleri ihmal edilebilir olarak hesaplıyor. Daha sonraki proje yöneticisi, karar alma organları bağlamında tutarsızlığı ortaya koyacak kadar güçlü değilse, bu yüksek kriz potansiyeli yaratır.

Faktör 3: tahminlere ve planlamaya %100 güvenin

Yaygın bir efsane, tahminlerin ve planlamanın güvenilirliğidir. Projenin konsepti benzersizliği ile tanımlanır. Belki de zaten benzer projeler vardı, ancak prensipte bir şirket her projeyle yeni bir bölgeye giriyor. Bu, tahminlerin ancak yaratıcıların mevcut projeyle ilgili deneyimleri ve uyarlama becerileri kadar iyi olabileceği anlamına gelir.

Ancak planlar hiçbir zaman spontane olayları, gereksinimler, teknolojilerdeki değişiklikleri veya beklenmeyen risklerin girişini içeremez. Nihayetinde, tahminler ve bunlara dayalı planlar, geleceğe yönelik bir bahisten başka bir şey değildir! Bu gerçeği kabul etmek ileriye doğru atılan ilk adımdır. Disiplin, cesaret ve sistem, olası krizleri önlemeye veya hafifletmeye yardımcı olur.

Faktör 4: Sihirli PM üçgeni sürekli olarak göz ardı edildi

Bilgisayar bilimi okudu, birinci dönem, birinci ders proje yönetimi: “Sihirli PM üçgeni” . Yönetim görevleriyle ilgilenen kişi, bu üçgenin yasalarıyla çok erken tanıştırılır. Bunlar, üç parametreden birindeki değişikliğin kaçınılmaz olarak diğer parametrelerden en az birinin sonuçlarına yol açtığını söylüyor.

Bununla birlikte, bu yasalar pratikte görmezden gelinemeyecek kadar mutludur. Tahmin ve planlama bağlamında daha önce bahsedildiği gibi, bir proje biraz benzersizdir ve planlanmamış etkilerin olasılığı son derece yüksektir. Bu nedenle sorumluların er ya da geç hemen her proje için bu etkilere tepki göstermesi gerekir. Ancak, tüm parametreler sabitse, yani müşteri zamana, bütçeye ve içeriğe uygunluk talep etmeye devam ederse, başarısızlık an meselesidir.

Faktör 5: Her şeyin belgelenmesi

Franz Beckenbauer'den sonra ücretsiz: "Biz buna bir klasik diyoruz!" Her geçen gün daha fazla şirket çevik prosedürlere (çoğunlukla scrum) güveniyor olsa da, kapsamlı dokümantasyona oluşturulacak yazılımdan daha fazla önem veren organizasyonlar ve projeler hala bulunuyor. Bu, özellikle büyük projelerde yüksek bir risktir. Çoğu zaman, binlerce sayfalık danışmanlar ve departman uzmanları genellikle aylarca hatta yıllarca çalışmış ve bu daha sonra SW'deki başka bir ekip tarafından tercüme edilecektir.

Dokümantasyon ne kadar kapsamlı olursa, gerçekleştirme süresi o kadar uzun olur ve yazılımın kullanıcıların gerçek gereksinimlerine karşılık gelme olasılığı o kadar düşük olur. Piyasadaki değişikliklere tepkiler mümkün değildir veya ancak büyük çaba ve zamansal tavizlerle mümkündür. Bir belge, ürünün kaldırılabileceği bir temel sunar. Ne yazık ki, yazılanlar her zaman net değildir ve sonuç, başlangıçta düşünülenden farklı bir şekilde düşünülür. Bölüm çalışanlarından ve son kullanıcılardan şu cümleyi kaç kez duydum: "Ah, ben onu çok farklı hayal etmiştim!" .

Faktör 6: Sadece dengeli bir proje organizasyonu yok

20 geliştiriciden oluşan bir ekip ve 1 teknik kişi mi? Bu yapının er ya da geç başarısız olacağını kabul etmek için uzman bilgisine gerek yoktur. Bir projenin başlangıcında, ister şelale ister çevik olsun, geliştiriciler çerçevelerle veya ortamları kurmakla meşgul oldukları için yine de çalışabilir. Ancak çok yakında çalışanlar sorular soracak – yoğun profesyonel desteğe ihtiyaç duyacaklar.

Tek konu uzmanı bu zamansal ve duygusal baskıya asla dayanamaz ve hem personel hem de uygulama sürecinde desteğe ihtiyaç duyar. Ancak personel darboğazını iletişim kısıtlaması ile karşılamak çok kötü bir fikirdir.

Ayrıca popüler bir fikir ve tipik yönetim hataları ölçeğinde çok önde: bir çalışan, geliştiricilerin sorularını toplar, bunları teknik irtibat kişisiyle tartışır ve yanıtları verir. Bu şekilde, mükemmel bir darboğaz yaratır, son derece yüksek bir hata oranını tetikler ve geliştirmeyi önemli ölçüde geciktirirsiniz.

Faktör 7: Kurbağayı yavaşça ısıtın

Bu hikayeyi biliyor musun? Bir kurbağayı su dolu bir tencereye koyar ve pişene kadar sürekli ısıtırsanız, kurbağa kaçmaya çalışmaz. Doğrudan sıcak suya atarsanız hemen dışarı fırlar.

Son yıllarda hakkımda edindiğim en önemli bilgilerden biri bilişim projelerinin çalışanlarının gün geçtikçe artan körlükle hayatlarını kaybetmeleridir. Bir kez kurulan süreçler belki geriye dönük olarak sorgulanır, ancak nadiren gerçekten sert olurlar. İnsanların değişikliklere tepki verme yeteneği, bir projenin süresiyle orantılı olarak ortadan kalkar.

Bu nedenle, kaçakları ve potansiyel olarak hedeflenmemiş yolları keşfetmek için (devasa) projeler tarafından daha önce dahil olmayan harici bir danışman tarafından sporadik aydınlatma (Sağlık Kontrolleri) önerilir. En geç, tam anlamıyla bir krizin farkına vardıktan sonra, yalnızca mevcut personelle geri dönüşü yaratmak neredeyse imkansızdır.

Yani mümkün olabilir

Açıklanan tipik yönetim hataları, yazılım geliştirme projelerinin başarılı bir şekilde tamamlanmasını engelleyen ve hatta önleyen kişisel isabet listemdeki davranış kalıplarının yalnızca küçük bir kısmıdır. Uzaktan bakıldığında, projelerin erken aşamalarında sorunları fark etmenin ve düzeltmenin kolay olduğu izlenimi doğabilir. Ancak sözde sabit olmayan çerçeve koşulları ve bahsedilen körlük çoğu zaman doğru kararların verilmesini zorlaştırıyor. Standish Group'un başlangıçta söylediği istatistikler her yıl bunu gösteriyor.

Bir projenin başı beladaysa, harici bir kriz yöneticisinin hassasiyetlerden ve proje geçmişi yükü olmadan analiz edip nesnel bir şekilde hareket etmesi şiddetle tavsiye edilir. İnsanları dinleyen bir uzmanın projeye tek katılımı zaten olumlu etkilere neden olabilir. Uygun önlemlerin seçimi de dönüşümde ve nihayetinde geri dönüşte başarılı olur.