Fail review: спілкування з клієнтами

[«Fail review» — рубрика, в якій ми збираємо історії про робочі провалили: що відбулось, як виправляли і які висновки нікого.]

Непорозуміння, культурні та національні відмінності, нестача комунікації, технічні проблеми — причин факапів у спілкуванні з клієнтами вистачає. А історій, що змушують червоніти або сміятись (і чомусь вчать!) — ще більше. ІТ-спеціалісти діляться власним досвідом.

Про важливість юзер-сторі

Станіслав Семухін , Senior Android Developer у GlobalLogic

На одному з попередніх робочих місць сталася дуже характерна історія.

То був внутрішній продукт однієї з українських аутсорсингових компаній, яким власник керував на рівних правах з партнерами. Ці партнери були, як заведено на типового стартапі, і фаундерами, і продакт-оунерами, і бізнес-аналітиками.

Ми робили мобільні застосунки для цього продукту під iOS та Android. Я займався розробкою Android-версії.

І от перед початком одного зі спринтів продакт-оунер (він же кофаундер, бізнес-аналітик тощо) швиденько через Skype пояснює логіку нової фічі, яку треба було зробити в наступному спринті. Достатня сказати, що логіка була досить складна та, як наслідок, вже після цих подій ми витворили досить велику діаграму переходів для її опису. А цей хлопець вирішив, що він нам за 10 хвилин усе пояснити, і ми всі з його слів швиденько зрозуміємо й зробимо.

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

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

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

Насправді він створив свою юзер-сторі, написавши про це в чаті, попросивши нас робити все по ній, але забув заасайнити її на мене.

Тож я 2 тижню робив задачу, керуючись своїми хибними уявленнями, як це повинно працювати. І від спливає спринт, підходить годину демо.

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

Настає моя черга для демо. Присутні продакт-оунер, який ставив мені завдання, iOS-розробник, QA (які під час спринту так і не знайшли годину хоч раз подивитися на Android-застосунок) та співвласник компанії (який також був серед засновників цього продукту).

Я, звичайно, показую тій варіант, який імплементував на основі створених мною юзер-сторі (він був далекий від завдання, як від Марсу).

Звичайно, бачу непорозуміння, що наростає серед глядачів, але йду до кінця. Після демо цей продакт-оунер ставити просте запитання: «Що це?». Я відразу кидаю посилання на свою юзер-сторі, за якою я це імплементував. Він робить ще ширші очі й повторює ті саме запитання вже стосовно моєї юзер-сторі.

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

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

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

Поки працював на іншому проекті, знайшов дуже здібного молодого trainee, який після тримісячного курсу молодого бійця отримав від мене репорт начальству про повну оперативну готовність. Як ментор я рекомендував його на тій попередній проект.

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

Отже, рекомендація всім українським стартапам: ваші ідеї й ваш продукт нічого не варті, доки ви не побудуєте процес розробки.

Коли закінчується бюджет

Денис Костін , Project Manager в Digital Cloud Technologies

Одного разу, багато років тому, ми з командою робили невеликий пробний проект для однієї з фондових бірж. Ключовим моментом були рядки. Треба було якнайшвидше зібрати команду, долучаючи всіх без обмежень. З боку клієнта був молодий активний менеджер, який сам розподіляв роботу й контролював скоуп. Працювали ми на T&M. Усе було гарно й позитивно до того моменту, коли він раптом сказавши мені, що в нього вже закінчується бюджет, а ми ще не зібрали напрацьоване докупи та залишалося ще багато цікавих і потрібних ідей. Анонсований ж дедлайн був ще далеко...

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

Навіть якщо клієнт дуже впевнений, краще залишатися менеджером і сумніватися, а для проектів з високим ступенем невизначеності — MVP та Agile.

Верблюжу молоко, манговий сік і робоча неділя

Микола Кульпа , Product Manager у Comarch Poland S. A.

Працюю Product Manager в компанії Comarch (Польща) вже понад рік. Ще на початку співпраці потрапив на кастомізацію продукту (проект з арабським клієнтом (країну, на жаль, назвати не можу), що тільки почав використовувати наш продукт і хотів підтримку SLA).

