#знания

СОДЕРЖАНИЕ ПРОЕКТА (часть 1).
Требования и иерархическая структура работ проекта.

ℹ️ Сперва определения 💬

* Описание содержания продукта (Product scope description) — это текстовый документ, который последовательно (сначала на высоком уровне, а затем более детально) уточняет характеристики продукта, услуги или результата, описанного в уставе проекта.
* Критерии приемки (Acceptance criteria) — четкий перечень условий, которые должны быть выполнены, чтобы результаты проекта могли быть приняты заказчиком. Это чек-лист, согласно которому заказчик будет принимать работу и проверять, насколько она соответствует его требованиям.
* Поставляемый результат (Deliverable) — любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта. Т.е. какие артефакты проекта мы должны передать заказчику в итоге. Например, разработали мобильное приложение, то помимо приложения мы передаем исходный код, документацию, обученных сотрудников, подготовленных для поддержки и сопровождения приложения.
* Исключения из проекта (Project exclusions) — формулировка того, что именно находится вне содержания проекта. Т.е. описание того, что в проект не входит.

Касательно последнего — очень крутая штука! Например, проектный менеджер с заказчиком обсуждает устав проекта и работы по нему. Потом подключается еще один стейкхолдер, который предлагает “запилить” какую-то фичу, пусть это будет раздел аналитики на сайте, который мы разрабатываем. Нет проблем! Однако в первоначальной идее данной фичи не было предусмотрено. И в данном случае менеджеру лучше прописать в исключениях, что в рамках данного релиза этот функционал разрабатываться не будет. Это избавит от возможных недопониманий или даже конфликтов. Представьте себе, что спустя какой-то промежуток времени этот самый стейкхолдер приходит к руководителю и спрашивает, как продвигаются дела по его фиче. Тот вспоминают, что был такой разговор. Идут к вам спрашивать, а у вас ничего нет, кроме слов, мол, мы же перенесли это на другой релиз. Это возможный конфликт.

* Ограничения проекта (Project constraints) — то, в чем ограничивает нас заказчик. Например, в выборе субподрядчиков, технологии, методологии и т.п. Но ограничения по срокам и бюджету в этот пункт не вписываем (для них есть другое место).
*Допущения проекта (Project assumptions) — факторы, которые считаются верными без предоставления доказательств и демонстраций. Здесь описывается влияние этих факторов на проект. Это предположения, с которыми согласны вы и спонсор проекта. Без этих предположений дальнейшее планирование проекта невозможно.

Итак, все начинается с базового плана. Данный план нужен для сравнения текущего положения дел в проекте с изначальным планом. Т.к. в бизнесе могут происходить изменения, то и в плане тоже должны происходить изменения.

Существует три вида базового плана:
- По содержанию работ
- По стоимости
- По расписанию

Это же наш Треугольник PMI, где изменения в одном повлекут изменения в других.
Любые коррективы с базовым планом нужно согласовывать со спонсором проекта.

Базовый план по содержанию проекта состоит из требований к проекту, соответствующей иерархической структуры работ (ИСР) и ее словаря.

Сперва мы создаем высокоуровневые требования. Для этого мы готовим вопросы, которые впоследствии задаем заказчику. Допустим, мы сами это делаем (есть различные варианты сбора требований).
После того, когда все желания заказчика задокументированы, необходимо разделить их на требования и исключения.
Хорошие требования — это те, которые имеют четкий критерий завершенности (Definition of done/DoD).
Все требования должны быть задокументированы и согласованы со всеми стейкхолдерами.

#знания

СОДЕРЖАНИЕ ПРОЕКТА (часть 2).
Требования и иерархическая структура работ проекта.

Иерархическая структура работ (ИСР) или Work Breakdown Structure (WBS) — это список работ, которые необходимо выполнить, чтобы успешно завершить проект. ИСР формируется на базе требований к проекту и отражает только те работы, которые нужно выполнить в ходе проекта. Это основа планирования проекта.

