İmzalanan bir sözleşme ile zamanında tahminde bulunmak isteyen Proje Yöneticisi

Daha önceki bir işte, bir proje yöneticisi (PM), bulunduğum bir projedeki kodun teslim süresinden memnun değildi. Proje liderim tarafından, Başbakan'ın görevler ve teslim tarihleri ​​için verdiğim süre tahminlerini kilitlemek için bir sözleşme imzalamamı düşündüğünü söyledi .

Projedeki durum, yeni teknolojiler, kod temeli, kodlama standartları ve değişime yatkın gereksinimlerle çalışıyor olmamızdı. Yeni şeyler öğreniyor ve onlara sürekli değişen gereksinimler için elimden gelenin en iyisini uyguluyordum. Yinelemeler boyunca gereksinimler 2-3 kat arttı, tahminim tamamlandı ve kabaca 5-8 kat arttı. Değişmeyen tek şey tahminler ve teslimat tarihleriydi.

Evet, en son teslim tarihlerini kaçırdım. Ve ben çok yeni teknolojiler üzerinde çalışıyordum, tüm geliştirme ekibindeki hiç kimsenin gerçekten yardımcı olamadığı için, buna aşina olmayacaklardı. En azından kolay değil.

Öyle görünüyordu ki, Başbakan numaralarının toplanmasını istedi - ve böylece her zaman zamanında çalışma kodunu ileteceğimi "sağlamak" için bir sözleşme imzalamamı istedi. Sanırım zamanında teslim edemezsem, imzalanan bir sözleşmeyle Başbakan bana karşı kullanabilirdi.

Bundan sonra olanların, diğer proje yöneticilerinin ve / veya proje liderlerinin beni savunduğuna ve bunun olmasına izin vermediğine inanıyorum.

Sorum şu, bu yönetici hakkında kırmızı bir bayrak mı yükseltir? Bir yöneticinin bir yazılım geliştiricisinin imzalanmış bir sözleşmeyle zaman tahminlerini kilitlemesi yaygın bir uygulama mı? Veya bu durumda, deneyin.

Lütfen dikkat, tam zamanlı bir çalışandım, bağımsız bir danışman değil.

Güncelleme : Haftalık olarak yeni tahminler verdiğimi eklemek isterim, ancak orijinal tahminler ve teslim tarihleri ​​PM'nin kararlaştırıldığı şey gibi görünüyor .

Sorum şu, bu yönetici hakkında kırmızı bir bayrak mı yükseltir?

Evet . Özgeçmiş / CV'nizi güncel hale getirmenin ve yeni bir iş aramaya başlamanın zamanı geldi demektir. Veya bu, menajerinizin sizinle çok kötü oyunlar oynamaya başlamak üzere olduğu anlamına gelir .

Bir yöneticinin bir yazılım geliştiricisinin imzalanmış bir sözleşmeyle zaman tahminlerini kilitlemesi yaygın bir uygulama mıdır?

Bunun bir çalışana uygulandığını hiç duymadım.

Zaman ve emek tahmini her zaman zordur. Özellikle mesleğimiz aşırı iyimserlik dolu olduğundan. Gelecekte tahminlere yardımcı olabilecek bazı tahmin sistemleri var, ancak kendisinden tarihsel istatistikler toplamaları gerekiyor. Biri PSP . Başka bir İşlev Puan . Birçok geliştirici de beğenmez ve her ikisine de karşı çok güçlü görüşler bulacaksınız.

Zaman ve çabayı tahmin etmedeki en önemli zorluk, tahmin sezgilerimizdeki geribildirimlerin yetersizliğidir. Anahtarlardan biri, tahminin ne olduğunu ve tahmin etmek için hangi parametreleri kullandığınızı yazmaktır. Sonra, gerçekte ne yaptığınıza bağlı olarak, bunu yapmayı düşündüğünüzle karşılaştırın. Ve tahmin parametrelerinizi değiştirmek için bunu kullanın. Mühendislikte buna " geribildirim " diyoruz .

Evet, kesinlikle alarm zilleri çalmalıdır.

