5 üyeli bir ekipte geliştiriciyim ve projemizin felakete yöneldiğine inanıyorum. Neden birazdan bahsedeceğim ama sorum şu: nasıl davranmalıyım?

Son teslim tarihi 1.5 aydır ve ne yaptığımızın önemi yok, bu proje başarısız olacak. Ben sadece projeyi sonlandırmamız ve zamanımızı boşa harcamamamız gerektiği fikrine katılıyorum, ancak politik olarak yöneticimizin bunu yapmasının imkansız olduğunu düşünüyorum.

Bu durumda ne yapmalıyım? Fazladan çaba sarf etmeli miyim yoksa sadece rahat mı etmeliyim? Peki yöneticiye ne demeliyim?

Bu projenin başarısızlığa uğramasının sebepleri:

• Son tarih yaklaşırken sahip olması gereken özelliklerin çoğu bitmedi
• Uygulama kararsız ve kullanımı çok zor
• Sistem çok karmaşık, kodun anlaşılması çok zor, değiştirilmesi çok zor - Veri modeli karmaşık bir ilişkisel veritabanı tarafından da yönetiliyor (100+ tablo)
• Belirsiz liderlik; Yönetici yeni bilgilere büyük değişikliklerle cevap veriyor
• Neredeyse otomatik testler veya birim testi yok
• Büyük ölçüde diğer sistemlere bağlı, ancak henüz bir entegrasyon testi yok

Aslında, biz aslında bu projeyi (karışıklıkla birlikte) 1-2 ay önce, birkaç ay boyunca üzerinde çalışan aynı menajerin altındaki başka bir dev ekipten miras aldık.

Endişelerinizi, yönetim merdivenine kadar mümkün olan en özlü ve yüzleşmeyen şekilde iletin. Riskleri özetleyin, ancak sonuçlarınızı onlara dayatmayın.

Yönetim her zaman ne yapacağını seçmelidir, ancak durumu değerlendirmek ve iletmek sizin işinizdir. İşler güneye gittiğinde kağıt izi bırakmak için e-posta kullanın.

Bunu yaptıktan sonra, projede iyi niyetle çalışmaya devam edin.

Unutmayın, proje, destekçileri ve arkasındaki finansal kararlar hakkında bilmeniz gereken her şeyi bilemeyebilirsiniz. Size aptal görünen yönetim kararları aslında sizin için görünmeyen akıllı muhakemeye dayanıyor olabilir.

Kağıt izi bırakın (ör. Günlük, kaydedilmiş e-postalar, vb.). Sadece gerçekleri ve nesnel gözlemleri dahil edin. Tüm sonuçları, yazanlar okuduğunda (eğer biri varsa) okuyunuz.

Bir geliştirici olarak, projenin önündeki bir engel olarak görülmediyseniz, hiçbir şüphe olmayacak şekilde parmakla işaretleme ile iyi bir sonuç çıkacaksınız. Yöneticiniz çok şanslı olmayabilir, ama bu burada önemli değil.

Sadece genel ilkelere göre özgeçmişinizi güncelleyin ve şirketinizin dışındaki diğer kişilerle zaman zaman tanıştığınızdan emin olun. Herhangi bir yerel geliştirici grubunun parçası değilseniz, 2 veya 3 grubuna katılın. Arkadaş ve tanıdıklardan oluşan bir ağ oluşturmak yıllar alır ancak uzun vadede buna değer. 2-yollu bir cadde olarak baktığınızdan emin olun - şirketinizdeki bir boşluğu yetenekli biriyle doldurmanıza yardımcı olabilirseniz, bu da iş bulmanıza yardımcı olan biri kadar iyidir.

2 kitap okumak için biraz zaman ayırmanızı önereceğim.

Death March , yazılım geliştirmede yaygın olan patolojik bir proje yönetimi stilini tanımlayan kanonik kitaptır. Sıkıştırma, özellik kayması veya yanlış yönetim nedeniyle, birçok proje kötü durumda sonuçlanır; yalnız olmadığınızı ve projenizin sadece ölüm yürüyüşü olmadığını anlamanıza yardımcı olur. Yazar Edward Yourdon, çıkmaz projeleri, her biri farklı başa çıkma stratejileri olan 4 kadran halinde sınıflandırıyor. Bazen tek başa çıkma stratejisi uzaklaşmaktır. Bence bu kitap, seçenek yelpazenizin ne olduğunu çözmenize ve yapabileceklerinizi ve yapamadıklarınızı daraltmanıza yardımcı olacak.

Felaket Çözümü proje yöneticileri için daha fazla yazılmıştır. Kırık bir projenin nasıl başlatılacağını bulmayı amaçlamaktadır: Nelerin kesilmesi, nelerin kesilmesi ve bunun müşterilere nasıl atılması gerektiği? "Konvansiyonel" yazılım projesi yönetimi bizi dağınık projelere sokar ve ilk başta onları içine alan aynı düşünceyi kullanarak sorunlarımızdan kaçamayız. Bu kitap Ölüm Marşı'ndan okumaktan biraz daha zor, fakat kitaplığınız için iyi bir kitap.

3 kariyer ve akıl sağlığını korumak için basit ve alaycı stratejiler.

1. Tren kazasından inin - bir tren kazasını görün: Projelerin başarısız olması moral için korkunçtur ve eğer ninjaya sahip olmadıkça yönetim becerileriniz kariyeriniz üzerinde bazı olumsuz etkilere neden olur. Yumuşak bir iniş görebiliyorsanız, şimdi atlayın.

