Bir müşteri gerçekçi olmayan beklentileri olduğunda ne yapmalı? [kapalı]

Veri gizliliğine ihtiyaç duydukları ve kendi ofisimizde çalışmamızı istemedikleri için son altı aydır bir müşteri sitesinde bir proje üzerinde çalışıyorum.

Bu müşteri sitesine yalnız göründüğümde, projeyi iki ay içinde bitirmem gerektiğini söyledi.

Müşteri bir yazılım şirketi olmadığından ve çeşitli politikalar nedeniyle, makineme Eclipse, Tomcat, vb. Gibi şeyler yüklememe izin vermem 20-25 gün sürdü. Projeyi aynı iki ayda tamamlamamı bekliyorlardı.

Bana herhangi bir gereksinim belgesi vermediler, ancak müşteri sitesinde çalıştığım için, gereksinimleri görüşmek üzere düzenli olarak toplantı yapıyorduk.

Altı ay sonra başvuru hala bitmedi ve herkes beni suçluyor, ancak ilk birkaç toplantıda tartışılanlardan çok daha fazla özellik eklediğimizin farkında değiller.

Bu süreçte birçok şeyi tekrarlamak zorunda kaldım, örneğin bir formu iki bölüme ayırın; Birkaç hafta sonra, benden iki kargaşayı ve diğer şekilleri tekrar birleştirmemi istediler.

Uygulamanın kapsamı her geçen gün artmaktadır, ancak yine de geciken iki aylık bir proje olduğunu düşünüyorlar. Onlara kapsamın arttığını söylediğimde, başlangıçta neden talepte bulunmadığımı soruyorlar.

Zaten her gün 11-12 saat çalışıyorum ve 3-4 saat yolculuk yapıyorum ve şimdi de cumartesi günleri gelmemi bekliyorlar.

Burada her şeyi yapmalıyım: gereksinimleri al, tasarım yap, kodla ve test et.

Lütfen böyle bir durumda ne yapmam gerektiğini söyle?

_{Ek ayrıntılar: Teslim edilecek parçaların bir listesi var, ancak daha sonra bunların da önemli olduğunu söyleyen birkaç şey daha eklediler. Ayrıca birkaç teslimatı da değiştirdiler. UAT sunucularına bile sahip değiller, geliştirme makinemi kendi IP adresiyle test ediyorlar.}

Bu, yöneticinizin başarısızlığıdır . Yüklenici olarak, şirketiniz tarafından yazılı olarak önceden kesin olarak kesin bir şart belirtilmeden böyle bir son teslim tarihine sahip olmamalısınız. Bunların hiçbiri sonradan saçma 'onlar özellikler eklendi' - oldu her seferde bu güncelleştirilmiş programa kapalı imzalamalıydım sen verdi onlara .

Yöneticiniz, onunla buluşmayı planladıkları için müşteriden özel bir takım gereksinimler elde etmeleri gerekiyor - proje A, B, C, D ve E'yi yapmalı. Müşterinin imzası, bu listeyi kabul eden o belgenin üzerinde olmalıdır. Bunu en başından almalıydın.

Yöneticiniz sizi desteklemiyorsa ve bu konuda size destek olmazsa - ve bunu çok sık söylemiyorum - başka bir iş aramaya başlayın. Çünkü muhtemelen tüm karmaşa için günah keçisi olursunuz. Ve 11 saat ve 3 saat işe gidip gelmeye istekliysen, daha iyisini hak eden çok özverili birisin.

Bu gibi durumlarda önemli olan, bir CYA kağıt izi oluşturmaktır. Özellikle karmaşık bir iş ilişkisinde, yazılı olmadan hiçbir şey yapılmamalıdır. Çalışmanıza izin vermek için 20 güne ihtiyaç duydukları halde başlangıç ​​programına bağlı kalmak, karmaşık hale geleceği büyük kırmızı bir bayraktır.

Ek özelliklerin gerekli olduğu bir toplantı mı yaptınız? Daha sonra yazın, her öğenin üzerinde "+ X gün geçerli programa" etiketleyin ve katılan herkese postalayın. Yalnızca müşterinin dahili posta sistemini kullanıyorsanız, ayrıca :, cc: ve bcc: alıcılar listesi de dahil olmak üzere yazdırın ve dikkatli bir şekilde arşivleyin. Bunun yanı sıra, GrandmasterB'nin dediği gibi, müşterinin orijinal gereksinimlerindeki bu gibi değişiklikleri imzalaması gerekir.

İstenilen program düzenlenemiyorsa, onlara yazın. Herhangi bir değişiklik olursa, sonuçları da dahil ederek onlara yazın. Ve bunun gibi.

