Несколько лет назад я увидел рекламу универсального зарядного кабеля inCharge 3. Чтобы вы понимали, как он выглядит, вот:

В рекламе говорилось, что он:

1. Чертовски прочен. По нему может проехать легковой автомобиль и он не сломается.
2. Заменяет все остальные кабели (USB-C, USB-A, Lighting, Micro-USB), при этом компактен.
3. Нормально так стоит. Мне он обошёлся в 1980 ₽

После того, как я его купил, оказалось, что:

1. Он не поддерживает быструю зарядку. Как в 2020 году можно выпустить кабель без поддержки быстрой зарядки?
2. Передача файлов через него происходит только в одном положении. Если вы вставите кабель не той стороной, он не будет работать.

Это называется обманутыми ожиданиями. Криворукие создатели этого кабеля решили сэкономить на распайке в надежде на то, что пользователи смирятся с недостатками гаджета. На деле они получили огромное количество требований возврата и несмываемое пятно на репутации, хотя задумка была отличная.

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

В продуктовой разработке вместо ожиданий заказчика, ожидания клиентов. Однажды мне довелось делать мобильное приложение, личный кабинет абонентов одного кабельного телеоператора. Заказчику очень понравилась программа телевещания из приложения Beeline TV и он хотел сделать это центральной фичей приложения:

У Билайна простые серые кирпичи с названиями телепередач, в нашем же приложении должны были быть картинки. На реализацию и оптимизацию этой фичи ушло огромное количество времени, всё это нещадно тормозило и глючило.

Помимо программы, в приложении были всякие сервисные функции — просмотр баланса, вызов мастера, чат с техподдержкой.

После релиза же выяснилось, что реальные клиенты хотят от такого приложения совершенно другого — просмотра эфира разных телеканалов онлайн. А программа телепередач, на которую мы убили столько времени, им не особо интересна. Единица в гугл плей, потерянные деньги и репутация.

Работа с галлюцинациями

Работа с галлюцинациями начинается с подбора правильного языка. Заказчика, скорее всего, не интересуют методы работы с кэшем, он в этом ничего не понимает, ему нужно, чтобы странички сайта грузились быстро → пользователи были довольны → товары продавались.

Кроме того, проблема может возникнуть, если вы будете называть понятные для заказчика вещи новыми, непонятными для него словами. Проблема достаточно частая, я с ней сталкиваюсь, например, в ходе собеседования. Интервьюер говорит какую-нибудь аббревиатуру и спрашивает, работал ли я с ней. Чаще всего, после объяснения термина более привычными словами оказывается, что работал, но называл иначе.

Снятие и фиксация ожиданий

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

Однако не менее важно проговаривать и границы проекта, что именно в рамках проекта или итерации вы не планируете делать.

И уж совершенно точно, очень важно проговаривать ключевые риски, определять стратегии по работе с ними, согласовывать, обработка каких рисков на стороне разработчика, а за какие будет отвечать заказчик.

При обсуждении этих вещей стоит избегать слишком размытых и неформализованных формулировок, вроде «приложение должно быть достаточно быстрым» или «безопасность хранения пользовательских данных для нас наиважнейший приоритет».

Не будет лишним прочесть мою заметку о том, как не превратить сбор требований в соревнование.

Неверные ожидания обязательно нужно корректировать. В разработке клиент прав далеко не всегда.

Ну и документируйте, документируйте, документируйте. Совершенно необязательно в виде трёхсотстраничных ТЗ, можно и в виде каких-то более легковесных вещей, но все ожидания должны быть зафиксированы и утверждены. Более того, управление этой самой документацией — непрерывный процесс, он не заканчивается на этапе планирования, нужно грамотно организовать работу с изменениями.

Работа с ожиданиями команды

Каждый член команды должен чётко понимать, что именно от него требуется. Профессионалы работают вдолгую, нужно не просто сделать проект, выгореть и разбежаться, а выдавать результаты постоянно и предсказуемо.

Ваша задача как пиэма — разъяснить каждому члену команды его границы ответственности. До какой глубины должен детализировать требования аналитик, какие методы тестирования совершенно точно потребуются от QA, должен ли разработчик покрывать код модульными тестами, ну и так далее.