2. Bu işe yaramazsa, başınızı eğmeyin: İnsanlar suçlayacak insanları aramaya başlayacak - onlar için kolaylaşmayın! Artan kaygıları artırırken, yönetim zinciri bunu yapmak için doğru bir şey olabilir, ancak hem etkisiz hem de risklidir. Kendi yöneticiniz endişelerinizi dile getirme ve onu atlamanız pek mümkün değildir, sadece ikinizi de kötü görünmekle kalmaz, aynı zamanda sizi bir 'baş belası' olarak nitelendirebilir; Elbette bu, aynı zamanda profesyonel olmak, saatlerinizi koymak, ancak kahramanlık yapmak anlamına gelmiyor.

3. T + 1'de acil durum çıkışını planlayın: Kendinize bazı seçenekler verin ve şimdi potansiyel bir iç veya dış transfer için gerekli çalışmaları yapın. İnsanlarla konuş; Proje finansmanı kesintiye uğradığında başkalarının sizinle ne yapacağına karar vermesini beklemenin ya da birkaç ay içinde göç eden insanların kaçınılmaz 'damgasına' gömülmek için hiçbir sebep yoktur.

Aşırı derecede sinik geliyorsa özür dilerim ama doğru çağırdıysanız, tatsızlığa uğramanızın bir tersi yok. Profesyonel olun, iyimser olun ama her zaman gerçekçi olun.

Yakında gerçekleşecek olan bu başarısız projenin şirketteki ve ötesindeki kariyeriniz üzerindeki etkisi ne olacak? Tecrübelerime göre, sadece başarılı projelerle ilişkilendirilmek kendi kişisel mükemmelliğinizin bir göstergesi değildir.

Sıkıntı karşısında sergilediğiniz nitelikler ve bazen kesin başarısızlık gibi görünen şeyler, genellikle düşündüğünüzden çok, üstler tarafından fark edilir. Ve ben senin acil müdürünün ötesinde hakkında konuşuyorum.

Şahsen, müdürümün yetersiz kalmasından kovulduğunu görme deneyimim oldu ve kendimi aynı gün pozisyonuna terfi ettirdim. Hoş değil, ama insanların beni izlediğini ve yaptığım şeyi sevdiğini gösterdi.

Çoğu zaman, başarısız bir projeyle gelen aynı karmaşa ve düzensizlik, size parlama fırsatı verir.

Öyleyse projeye şu şekilde bakın: Bu başarısız proje, ışığımın tüm güçlü yönlerime ve en iyi niteliklerime yansıması için ne gibi bir fırsat sunuyor? Beni daha iyi bir profesyonel ve daha iyi bir insan yapabilecek bu deneyimden hangi dersleri alıyorum?

Temel olarak, başarısızlıklardan elde edilen deneyimlerin toplamı, gerçek başarıyı teşvik eden şeydir.

Not: Thomas Owens, böyle bir projede bir insanın ne gibi özel şeyler yapabileceğini sordu. Bu durumlarda kişisel rehberlik olarak kullandığım birkaç genel önerim var. Bir tehlike projesinin mucizevi bir şekilde başarılı olmasına yardımcı olur mu? Hayır, ama kötü durumlara rağmen kişisel bir başarıya ulaşmamı sağladı.

1) Kişisel mükemmelliğe odaklanın - daha iyi kod yazmaya çalışın, daha yüksek kalite ve işlevsellik standartlarına uyun.

2) Kişisel ölçütlere odaklanın - ne kadar kod yazıyorsunuz, sonraki hataları ortaya çıkarıyor mu? Bu oranı mümkün olduğu kadar düşürün. Size verilen bir görev için bir tahmin vermeniz istendiğinde, genellikle doğru mudur veya zaman çizelgesini fazla / altında tamponladığınızı mı buluyorsunuz? Gerçekten bir göreve atandığında, işin ilerleyişi hakkında iyi bir geri bildirim sağlıyor musunuz, teslimat zaman çizelgesi sorunlarının ileriye dönük olarak önceden bildirilmesi de dahil mi?

3) Takım metriklerine odaklanın - Bunlar sadece başımın üstündeki bazı şeyler: Çalışmakta olduğunuz bir göreve bağımlılık nedeniyle diğer takım üyeleri gecikmeli mi? Görevinizi / alt görevlerinizi ekipteki kişilere devretme veya bölme konusunda iyi misiniz? Takımın bir veya daha fazla üyesiyle iletişim kurmakta zorlanıyor musunuz? Düzenli olarak geliştirmek için üzerinde çalıştığım tüm alanlar.

Böyle bir durumda, merdivenin en alt basamağı olarak, projeye yardımcı olmak için yapabileceğiniz çok fazla şey vardır.

• Çalışmanızın lekesiz olduğundan emin olun
• en büyük sorunlu alanların belirlenmesine yardımcı olun
• Sadece sorun değil, cevap vermeye çalışın. Onları tamir etmeye çalışıyor gibisin.

Bunun dışında, gerçekten 1 numaraya bakmak zorundasınız.

• Her şeyi belgeleyin
• tüm e-postaları sakla, sohbet et
• Mümkünse, projeden bir çıkış yolu bulmaya çalışın

Başarısız olan projeler ruh için toksik olabilir, depresyona neden olur, fazla çalışma ve düşük özgüven.

Her şey perspektiften göreceli.

Her gün yüzünde gülümseme olan başka bir adamın karşısında otururken korkunç projeler üzerinde çalıştım. Ah suratındaki gülümsemeyi tokatlamak istedim.

Bazı insanlar bir projedeki mevcut durumdan rahatsız değil. Katkılarından, görevlerinden zevk alıyorlar ve ilgi alanları dahilinde çalışıyorlar. Diğerleri, mevcut durumlara güçlü bir olumsuz tepki veriyor. Her şey günlük işlerimiz için algılanan beklentilerimizle ilgili.

