Jaką odpowiedź mam udzielić?

Ta odpowiedź dotyczy roli programisty ( bez bezpośrednich podwładnych ) :

Prosta odpowiedź brzmi: prawda . A w tym konkretnym przypadku, jeśli wiesz , że termin nie zostanie dotrzymany, najlepszym rozwiązaniem jest dostarczenie prawdy raczej wcześniej niż później .

Zasadniczo chcą wiedzieć, że nie zamierzasz ukrywać faktu, że nie dotrzymasz terminu i nie boisz się prosić o pomoc .

Nigdy nie dostaniesz takiej pracy, powtarzając odpowiedź, którą otrzymałeś na takiej stronie, jak ta. Musisz nauczyć się odpowiadać na to pytanie swoimi słowami, korzystając ze swojego doświadczenia i przykładów, których faktycznie byłeś częścią. To powiedziawszy, możesz znaleźć lepszą odpowiedź, aby udzielić im następnym razem. Kluczem jest zrozumienie, dlaczego o to pytają. Uważają, że wiedzą, co robić, a czego nie robić w tej sytuacji, i chcą zobaczyć, czy Ty też to robisz.

Dobra odpowiedź będzie zawierać dwie rzeczy. Po pierwsze, powinieneś być w stanie łatwo wymienić opcje: poinformowanie klienta, że ​​termin nie zostanie dotrzymany, porzucenie części pracy, tego typu rzeczy. Ta lista nie powinna zawierać rzeczy, które nie będą działać, takich jak dodawanie osób do projektu. Po drugie, powinieneś być w stanie wyjaśnić, w jaki sposób wybrałbyś jedną z tych opcji i jak byś się komunikował w danej sytuacji. Jeśli powiesz po prostu „Chciałbym X” bez żadnego wyjaśnienia, dlaczego X zamiast Y, to nie jest dobra odpowiedź.

Jeśli ubiegasz się o stanowisko kierownika projektu, będą oczekiwać nieco innych opcji i procesy myślowe, niż gdybyś aplikował jako programista pracujący bez wsparcia PM, ale podstawowe „Miałbym wybór X lub Y, nie rozważałbym A ani B, a wybrałbym X lub Y na podstawie Z ”nadal tam będzie.

Jeśli nie masz na to dobrej odpowiedzi i zostałeś o nią zapytany więcej niż raz, uzyskaj dobrą odpowiedź. Na pewno stawiłeś temu czoła? Nawet jeśli widziałeś, jak ktoś inny zajmuje się tym, a nie sam? Co zadziałało, co nie, co zrobiłeś wcześniej w tej sytuacji? Lepiej opowiadaj tę historię.

Jest to również okazja, po udzieleniu odpowiedzi na pytanie , aby porozmawiać o tym, jak ważne jest, aby nie wpaść w taką sytuację i co zrobić, aby temu zapobiec. Mogą to być regularne spotkania dotyczące statusu, częste publikacje, opieranie się pełzaniu zakresu, monitorowanie postępów lub dowolna liczba innych technik, których nauczyłeś się w swojej pracy. Ankieter chce wiedzieć, co umiesz robić.

Jako programista nie jest moim zadaniem omawianie tego rodzaju problemów z klientem, a jako programista nie mogę nic zrobić osobiście, aby naprawić problem.

Dlatego jedynym rozsądnym działaniem jest jak najszybsze skontaktowanie się z kierownikiem programu, aby uświadomić im, że jest problem i przedyskutować z nimi, co można zrobić, aby przywrócić projekt na dobrej drodze.

Odpowiedzią może być przydzielenie większej liczby osób do pracy, negocjowanie późniejszego terminu z klientem lub kilka innych opcji. Ale to nie moja decyzja.

Albo co oni spodziewają się usłyszeć?

Chcą zobaczyć, jak myślisz i przetwarzasz tego rodzaju pytania.

Nie chcą widzieć, jak próbujesz im powiedzieć to, co myślisz, że chcą usłyszeć. Nie chcą usłyszeć gotowej odpowiedzi.

