Kategoria: Bez kategorii

Aplikacja MVP – Minimum Viable Product

W dzisiejszym artykule chciałbym Wam przybliżyć czym jest aplikacja MVP. Zacznijmy może od prostej definicji która jest skrótem z języka angielskiego. Skrót ten oznacza produkt który reprezentuje sobą minimalną akceptowalną wartość.

Często lubię posługiwać się przykładami realnymi, które łatwo nam sobie wyobrazić. Powiedzmy drogi czytelniku, że chcesz mieć rower MVP. Oznacza to że ten rower ma minimalne funkcjonalności które określają go jako rower i nie pomylisz go z hulajnogą czy skuterem. Zatem taki rower MVP ma koła, ramę, kierownice, siodełko, pedały oraz hamulec. Czego nie będzie miał rower MVP? Przerzutek, dodatkowego hamulca, oświetlenia, dzwonka, lusterek, nie będzie wykonany z lekkich materiałów itd. Mam nadzieje że rozumiesz główne przesłanie. Ale tutaj dochodzimy do bardzo ważnej cechy produktu MVP. Produkt, w naszym przypadku rower, będzie w pełni funkcjonalny czyli nie powiemy że jest nieskończony lub niedziałający. Możemy powiedzieć że nie jest zbyt elegancki, modny lub wygodny, ale działa, i przemieszcza nas w bezpieczny sposób z punktu A do punktu B.

Jakie korzyści osiągniesz z aplikacji MVP

Dobrze, mam nadzieje że teraz w Twojej głowie pojawiła się niepokojąca myśl. Po co mi taki “słaby” rower gdy na rynku mamy tak dużo pięknie wyglądających rowerów z różnymi udogodnieniami, a nawet mamy rowery elektryczne które robią główną robotę z nas. Często gdy coś kupujemy to staramy się kupić coś bardzo dobrego, żeby posłużyło nam na lata i dzięki temu jesteśmy w stanie wydać na taki produkt więcej pieniędzy. Dlaczego nie mielibyśmy robić tego samego z aplikacjami?

Produkty które są wytwarzane masowo tj. rowery, telewizory, samochody i wiele wiele innych zostały wymyślone bardzo dawno temu i od tego czasu są ciągle rozwijane i udoskonalane, przechodzą miliony prób i dostają feedback od klientów. Z większością aplikacji jest zupełnie inaczej. Oprogramowanie bardzo często pisane jest pod specyficzne wymagania rynku lub klienta, dlatego powstaje od zera i tylko niektóre moduły został sprawdzone i zweryfikowane przez rynek. Jeżeli coś nie zostało przetestowane przez klientów to istnieje bardzo duża szansa że się nie sprawdzi. Dlatego inwestowanie bardzo dużo na samym początku może nie być w pełni uzasadnione. Może lepiej zrobić coś podstawowego, co może dać nam minimalną wartość i coś co możemy przetestować w realnym scenariuszu.

Czy każda firma potrafi osiągnąć założenia aplikacji MVP?

Teoretycznie każda firma może dla Was zrealizować założenia aplikacji MVP, niestety w praktyce tylko firmy w pełni rozumiejące technologię Agile potrafią to zrobić. Zapytasz się pewnie dlaczego? Odpowiedź nie będzie bezpośrednia i prosta. To tak jakby odpowiedzieć na pytanie: Dlaczego jeden aktor jest świetny i osiągnął sukces a drugi nie? W aktorstwie trzeba mieć iskierkę talentu i bardzo ciężko pracować i podchodzić do życia poważnie. Przekładając to na biznes, firma musi być dojrzała, rozumieć biznes, znać Twoje potrzeby, potrafić Ci doradzić ale zarazem nie zepsuć Twojego pomysłu, musi szanować Twój budżet i być skupiona na celu. Brzmi jak “mokry sen” 🙂 Pewnie dlatego to nie jest takie łatwe tworzyć produkty MVP.

