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

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

Я уже, как-то говорил, что у меня есть Телеграм-группа по поиску работы в регионах Беларуси, России, Украине и Европе. Так вот я принял решение сделать фокус на то, чтобы сосредоточить соискателей и рекрутеров в одной группе. Из статистики скажу, что правильно настроенные процессы и администрирование дает плоды в виде откликов и даже офферов из группы. А в такой период это осбенно важно.

Буквально за пару недель с 2,5к подписчиков, группа увеличилась до 3,5к (на момент написания поста). Вся аудитория — целевая. Никаких ботов и нерелевантных сообщений, что очень ценно. Сейчас для меня важно, чтобы люди находили то, что искали, помочь им советом в оформлении постов, резюме, поделиться полезными материалами или просто советом.

Привет 👋🏻

Сидеть ровно нельзя 🚫
Нужно двигаться дальше, обучаться чему-то новому и совершенствовать текущие навыки. Жизнь не останавливается.🕊

Поэтому буду продолжать постить образовательный и жизненный контент дальше. Нас ждет объемная тема о ЖЦП (см. последний абзац).

P.S. Не забываем, что формат канала — мой дневник 📔

#юмор

Текущая ситуация на рынке ИТ 😁

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

Пока я готовлю материал по первой порции ЖЦП, рекомендую ознакомиться поближе со Скрамом на бесплатном курсе от Stepik.
Даже если вы знакомы с фреймворком, рекомендую повторить его, т.к. скоро я поделюсь обновлением Скрам Гайда этого года.

Подкинь огня 🔥

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

Новый Scrum Guide 2022 будет выпущен в начале мая 2022 года с существенным изменением: недавно введенная Цель продукта уже удалена.

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

Пока не будем визуализировать важность удаления Product Goal из Framework. Поэтому в свете этих предстоящих изменений scrumfacilitators подготовили некоторые свои продукты, которые можно скачать бесплатно здесь.

На днях я наткнулся на такую информацию, которую опубликовал Иван Селиховкин на своем канале. Процитирую:

«Коллеги, собрали информацию, опыт наших студентов и официальных представителей PMI кто был записан на экзамен PMP в марте-апреле и столкнулся с уходом Pearson VUE из России и Беларуси: https://selihovkin.medium.com/pearsonvue2022-3b3a08eacc42

В двух словах:
- очные экзамены в России и Беларуси не проводятся
- поддержка PMI рекомендует отменить экзамен и "перезаписаться" на онлайн-сдачу (имейте ввиду, что с российским адресом записаться на онлайн-сдачу все равно не получится, поддержка об этом не предупреждает)
- те кто сумел подвердить переезд / смену адреса - смогли успешно записаться на онлайн-сдачу, однако по последней информации есть сообщения от поддержки что без зарубежного ВНЖ/ПМЖ/гражданства у граждан России экзамен не примут

Информация может обновляться и уточняться - буду корректировать текущий пост или создавать новый.»

А вы в курсе про данную сертификацию, как, где и с какими условиями проходит? Может, у нас есть те, кто уже сдавал экзамен PMP? Я в курсе, но было бы интересно услышать и другие мнения.

Комменты открыл.

#мойстатус #новости

Тук-тук! 🦊 Проверка связи.

Пропал я с радаров что-то... много чего случилось. Но стоит, все же, и отметиться.

Сменил я, значит, компанию. Тут 👈🏻 я немного писал о трудностях проекта. Компания и люди были замечательные, но так случилось... Ребятам желаю твердо выстоять в непростые времена для всех нас (связанные с геополитикой, мы, беларусы, знаем, что к чему), офигенного роста и отличных проектов 🦾

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

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

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

В общем, сейчас вливаюсь, осматриваюсь. Работы очень много, от чего пропадаю с радаров своего дневника. Но обещанное я выложу. Буду стараться.

Спасибо, что следите.
Работаем 🦾

Алоха, друзья 👋🏻
Я тут вот чего подумал. Есть мысли написать немного про нашу внутрянку прямо из гейм дева либо отложить ее чуть на потом, и лучше в ЖЦП погрузимся , как и было запланировано?

#полезности #инсайты

Как выглядеть профессионалом в глазах коллег и заказчика?

Нам часто приходится общаться голосом в рамках проекта/-ов. Но задумывались ли вы о качестве своей связи когда-нибудь, например, как меня слышно на созвонах с командой, коллегами из дргуих команд, СЕО, заказчиком и прочими стейкхолдерами? Честно признаться до определенного момента я глубоко не погружался в этот поинт, пока на своем проекте я не узнал, что один из коллег использует сторонний микрофон для созвонов — стриммерский. Качество связи у него сразу повысилось в разы. И его приятно слушать. После этого я понял, что это классный кейс и его нужно тоже реализовать у себя.

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

