Комментарии 41
Смотря что за проект. В каких-то можно менеджерить и без глубоких технических знаний, а к каким-то без этих знаний нет смысла и близко подходить.
Уровень менеджера должен быть как минимум не ниже уровня участников его команды, иначе его не будут уважать и слишком часто будут ставить на место более опытные разработчики.
Берем усредненную историю заказной разработки. Это, как правило, сайты, веб и мобильные приложения низкой и средней сложности, возможно CRM, и другие корпоративные штуки.
Уровень менеджера должен быть как минимум не ниже уровня участников его команды, иначе его не будут уважать и слишком часто будут ставить на место более опытные разработчики.
А в чем смысл? Он ведь не программирует, он управляет.
Насчет ставить на место — зависит от ситуации, от личных качеств ПМ-а и разработчиков. В целом по моему опыту это миф. Разные позиции — разработчики опытны в разработке, менеджеры опытны в управлении гораздо больше вышеуказанных разработчиков. С чего кому-то кого-то ставить на место.
В чем суть управления, по-вашему? Это же не только задачи раздавать и сроки оценивать, а еще и просчитывать риски, понимать сложные места (где технический долг может стать слишком большим), понимать причины проблем, предугадывать хорошие архитектурные решения, которые потом не выльются в месяцы переделок. Для всего этого нужна неплохая техническая экспертиза, которая может и возможна без знаний деталей технологий, но обычно наоборот накапливается путём набития шишек на множестве этих самых деталей.
Но я склонен считать что сложные места, причины технических проблем, архитектура — это работа техлида, архитектора, и выше по уровню — СТО. Проектный менеджер в этих вопросах имеет совещательный голос, так как не эксперт зачастую.
Про совмещение этих двух ролей — отдельная тема.
А в чём тогда смысл ПМ'а? Бегать к более опытным, слушать что они скажут и раздавать задачи от них?
Может тогда хорошему техлиду или архитектору нанять секретаря — дешевле, а эффект тот же?
Не дешевле, и эффект не тот же. Несмотря на то, что часть деятельности ПМ-а действительно напоминает круг обязанностей секретаря, он им далеко не ограничивается.
По сути, основная задача ПМ — успешно довести проект до финиша (или ближайшего milestone). И чтобы это сделать необходимо учесть нужды всех stakeholder-ов (в случае аутсорса — внешнего заказчика/продакт-менеджера, интересы своей компании, архитектора, тимлида(ов) и QA текущего проекта) учитывая доступные этому проекту ресурсы (время, финансирование и команду). Чтобы эти нужды выяснить сначала ПМ-у действительно нужно "бегать к более опытным", но дальше он должен принять решение в каком объёме и очереди эти нужды удовлетворять и контролировать процесс выполнения работ — а это уже вовсе не уровень секретаря, и тем более секретаря одного конкретного stakeholder-а (тимлида/архитектора).
Если это «коммерция», то там, чаще всего, заказчику важно иметь «одно окно» для решения всех вопросов. В этом случае хорошо, если ПМ будет верхнеуровневые технические проблемы решать на месте, не уходя на подумать и посовещаться с командой. Также будет быстрее работа вестись, если ПМ сможет понимать то, что ему пытается донести команда.
Если же это гос. заказчик, то у ПМа там очень специфичная роль: там лизни, тут наори и смотри, не перепутай. Но в таких проектах и ожидания заказчика от ПМ соответствующие.
И это только если мы говорим про сферическую, относительно монолитную по компетенциям команду из одних разработчиков. А представьте, у вас небольшая команда, которая делает мобильное приложение — например, по распознаванию кошечек. Чтобы управлять ей, менеджер должен уметь в Джаву и базы данных не хуже, чем бэкендщик(и), машинное зрение — не хуже, чем спец по Computer Vision/Machine Learning, Свифт и Котлин знать не хуже, чем мобильщики, тестировать не хуже, чем тестер, и вдобавок, проектировать интерфейсы не хуже, чем дизайнер? Какой-то супермен получается.
Опытные разработчики физически не могут поставить менеджера на место, если менеджер не будет лезть в их область компетенции. Если менеджер сморозил фигню, и разработчики его натыкали носом — это не значит, что менеджеру нужно прокачиваться в менеджменте, а не в разработке.
менеджмент — это про управление, а не про разработку
Если основная область деятельности компании — разработка какого-л. программного продукта, то получается, что управляем мы чем? Этой разработкой. Вы противопоставляете понятия управление и разработки, но чем же тогда занимается менеджер, чем именно он управляет и каковы его обязанности?
Обязанности менеджера не включают написание кода или переламывание команды через колено по поводу конкретных технических решений — только по поводу последствий этих решений.
Чтобы принимать решения, менеджер не должен быть лучшим кодером, чем разработчики.
А на деле, всё зависит от команды и то как она устроена.
Однако этого не понимают прежде всего работодатели. Лично знаю большую региональную ИТ-контору, где менеджер ИТ-проектов — девушка с самомнением, склонностью к сучеству и исключительно лживым резюме. Однако у неё всё прокатило и она активно имитирует рисование канбана на доске и аттестует программистов, пока они плюются и ненавидят её. Руководство убеждено в её эффективности и тупости программистов. Образование девушки — строго гуманитарное. Такие дела.
Прямо слепок моей прошлой работы. Девушка пытается манипулировать страхами программистов, на все возражения отвечает "мне пофиг", а потом парни сидят вечерами и ночами, реализуя "мне пофиг". А у нее проект с ОПП, флоу, кучей веб-фреймворков. А генеральный не вмешивается и самостоятельно перебирает сервера. ))) Идет автоматизация работы правительства России. Девушка кричит чиновникам в трубку-все легко, сейчас сделаем!)))
Менеджер проекта по аутсорсингу должен быть третейским судьёй между командой и заказчиком.
Если он будет только уметь звонить и писать ручкой — он очень быстро займёт сторону клиента, а команда будет забивать на его решения.
Если он будет бывшим техлидом — есть опасность что очень скоро начнёт принимать сторону команды и перестанет слышать клиента.
Поэтому золотая середина в виде общего широкого технического кругозора — имхо как раз то что надо.
Ну а специфичные знания наверное не очень требуются, можно найти в команде толкового человека который будет давать советы технического плана, там где это требуется. Надо только что-бы поработав полгода не возгордился, что он стал всё сам понимать и продолжал слушать чех кто в этом что-то понимает.
Когда отрисована сетевая диаграмма проекта, расставлены веса, работы разбиты по пакетам и назначены ответственные, начинается мониторинг и контроль. Ни на одном из этих этапов техническая экспертиза не вредит.
Менеджер понимает суть и цикл разработки софта
Достаточно этого, поэтому от голосования воздержался. Это нужно, чтобы менеджер понимал, что код нельзя просто написать, что есть другие этапы, на которых задействованы другие люди. Некоторые в комментариях путают тимлида и проджект менеджера. Грамотный менеджер будет использовать знания и опыт членов команды, чтобы решать технические вопросы.
Вообще, это зависит от модели управления проектом. Например, в компаниях, где я работал и использовался скрам, менеджеру никогда не требовались технические навыки кроме совсем базовых.
Человеку с широкой, но неспециализированной базой, будет проще думать более масштабно, не зацикливаясь на технических моментах.
А в управлении самое главное, как я считаю, именно «смотреть на карту», а не «крутить баранку». Баранку будут крутить спецы, а менеджер должен знать куда и как ехать. Он должен грамотно распланировать маршрут, со всеми бензоколонками, СТО, закусочными, мотелями. Чтобы команда добралась до цели комфортно, и без задержек.
Третий вариант ужасен, он сильно хуже первого. PM начинает не управлять проектом, а указывать разработчикам, как нужно делать.
День добрый.
Проекты бывают разные.
Если серьезный и крупный проект в банковской, нефтяной, крупной промышленной сфере, то минимум требования таковы:
- PMBoK, ITIL, IT Risk Management certificate, Prince2 и т.д.
- Владеет хотя бы одним из ООП Java 2, C#, .Net и.т.д.
- Одним из RDBMS Oracle 10g или выше, MS SQL Server, IBM DB2, OLAP технологии, архитектуру БД и т.д.
- Понимание работы Web/Application Servers Apache, IBM Web Sphere, JBOSS, Oracle APP Server и т.д.
- Опыт в программировании в среде GUI Eclipse, Sun Studio, Microsoft Studio и т.д.
- Плюсом будет знание Message service, Python, XML, Net/Web/System Administration, CISCO (или любой другой пром.маршрутизатор), Linux любую версию, понимание mail servers (SMTP, POP3) protocols, AD, DHCP, TCP/IP
- Коммуникабельность, знание английского языка, аналитический расклад ума.
Именно поэтому я больше ориентировался на аутсорс разработку небольшого и среднего масштаба. В проектах которые вы привели — да, как правило так. И это совмещение техлида и ПМ-а, но часто по другому никак. Хотя думаю многие на этом спотыкаются, сложно найти человека который и глубоко в проектном управлении разбирается, и технически подкован на уровне опытного разработчика, и при этом в теме новых вещей, его знания актуальны.
поддерживаю… поскольку РМ работает на посредническом фронте между клиентом (заказчиком) и своей командой разработчиков, он должен понимать что хочет первый и что смогут (возможно и как) сделать вторые, это своего рода «мост» коммуникаций, доведения идей, формулировок пояснений
ИМХО он должен:
- Раньше писать код, пусть даже на уровне нуба, но кроме всего прочего это даёт ему знание как быть вовлечённому в процесс разработки. Т.е. быть в курсе диаграммы состояний что такое и как обрабатывается Change Request — в какие тикеты превращаются, как тикеты обрабатываются и почему футболятся отодного к другому.
Что-то типа: пошёл в разрабы, но понял, что "не моё". - Пробовать тестирование — обязательно. Опять же ради чёткого понимания прицнципов перепасовки.
Типа: после разрабов пытался найти себя в тестировании, но тоже — не моё. - Базовые знания инфрастуктуры железа.
Типа: Админом быть никогда не хотел, но в универе преподавали.
Просто мой опыт говорит мне, что любой менеджер, пришедший извне или соседней сферы — пытается решить проблему исконно привычными методами. Т.е. железячник для решения — будет "добавлять память" и "рестартовать пробовали", программист — "напишет маахонькую утилитку на 6 месяцев доптестирования" (именно поэтому манагер должен быть тот, кому программирование — не зашло).
Парадоксально, но идеальный манагер ИМХО будет (пришло в процессе раздумывания над данным комментарием) сын обеспеченных, но не слишком, родителей, которые запихнули его абы в какой ВУЗ, но "на престижную профессию" программиста. Который не "полный раздолбай", но которому "не зашло". И, который, вместо запиливания лабораторных и курсовых, вкладывал себя в психологию и коммуникацию (заведение знакомств) и решению проблем "ты мне курсач, я тебе — с Ленкой познакомлю. Третий размер".
После чего поработал немного там, немного этам и — нашёл себя в подобном манагерстве. Он хоть и поверхностно, но в теме всех вопросов и небольшой, но всё таки опыт за разные роли — позволяет ему смотреть на проблему чуть более ширше, чем любой "узкий" специалист.
Поработав в нескольких компаниях и наблюдая за работой коллег по цеху, очень часто возникают вопросы о компетентности этих самых коллег, т. к. проджект, это в первую очередь человек, который знает проект от и до, он моментально знает что ответить заказчику на вопрос: «а давайте сделаем аудио сообщения», т. к. знает специфику своего проекта на программном уровне. К чему это я все, ранее я был разработчиком, не много тестировщиком, тимлидом и ушел в менеджмент, не потому что плохо кормят и надоело, а потому что в первую очередь хотел делать продукт, а не задачу.
Если смотреть к на то к чему это приводит, то чем грамотнее проджект в тех. плане, тем он дороже и тем меньше времени потребуется на коммуникации и принятия решения. Но касательно вопроса цены, то не совсем понимаю какая именно считается для вас оптимальной, т. к. человек с высокими тех. навыками будет стоить от 80 000 руб. в месяц и выше (в зависимости от региона разумеется)
Ну и по мимо этого, проджект должен понимать что такое дизайн и что в нем хорошо, а что плохо и в юзабилити. Так он сможет предлагать новые цифры и факты, чем обновляя сервисы старым клиента, останется дело за продутом, который уже должен это все упаковать и предложить
Для простоты предлагаю взять именно проектного менеджера, не касаясь продуктового.
Второе допущение — он работает в сфере IT аутсорсинга, т.е. заказной разработки софта для стороннего заказчика.
Хотя грань чертовски тонка.
Ну и что касается заработной платы, то я взял самый минимум. Т. е. к примеру знакомый (отучился на программиста, отличные коммуникативные навыки), не смог найти себе сразу работу в менеджменте, т. к. — опыта мало. Он на тот момент на 50к устроился (2 года назад), но за последнее время, ценник «не много» изменился в большую сторону, на 60%.
т. к. знает специфику своего проекта на программном уровне
При наличии хорошего тимлида — нужно ли это знать ПМ-у?
Насчет каждого вопроса заказчика — даже зная общую структуру проекта, без глубины, зачастую клиенту можно на любой вопрос уже ответить, потому что зачастую у него нет технической подготовки, с ним говорят на языке бизнеса.
т. к. человек с высокими тех. навыками будет стоить от 80 000 руб. в месяц и выше (в зависимости от региона разумеется)
А навыки ПМ-а у него будут? Думаю что техлид-ПМ, то есть два в одном по навыкам и опытом будет стоить раза в 2-3 больше. 80к стоит обычный ПМ с парой лет опыта и технической грамотностью и английским.
Каждый пишет о своем, мешая в кучу статистики совершенно разное.
В энтерпрайзе для программиста лучше тот, при котором можно получить больше ништяков и денег не особо напрягаясь на проекте и занимаясь тем, чем нравится. Ну вот например можно какой нибудь новый фреймворк поковырять, прокачать скилы…
Сугубо от проекта зависит. Главное, чтобы менеджер был не дураком. И вообще, менеджер должен уметь продать, а не задумываться о технических деталях.
Спасибо! Опрос просто отличный!
Но мне кажется что обсуждение именно PM не совсем верно, и сужать тему только до IT-сегмента не совсем то, что нужно для поиска решение.
Мне кажется что PM — это такой же руководитель отдела, как и любой другой, в любой другой сфере. На мой взгляд руководитель должен понимать как и зачем работает его команда, должен улавливать настроение каждого участника коллектива, вовремя увидеть нарастающую проблему чтобы избежать её роста, а так же ставить и корректировать каждую конкретную задачу на пути реализации. Конечно он должен обладать навыками достаточными для понимания всего происходящего, и в нашем конкретном случае он должен знать как работает та или иная технология, я всем её используют и как правильно её использовать, но вряд ли ему нужно глубокое понимание вообще всего того, что использует каждый разработчик в команде. Всё — таки на то и существуют специализации, чтобы использовать инструмент идеально. Руководитель же должен видеть картину в целом, и не быть специалистом в чём-то одном, иначе он рискует уйти в разработку с головой, проворонить реальную проблему и не иметь возможности ее решить, потому что будет занят мелкими вопросами.
В общем мне кажется что средний вариант самое то, и не важно к какого рода руководителю мы применим этот вопрос.
Но мне кажется что обсуждение именно PM не совсем верно, и сужать тему только до IT-сегмента не совсем то, что нужно для поиска решение.
Просто лично меня, как работающего давно в этой сфере — интересует именно в разрезе IT. Плюс думаю от отрасли все таки многое зависит — менеджмент проектов он очень разный, в IT он особенно своеобразный.
В целом я с вами согласен, придерживаюсь той же позиции. Единственное — аналогия проект/отдела не совсем правильно, это все же разные сущности, и функциональный руководитель и руководитель проекта имеют свою специфическую составляющую, в первую очередь тот факт что проект подразумевает наличие высокого уровня неопределенности. Но в остальном да — те и те руководители со всеми вытекающими.
Опыт как PM 6 лет (до этого работал как IT Business/System Analyst, IT Project Administrator).
Приведу пример.
Vendor: Крупная западная авиакомпания.
Customer: Oracle
Система: Oracle ERP.
Модули: HR Payroll, Finance, Sales & Marketing, Warehouse, IT, Top Management.
Система Web based.
Цена проекта > 2 млн USD + 1 year FOC support, дальше за отдельную плату tech. support, change requests etc.
Stage 1.
- Презентация, знакомство в стиле Say Hello.
Stage 2. - Созданы команды со стороны авикомпании по всем вовлеченным департаментам со своими Team Leads (5 команд и 1 человек из Top mngmt).
- Oracle выделил по два человека для каждого модуля (IT Business Analyst, IT Developer), Project Manager со стороны Oracle Representative EU).
- Знакомство сторон (команд). Для Oracle характерно то, что они выделяют для каждого модуля соответствующих аналитиков, т.е для фин.депа авиакомпании, они выделили аналитика, который шарит в финансах и в ИТ, так же и для HR, S&M, Warehouse…
Stage 3. - Знакомство с существующими системами авиакомпании, сбор информации, подготовка Templates, подгон Oracle ERP Modules.
- ПМ (в моем лице) получил все шаблоны.
- Встреча с каждой командой авиакомпании и Oracle Team.
- Построение Project Plan (MS Project, Primavera P6).
- Глубокое изучение шаблонов, корректировки, замечания, исправление, обновление шаблонов, risk management и в конце Project Administrator собирает все подписи со всех сторон и документирует в архив.
- Параллельно ИТ Администраторы БД обеих сторон вместе с ПМ обсуждают свои пред.области.
- Параллельно разработчикам и IT Business analysts Oracle создается CISCO VPN Tunnel для доступа извне к Staging server на стороне авиакомпании.
Stage 4. - Oracle Team уходит к себе в тыл на разработку самого каркаса системы, развертывает staging server через впн канал.
- Каждый модуль при заливке на staging server проверяется Team Lead и соответствующей командой, ПМ на стороне авиакомпании.
- Вносятся мелкие корректировки в функциональности модуля.
- По завершению подписывается Final Go-Live Agreement.
- Обучение тренеров со стороны авиакомпании (Train Trainers), дальше они обучают персонал, как пользоваться модулями.
Запускается система.
Я могу где то что то пропустить или поменять местами. Проект был внедрен около 9 лет назад. Пишу что помню, как говорится вкратце, чтобы было понятно что такое проект и ПМ для начинающих.
Я участвовал практически во всех встречах, во всех обсуждениях будь то IT, Finance, S&M, HR, Warehouse.
Конечно это был проект, где четко разделены клиент/продавец.
Таких и внутренних проектов было десятки, бывало параллельно два проекта ведешь.
Что мне как ПМ нужно было на проекте Oracle ERP знать? - Как работает отдел кадров (трудоустройство, з.п, внесение в штат, изменение позиции и grades т.е градация работников, отпуска, больничные, премии, увольнение и т.д.)
- Как работает фин.деп (тут черт ногу сломает, отдел пассажирских доходов, отдел авиагрузоперевозочных доходов, отдел внтр.фин аудита, отдел корп.доходов, отдел фин.аналитиков, отдел эл.коммерции, отдел расходов, отдел по з.п, отдел закупок и т.д.)
- Склад (Warehouse) тут одна длинная цепочка, начиная с заказа чего то до поступления на склад. Такой business scheme непрерывная.
- IT знание RDBMS Oracle, PL/SQL, понимание как работают сет.маршрутизаторы, знание Active Directory для SSO (Single Sign On) в систему пользователями авиакомпании, Server hardware, Java обязательно, т.к система тонкий клиент, там использовались технологии JSP, Servlets, JMS, XML, EJB, Applet и т.д.
Так же ITIL, PMBok. - S&M департамент особо зависит от фин.депа, топ менеджмента.
- Коммуникабельность.
- Умение быстро, четко и главное верно анализировать.
- Обязательное знание английского, т.к Oracle американцы. Уровень хотя бы Upper Intermediate.
Недавно тоже занимался enterprise проектом, и мой опыт вне IT, по тем же кадрам, финансам и прочему корпоративному — очень пригодился. Но в целом в таких проектах как вы описали — знания нужны специфические, и их не так много, поэтому я больше ссылался на аутсорс проекты меньшего масштаба, и без энтерпрайза.
Добрый вечер.
Был проект для HES Department (ТБ департамент) в крупной нефтяной компании, где я сам работал. Естесственно проект был без аутсорсинга, project scope, data collection, встречи, обсуждения, план проекта, ToR — Terms of Reference (по нашему ТЗ) пришлось делать самому. Так же сам был разработчиком, сам себе Team Lead, PM .
Тут уже за все ПМ отвечает. Благо проект был небольшим, на 250-300 пользователей. Это в основном ТБ инспектора, инженеры по контр.качества (QC Engineers), Менеджеры ТБ отделов и тб-шники подрядных организации.
Минусы:
Сам отвечаешь за все
Сам себе ставишь задачи по ТЗ
Плюсы:
Пишешь код как тебе удобно
Но вообще в наше время, если проект уровня enterprise, где вовлечены несколько департаментов, проект крупный и количество сотрудников работающие в данном проекте больше 500-1000 человек, то было бы правильно разделить ответственность на несколько уровней.
General Project Manager
IT Project Manager
Finance Project Manager
...etc
Хотя те же функции могут Team Leads выполнять.
Главное при внедрении крупной системы, это человеческий ресурс. Менеджер всего проекта не должен заниматься конфликтными ситуациями, человеческими факторами, на это есть Team Leads. Еще не хватало кроме того, как быть Project Core Person и тянуть весь проект, заниматься мелкими недоразумениями.
Четко поставлена задача, не выполняют в срок, сразу замена, нет времени на болтавню. Письмо начальству и замена. Почему так? В западных компаниях практикуется penalty за просрочку после deadline. Это касается и внедряющей и заказывающей сторон. Так же важна поэтапная проверка каждой готовой функциональности. Не все целиком в конце проекта, а по частям по ходу готовности.
Был случай, внедряли систему по грузоперевозкам, компания индийская, IBS Software. Индусы собрали все данные и уехали в Индию собирать проект, учитывая все замечания. В итоге через 8 месяцев, до Go-Live за 1 месяц предоставили грязный вариант проекта. Столько замечании от пользователей, где то что то криво, некоторые функционалы работают не так, какбыло обговарено. В конце 9 месячный проект продлился на 1.5 года и штрафов немеренно. За 1 просроченный день из за не рабочей функции системы 150$. Вот считайте за 6 мес просрочки какая сумма накрутилась.
Так же хочу для начинающих дать такой совет. Если вы ПМ и ваши поставленные задачи не выполняются командой или некоторыми team lead, смело идите к их начальству, не тяните, если вас не понимают, не уважают, не хотят с вами работать, идите к их менеджеру, в противном случае в конце на deadline отвечать будете вы, никто другой.
Опрос! Какой технический уровень должен быть у Менеджера проектов в IT?