Sevdiğiniz bazı çalışmaları yaparken. Şu anki projede sevmediğiniz açıkça unsurlar var.

Bu sorun öğelerinin ne olduğunu tanımlamanız ve bunları ele almanız gerekir.

• son tarih baskısı
• kalite kontrol
• profesyonellik
• yönetim rehberliği

Gelişimin yukarıdaki yönlerini önemli bulamayan birçok takım ve şirket var. Bulduğum şey, sık sık aşağıdakileri düşündükleri.

• Son baskı, insanları motive etmenin bir yolu olarak algılanıyor.
• Kalite daha pahalı ve iade limiti.
• Profesyonellik, işin diğer alanlarına da uygulanır.
• Yönetici bir zaman bekçisidir ve kalkınmaya katkıda bulunan bir kişi değildir.

Bu problemler senin değil. Bu onların ve davranışları üzerinde hiçbir enerji harcamamalısınız. Bir uçurumun başında bile olsa gülümseyip işini sevenlerden biri değilseniz, like mindedgeliştiricilerin yerini bulmayı düşünmelisiniz .

Çok daha mutlu olacaksın.

Proje için başarıya ulaşmak için yeni bir yol bulma konusunda proaktif olmaya çalışın. Bazı alternatifleri nasıl önerebileceğinizi düşünün. Şu anda patronunuz muhtemelen projenin başarısız olduğu için dövülüyor, sorun yerine çözümle gelen birisini takdir etmiyor mu?

Belki de özellikleri aşamalı teslim edilebilir parçalara bölmenin bir yolu vardır? Genellikle "olması gereken" dereceleri vardır, bu yüzden öncelik sırasına koyabilir ve bunları kilometre taşlarına ayırabilir misiniz? Zaman çizelgesi sonunda bir ürüne sahip olmak hiç olmadığı kadar iyidir. Ya da takımı yeni işlevler üzerinde çalışanlar ve istikrar konusunda çalışanlar arasında paylaşmayı düşünün, bu şekilde her iki tarafta da bazı ilerlemeler gösterebilirsiniz.

Bu çabalar başarılı olursa, başarılı olmanın bir yolunu bulabilen bir ekip üyesi olduğunuzu göstermiş olacaksınız, eğer değilse, pes etmeyeceğinizi ve bir çözüm bulmak için çalışacağınızı kanıtlamış olacaksınız.

Yaptığım çoğu projeye benziyor. Ancak, muhtemelen düşündüğünüz kadar kötü bitmeyecektir:

1) İşini yap. Sorumluluklarınızı yerine getirdiğiniz sürece tüm proje hakkında çok endişelenmeyin.

2) CYA. Proje başarısız olursa ve yöneticinin kendisinden başka herkesi suçlamaya başlayacağından şüpheleniyorsanız, sizden istenen her şeyi yaptığınıza dair yeterli kanıtınız olduğundan emin olun (bkz. Madde 1).

3) İyileştirme için birkaç kibar öneride bulunun. Uyarı zillerini çalmayın, mahkum ve hüzünlü olmayın, sadece kibar ve zekice olun.

Örneğin, ekip etkili birim testleri (veya herhangi bir test) yazmıyorsa, görmek istediklerinize yakın birkaç birim testi yazın ve bunun belirli bir sorunu çözmenize ya da zamandan tasarruf etmenize nasıl yardımcı olduğunu açıklayın.

Değişimi etkilemek istiyorsanız ne olursa olsun, somut sonuçları olan olumlu adımlara odaklanın. Bu proje asla kazanamaz hale gelebilir, ancak belki bir sonraki takım için takım öğrenebilir.

Ayrıca:

4) Fırsatçı refactoring arkadaşınızdır.

1. Çok çalış; fakat aileniz veya sağlığınız pahasına değil.
2. Tüm kritik tasarım kararlarının kaydını tutun; özellikle de işinizle ilgili oldukları için.
3. Ağ kurmaya devam edin ve durum çok zorlaşırsa veya toplu işten çıkarılmaların kurbanıysanız seçeneklerinizi açık tutun.
4. Deneyin değil bir "başarısız proje" olarak projenizin düşünmek. Herkes olumlu kalmayı ve sıkıntı karşısında çok mücadele etmeyi seven insanları sever. Bu yüzden mümkün olduğunca o kişi olmaya çalışın . Olumlu bir bakış açısı, titizlik ve kararlılık işyeri için her zaman iyidir.
5. Başarısız bir projeyi bekliyorsanız, ölüm sonrası bir toplantı yapmayı planlıyorsunuz. Ölüm sonrası toplantıda herkes hesaba katılacak. Tüm kodunuzu savunmaya hazır olun. [Not: Genel bir kural olarak, daha sonra savunmak için her zaman temiz kod yazmalısınız.] Kararlarınıza ilham veren e-posta veya tasarım belgeniz varsa, bu daha da iyidir.
6. Bu ölüm sonrası toplantıda, olumlu kalmaya çalışın; ve sadece sizin yargı, çaba, ya işçilik sorgulanmaya takdirde, e-posta ve tasarım belge kanıt sunmak.

En etkili bulduğum şey Robert L. Read'in program baskısıyla nasıl mücadele edileceği konusundaki tavsiyesi . İşte Read yazıyor:

Mücadele takvimi baskısının anahtarı, basitçe piyasaya baskı süresi haline getirmektir. Bunu yapmanın yolu, mevcut emek ile ürün arasındaki ilişkiye görünürlük kazandırmaktır. Dürüst, ayrıntılı ve hepsinden önemlisi, dahil olan tüm emeğin anlaşılabilir bir tahminini yapmak, bunu yapmanın en iyi yoludur. Muhtemel işlevsellik değişimleri hakkında iyi yönetim kararları alınmasına izin verme avantajına sahiptir.