Jak powstaje aplikacja MVP w praktyce

Przejdźmy teraz do praktyki, czyli jak zbudować taką aplikację? Dróg do celu może być wiele, ja posłużę się tutaj swoim autorskim podejściem wypracowanym przez wiele lat pracując w systemie Agile. Do tego celu posłużę się poniższą listą poszczególnych kroków:

1. Identyfikacja potrzeb klienta.
2. Opracowanie szablonów lub projektów graficznych (dokumentacja).
3. Opracowanie szczegółowego zakresu i harmonogramu prac.
4. Praca w trybie Agile (tryb zwinny).
5. Cotygodniowy / 2 tygodniowe spotkanie dotyczące aktualizacji postępu, zakresu i harmonogramu prac.
6. Zakończenie projektu.

Rozwińmy poszczególne punkty tego harmonogramu. W pierwszej fazie praca nad aplikacja zanim zaczniemy cokolwiek tworzyć musimy poznać bardzo dokładnie szczegóły działania oprogramowania. Staramy się zrozumieć głęboką motywację oraz podstawowy cel jaki klienta stawia przed tą aplikacją. My ze swojej strony doradzamy jak najlepiej podejść do tematu, nie tylko od strony technicznej ale także biznesowej. Na tym etapie prac nie jesteśmy “klakierami” którzy przyklaskują twojemu pomysłowi, staramy się go pozytywnie krytykować abyś mógł/mogła czerpać z naszego doświadczenia.

W drugiej fazie po poznaniu potrzeb klienta i zadań stojących przed aplikacją tworzymy dokumentację techniczną, która w zależności od złożoności i projektu może przybierać różne formy (schemat, opis, projekt graficzny). Już na tym etapie jesteśmy w stanie wykryć słabe i mocne strony aplikacji i stosownie szybko na nie zareagować.

Następnie przygotowujemy harmonogram w którym opisujemy główne funkcjonalności oraz terminy ich realizacji. Dokumentacja i harmonogram z mojego doświadczenia są jednym z najbardziej istotnych elementów procesu tworzenia aplikacji MVP, zaraz po pracy w trybie Agile.

Po tych etapach przystępujemy dopiero do prac programistycznych. Pracujemy w bardzo elastyczny sposób tzn. że co tydzień lub w maksymalnie co 2 tygodnie robimy sesje demo z klientem aby zademonstrować mu jak obecnie działa aplikacja i czy idziemy w dobrym kierunku. Dlaczego to takie istotne? Chodzi przede wszystkim o to aby sprawdzać czy może aplikacja nie osiągnęła już swojego założenia MVP wcześniej lub czy może nie potrzebujemy dostosować jej do zmieniającego się rynku. Ten etap powtarzamy w cyklach aż do zakończenia projektu.

Co potem? Teraz przychodzi czas na rynek i weryfikacje w praktyce aplikacji. Jeżeli rynek przyjmie pozytywnie stworzoną aplikację z reguły klienci wracają do nas z nowymi funkcjonalnościami i aplikacja z MVP staje się prawdziwą aplikacją internetową.

Plusy i minusy aplikacji MVP

Czas na wstępne podsumowanie zalet i wad aplikacji MVP. Nie traktuj proszę tego jako wyrocznie, a raczej moje subiektywne zdanie. Pamiętaj także że cechy aplikacji będą różnie oceniane w zależności od wymagań stojących przed aplikacją internetową oraz sytuacji biznesowej.

Zalety	Wady
Niski nakład finansowy	Dłuższy proces osiągania ostatecznego efektu
Przetestowanie swojego pomysłu niskim kosztem	Duże zaangażowanie ze strony klienta
Poznanie potencjalnych klientów	Trudniejszy proces tworzenia aplikacji, który musi uwzględnić dużą elastyczność
Szybkie uruchomienie wersji podstawowej oprogramowania
Wczesna identyfikacja mocnych oraz słabych stron aplikacji internetowej
Zmniejszone ryzyko inwestycyjne
Potencjalnie szybki zysk inwestycyjny

