А вот реальная история из жизни 😀

📋 Kanban: Визуальное управление задачами

Kanban — максимально простая методология. Подходит для малых проектов, где релизы не регулярные, но есть какой-то приоритизированный список задач.

Основные элементы Kanban:

1. Визуализация работы: Все задачи отображаются на доске, разделённой на колонки (например, “To Do”, “In Progress”, “Done”).
2. Ограничение незавершённой работы (WIP): Ограниченное количество задач в каждой колонке помогает контролировать нагрузку на команду.
3. Управление потоком: Цель — обеспечить плавное движение задач по доске, минимизируя задержки и узкие места.

Отличия Kanban от Scrum:

1. Гибкость против структуры:
• Scrum: Работает по фиксированным спринтам.
• Kanban: Нет спринтов. Работа выполняется непрерывно, и новые задачи могут быть добавлены в любой момент.
2. Роли:
• Scrum: Включает три ключевые роли — Scrum-мастер, владелец продукта и команда разработки.
• Kanban: Не требует определённых ролей, хотя часто используются менеджеры задач и владельцы продуктов.
3. Артефакты и события:
• Scrum: Включает бэклог продукта, бэклог спринта, инкременты, а также события, такие как планирование спринта, ежедневные встречи, обзоры спринта и ретроспективы.
• Kanban: Включает только доску и задачи. Нет формальных событий, но можно проводить регулярные встречи по необходимости. Кажется, мечта любого разраба🤣 — никаких встреч.
4. Изменения в процессе:
• Scrum: Изменения могут быть внесены только в начале нового спринта.
• Kanban: Изменения могут вноситься в любой момент.

Мой опыт:
Я использовал Kanban в рамках довольно большой компании. У меня было 4 команды, и одна из них занималась проектом «Система управления и дашборды». В ней было куча задач, были приоритеты, но не было жестких релизов. Разработчики просто постепенно всё пилили и сразу выкатывали, и админка тихонько обновлялась. Встречались мы раз в неделю, чтобы актуализировать приоритеты и просто «сверить часы».

В следующем посте расскажу о Waterfall — ещё одной методологии управления проектами. 📝

🌊 Waterfall: Традиционная методология управления проектами

В отличие от Agile методологий, таких как Scrum и Kanban, Waterfall (иногда называют "водопад") — это более традиционный и линейный подход к управлению проектами. Сам я никогда не работал с этой методологией, считается, что она устарела для современного управления. В современных реалях гибкость слишком важна. Но расскажу про её особенности:

Основные элементы Waterfall:

1. Линейная последовательность: Есть несколько фаз, и каждая из них выполняется только после предыдущей.
2. Фазы проекта:
- Сбор требований: Все требования полностью описываются на старте.
- Проектирование системы: UX/UI готовится для будущего продукта.
- Реализация: Техническая разработка.
- Интеграция и тестирование: Тестирование на соответствие требованиям.
- Внедрение: Выход продукта/решения в лайв.
- Поддержка: Обслуживание и улучшение продукта после его релиза.

Преимущества Waterfall:

1. Четкая структура: Каждый этап проекта чётко определён и легко отслеживается.
2. Документирование: Всё качественно документируется. Легко найти любую информацию и влиться в проект.
3. Контроль: Просто контролировать проект, так как есть чёткая структура.

Недостатки Waterfall:

1. Гибкость: Любые изменения, особенно на поздних стадиях, могут быть критичны.
2. Риски: Заказчик увидит продукт только в конце, реализация может быть неудачной.
3. Время: Проект займет больше времени, так как нет параллельности этапов.

В следующем посте расскажу, как выбрать подходящую методологию для вашего проекта. 📝

Немного юмора в связи с новостями о налогах)

💬 Токсичность в команде: мой опыт

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

У меня было мало опыта в таких ситуациях (думаю, вообще не было😀). И первое, что я сделал — назначил с ним 1-1 встречу, где прямо сказал, что есть жалобы, да и сам вижу некорректные сообщения, но он всё отрицал и сказал, что нам просто показалось (возможно, мой резкий подход его напугал). НО токсичность прекратилась🤔, увы, на время...

Тут я понял, что от меня мало толку, и обратился за помощью к HR. Она выяснила, что дизайнер чувствует себя обделённым и «не важным», так как его мнение в вопросах UX часто игнорируется в пользу заказчика, который не профессионал в данном вопросе.

Я организовал командную встречу, мы обсудили проблему, её решения и новый удобный для всех процесс, где слово дизайнера в будущих UX решениях стало финальным. После я проработал там ещё 2 года и больше не сталкивался с токсичностью со стороны этого коллеги.

Вывод: важно вовремя выявлять и решать конфликты в команде. Но не всегда это можно решить быстро и только силами менеджера. HRы реально полезны в таких ситуациях. 🛠️

Будет интересно услышать ваш «токсичный» опыт в комментах 😀

Для разнообразия ленты. Опять мои кривляния на камеру ))

💬 Хороший QA внезапно стал плохим: мой опыт

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

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

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

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

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

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

А как вы решали подобные ситуации в вашей практике? Делитесь в комментариях! 😊

сегодня опять день рилсов)

Сегодня мы проебали сроки

История по горячим следам:

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

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

Что делать в такой ситуации?
1) Не искать виноватых, назначить ретроспективу на день после реального релиза и там все разобрать
2) Собрать экстренную встречу и продумать план, который на текущий момент будет максимально приемлем для всех сторон.
Варианты:
- фичекат (сократить часть функционала на первый релиз)
- выделить больше ресурсов на разработку
- переработки для исполнителей. Важно соблюсти баланс между «надо» и мотивацией команды.
- снизить запрос на качество. По простому, релиз с некоторыми багами
- тестирование параллельно с разработкой. Это не приносит пропорциональной пользе относительно затраченным ресурсам, но может помочь сократить срок в целом. Но может демотивировать команду QA.
3) Приступать к работе по согласованному плану

Ретроспектива после релиза:
Обязательная часть процесса. Цель ретроспективы не искать виноватых, а найти решения как не допустить повторения проблемы в будущем. Необходимо собраться командой участников и обсудить как не допустить такой ситуации в будущем. Причин для нарушения дедлайнов может быть много и решения должны быть соответствующими. Приведу несколько примеров:
- нарушение оценки разработки. В будущем нужно уделить внимание качеству оценки, начать закладывать «процент» на оценку на риски, проводить ревью оценки другими разработчиками.
- нарушение сроков выполнения этапа одной из команд. В таком случае нужно проработать процесс этой команды в частном порядке.
- некорректные дедлайны. Важно задать вопрос, а на основе чего они были выставлены? Все ли было учтено изначально? Каждая ли команды перед этим дала оценку?

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

Прикладываю отрезок из сериала «Кремниевая долина». Я смеялся в голос 🤪

Классные рекомендации от Сбера

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

Первое, что приходит в голову — это PMBook. Это классика проектного менеджерства, конечно, она немного занудная и есть несколько версий, но там база. (кстати последняя внезапно стала очень короткой)

Вторая книга, которую могу посоветовать — это "Scrum. Революционный метод управления проектами" Джефф Сазерленд. Эту книгу написал сам основатель методики, а про сам Scrum я писал выше в постах.

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

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

Ну и последнее, не для новичков в управлении Путь камикадзе Эдвард Йордон. В книге рассказывать про работу над сложными проектами в самых нереальных и безнадежных ситуациях. Позволяет помочь пострессовать вместе с автором, чтобы в жизни было не так страшно))

Думаю на этом хватит)

💬 Недовольство команды чрезмерным контролем: мой опыт

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

На тот момент я был удивлен, казалось, что тщательный контроль помогает поддерживать высокий уровень производительности и качества работы. Но решил провести ряд встреч 1:1 с лидами и наиболее общительными членами команды. После нескольких откровенных разговоров с коллегами, стало ясно, что мой подход мешает им чувствовать себя самостоятельными и ответственными за свои задачи.

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

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

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

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

Давно ничего не писал в канале
Напишу сразу несколько постов как у меня дела и что происходит 😀

Вот мой новый рилсик, который не залетел, но мне очень нравится 😅

На самом деле, когда я начал вести канал от лица Менеджера проекта, я уже начал выполнять много работы Менеджера продукта (для кого то разницы нет, на самом деле она очень большая) и мне стало сложно находить истории или вдохновения писать о чистом проджект менеджменте.
Что я решил:
1) Название канала надо менять 😆
2) А кто мне запретит рассказывать о всем моем опыте?) Ну и что что я сейчас занимаю сразу две роли, мне нравится и опыт крутой! Буду рассказывать🤪
3) Надо находить мотивацию и делиться, желательно в прямом эфире, чтобы эмоция сохранялась! Обещаю, буду стараться

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

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

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

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

Product Manager – человек отвечающий за продукт, как видно из названия. Его задача принимать решения о том, как продукт будет развиваться, какие фичи будут реализовываться и зачем, проводить аналитику, в том числе конкурентов, придумывать новые идеи для улучшения, проводить АБ тесты на пользователях и многое другое, что будет развивать продукт и делать его лучше.

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