3 problemy w komunikacji z klientem, czyli co czyni cię seniorem

15 kwietnia
Tetyana Golubyeva, Delivery Manager, DataArt
3 problemy w komunikacji z klientem, czyli co czyni cię seniorem
Nieuzasadnione oczekiwania to problem, z którym mierzą się na co dzień zarówno klienci jak i zespoły projektowe. Przy różnicy zdań często pojawiają się konflikty. Każdy z nich wydaje się wyjątkowy, ale prawda jest taka, że przyczyny trudnych sytuacji, ze względu na to, jak często się zdarzają, da się pogrupować i wyodrębnić kilka głównych typów. Tatyana Golubyeva, Delivery Manager w DataArt, przeanalizowała 3 najczęściej występujące typy konfliktów i wyjaśniła, dlaczego specjaliści na poziomie junior i middle powinni być świadomi ich istnienia. Artykuł ten jest więc skierowany głównie do młodych programistów.

1. Szybka odpowiedź na nowe zapytania vs. dokładne planowanie

Tworzenie oprogramowania to zadanie zlecane na zewnątrz, podczas gdy support i hotfixy zostają zazwyczaj po stronie klienta. Jasne jest, że zespół IT po stronie klienta zawsze skupia się na wymaganiach biznesowych, które mogą błyskawicznie się zmieniać (np. coś nie działa i musi zostać naprawione natychmiast, umowa z nowym partnerem obejmuje aktualizację systemu). Priorytety nie są stałe i mogą nie wpisywać się w żadne stworzone wcześniej plany i harmonogramy. To szczególnie widoczne, kiedy zespół po stronie klienta nie jest liczny, a proces rozwoju oprogramowania jest źle ustrukturyzowany i nie obejmuje żadnego buforu oraz gradacji zadań według ich pilności.

Programiści w specjalistycznych firmach dążą do tego, by pracować według planu i oczekują, że na każdym etapie zmieszczą się w prognozowanym zakresie, a wszystkie zadania będą jasno sformułowane przez analityków biznesowych. Utrzymanie równowagi pomiędzy tymi dwoma światami jest niesamowicie trudne. Współpracownicy po stronie klienta zaczynają podejrzewać, że team outsourcingowy zwyczajnie nie chce odpowiadać na potrzeby biznesowe. Często nie rozumiemy, dlaczego nasi partnerzy nie trzymają się zatwierdzonego planu, nie są w stanie jasno sformułować wymagań i zmieniają je w trakcie realizacji projektu. Deklaracja “chcemy być jednym zespołem” przestaje działać, ponieważ z jednej strony mamy do czynienia z tymi, którzy “nie chcą pomóc”, a z drugiej tymi, którzy “łamią ustalenia”.

By uniknąć ostrej fazy takiego konfliktu, albo, co bardziej korzystne, w ogóle go uniknąć, obie strony powinny rozumieć, że rozwój i wsparcie oprogramowania to dwa różne procesy. Z tego powodu zespoły powinny pracować inaczej. Będziemy w stanie skoordynować działania tylko wtedy, kiedy zrozumiemy, że ostateczny cel jest wspólny, a oba teamy rozwiązują osobne, charakterystyczne dla nich problemy.

2. Aktualne wyzwania biznesowe vs nowe technologie

Nowe technologie same w sobie, interesują biznes wyłącznie z użytkowego punktu widzenia. Dla każdego klienta istotne jest rozwiązanie problemów biznesowych w efektywny sposób, nowe narzędzia analizowane są zatem tylko z takiej perspektywy. Tymczasem kierujący się entuzjazmem wobec technologii programiści zawsze chcą pracować z obiecującymi i robiącymi wrażenie rozwiązaniami.

Jakakolwiek migracja to dla klienta kwestia finansów. Jeśli wszystko działa bez zarzutu, oparte na przestarzałych frameworkach sprzed 5 lat, skłoni się on raczej ku wsparciu obecnego systemu niż drastycznym zmianom. Mało prawdopodobne, że zmotywujemy klienta tym, że użycie w jego aplikacji zaawansowanej technologii skutecznie przyciągnie uwagę grupy docelowej. W kontekście migracji lepiej sięgnąć po argumenty takie jak: szybkość działania, obniżenie kosztów wsparcia, bezpieczeństwo danych.

Programiści chcą natomiast uczyć się nowych technologii, najlepiej w godzinach pracy. Nie ma w tym nic złego: oczywiste jest, że na rynku pracy cenione są osoby, które posiadają doświadczenie związane z wieloma technologiami. I, oczywiście, pasjonaci, od samego początku skupieni na zgłębianiu swojej profesji i pokrewnych obszarów.

