Patron her zaman gereksinimler ve genel tasarım hakkındaki büyük kararları ertelerse ne yapmalı?

Yeni bir projeye başlarken, patronum her zaman sabit kararlar almaktan kaçınır. Genellikle şöyle diyor: tamam, bir şeyler yazmaya başlayın ve mümkün olduğunca genel olun. İşiniz bittiğinde nasıl devam ettiğimize bakıyoruz. Onun argümanı temelde asla bilemeyeceğiniz ve "çevik gelişim" dir.

Soruyu olabildiğince genel tutmak için: patronunuz karar vermek istemezse ne yaparsınız?

Sadece ona sadık kalın ve birkaç hafta sonra yeniden düzenleme ve kısmi yeniden yazma işlemine tabi tutulabilecek kodlar mı yazmalısınız? Ya da patron en az birkaç karar alana kadar tartışmaya devam etmeli mi? Bu şu anki stratejim aşağı yukarı. Çünkü bu bir fizik yasası gibi, bir noktada bir şeylerin teslim edilmesi gerekiyor. Patronun patronu sonuçları görmek istediği için ya da bir noktada işler saçma hale geldiği için.

Ayrıca patronumun neredeyse her şeyi eleştirdiğini de gözlemliyorum. Hatta kendi önerilerine dayanarak ...

Prototipler oluşturun

İlk başta hiçbir şey yapmayan ekranlar çizmeye başlayın (muhtemelen bunu yapmak için yeterli var mı?)

Yavaşça kısmen işlevsel hale getirebilmeli ve sonunda ne yapmaya çalıştığınız daha açık hale geldiğinde bazı kötü kodları yeniden düzenleyebilmelisiniz.

Bir şey görene ve ne istediklerini fark edene kadar ne istediklerini bilmedikleri yaygın bir sorundur. Birisi sizden sadece bir 'çerçeve' ya da size söylediği gibi 'jenerik' bir şey inşa etmenizi istediğinde, denerseniz sadece başınız belaya gireceğini fark ettim. Çerçeveler zaten yazılmıştır, bunu yapmanız gerekmez.

Mesajınızdan topladığım birkaç sorun var: 0-Projeyi yönetmek sizin işiniz değil ve son kullanıcı gereksinimlerini toplamak sizin işiniz değil. 1-Patron kesin gereksinimleri bilmiyor 2-Patron son kullanıcılarla gereksinimler hakkında konuşmuyor 3-Patron gerçekten çevik anlamayan terminoloji atıyor 4-Yeniden elde edilen bazı çözümler üzerinde çalışıyorsunuz. birkaç kez yazılmış ve bundan memnun değilsiniz

1,2 ve 3'e gelince, kıdemli bir kişi değilseniz, bu konuda çok az şey yapılabilir. Ancak, aşağıdakiler yapılabilir:

C - Ondan proje planını sizinle paylaşmasını isteyin. Görevleri ve son tarihleri ​​gösteren bir tane olabilir ya da inşa edecek. Bunlardan biri analiz ve ihtiyaçların toplanması ile ilgili olmalıdır. Değilse öner.

B - Yazılım projesinin başarısı için gereksinimlerin önemi üzerine bazı referanslar hazırlar

C - Ona Agile'ın ne olduğunu ve ne olmadığını bir sayfa hazırlayın.

D - Tasarım aşamasına tipik girdilerin bir listesini hazırlayın ve her birinin değeri konusunda ikna edin.

E - Takıma bir iş analisti ve / veya veri değiştirici eklenmesini önerin. Bu tür roller son kullanıcı ile birlikte oturmak zorunda kalacak ve size gerekli bilgileri veya en azından iyi bir kısmını alacaktır.

F - Diğer geliştiricilerin bu adamla nasıl işbirliği yaptığını görün.

# 4'e gelince, ona, uygulamanın ve işlevselliğin özellikleri hakkında fikir vermesine yardımcı olacak bir prototipleme yaklaşımı veya bir kod üreteci kullanmasını önerebilirsiniz. Çoğu araç mükemmel GUI oluşturmaz, ancak en azından gerekli işlevselliği yakalayabilirsiniz.

Her durumda, yinelemelerin her birini net bir şekilde belgelediğinizden ve ona hangi girdiyi aldığınızı, ne yaptığınızı (ayrıntılı olarak) ve sonucun ne olduğunu belirten bir e-posta gönderdiğinizden emin olun. Sonuçları (gereksinim eksikliği vb.) Gibi uygun nedenlerle ilişkilendirdiğinizden emin olun.

Ne yazık ki bazı insanlar tavsiye kabul etmiyor. Onunla nasıl iletişim kurduğunuza dikkat edin.

Bu iyi gitmiyor!

İyi şanslar.

Eskiden böyle bir patronum vardı - aslında onun sloganının "kararsızlık esnekliğin anahtarı" olduğunu söyleyebilirim.

