Jak zarządzać projektem po jego zamrożeniu/opóźnieniu na czas nieokreślony?

Question

W tej chwili jestem bardzo sfrustrowany, ponieważ byłem w trakcie opracowywania jakiegoś fajnego mechanizmu optymalizującego system obliczeń poprzez zmniejszenie liczby obliczeń od około pół miliona do kilku tysięcy. Dużo czasu zajęło mi zbadanie i przeanalizowanie danych, spisanie rzeczy, wykonanie kilku testów i ogólnie po prostu wykonanie mojej pracy. Potem mieliśmy spotkanie projektowe. Wyjaśniłem, co chcę zrobić, ile czasu zajmie i ile może poprawić projekt, a nawet umożliwi tworzenie nowych funkcji. Potem zdecydowano, że to zbyt dużo czasu, aby zrobić to wszystko przed następnym terminem. (Termin, który musiałby zostać przedłużony, gdybym mógł kontynuować.) Szybka burza mózgów jasno pokazała, że ​​istnieje proste rozwiązanie, które można by wykorzystać zamiast tego, co opóźniłoby optymalizację o kilka miesięcy.

Cóż, trudne!

Okay ... Właśnie napisałem tę frustrację. Teraz pytanie ... Mam teraz cały ten projekt w mojej głowie. Wiele z nich to tylko schematy i kawałki papieru z odręcznym tekstem, niektóre wydruki, a nawet kilka pytań tutaj w SO. Pomysły te zostaną zamrożone na jakiś czas, ale będę musiał je zapamiętać w przyszłości. Mogę dostać dzień, może dwa, żeby posprzątać notatki i zacząć dokumentować rzeczy.

Potrzebuję więc porady, jak najlepiej zapamiętać mój projekt w 4 miesiące od teraz. A może nawet za rok ... Co jest najważniejsze do zapisania? Lub dokument? (Biorąc pod uwagę krótki czas, jaki mam ...) Jakieś sugestie?

Dlaczego? W przeciwnym razie znów będę sfrustrowany za cztery miesiące. :-)

Answer 1

Zależy, co działa dla Ciebie - i jak chcesz się uczyć. Lubię korzystać z diagramów, więc w sytuacji, w której zaprojektowałem super algorytm (choć nie tak skomplikowany jak to!), Wykonuję następujące czynności:

1) Narysuj algorytm na papierze lub zapisz go .

2) Dodaj adnotacje, aby uczynić kompletnym sens dla Ciebie.

3) Opisz algorytm komuś innemu tylko z tego, co narysowałeś. To powstrzymuje cię przed wypełnianiem pustych miejsc z własnej wiedzy o algorytmie.

4) Jeśli w opisie występują luki, dodaj dodatkowe szczegóły, aby dokument stał się obszernym zapisem Twojego opisu.

5) Odłóż rysunek na tydzień i sprawdź, czy nadal ma to sens. W tym momencie powinien on być wystarczająco znajomy, aby dodać brakujące szczegóły.

Nie wiadomo, czy będzie to wystarczająco jasne w ciągu roku - czy też zechcesz z niego skorzystać.

Nadzieję, że pomaga!

Answer 2

Z mojego doświadczenia wynika, że ​​stare projekty zawsze wydają się nieaktualne po odkurzeniu. W nadchodzących miesiącach istniejący kod zmieni się, wymagania ulegną zmianie, a zmienisz się jako programista. Może powinieneś napisać krótkie wyjaśnienie i założyć, że i tak będziesz musiał je całkowicie przerobić w przyszłości.

Nie denerwuj się konkretnymi projektami, skup swoją energię na ulepszaniu jako programista. I przekaż to doświadczenie z tobą.

Answer 3

Szczegółowy dokument wymagań, który opisuje wszystkie wejścia i wyjścia, jest prawdopodobnie jednym z najlepszych sposobów na rozpoczęcie pracy. Jeśli jest to bardzo unikalny projekt kodu, metakod może być dobrym krokiem. to znaczy.

[Meta Object] 

    [Return String(string param1, string param2)] 

     Return param1 + " " + param2 

    [Return Integer(integer param1, integer param2, integer param3)] 

     Return (param1 + param3)/param2 

[End Meta Object] 

Zrób to wyglądać mniej więcej podobny do języka w/o testowaniu lub cokolwiek, po prostu uzyskać logc teoretyczną na papierze (notes) w ten sposób masz płytę wiosnę, kiedy/jeśli kiedykolwiek musiał wrócić do niego ... następnie udokumentuj światła dzienne.

Answer 4

Pod względem frustracji - na ogół spróbuj wyświetlić projekt jako podróż, a nie miejsce docelowe.

Jeśli zwróciłeś uwagę na to, jak wiele masz z tego projektu - rzeczy, których się nauczyłeś o technologii i biznesie, stworzyłeś moduły kodu, które możesz ponownie wykorzystać, zbudujesz relacje z członkami zespołu lub użytkownikami, popełniłeś błędy, których nie zrobisz ponownie i tak dalej. Może ci pomóc osobiście napisać listę tego, co wiesz teraz, czego nie zrobiłeś na początku projektu.

Ostatecznie firma mogła nie wdrożyć projektu, ale znaczna część korzyści, jakie przynosi Tobie jako osobie i programistce, nadal istnieje. Rzeczywiście, często można dowiedzieć się więcej o projektach, które idą źle, a także w firmach, które nie są świetne, gdy wszystko działa jak marzenie.

Podobnie jak reszta życia, tym więcej satysfakcji można uzyskać z dnia na dzień, a im mniej koncentrujesz się tylko na marquee, tym jesteś szczęśliwszy.

Nie mówię, że dostarczanie projektów nie jest dobre - to oczywiście dlatego, że kodujemy - ale to nie jest całkowicie pod naszą kontrolą, więc musisz być realistą i zrównoważonym, o ile pozwalasz, aby to miało wpływ na Ciebie.

(Obowiązkowe link lub coś Joel Jeff napisał: http://www.codinghorror.com/blog/archives/001297.html)

Answer 5

Jeśli znalazłeś Rozwiązanie raz, szanse są wysokie, dowiesz się rozwiązanie nawet 4 miesiące w dół linii dla tego samego problemu. To czego nie możesz przegapić to faktyczny problem.

Powinieneś zapisać wszystkie problemy związane z optymalizacją, które są źródłem problemów lub rzeczywistymi problemami. Należy starannie przechowywać notatki dotyczące tych problemów.

Teraz, następnym razem [powiedz o 4 miesiącach w dół], kiedy chcesz wrócić do tego ponownie. Musisz tylko przeczytać problemy z problemami z twoich notatek, a twój mózg zacznie działać w prostym kierunku, tak jak poprzednio.

Aby było jeszcze lepiej, możesz spróbować przejrzeć notatki o problemach raz na miesiąc lub dwa. Pozwoli to wytrenować twój mózg w kierunku rozwiązania, ponieważ za każdym razem będziesz kończył z rozwiązaniem dokładnie tak, jak robiłeś to po raz pierwszy.

Również, jeśli uda ci się rozwiązać problem lub problem, który zmotywował cię do rozwiązania problemu, byłoby świetnie.