Tahminin basitleştirmesi gereken ana fikir, emeğin neredeyse sıkıştırılamaz bir sıvı olduğudur. Artık bir kabın içine, kabının hacminin üstündeki bir kabın içine daha fazla su koyacağınızdan daha fazla zaman toplayamazsınız. Bir anlamda, bir programcı asla "hayır" dememeli, "demek istediğin şeyi almak için ne pes edeceksin?" Demeli. Net tahminler üretmenin etkisi, programcılara duyulan saygıyı arttırmak olacaktır. Diğer profesyoneller böyle davranır. Programcıların sıkı çalışması görünür olacak. Gerçekçi olmayan bir program oluşturmak da herkes için acı verici olacaktır. Programcılar kaput gözünü kırpamaz. Gerçekçi olmayan bir şey yapmalarını istemek saygısızlık ve moral bozucu.

Projenin "başarısızlığa yöneldiğini" söylediğinizde, bu, hangi görevlerin yapılması gerektiği ve her birinin ne kadar çaba göstermesi gerektiği konusundaki değerlendirmenize dayanmaktadır. Bu değerlendirmeyi açık , anlaşılır ve ayrıntılı yapın . Görevlerini bileşen parçalarına ayırın; Geliştirme zamanının nasıl harcanacağını olabildiğince ayrıntılı olarak açıklayın.

Bunu yaptığınızda, endişeleri yönetimle tartışmak için sağlam bir temeliniz vardır. Tüm olasılıklarda, değerlendirmenizi tamamlanması gereken tüm özel görevlere ayırdıktan sonra, işin sahip olduğunuzdan daha fazla zaman alacağını - muhtemelen çok daha fazlasını - ortaya koyabileceksiniz.

Bu ayrıntılı programı müdürünüzle tartışırken, esnek olmaya hazır olun. Yöneticiniz "Görev X bir ay sürmeyecek; en fazla bir hafta sürecek" diyebilir veya "Görev Y tamamen gereksizdir, bunu programdan keser." Kesinlikle bu noktaları tartışmak, ama ne çok daha önemli üzerinde sizin ve yöneticisi arasında bir anlayış ulaşmaktır olabilir bazı bir takvimin gerçekçi sürümü. Bu şekilde, sınama için zaman ayırmıyorsanız, yalnızca "beklenmedik şekilde" zaman aşımına uğramak yerine sınamayacağınız açık bir yönergeniz vardır. Ve menajerinizin zamanında gemi açmak için belirli köşeleri açıkça kesmeye yasal olarak istekli olması kesinlikle mümkün - buradaki birçok durum var.

Tahmini tartışmak ve tartışmak için somut bir madde verir. Seni aynı sayfaya koyar; Yöneticinizin endişelerinizi dikkate aldığından emin olmanıza yardımcı olur. Ve eğer müdürünüz açıkça imkansızı isterse, ikinize de açıkça görüneceği bir noktaya getiriyor. Eğer proje iyi ve gerçekten mahvolmuşsa, bunu açıkça ortaya koyacaksınız ve zamanınızı nasıl harcamanızı istediğine tam olarak karar vermek yöneticinize bağlı olacaktır.

Yöneticiniz muhtemelen başarısız olacağını bildiğinden, çoğundan daha iyisindir. Yönetici ile çalışmayı düşünürdüm ve uygulamanın dışlanabilecek parçaları / özellikleri olup olmadığını kontrol ederim.

Çok sık, her müşterinin isteğinin bir 'anlaşma katili' olduğunu düşünüyor ve teslimatı vaat etmek için yolumuzu terk ediyoruz. Birisi müşteri ile çalışana ve sondalar daha derin olana kadar, bu kararları veremeyebilirsiniz. Bunu yapamıyorsanız, hala en önemli olduğunu düşündüğünüz şeyi sağlamaya çalışın. Bazen affetmeyi istemek izin almaktan daha kolaydır.

Açıkça başarısız olan üç projeye katıldım. Bunlar oldukça acı vericiydi ama geriye dönüp baktığımda üçünden ikisinin kariyerim üzerinde olumsuz sonuçları yoktu ve üçüncüsü bile dünyanın sonu değildi.

İşte hatırladığım bazı gözlemler.

Junior pozisyondaki geliştiriciler ("spec başına kod", "hatayı düzelt", bunun gibi şeyler), takımdaki moral bozukluğu nedeniyle gevşemediği sürece fazla etkilenmez. Bu gibi pozisyonlarda, mantıklı ve hatta bazen başarılı bir hayatta kalma stratejisi elinizden gelenin en iyisini yapmak olabilir.

• ^{Örneğin, karşılaştığım başarısızlıklardan bir tanesinin (bu ilerlemeyi teknik lider tarafından özellikle akıllıca ele alma yaklaşımıyla birleştiğinde) sonuçta üst yönetimin projeyi geri kazanma ve verme kararını vermesine neden olan bilinen yüzden fazla böceğin düz ve metodik olarak tespit edilmesiyle aşılmıştı. yeni bir sürümle yine bir başka şans, ki bu da makul bir başarı elde etti.}

Daha üst düzey ve etkili konumlardaki programcılar, proje başarısızlığının olumsuz sonuçlarını paylaşmak için daha iyi hazırlanabilirler. Bir mimar, teknoloji lideri, üst düzey geliştiricinin genellikle projenin başarısından veya başarısızlığından sorumlu olarak kabul edilebilecek kadar büyük bir etki yapması beklenir.

