Вітання! Мене звуть Максим Нікітцов, я керівник проектів в компанії SmartHead. Ми займаємося розробкою цифрових продуктів. Як і всім в індустрії нам важливо, щоб замовники були задоволені виконаною роботою. Це можливо, якщо результат принесе їм необхідну користь, вирішить існуючу проблему. При цьому процес досягнення результату також повинен бути комфортним і орієнтованим на конкретного клієнта. У своїй практиці ми часто говоримо, що потрібно задовольнити очікування замовника.
У цій статті я розповім, що таке очікування, і поділюся порадами, як ними можна керувати. З одного боку може здатися, що тема якась очевидна. Як говориться в «Цитатнику великих»: нормально роби – нормально буде. Але з іншого боку ця тема сильно недооцінена і незаслужено знаходиться в тіні, тому що потрібно обережніше ставитися до очевидного. Про це і не тільки нижче.
Вступ
Очікування – це припущення, яке здається найбільш імовірним в ситуації невизначеності. Суб’єктивне побажання щодо майбутніх подій. Ми щодня створюємо очікування як свої, так і оточуючим людям. Про те, що ми зробимо і яким чином, як поведуть себе наші колеги і друзі.
На основі очікувань приймаються рішення і оцінюється їх успіх. При цьому очікування у людей можуть відрізнятися і зазвичай формуються надлишково позитивними (нам подобається вірити в краще). Коли очікування не відповідають реальності, це відчувається болісно. Ми відчуваємо себе розчарованими, навіть іноді обдуреними. Саме тому очікуваннями потрібно управляти.
Я буду говорити про управління очікуваннями в професійному контексті. На мій погляд, це один з ключових аспектів для побудови хорошого клієнтського сервісу і взаєморозуміння в команді. У повсякденному житті також корисно управляти очікуваннями. Це зробить спілкування з близькими і друзями надійнішим і повним довіри.
При вирішенні бізнес-завдань очікування формуються у вигляді вимог до результату і процесу його досягнення. Вони ґрунтуються на особистому досвіді, мотивах, думці колег і експертів. Часто очікування формуються відмінними від реальності, тому що кожен існує в абстрактному світі своїх особистих помилок. Спробуйте пошукати «типові когнітивні спотворення», ймовірно, знайдете багато знайомих шаблонів. Я не до того, що всі ми божевільні. Просто думаємо ми по-різному, і це природно.
Управляти очікуваннями – значить приводити припущення власника очікувань в найбільш можливу відповідність реальності. Іншими словами подумати, з’ясувати, зрозуміти, обговорити, переконати і переконатися самому. В першу чергу це відкрите спілкування. Управління – це вплив на очікування оточуючих людей і свої власні.
Далі ми розглянемо набір практик. Не ставтеся до них, як до догми. Вони покликані сформувати образ мислення, необхідний для успішного управління очікуваннями. Але питання їх застосування в кожному конкретному випадку завжди відкрите. Також можна помітити, що вони перетинаються з областями знань проектного управління. Так і є. Управління очікуваннями допомагає нам управляти вимогами, ризиками, термінами і т.д.
Всі приклади перебільшені, непотрібні деталі опущені, збіги з реальними людьми і ситуаціями випадкові.
Думайте про власника очікувань і будьте уважними персонально до нього
Як думає людина, очікуванням якого ми прагнемо відповідати? Який у нього контекст і досвід? Чого хоче особисто він? Найчастіше люди, відповідальні за вирішення завдань, самі цього результату не потребують. Це наймані співробітники: лінійні менеджери, заступники, помічники та секретарі керівників. Вони не бенефіціари з боку бізнесу і не користувачі продукту. При цьому у них є цілком конкретні потреби і занепокоєння, про які не варто забувати. Відштовхуватися від співрозмовника, його знань і переживань – половина успіху для якісного сервісу.
У компанії замовника в відділі маркетингу є менеджер, який відповідає за роботу сайту. Навіщо йому знати, що поточна проблема в скрипті, який бере дані з вивантаження CSV в невідповідному кодуванні ANSI, і потрібно використовувати зовнішню бібліотеку для роботи з файлами в UTF? У нього стрес, він вирішує завдання в незнайомій предметної області. Чи потрібно йому забивати голову незрозумілими термінами?
Його турбує термін і вартість вирішення проблеми, йому потрібно відзвітувати керівнику. Скажіть йому, коли карта з їх точками продажу знову коректно запрацює і що вам для цього потрібно, наприклад надання доступів до сервера і узгодження кошторису.
Якщо ж з вами спілкується технічний директор або інженер замовника, для нього деталі проблеми і рішення можуть бути важливіше.
Спілкуючись з конкретною людиною, потрібно говорити на зрозумілій йому мові, дотримуватися прийнятої раніше термінології. Якщо без роз’яснень почати називати зрозумілі речі новими словами (навіть якщо так правильніше), то ймовірно вас зрозуміють неправильно.
Може бути корисним досвід інших людей, які вже взаємодіяли з цією людиною. Взагалі, питати поради досвідчених товаришів – це корисно.
Задавайте правильні питання
Очікування виявляються в бесіді і опитуваннях. Потрібно намагатися задавати прямі відкриті питання, на які не напрошується проста відповідь «так» або «ні». Питання повинні направляти в суть завдання. Яку проблему ми повинні вирішити? У кого ця проблема виникає і чому? Що це за люди і чого саме вони хочуть?
– У вас була якась тактика з самого початку, і ви її дотримувалися?
– З самого початку у мене була якась тактика, і я її дотримувався.Ось так не треба ставити питання.
Хороше запитання повинне сприяти швидкому отриманню інформації. Іноді люди починають додумувати і видавати свої припущення за дійсні логічні ланцюжки. І замість прямого запитання задають непряме.
Керівник проекту Василь хоче зрозуміти, які обмеження по застосовуваних технологіях є у нового замовника. Василь припустив, що замовник захоче застосовувати знайомі йому по минулим проектам технології. У підсумку він задає питання: «На якому стеці зроблені інші ваші продукти?»
Але чи буде перелік застосованих раніше технологій відповіддю на його поточне питання: «Які у вас є вимоги і обмеження до стеку поточного проекту?» Ні звичайно. Це не очевидно.
Цим складним хитромудрим прикладом я хочу підкреслити: хороше питання – пряме відкрите питання, так би мовити, «в лоб».
Питання повинно мати зрозумілу мотивацію і контекст. Пам’ятайте, що оточуючі нас люди мають дещо відмінні знання про предмет розмови і поточний статус роботи. Якщо ми не дамо досить подробиць, наш співрозмовник додумає їх сам. При цьому невірний контекст може збити з пантелику і знизити бажання відповідати. Люди намагаються заповнювати невизначеності припущеннями. Але думаючи, витрачають багато енергії і, буває, «заганяються», видаючи припущення за істину.
Питання замовнику в контексті аналізу автоматизації процесу документообігу: «Чому бухгалтер приносить вам документи на підпис два рази в день?»
Що тут може бути незрозумілого, так? Але ймовірна перша емоційна реакція людини, яка не звикла думати як аналітик: «Яке ваше діло? Мій бухгалтер, скільки хочу, стільки і ганяю ». Починаючи питання з «чому», можна змусити співрозмовника виправдовуватися. А виправдовуватися ніхто не любить.
З мотивацією: «Процес підписання документів двічі в день – це виробнича необхідність? Ймовірно, частоту можна зменшити, скоротивши трудовитрати бухгалтера на підготовку документів і ваші на відволікання і підписання. З якою метою зараз це відбувається так часто? »
Або ще приклад спілкування вже всередині команди: «Скільки часу зайняла розробка особистого кабінету для Х?»
Начебто просте запитання керівника розробнику. Однак незрозуміло, чому воно задане. Керівник хоче проконтролювати дотримання проектних обмежень? Або оцінити ефективність спеціаліста, тому що є сумніви в його кваліфікації?
Можна відразу запитати точніше, усунувши ґрунт для параної: «Ми зараз оцінюємо можливу трудомісткість аналогічного проекту. Скажи, будь ласка, скільки часу у нас зайняла розробка особистого кабінету для Х? Що може вплинути на зменшення або збільшення цієї трудомісткості? »
Давайте відповіді на поставлені питання
Перед тим, як відповісти на питання, потрібно перевірити, чи відповідаємо ми саме на нього, чи не захопилися ми міркуваннями, втративши суть.
Питання: «Які терміни і бюджет будуть на вирішення завдання?»
Погана відповідь: «Підсумкову вартість робіт ми зможемо назвати після уточнення вимог. Для вирішення такого завдання потрібно застосовувати гібридну модель розробки. Спочатку потрібно провести етап аналітики і прототипування. На виході ми отримаємо більш чіткі вимоги, за якими вже можна буде точно оцінити трудомісткість і почати розробку ».
Нас запитали про ціну і термін, а ми про «підхід» і «ми зараз не знаємо». Замовнику це не допомагає.
Краще: «З досвіду розробки аналогічних проектів термін може скласти 3 місяці при бюджеті 5 млн. грн. Це груба оцінка по аналогії. Щоб її уточнити, потрібно спочатку уточнити вимоги. Також можна поступово занурюватися в деталі прямо в процесі роботи в умовах відомого обмеження по терміну і бюджету. Так, ймовірно, ми заощадимо час. Який з варіантів вам більше підходить? »
Якщо питання здається некоректним, не варто відразу відповідати питанням на питання. Спочатку краще постаратися відповісти саме на нього і вже потім давати коментарі щодо контексту, якого, можливо, не вистачає.
«Які технології застосовувалися при розробці продукту Х?»
«Ми використовували Node.js і React JS. Але для вашого проекту вибір технологій може відрізнятися. Які обмеження та побажання є з вашого боку? »«Як можна зменшити кількість годин у кошторисі?»
«Щоб зменшити кількість годин, потрібно скорегувати вимоги до результату і процесу роботи, вибрати інші способи вирішення завдання. На скільки ми зрозуміли, змінювати вимоги ви не готові, тому для зниження трудомісткості рішення поточної задачі можливостей немає. У такій ситуації правильніше говорити про підсумкову вартість рішення, а не кількість годин. Підкажіть, на яку суму ви розраховуєте? »
Говоріть, що робимо і не робимо
Важливо проговорювати своїми словами, як ми зрозуміли завдання: що ми збираємося зробити, яким буде результат. Потрібно пам’ятати про мету і погоджувати її з планованим рішенням.
Але також необхідно звертати увагу на те, чого ми точно не збираємося робити і чому. Часто вже цього досить, щоб відсікти завищені очікування. Або стане зрозуміло, що є важливі вимоги, які замовнику здавалися очевидними і не були озвучені, а нам здалися не обов’язковими.
Потрібно говорити про потенційні проблеми (ризики), що ми збираємося з ними робити. Або не збираємося, і що це означає для проекту. Які ризики ми беремо на себе, а які залишаються на стороні замовника.
Слідкуйте за конкретикою і точністю
Потрібно уникати розмитих формулювань, бути лаконічними і однозначними одночасно. Наші вигадані світи перетинаються, але вони не тотожні.
До теми бородатий анекдот.
Дружина відправляє чоловіка-програміста в магазин:
– Купи батон хліба, якщо будуть яйця – візьми десяток.
Чоловік повертається з магазину з десятьма батонами.
– Ти навіщо стільки хліба купив?
– Так адже яйця були …
Також, наприклад, «зробимо якомога швидше» звучить з одного боку цілеспрямовано, а з іншого не говорить, коли зробимо. Як розуміємо можливу тривалість виконання завдання ми, а як замовник? Якщо називаємо відносні терміни, то потрібно вказувати, щодо якої події і умови його настання.
Але є явне виключення – надто точні оцінки трудомісткості завдання. Ось їх якраз варто або уникати, або сім разів зважити всі за і проти. Оцінки, що таке точність оцінки і що з ними можна зробити – це окрема тема для розмови.
Перевіряйте припущення
Припускати і додумувати – це природно. Однак припущення повинно звучати саме як гіпотеза, і ставитися до нього слід так само: воно вимагає перевірки, що буде, якщо воно помилкове.
Потрібно з обережністю ставитися до очевидного. Ми спираємося на особистий досвід, а він може не збігатися з оточуючими людьми, яким очевидно інше. Як показує практика, чим очевидніше нам щось здається, тим впевненіше ми вважаємо це однаково зрозумілим для всіх. Ми багато разів спотикалися зі словами «це ж було так очевидно».
Виявляється, неперевірене очевидне – всього лише припущення, яке може бути помилковим.
Не плутайте «робити» і «зробити»
Якщо коротко, зробити – значить здати роботу. Якщо завдання треба зробити за п’ять днів, значить через п’ять днів має бути підтвердження, що все зроблено правильно. Для цього починати здавати роботу потрібно заздалегідь.
Варто стежити, щоб ці слова використовувалися з однаковим змістом командою проекту і замовником.
Знижуйте градус категоричності
Категоричність і авторитет спікера – рецепт некоректних очікувань. Часто висловлювання може бути істинним тільки в поточному контексті, і його обов’язково потрібно озвучити.
Наприклад, твердження «Використовувати хмарну інфраструктуру – найкраще рішення». Завжди? Або саме для поточного продукту, щоб забезпечити гнучкість масштабування і оптимізувати реалізацію деяких функцій?
Або «Цю функцію неможливо зробити». Точно? Можливо в принципі зробити дуже багато, питання тільки ціни і терміну – проектних обмежень, які, ймовірно, замовника не влаштують. Саме тому ми не зможемо в поточних умовах виконати таке завдання.
Накиньте на категоричне висловлювання контекст і аргументи, і воно стане більше схоже на експертну думку про поточну ситуацію.
Корегуйте невірні очікування
У нашій сфері є міф, що не можна говорити замовнику «ні» або що він не правий. Насправді можна і навіть потрібно, коли його завдання розходяться з реальністю і очікуваною користю. Головне, робити це потрібно аргументовано, пропонуючи альтернативні варіанти досягнення його цілей.
Не бійтеся знижувати ступінь очікуваного захоплення або надлишкового негативу щодо успіху проекту. Завищені і занижені очікування теж некоректні. Перші можуть знизити підсумкову задоволеність, тому що очікувався більш істотний ефект від результату. Другі – стати причиною відмови від реалізації ідеї, яка здається занадто неперспективною.
Не допускайте прогалин в комунікації
Чим довше ми не розмовляємо з людьми, тим сильніше їх очікування розійдуться з реальністю. Якщо ми не заповнимо правильно контекст, люди його додумають самі і можуть помилитися.
Думайте і говоріть про свої очікування
Допоможіть своїм товаришам. Розкажіть, чого хочете особисто ви від проекту, від взаємодії в команді, роботи в цій компанії. Які у вас цілі, пріоритети та інтереси. Озвучуйте свої побоювання, аргументуйте точку зору. Говоріть, коли ви очікуєте отримати результат, чого чекаєте в процесі виконання завдання. Намагайтеся бути об’єктивними.
Скажіть команді, що ви їй довіряєте і очікуєте рішення в термін, нагадайте про значення слова «зробити». Ви здивуєтеся, як свобода укупі з делегуванням відповідальності стимулюють людей думати.
Власними очікуваннями потрібно управляти так само – думати про їх ймовірну завищеність, категоричність і коригувати.
Основні тези
Для закріплення список рекомендацій:
- Думайте про конкретну людину і його потребах.
- Задавайте правильні питання і відповідайте на поставлені.
- Говоріть, що робимо і що не робимо.
- Будьте конкретними і точними.
- Перевіряйте припущення, знижуйте градус категоричності і очевидності.
- Не плутайте «робити» і «зробити».
- Корегуйте невірні очікування. У тому числі і свої.
- Не допускайте прогалин в комунікації.
- Говоріть про свої очікування.
Управління очікуваннями – це перш за все прозора комунікація і увага до конкретної людини. Важливо рефлексувати на тему очікувань – думати що зробити, щоб в них потрапити, і чому ми не потрапили. Кожна людина буде мати свою комбінацію очікувань щодо результату діяльності і процесу його досягнення.
Якщо не ми генеруємо коректні очікування, це робить хтось інший. Очікування є завжди, питання тільки в тому, наскільки вони наближені до реальності.
Одного разу мій друг сказав своєму колезі, який мовчки злився на керівника за його манеру керування: «Є така опція у людей -” поговорити “. Спробуй ». Не забувайте про цю опцію разом з «подумати».
Успіхів!
Оригінал статті російською мовою на сайті VC.ru