Podsumowanie

Mam nadzieje że ten artykuł przybliżył Wam pojęcie Aplikacji MVP. W biznesie nawet mała różnica przy dużej skali tworzy dźwignie która jest w stanie wznieść Twój biznes na wyższy poziom. Moim zdaniem każde przemyślane działanie w rozwój firmy przynosi bardzo szybko zysk, szczególnie innowacyjność rozpoznawana przez stosowanie oprogramowania dla firm w różnej formie czy to desktopowej czy internetowej.

Pamiętajcie że nawet 1% redukcji kosztów produkcji lub zarządzania produktem ma niesamowicie duży wpływ. Szczególnie stosowanie Aplikacji MVP pozwoli Wam zminimalizować koszty, zbadać rynek, otrzymać feedback od klientów.

Czy warto inwestować w aplikacje internetowe? Odpowiem cytatem Richarda Bransona: “Moją filozofią jest: jeżeli mam jakieś pieniądze to inwestuje je w nowe przedsięwzięcia, nie pozwalam im siedzieć w miejscu”.

Co to jest dokumentacja techniczna

Pewnie osoby nie techniczne zastanawiają się co to jest ta dokumentacja techniczna i dlaczego powinni na nią zwracać uwagę. Myślę że najłatwiej porównać ją do innych dokumentacji przygotowywanych np. w trakcie prowadzenia budowy budynku lub innej infrastruktury. W przypadku budowy domu bez takiej dokumentacji technicznej jest niemożliwym rozpoczęcia prac ze względów prawnych. Czy ktokolwiek z Was zastanawiał się dlaczego urzędnicy tego wymagają? Oczywiście powodów jest wiele ale ja posłużę się jednym czynnikiem – bezpieczeństwo. Jeżeli potencjalny projekt miałby zagrażać życiu lub zdrowiu ludzi to oczywiście taki projekt nie zostanie zatwierdzony.

Ok mówimy dużo o projekcie technicznym budynków ale o co chodzi z dokumentacją techniczną aplikacji? Otóż jest podobnie. Taka dokumentacja powinna zawierać najważniejsze założenia dotyczące aplikacji takie jak:

• środowiskach i na jakich systemach dana aplikacja ma działać,
• jaki potencjalnie ruch ma obsługiwać,
• no i oczywiście najważniejsze, czyli opis funkcjonalności.

Jeżeli posłużymy się analogią bezpieczeństwa w projektach budowlanych to taka dokumentacja techniczna aplikacji daje poczucie bezpieczeństwa obu stronom, zamawiającemu i wykonawcy, każda ze stron wie czego może się spodziewać. Czyli reguła win – win.

Jak już wiemy co to jest to przejdźmy do kolejnej nurtującej kwestii – dlaczego potrzebujemy dokumentacji technicznej? Co może nas motywować do jej stworzenia? Ludzie z reguły są leniwi, i bardzo dobrze, bo do tej pory mieszkalibyśmy w jungli i polowali na mamuty, a dzięki temu że jesteśmy leniwi to mamy to co mamy, czyli technologie, medycynę i inne zbytki, zapełniające nasze życie jak xbox lub tik tok 🙂

Skoro ludzie są leniwi to trzeba znaleźć jakiś inny sposób aby tworzyć bardzo dobre jakościowo produkty. Rozwiązaniem na to są wszelkie zapisane ustalenia. Jeżeli jakiś projekt trwa więcej niż kilka tygodni to ciężko zapamiętać wszystkie szczegóły które zostały na początku ustalone. Gdybyśmy tego nie spisali to albo stracilibyśmy bardzo wiele czasu na ponowne ustalania albo powtórne ustalanie czegoś mogłoby wpłynąć negatywnie na już istniejące elementy aplikacji. Gdy tworzymy dokumentację to od początku wiemy jak ma działać dana aplikacja i już na tym etapie jesteśmy w stanie wyłapać niezgodności lub konflikty w poszczególnych modułach systemu, a im wcześniej je znajdziemy tym więcej zaoszczędzimy.

