Finansowanie projektów zwinnych

Firma, w której pracuję, niepewnie dąży do strategii zarządzania projektami Agile - raz doświadczyła „radości” wodospadu. Kluczem do tego jest przesunięcie nacisku na dostarczanie funkcjonalności zamiast na dotrzymywanie trudnych terminów.

Podczas gdy proces rozwoju i relacje z klientami z pewnością poprawiły się dzięki iteracyjnym wersjom wspieranym przez Agile, nieco trudniej jest zastosować to samo uzasadnienie do strategii finansowania projektu. Klienci często nie są przyzwyczajeni do takich koncepcji, jak Agile i wyrażają duże zaniepokojenie tym, co postrzegają jako „będzie gotowy, kiedy będzie gotowy”.

Chciałbym usłyszeć opinie ludzi i doświadczenia związane z finansowaniem projektów Agile

edytuj: Chcę podkreślić, że nie proszę ludzi o wyjaśnienie zalet i wad metody Agile , ani że uważam, że Agile oznacza „będzie gotowy, kiedy będzie gotowy”, to strach wyrażony przez klienci / firmy, z którymi współpracowałem, promując zwinne metody programowania.

Interesuje mnie doświadczenie, jakie ludzie mieli w rozwiązywaniu konfliktów między „tradycyjnymi” metodami budżetowania wodospadu zakorzenionymi w klientach biznesowych / relacjach i bardziej progresywnymi metodami rozwoju - a strategiami budżetowymi, które przyjęli w celu wsparcia tej ewolucji.

Jeśli byłeś w stanie podać wycenę projektu z dokładną datą końcową wszystkich funkcji, dlaczego zdecydowałeś się na podejście zwinne? Ty i wszyscy inni walczycie z tym, a zwinne podejście jest z góry tego faktu. Użyj go jako propagandy przeciwko konkurencji. Southwest Airline nie obiecuje ci miejsca na wyspie, jak każdy inny, kto to robi, a następnie daje je komuś innemu.

Oczywiście klient chce dokładnej daty zakończenia. Chcą, aby niedrogie, wolne od błędów oprogramowanie zostało dostarczone z wyprzedzeniem, niezależnie od zmian w pierwotnym żądaniu. Poinformuj zespół sprzedaży, aby dowiedzieć się, jak sprzedać projekt przy użyciu zwinnych zasad. Im więcej interakcji przejdziesz, tym bliżej będziesz wiedzieć, kiedy projekt zostanie zakończony. Klient uczy się również uwzględniać skutki żądań zmiany.

Zwinne projekty nie działają w stylu „będzie gotowy, kiedy będzie gotowy”. To klasyczna linia z inżynierii wodospadu.

Zwinne projekty są zakończone, gdy klient zdecyduje, że nie chce wydawać więcej pieniędzy na dodatkowe funkcje. Może to zostać przekształcone w kluczowy punkt sprzedaży przez sprzedawców. Zamiast angażować się w ustalony zestaw funkcji (których potrzeba może lub nie być znana z góry) za określoną kwotę pieniędzy, klient może zacząć od początkowej kwoty za początkowy zestaw funkcji, a następnie rozłożyć ją etapami. Zagwarantuje to kilka rzeczy:

• Tak długo, jak lista funkcji jest odpowiednio uszeregowana pod względem priorytetów, klient zawsze otrzymuje kolejne najważniejsze funkcje dostarczane w następnej kolejności, maksymalizując w ten sposób swoje korzyści ze swoich wydatków (dostaje „największy huk za swoje pieniądze”).
• Jeśli klientowi zabraknie pieniędzy, zmaksymalizował swoją inwestycję ORAZ zapłacono Ci za to, co dostarczyłeś. Nikt się nie skrzywdzi, wszyscy zyskują.
• Klient może zmienić zdanie na temat priorytetów i funkcji na każdym zakręcie koła (na każdym końcu połączenia). Wyraźna przewaga nad zwykłymi umowami o stałej cenie.

Prawdopodobnie jest ich więcej, ale powyższe powinno wystarczyć, aby zachęcić sprzedawców we właściwym kierunku.

Nie uważam tego za przypadek „Będzie gotowy, kiedy będzie gotowy”. Zwinna metodologia promuje regularne oferowanie rezultatów, jak co dwa tygodnie. Właśnie dlatego klient jest ważną i bardzo aktywną częścią projektu przez cały okres jego życia, ponieważ zapewnia wskazówki dotyczące kształtowania się cech Twojego produktu. Jeśli już, klient zacznie widzieć wyniki wcześniej, niż pod koniec projektu, jak w podejściu do wodospadu.

Tak długo, jak będziesz powtarzać fakt, że klient będzie aktywną częścią projektu i że zobaczy, że projekt zaczyna kształtować się wcześnie, może to zapewnić, że nie jest to przypadek oczekiwania na zakończenie.

Chociaż miejsce, w którym pracuję, powoduje straszliwą banalizację Agile, myślę, że klienci bardziej wolą tworzenie oprogramowania w iteracjach niż pełne wersje.

Iteracje dostosowują się do indywidualnych żądań klientów, ponieważ proszą o coś i otrzymują je, gdy funkcja zostanie zaimplementowana, a nie po jej zakończeniu i wykonaniu wszystkich innych rzeczy, które zostały z nią zgrupowane w celu wydania.

Nigdy nie widziałem, aby klient powiedział: „Chcemy tej funkcji i chcemy poczekać 8 miesięcy, aż zostanie ona dostarczona z szeregiem innych funkcji, na których nam nie zależy”.

Co powiesz na ustanowienie cyklu płatności zgodnego z iteracjami? Idea zwinności polega na tym, że można naprawdę planować i szacować tylko w krótkich okresach, a nacisk i zaangażowanie są nadal silne w przypadku tych krótkich cykli. Dlaczego więc nie ukierunkować finansowania w ten sam sposób - poproś klientów, aby wnieśli wkład w pracę za $$ w tym samym czasie, gdy wnoszą wkład w poradnictwo. W końcu, jeśli nie dostaną tego, czego chcą, nie powinni za to płacić.

Następnie sprawdź, co dzieje się po zakończeniu projektu - na przykład, czy klient jest właścicielem kodu, czy tylko pliku wykonywalnego? Byłoby to jednak zgodne z wcześniejszymi projektami typu wodospad.

Ideą Agile jest szybkie iterowanie i ustalanie dokładnie tego, co zamierzasz dostarczyć pod koniec każdego sprintu, więc kiedy miną 2/3/4 tygodnie twojego sprintu, masz konkretne funkcje w aplikacji / projekcie które możesz przedstawić klientowi i uzyskać informacje zwrotne.

ETA: Możesz zebrać „sprinty” w „kamienie milowe” z ustalonymi rezultatami i otrzymywać płatności za kamień milowy.

Nie jestem przekonany, że powinieneś sprzedać ustalony projekt i obsługiwać Agile po swojej stronie, ale raczej sprzedawać iteracje klientowi.

Iteracje są zrozumiałe i nie łączysz dwóch pojęć.

Poniższe dwa dokumenty zawierają informacje o interakcjach Agile Management i procesach sprzedaży:

http://www.nayima.be/html/fixedpriceprojects.pdf i http://www.nayima.be/html/agilefixedprice.pdf