Motywacja w własnym projekcie

Zawód programisty to profesja, która wymaga ciągłego rozwoju. Bez tego nie będziemy w stanie utrzymać się przy długotrwałych projektach czy znaleźć nowej pracy. Pracodawcy czasami weryfikują jak programista rozwija swoje umiejętności, ale najczęściej w praktyce wychodzi na jaw jakie braki musimy nadrobić. Dlatego nie ważne czy pracujemy w firmie programistycznej, startupie czy nie związanej z branżą informatyczną, a bardziej produkcyjną, nierzadko musimy poświęcać swój wolny czas na doszkalanie się z różnych obszarów programowania. Oczywiście jest wiele metod, ale dzisiaj omówimy sobie jedno z najchętniej stosowanych czyli praca nad własnym projektem programistycznym.

Czym różni się tak naprawdę projekt własny od tego co realizujemy w firmie? Przede wszystkim tym, że jest on zupełnie inny od tego co robimy na co dzień. Musi on nas motywować do działania, dlatego nie możemy przenosić na niego całej rutyny działania jaką znamy z codziennej pracy. Ma być dla nas zupełnie czymś nowym i rozwojowym. Warto, więc przed jego realizacją zastanowić się co chcemy osiągnąć. Czy rozwój w obszarze nowych technologii, bibliotek, systemów zarządzania, czy szersze poznanie architektury i metod projektowania oprogramowania, a może chcesz zrobić po prostu coś innowacyjnego. Każde z tych działań prowadzi do poszerzania wiedzy, ale nie tylko, ponieważ jednocześnie tworzysz swoje portfolio oraz przybliżasz się do wydania własnego produktu, którym możesz się pochwalić przed przyszłym pracodawcą. A to z kolei zwiększa twoje szanse na to, aby stać się bardziej wartościowym pracownikiem na rynku pracy.

Motywacja we własnym projekcie
W karierze programisty warto realizować coś swojego i zdobywać nowe umiejętności.

Pytanie teraz w czym tym wszystkim jest haczyk? Wbrew pozorom zaangażowanie się w taki projekt nie jest łatwe. Jeśli zależy nam na tym żeby coś z tego powstało to musimy to traktować trochę jako drugi etat. Będzie on nam pochłaniał bardzo dużo wolnego czasu. Szczególnie na początku kiedy całą koncepcję musisz zaprojektować od zera i ustalić pewne standardy w projekcie. Kiedy masz kogoś do pomocy musisz dodatkowo zadbać o organizację oraz przepływ informacji. To kolejne godziny, które będziesz poświęcać po południami lub w weekend. A nawet w ciągu dnia. Wszystko zależy od tego jak inne osoby będą się w to angażować. Jeśli jesteś sam to masz trochę większą swobodę.

Motywacja we własnym projekcie – Podstawowy problem

To co teraz napisałem nie jest co prawda motywujące i nie pomaga to w niczym, ale właśnie uświadomiłem Ci programistyczną rzeczywistość. Nigdy nie będzie tak, że wszystko będzie szło po naszej myśli. Albo, że napiszemy idealny produkt w bardzo krótkim czasie. Na pewno będą zdarzać się sytuacje kiedy będziemy robić coś co niekoniecznie będzie nam się podobać, nie będziemy tego lubili lub nie będziemy wiedzieć jak się do tego zabrać. To jest jak najbardziej normalne. Do tego dochodzą też kwestie organizacyjne architektury oraz kodu naszej aplikacji. I tutaj też nie będzie łatwo, bo proces w sam sobie jest na tyle skomplikowany, że nawet niektóre duże firmy programistyczne mają z tym problem, a specjaliści na całym świecie badają i opracowują coraz to nowsze metody panowania nad projektami programistycznymi. Czytając ich publikacje na blogach możesz zobaczyć jak to tylko pozornie wszystko jest łatwe.

Oczywiście, gdyby byłoby to niewykonywalne to prawdopodobnie nie powstały by żadne startupy, projekty open source, biblioteki programistyczne czy firmy oferujące jakieś rozwiązania. Jest to do opanowania, trzeba przede wszystkim się do tego wszystkiego zmotywować i starać się tą motywację utrzymać. Jak to zrobić? Trzymać się po pierwsze kilku kluczowych zasad, zagrać trochę psychologicznie i stosować się do zaleceń. Rzecz jasna wszystko to za chwilę przybliżę.

Programowanie w zespole

