Jestem programistą w pięcioosobowym zespole i wierzę, że nasz projekt zmierza w kierunku katastrofy. Opiszę za chwilę, ale moje pytanie brzmi: jak mam się zachować?

Termin upływa za 1,5 miesiąca i wydaje mi się, że bez względu na to, co zrobimy, ten projekt się nie powiedzie. Uważam, że powinniśmy po prostu zakończyć projekt i przestać marnować nasz czas, ale politycznie myślę, że nasz menedżer nie jest w stanie tego zrobić.

Co powinienem zrobić w tym przypadku? Czy powinienem włożyć dodatkowy wysiłek, czy powinienem to po prostu wyluzować? A co powinienem powiedzieć kierownikowi?

Powody niepowodzenia tego projektu:

• Ze względu na zbliżający się termin wiele niezbędnych funkcji nie zostało jeszcze ukończonych
• Aplikacja jest niestabilna i bardzo trudna w użyciu
• System jest bardzo skomplikowany, kod bardzo trudny do zrozumienia, bardzo trudny do zmiany - model danych jest zbyt sterowany przez złożoną relacyjną bazę danych (ponad 100 tabel)
• Niejasne przywództwo; menedżer reaguje na nowe informacje poważnymi zmianami
• Prawie nie ma testów automatycznych ani testów jednostkowych
• Silnie zależy od innych systemów, ale nie ma jeszcze testów integracyjnych

W rzeczywistości odziedziczyliśmy ten projekt (wraz z bałaganem) około 1-2 miesiące temu od innego zespołu deweloperów pod tym samym menedżerem, który pracował nad nim przez kilka miesięcy.

Przekaż swoje obawy w najbardziej zwięzły i niekonfrontacyjny sposób na drabinie zarządzania. Podsumuj ryzyko, ale nie narzucaj im swoich wniosków.

Kierownictwo musi zawsze mieć wybór, co robić, ale Twoim zadaniem jest ocenić i zakomunikować sytuację. Użyj poczty e-mail, aby zostawić ślad papieru, gdy rzeczy idą na południe.

Po wykonaniu tej czynności, pracuj nad projektem w dobrej wierze.

Pamiętaj, że możesz nie wiedzieć wszystkiego o projekcie, jego projektantach i decyzjach finansowych. Decyzje zarządcze, które wydają ci się głupie, mogą w rzeczywistości opierać się na inteligentnym rozumowaniu, które jest dla ciebie niewidoczne.

Zachowaj ślad papieru (np. Pamiętnik, zapisane wiadomości e-mail itp.). Uwzględnij tylko fakty i obiektywne obserwacje. Pozostaw wszystkie wnioski każdemu (jeśli ktoś) przeczyta to, co napisałeś.

Jako programista, jeśli nie jesteś postrzegany jako przeszkoda dla projektu, prawdopodobnie dobrze wyjdziesz z palca, co bez wątpienia się wydarzy. Twój menedżer może nie mieć tyle szczęścia, ale tutaj nie ma to znaczenia.

Tylko na ogólnych zasadach, zaktualizuj swoje CV i upewnij się, że od czasu do czasu spotykasz się z innymi deweloperami spoza Twojej firmy. Jeśli nie należysz do żadnej lokalnej grupy programistów, dołącz do 2 lub 3. Budowa sieci przyjaciół i znajomych zajmuje lata, ale na dłuższą metę warto. Pamiętaj, aby spojrzeć na to jak na dwukierunkową ulicę - jeśli możesz pomóc w wypełnieniu otwarcia w swojej firmie kimś zdolnym, to jest tak samo dobry, jak ktoś, kto pomaga ci znaleźć pracę.

Polecam poświęcić trochę czasu na przeczytanie 2 książek.

Death March to kanoniczna książka opisująca patologiczny styl zarządzania projektami, szeroko rozpowszechniony w rozwoju oprogramowania. Ze względu na kompresję harmonogramu, wzdęcia lub złe zarządzanie wiele projektów kończy się w złym stanie; pomaga zrozumieć, że nie jesteś sam, a twój projekt nie jest jedynym marszem śmierci. Autor Edward Yourdon dzieli ślepe projekty na 4 ćwiartki, z których każda ma inne strategie radzenia sobie. Czasami jedyną strategią radzenia sobie jest odejście. Myślę, że ta książka pomoże ci ustalić, jaki masz zakres opcji, i zawęzić zakres możliwości.

Katastrofa Disentanglement jest napisana więcej dla kierowników projektów. Ma na celu zastanowienie się, jak segregować zepsuty projekt: co należy wyciąć, co można wyciąć i jak przekazać to klientom? „Konwencjonalne” zarządzanie projektami programowymi wpędza nas w bałaganiarskie projekty i nie unikniemy naszych problemów, stosując to samo myślenie, które nas wciągnęło. Ta książka jest nieco trudniejsza do przeczytania niż Marsz Śmierci , ale dobrze jest ją mieć na półce.

3 proste i cyniczne strategie utrzymania kariery / zdrowia psychicznego.

1. Zobacz powstający wrak pociągu - wysiadaj z pociągu: Nieudane projekty są straszne dla morale i jeśli nie posiadasz umiejętności zarządzania ninja w górę, będzie to miało negatywny wpływ na twoją karierę. Skacz teraz, jeśli widzisz jakieś miękkie lądowanie.

