Sık ihtiyaç değişiklikleri ile nasıl başa çıkılır?

Şu anki iş yerimde oldukça stresli (bence) durumla uğraşıyorum.

Yeni bir proje geliştirmeye başladık, bazı gereksinimler edindik, uyguladık ve daha sonra bir kişiye 'iş danışmanı' (işletme gereksinimlerini bilen fakat programı kullanmayacak kişi) diyebileceğiniz birine gösterdik. Bu kişinin başvuruyu müşterinin bakış açısından değerlendirmesi, test etmesi vb.

'Süreç' şöyle görünür:

1. iş danışmanı görüşmelerim patron ile akşam bir veya iki saat için windows messenger
2. ertesi gün o konuşmanın kopyasını içeren bir e-posta alırım. Bundan görevler seçmem gerekiyor, bildirilen hataları kontrol etmeliyim (genellikle hatalar değil, sadece zayıf testler ve geçmiş kurumları unutmak)
3. Değişiklikleri uyguluyorum, uygulama kabul ediliyor ve bir veya iki hafta içinde istemedikleri ortaya çıkıyor (yazılımı 5 dakika boyunca gören bazı potansiyel müşterilerle konuştular ve değişiklikler önerdiler) - Yeni değişiklikler yapmalıyım

Beni yanlış anlamayın, bazen gereksinimlerin değiştiğini anlıyorum. Beni rahatsız eden şey, işyerimde değişikliğin ne sıklıkta meydana geldiği ve 'yönetim' için ne kadar kolay olduğu, yeni özellikler veya bazen mevcut özelliklerde temel değişiklikler sağlıyor.

Aynı zamanda sıkı teslim tarihleri ​​üzerinde çalışıyoruz ve yazılımımıza devam etmek yerine daireler yürüttüğümüz izlenimini edindim.

Sizden bu durumla nasıl başa çıkacağınızı tavsiye ediyorum? Bu normal bir durum mu ve sadece bu konuda aşırı duyarlıyım?

Mümkünse, e-postayla gönderdiğiniz sohbeti alın ve bir gereksinimler belgesine dönüştürün. Ondan toplayabileceğiniz görevleri listeleyin ve öncelik olarak algıladığınız şekilde sıralayın ve her birine bir tahmin atayın. Sonra bir sonraki sürüm için hangi özellikleri istediklerini sorun.

Temel olarak, yönetimin ne inşa edeceğinizin farkında olduğu bir tür geribildirim döngüsünü zorlayın. İletiyi alana kadar kendi gereksinim belgelerinizi yazın.

Hikaye Kartları

Durumunuzun kullanıcı hikayelerini tanıtmak için çok uygun olduğunu düşünüyorum . Yöneticinizin öncelikleri belirlemesi için sürekli, etkileşimli bir yol sunmakta gerçekten yardımcı olurlar ve bir hafta sonra fikre geri döndüğünde ve bunun işe yaramadığını fark ettiğinde bile onları atabilir.

Gerçek dünyada gereksinimler rutin olarak değişir. Artı tarafta, yazılımı oluşturmayı ve göndermeyi bitirmeden önce bunu öğrenirsiniz - yazılımın doğrudan kullanıcısından sıkı bir geri bildirim döngüsüne sahipsiniz, ki bu gerçekten harika.

Buradaki en büyük sorun, değişikliğin yönetilmesinin en geçici yolu gibi görünüyor. Çevik / Scrum'ın, geri bildirim veren bir "ürün sahibi" olarak gördüğü şeylere sahipsiniz, ancak süreç kötü belgeleniyor ve kötü düşünülmüş.

Muhtemelen bir sonraki adımlarınızı bilgilendirmek için Scrum'daki modellere ve etkili bir ürün sahibinin ne olduğuna dair görüşlerine bakmak istersiniz .

Dolayısıyla, bu ad-hoc sürece sahip olmak yerine, "iş danışmanı" ile daha yakın ve daha yararlı bir ilişkiye sahip olduğunuz ve tartıştıkları değişikliklerin sonuçları hakkında herkesin aynı sayfada olduğu bir dünyaya taşınmayı hedefleyin .

