Prowadzenie projektów

Podczas działalności w KN Solvro może nadejść moment, że to właśnie TY jesteś osobą odpowiedzialną za dany projekt. Zastanawiasz się co dalej i z której strony to ugryźć? Nie martw się, właśnie w tym dokumencie znajdziesz wszystkie informacje jak przeprowadzić projekt w kole od początku do końca. Są tu wypisane wszystkie najważniejsze rzeczy o których należy pamiętać, ale jeśli znasz dodatkowe metody lub projekt wymaga bardziej specyficznego podejścia - droga wolna. Musimy pamiętać, że dobra dokumentacja projektowa i organizacyjna jest podstawą rozwoju i przechowania wiedzy na przyszłe pokolenia.

Jak zacząć

Zaczynając karierę w kole prawdopodobnie będziesz jednym z uczestników projektu wdrożeniowego. Prędzej czy później on się zakończy i wtedy stoi przed tobą ważna decyzja. Możesz zaangażować się w kolejny projekt jako uczestnik lub lead. Ze stanowisk leada wyróżniamy Project Managera oraz TechLeada. Przy mniejszych projektach oba te stanowiska mogą być pełnione razem.

Kwestia do jakiego projektu zależy tylko od ciebie. Możesz zostać Leadem projektu wdrożeniowego dla nowej rekrutacji, możesz zostać leadem w obecnym projekcie, gdzie obecny lead nie jest w stanie pełnić już tej roli, ale możesz również zaproponować swój własny innowatorski pomysł na projekt.

W każdym z tych przypadków pierwszy krok to kontakt z zarządem. Mając ogląd na wszystkie projekty w kole pomogą ci jak najlepiej się przygotować do swojej nowej roli. Tak naprawdę czym szybciej tym lepiej, bo od momentu chęci do momentu rozpoczęcia prac programistycznych jeszcze trochę.

Inicjacja

Na samym początku PM/TechLead tworzy kopię szablonu projektu na dysku w folderze 1. Projekty nazywając go nazwą roboczą projektu. Od tego momentu wszystkie rzeczy związane z projektem powinny tam być przechowywane.

Pitch deck

Mając chęci i ogólny koncept projektu pierwszym krokiem jest zrobienie krótkiego pitch decku w formie prezentacji na weekly. Pozwoli to zapoznać się wszystkim członkom koła z projektem, a tobie usłyszeć pierwszy feedback samego konceptu. W tym momencie możesz ogłosić również jakie osoby potrzebujesz do swojego projektu i rozpocząć wewnętrzny nabór.

Spotkanie wizyjne

Po skompletowaniu zespołu zalecamy tzw. spotkanie wizyjne w formie dłuższego spotkania stacjonarnego. Jest to pierwszy moment, gdy widzicie się wszyscy razem w nowym składzie, więc jest to idealny moment, żeby się zapoznać. Do umawianie tego i kolejnych spotkań polecamy narzędzia lettucemeet.com. Jak nazwa “spotkanie wizyjne” wskazuje spotkaliście się, aby ustalić konkretną wizję projektu. Jest nie niezmiernie ważne, aby każdy członek projektu był na “jednej stronie”, wiedział co się dzieje i czuł, że jego punkt widzenia został uwzględniony. Jest to również moment, aby konkretnie ustalić wizję projektu, do kogo ma on trafić i co trzeba uwzględnić. Warto użyć technik typu Design Thinking, business model canvas i inne, których opisy można znaleźć w Lista wiedzy w kategorii PM, a szczególnie polecane są Product_Development_Radek i (Design Thinking) Praktyczny przewodnik po procesie CSI_Lab.pdf. Po takim spotkaniu zalecana jest integracja. PM i TechLead na podstawie spotkania wizyjnego tworzą kartę projektu.

Karta projektu

