Jak zarządzasz żądaniami funkcji i zmianami oprogramowania? [Zamknięte]

Jestem inżynierem oprogramowania i przez ostatnie kilka lat stałem się de facto menedżerem projektów oprogramowania, ponieważ nie ma takiego. Aby zachować zdrowie psychiczne w dziale badań i rozwoju / inżynierii, klienci przyzwyczaili się do przychodzenia do mnie z prośbami. Nie mam doświadczenia w tej dziedzinie, więc po raz pierwszy działam jako kierownik projektu dla oprogramowania. Zarządzałem innymi rzeczami, ale nie oprogramowaniem.

Jak zatem zarządzasz projektami oprogramowania i zaznaczasz priorytety? Prośby przychodzą w rzadkich odstępach czasu, więc bardzo dobrze możemy pracować nad czymś dla kogoś innego, a następnie inna osoba przychodzi z „pośpieszną” pracą, nad którą trzeba pracować. Czy łatwiej jest po prostu powiedzieć, kto pierwszy, ten lepszy, czy to osoba z największą ilością pieniędzy?

Przekonałem się, że im bardziej klient skarży się na pilność jego prośby, chyba że sam jest programistą, zwykle jest to dobry znak, że prośba wcale nie jest pilna. Jeden z moich profesorów na studiach zawsze mówił nam, żebyśmy nie pozwalali, aby pilne przeszkadzało to, co ważne.

Zazwyczaj klasyfikuję wnioski w tej kolejności (YMMV):

1. Problemy związane z ostatnią aktualizacją lub migracją (najważniejsze).
2. Poprawki bezpieczeństwa.
3. Zepsuta funkcjonalność istniejącego systemu.
4. Zepsuta funkcjonalność funkcji RC i beta.
5. Płatne prośby o funkcje.
6. Żądania funkcji R&D od dużej części bazy użytkowników.
7. Żądania funkcji badawczo-rozwojowych od tylko jednego lub dwóch użytkowników.

Ten ostatni zajmuje dużo więcej czasu, ponieważ są to zazwyczaj prośby „pilne, potrzebuję tego wczoraj”. W rzeczywistości użytkownik rzadko zastanawia się, czego tak naprawdę potrzebuje lub w jaki sposób będzie wspierać jego model biznesowy. Najczęściej te pilne prośby, po dostarczeniu, zostają wykorzystane raz lub dwa razy i zapomniane. A kiedyś zapomniane, stają się niekończącym się bólem głowy z dziur bezpieczeństwa i niezamierzonych konsekwencji.

Lubię zasady:

1. QI - ważne i pilne
2. QII - Ważne, ale nie pilne
3. PIII - Nieważne, ale pilne
4. QIV - Nieważne i nie pilne

1. Skonfiguruj funkcję śledzenia błędów / zgłoszeń i poproś klientów / współpracowników o składanie zgłoszeń. Jeśli nie złożą biletu, nie robisz tego. Bilety muszą być wystarczająco szczegółowe, aby można było je realizować i muszą określać „pilność” („Potrzebuję go teraz” vs. „miło mieć”).
2. Przejrzyj nowe bilety i dokładnie je przeanalizuj . Wprowadź koszt w bilecie w dolarach, programistach, zasobach i / lub czasie. To jest niezbędne . Gdy Twoi klienci zobaczą, ile naprawdę ich kosztować, zobaczysz bardzo różne opcje w polu „Pilność”.
3. Codziennie ustal harmonogram na podstawie złożonych biletów i ich pilności. Udostępnij harmonogram innym osobom, aby było oczywiste, co porabiasz i czy jesteś gotowy na przyszłe żądania.

Widziałem projekty, w których zmianami wymagań zarządza bardzo ciężki system kontroli zmian. To jest złe. Wiele ważnych zmian się nie dzieje, ponieważ klient nie chce przechodzić przez kłopot ze złożeniem kontroli zmian, więc oprogramowanie nie spełnia ich potrzeb. Niektóre niewielkie zmiany są wprowadzane „pod radarem”, aby uniknąć tego procesu, więc oprogramowanie nawet nie pasuje do tego, co myślisz.