Mevcut süreciniz, bu insanların, tüketecekleri kaynak ve para için herhangi bir düzenleme yapmadan fikirleri beyin fırtınası yapmasını çok kolaylaştırıyor. Tüm bu özellikleri istiyorlarsa, bazı "oyunda deri" almaları gerekir.

İleti dizisinin bu e-postasını alın ve yalnızca bir e-tablo olsa bile bir tür özellik / hata izleme uygulamasına koyun. Yeni ilaveleri iş danışmanına geri gönderin ve ondan her bir öğede oturumu kapatmasını veya düzeltme sağlamasını isteyin. İmza ile birlikte, öncelik vermelidirler (Önce hangilerini istersiniz?).

Onayladıktan sonra, öğelerin test için ne zaman tamamlanacağına dair programınızı geri gönderin ve tamamlanma testini / onayını yapmak için bir zaman ayırmalarını sağlayın.

Bu tür bir dokümantasyon oluşturmanın neden programcı olduğunuzun olmadığını biliyorum, ancak ya bu listeleri atma riskine girebilir ya da zor kazanılan kodunuzu atmaya devam edebilirsiniz.

Geri itmek. Sorumluların bu taleplerin ne kadar maliyetli olduğunu görmesi gerekir.

Gereksinim değişiklikleri her zaman kötü değildir. Önemli olan müşterinizi hatırlamaktır. Bu durumda patronunuz müşterinizdir. Bu sürekli gereksinim değişikliklerinin kendisi için en faydalı ürünü üretme kabiliyetinizi sınırladığını patronunuza bildirmeniz gerekir. İşletmenin sürekli olarak değişikliklere tepki göstermenizden faydalanması tamamen mümkündür. Eğer öyleyse, bu onların iş modeli ve yanlış bir şey yapmıyorsunuz, ancak bu durumda tepeler için koşmayı tavsiye ederim!

Gereksinim değişikliklerinden hayal kırıklığına uğrayan insanlar genellikle her değişikliği ne kadar iyi yönettiklerine göre değerlenir. Bu "yeterince ele alınan değişiklik sayısı" metriği muhtemelen gerçek sorununuzun kaynağıdır. Patronunuzla daha iyi metrikleri tartışmayı düşünün. Sürekli değişen gereksinimlerle karşılaştığımda, sürekli değişen gereksinimlere uyum sağlamamı sağlayan içerik yazmaya çalışıyorum. Her gün bir simülasyon çalıştırmak ve verileri analiz etmek yerine, simülasyonu çalıştırma ve verileri daha ucuz bir şekilde analiz etme ve zaman içinde ödülleri toplayan araçlar yazacağım. Bu hala çok çılgınsa, araç yazmak için bir araç bile yazabilirim!

İşleminiz yinelemelerde kilitli gibi çevik ilkelerden yararlanabilir. Bir hafta, tarif ettiğiniz bu hızlı tempolu değişikliklerle makul bir hafta. 2 hafta sonunda daha iyi çalışabilir.

Yeterince önemli gereksinimler belirlendikten sonra, Project Ownerrolde olan kişinin oturumu kapatmasını sağlayın ve bunları oluştururken bir hafta boyunca kilitleyin. Meşgul olacağınız yere kendiniz için yeterli iş tahsis edin ve yetkilerin tahsisini bilmesine izin verin. yani haftada 16 puan üretebiliyorsanız ve 16 puanınız varsa, o hafta tam olarak kullanılırsınız. (Puan kavramı çevik iş akışından gelir)

Değişiklikler haftanın ortasında gelirse, şu sihirli kelimeleri söyleyin:

[Bu yeni özelliği], [bu yeni değişikliği], [vb.] Yapabilirim, ama ne yapmak istemiyorsun ?