Kişisel eğlencem için pozisyonda olsaydım, yöneticiden tüm şartları dondurucu bir sözleşme imzalamasını isterdim. Yöneticinin kefaletle serbest kaldığını hayal ediyorum. Sonra ayrılırdım.

Peki bu basit. Yöneticinize, belirtimi ne zaman kilitlemek için imzalayacağını tahmin edeceğiniz zaman hesaplamanız için imzalayacağınızı söyleyin. Çünkü, kesin olarak bilinmeyen bir şey için herhangi bir tahmin veremezsiniz. Başlamadan önce tüm proje özellikleri, değişiklik yok - ve bunu zamanında bitirebilirsiniz :)

Spec => sözleşmesinde yapılan bir değişiklik geçersiz. Muhtemelen iş ilk gününüzde 10 dakika sonra geçersiz sayılacak :)

Evet, bu bir kırmızı bayrak. Size anlattığı şey, yöneticinin yazılım projelerindeki riskin nasıl yönetileceğini anlamadığıdır. Yapması gereken şey, ilk başta gecikmeye tam olarak neyin sebep olduğunu bulmak ve daha sonra bir yazılım projesi sırasında kaçınılmaz olacak olan zamanlama risklerini etkin bir şekilde yönetmek için bir süreci uygulamaya koymaya başlamaktır.

ASLA hiçbir durumda yöneticime bir takvimi garanti eden bir sözleşme imzalamam. Diğerleri, şartnamelere kilitlenmesini imzaladığını belirtti. Bu bence yeterli değil. Bu, araçlarda veya teknolojide öngörülemeyen zorlukları, eksik veya zayıf tasarımları, diğer ekip üyelerinin performansını vb. Hesaba katmaz.

Bu bir kırmızı bayrak değil, bu silah sınıfı aptallık.

Eğer tahminler ve son tarihler sürekli olarak atılırsa, yapılacak mantıklı şey nedenleri tanımlamak ve süreçleri iyileştirmektir.

Eğer atı suçluyor ve tekmeliyorsanız, çünkü nereye gittiğinizi bilmiyorsunuz, at sizi ısırıp kaçarsa şaşırmayın!

Yönetici talebi ile aynı hizada iken. Tam olarak suçlanmıyor. Eğer bilmediğiniz bir bölgede çalışıyorsanız, "Bilmiyorum" demekte yanlış bir şey yoktur. "Bilmiyorum" un tamamen kabul edilebilir bir cevap olduğunu fark etmem biraz zaman aldı, bu yüzden bu sözleri söylemenin ne kadar acı olduğunu biliyorum. Ama gerçekten bilmiyorsanız o zaman cevap budur. Ve eğer onlara yalvarırlarsa, Sears (Uzun) Kulesi gibi uzun boylu bir yığın yapmak için kaç para harcayacağına dair bir tahmin yapmalarını isteyin. Ve size, harcadıkları her kuruşa ödeme yapan bir sözleşme imzalamaya hazırlar mı?

Maaşına değer herhangi bir Proje Yöneticisi, bazı şeylerin bir e-tabloya hoş ve hoş görünmediğini bilmelidir. Bazen işler bittiğinde yapılır. Bence ne kadar yaptığınız konusunda ilerleme vererek iyi gidiyorsunuz. Numara güncellemelerini vermeyi bırak.

Bir başka uygulama da büyük görevi daha küçük ve tahmin edilebilir birimlere bölmektir. Bu alıştırma, yapmanız gerekenleri daha iyi anlamanıza yardımcı olacaktır. Sırasıyla görevleri yıkma ve gizli gereksinimleri keşfetme ipuçları için Steve McConnell'in Yazılım Tahmini ve Stephen Withall'ın Yazılım Gereksinimleri Modellerine göz atın .

Tahminen kalçadan ateş etme. Yıkmak için zaman ayırın. Çok sayıda küçük görevi tahmin etmek size daha iyi bir genel tahminde bulunacaktır (ortalamaların yasası nedeniyle, tahminlerinizin bir kısmı altında olacaktır, ancak bazıları sona erecek ve bunlar birbirlerini tartmaya eğilimli olacaktır).

"Proje yöneticinize" danışın: Yazılım veya son teslim tarihi mi satıyoruz?

