Менеджер не должен уметь писать ТЗ для программиста… оперируя терминами программиста. Не путай разные понятия: ТЗ для программиста от старшего программиста и ТЗ для программиста от менеджера проектов.

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

И тут я подхожу к главной проблеме статьи: прикладные скилы — это важно. Но для менеджера проектов уметь писать ТЗ — это не прикладной скил. Это хард скилл.

Поясню на примере. Свадебный фотограф дает объявление на сайт. Молодожены откликаются на его объявление, и начинается этап согласования свадебного проекта.

И вот тут может начаться путаница. Фотограф может требовать от молодоженов сформулировать идею съемки на его языке, используя проф.термины — фокусное расстояние, боке, низкий/высокий ключ. И тогда начнется череда разбирательств и недовольства с обоих сторон.

Всего этого можно и нужно было избежать, будь у фотографа больше опыта и, соответственно, прокаченный хард скилл общения с клиентом.

Фотограф должен показать свое портфолио, объяснить на примерах, что он может предложить на выбор, а не требовать объяснить на его языке людям, которые в общем-то не должны ничего объяснять ему.

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

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

Поясню на примере задачи для сеошника. Суть в общем одна, будь то сеошник, интернет-маркетолог или программист.

Мне прилетает задача такого содержания: нужно понять, запускают ли конкуренты рекламные кампании и если да, то по каким группам товаров.

Для меня это неопределенная и неясная задача без объективного вывода, поэтому этот вывод я должен придумать себе сам. Оно мне надо?

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

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

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

А во-вторых, четкое ТЗ сокращает срок выполнения задачи и возможность планировать эти сроки.

Дак вот, вернемся к нашему ТЗ: …запускают ли рекламные кампании… Я думаю, что менеджер знает, что такое «рекламная кампания», но, скорее всего, его определение отличается от моего.

Он этого не знает, а я знаю.

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

Пы.Сы. если он разбирается, то стал бы писать ТЗ по-другому, я уверен.

Я хочу получить от менеджера понятную ему формулировку своей задача. Почему понятную ему? Он что, дурак? Скорее всего, нет. Но если менеджер сам будет понимать, что он хочет от меня, то он сможет ответить мне на дополнительные вопросы по задаче, которые мне, как исполнителю, остались непонятны.

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

Вот такой парадокс из жизненного опыта.

Менеджеру нужно объяснить то, что он хочет от задачи своими словами — например, хочу знать, где конкурент рекламирует наш товар. Вот так просто и понятно. Найди мне тех, кто рекламирует наш товар в Яндексе и Гугле.

Я уточню — а где именно: вы имеете ввиду рекламные объявления, которые стоят первыми позициями в поиске или то, что ниже?

И уверен, что получу такой же адекватный ответ.

После чего наш диалог может продолжиться по следующему сценарию.

Я уже отложил в голове, что мне нужно получить в терминах моей области: взять объявления из контекстной рекламы в Яндексе и, возможно, Гугле (в данном случае) и количество посетителей. Как я найду количество посетителей? Сниму стату по найденным фразам, Яндекс по крайней мере дает неплохой прогноз по показам, кликам и трафику в допустимыхъ приеделах с некоторой погрешностью.

Для себя я пишу следующее ТЗ:

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

Мне достаточно получить примерную, но однозначную интерпретацию того, что хочет менеджер на выходе своими словами.

Если я не вступлю в этот диалог с ним, то выполню задачу как сам додумаю ее, а менеджер получит что-то невнятное. Чем будет вызван негатив, зря потраченное время и бесконечные переделки.

Но мы все равно придем к тому, что я буду просить описание задачи своими словами и плюс уточняющие вопросы.

Уточняющие вопросы по ТЗ — это нормально, это не ТЗ плохое, это для полного понимания задачи.

Но есть еще вариант, он самый крутой и очень редкий.

Вариант, когда хард скил постановки ТЗ у менеджера прокачан очень мощно.

Тогда я получаю мега-крутое ТЗ сразу.

И тут я понимаю, что мне нужно проделать горы работы, но зато я знаю зачем я это делаю — у меня есть четкое ТЗ. И там все написано — выяснить рекламные каналы конкурентов.

Скорее всего, я буду рассматривать контекстную рекламу.

В этом случае, и только в этом случае, мы сможем сократить время разбирательств по ТЗ, собственно, на это самое время разбирательств. Без нервов. Без воды. Без смс. И, что самое главное, без регистрации.