А какие вы используете микрофоны на созвонах, поделитесь в комментах?

#юмор

Наконец, нашел крутой фреймворк, который разрешит все проблемы по управлению на проектах 😁

https://govno.works

Этот год оказался весьма непростым, но мы уверены, каждый смог собраться и сделать все возможное, чтобы этот мир стал немножко лучше. Но каждому из нас еще есть, к чему стремиться. 🦾
От каждого из нас зависит больше, чем вы могли бы себе представить.

Поэтому желаем в новом 2023-м году, чтобы каждый из нас, его семья, близкие и знакомые приблизились к миру еще ближе. Чтобы каждый жил в любви и гармонии, и уважении к друг другу. А также, чтобы мир IT не испытывал трудности в неспокойное время, и все ищущие могли найти свое рабочее место мечты.

С наступающим Новым Годом, друзья! 🎅🏻🎄
Берегите себя. 😉

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

Тех лид = твой друг

Есть золотое правило — если ты работаешь в команде, в которой есть Тех лид, а твой технический бэкграунд оставляет желать лучшего, то однозначно правильным решением будет дружить с ним не только с точки зрения прикрытия твоих слабых зон, но и помощи в управлении проектом. Правда, нужно четко понимать, кто есть кто на проекте, не перекрывать кислород ему тоже менеджерить, хотя и в рамках команды. Однако, все четко должны понимать, кто за что отвечает и куда не стоит заходить. Много брать на себя не нужно, и в микро менеджмент лезть тоже нельзя.

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

Чуть позже расскажу про один из наших рабочих флоу взаимодействия при передаче требований в разработку. Интересно?

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

Как хорошо вы знаете Scrum? Нет, это не про рэгби, и в нем его там нет.

Очень рекомендую посмотреть интервью крутого Скрам-Мастера пока я готовлю очередной постец.
🔗 Ссылка

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

Флоу взаимодействия при передаче требований в разработку у нас на проекте выстроен таким образом (в нем мы привлекаем Гейм-дизайнера, Тех. лида и QA):

1. Гейм-дизайнер в данном случае у нас выполняет одну из функций БА — создает описание какого-то функционала в Confluence. Если у меня есть время, а Гейм-дизайнер занят, то описание могу создать я. Шаги флоу такие же, только на один короче.
2. Затем, передает его мне на ревью. Если у меня есть вопросы, мы их обсуждаем и правим при необходимости на месте там же (вносит правки строго тот, кто описывал фичу. Другой лишь оставляет комменты).
3. Если возникают технические вопросы в плане реализации каких-то моментов, то мы помечаем их. И после ревью с Гейм-дизом, я пингую Тех лида — договариваемся, когда он может уделить время пообщаться и ответить на вопросы.
4. Как только вопросы закрыты, я "нарезаю" стори для команды в Jira. Проверяю.
5. Затем, пингую QA для ревью этих стори. Если после ревью у него нет вопросов, то они попадают в Бэклог, откуда мы берем задачи для презентации команде. Если вопросы есть, он оставляет комментарии, и уже я дорабатываю стори.
Вот и все.

Ключевая практика — это связка работы с тех. лидом и QA. Данная практика хорошо себя показала, и работает у нас хорошо. Тех. лид и QA уже погружен частично в будущую задачу, что на презентации будет проще сориентироваться и оценить ее. А вероятность возврата задачи на доработку сократилось где-то на 45%.

Данный флоу — не 100% гарантия качества на вашем проекте. Тут может быть много нюансов. Например, размер команды, опытность участников, даже характер и отношение к работе.
Если не знаете как быть, то, как минимум, есть такая схема. А там уже можно ее подтюнить по ситуации.

#юмор

А вы все еще грумите на проектах? 😁

#знания #полезности #горькаяправда #инсайты

Еще пару интересных правил на нашем проекте, о которых мы [участники проекта] договорились между собой:

1. Мы не пишем в личку по рабочим вопросам, чтобы никакая ценная инфа ненароком не пропала. Особенно уместно, когда сотрудник увольняется. Прикиньте, его аккаунта уже нет, а в его личке была ценная инфа. Печально, да?

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

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

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

1️⃣ На моем месте работы мой проект впал в литургический сон, так как заказчик тормознул разработку, как минимум по двум причинам:
Причина №1: Им нужно изучить юридические вопросы в разных Штатах, так как для проекта это имеет серьезное значение, чтобы продолжить разработку в рамках следующего этапа.
Причина №2: Экономический кризис в США, который затронул большинство компаний относительно сокращений штата сотрудников. Вы, наверняка, знаете об этом.

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