Kto powinien przygotować dokumentację?

Uważam osobiście po wielu latach doświadczenia, że dokumentację powinny przygotowywać obie strony kontraktu. Zamawiający najlepiej wie czego chce, a wykonawca powinien wesprzeć swoją techniczną wiedzą zamawiającego.

Każdemu kto zajmuje się zawodowo projektowaniem i tworzeniem aplikacji zachęcam do stworzenia swojego szablonu dokumentacji technicznej, ze swojej strony w dalszej części artykułu wskaże co powinno się znaleźć w takiej dokumentacji.

Dlaczego zachęcam do stworzenia takiego szablonu? Ponieważ pomoże to obu stronom ubrać swoje potrzeby w pewne ramy. Niejednokrotnie spotykałem się z tym, że klienci przychodzili do mnie z 30 stronicowymi dokumentami opisującymi w bardzo lakoniczny sposób jak ma działać aplikacja pomimo że było tam tak dużo treści. Wpisanie tego w odpowiedni szablon pomoże obu stronom zapanować nad niepotrzebnym słowotwórstwem, które w żaden sposób nie wpływa na opis funkcjonalności.

Oczywiście zamawiający nie zawsze może dysponować odpowiednią wiedzą, a także czasem aby opisać wszystko dokładnie, dlatego podział tych obowiązków powinien być ustalony na samym początku i myślę że należy w tym pierwszym etapie być bardzo elastycznym. Dobrym pomysłem jest organizowanie wspólnych sesji aby omawiać poszczególne etapy tworzenia tejże dokumentacji.

Czy potrzebuje projektu graficznego przy tworzeniu dokumentacji technicznej?

Myślę że przyda się tutaj krótkie wprowadzenie, co to jest projekt graficzny aplikacji webowej. Jak można się domyślać jest to obraz lub zbiór obrazów (grafik) przedstawiająca jak będzie wyglądać aplikacja. Jeżeli ktoś spotkał się już z projektem graficznym strony www to oczywiście może sobie łatwo wyobrazić czego się spodziewać. Należy jednak zaznaczyć że przy projektach graficznych aplikacji nie stawiamy aż w takim stopniu na przepiękną grafikę samą w sobie, ale na użyteczność aplikacji.

Jeżeli mowa o użyteczności to jednym z motywów popychających nas do stworzenia projektu graficznego jest przekonanie się czy nasza aplikacja będzie wygodna dla użytkowników zanim ją zaczniemy budować. W ten sposób zaoszczędzimy mnóstwo czasu gdybyśmy nagle pod koniec prac nad aplikacją uznali że pewne jej elementy nie są funkcjonalne z punktu widzenia przyszłego użytkownika.

Skoro wiemy już czym kierować się przy podejmowaniu decyzji czy zlecić przygotowanie projektu graficznego to musimy sobie jeszcze odpowiedzieć na pytanie: Kto powinien go przygotować? Od razu nasuwa nam się odpowiedź – Grafik. To jednak nie jest do końca poprawna odpowiedź, gdyż są różni graficy. Projekt aplikacji powinien głównie przedstawiać przepływ danych oraz w jaki sposób przyszli użytkownicy będą posługiwać się naszą aplikacją, dlatego przygotowaniem projektu najlepiej żeby zajął się UX Designer, czyli osoba specjalizująca się w projektowaniu interfejsu użytkownika. UX Designer powinien ściśle współpracować z właścicielem, który to najlepiej wie jak ma działać dana aplikacja.

Może to nie wydaje się na pierwszy rzut oka oczywiste ale praca nad projektem graficznym jest dużo tańsze niż praca developerów którzy musieliby niepotrzebnie zmieniać funkcjonalności po ich wdrożeniu.