Очевидный пример ИСР, это сборы для отпуска — мы пишем списком, что нам нужно собрать. Допустим, чемодан: перечисляем все вещи, которые нужно положить в него. Далее, рюкзак — все вещи, которые кладем туда. Документы: паспорта, билеты, ПЦР-тест, и т.д.

Важно декомпозировать все работы до того уровня, чтобы мы могли ими управлять. Все работы, что выше по списку — управляем, те, что ниже — должны знать, кто их будет выполнять, сколько нужно времени на это и как проверить, что работа готова. Нижний уровень называют пакетным уровнем. Делегирование + контроль исполнения.

Детализируя работы, менеджер должен знать, какой специалист будет нужен для конкретных/-ой задач/-и. Иначе он не сможет управлять работы проекта.

Обычно, хорошие примеры получаются на примере постройки дома.

Верхний уровень:
1. Подготовка фундамента
2. Строительство стен
3. Строительство крыши
4. Прокладка электрики
5. Подготовка сантехники
6. Отделочные работы и т.д.

Далее, детализация верхнеуровневых работ:

Фундамент
1.1 Подготовка котлована (вырыть, поставить блоки, армировать и т.д.)
1.2 Обрешетка фундамента
1.3 Заливка фундамента
1.4 Заливка площадки и т.д.

Когда делать ИСР? 🤔

Зависит от того, на каком этапе к нам попал проект. Если на этапе тендера, то можно построить высокоуровневую ИСР. Когда становится точно известно, что проект будет делать наша компания-исполнитель, то лучше сделать более детальную ИСР. Если проект уже стартовал, есть устав проекта, то ИСР должна быть полной и детализированной до уровня пакетов работ.
Подчеркну, что в ИСР неважно, в какой последовательности мы делаем работы, сколько они будут длиться и в какую сумму они обойдутся. Для этого у нас есть оценка и расписание.

Если требования вдруг меняются, при этом они все еще соответствуют целям бизнеса, то не стоит упираться и отказываться от изменений и ссылаться на ранее согласованные требования. Однако, обновить базовый план и ИСР будет нужно.

#мнение

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

#юмор #горькаяправда

- Почему вас зовут Иван, а не Николай?
- В графе имя я ставлю вам минус.

https://youtu.be/QI-bXKC2mvU

#знания

​Если команда не вкладывается в оценки 🤔

Эстимация — это бич всей разработки ПО. Давать точные оценки и попадать в них непросто. Негодуют клиенты, плачет команда, матерится менеджмент. ПМу тоже можно погрустить, но лучше что-нибудь предпринять. Чтобы исповедоваться реже попробуйте следующие благодетели:

1️⃣ Детализировать требования.
Чем четче сформулирована задача, тем точнее оценка.

2️⃣ Дробить фичи мельче.
Оптимально 1-4 дня.

3️⃣ Разбивать фичи на задачи (декомпозиция).
Выделяйте таски на бекенд, фронтенд, тестирование, и т.д. Максимум 1.5 дня на каждую. Если не выходит меньше — см. пункт 1.

4️⃣ Делать прототипы\инвестигейты на сложные фичи.

5️⃣ Проводить ретроспективы, обсуждать причины вылетов с командой.

6️⃣ Привлекать внешних спецов, если не хватает экспертизы.

7️⃣ Закладывать средний вылет в будущие оценки.

8️⃣ Трекать успеваемость (оценка vs. фактические затраты) по каждому члену команды. Доносить на митингах один-на-один.

9️⃣ Менять ребят, которые много и часто вылетают (>60% за 3-6 месяцев).

Вылет в 20-30% считается допустимой нормой, его стоит закладывать в начальную оценку.

#юмор

Поговорки к Agile активностям:
1. Демо: Сам себя не похвалишь – ходишь как оплеванный.
2. Стендап: В ногах правды нет.
3. Ретро: Кто старое помянет – тому глаз вон.
4. Планирование: Пути Господни неисповедимы.

#знания

Коррекция расписания проекта 📈

1️⃣ Сломать расписание (Crushing) — это значит добавить больше ресурсов с целью сокращения общей длительности проекта.
Например, один человек соберет все сливы за 2 дня, то два человека соберут их за 1 день. Суть метода в том, чтобы привлечь в проект больше людей и выполнить его быстрее.
Ломая расписание, ПМ смотрит на операции, лежащие на критическом пути проекта, и анализирует, можно ли их выполнить быстрее, добавив людей в команду, если у него есть такая возможность.

2️⃣ Быстрый проход (Fast tracking) — сжать расписание проекта за счет накладывания операций, которые обычно выполняются последовательно, одной на другую.
Например, тестирование, обычно, выполняется после раразботки, но есть такая вероятность, что тестирование можно начать за неделю до завершения разработки, тем самым завершить проект быстрее на неделю.
Данный метод сокращает сроки, но часто приводит в дополнительным рискам и увеличению стоимости. Допустим, наши раработчики в последний момент внесли какие-то изменения в работу, то тестировщикам придется начинать работу с самого начала, а то, что они делали раньше станет пустой тратой времени и энергии.

3️⃣ Изменить подход — смотрим на проект и находим иной путь его реализации. Например, отказ от написания собственного решения и покупка нового. То есть, не разрабатывать систему управления программой лояльности, а купить готовую, проверенную временем, ставшей уже стандартом в этой области.

4️⃣ Произвести переоценку зависимостей — это, допустим, когда мы можем приступить к разработке только тогда, когда мы купим мощный сервер (зависимость "Финиш-Старт"). Или же арендовать сервер. Или временно делаем на старом, пока не приедет новый.

5️⃣ Пересмотреть жесткие ограничения (думаю, тут и так понятно).


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

Навигация по каналу

• #знания — методы, практики, подходы и приемы.
• #полезности — шаблоны, документы, схемы, диаграммы, сервисы, порталы — все, что помогает быть более продуктивным.
• #мойстатус — о моем текущем положении в профессиональной сфере.
• #горькаяправда — взлеты и падения в ИТ сфере, взаимодействии с людьми и т.п.
• #юмор — мемы, видео, ситуации из практики.
• #мнение — авторское мнение на те или иные вещи в работе.
• #моимысли — свои размышления в разных областях и(или) подходах управления.
• #инсайты — осознание каких-либо вещей в процессе работы, лайфхаки, которые пришли со временем.
• #новости — новости и анонсы из мира проектного менеджмента в ИТ, методологий и фреймворков, методик и подходов, а также интересных событий в ИТ-сфере.
• #партнерский_материал — интересные материалы, сервисы, каналы, ивенты и прочая полезная информация на партнерской основе.
• #кейсы — случаи из моего опыта или опыта других менеджеров.

#реклама

Часто бывает так, что проект завершен в сроки и в нужном объеме, но клиенты все равно уходят из продукта. В этом случае стоит обратить внимание на проблемы в самом продукте.

Как? Проанализировать воронку, посмотреть на узкие места, протестировать гипотезы и спроектировать удобный для пользователей функционал. С этим поможет Product Games.

В своем канале Кристина Колузанова рассказывает про тестирование гипотез, фишки проектирования функционала, делится книгами и историями из жизни.

Хотите узнать больше про управление продуктами? Заходите в Product Games.

#мойстатус #горькаяправда

Алоха, друзья! 🖖🏻
Вижу, у нас прибавление на канале. Это приятно. Поэтому хочу еще раз напомнить новеньким, что тип канала — это журнал. Поэтому в нем я еще публикую заметки, помимо полезных постов.

Вот, например, буквально меньше недели назад я заболел короной…
Форма болезни проходит легко, слава Богу.
Да, это неприятная ситуация. Особенно, когда ты недавно устроился в новую компанию, запланирован созвон с иностранным клиентом, чтобы познакомиться, а ты внезапно уходишь в закат 😄

Благо я выбрал крутых ребят, которые по-человечески отнеслись к этой ситуации и всячески стараются поддерживать меня. Это чертовски приятно. Выбирайте правильную компанию, в которой будете работать.☝🏻

Как узнал о короне, сообщил об этом своему руководству и клиенту. Встречу перенесли на неопределенный срок, пока мне не станет лучше. Никаких проблем.

Во время больничного всегда есть, чем заняться. В моем случае я составил черновик с потенциальными вопросами по будущему проекту и людям на проекте, короткий план для мит & грита с клиентом. Если ты подготовлен — ты вооружен. Иногда, немного опасен 😄

Поэтому: «Самый лучший экспромт — подготовленный экспромт!».


Если набросаете сердечек, то я быстрее поправляюсь и опубликую обещанный пост 🙂.

​#полезности #знания
Что такое метод критического пути или сетевой график?

Критический путь (далее КП) — это все задачи, определяющие конечную дату запуска проекта. Если одна из задач нарушает график на один день, то весь проект будет задержан на этот срок. Часто возникают задачи, находящиеся вне плоскости критического пути. Это связано с отсутствием резервов времени в расписании. Резерв времени — срок, на который выполнение задачи может быть отложено без влияния на время запуска подзадач и дата завершения проекта не пострадает.

Чтобы определить КП, у нас должна быть известная последовательность работ. На базе диаграммы предшествования (Ганта) строится сетевой график. В сетевом графике узел выглядит так (изображение 1):
⁃ Ранний старт (Early Start) — самый ранний момент времени, в который может начаться запланированная операция.
⁃ Ранний финиш (Early Finish) — самый ранний момент времени, когда операция может быть завершена.
⁃ Поздний старт (Late Start) — самый поздний момент времени, в который может начаться запланированная операция, чтобы не задержать выполнение всего проекта. Здесь, если операция будет начинаться после этой даты, то весь проект будет задержан.
⁃ Поздний финиш (Late Finish) — самый поздний момент времени, когда операция может завершиться, не увеличив длительность всего проекта.

Например, возьмем диаграмму предшествования маленького проекта по созданию веб-сайта (изображение 2).
На ее базе мы рисуем сетевой график (изображение 3).
Обращаем внимание, на схеме появилась информация об узлах. Для каждой операции в центральной ячейке сверху цифрой прописана длительность ее исполнения. В первом блоке “Выработка требований” займет 3 дня, “Разработка дизайна” — 4 дня и т.д.
Устанавливаем дату начала проекта (= дата раннего старта первой операции) — ставим 0 у первых операций в ячейке раннего старта. Затем, добавляем длительность операции к дате начала, чтобы получить ранний финиш для первой операции. В примере это 0 + 3 = 3 дня.
Далее, в ячейку раннего старта следующей операции вписываем цифру раннего финиша предыдущей операции. Если предшествующих операций много, то в качестве раннего старта последующей операции выбираем самую позднюю дату раннего финиша. Например, “Согласование ТЗ” предшествуют сразу две операции: “Выработка требований” и “Разработка дизайна”. В дату раннего старта мы ставим 4 — самый поздний вариант (изображение 4).
Повторяем такие же действия слева-направо по всему графику, проходя по верхним ячейкам и заполняя даты раннего старта и раннего финиша для всех операций. Дата раннего финиша получится 25 (изображение 5). Это значит, что проект по созданию веб-сайта можно выполнить за 25 дней.

Теперь — обратный проход
В нижнюю правую ячейку позднего финиша операции “Демонстрация заказчику” пишем день завершения проекта из ячейки выше (25). Вычитаем длительность операции из позднего финиша, чтобы получить дату позднего старта операции — это 25 - 1 = 24. Вписываем 24 в левую нижнюю ячейку.
Далее, переносим дату (24) позднего старта из операции “Демонстрация заказчику” в ячейку позднего финиша следующей операции “Исправление ошибок”.
Если у предшествующей операции много других, то выбираем самую раннюю дату позднего старта предшествующей.
В итоге получается такой график (изображение 6).

Ну и осталось заполнить центральную ячейку снизу для каждой операции. Для этого нам нужно посчитать временной резерв — отнимаем от позднего старта ранний старт. В операции “Выработка требований” это 1 - 0 = 1. В операции “Согласование ТЗ” — это 4 - 4 = 0. И далее в таком же ключе. Во всей диаграмме в центральных ячейках, где получились нули — это и будет наш КП, на котором задержка этих операций приведет к задержке всего проекта. Серой заливкой показан КП (изображение 7). У всех отвальных операций есть резерв, т.к. они не лежат на КП и их задержка не повлияет на сроки сдачи всего проекта.

Так как несколько изображений в пост закрепить нельзя, поэтому ссылки на изображения смотрите в тексте.
Чуть позже сброшу задание, чтобы потренироваться с критическим путем.

#знания #полезности

Итак, первая задачка по нахождению критического пути.
Условия просты:
Определить критический путь в этих работах.
Первая колонка — наименование работ (подсказка: последовательность — в алфавитном порядке)
Вторая колонка — длительность работ в днях
Третья колонка — взаимосвязанные работы

Start — от этой работы все начинается (у нас два старта).

Смотрим на предыдущий пост и пробуем изобразить на бумаге (рекомендую).
Комменты остаются открытыми для обсуждения.

#знания #полезности

Даю подсказку следующего шага — схема, изображенная справа на рисунке.

Вашим следующим этапом будет построить схему с предшествующими работами, указав зависимости: Ранний Старт-Ранний Финиш, Поздний Старт-Поздний Финиш.

#знания #полезности

Заключительная часть с задачей.

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

Итого, критический путь у нас будет — E, B, D.
Ориентируемся на нижние нули в центре блоков.
Надеюсь, снова объяснять, почему так не нужно.

Добавлю только, что построение КП в наших реалиях не является супер-обязательным, но это желательно. Есть факторы, говорящие о нецелесообразности построения КП с точки зрения трудозатрат.
Например, мой случай на одном из проектов, где моя команда интегрировалась в уже существующий проект к другой внешней команде по разработке, в котором мы используем Agile-подходы, а условия и сроки довольно гибкие. Да, это не означает, что КП нужно игнорировать. Я просто не увидел необходимости тратить время на него. В нашем случае видением развития продукта и сроками управляет непосредственно PO, а не заказчик. Заказчику важен результат. И то, что мы сами напланировали, мы должны выполнить.

Скоро расскажу немного о своем статусе в работе.

​#мойстатус 🎅🏻

Компания, в которой я сейчас работаю относится к домену финтех. Мы разрабатываем, преимущественно, мобильные приложения, иногда — веб. Компания небольшая, около 80+ чел.

Проект у меня пока один — разработка мобильного приложения для трейдинга для одного бренда (брокера). Наша минская команда ваяет продукт совместно с украинскими ребятами. Работаем по фреймворку SAFe (масштабируемый Scrum. Глоссарий терминов SAFe). Если коротко, то это большая команда, состоящая из нескольких подкоманд (= вагон, а все вагоны = поезд), каждая из которых занимается своим направлением (веб, мобилки, дизайн, etc.). В фреймворке есть несколько уровней. На уровне Team and Technical Agility — это Scrum-Master (в своей подкоманде эту роль выполняю я + менеджерю минскую команду), и Product Owner. На уровне DevOps and Release on Demand — это RTE (Release Train Engineer), System Architect/Engineer, Product Manager (их несколько), а также Business owners. Далее — уровень бизнеса и системы — это Solution Architect/Engineer, STE (Solution Train Enginner), Solution Manager, и последний уровень — Lean Portfolio Managemnet — зона бизнеса, транслируемая уже на весь Enterprise. На ней останавливаться не будем.
Почти все то же, что в Скрам, только тут больше людей, есть доп. церемонии для лидов и ответственных лиц каждой из подкоманд, новые роли и уровни компетенций. С некоторыми ролями я даже не пересекаюсь. В целом, все выглядит гармонично. Такие фреймворки, обычно, хорошо подходят для больших и/или сложных Enterprise-проектов.