To trudne, ale staraj się nie zgadywać, co chcą usłyszeć. Zamiast tego wysłuchaj pytania, przemyśl je i odpowiedz szczerze. Spróbuj postawić się w pozowanej sytuacji i powiedz im, jak byś zareagował.

A jeśli rzeczywiście spotkałeś się z taką sytuacją, upewnij się, że wskazałeś, że masz, co zrobiłeś i jeśli chcesz znowu to samo.

Zabawne, że to było jedno z pytań, na które moja odpowiedź (chyba) dała mi jedną z moich poprzednich prac. To nie była dobra robota, bo takie sytuacje się tam zdarzały. Ale to było istotne dla tej pracy (i powinno dać mi wskazówkę, żeby tego nie brać).

Wspomniałem o tym, co zrobiliśmy w jednym z projektów, w których brałem udział:

Byliśmy w sytuacja niemożliwa: w małej firmie kontrakt pozwolił nam przetrwać kilka miesięcy. Było to rozszerzenie naszego systemu (księgowego), które chcieliśmy wdrożyć, ale termin wykonania tego był niemożliwy. Więc i tak zaczęliśmy go wdrażać, z naszymi najlepszymi przypuszczeniami, jak to zrobić, i opublikowaliśmy duży dokument z wieloma pytaniami z pytaniami, jak dokładnie chcą, aby nowa funkcja została zaimplementowana. Powiedzieliśmy im, że minie X miesięcy od otrzymania ostatecznych odpowiedzi.

Zgadnij, co: zajęło im miesiące uzgodnienie między sobą, czego dokładnie chcą, podczas gdy my wdrażali najlepsze przypuszczenia. Dostaliśmy kontrakt, dostaliśmy kilka kamieni milowych od klienta. W większości przypadków zgadywaliśmy dobrze, w kilku przypadkach musieliśmy przeprojektować, kilka funkcji zostało przeniesionych do fazy drugiej, ale firma przetrwała, by walczyć innego dnia.

Nie jestem pewien, czy możesz po prostu sfałszować taką odpowiedź (ponieważ to jest prawdziwa historia wojenna, każde dodatkowe pytanie może ujawnić, że jesteś fałszywy, jeśli tego nie przeżyłeś).

W sytuacji `` żyj albo zgiń '', jesteś zmuszony ryzykować z nadzieją że będziesz miał szczęście, bo jeśli nie, kompania i tak zginie. Nikt nie pisze o setkach startupów, które upadły, wspomina się tylko o tych, które odniosły sukces. Zobacz błąd dotyczący przetrwania - zakładasz, że przeżyjesz.

Zgodnie z Team Software Process (opracowanym przez Carnegie Mellon University), musisz komunikować się z Interesariuszami, gdy tylko zespół dowie się, że termin nie może zostać dotrzymany. Pozwala to wszystkim zainteresowanym stronom na zmianę planu, usunięcie funkcji lub podjęcie działań w celu rozwiązania problemu (niedotrzymania terminu).

Według Miesiąca Mythical Man Fredricka Brooksa Jr. dodanie większej liczby osób do projektu nie skróci harmonogramu.

Jeśli chodzi o zarządzanie projektami, istnieje trójkąt z bokami zakresu, czasu i budżetu. Jeśli zmieni się jeden ze stron (długość), pozostałe dwa również muszą się zmienić.

A więc, aby odpowiedzieć na pytanie ankietera:

1. Oblicz nowy termin w oparciu o obecne okoliczności. Określ prawdopodobieństwo pomyślnego dotrzymania terminu.
2. Oblicz czas potrzebny do ukończenia pozostałych wymagań. Określ prawdopodobieństwo dotrzymania terminu za pomocą tej techniki.
3. Oblicz nowy termin na podstawie dodania zasobów do projektu. Dothis dla 1 osoby do 5 osób. Określ prawdopodobieństwo dotrzymania terminu za pomocą tej techniki.
4. Zwołaj spotkanie z interesariuszami w celu omówienia sytuacji i planowania. Skorzystaj z informacji z punktów 1, 2 i 3 powyżej.