Kıdemli pozisyonda, neyin yanlış gittiğini ve neyin daha iyi yapılabileceğini analiz ederek başarısızlıktan “dolaylı olarak” kurtulmaya hazırlanmak daha iyi olurdu.

Bu bilgi bitleri, ölüm sonrası dersler doğru öğrenilirse paha biçilmez olabilir , WP'deki parlak cevapta açıklandığı gibi, kıdemli pozisyonlardaki çok başarılı kariyer bunların ne kadar iyi öğrenildiğine bağlı olabilir :

Yargı, başarıdan değil, başarısızlıklardan gelir. Çoğu şirket, başarısızlığı olan ve önceki şirketler tarafından ödenen insanları işe almak ister ...

Daha pratik bir notta "başarısız / yeni sürüm" yaklaşımı başarısızlıktan çıkmanın olası bir yolu olarak düşünülebilir. Tesadüfen olsun ya da olmasın (sanırım değil ), ancak kariyerime zarar vermeyen her iki başarısızlık da benzer senaryolara maruz kaldı: serbest bırakma Ntam bir felaketti, serbest bırakma N+1tolere edilebilirdi, serbest bırakma N+2ve daha sonra başarı elde edildi.

Ayakkabının içinde yürürken, büyük olasılıkla "bir sonraki sürüm" fikrini hazırlamak / geliştirmek için biraz çaba sarfederdim. Planlanan sürümden sonra düzeltmek istediğiniz bilinen geçici sorunların geçici bir listesi gibi bir şey yapın (ve iletişim kurun !) . Bir sonraki sürüm (ler) için gayri resmi ve kaba bir yol haritası taslağı hazırlayın.

Bu fikirleri çevrenizdeki insanlara nasıl iletebileceğinizi, bu planı göz önünde bulundurmak için yönetimi nasıl etkileyebileceğinizi düşünün. Projenin iyi bir pazarlama becerisine sahip biri varsa, "erken erişim", "beta", "müşteri önizlemesi", "tanıtım sürümü" gibi şeyleri daha yumuşak terimlerle tamamlayarak bunları hasar hasarını amortismana dahil etmeye çalışın. söyledi.

Bu fikrin sağırları daha fazla ortaya çıkacaksa, bir yedekleme planı düşünün. "Yüzden fazla bilinen böceğin düzeltilmesi" ile ilgili yukarıdaki haberi hatırlıyor musunuz? işlerin değişmesi için bir şans var, gerçekten.

Yönetim şimdi bir sonraki sürüm fikirlerine karşı sağır görünebilir, ancak proje kalitesi konusunda güçlü ikna edici kanıtlar karşısında yeniden düşünmeleri için iyi bir şans var.

• ^{Planlanan sürüm için dondurma kodu ile yönetimi tamamen bırakma kararı arasında uzun bir süre olması muhtemeldir. O zaman senin şansın: Bilinen sorunları çözmeye ve ilerlemeyi doğru şekilde "uyarlamaya" odaklanmak için çaba sarf ediyorsanız, bu bir fark yaratabilir (bir zamanlar bana olduğu gibi).}

Burada zaten pratik (ve başka şekilde) tavsiyelerde bulunuluyor, ancak bana göre bu gizemin anahtarı şu iki öğedir (benimkine önem verir):

Son teslim tarihi 1.5 aydır

ve

... biz aslında sadece etrafında (karmaşa) ile birlikte bu projeyi miras 1-2 ay önce gelen aynı yöneticiye altında başka bir dev ekip ...

Yani....

Takım Patsy Yenilmezler'e hoş geldiniz

Önceki takımın başarısız olmaktansa ... yapacak işleri vardı. Ve bir şekilde yönetici bununla devam etti. Son tarihe bu kadar takım değiştirmek, yapılacak en iyi proje yönetimi hamlesi değil, yani ... bunun nesi var?

Düzeltme: Son ekip, son teslim tarihinden ~ 3 ay önce değiştirildi.

-> Önceki takımın nasıl kaçmayı başardığını öğren ve bunu yap. <-

Bu belirgin boyutta bir sistemde hızlanmak, mimarisini daha az düzeltmek, testler eklemek ve bitirmek için 3 ay ancak yetecek kadar. Daha fazla zamana ihtiyacın var

Ve eğer bunu yapamazsanız, projenin süresiz olarak uzatılacağından ya da sihirli elfler ya da bir şey tarafından destekleneceğinden kesinlikle emin değilseniz, çantayı tutan solda kalan son adam olmak istemezsiniz.

Sert? Evet. Ancak, önceki takımlar / menajerler tarafından yapılan kötü planlama (en azından!) Sizin suçunuz olmasa da, 'teslim edilemedi' olacaktır .

Önceki takım kurtarıldı . Önceki takım kaldırıma atandı. Bu sana ne anlatıyor? Bana geri dönüş ekibi olduğunuzu ve yöneticinizin günü kurtarmak için kahramanlıklarınıza güvendiğini söylüyor.

5 kişilik bir ekip ve 1.5 ay kaldı. Yeni takım sadece 1-2 aydır projeye sahipti, bu yüzden yeni takım öğrenme eğrisinin üzerinde bile değil . Bu projenin boyutunda kaba bir tahminde bulunarak bana , projenin hiç problem yaşamamasına rağmen, yeni ekibin öğrenme eğrisinin üzerinden geçmesinin mümkün olmadığı gibi görünüyor .

Bu yüzden, (hala) bıktığını düşünüyorum.

Eğer durum buysa - ve sadece neyin doğru olduğuna veya neye inanmak istediğinize karar verebilirsiniz - bu tren kazasından kurtulmak için kimseye bir açıklama veya özür borçlu değilsiniz. Yine de bu konuda dikkatli olmanız gerekir.

