Рубрика «управление проектами и командой»

Ольга Стратанович, Program Director в ProductSense и Chief Product Officer в «Киноплан», рассказала о ключевых отличиях в мышлении и навыках менеджера продукта и менеджера проекта.

Продакт vs. Проджект: чем отличаются профессии, которые часто путают - 1

Профессия «менеджер продуктов» пока еще молодая в СНГ, но уже востребована на рынке. Компании с собственной разработкой ищут человека, который сможет выпустить и сопровождать продукт. Заказная разработка тоже нуждается в продуктовом подходе. Но хороших менеджеров продуктов на всех не хватает, поэтому возникает необходимость брать джуниоров из других областей.

Самой близкой областью считается менеджмент проектов. Я часто встречаю бывших менеджеров из заказной разработки, которые перешли в менеджмент продуктов. Они не понимают, какие изменения должны произойти на новой работе. Обычно они думают, что это всего лишь следующая ступень проектного менеджмента.

Давайте разберем, чем отличается менеджер продукта от менеджера проекта.

Читать полностью »

Настройка Jira под ваши нужды. Синхронизация команд в потоке проектов - 1

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

Дано:

  • вы разрабатываете и поддерживает сложный программный продукт, работающий на нескольких клиентах;
  • у вас несколько инженерных команд (бекенд, IT Ops, iOS, Android, веб и т. д.), которые работают независимо друг от друга с отдельными беклогами;
  • у вас несколько продуктовых направлений, то есть, грубо говоря, один продуктовый менеджер ведёт несколько проектов по своему направлению, другой менеджер — по своему;
  • ваши инженерные команды функциональны, то есть они не выделены на отдельные продуктовые направления, а решают задачи всех юнитов сразу, обслуживая определённую часть технологического стека;
  • и, конечно, вы используете Jira!

Читать полностью »

Jira против хаоса в разработке: как не терять задачи - 1

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

Дано:

  • вы разрабатываете и поддерживает сложный программный продукт, работающий на нескольких клиентах;
  • у вас несколько инженерных команд (бекенд, IT Ops, iOS, Android, веб и т. д.), которые работают независимо друг от друга с отдельными беклогами;
  • у вас несколько продуктовых направлений, то есть, грубо говоря, один продуктовый менеджер ведёт несколько проектов по своему направлению, другой менеджер — по своему;
  • ваши инженерные команды функциональны, то есть они не выделены на отдельные продуктовые направления, а решают задачи всех юнитов сразу, обслуживая определённую часть технологического стека;
  • и, конечно, вы используете Jira!

Читать полностью »

Всем добрый день!

До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.

Поехали.

Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.

О роли Delivery Manager мы говорим не часто. Конечно, это не часть “семьи” Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком “Разработчик”. Вот, пожалуй, и все.

Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.

Delivery Manager — новая роль в мире Agile - 1Читать полностью »

— Привет! Ну ты как, кто, где? — давно не виделись.
— Да я менеджер ИТ-проекта в большой компании.
— О, PRINCE, риски, экстремальное управление, финансы. Сложно!
— Да не. Так, ТЗ от клиента технарям и обратно таскаю за деньги. Фигня.

Вот такой вот реальный диалог. И, думается, диалог актуальный для многих компаний, особенно, если они не входят в десятку крупнейших вендоров и интеграторов, где процессы всё же отлажены и проекты выглядят именно как проекты. Понятно, почему многие компании малого и среднего бизнеса отворачиваются от самого понятия «проект» и работают как карта ляжет. В таких условиях работа прожект менеджера больше похожа на работу надсмотрщика, который приходит к программистам и просит быстрее накодить фичу, потом идёт к тестерам и призывает тестировать прямо сейчас и без критикалов, потом идёт с тимлидами разворачивать это на продакшене и с фиолетовым лицом приносит баги от клиента, причём независимо от того, минорный баг или критический, — лицо всегда одинаково фиолетовое, а речь начинается со слов: «У клиента всё упало». Правда, ситуация кажется нездоровой? Давайте о ней поговорим.

Менеджер проекта с ТЗ в руках — это ещё не признак управления проектом - 1
Типичный прожект менеджер, который не очень понимает, что такое управление проектами
Читать полностью »

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

На тренингах иногда спрашивают о фишечках, приемах и технологиях. Когда долго чем-то занимаешься, то такие вещи становятся само собой разумеющимися, и сложно сразу ответить на вопрос. Тем не менее я попробую выделить некоторые, на первый взгляд незначительные моменты, которые помогают экономить время и силы. Маленькие лайфхаки.
Читать полностью »

– У нас не получится уложиться в сроки!
– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!

Последнее время часто слышу: они провалились, потому что неправильно выбрали методологию разработки продукта. Вот если бы вы применили Scrum/DevOps/Agile/еще что-то, то все было бы хорошо. Похоже, эти люди кое-что не понимают в разработке софта.

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

Существуют десятки методологий, но ни одна не гарантирует результат. В каждом новом проекте процесс должен определяться каждый раз заново. В основном, выбор процесса зависит от разрабатываемого продукта и людей, участвующих в разработке. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.
Читать полностью »

В этом году я побывал на конференции Data Crunch в Будапеште посвященной аналитике данных и Data Engeneering. На эту конференцию приглашают спикеров из Linkedin, Uber, Github и множества компаний "второго эшелона", где люди делятся своим опытом или же рассказывают об инструментах по работе с данными. Ну и что мне так же интересно — это пообщаться с участниками конференции по понять, насколько наша российская действительность отличается от Европы и США.

Из того, чтобы я отметил это:

  1. Full Stack Data Sceince — 2 доклада были посвящены примерно той же теме, что я писал раньше. Сделайте DS/DA человеком, кто может решать задачи от начала и до конца. Не делите работу по "функциям", а делите DS по "топикам". Т.е. работа с данными это не разделение на части между теми, кто готовит, обрабатывает, анализирует, строит модели и визуализирует, а это разделение "топиков" между специалистами, кто может сделать все полностью.
  2. From zero to hero — ребята рассказывали по то, как строили свой отдел DS с нуля. В целом как обычно, обычные здравые идеи работают:Читать полностью »

Разработка софта считается плохо измеримым процессом, и кажется что, чтобы ей эффективно управлять, нужно особое чутье. А если интуиция с эмоциональным интеллектом развиты не очень, то неизбежно будут сдвигаться сроки, проседать качество продукта и падать скорость поставки.
Оцениваем процессы в команде разработки на основе объективных данных - 1
Сергей Семёнов считает, что это происходит в основном по двум причинам.

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

И предлагает подход к оценке и контролю процессов на основе объективных данных.

Ниже видео и текстовая версия доклада Сергея, который по результатам зрительского голосования занял второе место на Saint TeamLead Conf.
Читать полностью »

Здравствуйте, друзья! Появление популярного менеджера зависимостей в PHP — является одним из важнейших событий в жизни PHP-сообщества. Composer разделил время на "до" — когда наши самописные библиотеки лежали в zip-архивах или просто разбросаны по папкам и копировались "ручками", лишь в единичных случаях, использовался git или PEAR, и "после" — когда мы начали использовать composer. Но что делать если вы работаете с определенной CMS, а она не "знает" что такое composer?

Читать полностью »