Jak tworzenie aplikacji internetowych ma się do „Zasad życia” Jordana Petersona?

Kubek na laptopa Rules for life

Zainspirowany książką Jordana Petersona *12 Rules for Life*, uderzyło mnie to, jak jego zasady porządku, odpowiedzialności i rozwoju osobistego mogą wykraczać poza ich pierwotny kontekst i mieć zastosowanie do różnych aspektów życia. Zacząłem więc analizować, zasada po zasadzie, aby sprawdzić, czy to zadziała. Szczególnie interesujący był pomysł, że małe, konsekwentne działania prowadzą do znaczących rezultatów, ponieważ odzwierciedla to iteracyjny proces tworzenia oprogramowania, zwłaszcza Agile. Byłem ciekaw, czy te zasady, które opowiadają się za dyscypliną, jasnymi celami i skupieniem się na podstawach, mogą również poprawić sposób, w jaki podchodzimy do kodowania, zarządzania projektami i współpracy zespołowej. Ta ciekawość doprowadziła mnie do zbadania, w jaki sposób zasady te można zintegrować ze światem oprogramowania, zapewniając lepsze wyniki i bardziej celową pracę.

Przechodząc przez zasady, dostosowałem nieco sformułowania dla każdej zasady, aby lepiej odzwierciedlały aspekty, których dotyczą dla firm i domów programistycznych. Pokażę ci, jak to zrobić.

1. Stój prosto, gdy prowadzisz interesy lub zarządzasz projektem