Yöneticinin, projenin tehlikede olduğunu bilmediğinden ciddi olarak şüpheliyim, bu da nazik açıklamaların size olumsuzluktan başka hiçbir şey getirmeyeceği anlamına geliyor. Yöneticiniz Bay Rogers değilse , geleceğiniz tehlikede.

Ancak daima hatırlayın : İnternetteki yabancılardan kariyer tavsiyesi almayın.

Bu senin için inanılmaz bir fırsat! Bu konuda girişimci bir bakış açısına geçelim.

Yönetimin bu projenin başarıya ulaşmasını istediğini varsayarsak, onlara yardımcı olacak mükemmel bir konumdasınız. Bu gerçekleştirmenin bu kadar önemli olmasının nedeni, gördüğünüz uyarı işaretlerinin aslında bu projenin başarısızlığına yol açacağı inancı ve güvenini geliştirmek zorunda olmanızdır [1].

Sistematik düşünme ve kişilerarası iletişimde önemli becerileri kullanma şansınız budur. Kaçırılan sorunları ve olası fırsatları anlayın ve görselleştirin; böylece bunları mümkün olduğunca açık ve basit bir şekilde iletmek için bir strateji geliştirebilirsiniz.

Becerilerinizi geliştirmek için buradaki fırsatınızı tanıyın.

[1] Projeyi iptal etmek gerçekten başarılı olurdu. Başarısızlık kötü sonra iyi para harcıyor olurdu.

Ne yapabilirsin

• Bunu kendi kişisel mükemmellik terimlerinizle ele alın, "onların" projesi, aynı zamanda sizindir, başarısız olacağını bilseniz bile mülkiyeti alın. Neden? çünkü a) daha az başarısız olmasına yardım edebilirsin, b) meydan okuma zamanında, en çok öğrendiğin yer burasıdır c) Kendini kendi mükemmeliyet ölçütlerinle ölçmelisin, elinden gelenin en iyisini yapmak projeyi kurtaramaz, ama sen kendinle hala gurur duyuyor olabilir

• Diğer geliştiricilerle konuşun ve ne düşündüklerini görün, muhtemelen dikkatlice yapılırsa (insanların bir isyan veya başka bir şey başlatmak istediğinizi düşünmesini sağlama) aynı sıkıntıyı paylaştığını göreceksiniz, o zaman bu sadece sizin için değil diğerleri de

• Sorunu görmezden gelmek, onu ortadan kaldırmayacak, tüm olasılıklara rağmen nasıl devam edebileceği hakkında konuşmaktan bahsetmiyor, örneğin, en azından bazı iyi değerlere sahip olmanız gerekir, ya da ana "vay faktörü" kullanım durumu bunu yapabilir proje daha az sefil başarısız olur. Nasıl yapılır? Eh, "zorlaşınca zorlaşıyor" veya "çaresiz zamanları umutsuz önlemleri haklı çıkarır" ve diğer klişeler gibi fikirlerin azlığı, örneğin: OSS’nin yoğun kullanımı, aşırı programlama / çevik metodolojiler, hafta sonu hackathonları (sadece gönüllüler, insanları zorlamadan hafta sonları çalışmak). Bu, liderliği gösterebileceğiniz zamandır (eğer takım liderliği / kıdemli pozisyonda değilseniz dikkatlice) ama bu avantajdan faydalanıp alaycı bir hale gelebilirsiniz, sadece insanların bu projeyi biraz daha başarısız olabileceğini hissetmelerini sağlayın. herkes bilir.

• Yönetiminizin bildiğinden emin olun, ama çok, çok dikkatli, eğer biliyorlarsa, onlara bunu yüzleşmeksizin, sakin bir şekilde söylemekten memnuniyet duyacaklar, bunu daha fazla takdir etmeyeceklerse ve neden kimsenin söylemediğini merak edeceklerdir. Daha önce onlar hakkında. Onlara bunu bir hizmet olarak, hiçbir duygusal tarafı olmadan, sadece açık gerçeklerle ve gündem olmadan söylemelisiniz. Ne yapmaları gerektiğini düşündüğünüzü soracaklarsa (bu harika bir işarettir, ancak nadirdir), bir sonraki bölüme bakın.

Ne yapamazsın, ama yönetimin muhtemelen yapmalı

• Onlar "yardım etmek" projesi daha fazla kullanıcı eklemek gerekir bkz bu

• Hemen müşteriyi arayın ve onlara kötü haberi verin. Bu neden iyi bir fikir? Pekala, çevik yazılım geliştirme için manifestodan alıntı yapacağım, ancak onsuz bile, su düşüşü sevenler bile kötü sürprizlerden nefret ediyor. Eğer müşteri önceden biliyorsa, bu proje başarısız olmaya mahkumdur, mutsuz olacaklar, ancak yüzlerine çarpmadan önce sorunların olduğunu ve bunun üzerine geldiğinizden ve size uyum sağlamak için elinizden gelenin en iyisini yaptıklarını söylemekten çok daha mutlu olacaklar o. Müşteri birçok şey yapabilir ancak çoğu, son dakikada teslim edilebileceklerini (ya da yapamayan ancak kaliteli olmayan) bulduklarından daha kötü değildir. Müşteri, işe alma test personelini, denizaşırı BT çalışanlarını, iç eğitim planlarını değiştirebileceklerini ve sadece onlara karşı dürüst olduğunuz için geciktirebileceklerinden memnun kalacaklardır.

• Müşteriyle, hala projeden bir şeyler çıkarmanın yollarını düşünün, en yaygın olanı şeyleri çözmektir. örneğin, tasarlanma şeklini geliştirmek için çok zor olan bazı özellikler olabilir ve müşteri bazı küçük değişiklikler ve basitleştirmeler için hemfikir olduğunda, bazı özellikler daha basit hale gelir.

