Co zrobić, gdy klient ma nierealne oczekiwania? [Zamknięte]

Pracuję nad projektem przez ostatnie sześć miesięcy w witrynie klienta, ponieważ wymagają one poufności danych i nie chcą, abyśmy pracowali w naszym biurze.

Kiedy pojawiłem się sam na tej stronie klienta, powiedziano mi, że muszę ukończyć projekt za dwa miesiące.

Ponieważ klient nie jest firmą programistyczną, a ze względu na różne zasady zajęło mi około 20-25 dni, aby dać mi uprawnienia do zainstalowania na komputerze takich rzeczy, jak Eclipse, Tomcat itp. Nawet po opóźnieniu w konfiguracji środowiska, wciąż oczekiwali, że skończę projekt w tym samym dwumiesięcznym okresie.

Nie dostarczyli mi żadnych dokumentów wymagań, ale ponieważ pracuję w witrynie klienta, regularnie spotykaliśmy się w celu omówienia wymagań.

Po sześciu miesiącach aplikacja wciąż nie jest ukończona i wszyscy mnie obwiniają, ale nie zdają sobie sprawy, że dodaliśmy o wiele więcej funkcji niż te omówione na pierwszych spotkaniach.

W tym okresie musiałem przerobić wiele rzeczy, np. Podzielić formularz na dwie części; kilka tygodni później poprosili mnie o ponowne połączenie tych dwóch form, ponieważ jest to mylące i tak dalej.

Zakres aplikacji rośnie z każdym dniem, ale nadal uważają, że to dwumiesięczny projekt został opóźniony. Kiedy powiedziałem im, że zasięg się zwiększył, pytają, dlaczego na początku nie prosiłem o wymagania.

Pracuję już 11-12 godzin dziennie i podróżuję 3-4 godziny, a teraz oczekują, że przybędę także w soboty.

Muszę tutaj zrobić wszystko: wziąć wymagania, projekt, kod i przetestować.

Proszę mi doradzić, co mam zrobić w takim przypadku?

_{Dodatkowe informacje: Mieliśmy listę produktów do dostarczenia, ale dodali do niej jeszcze kilka rzeczy, mówiąc, że są one również ważne. Zmienili także kilka rezultatów. Nie mają nawet swojego serwera UAT, testują na mojej własnej maszynie programistycznej za pomocą adresu IP.}

To jest awaria twojego menedżera . Jako wykonawca nie powinieneś był być narażony na tak napięty termin w swojej firmie, jeśli nie miałby na piśmie określonego zestawu wymagań. Żadne z tych „dodanych funkcji” po tym bzdurach - za każdym razem, gdy to się stało, powinni podpisać się według zaktualizowanego harmonogramu, który im podałeś .

Twój menedżer, ponieważ planuje się z nim spotkać, musi uzyskać od klienta określony zestaw wymagań - projekt powinien wykonać A, B, C, D i E. A po jego zakończeniu jest on ukończony. Podpis klienta musi znajdować się w dokumencie potwierdzającym tę listę. Powinieneś był to mieć od samego początku.

Jeśli twój menedżer nie popiera cię i nie wspiera w tym - i nie mówię tego często - zacznij szukać innej pracy. Ponieważ prawdopodobnie staniesz się kozłem ofiarnym dla całego bałaganu. A jeśli chcesz pracować 11 godzin i 3 godziny dojazdu, to widać, że jesteś bardzo oddaną osobą, która zasługuje na coś lepszego.

W takich sytuacjach ważne jest zbudowanie papierowego szlaku CYA. Nic nie powinno być zrobione bez napisania tego, szczególnie w skomplikowanych relacjach biznesowych. Trzymanie się początkowego harmonogramu, choć potrzebowali 20 dni, aby nawet pozwolić ci pracować, to wielka czerwona flaga, że ​​stanie się skomplikowana.

Organizujesz spotkanie, na którym wymagane są dodatkowe funkcje? Zapisz następnie, oznacz „+ X dni do bieżącego harmonogramu” na każdym elemencie i wyślij pocztą e-mail do wszystkich zainteresowanych. Jeśli korzystasz tylko z wewnętrznego systemu pocztowego klienta, dodatkowo wydrukuj go, w tym listę odbiorców do :, cc: i bcc: adresatów i ostrożnie zarchiwizuj. Poza tym, jak powiedział GrandmasterB, klient powinien podpisać takie zmiany w pierwotnych wymaganiach.

Jeśli wymagany harmonogram nie może zostać dotrzymany, napisz go. Jeśli wystąpi jakakolwiek zmiana, napisz do nich, z podaniem konsekwencji. I tak dalej.

