Примечание переводчика:
Начало года — отличное время, чтобы вдумчиво оценить прошедший год. Окинуть широким взглядом происходящее и понять, как сделать 2019 год лучше, спокойнее и продуктивнее. В этом деле нам показалась полезной статья How To Slow Down to Go Faster Than Ever in Software Development, которую написал Lemi Orhan Ergin. А ее перевод мы публикуем ниже.
Читать полностью »
Ольга Стратанович, Program Director в ProductSense и Chief Product Officer в «Киноплан», рассказала о ключевых отличиях в мышлении и навыках менеджера продукта и менеджера проекта.
Профессия «менеджер продуктов» пока еще молодая в СНГ, но уже востребована на рынке. Компании с собственной разработкой ищут человека, который сможет выпустить и сопровождать продукт. Заказная разработка тоже нуждается в продуктовом подходе. Но хороших менеджеров продуктов на всех не хватает, поэтому возникает необходимость брать джуниоров из других областей.
Самой близкой областью считается менеджмент проектов. Я часто встречаю бывших менеджеров из заказной разработки, которые перешли в менеджмент продуктов. Они не понимают, какие изменения должны произойти на новой работе. Обычно они думают, что это всего лишь следующая ступень проектного менеджмента.
Давайте разберем, чем отличается менеджер продукта от менеджера проекта.
В предыдущей статье я рассказал, какие надстройки для Jira мы сделали, чтобы рабочий флоу стал максимально удобным, а тикет — исчерпывающе информативным. В сегодняшней статье мы решим другую задачу.
Дано:
В предыдущей статье я рассказал, какие надстройки для Jira мы сделали, чтобы рабочий флоу стал максимально удобным, а тикет — исчерпывающе информативным. В сегодняшней статье мы решим другую задачу.
Дано:
Всем добрый день!
До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.
Поехали.
Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.
О роли Delivery Manager мы говорим не часто. Конечно, это не часть “семьи” Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком “Разработчик”. Вот, пожалуй, и все.
Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.
— Привет! Ну ты как, кто, где? — давно не виделись.
— Да я менеджер ИТ-проекта в большой компании.
— О, PRINCE, риски, экстремальное управление, финансы. Сложно!
— Да не. Так, ТЗ от клиента технарям и обратно таскаю за деньги. Фигня.
Вот такой вот реальный диалог. И, думается, диалог актуальный для многих компаний, особенно, если они не входят в десятку крупнейших вендоров и интеграторов, где процессы всё же отлажены и проекты выглядят именно как проекты. Понятно, почему многие компании малого и среднего бизнеса отворачиваются от самого понятия «проект» и работают как карта ляжет. В таких условиях работа прожект менеджера больше похожа на работу надсмотрщика, который приходит к программистам и просит быстрее накодить фичу, потом идёт к тестерам и призывает тестировать прямо сейчас и без критикалов, потом идёт с тимлидами разворачивать это на продакшене и с фиолетовым лицом приносит баги от клиента, причём независимо от того, минорный баг или критический, — лицо всегда одинаково фиолетовое, а речь начинается со слов: «У клиента всё упало». Правда, ситуация кажется нездоровой? Давайте о ней поговорим.
Типичный прожект менеджер, который не очень понимает, что такое управление проектами
Читать полностью »
Опыт руководителя проекта проявляется в том числе и в мелочах, которые позволяют ему работать эффективно. Особенно это важно в начале проекта, когда нужно быстро запустить все процессы. Опытный РП приходит на проект с чемоданчиком собственных инструментов и приемов, позволяющих стартовать без долгих обсуждений, как лучше организовать работу.
На тренингах иногда спрашивают о фишечках, приемах и технологиях. Когда долго чем-то занимаешься, то такие вещи становятся само собой разумеющимися, и сложно сразу ответить на вопрос. Тем не менее я попробую выделить некоторые, на первый взгляд незначительные моменты, которые помогают экономить время и силы. Маленькие лайфхаки.
Читать полностью »
– У нас не получится уложиться в сроки!
– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!
Последнее время часто слышу: они провалились, потому что неправильно выбрали методологию разработки продукта. Вот если бы вы применили Scrum/DevOps/Agile/еще что-то, то все было бы хорошо. Похоже, эти люди кое-что не понимают в разработке софта.
Еще Алистер Коуберн в своей статье проанализировал разные программные проекты, которые выполнялись по разным моделям от совершенно «легких» и гибких до очень «тяжелых» и формализованных. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись. Отсюда Коуберн сделал вывод о том, что эффективность разработки не зависит от модели процесса.
Существуют десятки методологий, но ни одна не гарантирует результат. В каждом новом проекте процесс должен определяться каждый раз заново. В основном, выбор процесса зависит от разрабатываемого продукта и людей, участвующих в разработке. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.
Читать полностью »
В этом году я побывал на конференции Data Crunch в Будапеште посвященной аналитике данных и Data Engeneering. На эту конференцию приглашают спикеров из Linkedin, Uber, Github и множества компаний "второго эшелона", где люди делятся своим опытом или же рассказывают об инструментах по работе с данными. Ну и что мне так же интересно — это пообщаться с участниками конференции по понять, насколько наша российская действительность отличается от Европы и США.
Из того, чтобы я отметил это:
Разработка софта считается плохо измеримым процессом, и кажется что, чтобы ей эффективно управлять, нужно особое чутье. А если интуиция с эмоциональным интеллектом развиты не очень, то неизбежно будут сдвигаться сроки, проседать качество продукта и падать скорость поставки.
Сергей Семёнов считает, что это происходит в основном по двум причинам.
И предлагает подход к оценке и контролю процессов на основе объективных данных.
Ниже видео и текстовая версия доклада Сергея, который по результатам зрительского голосования занял второе место на Saint TeamLead Conf.
Читать полностью »
