Autor

Monika Perendyk

Trener, wykładowca, praktyk

Mity Programisty

7 kwietnia 2014 • 10 minut czytania

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ę. W obecnych czasach 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! Nawet nie powinniśmy tego robić. Istnieje bowiem duże ryzyko, że mamy za małą wiedzę, aby ogarnąć wszystko. Owszem Apple’a pisało dwóch programistów, ale musimy pamiętać, że 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..

Niestety to jest bolączka wielu programistów w firmach, w których stanowisko Analityka jest niedoceniane, albo jest marganizowane w całym cyklu powstawania oprogramowania. Bądź też doświadczenie analityka jest tak niewielkie, że tworzone są dokumenty niepełne, które nie spełniają norm analitycznych. Wówczas należy zastanowić się nad zmianą analityka, albo podnoszeniem jego kwalifikacji. Jednak w normalnej sytuacji (kiedy Analityk wie co pisze i co robi :) ) programista powinien opierać się na założeniach i ograniczeniach wynikających z powstałej dokumentacji. Jest wykonawcą tego co zostało spisane w dokumencie, zatem nie ma tutaj miejsca a przynajmniej nie powinno być miejsca na swoistą samowolkę. :)

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

Efekt ten jest bardzo często spotykany głównie w przypadku, kiedy w Firmach tworzone jest oprogramowanie, które jest ciągle rozwijane. Zazwyczaj są to firmy, które nie tworzą oprogramowania tzw. “szytego na miarę”, które oddawane jest w postaci “pudełka” do Klienta. Raczej są to firmy większe, które tworzą jedno wiodące oprogramowanie, które jest w miarę pojawiania się nowych potrzeb Klienta rozwijane. Efekt Słojów to mit, który bardziej dotyczy architektów niż programistów. W przypadku, kiedy po zebraniu wymagań i analizie i przekazaniu dokumentacji do architekta następuje projektowanie architektury rozwiązania. Bardzo często, głównie z winy analityka, który nie dopytał się Klienta czy chce w przyszłości rozwijać aplikację pod kierunkiem np. nowych formatów (bo w tej chwili deklaruje np. że chce raporty jedynie w formacie .pdf) itp. Wówczas architekt powinien przewidzieć i zostawić taką “wtyczkę”, która umożliwi dobudowanie nowych funkcjonalności bez zabudowywania już istniejącej architektury. W przeciwnym wypadku architektura naszej aplikacji będzie wyglądała jak słoje, dzięki którym aplikacja będzie bardziej przypominała nam chimerę, której stabilność jest daleka od ideału.

A wy z jakimi mitami się spotkaliście?

Udostępnij




Aby pogłębić wiedzę po artykule zalecam szkolenie:

Dobre praktyki analizy biznesowej

Zobacz