Pierwsze zalecenie, moim zdaniem najlepsze, ale też najtrudniejsze do osiągnięcia, jest zbudowanie zespołu. Niekoniecznie musimy być to duży. Może składać się z dwóch lub trzech osób. Najważniejsze jest to, aby osoby te były również zmotywowane do rozwoju i stworzenia czegoś swojego, a projekt traktowały trochę jako swoje hobby. Mówiąc prościej. Twój zespół w tych kwestiach musi myśleć podobnie. Niekoniecznie pod kątem technicznym, ale pod kątem nastawienia do tego typu przedsięwzięciach. Jeśli jednej osobie zależy na nauce podstaw programowania, a drugiej na rozwijaniu umiejętności to prawdopodobnie się nie dogadacie. Dlaczego? Bo ta pierwsza osoba będzie nie będzie miała wielkiego wkładu w projekt, a ta druga będzie się nudziła i demotywowała, ze musi wszystko robić za tą pierwszą. Jeśli chcesz zbudować grupę, w której ktoś dopiero zaczyna przygodę z programowaniem to musisz wczuć się w roli mentora. Co też ma swoje plusy i minusy, ale wtedy projekt nabiera zupełnie innego charakteru.

Motywacja we własnym projekcie

Teraz nasuwa się pytanie. Gdzie takich ludzi znaleźć? W szkole? Na studiach? W pracy? Najczęściej w Internecie. Sam kiedyś trafiłem do jednego projektu właśnie poprzez forum dyskusyjne, a konkretnie 4programmers. Jest tam nawet poświęcony osobny do tego dział. Z bliższego otoczenia również są szanse, ale niewielkie. Kiedy zaprezentujemy się w Internecie trafiamy do znacznie większego grona. Dlatego bardzo ważne jest mieć już gotową koncepcję i wizję tego co chcemy robić. Jeśli na samym starcie pokażesz, że sam nie wiesz czego chcesz to ludzie albo zaczną odchodzić albo w ogóle nie będą chcieli z tobą rozmawiać. Zanim, więc zaczniesz szukać przygotuj trochę materiałów. Czy to prezentację czy jakiś tekst, aby osoby zainteresowane mogły zobaczyć co chcesz dokładnie zrealizować, ale i jednocześnie pokażesz, że ten projekt traktujesz na poważnie i szybko go nie zakończysz. No i jednocześnie podniesiesz też motywację innych.

Nie przenoś rutyny z pracy do projektu

Kolejną kwestię o której już wspomniałem, ale tym razem zatrzymam się na niej dłużej, jest codzienna rutyna jaką przynosimy z pracy. Jest to najczęstszy błąd popełniany przez doświadczonych programistów. Podejmują się wyzwania stworzenia coś swojego i zaczynają od wprowadzania przyzwyczajeń, które znają ze swojej programistycznej codzienności we firmie, gdzie spędzając większą część dnia. Taki projekt może, ale nie musi się udać. Wszystko zależy od tego jak wygląda on we firmie. Ale najczęściej szybko się nudzi. Bo to co mamy w pracy przenosimy do domu. Zamiast się relaksować, jesteśmy dalej w pracy.

Nie przenoś rutyny z pracy do projektu to pierwsza zasada. Nie chcesz się zdemotywować, zadbaj o to, aby twój projekt był zupełnie czymś innym niż tym co masz na co dzień do czynienia. Oczywiście są dozwolone jakieś rozwiązania, które się sprawdzają, ale staraj się je ograniczać do minimum. Projekt w jaki się angażujesz ma być dla Ciebie i innych okazją to nauczenia się czegoś nowego i zdobycia nowego doświadczenia. Zbudowania portfolio czy otworzeniem nowych ścieżek kariery. Sam kiedyś popełniłem ten błąd, a nawet pracowałem po godzinach nad dodatkowymi projektami dla firmy, w której pracowałem. Przeważnie kończyło się to tym, że po kilku dniach pracy traciłem kompletnie motywację. Bo kiedy robimy coś dla obecnego pracodawcy to wchodzą w to również wymagania. A kiedy są wymagania pojawia się stres. Kiedy pojawia się stres spada motywacja.

Przemyśl i rozpisz

Kolejna zasada to dokładnie przemyśl i rozpisz co chcesz robić i jak chcesz to zrobić. Nieważne czy będziesz programować w pojedynkę czy w większym gronie. Zdecydowanie jest tutaj bardzo ważne. Najkrócej utrzymują się projekty, w których zaczyna się od szukania programistów i organizowania spotkań online. A pomysły na aplikację i plany są robione na końcu. Takie podejście prowadzi do szybkiego końca.

