[«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 — це 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
Добігала кінця фаза розробки продукту, і потрібно було презентувати напрацювання широкому колу представників клієнта: працівникам ІТ-департаменту, менеджменту, керівникам підрозділів — усього майже
Історії ІТ-спеціалістів, які поділились фейлами на умовах анонімності
Смайлик чи дужечка?
Не то чтобы факап, просто забавная история.
Был клиент, американский стартап, все общение в основном в чатиках: с мемами, сленгом, иногда даже нецензурными словами.
Попросил доступ на сервер, который до этого меинтейнили наши сисадмины. Высылаю аs is: логин + пароль примерно такой: 574Fa8qj).
Клиент не может зайти под этими кредами, мы (команда) заходим без проблем. После получасовых разбирательств (подозрение было на недоступность сервера извне или из другого региона) оказалось, что клиент думал, что «)» в конце пароля — смайлик.
Як різниця часових поясів врятувала від фейлу
Це були мій перший робочий тиждень у новій компанії й перше завдання, яке мені дали розв’язати.
У клієнта на корпоративному порталі було рішення, що генерувало на кожний місяць безліч повторюваних у компанії подій. У цьому рішенні перестала працювати певна функційність, а мені поставили завдання розібратися, що не так, і розв’язати проблему.
Для дослідження й роботи в клієнта функціювало тестове середовище, посилання на яке мало відрізнялося від продуктивного. Для того щоб дослідити проблему, мені потрібно було згенерувати набір повторюваних подій (орієнтовно 50). За класикою жанру, я переплутав вкладку браузера з тестовим і робочим середовищами. Помітив це відразу після того, як наповнив їхній робочий календар тестовими подіями.
На щастя, через різницю часових поясів у клієнта робочий день ще не почався, і ми змогли відфільтрувати тестові події за часом створення та швидко їх видалити.
Це точно був не найкращий початок нової роботи.
3000 євро за пару днів
Однажды я перепутал сотни с тысячами и указал стоимость проекта на пару дней в 3000 евро вместо 300. Что интересно, заказчик спокойно заплатил. Такой вот случай, когда плохое знание английского оказалось полезным.
Hi gays!
На своем первом зарубежном проекте я писала письма для команды в США, начиная словами «Hi gays!» Они молчали две недели, потом корректно попытались выяснить, почему я так делаю. Было очень стыдно и смешно — ребята были с чувством юмора.
Ще більше фейлів на співбесідахта робочі провали.