Z drugiej strony, nie zawsze jasne jest, w jaki sposób samorozwój programisty może pomóc biznesowi. Jeśli w obecnym projekcie dana technologia jest opcjonalna, nie powinno się oczekiwać od klienta, że dodatkowo zapłaci za zgłębianie jej tajników. Jeśli nie uda ci się zilustrować, w jaki sposób nowe technologie są w stanie zredukować koszty lub zwiększyć obroty firmy, update nie ma sensu. Z biznesowego punktu widzenia to całkowicie logiczne.

Trochę łatwiej jest z kwestią UI. Standardy w tym obszarze zmieniają się szybko, a dla klienta jest ważne, by, na przykład, jego strona wyglądała atrakcyjnie i nowocześnie, dzięki czemu łatwiej jest mu zgodzić się na regularne aktualizacje interfejsu. Czasami jednak przeterminowana wizualnie aplikacja wciąż zaspokaja potrzeby biznesowe. W takiej sytuacji klient może odrzucić oferty dotyczące modernizacji, nawet jeśli sam pomysł mu się podoba.

hand

3. Rozwiązanie konkretnego problemu vs nieskazitelny kod

Klient oczekuje od partnera technologicznego propozycji rozwiązania problemów biznesowych, które bierze pod uwagę określone restrykcje: czas, finanse i inne istotne zasoby. Programistom zawsze wygodniej jest pracować z wymaganiami przełożonymi na język inżynierów, często w formie szczegółowych instrukcji. Ale to specjaliści, którzy potrafią rozmawiać z klientem o jego potrzebach i opisać narzędzia techniczne, które są w stanie na nie odpowiedzieć, mogą być nazwani prawdziwymi seniorami. Zostanie seniorem bez tej umiejętności jest trudne.

Potrzeba posiadania jasnych instrukcji, nawet jeśli jesteś w stanie przełożyć je na nowe stylowe rozwiązania technologiczne, to raczej cecha specjalisty na poziomie middle. Jeśli jednocześnie znasz wiele technologii, wciąż jesteś middle developerem z szeroką wiedzą technologiczną. Żadne narzędzie samo w sobie nie ma realnej wartości rynkowej; staje się interesujące wtedy, kiedy oferuje możliwość rozwiązania konkretnego problemu,

Europie wschodnia wciąż rozwija kulturę w obszarze kreowania rozwiązań technologicznych. Powiedzmy 20 lub nawet 10 lat temu, specjaliści z tego rejonu koncentrowali się wyłącznie na tworzeniu kodu. Po pierwsze dlatego, że ich usługi były relatywnie niedrogie. Obecnie nie interesuje nas już praca za niewielkie stawki, co znaczy, że nasza gotowość do pobierania niskiego wynagrodzenia przestała być przewagą konkurencyjną. By utrzymać zainteresowanie usługami, należy zatem zanurzyć się w problematyce biznesowej, niwelując tym samym dystans dzielący programistów i klientów.

Outsourcing w produkcji oprogramowania nie różni się znacząco od innego biznesu usługowego. Kiedy oddajesz samochód do serwisu, nie jesteś raczej pytany, co dokładnie i jak naprawić. Prawdziwym “czarodziejem” jest ten, kto jest w stanie całkowicie rozwiązać twój problem w niekoniecznie jasny dla ciebie sposób. Tak samo dzieje się w świecie technologii - klient rozmawiający z developerem nie musi posiadać wiedzy na temat IT.

Dlaczego ja?

Wielu programistów jest przyzwyczajonych, że poszukiwanie odpowiednich rozwiązań jest zadaniem wyłącznie dla architekta. Obecnie jednak coraz więcej oczekuje się od programisty na poziomie seniora. Jeśli nie wiesz, jak rozwiązać problem klienta, może on od ciebie oczekiwać, że przedyskutujesz to z zespołem i zaoferujesz mu podejście, które będziesz w stanie uzasadnić. Szczególnie widoczne jest to w małych projektach, które nie zatrudniają architektów i w wąskich obszarach, takich jak automatyzacja procesów czy zarządzanie danymi, które nie wymagają dużych zespołów. Tylko developerzy pracujący za niskie stawki mogą pozwolić sobie na zanurzenie się wyłącznie w kod - ale ci, którzy ich poszukują, mają zupełnie inne potrzeby.

Architekci i liderzy zespołów dobrze to rozumieją, tak jak wielu seniorów. Ale z perspektywy mojego doświadczenia, wielu młodych programistów nie rozumie, jak istotna jest wiedza domenowa i, co najważniejsze, gotowość do podjęcia bezpośredniej komunikacji z klientem. Rozwijanie takich umiejętności jest kluczowe dla rozwijania kariery i, w dłuższej perspektywie, osiągnięcia zawodowego sukcesu.