Цели и результат. Как довести проект до проверяемого итога

Однажды я попросил трёх человек из одной команды ответить на простой вопрос: «Зачем мы делаем этот проект?» Один сказал, что мы запускаем новый личный кабинет. Второй — что мы повышаем удобство для клиентов. Третий — что начальник так велел в марте. Все трое работали над одним и тем же проектом полгода. И все трое были по-своему правы. Беда в том, что ни один из этих ответов нельзя было проверить.

Это и есть главная болезнь проектов: цель вроде бы есть, она звучит красиво, её даже записали в презентации, но в момент сдачи никто не может уверенно сказать, достигли её или нет. Заказчик недоволен, команда обижена, руководитель проекта оправдывается. Все работали честно. Результата нет.

Эта книга про одну управленческую компетенцию, которую я называю «Цели и результат». Звучит академично, но за этими двумя словами стоит очень практичный навык: умение превратить размытое «хотим, чтобы стало лучше» в конкретное «вот это мы считаем успехом, и вот так мы это проверим». Если вы умеете это делать, проект перестаёт быть лотереей. Если не умеете — даже самая сильная команда будет ходить кругами.

Почему «лучше» — это не цель

Давайте честно. Большинство проектов начинается не с цели, а с раздражения. Кого-то что-то достало. Клиенты жалуются — значит, надо «улучшить сервис». Продажи просели — «надо переделать сайт». Конкурент выпустил приложение — «нам тоже нужно приложение». Это нормально, так устроена жизнь в компаниях. Проблема не в том, что проект рождается из боли. Проблема в том, что боль так и остаётся единственным описанием цели.

«Улучшить сервис» — это направление, а не цель. У направления нет финиша. Вы можете улучшать сервис вечно, тратить бюджет, нанимать людей, и каждый раз кто-то скажет, что можно ещё лучше. Цель отличается от направления одним свойством: у цели есть состояние «достигнуто». Вы можете встать в определённый день и сказать: да, мы дошли. Или: нет, не дошли, не хватило вот этого.

Я предлагаю простой тест, который называю проверкой на финиш. Возьмите формулировку вашей цели и спросите: «Как именно мы поймём, что цель достигнута?» Если в ответ звучит ещё одно общее слово — «когда станет удобнее», «когда клиенты будут довольны», — у вас пока нет цели. У вас есть пожелание. Цель появляется тогда, когда на вопрос «как поймём» вы отвечаете чем-то, что можно увидеть, посчитать или показать.

Проверяемость — это уважение к людям

Может показаться, что вся эта строгость нужна ради отчётности. Что проверяемая цель — это для того, чтобы прикрыть себя перед руководством. Отчасти так, и я не буду делать вид, что это не важно. Но настоящая причина глубже.

Когда цель нельзя проверить, страдают люди. Команда не понимает, ради чего перерабатывает. Тестировщик не знает, что считать ошибкой, а что — нормой. Дизайнер переделывает экран в десятый раз, потому что «всё ещё не то», а что «то» — никто не сформулировал. Заказчик в финале испытывает смутное недовольство и не может объяснить, чего же ему не хватило. Все вымотаны, и все винят друг друга.

Проверяемая цель — это акт уважения. Вы как руководитель проекта берёте на себя труд договориться заранее: вот что мы считаем результатом, вот по каким признакам поймём, что дошли. Теперь у каждого есть опора. Команда знает, к чему идёт. Заказчик знает, что получит. Вы знаете, когда можно остановиться и сказать «сделано». Без этого договора любой проект превращается в бесконечное угадывание чужих мыслей.

Цель, которую можно проверить, экономит больше всего

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

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

О чём эта книга и как ею пользоваться

Я построил книгу так, как сам учился этой профессии — от понимания к практике и обратно к проверке себя.

Сначала мы разберём саму компетенцию: что такое цель, чем она отличается от результата и от пользы, как связать проект с бизнес-задачей, что такое критерии успеха и где проходят границы вашей ответственности. Это фундамент, без него остальное повиснет в воздухе.

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

Дальше идут инструменты. Это рабочие заготовки, которые можно взять и применить завтра: карта цели, формула результата, дерево пользы, списки вопросов к заказчику и к команде, протокол фиксации цели и приёмы регулярной сверки. Я старался описать их так, чтобы вы могли пользоваться ими без меня.

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

Читать можно подряд, а можно с любого места. Если у вас прямо сейчас горит проект с размытым запросом — открывайте дневник, там есть похожий эпизод. Если нужно срочно сформулировать критерии успеха — листайте к инструментам. Но я бы советовал хотя бы раз пройти всё по порядку. Компетенция «Цели и результат» — это не набор фокусов, а способ мышления, и он собирается из всех частей разом.

И последнее во введении. Руководитель проекта — это не тот, кто рисует диаграммы и собирает статусы. Это человек, который отвечает за то, чтобы проект привёл к проверяемому результату. Не к занятости команды. Не к красивому отчёту. К результату, на который можно показать пальцем и сказать: вот ради этого мы работали, и вот мы это получили. Вся книга — про то, как стать таким человеком.

