#знания

​Резюме или CV? (Part 1)

Пару слов об этих терминах, чтобы не путаться. Резюме (resume от фр.) – это более сжатый формат документа о себе, а CV (curriculum vitae) – это полная форма. Если первое больше распространено в русскоговорящих странах, Европе, то второе – в США и Канаде. Сейчас, говоря о CV, подразумевают, обычно, резюме. Поэтому не путайте эти понятия, мол, CV – это то же резюме, только на английском.
Я же буду говорить о резюме. Сейчас почти редко просят подробную информацию о вас.

Резюме как крутой блокбастер!

1️⃣. Eng/Rus versions
Раз я заговорил про английский, то, наше резюме должно быть в двух вариантах – английском и русском (для ИТ сферы это важно).
Если вы посылаете резюме на вакансию, которая написана на английском – так себе история.

2️⃣. Структура и последовательность тоже важны
• Ваше Имя и Фамилия
• Контакты (обычно, тел, e-mail, LinkedIn, Git – если разработчик)
• Локация
Плохо: Никаких детей, семейного положения, котиков и т.п.

3️⃣. Идентифицирующий заголовок
• Роль, на которую претендуете (job role – Node.js developer)
• Или позиция – Project Manager

4️⃣. Краткий текст о себе или Summary, содержащий
• 2-3 предложения о профессиональных ключевых моментах: совокупный стаж работы по вашему направлению, проекты, достижения (ачивки), с кем работали, что сделали. Тезисно, тегированно.
Плохо: длиннющий текст, подробное перечисление всех ваших скиллов, ваша история, взгляды на жизнь.
Представьте, что Summary – это 6-секундный тизер к вашему фильму-блокбастеру. Насколько крутым будет ваш тизер, настолько велика будет вероятность, что он привлечет рекрутера.

5️⃣. Ключевые навыки или Core skills
• 10-15 core skills
• Ключевые фразы, раскрывающие вашу экспертизу
• Фразы, релевантные для вашей позиции
Плохо: слишком мало или слишком много (20-30 скиллов), длинные предложения.

6️⃣. Секция – профессиональный опыт (желательно не длинный, но и не короткий):
• Название компании + локация + время работы
• Название позиции
• Выполняемые обязанности и достижения
• Применяемые технологии, методологии и программы
и т.д.
Плохо: нет конкретики, нет хронологии, нет достижений, слишком длинный текст.

Из-за длинного текста, продолжение будет в следующей части. Скоро.

#знания

Резюме или CV? (Part 2)

7️⃣. Другие секции: Образование
• Специальность, учебное заведение, год окончания
• Если несколько образований – укажите это в таком же ключе.
Плохо: длинный текст, инфа, не имеющая отношения к образованию.

В этой же секции, ниже, можно упомянуть какие-то курсы повышения квалификации, тренинги, волонтерскую деятельность – с датой их окончания. Также, стоит отметить, если есть какие-то заслуги и достижения, ученая степень.

8️⃣. Языки
Обязательно указать языки, которыми владеете. Если русский – родной – указать это. Знаете белорусский – напишите тоже. Лучше уровень владения указывать в соответствии с CEFR (A1-C2).
Плохо: уровень владения в виде диаграммы/графика, не указан родной язык.

9️⃣. Интересы
Также, рекомендую указать интересы: хобби и тематики, которыми интересуетесь. Желательно в одно слово, тегированно.
P.S. Если их не будет – не критично.

🔟. Рекомендации (референсы)
Данный пункт важный, но не критичный. Если есть рекомендации – это плюс к вашему резюме. Есть компании, которые не ленятся и интересуются, звоня прошлым вашим работодателям. Бывает, если даже нет рекомендаций, все равно могут сделать запрос о вас. Тут как повезет. Но т.к. у вас есть рекомендации, это уже говорит о том, что вы распрощались с предыдущим/-ми работодателем/-ями в хороших отношениях.

❗️ Общие рекомендации к резюме:
- Формат резюме: doc, pdf (лучше оба);
- Желательно 2 стр., для джунов – 1 стр.
- Рекомендованный шрифт – Calibri, Arial, Cambria;
- Названия секций и заголовков – ЗАГЛАВНЫЙ регистр букв (uppercase);
- Оптимальный размер шрифта – 11-15;
- Курсив – только для вторичной и важной информации;
- Главная информация – ориентирована по левой стороне листа;
- Будьте точны в цифрах, орфографии, пунктуации и ваших данных;
- Использовать только профессиональное портретное фото. В противном случае не ставьте ничего. Но лучше с фото.

