Oczekiwania programisty, a wymagania biznesu

W zespole gdzie pracuję od jakiegoś czasu organizujemy spotkania osób „na najwyższym szczeblu”. Chodzi o 3-4 osoby odpowiedzialne za ogarnianie pracy i projektów. I na ostatnim takim spotkaniu pojawił się temat, o którym jest ten wpis. Mianowicie zauważyliśmy duże zderzenie oczekiwań programistów, których mamy w zespole, z wymaganiami i oczekiwaniami klienta, czyli biznesu.

Marek Zając. Od sierpnia 2016r. związany z Software Mind (częścią grupy Ailleron), gdzie aktualnie jest full stack developerem i od niedawna team leaderem, który realizuje projekty dla klientów z Wielkiej Brytanii. Technologie w jakich się porusza to C#, JavaScript, TypeScript, .NET Core, ASP.NET MVC, Angular 2+, Docker. W pracy lubi bezpośredni kontakt z klientem i wpływ na podejmowane w projekcie decyzje.

Programista wymaga

Pracując nad projektem mamy pewne oczekiwania wobec zadań. Pierwszym z nich jest ocena tego, czy zadania są „fajne”. Kiedy te kryteria nie są spełnione to zaczyna się narzekanie. I grożenie zmianą firmy. Potrafimy bardzo głośno wyrażać swoje niezadowolenie. W końcu każdy chce żeby jego praca była satysfakcjonująca. A że pozycja programisty na rynku jest całkiem mocna, to pozwalamy sobie na większe dyskusje i otwarte narzekania.

Zastanawiając się nad tym co myślę, słuchając kolegów i koleżanek w pracy, ale też przeglądając internet, mogę zauważyć kilka powtarzających się kryteriów oceny czy praca jest „fajna”. Przyjrzyjmy się im.

„Cool” technologie

Oj, ile to razy się narzekało, że trzeba pracować w „starociach”! Jak coś miało swoją datę premiery kilka lat temu, to w zasadzie mogłoby już wymrzeć jak dinozaury.

Prawda jest taka, że w zespołach programistów, przynajmniej w Polsce, dominują młode osoby. A skoro młode to i dynamiczne, ale także i dynamicznie zmieniające standardy w jakich się poruszają. Sam też mam ochotę zastosować feature, który niedawno widziałem na prezentacji. W końcu chodzi o to, żeby upraszczać swoją pracę, albo sprawniej zaimplementować rozwiązania, nad którymi pracujemy.

Jakość ponad wszystko

Brak czasu na testy? Skandal! Konieczność robienia hacków w kodzie? Masakra. Zmieniające się wymagania sprawiają, że dotychczasowe rozwiązanie przestaje się sprawdzać? No muszą się zgodzić na ten refaktoring, bo to upadnie przecież!

Jakość jest dobra. Kropka.

Jednak jako programiści mamy czasami na jej punkcie fioła. Skupiamy się tak bardzo na maksymalizowaniu jakości, dopieszczaniu każdej linijki, że zapominamy o tym, że był jakiś zaplanowany termin oddania zadania. Przecież nie zostawimy tak tego, bo jeszcze ktoś zobaczy i uzna, że jesteśmy niekompetentni! Poza tym słaba jakość to pewna klęska.

Aplikacja w centrum uwagi

Pracując nad aplikacją chcemy widzieć, że jest to coś ważnego. Że wszystkie osoby zaangażowane w projekt poświęcą mu maksimum swojej uwagi. W końcu jest to APLIKACJA! Nie można bagatelizować takiej rzeczy. Chcemy czuć, że bez tego projektu biznes będzie podupadał. Chcemy mieć poczucie, że robimy coś od czego zależą losy firmy. Najlepiej żeby był to jej główny produkt. Dzięki temu wiemy, że nasza praca jest naprawdę potrzebna i bez nas nikt by sobie nie poradził.

A skoro to nasza aplikacja ma być tą najważniejszą, to nie chcemy ciągle tylko integrować jakichś usług. Staramy się przekonywać, że jak najwięcej logiki ma być u nas. Tylko w ten sposób będziemy mieć nad tym kontrolę! Takie korzystanie z zewnętrznych zasobów to tylko najpewniej proszenie się o kłopoty.

Zadania-wyzwania

Tylko rozwiązując wymagające zadania i zmagając się z programistycznymi wyzwaniami, czujemy, że w pełni pracujemy. Jako programiści sporo z nas ma dużą potrzebę realizacji zadań wymagających sprytnych rozwiązań. Najlepiej, kiedy te zadania wymagają od nas specjalistycznej wiedzy czy wręcz zespołowych dyskusji i analiz. Wtedy można powiedzieć, że praca jest faktycznie ciekawa.

Biznes oczekuje