Ben bir proje yöneticisiyim ve bir programcayım :-) Pek çok PM'nin endüstri dışından nasıl geldiği ve üretim hattı modeline uygun olmayan hiçbir şeyi yapamayacağı konusunda uzun süredir devam edebilirim ... ama ben olmaz, burada değil. Bunun yerine, gerçekte ne yapılması gerektiği konusunda uzun bir polemik (Bay Mod, eğer çok uzunsa onunla ne yapacağınızı yapın). Burada yapılan yorumlara katılıyorum, bazıları diğerlerinden önce yapmalısınız, ama işte ilk hareketiniz en iyi olacağını düşündüğünüz şey . Oh, ve sorunuza bariz cevap evet, ama bu aşağıda renkli ve ayrıntılı bir dilde detaylandırılmıştır.

Yine de başlamadan önce, Başbakan'ın büyük olasılıkla size keder verdiğini unutmayın, çünkü gıda zincirinde daha ileri bir kişi onlara keder veriyor. Onlar (biz) basit yaratıklarız ... Açıkladığınız durumu önlemenin yolları var - Mike Brown bunu oldukça iyi koruyor. Çalışmaya başlamadan hemen önce 3/4/5 .. saat boyunca bir şeyler yapmakta yanlış bir şey yoktur (bu gerçekleşmezse aslında her türlü alarmın çalması gerekir). Ve bilinmeyen bir bölgeye giriyorsanız, geriye doğru itin ve makul bir tahmin yapabilmek için alanı ve teknolojileri araştırmak için bir hafta isteyin (bunu uygun bir şekilde yapmak isteyeceksiniz, çünkü yeni teknolojinin Don ile öğrenmek ve oynamak istediğinizde sen?) Başbakanınız ve bulunduğunuz yerdeki yönetim bunu anlamıyorsa ... özgeçmişinizi güncelleyin ve en yakın çıkışı arayın, onları kadere bırakarak çok zengin hak ediyorlar. Başbakan'ın böyle bir sözleşmeyi imzalamak için tam zamanlı bir çalışan bulmayı bile düşünmesi kötü bir işarettir ... görebilmemin tek yoluTamamen beceriksiz olmayabilir, ancak proje liderinizle ve sizinle gerçekten akıl oyunları oynuyorlardı (okuduklarımdan bunu doğrudan size getirmediler ve nihayetinde tehdidi takip etmediler). PMing, sonuçta standart kurumsal psikopatınız için bir cennettir. Söylediklerinizden başkalarının sizin için yarasaya girmesi iyi oldu, bu yüzden aşağıdaki tavsiyeler muhtemelen sizin için olumlu sonuçlanacaktı. Konuşmadan daha fazlası olduğu ortaya çıktığında ellerinde bir devrim olacağını hayal ediyorum.

Yani tarif ettiğin asıl duruma / boşluğa , çünkü yine bir yerde, bir yerde olacak (yaklaşık 5 dakika önce ve tekrar başka bir 5, scheduleRepeat ()). Muhtemelen sözleşme aptallığı olmadan, ancak temel hikaye her zaman aynıdır. Bir toplantı düzenleyin (!), Toplantıları severler ;-) herkes sonunda bir şeyler yapıldığı gibi kendilerini arkaya atabilir. ÖNEMLİ:Teknik proje lideri / takım lideri / mimar / tasarım yöneticisini, konuyla zaten ilgilenen ve onlarla birlikte olan toplantı davetiyesine dahil ettiğinizden emin olun. Hiyerarşi ne kadar yüksekse, sizin tarafınızdaki biri için gidebilirsiniz. Çünkü PM'niz bunu görecek ve tasarım yöneticinizi bir eşdeğerle eşleştirmeye çalışacaktır. Olmazsa, aptallar ve zaten kazandınız. Bu kendi içinde genel olarak onları tekrar çizgiye çeker, çünkü şimdi onları yerinde çuvallayabilecek biri tarafından görülebilirler. Seninle oyun oynuyorlarsa, iyiliğe geri dönmene izin verilir.