Nie chodzi o „tak wam mówiłem”. kiedy bałagan w końcu uderzy w ścianę - i tak nie będą go słuchać. Jest to twoje ubezpieczenie, gdy klient pozywa cię, ponieważ uważa, że ​​nie wypełniłeś umowy lub gdy twoja firma pozywa klienta, ponieważ odmawia zapłaty.

Z tego, co opisujesz, wynika, że ​​uczestniczysz w klasycznym projekcie Marszu Śmierci :

W zarządzaniu projektami , o marszu śmierci jest jedną z kilku typów projektów patologicznych z udziałem dysphemistic, ciemny humor analogia do rzeczywistych marszów śmierci, takie jak wyczerpująca przepracowanie oraz (często i najbardziej szczególnie) wyczerpująca przepracowanie z nieuzasadnionych przyczyn w projekcie, który jest oczywiście obarczony wysokim ryzykiem złych wyników (tj. niepowodzenia projektu i potencjalnie zagrożenia utraty osobistej i grupowej reputacji) . Tak więc nazwa „marsz śmierci” może być zastosowana do projektu, który ostatecznie odnosi sukces, ale obejmuje domową część niezrównoważonej przepracowania lub (być może częściej) do projektu, który każdy inteligentny, poinformowany członek może skazać na porażkę (lub jest na bardzo wysokie ryzyko niepowodzenia), ale mimo to członkowie są zmuszeni do działania przez swoich przełożonych ...

Zjawisko jest dobrze znane i istnieje wiele literatury na temat tego, jak postępować - w tym oczywiście przełomowa książka Edwarda Yourdona Death March: The Complete Software Developer's Guide to Surviving „Mission Impossible” Project .

Cytowany powyżej artykuł w Wikipedii stanowi dobry punkt wyjścia do szukania dodatkowych informacji, badań i rekomendacji dla osób zaangażowanych / zainteresowanych projektami marszu śmierci .

Chodząc w twoich butach, pierwszą rzeczą, o której pomyślałbym, byłoby przekazanie mojemu kierownikowi odniesienia do powyższego artykułu.

W ten sposób poinformują ich, że jestem świadomy tego, co się dzieje, a być może nawet pomogą mi poprowadzić mnie w zakresie ram przewidzianych dla tego pojęcia, takich jak: „Zobacz, nasz obecny stan jest zbliżony do opisanego w rozdziale Xw Yourdon. Sprawdź to. na zewnątrz, wraz ze ściśle powiązanym rozdziałem Yitp ... ”

W (mało prawdopodobnym) przypadku, gdy kierownik nie jest świadomy tego kierunku studiów, skierowanie może dać mu dużo do myślenia, co pomoże zidentyfikować sytuację i zdecydować, jak sobie z tym poradzić.

Szczerze mówiąc, jeśli możesz to zrobić, najlepszym rozwiązaniem jest rezygnacja. Sytuacje takie jak ta są dla ciebie toksyczne i rzadko poprawiają się z czasem, bez względu na to, jak bardzo się starasz.

Najlepiej zmniejszyć straty i znaleźć inny koncert. Zastanów się jednak nad swoim doświadczeniem i skorzystaj z rad z innych odpowiedzi w tym wątku.

To jest poważne issue in project management . Wygląda na to, że Project Managerpowinieneś pracować nad listą materiałów do dostarczenia i nadać im priorytety za pomocą klienta.

Co najważniejsze , twój PM should discussi uzgodnij z klientem ramy czasowe (w tym projekt i analizę problemu / rozwiązania) w swoich szacunkach.

Posiadanie clear estimation of your work loadi dostarczanie elementów projektu uwolni cię od stresu, a także doda ci spokoju i pewności w pracy.

Spróbuj zastosować podejście zwinne , dostarczając swoje produkty w sprincie (2-3 tygodnie) i wykonując UAT (test akceptacji użytkownika) z klientem. Pamiętaj, zawsze planuj sprint przed rozpoczęciem sprintu.

Edycja: Z komentarzy jasno wynika, że ​​to w rzeczywistości porażka kierownika projektu . Brak odpowiedniego środowiska testowego i / lub programistycznego dla poważnego projektu, takiego jak twój, jest dużą dziurą dla projectprocesu SDLC.

Chociaż zgadzam się, że jest to błąd zarządzania, jest to również błąd z twojej strony. Na tym etapie będzie to bardzo trudne do naprawienia, więc część z tego, co musisz z tego zrobić, to sposób obsługi przyszłych projektów.

