Decyzja
Termin dostawy zależy od decyzji i dostępu, jak również od wysiłków rozwojowych. Oszacować pracę, a następnie umieścić ją w kolejności, która odzwierciedla to, co musi być znane jako pierwsze. Dziesięć osobistych dni nakładu niekoniecznie mieści się w dziesięć dni kalendarzowych, kiedy zatwierdzenie odbywa się pomiędzy zadaniami.
Przykład roboczy
Wyobraź sobie MVP, który weryfikuje klientów biznesowych za pomocą usługi zewnętrznej. Zespół może projektować formularze, podczas gdy dostęp jest w toku, ale nie może ubiegać się o prace integracyjne, dopóki nie będą dostępne referencje, przypadki testów i przewidywana umowa na odpowiedź. Umieść tę zależność na harmonogramie u właściciela i wymaganą datę.
Zbuduj rejestr zależności obok harmonogramu
Dla każdej zależności należy odnotować to, co jest potrzebne, kto je dostarcza, kiedy musi przyjść i jakie dowody się liczy jako gotowe. "Dostęp do API" może oznaczać logowanie, pozwolenie na korzystanie z organizacji testowej, zatwierdzony dostęp do sieci oraz przypadki błędów w próbie. Unikaj traktowania pierwszego maila zawierającego referencje jako zakończenia wszystkich czterech. Przypisz zależność osobie, która może ją uzyskać, a nie tylko deweloperowi, który na nią czeka. Przegląd zmian w rejestrze z prognozą, tak aby opóźnienia stają się widoczne przed upływem daty. Jest to szczególnie ważne, gdy założyciel po raz pierwszy koordynuje sprzedawców.
Prognoza przy użyciu wąskiej próby końcowej
Przed wypełnieniem osi czasu równoległymi zadaniami należy wykonać cienką ścieżkę, która dotyka krytycznych zależności. W przykładzie weryfikacji należy wysłać jeden dopuszczalny wniosek o przeprowadzenie testu, obsługiwać jedną nieudaną odpowiedź i pokazać użytkownikowi uzyskany status. Próba ujawnia różnice odpowiedzi, etapy zatwierdzania i brakujące środowiska, podczas gdy zakres jest nadal łatwy do dostosowania. Mack pozostaje przydatny do bieżącej pracy interfejsu, ale etykietuj, co dowodzi i co pozostawia nieprzetestowane. Zachowaj wynik odkrycia, weryfikację integracji i wydanie zatwierdzenia jako oddzielne kamienie milowe, aby nie stać cicho za innym.
Komunikacja zmian jako wyborów z konsekwencjami
W przypadku zmniejszenia zależności należy wyjaśnić wpływ na wynik i dostępne wybory: kontynuować niezależną pracę, zmienić zakres uruchomienia, zastosować tymczasowy proces ręczny lub zmienić datę. Określ ograniczenia jakiegokolwiek tymczasowego procesu i kto będzie go prowadził. Unikać spożywania całego okresu weryfikacji w celu zachowania wyglądu niezmienionego harmonogramu. Zmieniona prognoza powinna pokazać, co jest obecnie znane, co pozostaje niepewne i kolejne zdarzenie, które może ją ponownie zmienić. Dobry plan nie jest tym, którego data nigdy się nie porusza; jest to ten, którego ruch można wyjaśnić wystarczająco wcześnie, aby firma mogła działać.
Alternatywy warte ważenia
Równoległa praca pomaga, gdy zadania są rzeczywiście niezależne. Usługa makowa umożliwia rozwój interfejsu, ale nie weryfikuje prawdziwego dostawcy. Mniejszy zakres uruchomienia może zmniejszyć zależność; więcej deweloperów nie przyspieszy zatwierdzenia kontrolowanego przez inną organizację.
Gdzie plan się psuje
Unikaj jednej optymistycznej daty bez założeń. Oddziel techniczną datę zakończenia od akceptacji klienta i gotowości do startu. Lista wakacji, dostarczanie treści, czyszczenie danych, zatwierdzanie sprzedawców i osób upoważnionych do odpowiedzi na pytania dotyczące produktu.
Przed zleceniem pracy
Która nierozwiązana zależność leży na najdłuższej wymaganej ścieżce? Co się stanie, jeśli się poślizgnie? Które prace mogą być kontynuowane niezależnie? Dyskusja na temat planowania MVP powinna dostarczyć tych odpowiedzi i wyraźnego powodu do zmiany prognozy w przypadku zmiany dowodów.