Karta projektu jest podstawowym i najważniejszym dokumentem każdego projektu. Ten 1-2 stronicowy dokument zawiera wszystkie najistotniejsze informacje dotyczące przedsięwzięcia wliczając:

• Nazwę projektu
• Project Managera
• Tech Leada
• Grupę odbiorców - kto będzie używał efektów naszego projektu?
• Kontekst - dlaczego ten projekt powstaje, skąd wziął się pomysł?
• Cele projektu - co chcemy osiągnąć za pomocą tego projektu
• Zakres projektu - jak jest, jak chcemy żeby było, co w związku z tym robimy
• Poza zakresem projektu - czego nie robimy w projekcie
• Kamienie milowe - najważniejsze etapy projektu
• Interesjonariusze - na kogo rezultaty projektu będą wpływały
• Wymagania - dot. technologii, rezultatów, organizacji, itd.
• Założenia - jakie warunki przyjmujemy
• Ograniczenia - co nas ogranicza w projekcie
• Zagrożenia - co może pójść nie tak
• Szanse - co dodatkowo możemy zyskać
• Zespół projektowy - kogo potrzebujemy i kto bierze udział w projekcie
• Inne informacje
• Changelog - zmiany uzupełniane w trakcie trwania projektu

W zależności od typu projektu i jego szczególnych wymagań w karcie projektu może znaleźć się więcej lub mniej informacji. Dokument jest tworzony w trakcie/po spotkaniu wizyjnym, gdzie omówione powinny zostać wszystkie jego punkty.

Te kilka informacji pozwoli przechować wiedzę o projekcie przez następne pokolenia oraz w przypadku dłuższych projektów, gdzie skład zespołu zmienia się, szybko wdrożyć nowe osoby w scope projektu.

Wywiady

W przypadku projektów gdzie jest to możliwe i sensowne dobrą praktyką jest przeprowadzenie wywiadów z zdefiniowanymi grupami odbiorców. Musimy pamiętać, że nie robimy aplikacji dla samych siebie, a właśnie dla jakiś odbiorców. To ich potrzeby, pragnienia, bolączki i uwagi musimy wziąć pod uwagę planując funkcjonalności produktu. Więcej na ten temat można przeczytać w poradniku Jak badać klientów.

Planowanie

Na tym etapie przychodzi moment na zaplanowanie pracy. Wiadomo, nie jesteśmy wielkim korpo i staramy się działać zwinnie, więc planowanie skupi się na wypisaniu funkcjonalności jakie chcemy wykonać i rozbicie ich na podstawowe elementy.

WBS

Work breakdown structure może brzmi skomplikowanie, ale to tak naprawdę rozpisany podział pracy. Może również być ukazany graficznie.

Projekt dzielimy na etapy, następnie poszczególne części, a je końcowo rozbijamy na elementy. Pozwoli to zauważyć powtarzające się elementy, albo takie które nie są w sumie zbytnio potrzebne. Największym plusem WBS jest fakt, że określa on scope projektu i jest podstawą do rozpisania poszczególnych tasków. Przykładowy WBS w wersji graficznej znajduje się poniżej:

Więcej na ten temat można znaleźć w dostępnym na dysku poradniku Podstawy zarządzania projektem i podział prac .pdf.

Analiza MoSCoW

Na początku w każdym projekcie dążymy do wypuszczenia MVP, czyli podstawowej wersji, która spełnia nasze podstawowe oczekiwania. W celu przefiltrowania elementów z WBS na takie które są kluczowe, nie kluczowe, niepotrzebne, fajne, ale nie na teraz używa się analizy MoSCoW. Symbolizuje on następujące kategorie elementów:

• Must - rzeczy, które muszą być zrobione i są kluczowe dla wypuszczenia projektu
• Should - rzeczy, które powinniśmy zrobić, ale nie są kluczowe w momencie wypuszczenia projektu
• Could - rzeczy, które możemy zrobić, ale nie są kluczowe dla produktu w momencie wypuszczenia ani potem
• Won’t - rzeczy z których rezygnujemy i nie będziemy robić (kompletnie nie są potrzebne albo są niewykonalne)