Работаем мы с сервисом Microsoft Azure Devops, который является как таск-трекером, аналитикой прогресса работы, так и код-репозиторием и сервером.

Из ключевых особенностей жизни проекта:
Спринты — двухнедельные.
Ивенты: daily-meetings, PBR (Product Backlog Refinement aka Grooming), Planning, Demo (Sprint Review как такового нет), Retrospectives.
На PBR мы оцениваем в относительных единицах (Story Points) юзер-стори из подготовленного Product Owner’ом Бэклогом согласно практике Planning Poker. В оценке участвуют разработчики и QA.
На Planning, оцененные стори, мы закидываем в Спринт Бэклог и распределяем их на участников команды.
Также, следим за Remaining time в каждом тикете стори и задачи, чтобы был виден наглядный прогресс работы (эта функция имеется в Azure Devops).

А еще мне прям нравится, как проходит демо продукта:
Каждая подкоманда готовит короткую демо-презентацию с описанием Sprint Goal, что сделали/не сделали + наглядная демонстрация с шэрингом экрана. Созвон проходит в MS Teams, где собираются все участники проекта, а это около 140+ человек. На каждом стендапе спикера заказчики и стейкхолдеры могут задать свои вопросы. На все уходит около часа. Из-за подготовленности спикеров, демо выглядит четким. Пока что я не встречал еще такого уровня подготовки демо.

В общем, трейдить, конечно, это одно, но вот разрабатывать аппку для трейдинга — это другое. Если ты трейдишь, то эти знания не особо помогут в разработке приложения, т.к. нужно еще понимать, как происходит калькуляция ордеров, торговых приказов и т.п., какие есть особенности инструментов (ассетов), чем они отличаются, что такое хеджинг и неттинг, в чем их особенности и т.д. Сразу голова взрывается, но потом становится легче 🙂

​#юмор #горькаяправда

Тайный Санта заказчик🎅🏻, как бы, намекает.

Отличная новость! 🥳
Теперь реакции можно сразу ставить на сообщения.
Предлагаю затестить эту новую фичу от Телеграм на канале. Можно на этом сообщении сразу и прочекать. 🙂

Выходим из информационного отпуска 👊🏻

Если присмотреться, то публикаций не было около 1,5 месяцев. На то были свои причины. В первую очередь мне нужен был информационный отдых, т.к. скопилась некая усталость от инф. потока. Все-таки, непросто быть в ресурсе 24/7, 7 дней в неделю и 365 дней в году. Поэтому я воздерживался постить что-то незначительное или вообще ни о чем. Не люблю лить воду. Иногда где-то и проскакивает, но все мы не без греха. 😄

Поэтому я расскажу скоро про этапы жизненного цикла проекта. А именно — погрузимся в каждый этап отдельно — что входит в каждый этап, обязательные/необязательные пункты, какие-то особенности и т.д. Тема очень объемная, но интересная.

А подкиньте 🔥 кому не лень, кто еще здесь 😃

#горькаяправда #статус

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

Что касается проекта, то украинским ребятам, с которыми мы работаем, с 24-го февраля было точно не до работы, и минская команда старалась работать самостоятельно, несмотря на случившееся. Мы старались сохранять холодный рассудок и не сеять панику внутри команды. Однако, на второй день со своей стороны, видя ухудшение положения, мы поддержали украинских коллег словесно в нашем рабочем чатике, т.к. было видно, что им страшно.

Также, в виду возможного осложнения в моей стране и касательно мобилизации гражданских, моя компания прорабатывает план по защите своих сотрудников, вплоть до релокации.
Нужно быть готовым в любой момент.

Надеюсь, следующий пост будет и он будет в мирное время и по теме.

Берегите себя и близких. 🙏🏻♥️