Bir projede dikkat edilmesi gereken kıyametin uyarı işaretleri nelerdir? [kapalı]

Başarısız bir projede çalışmak, kullanılan dil, endüstri veya deneyim ne olursa olsun, çoğu programcının ortak sahip olduğu birkaç şeyden biridir.

Bu projeler harika öğrenme deneyimleri, ruh kırma felaketleri (veya her ikisi!) Olabilir ve çok sayıda nedenden dolayı oluşabilir:

• kalpte üst yönetim değişikliği
• vasıfsız / az kaynaklı takım
• dev döngüsü sırasında üstün rakiplerin ortaya çıkması
• fazla / yönetim altında

Bu tür birkaç projede çalıştıktan sonra, bir projenin başarısızlığa mahkum olduğu ilk aşamada tanımak mümkün müdür?

Benim için, büyük bir işaret, özellik sürünme ile birlikte sert ve hızlı bir dış son teslim tarihidir . İyi planlanmış ve programa doğru ilerleyen projeleri, geç özellik talepleri karşılanmaya başladığında ve son "teslim edilebilir" ifadesine eklendiğinde korkuluktan kurtulduğunu gördüm. Bu istekleri teklif edenler , odadan nadiren ayrılmaları nedeniyle "sadece bir şey daha" istemeden Columbo'nun takma ismini kazandılar .

Kafanda yaklaşmakta olan kıyametin zillerini çaldığı için dikkat ettiğin uyarı işaretleri nelerdir?

Kahramanca Kodlama

Gecenin geç saatlerinde kodlama yapmak, uzun saatler çalışmak ve çok fazla mesai yapmak, bir şeyin yanlış gittiğinin kesin bir işareti. Dahası, benim deneyimim, eğer projenin herhangi bir noktasında geç saatlere kadar çalışan birini görürseniz, sadece daha da kötüleşir. Bir özelliğini tekrar programa almak için yapıyor olabilir ve başarılı olabilir; ancak, böyle kodlayan kovboy, hemen hemen her zaman, kaçınılmaz olarak yakında daha fazlasına neden olacak bir planlama başarısızlığının sonucudur. Bu yüzden, projenin başlarında onu görüyorsunuz, sonuçta daha da kötüleşecek.

Programcılar "Kod korkunç, sıfırdan başlamalıyız" argümanını kazanmaya başladığında. Herhangi bir olgun uygulamada.

Daha iyi inşa edebileceğinizi veya sorunu daha iyi anlayabileceğinizi düşünebilirsiniz, ancak gerçekten yapamazsınız. Oh, ve bütün o çirkin yamalar? Bunlar, tekrar yazmaya başlayacağınız gerçek dünyadaki sorunların düzeltilmesidir.

Ayrıca, bir gün, proje yöneticisine, 6 aylık çalışma sonunda neden kapasitenin neredeyse% 85'ine ve uygulamanın başladığınızda sahip olduğunuz hataların% 150'sine kadar olduğunuzu açıklamak zorunda kalacaksınız.

Bir problem çözücü olarak yeni bir araç.

İnsanlar alışılmadık araçları kullanmayı planladığında, umrumda değil, ama gözüm üzerinde kalıyor. Bu araçların ilan edilen tüm faydalarını programa dahil etmeye başladıklarında endişeleniyorum. Eğlenceli örnekler:

• Programın bir ayını tıraş edebiliriz, çünkü nesneye yönelik bir dil kullanmayı deneyeceğiz (sahip olduğumuz tüm c geliştiriciler olsa bile).
• Tüm süreç sorunlarımızı çözecek olan bu yeni şeyi deneyeceğiz!
• Projenin yarısı olduğunu biliyorum, ama ya ORM'leri yeni bir şeyle değiştirirsek?

Yeni teknolojiler ve uygulamalar mükemmeldir, ancak neredeyse tüm avantajlardan geçitten faydalanamazsınız.

Bana göre, en büyük ve en kısa sürede fark edebileceğiniz tek sorun, işletmelerin yazılı gereklilikleri zaman kaybı olarak görmesidir.

Yani temelde; Yazılı Gereklilik Yok

