Jak wytłumaczyć nietechnicznej osobie, dlaczego zadanie potrwa znacznie dłużej niż myśli? [Zamknięte]

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?

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.

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:

1. Po pierwsze, składają się na to dwie części - strona internetowa, którą widzi użytkownik, i serwer, który wykonuje ciężkie prace. Obie części muszą tam być, aby ta funkcja działała.
2. Pierwszą częścią będzie stworzenie strony internetowej, która ma sens dla użytkownika (dodaj front-end HTML, dodaj javascript po stronie klienta). Kluczem tutaj jest to, że strona internetowa musi wyglądać, jakby była częścią tego produktu, musi działać we wszystkich obsługiwanych przez nas przeglądarkach i musi być zręczna. To, co widzi użytkownik, więc jeśli źle wygląda, pomyśli, że nasz produkt jest zły. Rozwinięcie tego, a następnie przetestowanie zajmie X dni.
3. Następnie pod stroną internetową muszą znajdować się rzeczy, które wykonują pracę. W tym przypadku oznacza to wstaw tutaj opis funkcji (mapy do - dokonaj pewnych zmian w bazie danych, napisz kod po stronie serwera, zaimplementuj potwierdzenie e-mail, dodaj weryfikację, użyj testów jednostkowych). Nie mogę tego tak po prostu zrzucić. Jeśli kod zostanie opracowany, a następnie przetestowany, ryzykujemy uszkodzenie danych WSZYSTKICH użytkowników. Oznacza to, że prosta nowa rzecz może zaszkodzić reputacji produktu na całym świecie - nawet dla użytkowników, którzy nie korzystają z tej konkretnej funkcji. Nasze praktyki programistyczne obejmują to - przeprowadzamy wiele testów, aby upewnić się, że tak się nie stanie - ale to oznacza, że ​​muszę odpowiednio wcześnie zaplanować, aby to przetestować. To zajmie mi Y dni.
4. Szybkość to wielka sprawa w naszym produkcie. Jeśli coś nie dzieje się szybko, użytkownicy pomyślą, że produkt nie jest dobry. Więc po napisaniu tych wszystkich rzeczy muszę przejść przez całą pracę i upewnić się, że jest na równi pod względem wydajności. Jest to wielka sprawa w przypadku treści internetowych - jeśli ludzie zobaczą, że strona działa wolno, szybko przejdą do innego produktu, aby zaspokoić tę samą potrzebę, ponieważ naprawdę trudno dostrzec różnicę między powolnym a zepsutym. Tego rodzaju praca zwykle zajmuje Z dni (optymalizacja zmian DB pod kątem prędkości, refaktoryzacja i optymalizacja kodu pod kątem prędkości)

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:

• Kup, mówiąc głównie o postrzeganiu klientów i korzystaniu z produktów, zbliżasz się do mówienia w ich języku - języku $$ - chodzi o to, że jeśli kod zostanie zhakowany razem w tandetny sposób, w końcu stracisz biznes - jeśli nie na tej funkcji, a następnie na pewnej kolejnej funkcji, gdy słabe praktyki programistyczne uniemożliwiły rozszerzenie kodu.
• Określ sekwencję zdarzeń. Kolejne nietechniczne pytanie brzmi: „jeśli mamy więcej programistów niż ciebie, czy byłoby to szybsze? Jeśli tak, to jeśli zajmie to 40 godzin, czy 40 osób może to zrobić tego popołudnia?” Oczywiście odpowiedź brzmi: „NIE! JESTEŚ SIĘ POZWALAĆ ??”. Ale to nie jest najlepsze. Najlepsze jest to, że jest tutaj logiczna sekwencja kroków. Rzeczy B nie można zrobić, dopóki nie pojawi się rzecz A (jeśli nie napisałeś żadnego kodu, nie możesz go tak naprawdę zoptymalizować ani przetestować ...). Rzeczy A i A można jednak zrobić razem, więc jeśli mogliby oszczędzić tego mądrego faceta, moglibyście skrócić czas z tygodnia do 4 dni, a jeśli mogliby zagwarantować niesamowite wsparcie testowe, prawdopodobnie moglibyście dostać 3 dni. Tam'
• Skoncentruj się na ryzyku i przygotuj się na informację, że niektóre rodzaje ryzyka są w tej chwili tego warte. Za to ludzie biznesu dostają wielkie pieniądze - zastanawianie się, jakie ryzyko warto podjąć. Na przykład, jeśli szybkość wprowadzania na rynek ma negatywny wpływ na wydajność, ponieważ Twoja firma ma wystarczającą ilość gotówki, aby w krótkim okresie wprowadzić absurdalną liczbę serwerów, możesz zostać poproszony o pominięcie wszystkich tych rzeczy w kroku 4 (optymalizacja kodu / bazy danych ). Tak mają rację - Twoim zadaniem jest wyjaśnienie ryzyka związanego z tą decyzją.
• Jeśli jednak nie ufasz tym ludziom, otrzymaj potwierdzenie na piśmie - nie musi to być konfrontacyjny, wystarczy szybki e-mail z informacją: „oto, o czym myślę, że rozmawialiśmy, oto, czego nie robię, oto Zrobię to teraz, więc daj mi znać, jeśli się nie zgadzasz ... jeśli nie otrzymam wiadomości, zakładam, że jest to właściwy sposób postępowania ". Biorąc pod uwagę, że zarządzanie produktem może być centrum krótkotrwałej utraty pamięci, jest to bardzo pomocne dla wszystkich.

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.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

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 .

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.

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.