Özellik isteklerini ve yazılım değişikliklerini nasıl yönetirsiniz? [kapalı]

Ben bir Yazılım Mühendisiyim ve son birkaç yıldır fiili olmayan bir yazılım proje yöneticisi oldum, çünkü bir tane yoktu. Ar-Ge / Mühendislik departmanında akıl sağlığımızı korumak için müşteriler istekleri ile bana gelmeye alışmışlardır. Bu alanda hiçbir tecrübem yok, bu yüzden ilk defa yazılım projeleri için proje yöneticisi olarak görev yapıyorum. Başka şeyleri başardım ama yazılımı değil.

Peki yazılım projelerini nasıl yönetiyor ve öncelikleri nasıl belirliyorsunuz? İstekler nadir aralıklarla gelir, bu yüzden başka biri için bir şeyler üzerinde çalışabiliriz ve daha sonra başka bir kişi üzerinde çalışılması gereken "acele" bir işe girer. İlk Gelince İlk Serçe'yi söylemek kolay mı yoksa en fazla parası olan kişi mi?

Bir müşterinin isteğinin ne kadar acil olduğuyla ilgili şikayetlerinin daha fazla olduğunu, kendileri de bir geliştirici olmadıkça, isteğin hiç acil olmadığının iyi bir işareti olduğunu buldum. Üniversitedeki profesörlerden biri her zaman acil olanın önemli müdahalesine izin vermememizi söylerdi.

Genelde istekleri bu siparişte (YMMV) sınıflandırırım:

1. Son güncelleme veya geçişle ilgili konular (en önemlisi).
2. Güvenlik düzeltmeleri.
3. Mevcut sistemin bozuk işlevselliği.
4. RC ve beta özelliklerinde kopuk işlevsellik.
5. Ödenen özellik istekleri.
6. Ar-Ge özelliği, kullanıcı tabanının büyük bir kısmından talep ediyor.
7. Sadece bir veya iki kullanıcıdan gelen Ar-Ge özelliği talepleri.

Bu sonuncusu aslında çok daha fazla zaman alıyor çünkü "acil, dün ihtiyacım var" talepleri olma eğilimindeler. Gerçekte, kullanıcı gerçekte ihtiyaç duyduğu veya iş modelini nasıl destekleyeceği konusunda tamamen nadiren düşünmüştür. Çoğu zaman, bu acil talepler bir kez teslim edildikten sonra bir veya iki kez kullanılmaya başlanır ve unutulur. Ve bir kez unutulduklarında, güvenlik deliklerinin bitmeyen bir baş ağrıları ve istenmeyen sonuçları olurlar.

İlkelerini severim :

1. QI - Önemli ve Acil
2. QII - Önemli ancak Acil Değil
3. QIII - Önemli Değil ama Acil
4. QIV - Önemli Değil ve Acil Değil

1. Bir özellik / hata / istek takip sistemi kurun ve müşterilerinizin / iş arkadaşlarınızın biletlerini alın. Bilet alamazlarsa, yapmazsın. Biletler harekete geçebilecek kadar ayrıntılı olmalı ve "aciliyet" belirtmelidir ("şimdi ihtiyacım var" vs. "olması güzel").
2. Yeni biletlerden geçin ve dikkatlice kapsamlaştırın. Fişi maliyete dolar, geliştiriciler, kaynaklar ve / veya zaman cinsinden girin. Bu esastır . Müşterilerinizin şey olacağını görmek zaman gerçekten onlara mal, siz "aciliyet" alanına çok farklı seçenekler göreceksiniz.
3. Günlük olarak, verilen biletlere ve ivediliklerine göre planınızı hesaplayın. Programı başkaları tarafından görülebilir hale getirin, böylece ne yaptığınız ve gelecekteki talepler için uygunluk durumunuz açık olacaktır.