Bu ölüm öpücüğü.

Yönetim Bağlantısını Kes

Son teslim tarihlerinden, özelliklerden, kadrodan vb. Sorumlu olanlar, projeyi teslim etmekten sorumlu olan kişilerle bağlantılarını kestiklerinde. Bu yol açabilir:

• Müşteri, özellik maliyetini anlamayan bir kişiyle konuşurken özellik sürünmesi
• Yeni geliştiricilerin bir yardımdan ziyade bir hiyerarşi olmak için yeterince geç bir projeye atıldığı Man-month sendromu
• Son kararların ticari sonuçlarıyla ilgilenmek zorunda kalan, ancak uygulama sonuçlarını değil, insanlar tarafından yaratılan gerçekçi olmayan son tarihler.
• Müşteri odaklı iletişim ortada yönetim tarafından engellendiğinde sorunu çözmeyen ürünler.
• Potansiyel sorunların devs ve yönetim arasında yeterince erken iletişimde bulunmadığı zayıf risk yönetimi.

Bu nedenle, yönetim projeye ilgisiz göründüğü zaman, zayıf iletişim kuruyor, müşterileri dinlemiyor ya da tepelerde koşan dev ekibi dinlemiyor gibi görünüyor.

1. Kilit geliştiriciler ayrıldığında ve yönetim umursamadığında

2. Kilit geliştiriciler ayrıldığında ve diğer geliştiricilerin hiçbiri ilgilenmediğinde

Birincisi, genellikle takım dinamikleri ile yakından temas eden yöneticilerin (“10x süper yıldız”, iyi programcılar ve birbirleriyle nasıl etkileşimde bulundukları vb.) Göstergesidir.

İki numara genellikle, kalan geliştiricilerin bir kısmına ciddi ilgi eksikliği olduğunu gösterir.

İlk kez birisi, genellikle yönetim der ki "vaktimiz yok .."

Genelde dokümantasyon veya kod incelemeleri gibi vakti olmayan bir şeyden önce (tüm test formları dahil olmak üzere başka herhangi bir şeyi daha istatistiksel olarak bulur ve düzeltir)

Müşterinin, pazarlamanın veya yönetimin bir tarih seçmesine izin verin ve sonra hayali bir programa geri çalışmayı deneyin

Yönetim, işletmeye "Hayır" demek için çok zayıf olduğunda.

