Разработчики говорят, что stand-up (дейлик) — глупая трата времени. А так ли это? 🤔

Когда я впервые предложил своей команде ежедневные встречи, все возмущались и восприняли это как инструмент контроля, а не помощи. Ребята считали, что это пустая трата времени и лучше сразу приступить к работе. Но я был уверен, что это должно нам помочь. (У нас была проблема, что информация медленно перемещалась по команде)

И вот мы начали собираться по утрам, да, в начале пришлось немного надавить. Главное, чтобы все реально участвовали. Можно добавить элементы игры, но самое важное — вести эту встречу так, чтобы это была дискуссия, а не монолог. Когда команда чувствует заинтересованность, участники лучше делятся и помогают друг другу.

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

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

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

Если вам кажется, что дейлики — это глупая трата времени, значит вы не с тем их едите. Попробуйте по-другому!

🍕 Принцип двух пицц от Amazon:

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

Почему это работает?🤔
1. Меньше бюрократии: В маленьких командах решения принимаются быстрее. Вы помещаетесь в небольшом кабинете и можете подойти к любому сотруднику и ущипнуть его со словами «Спринт в огне».
2. Лучшая коммуникация: С небольшим количеством людей проще общаться. Мы часто устраиваем быстрые созвоны, всё понятно без лишних слов. И в целом это «дешево» в отличии от большой команды.
3. Больше ответственности: Каждый чувствует свою значимость. Когда у нас было всего пять человек на проекте, каждый знал, что его вклад действительно важен. Да и видел разумеется.

Как это работает у меня?
Сразу скажу, что не работал в таких маленьких командах изначально. Но приходя в крупную команду, всегда делю её на несколько проектных групп:
1. Выделил основные независимые направления разработки
Как правило даже если команда большая, разработчики специализируются на каких-то направлениях: одни пилят продуктовое решение, вторые админку, а третьи эксперименты ставят.
2. Разбил на три команды:
Под разбил понимаю, что у команд отдельные спринты, дейлики, ретро и все возможные стандартные встречи.
3. Нанял новых ПМов на каждую команду
Этот пункт не обязателен, если работы не много. Но часто бывает, что один ПМ не справится.

Минусы:
- Разработчики не погружены в детали проекта, с которым не работают (Одно из решений: иногда перемешивать команды)
- Меньше ресурсов для крупных задач: Маленьким командам может не хватать людей для выполнения больших и сложных задач.
- Проблемы с масштабированием: Увеличение числа маленьких команд может привести к сложностям в координации и интеграции их работы.
- Повышенная нагрузка на ПМов: Если нанимать дополнительных ПМов нет возможности, то оставшиеся могут быть перегружены.

🚀 Что такое Agile и почему он важен?

Когда я начинал свой путь в банке, об Agile там только говорили, но даже не пытались применять. Столкнулся я впервые с методологией "вживую" только в своей первой IT. И осознал, что это не просто модное слово, которое вставляют в тренинги, а рабочий инструмент в "здоровых" компаниях.

Agile — это методология, которая помогает командам быть гибкими и быстро адаптироваться к изменениям.

Почему Agile круто? 😎

Гибкость: Самый банальный пример. Заказчик приходит через месяц после запуска и меняет половину концепции продукта. Конечно, это всегда больно, но с Agile это можно пережить малыми потерями.
Коммуникация: Мы проводим регулярные дейлики, а еще планнинги, грумминги, ретро, 1-1 и т.д. О них тоже расскажу позже.
Продуктивность: Работая итеративно, мы быстро выпускаем новые апдейты, и продуктом можно начать пользоваться быстрее и получить аналитику. Это значит, что мы не тратим месяцы на что-то, что в итоге никому не нужно.
Клиентоориентированность: Agile помогает лучше понимать потребности заказчика. Заказчик каждый день получает новые данные и пару раз в неделю очередной релиз. Разумеется, это помогает ему быстро принимать решения и, если нужно, менять направление развития максимально оперативно.

В следующих постах расскажу про три популярные методологии, основанные на Agile: Scrum, Kanban и Waterfall. 📈

📈 Scrum: Самый популярный! А почему?

Простыми словами: Scrum — это методология со спринтами, Scrum-мастером и ретроспективами. По сути, большинство, когда слышат слово Agile, на самом деле представляют в голове Scrum.

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

1) Роли:

• Scrum-мастер: Помогает команде следовать Scrum процессам и устраняет препятствия. (На деле мало компаний выделяют эту должность, и всё это просто PM)
• Владелец продукта: Управляет бэклогом продукта и максимизирует его ценность.
• Команда разработки: Работает над созданием инкремента продукта.

2) Артефакты:

• Бэклог продукта: Список всех желаемых фич, доработок, багов.
• Бэклог спринта: Задачи для текущего спринта.
• Инкремент: Готовый результат работы за спринт.

3) События:

• Спринт: Короткий цикл (2-4 недели) для создания инкремента. (Хотя я сейчас работаю в команде, где спринт = 1 неделя)
• Планирование спринта: Планирование задач на спринт.
• Дейли: Короткие ежедневные встречи для синхронизации.
• Обзор спринта: Демонстрация результатов спринта. (Иногда делают в узком круге, чисто менеджеры рассказывают СЕО, а обычно не делают)
• Ретроспектива: Обсуждение проблем и успехов, а также улучшений. (По хорошему проводят раз в спринт, по факту в лучшем случае раз в месяц)

Почему Scrum работает?

• Фокус на результат: Конкретные цели на каждый спринт.
• Прозрачность: Регулярные встречи и артефакты для всех участников.
• Быстрая адаптация: Возможность быстро реагировать на изменения.

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

Кстати, часто на собесах меня просили описать основные артефакты Scrum. А вот вам ответы 😄

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

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

📋 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 с лидами и наиболее общительными членами команды. После нескольких откровенных разговоров с коллегами, стало ясно, что мой подход мешает им чувствовать себя самостоятельными и ответственными за свои задачи.

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

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

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

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