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

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

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

Содержание статьи — классика проектного управления. Я бы сказал «баян», но, к сожалению и счастью, 80% менеджеров проектов с рынка труда найдут ее полезной. К сожалению, потому что таков их уровень. К счастью, потому что они, при этом, чему-то научатся. К сожалению, нашему рынку нужны вот такие «школьные» статьи — ведь профессионального обучения пока всерьез нет. К счастью, появились люди, готовые учить и рассказывать азбуку. Ведь с нее надо начинать. Это было А, у Тачата на РИКе есть и Б. И это к счастью.

Умение задавать вопросы — не самое главное для менеджера. Главное для менеджера — умение задавать уместные вопросы и адресовать их правильным людям. Показаться клиенту шибко умным — это стратегия, работающая в 10-15% случаев. В остальное время луше показаться им хитрожадным или самодовольным дебилом. Тогда они начнут с тобой работать.

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

На сайте CMS Magazine скорее имеет смысл поговорить о вопросе с точки зрения исполнителя (агентство / продакшн), где аккаунт-отделу приходится сталкиваться с разными барьерами.

В свое время я разработал простенькую универсальную блок-схему для аккаунт-отдела, глядя на которую можно быстро классифицировать задачу (от клиента, который априори интересен компании) и принять какое-то решение с минимальным набором вопросов:

Если пошагово описывать процесс классификации задачи и запуска ее в работу, то требуется понять:

1. Относится ли задача к какому-то существующему проекту или это совершенно новая задача?
2. Будет ли компания работать над этой задачей:
   • Что нужно сделать?
   • В рамках ли ее компетенций?
   • Прибыльно ли?
   • Интересно ли это для компании?
   • Хватит ли ресурсов?

Если все ок, то нужно создать:

1. Коммерческое предложение
2. Первичную проектную документацию (кост, тайминг)
3. Юридическую документацию (договор, приложение)

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

К этим базовым и безусловно важным вопросам, я бы добавил вопрос совместимости будущей команды проекта. Если команда уже работала вместе, то в новом проекте вероятность положительного исхода сильно возрастает. Спланировать можно многое, но, чтобы планы не рушились о стену человеческих отношений или банального неумения работать в команде, стоит выделять либо готовые «сыгранные» команды, либо проводить дополнительный набор специалистов с учетом мнений существующего коллектива, в который и будет вливаться новичек. Очень многое зависит от тех, кто будет руками этого процесса и это нужно учитывать.

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

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

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

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

Ну и, конечно, надо уметь оценить количество и качество ответов на эти вопросы. Тогда все получится.

Неплохой перевод статьи, но было бы хорошо, если бы автор поделился собственным опытом на данную тему.

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

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

Пардон мой французский, статья детсадовская :-). Общий смысл — перед тем как браться за проект, нужно понять, что это за проект, кому и зачем он нужен. А это разве не очевидно? А стоит ли заниматься проектами тем, кому это не очевидно? :-) Привычка постоянно задавать вопрос «зачем» (или более формально: «с какой целью») — это вообще одна из самых нужных привычек в любом бизнесе. Больше того, люди, которые имеют привычку задавать вопросы, обычно умнее тех, кто не задает вопросов :-) (это уже философия)

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

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

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

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

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

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

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

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

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

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

Вопросы, касающиеся бизнеса. Эти вопросы не затрагивают компетенцию менеджера проекта и должны решаться за рамками управления проектом (бизнесом, аналитиками, консультантами):

• вопросы про последствия внедрения проекта (репутация и тп)
• вопросы про последствия невнедрения проекта
• вопросы про недостатки (в контексте приведенного примера про увольнение). Сокращение персонала — может быть, наоборот, одной из задач.
• вопросы про выгоду

Ключевые вопросы, связаные с формированием требований к взаимодействию и ведению проекта:

• планирование времени
• планирование бюджетов
• планирование ресурсов: состав рабочих групп, распределение ролей и обязанностей

• лица, принимающие решения
• порядок согласования, контроля, сдачи и приемки работ
• критерии приемки проекта (это обязательно то, что можно посчитать, измерить либо трактовать однозначно)

Сопровождение и обеспечение

• обучение персонала, тренинги
• оборудование
• документирование и тп.

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

При таком подходе вашему менеджеру не понадобится спрашивать про последствия не сдачи проекта.

По опыту работы, 20 вопросов, увы, осилит далеко не каждый клиент. Если выбирать из предложенных автором, я бы выделил следующий необходимый и достаточный ТОР-5:

1. Какие бизнес задачи должен решить данный проект?
2. Какие последствия будут для компании, если проект не будет запущен?
3. Кто является ЛПР?
4. Зависит ли от реализации нового проекта, реализация других проектов?
5. Предусматривает ли бюджет непредвиденные расходы?

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

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

Нередко важным вопросом является место данного проекта в глобальной бизнес-цели Заказчика. Тогда исполнитель видит для себя задачу минимум (успешная реализация данного проекта) и задачу максимум (полноценное формирование проекта как части большой бизнес-идеи).

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

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

Проблемы многих проектов заключаются в том, что конечную цель или сам процесс ее достижения стороны видят по-разному. Поэтому еще важнее менеджеру проекта разбираться в нюансах, задавать вопросы, объяснять заказчику позицию студии по ключевым вопросам и ее подход к работе. Но на практике так происходит не всегда. Во-первых, на стадии продажи для достижения цели менеджер может говорить и обещать клиенту то, что в бюджет и сроки проекта выполнить нельзя. Во-вторых, многие менеджеры просто боятся начинать разбирать возникающие на проекте противоречия (то ли из-за нежелания вступать в конфликт и делать не то, что от тебя ожидают, то ли от боязни потерять клиента и, соответственно, часть заработка), начинают идти на поводу клиента (которому не нравиться предложенные решения, и он начинает решать проблему со своей точки зрения — например, предлагать попробовать добавить немного персикового или поработать со шрифтами). Результат таких действий — когда конфликт доходит до руководства, то сделать практически ничего нельзя, т.к. бюджет на разработку потрачен впустую, заказчик недоволен, отношения частично испорчены. Поэтому менеджеру всегда необходимо проговаривать, уточнять и прояснять ВСЕ спорные и непрозрачные моменты и разъяснять их заказчику. Как правило, если аргументировать свою позицию и подход к работе, то заказчики с пониманием относятся к спорным моментам. Если этого не сделано и менеджер не захотел (или не нашел времени) уделить клиенту время, то срабатывает правило Мерфи. В теории это называется управление клиентскими ожиданиями. Если такая работа проведена, то вероятность оказания качественной услуги и успешного завершения проекта значительно возрастает.

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

Мне абсолютно очевидно, что стадия продажи проекта, определения его целей и задач, возможных рисков, требований к конечному результату, предпроектные исследования — определяющий этап любого IT-проекта, начиная от сайта-визитки и заканчивая автоматизацией бизнес-процессов. Этап, на 80% определяющий конечный результат и весь ход проекта. Действительно, даже самый длинный и сложный путь (проект) начинается с первого шага, но еще более длинный путь начинается с первого шага не туда. Это сказал Ицхак Кальдерон Адизес, и это — сущая правда.

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