Bu, "Sana söylemiştim" değil. karışıklık nihayet duvara çarptığında - yine de onu dinlemeyecekler. Bu, müşterinin sizi sözleşmeyi yerine getirmediğinizi düşündüğü için veya şirketiniz müşteriyi ödemesi nedeniyle reddettiği için dava açtığını düşündüğü için sizin sigortanızdır.

Tanımladığınıza göre, klasik bir Death March projesine katıldığınız anlaşılıyor :

Gelen proje yönetimi , bir ölüm yürüyüşü bir dysphemistic içeren patolojik projelerin çeşitli türlerinin herhangi bir gerçek için, koyu mizah benzetme ölüm yürüyüşleriÖrneğin, çok fazla yorulma ve (genellikle ve en özel olarak), kötü sonuçlanma riski yüksek olan (yani, proje başarısızlığı ve muhtemelen kişisel ve grup itibarı hasarı tehdidi) riski yüksek olan bir proje üzerinde, kötü niyetli bir şekilde yorulmadan çalışmak; . Bu nedenle, "ölüm yürüyüşü" adı, nihayetinde başarılı olan ancak sürdürülemez fazla çalışmanın evden genişlemesini içeren bir projeye uygulanabilir (veya belki de daha sık) herhangi bir zeki, bilgili üyenin görebileceği bir projeye başarısız (veya çok yüksek başarısızlık riski altındadır) ancak üyelerin yine de üstleri tarafından hareket etmek zorunda kalmaları ...

Fenomen iyi bilinmektedir ve nasıl devam edeceğiniz konusunda pek çok literatür vardır - elbette seminal Edward Yourdon'un Ölüm Marşı kitabı : 'Görev İmkansız' Projesinden Kurtulma Komple Yazılım Geliştirici Kılavuzu .

Yukarıda alıntılanan Wikipedia makalesi , ölüm yürüyüşü projeleriyle ilgilenen / ilgilenenlere daha fazla bilgi, araştırma ve öneri aramak için iyi bir başlangıç ​​noktasıdır .

Ayakkabının içinde yürürken, ilk önce düşündüğüm şey yukarıdaki yazıya atıfta bulunarak menajerime haber vermek.

Bu yol, neler olup bittiğinin farkında olduğumu bilmelerine ve muhtemelen "Bak, şu anki durumumuz XYourdon'daki bölümde anlatılana yakındır . dışarı, yakından ilgili bölümle birlikte Y... "

Yöneticinin bu çalışma alanından haberdar olmadığı (çok muhtemel olmayan) durumlarda, atıfta bulunmak, durumu tespit etmek ve nasıl başa çıkılacağına karar vermek için düşünce için bol miktarda yiyecek verebilir.

Dürüst olmak gerekirse, bunu yapabilmeniz mümkün ise, en iyi çözüm istifa etmektir. Bunun gibi durumlar sizin için toksiktir ve ne kadar zorlarsanız çalışın zamanla nadiren iyileşir.

Kayıplarını azaltmak ve farklı bir iş bulmak için en iyisi. Ancak, deneyimlerinizi yansıtın ve bu konudaki diğer cevapların önerilerini alın.

Bu ciddi bir şey issue in project management . Teslim edilebilir listeniz üzerindeProject Manager çalışmanız ve onları müşteri ile önceliklendirmeniz gerekiyor gibi görünüyor .

En önemlisi , Başbakanınız should discussve Müşteri ile tahminlerinizde zaman çizelgesini (tasarım / problem / çözüm analizi dahil) kabul etmiş sayılırsınız.

Having clear estimation of your work loadve projenin teslim öğeleri, yanı sıra, stres sizi rahatlatmak katacak huzur çalışmalarınızda ve güven.

Öğelerinizi sprintte (2-3 hafta) teslim ederek ve müşteriyle UAT (kullanıcı kabul testi) yaparak Agile yaklaşımını kullanmaya çalışın . Unutmayın, sprint başlamadan önce daima sprint planlamanızı yapın.

Düzenleme: Yorumlardan, bunun gerçekten de proje yöneticinizin başarısız olduğu açıktır . Sizinki gibi ciddi bir proje için uygun test ve / veya geliştirme ortamına sahip olmamak, SDLC süreci için büyük bir projectdeliktir.

Bunun bir yönetim hatası olduğu konusunda hemfikir olmama rağmen, sizin açınızdan da bir başarısızlık. Bu aşamada düzeltilmesi çok zor olacak, bu yüzden bundan kurtulmanız için gerekenlerin bazıları gelecekteki projelerin nasıl ele alınacağıdır.