Najpierw musisz nalegać, aby na początku projektu istniał dokument dotyczący wymagań. Nie musi to być wymyślne ani formalne, ale nie można niczego zbudować, dopóki klient nie określi, czego się oczekuje. Jeśli nie masz tego na piśmie, szanse na zadowolenie klienta z efektu końcowego wynoszą około 0%. Jest to więc niezwykle ważne. Twoim zadaniem jest poszukiwanie niejasności w tym dokumencie i jak najszybsze ich wyjaśnienie. Gdy natkniesz się na jedną z nich i nie wiesz, jak ją interpretować, nie zgaduj, co to znaczy, upewnij się, że ty i klient jesteście na tej samej stronie, co to znaczy. Tak, oznacza to więcej rozmów z ludźmi i więcej spotkań oraz mniej kodowania. Ale wyjaśnienie niejasnego wymogu zajmuje znacznie mniej czasu niż błędne zakodowanie go, a następnie ponowne kodowanie. Co więcej, często musisz dać im ponowne kodowanie za darmo, co nie jest dobre dla firmy, w której pracujesz.

Następnie mówisz im, ile czasu zajmuje wykonanie pracy, a to wyznacza termin. Nigdy nie akceptujesz terminu, który jest oparty na czymkolwiek innym niż ilość godzin potrzebnych do wykonania pracy w celu spełnienia wymagań. Jeśli to zrobisz, znów będziesz w marszu śmierci. Pokaż im, w jaki sposób nie jest możliwe dotrzymanie terminu, dokonując szczegółowego objaśnienia godzin. Nie możesz zmieścić 200 godzin czasu programowania w jednym tygodniu, mając tylko 1 programistę, bez względu na to, jak bardzo klient tego chce. W tym momencie, w którym termin jest nieruchomy, pytasz, jakie przedmioty należy przenieść do następnej iteracji.

Nie zapominaj, że czas opracowywania to tylko niewielka część czasu projektu przy szacowaniu czasu projektu. Musisz także wziąć pod uwagę spotkania i komunikację e-mail / telefon, testowanie, wdrażanie, dokumentację, fizyczną konfigurację serwerów, stacji roboczych, oprogramowania. Ponadto, planując termin, możesz założyć, że masz do dyspozycji 6 godzin dziennie, a nie 8. To ma na celu uwzględnienie urlopu, żałoby, zwolnienia lekarskiego, nieuniknionego opóźnienia (na przykład, kiedy musiałeś czekać, aż otrzymają uprawnienia) w sieci itp.), szkolenia, prace niezwiązane z projektami (harmonogramy, spotkania HR itp.). Jednym z największych powodów, dla których ludzie nie dotrzymują terminów, jest założenie, że będą się rozwijać i pracować 8 godzin solidnie każdego dnia. To po prostu nie jest realistyczne założenie.

I za każdym razem, gdy dodają kolejny utwór, mówisz im, ile czasu to zajmie i ile dodatkowej pracy przesunie termin. Nie prosisz o przesunięcie terminu, mówisz im, że zmienia się z powodu nowego wymogu. Teraz powinieneś porozmawiać o tym ze swoim menedżerem, ale przede wszystkim twoją odpowiedzialnością jest upewnienie się, że menedżer wie za każdym razem, gdy wymaganie jest zmieniane, i ile to doda do projektu. Upewnij się, że wszystko to jest w formie pisemnej, abyś mógł się bronić w razie potrzeby.

Następnie, nie pozwól, by cię wykorzystano do pracy w 11-godzinne dni i weekendy. W krótkich okresach jest to OK (mniej niż 1 tydzień co sześć miesięcy), ale w dłuższej perspektywie jest to po prostu niedopuszczalne. Zmęczeni ludzie kodują wolniej i popełniają więcej błędów. Możesz osiągnąć więcej dzięki lepszej jakości pracy regularnie 8 godzin niż regularnie 11 godzin. i weekendy.

Odkryłem, że wykresy Gantta mogą być bardzo dobre w takich sytuacjach. Mogą zilustrować klientom bieżący harmonogram i mogą być przydatne w zilustrowaniu efektu dodania nowych funkcji / zmian. Czasami powiedzenie klientowi, że funkcja x wpłynie na dostawę w ciągu y dni, nie zarejestruje się u niego. Mając to wyraźnie na wykresie, mogą lepiej to zrozumieć.

Najlepiej byłoby to zrobić od początku projektu. Wyjaśnienie „ opóźnień ” do tego momentu może nie być tak przydatne , ale może pomóc w kontynuowaniu projektu.

Z Wiki :

Wykresy Gantta ilustrują daty rozpoczęcia i zakończenia elementów końcowych i elementów podsumowujących projektu.