И всегда проговаривайте сроки, помните о SMART.

Если в рамках проекта взаимодействуют несколько отделов, вам поможет матрица взаимных ожиданий.

Прозрачность

Если не рассказывать заказчику о ходе работ, он начинает нервничать. Во времена, когда Jira ещё работала в РФ, мы использовали плагин Big Picture, чтобы сформировать диаграмму Ганта на основании существующих задач и поделиться ссылкой на неё с заказчиком. Таким образом, он постоянно, в режиме реального времени видел прогресс по задачам. Но если таких возможностей нет, можно ограничиться краткими меморандумами, раз в одну или две недели.

Также нужно проводить промежуточные демо, чтобы собрать обратную связь. Такие вещи встроены, к примеру, в сами основы скрама.

Вопросы

Для того, чтобы лучше управлять ожиданиями, пользуйтесь следующими вопросами:

• Чего ожидает заказчик и его бизнес?
• Чего хотят получить пользователи продукта?
• Что ждет заказчик от каждого специалиста и команды в целом?
• Является ли план работ актуальным и верным?
• Вы все еще движетесь к цели или стоит внести корректировки в цель / план?

В целом, это всё, что вам нужно знать об управлении ожиданиями.

Частая проблема — сотрудники отдела убеждены, что коллеги из соседнего отдела не делают то, что от них требуется. Сотрудники соседнего отдела, в свою очередь, понятия не имеют, что от них требуется именно это. Болезнь особенно характерна для крупных компаний. Для диагностики проблемы руководителю (особенно, если они пришёл «снаружи») надлежит составить следующую таблицу:

	Ожидания разработки	Ожидания тестирования	Ожидания внедрения
Обязательства разработки	—	Олли Мяяття: Осси Вяанянен: Лассе Кукконен:	Сами Сало: Теему Селянне: Олли Йокинен:
Обязательства тестирования	Яркко Иммонен: Петри Контиола: Лаури Корпико:	—	Сами Сало: Теему Селянне: Олли Йокинен:
Обязательства внедрения	Яркко Иммонен: Петри Контиола: Лаури Корпико:	Олли Мяяття: Осси Вяанянен: Лассе Кукконен:	—

 
В примере три отдела — разработка, тестирование, внедрение. В каждом работает по три сотрудника:
Разработка: Яркко Иммонен, Петри Контиола, Лаури Корпико.
Тестирование: Олли Мяяття, Осси Вяанянен, Ласси Кукконен.
Внедрение: Сами Сало, Теему Селянне, Олли Йокинен.
 
Таблица расшаривается на всю компанию. Это важный момент — заполнить её должны не только руководители подразделений, но и сотрудники. Каждый сотрудник пишет, что именно он ожидает от других отделов.
 
 
После заполнения может получиться следующее:

	Ожидания разработки	Ожидания тестирования	Ожидания внедрения
Обязательства разработки	—	Олли Мяяття: Основной поток должен работать без ошибок на компьютере разработчика. Осси Вяанянен: Передаваемый код должен быть покрыт модульными тестами. Лассе Кукконен: Передаваемый код должен содержать комментарии.	Сами Сало: Соблюдение сроков разработки, предоставление пояснительной записки. Теему Селянне: Быстрое исправление дефектов, обнаруженных заказчиком. Олли Йокинен: Умение проводить доработки, взаимодействуя с внедренцем напрямую.
Обязательства тестирования	Яркко Иммонен: Своевременное предоставление тестовых планов. Петри Контиола: Участие в выработке варианта реализации. Лаури Корпико: Своевременно давать фидбек по протестированной доработке.	—	Сами Сало: Передавать только доработки, не содержащие дефектов. Теему Селянне: Не затягивать тестирование. Олли Йокинен: Умение быстро выявлять причины дефектов, найденных заказчиком.
Обязательства внедрения	Яркко Иммонен: Предоставление грамотных ТЗ. Петри Контиола: Своевременные ответы на вопросы в процессе разработки. Лаури Корпико: Быстрые темпы приёмки.	Олли Мяяття: Внедренец, обращающийся с возможным дефектом, должен предоставить грамотное описание этого дефекта. Осси Вяанянен: Внедренецы должны принимать участие в регрессионных тестах. Лассе Кукконен: Внедренцы должны обеспечивать обратную связь после передачи протестированной доработки.	—

 
 