Друзья, это все рекомендации по резюме. НО! Есть еще сопроводительное письмо (cover letter). Если интерес есть, голосуйте. Если нет, то следующий пост будет об интервью. Это непростая тема и насущная одновременно.
Обнял.🙏🏻

#знания

Сопроводительное письмо / Cover letter

1️⃣. Сперва определимся, есть ли у вас опыт в данной должности или нет. Пишем при откликах на вакансии, в личных сообщениях рекрутерам и HR, если:
• Нет опыта/недостаточно
• Если у вас очень большой опыт
• При большой конкуренции
• Если не получили ответ в течение 3-4 дней после отклика на вакансию

2️⃣. Содержание и суть
• Если вы подходите на вакансию, напишите, как бы вы могли помочь компании в решении проблемных моментов, исходя из описания вакансии (требования, обязанности);
• Рассказать о своих ключевых скиллах, подходящих под эту вакансию;
• Быть честным;
• Для каждой компании – индивидуальное письмо;
• Max размер письма – пол листа А4;
• В конце письма, желательно подпись с именем и e-mail (можно и телефон);
Плохо: не писать о ваших целях и что хотите сделать; дублировать всю инфу из резюме; просить или клянчить, умолять; оправдываться за навыки, которых у вас нет;

Пример адекватного письма:

Здравствуйте, Ольга.
Меня зовут Михаил Иванов. Меня заинтересовала вакансия Project Manager в вашей компании.
Изучив внимательно вакансию, хочу обратить внимание в ней на такие моменты как …, с которыми я имел дело на … проектах с таким/схожим направлением последние 2 года. Имел в подчинении min …, max … людей, вел проекты с … (география, например) заказчиками.
Детальней о моем опыте – во вложенном резюме.
Буду рад пообщаться и узнать друг друга получше.

С уважением,
Михаил Иванов
mikhail-ivanov@gmail.com
8 (029) 000-00-00

P.S. Если описание вакансии на английском, то рекомендую и сопроводительное письмо писать на английском. Это логично.
За содействие в материале о резюме и сопроводительном письме отдельно благодарю Ольгу Калион.

Следующий пост будет о собесах, моего фидбека и их нюансах. А после собесов начнем уже разбираться в самом, что ни на есть менеджменте.
Обнял. 🙏🏻

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

Будни рекрутера 😬

#знания

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

На самом деле, скрин выше это мой реальный кейс. Я слышал о неадеквате и странном поведении рекрутеров, но с таким столкнулся впервые. Я и предположить не мог, что все настолько печально. Кстати, с подобными картинами сталкивался только в сфере ИТ. Частенько встречается отсутствие чувства такта, сразу переход на “ты”, часто пишут не к месту смайлики (много), формулировки предложений и механика переговоров оставляют желать лучшего, периодически вводят в заблуждение относительно вакансии по требованиям и условиям труда, часто игнорят с ответом, очень часто не дают обратную связь по результатам тестового задания и т.п. И о-очень редко встречаются профессиональные 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? Выход есть! Когда вы выполняете тестовое задание от очередной галеры, рекомендую оформлять все задания в облако, а ссылку прикрепить к резюме. Можно сказать, это и будет вашим портфолио, взглянув на которое, можно будет увидеть ваши старания.

#мнение

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

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

#знания

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

Начнем с введения. Кто такой 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 или жизненный цикл проекта – это последовательность фаз проекта, задаваемая исходя из потребностей управления проектом.
При этом, мониторинг и контроль действует и на Планирование, и на Завершение, как и Исполнение на Мониторинг и контроль и Планирование.

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

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

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

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

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

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

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

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

#знания

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

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

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

#знания

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

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

📣 Способы управления проектами
Бывают разными. Много перечислять не буду. Озвучу одни из самых распространенных:
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 раза. Однако на выходе получили уникальный, качественный и очень крутой продукт.
Можно ли этот проект назвать успешным?

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

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

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

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

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

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

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

#знания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#знания

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

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

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

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

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

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

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

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

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

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

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

#знания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не знал, что меня ждет❗️(часть 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️⃣ Скорость работы, знания и взаимодействие
Буду краток, скорость работы пониже и знания похуже наших разрабов. Тут ничего не поделаешь. Однако взаимодействие в некоторых местах полегче будет, ребята тебя больше слушают и меньше включают своё эго, которое у нас раздуто в разы по сравнению с этими ребятами. Стоило бы поучиться.

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

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