Три проблеми комунікації з клієнтом, або Що важливо для розробника, щоб стати сеньйором

6 лютого
Тетяна Голубєва, Delivery Manager DataArt
Три проблеми комунікації з клієнтом, або Що важливо для розробника, щоб стати сеньйором
Невиправдані очікування — проблема, з якою стикаються і замовники, і команди розробки. Через різні очікування один від одного доволі часто виникають конфлікти. Деяким вони здаються унікальними, але насправді вони схожі на десятки, якщо не сотні інших, і навіть цілком групуються за типами. Тетяна Голубєва, делівері менеджер DataArt, розібрала три найпоширеніші конфлікти та пояснила, чому знання про них є важливим для Junior і Middle розробників. Стаття найперше адресована якраз молодим програмістам.

У кожному пункті наведені цілком стандартні очікування кожного боку, які в реальних проектах нерідко вступають у протиріччя.

1. Швидка реакція на нові запити vs. Чітке планування та дотримання графіка

Часто на аутсорс віддають саме розробку, залишаючи на стороні замовника підтримку та хотфікси. Зрозуміло, що IТ-команда клієнта завжди орієнтована на запити бізнесу, які можуть змінюватися дуже швидко: наприклад, щось впало та вимагає негайного відновлення, або до угоди з новим партнером входить апдейт системи. Такі пріоритети можуть змінюватися дуже швидко та погано вписуються у будь-які плани, складені заздалегідь. Особливо це помітно, якщо в команді замовника не так багато людей, а процеси розробки ПЗ в компанії є нескладними та мало структурованими, тобто там, як правило, не закладають буфер і структурують роботу в найперше за терміновістю.

Розробники у профільних компаніях прагнуть працювати згідно з планом. І чекають, що на кожному етапі матимуть прописаний скоуп, а всі завдання будуть чітко сформульовані бізнес-аналітиком.

Підтримувати рівновагу між цими двома режимами, виявляється, дуже складно. Нашим колегам на стороні клієнта починає здаватися, що фахівці на аутсорсі просто не хочуть реагувати на потреби бізнесу. Ми ж часто не можемо зрозуміти, чому партнери не дотримуються ухваленого плану, не можуть достатньо чітко опрацювати вимоги та ще й змінюють їх у процесі роботи. Декларація “Ми хочемо бути з вами однією командою” перестає викликати довіру, адже з одного боку опиняються ті, хто “не хоче допомагати”, а з іншого — ті, хто “зриває домовленості”.

Щоб такий конфлікт вийшов із гострої фази, а ще краще в неї не переходив, обом сторонам бажано розуміти, що розробка та підтримка софту мають доволі різні процеси. Відповідно, командам доводиться працювати в них по-різному. Ми всі зможемо узгодити свої дії, тільки прийнявши, що при загальній кінцевій меті кожна з двох команд вирішує власні задачі.

2. Поточні задачі бізнесу vs. Інтерес до нових технологій

Самі собою нові технології бізнес цікавлять виключно з прикладної точки зору. Будь-якому замовнику важливо вирішити проблеми бізнесу найефективнішим способом, і нові інструменти він розглядає виключно у цій площині. При цьому програмісти, як люди захоплені, завжди хочуть працювати з найостаннішими та найперспективнішими технологіями.

Для замовника будь-яка міграція — це, насамперед, гроші. Якщо все працює на фреймворках п'ятирічної давності, він, швидше, очікуватиме підтримки існуючої системи без радикальних змін усередині. Мотивувати бізнес тим, що його додаток приверне увагу через використання просунутої технології, навряд вийде. Щоб переконати клієнта в необхідності міграції, краще оперувати поняттями швидкості, вартості підтримки, безпеки даних.

Зі свого боку, розробники хочуть освоювати нові технології, та бажано в робочий час. У цьому немає нічого поганого: зрозуміло, що на ринку праці фахівець цінується відповідно до кількості технологій, в яких він має практичний досвід. І, звісно, захоплений інженер із самого початку орієнтований на дослідження своєї професії та суміжних областей. Якщо ви хочете більше дізнатися про цей феномен, зверніть увагу на книгу "Потік" Міхая Чіксентміхайі.