Мы выявили ожидания и поняли, что именно отделы ждут друг от друга. Осталось превратить ожидания во внятные обязательства с численными показателями, на основании которых можно считать индекс соответствия ожиданиям для каждого отдела и ставить внятные планы.

Отдел	Обязательство	Показатель	План
Разработка	Основной поток перед сдачей на тест работает на компьютере разработчика без ошибок.	Количество замечаний тестировщика но ошибкам в основном потоке в доработках, сданных на тест. (Фиксируется в задаче на тестирование).	Количество замечаний по ошибкам в основном потоке за месяц/Количество доработок за месяц не более 0,3. Пример: 10 доработок в месяц, 5 ошибок. Факт = 5/10 = 0,5, план не выполнен. 10 доработок в месяц, 2 ошибки. Факт = 2/10 = 0,2, план выполнен.
	Передаваемый код должен быть покрыт модульными тестами.	Процент покрытия процедур модульными тестами. (Фиксируется в задаче на тестирование)	Среднее покрытие процедур модульными тестами не ниже 90 % в месяц.
	Доработки должны сдаваться в срок.	Разница между датой дедлайна и датой передачи доработки заказчику (Фиксируется автоматически по закрытию задачи на сдачу заказчику)	Среднее отклонение фактических дат от плановых не выше корня квадратного от среднего количества плановых дней на доработку. Пример: В среднем, 9 дней на доработку по плану. Среднее отклонение от плана: 2 дня. sqrt(9)=3; 3 меньше 2, план выполнен.
	Дефекты, пришедшие от клиента должны закрываться максимально быстро.	Среднее время закрытия дефекта. (Фиксируется в дефекте)	Среднее время закрытия дефектов с признаком «дефект от клиента» не больше 2 рабочих дней.
Тестирование	Своевременно предоставлять тестовые планы.	При передаче требований в работу, к задаче на разработку должна быть прикреплена ссылка на тестовый план.	Процент покрытия передаваемых доработок тестовыми планами не ниже 95 %
	Передавать внедренцам только доработки, не содержащие дефектов в основных и альтернативных потоках.	Количество дефектов от клиента на протестированные данным тестировщиком доработки.	Отношение количества дефектов от клиента на доработки данного тестировщика к количеству переданных доработок не выше 0,3 Пример: 10 доработок в месяц, 5 ошибок. Факт = 5/10 = 0,5, план не выполнен. 10 доработок в месяц, 2 ошибки. Факт = 2/10 = 0,2, план выполнен.
	Тестирование должно проводиться максимально оперативно.	Среднее отклонение фактических дат от плановых.	Среднее отклонение фактических дат от плановых не выше корня квадратного от среднего количества плановых дней на доработку. Пример: В среднем, 9 дней на тестирование по плану. Среднее отклонение от плана: 2 дня. sqrt(9)=3; 3 меньше 2, план выполнен.
Внедрение	Приёмка должна проводиться максимально быстро.	Среднее количество дней между сдачей заказчику доработки и подтверждением приёмки.	Среднее время приёмки — не более двух недель.
	Внедренец, обращающийся с возможным дефектом, должен представить грамотное описание этого дефекта.	Количество возвратов дефекта тестировщиком внедренцу.	Отношение количества возвращённых на доописание дефектов к общему количеству дефектов от внедренцев не выше 0,3
	Внедренецы должны участвовать в регрессионных тестированиях.	Количество участий данного внедренца в регтестах за квартал.	Среднее количество участий сотрудников отдела внедрения в регтестах не ниже 3 в квартал.

 
 
Как видно из таблицы, директор выбрал ожидания, которые считает важными для бизнеса и превратил в обязательства, исполнение которых можно проверять при помощи рассчитываемых показателей.

Подобный подход способен решить массу внутренних проблем и конфликтов.