Jak przygotowywać dokumentację techniczną

Aby odpowiedzieć szczegółowo na to pytanie, potrzeba by przygotować oddzielny artykuł. Ja w tej części skupię się bardziej an ogółu tak aby lepiej zrozumieć czym jest taka dokumentacja. Od razu na wstępie chciałbym zaznaczyć, że nie ma na ten dokument jakiegoś wzoru czy opracowania naukowego. W moim przykładzie, który postaram się tutaj opisać, opieram się na swoich doświadczeniach przy tworzeniu takich dokumentacji.

Aby łatwiej poruszać się po dokumentacji warto ją ustrukturyzować (podzielić na rozdziały). Przykładowa struktura może zawierać:

1. Tytuł projektu
2. Opis projektu
3. Określenie wymagań

• językowych
• technicznych
• dotyczącego przewidywanego ruchu
• graficznych
• SEM & SEO

4. Infrastruktura IT
5. Opis funkcjonalny projektu

• opis poszczególnych modułów projektu
• wymagania co do formularzy i ich walidacji
• możliwe funkcje które użytkownik może wykonać w danym module

Jednak zanim zaczniemy opisywać naszą aplikację ja polecam przygotować sobie makiety (można je wykonać ręcznie, ołówkiem lub za pomocą specjalistycznych programów), które w sposób graficzny przedstawią jak nasz aplikacja ma działać. To działanie podobnie jak przygotowanie projektu graficznego przez UX Designera pomoże nam dostrzec pewne luki w logice aplikacji, a także posłuży jako świetna baza do stworzenia profesjonalnego projektu graficznego.

Oczywiście ten punkt dotyczący tworzenia makiet można pominąć, gdy aplikacja jest bardzo mała lub gdy mamy taką wizję, ale ja ze swojego doświadczenie zalecam poświęcenie kilku dodatkowych godzin aby to zrobić.

Na koniec chciałem także przedstawić inne formy przygotowywania dokumentacji technicznej. Możemy sobie wyróżnić:

• dokumentację opisową – tekstowe przedstawienie funkcjonowania aplikacji (może być w strukturze którą zaproponowałem.
  Zaletą takiej dokumentacji jest możliwość jej wykorzystania do opisu poszczególnych zadań dla programistów
• dokumentację opisowo graficzną – jest to połączenie dokumentacji tekstowej i graficznej. Jest to rekomendowana przeze mnie forma dokumentowania aplikacji.
• dokumentację graficzną – przestawienie działania aplikacji w postaci grafik przedstawiających poszczególne stany aplikacji
• dokumentację blokową – jedna z najtańszych i najszybszych do przygotowania jednak z mojego punktu widzenia przynosząca najmniej wymierne korzyści jednak bardzo dobra, jako baza do przygotowania bardziej rozbudowanej dokumentacji.

Dlaczego warto wytwarzać dokumentacje

Poniekąd odpowiedzieliśmy sobie między wierszami na to pytanie. Tutaj jednak postaramy się podsumować to co do tej pory powiedzieliśmy sobie o dokumentacji technicznej z naciskiem dlaczego warto.

Aby szybko odpowiedzieć sobie na to zagadnienie warto zastanowić się czy nasza aplikacja będzie duża i skomplikowana. Jeżeli odpowiedź jest twierdząca to stanowczo powinniśmy podjąć te wysiłki i na pewno ta inwestycja się zwróci w postaci mniejszej ilości poprawek i zmian w funkcjonalności. Jeżeli nasz projekt wydaje się krótki np 1-3 miesiące pracy to można posłużyć się mniej skomplikowaną dokumentacją, np.: graficzną lub blokową.

Wiadomym jest że wytworzeniem takiej dokumentacji będzie wiązać się z jakimś nakładem czasowy a co za tym idzie także nakładem finansowym. Jednak uwierzcie mi, z mojego doświadczenia, te nakłady są kroplą w morzu jeżeli porównamy to z późniejszymi nakładami jakie trzeba ponieść gdy czegoś się do końca nie przemyślało.

Życiowe przypadki gdy projekty nie posiadały dokumentacji.

Na koniec tego artykułu chciałbym was przestrzec przed brakiem dokumentacji technicznej i rozpisanych funkcjonalności na bazie moich doświadczeń oraz doświadczeń moich klientów. Wiadomym jest że przygotowanie dokumentacji oraz projektów, makiet graficznych zabiera sporo czasu, dodatkowo opracowanie całej koncepcji skomplikowanej aplikacji także może zająć sporo czasu. Byłem świadkiem gdy taki proces zajmował rok czasu. Dużo? To oczywiście zależy, w projekcie w którym brałem udział powiedziałbym że dało się to zrobić w 6 miesięcy ale wcale nie uważam że rok czasu przy  bardzo zaawansowanych projektach to dużo.

Przejdźmy teraz do porażek z którymi się w swojej karierze spotkałem. Pierwszą z nich był nasz prywatny projekt marketingowy którego dokumentacja techniczna została napisana na kolanie i gdy doszło do implementacji i coś zaczęło powstawać to okazało się że: 

• po pierwsze to nie wygląda ładnie (brak projektu graficznego),
• po drugie zaczęły pojawiać się logiczne braki podstawowych funkcjach.

Nasza aplikacja wydawała się dość prosta i mała jednak ostatecznie przerwaliśmy pracę i obecnie opracowujemy do niej dokumentację techniczną i projekt graficzny od nowa. Dzięki temu oprogramowanie zyskało dodatkowe funkcjonalności oraz zostało przemyślane biznesowo jako rozwiązanie SaaS.

Kolejną aplikacją w której mieliśmy przyjemność brać udział był system parabankowy który miał opisane pewne ramy i nawet przygotowane projekty graficzne, jednak w połowie prac nad aplikacją zaprzestano analizować kolejne funkcjonalności i przygotowywać odpowiednie projekty i przez to nasza praca posuwała się bardzo wolno i na koniec musieliśmy sporo rzeczy przerobić lub robić od nowa.

Następną lekcję wyciągnąłem z aplikacji wspierającej procesy HR. Jest to bardzo zaawansowana aplikacja która przez kompletny brak dokumentacji technicznej była zmieniana tyle razy że już tego nie sposób spamiętać. Ostatecznie aplikacja ujrzała światło dzienne ale moim skromnym zdaniem dało się ją napisać w 4 lub 5 krotnie mniejszym budżecie.

Myślę że nic tak nie przemawia do przedsiębiorców jak pieniądze. Więc proszę Was zastanówcie się na tym tematem i nie wybierajcie zawsze najszybszej i najtańszej drogi w ramach przetargu, bo może Was to zaprowadzić w poważne kłopoty finansowe.

Mam nadzieje że po przeczytaniu tego artykułu jesteście uzbrojeni w wiedzę, którą będziecie mogli wykorzystać przy podpisywaniu kontraktów i umów na zrobienie oprogramowania dla Waszych firm.

Kod review (CR) – dla niektórych zmora dla innych niepotrzebna rzecz, jeszcze inni powiedzą że zwalnia proces developmentu. W każdym z tych stwierdzeń jest trochę prawdy i to niestety prawdy negatywnej. A co powiecie gdybym powiedział wam że CR może być źródłem wiedzy, motywacji zespołu i przyśpiesza proces rozwoju aplikacji?

Dla naprawdę niewtajemniczonych, bardzo prosta definicja kod review – jest to proces mający na celu wykrycie błędów popełnionych w kodzie w trakcie tworzenia oprogramowania, co za tym idzie poprawienie jakości tworzonego produktu.

W tym artykule skupię się bardziej na teoretycznej jak i psychologicznej stronie zagadnienia. Techniczna część pojawi się w innych artykułach.

Po co to robić

Głównym celem przeglądania kodu jest zwrócenie uwagi jego jakość. Niezwykle ważne jest spójność z ogólno przyjętymi lub wewnętrznymi standardami, dzięki czemu nowo dołączająca osoba będzie miała poczucie że kod pisała jedna osoba.  Taki kod jest potem łatwiejszy do utrzymania i ewentualnych zmian. Nie mam tutaj na myśli dobrych edytorskich standardów bo to za nas powinien wykonać ESLint, my powinniśmy skupić się na aspektach architektonicznych, strukturze kodu oraz stosowanych wzorcach projektowych, jego czytelności i wydajności.

W swojej pracy często natrafiam na nieczytelny kod. Nie chcę się tutaj rozwodzić na tym co to oznacza że kod jest czytelny lub nie ale odsyłam do świetnej książki Roberta C Martina “Clean Kod” (“Czysty Kod”). Pokrótce powiem że jeżeli nie potrafisz przeczytać ze zrozumieniem co dana linijka wykonuje to znaczy że kod jest zbyt skomplikowany.

Drugim bardzo bardzo ważnym aspektem jest znalezienie ewentualnych błędów. To zadanie stawia przed przeglądającym kod trudne wyzwanie. Aby znaleźć błąd patrząc się tylko na kod trzeba mieć duże doświadczenie i sporo praktycznej wiedzy. Jest to zadanie trudne i nie zawsze kończy się sukcesem. Nawet najsprawniejsze oko czasami nie dostrzeże ukrytego błędu. Jak się uchronić przed taką sytuacją? Pogódź się z nią nie wychwycisz wszystkiego. Błędy powinny być też wyłapywane przez testy automatyczne i to po to programiści je piszą.

Podsumowując tą część uważam że ważniejszy jest pierwszy aspekt czyli struktura, architektura i szeroko pojęta jakość kodu.

Aspekt psychologiczny

Każdy artysta, rzemieślnik, i tutaj na równi postawię też programistę, gdyż uważam że to taki nowoczesny rzemieślnik, stara się aby jego produkt był najwyższej jakości. Często w związku z tym utożsamia się osobiście ze swoim dziełem i wiąże się z nim emocjonalnie. Gdy robisz komuś code review musisz pamiętać o tym że możesz kogoś nieświadomie urazić krytykując jego dzieło.

Postawmy się teraz w roli twórcy oprogramowania. Staraliśmy się wykonać naszą pracę najlepiej jak potrafiliśmy a teraz nas ktoś krytykuje i uważa że nasze pomysły są złe. Jak znaleźć tą granicę pomiędzy przeglądającym a twórcą aby wszyscy się dobrze zrozumieli. O tym więcej w dalszej części ale tutaj taka moja rada. Gdy piszesz komentarz do czyjegoś kodu to staraj się aby to było konstruktywne i asertywne. Używanie sformułowań że ta część kodu jest po prostu zła albo że tak się nie pisze nie jest dobrym komentarzem. Uzasadnij dlaczego coś jest złe i zaproponuj jak to zrobić inaczej. Wrzuć ciekawy artykuł na ten temat aby poszerzać wiedzę. Wtedy ta osoba czytając dodatkową, postronną opinię na dany temat zrozumie sama że źle zinterpretowała tą część kodu i dodatkowo będzie mieć satysfakcję ze czegoś nowego się nauczyła. 

Gdy jesteś twórcą kodu schowaj dumę do kieszeni i nie traktuj tego jako atak na Ciebie bo to tylko kod. Sprawdź co napisał przeglądający i jeżeli miał rację podziękuj za to że czegoś Cię nauczył a jeżeli się z nim nie zgadzasz to niech to będzie konstruktywne, podeprzyj się artykułem lub przykładami.