Yaptığınız geliştirme işi ne olursa olsun , müşterinin problemini çözmek için muhtemelen patronunuzdan daha iyi bir konumdasınız demektir. Sorunun ne olduğunu bilmiyorsanız (bu bir spesifikasyonla aynı şey değildir), o zaman birisi gereksinimlerini düzgün bir şekilde toplamaz.

Bazı sayfa düzenlerini çizin veya yarı / fonksiyonel olmayan bir prototip oluşturun. Ama bir şey yap. Tam istemci yazılımı veya web uygulamaları oluşturup oluşturmadığınız yayınınızdan net değil, ancak ikincisinin güzelliği, erken, sıklıkla yayınlayabilirsiniz. Çıplak kemiklerle başlayın ve oradan çalışın. Yanlış bir başlangıç, bazı diyalogların akması ve bazı kararların alınması durumunda zarar vermez.

Müşterilerimiz için $ WORK (dahili web uygulamaları) hakkında bir sözümüz var: "Ne istediğini söyleyebilmen için sana bir şey vereceğim." İlk taslağı atmaya hazır olun, ancak aslında ne kadar nadiren yapmanız gerektiğine şaşırabilirsiniz.

Agile kitaplarının kararları olabildiğince ertelemeyi önerdiğini, ancak bundan daha fazla olmadığını belirtin . Her kararın verilmesi gereken bir nokta vardır ve belki de şu an oradasınızdır.

Öte yandan, kendinizi de sorgulayın. Bu uygulama için hangi kalıcılık katmanını kullanacağınıza gerçekten karar vermeniz gerekiyor mu? Ya da bir CSV'ye yazmaya başlayabilir ve daha sonra bu kararı verebilecek kadar soyutlanmış tutabilir misiniz?

Kendi spesifikasyon belgenizi yazın ve açıkladığınız bir incelemeye sahip olun, imzaladı. O zaman patron olacaksınız ve patronunuz teknik konulardan ziyade kişilerarası yönetim konularına geçecek.

'Yukarı doğru yönetime' katılın, patronunuz ve müşterilerinizle konuşun, bazı çözümler bulun, ekibinizin uygulamak için en iyisini seçin, diğerlerinde kusurları bulun ve yöneticinizi 'doğru' karar vermek için 'yönetin'.

Ve elbette onun tüm fikri olduğunu düşündüğünden emin olun. (özellikle her şey ters gittiğinde!)

Bir şey tasarlamanız ve uygulamanız gerekiyor. Patronunuz karar vermeyeceğinden, kendiniz verin. Kararlarınızı ve varsayımlarınızı uygulamadan önce belgelemek için biraz zaman ayırın. Patronunuz da dahil olmak üzere endişe duyabileceğiniz kişilere gönderin. Umarım, bu liste patronunuzdan daha fazlasını içerir, çünkü bazı kararlar alması için biraz baskı uygular çünkü diğerleri ilerlemeye hazır olduğunuzu bilmektedir. Kararları yazılı olarak koyduğunuzda, özellikle de başkalarının katılmadığı kararlar alırsanız, ne kadar hızlı geri bildirim aldığınıza şaşıracaksınız. Bu arada, aksi belirtilmedikçe verdiğiniz kararlara devam edeceğim.

Patronunuzun istemediği şeyi uygulayarak zaman kaybetmeye son verdiyseniz, izleyeceğiniz yolun farkında olduğu için sizin değil, onun üzerindedir.

Ayrıca, bazı insanlar başlamak için zor zamanlar var, ama bir kez somut bir şey gördükten sonra zihinleri devreye girer. Belki patronunuz böyledir ve ona yazılı olarak ne yapmayı planladığınızı söylemeniz aklını başlatacaktır.

Kararları kendiniz alın ve kodlamaya başlayın. Elbette, esnek bir şekilde geliştirmek yardımcı olacaktır (henüz yapmadıysanız Robert C Martin'in Çevik Desenlerini, İlkelerini ve Uygulamalarını okuyun), ancak hiçbir karar alınmazsa dünyadaki tüm esneklik yardımcı olmaz. Sadece düşündüğünüzü geliştirmeniz gerektiğini görebilirsinizgerekir ve ardından gerektiği gibi değiştirilir. Genellikle müşteriler / patronlar görene kadar ya da istemedikleri bir şey görene kadar ne istediklerini bilmezler. Bu muhtemelen sizi geliştirici olma kapsamının dışına çıkarır, ancak bu hayattır. Ben ve meslektaşlarımın etkili bir şekilde ticari kararlar aldıklarını sık sık görüyorum. Bazen bunlar sorgulanmaz ve yaptığım kararlar işi sürmeye başlar, çünkü hiç kimse karar vermeyecektir. TÜM varsayımlarınızı ve kararlarınızı (istisnalar hariç) listelediğinizden ve bunları patronunuza sunduğunuzdan emin olun.