Мене, адміністраційну людину з технічним бекграундом, вислали на першу лінію підтримки (onsite) до клієнта, щоб, мовляв, і продукт краще вивчив, і з клієнтом ближче познайомився, і провів аналіз бізнесу зсередини.

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

Ніхто не попередив, що я повинен виходити на роботу в неділю. Вже в обід, коли я, відіспавшись, вирушив на закупи до найближчого торговельного центру, мені на приватний номер (службовий ще не встиг зробити) зателефонував невідомий арабський номер. Це був клієнт, який проінформував, що вони відмовляються від SLA, оскільки на честь мого прибуття прийшов сам СТО фірми, аби традиційно вручити мені фірмовий шарф, а я просто не з'єднання явився!

Беру таксі й лечу з пакетами їжі, пакетом KFC і трилітровою банкою молока, до якої була прив'язана язано акційний манговий сік. На контролі пояснюю, що я працівник onsite й мені дуже терміново потрібно на зустріч. Мене відмовляються пускати, оскільки я не мав документів, а лише українські автомобільні права, написані невідомою їм мовою. Знаходжу якесь фото закордонного паспорта, нагадую, що на мене чекає СТО, і чую, напевно, найгірше: «Is it you Nick from Comarch?» Повертаюся й бачу перед собою старшого араба у білій мантії. Мило відповідаю, що це я, і починаю перепрошувати за запізнення й пояснювати, що на мене чекає зустріч із СТО.
На це чоловік відповідає, що зустрічі не буде, бо він має бігти, альо запрошує мене з понеділка знову прийти до офісу та, посміхаючись, дає мені візитівку й шарф.

І так, це був тієї самий СТО мого клієнта... Наступний діалог я є запам'ятав на все життя:
— Do you like camel milk?
— Camel milk! What do you mean?
— Dear Nick, U have a big bottle of camel milk in your hand.
— OMG! Facepalm...

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

Гроші — не головне

Олександр Литвиненко , Tech Lead

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

Одного разу я працював із MLM-щиками, бізнес яких засновано на створенні пірамід. Найбільше рефералів у таких системах збирають ті люди, які реально вірять у продукт. Вони вкладають у нього всі сили, адже, на відміну від типових пірамід, тут є якесь пояснення, звідки беруться гроші (інколи навіть доволі логічне). Чи вигадують ці люди продукт? Ні, продукт, зазвичай, дійсно є, але більшу частину прибутку цього продукту просто розподілено за рефералці, тому це зазвичай хайп.

Я працював з ними кілька років, і щоразу, як роботодавець казав: «Я хочу крутий продукт!», я давав йому цей крутій продукт. Альо MLM — це не там, де крутій продукт, це там, де все зроблено абияк, половина функцій не працює, а в апдейта важлива не якість, а кількість.

Саме тоді я чітко зрозумів, що не хочу так працювати й знайшов свою нішу: якісні та технологічні продукти.