Asla karşılanamayan son teslim tarihlerine yol açmakta, bu da IT departmanına güven verememesine yol açmakta, bu da geliştiricilerin kesmeler yaratmalarına yol açmaktadır (örn. Birinin makinesinde çalışan db'ye erişim ... bir süre sonra BT için bir kabusa yol açmaktadır). kritik sistemin 'göç etmesi gerekiyor ...

Aklıma gelen ilk işaret, yönetimin zincirden ya da müşteriden uzaklaşacağına dair ümitlerle kötü haberleri iletmeye istekli olmadığı (yani arzulu düşünceyle yönetim) olduğu zamandır. Geliştiricilerin kaç hafta öncesine, hatta aylara kadar dayanamadıklarını ve henüz hiç kimsenin müşteriye söylemek istemediğini kanıtladığını düşünemiyorum. İhtiyacın önceden açıklanmasının gerçek bir nedeni olduğunda, son teslim tarihini zorlamayacak bir müşteriyi nadiren gördüm; Son teslim tarihinin karşılanmayacağını ve ertesi gün karşılanmayacağını ancak iki ay aşağıya indiğini söylerken sık sık kızgın bir müşteri gördüm. Bu noktada, haklı olarak ekleyebilirim, süreçlerinizi sorgulayabilirim - bunu daha önce nasıl bilmiyorsunuz?

Başarısızlığın yaşandığına dair kesin bir işaret, yeni geliştiricileri, mevcut sistemi anlayan insanlardan ziyade, sürecin en karmaşık, en kritik kısmına atamaktır. O zaman, işleri gerçekten doğru bir şekilde tamamlayıp tamamlamadıklarını veya soruları olup olmadıklarını görmek için dikkatlice izlemeyin. Sahip oldukları iddia edilen becerilere gerçekten sahip olduklarını öğrenene kadar yeni çalışanların izlenmesi gerekir. Kritik bir projeye sahip olan ve herkese her şeyin aylarca yolunda olduğunu söyleyen ve son teslim tarihinden bir hafta öncesine kadar çıkmadan kalan herkese herşeyin yolunda olduğunu söyleyen yeni bir çalışanın çalışmasını yineleyen acı verici bir yaz geçirmeyi hala hatırlayabiliyorum ve yaptığı hiçbir şey kullanılabilir değildi.

Bir başka kesin başarısızlık belirtisi, geliştiricilerin önce yapılan diğer şeylere bağlı parçalar üzerinde çalıştığı ve bu şeylerin yapılmadığı ve hatta başlatılmadığıdır. Yönetim, verilen işi doğru sırada alamazsa, tüplerden aşağı inersiniz.

Tabii ki her seferinde son tarihi geri itmeden sürünme özelliği işlerin kötü gideceğine dair en yaygın işaretlerden biri. Tabağıma 20 saatlik bir çalışma eklerseniz, son teslim tarihi 20 saattir. Olmazsa, proje başarısız olur, garantilidir.

Kariyerimde gördüğümden emin olduğum işaretlerden biri, yönetimin programa zaman ayırmak için daha fazla ceset getirmekten bahsetmeye başlamasından kaynaklanıyor. Aslında bir proje yardımında daha fazla ceset görmedim.

Teknik olmayan yöneticiler, hiçbir şekilde nitelikli olmadıkları teknik kararlar almakta ısrar etmeye başladığında. Büyük, büyük kırmızı bayrak!

En belirgin işaret, yüksek bir personel devridir. Herkes yeni bir iş ararken, muhtemelen siz de yapmalısınız.

Bir diğer açık bariz işaret ise ilerleme eksikliği. Bir yıl geçerse ve hedefe daha yakın olmuş gibi görünmüyorsanız, mahkumdur. Bu, özellikle ihtiyaçlar uygulayabileceğinizden daha hızlı değiştiğinde gerçekleşir.

Sıkılmış takım üyeleri.

"% 90 bitirdiniz", teslimat haftaya, ama sorun yok çünkü tek yapmanız gereken "test".

• Herkes fiziksel ve zihinsel olarak yorgun
• Müşteriler / kullanıcılar zaman çizelgeleri veya gördükleri şeylerden açıkça mutsuzlar
• Aslen güzel tasarım şimdi tehlikeye girdi
• Düzeltmek isteyeceğiniz, ancak bunu yapamayacağınız nispeten önemli bazı hatalarla nakliye için istifa ettiniz
• Kalan gururu, gönderdiğiniz şey yerine sevkıyat eyleminde - hayatta kalan bir zihniyete, profesyonel gururdan daha yakın
• Ekip, işe yaramayan ve bu bölümleri görmezden gelen ve en iyisini umdukları için kesin şeyler olduğundan korkuyor, çünkü orada olabileceklerden korkuyorlar.
• Herkes yukarıda ve öteye gittiğine inanıyor (ve haklılar)
• İnsanlar tükenmişlik belirtileri gösteriyor (genel karamsarlık, ilgisizlik, öfke)

(Jim McCarthy'nin Yazılım Geliştirme Dinamiğinden seçildi ).

Kovboy kodlayıcıları, büyük egoları ve bunların yönetim kabulü

Proje planı, tek bir tasarım, geliştirme, test ve dağıtım (klasik şelale) için 1 aydan daha uzun bir proje için çağrı yaparsa, bir mil koşardım.

Tamamen çevik olmanıza gerek yok, ancak kısa gelişim döngülerine sahip olmak, herkese ilerleme göstermenizi (müşteri, yönetim ve geliştiricilerin kendileri) ve kaçınılmaz olduğunda, değişen gereksinimlerle baş etmenizi sağlar.

Poligonda Vahşi Koşu Geliştiricileri

Bu, diğer geliştiricilerin (veya ne yazık ki sizlerin) tasarımdan önemli ölçüde farklı bir bileşen geliştirdiğini ve bunun sistem / UAT testine kadar alınmadığını fark ettiğinizde oldu. Ben böceklerden bahsetmiyorum; Önemli sistem bileşenlerinin özellikleri eksik veya işlevsellik için sorulmamış ve önemli bir yeniden işleme olmadan UAT'ı asla geçmeyeceklerinden bahsediyorum. Bu sorun şunları gösterir:

• Kalite sisteminiz bozuldu; İlgili geliştirici neden tasarım / uygulama aşamasında konuyla ilgilenmedi. Kod başına incelenip denetlenmedi mi? Ünite ve entegrasyon testleri neden bu konuda başarısız oldu? Bir tür tutarlı birim / entegrasyon testi yaptırmazsanız, mahvolursunuz.
• Proje yöneticiniz / teknik lideriniz geliştirme ekibinin kontrolünde değil. Geliştiricilerin gerekenleri sağlamasını sağlayamazlarsa, asla tam bir çözüm sunamayacaklardır.

Bir projedeki önemli bir geliştirici haftalarca herhangi bir kodu kontrol etmediğinde ve ciddi bir dönüm noktası ortaya çıktığında.

Taahhütlü bir işti ve işte daha kıdemli geliştirici ve PM, daha büyük bir kesim elde etmek için ekip kurmak istediklerine karar verdi, böylece diğer geliştirici 3 haftalık kritik kod rehinesi aldı. Sonunda, beceriksiz Başbakan (projeyi yıkım için bir kursa yerleştirmek için 6 aydır harcadığı) ateş ettik ve geliştiriciyle konuştuk.

Projenin geri kalanının mazoşist bir ölüm yürüyüşü olduğunu, spesifik donmanın ertelendiğini, müşteriye Başbakan'ın projeyi terk etmesini planladığı korkunç programlamayı telafi etmek için bir dizi imtiyaz özelliği verildi ve projenin kalitesini çektiğini söylemek yeterli oldu. her yerinde bunun yüzünden.

Başbakan, CDR (Kritik Tasarım İnceleme) için sadece müşteriyle olan toplantıyı kesmek ve telaşlı bir uyum atmak için inmeye cesaret bile duyuyordu. Proje kapsamında seyahat masraflarının ödenmesini talep ettiğinde kendisine kibarca vazgeçmesi söylendi.

Bu projeyi etkileyen, burada bulunan diğer cevaplardan en az 5 tanesi ile kolayca tespit edebiliyorum. Kısacası, ilk ciddi kodlama projemde çok zor dersler aldım.

İlk işaretim, önümüzdeki on hafta boyunca kaç saatlik fazla mesaiye katılacağımızı sordukları ve maaşlı çalışanlara, projenin başarısına ve son teslim tarihlerine göre belirtilen fazla mesai için bir bonus teklif ettikleriydi.

Gördüğüm diğer önemli işaretler: Gereksinimler tanımı programın üzerinden geçiyor ve bitiş tarihi taşınmıyor. Başlamadan önce geride kaldık. Zamanını tasarımdan uzaklaştırdılar, bu yüzden veritabanı tasarımı ve site tasarımı olmadan başladık, ancak diğer şeylerin yanı sıra henüz tasarlanmamış ve yaratılmayan tablolara ithalat yaparak zamanında teslimat yapması bekleniyor.

Kritik yoldaki öğeler sırayla yerine eşzamanlı yapılırken. (Eğer X aracını kullanmam gerekiyorsa ve programlayıcı A henüz yeni başlıyorsa, görevimi geciktirecek.)

Yöneticiler Şükran Günü'nde kod işlerken.

Saat 11: 00'den sonra ve saat 6'dan daha erken bir tarih damgası olan e-postalar almaya başladığınızda.

Bazı karmaşıklıklarla nasıl başa çıkılacağıyla ilgili her soru aynı cevap ile karşılandığında, "Henüz bunun için endişelenme".

Halen ihtiyaç duyduklarında değişiklik yaptıkları gün, sen QA'ya git ya da yaşa.

Günlük toplantılara başladığınızda, ilerlemenizin eksikliğini tartışmak birkaç saat sürecek. Bu, çünkü bütün gün toplantıdayım. Günlük 5 dakikalık toplantı para cezası, günlük toplantı bir saatten fazla gider, sorun değil.

Veri tabanı ekibi ve uygulama ekibi birbirleriyle konuşmadığında.

Müşteri söz verilen bilgileri zamanında sağlayamadığında. Özellikle bunlar veri alma dosyaları olduğunda ve kodun nasıl çalıştığını kontrol etmek için veritabanındaki bu verilere ihtiyacınız olduğunda.

Bazı yöneticilerin ofislerinin dışına bir stop lambası yerleştirmeyi düşündüğünüzde, ona o gün yaklaşmanın güvenli olup olmadığını bildirmek için.

Son başvuru tarihi yaklaşırken başarısız bir projeyi tespit etmenin genellikle kolay olduğunu düşünüyorum. Söylediğiniz gibi, bir set taşa son teslim tarihi ile birlikte sürünme özelliği bir projeyi öldürmenin kesin bir yoludur.

Ancak kilit nokta başarısız bir projeyi önceden tespit etmektir. Bu durumda tek gerçek 'kıyamet işareti' nin 'ne zaman bittiğimiz' tanımının tam bir eksikliği olacağını düşünüyorum. Ofsette bunu bilmediğimiz sürece IMO başarısızlığına mahkum oluruz.

Son beş yılda üç ölüm yürüyüşüne katıldım. İşte benim bağırsak dolandırıcılık hissi katkıda bulunan birkaç şey.

• Şirket, küçük geliştiricilerin yeni özellikler tasarlamasına ve geliştirmesine karar verdi ve hatalarını gidermek için daha pahalı üst düzey geliştiriciler atar.
• Şirket, gerekli alan uzmanlığına sahip olmayan üçüncü dünya şirketlerine kritik yazılım bileşenlerini dış kaynaklardan tedarik etmektedir.
• Çatışma zamanı döngüleri o kadar yakınlaşıyor ki, halkların sağlığı bozuluyor.
• Ekibinizin yol açtığı haplar, her gece uyumak için ilaç kullanmaya başladı.
• Müşteri değişiklik siparişlerini analiz edebileceğinizden daha hızlı gönderir.
• Birkaç yıl içinde birkaç hafta içinde bir iş bulmanız gerekiyor, ancak yönetim bir özellik dondurması yapmayı reddediyor.
• Donanım tedarikçileriniz programa göre uygulanabilir bir ürün teslim etmekte zorlanıyorlar ve şirketinizdeki karar vericiler herhangi bir alternatif düşünmeyecekler.
• Prototip cihaz geliştiricilerin ihtiyaç duydukları için, muhtemelen gerçekçi olmayan programlarla tanışma şansına sahip olmaları hayatidir ve kendilerini iyi hissettirmeleri için üst düzey yöneticilere verilir.
• Birinci hafta: "Ah, kahretsin, kod buggy. Herkes yeni özellikler yapmaktan vazgeçip hataları düzeltiyor." İkinci hafta: "Ah, kahretsin, özellik programına uymayacağız. Herkes hataları düzeltmeyi bırakıp yeni özellikler yazdı." Süresiz olarak tekrarlayın.
• Gelişim bir ülkede yapılır ve KG, dünyanın dört bir yanındaki yarı yolda başka bir ülkede yapılır, bu nedenle bir hata ile ilgili bir gidiş-dönüş iletişimi her zaman 24 saat gerektirir ve ilgili kişilerin en az biri karmaşık teknik sorunları tartışıyor. Bir dilde onlar yetkin değildir.

Benim için, özellik setinden (aka yöneticiler, ürün sahipleri, müşteriler ...) sorumlu olanların önemsemeyi bırakması veya cevapları hakkında umutsuz bir havası varmış gibi görünmesidir. Özellikler hakkındaki sorular ilgisizlik ve cesaretsizlikle buluşuyor. Projeye yatırım veya güven kaybettikleri açıktır.

Bu benim için, benim yürüdüğüm bir projenin “yüreğin üst yönetimi değişikliği” nde vurduğu zaman oldu. Nasıl çalışması gerektiğiyle ilgili sorular soruyordum ve aniden kimsenin gerçek bir görüşü olmadığını söyledi.

Bir süre sonra proje iptal edildi ve yazdığım tüm güzel kodlar hurdaya çıkarıldı.

Paul Vick, birkaç yıl önce kara delik projeleri hakkında mükemmel bir yazı yazdı . Tüm tavsiyelerin alakalı olduğunu düşünüyorum. (Uzunluğa göre öğeleri ve özetleri düzenledim.)

• Saçma görkemli görkemli hedefler . "İnsanların bilgisayarlarla çalışma şeklini temelden yeniden düşünün" gibi.
• Tamamen gerçekçi olmayan tarihler . Genellikle bu, orijinal kod tabanını başlangıçta olduğundan çok daha kısa sürede yeniden yazabileceklerine inanmalarıdır.
• Uyumluluk konusunda gerçekçi olmayan inançlar . İnanmak gibi, fazladan çaba sarf etmeden tüm küçük tuhaflıkları tekrar yazabilir ve koruyabilirsiniz.
• Her zaman büyük bir son teslim tarihinden "altı ay" sonra gelmemiş gibi görünüyor . Ya da gelirse, telafi etmek için projenin sonuna başka bir dönüm noktası eklenir.
• Çok miktarda kaynak tüketmek zorundadır . Genellikle can damarı bir veya daha fazla yerleşik üründen emilerek.
• Henüz kanıtlanmayan yepyeni teknolojiyi kullanmayı dahil edin . Bu nedenle, tüm ölçeklenebilirlik problemlerini yeni teknolojiyle giderirler.

Zihinsel olarak "Her şey yolunda. Endişelenecek bir şeyimiz yok" u çeviriyorum. "Hepimiz mahvolduk" a her seferinde yönetimin söylediğini duydum. Genelde yöneticilerin ilgisiz toplantılarda tesadüfen attığını duyarsınız ("Bu arada, her şey yolunda gidiyor. Endişelenmek için bir neden yok!"), Ancak bunu söylemek için özel olarak çağrılan bir toplantı yapmak daha da büyük bir kırmızı bayrak.

Bir yöneticinin bu satırlar boyunca bir şeyler söylediğini ve yalan olduğu ortaya çıkmadı .

Ölü bir projeden aldığım birkaç nokta:

• Yönetim ekibi daha hızlı bitirmesi için ikiye katlar.
• geliştiriciler, son başvuru tarihlerini karşılamak için böcekleri "gömmeye" başlıyor ve açık olmasına rağmen, kod incelemesi sırasında göz ardı ediliyor.

Yönetim aynı anda projeyi farklı yönlere çektiğinde ve taşıma hala devam ediyor.

Bir zamanlar iki adam tarafından yönetilen bir projeye katıldım. Ya birbirleriyle konuşmadılar ya da her birinin çözmesi gereken bir ego var, ancak çalışmamızı her hafta ya da öylesine ters yönde yönetiyorlardı. Asla sonuç olmayacağının farkına varmak uzun sürmedi. Memnuniyetle katılımım sadece birkaç ay sürdü.

Bu kısa makaleye bakın: BT Projeleri Doğru Yapıldığında .

Makalede belirtilen elementlerin hiçbirinin olmaması alarm zillerini çalmalı:

Bu nedenle, projenizin aşağıdakilerin hepsine sahip olduğundan emin olun, eğer değilse, endişelenmelisiniz:

(yukarıdaki makaleyi alıntılamak için :)

1. "Birincisi, neyin başarılacağına dair net bir vizyona dayanıyor olmalarıdır."

2. “İkinci karakteristik, özellikle üst yönetim olmak üzere, işletme genelinde yer alan farklı tarafların desteği ve taahhüdü ile ilgilidir.”

3. "Üçüncüsü, ele alınması gereken sorunların anlaşılması."

4. “Nihai ortak karakteristik, yeterli kaynak ve becerinin erişilebilir hale getirilmiş olmasıdır.”

İstatistiksel olarak, bir yazılım projesinin başlaması, ezici bir çoğunluğunun yaptığı gibi başarısız olacağının adil bir işaretidir ...