Toplantıda, neyle uğraştığınızın teknik ayrıntılarını ve bunun neden zaman aldığını öğrenin. Bunu bilmek istemeliler (ve bunu yapmanıza nasıl yardımcı olabilirler), ama üzücü gerçek şu ki, bu gerçekleşmiyor ... Gözleri kafalarına geri dönmeden önce muhtemelen 10 dakikanızı alacaksınız. Şimdi burada yapmak istediğim şey muhtemelen yasal değil ... evet, kontrol ettim, aslında çok yasadışı ve bu kadar uzun süre hapse girmek istemiyorsunuz. Mesele şu ki, proaktif olmak için elinden geleni yapıyorsun ve daha yüksek seviyelere ulaşırsan, acın artık olması gerektiği gibi. İşlerin nasıl oynanabileceği konusundaki kararınızı kullanmak zorunda kalacaksınız, çünkü 'tırmanma' ne olacak. Bulunduğunuz yerdeki liderlik yarı yarıya iyi ise, doğru olanı yapacaklardır. ve sizin de doğru olanı yapın. Olmazsa, o zaman özgeçmişinizi pazarda önceden elde etmiş olsaydınız ... yine de ilk fırsatta bırakacaktınız (ve sonuçta yaptığınız gibi görünüyor). Liderlik iki gruba ayrılacak - ya teknik açıdan anlayışlılar ve anında görüşünüzü görecekler; ya da değiller ve sırıtıp dayanmaktan başka ne yapacaklar? Yaptıklarını yapabilselerdi, çoktan yaparlardı zaten. t ve sırıtmak ve katlanmaktan başka ne yapacaklar? Yaptıklarını yapabilselerdi, çoktan yaparlardı zaten. t ve sırıtmak ve katlanmaktan başka ne yapacaklar? Yaptıklarını yapabilselerdi, çoktan yaparlardı zaten.

Değişen gereksinimler sorununu en sonunda kullanacağınız koz kartınız olarak saklayın ... herkes için bir çıkış görevi görür. Projenin kendisi ve lanet müşteri / paydaş isimlerini boşuna almış olacak. İleriye giden en acısız yol, projede bir tür sıfırlamanın gerçekleşmesi ve belki de PM'in sessizce farklı bir alana atanması olabilir. Mucizeler bazen olur. Eğer sözleşme konusu toplantıda Başbakan tarafından gündeme geldiyse, sözleşme şartlarını dondurmak için gereken şartları yerine getirin - endişelendiğim kadarıyla, kendileriyle köprülerini yaktıkları ve tüm gelişim ekibine başladıkları zaman bu tür akıl oyunları oynamak.

İmzalamadan önce: Kapsamı / gereksinimleri değiştirme - Çevik metodolojiyi benimsemenin en iyi sebeplerinden biri, bu nedenle müşteriler / paydaşlar istedikleri şey hakkındaki fikirlerini değiştirmekten sorumludurlar ...

Ah, başka bir şey: "Bilmiyorum" ifadesinde, her zaman proje ekibimden birinde bir teknoloji uzmanı veya üyenin değerinin nasıl ölçüleceği konusundaki kişisel kriterim olmuştur. Doğrudan yüzünüze söyleyebilecek en iyi insanlar olduğunu biliyorum, çünkü öncelikle derinliklerinin düştüğünü bilen biri asla bunu söyleyemez - onları gerçek yetenekleri olan biri tarafından açıkça ortaya çıkmaya açar Bir kalp atışı. Öte yandan, önden söyleyecek ve söyleyecek birinin, bilinmeyenlerle nasıl başa çıkılacağına dair temel bir planı (bununla birlikte düşünülmemiş olsa bile), böylece 24 saat içinde daha yararlı bir cevap olacak. ve bir hafta içinde daha da iyi bir tane. Apollo 13 Ay'ın karanlık tarafında uçarken, bir sürü "Bilmiyorum" oluyordu.

Evet, özellikle tam zamanlı bir çalışan iseniz, bu bir kırmızı bayrak ortaya çıkarmalıdır. Sözleşmenin koşulları neydi? Son teslim tarihini kaçırsaydın gerçekten kovulur muydun? Yoksa sadece ikramiye kaçırır mısın? Ne yapacaklar?

