Уявіть, ніби їдете за кермом у тумані. Ви рухаєтесь впевнено, хоча вам складно побачити, що відбувається попереду. У вас є лише поверхове розуміння ситуації на дорозі. Приблизно так почувається і клієнт, коли на проєкті не забезпечують належний рівень візібіліті (visibility) — прозорості усіх дій фахівців.
Поняття «візібіліті» означає, що клієнт повноцінно розуміє все, що коїться на різних етапах проєкту.
Напевно, комусь із читачів зараз відгукнуться ці рядки. Коли в якийсь момент не можеш збагнути, чому із замовником стало складно спілкуватись, чому він нервує. На початку своєї кар’єри ліда я теж не розумів важливості візібіліті. Команда витрачала шалену кількість годин на непотрібні роз’яснення клієнту замість того, аби приділити більше уваги самим проєктам.
Згодом усе змінилося на краще завдяки впровадженню принципів візібіліті. Цими порадами я і хочу поділитися з вами — розробниками, менеджерами, бізнес-аналітиками та всіма, хто відповідає за комунікації із замовником.
Якщо клієнт не має достатньо інформації щодо специфіки вашої роботи, у нього можуть виникати ідеї, які буде складно втілити в життя. Можна скільки завгодно пропонувати, скажімо, тестування продуктивності застосунку, але чого воно варте, якщо ним користуються всього 5 людей і за специфікою продукту більше не буде. Такий запит не має сенсу.
Ви з клієнтом перебуваєте у різних контекстах, які можуть зовсім не перетинатися. В результаті вам важко донести йому свою думку. Зідзвони затягуються по часу і врешті стають марними. Продуктивність роботи падає, терміни розробки і тестування зміщуються.
Клієнт повинен знати, коли і що ви зробили добре. За відсутності візібіліті він не розуміє, навіщо розробники створюють певні фічі і що вони дають проєкту. Тож ви не зможете «продати» заслужений успіх. Замовник просто не оцінить ваші здобутки, бо бачитиме користі з цього.
Якщо людей завантажують неадекватними завданнями, недоцільними і тривалими мітингами, а результати їх старань не цінують, то в якийсь момент їм забракне знаходити сили і натхнення на роботу. Ситуація швидко позначиться на ініціативності, продуктивності працівників. Людина навіть може втратити віру в себе і у те, що здатна втілити щось вартісне.
Перш за все — відчутно простіша взаємодія з клієнтом. Адже бути із замовником на одній хвилі — значить швидше надати йому потрібний функціонал і вирішити бізнес-потребу. Та цим переваги візібіліті не обмежуються. Серед іншого корисного можна виділити наступні…
Коли клієнт бачить і розуміє вашу роботу зсередини, вам буде простіше переконувати його в правильності своїх ідей. Він також матиме чітке уявлення про ваші можливості і термінів, в які команда втілить задум.
Людина бачить реальну користь від ваших старань — до прикладу, у фідбеках від користувачів, у кількості завантажень застосунку. А отже клієнт готовий збільшувати кількість задач, урізноманітнювати їх, покладаючись на ваші ідеї та напрацювання. У свою чергу перед вами відкриваються нові активності та виклики. Не виключено, що клієнт дасть добро і на нових людей у команді.
Комунікація стає простішою і значно прискорюється. Переваги відчують не лише ті, хто напряму спілкується з клієнтом, а й інші учасники команди. Ваші колеги зможуть активніше висловлюватись на мітингах, відстоювати свої ідеї, ділитися успіхами, відкрито обговорювати з клієнтом труднощі й спільно шукати рішення.
Сарафанне радіо досі залишається найкращим способом залучення нових клієнтів. Задоволений роботою замовник із високою ймовірністю рекомендуватиме вашу команду своїм партнерам, друзям, знайомим.
Якщо з візібіліті у вас не склалося й комунікація з клієнтом вже погіршилася, спробуємо виправити ситуацію за допомогою матриці 2х2.
Матриця складається з чотирьох блоків та має дві вісі. По горизонталі — ступінь прозорості роботи команди, по вертикалі — ступінь довіри до команди з боку замовника. У класичному проєкті ми стартуємо з квадрата A.
На початку клієнт вам мало довіряє і достеменно не знає, що ви робитимемо. Мета команди — в процесі роботи перейти до точки D. Там довіра клієнта настільки висока, що він не потребує від вас абсолютної звітності по кожному кроку. Він вже повністю покладається на вас. Це виражається у спрощеній комунікації та більш комфортній роботі.
Щоб потрапити з точки A до точки D, треба пройти через B та C. Але зверніть увагу: між A і D є червона двонаправлена стрілка. Що вона означає? Якщо ви припускаєтесь серйозної помилки в роботі і підставляєте замовника, довіра падає. Клієнт знову сумнівається в тому, чим займається команда. Тут вихід один — знову йти від A через B та C до бажаного D. У такому разі шлях до бажаного рівня довіри може бути довшим.
У деяких кейсах існують шорткати для швидкого переходу з початкової точки до кінцевої. Хоча такі приклади скоріше не про розробку, аутсорс чи менеджмент. Припустимо, ви — представник B2B-компанії й шукаєте клієнта. Ви можете працювати над комерційною пропозицією чи тендером. А можете «накрити галявину» для потенційного замовника — й автоматично перейти від A до D. Тепер клієнт вам довіряє, але досі не розуміє, як ви працюєте.
Пропоную детальніше розглянути переміщення по матриці 2х2 й необхідні дії з вашого боку для переходу на наступний рівень.
Для початку попрацюємо над підвищенням прозорості у роботі команди.
Поясніть, що вміють ваші люди, познайомте фахівців із клієнтом. Замовнику важливо впевнитися, що він зможе покладатися на вас, а такі стартові розмови покажуть, що і ви в цьому зацікавлені.
Завжди говоріть про реальні терміни для вирішення тих чи інших задач. Якщо маєте певні обмеження в технологіях, що використовуються, варто їх одразу озвучити. Так ви покажете клієнту свою відкритість і допоможете зрозуміти реальні можливості команди.
Для багатьох тестувальників та розробників це болісна тема. Адже часто доцільність звітів для них не очевидна. Найпоширеніші причини цього — коли команді погано пояснили, навіщо потрібен конкретний звіт або коли звіт у поточному вигляді не несе практичної користі. Проте на початковому етапі звіти вкрай важливі. Документація допоможе в динаміці відзначати дії команди та результати.
Завжди пам’ятайте про мету та очікувані результати по проєкту й регулярно діліться з клієнтом поточними напрацюваннями.
Вітаю, ви потрапили у квадрат B! У вас уже все суперпрозоре, хоча довіра від замовника досі на низькому рівні. Щоб покращити ситуацію, продовжуйте робити свою справу:
Якщо робити так тривалий час, замовник переконається у якості вашої роботи і почне вам по-справжньому довіряти.
Ідеальна ситуація. На цьому етапі ви можете позбавити команду частини зайвих звітів. Листувань поменшає, мітинги теж стануть коротшими. Якщо спочатку звіти обов’язково були потрібні, згодом завелика кількість такої інформація обтяжує роботу.
Насправді майже кожен клієнт не хоче стежити за вами. Це складно і забирає багато сил та часу. Тому коли він зрозуміє, що вам можна довіряти, то із задоволенням відмовиться від декількох рутинних звітів або скоротить періодичність їхньої підготовки. Аби переконатися у вашій порядності та якості роботи, клієнту буде достатньо просто поговорити з вами.
Щоб прискорити рух по матриці 2х2 та намагатись уникати проблем із клієнтом, слідуйте наступним принципам:
Не примушуйте клієнта вимагати звіти. Якщо він прийшов із запитом на нову звітність, то ви вже щось робите неправильно. Що могло трапитись?
В оцінках не варто покладатися на слова. Скажімо, замовник хоче побачити тестове покриття. Недостатньо сказати йому, що воно гарне. Залежно від ситуації гарним може бути покриття і 80%, і 40% і навіть 15%. Розрахуйте всі показники та поясніть їх. Так ви краще введете клієнта у контекст. Інакше обговорення можуть стати хибними. Замовник називатиме тестове покриття у 93% слабким, хоча вище зробити його неможливо чи наразі занадто складно.
Ви маєте добре розуміти, що цікавитиме клієнта. Наприклад, інколи QA-інженерам складно в цьому розібратися. На нашому рівні важливі одні показники, а на рівні бізнесу — інші. Я раджу йти ітеративним шляхом.
Після передачі звіту завжди просіть фідбек. Чи все зрозуміло в документі? Чого не вистачає? Що хотілося б дізнатися?
Спершу ви даєте базову інформацію, але вона може виявитись для клієнта малокорисною або взагалі непотрібною. А так ви продемонструєте, що турбуєтеся про покращення процесів та підвищення візібіліті.
Поінформованість клієнта — його спокій. Цей меседж пронизує червоною ниткою всю статтю. Клієнт завжди має бути в курсі всього, що відбувається на проєкті. І тут всі способи доцільні: і спілкування, і звіти, й інша ваша діяльність. Подавайте інформацію на зрозумілому та цікавому для клієнта рівні.
Йому неважливо, як ви написали рядок коду, який метод використали і що саме відрефакторили. Йому треба знати, що ви реалізували одну фічу, а іншу — ні, і можете пояснити, чому так сталося. Якщо ви чогось не змогли чи не встигли зробити, не чекайте від нього питання «Чому це не готово?». Самі скажіть про це. Так буде чесно.
Розповідайте про всі досягнення команди. Вигадали класну фічу, яка вирішить проблему користувача? Зробили щось швидше за прописані терміни? Підтягнули метрики, що були на низькому рівні? Говоріть про це — адже ви зробили чудову роботу і принесли користь бізнесу клієнта.
Отже, висновок простий — не залишайте клієнта «в тумані», наодинці зі своїм непорозумінням. Це загрожує тим, що він заповнить порожнечу якимись домислами та припущеннями. А це вже може стати серйозною проблемою для всієї команди. Набагато простіше одразу надавати клієнту всю базову інформацію й поступово розповідати про наступні кроки. Підвищення візібіліті не лише зробить вашу роботу якіснішою. Процес розробки стане комфортнішим для всієї команди і менш стресовим для самого клієнта.
Дуже хочеться робити якісь десктопні апки. Сумую за часами коли всі програми були offline-first, і…
Надсилаючи криптовалюту, багато новачків ставлять запитання: як працюють комісії та чому вони відрізняються в різних…
Нова афера набирає обертів — ось детальний розбір того, як фальшиві потенційні роботодавці намагаються вкрасти…
Соцмережа з можливістю вбудовувати повноцінні додатки прямо в пости — звучить як фантастика, але Farcaster…
Я ніколи в житті не був на співбесіді «по ту сторону». Мене ніхто не запрошував…
Я багато писав про fly.io — тоді ще новачка на ринку IaaS/PaaS хостингу. Я й…