Po drugiej stronie barykady mamy ten mityczny biznes. Jako, że sporo firm IT to outsourcing, to tym biznesem jest po prostu klient zamawiający projekt. I to zazwyczaj w jego kierunku kierowane są nieprzychylne uwagi programistów w biurze. Niekiedy słuszne, ale my nie o tym dzisiaj. Bo wśród tych uwag co do decyzji lub wymagań klientów również da się wyłapać kilka powtarzających się. A kiedy tak się zastanowić skąd one wynikają to można zobaczyć, że łączą się one z powszechnymi praktykami prowadzenia biznesu.

Więc czego ten biznes oczekuje?

Dostarczanie na czas

Nic tak nie utrudnia planowania pracy jak opóźnienia w realizacji zadań. Przeciągające się realizacje projektów powodują, że albo praca osób czekających na ten projekt jest nieefektywna, albo wymaga szukania innych możliwości jej wykonywania.

Co więcej, nieraz to przepisy czy umowy wymagają dostarczenia w terminie. W końcu mając system księgowy nie możemy wdrożyć obsługi najnowszych przepisów dotyczących np. podatków, bo do tego momentu nasz system będzie albo generował niezgodne z prawem dane, albo będzie musiał być po prostu nieużywany. Podobnie sprawa ma się z umowami. Konieczność wyłączenia jakiejś usługi i dostosowania systemu do jej nowego odpowiednika wynika wprost z umów podpisanych z dostawcami.

Spójność

Standardy w firmie mają proste cele – ułatwić wdrażanie nowych osób, przenoszenie ich pomiędzy zespołami i zminimalizować koszty obsługi wszystkich elementów. Im więcej rzeczy działa w podobny lub wręcz ten sam sposób, tym prostsza ich konfiguracja, obsługa czy kontrola. Dlatego też w prowadzeniu biznesu dużą rolę odgrywa spójność. Zarówno ze standardami, jak i pod względem wykorzystywanych narzędzi. Dzięki temu minimalizuje się ryzyko powstania chaosu, bądź zbyt dużego wzrostu kosztów utrzymania całości.

Przydatność

W jakim przypadku projekt jest całkowicie nieudany? Kiedy jest słabej jakości? Kiedy nie spełnia najnowszych standardów? A może kiedy jest banalny? Nic z tych rzeczy! Projekt jest tak naprawdę nieudany w momencie, kiedy nikomu nie jest przydatny.

W końcu kiepską jakość można powoli poprawiać, standardy wprowadzać stopniowo, a samą aplikację coraz bardziej rozbudowywać. Tylko po co nam to wszystko, jeżeli czas i pieniądze poświęcone na realizację kończą w czymś co ląduje w koszu, bo nikt nie ma zamiaru tego używać, w żaden sposób nie jest to nikomu przydatne.

Tak więc przydatność, a więc potencjalnie możliwość zarabiania na projekcie albo oszczędzania dzięki niemu to cecha, która musi być obecna zawsze.

Projekt przeszkadza programistom

Wniosek z tego wszystkiego można wysnuć taki, że programistom w firmach przeszkadzają projekty, które robią. Zawsze ten zły klient każe robić zadania, których nie chcemy. Do tego nawet nie możemy użyć narzędzi, których chcemy, bo też ktoś nas ogranicza. Poza tym tych spotkań ustalających wymagania to chyba z milion. Jeszcze ciągle pytają czy na pewno zdążymy.

Jak porównamy sobie to czego oczekują programiści z tym czego potrzebuje biznes to wręcz możemy dojść do wniosku, że wymagania i oczekiwania biznesu przeszkadzają programistom w przyjemnej pracy.

Jednak nie chciałbym żeby było to tak odebrane. Bo tutaj raczej o co innego chodzi. Po prostu zbyt często zapominamy, że ostatecznie dostarczamy projekty, które będą używane w innych projektach, produktach, zdaniach. Już nie związanych z kodem. Warto więc przynajmniej próbować zrozumieć drugą stronę. Odkąd prowadzę własną firmę robiąc swoje produkty dużo łatwiej jest mi zrozumieć, co stoi za pewnymi decyzjami.

Zastanówmy się więc nad kilkoma pytaniami, które przydadzą się przy budowaniu współpracy.

Po co to robimy?

Jak wspomniałem w akapicie o aplikacji, w centrum uwagi mamy tendencję do oczekiwania, że to nasza aplikacja jest tą jedyną najważniejszą. Deprecjonujemy znaczenie wszystkich innych usług i systemów. Oburzamy się kiedy musimy robić jakieś banały. Prosta strona, która wyświetli dane z kilku serwisów? To nas wręcz obraża!

Ale czy zadaliśmy kiedyś pytanie po co ta aplikacja powstaje? Jaką wartość da? Być może ta jedna strona, która tylko agreguje dane z innych źródeł pozwoli znacznie uprościć proces w firmie? Albo da szansę w jakimś dziale prowadzić skuteczniejszą analizę, a przez to szukać nowych możliwości biznesowych?