Informacje z punktów 1, 2 i 3 powinny pochodzić od członków zespołu (wykonujących pracę). Są najbliżej projektu i potrafią udzielić informacji z najwyższym stopniem pewności.

IMHO, planuj sesje nadgodzinowe tylko wtedy, gdy czas ukończenia jest mały. Nie ma gwarancji, że praca w godzinach nadliczbowych poprawi jakość produktu; czasami nadgodziny mogą spowodować więcej problemów i wydłużyć harmonogram.

W jednym sklepie, w którym pracowałem, wymagania zostały usunięte z projektu w celu skrócenia harmonogramu.

To byłaby moja odpowiedź, gdyby moja rola była kierownikiem projektu :

Jeśli uważam, że nie dotrzymamy terminu, pierwszą rzeczą, którą muszę ustalić ile potrzeba pod względem siły roboczej i innych zasobów, aby osiągnąć cel.

Następnie powinienem udać się do mojego kierownictwa i razem możemy przeprowadzić ocenę, czy warto wydać dodatkowe zasoby, aby aby zakończyć projekt.

Jeśli kierownictwo naciska na dodatkowe zasoby, udałbym się do klienta i wyjaśniłbym sytuację oraz zaleciłbym ograniczenie zakresu prac, aż do momentu, gdy praca stanie się wykonalna w ramach czasowych. Pracowałbym z klientem, aby ustalić priorytety pracy, aby zminimalizować wpływ klienta.

Jeśli klient odmówi ograniczenia zakresu lub omówienia priorytetu pracy, dokładnie przeanalizowałbym wymagania, aby zobaczyć, na czym zestaw rezultatów, który ogranicza szkody dla reputacji mojej firmy, a ponadto wszelkie kary finansowe, które miałyby zastosowanie. Chciałbym bardzo jasno powiedzieć klientowi, co zostanie dostarczone w tych ramach czasowych, aby złagodzić wpływ klienta.

Wyobrażam sobie, że w niektórych sytuacjach klienci mogą być bardziej otwarci na renegocjacje, gdy zdadzą sobie sprawę, że nie dostaną wszystkiego, czego chcą i chcą mieć lepszą kontrolę nad tym, co otrzymują. Mogą też chcieć przesunąć „twardy” termin.

Oczywiście szkoda, że ​​każdy projekt doprowadziłby do punktu, w którym pod koniec byłaby wielka niespodzianka. Idealnie byłoby, gdybyśmy śledzili postępy, co pozwoliłoby nam na stopniowe modyfikowanie zakresu prac, aby zapewnić spełnienie najważniejszych wymagań.

Wcześniej zadawałem takie pytanie, więc nie jest to rzadkie. Moim zdaniem jedyna prawidłowa odpowiedź jest następująca:

Ktoś gdzieś schrzanił, żeby się tu dostać, teraz zrobimy to najlepiej, organizując spotkanie awaryjne i zobaczymy, co jest możliwe zamiast tego, co nie jest.

Świadomość, że ci się nie uda, a zrobienie tego i tak byłaby złą odpowiedzią. Jeśli nie można tego zrobić, nie można tego zrobić. Jednak często napotkasz sytuacje, które wyglądają , jakby proszą cię o zrobienie niemożliwego.

Absolutnym kluczem jest tutaj znalezienie tego, co jest możliwe i stamtąd pracować. To nie jest kwestia inżynierii oprogramowania. To jest kwestia zarządzania oczekiwaniami, radzenia sobie z nieoczekiwanymi i utrzymania projektu razem.

Oznacza to również, że szukają czegoś więcej niż kogoś, kto po prostu pisze kod. Szukają kogoś z powiewem umiejętności menedżerskich lub przynajmniej dowiadują się, czy je masz. Ponieważ bez względu na to, jakiej odpowiedzi im udzielisz, jak dasz im odpowiedź, powie im wiele o tym, jak myślisz o projektach.