2️⃣ Я уже говорил ранее, что у меня есть свой проект. Так вот, в один прекрасный момент ко мне пришла мысль: “А почему бы не превратить это дело в стартап и развиваться дальше, чтобы была не только Телеграм-группа”. Действительно, почему бы и нет! Проанализировав ситуацию, я понял, что мне ничего не мешает и у меня есть все необходимое для старта. А раз я менеджер, то я должен организовать все по красоте.

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

Моей главной задачей было использовать текущие ресурсы, возможности и знания, чтобы это было менее затратно с финансовой стороны. Таким образом, первым делом я организовал рабочее окружение для работы себе и команде:
- Slack — для коммуникации
- Notion — для документации
- Google Drive — хранилище материалов
- Figma — пространство для дизайна
- Miro — для графиков, быстрых заметок, ретро и прочих вещей
- другие тулы для ретро, оценки задач и т.д.

Далее, я пригласил всех текущих ребят в эти сервисы, сделал структуру чатов в канале, в пространстве с документацией, папки в хранилище, пространство в Figma и Miro.

Затем, я взялся за документацию — составлять планы о том, что уже есть и что нужно, описывать структуру проекта, команду, функционал продукта, дизайн-систему, определился с целью, каналам развития, что и как нужно улучшить в текущем состоянии, бизнес-план и т.д. В этом всем мне очень хорошо помогает ChatGPT. Благодаря четким запросам, он способен выдавать отличные решения. Если вы его еще не используете в своей работе, то очень рекомендую. Думаю, позже я опишу несколько кейсов его использования в своей работе и повседневных кейсах.

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

Поиском нового коммерческого проекта я пока повременю по причине того, что я почти год был без нормального отпуска, а также, хотелось бы плотнее взяться за развитие своего продукта. Хотя, уже я обновил свое CV, составил универсальное CL (cover letter), которое буду адаптировать согласное каждой вакансии, подготовил борду для поиска, сравнительную таблицу компаний, вопросы рекрутеру и руководству, возможные вопросы мне со стороны работодателя и ответы на них, summary о себе. То есть, если мне что-то попадется интересное или предложит работодатель, то я уже буду готов.

Следующий пост сделаю по стадиям проекта. Разберемся в них подробнее.

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

Как работать с рисками и для чего они нужны в проектном менеджменте?

Как мы знаем, риски занимают одно из самых важных мест в проекте. Я напишу, зачем нужно определять риски, как и на что они влияют и как с ними работать.

🪩Overview
Работа с рисками помогает нам понять, какие есть/будут или могут быть препятствия в ходе разработки продукта. Своевременное реагирование на те или иные риски позволит избежать сложностей в ходе разработки продукта. Если позаботиться о риск-менеджменте заранее, то это сэкономит много времени и нервов на идентификацию во время их возникновения.
PMBOK рекомендует управлять рисками в 4 этапа: Инициация, анализ, планирование, мониторинг и контроль.
Риски бывают разные. Например, технические, со стороны бизнеса (заказчика), человеческого фактора, системные, политического характера, финансовые и т.д.
Рекомендуется определить риски до стадии планирования проектных работ (на стадии инициации) после сбора информации и требований о проекте.
Стратегии реагирования на риски: Transfer, Accept, Mitigate

Есть множество подходов и практик, как вести риск-менеджмент план (реестр рисков) и как на них реагировать. Расскажу один из способов с точки зрения практики.
Для начала нужно отталкиваться от того, что это за продукт, его домен, бизнес-цели, для чего и для кого продукт, сроки разработки, модель договора, какие технологии будут применяться в разработке, какие сервисы будут подключаться в процессе и какие будут использоваться после выпуска в продакшен, etc. Все эти и другие детали помогут определить риски. Чем больше мы задаем вопросов, тем больше можем определить возможных рисков. Некоторые риски можно определить быстро, например, ограниченный бюджет в сравнении с объемом работ — работ больше, чем выделено бюджета на проект. Это риск.

🏋🏻Практическая часть
Итак, для этапа инициации рисков PM собирает всю команду на встречу, на которой каждый участник озвучивает потенциальные риски. Задача — собрать как можно больше рисков (50-100). Затем, выделить самые критичные, например, 20-30. Все риски нужно распределить в таблицу (реестр рисков) относительно “причина-риск-эффект”.
Затем, PM организовывает встречу с лидами проекта. Каждый участник оценивает риск из таблицы по 10-бальной шкале с точки зрения “Вероятность” и “Последствия”. Встреча заканчивается.
Далее, PM считает важность рисков как “Вероятность” умноженное на “Последствия” и сортирует список по убыванию “Важности”. PM обозначает риски, превысившие границу “Важности” в списке.

