Hej
Mam w planach do napisanie duży projekt którego napisanie może zająć 3-4 miesiące i moje pytanie brzmi, jak najlepiej zorganizować sobie pracę i od czego zacząć. Do realizacji projektu wykorzystam OOP i MySQL, w razie potrzeby też inny język. na chwilę obecną projekt będzie wymagał, stworzenie designu, napisanie ponad 60 class, panela administratora, konta użytkowników etc...

Proszę o jakieś wskazówki od czego najlepiej zacząć.

Od zaprojektowania całości. Jeśli stwierdzisz "o, jest super" to dopiero wtedy możesz zająć się programowaniem. W przypadku popełnienia błędu w fazie projektowania późniejsze jego wyeliminowanie może okazać się bardzo trudne. Projekt, projekt i jeszcze raz projekt.

Dokładnie, rozrysuj sobie bazę, frameworka (w sensie co gdzie, do czego, po co i dlaczego), podziel cały projekt na etapy (tzw. kamienie milowe), wypisz sobie co jest ważniejsze i tym zajmij się na początku, a głupoty zostaw sobie na koniec.

Wiem co i jak ma wyglądać, jakie klasy muszę sobie napisać. Projekt będę pisał obiektowo ponieważ jest to dla mnie duże ułatwienie, i w każdej chwili mogę użyć gotową klasę, a nie pisać bez sensu kod na nowo, a co najważniejsze w razie rozbudowy projektu wystarczy tylko klasy rozbudować o dodatkowe funkcje.
Projekt bazy danych już mam gotowy

Tak troche Waterfallem zawiało

Zdarza się tak, że "idę na żywioł", a w zasadzie najczęściej tak jest - jestem zwolennikiem Agile

I te "głupoty" to wbrew pozorom najwięcej czasu pochłaniają, naprawdę takie małe pierdoły o których nawet nie myślisz na początku projektu.

Dobrze się tu sprawdza zasada 80/20 - 20% funkcjonalności zajmie 80% czasu

A co do organizacji pracy - przed rozpoczęciem pisania zorganizuj sobie system kontroli wersji. Jeżeli planujesz pisać w grupie to na jakimś dostępnym dla wszystkich serwerze. A jeżeli piszesz sam, to też Ci się to przyda - wtedy możesz postawić lokalnie np serwer svn, albo nawet wykorzystać protokół file: w kliencie svn.

Do zaplanowania wszystkiego w szegolach trzeba masy czasu, masy wiedzy i doswiadczenia (zeby wiedziec jakie konsekwencje bedzie mialo TAKIE wykonanie TAMTEJ funkcjonalnosci itd), a i tak cos pominiesz, nie przewidzisz, cos sie potem zmieni, albo nie masz precyzyjnych wymagan co do czesci funkcjonalnosci.