Bunun ortaya çıkardığı bayrak, yöneticinin yeni / yabancı teknolojilerle ilgili bir projeyi nasıl yöneteceği ve tahmin edilen çabayı doğrudan etkileyen gereklilikleri değiştireceği konusunda hiçbir fikrinin olmamasıdır. Zor zamanlar bazen olurken, durumu bilen bir yönetici çalışanların onları zorlamak için sözleşmeleri imzalatmaya çalışmamalı. Gece geç saatlerde ve aksaklık zamanlarında kötü olacak ama bu muhtemelen kurs için uygun. Ve hala bazen son tarih kayar. Bu gerçekleşir ve bir başkasının yayınladığı gibi, programa uymanın tek yolu zaman çizelgesini korumak için hala yeterli yer kalması için EARLY ON koşullarını dondurmaktır.

Söylediklerinize göre, alarm zilleri birkaç ay geç kaldı. Zamana duyarlı bir projeyi, personelin henüz bilmediği teknolojilere dayandırmak normalde risklidir. Gereksinim toplama ve kapsam yönetimi konularında herhangi bir fikriniz yoksa, bunu yapmak aptallıktır.

Bu, diğer cevaplara katılıyorum dedi. Ayrıca, daha önce yapmadıysanız özgeçmişinizi güncellemek isteyebilirsiniz.

Diğer tüm katılımcılar gibi, bunun da bir kırmızı bayrağı kaldırması gerektiğine daha fazla katılamamıştım.

Başbakan, kalkınma sürecine katılmak istemiyor gibi görünüyor.

Kişisel pratiğimde, detaylı ön spesifikasyonlar, imzalar, tam proje tahmini veya sabit teklifli fiyatlandırma (danışmanlık perspektifinden) ile uğraşmaktan çok uzağa gittim.

Bunun nedeni, Çevik ve Yalın Yazılım gurularının çoğunun hakkında konuştuğu, bu yazılımın sabit bir üretilebilir varlık olmadığı, ancak çoğunlukla keşif süreci olduğu gerçeğidir.

Pek çok insan hala bu fikirle ilgili sorun yaşıyor ve bu benim Başbakanınızın yaptığı gibi. Bu basit bir takas anlaşması ile sonuçlanır.

Sağlam özellikler ve sabit tahminler, değişim maliyetinin yüksek olduğu sistemler için işe yarar. Yüksek katlı bina yapmak gibi. Asansör boşluğunu öne çıkarmayı unuttuysanız, inşa edildikten sonra binayı güçlendirmek gerçekten zor olacaktır. Yüksek değişim maliyeti çok fazla ön planlama, bileşenlerin ve teknolojilerin bilinmeyenlerini öğrenme ve ön denemeler gerektirir. Ancak tüm bu ödevleri yaptıktan sonra, bütçenizi ve maliyetinizi tahmin edebilirsiniz.

Yazılımda insanlar değişimin maliyetinin düşük olduğu fikrine çok alıştılar ve bu nedenle, bir sürüm gördüklerinde bir şeyi değiştirebilmenin avantajlarından faydalanmak istiyorlar, uygulamanın, işin, müşterinin yeni anlayışını kullanıyorlar. devam eden bir temel. Bütün bunlar iyi ve doğru bir şekilde kaldıraç yapıldığında büyük bir fırsat. Tanıştığım ve birlikte çalıştığım çoğu yazılım çalışanı aslında çok fazla zaman harcamaktan ve planlama yapmaktan hoşlanmıyor; çoğumuz (PM dahil) devam eden çekiş görmek istiyoruz. İteratif gelişimin küçük, artımlı işlevsellik bültenleriyle geldiği yer burasıdır. Değişim maliyetinin düşük kalmasını ve teknik borcun kalmasını garantilemek için teste dayalı geliştirme gibi kullanılabilecek başka uygulamalar da vardır .

