Как выстраивать доверительные отношения с заказчиком, получать и передавать информацию?
Всем привет! Сегодня принесла тему, от которой у большинства моих коллег немедленно скукоживается лицо, им хочется втянуть голову в плечи, стать черепахой в своем панцире и никогда не вылезать наружу (видели мы эту наружу, не нужна она нам). Коммуникация с заказчиком, действительно, может сводить с ума (причем вы в любой момент времени можете оказаться на стороне заказчика, и почувствовать, что это вас сводят с ума талантливые исполнители). В статье сегодня рекомендации по выстраиванию доверительных отношений с заказчиком для стороны исполнителя, но иногда я буду делать акценты на том, что если исполнитель какие-то пункты пропускает, заказчик вполне может самостоятельно инициировать решение этой проблемы (потому что что? Правильно, потому что доверительные отношения — это когда виноваты обои, обои сворачивайтесь, мы уходим).
Разбирать сегодня какие-то шаги и рекомендации буду на примерах, спонсором примеров является мой опыт и опыт коллег и друзей, поэтому если у вас вдруг есть тоже такие истории — пишите, делитесь, важно понимать, что вы не одиноки.
Итак, что такое общение с заказчиком, какие методы / инструменты нам помогут это общение сделать эффективным и доверительным, почему вообще важно выстраивать именно доверительные отношения. Пишем!
Эффективность доверительных отношений
Ни один проект не может быть инициирован или запущен без заказчика. В ролевой модели проектного управления заказчик отвечает за выражение потребности в конечном результате проекта (помогает определить требования к результату), он принимает результат проекта, признавая его годным или не годным, оценивает промежуточные результаты, вносит корректировки.
Как создать доверие с заказчиком? Необходимо, что вы придерживались в коммуникации принципов открытости, прозрачности и честности. То есть не скрывали важную информацию, предоставляли достаточно данных в понятном и доступном виде для самостоятельного принятия решения заказчиком и не врали. Я про откровенную ложь и такую, знаете, полуправду, когда вы делаете предположение об уровне осведомленности заказчика в теме и даете ему информацию заведомо неверную, но которая выгодна вам.
Что помогает в выстраивании отношений на таких принципах? Регулярное взаимодействие в удобных каналах коммуникации (лично или онлайн, видео или текст), навыки активного слушания и диалога (слушаю, спрашиваю, даю ответ на вопрос, не раздаю непрошенных советов, но подаю информацию нейтрально окрашенных тонов).
И тут есть несколько направлений именно внутри этих регулярных взаимодействий. То есть, я могу взаимодействовать, чтобы:
- понимать и уточнять требования заказчика, собирать обратную связь
- управлять ожиданиями заказчика по ходу выполнения проекта
- решать конфликты
Это прям три таких основных направления коммуникации. Давайте про каждое поговорим подробнее, как внутри этих направлений выстраивать доверие, соблюдая принципы открытости, честности и прозрачности.
Понимание и уточнение требований заказчика
В статье про требования и работу с ними, я подробно описывала, в чем заключается роль менеджера проекта, на каких этапах проекта какие решения он может принимать и кого привлекать на помощь. Здесь же сделаем акцент на инструменты для понимания и уточнения требований заказчика:
- собеседования и опросы — это могут быть как интервью один-на-один, так и опросы фокус-групп со стороны заказчика;
- письменная документация — подробное фиксирование всех требований, например, в виде user story / use case, блок-схем, может быть в виде различной глубины прототипов.
Делали ПО на основе имеющегося продукта, то есть дорабатывали существующий продукт под требования и контекст заказчика. Провели несколько встреч с топ-менеджментом, отвечающим за внедрение ПО, согласовали потребности (что должна уметь делать кастомизированная версия), зафиксировали в документации, как в технической, так и в проектной. Решили начать с грубого (буквально из скриншотов и схем) визуального прототипа, и я на утверждение этого прототипа позвала тех специалистов, кто непосредственно будет работать на местах с этим ПО. Прототип был не принят, потому что исполнители на местах задавали вопросы, как им в таком случае делать привычные, допустим, отчеты, и выводить на печать какие-то части отображаемой на экране информации. В требованиях и пожеланиях об этих отчетах и печати ни слова от топ-менеджеров зафиксировано не было.
То есть при выявлении требований заказчика я допустила ошибку: собеседования и опросы провела не с полными фокус-группами, куда бы входили и топ-менеджеры, и исполнители, из-за чего в документацию не попала важная часть ожидаемого функционала. Где здесь наши принципы? Я честно признала, что ошиблась (я могу ошибиться!), прозрачный процесс приемки прототипа показал заказчику, что более полные опросы и собеседования дадут больше информации (то есть они откроют нам свои процессы и мы, как разработчики, лучше будем понимать, в чем глубинные потребности и задачи проекта).
Если вам, как заказчику кажется, что ваши требования собрали не со всей тщательностью голодного медведя у куста малины, то инициируйте новую встречу для того, чтобы убедиться, что вас правильно поняли, попросите визуальные прототипы схематичные для сверки понимания, попросите поговорить еще с кем-то из конечных пользователей результата проекта, они могут случайно поделиться полезной информацией с исполнителем. Проверять, что тебя правильно поняли — нормально.
Управление ожиданиями
Как управлять ожиданиями заказчика? Начнем с определения, что такое вообще это ваше управление ожиданиями. Мем про ожидание и реальность помним? Вот управление ожиданиями — это несмешной мем, когда ожидание и реальность совпадают, причем у всех сторон (помним про обои!). Когда речь идет про управление проектами, у нас есть четыре глобальных ожидания от проекта:
- ожидания по срокам — за какой период времени этот проект может быть реализован в том виде, в каком мы его представляем;
- ожидания по бюджету — за какую сумму денег и иных ресурсов этот проект может быть реализован в том виде, в котором мы его представляем, и за время, которое мы закладываем;
- ожидания по целям и задачам (скоупу, функционалу) — вид конечного результата, который мы можем получить выполнив работы за указанные бюджет и сроки;
- ожидания по качеству — качество конечного результата, а еще качество самих работ, услуг, работников, которые мы ожидаем получить за указанные бюджет и сроки.
Управление ожиданиями начинается на этапе выявления требований к будущему результату проекта. Вы, как исполнитель, собираете все необходимые и достаточные требования заказчика, чтобы обрисовать функционал / описание конечного результата. В статье про требования я также писала про сбор бизнес-правил и бизнес-требований, и вот они помогают задавать контекст для этих ожиданий от результата.
При запуске нового проекта по разработке веб-сайта мы согласовываем с заказчиком его бизнес-требования:
1) Основной функционал сайта должен быть готов к 1 сентября, там конференция, на которой будут раздавать визитки со ссылкой на сайт.2) Работы должны выполняться только нами, без субподрядчиков и фрилансеров, служба безопасности не хочет проверять дополнительно еще исполнителей.3) Продажи через сайт должны быть не менее 30% от общего числа продаж в течение первых шести месяцев после запуска (иначе не выгодно заказчику вкладываться в сайт).
Эти требования не относятся к функциональным или нефункциональным, пользовательским. Это требования бизнеса, ожидания от результата проекта. Что мы делаем дальше, чтобы коммуницировать открыто, честно и прозрачно?
Уточняем функционал этого сайта, чтобы оценить реалистичность ожиданий, уточняем свои ресурсы и возможности, передаем информацию заказчику:
- сделать сайт с указанным функционалом успеваем к 1 сентября только если привлечем субподрядчика на дизайн (сейчас загрузка такая, что наш дизайн не справится), второй вариант — снять нашего дизайнера с текущего проекта и передать на субподряд, но надо согласовывать это с другим заказчиком и / или с дизайнером, но это время и тогда успеть сложнее
- стоить будет разработка столько, дизайн столько, консультации и сопровождение столько, сроки по каждому типу работ вот такие, вот такие запасы по срокам есть на форс-мажоры
- мы, как разработчик сайта, не можем повлиять на объем продаж на сайте, если только а) не сделаем настройки оптимальной поисковой выдачи на моменте разработки, и б) не предоставим контакты хороших интернет-маркетологов для настройки рекламы, метрик и прочих штук для оптимизации продаж
Заказчик может согласиться или не согласиться менять свои ожидания от нас, как исполнителя, и от сайта, как от результата, но мы честно предупредили о том, как обстоят дела, открыто поделились информацией по маркетингу и предоставили прозрачную смету из видов работ и их стоимости.
Мы могли, разумеется, поступить иначе (сейчас вредные советы будут!): не говорить про субподряд, взять на время нового дизайнера в штат на этот проект, увеличить стоимость дизайна в смете, заложив в сумму увеличения неустойку по перебрасыванию дизайнера с одного проекта на другой, мы могли сказать, что с таким сайтом продажи за три месяца отобьют стоимость (потому что никакой ответственности мы не несем за такие заявления, но это формирует ложное ожидание).
Если бы мы так поступили, заслужили бы мы доверие заказчика? Нет.
Как мы в процессе реализации управляем ожиданиями? Очень просто:
- регулярные отчеты о том, что план был такой, вот такой факт, вот такие отклонения по срокам, бюджету, функционалу, качеству по таким вот причинам
- своевременное информирование о проблемах и рисках (о проблемах, как только случилась, с вариантами решений или просьбой о помощи, а о рисках — до наступления самого риска)
- сбор обратной связи — спрашивать заказчика, что он думает о промежуточном результате, какие у него ощущения по срокам, деньгам, качеству от уже готового и от того, что нужно доделать, собирать обратную связь так же тщательно, как собирали исходные требования, презентовать результаты и вносить правки по итогам обратной связи, а не игнорировать их
- информационное (рабочее) пространство — организовать удобное заказчику и вам единое место, где лежат документы, отчеты, ТЗ, презентации, записи видеозвонков, вы можете также предоставить доступ к рабочему пространству (например, добавить менеджера со стороны заказчика на доску проекта, чтобы видел текущий статус в живом времени)
- заранее обговоренные каналы коммуникации — вся информация предоставляется только в них и только в тех видах, о которых договорились (лично или онлайн, текстом или картинками, голосовыми сообщениями), про коммуникационный план писала здесь
Если вы, как заказчик, считаете, что вашими ожиданиями не управляют, что вы можете бесконтрольно фантазировать о том, как сайт будет зеркальным и отражать лицо любого смотрящего в него, то вы можете инициировать встречу, чтобы обсудить, как часто и в каком виде вам предоставляют информацию, какую, о чем. В конце концов вы можете просто сверить ожидания и по срокам, и по бюджету, и по качеству. Это нормально, если все в рамках взаимных договоренностей и этики.
Решение конфликтов
Конфликты с заказчиком — штука крайне неприятная, потому что высасывает все добро в тебе, как Дементор. Ты, как исполнитель, хочешь и команду свою защитить, и компанию, и проект. Заказчик хочет сделать все ровно то же самое, поэтому это всегда очень агрессивная защита с нападением у обоих сторон конфликта.
Заказчик заказал разработку сложного ПО. В процессе работы заказчик неоднократно изменял требования и добавлял новые функции, что приводило к увеличению объема работ и сроков. Несмотря на все усилия команды разработчиков, проект начал задерживаться, и заказчик стал высказывать недовольство, требуя завершения проекта в первоначально оговоренные сроки и без увеличения бюджета.
и
Заказчик заказал разработку сложного ПО. Однако в процессе работы выяснилось, что команда разработчиков недооценила сложность проекта, и разработка стала задерживаться. Были допущены ошибки в коде, что привело к низкому качеству промежуточных версий продукта. Заказчик выразил недовольство и пригрозил разрывом контракта и поиском другой компании для завершения проекта.
Это два разных конфликта, которые все равно придется решать одинаково:
- открыто и честно признать проблему (обеим сторонам нужно признать, что у них на пути проблема, не отмахиваться, что это проблема заказчика / исполнителя, пока это ваш общий проект — это ваша общая проблема)
- проанализировать и выявить причины проблемы (не искать виноватых, мол, Олег опять не так сказал, и Вася опять не так понял, а провести прозрачное расследование с конкретными фактами, какая информация в каком виде кем была получена и как интерпретирована и использована дальше)
- исправить ошибки и найти решение (работа над ошибками тоже общая, вы вместе делаете план по решению, вместе ищете способы, может быть, вы пересмотрите итоговые сроки, может быть, вы измените бюджет, может быть, вы разорвете отношения, потому что никто не захочет идти на уступки)
- реализовать и проконтролировать исполнение решения (тут тоже вместе нужно работать, ничего не поделаешь)
По моему скромному опыту и опыту моих коллег, друзей, — все конфликты являются результатом либо неверно собранных требований, либо отсутствия управления ожиданиями (вариант, когда это именно коммуникационный человеческий фактор тоже есть, но мы тут немножко в мире пони и притворяемся, что люди не ведут себя как придурки, не хамят, не грубят, не обесценивают работу и все вот это вот).
Рабочий конфликт (не личностный) всегда строится вокруг работы (ее результата, требований к результату или ожиданий от результата), не рабочий конфликт — всегда про эмоции и конкретного человека, который бесит. Иногда этот человек — ты сам, и это тоже нормально, но не давать этому мешать работе — твоя зона ответственности.
В общем, что это я? А, да. Доверительные отношения с заказчиком — залог успешного проекта. Будьте открытыми, честными, ведите свои дела прозрачно, коммуницируйте эффективно, управляйте ожиданиями и нормально выявляйте требования. И не будьте придурками!
С вами была ProjectPixie, залетайте на огонек, делитесь своими историями про заказчиков и исполнителей: