Дмитрий Сорокин | Дневник_Манагера

#знания

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

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

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

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

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

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

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

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

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

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

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

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

#знания

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

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

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

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

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

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

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

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

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

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

#мойстатус

Всем Алоха!🖖🏻

Еще находясь в Дубае, я уже начал присматривать новое место работы. На данный момент пройдено около 22-23 интервью (именно взаимодействие от отклика/переписки с рекрутером до технического интервью). Итого - 1 оффер. Мог бы быть возможный 2-й оффер. Почему возможный? Потому что много иностранных компаний хотят и готовы взять к себе на "борт"хороших специалистов, однако не все так просто. Ну например, украинские компании оформить в штат не резидента по украинскому законодательству не могут, если нет украинского гражданства/ВНЖ и разрешения на работу - это основные проблемные моменты, которые мешают. Да, можно зарегитрировать ИП и работать по договору подряда (гражданско-правовой договор). Но это уже другая история.
Еще, заметил, что частенько беларуские компании, почему-то, жлобятся на нормальную зп (ну камон!), при этом периодически планка с требованиями довольно высока. Еще раз, подчеркну, что не все так делают. Я не претендую на звание эксперта управления проектами, однако это мои наблюдения путем сравнения на протяжении длительного времени (я говорю о своей позиции PM) с требованиями и условиями, что предлагают те же украинские компании.

Относительно недавно я узнал о таком Jobs portal как Djinni.co. Хочу сказать, что динамика на этом сайте в разы лучше, чем даже в LinkedIn. Спустя 2-3 недели, мое резюме оказалось в Топ-10 по Минску. Оттуда, собственно, я и получил первый оффер меньше, чем за месяц (решение еще принимаю).

Итак, 20-23 интервью ~ 1 оффер. В принципе, неплохо. Зато за это время я смог лучше подготовиться, чтобы проходить интервью. Я даже составил серьезные вопросы, которые задаю интервьюерам. В итоге, получается полноценное интервью, в котором обе стороны узнают друг друга лучше.
Да, кстати, рекомендую вести борду (доску) по интервью в Trello. Это поможет структурировать ваши карточки-компании, которые вы заполняете с соответствующим фидбэком и сортируете в соответствии с нужным статусом по вашему флоу.

UPD: А сами вопросы я оформил в Гугл Док таблицу, вышло около 18. 1 вкладка = 1 компания. Это помогает проанализировать каждую компанию в отдельности и избавляет необходимость напрягаться вспоминать, о чем говорил рекрутер про свою компанию и вашу должность.

Следующий пост на этой неделе я опубликую по Требованиям и Иерархической структуре работ проекта (ИСР/WBS).

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

Все проекты закрылись! 😲

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

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

Ситуация была в подвешенном состоянии. Договорился с руководством. Начал потихоньку присматривать новые места. Дабы не было затратно по деньгам, я принял непростое для себя решение вернуться в Минск, хотя я мог остаться там. Быть на связи и работать удаленно сейчас вообще не проблема, ну а я сэкономлю на аренде, еде и прочих затратных статьях. Дубай ведь город дорогой :)

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

Подтвержденный инсайд
Всегда придерживался этой политики и придерживаюсь сейчас: что бы ни случилось, я всегда рекомендую налаживать хорошие взаимоотношения с людьми, несмотря на негативный исход. Потому что репутация в работе - чуть ли не самый важный элемент. Сейчас тебе все равно, а спустя какое-то время судьба тебя сведёт с твоими бывшими коллегами в другом месте. И в каких отношениях ты с ними был раньше, будет определять твой будущий результат. Ну или не результат. It’s up to you.


P.S. Несмотря на то, что это мои заметки, следующий пост я продолжу по теме менеджмента. Киньте реакций, если читаете меня. Мне будет приятно.

#мойстатус #знания

Я не знал, что меня ждет❗️(часть 2)

7️⃣ Инструменты и рабочие тулы
Jira, Confluence, Gitlab, Google Docs — нет! Тут этого не было. Slack и Bitbucket только были. И то, не особо ими и пользовались. Ребята юзали Azure DevOps, в котором у меня не было опыта от слова вообще, MS Teams, Office 365, в который входят различные продукты и сервисы от Microsoft (там же и почта Outlook, которую используем как оф. канал общения с клиентами), виртуальная машина — всё связано с Microsoft.
Поясню. Здесь в Эмиратах всё секьюрно, и местные власти предпочитают Microsoft (офис который у нас тут есть) Гугловским сервисам, секьюрность которых, кстати, чуть пониже Гейтсовских. Поэтому работа с отдельными файлами — это норма. И файлы грузятся в онлайн облако — OneDrive. Сбрасывать клиентам документацию не ссылкой на файл, а отдельным файлом. Да, вот так вот 🙂. Напомнило мне, когда я работал в банке, и бразуером пользовались Internet Explorer (до того, как он стал Edge). Приходится привыкать и адаптироваться.

Но нужно было как-то улучшить это положение. Что сделал я:
Создал пространство в Google Drive для компании, настроил, чтобы было удобно работать с файлами, покрутил настройки безопасности, дал доступы нашему менеджменту и разработчикам. Этот вариант был только для нашей компании. Но хоть как-то упростить работу.
Создали пространства компании в Jira и Confluence (как не крути, Jira удобнее и функциональнее Azure, а в Confluence удобнее хранить документацию о проектах в виде архива. Тем паче эти две тулы одной компании, секьюрность которой высокая).
Также, создал Time reports и обучил разработчиков корректно его оформлять. Один проект = один Time report. Но так как некоторые разработчики работали на нескольких проектах одновременно, пришлось один отчет создать общим, в котором они писали каждый день, каким проектом занимались, что именно делали и указывали количество часов, затраченных на работу. В дальнейшем, кстати, время трекать будем иначе, более точно, т.к. разработчики могут указать не реальные часы. Все это нужно для того, чтобы менеджмент понимал прозрачность работы и мог корректно считать зарплату, но и другие выплаты.

8️⃣ Митинги
Как я писал выше, соотношение разработчиков к проектам + малые сроки на некоторых проектах были проблемой. А в одном проекте настолько жесткий дедлайн, что частота встреч только отнимала бы время разработки и это реально боль. Взвесив все за и против, я решил внедрить только самые важные события: спринт (у нас недельный), стендап (раз-два в неделю), ретроспектива (раз неделю/две), PBR (это когда пересмотр бэклога и его наполнение — раз в неделю). Всё! И это работает. Демо не на всех проектах присутствует. Вероятно, такие взаимодействия с заказчиками были налажены до меня. Но на одном проекте, где заказчик не из гос. аппарата, я настраиваю процессы по канонам всеми нам знакомым практикам и использую нормальные подходы. Чего только стоит консолидация из требований задач и их эстимация (оценка) в соответствии с известными практиками. Разумеется и демо там есть.

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

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

Это основные моменты, над которыми нужно работать. Работы хватает более чем. Скоро грядут изменения в виде подкрепления человеческих ресурсов. Надеюсь, это положительно отразится на работе.

#мойстатус #знания

Я не знал, что меня ждет❗️(часть 1)

До приезда в Эмираты я не знал, что меня ждет. А когда приехал, я увидел другие законы, мультинациональность, другие правила и систему, отношение к работе и т.п., отличные от наших беларусских реалий. Да даже в Украине и России не так. Все, что написал выше, всё другое. Но давайте по порядку.

1️⃣ Компания — аутсорсинговая, хотя иногда мы разрабатываем собственный продукт для продажи.

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

3️⃣ Знакомство
Я созвал встречу в meeting room, предварительно подготовив материал и тему встречи.
Суть: каждый по кругу коротко рассказывает о себе пару фактов: как зовут, позиция в разработке, откуда родом, хобби, и своя уникальная особенность. Я не записывал на бумагу, я решил записать на диктофон, предварительно спросив ребят разрешение. Да, о себе я тоже рассказал, разумеется.
После я адаптировал тест Майерс-Бриггс для ребят и сбросил всем шаблон, рассказав суть теста и обозначив сроки выполнения.

Для чего это было нужно. Некоторые факты дадут нужную мне информацию о человеке, а заодно некоторые ребята узнают факты о своих коллегах. Вероятно, что не все так хорошо знакомы и знают о хобби друг друга и уникальных особенностях. А тест — это больше прикладная тема, которая может примерно показать, какой у кого тип личности (отсылка на книгу Патрика Ленсиони — 5 пороков команды).

4️⃣ Разработчиков пока немного (есть еще удаленная команда), а проектов столько, что не хватает людей. Либо если бы было времени больше, то было бы терпимо. Это плохая практика, когда некоторые разработчики работают параллельно на нескольких проектах. И это проблема: жонглирование человеческими ресурсами и временем, чтобы максимально безболезненно закрыть проекты. К сожалению, такое счастье мне досталось от предыдущего менеджмента. Но мы всё пофиксим! Вопрос времени.