2. Jeśli to nie zadziała, nie spuszczaj głowy: ludzie zaczną szukać ludzi, których można winić - nie ułatwiaj im! Choć eskalacja obaw w łańcuchu zarządzania może być słuszna, jest to nieefektywne i ryzykowne. Twój menedżer raczej nie przekaże twoich obaw, a ominięcie go nie tylko sprawi, że oboje będziesz wyglądać źle, ale może sprawić, że staniesz się „kłopotliwym”, tj. Osobą, której można winić za osłabienie projektu w pierwszej kolejności itp. To oczywiście oznacza również profesjonalizację, poświęcanie czasu, ale brak heroizmu.

3. Zaplanuj wyjście awaryjne na T + 1: daj sobie kilka opcji i zrób podstawy dla potencjalnego transferu wewnętrznego lub zewnętrznego już teraz. Rozmawiać z ludźmi; nie ma powodu, aby czekać, aż inni zdecydują, co zrobić z tobą, gdy finansowanie projektu zostanie zmniejszone, lub pogrążyć się w nieuniknionym „bałaganie” ludzi migrujących za kilka miesięcy.

Przepraszam, jeśli to brzmi zbyt cynicznie, ale jeśli poprawnie to nazwałeś, nie ma plusów, aby cierpieć z powodu nieprzyjemności na twojej drodze. Bądź profesjonalistą, bądź optymistą, ale zawsze bądź realistą.

Jaki wpływ będzie miał ten niedługo zakończony niepowodzeniem projekt na twoją karierę w firmie i poza nią? Z mojego doświadczenia wynika, że ​​samo bycie związanym z udanymi projektami nie jest wskaźnikiem Twojej osobistej doskonałości.

Cechy, które przejawiasz w obliczu przeciwności losu, a czasem coś, co wygląda na pewną porażkę, często zostaje zauważone przez przełożonych, bardziej niż myślisz. I mówię o tym poza twoim bezpośrednim kierownikiem.

Osobiście doświadczyłem, jak mój bezpośredni menedżer został zwolniony z powodu niekompetencji, a następnie tego samego dnia awansowałem na jego stanowisko. Nie było przyjemnie, ale pokazało, że ludzie mnie obserwują i podobają mi się to, co zrobiłem.

Często ten sam chaos i dezorganizacja, które towarzyszą nieudanemu projektowi, dają ci szansę zabłysnąć.

Spójrz więc na projekt w ten sposób: jaką szansę daje ten upadający projekt, aby światło świeciło na wszystkie moje mocne strony i najlepsze cechy? Czego się uczę z tego doświadczenia, dzięki czemu będę lepszym profesjonalistą i lepszą osobą?

Zasadniczo, suma doświadczeń wyciągniętych z porażek jest tym, co napędza prawdziwy sukces.

Uwaga: Thomas Owens zapytał, jakie konkretne rzeczy osoba może zrobić w takim projekcie. Mam kilka ogólnych sugestii, które wykorzystałem jako osobiste wytyczne w takich sytuacjach. Czy pomoże to cudownemu projektowi w niebezpieczeństwie? Nie - ale odkryłem, że pomogło mi to zachować właściwy punkt widzenia i znaleźć osobisty sukces pomimo złej sytuacji.

1) Skoncentruj się na osobistej doskonałości - staraj się pisać coraz lepszy kod, spełniaj coraz wyższe standardy jakości i funkcjonalności.

2) Skoncentruj się na danych osobowych - ile piszesz kodu, który powoduje kolejne błędy? Zmniejsz ten stosunek do jak najniższego. Czy jesteś poproszony o podanie szacunkowej wartości przypisanego zadania, czy ogólnie jesteś dokładny, czy też uważasz, że zbytnio lub za mało buforowałeś oś czasu zbyt mocno? Czy po przydzieleniu zadania zapewniasz dobry poziom informacji zwrotnych na temat postępu prac, w tym z wyprzedzeniem z wyprzedzeniem informując o problemach z harmonogramem dostaw?

3) Skoncentruj się na wskaźnikach zespołu - to tylko niektóre rzeczy z mojej głowy: Czy inni członkowie zespołu pozostają w tyle z powodu zależności od zadania, nad którym pracujesz? Czy jesteś dobry w delegowaniu lub podziale zadania / podzadań na inne osoby w zespole? Czy masz trudności z komunikacją z jednym lub kilkoma członkami zespołu? Wszystkie obszary, nad którymi pracuję, aby regularnie się ulepszać.

W takiej sytuacji, jako najniższy szczebel drabiny, możesz tylko tyle zrobić, aby pomóc projektowi.

• Upewnij się, że Twoja praca jest bez skazy
• pomóc zidentyfikować największe obszary problemowe
• Spróbuj udzielić odpowiedzi, a nie tylko problemów. Wygląda na to, że próbujesz je naprawić.

Poza tym naprawdę musisz dbać o numer 1.

• Dokumentuj wszystko
• zachowaj wszystkie e-maile, rozmowy IM
• Spróbuj znaleźć wyjście z projektu, jeśli to możliwe

Nieudane projekty mogą być toksyczne dla duszy, powodować depresję, nadmierną pracę i niską samoocenę.

Wszystko zależy od perspektywy.

Pracowałem nad okropnymi projektami, siedząc naprzeciw innego faceta, który codziennie miał uśmiech na twarzy. Och, jak chciałem wymazać ten uśmiech z jego twarzy.

Niektórym ludziom nie przeszkadza obecny stan rzeczy w projekcie. Cieszy ich wkład, zadania i praca w dziedzinie ich zainteresowań. Podczas gdy inni mają silną negatywną reakcję na obecny stan rzeczy. Chodzi o nasze spostrzegane oczekiwania dotyczące codziennych zadań.

