Проектный дайджест #2
Что интересного писали про управление проектами на vc.ru за прошедшую неделю.
Прошла очередная неделя, а это значит, что пора вспомнить, что писали на vc.ru о проектах, проект-менеджерах и проектном управлении. Пилотный выпуск вроде не вызвал отторжения у уважаемой аудитории, так что мы продолжаем формат.
Итак, начнем с теории.
Теория проектного управления
В рубрику попадают несколько материалов по проектным методологиям и их применению
- Кому подойдет Scrum
Ребята внедряют скрам и рассказывают, чем он полезен. Увы, коротко и справочно, но наверняка кому-то поможет с матчастью. - Кому нужен Agile, и как выбрать подходящий стиль работы в методологии
Хорошее сочетание базовой теории Agile и Scrum и личного (корпоративного) опыта. Главный вывод - экспериментируйте с подходами. Авторы перешли к гибридному Scrumban, сократили спринты и придерживаются принципа "морального права на ошибку". - Ретроспективы для Agile-команд: цели, задачи, особенности проведения
Коротко и довольно содержательно о ретро как ключевом компоненте скрама и о том, как не сделать его бесполезным (вредным). Ну и да, там же реклама их платформы для проведения ретро. - Регламенты: инструкция по применению
Не совсем ПМ, но, кажется, материал будет полезным и для ваших процессов, и для проектов. Автор пишет про то, чем хороша и чем плоха регламентация и как сделать, чтобы регламент читали и использовали, а не только хранили. - Управление изменениями, как PM-у правильно работать с изменениями на своём проекте
Собственно, сабж. Местами суховато и перекос в сторону теории, но в целом хорошо раскрытая полезная тема.
Навыки менеджера проектов
В этот раз материалов немного.
- Что бы я хотел знать на старте карьеры? Советы руководителей агентств проджект-менеджерам
Сибирикс спросил у руководителей IT-агентств (кстати, что это?) о том, что нужно знать ПМу. Советы разнообразные - в основном, предлагают прокачать общение, инструментарий, любознательность, системный подход, умение планировать и полеты на спортивном самолете. Мемы и реклама своей книги - в комплекте. - Как вождение НРИ учит менеджерским практикам
НРИ - это настолки, а автор - Dungeon Master (не гуглите картинки, плиз). И оказывается, вождение в ролевых настолках отлично помогает в работе. Тут тебе и решение конфликтов, и седация токсиков, и поддержка мотивации, и предупреждение выгорания, и умение складно говорить... В общем, автор умело агитирует. - Проблема первого проекта — взвалить на себя обязанности заказчика, проджекта, тимлида и вообще всех
Кристина из МТС рассказывает, как однажды вкатилась в РП и чуть не погибла. Потому что всё взвалила на себя, - а так делать опасно и неправильно, потому что (а) выгоришь, (б) не вырастешь, (в) не вовлечешься, (г) останешься без помощи и ресурсов, (д) расслабляет и дезорганизует команду.
Управление проектной командой
Непосредственно на эту тему вышел, по-моему, один материал, и то не про ПМ как таковой:
- Дрим Тим или идеальный ролевой состав в командной разработке
Но материал любопытный. Авторы и есть проектная команда по разработке ИТ-продукта, а публикация - это описание состава их команды и функционала каждой роли: владелец продукта, проект-менеджер (назван "управляющим проектом"), бизнес-аналитик, системный аналитик, аналитик данных, системный архитектор, технический лидер, программист, QA, дизайнер интерфейсов, технический писатель, специалист техподдержки, системный администратор, маркетолог. Фух, получилось больше, чем обычно выделяют в онлайн-курсах для ПМ.
Еще пару материала выделим за тему управления знаниями и обучением. - Как не слить силы и бюджет, организуя обучение сотрудников своими силами
Такой мини-гайд по тому, как подступиться к обучению персонала в условиях сокращения бюджетов, с ссылками, чек-листами и рекламой тг-канала, естественно. - Как платформа управления знаниями упрощает онбординг
Авторы в основном рекламируют свою платформу, но по случайности довольно последовательно дают матчасть по организации онбординга, которую можно реализовать на любом инструментарии. А еще они просили поделиться примерами хорошего и плохого онбординга, но никто из читателей так и не поделился.
Советы бывалых
В этой рубрике - разного сорта и разной ценности опыт, который может пригодиться в работе РП.
- Космос внутри: почему enterprise-решения и «ванильный» discovery несовместимы
Очень умная девушка рассказывает очень умным языком про процесс сбора требований и прототипирования - За 5 месяцев до дедлайна: как мы успели сделать систему онлайн-обучения к 1 сентября
Материал уровня хабра - рассказ о том, как едва, но успели сдать проект, интегрирующий множество микросервисов, как подбирали стек, как выкручивались из ограничений, как проектировали архитектуру. - «Рецепт нового блюда — та же разработка»: как опыт в общепите и бизнесе помогает в IT
Своеобразный кейс - автор рассказывает, как перешел из IT в свой не-айтишный бизнес (общепит) и как навыки проектного управления помогают ему в совершенно новой области. - Постановка задач в бизнесе: как ставить задачи, чтобы они выполнялись верно и в срок
Около-проектное обсуждение и опыт того, как сделать так, чтобы ваши задачи не только дошли до исполнителя (и желательно в корректном виде), но еще и были выполнены. Много советов, рекомендаций и даже комментариев читателей. - Пожиратели жизни: Что мы знаем о хронофагах, и как их усмирить
Маст-рид (или нет) для проджектов, любящих попялиться в мемы, новости, дашборды, - да хоть куда, лишь бы не работать. Автор (тоже ПМ) провел эксперимент над собой, выполнил сложные подсчеты и сделал открытие, что время тратится на всякую фигню. Рекомендации - всё лишнее отключить, использовать планировщики, а также (цитата) "сделать красивую канбан-доску, чтобы все в офисе видели вашу продуктивность". - Целых две статьи о том, что в сложной разработке бриф не нужен и можно справляться записями разговоров и автоматической документацией, а также привлекать на встречи исполнителей, чтобы избежать глухого телефона при передаче задачи.
Инструментарий
Материалы про сервисы и приложения, которые помогают управлять проектами.
- Как правильно организовывать доски в Notion и не только?
В компании автора используется 50 досок Notion, и он в них не путается, потому что использует свою методологию. Публикация демонстрирует на примерах, как создавать такие доски и как правильно отразить рабочий процесс на доске. Много скриншотов и обсуждений. - Как мы сделали из Figma инструмент для проектного менеджмента и спокойствия наших клиентов
А тут то же самое, но в Фигме и существенно короче. - Управление SEO-проектами в ClickUp. 8 советов по оптимизации рабочего процесса
Большой гайд по продукту и по управлению проектом с его помощью.
Вот такой была неделя публикаций о проектах на vc.ru. Если мы пропустили какой-то ценный материал — поделитесь им в комментариях. Предложения по формату и содержанию - приветствуются!
До новых встреч!
Миллениал решил донести основы Agile, когда все про него уже забыли?
вам картинка не понравилась? она из публикации, которая упомянута в дайджесте. И еще у вас есть кнопка игнора!
они в неё не в состоянии, такие хотят страдать и прям так, чтобы все видели, как они мучаются)
Мне не нравятся торгаши, впаривающие неработающую фигню
Какая проектная методология работает лучше всего для продуктов в стартапе? Экстремальное программирование не предлагать, это как ответ "а хз", а водопад не подойдет тк никто тебе инвестиций на 2 года вперёд может не дать, могут и на полгода раунды траншей.
Я без критики и не адепт аджайла, мне правда очень интересно чтобы понимать
Agile, вообще не про продукты... так вы еще и неучи
Сурьезно? Сам аджайл это про подход к разработке, но этот подход не имеет смысла без конкретных фреймворков и методов, которые таки продуктовые
Вовсе нет.. Agile, это принцип для реализации. А реализовывать нужно что-то, это что-то и есть продуктовая разработка. Просто в России Путин дал деньги ФРИИ, в которых набрали с улицы Красинского Илью, Дмитрия Калаева, Тертычного Глеба и прочие профаны. Вот они много лет всякую чушь рынку и втирали. Ща, эту лже.знания никак не вылечить уже...
А что значит "вовсе нет"? Есть манифест, вы по нему как работать собираетесь? Или вам всё -таки для внедрения принципов в конкретную операционную деятельность нужны определенные фреймворки, методы и тд, а у них во главе угла стоит именно продукт, с ролью po и продуктовыми практиками? PS Понятия не имею кто эти товарищи, учился и продолжаю за рубежом, собственно 99% всех котируемых сертификатов для SM или AC выдаются зарубежными компаниями, они же основатели практически всех практик. Есть масса переведенной литературы, ещё больше на английском, это же не какие -то тайные знания.
Приходит заказчик и ты начинаешь его реализовать по принципам Agile. Сейчас литературу пишет все кто хочет, читать то нужно первоисточник и думать головой.
Сразу понятно, что вы этим не занимались. Приходит к вам заказчик, говорит хочу такой продукт. Дальше то что?) Вы командой пробовали управлять? Это же набор ежедневных конкретных действий, а не абстракция
Самое печальное, что этим занимаются профаны.
"говорит хочу такой продукт" - т.е. человек уже определил рынок, бизнес, зачем ему что-то нужно, функционал - это и есть продуктовая разработка. Все отсальное, это кодинг - тут и нужен Agile и Scrum.
Нет, дорогой "профи") заказчик вам говорит "хочу такой продукт" - это значит, что он имеет смутную идею о продукте, а чаще всего какую-то "боль", которую надо закрыть. И вот-тут то и вступает PO, который является профи в этой области, он выдвигает гипотезы, их проверяет, рисует CJ, USM, VSM и тд и тд, и только после того как гипотеза прошла проверки, определены базовые метрики, начинается бизнес-анализ с архитектурой, и только потом дело дойдет до SA и непосредственно написания кода. Более того, если это scrum, то каждый кусок продукта вы обязаны проверить, собрать обратную связь и снова прогнать ч\з этап продуктового анализа. Все это вместе и называется продуктовая разработка. А agile вам может задать какие-то базовые принципы, которые ни как не померить и на хлеб не намазать. А вот, к примеру, Scrum или Safe или Kanban даст уже какую-то канву (события, роли, артефакты и тд).
"хочу такой продукт" - это значит, что он имеет смутную идею о продукте. Расскажи мне ыксперт откуда эта идея беретя и для чего он хочет чтобы подрядчик ему это сделал?
Ну, вот как вы думаете, откуда берутся идеи? Ну, так, на вскидку. Вот идея у вас написать комментарий по теме, в которой вы не шарите, она откуда взялась? Вот оттуда же берутся запросы на разработку. Только, когда за идеями стоят сотни миллионов вложенных денег, они слегка осмысленнее чем у вас
Ты же у нас экспер. Причел человек, платит свою деньги, хочет чтобы програмисты ему это закодили.
- Почему он хочет именно это, а не что-то другое?
- Зачем ему это?
- Что он с этим будет делать дальше?
- Как будут выводить на рынок?
- Как монетизировать?
- Какая стратегия развития?
- Откуда будут привлекать ресурсы?
Agile на эти вопросы не отвечает. А именно это и есть продуктовая разработка.
Мы по кругу ходим... Agile - это подход, зафиксированный в манифесте. Все, он не отвечает на вопрос "как?", он даже толком не отвечает на вопрос "что?". Вы его откройте и прочитайте. Он же на русском есть. В рамках аджайл подхода есть масса фреймворков, методов, методологий и тд. Вот они призваны ответить на вопрос как?. Дак вот, когда к вам приходит стейкхолдер, он как правило не хочет, чтоб вы ему что-то кодили. Ему плевать на стек, на ux\ui, на то какие будут интеграции, сколько нужно ресурсов на это и тд. Он вообще не шарит в разработке и продуктовом подходе. У него есть проблема. К примеру, в компании надо наладить внутренний обмен электронными документами с определенным уровнем секретности. Вот запрос. И заказчик понятия не имеет как это делать, он за то вам деньги и заплатит, чтоб вы как профи ему дали в результате готовый продукт, а точнее решили этим продуктом его проблему. А разработка продукта уже делится на Discovery и Delivery, и оба это процесса живут внутри продуктовой команды. Если у вас Discovery вынесен за команду, то тут никаких гибких подходов не надо, тк вам принесут конкретное тз, которое надо довести до прода и получившийся продукт потом поддерживать.
Это то я и пытаюсь донести, что Agile никак не связан с продуктовой разработкой. Это просто прницип взаимодействия исполнителя с заказчиком. Не надо Agile пихать везде!
Если быть точнее то Agile это один из подходов к управлению процессами. он имеет отношение к продуктовой разработке, если применяется на конкретном проекте, если не применяется, то конечно не рбаотает.
Agileне подход, а принцым. Нет не имеет отношения к продуктовой разработке, т.к. у продакт-менеджеров свои инструменты и принципы.
Сразу видно дилетанта. Agile не может быть принципом, да он состоит из 12 принципов закреплённом в манифесте https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/
но это подход к управлению процессом на проекте.
1. Взаимодействие с заказчиком - это процесс.
2. Взаимодействие с командой - это процесс
и т.д.
Вот в 12 - ти закреплённых принципах и строится как один из подходов к управлению процессами.
Но сам по себе Agile не может быть принципов, так как он не может быть истинным правилом (смотрите значение слова принцип) так как во время управления проектом в котором могут возникать различные нештатные ситуации, так и если проект большой разные сектора могут использовать разные подходы для достижения результата.
Продуктовая разработка - что вы вообще понимаете под этим?
ты сам то уже определись... Agile, это принцип, процесс или правила?
Давно определился см. выше.
Ты не смог это внятно донести. Если у тебя эту лажу покупают - торгуй! Хорошо, что в мире столько лохов
ну ясненько
Сколько я это гавно повидал под соусом Agile...
В итоге когда очередной говно Project Manager с курсов приходит и говорит мы ведём проект по AGILE... То через 4 месяца на его место приходит уставший, потрёпанный опытный менеджер проектов. И всем устраивает на проекте такой Agile