Idealnie zorganizowany projekt

Hej,

nie jestem pewny czy dział odpowiedni więc w razie czego proszę o przesunięcie.

Pracowałem już w wielu firmach - małych, dużych, średnich. Wszędzie był 'chaos' (a przynajmniej tak mi się wydaje) na różnych poziomach oraz wszechobecne developerów narzekanie na ten chaos. Ja narzekać czasami też lubię, ale tak w między czasie zastanawiam się - co zrobić, aby ten chaos choć trochę ograniczyć.

No i prawdę mówiąc mam kilka pomysłów, ale kompletnie nie jestem przekonany, że długoterminowo będą one faktycznie skuteczne. I tutaj pytanie do was. Załóżmy na potrzeby tematu taką sytuacje:

Mamy projekt w korpo. Projekt nowy, ale dość spory - niech to będzie 15 zespołów (plus minus, bo wiadomo co miesiąc 5 osób odejdzie, 3 przyjdzie). Cała architektura to ok. 90 komponentów (cały czas się rozrasta), mikroserwisy blebleble. Część mikroserwisów jest 'wspólna' - np. jakieś zbieracze logów, jakieś systemy alertów itd.

No i teraz problemy:

• wspólne komponenty nie mają właściciela - chcesz coś dodać? musisz zrobić to sam - każda nowa osoba traci sporo czasu, aby się zintegrować z systemami (czy nie powinien być tutaj jeden właściciel?)
• utrzymanie dokumentacji - częśc w confluencie, część na githubowych readmie, część w teamsach na wiki
• przepływ informacji - czy wymagane są spotkania całych zespołow? jak często? od czego to zależy? a może sami team leaderzy?
• rozwój wspólnych bibliotek - jak ogarnąć, że robimy w sumie to samo i może warto z jakimś zespołem porozmawiać o wspólnej bibliotece - kto wtedy jest włascicielem?
• wprowadzenie nowych ludzi - wszystko w okoł się zmienia, zespoły mają różne problemy i projekty wiec ciężko zrobić jedno intro dla nowych

No i oczywiście największy problem - deadline, biznes blebleble.Aczkolwiek wydaje mi się, że tak na prawdę problemem jest kwestia wszechobecnej niewiedzy. Jest pare osób, które ogarniają projekt, ale nie mają czasu na konkretna dokumentacje. Jak już mają czas i zrobią dokumentację to niestety nie ma osób, które chcą później ją aktualizować i tak o to kończymy z masą nieaktualnej dokumentacji.

Jak to u Was wygląda? Wiadomo, że każdy chce mieć idealną specyfikację podaną na tacy, super dokumentacje projektu, aby od razu w niego wskoczyć, ale jednoczesnie nikomu się nie chce jej zaktualizować gdy widzi, że jakiś krok się zmienił... I tak wszyscy sobie narzekają, a nic nie chcą z tym zrobić.

Co zrobić, aby było dobrze? Jak żyć?

Dodam tylko, że zmiana pracy w tym przypadku to nie jest rozwiązanie - przerabiałem to. Chcę faktycznie zrozumieć jak to robi np. google, albo inne firmy w których to działa. W czym tkwi sekret - może np. dokumentacja w stylu https://documentation.divio.com/, a może jakiś trick typu - one page doc dla całego projektu? A może faktycznie jest tutaj przede wszystkim konieczna mobilizacja ludzi?

wspólne komponenty nie mają właściciela

To się nazywa komunizm i kończy się jak komunizm...

Wydziel zespół "platform", "core" czy "fundation" który to będzie utrzymywał. Inni nadal mogą kontrybuować jak potrzebują czegoś na szybko ale review i ostateczne decyzje projektowe będą w kompetencjach tego nowego zespołu.

utrzymanie dokumentacji

Architekt czy Principal ma pobłogosławić jedno miejsce, inny się muszą zmigrować. Docelowy system musi mieć dobre wyszukiwania i system linkowania, a także wsparcie do wyświetlania diagramów/obrazków. GitHub jest taki sobie, ale ma tą zaletę że dokumentacja jest wersjonowana i reviewowana tak jak kod.

spotkania całych zespołow?

Nie bluźnij...

rozwój wspólnych bibliotek

Zespół platform powinien przejąć, na starszych programistach musi ciążyć odpowiedzialność za unikanie duplikacji i wykorzystywanie tego co już jest.

wprowadzenie nowych ludzi

Pewne rzeczy na bank są wspólne, autentykacja do firmowych systemów, IDE, konfiguracja środowiska - to powinno być wspólne. Jeżeli zespół ma szczególne wymagania to powinien dopisać do tego swój szczególny guide, ale zawsze powinno iść guide ogólno firmowy -> guide dla danego zespołu -> guide dla danego stanowiska.

