Я не представляю себе менеджера, который сформировался (как менеджер), не узнав при этом как разрабатываются веб-проекты. Чем он тогда всё это время занимался, пока шло его «формирование»?

Волей-неволей любой менеджер, занимающийся продюсированием веб-проекта сталкивается в работе с проектировщиками, дизайнерами, front-end и back-end разработчиками, SEO-шниками, иллюстраторами и другими участниками продакшена, в зависимости от масштаба компании и решаемых задач. В ходе этого взаимодействия менеджер решает множество различных тасков, разруливает тысячи факапов, общается, обсуждает задачи, обучается их формировать и выставлять в разработку, принимает участие в тестировании продукта, узнает о технологиях, CMS, фреймворках и, сам того не замечая, прокачивается ото дня в день. Если он нифига не учится, как ему можно доверять самое святое — оценку проекта и постановку задач?

Мой ответ на вопрос «Что делать?» — увольняйте его к черту. Сегодня же.

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

Для оценок и нюансов привлекать экспертов. Но стоит помнить, что есть 4 типа оценок с разной точностью:
— Навскидку −25 + 75%;
— Экспертная −10% + 25%;
— PERT — по 3м точкам (при разбросе экспертных оценок) −5% +15% ;
— Детальная (после разбора состава работ до модуля в 2-3 часа) — −5% +5%.

Знать формулы расчета сроков: (часы/количество разрабов)/0,6 (ibm для буржуев берет коэфф 0,8, но у нас как-то хуже с эффективностью).

Знать как формировать бюджет (себест, риски, время ПМа, управленческий резерв).

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

И да, проектировщика лучше отдельно.

В целом — лучше прокачать человека на толковых курсах по управлению проектами — PMBook, Agile. Остальное доберет в процессе. вышесказанное — мое мнение."

Прокачка ради прокачки или повышение эффективности подготовки оценки? Если второе — есть несколько шагов:

1. Проанализируйте процесс оценки, декомпозируйте на задачи и опишите критериикачества.
2. Соберите базу ранее сделанных оценок, классифицируйте и поддерживайте.
3. Ведите управленческий учет или хотя бы собирайте статистику по проектам.
4. Создайте стандарт подготовки оценок.

Мы это проделали и убедились, что за 2 недели можно прокачать нового менеджера (даже без проф. образования и опыта в отрасли) так, что оценка типового проекта займет 2-3 часа включая контроль наставника, а через 1-1.5 месяца он будет самостоятельно ее делать за 1 час.

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

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

Мы пишем ТЗ основываясь на принципе «от общего к частному». А именно: выясняем глобальные задачи, формируем общие решения для этих задач, а затем уже прикидываем карту сайта, прототипы и т.д. и т.п.

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

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

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

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

Есть только один способ обучения — сделать 5-10-100 проектов. В нескольких проектах участвовать в качестве наблюдателя, еще 2-3 проекта сделать под началом опытного специалиста, задавая вопросы и консультируясь. А затем уже пуститься в свободное плавание и все делать самому. Выполнив с десяток сложных проектов, придет понимание, что обсуждать с клиентом, как с его слов составить тз и сколько времени потребуется на его реализацию.

Это процессная студия или проектная?

Процессная — это значит, что основной продукт — это, например, корпоративные сайты и/или интернет-магазины, которые имею на 80-90% стандартную функциональность (остальное — доработки под специфику конкретного клиента). Здесь обучающий элемент — это описание бизнес-процессов, производственные стандарты, рабочие инструкции.

Действия: обучение и понимание внутренним стандартам, прохождение курсов 1С-Битрикс, наставничество.

Проектная студия сегодня пишет личный кабинет для страховой компании, завтра автоматизирует логиста, через месяц разрабатывает он-лайн сервис. Здесь априори обучать сложно, PM-мом может быть человек с опытом разработки от 2-х лет. Необходимы общие правила по ведению проектов и сильная команда. Быстро обучить/прокачать сотрудника не получится.

Действия: обучение принципам ведения проектов и внутрикомандного взаимодействия, работа от 3-6 месяцев ассистентом у опытного коллеги, работа с менее сложными проектами, ведение базы знаний.

У менеджера, на мой взгляд, главными компетенциями должны быть способности слышать Заказчика и понимать его бизнес задачу. Большинство задач — типовые, т.е. встречаются часто. Для типовых проектов студии стоит упростить задачу менеджера стандартизацией. Для этого стоит накопить статистику по задачам и времени/стоимости их решения. Где разброс «нормальный» для оценки у менеджера данных хватит, у команды надо попросить уточнить желаемый вид ТЗ и работать с этим. Там, где разброс не нормальный — стоит выделить риски и обработать их. Этих данных для пресейла и составления ТЗ при должном уровне автоматизации хватит. Если проект не типовой — необходимо подключать тех. директора/архитектора. Если же менеджер сам желает разобраться, надо обязательно помочь ему силами компании или online обучением.

Если мы говорим о маленькой студии/проекте (а только там может существовать менеджер-человек-оркестр, который и ТЗ пишет, и проект оценивает) — то уровень задачи не требует высокого уровня компетенции (в противном случае, за ТЗ будут отвечать уже технические специалисты), а значит достаточно будет:

1. базы знаний компании, типовые юзкейсы, сравнительная таблица применимости CMS/фреймворков/технологий в типовых случаях;
2. описание функционала продукта (и другие материалы) на сайтах производителей;
3. демо-версии продуктов;
4. анализ ранее выполненных работ студии и их ТЗ/брифа/задачи/сметы/трудозатрат;
5. помощь более опытных коллег;
6. помощь тех. специалистов.

За пределами компании интенсивов/курсов по программе «Битрикс/UMI/Yii/Symfony/etc. для Менеджеров» на мой взгляд нет.

В свою бытность менеджером пять лет назад у меня был разве что опыт сборки статических страничек на HTML и настройки Joomla. Что не мешало делать крупные проекты и жестоко факапить сроки. Причём факапы происходили из-за недостатка именно менеджерских навыков и знаний, но не технических. Поэтому я необъективен и основываюсь только на своём опыте. 

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