Podczas gdy możesz wykonywać część pracy, którą lubisz. W obecnym projekcie wyraźnie znajdują się elementy, których nie lubisz.

Musisz zidentyfikować te elementy problemu i rozwiązać je.

• presja terminu
• kontrola jakości
• profesjonalizm
• wskazówki kierownictwa

Istnieje wiele zespołów i firm, dla których powyższe aspekty rozwoju nie są ważne. Znalazłem to, że często myślą:

• Presja związana z terminem postrzegana jest jako sposób na motywowanie ludzi.
• Jakość kosztuje więcej i limit zwrotów.
• Profesjonalizm dotyczy także innych obszarów działalności.
• Menedżer jest mierzącym czas, a nie osobą, która przyczynia się do rozwoju.

Te problemy nie są twoje. Jest ich i nie powinieneś marnować energii na ich zachowanie. Jeśli nie jesteś jednym z facetów, którzy uśmiechają się i lubią swoją pracę, nawet gdy zmierza ona do urwiska, powinieneś pomyśleć o znalezieniu miejsca dla like mindedprogramistów.

Będziesz znacznie szczęśliwszy.

Staraj się proaktywnie szukać nowego sposobu osiągnięcia sukcesu w projekcie. Zastanów się, jak możesz zaproponować alternatywne rozwiązania. W tej chwili twój szef prawdopodobnie zaczyna bić się z powodu niepowodzenia projektu, czy nie doceniłby kogoś, kto wpadłby na rozwiązania zamiast problemów?

Może istnieje sposób na podzielenie funkcji na rozłożone elementy? Często istnieją stopnie „must have”, więc sprawdź, czy możesz ustawić te priorytety i pogrupować je w kamienie milowe. Lepiej mieć jakiś produkt na końcu osi czasu niż nic. Lub rozważ podzielenie zespołu między osoby pracujące nad nową funkcjonalnością a innymi pracującymi nad stabilnością, w ten sposób możesz pokazać pewne postępy na obu frontach.

Jeśli te wysiłki się powiodą, pokażesz, że jesteś członkiem zespołu, który może znaleźć sposób na odniesienie sukcesu, jeśli nie, nadal będziesz demonstrować, że się nie poddajesz i będziesz pracował nad znalezieniem rozwiązania.

Brzmi jak większość projektów, w których byłem. Jednak prawdopodobnie nie skończy się tak źle, jak myślisz:

1) Wykonuj swoją pracę. Nie przejmuj się tak bardzo ogólnym projektem, o ile wypełnisz swoje obowiązki.

2) CYA. Jeśli projekt się nie powiedzie i podejrzewasz, że kierownik zacznie obwiniać wszystkich oprócz siebie, upewnij się, że masz wystarczający dowód na to, że zrobiłeś wszystko, co od ciebie wymagane (patrz punkt 1).

3) Podaj kilka grzecznych sugestii dotyczących ulepszeń. Nie dzwony ostrzegawcze, nie bądź zgubą i mrocznością, bądź po prostu uprzejmy i subtelny.

Na przykład, jeśli zespół nie pisze skutecznych testów jednostkowych (lub jakichkolwiek testów), napisz kilka testów jednostkowych bliżej tego, co chciałbyś zobaczyć i przyczynowo wspomnij, w jaki sposób pomogło ci to rozwiązać konkretny problem lub zaoszczędzić czas.

Cokolwiek by się nie stało, jeśli chcesz wpłynąć na zmianę, skoncentruj się na pozytywnych krokach, które mają konkretne wyniki. Ten projekt może nigdy nie okazać się zwycięzcą, ale może zespół może się nauczyć na następny.

Również:

4) Oportunistyczne refaktoryzowanie jest twoim przyjacielem.

1. Pracuj ciężko; ale nie kosztem rodziny ani zdrowia.
2. Rejestruj wszystkie krytyczne decyzje projektowe; szczególnie, gdy dotyczą twojej pracy.
3. Utrzymuj sieć i utrzymuj otwarte opcje, jeśli sytuacja stanie się zbyt trudna lub staniesz się ofiarą masowego zwolnienia.
4. Staraj się nie myśleć o swoim projekcie jako o „nieudanym projekcie”. Wszyscy lubią ludzi, którzy zachowują się pozytywnie i walczą w obliczu przeciwności losu. Tak długo, jak to możliwe, staraj się być tą osobą. Pozytywne nastawienie, charakter i determinacja są zawsze dobre dla miejsca pracy.
5. Jeśli spodziewasz się nieudanego projektu, oczekujesz spotkania pośmiertnego. Podczas sekcji zwłok wszyscy zostaną pociągnięci do odpowiedzialności. Przygotuj się do obrony całego swojego kodu. [Uwaga: Zasadniczo zawsze powinieneś pisać czysty kod, aby później łatwo go obronić.] Jeśli masz e-mail lub dokument projektowy, który zainspirował twoje decyzje, to nawet lepiej.
6. Na spotkaniu pośmiertnym staraj się pozostać pozytywnym; i tylko przedstawić swój e-mail i projektowania dowodów dokumentu, jeśli orzeczenie, wysiłek, lub wykonanie podważa.

Najbardziej efektywne okazało się zalecenie Roberta L. Reada dotyczące walki z presją związaną z harmonogramem . Oto, co pisze Read:

Kluczem do walki z presją związaną z harmonogramem jest po prostu przekształcenie go w presję na wprowadzenie na rynek. Sposób, aby to zrobić, aby uzyskać wgląd w związek między dostępną siłą roboczą a produktem. Najlepszym sposobem na to jest sporządzenie rzetelnego, szczegółowego, a przede wszystkim zrozumiałego oszacowania wszystkich zaangażowanych pracowników. Ma tę dodatkową zaletę, że umożliwia podejmowanie dobrych decyzji zarządczych dotyczących możliwych kompromisów funkcjonalnych.

Kluczowym spostrzeżeniem, które szacunki muszą wyjaśnić, jest to, że poród jest prawie nieściśliwym płynem. Nie możesz zapakować więcej w krótkim czasie, niż możesz zapakować więcej wody do pojemnika ponad objętością tego pojemnika. W pewnym sensie programista nigdy nie powinien mówić „nie”, a raczej „co poświęcisz, aby dostać to, czego chcesz?”. Wynikiem jasnych szacunków będzie zwiększenie szacunku dla programistów. Tak zachowują się inni profesjonaliści. Ciężka praca programistów będzie widoczna. Ustalenie nierealistycznego harmonogramu będzie również boleśnie oczywiste dla wszystkich. Programiści nie mogą zostać oszukani. Proszenie ich o zrobienie czegoś nierealnego jest pozbawione szacunku i demoralizujące.

Kiedy mówisz, że projekt „zmierza w kierunku niepowodzenia”, jest to oparte na twojej ocenie, jakie zadania należy wykonać i ile wysiłku wymagać będzie każde z nich. Spraw, aby ocena była wyraźna , zrozumiała i szczegółowa . Rozdziel zadania na części składowe; wyjaśnij tak szczegółowo, jak to możliwe, w jaki sposób zostanie spędzony czas programowania.

Gdy to zrobisz, będziesz mieć solidne podstawy do omawiania problemów z zarządem. Najprawdopodobniej po podzieleniu oceny na wszystkie konkretne zadania, które należy wykonać, będziesz w stanie wykazać, że praca zajmuje więcej czasu niż masz - być może znacznie więcej.

Po omówieniu tego szczegółowego harmonogramu ze swoim menedżerem bądź przygotowany na elastyczność. Twój menedżer może powiedzieć „Zadanie X nie zajmie miesiąca; zajmie to najwyżej tydzień” lub „Zadanie Y jest całkowicie niepotrzebne, odetnij to od harmonogramu”. Można oczywiście dyskutować te punkty, ale to, co jest o wiele ważniejsze jest to, aby osiągnąć porozumienie między wami a waszym mające na jakimś realistycznej wersji harmonogramu. W ten sposób, jeśli nie masz przydzielonego czasu, powiedzmy, na testowanie, masz wyraźną dyrektywę, aby nie testować, zamiast po prostu „nieoczekiwanie” kończyć się. I zdecydowanie możliwe jest, że Twój menedżer jest uprawniony do wyraźnego skrócenia niektórych rogów, aby wysłać na czas - istnieje wiele przypadków, w których „

Szacunek daje konkretną treść do dyskusji i dyskusji. To stawia cię na tej samej stronie; pomaga ci mieć pewność, że twój kierownik wziął pod uwagę twoje obawy. I prowadzi cię do tego, że jeśli twój menedżer wyraźnie prosi o niemożliwe, będzie to doskonale widoczne dla was obojga. Jeśli projekt jest dobrze i naprawdę skazany, wyraźnie to wyjaśnisz i to do twojego menedżera należy decyzja, w jaki sposób chcesz, abyś spędził czas.

Ponieważ twój menedżer wie, że to prawdopodobnie nie powiedzie się, jesteś lepiej niż większość. Rozważę współpracę z menedżerem i zobaczę, czy są jakieś części / funkcje aplikacji, które można wykluczyć.

Zbyt często uważamy, że każde żądanie klienta jest „zabójcą transakcji” i staramy się obiecać dostawę. Dopóki ktoś nie będzie współpracować z klientem i sondować głębiej, możesz nie być w stanie podjąć takich decyzji. Jeśli nie możesz tego zrobić, nadal staraj się dostarczyć to, co uważasz za najważniejsze. Czasami łatwiej prosić o wybaczenie niż o pozwolenie.

Brałem udział w trzech projektach, które były wyraźnie porażką. Były to dość bolesne, ale patrząc wstecz, dwie z trzech nie miały negatywnych konsekwencji dla mojej kariery, a nawet trzecia nie była końcem świata.

Oto niektóre spostrzeżenia, które pamiętam.

Deweloperzy na niższych stanowiskach („kod na specyfikację”, „napraw błąd” itp.) Nie mają większego wpływu, chyba że zwolnią z powodu obniżonego morale w zespole. Na takich pozycjach rozsądna, a czasem udana strategia przetrwania może być po prostu jak najlepiej.

• ^{Na przykład jedną z porażek, których doświadczyłem, udało się przezwyciężyć poprzez proste, metodyczne naprawianie ponad stu znanych błędów, które (w połączeniu ze szczególnie inteligentnym podejściem do promowania tego postępu przez lidera techniki) ostatecznie doprowadziły kierownictwo wyższego szczebla do decyzji o odzyskaniu projektu i to kolejna szansa z nowym wydaniem, które z kolei odniosło spory sukces.}

Programiści na wyższych, wpływowych stanowiskach byliby lepiej przygotowani do dzielenia się negatywnymi konsekwencjami niepowodzenia projektu. Oczekuje się, że architekt, lider technologii i starszy programista wywrze wystarczająco duży wpływ, aby uznać go za odpowiedzialnego za sukces lub porażkę projektu.