Yani, sınırlı bir kaynağınız, sadece çok fazla iş alabilirsiniz. Yeni bir iş öğesi gelirse, sizin sınırlı kaynak olmanıza ve yeni öğeye puan atamanıza ve bu yeni gelen değişiklik yerine diğer öğeleri bırakmanıza / değiştirmenize izin verilir. Yineleme listenizi proje sahibiyle birlikte yeniden önceliklendirin; değişiklikle daha iyi başa çıkmalısınız.

Gereksinimler bundan daha sık değişiyorsa, ortamınızda daha fazla istikrar için müzakere etmeniz gerekebilir.

"Gereksinim değişikliği" ifadesi bazen BT çalışanları tarafından kötüye kullanılıyor. Açıkladığınız şey gerçekten gereksinimlerin değişmesidir, ancak bunun nedeni aşağıdakilerden biri veya daha fazlası olabilir (Durumunuz hakkında yeterli bilgim yok, bu nedenle aşağıdakiler geçerli olabilir veya olmayabilir):

1. Yönetimin son kullanıcıyı olabildiğince çabuk mutlu etme ve hızlı ilerleme gösterme tutkusu.

2. Ayrıntılı analiz eksikliği. Analistlerin neden sadece neyin değil hakkında soru sormaları gerektiğini unutmayın. Analistlerin sadece sipariş almakla kalmayıp son kullanıcı ile bir "çözüm" hakkında "düşünmesi" gerekir.

3. İhtiyaçların doğrulanması ve onaylanması için resmi bir sürecin olmaması ve ardından onay.

4. Yanlış kişiden bir veya daha fazla rol gerçekleştirmesini istemek, Business Analyst veya Systems Analyst rolleri gibi eğitilmeleri gerekmez.

5. Sınırlı prototip oluşturma.

6. Hızlı bir şekilde yapılması gerektiği varsayımı / korkusu ve eğer değilse BT'nin suçlanması.

Yukarıdakilerin tümü doğru bir şekilde ele alınmadıkça, BT ile iş / son kullanıcı arasındaki ilişki stresli olacaktır. Bunun, yukarıdaki noktanın kesin olduğu anlamına gelmediğini lütfen unutmayın. Durumunuza benzer stresli durumlara yol açan başka faktörler de var, ancak bu listenin sizi yönlendirmesi gerektiğini düşünüyorum.

Bence buna birkaç yönden yaklaşmalısınız:

1. Tüm paydaşların (tüm geliştirme ekibi dahil) iş danışmanıyla buluşmasını (çevrimdışı / çevrimiçi) sağlayın ve etki alanını, vizyonu ve daha sonra gereksinimleri birlikte beyin fırtınası yapmaya çalışın.

2. Gereksinimleri / kullanıcı öykülerini her birini not
   ederek resmileştirin: a. Öncelik (aciliyet / önem)
   b. Vade (ne kadar iyi tanımlanmışsa - hissedarların çoğunluğu tarafından anlaşılır ve üzerinde anlaşmaya varılır *)
   c. Karmaşıklık (kabaca tahmin)
   
   Bir sonraki aşamada hangi gereksinimin / kullanıcının çalışacağını seçerken, üç faktörü de dikkate alın. Gereksinimin düşük vadesi varsa, tüm paydaşlarla iletişim kurduğunuz, gereksinimin arkasındaki nedeni araştırdığınız ve harekete geçmeden önce gereksinimi daha iyi tanımlayın (kullanım senaryoları yazın ve / veya tel çerçeveler oluşturun ve sunun). bunun üzerine.

3. Her uygulamadan önce tasarım yaparken birkaç adım önde düşünmeye çalışın - değişiklikleri barındıracak esnek bir mimari tasarlayın.

4. SCRUM veya Kanban gibi çevik bir geliştirme sürecini uyarlamaya çalışın - bu size değişen gereksinimleri olan bir ürün geliştirmek için bir araç seti sağlayacaktır.

Ayrıca, moderatörlerden bu soruyu burada işaret etmesine rağmen PM.stackexchange.com'a (işaretleyerek) taşımasını istemeyi düşünmelisiniz.

(*) Anlaşma için pay sahipleri: iş, pazarlama, proje yönetimi, geliştirme ve KG.