З іншого боку, не завжди зрозуміло, як саморозвиток програміста допоможе бізнесу. І якщо в поточному проекті та чи інша технологія не є обов'язковою, недоцільно очікувати від клієнта доплати за поглиблену експертизу в ній.

Якщо не вийде показати, як нові технології скоротять витрати або збільшать доходи бізнесу, від оновлення доведеться відмовитись. І з боку бізнесу це є цілком логічним.

Трохи простіше з UI. Стандарти тут змінюються швидко, і якщо для клієнта важливо, щоб його сайт виглядав сучасно, він погоджується на регулярні оновлення. Але й тут нерідко доводиться визнати, що веб-додаток, який відстає від візуальних стандартів на декілька років, все ж задовольняє потреби бізнесу. Тому замовник цілком може відхилити ваші пропозиції щодо апдейту, навіть якщо сама ідея йому подобається.

image

3. Вирішення конкретної проблеми vs. Гарний код згідно з техзавданням

Замовник очікує від технологічного партнера вирішення проблем бізнесу, причому з урахуванням обмежень: часу, грошей або інших ресурсів. Програмісту завжди комфортніше працювати з вимогами, вже перекладеними мовою інженерних термінів, і він часто розраховує на докладну інструкцію. Але якраз колеги, які вміють обговорити з замовником те, що йому потрібно, а потім описати технологічні інструменти для рішення, зазвичай і називаються сеньйорами. І стати Senior розробником без цієї навички досить складно.

Потреба в чітких інструкціях, навіть якщо ви готові перекласти їх у нові стильні технології, підтверджує, швидше, рівень Middle. Якщо ви при цьому знаєте багато технологій, то по суті ви — middle-розробник зі знанням великої кількості технологій. Шкода, але ніякий інструмент сам собою не є цінністю для ринку, він цікавий тільки потенціалом вирішення тієї чи іншої проблеми.

Наразі у Східній Європі не вистачає культури пошуку інженерних рішень. Скажімо, двадцять, а то й десять років тому наші колеги в Україні та сусідніх країнах ще могли дозволити собі концентруватися тільки на написанні коду. Передусім тому, що їхні послуги коштували відносно недорого. Зараз працювати дешево нам стало нецікаво, а значить, готовність до невисокої оплати перестала бути нашою конкурентною перевагою. І щоб підтримувати інтерес до своїх послуг у цих умовах, важливо вникати у проблеми бізнесу, скорочуючи дистанцію з клієнтом.

Аутсорсинг у виробництві софта мало чим відрізняється від іншого сервісного бізнесу. Якщо ви пригнали машину до автосервісу, то у вас, швидше за все, не стануть питати, що саме та як потрібно відремонтувати. Вважається, що майстер — це той, хто може вирішити вашу проблему, можливо, не цілком зрозумілим для вас способом. Так само і клієнт, який розмовляє з вами як з розробником, зовсім не повинен глибоко розбиратися в IТ.

Чому я?

Більшість розробників звикли вважати пошук рішення виключно задачею архітектора. Насправді сьогодні цього все частіше очікують від програміста рівня Senior. Якщо ви не знаєте, як вирішити проблему замовника, він має право розраховувати, що ви обговорите її з колегами та все ж запропонуйте йому підхід, пояснивши свій вибір. Особливо це стосується маленьких проектів, які не можуть дозволити собі архітектора, та вузьких напрямків, на зразок Robotic process automation або Data management, де майже ніколи не потрібні великі команди. В принципі, дозволити собі стовідсоткове занурення виключно у код можуть тільки розробники з низьким рейтом — але ті, хто їх шукає, вже дивляться на зовсім інші регіони.

Архітектори та тімліди все це добре розуміють, як і багато хто з сеньйорів. Але, судячи з мого досвіду, багато молодих програмістів поки що не зовсім розуміють значення доменних знань, а головне — готовності до прямого спілкування з замовником. А розвиток таких навичок є дуже важливим для успішної кар'єри.

  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    7 жовтня
  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    29 вересня
  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    26 вересня
  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    Сьогодні