[Из песочницы] Понятие квалифицированного заказчика в проектном менеджменте
Введение
В процессе работы аналитиком мне неоднократно приходилось разбирать причины неудач в проектах. По мере накопления опыта у меня выработалась определенная методика работы с заказчиками, которой хотел бы поделиться.
Думаю, что не мне одному приходилось сталкиваться с расплывчатыми требованиями к продукту, проекту или сервису. Часто заказчик оказывается «очень занятым», «недоступным для детального обсуждения» и т.д. Со временем у меня выработался критерий деления заказчиков на «квалифицированных» и «неквалифицированных», и, благодаря описанной ниже методике, каждый из вас сможет достаточно быстро провести аудит имеющихся задач (как полученных, так и поставленных кому-то)
«Неквалифицированный» в этом контексте не несет негативной окраски. Значение этого термина используется для описания недостаточности опыта для выполнения функции заказчика. Безусловно, исполнители тоже бывают неквалифицированными. Но в этой статье проблема исполнителя рассматриваться не будет.
Ниже будет описан метод, позволяющий заказчику формулировать квалифицированный заказ. Надеюсь, метод позволит уменьшить те ситуации, когда на «демо» выкатывается «совершенно не то что хотелось».
Немного теории
Как, в принципе, устроена кооперация в процессе решения проблем?
- Есть заказчик, который испытывает затруднения в своей деятельности — не может самостоятельно получить нужный результат.
- Этот заказчик формулирует проблему и ищет исполнителя, способного решить проблему.
- Чтобы исполнитель выдал правильный результат, стороны договариваются о критериях приемки результата заказчиком.
- И заказчик, и исполнитель при этом доложены быть квалифицированным, т.е. первый — способным сформулировать критерии приемки результата, второй — обеспечить результат, соответствующий критериям.
Если хотя бы одно из условий не соблюдается, то проблема не будет решена.
Применяем теорию на практике
Как правило, эта модель работает, и не вызывает затруднений, на бытовом уровне (починить текущий кран или заменить масло в двигателе), а также в тех специальностях, где производится реальный продукт или услуга (результат работы инженера или аналитика).
Представим кейс — один разработчик делает базу данных и ему нужен frontend для визуализации. Сам он делать не умеет и ищет исполнителя (сервис) который решит его проблему. При постановке задачи для сервиса заказчик (держатель базы) описывает проблему (он не может визуализировать информацию, хранящуюся в БД), публикует интерфейс, и определяет критерии приемки (функциональные, стоимостные, технологические).
Если в заказе отсутствует хотя бы один из этих трех пунктов, то можно предполагать, что заказчик сам до конца не понимает, что хочет получить от исполнителя. Такой заказ- неквалифицированный, и исполнителю за такую задачу браться не следует, т.к. велик риск «не угадать».
Аналогичный подход действует и у аналитиков. Аналитик, выступая сервисом, встречается с заказчиком, идентифицирует проблему, получает интерфейс, к которому должно «прицепиться» проектируемое решение и фиксирует критерии приемки. Если заказчик говорит «вы же умные придумайте что-нибудь», аналитик как правило, считает, что за такую задачу лучше не браться, т.к. заказчик «неквалифицированный» и будут проблемы при приемке-сдаче результатов.
Применяем теорию на практике -2
Разработчики и аналитики давно научились фиксировать требования к заказам, используя ТЗ, спецификации…, но если мы переходим на уровень менеджмента, то обнаруживаем что все меняется. Вчерашний инженер, четко формулировавший заказ другому инженеру, при переходе в категорию менеджеров начинает формулировать задачи очень расплывчато.
Примеры неквалифицированных заказов сто стороны менеджеров мне приходится встречать почти каждый день. Вот типичные образцы:
- «У нас есть проблема с количеством багов в релизе. Надо тестировать тщательнее и прорабатывать все возможные варианты работы пользователя».
- «Для повышения прозрачности процессов мы будем использовать KPI. Руководителю каждой группы необходимо написать приложения, по каким показателям оценивать результаты работы из группы»
- «Для того чтобы выбрать, какой из двух конкурирующих продуктов развивать дальше, надо назначить продукт-оунера, который проанализирует рынок и напишет предложения на основании которых можно будет сделать выбор»
Знакомо?
Как думаешь, читатель, насколько успешным будет выполнение каждой из перечисленных задач? Когда я работал аналитиком, мне никогда не удавалось выполнить такие поручения ни с первого ни со второго раза.
Со временем я сам дорос до руководителя, и на собственной практике неоднократно убедился, что правильная, квалифицированная формулировка заказа (или задания) многократно повышает вероятность решения проблемы в первой итерации.
Как нам получить квалифицированного заказчика-менеджера? Что он должен научиться делать и какой методике следовать, чтобы получать именно то что он хочет? По аналогии с методом инженеров, менеджер при формулировке заказа, менеджер должен определиться по трем пунктам:
- Формулировка проблемы. Определяем суть затруднения и описываем его в 1–2 предложениях (для начала).
- Критерии приемки. Каждый критерий представляет собой ответ на вопрос: «Как мы поймем, что решили эту проблему? Что должно появиться (или исчезнуть в результате решения проблемы?» Ответы на этот вопрос даст и заказчику, и исполнителю четкое представление как на финише будет оцениваться результат. Формулировки этих ответов позволяют так же определить MVP решения, если мы расставим приоритеты для полученного списка.
- По аналогии с интерфейсами, которые обсуждают инженеры, следует определить зависимые области. Все области, которые взаимосвязаны с решением проблемы, должны быть проинформированы об изменениях, и, возможно сами претерпеть изменения.
Если хотя бы на один вопрос нет четкого ответа, то заказ исполнителю будет неквалифицированным, и браться за него не стоит.
Возьмем для примера один из вышеприведенных кейсов и начнем его разбирать по предлагаемой схеме. Вот типичная проблема менеджера: В компании существует две конкурирующие разработки; надо принять решение — какую из них выбрать?
Неквалифицированный заказчик — менеджер:
Для выбора конкурирующих разработок приглашает product owner и ставит ему задачу «разработать продуктовую стратегию и предоставить информацию для выбора продукта». И срок дает — первый замер — через месяц.
Как правило через месяц самое лучшее что можно увидеть — это несколько слайдов в PP с общими фразами. Обычно это «не то что хотелось». И дальше запускается цикл перебора вариантов в поисках решения для несформулированного заказа. Исполнитель загружен и претензий к качеству работы нет. Но и удовлетворения от результата нет тоже. Постепенно идея вырождается в бесконечные обсуждения.
Как действует квалифицированный заказчик?
Менеджер выдает заказ по «инженерному» формату.
формулировка проблемы: не можем принять решение, какой продукт развивать (или может быть — оба?)
Критерии приемки: как мы поймем, что решили проблему? Что должно появиться для принятия решения? (в качестве примера):
- Появится оценка степени готовности к промышленной эксплуатации (высокий приоритет);
- Решение должно соответствовать существенным функциональным требованиям заказчиков;
- Перспективность и современность стека используемых технологий. И т.д. Такой список может быть длинным, но, чем точнее мы сформулируем критерии, тем проще будет принято решение; самое важное что решение будет обоснованным.
Формулируем зависимые задачи, которые изменятся вследствие принятого решения
- Продуктовая концепция: как она изменится?
- Экономическая модель: как повлияет решение на модель монетизации?
- Производственная составляющая: как изменится стек технологий после принятия решения?
- Обеспеченность кадрами — сможем ли развивать продукт при текущей квалификации персонала?
Итог
Менеджер, являясь квалифицированным заказчиком, формулирует заказ (задачу) исполнителю следующим образом:
- Определяет проблему (формулирует задачу, решение которой пока не известно)
- Определяет критерии приемки результатов (описывает условия, при которых проблема является решенной)
- Определяет зависимые задачи, которые исполнитель должен учитывать при решении проблемы.
Если эта тема окажется интересной, следующая статья будет посвящена «неквалифицированному» исполнителю.