Na wyższym stanowisku lepiej byłoby przygotować się na porażkę „pośrednio”, analizując, co poszło nie tak i co można zrobić lepiej.

Te fragmenty wiedzy, poubojowe lekcje mogą być nieocenione, jeśli zostaną właściwie wyuczone, a bardzo udana kariera na wyższych stanowiskach może zależeć od tego, jak dobrze się je uczy, jak wyjaśniono w tej genialnej odpowiedzi na WP :

Osąd nie pochodzi z sukcesu, ale z porażek. Większość firm chce zatrudniać osoby, za które wcześniejsze awarie opłacały ...

Mówiąc bardziej praktycznie, można rozważyć podejście „następna / aktualizacja wydania” jako możliwe wyjście z awarii. Przypadkowo lub nie (chyba nie ), ale obie niepowodzenia, które nie zaszkodziły mojej karierze, przebiegały według bardzo podobnych scenariuszy: wydanie Nbyło całkowitą katastrofą, wydanie N+1było do zaakceptowania, wydania, N+2a później były zwykłym sukcesem.

Chodząc w twoich butach, zapewne włożyłbym trochę wysiłku w przygotowanie / promowanie idei „następnego wydania”. Zrób (i przekaż !) Coś w rodzaju wstępnej listy znanych problemów, które chciałbyś naprawić po planowanym wydaniu. Przygotuj nieformalną, przybliżoną mapę drogową dla następnych wydań.

Pomyśl, w jaki sposób możesz przekazać te pomysły ludziom wokół ciebie, jak wpłynąć na kierownictwo, aby rozważyć ten plan. Jeśli w projekcie jest ktoś z dobrymi umiejętnościami marketingowymi, spróbuj zaangażować go do amortyzacji szkód spowodowanych awarią, kończąc nadchodzące wydanie na bardziej płynnych warunkach, takich jak „wczesny dostęp”, „beta”, „podgląd klienta”, „wprowadzenie”, itp. że.

Pomyśl o planie tworzenia kopii zapasowych na wypadek, gdyby wyższy poziom wydawał się głuchy na ten pomysł. Pamiętasz powyższą historię o „naprawieniu ponad stu znanych błędów”? naprawdę jest szansa, że ​​coś się zmieni.

Kierownictwo może teraz wydawać się głuche na pomysły na kolejne wydanie, ale istnieje duża szansa, aby ponownie się zastanowili w obliczu silnych przekonujących dowodów na postęp jakości projektu.

• ^{Jest całkiem prawdopodobne, że pomiędzy zamrożeniem kodu a planowanym wydaniem a decyzją kierownictwa o jego całkowitym usunięciu będzie raczej długi czas. Ten czas jest twoją szansą: jeśli skoncentrujesz wysiłek na rozwiązaniu znanych problemów i właściwej „ewangelizacji” postępu, może to mieć znaczenie (tak jak kiedyś mi to zrobiło).}

Są tu już mnóstwo praktycznych (i nie tylko) porad, ale dla mnie kluczem do tej tajemnicy są dwa elementy (moje podkreślenie):

Termin upływa za 1,5 miesiąca

i

... właściwie odziedziczyliśmy ten projekt (wraz z bałaganem) około 1-2 miesiące temu od innego zespołu deweloperów pod tym samym menedżerem ...

Więc....

Witamy w Team Patsy The Avengers

Poprzedni zespół miał lepsze rzeczy do roboty ... niż porażka. I jakoś kierownik zgodził się z tym. Zmiana zespołów tak blisko terminu nie jest najlepszym krokiem w zarządzaniu projektami, więc ... o co chodzi?

Korekta: Poprzedni zespół został zastąpiony ~ 3 miesiące przed terminem.

-> Dowiedz się, jak udało się uciec poprzedniej grupie deweloperów, i zrób to. <-

3 miesiące to ledwie wystarczająco dużo czasu, aby przyśpieszyć system o tej pozornej wielkości, a tym bardziej poprawić jego architekturę, dodać testy i ukończyć go. Potrzebujesz więcej czasu

A jeśli nie możesz tego zrobić, chyba że masz absolutną pewność, że projekt zostanie przedłużony na czas nieokreślony, lub będzie wspomagany przez magiczne elfy lub coś w tym rodzaju, nie chcesz być ostatnim człowiekiem, który stoi z teczką.

Szorstki? Tak. Ale podczas złego planowania (co najmniej!) Po wcześniejszym zespołów / menedżerów nie jest twoja wina „niedostarczenie” będzie .

Poprzedni zespół został zwolniony za kaucją . Poprzedni zespół został wyrzucony z krawężnika. Co ci to mówi? Mówi mi, że jesteś zespołem zmieniającym ... a twój menedżer liczy na twoją heroiczność, aby uratować dzień.

Zespół 5-osobowy i pozostało 1,5 miesiąca. Nowy zespół miał projekt dopiero od 1-2 miesięcy, więc nowy zespół nie przekroczył nawet krzywej uczenia się . Biorąc pod uwagę przybliżoną wielkość tego projektu, wydaje mi się, że nie ma mowy, aby nowy zespół przekroczyłby krzywą uczenia się, nawet jeśli projekt nie miałby żadnych problemów.

Więc (nadal) myślę, że zostałeś oszołomiony.