Miałem już takie sytuacje kiedy ktoś chciał coś zrobić, ale nie do końca miał sprecyzowane. Zaczynało się od bezsensownego spotkania, w którym każdy miał wymyślić co chciałby robić. Po chwili okazywało się, że większa część uczestników w ogóle nie umie programować i trzeba poszukać kogoś kto umie. A takie osoby ciężko znaleźć szczególnie kiedy ma dołączyć do czyjegoś projektu i wziąć całą odpowiedzialność. Zapewniam was, że takie podejście nie zadziała.

Ludzie w branży IT chętnie podejmują się dodatkowych projektów pod warunkiem, że ma on dokładnie sprecyzowany cel i jesteś w stanie przewidzieć czego możesz się spodziewać. Rozwój w pewnych sytuacjach staje się bardziej zachęcający niż pieniądze, a przy okazji poznajemy też nowych ludzi. Zanim, więc zabierzesz się za projekt przemyśl go. Poświęć trochę czasu w weekend czy nawet cały tydzień. Weź wolne w pracy i spróbuj coś przygotować. Dokładnie przemyśl co chcesz zrobić, w jakiej technologii, jakie frameworki i system kontroli wersji chcesz użyć no i najważniejsze, jaką aplikację chcesz pisać. Rozrysuj koncepcję, porób schematy blokowe, diagramy, opisz w kilku słowach, albo może nawet przygotuj jakiś prototyp. Nieważne czy będziesz robić to sam czy z kimś. Kiedy będziesz mieć wszystko rozpisane będzie Ci lepiej się do tego zabrać nawet indywidualnie. Na koniec kiedy masz coś przygotowane do tego stopnia, że można ruszyć z projektem, przygotuj jakąś prezentację roześlij po forach, grupach na Facebooku czy LinkedIn, albo jakiś serwisach i czekaj. Może ktoś się zgłosi. A w międzyczasie zaczynaj kodować sam.

Cierpliwość i pośpiech

Projektowanie i szukanie programistów to bardzo czasochłonne zadanie, które może trwać tygodniami, a nawet miesiącami. Chociażby dlatego, że nie każdy będzie w stanie się utrzymać dłużej niż kilka dni. Z różnych przyczyn. Spadnie mu szybko motywacja lub stwierdzi, że jednak to nie dla niego. Będą też przypadki kiedy to my nie będziemy chcieli wziąć danej osoby, bo będzie albo za mało zaangażowana, albo będzie próbowała coś zmieniać po swojemu. Oczywiście to jest nasz projekt i musimy się trochę tego strzec, ale też słuchać ludzi i zmieniać pod nich. W ten sposób pokażemy, że oni również mają w niewielkim stopniu wpływ na rozwój i organizację projektu. Wszystko ma tylko swoje granice.

Zatem kolejna zasada to cierpliwość i dynamika projektu. Pewnych rzeczy nie przeskoczymy. Muszą trwać. I głównie będzie to tyczyło się samego projektu. Rozwoju naszej aplikacji. Zanim przejdziemy do kolejnego kamienia milowego. Ale jednocześnie musimy dbać o to, aby coś w tym projekcie się działo. Głównie chodzi tu o aspekty organizacyjne. Jeśli na przykład code review to staraj się regularnie przeglądać kod. Merguj w miarę szybko gałęzie w repozytorium. Odpowiadaj na wiadomości. Co jest bardzo też ważne. Zanotuj na bieżąco postępy. To nie tylko motywuje zespół, ale również siebie samego. Cierpliwość i dynamika jest również bardzo ważna w indywidualnych projektach. Jeśli nie zabierasz się za pracę regularnie to prawdopodobnie będzie to wszystko trwało zbyt długo aż w końcu zapomnisz o projekcie i go nie zrealizujesz.

Przepływ informacji i dokumentacja postępów

Dynamika projektu w zespole najczęściej opiera się na przepływie informacji, z kolei w indywidualnych formach na monitorowaniu postępów. Kiedy mamy na przykład projekty open source to najczęściej można ocenić czy żyje czy całkowicie umarł. Po czym? Po postępach i aktywności dewelopera lub deweloperów. Na rynku stosuje się rozwiązania, przystosowane do zarządzania projektami, które łączą się również z kontrolą wersji. Na podstawie kontroli wersji jest na przykład śledzona aktywność. Kto jaki ma wkład w repozytorium. Co dokładnie zmienił itd. W zadaniach na przykład mamy system komentarzy, gdzie można udzielać pomocy czy prowadzić dyskusje z członkami zespołu jak i naszymi użytkownikami aplikacji. To wszystko to jest właśnie dokumentacja postępów i przepływ informacji.