• Kendi üst yönetimlerini güncelle, onların da işlerini korumalarına yardımcı olacak ...

Eğer gerekenler DEĞİL yapmak

• Projeye fazla kişi eklemek için sor (bkz bu )

• Çıkın / başka bir iş arayın (en azından henüz değil), bu, öğrenebileceğiniz bir şeydir ve sizi bir gün daha iyi bir geliştirici veya daha iyi bir yönetici yapan nedir. Daha iyi, daha iyi zaman yönetimi, daha iyi tasarım, daha iyi kod yazmayı ve akranlar ve yönetimle daha iyi çalışmayı daha iyi değerlendiriyorsunuz. Orada çalışmayı sevmiyorsanız, başka bir nedenden dolayı değil, bu 2 ayın sonunda bir iş arayın.

• Projeyi, yönetimi, miras aldığınız kötü tasarımı, yeni başlayanlar geliştiricilerini, 1 saat süren bir şeyi yapmalarını açıklamak için 3 saat süren, sizin kadar pozitif olacağına dair akıl yürütmek, şikayet etmek veya olumsuz olmak Yapabilmek.

• Yönetimi eleştirin ve sorun yaratan bir hedef haline gelin, aynı teknedeler, ve bilmediğiniz şeyleri biliyor olabilirler, yapabileceğiniz tek şey onları güncellemektir (her zaman kendi doğrudan yöneticinizi güncelleyin, asla atlamayın)

• İnsanları suçla (ya da kendini), yardım etmez, asla

• Çok ciddiye alın, tıbbi ekipman olmadığı sürece, son başvuru tarihlerini kaçırırsanız hiç kimsenin ölme olasılığı yoktur, bu yazılım, geçim için son tarihleri ​​özlüyoruz, rahatlayın.

Bu sadece iki sentim, YMMV

Projenizin karşılaştığı sorunları bulun ve nesnel olarak mümkün olduğunca net bir şekilde ölçmeye çalışın. Her "metrik" ile, bu metriğin neden önemli olduğuna inandığınızı tanımladığınızdan emin olun. Yöneticinize, belirli bir metrik "kabul edilebilir aralık" dahilinde olmazsa sonuçların ne olacağı hakkında fikir vermek istersiniz. Hangi değerlerin "İyi", "Kabul Edilebilir", "Sorunlu" veya "Kötü" olduğunu belirtmek için her bir metrik için bazı kurallar vermeniz gerekecektir. Her ölçütü ön tanımlayınız. Mümkünse, bir projenin başarılı olması ve bunu mevcut proje ile karşılaştırması için asgari olarak neyin gerekli olduğunu tanımlayabilirsiniz.

• Statik Kod Kalitesi, çok sayıda statik analiz aracıyla belirlenebilir. Bunu uygun gördüğünüz kadar basit veya ayrıntılı tutabilirsiniz. Size önerdiğim metrikler:
  • Cyclomatic karmaşıklık
  • Kodunuzun boyutu (örneğin, işlev / sınıf başına satır sayısı, dosya sayısı, tablo sayısı ...)
  • Hangi modüllerin çok büyük olduğunu belirleyin
  • Çoğaltma.
  • Kod stiline bağlılık
• Kusur oranı
  • KLOC başına modül ve veya alt sisteme göre (sisteminizin sorunlu bölümlerini tanımlayın)
  • Her takım üyesi için ne kadar olduğunu hesaplayabilirsin ama bence bunu kendine saklaman gerekir.
  • çözüldü vs bulundu
  • bir hatayı çözmek için gereken süre (belki de eğer bu eğimliyse, bunun bir grafiğini yapın)
  • belki de bu, şu anki hızda devam ederse ne kadar zamana ihtiyaç duyulduğunu tahmin etmek
• Planlama
  • Ekstrapolat süresi için inşa edilen özellikler kullanılır. Özelliğin karmaşıklığını dikkate alın. Bu çok kesin olmak zorunda değil. Bununla iletmek istediğiniz şey "A, B ve C özellikleri D, E ve F ile aynı karmaşıklıktadır. ABC özellikleri ile planlanan zaman% 170 oranında kullanılır. Eğer hiçbir şey değişmezse aynı olacağını düşünüyoruz. DEF için zamana veya “Ortalama özelliğin hesaplanandan% X daha uzun sürdüğü” satırına ihtiyaç vardır. Gelecekteki planlamada bunu telafi etmemiz gerektiğine, işlevselliğin geri kalanının inşa edilmesinin daha kolay olduğunu varsaymak için hiçbir nedenimiz yoktur. Gerçekçi değilse, bir plan yapmanın faydası yoktur.
  • Bazı aylık veya tercihen daha kısa bırakma zamanlaması yapmaya çalışın. Sadece iç ise. Bu, proje için gereken süreyi fazladan tahmin etmenize yardımcı olabilir. Bu aynı zamanda sizi gerçekçi olmayan taahhütlerde bulunmaktan kurtarabilir (eğer serbest bırakılmadan önce yeni işler yapmazsanız). Her bir silindir için bir planlama yapın ve yeni özelliklerin yalnızca bir sonraki çevrime girdiğinden emin olun (yani, mevcut çevrime asla eklenemez).
• Test kapsamı: "normal" test kapsamı değerlerini açıklayın ve mevcut kapsamınızın ne olduğunu gösterin
• Belgelendirme: Aslında yüzde kaçı belgelenmiştir? Ne kadar iyi?
• modülerlik:
  • Sınıf bazlı (kavrama ve uyum)
  • Paket tabanlı
  • Alt sistem tabanlı (kaç tane iletişim yolu var?)