Jeśli tak jest - i tylko Ty możesz zdecydować, co jest prawdą lub w co chcesz wierzyć - nie jesteś nikomu winien wyjaśnienia ani przeprosin za zejście z drogi temu wrakowi pociągu. Musisz być jednak dyskretny.

Wątpię poważnie, że kierownik nie zdaje sobie sprawy z tego, że projekt jest zagrożony, co oznacza, że ​​delikatne wyjaśnienia przyniosą jedynie negatywną uwagę. O ile kierownikiem nie jest pan Rogers , twoja przyszłość jest zagrożona.

Ale zawsze pamiętaj : nie korzystaj z porad nieznajomych w Internecie.

To dla ciebie niesamowita okazja! Weźmy w tym zakresie przedsiębiorczy punkt widzenia.

Zakładając, że kierownictwo chce, aby ten projekt się powiódł, jesteś w doskonałej pozycji, aby mu pomóc. Powodem, dla którego ta realizacja jest tak ważna, jest to, że musisz rozwinąć przekonanie i pewność, że znaki ostrzegawcze, które widzisz, faktycznie doprowadzą do niepowodzenia tego projektu [1].

To Twoja szansa na ćwiczenie ważnych umiejętności systematycznego myślenia i komunikacji interpersonalnej. Zrozum i zwizualizuj problemy i potencjalne możliwości, które są tracone, abyś mógł opracować strategię komunikowania się tak jasno i prosto, jak to możliwe.

Poznaj swoją szansę na poprawę swoich umiejętności.

[1] Rezygnacja z projektu byłaby faktycznie sukcesem. Niepowodzenie wydawałoby dobre pieniądze po złym.

Co możesz zrobić

• Potraktuj to w kategoriach własnej doskonałości, to „ich” projekt, ale także twój, przejmij na własność, nawet jeśli wiesz, że się nie uda. Dlaczego? ponieważ a) możesz pomóc mu trochę się nie udać, b) w czasie wyzwań, tutaj uczysz się najwięcej c) powinieneś mierzyć się za pomocą własnych mierników doskonałości, dokładanie starań może nie uratować projektu, ale możesz może być z ciebie dumny

• Porozmawiaj z innymi programistami i przekonaj się, co myślą. Prawdopodobnie przekonasz się, że wielu podziela tę samą frustrację, jeśli zrobisz to ostrożnie (nie każ ludziom myśleć, że chcesz rozpocząć bunt lub coś takiego), to może pomóc nie tylko tobie, ale inni też

• Zignorowanie problemu nie spowoduje, że odejdzie, mówiąc o sposobach, wbrew wszelkim przeciwnościom, wciąż go przezwyciężaj, np. Przynajmniej zdobądź trochę przyzwoitych must have, lub główny przypadek użycia „czynnika wow” zrobiony dobrze, może to zrobić projekt kończy się mniej żałośnie. Jak to zrobić? no cóż, kilka pomysłów na „kiedy ciężko jest iść na ciężko” lub „desperackie czasy usprawiedliwiają desperackie środki” i inne klisze, na przykład: masowe korzystanie z OSS, ekstremalne programowanie / zwinne metodyki, hackaton weekendowy (tylko wolontariusze, nie zmuszanie ludzi do weekendy pracy). To czas, w którym możesz wykazać się przywództwem (ostrożnie, jeśli nie zajmujesz stanowiska kierowniczego / wyższego szczebla), ale możesz skorzystać z tej przewagi i stać się ich kpiną, po prostu spraw, aby ludzie poczuli, że mogą otrzymać ten projekt tylko trochę mniej niż porażka niż wszyscy wiedzą, że tak będzie.

• Upewnij się, że twoje kierownictwo wie, ale bardzo, bardzo ostrożnie, jeśli wiedzą, docenią to, że im to powiesz w niekonfrontacyjny, spokojny sposób, jeśli nie, docenią to jeszcze bardziej i zastanawiają się, dlaczego nikt nie powiedział o tym wcześniej. Powinieneś powiedzieć im to jako usługę, bez jakiejkolwiek strony emocjonalnej, po prostu zwykłych faktów i bez planu. Jeśli zapytają cię, co według ciebie powinni zrobić (co jest świetnym znakiem, ale rzadkim), przejdź do następnej sekcji

Czego nie możesz zrobić, ale twoje kierownictwo prawdopodobnie powinno

• Nie powinni dodawać więcej osób do projektu, „aby” to zobaczyć

• Zadzwoń natychmiast do klienta i przekaż mu złe wieści. Dlaczego to dobry pomysł? Cóż, zostawię cytat z manifestu zwinnego tworzenia oprogramowania, ale nawet bez niego nawet miłośnicy wodospadów nie znoszą złych niespodzianek. Jeśli klient z góry wie, że ten projekt jest skazany na porażkę, będzie niezadowolony, ale będzie o wiele szczęśliwszy, gdy powiesz mu, że są problemy, zanim pojawi się na ich twarzy, i że jesteś przy nim, i starasz się jak najlepiej to. Klient może robić wiele rzeczy, ale większość z nich nie jest gorsza niż dowiadywanie się w ostatniej chwili, że nie ma dostawy (lub robią to, ale nie ma jakości użytecznej). Klient doceni to, ponieważ będzie mógł opóźnić zatrudnienie personelu testującego, pracowników IT offshore, zmienić swoje wewnętrzne plany szkoleniowe i wszystko tylko dlatego, że byłeś z nimi szczery.