I odwrotnie, widziałem również projekty, w których kierownik projektu uważa, że ​​„reaktywny” oznacza zmuszenie programistów do odpowiedzi na każde żądanie od użytkowników, co oznacza po prostu, że nigdy nie wykonasz żadnego rdzenia programistycznego, a twój kod stanie się wielkim nieporęcznym bałaganem na szczycie włamać się. Zasadniczo teraz nie masz żadnych programistów, masz zespół nadmiernie wykwalifikowanych inżynierów sprzedaży.

Można więc mieć nadzieję, że sytuacja między tymi dwoma biegunami działa dobrze, i spodziewam się, że to, co działa najlepiej dla ciebie, jest zarówno osobistym wyborem, jak i położeniem. Zdecydowanie warto uchwycić koszt każdej zmiany. W ramach takich jak Scrum możesz wyrazić koszty w punktach fabularnych, a zespół może oddać pracę wykonaną w każdej iteracji w stosunku do całkowitego dostępnego wysiłku. Jeśli masz menedżera produktu, możesz poprosić tę osobę o oszacowanie oczekiwanej korzyści z żądania zmiany lub funkcji. Zwykle odbywa się to w kategoriach chronionych dochodów (ilu klientów odejdzie, jeśli tego nie zrobisz) i przyciąga przychody (ilu klientów przyjedzie, jeśli to zrobisz). Może to pomóc w ustalaniu priorytetów, ale może również odzwierciedlać uprzedzenia lub osobiste preferencje menedżera produktu.

Oto kilka myśli ...

Na rynku jest mnóstwo oprogramowania, które pomaga: http://www.fogcreek.com/ z Fogbugz, GeneXus USA z XPM http://www.genexususa.com/xpm itp.

To jak sztuka równoważenia żądań nowych funkcji z poprawkami błędów i własnymi pomysłami. Musisz zdobyć jedzenie na następną zimę, ale musisz też dzisiaj jeść.

Masz czas, zasoby i zakres, jak najlepiej z niego korzystaj.

Henry Ford również kiedyś powiedział: „Gdybym słuchał klientów, dałbym im szybszego konia” ...

Osobiście: bądź dynamiczny, nie stawiaj reguł takich jak te, które powiedziałeś ... i uważaj na reguły innych ludzi ... mogą działać dobrze w swoim kontekście, ale nie w twoim.

To, co zakończyliśmy, to to, że teraz będziemy odbywać dwumiesięczne spotkania dotyczące sprzedaży / inżynierii, aby omawiać bieżące projekty i nadchodzące lub przyszłe prośby o funkcje. Inżynierowie ds. Sprzedaży staną się kierownikami projektów i przynajmniej będą dostosowani do najnowszych ofert produktów. W przeszłości po prostu łatwo było przekazać to inżynierii i zapomnieć o tym. Prawdopodobnie zmniejszy to obciążenie inżyniera oprogramowania i obciąży sprzedażą i zarządzaniem rozsądnym wykorzystaniem naszego czasu.

Firma, dla której pracuję, korzysta z dwóch głównych aplikacji, narzędzia internetowego o nazwie JIRA do obsługi aspektów związanych z projektem oraz naszego systemu pomocy technicznej do obsługi żądania zmiany za pośrednictwem funkcji rfc

Odpowiedzi, które do tej pory widzę, są dobre. Jedną z rzeczy, które konkretnie przeliteruję, jest to, że musisz być dobry w mówieniu „Nie” w przypadku niektórych próśb.

Jeśli zezwolisz klientowi na ustawienie pilności, prawie zawsze będzie to „Wysoka” (lub wyższa).

Ty (ty sam lub zespół, w zależności od konfiguracji) będziesz musiał ocenić te żądania i uszeregować je według własnych kryteriów.