Прежде чем разбирать инструменты и ситуации, договоримся о словах. В управлении проектами половина споров возникает не потому, что люди не согласны по существу, а потому, что вкладывают разный смысл в одни и те же термины. Один говорит «результат» и имеет в виду готовый продукт. Другой слышит «результат» и думает про деньги, которые продукт принесёт. Третий — про то, что наконец-то можно закрыть проект и выдохнуть. Поэтому начнём с простых определений.

Простое определение

Компетенция «Цели и результат» — это умение руководителя проекта договориться о проверяемом результате, удержать его в фокусе всей команды на протяжении проекта и довести проект именно до этого результата, а не до чего-то похожего.

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

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

Цель, результат, польза — три разные вещи

Это, пожалуй, самое важное различие во всей книге. Цель, результат и польза — не синонимы, и путать их дорого.

Результат — это то, что физически появляется в мире благодаря проекту. Новый раздел на сайте. Обученные сотрудники. Запущенная производственная линия. Подписанный регламент. Результат можно потрогать, увидеть, открыть. Он либо есть, либо его нет.

Польза — это то, что результат меняет в жизни заказчика или клиентов. Раздел на сайте появился — и клиенты стали находить нужное быстрее. Сотрудников обучили — и количество ошибок снизилось. Линию запустили — и себестоимость упала. Польза не равна результату. Можно сделать прекрасный результат, который не приносит никакой пользы. И, к сожалению, такое случается чаще, чем хотелось бы.

Цель — это связка между результатом и пользой, выраженная так, что её можно проверить. Хорошая цель звучит примерно так: «Сделать вот такой результат, чтобы получить вот такую пользу, и мы поймём, что дошли, по таким-то признакам». В этой формуле есть всё: что делаем, ради чего и как проверяем.

Приведу живой пример. Заказчик говорит: «Хочу мобильное приложение». Мобильное приложение — это результат. Само по себе оно никому не нужно. Начинаем копать: зачем приложение? Чтобы клиенты заказывали повторно, не звоня в колл-центр. Вот она, польза: снижение нагрузки на колл-центр и рост повторных заказов. Теперь формулируем цель: «Запустить приложение, через которое клиенты смогут оформить повторный заказ за минуту без звонка, чтобы за полгода доля повторных заказов через приложение достигла трети от всех повторных». Это уже цель. Её можно проверить.

Связь с бизнес-задачей

Любой проект в компании существует не сам по себе. Он чему-то служит. Где-то наверху есть человек, который решил выделить на проект деньги и людей, потому что рассчитывает на отдачу. Эта отдача и есть бизнес-задача.

Руководитель проекта обязан понимать, какую бизнес-задачу решает его проект, даже если ему её прямо не назвали. Это не любопытство и не желание залезть не в своё дело. Это страховка. Когда вы знаете бизнес-задачу, вы можете принимать сотни мелких решений по ходу проекта правильно. Какую функцию делать первой? Ту, что ближе к бизнес-задаче. Чем пожертвовать при нехватке времени? Тем, что дальше от неё. Какой спор с заказчиком стоит того, чтобы в него вступить? Тот, где на кону бизнес-задача.

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

Критерии успеха

Критерии успеха — это конкретные признаки, по которым в финале мы определим, удался проект или нет. Они отвечают на тот самый вопрос из введения: «Как мы поймём, что дошли?»

Хороший критерий обладает четырьмя свойствами. Он проверяем — то есть его можно подтвердить чем-то осязаемым, а не ощущением. Он согласован — заказчик и команда заранее признали его справедливым. Он определён во времени — понятно, на какой момент мы его меряем. И он находится в зоне влияния проекта — мы можем на него реально повлиять своими действиями, а не зависим целиком от факторов вне проекта.

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

Я различаю критерии результата и критерии пользы. Критерий результата — проект что-то создал и оно работает как договорились. Критерий пользы — это что-то изменило нужную метрику. Идеально иметь и те, и другие. Но критерии результата вы можете проверить сразу в финале проекта, а критерии пользы — только спустя время, когда результатом начнут пользоваться. Это важно проговорить с заказчиком заранее, иначе в день сдачи он спросит про пользу, которая ещё физически не успела проявиться.

Границы ответственности

Это болезненная тема, и я подойду к ней прямо. Руководитель проекта отвечает за результат, но не за всё на свете. И умение провести границу — часть компетенции.

За что вы отвечаете точно: за то, что результат создан, проверен и соответствует согласованной цели. За то, что критерии успеха были сформулированы и зафиксированы до начала работы. За то, что заказчик в любой момент понимал, к чему идёт проект, и не получил сюрприза в финале. За то, что команда знала цель и работала на неё.

За что вы не отвечаете: за решения, которые принял заказчик вопреки вашему предупреждению. За изменения рынка, которые произошли уже после сдачи. За то, что бизнес-задача оказалась изначально неверной, если вы добросовестно сделали то, о чём договорились. Но — и это важно — вы отвечаете за то, чтобы вовремя и внятно предупредить о рисках. Молчаливое выполнение заведомо проигрышного плана — это не «я сделал что просили», это профессиональная ошибка.