5️⃣ Разработчики давно не были в отпуске
Как все знают, утомление и выгорание может быть ближе, чем мы думаем. К сожалению, отпустить даже одного в отпуск не представляется возможным, поэтому я решил, что можно хотя бы укрепить моральное состояние ребят — развитие в корпоративной культуре. Например, с ходу сделал раз в две недели Pizza Day, т.к. этого у них не было. Я был удивлен их радостным лицам, когда ребята могли отвлечься, пожевать их любимую пиццу и поговорить на разные темы. Мелочь, но работает. Также, я начал хвалить ребят за работу, которую они сделали хорошо, в срок, проявили инициативу и т.д. И это работает! Оплачиваемые овертаймы. Раньше с этим были проблемы.

6️⃣ Не настроены процессы в разработке
Scrum, Kanban, Waterfall, XP... Не, не слышали! Нельзя просто так взять и вслепую начать внедрять Скрам, Канбан или какую-то другую методологию. Есть много факторов, позволяющих понять, что лучше применить (есть еще способ испробовать разные подходы), но это уже другая история. Так как компания работает преимущественно с гос. учреждениями, то тут Scrum может не покатить. Канбан — менее регламентирован (разве что инструмент доски покатит). Пришлось пойти ва-банк — создать свой легковесный фреймворк (это громко сказано) лишь с пару обязательными ритуалами, техниками и подходами. Он чем-то похож на легковесный, гибкий фреймворк p3express. Кстати, мне он очень нравится. Я уже об этом говорил ранее. Легкий в понимании, простой в использовании. Но натренироваться нужно (сам еще в процессе).

#знания

ЧАСТЬ 2
К сожалению, из-за ограничения в символах пришлось разбить текст на две части.

Шаблон Резюме проекта можете скачать здесь.

Есть еще план управления проектом. Его иногда путают/объединяют с уставом проекта, но это неверно.

PMBoK говорит: «План управления проектом — это документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль. Он интегрирует и консолидирует все вспомогательные и базовые планы, полученные в результате процессов планирования.»

Устав более статичен. План управления проектом говорит о том, как ПМ и команда проекта будут исполнять и контролировать этот проект, чтобы добиться результатов в границах и параметрах, описанных в Уставе. Этот документ более динамичен, он изменчив по ходу проекта, так как сразу определить все процессы не удастся.

Спасибо всем, кто читает и ждет. В следующий раз поделюсь своим фидбэком из работы в Эмиратах. 😉

ЧАСТЬ 1
Наконец я проснулся от релокационного сна.😃 Хоть и есть небольшая “сонливость”🤤.

Сперва объясню, почему можно назвать проект успешным, если он превысил срок разработки вдвое, а бюджет в 3 раза, при этом, на выходе мы получили уникальный, качественный и очень крутой продукт. Выше я публиковал треугольник PMI. Этот треугольник позволяет понять наглядно, какой результат мы можем получить: сфокусировавшись на цене и времени или на цене и скоупе, или скоупе и времени — мы можем получить качественный продукт. Но практически всегда никогда мы не получим качественный продукт, если попытаемся сфокусироваться на приемлемой цене за разработку, приемлемом тайминге и не огромном и понятном скоупе работ. Это, можно сказать, аксиома, в жизни это не работает. Опустим единичные случаи. Поэтому, исходя из этих данных, мы можем назвать наш проект успешным. В жизни же, этот проект может оказаться неуспешным, потому что заказчик так посчитает. Но тут уже зависит от изначальных требований и Acceptance Criteria. Кстати, позже об этом поговорим, как и о DoR, DoD.

#знания

Устав проекта/Резюме проекта/План управления проектом

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

PMBoK говорит: «Устав проекта — это документ, выпускаемый инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. Он документирует бизнес-потребности, допущения, ограничения, понимание потребностей заказчика, высокоуровневые требования, а также новый продукт, услугу или результат, который планируется создать.»

Из чего он состоит:

● Значение проекта;
● Измеримые цели проекта и соответствующие критерии успеха;
● Высокоуровневые требования;
● Высокоуровневые описания, границы и ключевые поставляемые результаты проекта;
● Совокупный риск проекта;
● Укрупненное расписание контрольных событий;
● Заранее утвержденные финансовые ресурсы;
● Список основных заинтересованных сторон;
● Требования к одобрению проекта;
● Критерии выхода из проекта;
● Назначенный руководитель проекта, сфера ответственности и уровень полномочий;
● Участники проекта.

Если необходимо изменить зафиксированное в Уставе, значит для ПМ или Исполнителя это повод к пересмотру договорных отношений с Заказчиком. Соответственно этот документ делает Заказчик или Спонсор, а не ПМ или Исполнитель. Это важно!

Шаблон адекватного Устава проекта прикрепляю здесь.

Устав не обязательно создается. Вместо него может быть договор, в котором будут прописаны все необходимые условия. Также, есть резюме проекта. Это схожие по сути документы, но все-таки отличаются. Он может быть более коротким.

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

Итак, предположим нам нужно подготовить резюме проекта.
На этом шаге нужно определиться, что из себя представляет проект.
Спонсор проекта готовит простой одностраничный документ — резюме проекта, в котором отвечает на несколько вопросов:
Цель проекта — какой продукт, услугу или результат нужно получить? (лучше сформулировать по SMART);
Выгоды — зачем мы это делаем?
Какие материальные/нематериальные ценности мы получим от проекта?
Требования — без каких условий проект/результат проекта не имеет смысла?
Сроки — сколько это займёт времени?
Бюджет — сколько это будет стоить?
Риски — что может пойти не так? Какие неопределённые события могут поставить проект под угрозу?
Роли — кто будет принимать участие в проекте?

Потом резюме можно править и расширять — этим займётся менеджер проекта.

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

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

Спасибо, что читаете мои заметки и реагируете на них. Я ценю это. С Новым Годом тебя, который читает это сообщение, и твоих близких! 🥳🎅🏻🎄

#знания

​Новая версия Scrum guide

2 недели назад анонсировали новую версию Скрам гайда. За 25 лет существования фреймворка, он менялся всего несколько раз и каждый раз это большое событие в мире Эджайла.

Следуя тренду последних лет, Cкрам стал более инклюзивным. Из гайда убрали слова тестирование, релиз, система, характерные для мира разработки софта. Людей из других сфер, которые только пробуют фреймворк, отталкивали эти термины, мол "у нас такого нет, поэтому Скрам нам не подходит". По этой причине их заменили на более нейтральные 🤐.

Сам текст будто бы прогнали через сервис glvrd.ru - он сократился с 19 страниц до 13, став менее формальным и более дружелюбным.

В этом же и минус новой редакции - общие фразы не объясняют как именно использовать Скрам. Например, в Sprint Review раньше были конкретные советы как проводить митинг: проходиться по done, обсуждать ситуацию на рынке, релизы, бюджеты. Теперь все это упразднили.

❗В новой версии есть одно действительно важное обновление.

Раньше у команды была только Sprint Goal - микро-цель на ближайшие 2 недели. Теперь все микро-цели собираются в одну большую-мега-цель Product Goal, ради которой все затевалось. Такая цель очень нужна продактам, потому что помогает ответить на вечные вопросы "какой продукт мы строим и для кого?", на которых потом строится весь продакт-менеджмент.

Изменений в новом гайде много (полный список), но большинство из них косметические - это все тот же старый добрый Скрам.

Текст: Роман Ковалевский

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

Однако. Совпадение?

​Привет из жаркого Дубая! 👋🏻

Я немного потерялся из-за переезда сюда, решение соответствующих вопросов и все такое. Также, на новом месте увидел, что предстоит отстроить процессы и сплотить команду, можно сказать с нуля! 😬
Вот сейчас, например, объяснял ребятам, что такое Скрам в общих чертах 🙂. Весело, конечно, но что поделать. Буду тогда ещё писать в заметках, как я буду выстраивать процессы и создавать сплоченную команду.
Следующий пост будет про устав, как и было обещано.

P.S. Кто ответил в задаче выше, что проект можно назвать успешным — молодцы, потому что это правильный ответ. Кто ответил нет, ничего страшного. Я объясню, почему его можно назвать успешным.
P.S.(2) На фото — вид из офиса, а конкретно моего кабинета.

❓ЗАДАЧА
Проект превысил срок разработки вдвое, а бюджет в 3 раза. Однако на выходе получили уникальный, качественный и очень крутой продукт.
Можно ли этот проект назвать успешным?

#знания