İlk önce, projenin başlangıcında bir gereksinim temel belgesinde ısrar etmeniz gerekir. Süslü ya da resmi olmak zorunda değildir, ancak müşteri ne beklendiğini belirtene kadar başarılı bir şey oluşturamazsınız. Bunu yazılı olarak yapmazsanız, müşteriden nihai sonuçtan memnun olma şansı yaklaşık% 0'dır. Yani bu kritik derecede önemlidir. Ayrıca, bu belgedeki belirsizlikleri aramak ve en kısa zamanda bunları ortadan kaldırmak da sizin işinizdir. Bunlardan birine rastladığınızda ve nasıl yorumlayacağınızdan emin değilsiniz, ne anlama geldiğini tahmin etmeyin, sizin ve müşterinin ne anlama geldiğiyle ilgili aynı sayfada olduğunuzdan emin olun. Evet, bu insanlarla daha fazla konuşma ve daha çok toplantı ve daha az kodlama anlamına gelir. Ancak belirsiz bir gereksinimi ortadan kaldırmak, yanlış kodlamaktan ve daha sonra yeniden kodlamaktan daha az zaman alır. Dahası, sıklıkla tekrar kodlamaları ücretsiz olarak vermelisiniz ve bu çalıştığınız şirket için iyi değildir.

Daha sonra, onlara işi yapmanın ne kadar sürdüğünü ve son süreyi belirlediklerini söyleyin. Gereksinimleri karşılamak için gereken işi yapmak için harcayacağınız saatler dışında hiçbir süreye dayanan bir süre kabul etmiyorsunuz. Eğer yaparsan, yine ölüm yürüyüşünde olacaksın. Onlara, süreleri için ayrıntılı bir açıklama yaparak son tarihin nasıl karşılanamadığını gösterin. Müşteri ne kadar isterse sürsın, sadece 1 geliştiriciyle haftada 200 saat geliştirme süresine uymazsınız. Son tarihin taşınmaz olduğu noktada, hangi öğelerin bir sonraki yinelemeye taşınması gerektiğini sorarsınız.

Proje zaman tahminleri yapılırken, büyüme zamanının proje zamanının sadece küçük bir kısmı olduğunu unutmayın. Ayrıca toplantılar ve e-posta / telefon iletişimi, test, dağıtım, dokümantasyon, sunucuların fiziksel kurulumu, iş istasyonları, yazılımlar için hesap açmanız gerekir. Ayrıca, son tarihin planlanmasında, yalnızca 8 günlük olmayan 6 saatin olduğunu varsayabilirsin. Bu, izin, ölüm, hastalık süresi, kaçınılmaz bir gecikmedir (örneğin, izin almasını beklemek zorunda kaldığın zaman) ağ üzerinde vb.), eğitim, proje ile ilgili olmayan çalışmalar (zaman çizelgeleri, İK toplantıları, vb.). İnsanların son başvuru tarihlerini karşılamamalarının en büyük sebeplerinden biri, sadece geliştirme yapacakları ve her gün 8 saat boyunca çalışacakları varsayımını ortaya koymalarıdır. Bu sadece gerçekçi bir varsayım değildir.

Ve her yeni bir parça eklediklerinde, onlara ne kadar zaman alacağını ve ek çalışmanın son tarihi ne kadar hareket ettireceğini söylersin. Son tarihi taşımak istemezsiniz, onlara yeni gereksinim nedeniyle hareket ettiğini söylersiniz. Şimdi bu işlem için yöneticisi aracılığıyla gitmeli, ama öyle her şeyden önce emin yönetici projeye katkı sağlayacak her türlü şartı değiştirilir zaman ve ne kadar bilir hale getirmek için reponsiblity. Bütün bunların yazılı olduğundan emin olun, böylece gerekirse kendinizi savunabilirsiniz.

Daha sonra, 11 saat gün ve hafta sonları çalışmak için kendinizi kötüye kullanmanıza izin vermeyin. Bu kısa mahpuslarda tamamdır (her altı ayda bir 1 haftadan daha az), ancak uzun vadede bu kabul edilemez. Yorgun insanlar yavaşlar ve daha fazla hata yaparlar. Düzenli olarak 11 saatten 8 saat daha düzenli çalışarak daha kaliteli çalışabilirsiniz. ve hafta sonları.

Gantt Grafikleri'nin bu gibi durumlarda çok iyi olabileceğini gördüm. Müşterilere mevcut programı gösterebilir ve yeni özelliklere / değişikliklere eklenmenin etkisini göstermede faydalı olabilir. Bazen, x özelliğinin bir teslimatı y gününe kadar etkileyeceğini bir müşteriye söylemek, kayıt yaptırmaz. Bir grafik üzerinde açıkça göstererek daha iyi anlayabilirler.

İdeal olarak bu, projenin başlangıcından itibaren yapılmalıdır. Bu noktaya kadar olan “ gecikmeleri ” açıklamak faydalı olmayabilir, ancak projenin ilerlemesine yardımcı olabilir.

Gönderen Wiki :

Gantt çizelgeleri, terminal elemanlarının başlangıç ​​ve bitiş tarihlerini ve bir projenin özet elemanlarını gösterir.