• wraz z klientem pomyśl o sposobach zrobienia czegoś z projektu, najczęstszym jest opisywanie rzeczy. na przykład niektóre funkcje mogą być zbyt trudne do opracowania w sposób, w jaki zostały zaprojektowane, a jeśli klient zgodzi się na niewielkie modyfikacje i uproszczenia, niektóre funkcje staną się prostsze.

• Zaktualizuj swoje własne wyższe zarządzanie, pomoże im również utrzymać pracę ...

Czego NIE powinieneś robić

• Poproś o dodanie większej liczby osób do projektu (zobacz to )

• Porzuć / poszukaj innej pracy (przynajmniej jeszcze nie), to jest coś, z czego możesz się uczyć i co sprawi, że pewnego dnia będziesz lepszym programistą lub lepszym menedżerem. Nauczysz się doceniać wiele rzeczy lepiej, lepiej zarządzać czasem, lepiej projektować, pisać lepiej kod i pracować z rówieśnikami i zarządzaniem lepiej. Poszukaj pracy po upływie 2 miesięcy, jeśli nie lubisz tam pracować, nie z jakiegokolwiek innego powodu.

• Narzekaj, narzekaj lub negatywnie oceniaj projekt, zarządzanie, zły projekt, który odziedziczyłeś, nowi programiści, których musisz pamiętać, że zajmuje Ci to 3 godziny, aby wytłumaczyć im, że robią coś, co zajmuje Ci 1 godzinę, bądź pozytywny tak samo jak ty mogą.

• Krytykuj zarządzanie i stań się celem jako sprawca problemów, są na tej samej łodzi i mogą wiedzieć rzeczy, których ty nie wiesz, wszystko co możesz zrobić, to je zaktualizować (zawsze aktualizuj swojego bezpośredniego menedżera, nigdy go nie omijaj)

• Obwiniaj ludzi (lub siebie), to nigdy nie pomaga

• Weź to zbyt poważnie, chyba że chodzi o sprzęt medyczny, nikt nie umrze, jeśli dotrzymasz terminów, to oprogramowanie, dotrzymamy terminów życia, zrelaksujesz się.

To tylko moje dwa centy, YMMV

Znajdź problemy, na które natrafia Twój projekt i postaraj się jak najdokładniej oszacować. Z każdym obliczonym przez Ciebie „metryką” upewnij się, że określasz, dlaczego uważasz, że ta metryka jest ważna. Chcesz dać swojemu menedżerowi wgląd w konsekwencje, gdyby pewne dane nie były w „dopuszczalnym zakresie”. Musisz podać wytyczne dla każdej metryki, aby wskazać, które wartości są „dobre”, „dopuszczalne”, „problematyczne” lub „złe”. Zdefiniuj z góry każde kryterium. Jeśli to możliwe, możesz opisać, co byłoby minimalnie potrzebne do powodzenia projektu i porównać to z obecnym projektem.

• Jakość kodu statycznego można określić ilościowo za pomocą wielu narzędzi do analizy statycznej. Możesz zachować to tak proste lub szczegółowe, jak uważasz. Wskaźniki, które sugeruję zacząć od:
  • Złożoność cykliczna
  • Rozmiar twojego kodu (np. Liczba linii na funkcję / klasę, liczba plików, liczba tabel ...)
  • Zidentyfikuj, które moduły są zbyt duże
  • Powielanie.
  • Przestrzeganie stylu kodu
• Wskaźnik wad
  • według KLOC według modułu i / lub podsystemu (zidentyfikuj problematyczne części systemu)
  • możesz obliczyć ile na członka zespołu, ale myślę, że powinieneś zachować to dla siebie
  • rozwiązany vs znaleziony
  • czas potrzebny na rozwiązanie błędu (być może, jeśli jest to skłonne, zrób wykres tego)
  • być może oszacuj, ile czasu potrzeba, jeśli będzie to nadal rosło w obecnym tempie
• Planowanie
  • Czas ekstrapolacji wykorzystany dla wbudowanych funkcji. Weź pod uwagę złożoność funkcji. To nie musi być bardzo precyzyjne. To, co chcesz przekazać, byłoby takie jak w przypadku „Funkcji A, B i C mają tę samą złożoność D, E i F. Z cechami ABC wykorzystano 170%, jeśli planowany czas. Jeśli nic się nie zmieni, oczekujemy tego samego potrzebny jest czas na DEF ”lub w stylu„ Średnia funkcja zajmuje X% czasu dłużej niż obliczono. Nie mamy powodu zakładać, że resztę funkcjonalności można łatwiej zbudować, więc powinniśmy to zrekompensować w przyszłym planowaniu Nie ma sensu planowanie, jeśli nie jest realistyczne.
  • Staraj się mieć miesięczny, a najlepiej nawet krótszy harmonogram wydań. Jeśli tylko wewnętrzny. Może to pomóc w dalszym ekstrapolowaniu czasu potrzebnego na projekt. Może to również uchronić cię przed podejmowaniem nierealnych zobowiązań (jeśli nie zobowiązujesz się do nowej pracy przed wydaniem wydania). Zaplanuj każdy cykl i upewnij się, że nowe funkcje wejdą tylko w następny cykl (tj. Nigdy nie będą mogły zostać dodane do bieżącego cyklu).
• Pokrycie testowe: wyjaśnij „normalne” wartości pokrycia testowego i pokaż, jaki jest twój obecny zasięg
• Dokumentacja: Ile procent jest faktycznie udokumentowanych? Jak dobry?
• Modułowość:
  • Na podstawie klasy (sprzężenie i spójność)
  • Na podstawie pakietu
  • Oparty na podsystemie (ile jest ścieżek komunikacyjnych?)