deadline

Bardzo dużo zależy od kultury pracy w danej firmie. Czy to jest prototyp, a potem przepisanie od nowa czy prototyp a potem łatanie i przerzucanie łajna? Firma to startup czy bardziej legacy? Staraj sie komunikować opóźnienia, w symie było już duży dyskusji na forum na ten temat...

nikomu się nie chce jej zaktualizować

Bariera do edycji musi być bardzo niska, wtedy ludzie będą poprawiać. Musi być kultura dbania o doci.

Wieczorem rozwinę swoje myśli, teraz kurier z wiertłem diamentowym wzywa...

Wydziel zespół "platform", "core" czy "fundation" który to będzie utrzymywał. Inni nadal mogą kontrybuować jak potrzebują czegoś na szybko ale review i ostateczne decyzje projektowe będą w kompetencjach tego nowego zespołu.

Dzięki za ten głos - również uważam, że powinien być dedykowany zespół odpowiedzialny za "wspólne" zabawki. Już to kilka razy podnosiłem, w takim razie będę dalej popychał ten pomysł. Wydawało mi się, że może ta idea, że "każdy developer jest samodzielny i świadomy za swój projekt więc dajmy im dużo wolności - w tym integracje ze wspólnymi libkami", jest ok i po prostu nie wierzę w ludzkość, ale po tym co po czasie widzę - ludzie po prostu nie ogarniają na tyle (i to nie jest jakaś obraza), aby tak z doskoku sobie wbić np. w komponent do integracji z elasticem, aby dorzucić swoje 3 grosze. Zamiast 1h to trwa to 2 tygodnie...

Czy to jest prototyp, a potem przepisanie od nowa czy prototyp a potem łatanie i przerzucanie łajna? Firma to startup czy bardziej legacy?

Duże korpo, dokładniej - bank inwestycyjny. Projekt to dość skomplikowany (ale na nowych technologiach) system przetwarzający miliony eventów / godzinę.

W jednej firmie były 2 teamy. Oba miały tego samego klienta, i w obu przypadkach klient nie miał czasu, bądź chęci, aby poświęcać czas na spisanie wymagań.

Jeden team skupił się na próbie udokumentowania wszystkich wymagań, robił to co było pewne i potwierdzone. Drugi team podszedł do tematu na luzie, starał się przede wszystkim zaskoczyć pozytywnie.

Efekt:

Pierwszy team nawet nie był w połowie prac, frustracja w zespole narasała, były napięcia na linii z klientem.

Drugi team, przyjmował feedback. Klient widział efekty, mógł łatwo i szybko odnieść się do tego co chce zmienić, wprowadzić. W tym zespole mimo, że część rzeczy nie weszła, to morale były cały czas wysokie.

Wniosek:

Jeśli Twoją firmę stać na taki flow, to nie próbuj zrzucić wszystkiego na papier. Po prostu wykorzystaj takie okoliczności i próbuj pozytywnie zaskoczyć.

Pracowałem w wielu firmach, i nie może zaistnieć to o czym mówisz. nawet w Matrixie agent mowił, że to już kolejna jego wersja bo poprzednie chciały być zbyt idealne. 15 zespołów ? chyba nawet developerce gier tylu nie ma :) ja pracowalem w banku to były 4 zespoły dev. core, front, bazy i sieciowcy. I ci sami ogarniali wszstkei banki takiego wlasicicela. Więc nie było nawet tak że jakaś grupa była dedykowana do tego banku, a inna do innego.

Właścicielem projektu jest obecnie wytypowana osoba no bo jak sie zwolni to trzeba wybrać inną. To nie tak ze przychodzi klient i on jest ownerem. Ty pracujesz w korpo dla klienta od wewnatrz i on ma to w d.... szef mowi ma byc, to ma byc.

Brak zrozumienia procesów sprawia ze szef naciska i przez te naciskie robi sie tymczasowa fuszerke ktora pozniej zostaje i jest rozbudowywana, tak jak bylo w przypadku mojej innej pracy :) koles gdy zaczynal napisał costam w php. potem dobrali kolejnych i kolejnych i z tego g....na wyszedl im serwis ktory musieli ogarniac. Nie było wtedy frejmłorków a całośc do dzis opiera sie na dwoch plikach ktore maja tyle makaronu że dziwne ze to sie trzyma, a firma finansowa xD

Byłem w firmie co, jeden mądruś pisał dokuentacje przez 4 miesiące, której do dziś nikt nigdy nie otworzył, jeszcze ja wydrukował i oprawił, co za typ. A już dawno się pozmieniały niektóre funkcje jak przypuszczam. Także to co piszesz jest całkiem normalne przynajmniej ja miałem takie doświadczenie i jest to moja subiektywna opinia z którą nie każdy musi się zgadzać.

