Допустим, вам прислали приглашение на встречу: нашли в календаре незакрашенный квадратик с 13 до 14 и назначили совещание. Во встрече только название: «Статус по проекту» или «Текущие проблемы». Иногда еще и цель: «Обсуждение архитектуры», «Распределение ресурсов», или «Что мы делаем дальше?». Вы лишь предполагаете, зачем вас пригласили на встречу — но ради предположений не стоит собираться.

Теперь вспомните, сколько у вас было таких встреч и сколько из них оказались полезными. Если бы после рабочей встречи проводили опрос, то больше 50% ответили бы, что ожидания от встречи разошлись с реальностью, а ещё 20% признались бы, что не поняли, зачем их вообще позвали. И если начать выяснять детали, в большом проценте случаев выяснится, что встреча была не нужна.

Поэтому всегда нужно начинать с цели.

Откройте любой сайт, и вы увидите одни истории успеха компаний: заказчиков, исполнителей, подрядчиков. В историях успеха иногда встречаются предыстории: как было нелегко, но потом все собрались, преодолели трудности и наступило вселенское счастье. У нас не любят писать, что у компании ничего не получилось — хотя это полезнее сотен успешных успехов. Но я знаю точно: во всех историях про неуспех почти всегда будет одна и та же проблема – неправильная цель и её отсутствие.

Как же перестать ставить неправильные цели? Начать задавать правильные вопросы. Хотя бы три.

Финансовый директор сервисной компании Y решил сделать закупки прозрачными. Для этого решил описать этот процесс и автоматизировать его. Это было похоже на неплохую цель: автоматизация закупочной деятельности. Компания наняла специалистов по описанию процессов и компанию для их автоматизации — но ничего не получилось. Потому что цель была сформулирована неправильно.

Давайте выяснять.

Автоматизация закупочной деятельности. Зачем? Для того, чтобы процесс был прозрачным. Зачем? Чтобы уменьшить время согласования и выполнения закупки, но не пропускать обязательные шаги процесса. Зачем? Чтобы сэкономить время сотрудников, которые пытаются что-то купить. Зачем? Наверное, неправильно, что большой компании на покупку компьютерной мышки нужен месяц внутренних процессов, и пока идут согласования, смысл закупки теряется. Стоп! Так цель в экономии, разработке оптимальной версии процесса или работе над имиджем («нехорошо, когда в большой компании…»)?

Во так, за несколько «Зачем?» удается докопаться до реальной причины. Становится понятно, почему автоматизация не помогла. Идея была хорошей, неверной. Поэтому проект и не решил существующую проблему.

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

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

Определили проблему: несистемное изменение оргструктуры. Цель тоже поставили – сформировать её учёт вплоть до целей и задач сотрудников, автоматизировать процесс согласования. Начали реализовывать проект, но через месяц-два-три чудо не случилось: система вроде была готова, но проблема почему-то не решалась. Стали собираться раз в неделю на совещание и думать, чтобы такое ещё сделать, чтобы получить результат. Через несколько совещаний поняли, что всё три раза перенастроили, а чуда по-прежнему нет. Началась бесконечная работа над процессами, модификацией многострадальной системы и возвращениям к началу — этакий «Замок» Кафки. Получилось ли что-то в итоге, история умалчивает.

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

В проекте Z была ещё одна проблема: его курировал человек, который не понимал ни в HR, ни в ИТ, но очень хотел стать лидером проекта. Вместе с внедрением проекта и изменениями процессов команда обучала человека, которому предстояло принимать все решения. В итоге проект развивался не по сценарию, а в формате «письма Дяди Шарика»: в процессе дописывали не то, что актуально сейчас, а то, что нужно для достижения цели. Проект затянулся.

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

Представьте себе идеальный мир, в котором вам назначили встречу. В календаре не просто тема встречи, а описание: цель, повестка, материалы для ознакомления и ожидаемый результат. Более того, для каждого участника встречи определена роль, личные цель и результат. А потом по результатам встречи кто-то подведет итог и сделает выводы.

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

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

Источник: vc.ru