Powinieneś iść do pracy i robić to, co byś zrobił przy każdym projekcie, niezależnie od tego, czy się powiódł, czy nie. Otrzymujesz wynagrodzenie za wykonywanie swojej pracy. Zrób to najlepiej, jak potrafisz. Zakładając, że nie jesteś kierownikiem / kierownikiem projektu, to nie do ciebie należy decyzja, czy program powinien zostać anulowany czy nie. Decyzja o luzie jest taka sama, jak przy podejmowaniu decyzji o anulowaniu projektu. To nie jest część twojego opisu pracy.

Jednak w szerszym ujęciu nie oznacza to, że powinieneś pracować 50, 60 lub więcej godzin tygodniowo, aby spróbować dotrzymać harmonogramu. Po raz kolejny zadaniem kierownictwa jest znalezienie sposobu osiągnięcia celów projektu. Ponad 50 godzin pracy w tygodniu nie jest rozsądną opcją, chyba że są skłonni płacić za nadgodziny i nie chcą odkładać życia rodzinnego. Po raz kolejny zadaniem kierownictwa było opracowanie możliwego do osiągnięcia harmonogramu. Nie mogą zakładać, że mogą zmusić pracowników do ignorowania życia rodzinnego w celu spełnienia nierealistycznych harmonogramów.

Ponadto, chociaż harmonogram może powiedzieć, że pozostało 1 1/2 miesiąca. To prawdopodobnie nie jest data „drop dead”. Niektórzy klienci mogą wziąć to, co masz, do tej daty, nawet jeśli to nie wszystko. Niektórzy klienci mogą uzyskać dodatkowe fundusze, ponieważ włożyli już dużo pieniędzy w projekt. Czasami sama firma może ponieść dodatkowe koszty, aby zapewnić zadowolonego klienta. Wszystko to jest poza twoją kontrolą. Wykonuj swoją pracę najlepiej jak potrafisz. To da opcje zarządzania do pracy, które mogą zmienić projekt katastrofy w wielki sukces. Widziałem to wiele razy.

Mogę tylko powtórzyć to, co powiedzieli inni, ale zdecydowanie podkreślam: Zawsze staraj się jak najlepiej pracować i trzymaj papierowy ślad. zarówno z przyczyn CYA, jak i technicznych.

Jakikolwiek wypadek, który nadejdzie, zależy od osobistego charakteru kierownictwa; ale powiem wam, że piekło znajduje się na końcu niekompetentnego, kłamliwego zarządzania. Ale najgorsze, jakie odejdziesz z nienaruszonym szacunkiem dla siebie (i rówieśników).

Miej dobre notatki na temat technicznych aspektów Marszu Śmierci. Kiedy dostaniesz nieuniknione pytanie, czy jesteś w nieudanym projekcie; dlaczego się nie udało i co zrobiłeś, aby temu zapobiec? Zarządzanie kością nie jest odpowiedzią - nawet jeśli jest to przyczyną.

Można łatwo założyć, że jest to nieunikniona i kompletna porażka i po prostu poddać się projektowi. Jako konsultant często jestem zapraszany do pomocy w projektach na różnych etapach degeneracji, zakończonych niepowodzeniem lub niepowodzeniem, a częścią tego, za co otrzymuję wynagrodzenie, jest ożywienie i ukończenie takich projektów.

To, co postrzegasz jako całkowitą awarię, może nie być postrzegane jako takie przez wszystkich, w zależności od perspektywy. W idealnym świecie każda funkcja byłaby kompletna, zakodowana elegancko i niezależnie od innych systemów i każdej linii testowanego kodu. Nie widziałem ani jednego projektu, który wyglądałby tak w wersji 1. W rzeczywistości wysłanie projektu oznacza kompromis, może nawet brakuje niektórych kluczowych funkcji, ale produkt może zostać wysłany i nawet jeśli będzie w najlepszej jakości beta , przynajmniej dostaniesz opinię, które rzeczy naprawić w pierwszej kolejności. Zaletą tego jest to, że może informować kierownictwo, że oprogramowanie nigdy nie jest zrobione, a zamiast próbować stworzyć pewne v 1.0 w próżni, lepiej jest iterować i reagować na zmiany w zwinny sposób. Wreszcie, jako programista na tym stanowisku, Myślę, że kluczową rzeczą jest opracowanie jak najlepszego kodu w tych warunkach - udokumentuj go, sam napisz testy, jeśli musisz (szczególnie w przypadku zależności zewnętrznych) i wykorzystaj swoją wiedzę o systemie, aby przekazać, które funkcje są naprawdę kluczowe i muszą -Czy i które mogą poczekać tydzień lub miesiąc. Wypowiedz się o swoich obawach i uzasadnij je tak, jak nam. Zamiast przygotowywać się do planu B, przygotuj się na to, że ty i inne biedne dusze prawdopodobnie naprawicie cały ten błędny i jeszcze nie zrobiony kod PO wysłaniu produktu - jak wspomniano powyżej, oznacza to napisanie kodu w modułowy, oddzielony sposób - jeśli uważasz, że kod warstwy trwałości jest zły, miejmy nadzieję, że powinieneś być w stanie całkowicie go zastąpić w następnej wersji. Wreszcie, nie rozpaczaj - radzenie sobie z taką sytuacją jest częścią tego, co „ płacą za to i jest to proces uczenia się. Niezależnie od wyniku tego konkretnego projektu, będzie to liczyło się jako cenne doświadczenie w przyszłości.