Bo właśnie na podstawie takich informacji jesteśmy w stanie ocenić czy ten projekt faktycznie żyje, czy jego członkowie robią coś fajnego i jak jest zorganizowany. To dodatkowo motywuje i zachęca do jego dołączenia, a jeśli dodatkowo robimy fajną i przydatną aplikację to pozyskujemy też potencjalnych klientów. Taka dokumentacja może się też przydać w sytuacjach kiedy szukamy inwestora, albo organizujemy jakąś zbiórkę na dalszą realizację projektu.

Automatyzacja w zakresie prowadzenia projektu

Mamy przepływ informacji, mamy dokumentację. Wiemy już, że warto programować w zespole, ale też można samemu. Kwestie organizacyjne nawet we własnym projekcie programistycznym są bardzo ważne, gdyż pozwalają łatwiej zapanować nad tym co się dzieje i wrócić po dłuższej przerwie. Dokumentować możesz w formie ręczne, ale zdecydowanie zalecam robić to automatycznie. Robią to właśnie systemy zarządzania projektami i niektóre systemy kontroli wersji. Ja na przykład używam Gitea, który jest bardzo podobny do Github’a. Ale jest też Open Project, darmowy w podstawowej wersji i w zupełności wystarczający. GibLab, czyli system kontroli wersji i zarządzenie projektem w jednym. Azure DevOps od Microsoftu i inne. Rozwiązań tego typu jest sporo. Warto je wszystkie zainstalować, potestować no i nauczyć jest przynajmniej jednego z nich. Pamiętaj, aby był taki, którego nie używasz na co dzień w pracy.

Są też zwolennicy dokumentowania wszystkiego ręcznie. Czyli prowadzenie tabelek w Excelu i wpisywania wszystkiego każdego dnia. Ma to jedną dużą zaletę. Na bieżąco widzisz jak się projekt zmienia. Jaka jest aktywność jego uczestników oraz na jakim etapie jesteś. Takie wprowadzanie ręczne jest jednak podatne na błędy, a druga kwestia po jakimś czasie się znudzi. Jako indywidualny deweloper lub organizator nie będziesz mieć również czasu dodatkowe rzeczy. W końcu robisz to po godzinach. Warto, więc pomyśleć i skorzystać z rozwiązań, które zrobią to za Ciebie. Skupisz się dzięki temu na ważniejszych rzeczach, zwiększające motywację niż kolejna dzienna rutyna.

Chodź powiedziałem, że automatyzacja to bardziej zalecenie niż zasada, to traktuj ją jako to drugie. Byłem w projektach, w których ta automatyzacja stała na bardzo słabym poziomie. Wiele rzeczy było wykonywane ręcznie i po jakimś czasie było to coraz bardziej zaniedbywane. Dla uczestników są to ciekawe i motywujące informacje, ale dla samego organizatora to po dłuższym czasie nudne rutynowe czynności. W konsekwencji kończyło się to tak, że inne elementy projektu nie były w ogóle ruszane tylko skupiano się na statystykach. W zespole trzeba niestety bardzo często innych mobilizować, a jeśli zajmujemy się wprowadzaniem danych do tabelek to robimy to rzadziej.

Podsumowanie

Podsumowując wszystkie zasady i zalecenia jakie tutaj podałem można wyciągnąć kilka wniosków. Po pierwsze własny projekt programistyczny to zadanie pochłaniające sporą część wolnego czasu. Jeśli zależy nam oczywiście żeby coś z tego powstało. Motywacja może spaść zaraz na początku, a powodem tego jest najczęściej nieodpowiednie przygotowanie. Dlatego zanim za coś się zabierzesz najpierw przemyśl co chcesz zrobić i czy będziesz mieć na to czas. W innym wypadku będzie to strata czasu.

Druga kwestia to odpowiedzialność. Programując samemu czegoś takiego nie ma, ale kiedy szukamy już osób do współpracy musisz liczyć się z tym, że spadają na Ciebie pewne obowiązki. Jeśli je zaniedbasz to w przyszłości może być Ci trudno znaleźć programistów do kolejnych projektów lub obecnego. Dlatego moja rada jest taka, że jeśli nie jesteśmy w stu procentach pewni zacznij programować sam, a potem szukaj. Zobaczysz jak będzie utrzymywać się twoja motywacja. Będziesz miał już sporo rzeczy zorganizowane i łatwiej będzie później wprowadzić nowe osoby. Opanujesz też jakiś system do zarządzania projektami, co pozwoli już na starcie zautomatyzować sporo rzeczy.

Mam nadzieję, że wpis, który dla Ciebie przygotowałem był ciekawy i motywujący. Jeśli masz jakieś pytania lub chcesz podzielić się opinią zostaw komentarz. Na pewno na niego odpowiem.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *