Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Интересная статья. Вопрос с менеджерами действительно актуален, ведь это руководитель, командир проекта и его разработчиков, призванный воплотить все это в жизнь.
На вопрос отличия коммерческого менеджера от менеджера проекта ответить не просто. Коммерческие на связь с клиентом выходят первыми и в силу отсутствия «Продюсерских» способностей могут наломать дров в желании продать проект. Задача у них такая, продавать. Продал и забыл, наобещав золотые горы, не ему же потом все это расхлебывать. А вот задача менеджера проектов, это все как раз расхлебать и даже работая на опережение, постараться не дать коммерческому наломать этих самых дров.
Они должны работать в тандеме, хорошо знать друг друга и ладить. Коммерческий менеджер должен аккуратно ввести в игру менеджера проекта да так, чтобы клиент даже не заметил, что проектом уже занимается другой специалист.
Часто бывает, что клиент заказавший разработку сайта сам не понимает, что из себя представляет этот маркетинговый инструмент, как он работает и зачем он ему вообще нужен. У клиента может не быть фирменного стиля, логотипа и т.д. Мне как разработчику бывает очень сложно понять какие задачи должен решать будущий ресурс. Здесь важную роль играет умения менеджера понять чем дышит компания, каким игроком она является на рынке услуг, как она себя рекламирует. Но, часто этого не происходит. Начинается непонимание с клиентом, затягивается feedback и как следствие проект вылетает из намеченного графика еще на стадии разработки дизайна.
Можно много привести примеров, что должен уметь и делать менеджер проектов, но по требованиям он будет подпадать под вундеркинда.
Лично мое мнение, не стоит все перекладывать на плечи менеджера проектов, важна работа всей команды. Недостающие навыки менеджера легко может компенсировать команда разработчиков. Может стоит подумать как грамотно организовать командный процесс?
Встреча с клиентом может быть полезна и дизайнеру, и программисту и технологу, нужно и об этом не забывать. Разработчики тоже должны «чувствовать» проект.
На вопрос отличия коммерческого менеджера от менеджера проекта ответить не просто. Коммерческие на связь с клиентом выходят первыми и в силу отсутствия «Продюсерских» способностей могут наломать дров в желании продать проект. Задача у них такая, продавать. Продал и забыл, наобещав золотые горы, не ему же потом все это расхлебывать. А вот задача менеджера проектов, это все как раз расхлебать и даже работая на опережение, постараться не дать коммерческому наломать этих самых дров.
Они должны работать в тандеме, хорошо знать друг друга и ладить. Коммерческий менеджер должен аккуратно ввести в игру менеджера проекта да так, чтобы клиент даже не заметил, что проектом уже занимается другой специалист.
Часто бывает, что клиент заказавший разработку сайта сам не понимает, что из себя представляет этот маркетинговый инструмент, как он работает и зачем он ему вообще нужен. У клиента может не быть фирменного стиля, логотипа и т.д. Мне как разработчику бывает очень сложно понять какие задачи должен решать будущий ресурс. Здесь важную роль играет умения менеджера понять чем дышит компания, каким игроком она является на рынке услуг, как она себя рекламирует. Но, часто этого не происходит. Начинается непонимание с клиентом, затягивается feedback и как следствие проект вылетает из намеченного графика еще на стадии разработки дизайна.
Можно много привести примеров, что должен уметь и делать менеджер проектов, но по требованиям он будет подпадать под вундеркинда.
Лично мое мнение, не стоит все перекладывать на плечи менеджера проектов, важна работа всей команды. Недостающие навыки менеджера легко может компенсировать команда разработчиков. Может стоит подумать как грамотно организовать командный процесс?
Встреча с клиентом может быть полезна и дизайнеру, и программисту и технологу, нужно и об этом не забывать. Разработчики тоже должны «чувствовать» проект.
Что случится 15 июня?
То, что про менеджеров проектов в статье написано — справедливо для специфичных небольших проектов (сайты, логотипы, баннеры, SEO и т.д.). Т.е. статью надо было назвать "… менеджера ИТ-медийных проектов с сейлзовой нагрузкой в молодой динамично развивающейся… "
Выбирайте дизайнера/программиста/технолога-переростка с подвешенным языком, пониманием необходимости вылизывать клиента и другими навыками продавашки и не парьтесь. Покажите ему, как выглядят и составляются договоры, акты выполненных работ, счета, счета-фактуры, если не имел чести сталкиваться — и вперед!
ИМХО, ни один серьезный менеджер проектов (в профессиональном смысле этой роли/должности) на такие вакансии/работы не пойдет, чтобы не портить себе проф. карму. Такие вакансии в таких компаниях — это тупиковый вариант с т.з. профессионального развития менеджера проектов.
Еще раз: то, что вы ищете — это некий гибрид с поверхностным знанием нескольких проф. областей, 100% выходец из технарей (а не «общий управленец»), для работы в очень ИТ-специфичной области. Для этого гибрида это, скорее всего, будет первый/второй опыт «управления проектами», верхняя возрастная планка — 25-26 лет.
Выбирайте дизайнера/программиста/технолога-переростка с подвешенным языком, пониманием необходимости вылизывать клиента и другими навыками продавашки и не парьтесь. Покажите ему, как выглядят и составляются договоры, акты выполненных работ, счета, счета-фактуры, если не имел чести сталкиваться — и вперед!
ИМХО, ни один серьезный менеджер проектов (в профессиональном смысле этой роли/должности) на такие вакансии/работы не пойдет, чтобы не портить себе проф. карму. Такие вакансии в таких компаниях — это тупиковый вариант с т.з. профессионального развития менеджера проектов.
Еще раз: то, что вы ищете — это некий гибрид с поверхностным знанием нескольких проф. областей, 100% выходец из технарей (а не «общий управленец»), для работы в очень ИТ-специфичной области. Для этого гибрида это, скорее всего, будет первый/второй опыт «управления проектами», верхняя возрастная планка — 25-26 лет.
Полностью согласен. Серьезного менеджера проектов подобными вакансиями не заманить. А все потому, что в самих компаниях работа менеджера проектов недооценивается. Очень редко где руководители понимают ценность менеджера проектов. И, в основном, понимают в компаниях западных или ориентированных на западный подход. А у нас МП считаются дешевой рабочей силой, которые при этом выполняют адский объем работы, и стоят первыми в списке на увольнение, если дела у компании идут не очень. Это все очень грустно. Поэтому толковые менеджеры или начинают свой собственный бизнес-проект или идут заниматься каким-нибудь одним крупным проектом туда, где есть деньги.
Ну, наша «молодая» компания работает с 1999 года, и в ней больше сотни сотрудников, и есть много очень крупных проектов и клиентов. И отвественность за клиентов — весьма и весьма большая, так что от каждого менеджера (проектов, аккаунтов, сейлзов, медийных и т.д.) требуется умение быть другом клиента и коллегой для всех участников процесса. И отношения к менеджерам, как к расходному материалу нет.
Дизайнеры-технологи-программисты — только толковые трудятся, и их специализация — тоже мега-отвественная, так что их к общению с клиентами подключают только в исключительных случаях. Так как они — прекрасные ребята, то они могут, конечно, общаться — без проблем, профессионально. НО! Кто тогда будет оформлять, верстать, программировать? Мы через такое проходили, и не мы одни — здесь в обсуждениях уже было. Всё хорошо в меру :-)
Дизайнеры-технологи-программисты — только толковые трудятся, и их специализация — тоже мега-отвественная, так что их к общению с клиентами подключают только в исключительных случаях. Так как они — прекрасные ребята, то они могут, конечно, общаться — без проблем, профессионально. НО! Кто тогда будет оформлять, верстать, программировать? Мы через такое проходили, и не мы одни — здесь в обсуждениях уже было. Всё хорошо в меру :-)
Нельзя скрещивать ежа и ужа. Каждому типу менеджеров — свое место.
Менеджер должен быть эффективным. Точка.
Что значит эффективным? Это когда он умеет максимизировать прибыль минимизируя затраты. Умение управлять немаловажно, но является вторичным по сравнению с основной целью — коммерческая эффективность. Если для вас это звучит дико, значит вы смотрите на проблему снизу.
Лично для меня привлекательным типом ПМ является дирижер. Вроде и стоит ко всем задницей, и бесполезно, с первого взгляда, машет руками, но без него нет музыки, тобишь звона монет в карманах.
Менеджер проектов не должен продавать. Для этого есть «продажники». Он категорически не должен быть почтальоном. Ему нужно уметь анализировать информацию, и выделять самые энергоэффективные решения. Он должен быть лидером в коллективе и безоговорочным авторитетом.
Менеджер должен быть эффективным. Точка.
Что значит эффективным? Это когда он умеет максимизировать прибыль минимизируя затраты. Умение управлять немаловажно, но является вторичным по сравнению с основной целью — коммерческая эффективность. Если для вас это звучит дико, значит вы смотрите на проблему снизу.
Лично для меня привлекательным типом ПМ является дирижер. Вроде и стоит ко всем задницей, и бесполезно, с первого взгляда, машет руками, но без него нет музыки, тобишь звона монет в карманах.
Менеджер проектов не должен продавать. Для этого есть «продажники». Он категорически не должен быть почтальоном. Ему нужно уметь анализировать информацию, и выделять самые энергоэффективные решения. Он должен быть лидером в коллективе и безоговорочным авторитетом.
У меня есть второе высшее образование по менеджменту проектов, и я сейчас не работаю менеджером проектов, потому что из перечисленного, ничто не относится к менеджменту проектов. Ждут чего угодно, кроме менеджмента проектов.
В моём понимании, менеджер проектов осуществляет действия по управлению проектом. А именно, прикладывать знания и умения в управлении к проекту, начиная от его старта и заканчивая его окончанием. Какие знания и умения требуются? Если подходить от практики, это составление устава, составление содержания, составление плана, контроль и мониторинг хода работ, управление изменениями, управление рисками, управление персоналом… можно перечислять дальше по PMBOK. Менеджер должен знать и уметь бизнес-планировать, а именно вычислять чистую приведенную стоимость проекта и другие экономические показатели, менеджер должен знать, как те или иные изменения повлияют на них, и соответствующим образом принимать решение. Менеджер проектов работает с проектом, а не с каким-то абстрактным перечислением сущностей (команда, клиент и пр. — это всё элементы проекта).
А вот это «звонить», «креативить»… это всё отношение к менеджеру, как к «менеджеру по продажам», которые ни разу не менеджеры. Где там менеджмент?.. Наболело.
В моём понимании, менеджер проектов осуществляет действия по управлению проектом. А именно, прикладывать знания и умения в управлении к проекту, начиная от его старта и заканчивая его окончанием. Какие знания и умения требуются? Если подходить от практики, это составление устава, составление содержания, составление плана, контроль и мониторинг хода работ, управление изменениями, управление рисками, управление персоналом… можно перечислять дальше по PMBOK. Менеджер должен знать и уметь бизнес-планировать, а именно вычислять чистую приведенную стоимость проекта и другие экономические показатели, менеджер должен знать, как те или иные изменения повлияют на них, и соответствующим образом принимать решение. Менеджер проектов работает с проектом, а не с каким-то абстрактным перечислением сущностей (команда, клиент и пр. — это всё элементы проекта).
А вот это «звонить», «креативить»… это всё отношение к менеджеру, как к «менеджеру по продажам», которые ни разу не менеджеры. Где там менеджмент?.. Наболело.
Ваша позиция ясна, мы сами еще в 2005 году толпой обучались PMBOKу и сами преподаем управление ИТ-проектами на его базе в электротехническом университете. Обучение помогло структурировать мозги и многое из полученного удалось воплотить в жизнь особенно на длинных ресурсоемких и сложных проектах. Однако опыт работы показал, что держать отдельно менеджера проектов, незапятнанного пресейлом или вопросами маркетинга нет возможности. Так же как и сэйлз не сможет зацепить клиента с первых же слов телефонного разговора, не побывав в полях и не выполнив пару проектов, так менеджер проекта может не увидеть всей картины не начав общения с холодных звонков. К сожалению коммуникации между сейлзами и менеджерами проектов не всегда 100-процентные.
Единственно пришлось проводить сегментацию направлений и разделение менеджеров. Одни занимаются только проектами по электронному документообороту, другие — промышленной оцифровкой, третьи — заказными проектами.
Единственно пришлось проводить сегментацию направлений и разделение менеджеров. Одни занимаются только проектами по электронному документообороту, другие — промышленной оцифровкой, третьи — заказными проектами.
Обмен мнениями показывает, что у всех свои представления о менеджменте в целом и менеджменте проектов в частности.
Это ни хорошо, ни плохо. Просто в каждой компании исторически складывались те или иные порядки.
Иногда причудливые, но вполне эффективные и приносящие результат.
Для меня управление проектом — это прежде всего управление людьми, которые в этом проекте заняты.
Это ни хорошо, ни плохо. Просто в каждой компании исторически складывались те или иные порядки.
Иногда причудливые, но вполне эффективные и приносящие результат.
Для меня управление проектом — это прежде всего управление людьми, которые в этом проекте заняты.
Плохо это. Не хорошо. Менеджер проекта отвечает за успех проекта. За то, что он будет сдан вовремя и не выйдет из бюджета. За то, что команда после его окончания не разбежится и получит какие-то новые знания, профессионально вырастет. За то, что заказчик будет доволен результатом и захочет работать с вами дальше.
Но соглашусь с вами: наиболее важная (я бы даже сказал — решающая) составляющая в успехе проекта — это хорошая команда, поэтому работе с людьми надо уделять наибольшее внимание. Но ограничиваться только этим — опасно.
Но соглашусь с вами: наиболее важная (я бы даже сказал — решающая) составляющая в успехе проекта — это хорошая команда, поэтому работе с людьми надо уделять наибольшее внимание. Но ограничиваться только этим — опасно.
Проект — всего лишь инструмент, или объект, над которым оперирует менеджер и его команда. Успешность проекта не гарантирует главного — роста прибыльности компании.
Конечно. Именно поэтому рост прибыли не входит в сферу ответственности руководителя проекта. Конечно, хороший ПМ должен быть заинтересован в росте прибыльности компании, но отвечает он только за успех проекта.
Если успешный проект не ведёт к росту прибыли — это уже ошибки стратегического масштаба.
Если успешный проект не ведёт к росту прибыли — это уже ошибки стратегического масштаба.
Не согласен. Менеджер имеет все инстументы, чтобы корректировать затратную часть проекта. Например, он может принять решение о смене приоритетов в разработке, что прямым образом может отразиться на прибыли. Ведь прибыль можно увеличивать двумя способами: увеличивая доходы и уменьшая затраты.
За успех проекта ПМ не может отвечать, так как успешность находится в руках маркетологов. ПМ может отвечать за качество продукта, за сроки реализации, за приоритетность разработки, но за успешность — только косвенно. Приведу простой пример. Win95 был жутко глючной ОС, но успешной благодаря маркетингу. Андроид 3.0 во всех обзорах получает оценку «недопиленный», но общая истерия вокруг Андроида только подогревает к нему интерес. Успешный? Да. Благодаря труду ПМ-ов? Далеко не на 100%.
Успешный проект может не вести к росту прибыли. XBOXы и PS3 продавались ниже себестоимости. Потому что нужно было захватить рынок, и потом уже получать прибыль из других источников. Назвать это ошибкой стратегического масштаба у меня как-то язык не поворачивается.
За успех проекта ПМ не может отвечать, так как успешность находится в руках маркетологов. ПМ может отвечать за качество продукта, за сроки реализации, за приоритетность разработки, но за успешность — только косвенно. Приведу простой пример. Win95 был жутко глючной ОС, но успешной благодаря маркетингу. Андроид 3.0 во всех обзорах получает оценку «недопиленный», но общая истерия вокруг Андроида только подогревает к нему интерес. Успешный? Да. Благодаря труду ПМ-ов? Далеко не на 100%.
Успешный проект может не вести к росту прибыли. XBOXы и PS3 продавались ниже себестоимости. Потому что нужно было захватить рынок, и потом уже получать прибыль из других источников. Назвать это ошибкой стратегического масштаба у меня как-то язык не поворачивается.
Да. Насчёт успеха вы выразились гораздо точнее. Действительно, плохо произведённый проект тоже может быть успешным.
С другой стороны, не думаю, что ПМ может принимать решение о смене приоритетов. Это должны решать всё те же маркетологи.
А вообще — всё сильно зависит от конкретной ситуации. Функции, которые разные фирмы возлагают на руководителя проектов, сильно разные. Это видно даже из этого обсуждения.
С другой стороны, не думаю, что ПМ может принимать решение о смене приоритетов. Это должны решать всё те же маркетологи.
А вообще — всё сильно зависит от конкретной ситуации. Функции, которые разные фирмы возлагают на руководителя проектов, сильно разные. Это видно даже из этого обсуждения.
Уточню про смену приоритетов. Естественно, про глобальную смену не шла речь. Имелось в виду перераспределение нагрузки таким образом, чтобы результат работы был максимально эффективным. Тут еще все зависит от методологии разработки. Если ПМ идет на поводу у продажников, то скорее всего разработчикам будет выставлены как приоритетные те задачи, которые максимально эффективны с точки зрения продаж. Если же ПМ умеет искать компромисы между хотелками клентов и планомерным развитием продукта, то он будет чередовать мелочи к глобальными задачами.
Про функции верно подмечено. ПМ-а пытаются подбирать такого типа, чтобы он максимально удовлетворял запросам вышестоящего руководства.
Про функции верно подмечено. ПМ-а пытаются подбирать такого типа, чтобы он максимально удовлетворял запросам вышестоящего руководства.
Оценка успешности менеджера складывается из его успешности при выполнении следующих задач (от наиболее важных к менее):
1. Постановка целей
2. Организаторская работа
3. Мотивация команды
4. Контроль выполнения, метрики
5. Саморазвитие, развитие команды
На собеседовании вместо выявления подтипа менеджера попросите его рассказать о реальных примерах по каждому из пунктов.
1. Постановка целей
2. Организаторская работа
3. Мотивация команды
4. Контроль выполнения, метрики
5. Саморазвитие, развитие команды
На собеседовании вместо выявления подтипа менеджера попросите его рассказать о реальных примерах по каждому из пунктов.
Это не определение, а размышление. О том, какого менеджера я бы хотел пригласить на работу, и я просто вспомнил, каких знал. То есть задачи такой не было изначально — давать определение. Ну а размышления могут быть и на 100500 тысяч знаков :-)
У меня не было задачи вывести оределение менеджера. Пускай этим занимаются те, кому это нравится.
Я вспомнил те подходы людей, которые мне встречались — причем они встречались как в мелких, так и в крупных компаниях. Сделал я это для того, чтобы сформулировать для себя — какой же мне нужен менеджер проектов.
Полностью согласен с Капитаном — поэтому и продумываю, как мне составить вакансию под принятый стиль работы в нашей компании. Тем не менее, некоторые компании ищут пути оптимизации работы и готовы пересматривать сущетвующий уклад, и мне стало интересно — что мы можем изменить (если нужно изменять) и какими плюсами-минусами мы обзаведемся.
Я вспомнил те подходы людей, которые мне встречались — причем они встречались как в мелких, так и в крупных компаниях. Сделал я это для того, чтобы сформулировать для себя — какой же мне нужен менеджер проектов.
Каким образом он эту задачу будет выполнять, зависит от принятого у вас стиля работы.
Полностью согласен с Капитаном — поэтому и продумываю, как мне составить вакансию под принятый стиль работы в нашей компании. Тем не менее, некоторые компании ищут пути оптимизации работы и готовы пересматривать сущетвующий уклад, и мне стало интересно — что мы можем изменить (если нужно изменять) и какими плюсами-минусами мы обзаведемся.
Я и сам, поработав в разных студиях, от САЛ до собственной, встречал только двух руководителей проектов, которые делали своё дело так, что им можно было любоваться.
У Вас, похоже, тоже опыт был печальным :-), раз только двух таких встречали.
Могу ошибаться, но лидер — он в любом случае лидер, независимо от того, насколько он является менеджером проекта, если так можно выразиться. Такого хочется заполучить к себе. Потому как прекрасная команда уже есть :-)
Также работаю менеджером по проектов. Но столкнулся с другой ситауцией: когда вместо того, чтобы работать с клиентом, командой и другими отделами приходиться как учитель сидеть и проверять код программистов и давать разжеванные команды к действиям.
Если это не прекращается и команда не растёт профессионально, значит надо задуматься об эффективности вашей работы с программистами.
Если же всё нормально, то через некоторое время у вас будет отличная профессиональная команда, да и лояльная, к тому же, т.к. все будут понимать. что именно вы их воспитали.
Если же всё нормально, то через некоторое время у вас будет отличная профессиональная команда, да и лояльная, к тому же, т.к. все будут понимать. что именно вы их воспитали.
По поводу вопросов в конце статьи — ИМХО не надо выдумывать новый смысл и объем обязанностей для хорошо устоявшихся ролей и называть вещи своими именами — сейлз (аккаунт менеджер), менеджер проектов, системный аналитик, бизнес-аналитик, разработчики разные и т.д.
Если в вашей компании, так уж сложилось, все занимаются всем по чуть-чуть, то просто явно говорить, что человек совмещает несколько ролей и списывать часы по ролям. Большинство людей со временем будут тяготеть к какой-то одной роли. А при расширении компании и повышении качества услуг двигаться в сторону специализации, а не толпы шив-многостаночников, которые и жнец, и швец, и на дуде игрец. Если последний вариант — это ваша фишка и конкурентное преимущество, то жестко закреплять людей за клиентами, чтобы их полностью обрабатывали. И называйте их как хотите внутри компании, просто потом при устройстве на работу в другую компанию — «я был менеджером проекта по разработке баннера» будет срывать в истерику даже ничего не соображающих хрюшек.
Если в вашей компании, так уж сложилось, все занимаются всем по чуть-чуть, то просто явно говорить, что человек совмещает несколько ролей и списывать часы по ролям. Большинство людей со временем будут тяготеть к какой-то одной роли. А при расширении компании и повышении качества услуг двигаться в сторону специализации, а не толпы шив-многостаночников, которые и жнец, и швец, и на дуде игрец. Если последний вариант — это ваша фишка и конкурентное преимущество, то жестко закреплять людей за клиентами, чтобы их полностью обрабатывали. И называйте их как хотите внутри компании, просто потом при устройстве на работу в другую компанию — «я был менеджером проекта по разработке баннера» будет срывать в истерику даже ничего не соображающих хрюшек.
По моему тут какое-та подмена понятий.
Все что относится к project- менеджменту давно описано в стандартах PMI
В статье же намешано всё — менеджеры по продажам, офис-менеджеры, продюсеры…
Все что относится к project- менеджменту давно описано в стандартах PMI
В статье же намешано всё — менеджеры по продажам, офис-менеджеры, продюсеры…
Увидев заголовок сначала обрадовался, о том что затронута интересная тема. Почитав статью — расстроился.
Дело в том, что автор даже не потрудился даже изучить смысла использованного термина, зато кинулся классифицировать и наполнять содержанием неправильно обозначенную сущность, чем свел ценность своей работы почти к нулю.
Запомните пожалуйста. Человек который «представляет заказчика в компании» называется аккаунт менеджер!!! Его зарплата напрямую зависит от количества покупок клиента.
А менеджер проекта — это руководитель рабочей группы в компаниях с горизонтальной иерархией.
Задача менеджера проекта координировать работу членов рабочей группы, контролировать сроки и принимать окончательные решения в спорных ситуациях. Его зарплата обычно зависит от выполнения сроков и удовлетворенности заказчика при услвоии контроля бюджета.
Автор написал что идеальный менеджер это
Если взять полномочия проджекта и наделить ими аккаунта, то бизнесу придет конец. Причина банальна — аккаунт всегда будет хотеть сделать как можно больше, за как можно меньшие деньги. В то время как проджект наоборот распоряжается выделением ограниченного ресурса.
Или если смотреть смотреть в деньгах, то аккаунт отвечает за приток денег, а проджект за их расход.
Для контроли функции прибыли, нужны очень серьезные полномочия, которые в описанных компаниях есть только у генерального директора ну или партнера, участвующего в прибыли.
Нет ничего удивительного в том, что вместо сотрудников выполняющих задачи у автора получаются то почтальоны, то администраторы.
Совет если компания маленькая, то роль аккаунта обязательно должна быть, а роль проджекта может быть размазана между начальником дизайнеров, директором, финансистом.
Если компания растет то нужно делать связку аккакунт — проджект. При этот должен осознанно быть создан конфликт интересов. Аккаунт будет тянуть одеяло на клиента, а проджект на компанию. Задача руководителя балансировать этот процесс, чтобы максимизировать прибыль и не допускать перекосов. Иначе фирма или останется без денег или без клиентов.
Дело в том, что автор даже не потрудился даже изучить смысла использованного термина, зато кинулся классифицировать и наполнять содержанием неправильно обозначенную сущность, чем свел ценность своей работы почти к нулю.
Запомните пожалуйста. Человек который «представляет заказчика в компании» называется аккаунт менеджер!!! Его зарплата напрямую зависит от количества покупок клиента.
А менеджер проекта — это руководитель рабочей группы в компаниях с горизонтальной иерархией.
Задача менеджера проекта координировать работу членов рабочей группы, контролировать сроки и принимать окончательные решения в спорных ситуациях. Его зарплата обычно зависит от выполнения сроков и удовлетворенности заказчика при услвоии контроля бюджета.
Автор написал что идеальный менеджер это
сплав продюсера и менеджера клиентовЭто как раз те роли которые я обозначил.
Если взять полномочия проджекта и наделить ими аккаунта, то бизнесу придет конец. Причина банальна — аккаунт всегда будет хотеть сделать как можно больше, за как можно меньшие деньги. В то время как проджект наоборот распоряжается выделением ограниченного ресурса.
Или если смотреть смотреть в деньгах, то аккаунт отвечает за приток денег, а проджект за их расход.
Для контроли функции прибыли, нужны очень серьезные полномочия, которые в описанных компаниях есть только у генерального директора ну или партнера, участвующего в прибыли.
Нет ничего удивительного в том, что вместо сотрудников выполняющих задачи у автора получаются то почтальоны, то администраторы.
Совет если компания маленькая, то роль аккаунта обязательно должна быть, а роль проджекта может быть размазана между начальником дизайнеров, директором, финансистом.
Если компания растет то нужно делать связку аккакунт — проджект. При этот должен осознанно быть создан конфликт интересов. Аккаунт будет тянуть одеяло на клиента, а проджект на компанию. Задача руководителя балансировать этот процесс, чтобы максимизировать прибыль и не допускать перекосов. Иначе фирма или останется без денег или без клиентов.
Если нужны шашечки, то можно наплодить аккаунт и прочих менеджеров. Если нужно ехать, то нужен один человек, который отвечает за результат своего труда как перед заказчиком (сданный проект), так и перед организацией (денежная отдача).
Понимаете, в вашем комментарии очень нечётко определено «отвечает за результат своего труда». А менеджер должен отвечать за конкретные вещи: поиск заказчиков, текущее общение с клиентами, аналитика, бюджет и сроки, люди, продажи, бизнес-стратегия. Согласитесь, тяжеловато всё это на одного грузить.
«Отвечать за всё» = «не отвечать ни за что». Человек должен заниматься конкретной работой, а не интегрировать в себе задачи пяти должностей. Это как два зайца, за которыми, как известно, гнаться не советуют.
Вот когда человеку чётко сказано, за что он отвечает, тогда и эффект есть.
«Отвечать за всё» = «не отвечать ни за что». Человек должен заниматься конкретной работой, а не интегрировать в себе задачи пяти должностей. Это как два зайца, за которыми, как известно, гнаться не советуют.
Вот когда человеку чётко сказано, за что он отвечает, тогда и эффект есть.
Результат труда для заказчика — подписанный акт приемки передачи и удовлетворенность.
Результат труда для компании — деньги на счете.
За все что посередине отвечает PM. Это его конкретная работа — превратить приведенного сейлзами заказчика в эти две сущности.
Единственное что здесь не измеряется прямо — удовлетворенность заказчика.
Результат труда для компании — деньги на счете.
За все что посередине отвечает PM. Это его конкретная работа — превратить приведенного сейлзами заказчика в эти две сущности.
Единственное что здесь не измеряется прямо — удовлетворенность заказчика.
Да, как раз самая большая ошибка, что один отвечает за продажи, другой за реализацию, третий за бюджет, а четвертый за сроки. В итоге за результат не отвечает никто.
«Конкретная работа» — абсолютно не конкретная формулировка. Чуть более конкретная, чем: «задача ПМа, чтобы компания зарабатывала деньги» :).
Что в вашем понимании «результат»?
Если вас как бизнесмена интересуют лишь деньги на счёте — это, вроде, нормально. Хотя, конечно, стратегическое развитие компании тоже в вашей компетенции.
Вы, вероятно, путаете руководителя проектов и, скажем, руководителя направления или директора компании. Но у них специфика такая, что непосредственно проектами они напрямую не руководят.
Что в вашем понимании «результат»?
Если вас как бизнесмена интересуют лишь деньги на счёте — это, вроде, нормально. Хотя, конечно, стратегическое развитие компании тоже в вашей компетенции.
Вы, вероятно, путаете руководителя проектов и, скажем, руководителя направления или директора компании. Но у них специфика такая, что непосредственно проектами они напрямую не руководят.
Результат фиксируется в KPI и может быть разноплановым. Условно, для главного инженера на заводе это на 50% выполнение плана по производству, на 30% вписывание в нормативы по травматизму и 20% внедрение новых технологий.
Вы на машине когда едете тоже назначите отдельных ответственных за то чтобы рулить, чтобы жать на педали и чтобы переключать передачи? Или все-таки наймете одного водителя, который довезет вас куда нужно?
Вы на машине когда едете тоже назначите отдельных ответственных за то чтобы рулить, чтобы жать на педали и чтобы переключать передачи? Или все-таки наймете одного водителя, который довезет вас куда нужно?
Сравнение с машиной совершенно некорректно. Я абсолютно с тем же успехом могу спросить, заставите ли вы на самолёте единственного пилота разносить обед пассажирам вместо стюардессы? Или, продолжая сравнение, будете ли вы требовать от этого водителя, чтобы он во время движения играл на волынке и занимался финансовым анализом ситуации на рынке плюшевых медведей?
Может быть, мы просто про разные сферы деятельности говорим? Я, к сожалению, про завод ничего сказать не могу, т.к. совершенно не знаком с предметом. Возможно, для завода такой подход и пройдёт, хотя тоже сомневаюсь.
Вообще — если сфера ответственности определена чётко и KPI вы заявляете менеджеру при найме, то это его вопрос соглашаться на эту работу или нет.
Я бы никогда не согласился взять ответственность «за всё». Просто потому, что никто не сможет делать «всё» эффективно. А за свою работу менеджер отвечает всегда, если уж взялся делать.
Может быть, мы просто про разные сферы деятельности говорим? Я, к сожалению, про завод ничего сказать не могу, т.к. совершенно не знаком с предметом. Возможно, для завода такой подход и пройдёт, хотя тоже сомневаюсь.
Вообще — если сфера ответственности определена чётко и KPI вы заявляете менеджеру при найме, то это его вопрос соглашаться на эту работу или нет.
Я бы никогда не согласился взять ответственность «за всё». Просто потому, что никто не сможет делать «всё» эффективно. А за свою работу менеджер отвечает всегда, если уж взялся делать.
Причем здесь «плодить»?
Во-первых автор поста сам написал что нанимает сотрудника, следовательно мы уже не обсуждаем плодить/не плодит, а думаем кого именно плодить.
Во-вторых, автор путает функцию работы с клиентом и функцию работы с проектом. Эти функции требуют разных компетенций условно говоря — продавец и менеджер. Очевидно, что в небольших компаниях это все намешено в кучу и может быть раскидано как у годно. Еще раз повторю свою мысль в менеджменте не бывает слово «неправильно», есть слово «неэффективно».
Совмещение в одной голове функции работы с клиентом и ведения проекта, эффективно пока клиентов мало и попался уникальный человек на это способный.
Если же компания растет, выгоднее раскидать эти функции на разных людей со сравнительно простым функционалом, чем ставить второго, третьего многорукого шиву. Выгоднее — не значит правильнее.
Если Автор не готов пересматривать свои представления о структуре организации, не готов признавать существования более эффективных схем, то для него «правильнее» жить со своей концепцией и искать людей вписывающихся в нее. В конце концов неоспоримо что если найти человека, который в одиночку делает работу 10 или 100 людей то это здорово. Просто опыт показывает, что ставка на таких людей обычно проигрышна.
В компании всегда есть один человек который отвечает один за все, его называют генеральный директор. Два генеральных директора в одной компании, это трагедия :)
Во-первых автор поста сам написал что нанимает сотрудника, следовательно мы уже не обсуждаем плодить/не плодит, а думаем кого именно плодить.
Во-вторых, автор путает функцию работы с клиентом и функцию работы с проектом. Эти функции требуют разных компетенций условно говоря — продавец и менеджер. Очевидно, что в небольших компаниях это все намешено в кучу и может быть раскидано как у годно. Еще раз повторю свою мысль в менеджменте не бывает слово «неправильно», есть слово «неэффективно».
Совмещение в одной голове функции работы с клиентом и ведения проекта, эффективно пока клиентов мало и попался уникальный человек на это способный.
Если же компания растет, выгоднее раскидать эти функции на разных людей со сравнительно простым функционалом, чем ставить второго, третьего многорукого шиву. Выгоднее — не значит правильнее.
Если Автор не готов пересматривать свои представления о структуре организации, не готов признавать существования более эффективных схем, то для него «правильнее» жить со своей концепцией и искать людей вписывающихся в нее. В конце концов неоспоримо что если найти человека, который в одиночку делает работу 10 или 100 людей то это здорово. Просто опыт показывает, что ставка на таких людей обычно проигрышна.
В компании всегда есть один человек который отвечает один за все, его называют генеральный директор. Два генеральных директора в одной компании, это трагедия :)
Если Автор не готов пересматривать свои представления о структуре организации, не готов признавать существования более эффективных схем, то для него «правильнее» жить со своей концепцией и искать людей вписывающихся в нее.
Автор — в поиске оптимального решения для компании, и в поиске компетентного сотрудника. Одно никак не исключает другого. Стремление к идеалу — это, на взгляд автора, очень правильное стремление :-), но, как писал автор — важно вовремя остановиться (и нет пределов совершенству). Готов признавать более эффективные схемы, если они могут работать безлично, то есть в отрыве от конкретных людей. Но такого нигде и никогда не встречал. Всегда главное — это люди.
Найдете такую схему-систему — расскажите. Я не троллю, мне правда интересно.
> Всегда главное — это люди.
Считаю, что всегда главное — что люди делают, а потом что это за люди. И от этого уже плясать. «Безличные» (до некоторой бОльшей степени, чем «люди») системы бывают — там, где регламентированы процессы. Регламент — не обязательно бумага на 50 страниц, я при составлении регламента по УП в своё время уложился в 10 страниц с цветными картинками, + 3 страницы на шаблоны документов (исключая договоры).
Когда есть хороший процесс УП, всем понятно, что от них требуется, и в чем проблема, если не получается.
Считаю, что всегда главное — что люди делают, а потом что это за люди. И от этого уже плясать. «Безличные» (до некоторой бОльшей степени, чем «люди») системы бывают — там, где регламентированы процессы. Регламент — не обязательно бумага на 50 страниц, я при составлении регламента по УП в своё время уложился в 10 страниц с цветными картинками, + 3 страницы на шаблоны документов (исключая договоры).
Когда есть хороший процесс УП, всем понятно, что от них требуется, и в чем проблема, если не получается.
Никто и не говорил, что важно что это за люди. Важно то, насколько люди профессиональны, мотивированы и понимают суть своей работы.
При любом, даже самом лучшем процессе плохой программист хорошего кода не напишет. Обратное изредка случается. Хотя тоже из области фантастики.
Кстати, любой процесс увеличивает производительность в среднем на 5-10%. Максимум — на 35%. Роберт Гласс исследовал в своё время.
Так что, всего хорошо в меру, но увлечение процессом и игнорирование people management'а губительно для команды.
Почитайте «Успешные проекты и команды» Демарко и Листера. Это (наряду с Бруксом) — классика из обязательной к прочтению профессиональными ПМами. Уверен, ваше мнение немного поменяется.
При любом, даже самом лучшем процессе плохой программист хорошего кода не напишет. Обратное изредка случается. Хотя тоже из области фантастики.
Кстати, любой процесс увеличивает производительность в среднем на 5-10%. Максимум — на 35%. Роберт Гласс исследовал в своё время.
Так что, всего хорошо в меру, но увлечение процессом и игнорирование people management'а губительно для команды.
Почитайте «Успешные проекты и команды» Демарко и Листера. Это (наряду с Бруксом) — классика из обязательной к прочтению профессиональными ПМами. Уверен, ваше мнение немного поменяется.
Я и не вам отвечал :) ДеМарко я читал.
Я говорил про процесс управления проектами, а не разработки. Считаю, что процессы управления должны идти отдельно от процессов исполнения (это не только моё мнение, в наиболее формализованном виде я почерпнул его из других книг по УП).
Процессы нужны не только для производительности. Процессы нужны для совершенствования (хотя бы по ISO), и для того, чтобы на их результатах можно было надстраивать другие процессы. Например, управление портфелем проектов.
Сам по себе процесс не очень нужен, нужны его результаты. В частности результатом процессов управления проектами является завершенный в срок, в бюджет, и с надлежащим качеством проект. Я вот об этом.
Я говорил про процесс управления проектами, а не разработки. Считаю, что процессы управления должны идти отдельно от процессов исполнения (это не только моё мнение, в наиболее формализованном виде я почерпнул его из других книг по УП).
Процессы нужны не только для производительности. Процессы нужны для совершенствования (хотя бы по ISO), и для того, чтобы на их результатах можно было надстраивать другие процессы. Например, управление портфелем проектов.
Сам по себе процесс не очень нужен, нужны его результаты. В частности результатом процессов управления проектами является завершенный в срок, в бюджет, и с надлежащим качеством проект. Я вот об этом.
Нет ничего удивительного в том, что вместо сотрудников выполняющих задачи у автора получаются то почтальоны, то администраторы.
Это я перечислял (повторюсь) стили работы встречавшихся мне менеджеров. У всех людей есть перекосы к тому или иному стилю работы, вот и всё. Не говорю, что они действительно так делятся. Даже переходят из одних в других:
Но все люди – люди, и время от времени кочуют из одного типа менеджера в другого, в зависимости от специфики работы организации, клиентов и личных навыков (которые они могут развивать).
Очень грамотно описал про конфликт интересов. В организациях все элементы должны быть вовлечены в прозрачные системы сдержек и противовесов — утрированно говоря, «лучше война по правилам, чем дружба с нарушением правил». Если грамотно замотивировать эти системы сдержек и противовесов с помощью KPI, то каждая роль, действуя в своей «области ответственности», будет пытаться выжать свой максимум, достигая процессного и проектного совершенства! )).
Показался интересным вопрос насчет техподдержки и проблемы контактеров/менеджеров в таких долгоиграющих проектах.
В средних организациях эта проблема очень распространена, когда первоначальный контактер уже не имеет физической возможности выступать в качестве менеджера. У нас лечат эту проблему так: клиента по сути ставят перед фактом о назначении нового менеджера. Но контактер остается супервайзером и время от времени звонит клиенту, интересуется как дела и т.д. Если клиент недоволен, то доносит это до руководства.
В итоге клиент получает профессиональное отношение — раз и чувствует заботу — два.
В средних организациях эта проблема очень распространена, когда первоначальный контактер уже не имеет физической возможности выступать в качестве менеджера. У нас лечат эту проблему так: клиента по сути ставят перед фактом о назначении нового менеджера. Но контактер остается супервайзером и время от времени звонит клиенту, интересуется как дела и т.д. Если клиент недоволен, то доносит это до руководства.
В итоге клиент получает профессиональное отношение — раз и чувствует заботу — два.
Сколько каких проектов может вести менеджер одновременно? А если это менеджер клиентов – то сколько клиентов может параллельно вести один менеджер?
По моей практике, боле 3-4 активно идущих проекта вести сложно. Прибавим к этому относительно неограниченное количество проектов «на поддержке» в вялотекущем состоянии.
Еще важно (на мой взгляд), чтобы менеджер проектов не был загружен на 100 и более процентов. У него должно оставаться время на ревью проектов. Если этого времени не остается, то менеджер превращается рано или поздно в «почтальона», теряет мотивацию и «хватку».
По моей практике, боле 3-4 активно идущих проекта вести сложно. Прибавим к этому относительно неограниченное количество проектов «на поддержке» в вялотекущем состоянии.
Еще важно (на мой взгляд), чтобы менеджер проектов не был загружен на 100 и более процентов. У него должно оставаться время на ревью проектов. Если этого времени не остается, то менеджер превращается рано или поздно в «почтальона», теряет мотивацию и «хватку».
Всё зависит от количества людей в проектной команде.
На практике: проекты с командой из 4 человек и более съедают 100% времени, 2-3 — 75%. 1 человек — около 25-30%.
Для проектов > 7-10 человек необходимо делить проект на подпроекты и ставить во главе каждого линейного руководителя.
На практике: проекты с командой из 4 человек и более съедают 100% времени, 2-3 — 75%. 1 человек — около 25-30%.
Для проектов > 7-10 человек необходимо делить проект на подпроекты и ставить во главе каждого линейного руководителя.
И от этого зависит тоже.
«ставить во главе каждого линейного руководителя. „
В большинстве компаний это просто невозможно по причине отсутствия кадров. Более того, зачастую состав участников от проекта к проекту не меняется. И вся компания тащит на себе сразу несколько проектов. Это свойственно небольшим компаниям.
Вообще я столкнулся с двумя направлениями расширения штата.
Представим, что соотношение между менеджерами и производящими мощностями 1 к 2. Это изначальное соотношение.
Путь 1. Увеличение состава менеджеров так, чтобы было 1 к 1 или даже 4 к 3. Мотивация (глупая, но я встречал и такое) — больше менеджеров, больше задач и проектов => больше денег. Но при узкости производящего канала — скорее всего захлебнется.
Путь 2. Увеличение производящих мощностей. 1 к 3<. Захлебнется по причине того, что при возрастающей нагрузке на менеджеров падает нагрузка на производящий элемент. Тоже встречал такое — мотивация такая — менеджер только перераспределяет задачи и задач в день перераспределить может много.
Оба пути не верны. На мой взгляд, при должной организации процесса должны быть сформированы устойчивые группы единовременно ведущие 1 проект. 3-4 группы может курировать один менеджер проектов, но во главе каждой группы должен быть еще какой-то лидер. Младший менеджер проекта, например. Но где такое реально — я не видел (у меня сейчас похоже на это, но не совсем).
«ставить во главе каждого линейного руководителя. „
В большинстве компаний это просто невозможно по причине отсутствия кадров. Более того, зачастую состав участников от проекта к проекту не меняется. И вся компания тащит на себе сразу несколько проектов. Это свойственно небольшим компаниям.
Вообще я столкнулся с двумя направлениями расширения штата.
Представим, что соотношение между менеджерами и производящими мощностями 1 к 2. Это изначальное соотношение.
Путь 1. Увеличение состава менеджеров так, чтобы было 1 к 1 или даже 4 к 3. Мотивация (глупая, но я встречал и такое) — больше менеджеров, больше задач и проектов => больше денег. Но при узкости производящего канала — скорее всего захлебнется.
Путь 2. Увеличение производящих мощностей. 1 к 3<. Захлебнется по причине того, что при возрастающей нагрузке на менеджеров падает нагрузка на производящий элемент. Тоже встречал такое — мотивация такая — менеджер только перераспределяет задачи и задач в день перераспределить может много.
Оба пути не верны. На мой взгляд, при должной организации процесса должны быть сформированы устойчивые группы единовременно ведущие 1 проект. 3-4 группы может курировать один менеджер проектов, но во главе каждой группы должен быть еще какой-то лидер. Младший менеджер проекта, например. Но где такое реально — я не видел (у меня сейчас похоже на это, но не совсем).
На мой взгляд, при должной организации процесса должны быть сформированы устойчивые группы единовременно ведущие 1 проект. 3-4 группы может курировать один менеджер проектов, но во главе каждой группы должен быть еще какой-то лидер. Младший менеджер проекта, например. Но где такое реально — я не видел (у меня сейчас похоже на это, но не совсем).
Я разделяю точку зрения! В нашем случае существует не «Младший менеджер проекта», а один из участников рабочей группы (чаще всего технолог, потомоу что он участвует и в работе дизайнеров, и в работе программистов).
Ну, собственно, именно это я и хотел сказать. когда писал про линейных руководителей. Они и техническими специалистами могут быть вполне, не обязательно ПМами. Другое дело, что на них будет дополнительная ответственность за их часть команды.
Ну и, кстати, про небольшие компании — у таких компаний проекты с количеством человек больше 7 встречаются редко.
Ну и, кстати, про небольшие компании — у таких компаний проекты с количеством человек больше 7 встречаются редко.
Конечно. И в маленьких компаниях роль PM иногда трансформируется весьма причудливым образом. Ведь PM'ом может быть ведущий специалист, пользующийся доверием руководства. И тогда приходится совмещать свои прямые функции и функции менеджера. Путь порочен, но распространен. Но еще страшнее, когда в сторону PM двигают девушку-аккаунта, которая вообще не в зуб ногой. Тут опять мотивация такая, что PM перераспределяет задачи, а с этим и обезьянку можно натаскать.
Еще выражу свою боль и печаль по поводу взгляда на ценность PM в глазах у руководства. Очень часто я встречался с мнением, что PM ничего сам не производит и денег компании не приносит. В этом ракурсе даже посредственный верстальщик может быть более ценным, чем менеджер. И это, на мой взгляд, тоже беда маленьких компаний.
Еще выражу свою боль и печаль по поводу взгляда на ценность PM в глазах у руководства. Очень часто я встречался с мнением, что PM ничего сам не производит и денег компании не приносит. В этом ракурсе даже посредственный верстальщик может быть более ценным, чем менеджер. И это, на мой взгляд, тоже беда маленьких компаний.
Да. Менеджер-программист — это боль. Задачи совершенно разные. Тимлид вполне нормально ставит задачи и распределяет работу, но вот, когда к этому добавляются бюджет, сроки и разговорчивый заказчик, всё становится плохо.
Такой проект обычно умирает. Если только программист не перестаёт писать практически полностью и не становится «нормальным» ПМом.
Такой проект обычно умирает. Если только программист не перестаёт писать практически полностью и не становится «нормальным» ПМом.
Такой проект обычно умирает. Если только программист не перестаёт писать практически полностью и не становится «нормальным» ПМом.
В этом случае спасает прослойка в виде аккаунта. Получается эдакий монстр из трех функций в двух людях.
Вообще, для маленьких компаний еще имеет значение самоорганизация. Ведь как нигде в маленьких компаниях возрастает роль отдельного сотрудника. Я допускаю, что в сферической компании в вакууме возможна самоорганизующаяся модель, при которой отсутствует менеджмент как класс. Где-то я про это читал, но как-то не отложилось.
Сорри, что я все свожу к маленьким компаниям. Эта тема меня наиболее интересует, так как чаще с этим встречался и это наиболее актуально для современной действительности.
В этом случае спасает прослойка в виде аккаунта. Получается эдакий монстр из трех функций в двух людях.
Вообще, для маленьких компаний еще имеет значение самоорганизация. Ведь как нигде в маленьких компаниях возрастает роль отдельного сотрудника. Я допускаю, что в сферической компании в вакууме возможна самоорганизующаяся модель, при которой отсутствует менеджмент как класс. Где-то я про это читал, но как-то не отложилось.
Сорри, что я все свожу к маленьким компаниям. Эта тема меня наиболее интересует, так как чаще с этим встречался и это наиболее актуально для современной действительности.
Можно проще, менеджер должен обладать такими качествами:
— гибкость (тут и умение общаться и договариваться, знать языки и культурные специфики, входить в положение и примерять на себя разные роли)
— обучаемость (легко и быстро разбирается с спецификой бизнеса клиента, занимается самообучением, проявляет интерес к разным областям знаний вне зависимости от специфики проекта).
— системный подход (видит проблему шире, чем то, что требует решения в данный момент, видит связи между проблемами, имеет стратегическое видение).
— лидерство (брать на себя ответственность, уметь управлять людьми, уметь мотивировать себя и подчиненных).
Думаю, этого хватит чтобы быть успешным менеджером, а остальное приложится.
— гибкость (тут и умение общаться и договариваться, знать языки и культурные специфики, входить в положение и примерять на себя разные роли)
— обучаемость (легко и быстро разбирается с спецификой бизнеса клиента, занимается самообучением, проявляет интерес к разным областям знаний вне зависимости от специфики проекта).
— системный подход (видит проблему шире, чем то, что требует решения в данный момент, видит связи между проблемами, имеет стратегическое видение).
— лидерство (брать на себя ответственность, уметь управлять людьми, уметь мотивировать себя и подчиненных).
Думаю, этого хватит чтобы быть успешным менеджером, а остальное приложится.
Я сейчас ищу продюсеров на мобильные и социальные игры. Признаться — нелегко. Только бывает покажется, что тебе прислал резюме тот самый, как что-нить идет не так — либо на тестовом провал (причем на сроках его выполнения) либо еще что. Также очень тяжело понять что из себя реально представляет человек до того, как он начнет что-то делать уже в составе команды… Но что самое интересное, опыт показывает, что лучший продюсер — тот, кто равно отдален от всех специализаций разработки — он не лезет в программирование, но четко контролирует девелоперов, выпытывая практический смысл их плана и отталкиваясь от того «что это даст проекту», а не от «прикольной прогерской фишки». Он не пытается ничего нарисовать сам, при этом четко подбирает рефы и знает что он хочет и т.п. Возможно, тут играет роль специфика геймдева…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рассуждения о смысле работы менеджера проектов и о том, как сформулировать требования к этой вакансии