W świecie tworzenia oprogramowania „wyprostowanie się” oznacza przejęcie odpowiedzialności za swoje projekty i utrzymanie postawy pewności siebie i przywództwa. Wiąże się to z ustalaniem jasnych oczekiwań, przejrzystością wobec klientów i pewnym prowadzeniem ich przez proces rozwoju. Powinno to być rozpatrywane zarówno przez klienta biorącego odpowiedzialność za swój pomysł, jak i przez software house – poprzez dostarczanie nie tylko oprogramowania, ale i WARTOŚCI z pewnością siebie.
Na przykład, kiedy oceniamy projekt, nie rzucamy tylko zakresu szacunków. Poświęcamy czas na wyjaśnienie przesłanek stojących za naszą oceną, upewniając się, że nasi klienci rozumieją zakres i potencjalne wyzwania. Buduje to zaufanie i pozycjonuje nas jako pewnych siebie liderów, na których można polegać.
Na przykład, w ostatnim projekcie Profit Board (https://sailingbyte.com/pl/case-studies/profitboard/), pomogliśmy klientowi w poruszaniu się po złożonych wymaganiach technicznych, stojąc twardo na straży niezbędnych kroków do skalowalnego i bezpiecznego rozwiązania SaaS. W Sailing Byte wierzymy, że silne, jasne przywództwo jest niezbędne do pomyślnej realizacji projektu.

2.  Traktuj siebie z takim samym szacunkiem, jakim darzysz innych

W tworzeniu oprogramowania dobre traktowanie siebie oznacza docenianie własnego czasu, umiejętności i wiedzy. Jako właściciel software house’u i Product Owner, często widzę, jak ważna jest troska o samego siebie, odzwierciedlona w tym, jak radzimy sobie z projektami. Traktując nasz zespół i siebie z szacunkiem, tworzymy środowisko, w którym jakość pracy kwitnie. Jest to często powtarzane przez właścicieli firm, a jednak wciąż niedoceniane: pamiętaj o dbaniu o siebie!
W praktyce oznacza to ustalanie realistycznych terminów, unikanie wypalenia i zapewnienie, że nasz zespół ma zasoby i wsparcie, których potrzebuje. W dłuższej perspektywie jest to najbardziej korzystne nie tylko dla Ciebie, ale także dla Twoich klientów! Na przykład, w ostatnim projekcie CRM (https://sailingbyte.com/pl/case-studies/lourse-international/), zademonstrowaliśmy to poprzez rozłożenie pracy w sposób, który pozwolił na kreatywne rozwiązywanie problemów bez narażania naszego dobrego samopoczucia lub jakości produktu końcowego.

3.  Zaprzyjaźnij się ze swoimi klientami, rozwijając się wraz z nimi

.
W kontekście tworzenia oprogramowania zasada ta dotyczy budowania relacji z klientami, którzy są zgodni z Twoimi wartościami i celami. W Sailing Byte staramy się pracować z klientami, którzy są zaangażowani w tworzenie czegoś znaczącego, a nie tylko szybkich wygranych. Rozumiemy, że najlepsze relacje przetrwają długo i przyniosą korzyści wszystkim stronom – jeśli klient się rozwija, my również możemy się rozwijać i odwrotnie.
Wspieramy te relacje poprzez przejrzystość naszych procesów, takich jak Agile i Scrum, oraz poprzez dostarczanie dodatkowych wskazówek, co można poprawić w ich firmach. Kiedy obie strony są zaangażowane w sukces projektu, wynik jest zawsze lepszy.
Świetnym tego przykładem jest nasza współpraca z klientem KDK (https://sailingbyte.com/pl/case-studies/klinika-dla-kobiet/), który jest równie pasjonatem doświadczeń użytkownika jak my. Nasza współpraca doprowadziła do powstania produktu, który przekroczył zarówno nasze oczekiwania, jak i oczekiwania użytkowników końcowych. A nasza współpraca wciąż kwitnie.

4.  Porównuj swój biznes do tego, kim byłeś wczoraj, a nie do tego, kim ktoś inny jest dzisiaj.

Ta zasada przypomina, aby skupić się na ciągłym doskonaleniu, a nie na porównywaniu. W tworzeniu oprogramowania przekłada się to na iterację procesów, doskonalenie umiejętności i ciągłe poszukiwanie sposobów na ulepszenie oferty produktowej. A w kontekście Agile EBM wzmacnia wiarygodność dowodów i dostosowywanie się do bieżącej sytuacji w porównaniu z sytuacją, która obowiązywała wczoraj.
W Sailing Byte regularnie zastanawiamy się nad naszymi przeszłymi projektami, aby zidentyfikować obszary, w których możemy się poprawić. Niezależnie od tego, czy chodzi o optymalizację naszego wykorzystania Laravel i ReactJS w celu uzyskania lepszej wydajności, czy też o udoskonalenie naszych praktyk Scrum, zawsze szukamy sposobów, aby zrobić coś lepiej niż wczoraj. I pomagamy naszym klientom zrozumieć zarządzanie oparte na dowodach, aby również mogli tego spróbować.
Na przykład projekt TenantTracks (https://sailingbyte.com/pl/case-studies/tenanttracks/), w którym ulepszyliśmy nasz potok CI / CD, jest doskonałym przykładem. Analizując poprzednie wdrożenia, zidentyfikowaliśmy wąskie gardła i wdrożyliśmy zmiany, które zaowocowały szybszymi i bardziej niezawodnymi aktualizacjami.

5.  Nie pozwalaj swoim klientom robić niczego, co sprawia, że ich nie lubisz

Kluczem jest tutaj ustalenie granic i wytycznych, które zapobiegną wymknięciu się projektów spod kontroli. Oznacza to edukowanie klientów w zakresie najlepszych praktyk, pomaganie im w ustalaniu realistycznych oczekiwań i upewnianie się, że projekt pozostaje zgodny z pierwotnymi celami. Wielu z naszych klientów na samym początku nie miało pojęcia, jak prowadzić biznes SaaS, ale ponieważ pokierowaliśmy ich niektórymi aspektami, teraz dobrze prosperują. W Sailing Byte wykorzystujemy warsztaty i szczegółowe sesje planowania, aby zapobiec rozrostowi zakresu i utrzymać projekty na właściwym torze. Ustanawiając jasne wytyczne od samego początku, unikamy frustracji wynikającej z niedopasowanych oczekiwań.
Na przykład w projekcie TenantTracks (https://sailingbyte.com/pl/case-studies/tenanttracks/) pomogliśmy klientowi zrozumieć znaczenie ustalania priorytetów funkcji w oparciu o zachowanie użytkownika, uniknęliśmy niepotrzebnych komplikacji i ulepszyliśmy produkt, który spełniał jego potrzeby bez zbaczania z kursu.

6.  Uporządkuj swój biznes zanim zaczniesz krytykować świat

Zanim zaczniesz doradzać klientom lub wydawać rekomendacje, ważne jest, aby upewnić się, że Twoje wewnętrzne procesy są solidne jak skała. W Sailing Byte bierzemy to sobie do serca, utrzymując silną wewnętrzną strukturę— niezależnie od tego, czy jest to nasze przestrzeganie GitFlow, nasze strategie wdrażania, czy nasze protokoły bezpieczeństwa. Innym przykładem jest posiadanie standardowych procedur tworzenia kopii zapasowych lub wdrożeń CI/CD.
Ustawiając nasz „dom” w idealnym porządku, jesteśmy w stanie zaoferować naszym klientom cenne spostrzeżenia. Oznacza to również, że kiedy pojawiają się wyzwania, jesteśmy dobrze przygotowani, aby sobie z nimi poradzić.
W niedawnym projekcie dla Axim Design (https://sailingbyte.com/pl/case-studies/axim-creative/)  zajęliśmy się kwestią bezpieczeństwa, którą nasze dobrze zorganizowane procesy wewnętrzne pozwoliły nam szybko i skutecznie znaleźć i rozwiązać, zapewniając zaufanie i satysfakcję klienta.

7.  Realizuj działania, które zapewniają wartość

W tworzeniu oprogramowania kuszące jest chodzenie na skróty lub wybieranie szybkich rozwiązań, ale często prowadzi to do większych problemów. W Sailing Byte przedkładamy znaczące, długoterminowe rozwiązania nad krótkoterminową celowość. Oznacza to wybór skalowalnych technologii, takich jak Laravel i ReactJS oraz przestrzeganie najlepszych praktyk w zakresie architektury oprogramowania. Oznacza to również, że czasami jesteśmy wybredni, jeśli chodzi o projekty, które faktycznie chcemy realizować. Chcemy robić rzeczy, które mają znaczenie.
Oznacza to również, że zachęcamy naszych klientów do skupienia się na tym, co przyniesie długoterminową wartość, nawet jeśli wymaga to więcej czasu lub zasobów z góry. Takie podejście doprowadziło do powstania bardziej solidnych, skalowalnych i udanych produktów.
Na przykład w projekcie NFF (https://sailingbyte.com/pl/case-studies/new-food-finance-pl/) zdecydowaliśmy się na bardziej złożoną, ale ostatecznie bardziej skalowalną architekturę bazy danych, a klient zauważył znaczące korzyści w zakresie wydajności i elastyczności produktu w czasie.

8. mów prawdę – lub przynajmniej nie kłam

Ta zasada jest tak uniwersalna, że nie wymaga żadnych poprawek.
Szczerość jest podstawą udanych relacji z klientami i wyników projektów. W Sailing Byte wierzymy w szczerość wobec naszych klientów w kwestii tego, co można, a czego nie można osiągnąć, potencjalnego ryzyka i realiów rozwoju oprogramowania. Jest to również podstawowa zasada prawidłowego rozwoju Agile – tak długo, jak postrzegamy siebie nawzajem z klientem jako profesjonalistów, działa to dobrze.
Ta szczerość rozciąga się na sposób, w jaki komunikujemy się przez cały cykl życia projektu. Jeśli dana funkcja zajmie więcej czasu niż oczekiwano lub jeśli napotkamy nieoczekiwane wyzwanie, natychmiast informujemy o tym klienta i omawiamy, jak iść naprzód. Czasami oznacza to dużo komunikacji przez Slack, e-mail lub na spotkaniach, ale ostatecznie jest to najlepsze podejście, jakie do tej pory znaleźliśmy.
W niedawnym projekcie Animala (https://sailingbyte.com/pl/case-studies/animala/), w którym musieliśmy renegocjować harmonogram z powodu nieprzewidzianych wyzwań technicznych, nasze zaangażowanie w przejrzystość pomogło utrzymać zaufanie klienta i zapewniło kontynuację projektu na mocnych podstawach.

9. Przyjmij, że osoba, której słuchasz, może wiedzieć coś, czego ty nie wiesz

Jako Product Owner ważne jest, aby zdawać sobie sprawę, że klienci wnoszą cenne spostrzeżenia na temat swojej branży i użytkowników. W Sailing Byte uważnie słuchamy naszych klientów, ceniąc ich wiedzę i doświadczenie oraz integrując je z procesem rozwoju.
Zasada ta jest szczególnie istotna podczas naszych warsztatów i sesji planowania, podczas których zachęcamy klientów do dzielenia się swoją wizją i doświadczeniem. Łącząc ich wiedzę z naszymi umiejętnościami technicznymi, tworzymy rozwiązania, które są nie tylko solidne technicznie, ale także dostosowane do potrzeb rynku. Pomaga to również zastanowić się klientom nad ich pomysłem na biznes i skonfrontować ich (czasami po raz pierwszy!) z kimś, kto ma doświadczenie w uruchamianiu SaaS.
W projekcie MyRotat (https://sailingbyte.com/pl/case-studies/myrotat/), gdzie ściśle współpracowaliśmy z klientem, który miał głęboką wiedzę branżową, rezultatem był wysoce ukierunkowany produkt SaaS, który szybko zyskał przyczepność na rynku.

10.  Bądź precyzyjny w swoich wypowiedziach (i e-mailach)

Jasność w komunikacji jest kluczowa w rozwoju oprogramowania. Niezależnie od tego, czy chodzi o definiowanie wymagań projektowych, pisanie historyjek użytkownika, czy omawianie szczegółów technicznych, precyzja zapobiega nieporozumieniom i zapewnia, że wszyscy są po tej samej stronie.
Wolę również komunikację pisemną zamiast mówionej, gdy wymagana jest precyzja – zarówno dlatego, że pozwala zawsze wrócić do wiadomości, jak i dlatego, że pozwala czytelnikowi przeczytać kilka razy te same słowa, aby lepiej je zrozumieć. W Sailing Byte kładziemy nacisk na precyzyjną komunikację na każdym etapie projektu. Obejmuje to nasze szczegółowe oceny, przejrzystą dokumentację i regularne aktualizacje podczas sprintów na Asanie. Będąc precyzyjnymi, minimalizujemy ryzyko błędów i utrzymujemy projekty na właściwym torze.
Weźmy na przykład system z wieloma integracjami, w którym musisz komunikować się z wieloma stronami jednocześnie – tak było w przypadku projektu CargoSeller (https://sailingbyte.com/pl/case-studies/cargoseller/). Wdrożyliśmy złożoną integrację, a nasza precyzyjna komunikacja z klientem, dostawcami API i wewnątrz naszego zespołu była kluczem do uniknięcia kosztownych błędów i zapewnienia płynnego rozwoju i wdrożenia.

11. Nie przeszkadzaj klientom, gdy eksperymentują

Klienci i użytkownicy końcowi, podobnie jak dzieci uczące się jeździć na deskorolce, potrzebują swobody odkrywania, eksperymentowania, a nawet popełniania błędów. W Sailing Byte zdajemy sobie sprawę z tego, jak ważne jest zapewnienie klientom przestrzeni do wprowadzania innowacji i próbowania nowych rzeczy, nawet jeśli oznacza to podjęcie pewnego ryzyka. Jest to również część EBM – spróbuj eksperymentować i zobacz, co się stanie!
W pełni wspieramy to, tworząc elastyczne, skalowalne rozwiązania, które pozwalają na eksperymentowanie. Niezależnie od tego, czy jest to nowa funkcja, czy inne podejście do marketingu, zachęcamy naszych klientów do podejmowania skalkulowanego ryzyka, wiedząc, że jesteśmy tutaj, aby ich wspierać.
W projekcie WISSP (https://sailingbyte.com/pl/case-studies/wissp/) pracowaliśmy ze startupem wypróbowującym nowatorski model biznesowy, zapewniliśmy podstawy techniczne, które pozwoliły im na szybkie zmiany i iterację bez utraty tempa.

12. Cofnij się o krok i pogłaszcz kota

W szybko zmieniającym się świecie tworzenia oprogramowania ważne jest, aby doceniać małe, często pomijane momenty sukcesu i radości. W Sailing Byte staramy się świętować kamienie milowe, niezależnie od tego, czy jest to ukończenie sprintu, udane uruchomienie, czy pozytywne opinie klientów.
Poświęcenie czasu na „pogłaskanie kota” przypomina nam, dlaczego robimy to, co robimy i pomaga utrzymać morale zespołu. To właśnie te małe chwile uznania utrzymują naszą motywację i łączą nas z szerszą perspektywą.
Jeśli osiągniesz kamień milowy, poświęć czas na świętowanie z zespołem i klientem, wzmacniając nasze zaangażowanie zarówno w jakość, jak i radość z naszej pracy. Bądź dumny i zadowolony ze swojej pracy!

Czy 12 zasad życia może być 12 zasadami tworzenia oprogramowania?
Najciekawszą rzeczą w tej analizie było to, że zastosowałem już te zasady zarówno w procesach biznesowych, jak i programistycznych, co doprowadziło mnie do wniosku, że 12 zasad życia jest całkiem kompatybilnych ze zwinnym tworzeniem oprogramowania. Oczywiście – w 12 zasadach jest więcej rzeczy, których nie ma w Agile i vice versa (jak na przykład wyraźnie określony Cel Produktu). Ale moim zdaniem jest to dość niesamowite, że można nieco nałożyć na siebie te dwie idee i dodać znacznie więcej wartości zarówno do życia osobistego, jak i rozwoju biznesu.

Autor

Łukasz Pawłowski

CEO of Sailing Byte

Prowadzę Sailing Byte – Software House, który koncentruje się na technologiach Laravel i React, ale nie ogranicza się tylko do nich; realizowaliśmy również projekty z wykorzystaniem C#, Unity, Fluttera, SwiftUI i innych technologii. Moja rola polega na organizowaniu i dostarczaniu oprogramowania w metodyce Agile – poprzez zapewnianie doświadczenia, wiedzy i odpowiedniego zestawu narzędzi do współpracy z naszymi klientami. Podczas tej podróży poznałem wielu wspaniałych ludzi, którzy również przyczynili się do rozwoju Sailing Byte jako polskiego Software House’u, dostarczającego wysokiej jakości rozwiązania programistyczne w Europie, Wielkiej Brytanii i Stanach Zjednoczonych.

Powiązane studium przypadku