Daha önceki bir işte, bir proje yöneticisi (PM), üzerinde bulunduğum bir projedeki kodun teslim süresinden memnun değildi. Proje liderim tarafından, PM bana zaman tahminlerimi kilitlemek için bir sözleşme imzalamayı düşündüğünü söyledim Görevler ve teslim tarihleri için verdim.
Projedeki durum, yeni teknolojiler, kod tabanı, kodlama standartları ve değişime eğilimli gereksinimlerle çalışmamızdı. Yeni şeyler öğreniyordum ve bunları değişmeye devam eden gereksinimler için elimden gelenin en iyisini uyguluyordum. İterasyonlar boyunca gereksinimler 2-3 kat arttı, tahminim tamamlanacak tahminim yaklaşık 5-8 kat arttı. Değişmeyen tek şey tahminler ve teslim tarihleri oldu.
Evet, en son teslim tarihlerini kaçırdım. Ve tüm geliştirme ekibinde kimsenin gerçekten yardım edemeyeceği çok yeni teknolojiler üzerinde çalışıyordum çünkü onlar bunu bilmiyorlardı. En azından kolay değil.
O zaman bana PM numaralarının toplanmasını istedi - ve böylece her zaman zamanında çalışma kodu teslim olacağını "sağlamak" için bir sözleşme imzalamak istedi gibi görünüyordu. İmzalı bir sözleşmeyle PM zamanında teslim edemezsem 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 açmalı mı? Bir yöneticinin, bir yazılım geliştiricisinin imzalı bir sözleşme ile zaman tahminlerini kilitlemesi yaygın bir uygulama mıdır? Veya bu durumda, deneyin.
Unutmayın, bağımsız bir danışman değil tam zamanlı çalıştım.
Güncelleme: Haftada yeni tahminler verdiğimi eklemek istiyorum, ancak orijinal tahminler ve teslimat tarihleri neydi? PM düzeltildi.
Sorum şu, bu yönetici hakkında kırmızı bir bayrak mı çıkarmalı?
Evet . Bu, özgeçmişinizi/CV'nizi güncellemenin ve yeni bir iş aramanın zamanı geldiğini gösterir. Veya yöneticinizin 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 çaba tahmini her zaman zordur. Özellikle mesleğimiz aşırı iyimserlikle dolu olduğu için. Gelecekte tahminlerde yardımcı olabilecek bazı tahmin sistemleri vardır, ancak kendinizden geçmiş istatistikleri toplamaları gerekir. Biri PSP . Diğeri İşlev Noktaları . Pek çok geliştirici ikisini de sevmez ve her ikisine de karşı çok güçlü görüşler bulacaksınız.
Zaman ve çabayı tahmin etmedeki temel zorluk, tahmin sezgisel yöntemlerimizde geri bildirim eksikliğidir. Anahtarlardan biri, tahminin ne olduğunu düşündüğünüzü ve tahmin etmek için kullandığınız parametreleri yazmaktır. Ardından, gerçekte ne yaptığınıza bağlı olarak, bunu ne yapacağınızı düşündüğünüzle karşılaştırın. Tahmin parametrelerinizi değiştirmek için bunu kullanın. Mühendislikte buna " feedback " diyoruz.
Evet, bu kesinlikle alarm zilleri çalmalıdır.
Ben kişisel eğlence için pozisyonda olsaydı, ben müdür tüm gereksinimleri dondurma bir sözleşme imzalamak isterdi. Yönetici muhtemelen kefalet olacağını hayal. Sonra giderdim.
Bu basit. Yöneticinize, spesifikasyonu kilitlemek için ne zaman imzalayacağını tahmin etmek için zaman tahmininizi kilitleyeceğinizi söyleyin. Çünkü kesin olarak bilinmeyen bir şey için tahmin sağlayamazsınız. Başlamadan önce tam proje özellikleri, değişiklik yok - ve zamanında bitirebilirsiniz :)
Şartname sözleşmesinde yapılan bir değişiklik geçersizdir. Muhtemelen şey ilk gününüzde 10 dakika sonra geçersiz olacaktır :)
Evet, bu bir kırmızı bayrak. Size söylediği şey, yöneticinin yazılım projelerinde riski nasıl yöneteceğini anlamadığıdır. Yapması gereken, ilk etapta gecikmeye tam olarak neyin neden olduğunu bulmak ve daha sonra bir yazılım projesi sırasında kaçınılmaz olacak program risklerini etkili bir şekilde yönetmek için bir süreci uygulamaya başlamaktır.
ASLA hiçbir koşulda bir programı garanti eden müdürümle sözleşme imzalamam. Diğerleri, spesifikasyonlarda bir kilitlemeyi imzaladığını belirtti. Bence bu yeterli değil. Bu, araçlar veya teknoloji, eksik veya zayıf tasarımlar, diğer ekip üyelerinin performansı vb. İle ilgili öngörülemeyen zorlukları açıklamaz.
Bu kırmızı bir bayrak değil, bu silah sınıfı aptallık.
Tahminler ve son tarihler sürekli olarak uçurulursa, yapılacak rasyonel şey nedenleri belirlemek ve süreçleri iyileştirmektir.
Nereye gittiğini bilmediğin için atı suçluyorsun ve atıyorsan, at seni ısırır ve kaçarsa şaşırma!
Müdür onun talebi ile çizgi dışındayken. Tam olarak suçlanmıyor. Tamamen yabancı bir bölgede çalışıyorsanız, "Bilmiyorum" demenin yanlış bir yanı yok. "Bilmiyorum" un mükemmel kabul edilebilir bir cevap olduğunu fark etmem biraz zaman aldı, bu yüzden bu kelimeleri söylemenin ne kadar acı çektiğini biliyorum. Ama eğer gerçekten bilmiyorsanız, cevap budur. Ve eğer bunlardan saparlarsa, onlardan Sears (Willis yapmak) Kulesi kadar yüksek bir yığın yapmak için kaç pennies alacağını tahmin etmelerini isteyin. Ve size her kuruşunu ödeyen bir sözleşme imzalamaya istekli olacaklar mı?
Maaşına değer herhangi bir Proje Yöneticisi, bazı şeylerin bir e-tabloya Güzel ve hoş uymadığını bilmelidir. Bazen işler bittiğinde yapılır. Ne kadar yaptığınız konusunda ilerleme sağlayarak başarılı olduğunuzu düşünüyorum. Numara güncellemelerini vermeyi bırak.
Başka bir alıştırma, büyük görevi daha küçük, daha tahmin edilebilir birimlere bölmektir. Bu egzersiz, ne yapmanız gerektiğini de daha iyi anlamanıza yardımcı olacaktır. Görevleri dağıtma ve gizli gereksinimleri keşfetme ipuçları için Steve McConnell'in Yazılım Tahmini ve Stephen Withall'ın Yazılım Gereksinimleri Kalıpları konusuna bakın.
Bir tahminle kalçadan ateş etmeyin. Yıkmak için zaman ayırın. Çok sayıda küçük görevi tahmin etmek size daha iyi bir genel tahmin verecektir (ortalamalar kanunu nedeniyle bazı tahminleriniz altında olacaktır, ancak bazıları bitecek ve birbirlerini tartmaya eğilimlidirler) büyük görev.
"Proje yöneticinize" sorun: Yazılım mı yoksa teslim tarihi mi satıyoruz?
Ben bir proje yöneticisiyim ve bir programcıyım :-) Çoğu PM'nin endüstri dışından nasıl olduğu ve üretim hattı modeline iyi uymayan bir şeyle başa çıkamadığım uzun bir süre devam edebilirim ... olmaz, burada değil. Bunun yerine, aslında ne yapacağınıza dair uzun bir polemik (Bay Mod, çok uzunsa onunla ne yapacağınızı yapın). Burada yapılan yorumlara katılıyorum, bazıları diğerlerinden önce yapmalısın, ama işte ilk hamlenin en iyi olacağını düşünüyorum. Oh, ve sorunuzun açık cevabı evet, ancak bu aşağıda renkli ve ayrıntılı bir dilde detaylandırılmıştır.
Yine de başlamadan önce PM büyük olasılıkla size keder veriyor, çünkü gıda zincirinin üstündeki bir başkası onlara keder veriyor.) (Biz) basit yaratıklar ... tarif ettiğiniz durumdan kaçınmak için - Mike Brown bunu oldukça iyi bir şekilde kapsıyor. 3/4/5 .. saat boyunca bir şey üzerinde çalışmanın yanlış bir yanı da yok. Bilinmeyen bir bölgeye gidiyorsanız, geri itin ve mantıklı bir tahmin yapabilmek için alanı ve teknolojileri araştırmak için bir hafta isteyin (bunu doğru yapmak isteyeceksiniz çünkü yeni teknolojinin öğrenmesini istiyorsunuz = PM ve bulunduğunuz yerdeki yönetim bunu anlamıyorsa ... özgeçmişinizi güncelleyin ve en yakın çıkışı arayın, onları çok zengin bir şekilde hak ettikleri kadere bırakarak PM tam zamanlı bir çalışanın kötü bir kötü sig gibi bir sözleşme imzalamasını bile düşünebilir. n ... tamamen beceriksiz olamayacaklarını görebilmemin tek yolu, proje liderinizle gerçekten akıl oyunları oynaması ve (okuduğum kadarıyla bunu doğrudan size vermediler ve sonunda tehdidi takip etmediler). PMing, her şeyden önce standart kurumsal psikopatınız için bir cennettir. Başkalarının sizin söylediklerinizden sizin için yarasaya girmesi iyi oldu, bu nedenle aşağıdaki tavsiye muhtemelen sonunda sizin için pozitif çıktı. Konuşmaktan daha fazlası olduğu ortaya çıkarsa ellerinde bir devrim yaşayacaklarını hayal ediyorum.
Yani açıkladığınız gerçek duruma/deliğe, çünkü birisine, bir yere (yaklaşık 5 dakika önce ve yine başka bir 5, scheduleRepeat () gibi) tekrar olacak. Muhtemelen sözleşme aptallığı olmadan, ancak temel hikaye her zaman aynıdır. Bir toplantı (!) Düzenleyin, toplantıları severler ;-) Herkes aslında bir şey yapıldığı gibi sonunda arkada patlayabilir. ÖNEMLİ: Teknik proje liderinizi/ekip liderinizi/mimarı/tasarım müdürünüzü, konuyla zaten ilgilenmiş ve onları ele geçirmiş olan toplantı davetine dahil ettiğinizden emin olun. Hiyerarşi ne kadar yüksek olursa, 'tarafınızdaki' biri için gidebilirsiniz, o kadar iyidir. Çünkü PM bunu görecek ve tasarım yöneticinizi bir eşdeğeri ile eşleştirmeye çalışacaksınız. Değilse, aptallar ve zaten kazandınız. Bu kendi içinde onları tekrar sıraya çekecektir. , çünkü şimdi muhtemelen onları yerinde çuval edebilecek biri tarafından görülebilirler.Sizinle oyun oynuyorlarsa, iyiliği iade etmenize izin verilir.
Toplantıda, neyle uğraştığınızın ve neden bu kadar zaman aldığının teknik ayrıntılarını gözden geçirin. Bunu bilmek istiyorlar (ve bunu yapmanıza nasıl yardımcı olabilirler), ama üzücü gerçek şu ki bu gerçekleşmiyor ... muhtemelen gözleri başlarına geri dönmeden önce 10 dakika alacaksınız. Şimdi burada yapmak isteyeceğim şey yasal değil ... evet, kontrol ettim, aslında oldukça yasadışı ve uzun süre hapse girmek istemiyorsun. Mesele şu ki, proaktif olmak için en iyi çabayı göstermiş olursunuz ve eğer daha üst seviyeleriniz varsa, acınız artık onlarındır ... olması gerektiği gibi. İşlerin nasıl oynayabileceğine dair yargınızı kullanmanız gerekecek, çünkü 'yükselme' olacak. Bulunduğunuz yerdeki liderlik yarı iyi ise, doğru olanı yapacak ve sizin de doğru olanı yapacaklardır. Değilse, o zaman önceden piyasada özgeçmişiniz olurdu ... yine de ilk fırsatta ayrılacaksınız (ve sonuçta yaptığınız gibi görünüyor). Liderlik iki gruba ayrılacak - ya teknik olarak bilgili ve anında bakış açınızı görecekler; ya da değiller ve sırıtmak ve taşımak dışında bu konuda ne yapacaklar? Yaptıklarınızı yapabilirlerse, bunu zaten yapıyorlardı.
Sonunda kullanmak için koz kartınız olarak değişen gereksinimler sorununu saklayın ... herkes için bir çıkış görevi görecektir. Projenin kendisi ve lanet olası müşteri/paydaşın adı boşuna olacaktır. En acısız yol, projede bir tür sıfırlamanın gerçekleşmesi ve belki de PM sessizce farklı bir alana yeniden atanması olacaktır. Başbakan tarafından toplantıda yükseltilmiş, sonra karşı sözleşme talebini dondurmak gereksinimleri ile geri - endişelendiğim kadarıyla onlar zaten seninle köprüleri yaktılar ve bu tür zihinleri oynamaya başladığında tüm geliştirme ekibine oyunlar.
Çıkış yapmadan önce: Değişen kapsam/gereksinimler - Çevik metodolojiyi benimsemenin en iyi nedenlerinden biri, bu nedenle müşteriler/paydaşlar istediklerine dair fikirlerini değiştirmekten sorumludurlar ...
Oh, başka bir şey: "Bilmiyorum" ifadesinde, her zaman proje takımlarımdan birinde diğer bir teknoloji uzmanının veya üyenin değerini nasıl ölçeceğime dair kişisel ölçütüm oldu. Doğrudan yüzünüze en iyisi olduğunu söyleyebilen tek kişi buluyorum, öncelikle derinliklerinin dışında olduğunu bilen biri asla bunu söylemeyecektir - onları gerçek yetenekleri olan bir kişi tarafından açıkça maruz kalmaya açar. bir kalp atışı. Öte yandan, ön plana çıkacak ve söyleyecek birinin, bilinmeyenlerle nasıl başa çıkılacağına dair temel bir planı da olacaktır (24 saat içinde daha faydalı bir cevap olacak, ve bir hafta içinde daha da iyi. Apollo 13, Ay'ın karanlık tarafında uçarken, bir sürü "Bilmiyorum" vardı. Eğer bu tür şeylerle başa çıkamazsan, yanlış oyundasın.
Evet, özellikle tam zamanlı bir çalışansanız, kırmızı bir bayrak kaldırmalıdır. Sözleşmenin koşulları nelerdi? Son başvuru tarihlerini kaçırırsanız gerçekten kovulur muydunuz? Yoksa sadece bir bonusu kaçırır mısın? Ne yaparlardı?
Bunun ortaya koyduğu bayrak, yöneticinin yeni/bilinmeyen teknolojilerle uğraşan bir projeyi ve tahmini çabayı doğrudan etkileyen değişen gereksinimleri nasıl yöneteceği hakkında hiçbir fikre sahip olmamasıdır. Zor zamanlar bazen gerçekleşse de, durumu bilen bir yönetici, çalışanların bunları uygulamak için sözleşme imzalamalarını sağlamaya çalışmamalıdır. Geç gece ve crunch kez kötü olacak ama bu muhtemelen kurs için eşit. Ve yine de bazen son tarih kayar. Bu olur ve başka birinin yayınladığı gibi, programa sadık kalmanın tek yolu, zaman çizelgesini tutmak için hala yeterli alan olması için ERKEN AÇIK gereksinimleri dondurmaktır.
Söylediklerinden, alarm zilleri birkaç ay çok geç. Zamana duyarlı bir projeyi, personelin zaten aşina olmadığı teknolojilere dayandırmak normalde risklidir. Gereksinim toplama ve kapsam yönetimi hakkında herhangi bir fikriniz yoksa bunu yapmak aptalca.
Diğer cevaplara katılıyorum dedi. Ayrıca, henüz yapmadıysanız özgeçmişinizi güncellemek isteyebilirsiniz.
Diğer tüm katılımcılar gibi, bunun kırmızı bir bayrak açması gerektiği konusunda daha fazla anlaşamadım.
PM geliştirme sürecine dahil olmak istemiyor gibi görünüyor.
Kişisel uygulamamda uzun zamandır ayrıntılı ön özellikler, imzalar, tam proje tahmini veya sabit teklif fiyatlandırması (danışmanlık perspektifinden) ile uğraşmaktan uzaklaştım.
Bunun nedeni, Çevik ve Yalın Yazılım gurularının çoğunun bahsettiği, yazılımın sabit üretilebilir bir varlık olmadığı, ancak çoğunlukla bir keşif süreci olduğu gerçeğidir.
Birçok insan hala bu kavramla ilgili sorun yaşıyor ve kulağa PM da yaptı.) Basit bir takas anlaşması geliyor.
Sağlam ön özellikler ve sabit tahminler, değişim maliyetinin yüksek olduğu sistemler için çalışır. Yüksek bir bina inşa etmek gibi. Asansör şaftlarını öne çıkarmayı unuttuysanız, inşa edildikten sonra binayı güçlendirmek gerçekten zor olacaktır. Yüksek değişim maliyeti, çok sayıda ön planlama, bileşen ve teknolojilerin bilinmeyenlerini öğrenme ve ön deneme gerektirir. Tüm bu ödevleri ancak bir kez yaptıktan sonra bütçeyi ve maliyeti tahmin edebilirsiniz.
Yazılımda insanlar değişim maliyetinin düşük olduğu fikrine çok alıştılar ve bu yüzden bir sürüm gördüklerinde bir şeyleri değiştirebilmekten, uygulamanın, işletmenin, müşterinin yeni anlayışını dahil etmekten faydalanmaktan hoşlanıyorlar. devam ediyor. Tüm bunlar doğru kullanıldığında iyi ve büyük bir fırsattır. Tanıştığım ve çalıştığım çoğu yazılım insanı aslında çok fazla zaman planlaması veya araştırması yapmaktan hoşlanmıyor; çoğumuz (PM'ler dahil) sürekli çekiş görmek istiyoruz. Bu, yinelemeli gelişimin küçük, artımlı işlevsellik sürümleriyle geldi. Değişim maliyetinin düşük düşük ve teknik borç içerdiğini garanti etmek için test odaklı geliştirme gibi kullanılabilecek başka uygulamalar da vardır.
Bu işi yapmak her iki taraf arasında bir "sözleşme" içerir, ürün sahibi (Agile PM veya müşteriler veya KG ekibi) ve geliştiriciler için konuşur.Geliştiriciler yalnızca öncelikli olan şeyler üzerinde çalışmayı kabul eder bu yinelemede en önemlisi ve bununla sonsuza dek sürmemek, ancak tam entegre işlevsellik parçalarını sık sık (örneğin haftalık veya aylık) yayınlamaya çalışmak Ürün sahipleri, tersine, sürekli sürümleri sürekli olarak gözden geçirmeyi ve İstem geri bildirimi sağlamayı kabul ederler. ayrıca bir sonraki yineleme için öncelikleri belirlemeyi ve bir kez yineleme süresi boyunca zihinlerini değiştirmemeyi kabul eder.
Anlaşmanın bu ikinci kısmı PM muhtemelen anlayamayacağınız bir şeydir. Pek çok geleneksel Başbakan aslında bilmiyorlar. Sorunları, alternatifleri, daha iyi yolları, vb. duymak istemiyorum. Bunun dezavantajı, sadece yazılım geliştirme akışına karşı olmakla kalmaz, aynı zamanda masaya birçok fırsat bırakarak organizasyona zarar verir.
Çevik Manifesto'ya bir göz atın: http://agilemanifesto.org/ Sizinle rezonansa girebilir. Okumak için iyi bir kitap da Mary Poppendieck'in "Yalın Yazılım Geliştirme"
İyi şanslar.
Yönetici, amirine rapor verdiğinde suçlanacak birini arıyor gibi görünüyor.
Bir 'tahmin'in' sabit bir dönem 'ile aynı olduğunu düşünen mantıksız bir yöneticiniz varsa, yapılacak en iyi şey çok cömert bir tahmin dönemi düşünmek ve sonra iki katına çıkarmaktır!
Ayrıca, yöneticiyi gereksinimlerin tamamen ayrıntılı ve sabit olmasını sağlamaya zorlayın. O andan itibaren yapılacak herhangi bir değişiklik, yeni tamamlanma süresinin proje yöneticisi ile 'resmi bir görüşme' yapılmadan 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 feshinizi kendi hatanız yaparken sizi atmak için bir kağıt izi kurmaya çalışmasıdır. Bu onu çok kırmızı bir bayrak yapar. Kilometreniz elbette biraz değişebilir.
Her yerde iyi cevaplar, ama 2 sentimi ekleyeyim.
Hiç olasılık incelerseniz, "rastgele değişken" diye bir şey vardır. Bu, değerini bilmediğiniz bir sayıdır, ancak normal (çan eğrisi) dağılımı veya başka bir dağıtım gibi bilmediğinizi bir dağılımla tanımlayabilirsiniz.
Mesele şu ki, iş biraz zaman alacaktır, ancak önceki herhangi bir tahmin, olumsuz tarafta veya olumlu olarak, az ya da çok yanlış olacaktır, bu nedenle risk vardır ve birisinin riski alması gerekir. Genellikle insanlar risk alırlarsa bunun bedelini alırlar. Sigorta maliyeti.
Bir danışman olduğumda, genellikle sabit fiyatlı bir sözleşmeye karşı zaman ve malzeme sözleşmesi imzalama seçeneğim vardı. Zaman ve malzemelerle müşteri riski üstlenir. Sabit fiyatlı, riski taşıyorum. Sabit fiyatlı bir güvenlik marjı oluşturuyorum çünkü hedefi karşılayamazsam kimse kazanamaz.
Özellikle sabit gereksinimler olmadan sabit bir teslim tarihi vermenizi istemek, gerçekte neyi riske attığınız net olmasa da riski size aktarmaya çalışmak gibi geliyor. Her durumda, bir cevap basitçe gerçekten cömert bir güvenlik marjı koymaktır.
Not; Bunu hükümet sözleşmeleriyle her zaman görüyorsunuz. Teklifler için bir ilk istek var, teklifler alınıyor, düşük bir teklif kabul ediliyor ve daha sonra değişiklik talepleri gelmeye başlıyor, bu yüzden maliyet balonları ve yüklenici suçlanıyor. Müşteri ile yüklenici arasında, ters olandan ziyade bir ekip çalışması ilişkisi varsa işler daha iyi çalışır.
"Her ikisi de donmuşsa, su üzerinde yürümek ve bir spesifikasyondan yazılım geliştirmek kolaydır."
İleri V. Berard
Gereksinimleriniz değişiyorsa, ilk tahminlerinizin doğru olmasını beklemek mantıksızdır. Evet, bu bir kırmızı bayrak olmalı.
Evet, elbette bu eski patronunuzun deneyimi ve yetkinliği hakkında bir bayrak getiriyor. Evet, çoğu insanın önerdiği gibi, CV'nizi güncellemek için iyi bir zaman olacaktır.
Evet, diğer cevapların belirttiği gibi, çoğu durumda bu sözleşmeyi 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ünmenin farkındadır. Birçoğu kaliteyi dördüncü bir boyut olarak da aday gösterecektir ("Çalışmayacağını kabul etmeye istekli olduğunuz sürece yarın düşük bir bütçe için istediğiniz herhangi bir gereksinimi karşılayabilirim!")
Ancak başka bir boyut daha var: risk. Zamanın sadece% 50'sini başarıyla sunmam gerekirse tahminlerimi son derece düşürebilirim; çok daha yüksek bir teslimat oranını işlemek için doldurulur.
Riske çeşitli şekillerde hitap edebiliriz (ve dolgu tahminleri bunlardan biridir). Yönetici herhangi bir riski kabul etmek istemiyor ve riski omuzlarınıza atmak istiyor. Normalde, iyi bir telafi edilmediğiniz sürece böyle bir hareketi reddetmelisiniz.
Son tarihinizi, beklenmedik gecikmelerle başa çıkmak için karşılıklı olarak kabul edilebilir miktarda dolgu ile belirleyebiliyorsanız ve vurursanız (çok büyük) bir bonusu müzakere edebiliyorsanız ve cezalar (örneğin kovulmak gibi) yapamıyorsanız, bu riski kendiniz kabul etmenin ve sözleşmeyi imzalamanın faydalı bir "kumar" olduğunu görebilirsiniz.
Kendinizi onun yerine koyun ve bunu neyin motive ettiğini anlamaya çalışın diyorum. Yöneticiler/Muhasebecilerden, neler olup bittiğini ve nasıl gittiğini haklı çıkarmak için bir sayıya ihtiyaçları vardır.
Yönetim kurulunda son tarihleri kaydırmak için alay konusu olmak, çok fazla ölü çizgiyi kaçırmak, onları kilitlemenin mümkün olan en basit yolunu denedi. Bana bir numara verin ve burada imzalayın! Diğer tarafta olmanız, bunun sadece size karşı bir şey olduğunu algılayabilirdi. Ne zaman tahminlerde bulunmak ve ayarlanması gerektiğini fark etmek onun için daha yararlı olduğu şeydir. İsteği 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 sorunları çözüyoruz. Bu farklı değil, problemini anlıyor ve çözüyor ve en iyi arkadaşınız olacak. Kimsenin kişisel kan davası planlamak için vakti olmadığı için yapılacak çok iş var! Çalışması için yardıma ihtiyacı var, en basit çözüm birisinin bir kağıt imzalamasını sağlamaktı! Muhtemelen bunu aptallar için bir yönetim kitabından aldı, "İşçilerinizi imzalayın ve bir sayıdan sorumlu olun." Komik ama üzgün
Bu düz aptallık. Nihai hedefin ne olduğunu bilmiyorum, ancak yazılım ürünlerinden sorumlu her yarım proje yöneticisi, tahminlerin tam olarak adlandırıldıkları şey olduğunu bilmelidir: tahminler. Söz vermiyorlar ve yazılım geliştiricilerini tüm enerjilerini tüketmeden ya da yine de "vaatlerini" kırmaya zorlamadan böyle yapılamazlar.
Böyle bir sözleşmenin ne kadar saçma olduğunu göstermek istiyorsanız, iki öneri olabilir:
a) Projenin sözleşmesiz tahmin ettiğiniz sürece beş veya on kat daha fazla aldığı noktayı fazlasıyla abartın. Proje yöneticisi tahminlerin neden bu kadar yüksek olduğunu sorarsa, sadece sözleşmenizi yerine getirdiğinizden emin olun.
b) Bu zaten önerilmişti: Tek bir şartın değişmediğinden ve yazım hatalarının düzeltilmesini içerdiğinden emin olan bir sözleşme isteyin. Deneyimlerime göre, geliştirme sırasında gereksinimlerin bir noktada değişmediği tek bir yazılım projesi yoktur. Proje yöneticisinin sözleşmelerini sizden daha fazla ihlal etmesi muhtemeldir.
Proje yöneticisi bu iki öneriyi kabul ederse, onların aklından çıkmadığından emin olabilirsiniz.
Bu arada, tam zamanlı bir çalışan için sözleşme nasıl yapılır? Diğer ülkelerdeki çalışma yönetmeliklerini bilmiyorum, ancak bir şirkette tam zamanlı çalışan olarak, hiç kimsenin sizi bir son teslim tarihine uymak ve geçerli bir davaya sahip olmak için bağlayıcı bir sözleşme imzalamaya zorlayabileceğini düşünmüyorum. Elbette, son teslim tarihine uymamanız durumunda 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ü şekilde kesebilirler. Yani, bu diğer ülkelerde farklı olmadıkça, ciddiye almanız gereken her şeyden çok boş bir tehdit gibi görünüyor.
Buradaki tahıllara karşı gideceğim.
Açıkladığınız durum, Mühendislik ekip düzeyinde, özellikle de geç bir proje/sürümden sonra olağandışı değil. Çoğu durumda, yönetiminizin ve tüm kuruluşunuzun belirli bir çıkış tarihi için kaydolmuş değeri olabilir ve kuruluşun diğer bölümleri bu tarih için hazırlanır. Yönetim zincirinizde bu tarihe ulaşmak için büyük bir baskı olabilir.
Burası genel bir mühendislik sürecinin devreye girdiği yerdir. Muhtemelen şelale modelini duymuşsunuzdur. Başka modeller de var, ancak hepsinin nihai hedefi tutarlı bir şekilde bir şey sunmaktır ne zaman beklendiği ve içerdiği ne kabul edildi. İşlevsel özellikler, tasarımlar, görev listeleri vb. İletişim, risk analizi ve (dediğin gibi) programla ilgili beklentileri düzenli olarak güncellemek, planların ayarlanabilmesi için sürprizleri azaltır ve bilgileri mümkün olan en kısa sürede kullanıma sunar. Ve evet, özellikler eklendiğinde veya kaldırıldığında planda ayarlamalar yapılmalıdır.
Çalıştığım bazı ekiplerde tahminlerime imzalı taahhütler olarak davranmakta tereddüt etmem, ancak bu, ekiplerin ve yönetimin kalitesini yansıtır ve tahmin etme konusunda herhangi bir beceriyi yansıtmaz. A takım istekli bir sözleşme imzala zamanında teslim etmek, kırmızı bayrak değil, iyi çalışan bir ekibin göstergesidir.