Możliwą kontynuacją może być (albo jako pytanie od nich lub jako odpowiedź od Ciebie, jeśli oczekują długich odpowiedzi), jak poradzić sobie z opadem i zmniejszyć ryzyko ponownego wystąpienia.

Jest więc termin, którego nie można dotrzymać. Cokolwiek odpowiesz, cokolwiek zrobisz, jedyną rzeczą, która się nie wydarzy, jest dotrzymanie terminu. Oto, co Ty i Twój menedżer możecie zrobić:

1. Jak najszybciej powiadom swojego menedżera, aby dał mu szansę zminimalizowania szkód. Niedotrzymanie terminu i straty finansowe w wysokości 10 000 USD są o wiele lepsze niż przekroczenie terminu i straty finansowe w wysokości 100 000 USD.

2. Nie panikuj, uspokój się i uspokój wszystkich innych. Poważnie. Widziałem dorosłych trzepoczących wokół jak bezgłowe kurczaki w takich sytuacjach. Zrobiłem to samo kiedyś, kiedy byłem dużo młodszy i wyciągnąłem z tego naukę. Teraz wiem, że zamiast trzepotać się w kółko i nic nie robić, zmieniasz problem w głowie z nierozwiązywalnego „Jak dotrzymać terminu, którego nie da się dotrzymać” na „Jak zminimalizować szkody”.

3. Metoda, która nie działa, to pośpiech lub próba dodania większej liczby osób. Pomocne jest skłonienie ludzi do robienia rzeczy drugorzędnych. Na przykład, jeśli masz napisać kod i wypróbować go, piszesz kod, a ktoś inny go wypróbuje. Inną metodą, z której może skorzystać Twój menedżer, jest poprawa zdolności do przepracowywania większej liczby godzin. 100 m od mojego miejsca pracy jest ładny hotel. Mogę spędzić więcej godzin, jeśli mój szef zapłaci za mnie za pobyt w tym hotelu i zamawia zdrową żywność w porze lunchu, a zdrową żywność o 17:00. Pewnego razu ktoś musiał być w moim domu, aby odebrać dostawę mebli. Moja żona szefa to zrobiła. Nie była szczęśliwa, ale mój szef potrzebował mnie do pracy. Takie rzeczy też są dość motywujące.

4. Istnieją dwie oczywiste metody wcześniejszego ukończenia: Obniż jakość i zmniejsz liczbę funkcji. To wymaga omówienia.

5. Istnieje oczywista metoda dotrzymania terminu, o którym ludzie często zapominają (ponieważ patrz punkt 2): przesuń termin. Bardzo niewiele terminów jest nie do przesunięcia. Zobacz genialną metodę Petera M. Gratulacje, jeśli możesz to zrobić. Często łatwiej jest po prostu negocjować. Prawdopodobnie zrobiono to o jeden lub dwa poziomy nad tobą. Ale jeśli wyjaśnisz klientowi, że nie ma szans na otrzymanie obiecanej rzeczy w obiecanym czasie, może on wydłużyć termin lub nic nie dostać.

6. Mam nadzieję, że do tego nie dojdzie, ale największe szanse na przeżycie ma pierwszy szczur, który wyskoczy z tonącego statku.

Wydaje mi się, że niektórzy z innych konstruują zbyt słabą wersję „twardego terminu”.

Nigdy nie byłem PM, ale nieraz musiałem powiedzieć prawdę CEO, gdy wszyscy inni, w tym premier, który powinien był wiedzieć, milczeli. Mamy pewne wymagania prawne, a gdy wymagania prawa się zmienią, musimy zmienić nasz kod, aby był zgodny, a terminy są ustalane przez rząd. Prawda była taka: „Ten dzień już minął”.

