Dzień Programisty: kto naprawdę pisze Twój system

Na spotkaniu ofertowym prawie nikt nie pyta wprost, kto napisze kod - a to pytanie zmienia więcej niż lista funkcji. Zwykle odpowiada handlowiec albo project manager, a osoba, która faktycznie usiądzie do klawiatury, poznaje Twoje wymagania dopiero z zapisanego zgłoszenia. Przy każdym takim przejściu ginie „wyjątek” i „to, które poszło źle” - a to one najlepiej tłumaczą Twój proces, nie lista funkcji.

13 września, w 256. dzień roku - liczba symboliczna dla programistów, bo tyle wartości mieści jeden bajt - obchodzony jest Dzień Programisty. Dobra okazja, żeby zadać to pytanie na głos, zanim cokolwiek podpiszesz.

Dlaczego to pytanie w ogóle ma znaczenie

Nie chodzi o oszczędność, choć o niej też pisaliśmy przy okazji wyceny. Chodzi o to, ile razy Twoje wymaganie zmienia właściciela, zanim trafi do kodu.

Każde przejście - od Ciebie do handlowca, od handlowca do analityka, od analityka do programisty - jest tłumaczeniem. Tłumaczenie gubi dokładnie to, co w opisie własnej pracy wydaje się oczywiste i dlatego nigdy nie trafia na papier: pole, o którym nikt nie myśli przy wycenie. U elektryków z FUR Dorian było to pole „klient jeszcze nie w kartotece” - drobne z pozoru, a bez niego formularz stawałby się powodem, żeby nie wypełnić karty wcale. Im więcej osób między Tobą a klawiaturą, tym więcej okazji, żeby taki szczegół zniknął po drodze - i tym więcej rund poprawek, zanim ktoś w ogóle zauważy, że go zabrakło.

Trzy pytania, które to sprawdzą

Zadaj je na pierwszym spotkaniu, obojętnie z jakim dostawcą rozmawiasz.

1. Kto będzie na spotkaniu, na którym ustalamy zakres? Jeśli nie ma tam nikogo, kto później usiądzie do kodu, każdy Twój wyjątek przejdzie przez dodatkowe tłumaczenie, zanim dotrze do klawiatury - a Ty nie dowiesz się, które z nich.
2. Czy na pytanie „dlaczego akurat tak to zrobiliście” dostajesz odpowiedź od razu, czy „sprawdzę i wrócę”? „Sprawdzę i wrócę” samo w sobie nie jest złym znakiem - czasem naprawdę trzeba zajrzeć do kodu. Złym znakiem jest to zdanie powtórzone przy każdym pytaniu technicznym z rzędu: wtedy rozmawiasz z kimś, kto przekazuje wiadomości, a nie z kimś, kto podejmuje decyzje.
3. Ile osób w ogóle dotknie mojego projektu? Nie chodzi o to, żeby było ich mało za wszelką cenę, tylko żeby dało się je policzyć na palcach jednej ręki i nazwać z imienia. Jeśli odpowiedzią jest wzruszenie ramion, nikt po drugiej stronie tego nie liczy.

Jak to wygląda u nas

Dwie osoby, bez podwykonawców - i to ten sam zespół projektuje system na pierwszym spotkaniu, co dowozi go na koniec. Kiedy klient pyta, dlaczego dany ekran działa akurat tak, a nie inaczej, odpowiada osoba, która to zaprojektowała i która to zaimplementuje - na tym samym spotkaniu, nie w mailu tydzień później.

To nie jest wyłącznie kwestia wygody. Przy systemie dla grawerni laserowej kluczowa decyzja - że stanu magazynowego nie da się wpisać ręcznie, tylko wynika z ruchów - wyszła z tego samego prześledzenia drogi zlecenia od zapytania do zapłaty, które ujawniło też, że zlecenia mają trzy różne typy, a nie z dokumentu wymagań spisanego po fakcie. Gdyby to prześledzenie szło przez pośrednika, zamiast wprost z osobą, która na co dzień zna proces, część takich ustaleń łatwo ginęłaby po drodze.

Wykonawca nie potrzebuje słuchać o Twoim problemie z drugiej ręki. Potrzebuje usłyszeć go raz, od Ciebie.

Kiedy to akurat nie ma znaczenia

Uczciwie: przy dużym wdrożeniu - kilkanaście osobomiesięcy, kilka zespołów, integracje na wielu frontach naraz - struktura z project managerem, analitykiem i osobnym zespołem QA jest potrzebna, bo jedna czy dwie osoby fizycznie by nie ogarnęły całości. Sami mówimy to wprost: przy projekcie na kilka tysięcy godzin nasza struktura by nie wystarczyła.

Pytanie o to, kto pisze kod, ma sens przy każdym budżecie - zmienia się tylko to, jakiej odpowiedzi warto się spodziewać. Przy jednym procesie zamkniętym w kilka tygodni dobra odpowiedź brzmi „ja i jeszcze jedna osoba, obie na tym spotkaniu”. Przy dużym systemie dla całej organizacji dobra odpowiedź to nazwany zespół z jasnym podziałem ról - a zła to wzruszenie ramion, niezależnie od wielkości projektu.

Najczęstsze pytania

Czy mogę porozmawiać z programistą przed podpisaniem umowy?

U nas to nie jest wyjątek na życzenie. Mapę Systemu, na której ustalamy zakres, prowadzi osoba, która potem ten zakres wycenia i pisze kod.

Czy dwuosobowy zespół to nie ryzyko - choroba, urlop, wypalenie?

Jest to ryzyko inne niż w dużym zespole, nie mniejsze ani większe z automatu. W dużej strukturze projekt przeżyje nieobecność jednej osoby, ale zwykle traci tempo na czasie wdrożenia zastępstwa w kontekst. U nas obie osoby znają cały projekt od pierwszego spotkania, więc nieobecność jednej nie zatrzymuje pracy - zatrzymuje tylko tempo na czas jej trwania. Przy projekcie na kilka tysięcy godzin ta różnica przestaje działać na naszą korzyść, o czym piszemy wyżej.

Skąd mam wiedzieć, że to, co słyszę na spotkaniu, jest prawdą, a nie tylko dobrą odpowiedzią sprzedażową?

Poproś o rozmowę z ostatnim klientem albo o pokazanie fragmentu kodu z realnego projektu, nie ze slajdu. Dostawca, który faktycznie robi to, co mówi, nie ma powodu, żeby tego unikać.

Umów bezpłatną Mapę Systemu - jeśli chcesz sprawdzić, jak wygląda ta rozmowa u nas, zanim cokolwiek zamówisz.