Bu işi yapmak, her iki taraf arasında bir "sözleşme", ürün sahibi (PM veya müşteriniz veya QA ekibiniz için çevik konuşma) ve geliştiriciler içerir. Geliştiriciler, yalnızca belirtilen yineleme için en önemli olarak öncelik verilen şeyler üzerinde çalışmayı ve bununla sonsuza dek devam etmemeyi kabul eder, ancak tam olarak entegre işlevsellik parçalarını sık sık (örneğin haftalık veya aylık) serbest bırakmaya çalışırlar. Ürün sahipleri, tersine, artan sürümleri sürekli olarak gözden geçirmeyi ve anında geri bildirimde bulunmayı kabul eder. Ayrıca bir sonraki yineleme için öncelikleri belirlemeyi kabul ederler ve bir kez yineleme süresince fikirlerini değiştirmeyeceklerdir.

Anlaşmanın bu ikinci kısmı, Başbakanınızın muhtemelen anlamadığı bir şey. Pek çok geleneksel Başbakan aslında değil. Bazıları, çalışmalarının şartnameyi bıraktıklarında yapıldığını düşünüyor; problemler, alternatifler, daha iyi yollar vs. hakkında duymak istemiyorlar. Bunun dezavantajı, bunun sadece yazılım geliştirme akışına karşı gelmesi değil, aynı zamanda masaya birçok fırsat bırakarak organizasyona da zarar vermesi.

Çevik Manifesto'ya bir göz atın: http://agilemanifesto.org/ Size rezonans verebilir. Okumak için iyi bir kitap da Mary Poppendieck'in "Yalın Yazılım Geliştirme" dir.

İyi şanslar.

Yöneticinin, amirine rapor verdiğinde suçlayacak birini aradığı anlaşılıyor.

Bir 'tahminin' bir 'sabit dönem' ile aynı olduğunu düşünen mantıksız bir yöneticiniz varsa, yapılacak en iyi şey çok cömert bir tahminde bulunup bunu iki katına çıkarmaktır!

Ayrıca, yöneticinin gereksinimlerin tamamen ayrıntılı ve sabit olmasını sağlamaya zorlayın. Bundan sonra yapılacak herhangi bir değişiklik, yeni tamamlanma zamanının proje yöneticisi ile 'resmi bir yeniden müzakere' olmadan ele alınmayacaktır.

Sonunda proje yöneticisi fikri alır ve buna göre planlar.

Bu tür bir şeyle ilgili kişisel deneyimim, proje yöneticisinin fesihinizi kendi suçunuz haline getirirken sizi elden çıkarmak için bir kağıt izi oluşturmaya çalıştığı yönünde. Bu çok kırmızı bir bayrak olur. Kilometreniz elbette biraz değişebilir.

Her yerinde iyi cevaplar var, ama 2 kuruş ekleyeyim.

Olasılığı araştırırsanız, "rastgele değişken" diye bir şey vardır. Bu, değeri bilmediğiniz bir sayıdır, ancak normal (çan eğrisi) dağılımı veya benzeri bir dağılımla bilmediğinizi açıklayabilirsiniz.

Mesele şu ki, iş biraz zaman alacaktır, ancak önceden tahmin edilen herhangi bir tahmin, olumsuz taraf veya pozitif taraflarda, az ya da çok yanlış olur, bu nedenle risk vardır ve birinin riski alması gerekir. Genellikle, eğer insanlar risk alırlarsa, bunun için para alırlar. Sigorta ücrete tabidir.

Danışman olduğum zaman, genellikle sabit fiyatlı bir sözleşmeye karşı bir zaman ve malzeme sözleşmesi imzalama seçeneğim vardı. Zaman ve malzemelerle müşteri riski üstlenir. Sabit fiyatla riske girerim. Sabit fiyatlı bir güvenlik marjı oluşturuyorum, çünkü hedefi tutmazsam kimse kazanamaz.

Sabit bir teslimat tarihi belirlemenizi istemek, özellikle de belirli şartlar olmadan, gerçekte neyi riske attığınızı net olmasa da riski size aktarmaya çalışmak gibi geliyor. Her durumda, tek bir yanıt basitçe cömert bir güvenlik marjı sağlamaktır.

PS Bunu her zaman devlet sözleşmeleriyle görüyorsunuz. Teklifler için ilk talep var, teklifler alınıyor, düşük bir teklif kabul ediliyor ve ardından değişiklik talepleri gelmeye başlıyor, böylece maliyet balonları ve yüklenici suçlanıyor. Müşteri ile müteahhit arasında rakip bir ilişkiden ziyade ekip çalışması ilişkisi varsa, işler daha iyi sonuç verir.

