Как правильно собирать ТЗ на проект?

Периодически буду делиться здесь контентом, что рассказываю на нашей школе аналитики Changellenge >> Education. Сегодня расскажу про то, как мы советуем собирать ТЗ.

Мы применяем подход Problem Statement Worksheet. Взяли его у McKinsey. Детали метода представлены на картинке к посту. Здесь же хотел отразить 5 интересных аспектов:

Первое. Он изначально кажется сложным и трудным. Но после 5-10 заполнений, ты запоминаешь его наизусть и начинаешь применять почти при любой задаче.

Второе. Подход говорит, что в рамках ТЗ обязательно нужно отразить 7 элементов: 1) простую формулировку задачи по SMART, чтобы было просто запомнить, 2) контекст возникновения проблемы, 3) критерии успеха, 4) что нужно рассмотреть в задаче, 5) какие у нас ограничения, 6) кто стейкхолдеры, 7) где поискать информацию.

Третье. Там нет ни одного лишнего элемента. Например, многие люди опускают седьмой пункт “Где поискать информацию”. И как результат исполнитель делает проект в течение пары месяцев, представляет результат, а заказчик говорит “Блин, ребята, вы мне то же самое рассказываете, что и Паша рассказывал год назад, когда этот анализ делал”. А слабо было сказать, что Паша делал анализ?) Ну ты не спрашивал…

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

Пятое. Этот подход универсален. Он подойдет для стратегического консалтинга, для ИТ проектов, для сбора с женой на отдых. Везде.

Как вам подход? Ставьте реакцию, если его разделяете.

И отправляйте своих сотрудников к нам на обучение на курс Аналитик PRO, где мы разбираем этот подход и еще >100 других.

До конца 29 сентября можно получить отличную скидку по коду НОЧЬ30.