Nasz projekt NIE JEST WYJĄTKOWY
Zaczynając pracować jako programista często myślałem, że projekt, który robimy w pracy jest wyjątkowy, świeży, jest czymś do czego trzeba podejść w pełni indywidualnie. Bo nikt wcześniej czegoś TAKIEGO nie robił. Takiemu myśleniu sprzyja też narracja prowadzona przez „biznes”. Nieraz można usłyszeć od osób zgłaszających wymagania i mówiących o planie na projekt, że jest to coś ważnego i nietypowego. W powietrzu non stop wisi taka atmosfera robienia czegoś czego jeszcze nie było. I jeżeli ktoś się zagapi to faktycznie zacznie w to wierzyć do samego końca.
A zapominamy, że kiedy biznes mówi o „jedynym w swoim rodzaju projekcie” to ma na myśli coś innego niż my. Ma w głowie projekt jako produkt, który rozwiązuje konkretne problemy lub zaspokaja konkretne potrzeby. My zaś słysząc coś takiego myślimy o nowym wyzwaniu projektowym i nowych technologiach jakie będą musiały być użyte.
Wszystko takie samo
Prawa, do której dochodzimy po latach pracy jest bardziej brutalna. Bo w rzeczywistości projektów, które faktycznie są czymś nowym i wymagającym nietypowych rozwiązań jest naprawdę mało. Jeżeli pracuje się w korporacji przy korporacyjnym oprogramowaniu albo robi jakiś system typu ERP, CRM itd. to choćby zamawiający bardzo mocno się starał to nie dajmy się zwieść, że jest to coś niesamowitego. Bo wszystkie te projekty są jakąś wariacją już istniejących systemów.
Kiedy zaczniemy się zagłębiać w tematykę architektury aplikacji, a potem analizować to co robimy w pracy to bardzo dobrze widać, że nie ma w tym nic innowacyjnego. Nagle dochodzimy do wniosku, że ten projekt to kolejne zapisywanie danych z formularza do bazy. Albo następne narzędzie będące „Excelem w przeglądarce” lub coś co pozwala dodać dane i zaakceptować je przez kogoś innego. Jedyne co się zmienia to dziedzina dla jakiej to robimy i zestaw pól, które obsługujemy.
Dobra nasza
Ale żeby nie brzmieć tak pesymistycznie to mam też dobrą wiadomość związaną z takim stanem rzeczy. Skoro te systemy są podobne to i rozwiązania, które w nich siedzą prawdopodobnie były i są podobne. Więc na pewno ktoś je już sklasyfikował, opisał i przeanalizował. Chociażby podjął ten temat Uncle Bob, w jednej ze swoich książek albo Martin Kleppmann. Dlatego pracując przy typowym rozwiązaniu biznesowym możemy spokojnie zagłębiać się w tematy standardowych architektur i frameworków i na 100% znajdziemy rozwiązanie pasujące do naszego przypadku. Nie ma potrzeby wymyślania koła na nowo.
Czy będzie to najprostsza architektura warstwowa czy też jakieś rozwiązanie heksagonalne albo mikroserwisy. To wszystko jest już dobrze opisane i znajdziemy masę osób, które mają w tym doświadczenie. Więc nie jesteśmy sami i w razie wątpliwości lub problemów znalezienie rozwiązania nie jest trudne. Ważne tylko żeby być świadomym co robimy. Bo jeżeli wiemy jakiej architektury czy wzorca używamy to szukanie w Google jest proste. A jeżeli robimy coś czego nie rozumiemy to będziemy mieli ciągle wrażenie, że robimy coś o czym nikt nigdy nie mówił.
Skupienie na potrzebach
Wiedząc, że większość tych aplikacji jest bardzo podobna do siebie możemy skupić się na konkretnych czynnikach. Chociażby na dobraniu rozwiązania pod względem obciążenia, niezawodności albo podatności na zmiany. Nie musimy ulegać przesadnie podniosłej narracji bo mamy w ręku zestaw narzędzi, który pozwala nam chłodno ocenić sytuację. Czy aplikacja będzie miała duży ruch? A może jakiś jej element jest bardzo niepewny i jest duża szansa, że będzie wymieniony? A może istnieje już narzędzie, które robi to co potrzeba i wystarczy, że się z nim zintegrujemy?
Mając odpowiedzi na te pytania i wiedząc, że projekt od strony inżynierii zawrze się na pewno w jednym z kilku używanych rozwiązań możemy dobrać dla klienta rozwiązanie najlepiej pasujące do potrzeb. Dodatkowo wystarczy, że skupimy się na odkrywaniu jaki problem rozwiązuje dana aplikacja, bo to w jaki sposób to robi już po części wiemy. Pamiętając, że robimy „kolejny podobny produkt” unikamy podejścia „Hype Driven Development” i działamy rozważniej i w taki sposób, żeby potem przy utrzymaniu lub modyfikacji projektu mówić „super, byliśmy na to gotowi”.
Bo pamiętajmy, że dla klienta albo użytkownika innowacyjność projektu może wynikać z faktu dodania jednego przycisku do już istniejącego rozwiązania. Naszym zadaniem jest bycie gotowym na ten przycisk.
Leave a Comment