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

23

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.

ashishjmeshram
źródło
11
Zrobisz to szybciej, jeśli pracujesz tylko przez 8 godzin i nie ma weekendów. Wyczerpanie ogranicza twoją produktywność. alternet.org/visions/154518/…
HLGEM
10
Wygląda na to, że jesteś kozłem ofiarnym kogoś innego
Czy możesz dodać edycję wyjaśniającą, w jaki sposób rozwiązano tę sytuację? Może pomóc przyszłym czytelnikom, jeśli znajdą się w podobnej sytuacji.
Radu Murzea
Gdzie znalazłeś swoją nową pracę?
Mawg,

Odpowiedzi:

65

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.

Grandmaster B.
źródło
Kiedy rozmawiałem na ten temat z moim menedżerem, był bardzo pomocny. Ale wszystko zależy od tego, co dzieje się teraz podczas spotkania :(
ashishjmeshram,
1
Z mojego doświadczenia wynika, że ​​programiści bardzo szybko obwiniają zarządzanie za wszystko, co idzie nie tak ... Pierwsza część Bold prawie zniechęciła mnie do przeczytania tej bardzo dobrej odpowiedzi. Jeśli menedżer nie był świadomy problemu, trudno jest go całkowicie winić (chociaż dobry menedżer „po prostu wie”, co się dzieje, bez względu na to, co mu powiedziano). Deweloper powinien wcześniej zwrócić uwagę menedżerów na takie kwestie, jak to.
mattnz
1
Myślę, że w tym przypadku znalazł się w sytuacji bez uzgodnienia niezbędnych wymagań na wystarczającym poziomie szczegółowości lub przynajmniej bez wyraźnego wskazania, jaki organ miał do czynienia ze zmianami klienta w zakresie projektu . Oba są problemami zarządzania. W tym drugim przypadku, jeśli chodziło o to, że będzie on obsługiwał klienta, należało wyjaśnić mu, że tak było, oraz w jakim zakresie może on dostosować ich oferty i daty dostawy dla klienta.
GrandmasterB
1
@GrandmasterB. Niemal tydzień po spotkaniu wiele powiedziano o robieniu rzeczy w bardziej zorganizowany sposób, ale nic się nie zmieniło. Próbowałem wymienić wszystkie rzeczy, które omawialiśmy podczas spotkań dotyczących wymagań i wysyłania wiadomości e-mail do klientów. Nikt nie zadał sobie trudu, aby je przeczytać, a zamiast tego dostałem to od klientów „Musiałeś stracić godzinę na pisanie tego e-maila”. :(
ashishjmeshram
1
Jestem ciekawy, jak to się skończyło. Twój klient jest ignorantem i samolubny. Nie słuchają cię, ponieważ nie muszą. Musisz złożyć stanowcze oświadczenie, że nie możesz dłużej pracować w ten sposób. Więc odszedłeś? A może mimo to ukończyłeś pracę?
Forza,
21

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.

Bezpieczne
źródło
16

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ć.

komar
źródło
11

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.

bitopy
źródło
2
To nie jest zła odpowiedź, proszę nie głosować bez wyjaśnienia. Tak, to jest jak cięcie węzła gordyjskiego, ale sądząc z sytuacji OP opisanej (i jego desperacji) może to być najlepsza rzecz, jaką może zrobić. Praca + podróż 14 godzin plus praca w soboty? Wygląda na to, że twoje zdrowie fizyczne i psychiczne jest poważnie zagrożone.
Tamás Szelei,
1
Z doświadczenia wynika, że ​​tego rodzaju sytuacja jest rzeczywiście spowodowana kulturą firmy i będzie wymagać osób, które obecnie nie cierpią z powodu tej sytuacji. Zmiana takiej kultury będzie prawie niemożliwa.
deadalnix
Dlaczego nie jest to najbardziej aktualna i akceptowana odpowiedź? quit++;
Mawg
11

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.

wprowadź opis zdjęcia tutaj

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.

EL Yusubov
źródło
2
Mieliśmy listę produktów do dostarczenia. Ale dodają jeszcze kilka rzeczy, mówiąc, że są one również ważne. Zmieniają także kilka rzeczy na liście produktów. Nie mają nawet swojego serwera UAT, testują na mojej własnej maszynie programistycznej za pomocą adresu IP.
ashishjmeshram
To są ludzie biznesu. Nie rozumieją projektowania itp. Rzeczy. Początkowo próbowałem im to wyjaśnić, ale wszystko, co powiedzieli, nie obchodzi nas, jak to robisz, ale rób to tak, jak tego chcemy.
ashishjmeshram
2
+1 za podejście zwinne. Zrób to i trzymaj się tego, jak najbardziej.
Bruno Schäpper,
1
@Vain Felloman - „+1” oznacza, że ​​głosujesz za odpowiedzią.
mouviciel
@mouviciel Yap. nie ja? O ile mi
wiadomo,
10

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.

HLGEM
źródło
1
Dziękuję za odpowiedź. Bardzo dobre punkty do zbadania.
ashishjmeshram
+1 za „Nie prosisz o przesunięcie terminu, mówisz im, że się zmienia z powodu nowego wymagania”. Wskazuje to, że termin nie jest czymś, co wymyśliłeś, ale nieodłączną właściwością projektu.
sleske
1
you need to insist ona a requirements baseline document at the start of the project, Next, you tell them how long it takes to do the work and that sets the deadline., And every time they add another piece on, you tell them how much longer it will take and how much the additional work will move the deadline. Świetna rada, ale będąc w takiej sytuacji, kiedy już został zwolniony w mniej niż miesiąc za to, że niemożliwe do pracy z pozornie. Prawdziwa sytuacja to, jak mówią inni, tego rodzaju firmy chcą kozłów ofiarnych i wymówek, a nie produktywnych realistycznych twórców oprogramowania.
wałek klonowy
4

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.

AidanO
źródło
Jeśli odpowiedź zostanie odrzucona, proszę dać mi znać, dlaczego. Dzięki.
AidanO
1
+1 - Wykresy Gantta mogą być oldschoolowe, ale wygląda na to, że klient nie kupuje projektu, więc coś tak prostego jak wykres Gantta może pokazać im efekt dodatkowych wymagań.
dave