Jak odpowiedzieć „Kiedy to się stanie?”

Wszyscy to mamy, problemy, które okazują się trudne do rozwiązania i wypracowanie poprawki za pomocą niejasnego kodu i dziwnej nieoczekiwanej funkcjonalności. Powoli, logicznie pracując na własną rękę, próbując znaleźć wzorce, błędy, błędy. Ten proces wymaga czasu, a problemy często nie są łatwe do zrozumienia przez klienta.

Jak można odpowiedzieć na pytanie „Kiedy to będzie zrobione?”, Zwłaszcza gdy klient może nie zrozumieć nieodłącznych zawiłości związanych z tworzeniem oprogramowania?

Odpowiadasz na pytanie szczerze.

Mówisz im, że to trudny problem, rozwiązanie nie jest oczywiste i nie masz pewności, ile czasu zajmie jego rozwiązanie. Obiecuj aktualizować je o postępach co [ramy czasowe], aby wiedzieli, że nad tym pracujesz, i oczywiście wysyłali im aktualizacje.

Programiści podchodzą do złożonego problemu, rozkładając go na mniejsze i rozwiązując je osobno.

W idealnym świecie rozwiązanie problemu byłoby złożonym problemem A, a w danym momencie byłbyś w stanie go rozłożyć na krótką listę małych problemów od A ₁ do A _n , ponieważ każda ocena czasu jest prosta, biorąc pod uwagę czas potrzebny na rozwiązanie początkowego złożonego problemu wynosiłby:

gdzie D jest samym procesem rozkładu.

W prawdziwym świecie jedynym problemem jest to, że t ( D ) byłby w rzeczywistości większy niż czas poświęcony na rozwiązanie drobnych problemów. Innymi słowy, aby dostać się do tego poziomu rozkładu problemu, praktycznie musisz rozwiązać sam problem.

Ciągle możesz:

• Podziel dane zadanie (rozwiązanie problemu) na mniejsze części, przy czym każda część nadal stanowi złożony problem,

• Oceń oczekiwany czas dla każdej porcji i odpowiadające jej ryzyko.

  Na przykład zadanie 1 wymaga około. 5 godzin, ale ryzyko, że zostaniesz zablokowany, jest wysokie, więc daj klientom 12 godzin na oczekiwanie.

• Oceń zależności i ich wpływ na czas.

  Na przykład zadanie 19 wymaga 2 godzin, a ryzyko jest tak niskie, że można powiedzieć, że na pewno 2 godziny. Nie 1. Nie 3. Ale zadanie 19 opiera się na zadaniu 24: zadanie 24 może wpłynąć na zadanie 19 w sposób, który wymagałby całkowitego przepisania kodu zadania 19 przy użyciu innego podejścia.

• Podaj wszystkie te szczegóły swojemu klientowi. Nie dawaj sumy.

Ostatni punkt jest ważny. Jeśli podasz sumę, powiedzmy 192 godziny, klient uważa, że ​​jest to bardzo precyzyjna miara, a czas, który spędzisz, wynosi, powiedzmy, 189 do 195 godzin.

Jeśli zamiast tego podajesz szczegóły,

• Klient, któremu zależy, zrozumie, że to nie 192 godziny. To 192 godziny, jeśli wszystko pójdzie nie tak, biorąc pod uwagę ryzyko określone podczas oceny. To również 238 godzin, jeśli wszystko pójdzie jeszcze gorzej. To również 85 godzin, jeśli wszystko jest w porządku.

• Jeśli chodzi o klienta, który go nie obchodzi, nie przeczyta on twojej odpowiedzi we wszystkich przypadkach. Wszystko, czego chce, to liczba, by móc cię później winić. Udzielając bardzo szczegółowej odpowiedzi, której nigdy nie przeczyta, wiesz, że nie może cię zapytać o czas, jaki zajmie to ponownie: już odpowiedziałeś na to. Nie może cię też później winić, ponieważ nie przeczytał odpowiedzi, aby obliczyć sumę.

Cokolwiek szacujesz, nie zapomnij uwzględnić prawa Hofstadtera : zawsze trwa to dłużej niż się spodziewasz, nawet jeśli weźmiesz pod uwagę prawo Hofstadtera.