Конфлікт із тім замовником почався відразу, як стали співпрацювати. На момент старту я займався складними проектами в дуже стислі рядки, коли все горить (був молодий, і здоров'я дозволяло). Саме з таким проектом він прийшов до мене: рядки нереальні — півтора тижня (MLM — це high load). Ми погодили, що система створюється з розрахунку на 10 тис. одночасних користувачів, але тільки для потокового функціонала. Після старту мені дадуть час на вдосконалення системи.

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

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

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

Завдяки цьому досвіду я сформував своє ставлення до ведення бізнесу. Я не заробляю мільйони, але мені вистачить на старість. Мої клієнти — адекватні люди, які прийшли за якістю. І працювати з ними — задоволення.

Клієнти — теж люди

Alex Fogol , Software Developer, C/C++ Expert у Selene Associates

Спілкування з клієнтами — нескінченна історія. Одного разу ми з клієнтом погодили специфікацію протоколу, яким малі спілкуватися між собою окремі програмні частини, і кожен зі свого боку почав розробляти прототипи. Це було дуже важливо, бо прототипи малі показати великому начальству, щоб продемонструвати прогрес (виділяйте бюджет і шліть гроші).

Напередодні презентації нічого не працює. Водночас клієнт стверджує, що все робить правильно. І сумніватися в цьому важко: ми ж погодили специфікацію, що могло піти не так?

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

Так і сказати. Головне — не боятися. А ще бути ввічливим.

Отже, іду до клієнта й кажу: «Хлопці, тут у нас, напевно, якась проблема, геть дрібне непорозуміння. А дайте-но я гляну ваш код, бо ж мені треба налагодити свій. Тож я подивлюся, як вони там, дві програми, між собою спілкуються».

Дають. А я вже знаю, що шукати, тож знаходжу відразу. Кажу: «Ой, тут не так, як ми домовлялися, але зараз швиденько виправимо, то не страшне, то з усіма трапляється!» Ще година пішла на те, щоб знайте, як то треба зробити мовою програмування клієнта, і від маємо: програми почали спілкуватися! Клієнт щиро вражений і задоволений та має що показати своєму великому начальству. Клієнт стоїть на нашому боці в питанні підписання контракту. Чистий профітЪ!

Ця тактика досить проста: якщо виникає проблема, слід ставати не на свій бік, не на бік клієнта, а саме на бік, що проти проблеми. І так само ставити туди й клієнта. Тож ми (я, ви й клієнт) — на одному боці, а проблема — на іншому. І це працює! Я перевіряв.

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

І суть моралі в тому, що «такі самі люди» геть не означає «такі, як я сам». Вони — інші. Вони можуть не бачіті проблему під тим самим кутом, під яким бачу її я. Навіть коли для мене це очевидний. Тому ніяк не можна ставити себе на місце клієнта. Слід саме очікувати, що ми й смороду бачимо це — просто одне й ті саме — по-різному.

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

Хотіли як краще, а вийшло...

Andriy Bas , Co-founder Uptech

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

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

Під час розмови ми зрозуміли, що product-market fit — нечіткий, а жодного аналізу не проводили. Потреба продукту на ринку була особистим припущенням. Аргумент клієнта був: «Ти ходіш на каву? Від бачиш, усі, з ким спілкувався, ходять на каву, тож сервіс буде популярними».

Ми, винятково через бажання допомогти, розказуємо, що є в нас якраз для його кейсу такий процес Discovery, під час якого ми проведемо user research, зрозуміємо цільову аудиторію, розробимо прототип і протестуємо його перед будь-якою розробкою. Мовляв, так правильно робити, так він заощадить гроші й це максимізує його шанс зробити успішний продукт. Адже це найпопулярніша помилка, якої припускаються засновники, і якої ми йому допоможемо уникнути.
І що ви думаєте? Замість того щоб прислухатися до нашої поради, він образився. Розгнівався, що ми не поважаємо його ідеї та ставимо під сумнів його компетенцію. Звісно ж, йому не потрібне ніяке тестування, бо продукт напевне буде успішний, і він це сам знає.

Ми так і не змогли знайті спільну мову. Він закінчив розмову. Звісно, ми не продовжили роботу. На жаль, не знаємо, як його «успішний проект» зараз поживає.

Отак, намагаючись допомогти, інколи залишаєшся винним...

Мистецтво компромісу

Володимир Яцевський , Chief Executive у LiveArt

Одного разу до нас звернувся клієнт з Німеччини, що мав власний продукт з онлайн-верстки друкованих матеріалів. Попередня версія була виконана з допомогою Flash, а тому клієнт шукав можливості переписати його на HTML/JS стек. Не буду вдаватись в технічні подробиці, але ідея проекту полягала у «схрещенні» нашої технології зі стороннім RTE-редактором (Rich Text Editor). Зі свого боку ми повідомили, що спочатку це буде суто R&D проект, який ми не можемо конкретно ні оцінити, ні гарантувати результатів.

І вісь тут нас чекав провал. Попри всю комунікацію, представники клієнта продовжували вважати проект досить тривіальним, обмеженим у часі і бюджеті, без особливих ризиків. Коли ж ми представили кілька MVP і почали вказувати на недоліки сторонніх бібліотек, які ми не були в змозі подолати, незадоволення клієнта наростало. Він вважав, що дефекти можна виправити в рамках того ж бюджету. Ситуація продовжувала загострюватись: клієнт не отримав очікуваного результату, нам було не вигідно продовжувати R&D проект на умовах фіксованого фінансування та відсутності розуміння характеру проекту клієнтом.

Одного дня я отримав досить однозначної листа: «виправте дефекти у рамках бюджету, або ми працюємо з вашими конкурентами і закриваємо проект». І комунікація, і сам проект опинилися у патовому стані. Усі пояснення та посилання на попередні листи та домовленості натикались на одну відповідь — «you have to fix it as promised».

У цею годину я натрапив на книгу Chris Voss «Never split a difference» . Її лише нещодавно перекладали у нас як «Ніколи не йдіть на компроміс» . Впавши у відчай від перспективи втратити цікавого клієнта, я зважився використати метод каліброваних питань у відповідь на всі жорсткі вимоги клієнта. Це був типовий наївний експеримент: я лише прочитавши частину книжки, а сам метод випробував хіба що на своєму синові, який якраз переживав кризу трьох років. Відправивши першого листа, я вже подумки очікував відповідь від комерційного директора компанії-клієнта з вимогою повернути проектні кошти... Здавалось, вся команда затамувала дихання. Усю розробка було поставлено на паузу.

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

Правило великого пальця і як у нас «віджимали» проект

Денис Братчук , директор з інжинірингу, GlobalLogic

Найбільш очевидні «факапи», які траплялися під час спілкування з клієнтами — це ті, які були помічені негайно. Канонічний приклад — мікрофон, який випадково виявляється включеним під час дзвінка, і дозволяє співрозмовнику почути те, що не було призначено для всіх.

Одного разу при дистанційному спілкуванні з потенційним партнером по бізнесу та обговоренні проекту, в якому ми спільно збиралися брати участь, один з представників партнера вимовив: «Я зайнятий, на дзвінку, віджимаємо проект у компанії такий-то». Чи варто говорити, чим закінчився цей дзвінок, а з ним і наше ледь почалося співробітництво?

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

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

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

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

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

Смакуючи чіпсами, вимикайте мікрофон

Андрій Кладочний , Frontend/SharePoint Developer

Добігала кінця фаза розробки продукту, і потрібно було презентувати напрацювання широкому колу представників клієнта: працівникам ІТ-департаменту, менеджменту, керівникам підрозділів — усього майже 10-15 осіб. Хтось із боці клієнта, під'єднавшись до презентації, забув вимкнути мікрофон і почав, прицмокуючи, смакувати чіпсами. Залізна витримка нашого BA допомогла йому закінчити презентацію, попри це звукове тло.

Історії ІТ-спеціалістів, які поділились фейлами на умовах анонімності

Смайлик чи дужечка?

Не те щоб факап, просто забавна історія.

Був клієнт, американський стартап, все спілкування в основному в чатиках: з мемами, сленгом, іноді навіть нецензурними словами.

Попросив доступ на сервер, який до цього меинтейнили наші сисадміни. Висилаю аѕ is: логін + пароль приблизно такий: 574Fa8qj).

