Мы на работе часто решали ранее исследовательские задачи, в них работали просто в специальном трекере, выделяли время, оценивали, проговаривали критерии приемки результатов. Сначала было средне, потом было эффективно — т.к. при очень сильном менеджменте задачи не простаивали, персонал так же был заинтересован и привык работать в redmine — поэтому задачи не отличались особо от рутинных задач (по разработке).
В университете — сложнее, часто нет жестких сроков, мотивация у всех разная и не всегда она понятна, и ответственность многих участников — на очень низком уровне (особенно, нельзя положиться на некоторых аспирантов — но это мой личный опыт).
Может быть, в крупных университетах вроде МГУ и ВШЭ с этим лучше обстоят дела — было бы интересно узнать их опыт.
По поводу .tex — есть СЭД Тезис (от @Haulmont — которые есть тут, на хабре), разработчики которой плотно работают с университетом в Самаре — можно было бы написать им пожелание :-)
Использовать СЭД — идея отличная!
У меня давно были мысли — а что если в университете исследовательскую деятельность автоматизировать через трекер задач, например Redmine. Был бы интересный эксперимент + была бы статистика — сколько статей просрочено, сколько успешно выполнено, какие исследования сделаны и т.д.
Если относится к исследованию — как к конкретному проекту, над которым работает несколько человек (аспиранты и студенты), а проект сам ведет менеджер (научный руководитель) — могло бы получится интересно.
P.S. Почему бы не добавить возможность сдавать файлы в .tex?
Нет, не согласен. Тут надо факты конкретные показывать — дорогу, среднюю и медианную скорость с которой выборка людей проходит обе дороги, отклонения.
Может быть там лестница была, конкретный человек по ней может быстро или медленно ходить. Вы так же уверены на 100% что вы средний человек — ходите не быстрее и не медленнее по определенным местностям. Я вот по дорогам еле плетусь зимой, но по лестницам всегда бегу — так делают не все.
Но говорить что алгоритм можно было бы доработать — надо, пишите в багтрек к ним, пишите отзывы в плеймаркете.
Честно говоря, шторка для почты — это фантики, я ее видел может быть 1 раз вообще в жизни — отображать что то слева — это задача почтового клиента, а не фича в браузере (которая в хроме, кстати работает).
Про карты — да, пути не идеальны, виновата ли в этом практика найма руководителей в Гугле — нет, не виновата, это пример несовершенного мира ))
Спасибо, статья интересная и очень актуальная для многих!
Обязательно надо рекомендовать ее к распространению в ВУЗах, в которых готовятся будущие разработчики и аналитики.
Действительно круто, что у вас есть такие вакансии — когда я закончил математические методы в экономике и очень хотел работать аналитиком данных, увы, в моем городе нужны были скорее техписатели и консультанты по бизнес-процессам — именно туда и приходилось идти людям, которым была интересна аналитика.
Про степени и статистику — согласен, знаю кучу людей, со степенями (КТН и КФМН), которые защищались по релевантным темам, однако от разработки современного ПО они очень далеки, и не пройдут даже на джуниора.
В то же время, человек со степенью приходит в компанию с ожиданием признания его заслуг и быстрого карьерного роста, чего как правило не бывает, т.к. талантливый студент, отработав в компании три года совмещая такую работу с учебой, будет на голову выше любого кандидата наук без опыта работы в ИТ.
У нас ранее был на поддержке проект, с круглосуточной поддержкой и критичными для заказчика сервисами. Никакого особенного RocketScience там не было — виндовые службы (и их резервные копии на соседнем сервере), БД Оракл и ее резервная копия, переключалка БД, + не забился ли жесткий диск (логирование же), нет ли проблем с тэйблспейсами — всего 20-25 компонентов на 1 заказчика, заказчиков около 20. Мониторили работоспособность каждого компонента (делали софт сами).
И честно говоря — без нормального описания процессов все это слабо работало. Дело в том, что тот кто следит за мониторингом — либо получает разумное количество сообщений в единицу времени и обрабатывает их, либо получает больше необходимого и на часть забивает. К тому же, у него есть еще и функциональные задачи + какую то часть времени он за мониторингом не следит (например поехал в отпуск или командировку) и мониторинг бесхозный и бесполезный, начинает присылать тонны сообщений.
В итоге, так это и похоронили — слишком сложно для понимания, мало полезно.
Идеальна система мониторинга, которая:
а) не пишет ненужного, а пишет только по делу;
б) суперлегко настраивается (типа развернул сервис, ввел параметры, подцепил процессы и забыл, а не обновлял БД и настраивал таблицы руками);
в) легок в освоении для саппорта (сотрудник отвалился — новый сел, получил письмо и понял что там написано).
Так же клево, когда менеджмент продумал и внедрил систему реагирования на события. Например в отделе работают Вася и Петя. Вася отвечает за мониторинг все будние дни. Петя отвечает за мониторинг все выходные дни, и дни когда Вася в командировке. Если мониторинг присылает письмо с проблемой, ответственный пишет в ответ «Принято в работу, номер тикета в саппорте 31337» и это рассылается на группу. Далее он работает по тикету в рамках текущего процесса поддержки, а когда инцидент решен — пишет в группу — «Инцидент решен — дело было в засорившемся логами диске С; по результатам создана проблема тикет 31338 — анализ использования места на ЖД для сервера N».
Конечно, можно дофига к мониторингу прикрутить — нагрузку ЦП в пике, IO на ЖД, загрузку памяти и т.д. и т.п. — но нужна ли вам реально эта информация — на мой взгляд она отладочная, должна либо в лог писаться, либо это должно быть обнаружено на тестировании.
Мониторить это у заказчика — не знаю, не знаю…
Но статью плюсану, интересно, спасибо.
Хм, ну подход конечно логичный.
Но я бы вообще радовался, что кто то (бесплатно!) рецензирует статьи. Если что то оскорбительное бы написали — другой вопрос, а что человек как то не так что то понял, или спорит т.к. имеет другие данные (может быть вообще парадигму) — это нормально.
Жаль в ВАКовских журналах такого нет — может быть, статьи писали бы качественнее.
Коллеги.
А другого места обсуждать научные публикации нету, кроме как на Хабре?
Я по моему если не ошибаюсь, это приветствуется в рамках конференций и научных журналов.
Еще, в мое время, авторам замечания по книгам писали напрямую, сейчас я думаю тоже это не проблема.
P.S. Понравилось как составлены структурно статьи и что за обсуждение никто на личности не перешел. Это приятно видеть :-)
Мегакруто! Спасибо.
Подкину бизнес-идей — смартфон iExcel, браузер Excella, почтовый клиент Excelook, приставку для телевизора Sony Exceltion, умные excel-часы с возможностью устанавливать 1 048 576 будильников, фитнес-экслет с возможностью мерить показания тела и сохранять в Excel-файл, нейронную сеть на Excel, Excel-coin, методологию управления проектами Excram…
Спасибо, интересно. Сотрудничать с ВУЗами и привлекать выпускников — это всегда хорошо и правильно!
Предложение к размышлению — организуйте внешние семинары, где делитесь опытом, куда могут приходить все заинтересованные лица, и приглашайте на них открыто (но модерируйте и подтвеждайте заявки, например что бы на семинар по бизнес-анализу попали люди, уже знакомые с областью, а не кто попало).
Темы для семинаров вы знаете и сами — рассказ об опыте внедрения гибких медодологий управления проектами, практика экстремального программирования, управление сложными заказчиками, и т.д. и т.п. — смысл только в том, что бы это были семинары уже для «зубров».
Убьете сразу несколько зайцев — получите хороший опыт ведения таких мероприятий (внутри он у вас уже есть) повысите лояльность коллег из других компаний (и, возможно, привлечете уже не только молодых специалистов), угодите заказчикам (которые тоже захотят поучаствовать), получите какую-никакую пиар-компанию и т.д.
Ага, все верно.
У заказчика есть проблема — учет ликвидаторов ведется неверно. Это у него болит, и он хочет это исправить. Он звонит интегратору и озвучивает свою проблему.
Тот присылает проектную команду, проводит анализ и предлагает заказчику несколько вариантов решений, с их стоимостью, например:
0. Уволить ликвидаторов (бесплатно, но есть риски, которые заказчик не готов взять на себя — затем то он и позвонил нам!). Не рассматриваем.
1. Учитывать ликвидаторов в эксцеле (100к + 3 часа работы пользователя в месяц).
2. Поставить SAP и учитывать все автоматически (90 млн. рублей).
Конечно, представляет это не арх, а ПМ\пресейл, но именно арх ответственный за то, что бы правильно понять бизнес-проблему заказчика и предложить ее решение с помощью имеющихся средств (или несколько альтернатив).
ПМ вообще людьми не командует — у них есть функциональный руководитель. Как правило, из команды ПМу напрямую никто не подчиняется, и уж в 100% случаев ПМ не может приказывать заказчикам.
У вас на проекте есть цели (например внедрить систему электронного документооборота за 6 месяце, в бюджете 10 млн рублей, соответствующую текущим БП предприятия) и есть люди (например команда из 5 человек с какими-либо скиллами — БА, СД, QA и т.д., а так же заказчик и его команда).
Для того что бы обеспечить достижение целей данными людьми, ПМ должен применить лидерство — обеспечить готовность, желание, намерения людей достигать целей некоторым способом (чем их мотивировать это каждый раз отдельный вопрос).
Если ваш ПМ не лидер, если он не умеет мотивировать людей, не умеет управлять командой и заказчиком, — это не настоящий ПМ, пусть идет в функциональные руководители и там командует.
Я бы наверное идеальный путь ПМа описал так:
0. Выбор области, где человек хочет работать — хочет ли делать проекты по строительству ракет, или домов, или софта.
1. Хороший университет, который дает хорошую управленческую базу, а так же формирует критическое мышление и правильное видение бизнеса вообще (и проектного бизнеса, как подможества). Минутка рекламы — в регионе, откуда я родом это СУ — там же нам давали знания о проектном менеджменте (как частном случае менеджмента, вообще).
2. На 2-3-4 курсе университета — работа по специальности в области, где ты хочешь работать (например, если хочешь руководить проектами в разработке софта, желательно иметь представление о процессах разработки, внедрения, тестирования и т.д. — для чего можно пойти в компанию на джуниора — аналитика, разраба, тестера, внедренца и т.д.). Компания нужна не абы какая, а с хорошо (или неплохо) поставленными процессами управления проектами — Ланит, Астерос, Неткрекер, Наумен, АйТеко, СМС-ИТ.
3. Далее — через 1-2 года, когда будешь чувствовать себя уверенно на этом месте — попросить дополнительно загрузить работой администратора проекта (вести протоколы, вносить данные в систему управления проектам, низкоуровнево планировать ресурсы в проджект-сервере и т.д.).
4. Далее — брать на себя роль ПМа в проекте, где ты был аналитиком/тестировщиком/программистом и т.д. Как правило, свой проект/продукт знаешь уже хорошо, много общался с заказчиком (особенно если ты аналитик), знаешь все процессы в организации, людей, и т.д. и т.п.
А просто пройти курсы по ПМству — надо обязательно (например, сразу после универа), но только в паре с реальным опытом, без опыта — они бесполезны.
P.S. Прям статью написать захотелось, о том, что нужно запланировать, для того что бы пойти в ПМы )))
В моем понимании — архитектор подключается на этапе пресейла, смотрит что из предполагаемого скоупа проекта (требований заказчика) реализуется стандартный функционалом ПО (при условии, что это ПО вообще есть, и у него есть стандартный ф-л), а что требует доработки (или если разработка идет с нуля, определяет как надо доработать — какие методы и технологии использовать).
Далее — заказчику показывается некий прайс с гэп анализом, и заказчик далее проводит функционально-стоимостной анализ каждой фичи в проекте.
Например:
Проект: Внедрение MS Excel в компании ООО «Вектор».
Требование 1: Создание электронных таблиц. Стандартный функционал. Доплата не требуется.
Требование 1: Загрузка данных о отпусках участников ликвидации Чернобыльской аварии в таблицы из самописной ERP. Не стандартный функционал. 90 тыс. рублей.
Далее, заказчик думает и выбирает — надо ли ему эти отпуска за 90 тысяч реализовывать, или он их руками забьет (может у него одни ликвидаторы работают). И так по каждому требованию пользователей (конечно, верхнеуровнево, мы же в пресейле еще).
Ну и плюс тут архитектор должен ограничения грамотно написать, например если предполагается миграция данных сколько данных мигрируется (не более 1 млн записей например), кто отвечает за валидацию, какими средствами происходит миграция и т.д. и т.п.
Это позволяет рамки проекта определить правильно, а ПМ это не всегда может сделать, на сложных проектах — скорее никогда.
Вопрос — очень интересно, а есть ли у вас среднее по больнице по бюджету на одного ПМа?
Например, один ПМ ведет от 1 до 5 проектов с общим бюджетом ~40 млн в год.
Такую картинку предлагаю вам рассмотреть.
Но там РМ — это програм менеджер, а не проджект )
Вам ПМ может быть и не нужен, но это сильно от процессов зависит, о которых данных не достаточно.
Кто то же поставляет вам эпики, кто то считает бюджет, кто то считает TCO, экономические эффекты, курирует нагрузку команды и планирует использование людей и средств, рисует роадмэпы и показывает их топам и т.д. и т.п. Если это все делает скрам-мастер — это и есть ваш ПМ ))
Знаю крупный банк, где скрам и более 10 скрам команд пилит один продукт, а ПМ координирует эти команды и управляет сверху результатом, который они выдают.
Мимо проходил, и увидел ваш комментарий, попробую ответить что подсказыват мой опыт ПМства.
Поскольку терминология гуляет от методологии к методологии, буду приводить объяснения по ходу рассуждений.
У вас у проекта есть инициатор, и есть спонсор (часто это одно и то же лицо, но не всегда).
Для вас главное спонсор — пусть для вас это ваш заказчик проекта (и не важно, он инициатор или нет).
Задача спонсора в этом проекте — организовать ресурсы для проекта в нужном количестве.
Задача ПМа — предоставить спонсору данные о ресурсах, необходимых в компании.
Для этого ПМ составляет план проекта, в которых входит план управления ресурсами. Последний (в вашем случае) должен отвечать на следующие вопросы:
— кто нужен?
— зачем нужен?
— когда нужен?
— на сколько нужен?
Предположим вам нужна уборщица тетя Глаша, для того что бы прибрать кабинет после того как айтишники насверлили там дырок для сети. Тета Глаша вам (и ПМу если это еще не вы) не подчиняется.
Так вот, вы включаете ее в план управления ресурсов, исходя из плана работ, который вы составили.
В плане работ вы видите, что айтишники будут тянуть сеть с 1 по 10 июля (± 1 день). Убирать за ними надо по вашим экспертным оценкам 2 дня.
Итого — в плане управления ресурсами вы пишете — «Тетя Глаша, с 10 по 12 июля, в объеме 16 часов».
После этого вы показываете план управления спонсору проекта, который либо соглашается с ним, либо вносит в него правки (например пишет, что может выделить тетю Глашу вместо 10-12 июля на 10-14 июля, но в объеме 4 часа в день — вы соглашаетесь, но объясняете спонсору что эта работа стоит на критическом пути проекта и следовательно срок всего проекта увеличивается на 2 дня (либо у вас есть запас по времени для этой работы)).
Итого, спонсор проекта (как правило это один из топ-менеджеров) подписывает вам план управления ресурсами, и согласно этому плану — ресурсы должны быть выделены.
Что происходит, например если тетя Глаша 10 июля вместо того что бы убирать кабинет после айтишников, уходит убирать цех по приему стеклотары (несмотря на все ваши напоминания об этой работе)? Вы пишете письмо ее руководителю, с копией на спонсора — который становится ответственным за задержку проекта на 1 день — а далее в соответствии с уставом проекта и внутренними регламентами к нему применяются санкции — например штрафы, лишение премии, и т.д.
Но, естественно, если ПМ в начале проекта тетю Глашу не попросил на 2 дня или не внес это в план управления ресурсами — ее руководитель имеет полное право отказать в предоставлении — и это значит что ПМ очень плохо планирует ресурсы.
Конечно, есть и изменения — например тетя Глаша заболела. Но у хорошего ПМа всегда есть 10% сроков — заложенных на риски, и это как раз тот самый (± 1 день) про который речь шла выше.
Ну или как то так. Если у вас серьезные проблемы с организацией проектной деятельности — наймите хорошего ПМа со стороны, который придет, все организует, найдет ответственных, сделает разумный план проекта, организует управляющие комитеты, объяснит людям их роли на проекте, зафиксирует ответственных за работы, заложится на риски, и т.д. и т.п. После этого у вас работы встанут на проектные рельсы. Самим это делать может быть и дешевле, но долго — 2-3 года в среднем проходит от идеи «хотим делать проекты правильно» до «делаем проекты успешно».
>> Например, строительство электростанции и разработка софта — кардинально разные проекты. Разная методология управления (PMI, Agile, Scrum…)…
PMI — Project Management Institute, а не методология.
PMBOK — свод знаний, об управлении проектами, разработанный PMI — а не методология (и это явно в нем прописано). AGILE — философия, объединяющая в себе методы управления проектами, а не методология. Agile подходы так же включены в последнюю версию PMBOK, пруфлинк — www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition
SCRUM — управленческий фреймворк (в крайнем случае набор принципов для построения процессов) применяемый для управления проектными командами, а не методология.
Правильнее было бы просто написать — разная методология управления, или методология управления построенная на разных принципах (гибкий и классический подходы).
Может быть я чего то не знаю, и какой то скрытый смысл за этим лежит?
Потому что сейчас в моих глазах это выглядит как закидывание в статью модных терминов (и аббревиатур).
В университете — сложнее, часто нет жестких сроков, мотивация у всех разная и не всегда она понятна, и ответственность многих участников — на очень низком уровне (особенно, нельзя положиться на некоторых аспирантов — но это мой личный опыт).
Может быть, в крупных университетах вроде МГУ и ВШЭ с этим лучше обстоят дела — было бы интересно узнать их опыт.
По поводу .tex — есть СЭД Тезис (от @Haulmont — которые есть тут, на хабре), разработчики которой плотно работают с университетом в Самаре — можно было бы написать им пожелание :-)
У меня давно были мысли — а что если в университете исследовательскую деятельность автоматизировать через трекер задач, например Redmine. Был бы интересный эксперимент + была бы статистика — сколько статей просрочено, сколько успешно выполнено, какие исследования сделаны и т.д.
Если относится к исследованию — как к конкретному проекту, над которым работает несколько человек (аспиранты и студенты), а проект сам ведет менеджер (научный руководитель) — могло бы получится интересно.
P.S. Почему бы не добавить возможность сдавать файлы в .tex?
Может быть там лестница была, конкретный человек по ней может быстро или медленно ходить. Вы так же уверены на 100% что вы средний человек — ходите не быстрее и не медленнее по определенным местностям. Я вот по дорогам еле плетусь зимой, но по лестницам всегда бегу — так делают не все.
Но говорить что алгоритм можно было бы доработать — надо, пишите в багтрек к ним, пишите отзывы в плеймаркете.
Про карты — да, пути не идеальны, виновата ли в этом практика найма руководителей в Гугле — нет, не виновата, это пример несовершенного мира ))
Обязательно надо рекомендовать ее к распространению в ВУЗах, в которых готовятся будущие разработчики и аналитики.
Действительно круто, что у вас есть такие вакансии — когда я закончил математические методы в экономике и очень хотел работать аналитиком данных, увы, в моем городе нужны были скорее техписатели и консультанты по бизнес-процессам — именно туда и приходилось идти людям, которым была интересна аналитика.
Про степени и статистику — согласен, знаю кучу людей, со степенями (КТН и КФМН), которые защищались по релевантным темам, однако от разработки современного ПО они очень далеки, и не пройдут даже на джуниора.
В то же время, человек со степенью приходит в компанию с ожиданием признания его заслуг и быстрого карьерного роста, чего как правило не бывает, т.к. талантливый студент, отработав в компании три года совмещая такую работу с учебой, будет на голову выше любого кандидата наук без опыта работы в ИТ.
И честно говоря — без нормального описания процессов все это слабо работало. Дело в том, что тот кто следит за мониторингом — либо получает разумное количество сообщений в единицу времени и обрабатывает их, либо получает больше необходимого и на часть забивает. К тому же, у него есть еще и функциональные задачи + какую то часть времени он за мониторингом не следит (например поехал в отпуск или командировку) и мониторинг бесхозный и бесполезный, начинает присылать тонны сообщений.
В итоге, так это и похоронили — слишком сложно для понимания, мало полезно.
Идеальна система мониторинга, которая:
а) не пишет ненужного, а пишет только по делу;
б) суперлегко настраивается (типа развернул сервис, ввел параметры, подцепил процессы и забыл, а не обновлял БД и настраивал таблицы руками);
в) легок в освоении для саппорта (сотрудник отвалился — новый сел, получил письмо и понял что там написано).
Так же клево, когда менеджмент продумал и внедрил систему реагирования на события. Например в отделе работают Вася и Петя. Вася отвечает за мониторинг все будние дни. Петя отвечает за мониторинг все выходные дни, и дни когда Вася в командировке. Если мониторинг присылает письмо с проблемой, ответственный пишет в ответ «Принято в работу, номер тикета в саппорте 31337» и это рассылается на группу. Далее он работает по тикету в рамках текущего процесса поддержки, а когда инцидент решен — пишет в группу — «Инцидент решен — дело было в засорившемся логами диске С; по результатам создана проблема тикет 31338 — анализ использования места на ЖД для сервера N».
Конечно, можно дофига к мониторингу прикрутить — нагрузку ЦП в пике, IO на ЖД, загрузку памяти и т.д. и т.п. — но нужна ли вам реально эта информация — на мой взгляд она отладочная, должна либо в лог писаться, либо это должно быть обнаружено на тестировании.
Мониторить это у заказчика — не знаю, не знаю…
Но статью плюсану, интересно, спасибо.
Но я бы вообще радовался, что кто то (бесплатно!) рецензирует статьи. Если что то оскорбительное бы написали — другой вопрос, а что человек как то не так что то понял, или спорит т.к. имеет другие данные (может быть вообще парадигму) — это нормально.
Жаль в ВАКовских журналах такого нет — может быть, статьи писали бы качественнее.
А другого места обсуждать научные публикации нету, кроме как на Хабре?
Я по моему если не ошибаюсь, это приветствуется в рамках конференций и научных журналов.
Еще, в мое время, авторам замечания по книгам писали напрямую, сейчас я думаю тоже это не проблема.
P.S. Понравилось как составлены структурно статьи и что за обсуждение никто на личности не перешел. Это приятно видеть :-)
Подкину бизнес-идей — смартфон iExcel, браузер Excella, почтовый клиент Excelook, приставку для телевизора Sony Exceltion, умные excel-часы с возможностью устанавливать 1 048 576 будильников, фитнес-экслет с возможностью мерить показания тела и сохранять в Excel-файл, нейронную сеть на Excel, Excel-coin, методологию управления проектами Excram…
2 года можно ходить…
Предложение к размышлению — организуйте внешние семинары, где делитесь опытом, куда могут приходить все заинтересованные лица, и приглашайте на них открыто (но модерируйте и подтвеждайте заявки, например что бы на семинар по бизнес-анализу попали люди, уже знакомые с областью, а не кто попало).
Темы для семинаров вы знаете и сами — рассказ об опыте внедрения гибких медодологий управления проектами, практика экстремального программирования, управление сложными заказчиками, и т.д. и т.п. — смысл только в том, что бы это были семинары уже для «зубров».
Убьете сразу несколько зайцев — получите хороший опыт ведения таких мероприятий (внутри он у вас уже есть) повысите лояльность коллег из других компаний (и, возможно, привлечете уже не только молодых специалистов), угодите заказчикам (которые тоже захотят поучаствовать), получите какую-никакую пиар-компанию и т.д.
У заказчика есть проблема — учет ликвидаторов ведется неверно. Это у него болит, и он хочет это исправить. Он звонит интегратору и озвучивает свою проблему.
Тот присылает проектную команду, проводит анализ и предлагает заказчику несколько вариантов решений, с их стоимостью, например:
0. Уволить ликвидаторов (бесплатно, но есть риски, которые заказчик не готов взять на себя — затем то он и позвонил нам!). Не рассматриваем.
1. Учитывать ликвидаторов в эксцеле (100к + 3 часа работы пользователя в месяц).
2. Поставить SAP и учитывать все автоматически (90 млн. рублей).
Конечно, представляет это не арх, а ПМ\пресейл, но именно арх ответственный за то, что бы правильно понять бизнес-проблему заказчика и предложить ее решение с помощью имеющихся средств (или несколько альтернатив).
У вас на проекте есть цели (например внедрить систему электронного документооборота за 6 месяце, в бюджете 10 млн рублей, соответствующую текущим БП предприятия) и есть люди (например команда из 5 человек с какими-либо скиллами — БА, СД, QA и т.д., а так же заказчик и его команда).
Для того что бы обеспечить достижение целей данными людьми, ПМ должен применить лидерство — обеспечить готовность, желание, намерения людей достигать целей некоторым способом (чем их мотивировать это каждый раз отдельный вопрос).
Если ваш ПМ не лидер, если он не умеет мотивировать людей, не умеет управлять командой и заказчиком, — это не настоящий ПМ, пусть идет в функциональные руководители и там командует.
0. Выбор области, где человек хочет работать — хочет ли делать проекты по строительству ракет, или домов, или софта.
1. Хороший университет, который дает хорошую управленческую базу, а так же формирует критическое мышление и правильное видение бизнеса вообще (и проектного бизнеса, как подможества). Минутка рекламы — в регионе, откуда я родом это СУ — там же нам давали знания о проектном менеджменте (как частном случае менеджмента, вообще).
2. На 2-3-4 курсе университета — работа по специальности в области, где ты хочешь работать (например, если хочешь руководить проектами в разработке софта, желательно иметь представление о процессах разработки, внедрения, тестирования и т.д. — для чего можно пойти в компанию на джуниора — аналитика, разраба, тестера, внедренца и т.д.). Компания нужна не абы какая, а с хорошо (или неплохо) поставленными процессами управления проектами — Ланит, Астерос, Неткрекер, Наумен, АйТеко, СМС-ИТ.
3. Далее — через 1-2 года, когда будешь чувствовать себя уверенно на этом месте — попросить дополнительно загрузить работой администратора проекта (вести протоколы, вносить данные в систему управления проектам, низкоуровнево планировать ресурсы в проджект-сервере и т.д.).
4. Далее — брать на себя роль ПМа в проекте, где ты был аналитиком/тестировщиком/программистом и т.д. Как правило, свой проект/продукт знаешь уже хорошо, много общался с заказчиком (особенно если ты аналитик), знаешь все процессы в организации, людей, и т.д. и т.п.
А просто пройти курсы по ПМству — надо обязательно (например, сразу после универа), но только в паре с реальным опытом, без опыта — они бесполезны.
P.S. Прям статью написать захотелось, о том, что нужно запланировать, для того что бы пойти в ПМы )))
Далее — заказчику показывается некий прайс с гэп анализом, и заказчик далее проводит функционально-стоимостной анализ каждой фичи в проекте.
Например:
Проект: Внедрение MS Excel в компании ООО «Вектор».
Требование 1: Создание электронных таблиц. Стандартный функционал. Доплата не требуется.
Требование 1: Загрузка данных о отпусках участников ликвидации Чернобыльской аварии в таблицы из самописной ERP. Не стандартный функционал. 90 тыс. рублей.
Далее, заказчик думает и выбирает — надо ли ему эти отпуска за 90 тысяч реализовывать, или он их руками забьет (может у него одни ликвидаторы работают). И так по каждому требованию пользователей (конечно, верхнеуровнево, мы же в пресейле еще).
Ну и плюс тут архитектор должен ограничения грамотно написать, например если предполагается миграция данных сколько данных мигрируется (не более 1 млн записей например), кто отвечает за валидацию, какими средствами происходит миграция и т.д. и т.п.
Это позволяет рамки проекта определить правильно, а ПМ это не всегда может сделать, на сложных проектах — скорее никогда.
Например, один ПМ ведет от 1 до 5 проектов с общим бюджетом ~40 млн в год.
Такую картинку предлагаю вам рассмотреть.
Но там РМ — это програм менеджер, а не проджект )
Вам ПМ может быть и не нужен, но это сильно от процессов зависит, о которых данных не достаточно.
Кто то же поставляет вам эпики, кто то считает бюджет, кто то считает TCO, экономические эффекты, курирует нагрузку команды и планирует использование людей и средств, рисует роадмэпы и показывает их топам и т.д. и т.п. Если это все делает скрам-мастер — это и есть ваш ПМ ))
Знаю крупный банк, где скрам и более 10 скрам команд пилит один продукт, а ПМ координирует эти команды и управляет сверху результатом, который они выдают.
Поскольку терминология гуляет от методологии к методологии, буду приводить объяснения по ходу рассуждений.
У вас у проекта есть инициатор, и есть спонсор (часто это одно и то же лицо, но не всегда).
Для вас главное спонсор — пусть для вас это ваш заказчик проекта (и не важно, он инициатор или нет).
Задача спонсора в этом проекте — организовать ресурсы для проекта в нужном количестве.
Задача ПМа — предоставить спонсору данные о ресурсах, необходимых в компании.
Для этого ПМ составляет план проекта, в которых входит план управления ресурсами. Последний (в вашем случае) должен отвечать на следующие вопросы:
— кто нужен?
— зачем нужен?
— когда нужен?
— на сколько нужен?
Предположим вам нужна уборщица тетя Глаша, для того что бы прибрать кабинет после того как айтишники насверлили там дырок для сети. Тета Глаша вам (и ПМу если это еще не вы) не подчиняется.
Так вот, вы включаете ее в план управления ресурсов, исходя из плана работ, который вы составили.
В плане работ вы видите, что айтишники будут тянуть сеть с 1 по 10 июля (± 1 день). Убирать за ними надо по вашим экспертным оценкам 2 дня.
Итого — в плане управления ресурсами вы пишете — «Тетя Глаша, с 10 по 12 июля, в объеме 16 часов».
После этого вы показываете план управления спонсору проекта, который либо соглашается с ним, либо вносит в него правки (например пишет, что может выделить тетю Глашу вместо 10-12 июля на 10-14 июля, но в объеме 4 часа в день — вы соглашаетесь, но объясняете спонсору что эта работа стоит на критическом пути проекта и следовательно срок всего проекта увеличивается на 2 дня (либо у вас есть запас по времени для этой работы)).
Итого, спонсор проекта (как правило это один из топ-менеджеров) подписывает вам план управления ресурсами, и согласно этому плану — ресурсы должны быть выделены.
Что происходит, например если тетя Глаша 10 июля вместо того что бы убирать кабинет после айтишников, уходит убирать цех по приему стеклотары (несмотря на все ваши напоминания об этой работе)? Вы пишете письмо ее руководителю, с копией на спонсора — который становится ответственным за задержку проекта на 1 день — а далее в соответствии с уставом проекта и внутренними регламентами к нему применяются санкции — например штрафы, лишение премии, и т.д.
Но, естественно, если ПМ в начале проекта тетю Глашу не попросил на 2 дня или не внес это в план управления ресурсами — ее руководитель имеет полное право отказать в предоставлении — и это значит что ПМ очень плохо планирует ресурсы.
Конечно, есть и изменения — например тетя Глаша заболела. Но у хорошего ПМа всегда есть 10% сроков — заложенных на риски, и это как раз тот самый (± 1 день) про который речь шла выше.
Ну или как то так. Если у вас серьезные проблемы с организацией проектной деятельности — наймите хорошего ПМа со стороны, который придет, все организует, найдет ответственных, сделает разумный план проекта, организует управляющие комитеты, объяснит людям их роли на проекте, зафиксирует ответственных за работы, заложится на риски, и т.д. и т.п. После этого у вас работы встанут на проектные рельсы. Самим это делать может быть и дешевле, но долго — 2-3 года в среднем проходит от идеи «хотим делать проекты правильно» до «делаем проекты успешно».
PMI — Project Management Institute, а не методология.
PMBOK — свод знаний, об управлении проектами, разработанный PMI — а не методология (и это явно в нем прописано).
AGILE — философия, объединяющая в себе методы управления проектами, а не методология. Agile подходы так же включены в последнюю версию PMBOK, пруфлинк — www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition
SCRUM — управленческий фреймворк (в крайнем случае набор принципов для построения процессов) применяемый для управления проектными командами, а не методология.
Правильнее было бы просто написать — разная методология управления, или методология управления построенная на разных принципах (гибкий и классический подходы).
Может быть я чего то не знаю, и какой то скрытый смысл за этим лежит?
Потому что сейчас в моих глазах это выглядит как закидывание в статью модных терминов (и аббревиатур).