Проектное управление, его сферы и способы

Сферы проектного управления могут быть разные:
Информационные технологии, строительство, переналадка какой-то линии крупного завода и т.д. Мы же сфокусируемся на сфере ИТ.

📣 Способы управления проектами
Бывают разными. Много перечислять не буду. Озвучу одни из самых распространенных:
1. Методы – Kanban, Lean
2. Фреймворк – SCRUM, Nexus, SAFe, LeSS (последние три применяются, как надстройки SCRUM)
3. Методологии – Waterfall, XP, PMI, PRINCE2, RUP и др.

ℹ️ Маленькая справка

* Метод – своего рода некая гибкая модель (итерационная, Agile).
* Фреймворк – предоставляет скелет нашего будущего приложения.
* Методология – набор руководящих принципов и процедур для управления проектом.
* Библиотека – набор готовых компонентов, которые мы можем использовать в нашем приложении.

Самые популярные способы на сегодняшний день – SCRUM, Kanban, PMI. Хотя многое зависит от проекта, культуры компании, пожелания заказчика и проч. факторов.

🔺Проектный треугольник PMI
Как мы уже знаем, большинство проектов имеют определенную дату окончания, бюджет и объем работ. Это трио времени, денег и объема часто называют проектным треугольником, потому что при внесении изменений в один из этих элементов меняются оба других.
В большинстве проектов, по меньшей мере, одна сторона треугольника фиксирована, то есть ее невозможно изменить.

Также, типы проектов бывают:

🔹По сферам деятельности
1. Технический
2. Организационный
3. Экономический
4. Социальный
5. Смешанный

🔷По длительности
1. Краткосрочный
2. Среднесрочный
3. Долгосрочный

🔷По степени сложности
1. Простые
2. Сложные
3. Очень сложные

В следующий раз поговорим про Устав проекта📜. Что это, зачем он нужен и обязателен ли он вообще.

❓А сейчас задачка. Кстати, вполне реальный кейс:
Проект превысил срок разработки вдвое, а бюджет в 3 раза. Однако на выходе получили уникальный, качественный и очень крутой продукт.
Можно ли этот проект назвать успешным?

⚠️ Реакции на задачу будут ниже.

#знания

Знаю, что тут есть ребята ПМы уже с опытом, поэтому, чтобы они не скучали, хочу поделиться интересным вебинаром, который пройдет 1 окт в 19:00 о проектном фреймворке в заказной разработке p3express.
Лично я этот фрейм знаю и мне он тоже нравится. В первую очередь своей простотой и структурированностью.

Спикер:
Стас Спасёных, основатель студии Штрихпунктир. Он выбрал p3express и расскажет, почему, как он адаптировал фрейм и что это даёт.

Ссылка: https://bit.ly/2ENT4EM

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

ОТКЛОНЕНИЕ ОТ ТЕМЫ ПОСТ

Уже как месяц я ничего не публиковал на своём канале. И этому есть веские причины. Я бы не хотел отклоняться от темы канала, но сделать вид, будто ничего не происходит, тоже не могу. В стране, где я живу – в Беларуси – после президентских выборов 9 августа стало неспокойно, потому что последней каплей народа были сфальсифицированные выборы, в которых очередной раз "победил" Лукашенко. В период с 9 по 11 августа народ подвергся жестокости со стороны властей (били, пытали, есть убитые). По сей день люди выходят на улицы, выражая своё недовольство. Протесты максимально мирные. Лишь силовики вносят хаос и дестабилизацию.