Клієнт не може зайти під цими кредами, ми (команда) заходимо без проблем. Після півгодинних розглядів (підозра було на недоступність сервера ззовні або з іншого регіону) виявилося, що клієнт думав, що «)» в кінці пароля — смайлик.

Як різниця часових поясів врятувала від фейлу

Це булі мій перший робочий тиждень у новій компанії й перше завдання, яке мені дали розв'язків зв'язати.

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

Для дослідження й роботи у клієнта функціювало тестове середовище, посилання на яке мало відрізнялося від продуктивного. Для того щоб дослідити проблему, мені потрібно було згенерувати набір повторюваних подій (орієнтовно 50). За класикою жанру, я переплутав вкладку браузера з тестовим і робочим середовищами. Помітив це відразу після того, як наповнив їхній робочий календар тестовими подіями.

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

Це точно був не найкращий початок нової роботи.

3000 євро за пару днів

Одного разу я переплутав сотні з тисячами і вказав вартість проекту на пару днів в 3000 євро замість 300. Що цікаво, замовник спокійно заплатив. Такий ось випадок, коли погане знання англійської виявилося корисним.

Hi gays!

На своєму першому закордонному проекті я писала листа для команди в США, починаючи словами «Hi gays!» Вони мовчали два тижні, потім коректно спробували з'ясувати, чому я так роблю. Було дуже соромно і смішно — хлопці були з почуттям гумору.

Ще більше фейлів на співбесідах та робочі провалили .

Опубліковано: 18/07/19 @ 07:00
Розділ Різне

SEO Блог