Evet, elbette bu eski patronunuzun deneyimi ve yeterliliği hakkında bir bayrak ortaya çıkarır. Evet, çoğu insanın önerdiği gibi, özgeçmişinizi güncellemek için iyi bir zaman olabilir.

Evet, diğer cevapların ifade ettiği gibi, çoğu durumda bu anlaşmayı imzalamak istemezsiniz. Ancak, imzalamayı düşünebileceğiniz bazı durumlar olabileceğini önermek istiyorum.

Çoğu geliştirici ve yönetici, işlevsellik, son tarih ve bütçe arasındaki sürekli sürtüşmenin farkındadır. Birçoğu aynı zamanda kaliteyi dördüncü bir boyut olarak atayacaktır ("Yarın itibariyle düşük bütçeli, istediğiniz işe yaramayacağını kabul ettiğiniz sürece istediğiniz herhangi bir gereksinim getirebilirim!").

Ancak başka bir boyut daha var: risk. Zamanın yalnızca% 50'sini başarılı bir şekilde vermem gerekiyorsa, tahminlerimi büyük ölçüde düşürebilirim; çok daha yüksek bir teslimat oranına uyacak şekilde döşenmiştir.

Riski çeşitli yollarla ele alabiliriz (ve dolgu tahminleri bunlardan biridir). Yönetici herhangi bir riski kabul etmeye istekli değildir ve riski omuzlarınıza koymak ister. Normalde, tazminat almadığınız sürece ... böyle bir hareketi reddetmelisiniz.

Son tarihinizi, beklenmeyen gecikmelerle başa çıkmak için karşılıklı olarak kabul edilebilir miktarda bir dolgu maddesiyle aday gösterebiliyorsanız ve vurursanız (çok büyük) bir bonusu müzakere edebiliyorsanız ve mali durumu elinizde tutabiliyorsanız, Cezaları (örneğin kovulmak) yapamıyorsanız, bu riski kendiniz kabul etmenin ve sözleşmeyi imzalamanın değerli bir "kumar" olduğunu, gereklilik gerekliliklerini yerine getirmek için uygun hükümler olduğunu görebilirsiniz.

Bu doğrudan aptallık. Nihai hedefin ne olduğunu bilmiyorum, ancak yazılım ürünlerinden sorumlu olan yarı yolda çalışan her proje yöneticisi, tahminlerin tam olarak ne adlandırıldığının farkında olmalıdır: tahminler. Söz vermezler ve yazılım geliştiricilerini tüm enerjilerini tüketmeden ya da “sözlerini” kesmeye zorlamadan böyle bir şey yapamazlar.

Böyle bir sözleşmenin ne kadar saçma olduğunu göstermek istiyorsanız, işte iki öneri olabilir:

a) Projenin, sözleşme yapmadan tahmin edeceğiniz sürenin beş veya on katını aldığı noktaya aşırı değer verin. Proje yöneticisi tahminlerin neden bu kadar yüksek olduğunu soruyorsa, sadece sözleşmenizi yerine getirdiğinizden emin olduğunuzu söyleyin.

b) Bu zaten önerilmiş: Tek bir şartın değişmemesini ve yazım hatalarının düzeltilmesini de içerdiğinden emin olan bir sözleşme isteyin. Tecrübelerime göre, geliştirme sırasında ihtiyaçların bir noktada değişmediği tek bir yazılım projesi yoktur. Proje yöneticisinin sözleşmesini sizden daha fazla ihlal etmesi muhtemeldir.

Proje yöneticisi bu iki öneriden herhangi birini kabul ederse, akıllarından çıkmadıklarından emin olacağınızdan emin olabilirsiniz.

Bu arada, tam zamanlı bir çalışan için bir sözleşme nasıl olsa işe yarar? Diğer ülkelerdeki iş düzenlemeleri hakkında bilgim yok, ancak bir şirkette tam zamanlı çalışan olarak, bir kimsenin sizi son teslim tarihine uymak ve geçerli bir dava açmak için bağlayıcı bir sözleşme imzalamaya zorlayabileceğini sanmıyorum. Elbette, son teslim tarihine uymazsanız size cehennem verebilirler, ancak bunun için bir sözleşmeye ihtiyaçları yoktur. Kimse seni kovamaz ya da daha az para veremezdi. Anlaşılan bonusunuzu en kötü ihtimalle kesebilirler. Bu, diğer ülkelerde farklı olmadığı sürece, ciddiye almanız gereken her şeyden daha fazla boş bir tehdit gibi görünüyor.