Gereksinim değişikliklerinin çok ağır bir değişim kontrol sistemi tarafından yönetildiği projeleri gördüm. Bu kötü. Birçok önemli değişiklik gerçekleşmez, çünkü müşteri bir değişiklik kontrolü sağlama zorluğundan geçmek istemez, böylece yazılım ihtiyaçları ile eşleşmez. İşlemden kaçınmak için bazı küçük değişiklikler “radarın altında” kayıyor, bu yüzden yazılım düşündüğünüzle eşleşmiyor.

Bunun tersine, proje yöneticisinin "reaktif" olduğunu düşündüğü ve kodlayıcıların kullanıcılardan gelen her isteğe yanıt vermesi anlamına geldiğini düşündüğüm projeler gördüm. kesmek. Temel olarak, şimdi hiçbir geliştiriciniz yok, fazla kalifiye satış mühendislerinden oluşan bir ekibiniz var.

Dolayısıyla, bu iki kutup arasında iyi çalışan bir durum olduğunu umuyorum ve sizin için en iyi olanın hem kişisel bir seçim hem de konumlandırılmasını bekliyorum. Her değişikliğin maliyetini yakalamanın kesinlikle bir değeri var. Scrum gibi bir çerçevede, hikaye puanlarındaki maliyeti ifade edebilir ve ekip, her tekrarlamada yaptıkları işleri toplam kullanılabilir çabaya karşı değiştirebilir. Bir ürün yöneticiniz varsa, o kişiden bir değişiklik veya özellik isteğinin beklenen yararını ölçmesini sağlayabilirsiniz. Bu genellikle korumalı gelir (bunu yapmazsanız kaç müşteriden ayrılacağı) ve kazanılan geliri (bunu yaparsanız kaç müşterinin geleceği) açısından yapılır. Bu önceliklendirme konusunda yardımcı olabilir, ancak ürün yöneticisinin önyargısını veya kişisel tercihini de yansıtabilir.

İşte bazı düşünceler ...

Piyasada size yardımcı olacak birçok yazılım var, http://www.fogcreek.com/ ile Fogbugz, GeneXus USA XPM ile http://www.genexususa.com/xpm , vb.

Yeni özellik isteklerini hata düzeltmeleriyle ve kendi fikirlerinizle dengelemek bir sanattır. Gelecek kış için yiyecek almak zorundasın, ama bugün de yemek zorundasın.

Vaktiniz, kaynaklarınız ve kapsamınız var, bundan en iyi şekilde yararlanın.

Henry Ford bir keresinde ünlü olarak “Müşterileri dinleseydim, onlara daha hızlı bir at verirdim” dedi.

Şahsen: dinamik olun, söyledikleriniz gibi kurallar koymayın ... ve diğer insanların kurallarına dikkat edin ... kendi bağlamlarında iyi çalışabilirler, ancak sizin adınıza uygun olmayabilirler.

Şimdi sona erdiğimizde, şimdiki projeleri ve gelecek veya gelecekteki özellik taleplerini tartışmak için iki ayda bir satış / mühendislik toplantıları yapacağız. Satış mühendisleri proje yöneticisi olacak ve en azından en son ürün teklifleriyle uyumlu olacaklar. Geçmişte Mühendislik'e iletmek ve unutmak kolaydı. Bu, bir yazılım mühendisinin yapması gereken yükü azaltacaktır ve zamanımızı akıllıca kullanabilmek için satış ve yönetimin peşinde koşacaktır.

Çalıştığım şirket, projeyle ilgili yönleri ele almak için JIRA adlı web tabanlı bir araç ve rfc işlevselliği ile değişiklik talebini yerine getirmek için yardım masası sistemimiz olmak üzere iki ana uygulama kullanıyor

Şimdiye kadar gördüğüm cevaplar iyi. Özellikle heceleyeceğim bir şey, bazı isteklere "Hayır" derken iyi olmak zorunda kalacağınız.

Müşterinin aciliyeti ayarlamasına izin verirseniz, hemen hemen her zaman "Yüksek" (veya daha büyük) olur.

Siz (kendiniz veya kurulumunuza bağlı olarak bir takım) bu istekleri değerlendirmeniz ve kendi kriterlerinize göre önceliklendirmeniz gerekecektir.