Ostatnio pisalem, ze u mnie w firmie jest troche balaganu i dostalem projekt bez dokuementacji. Teraz chce napisac, ze jest tu nie tylko burdel, ale tez kilka rzeczy dobrych :)

Czesc techniczna naszego osrodka (biura?) jest zorganizowana w kilka dzialow, ktore wspolpracuja: architekci, developerzy, quality assurance (testerzy). Do tego jest dolozone jest troche ludzi nietechnicznych: managerowie i project managerowie.

Przygotowanie projektu wyglada tak, ze najpierw odbywaja sie narady managerow z klientami na tzw. wysokim bullshit levelu, duzo power pointa, wyciaganie podstawowych requirementow, budzety itd. Potem do rozmow przystepuja PMowie, ktorzy z PMami klienta ustalaja co i jak bedzie tworzone i wdrazane. W tym samym czasie powstaje team projektu, jakis PM, tech leader i developerzy. Tech leaderzy ustalaja z technicznymi po stronie klienta jak ma byc zaimplementowane to, co panowie wyzej ustalili. Developerzy dostaja dokument z podzialem pracy, terminami, wytycznymi itd. I projekt rusza. Build team co tydzien robi buildy z aktualna wersja projektu, ktore testerzy moga juz testowac.

Do tej pory bylem przyzwyczajony do projektow, gdzie jest ktos (przewaznie techniczny) kto najpierw ustala z klientem co chce zrobic, potem wymysla jak, a potem to implementuje sam lub z jakimis developerami do pomocy. Wydawalo mi sie to naturalne i jedynie sluszne. W tej chwili juz bym nigdy nie chcial wrocic do takiego rozwiazania. Dlaczego? Bo tutaj kazdy robi to w czym jest dobry. Developer nie marnuje czasu na rozmowe z klientem, polbogowie z architecture teamu nie marnuja swojego (drogiego) czasu na implementowanie, tech leaderzy nie spotykaja sie z ludzmi, ktorzy nie rozumieja implementacji itd. Jednoczesnie dzieki temu developerem mozna byc majac naprawde srednie pojecie o tym co sie robi - nad wszystkim czuwa kilka osob wyzej. Czy to wada czy zaleta tego jeszcze nie jestem pewny.