📅Планирование
Фактически, на данном этапе происходит управление проектом. Для каждого критического риска, которые мы выделили, необходимо придумать стратегию, которая наш проект от него обезопасит:

1. Transfer. Переносим ответственность за последствия риска на третью сторону (заказчика, компанию партнера, страховую компанию, etc). Применять эту стратегию есть смысл, если мы сами не можем повлиять на риск и есть на кого эту ответственность переложить.
2. Accept. Принимаем ответственность за последствия риска на себя, но ничего не делаем, оставляем всё как есть. Применять этот подход есть смысл только когда с риском мы поделать ничего не можем, а делать трансфер на третью сторону неоправданно дорого.
3. Mitigate. Боремся с риском, принимая ответственность на него на себя. Для борьбы с риском хорошо иметь несколько планов. Основной, для того, чтобы риск подавить, и отходной, на случай если риск все-таки случился и влияет на проект:

• Основной план необходимо внедрять сразу до того, как риск случился. Он должен понижать либо “Вероятность”, либо “Последствия” риска. Здесь нам поможет запись рисков в формате “причина-риск-эффект”. Чтобы понизить “Вероятность” риска, нужно бороться с его причиной. Чтобы побороть “Последствия”, нужно защищать предмет его воздействия.
• Отходной план внедряется в случае, если меры по борьбе с риском не принесли результатов, риск случился и стал проблемой.

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

🔎Мониторинг и контроль
Это, скорее, процесс, чем этап. Его цель — поддерживать список рисков и план проекта в актуальном состоянии.


💡Заключение
Для проекта с командой в 15 человек, расходы на управление рисками составят 50–60 человеко-часов в месяц. При этом, будет идентифицироваться около 50 новых рисков, из них в среднем 10 самых важных будет планироваться и подавляться. Положив, что критичный риск отбирает у проекта минимум 40 человеко-часов, мы получаем от 400 человеко-часов экономии ежемесячно.

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

🔗 Ссылка на шаблон

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

Что если пересеклись два проекта: было изначально не качественное планирование и проработка рисков, которая привела к пересечению дедлайна двух проектов (часть 1).

Допустим, это случилось. В таком случае:

1. Экстренно собрать митинг с тим лидами и обсудить варианты решения (сокращения работ), чтобы уложиться в сроки.
2. С подготовленным планом организовать встречу с заказчиком/-ами и обсудить ситуацию с наложением сроков (Agile агитирует вести честное и прозрачное взаимодействие с заказчиком, чтобы качественно установить доверие друг с другом): чем это чревато и предложить варианты решения. Например, сократить некоторый объем работ/функционал, который не столь важен, приоритетен сейчас. Обычно, всегда получается к чему-то придти.
3. Делать часть работы менее качественно, использовать “костыли”.
4. Пригласить/нанять дополнительных исполнителей.
5. Узнать все о текущих проектах в системе — что они из себя представляют, каковы их задачи, требования и сроки, технологии/инструменты, бюджет, исполнители, кто заказчик.
6. Разобраться, как до меня были настроены процессы и были ли они настроены вообще.
7. Как происходит планирование и происходит ли оно вообще и чем руководствуются при этом.
8. Как происходит оценка задач и происходит ли она вообще.

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

Что если пересеклись два проекта: было изначально не качественное планирование и проработка рисков, которая привела к пересечению дедлайна двух проектов (часть 2).

Уточняем дальше вопросы:
9. Как происходит сбор требований и насколько качественная их проработка + уточнить приоритетность (если есть).
10. Делается ли реестр рисков.
11. Настроен ли воркфлоу для комфортной работы и как настроен.
12. Как и кем определяется Definition of Done и как происходит Acceptance Criteria.
13. Есть ли какой-то фоеймворк, по которому работает команда/-ы и есть ли какие-то события (митинги-ритуалы в работе команды).
14. Как происходит приемка проекта, акты + есть ли стадии пресейла до начала работы над проектом.
15. Сверить договоры и сверить ТЗ с текущими задачами — насколько правильно все понятно исполнителями + при необходимости переделать/обновить и пересогласовать с заказчиком/-ами.
16. Проверить/создать среду для разработки исполнителям для удобства работы + ввести режим отчетности.
17. Составить график проектов, исходя из текущей ситуации и сделать приоритизацию.
18. Составить/сверить реестр рисков (если не делался)
19. Свериться с экономической частью — все ли верно. При необходимости сделать переоценку проекта.