Tą względnie prostą metodą możemy w krótkim czasie stwierdzić jakie elementy mają priorytety. Zaleca się przeprowadzić taką analizę z zespołem po omówieniu WBS.

Technologie

W tym momencie warto porozmawiać z zespołem jakich technologii dokładnie będziemy używać. Mogą być one dyktowane unikalnymi wymaganiami projektu, ale również preferencji zespołu. Może akurat chcecie spróbować nowej technologii albo użyć gotowego rozwiązania, które zaoszczędzi wam dużo nudnej pracy.

Rozpisanie zadań

Jako główną platformę do prowadzenia projektu w kolejnych fazach jest GitHub. Każde repozytorium może mieć utworzony projekt, które idealnie integruje się w wszystkimi funkcjonalnościami GitHuba.

Lead jest odpowiedzialny za jego utworzenie, odpowiednie skonfigurowanie pól i milestone oraz rozpisanie zadań wzorując się na WBS. Następnie na spotkaniu z zespołem przypisujemy zadania wg. preferencji ustawiając orientacyjny czas wykonania. Pozwoli to oszacować czas potrzebny na zadanie i status projektu.

Pamiętajmy o jak najbardziej pomocnych opisach zadań najlepiej od razu z linkami/screenami do makiety UI/UX.

Więcej informacji można znaleźć w Handbooku Githuba

Makiety UI/UX

Przyjmując, że projekt posiada interfejs graficzny i jest potrzeba makiet, projekt UX/UI jest kluczowym elementem zapewniającym spójność i przyjemność pracy.

Przy prostych projektach zachęcamy leadów do spróbowania swoich umiejętności graficznych w figmie albo odnalezienie tych umiejętności w członku zespołu. Przy większych projektach oczywiście jest dostępny grafik lub UI/UX designer.

Na tym etapie przychodzi również decyzja wiążąca się z wybranymi technologiami. Jeśli została wybrana biblioteka komponentów lub gotowy szablon jest to kluczowe, aby używać udostępnianych przez nich designów w celu zapewnienia spójności wizualnej.

Dla mniejszych projektów lub takich w fazie początkowej zalecamy używanie identyfikacji wizualnej KN Solvro, dostępnej w folderze Identyfikacja wizualna. W dalszych fazach projektów lub przy większym scopie zalecamy utworzenie osobnej identyfikacji wizualnej całej aplikacji.

Większość informacji dla UI/UX designerów miejmy nadzieję, że już niedługo znajdzie się w Handbooku UI Designera.

Realizacja

No i cóż, czas start. W tym momencie wiadomo jaki jest zakres pracy. Wszyscy są na jednej stronie i czas zacząć zabawę.

Praca zwinna i spotkania

Zalecamy cotygodniowe spotkania na których omawiamy zadania do zrobienia i ewentualne problemy i przypisujemy zadania do osób wg. preferencji. Po tym okresie spotykamy się na kolejnym weekly, gdzie omawiamy wprowadzone zmiany, napotkane problemy, obszary do rozwoju i rozpisujemy kolejne zadania.

W zależności od nastawienia zespołu zalecamy stacjonarne comiesięczne spotkania stacjonarne, gdzie szerzej patrzymy na projekt, jak nam się pracuje w zespole i co robimy dalej. Jest to również doskonała okazja do integracji zespołu.
Na spotkaniach całego koła chwalimy się naszymi osiągnięciami najlepiej prezentując wersję live i zbierając upragniony feedback.

Code review

Code review jest podstawą rozwoju programisty. Pozwala on na przekazanie przez bardziej doświadczonego programistę wiedzy i insightów na danym kodzie do mniej doświadczonego programisty.

Każdy projekt powinien mieć bardziej doświadczoną osobę techniczną (TechLeada), która udziela tego feedbacku w PR.

