Prawie każdy programista musi odpowiedzieć na pytania od strony biznesowej, takie jak:
Dlaczego dodanie tego prostego formularza kontaktowego potrwa 2 dni?
Gdy programista oszacuje to zadanie, może je podzielić na kroki:
- wprowadź zmiany w bazie danych
- optymalizuj zmiany DB pod kątem prędkości
- dodaj front-end HTML
- napisz kod po stronie serwera
- dodaj weryfikację
- dodaj javascript po stronie klienta
- użyj testów jednostkowych
- upewnij się, że konfiguracja SEO działa
- wdrożyć potwierdzenie e-mailem
- refaktoryzuj i zoptymalizuj kod pod kątem szybkości
- ...
Może to być trudne do wytłumaczenia osobie nietechnicznej, która zasadniczo uważa, że całe zadanie polega na połączeniu HTML-a i stworzeniu tabeli do przechowywania danych. Dla nich może to być 2 godziny MAKS.
Czy jest więc lepszy sposób na wyjaśnienie, dlaczego szacunek jest wysoki dla osób niebędących programistami?
communication
estimation
Mag20
źródło
źródło
Odpowiedzi:
Właśnie to zrobiłeś w swoim pytaniu.
Podziel zadanie na poszczególne kroki i podaj szacunki dla każdego z nich. To pokaże, że wziąłeś pod uwagę wszystkie opcje i (miejmy nadzieję) uwzględniłeś wszystkie ewentualności.
Jeśli ramy czasowe są zbyt duże, możesz przedyskutować, które części (np. Potwierdzenie e-mailem) nie są potrzebne w tym przypadku, z konkretnymi danymi, zamiast po prostu próbować wcisnąć kwartę do kufla piwa.
Rób to wystarczająco często, a mam nadzieję, że nauczysz ich, że rozwój jest zwykle większy niż na pierwszy rzut oka.
źródło
Wyliczanie zadań jest prawie idealne, ale pamiętaj, że zadania, które mają doskonały sens dla inżyniera, nie mają większego sensu dla osoby nietechnicznej. Na przykład z powyższej listy wiem, że „optymalizacja zmian DB pod kątem szybkości” może być jednym lub kilkoma czasochłonnymi zadaniami, które obejmują profilowanie kodu, uruchamianie go w poszukiwaniu wolnych punktów, przeglądanie go z ekspertami lub przerzucanie go przez zestaw predefiniowanych testów specyficznych dla produktu. A potem prawdopodobnie masz kilka godzin, jeśli nie dni, waląc głową w biurko, próbując znaleźć sposób na naprawienie zbyt wolnych obszarów.
Być może jednak straciłeś zarządzanie projektami słowem „DB”, jeśli nie słowem „optymalizuj”.
Ogólnie rzecz biorąc, wyrażam to w zarządzaniu projektami w kategoriach DUŻYCH kroków słowami opisującymi ryzyko w kontekście biznesu. Biorąc twoją listę, sprowadziłbym ją w ten sposób, gdybym rozmawiał z moim kierownikiem projektu:
Unikałbym wszelkich szacunków, które są krótsze niż pół dnia. Będą musieli zaufać, na pewnym poziomie, że wiesz, o czym mówisz. A jeśli naprawdę myślą, że to będą tylko 2 godziny, zaproś ich, aby usiedli z tobą przez 2 godziny, podczas gdy przeprowadzisz ich dokładnie tak, jak wygląda 2 godziny w życiu programisty SW - a następnie zrób kodowanie klasy 101 dla około 2 godzin, aby dokładnie pokazać, co należy wziąć pod uwagę, aby nawet zacząć rozwiązywać problem.
Najważniejsze są następujące rzeczy:
źródło
Jest takie powiedzenie: „Nie zmieścisz dziesięciu funtów (badziewia) w pięciofuntowej torbie”. Twoim zadaniem jest wykazanie, że zadanie to dziesięć funtów, a oni proszą o wykonanie go w terminie pięciu funtów.
Jedyne, czego brakuje, to szacunkowe czasy. Dla każdego zadania określ przybliżony czas i pokaż, jak wszystkie te elementy składają się na szacowany koszt. Nie pozwól, aby szacunek był dłuższy niż 4 godziny. Jeśli masz jakieś zadanie, w którym mówisz „dzień” lub „10 godzin”, podziel je na mniejsze podzadania.
Teraz masz szczegółowy wykaz kosztów. Ogólnie rzecz biorąc, daje to do 27 godzin pracy.
Możesz teraz pokazać to swojemu klientowi i powiedzieć: „To są rzeczy, które należy zrobić, kosztem każdego”. Użyj słowa „koszt”, ponieważ czas JEST kosztem, a kierownictwo rozumie koszty. Wyjaśnij, że prawdopodobnie możesz porzucić dwa zadania optymalizacji na końcu, ale będą one miały negatywny wpływ na później, i stanowią tylko 15% całkowitej wartości szacunkowej.
Upewnij się także, że realistycznie wyjaśnisz swoje godziny / dzień. Na przykład, jeśli jesteś wezwany do pomocy technicznej lub utrzymywania baz danych lub czegokolwiek, to uwzględnij to w swoich szacunkach. Nie mów „Cóż, potrafię robić 7,5 godziny dziennie dobrego kodowania”, ponieważ prawdopodobnie nie możesz. Prawdopodobnie jest to bardziej jak 5 lub 6.
Następnie, co najważniejsze, śledź swoje postępy. Powiedz, że możesz zrobić 5 godzin dziennie kodowania. Wtedy powinieneś być w stanie odrzucić dwa pierwsze zadania (w moim przykładzie) w poniedziałek, zakończyć trzecie i rozpocząć czwarte we wtorek i tak dalej. Stwórz listę kontrolną, która to pokazuje, abyś mógł pokazać je w środę, kiedy przyjdą i powiedz „Jak leci, czy nadal będziesz gotów do końca piątku?”
Zobacz moje slajdy do mojego wystąpienia Zapobieganie kryzysowi: szacowanie projektu i śledzenie, które działa, które dałem w OSCON kilka lat temu. Spójrz na slajd 21 „Planowanie tygodnia”. Istnieje również przykładowy wykres prędkości .
źródło
Poprosić ich:
Jak byś to zrobił? Które moduły byś zmienił? Ile wierszy kodu? Jakie są konsekwencje dla bezpieczeństwa? Wszelkie zmiany w schemacie bazy danych? Jeśli dokonasz zmiany w bazie danych, na ile plików ma to wpływ? Ile czasu zajęło dodanie ostatniego formularza? Jaka jest średnia (średnia arytmetyczna) dodania formularza? Co było najdłuższe? Ocenię, że zajmie to minutę mniej niż najdłużej. Jeśli nie wiesz, ile czasu zajęło dodanie ostatnich N formularzy, gwarantuje się, że szacunek ten będzie dokładny tylko do jednego rzędu wielkości.
źródło
Mógłbym powiedzieć, żebyś im wytłumaczył, że ich oprogramowanie jest jak 100-tonowa maszyna z 10 000 różnych części, z których wiele jest połączonych w skomplikowany sposób. Montaż 1-calowego elementu w tej maszynie wymaga pewnej inżynierii, aby nie złamała maszyny, ALE lepsza odpowiedź to:
Gdybyś miał lepszą architekturę kodu, czy takie zadania byłyby takie proste? Odpowiedź jest taka, że większość zespołów programistycznych nie jest dobrymi architektami (ponieważ po prostu nie zgromadzili ton ogólnych, architektonicznych szablonów lub nie są mistrzami w dziedzinie problemowej wystarczająco, aby przewidzieć każdy problem) i nie zawsze są dobrymi inżynierami , więc nie czują się pewnie w podawaniu szacunków lub składaniu obietnic.
Podobnie jak w XX wieku gromadzenie dobrej architektury i inżynierii do budowy dużych budynków, narzędzia do inżynierii oprogramowania po prostu nie znalazły się w głównym nurcie. Są rozwijane: wymaga nowego sposobu myślenia. Zobacz kod Zen na wiki.hackerspaces.org/Hacking_with_the_Tao.
źródło