Jak przekonać klienta do swojej racji

Czytasz wiadomość na slacku z kawą w ręku. Klient wymyślił nowe rzeczy do zrobienia. Na już. "Po prostu świetnie."

Dług techniczny urósł do krytycznego momentu. Praca zwalnia a programiści boją się dokonywać zmian w istniejących miejscach. Ciągle dopisują nowy kod, zamiast poprawić stary. Nie ma testów, brakuje doświadczenia w refactoringu aplikacji. A co jest najgorsze? Nie ma czasu. Klient ma nowe zadania.

Kawa na ławę

Odstawiasz kubek i myślisz. Nie ma co ukrywać - jesteś w dupie. Nowe rzeczy są ważniejsze. To zauważy klient i użytkownicy. Nikogo poza tobą nie interesuje co się dzieje wewnątrz.

Możesz to wszystko tak zostawić albo wziąć sprawy w swoje ręce.

Ważna informacja:

Klient nie chce słuchać o tym co jest źle! W końcu płacił za to, żeby było dobrze. Nie opowiadaj jak okropni byli poprzedni programiści. Pokaż mu drogę jak będzie jeszcze lepiej.

Przejmujemy kontrolę

Przygotujmy plan naprawczy. Nie dla klienta tylko dla siebie. Na początek techniczne retro. Opowiadałem już, więc warto poczytać i wprowadzić: https://patys.pl/techniczne-retro-w-twoim-projekcie

Cel? Przekonać klienta, że są potrzebne zamiany. Tylko jak?

Skoro wiemy co się źle dzieje, możemy pokazać na czym nam zależy. Mamy wypunktowane konkretne miejsca.

Działamy

Przygotuj 5 rzeczy, które da się zrealizować w rozsądnym czasie. Jeśli są jakoś połączone to jeszcze lepiej, bo mamy więcej czasu na poprawienie szerszego aspektu aplikacji.

Do każdej z rzeczy dopisz, jaką da przewagę. Weźmy na przykład taki punkt: Use only absolute paths, instead of relative. Jak to wygląda?

Zamiast pisać tak:

import Component from '../../../../components/Component';

Możesz robić tak:

import { Component } from 'components';

Od tego momentu każda osoba w zespole nie będzie się musiała uczyć na pamięć struktury projektu i latać po plikach. Wszystko będzie w jednym miejscu. Dodatkowo to lepiej wygląda.

Wypunktujmy korzyści:

• nie musimy znać struktury projektu
• łatwiej wdrążyć nowe osoby
• szybciej programujemy (nie trzeba szukać plików, mniej pisania, mniej myślenia)
• czytelniejszy kod
• łatwiej przenieść komponent w inne miejsce (zmiana będzie tylko w jednym pliku zamiast we wszystkich, gdzie importujemy)

Czas na zmiany!

Zebrałeś co chcesz zmienić. Masz plan jak to zrealizować. Jesteś w stanie powiedzieć ile to zajmie i wskazać korzyści.

Przygotuj pozytywnie brzmiącą notatkę. Coś w stylu:

Hej, jeśli dostanę 3 dni to mogę zrobić [...] (wypisz punkty, pokaż ich zalety). Są to standardy i dobre praktyki w programowaniu, które znacznie poprawią naszą pracę.

Dzięki temu zaoszczędzimy w przyszłości czas, zmniejszymy liczbę błędów oraz szybciej wprowadzimy nowe osoby do projektu. Przy okazji będzie łatwiej zrobić ticket XX-12 i XX-13 co zaoszczędzi nam dzień, a w przyszłośći przy kolejnych będzie podobna sytuacja.

Co byś pomyślał otrzymując taką wiadomość? Poświęcić 3 dni teraz, ale dostać możliwość robienia innych rzeczy w przyszłości szybciej. Już teraz odejdzie jeden dzień na te 2 rzeczy, a pewnie będzie więcej takich.

Zgoda. Możesz robić.

Zrób to mądrze

Nie napieraj na klienta. On musi czuć, że się to opłaca. Jednego dnia wyślij wiadomość i odpowiedz na pytania. Kolejnego możesz zapytać "To jak, robimy?". Po otrzymaniu potwierdzenia, opisz ładnie co zostanie zrobione. Niech czuje, że jest to istotne mimo że nie zobaczy żadnej zmiany. Postaw go w swojej sytuacji, ale od pozytywnej strony. Pokaż mu zalety, bo o wadach nikt nie chce słuchać.

Bądź odpowiedzialny

Klient musi czuć Twoją pewność. Nawet jeśli Ci nie idzie, nawet jeśli coś źle wyestymowałeś lub pojawiły się błędy. Weź to na klatę. Bądź profesjonalistą i nie zwalaj na coś winy. Jesteś odpowiedzialny za swój kod i musisz pokazać inne wartości płynące z Twojej pracy. Będziesz mógł wprowadzać zmiany, gdy zdobędziesz zaufanie. A to się stanie gdy będziesz podchodził profesjonalnie do bycia programistą.