Czy istnieją jedynie mity klienta i mity analityka? A co z programistami? Czy wśród nich również można spotkać się z mitami? Zapraszam do zestawienia 3 kluczowych mitów, z jakimi można się spotkać w pracy z programistami.

Mit 1- Skoro Woźniakowi i Jobs’owi udało się stworzyć i napisać system na pierwszego Apple’a w garażu to mi też się uda napisać dowolny program.

Owszem analogicznie jak to było w przypadku pierwszego DOS’a czy Windowsa ktoś musiał go napisać mając jedynie do dyspozycji swoją wiedzę. Fascynujące historie z początków Doliny Krzemowej potrafią inspirować, ale niestety mogą również prowadzić do błędnych założeń. Tak, Steve Wozniak napisał pierwsze oprogramowanie Apple na własnym sprzęcie, ale… były to zupełnie inne czasy.

W dobie wielu technologii, gdzie aplikacje rozwijają się w zastraszającym tempie a wiedza jest rozproszona i powstają nowe metodyki pisania wewnątrz firm nie możemy ograniczać się jedynie do swojej wiedzy. Ba! choćby nie powinniśmy tego robić. Istnieje bowiem duże ryzyko, iż mamy za małą wiedzę, aby ogarnąć wszystko. Owszem Apple’a pisało dwóch programistów, ale musimy pamiętać, iż nie wszystkie aplikacje tak powstają. Zatem potrzebne jest wsparcie nie tylko od strony Klienta, który poprzez przedstawienie swoich wymagań może nieświadomie nakierować nas na rozwiązanie technologiczne, ale również Analityka, który zaznaczy nam ograniczenia, które musimy wziąć pod uwagę w procesie tworzenia oprogramowania.

Mit 2 Przeczytam dokumentację, ale i tak zrobię swoje..

Brzmi znajomo? Niestety, to częsta bolączka firm, w których rola analityka jest niedoceniana lub zepchnięta na margines. A jednak dobrze napisana dokumentacja (czy to specyfikacja wymagań, czy user stories) to nie sugestia – to fundament.

Kiedy ten mit się pojawia?

Gdy programista traktuje dokumentację jako „papierologię” zamiast realnej pomocy w zrozumieniu kontekstu.

Gdy analityk dostarcza niepełne, nieprecyzyjne wymagania.

Gdy brakuje dobrej komunikacji między zespołami – bo dokumentacja to tylko narzędzie, a nie substytut rozmowy.

Rozwiązanie? kooperacja zamiast rywalizacji. Dokumentacja dostarcza kontekst i warto ją omówić i rozwiać wątpliwości oraz wypracować zasady współpracy, które wspierają rozwój standardów w organizacji.

Mit 3 Efekt słojów, czyli jak nie stworzyć chimery.

Wiele firm rozwija swoje systemy latami – dokładane są kolejne funkcje, moduły i usprawnienia. I tu pojawia się problem: bez strategicznego podejścia architektura zaczyna przypominać słoje drzewa – każda warstwa powstaje na szybko, bez spójnego planu.

Główna przyczyna?

Brak przemyślanej architektury i elastyczności w projektowaniu.

Niedostateczna analiza przyszłych potrzeb biznesowych (np. klient dziś chce raporty w PDF, ale za dwa lata może chcieć je w nowszej technologii, aby nie odstawać od konkurencji).

„Łatanie” systemu zamiast jego optymalizacji.

Co można zrobić?

Już na etapie zbierania wymagań warto pytać: jakie zmiany są planowane w przyszłości?

Architekci powinni projektować rozwiązania z myślą o rozwoju, a nie tylko o tym, co działa dziś. Dokumentacja powinna uwzględniać nie tylko obecne potrzeby, ale i możliwe ścieżki rozwoju systemu.

A wy z jakimi mitami się spotkaliście?