Buradaki tahılı karşı geleceğim.

Tarif ettiğiniz durum , özellikle özellikle geç bir projenin / sürümün ardından Mühendislik ekibi düzeyinde olağandışı bir durum değil . Birçok durumda, yönetim ve tüm organizasyon aslında var olabilir kaydoldum belirli çıkış tarihi için ve örgütün diğer parçaları bu tarihten kadar dişli olacak. Yönetim zincirinizde o tarihe vurmak için muazzam bir baskı olabilir.

Genel bir mühendislik sürecinin geldiği yer burasıdır. Şelale modelini muhtemelen duymuşsunuzdur. Orada diğer modeller vardır, ama hepsi nihai amacı sürekli bir şeyler sunmaktır zaman beklenen ve ihtiva edilmektedir neyi kabul edildi. İşlevsel özellikler, tasarımlar, görev listeleri vb. Hepsi bunu öngörülebilir bir işlem haline getirmeye gider. İletişim, risk analizi ve (dediğiniz gibi) programla ilgili beklentileri düzenli olarak güncellemek, sürprizleri azaltır ve en kısa zamanda planların düzenlenmesi için bilgilerin kullanılabilir olmasını sağlar. Ve evet, özellikler eklendiğinde veya kaldırıldığında plan üzerinde ayarlamalar yapılmalıdır.

Çalıştığım takımların bazılarında, tahminlerime imzalı taahhütler gibi davranmakta tereddüt etmem, ancak bu takımların ve yönetimin kalitesini yansıtan ve tahmin etme konusunda özel bir beceri içermemektedir. Bir takım istekli bir sözleşme imzalamak zamanında teslim için iyi çalışma ekibinin bir göstergesi değil, bir kırmızı alarmdır.

Kendini onun yerine koy ve ne motive ettiğini anlamaya çalış derim. Yöneticiler / Muhasebeciler adaylarından ne olduğunu ve işlerin nasıl yürüdüğünü doğrulamak için bir sayıya ihtiyaçları var.

Kurul odasında son başvuru tarihlerini değiştirmek için gülünç olmak, çok fazla ölü çizgiyi kaçırmak olabilir, kilitlenmeleri için en basit yolu denedi. Bana bir numara verin ve imzalayın! Diğer tarafta olmak, sadece sana karşı bir şey olduğunu algılayabilirdi. Tahminler yapmak ve düzeltilmeleri gerektiğinin farkına varmak, onun için daha yararlı olduğu şeydir. Talebi neyin motive ettiğini ve karşılaştığı asıl sorunun ne olduğunu anlarsanız, ona ve kendinize yardımcı olabilirsiniz. Programcılar olarak problemleri çözeriz. Bu durum farklı değil, problemini anlayın ve çözün ve en iyi arkadaşınız olacak. Yapılması gereken çok iş var, kimsenin kişisel bir satıcı satın almak için zamanı yok! Çalışmalarında yardıma ihtiyacı var, en basit çözüm birinin kağıt imzalamasıydı! Muhtemelen bunu aptallar için bir yönetim kitabından, “İşçilerinizin imzalamasını ve bir sayı için hesap verebilir şekilde yardım almasını sağlayın” kitabından aldı. Komik ama üzgün

"Her ikisi de donmuşsa, suda yürümek ve bir spesifikasyondan yazılım geliştirmek kolaydır."

-Edward V. Berard

Gereksinimleriniz değişiyorsa, ilk tahminlerinizin doğru olmasını beklemeniz makul değildir. Evet, bu bir kırmızı bayrak olmalı.

Sözleşme son tarihi karşılamamak için bir ceza belirtiyor mu? Olmazsa, hiç sorun değil - sadece o zamanki bilgilerinize dayanarak bir tahminde bulunuyorsunuz.