Этот пост изначально задумывался как отзыв на тренинг Happy-PM «Путь самурая», но в итоге я решил написать, чем же на самом деле занимаются менеджеры проектов вне отрасли разработки ПО.
С недавнего времени я работаю в небольшой компании, занимающейся системной интеграцией. Под этим загадочным названием скрывается продажа оборудования, монтаж локально-вычислительных сетей, телефонии, настройка серверов, и не только – и электропитание, и охранно-пожарные сигнализации, и т.д. Попробуем разобраться, чем занимается руководитель (или менеджер) проекта в подобной организации. Это и менеджер по продажам, и по закупкам оборудования, и технический специалист, который должен знать всё до винтика в проекте, которым он руководит. Можно конечно и не знать некоторых вещей, но например, не имея опыта монтажа и настройки (ну или хотя бы продажи) оборудования SDH, трудно предположить, какова трудоёмкость этих работ, и сколько денег на это может быть потрачено.
Попробуем сравнить его с менеджером проекта (или project manager – PM) в области разработки ПО, о работе которого я могу предположить по материалам упомянутого выше тренинга “Путь Самурая”. Такой человек, как правило, занимается организационной, но не технической работой, и уж точно не занимается продажами. Если же обезглавить руководителя проектов так, что он перестанет понимать что-либо технически – его останется только уволить. И как правило, руководитель проекта занимается такими проектами, которые он сам понимает.
Кроме того, у руководителя проекта, как правило, нет непосредственных подчинённых. Специалисты привлекаются к работам по необходимости из соседнего подразделения. Такая структура, насколько я помню, называется матричной (об этом я узнал как раз из тренинга Happy PM).
И самое интересное: я пока ещё не видел, чтобы в работе руководителей проектов использовался специальный софт для управления проектами (например, MS Project), так как не очень понятно, к чему его применять. Основной софт, используемый в работе – это Excel. В отличие от PM, который в основном работает с людьми, наш руководитель проекта в основном работает с таблицами спецификаций оборудования и ценами.
Кроме того, непонятно, есть ли смысл в сертификации PMP для такой работы.
Вот основные действия, которые делает руководитель проекта (непонятно только, почему это не делает специально выделенный для этого продажный менеджер) на этапе впаривания заказчику решения:
1. Получить от заказчика технические требования (например, в виде конкурсной документации, если проводится конкурс на поставку какого-то оборудования или решения).
2. Отредактировать документацию, обезличив так, чтобы в ней не упоминалось название конечного заказчика и каких-то ещё ненужных подробностей.
3. Запинать технических специалистов, чтобы они расписали техническое решение по каждому из разделов документации (например, локально-вычислительная сеть, телефония, и т.д.).
4. Отправить отдельные куски документации в сторонние компании – поставщикам соответствующих решений (по тем разделам документации, по которым технические специалисты не умеют или не знают, что делать).
5. Ответить техническим специалистам и поставщикам решений на все вопросы, на которые, в общем-то, нет ответов и в техническом задании.
6. Получить от технических экспертов спецификации требуемого оборудования и стоимость работ (хотя бы примерно, в человеко-часах).
7. Запинать человека, который занимается закупкой, чтобы он узнал цены на оборудование по спецификации (“расценил” спецификацию).
8. Получить от компаний-поставщиков решений готовые спецификации с ценами, свести их все в единую таблицу.
9. Выбить хорошие скидки из поставщиков. Запинать поставщиков так, чтобы они дали ещё более хорошие скидки.
10. Заложить в доходную часть проекта возможные и невозможные издержки.
11. Скрестить пальцы. Молиться. Пойти и утопиться. 🙂
Есть ещё много разных нюансов. Что происходит на этапе реализации проекта – я расскажу как-нибудь потом, когда будет такой опыт.
Кто такой руководитель проекта – мы вроде немного разобрались, осталось только понять, с чем его едят. И вот тут мы понимаем, что если в проекте что-то пойдёт не так, к примеру, он начнёт выходить за рамки выделенного на него бюджета, то руководителя проектов, образно выражаясь, “съедят с говном”.