Byłem tam od dawna. Wiedziałem, ile czasu zajmie od wewnętrznej wersji inżynierskiej do produkcji. Właśnie przejrzałem protokoły testów i wiedziałem, jak długo potrwa test. Miałem naprawdę dobre oszacowanie liczby elementów odesłanych do testów, które zakończyły się niepowodzeniem, zastosowałem niską wartość czasu realizacji i naprawdę dobrą wartość, jeśli chodzi o czas ponownego testowania. Zsumowałem liczby i okazało się, że mamy -1 dni na dalszy rozwój. Nie pamiętam, jak poszło wyjaśnienie tego wszystkiego (co stało się natychmiast), ale pamiętam tylko moją wstępną wypowiedź.

Ze względu na ograniczenia kontroli źródła, na których kierownictwo wcześniej nie zwracało uwagi, mogliśmy nie zdecydować się na porzucenie ukończonych funkcji, aby zwolnić czas testowania, więc tych rzeczy nie można było poprawić.

Niestety nie mogłem im powiedzieć, ile dni mogliby realistycznie oczekiwać, więc nie zaakceptowali mojej odpowiedzi. Jednak podczas wewnętrznej demonstracji wymaganych przez regulacje funkcji w następnym tygodniu kierownictwo poprosiło o wprowadzenie do nich gruntownych zmian. Idź do dzieła.

Skończyło się na tym, że dostarczaliśmy półtora miesiąca późno

Między młotem a kowadłem? Wejdź na drugą stronę skały i zaoferuj klientowi demo częściowej funkcjonalności w 1/2 czasu przed terminem. Zaskoczysz ich i wciągniesz do rozmowy. Przynosząc je co tydzień, aby omówić, jakie funkcje zostały zwiększone w tym tygodniu, szybko dowiesz się, że ich wymagania nie były w 100% tego, czego potrzebowały, a zanim upłynie termin, możesz mieć „coś”, z czego mogą korzystać, nawet jeśli jest sprawny w 80%, wyprzedzasz konkurencję wodospadu.

Biorąc wszystko, co zostało powiedziane za dobrą monetę, najlepszą opcją jest potraktowanie dalszej pracy nad tym projektem jako stratę czasu i przejście do następnego projektu. Co nie jest decyzją programisty.

W prawdziwym życiu tak się nie dzieje. Byłem w takich sytuacjach, a rozwiązaniem w zasadzie było dać klientowi to, co chciał zobaczyć. Który zmienił się z nieczytelnych danych (niezupełnie właściwy format, ale nie celowo) na fałszywe dane (wygenerowane lub testowe dane przechodzące przez procedury zapisu), na rzeczy przygotowane z ręczną interwencją, ręcznie wybrane przykłady robocze do rzeczywistych.

Może to wymagać współpracy z firmą, która faktycznie zawiera umowę, w celu przekonania dalszych odbiorców, aby również zagrali w tę grę: rzeczy muszą wyglądać tak, jakby brakowało ich tak mało, że rezygnacja z przerwania nie miałaby sensu.

brałem podwykonawstwo od niekompetentnych kontrahentów, z dobrymi relacjami biznesowymi i dobrze płacącymi, gdzie głównym priorytetem było zawsze zadbać o ochronę, bezpiecznie obliczać terminy i dostarczać działające i dobrze udokumentowane materiały, które za każdym razem musieli podpisywać ponieważ projekt rządzący z całą pewnością zmierzał do lądowania awaryjnego, a ty nie chciałeś być kozłem ofiarnym pod rozpadającym się podwoziem.

Ten pożar śmieci został odwołany około dwa lata po „twardym” dea dline, długo po tym, jak dostarczyłem i odebrałem. To jest powód, dla którego właściwą reakcją na pewną porażkę w przypadku twardego terminu rzadko jest poddanie się: niektóre terminy mogą skutkować karami, których chce się uniknąć. Ale terminy zabijania trwającego projektu na dobre są rzadkie, a ostateczna decyzja może zapaść w czasie, którego nie jesteś świadomy.