Zazwyczaj używam zmodyfikowanej formuły z CPM / PERT. To jest coś takiego:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(Nie jestem pewien, jak wykonać wymyślne formatowanie matematyczne; jeśli ktoś chce to w tym celu edytować, nie krępuj się).

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

Chciałbym podkreślić, że może się znacznie różnić w zależności od przebiegu projektu. Jeśli dokonujesz ponownej oceny projektu co kilka dni, możesz nawet dostarczyć cotygodniową aktualizację. To długa droga do zadowolenia drażliwych klientów. :)

Wyjaśnianie niejasnych terminów użytkownikom nietechnicznym jest trudne. Odnosi się to zarówno do kreatywnych faz projektu, jak i do śledzenia nieznośnego błędu. W obu przypadkach tradycyjne „rozkładanie pracy na mniejsze kawałki” również nie działa.

Pierwotne zadanie koncentruje się na tym drugim przypadku, więc zastanówmy się nad tym. Jeśli nie możesz podać osi czasu, powiedz użytkownikowi, co spróbujesz i kiedy do niego wrócisz. Po osiągnięciu punktu w połowie na narzuconej osi czasu przekaż krótką i uczciwą aktualizację wiadomości e-mail. Co najmniej godzinę przed upływem terminu udziel formalną odpowiedź. Teraz masz wiarygodność. Jeśli problem nie zostanie rozwiązany, przynajmniej świecisz światłem. To może wydawać się stratą czasu, ale tak nie jest.

Ponieważ nie możesz uwzględnić nieznanych przeszkód i nieprzewidzianych niespodzianek, oszacowanie ich z pewnością może być trudne. Pomysły:

• Wypróbuj zakres - „Jestem pewien, że zajmie to co najmniej N dni (np. 3), ale może zająć nawet 4 N. ”
• Poproś starszych inżynierów o pomoc w szacowaniu i obronie szacunków.
• Pracuj w krótszych iteracjach (w stylu Agile / Scrum), aby stworzyć minimalny kod, który doda wartość biznesową (zyskując pewność siebie i zaufanie), a następnie powtórz.
• Naucz się umiejętności negocjacyjnych z książki takiej jak klasyczny Jak się dostać (http://www.amazon.com/gp/aw/d/0143118757).

W przypadku nowego rozwoju, zwłaszcza rozwoju zwinnego:

„Doskonałość zostaje osiągnięta, nie wtedy, gdy nie ma już nic do dodania, ale kiedy nie ma już nic do zabrania”. - Antoine de Saint-Exuper

Jeśli szacujesz wysiłek i czas na naprawienie niektórych prawie niemożliwych do odtworzenia błędów (błędów) w ohydnie nadmiernie złożonym systemie z bardzo niewielką liczbą programistów posiadających niewielką wiedzę na temat systemu, to jedyną prawidłową odpowiedzią jest „Kiedy zostanie naprawiony”.

Zazwyczaj mówiłbym im prawdę. Powiedziałbym im, że nie wiem teraz, a za tydzień będę miał lepszy wgląd. Wręczyłbym im park piłek z tyloma zawijasami przed sobą, ile można zmieścić na papierze, aby wskazać, że jest to zgadywanka oparta na przeczuciu. Jeśli zaczną cię ostro naciskać, po prostu zacznij każde zdanie od „Jest to możliwe ...” Zwykle każdy, dla kogo robię, jest zadowolony z „Sprawdź za tydzień, ale teraz wszystko, co mogę powiedzieć, to około 2 miesięcy” czy jakoś tak.

Proces oprogramowania osobistego (PSP) koncentruje się na poprawianiu szacunków. Osiąga się to poprzez zdyscyplinowane rejestrowanie zadań. To w zasadzie „przyspiesza” część „szacowania” doświadczenia, ponieważ będziesz mieć rzeczywiste dane o typowych zadaniach. Oczywiście zawód ten wciąż wymaga unikalnych rozwiązań wielu problemów, ale z mojego doświadczenia wynika, że ​​szacunki są lepsze po użyciu PSP.