Pytanie, kto będzie odpowiedzialny za utrzymanie „usług wspólnych” na produkcji ;) Tak jak poprzednicy wskazali, musi być jakiś Technical Owner tych zabawek. Jeśli chodzi o rzeczy typu ogarnięcie CI/CD, baz danych, service discovery, jakichś self-serviców - to powinny zajmować się tym dedykowane zespoły, które tworzą „usługi dla usług” i rozwijają je jak produkt - tylko, że stakeholderem są w tym przypadku zespoły produktowe. Jest fajna książka na ten temat - „Team Topologies”.

Odnośnie dokumentacji to chyba tak jak z komunikatorem - ustalcie jakiego używacie i tego się trzymajcie. Niestety nie mam najlepszych doświadczeń jeśli chodzi o prowadzenie dokumentacji w środowisku wielozespolowym - efektywniej jest się zdzwonić niż poświęcać czas na aktualizacje dokumentacji. Jeszcze nie widziałem dokumentacji, która byłaby kompletna i aktualna - w świecie mikrousług bardzo szybko się wszystko zmienia (i dobrze) ;)

Na koniec - nie ma czegoś takiego jak „idealnie zorganizowany projekt”, jest za to kult cargo ;) czyli wzorowanie się na Allegro czy Google bez zrozumienia dlaczego tak to robią (a robią inaczej). Wyszedłbym od potrzeb, pain pointów i zaczął je adresować w gronie starszyzny (plus ochotnicy).

Nie ma idealnych projektów, to co się sprawdziło w projekcie X, w firmie Y, z ludźmi Z, może być kompletną porażką, jeżeli dowolny z tych elementów się zmieni. Jedyna droga, żeby projekt nie poszedł na dno, to cyklicznie patrzeć jakie są problemy i znajdować sposoby na ich rozwiązanie. Jeżeli masz trochę więcej doświadczenia, albo wiedzy możesz wystartować z lepszego poziomu, bo już wiesz, że np. wspólny komponent to niczyj komponent.

A moje zdanie co do opisanych przez ciebie problemów:

• każdy komponent powinien mieć swoją właściciela (zespół). Inni mogą co najwyżej robić pull requesty jak im się śpieszy, ale to właściciel odpowiada za to co wchodzi do jego kawałka. Jak masz no. jakąś bibliotekę współdzieloną przez 5 zespołów to i tak musisz mieć zespół odpowiedzialny za to, że działa.
• każde repozytorium powinno mieć własny readme opisujący co robi ten kawałek, jak go zbudować.
• system powinien mieć trochę dokumentacji, ale utrzymywanej w stanie możliwie aktualnym
• jak będziecie robić spotkania wszystkich ludzi z wszystkich zespołów to ani nic nie ustalicie, ani nie będzie czasu na pracę. Według mnie, lepiej zrobić krótkie spotkanie liderów, żeby spróbowali rozwiązać problem, mogą mieć wsparcie w postaci doproszenia kogoś z zespołu jeżeli sami czegoś nie ogarniają - dzisiaj to banał wysyłasz na slacku prośbę o dołączenie i moment później masz już kogo potrzebowałeś.
• wspólne biblioteki - właściciel zawsze musi być jeden zespół, wykonujących robotę może być wielu - opisałem wyżej. I należy dogadać się między sobą, a nie wciągać do tego biznes, bo wtedy przez rok będziecie gadać kto jest senior product managerem junior product managerem, czy potrzeba więcej czasu na analizę, czy rok wystarczy a na koniec wszystko walnie o beton, bo każdy zespół zrobi tę bibliotekę sam sobie, a managerowie się obrażą, ze nikt na tak ważne spotkania nie przychodzi.
• każdy zespół powinien mieć krótki, nie formalny, ale pełny dokument jak się zabrać za pracę nad projektem. Jak przychodzi nowy, to jego pierwszym zadaniem jest zrobić to co tam jest napisane i nanieść swoje poprawki, jak gdzieś się musiał kogoś dopytać.

utrzymanie dokumentacji - częśc w confluencie, część na githubowych readmie, część w teamsach na wiki

Część powinna byc w projekcie np. w README jakimś, ale część na jakimś confluencie. Co innego opis stawiania aplikacji, a co innego architektura systemów wysokopoziomowa.

wprowadzenie nowych ludzi - wszystko w okoł się zmienia, zespoły mają różne problemy i projekty wiec ciężko zrobić jedno intro dla nowych

Można na przykład nagrac godzinny film z wprowadzeniem do architektury systemów. WIem bo widziałem taki xD