Z drugiej strony może się okazać, że nie jesteśmy w centrum uwagi, ale to co robimy jest brakującym trybem w dużej maszynie. Nieraz jest tak, że klient ma już system, który w jakiś sposób przetwarza dane i wykorzystują go wszystkie pozostałe systemy firmowe. Teraz tylko potrzebuje mieć inny sposób na dostęp do tych danych. Dlaczego więc miałby duplikować logikę, która już istnieje, skoro wystarczy odwołać się do istniejących struktur?

Inna sytuacja – klient nalega na dotrzymanie terminu. My jednak ciągle coś poprawiamy, usprawniamy, zmieniamy. Ale czy wiemy skąd ten pośpiech? Co jeżeli powód powstawania tej aplikacji, to chęć wejścia na nowy rynek, jakaś szansa biznesowa, która wymaga „wstrzelenia się” w termin? Albo tak jak już pisałem przy oczekiwaniach biznesu, co do dostarczania na czas – konieczność spełnienia wymogów prawnych?

Skupiając się tylko na tym jak coś robimy, a zapominając po co to robimy jest szansa, że zaczynamy ciągnąć projekt nie w tą stronę, która prowadzi do jego sukcesu. Jakkolwiek byłby zdefiniowany przez biznes.

Może mają rację?

To, że wiemy najlepiej jak powinien być rozwijany projekt to oczywista oczywistość. Ale spróbowaliśmy dowiedzieć się, dlaczego klient proponuje jakieś rozwiązanie? Być może stoi za tym inna logika niż ta, którą przyjęliśmy. Co jeżeli cała infrastruktura i ludzie są przygotowani na korzystanie z technologii X i Y, a my forsując technologię Z, która być może jest nowsza, lepsza, szybsza spowodowalibyśmy, że trzeba by dodać potężny wyjątek w całej strukturze, przeszkolić ludzi, zmienić oprogramowanie itp.?

Jeżeli klient wszystko ma oparte o bazę MSSQL Server, a my przekonujemy go do użycia w naszym projekcie bazy Oracle (no dobra, nikt by tego z tą bazą nie robił) to jak wiele dodatkowe pracy i zasobów będzie go kosztowała taka zmiana? Czy potrafimy powiedzieć jakie faktycznie korzyści będą z tego? Poza tymi typu „bo nam będzie łatwiej”?

Podobnie sprawa ma się z różnymi wymaganiami w systemie. To, że na logikę jakiś proces wydaje nam się bez sensu to nie znaczy, że taki jest. Skądś się wziął. I do czegoś prowadzi. Być może zepsuje nam to koncepcję architektury, ale sprawi, że przydatność aplikacji mocno wzrośnie? Jak w takim razie powiedzieć, że aplikacja nie może być zbyt przydatna, bo nasza koncepcja musiałaby być przepisana albo utracić na jakości kodu?

Czy informujemy?

Widzimy, że rozwiązanie, które wymyślił klient jest kiepskie. Zaczynamy więc narzekać na to, jak głupi ludzie pracują po tej drugiej stronie. Ale czy w takim wypadku pomyśleliśmy, że po prostu wiemy o czymś o czym druga strona nie ma pojęcia? Nikt nie ma całej wiedzy więc też nie zawsze widzi inne możliwości rozwiązania problemu. Dlatego jeżeli zauważamy, że coś może być potencjalną przyczyną problemu w przyszłości albo wiemy, że da się do tematu inaczej podejść to czy mówimy o tym? Czy może po prostu narzekamy, że klient jest głupi i denerwujemy się implementują jego pomysły, a potem poprawiając błędy, które po czasie wyszły przez błędne decyzje?

Podsumowanie

Nie uważam, ze biznes zawsze ma rację. Nie twierdzę, że wszystkie jego decyzje, pomysły czy wymagania są słuszne. Jednak jeżeli chcemy na coś narzekać to po prostu upewnijmy się, że nasze skargi to nie tylko nasze zachcianki, fanaberie i chęć zebrania wpisów do CV. Bo samym narzekaniem nie zmienimy za wiele.

Starając się zrozumieć pewne decyzje i akceptując KOMPROMIS i godząc się (po odpowiedniej argumentacji) np. na zaciągnięcie DŁUGU TECHNICZNEGO, o którym jasno powiemy jakie są jego wady i zalety, postarajmy się dowiedzieć wszystkiego przed podjęciem decyzji. Bo następny klient wcale nie będzie lepszy. W końcu biznes wszędzie działa tak samo.

A jeżeli pracując w technologii .NET brakuje Ci jednak nauki nowych rozwiązań albo chcesz móc proponować klientowi jeszcze większy wachlarz możliwości na implementację systemu i infrastruktury to zapraszam Cię do mojego kursu kręcącego się wokół frameworka ASP.NET Core. Więcej informacji znajdziesz na stronie kurs-szarpania.pl. Jeśli interesuje Was czym różni się umowa B2B od standardowego UoP, to przeczytajcie nasz artykuł.

Artykuł został pierwotnie opublikowany na zajacmarek.com. Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z