Эта ситуация затронула многие фирмы и предприятия в разных отраслях. А не так давно и IT сектор. 2 сентября Департамент финансовых расследований Комитета государственного контроля Беларуси устроил обыск в офисе компании PandaDoc (#savePandaDoc), которой владеет и руководит бизнесмен Микита Микадо, живущий в США. С чем связаны обыски, пока неизвестно. Компания работает в белую, платит налоги, недавно проходила международный аудит. В числе задержанных — директор офиса Дмитрий Рабцевич и менеджер по продукту Виктор Кувшинов. В отношение последнего возбуждено уголовное дело по статье о хищении путём злоупотребления полномочиями, которая предусматривает до 12 лет тюрьмы. Четверых посадили и навесили уголовные дела. 🤦🏻‍♂️

Это все печально. Но в это непростое для белорусов время приходится ретироваться, адаптироваться и быть гибким, как касательно обстановки вокруг, так и в отношении работы.
Что касательно работы, то, самое интересное, на сегодняшний день у меня есть два оффера: один с работой на ремоуте дома, а другой с релокейтом в ОАЭ. Покидать родную страну не хочется, особенно в такой важный период времени, но развиваться и зарабатывать за меня никто не будет, а значит, нужно делать непростой выбор. Везде есть свои нюансы. И без них никак.

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

#знания

ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ И ПРОГРАММЫ

Начнем с введения. Кто такой PM я писал в самом начале дневника, можете освежить в памяти здесь. А сейчас – сферы влияния руководителя проекта:

•Проект
•Организация
•Отрасль
•Проф дисциплина
•Другие сферы

Наглядный пример: зона действия руководителя проекта (по уровням):
1️⃣. Команда проекта [dev team] (руководители публично-частных партнерств. Руководители ресурсов);
2️⃣. Спонсоры [sponsors] (органы управления, управляющие комитеты, ОУПы);
3️⃣. Заинтересованные стороны [stakeholders] (поставщики, заказчики, конечные пользователи).

Компетенции руководителя
Есть такая штука, как треугольник талантов PMI, состоящий из трех ключевых составляющих, которые характеризуют руководителя проекта:

1️⃣. Техническое управление проектами
2️⃣. Лидерство
3️⃣. Стратегическое управление и управление бизнесом

Если команда проекта и спонсоры всем понятны, то кто такие заинтересованные стороны проекта или стейкхолдеры?
Это лица или организации, которые активно участвуют в проекте или интересы которых могут быть затронуты как положительно, так и отрицательно в ходе исполнения или в результате завершения проекта.
Для удобства понимания, как реагировать и общаться с ними, есть удобная схема (график) в виде осей ординат X, Y, где по оси X – интерес, а по оси Y – власть. Ось Х условно делим на две части: первая часть имеет значение «Низкий» (интерес), вторая часть оси X – «Высокий». Ось Y делим так же: первая часть – «Малая» (власть), вторая часть оси Y – «Большая». Рекомендую начертить на листке для лучшего понимания и восприятия.

Ориентируемся по оси X:
1️⃣. Над значением «Низкий» находится значение «Наблюдать (минимальные усилия)». Это же значение соответствует части «Малая» по оси Y.
2️⃣. Над значением «Высокий» располагается значение «Держать в курсе дел». Это же значение соответствует части «Малая» по оси Y.
3️⃣. Над значением «Низкий», после «Наблюдать», находится значение «Удовлетворять», которое соответствует по оси Y значению «Большая».
4️⃣. Над значением «Высокий», после «Держать в курсе дел», находится значение «Активно управлять», которое соответствует по оси Y значению «Большая».

Итого, если на проекте у одного из заинтересованного лица, интерес низкий и власть малая, то, в соответствии с графиком, мы можем «Наблюдать (минимальные усилия)». Если власть большая и интерес высокий, то мы выбираем «Активно управлять». Надеюсь, понятно.
Подчеркну, что этот график лишь ориентир и не является истиной в последней инстанции. Он может дать опору, от чего отталкиваться. Многое зависит от ситуации. Не всегда может быть при невысокой власти и большом интересе «Держать в курсе».

Основные процессы и их связи
1️⃣. Инициирование (Initialization),
2️⃣. Планирование (Planning),
3️⃣. Исполнение (Executing),
4️⃣. Мониторинг и контроль (Controlling and Monitoring),
5️⃣. Завершение (Closing).

Это группы процессов, которые называют Project Life Cycle или жизненный цикл проекта – это последовательность фаз проекта, задаваемая исходя из потребностей управления проектом.
При этом, мониторинг и контроль действует и на Планирование, и на Завершение, как и Исполнение на Мониторинг и контроль и Планирование.

Друзья, открываю комментарии. Напишите, получилось ли у вас изобразить график правильно.

Следующий пост долго ждать не заставит. Следите. Обнял.🙏🏻

#мнение

Как вы могли заметить по моим постам, информацию я даю дозированно и поэтапно. По-сути, это всё – этапы подготовки, развитие и фидбэк моего статуса. Поэтому я публикую посты не только для себя, но и для вас, чтобы я мог и сам вернуться к ним, освежить что-то в памяти, проследить свой прогресс, поделиться новым опытом. Для меня важно быть профи в любом деле, и в менеджменте – не исключение. Плохим специалистом вы всегда можете быть в любой момент, а вот стать профессионалом — нет.

Друзья, я помню, что говорил о следующем посте по проектной тематике, особенностях, однако понял, что, возможно, кому-то будет интересно узнать немного про кейсы в интервью для PM. Поэтому, как всегда, голосовалка выше покажет. Жду активити от вас. 👣
Обнял.🙏🏻

#знания

Интервью или просто "собесы"

На самом деле, скрин выше это мой реальный кейс. Я слышал о неадеквате и странном поведении рекрутеров, но с таким столкнулся впервые. Я и предположить не мог, что все настолько печально. Кстати, с подобными картинами сталкивался только в сфере ИТ. Частенько встречается отсутствие чувства такта, сразу переход на “ты”, часто пишут не к месту смайлики (много), формулировки предложений и механика переговоров оставляют желать лучшего, периодически вводят в заблуждение относительно вакансии по требованиям и условиям труда, часто игнорят с ответом, очень часто не дают обратную связь по результатам тестового задания и т.п. И о-очень редко встречаются профессиональные HR и рекрутеры, которые на самом деле знают своё дело, умеют грамотно писать, разговаривать и излагать свои мысли, а эмоции и личные мотивы не смешивают с работой, т.к. руководствоваться только мордашкой кандидата и/или насколько он мало задаёт вопросов (любопытен) – это не комильфо.

Итак, немного о своём статусе. На сегодняшний день я так и не нашел адекватного предложения после проброса с оффером. Коронавирус все еще не отпускает ситуацию по рынку труда. Чтобы не сидеть на попе ровно, пришлось устроиться не по направлению, чтобы прокормить себя. Параллельно мониторю рынок дальше, прохожу различные тренинги и курсы, интервью, читаю соответствующую литературу, провожу нетворкинг.
Из последнего, прошел авторский тренинг Agile Project Management от Александра Лемешевского и моего фамильного тёзки Михаила Сорокина. Скажу просто: если будет еще набор, однозначно рекомендую на него попасть. Это тот тренинг, в котором практика очень приближена к реальным ситуациям на проекте + ценная теория.

Интервью

Для ПМа, также, как и для Scrum-Master, Project Coordinator, Product Manager интервью, как правило, делится на два этапа:
1️⃣. Интервью по проверке английского языка: диалог с преподом/HR/рекрутером/руководителем, тест по английскому, тестовое задание на английском – обычно такие варианты.
2️⃣. Техническое интервью – это не про код, это про методологии, фреймворки, с какими технологиями и тулами приходилось работать на проекте, немного computer science и кейсы (реальные или смоделированные ситуации на проекте, которые имеют какой-то вопрос и который вам необходимо решить).
Касательно кейсов и ответов на вопросы есть в интернете необходимая информация, например, PMBoK, книга Гейла Лаакмана Макдауэлла “Cracking PM interview” или tproger.ru. Хочу подчеркнуть, что на многие вопросы нужно знать либо точный, либо максимально приближенный к нему ответ – кто знает, кто будет задавать вам эти вопросы, руководитель или рекрутёр. Последний вообще может по бумажке сверяться, что выглядит так себе, согласитесь)
Насколько я вижу, в РФ требования к ПМ могут быть чуть ниже в сравнении с требованиями в РБ: многие аутсорс-компании работают с зарубежными заказчиками, а значит и язык – must have. Если это продуктовая галера, то с языком может быть проще. Россия большая, там много продуктовиков, соответственно, сами понимаете. Однако подчеркну, что все зависит от конкретной компании и ее требований.
Сейчас почти все интервью проходят дистанционно по Skype, Zoom, Webex или по телефону или где-то еще. Думаю, не нужно детально расписывать о том, что до интервью стоит прошерстить инфу о компании, отзывам, инфу о вакансии (если есть), подготовить самые важные вопросы (лучше до 3-5). Также, рекомендую подготовить спич о себе, чтобы он был лаконичным и ёмким. Чтобы, рассказав, собеседник понял, кто вы, чем занимались, что делали и какой результат имеете. И да, на английский язык все переводим и запоминаем.
Еще один инсайд: если для разработчиков портфолио – это залить свой код на GitHub, то какое портфолио может быть для PM? Выход есть! Когда вы выполняете тестовое задание от очередной галеры, рекомендую оформлять все задания в облако, а ссылку прикрепить к резюме. Можно сказать, это и будет вашим портфолио, взглянув на которое, можно будет увидеть ваши старания.