Więcej na ten temat i jak dobrze używać githuba znajdziemy w nadchodzącym handbooku githuba.

Solvro Talks

Solvro Talks jest inicjatywą mającą na celu szerzenie wiedzy technicznej. Składa się ona z prezentacji oraz posta i może poruszać wszystkie zakresy od napotkanych problemów i jak je rozwiązaliście przez użyliśmy nowej technologii i chcemy pokazać jak się z nią nam pracowało do podsumowania projektu po kluczowej fazie.

Przedstawiane będą one na weekly oraz wybrane na corocznej konferencji W4N WIT-KoN, którego Solvro jest głównym współorganizatorem.

Zachęcamy wszystkich, zarówno jako projekty jak i pojedyncze zespoły na dzielenie się wiedzą, bo tak się rozwijamy.

Środowisko

Dla projektów, których to dotyczy praca developerska będzie prowadzona na developerskiej wersji naszych serwerów i coolify. Przypisana tam domena to solvro.pl, więc w tej subdomenie będzie znajdować się developerska wersja aplikacji.

Open Source

Jednym z kierunków do jakich dążymy to tworzenie oprogramowania w stylu open source. Pozwala to jeszcze bardziej chwalić się naszymi osiągnięciami, a członkom projektu od razu budować sobie portfolio.

W tym celu musimy pamiętać o jakości kodu, jakim się prezentujemy i nie używaniu assetów, które mogą być problematyczne ze strony prawa.

Wdrożenie

Wdrożeniem nazywamy upublicznienie aplikacji na pewnym etapie pracy. Pierwszym wdrożeniem danej aplikacji będzie jej MVP. W zależności od projektu będzie on promowany w adekwatnym miejscu.

Od tego momentu przechodzimy na tzw. produkcję, gdzie reliability musi być zachowane na bardzo wysokim poziomie. Jeśli nie wcześniej to od tego momentu zalecamy podział branchy na main i dev.

Infrastrukturą wdrożenia będzie zajmował się devops i końcowo produkcyjna aplikacja będzie hostowana na innym serwerze niż developerska. Domena aplikacji produkcyjnej jest subdomeną solvro.pl

Więcej info z deploymentu znajdziesz w Handbooku Deploymentu.

Zamknięcie lub dalsza praca

Po wdrożeniu danego etapu oficjalnie go zamykamy. Jest to doskonały moment na uporządkowanie dokumentacji i kodu oraz SolvroTalk na weekly.

Retrospekcja

Po dłuższym czasie intensywnej pracy i zamknięciu danego etapu istotne jest szczere porozmawianie ze sobą jak nam się wspólnie pracowało. Robi się to w formie retrospekcji, czyli stacjonarnego luźnego spotkania gdzie rozmawiamy sobie o tym co poszło dobrze, co poszło źle i co możemy z tym zrobić.

Co dalej

Jeśli po retrospekcji widzimy, że doskonale się nam pracuje możemy w tym samym składzie brać się za kolejny etap danej aplikacji lub przejście dalej do nowego projektu. Końcowo cykl się zatacza i zaczynamy od początku.

Myśli końcowe

Przedstawione tu informacje są wskazówką do przeprowadzenia projektu w KN Solvro. Każdy projekt rządzi się swoimi prawami i to właśnie twoim zadaniem jest dopasowanie metod i zarządzania do danej sytuacji. Nie ma metody, która pasuje do wszystkiego, ale wiele z nich jest przetestowanych w świecie zawodowym sposobami na uniknięcie późniejszych nieprzyjemności.

Pamiętajmy, że nie robimy projektu tylko dla siebie, ale dla wspólnoty jaką jest Solvro i PWR. Dlatego istotne jest pozostawienie po sobie solidnej dokumentacji i przekazanie wiedzy na kolejne pokolenia.

Prezes VII Zarządu KN Solvro

Dawid Linek