İşe gitmeli ve başarılı olup olmadığına bakılmaksızın herhangi bir projede ne yapacağınızı yapmalısınız. İşini yapmak için para alıyorsun. Yeteneğinin en iyisini yap. Proje yöneticisi / sorumlusu olmadığınızı varsayarak, bir programın iptal edilip edilmemesi gerektiğine karar vermek sizin sorumluluğunuzda değildir. Gevşemeye karar vermen, projeyi iptal etme kararını verdiğin gibi. Bu iş tanımının bir parçası değil.

Ancak, büyük resimde, bu zamanlamayı denemek ve karşılamak için haftada 50, 60 veya daha fazla saat çalışmanız gerektiği anlamına gelmez. Bir kez daha, bu proje hedeflerine nasıl ulaşılacağını bulmak için yönetimin görevi. 50+ saat çalışma haftası, fazla mesai yapmak istemedikleri ve aile hayatınızı beklemeye almadığınız sürece makul bir seçenek değildir. Bir kez daha, ulaşılabilir bir program oluşturmak bir araya geldi. Gerçekçi olmayan programları yerine getirmek için çalışanları aile hayatlarını görmezden gelmeye zorlayabileceklerini varsaymazlar.

Ayrıca program 1/2 ay kalabiliyor. Bu muhtemelen "ölü bırakma" tarihi değildir. Bazı müşteriler, hepsi olmasa bile sahip olduklarınızı o tarihe kadar alabilir. Bazı müşteriler, projeye zaten çok para harcadıkları için fazladan fon bulabilirler. Bazen şirketin kendisi memnun bir müşteri sağlamak için ek maliyetler üstlenebilir. Bütün bunlar senin kontrolün dışında. İşini yeteneğinin en iyisini yap. Bu, felaket projesini büyük bir başarı hikayesine dönüştürebilecek olan bununla birlikte yönetim seçenekleri verecek. Bunun birçok kez olduğunu gördüm.

Sadece başkalarının söylediklerini yineleyebilirim ama vurgula vurguluyorum: Her zaman en iyi çalışmanız için gayret gösterin ve bir kağıt izi bırakın. hem CYA hem de teknik sebeplerden dolayı.

Yolunuza çıkan herhangi bir düşüş yönetimin kişisel karakterine bağlıdır; ama size söyleyeyim ki, beceriksiz, yalancı yönetimin alıcı ucunda. Ancak, kendinizle (ve meslektaşlarınızla) bırakacağınız en kötüsü, tam bir saygı ile.

Ölüm Mart'ınızın teknik yönleriyle ilgili not alın. Kaçınılmaz görüşme sorusunu aldığınızda başarısız bir projeye katıldınız; neden başarısız oldu ve önlemek için ne denedin? Bonehead yönetimi bir cevap değil - nedeni olsa bile.

Kaçınılmaz ve kesin bir başarısızlık olduğunu varsaymanın ve projeden vazgeçmenin kolay bir yolu olabilir. Bir danışman olarak sık sık çeşitli dejenerasyon aşamalarında olan, başarısız veya başarısız olan projelere yardım etmeye davet edilirim ve bunun için ödenenlerin bir kısmı bu projeleri canlandırmak ve tamamlamaktır.

Tam bir başarısızlık olarak gördüğünüz şey, bakış açısına bağlı olarak herkes tarafından algılanamayabilir. İdeal bir dünyada, her özellik eksiksiz ve diğer sistemlerden ve test edilen her kod satırından bağımsız olarak kodlanmış olur. Rev 1'de buna benzeyen tek bir proje görmedim. Gerçek dünyada, bir projenin nakliyesi bazı ödünlerin alınması, hatta bazı temel özelliklerin eksik olması anlamına gelebilir, ancak ürün en iyi şekilde beta kalitesi olsa bile ürün gönderebilir , en azından ilk olarak hangi şeylerin düzeltileceği konusunda geri bildirim alacaksınız. Bunun tersi, yönetime yazılımın hiçbir zaman yapılmadığını bildirmesi ve vakumda belirli bir v 1.0 geliştirmeye çalışmak yerine değişikliklerin çevik bir şekilde yinelemesinin ve yanıt vermesinin daha iyi olacağı yönündedir. Sonunda bu pozisyonda bir geliştirici olarak, Bence asıl mesele bu koşullarda mümkün olduğunca iyi bir kod geliştirmek - bunu belgelemek, kendiniz (özellikle dışsal bağımlılıklar için) test etmek ve sistem hakkındaki bilgilerinizi hangi özelliklerin gerçekten çok önemli ve gerekli olduğunu bildirmek için kullanmaktır. -have ve hangileri bir hafta veya bir ay bekleyebilir Endişelerinizi dile getirin ve bize yaptığınız gibi haklı olun. B planı için hazırlık yapmak yerine, siz ve diğer fakir ruhların muhtemelen tüm buggy ve yapılmayan kodları sabitleyeceği gerçeğine hazırlanın, ürün gönderildikten SONRA - yukarıda belirtildiği gibi, kodunuzu modüler bir dekuplajlı şekilde yazmak anlamına gelir. kalıcılık katmanı kodunun kötü olduğunu düşünüyorsunuz, umarım bir sonraki revizyonda tamamen değiştirebilmelisiniz. Sonunda, umutsuzluğa kapılmayın - böyle bir durumla başa çıkmak sizin işinizin bir parçası bunun için para alıyorsunuz ve bu bir öğrenme süreci. Bu özel projenin sonucuna bakılmaksızın, bu gelecekte değerli bir deneyim olarak sayılacaktır.