Başarısız olan programlama projeleri ile nasıl başa çıkılır?

12

Projelerin başarısız olması nadir değildir.

Bir programcı olarak başarısız olan projelerle nasıl başa çıkıyorsunuz?

Başarısızlığın bazı tanımları:

Son teslim tarihi.
Kod ve işlevsellik olması gerekeni yapmaz.
Yazılım, temelde teslim edilemeyen, buhar veya çok sayıda aşama haline gelir.

Ya da belki kendi başarısızlık tanımınız var.

Parmakları işaret etmeye başlıyor musunuz? Kendinizi, gereksinimleri, teknolojiyi, yönetimi, müşteriyi vb. Suçluyor musunuz? Takım olarak dersler öğrenildi mi?

team project failure

— spong
kaynak

11

Bebek gibi ağlama eğilimindeyim. Yine de herkes için işe yaramaz.

— ChaosPandion

Bu bağlamda başarısızlık, yine de satış beklentilerini karşılamayan iyi bir program (olması gerekeni yapıyor, hata yok) olarak tanımlanıyor mu?

— tcrosley

8

Başarısız veya başarılı olan tüm projeler için öğrenilen dersleri yapmalısınız. İyi bir projeden öğrenilecek çok şey var.

Gerçek başarısız projeler benim için çok nadirdi. Ne olduğunu anlamaya ek olarak, altta yatan nedenlere ulaşmak için "neden 5 kez sor" şeyini yapıyorum. Neler olduğunu neden fark etmedim ve bu konuda bir şeyler yaptım ya da en azından dışarı çıktım.

Herkesin ilk pozisyonu her şeyi suçlamaktır - müşteri, teknoloji, ele alınan iş problemi, metodoloji, ekip üyeleri, dil, platform, sabah kahvenizi alma şeklimiz bile. Retrospektifle ilgili güzel bir şey (sadece kendi kafanızda olsa bile), bu faktörlerin bir kısmı veya tümü ile uzlaşma ve sorun olmadığını fark etme şansıdır.

Son 30+ yılın tek asıl başarısızlığımla, proje geldiğimizde tam anlamıyla yıllar boyunca ihtiyaçlardaydı. Gereksinimlerimiz çözüldü. Biri yönetimden, yüzlerce son kullanıcıdan geldi. Kod yazdık, bir sürü kod yazdık, bazıları parlak. Test ve kabul testleri ve değişiklikler ve argümanlar ve değişiklik talepleri ve ücretsiz iş ve ücretli iş ve son dakika cıvataları ve gerçeküstü mizah ve VP'lere ve bunların hepsine tırmanışlar vardı. Sonunda her şey durmak için tökezledi. Başarısızlığın nedeni, tek yönetim gereksiniminin son kullanıcılar için kabul edilemez olmasıydı. Ve ne kadar yol alırlarsa alsınlar bunu geçemezler ve sistemi asla kabul etmezlerdi. Ancak yönetim başka türlü olmazdı. Bu böyleydi ve çok paramız olmasına rağmen, sonunda,

Hala bu teknolojide çalışıyorum, hala bu süreçleri kullanıyorum ve hala aynı insanlarla çalışıyorum. O müşteri için başka bir proje bile yapardım. Ancak son kullanıcılar, kendi yönetiminin gereksinimlere enjekte ettiği bir şeyi sevmediklerini söylediklerinde, işe yarayan iyi kod yazmanın sizi başarısız bir projeden korumadığını hatırlayacağım. Ve bu konuda bir şey yapacağım, bir iki yıl sonra değil.

— Kate Gregory
kaynak

3

Bu cevabı tekrar okurken gülümsüyorum. Sonuna doğru her şey üzgün olmaktan daha komik oldu - ve bir yıl boyunca bunun için hiçbir şey talep etmeden bunun üzerinde çalıştım. En sevdiklerimden biri, bir kullanıcıya imzalamak için bir değişiklik isteği teslim etti ve "Bunu imzalamıyorum - beni tutacaksın!" Dedi. sadece "iyi, o zaman ben kodlamıyorum."

— Kate Gregory

3

Önemli şeyler yapmaktan kaçınırken, birkaç gün ila bir hafta boyunca kaltak, sonra neyin yanlış gittiğini ve tekrar olmasına izin vermemeyi anlamaya çalışın.

— David Thornley
kaynak

3

Konu hakkında Death March adlı harika bir kitap var: http://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

Okumanızı şiddetle tavsiye ederim. Projelerinizi birçok açıklamada tanıyabilirsiniz.

Politika da dahil olmak üzere kuruluşunuzun birçok karmaşık bileşenine bağlı olduğu için tek bir cevap yoktur ...

1

Benden başka herkesi suçladım .... haha, sadece şaka yapıyordum. Yaptığım şey "Mea Culpa" dokümanı yazmak, "yaptığım" yanlış şeyler. belki bu projeye yardımcı olmaz, ancak aynı hataları tekrarlamamanın iyi bir yoludur

— Nisanio
kaynak