#мнение
Специфика поиска работы. Часть 2
Есть всегда два подхода в таких случаях: либо выпячивать свои сильные стороны, либо перекрывать слабые. Конечно, всегда можно отчаяться и просто постоянно откликаться в надежде найти хоть какое-то место.
Однако я, как и полагаю ты, читатель, менеджер. И в нашу прошивку заложено не не ошибаться, не не косячить, не не иметь недостатков, а наоборот — собирать всего и побольше, с тем лишь отличием, что постоянно рефлексировать и задумываться, как это применить с пользой или преодолеть.
Я, например, выбрал путь 70 на 30. 70% усилий я трачу на перекрытие слабых сторон.
Если говорить про 70% на усиление слабых сторон:
- За чуть меньше года мой английский продвинулся с A0 до B1-. Я в целом могу поддержать разговор в общих чертах, читать и писать, причём в первую очередь развиваю developing conversations;
- Я уже не так спешу по карьерной лестнице и больше уделяю внимание степенному росту как личности;
- В сообществах я не устраиваю широкие дискуссии, лишь включаюсь изредка с помощью и поддержкой;
- Плотно работаю с психологом и изучаю себя.
Про 30% фокуса на сильных сторонах:
- Я потихоньку ковыряю протоколы и сети;
- Изучаю prompt-инжиниринг и работу нейросетей;
- Погружаюсь в крипту и трейдинг;
- Уделяю время погружению в задачи своих подчинённых и смежных сотрудников;
- Готовлюсь к поступлению на клинического психотерапевта в европейский вуз.
P.S. К чему этот пост — надеюсь, он вдохновит тебя, кто бы ты ни был, дорогой читатель. Трудности возникают всегда и не только у начинающих. Важно всегда искать способы их преодолеть и верить в свои возможности
P.P.S. Я в данный момент работаю, и меня всё устраивает, однако я нахожу важным и полезным ходить на собеседования — это освежает и позволяет держать себя в тонусе. Как фитнес
Специфика поиска работы. Часть 2
Есть всегда два подхода в таких случаях: либо выпячивать свои сильные стороны, либо перекрывать слабые. Конечно, всегда можно отчаяться и просто постоянно откликаться в надежде найти хоть какое-то место.
Однако я, как и полагаю ты, читатель, менеджер. И в нашу прошивку заложено не не ошибаться, не не косячить, не не иметь недостатков, а наоборот — собирать всего и побольше, с тем лишь отличием, что постоянно рефлексировать и задумываться, как это применить с пользой или преодолеть.
Я, например, выбрал путь 70 на 30. 70% усилий я трачу на перекрытие слабых сторон.
Если говорить про 70% на усиление слабых сторон:
- За чуть меньше года мой английский продвинулся с A0 до B1-. Я в целом могу поддержать разговор в общих чертах, читать и писать, причём в первую очередь развиваю developing conversations;
- Я уже не так спешу по карьерной лестнице и больше уделяю внимание степенному росту как личности;
- В сообществах я не устраиваю широкие дискуссии, лишь включаюсь изредка с помощью и поддержкой;
- Плотно работаю с психологом и изучаю себя.
Про 30% фокуса на сильных сторонах:
- Я потихоньку ковыряю протоколы и сети;
- Изучаю prompt-инжиниринг и работу нейросетей;
- Погружаюсь в крипту и трейдинг;
- Уделяю время погружению в задачи своих подчинённых и смежных сотрудников;
- Готовлюсь к поступлению на клинического психотерапевта в европейский вуз.
P.S. К чему этот пост — надеюсь, он вдохновит тебя, кто бы ты ни был, дорогой читатель. Трудности возникают всегда и не только у начинающих. Важно всегда искать способы их преодолеть и верить в свои возможности
P.P.S. Я в данный момент работаю, и меня всё устраивает, однако я нахожу важным и полезным ходить на собеседования — это освежает и позволяет держать себя в тонусе. Как фитнес
🔥36👍9
#рецепт
Управление ожиданиями через информирование по форме
Привет, читатель!
Сегодня разберём важную тему — управление ожиданиями стейкхолдеров. Это не просто “пиши в чатик, что всё ок”, а фундаментальный навык, который помогает избежать паники и сохранить доверие. Управление ожиданиями — это неотъемлемая часть проектного управления, и я расскажу, как делаю это на практике.
В любой проектной деятельности стейкхолдеры хотят быть уверены, что всё под контролем. Когда они понимают, что происходит, что влияет на проект и какие шаги предпринимаются, это снижает напряжение и повышает доверие. Без должного управления ожиданиями каждый сбой может превратиться в лавину негодования и беспокойства. Так они переходят из разряда "обладеть, они там совсем ...лись" в разряд "а, ну бывает, нехорошо конечно, разбирайтесь давайте)”
По сути, управление ожиданиями — это про поддержание прозрачности и вовлечённости стейкхолдеров. Это значит своевременно информировать их о проблемах, изменениях и планах, избегая ненужных эмоций и паники. Важно понимать, что хорошая коммуникация — это не про отчёты, а про лаконичное и точное донесение информации.
Обычно у меня десятки стейхолдеров и есть несколько ЛПР. Без управления ожиданиями никуда, так как мы активнее всего в рабочих коммуникациях используем Slack, то я информирую через него. В Яндекс деньгах была создана специальная группа стейкхолдеров по нашему направлению в аутлуке (алиас) и писались письма сразу на всю группу, а на текущем я создал специальный слак-канал. Бывают и инциденты на проде, они требуют особого внимания — тут уже не обойтись без чёткой структуры сообщения и пост-мортем анализа, если инцидент крупный. Когда происходит что-то серьёзное, подключаются L2/L3 и проводится разбор полётов, чтобы избежать повторений.
Структура сообщения, которую я использую
Я делю сообщение на такие разделы:
1. Ситуация или проблема — что именно случилось.
2. Причина — почему это произошло.
3. Влияние — чем это грозит бизнесу и пользователям.
4. План действий — что уже сделано и что ещё нужно сделать.
5. Предыдущие действия — если это повторяющийся или сложный инцидент, я добавляю хронологию проблем.
Пример сообщения с такой структурой
"Ситуация: Релиз версии 1.14.0, запланированный на утро 16 октября 2024 года, пришлось перенести из-за необходимости включения двух критичных задач, которые влияют на стабильность приложения:
1. [X-6152] — Определить, почему в 'connection' отправляется 'unknown'.
2. [X-6056] — Изменение логики отображения сообщения 'нет интернета'.
Причина: Добавление этих задач необходимо для улучшения качества работы с сетью и устранения проблемы с некорректным отображением статуса соединения. Это позволит точнее отслеживать состояние сети, избежать лишних сбоев и улучшить пользовательский опыт. Задачи также связаны с исправлениями, которые были выполнены в прошлых спринтах, но не попали в релизные сборки за последний месяц.
Влияние: Включение этих задач требует дополнительного времени на разработку и тестирование. Из-за этого мы не сможем выпустить релиз утром 16 октября, как планировалось. Перенос релиза на утро четверга, 17 октября.
План действий:
- Завершение разработки и тестирования задач [X-6152] и [X-6056] до конца среды, 16 октября.
- Проведение полного регресс-тестирования — до конца дня среды.
- Выпуск релиза перенесён на утро четверга, 17 октября.
Подробный статус задачи по релизу доступен в отчёте о релизе.
FYI: ЛПР1, ЛПР2, ЛПР3"
Управление ожиданиями — это не просто про передачу информации, а про удержание доверия и контроль ситуации. Структурированный подход позволяет стейкхолдерам чувствовать себя уверенно даже в моменты непредвиденных проблем. Так что не забывай: ясность и точность — твои лучшие друзья.
А как ты управляешь ожиданиями? Делись опытом!
Управление ожиданиями через информирование по форме
Привет, читатель!
Сегодня разберём важную тему — управление ожиданиями стейкхолдеров. Это не просто “пиши в чатик, что всё ок”, а фундаментальный навык, который помогает избежать паники и сохранить доверие. Управление ожиданиями — это неотъемлемая часть проектного управления, и я расскажу, как делаю это на практике.
В любой проектной деятельности стейкхолдеры хотят быть уверены, что всё под контролем. Когда они понимают, что происходит, что влияет на проект и какие шаги предпринимаются, это снижает напряжение и повышает доверие. Без должного управления ожиданиями каждый сбой может превратиться в лавину негодования и беспокойства. Так они переходят из разряда "обладеть, они там совсем ...лись" в разряд "а, ну бывает, нехорошо конечно, разбирайтесь давайте)”
По сути, управление ожиданиями — это про поддержание прозрачности и вовлечённости стейкхолдеров. Это значит своевременно информировать их о проблемах, изменениях и планах, избегая ненужных эмоций и паники. Важно понимать, что хорошая коммуникация — это не про отчёты, а про лаконичное и точное донесение информации.
Обычно у меня десятки стейхолдеров и есть несколько ЛПР. Без управления ожиданиями никуда, так как мы активнее всего в рабочих коммуникациях используем Slack, то я информирую через него. В Яндекс деньгах была создана специальная группа стейкхолдеров по нашему направлению в аутлуке (алиас) и писались письма сразу на всю группу, а на текущем я создал специальный слак-канал. Бывают и инциденты на проде, они требуют особого внимания — тут уже не обойтись без чёткой структуры сообщения и пост-мортем анализа, если инцидент крупный. Когда происходит что-то серьёзное, подключаются L2/L3 и проводится разбор полётов, чтобы избежать повторений.
Структура сообщения, которую я использую
Я делю сообщение на такие разделы:
1. Ситуация или проблема — что именно случилось.
2. Причина — почему это произошло.
3. Влияние — чем это грозит бизнесу и пользователям.
4. План действий — что уже сделано и что ещё нужно сделать.
5. Предыдущие действия — если это повторяющийся или сложный инцидент, я добавляю хронологию проблем.
Пример сообщения с такой структурой
"Ситуация: Релиз версии 1.14.0, запланированный на утро 16 октября 2024 года, пришлось перенести из-за необходимости включения двух критичных задач, которые влияют на стабильность приложения:
1. [X-6152] — Определить, почему в 'connection' отправляется 'unknown'.
2. [X-6056] — Изменение логики отображения сообщения 'нет интернета'.
Причина: Добавление этих задач необходимо для улучшения качества работы с сетью и устранения проблемы с некорректным отображением статуса соединения. Это позволит точнее отслеживать состояние сети, избежать лишних сбоев и улучшить пользовательский опыт. Задачи также связаны с исправлениями, которые были выполнены в прошлых спринтах, но не попали в релизные сборки за последний месяц.
Влияние: Включение этих задач требует дополнительного времени на разработку и тестирование. Из-за этого мы не сможем выпустить релиз утром 16 октября, как планировалось. Перенос релиза на утро четверга, 17 октября.
План действий:
- Завершение разработки и тестирования задач [X-6152] и [X-6056] до конца среды, 16 октября.
- Проведение полного регресс-тестирования — до конца дня среды.
- Выпуск релиза перенесён на утро четверга, 17 октября.
Подробный статус задачи по релизу доступен в отчёте о релизе.
FYI: ЛПР1, ЛПР2, ЛПР3"
Управление ожиданиями — это не просто про передачу информации, а про удержание доверия и контроль ситуации. Структурированный подход позволяет стейкхолдерам чувствовать себя уверенно даже в моменты непредвиденных проблем. Так что не забывай: ясность и точность — твои лучшие друзья.
А как ты управляешь ожиданиями? Делись опытом!
👍41🔥19👀2
#мнение
Что будет дальше
Привет, читатель!
Давно не виделись. Как ты заметил, последние полгода я постоянно пропадал, хотя всеми силами пытался вернуться к активным публикациям. Для меня прошлый год прошел под лозунгом «выжить». Сложности со здоровьем, рабочая нагрузка — все это заставило меня притормозить. Но я решил воспринимать это не как шаг назад, а как паузу для накопления сил.
Этот год я хочу провести по-другому — с горящими глазами и вдохновением. Планирую активно учиться и развиваться: сдать IELTS General на B2, пройти сертификацию PMP, подтянуть технические навыки. Кстати, я уже работаю над своим сайд-проектом на Flutter с использованием Clean Architecture и Bloc. Помогает мне в этом GPT и немного claude — и, что приятно, получается довольно здорово!
А теперь о главном — о блоге.
---
О будущем блога
Я всегда сторонился монетизации и слишком простого контента. Был страх превратиться в «типичного блогера» или, того хуже, «инфоцыгана», который пишет ради цифр и видит в читателях лишь аудиторию. Но в какой-то момент я понял, что блог для меня больше, чем просто место для размышлений. Это уже инструмент, по которому судят обо мне, и через который я могу влиять на людей.
Честно признаюсь, в режиме отсутствия энергии поддерживать высокий уровень качества стало сложно. Но я все равно вижу тебя, читатель, как живого коллегу и собеседника. Того, с кем мы обсуждаем факапы на кофетолке и ворчим на стейкхолдеров в чате.
Сейчас я хочу сделать блог более системным. Это не значит, что я откажусь от своей искренности и стиля. Наоборот, я намерен еще больше углубиться в темы, которые считаю важными, и буду структурировать работу над контентом. В том числе — добавлю элементы монетизации, такие как реклама.
---
Чего я хочу достичь в 2025?
К концу 2025 года я хочу, чтобы блог стал для меня мощной мотивацией. Чтобы мои посты вдохновляли, цитировались и вызывали обсуждения. Я хочу, чтобы меня приглашали выступать, звать на подкасты, брать интервью . Хочу, чтобы мой опыт стал примером для других, чтобы я показывал: проектный менеджмент — это не просто процессы, сроки и бюджеты, это настоящее искусство, в котором можно расти и получать удовольствие от процесса.
---
О миссии блога
Я хочу быть тем, кого мне не хватало в начале пути. Не просто человеком, который учит, а коллегой, который делится опытом, дает инструменты и показывает: управление может быть проще и эффективнее. Мой блог — это место, где можно найти поддержку, вдохновение и материалы для решения реальных задач.
---
Чем я отличаюсь?
Я не гуру, а вечный ученик. Поэтому название Junior PM будет всегда актуально. Я пробую новое, ошибаюсь, делаю выводы и делюсь этим. Моя сила в честности, практичности и умении признавать, что я тоже расту. Блог — это моя личная учеба, и я рад, что могу разделить ее с тобой.
---
О формате
Будет много разного, но в целом можно считать что будет примерно так:
- Большие статьи: кейсы, шаблоны, лайфхаки, теория
- Средние посты: размышления, ответы на вопросы, полезное из сообществ менеджеров
- Краткие посты: напутствия, задачи, любопытный контент
Будет также много нового:
- Новый каналы - medium, reddit, instagram и еще несколько
- Новые форматы. Например, хочу попробовать себя в коротких видео с размышлениями
- Буду использовать больше сервисов-помогатор. Как-нибудь поделюсь что там есть среди нейросетей и сервисов от райтинга до автопостинга и репурпозинга.
---
Зачем мне это нужно?
Этот блог — не только способ делиться знаниями, но и инструмент моего роста. Это моя мотивация учиться, пробовать, экспериментировать. Это возможность становиться лучше и вдохновлять других.
---
P.S. Если у тебя есть темы которые ты бы хотел чтобы я раскрыл, вопросы или просто обратная связь, я буду тебе рад, мои личные сообщения всегда открыты!
Что будет дальше
Привет, читатель!
Давно не виделись. Как ты заметил, последние полгода я постоянно пропадал, хотя всеми силами пытался вернуться к активным публикациям. Для меня прошлый год прошел под лозунгом «выжить». Сложности со здоровьем, рабочая нагрузка — все это заставило меня притормозить. Но я решил воспринимать это не как шаг назад, а как паузу для накопления сил.
Этот год я хочу провести по-другому — с горящими глазами и вдохновением. Планирую активно учиться и развиваться: сдать IELTS General на B2, пройти сертификацию PMP, подтянуть технические навыки. Кстати, я уже работаю над своим сайд-проектом на Flutter с использованием Clean Architecture и Bloc. Помогает мне в этом GPT и немного claude — и, что приятно, получается довольно здорово!
А теперь о главном — о блоге.
---
О будущем блога
Я всегда сторонился монетизации и слишком простого контента. Был страх превратиться в «типичного блогера» или, того хуже, «инфоцыгана», который пишет ради цифр и видит в читателях лишь аудиторию. Но в какой-то момент я понял, что блог для меня больше, чем просто место для размышлений. Это уже инструмент, по которому судят обо мне, и через который я могу влиять на людей.
Честно признаюсь, в режиме отсутствия энергии поддерживать высокий уровень качества стало сложно. Но я все равно вижу тебя, читатель, как живого коллегу и собеседника. Того, с кем мы обсуждаем факапы на кофетолке и ворчим на стейкхолдеров в чате.
Сейчас я хочу сделать блог более системным. Это не значит, что я откажусь от своей искренности и стиля. Наоборот, я намерен еще больше углубиться в темы, которые считаю важными, и буду структурировать работу над контентом. В том числе — добавлю элементы монетизации, такие как реклама.
---
Чего я хочу достичь в 2025?
К концу 2025 года я хочу, чтобы блог стал для меня мощной мотивацией. Чтобы мои посты вдохновляли, цитировались и вызывали обсуждения. Я хочу, чтобы меня приглашали выступать, звать на подкасты, брать интервью . Хочу, чтобы мой опыт стал примером для других, чтобы я показывал: проектный менеджмент — это не просто процессы, сроки и бюджеты, это настоящее искусство, в котором можно расти и получать удовольствие от процесса.
---
О миссии блога
Я хочу быть тем, кого мне не хватало в начале пути. Не просто человеком, который учит, а коллегой, который делится опытом, дает инструменты и показывает: управление может быть проще и эффективнее. Мой блог — это место, где можно найти поддержку, вдохновение и материалы для решения реальных задач.
---
Чем я отличаюсь?
Я не гуру, а вечный ученик. Поэтому название Junior PM будет всегда актуально. Я пробую новое, ошибаюсь, делаю выводы и делюсь этим. Моя сила в честности, практичности и умении признавать, что я тоже расту. Блог — это моя личная учеба, и я рад, что могу разделить ее с тобой.
---
О формате
Будет много разного, но в целом можно считать что будет примерно так:
- Большие статьи: кейсы, шаблоны, лайфхаки, теория
- Средние посты: размышления, ответы на вопросы, полезное из сообществ менеджеров
- Краткие посты: напутствия, задачи, любопытный контент
Будет также много нового:
- Новый каналы - medium, reddit, instagram и еще несколько
- Новые форматы. Например, хочу попробовать себя в коротких видео с размышлениями
- Буду использовать больше сервисов-помогатор. Как-нибудь поделюсь что там есть среди нейросетей и сервисов от райтинга до автопостинга и репурпозинга.
---
Зачем мне это нужно?
Этот блог — не только способ делиться знаниями, но и инструмент моего роста. Это моя мотивация учиться, пробовать, экспериментировать. Это возможность становиться лучше и вдохновлять других.
---
P.S. Если у тебя есть темы которые ты бы хотел чтобы я раскрыл, вопросы или просто обратная связь, я буду тебе рад, мои личные сообщения всегда открыты!
🔥72👍15👀8
#кейс_стади
Новый тип постов
Добавляю новый формат в блог — задачки для менеджеров. (Да как у Колганова или Ковалеского, но иначе). Это ежедневный контент, который позволит размять немного мозг, пока вливаешь в себя жизнеобеспечивающие жидкости с утра, и подготовиться к работе.
Задачки не про правильные или неправильные ответы — их вообще нет. Важно задать допущения и подумать, как бы ты действовал в такой ситуации.
Первая задача уже здесь! Читай, размышляй, пиши свои варианты в комментариях 👇
Обсуждаем!
Новый тип постов
Добавляю новый формат в блог — задачки для менеджеров. (Да как у Колганова или Ковалеского, но иначе). Это ежедневный контент, который позволит размять немного мозг, пока вливаешь в себя жизнеобеспечивающие жидкости с утра, и подготовиться к работе.
Задачки не про правильные или неправильные ответы — их вообще нет. Важно задать допущения и подумать, как бы ты действовал в такой ситуации.
Первая задача уже здесь! Читай, размышляй, пиши свои варианты в комментариях 👇
Обсуждаем!
👍17💩2
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях
Ситуация:
Твоя команда начала новый проект с жёсткими дедлайнами. Через две недели работы ты замечаешь, что сотрудники стали избегать открытого общения на ежедневных стендапах. Все говорят только о выполненных задачах, но ты знаешь, что реальных проблем больше, чем кажется.
Проблема:
У тебя есть ощущение, что кто-то из команды боится показать слабину. Возможно, это из-за нового сотрудника, который слишком амбициозен и активно "выставляет оценки" чужой работе.
Вопрос:
Как ты решишь эту проблему? Стоит ли напрямую поговорить с этим сотрудником или изменить формат стендапов? Возможно, ты предложишь ещё какой-то подход?
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях
Ситуация:
Твоя команда начала новый проект с жёсткими дедлайнами. Через две недели работы ты замечаешь, что сотрудники стали избегать открытого общения на ежедневных стендапах. Все говорят только о выполненных задачах, но ты знаешь, что реальных проблем больше, чем кажется.
Проблема:
У тебя есть ощущение, что кто-то из команды боится показать слабину. Возможно, это из-за нового сотрудника, который слишком амбициозен и активно "выставляет оценки" чужой работе.
Вопрос:
Как ты решишь эту проблему? Стоит ли напрямую поговорить с этим сотрудником или изменить формат стендапов? Возможно, ты предложишь ещё какой-то подход?
🔥13😁4🤯3
#полезности
Амбулаторное обследование процессов
Привет, читатель!
Недавно в Канбан Толкс наткнулся на классное обсуждение — делились вопросами для интервью о процессах. Как понять, что болит у команды или заказчиков, на что стоит обратить внимание?
Было много толковых идей, и я решил сохранить лучшие вопросы. Они помогут вам в работе — бери, используй, адаптируй под свои задачи.
➡️ Лови список:
О человеке
- Чем занимаешься в компании
- Какая цель твоей работы
- Что именно ты делаешь?
- Какие ожидания от твоей работы, как тебя оценивают?
- В какой команде/подразделении работаешь, кто под твоим руководством?
О бизнесе в целом
- Какая бизнес-цель стоит перед подразделением/твоим продуктовым направлением?
- Что сейчас хорошо в подразделении/бизнесе?
- Что сейчас плохо в подразделении/бизнесе?
- От кого/чего зависит успех подразделения/бизнеса?
О команде
- Какая цель работы твоего подразделения/команды/направления?
- Кто для тебя заказчики?
- От кого/чего зависит успех вашей команды?
- Что сейчас работает хорошо?
- Чем ты сам сейчас не доволен?
- Чем сейчас довольны и недовольны заказчики
- Какие ожидания не выполняются? Сроки? Предсказуемость сервиса?
- Понятно ли на какой стадии работа? Когда будет завершена?
- Качество работ устраивает?
- На какие темы чаще всего возникают дискуссии?
- Возможно, есть какие-то явные или скрытые конфликты отделов/сотрудников, которые ты ощущаешь?
- Чем сейчас довольны и недовольны участники команды/отдела
- Нравится ли формат и режим работы?
- Что замедляет их работу?
- Часто прерывают?
- Часто ли задача заблокирована другими?
- Хорошо ли ставятся задачи?
- Возможно, что-то мешает улучшать процесс работы/совершенствоваться?
- Есть ли что-то, что регулярно мешает делать работу так качественно, как хотелось бы?
- Есть перегрузка? Переработки?
- Какие планы по развитию команды и бизнеса? Что ждет всех в ближайший год?
О процессах
- Что вы выпускаете? Что для тебя является единицей завершенной работы? Перечисли
- Откуда обычно появляются задачи?
- Опиши по любой задаче ваш процесс работы
- Как вы выбираете что делать? Как работают приоритеты?
- Как вы ведете учет своей работы, визуализируете её?
- У вас есть доска команды? Поделись ссылкой
- Как узнать текущий статус работ?
- Как узнать, что задача заблокирована и работа не ведется?
- Часто ли у вас задачи с дедлайном?
- Как измеряете процесс?
- Какие есть регулярные встречи, ритуалы, какие действия предпринимаете после них?
- Бывает ли, что делаете работу, которая потом оказывается не нужна?
Советы
- Что можно быстро изменить?
- На что нужно обратить внимание в первую очередь?
- Чего нужно остерегаться?
- С кем еще стоит пообщаться? Что нужно прочесть и изучить?
- Дай мне любой совет
Автор @britishpop
А еще там же мелькал ассесмент https://docs.google.com/document/d/1GxBAhQbhz_86Fd2qpH1qhh8Vtf_wbUyAYI5ZLhmVJbo/edit?tab=t.0
Амбулаторное обследование процессов
Привет, читатель!
Недавно в Канбан Толкс наткнулся на классное обсуждение — делились вопросами для интервью о процессах. Как понять, что болит у команды или заказчиков, на что стоит обратить внимание?
Было много толковых идей, и я решил сохранить лучшие вопросы. Они помогут вам в работе — бери, используй, адаптируй под свои задачи.
➡️ Лови список:
О человеке
- Чем занимаешься в компании
- Какая цель твоей работы
- Что именно ты делаешь?
- Какие ожидания от твоей работы, как тебя оценивают?
- В какой команде/подразделении работаешь, кто под твоим руководством?
О бизнесе в целом
- Какая бизнес-цель стоит перед подразделением/твоим продуктовым направлением?
- Что сейчас хорошо в подразделении/бизнесе?
- Что сейчас плохо в подразделении/бизнесе?
- От кого/чего зависит успех подразделения/бизнеса?
О команде
- Какая цель работы твоего подразделения/команды/направления?
- Кто для тебя заказчики?
- От кого/чего зависит успех вашей команды?
- Что сейчас работает хорошо?
- Чем ты сам сейчас не доволен?
- Чем сейчас довольны и недовольны заказчики
- Какие ожидания не выполняются? Сроки? Предсказуемость сервиса?
- Понятно ли на какой стадии работа? Когда будет завершена?
- Качество работ устраивает?
- На какие темы чаще всего возникают дискуссии?
- Возможно, есть какие-то явные или скрытые конфликты отделов/сотрудников, которые ты ощущаешь?
- Чем сейчас довольны и недовольны участники команды/отдела
- Нравится ли формат и режим работы?
- Что замедляет их работу?
- Часто прерывают?
- Часто ли задача заблокирована другими?
- Хорошо ли ставятся задачи?
- Возможно, что-то мешает улучшать процесс работы/совершенствоваться?
- Есть ли что-то, что регулярно мешает делать работу так качественно, как хотелось бы?
- Есть перегрузка? Переработки?
- Какие планы по развитию команды и бизнеса? Что ждет всех в ближайший год?
О процессах
- Что вы выпускаете? Что для тебя является единицей завершенной работы? Перечисли
- Откуда обычно появляются задачи?
- Опиши по любой задаче ваш процесс работы
- Как вы выбираете что делать? Как работают приоритеты?
- Как вы ведете учет своей работы, визуализируете её?
- У вас есть доска команды? Поделись ссылкой
- Как узнать текущий статус работ?
- Как узнать, что задача заблокирована и работа не ведется?
- Часто ли у вас задачи с дедлайном?
- Как измеряете процесс?
- Какие есть регулярные встречи, ритуалы, какие действия предпринимаете после них?
- Бывает ли, что делаете работу, которая потом оказывается не нужна?
Советы
- Что можно быстро изменить?
- На что нужно обратить внимание в первую очередь?
- Чего нужно остерегаться?
- С кем еще стоит пообщаться? Что нужно прочесть и изучить?
- Дай мне любой совет
Автор @britishpop
А еще там же мелькал ассесмент https://docs.google.com/document/d/1GxBAhQbhz_86Fd2qpH1qhh8Vtf_wbUyAYI5ZLhmVJbo/edit?tab=t.0
🔥19👍6💩1
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях**
Ситуация:
Вы — проджект-менеджер в продуктовой компании, занимающейся разработкой CRM-системы для корпоративных клиентов. Один из ваших крупных заказчиков запросил отчет по эффективности внедрения продукта спустя 3 месяца после релиза. Отчет должен содержать конкретные метрики, подтверждающие успех внедрения.
На стороне клиента есть три заинтересованных отдела:
1. Отдел продаж хочет увидеть увеличение числа успешных сделок.
2. Отдел поддержки клиентов заинтересован в уменьшении времени на обработку заявок.
3. IT-отдел требует данных о стабильности системы (аптайм, число критических ошибок).
Проблема:
Ваши ресурсы ограничены: вы можете собрать и проанализировать только два из трех наборов метрик к установленному сроку. Однако, если ожидания хотя бы одного отдела не будут выполнены, существует риск ухудшения сотрудничества с клиентом.
Вопрос:
Как вы выберете приоритетные метрики? Какие действия предпримете, чтобы согласовать ожидания всех сторон и сохранить партнерство?
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях**
Ситуация:
Вы — проджект-менеджер в продуктовой компании, занимающейся разработкой CRM-системы для корпоративных клиентов. Один из ваших крупных заказчиков запросил отчет по эффективности внедрения продукта спустя 3 месяца после релиза. Отчет должен содержать конкретные метрики, подтверждающие успех внедрения.
На стороне клиента есть три заинтересованных отдела:
1. Отдел продаж хочет увидеть увеличение числа успешных сделок.
2. Отдел поддержки клиентов заинтересован в уменьшении времени на обработку заявок.
3. IT-отдел требует данных о стабильности системы (аптайм, число критических ошибок).
Проблема:
Ваши ресурсы ограничены: вы можете собрать и проанализировать только два из трех наборов метрик к установленному сроку. Однако, если ожидания хотя бы одного отдела не будут выполнены, существует риск ухудшения сотрудничества с клиентом.
Вопрос:
Как вы выберете приоритетные метрики? Какие действия предпримете, чтобы согласовать ожидания всех сторон и сохранить партнерство?
🤔9👍4💩2
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях
Ваша роль
Вы — руководитель проектного офиса в IT-ГАЗМЯС, отвечаете за управление программами проектов, процессы проектного управлеиня, распределение ресурсов и отчетность перед топ-менеджментом.
Ваш контекст
Ваша компания разрабатывает IT-продукты для родительской компании ГАЗМЯС, структура матричная. Новый топ-менеджер делает акцент на детализации отчетов и личном участии руководителей в работе над проектами.
Ваша проблема
На отчетной встрече по важного проекту (импортозамещению SAP) вы представили отчет по проектам. Топ-менеджер задал уточняющий вопрос о задачах в одном из проектов. Ответить сразу вы не смогли, так как такие детали находятся у проектного менеджера. Он раскритиковал вас за недостаток владения информацией и предложил приглашать на встречи всю команду.
Ваши действия
Вы уже предприняли следующие шаги:
1. Уточнили, что на уровне руководителя важнее фокус на общей картине и рисках, чем знание деталей.
2. Подготовили более подробный отчет для следующей встречи с включением ключевых метрик и статусных данных.
3. Попытались объяснить, что регулярное участие всей команды в таких встречах снизит их продуктивность.
Однако эти шаги не изменили мнение топ-менеджера. Он считает, что отсутствие оперативных ответов снижает доверие и эффективность, а значит ставит под сомнение ваши проф. качества и целесообразность вашего нахождения в компании
Главный вопрос
Как вам убедить топ-менеджера в необходимости разделения стратегического и операционного управления, сохранив доверие к своей работе?
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях
Ваша роль
Вы — руководитель проектного офиса в IT-ГАЗМЯС, отвечаете за управление программами проектов, процессы проектного управлеиня, распределение ресурсов и отчетность перед топ-менеджментом.
Ваш контекст
Ваша компания разрабатывает IT-продукты для родительской компании ГАЗМЯС, структура матричная. Новый топ-менеджер делает акцент на детализации отчетов и личном участии руководителей в работе над проектами.
Ваша проблема
На отчетной встрече по важного проекту (импортозамещению SAP) вы представили отчет по проектам. Топ-менеджер задал уточняющий вопрос о задачах в одном из проектов. Ответить сразу вы не смогли, так как такие детали находятся у проектного менеджера. Он раскритиковал вас за недостаток владения информацией и предложил приглашать на встречи всю команду.
Ваши действия
Вы уже предприняли следующие шаги:
1. Уточнили, что на уровне руководителя важнее фокус на общей картине и рисках, чем знание деталей.
2. Подготовили более подробный отчет для следующей встречи с включением ключевых метрик и статусных данных.
3. Попытались объяснить, что регулярное участие всей команды в таких встречах снизит их продуктивность.
Однако эти шаги не изменили мнение топ-менеджера. Он считает, что отсутствие оперативных ответов снижает доверие и эффективность, а значит ставит под сомнение ваши проф. качества и целесообразность вашего нахождения в компании
Главный вопрос
Как вам убедить топ-менеджера в необходимости разделения стратегического и операционного управления, сохранив доверие к своей работе?
🎉9👍3💩2😱1🕊1
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях**
Ваша роль
Вы — Скрам-мастер в компании, разрабатывающей решение для визуализации данных для трейдеров. Основная задача — обеспечивать бесперебойную работу команды, помогать устранять блокеры и улучшать процессы, чтобы спринты завершались вовремя и с ожидаемым качеством. Вы не очень жестко следуете скраму, но у вас PSM II
Контекст
Компания специализируется на создании высоконагруженных систем для анализа и визуализации данных, которые используют трейдеры. В команде — 8 разработчиков, 3 тестировщика, дизайнер, и 2 аналитика. Процессы построены на Scrum, задачи распределяются через Jira,. Ключевые клиенты компании требуют быстрой реакции на изменения и высокую точность работы системы.
Проблема
В ходе планирования спринта команда столкнулась с конфликтом. Разработчики считают, что на грумингах очень занижаются оценки задач, из-за чего разработка выглядит перегруженной. Тестировщики уверены, что разработчики не учитывают время на тестирование в своих оценках, что приводит к увеличению нагрузки ближе к концу спринта. Дизайнер утверждает, что его задачи постоянно делаются лишь наполовину и вообще не релевантны дизайн-системе, хотя визуальная часть продукта критична для пользователей.
Эти разногласия приводят к:
- Постоянным пересчетам капасити команды.
- Задержкам с датой код-фриза.
- Ругани в кулуарах.
Ваша цель
Вы хотите наладить прозрачный процесс оценки задач, чтобы это позволило вести устойчивый ритм работы.
Другие действующие лица
- Разработчики. Их интерес — делать задачи с хорошими техническими решениями, которые легко поддерживать.
- Тестировщики. Хотят, чтобы их время на проверку учитывалось наравне с разработкой.
- Дизайнер. Настаивает на том, что его работа должна стать частью приоритетов.
- Продакт-овнер. Заинтересован в соблюдении дедлайнов и запросов от клиентов.
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях**
Ваша роль
Вы — Скрам-мастер в компании, разрабатывающей решение для визуализации данных для трейдеров. Основная задача — обеспечивать бесперебойную работу команды, помогать устранять блокеры и улучшать процессы, чтобы спринты завершались вовремя и с ожидаемым качеством. Вы не очень жестко следуете скраму, но у вас PSM II
Контекст
Компания специализируется на создании высоконагруженных систем для анализа и визуализации данных, которые используют трейдеры. В команде — 8 разработчиков, 3 тестировщика, дизайнер, и 2 аналитика. Процессы построены на Scrum, задачи распределяются через Jira,. Ключевые клиенты компании требуют быстрой реакции на изменения и высокую точность работы системы.
Проблема
В ходе планирования спринта команда столкнулась с конфликтом. Разработчики считают, что на грумингах очень занижаются оценки задач, из-за чего разработка выглядит перегруженной. Тестировщики уверены, что разработчики не учитывают время на тестирование в своих оценках, что приводит к увеличению нагрузки ближе к концу спринта. Дизайнер утверждает, что его задачи постоянно делаются лишь наполовину и вообще не релевантны дизайн-системе, хотя визуальная часть продукта критична для пользователей.
Эти разногласия приводят к:
- Постоянным пересчетам капасити команды.
- Задержкам с датой код-фриза.
- Ругани в кулуарах.
Ваша цель
Вы хотите наладить прозрачный процесс оценки задач, чтобы это позволило вести устойчивый ритм работы.
Другие действующие лица
- Разработчики. Их интерес — делать задачи с хорошими техническими решениями, которые легко поддерживать.
- Тестировщики. Хотят, чтобы их время на проверку учитывалось наравне с разработкой.
- Дизайнер. Настаивает на том, что его работа должна стать частью приоритетов.
- Продакт-овнер. Заинтересован в соблюдении дедлайнов и запросов от клиентов.
👍3💩2👏1
#мнение
Нейросети всех заменяют!
Полно таких кликбейтных лозунгов (тут кстати тоже). Но что я пока вижу на деле поделюсь ниже.
Ты, как читатель, наверное, заметил, что я их применяю, так как грамматических и пунктуационных ошибок стало меньше. Я люблю сложную русскую речь с витееватыми оборотами, но их правила грамматики не отвечают мне взаимностью.
Также, в целом, я планирую наращивать использование нейросетей для блогинга, но не потому, что я хочу заливать аудиторию низкокачественным сгенерированным контентом. Напротив, я хочу повышать его качество, упрощая себе создание сложного и действительно полезного. Также я не хочу тратить уж слишком много времени на создание картинок или анимированной обложки.
Тут не будет рекламы конкретного курса или очень классных нейросетей. Зато будут полезные ссылки на действительно полезные ресурсы, которые могут помочь как в промпт-инжиниринге, так и в выборе нейросети:
- LLM Arena — актуальные по мощности нейросети и их ранкинг: https://lmarena.ai/?leaderboard
- AI For That — нейросетевой поисковик для нейросетей. Позволяет легко подбирать под конкретную задачу сервис и смотреть его юзкейсы: https://theresanaiforthat.com/
- Промтгайд — вводный тестовый курс про промптинг: https://www.promptingguide.ai/
- Промпт хиро — сборник хороших промптов: https://prompthero.com/
- Ведущие принципы качественных промптов — https://github.com/VILA-Lab/ATLAS. Ребята провели крутое исследование и опубликовали результаты.
P.S. Для чего я сам планирую использовать нейросети и что мне удалось накопать. А особо ничего — сейчас больше это для развлечения и совсем небольшой помощи. Действительно что-то автоматизировать или заменить, не на уровне говорящей головы, ничего не может. Но я в процессе поисков.
Генерация идей
Да, нашел пару сервисов. Но мое буйное воображение все равно справляется лучше
Создание скелетонов и набросков
Ничего нет толкового.
Хуманизация текстов
Да, есть пару сервисов, но они не палятся лишь при чеке другими нейросетями. Опытный глаз легко видит работу нечеловека.
Грамматика и ошибки
Тут навалом, много крутых сервисов.
Суммаризация и упрощение информации
Есть 2–3 игрока, но они достаточно бестолковые и под капотом GPT-3.5.
Генерация текстового контента
Есть 2 крутых игрока и много мелочи, но полноценного блогера даже для микропостинга это не сможет заменить.
Репурпойзинг (когда из большой статьи делается сторис в инстаграм)
Ничего нет на рынке
Генерация визуала
Тут много крутого, и уже очень далеко продвинулись. Но нормально писать текст на картинке еще никто не умеет.
Сторителлинг
Есть 2 сервиса которые хорошо как развивают истории, так и пишут с нуля. Но без готового скелета и действительно расписанного черновика генерят скучные вещи
Шутки, мемы, геги, реддит-триггеры
Действительно что-то забавное ничего особо делать не умеет
Автоматизация публикаций, кросспостинг
Ничего адекватного нет на рынке.
Написание автоматизаций и файлов
Есть пара крутых игроков, но по сути gpt-o1-pro справляется лучше.
Факт-чекинг
Никто пока не справляется
Поиск среди научных публикаций и обоснованных исследований
Есть несколько попыток, но результаты грустные
Вовлечение аудитории
Навалом сервисов, которые генерят заголовки, seo/aso теги
Выдержка тон-оф-войс и бренд стиля
Есть 3 хороших сервиса, но за просто космический прайс
Нейросети всех заменяют!
Полно таких кликбейтных лозунгов (тут кстати тоже). Но что я пока вижу на деле поделюсь ниже.
Ты, как читатель, наверное, заметил, что я их применяю, так как грамматических и пунктуационных ошибок стало меньше. Я люблю сложную русскую речь с витееватыми оборотами, но их правила грамматики не отвечают мне взаимностью.
Также, в целом, я планирую наращивать использование нейросетей для блогинга, но не потому, что я хочу заливать аудиторию низкокачественным сгенерированным контентом. Напротив, я хочу повышать его качество, упрощая себе создание сложного и действительно полезного. Также я не хочу тратить уж слишком много времени на создание картинок или анимированной обложки.
Тут не будет рекламы конкретного курса или очень классных нейросетей. Зато будут полезные ссылки на действительно полезные ресурсы, которые могут помочь как в промпт-инжиниринге, так и в выборе нейросети:
- LLM Arena — актуальные по мощности нейросети и их ранкинг: https://lmarena.ai/?leaderboard
- AI For That — нейросетевой поисковик для нейросетей. Позволяет легко подбирать под конкретную задачу сервис и смотреть его юзкейсы: https://theresanaiforthat.com/
- Промтгайд — вводный тестовый курс про промптинг: https://www.promptingguide.ai/
- Промпт хиро — сборник хороших промптов: https://prompthero.com/
- Ведущие принципы качественных промптов — https://github.com/VILA-Lab/ATLAS. Ребята провели крутое исследование и опубликовали результаты.
P.S. Для чего я сам планирую использовать нейросети и что мне удалось накопать. А особо ничего — сейчас больше это для развлечения и совсем небольшой помощи. Действительно что-то автоматизировать или заменить, не на уровне говорящей головы, ничего не может. Но я в процессе поисков.
Генерация идей
Да, нашел пару сервисов. Но мое буйное воображение все равно справляется лучше
Создание скелетонов и набросков
Ничего нет толкового.
Хуманизация текстов
Да, есть пару сервисов, но они не палятся лишь при чеке другими нейросетями. Опытный глаз легко видит работу нечеловека.
Грамматика и ошибки
Тут навалом, много крутых сервисов.
Суммаризация и упрощение информации
Есть 2–3 игрока, но они достаточно бестолковые и под капотом GPT-3.5.
Генерация текстового контента
Есть 2 крутых игрока и много мелочи, но полноценного блогера даже для микропостинга это не сможет заменить.
Репурпойзинг (когда из большой статьи делается сторис в инстаграм)
Ничего нет на рынке
Генерация визуала
Тут много крутого, и уже очень далеко продвинулись. Но нормально писать текст на картинке еще никто не умеет.
Сторителлинг
Есть 2 сервиса которые хорошо как развивают истории, так и пишут с нуля. Но без готового скелета и действительно расписанного черновика генерят скучные вещи
Шутки, мемы, геги, реддит-триггеры
Действительно что-то забавное ничего особо делать не умеет
Автоматизация публикаций, кросспостинг
Ничего адекватного нет на рынке.
Написание автоматизаций и файлов
Есть пара крутых игроков, но по сути gpt-o1-pro справляется лучше.
Факт-чекинг
Никто пока не справляется
Поиск среди научных публикаций и обоснованных исследований
Есть несколько попыток, но результаты грустные
Вовлечение аудитории
Навалом сервисов, которые генерят заголовки, seo/aso теги
Выдержка тон-оф-войс и бренд стиля
Есть 3 хороших сервиса, но за просто космический прайс
🔥12👎6💩6
Привет, читатель! Последняя задачка эксперимента! На этой неделе я публиковал их ежедневно, чтобы понять, как тебе такой формат. Завтра подвожу итоги и буду ждать обратную связь — что зашло, что нет, и как можно сделать лучше. Очень важно твое мнение, так что обязательно загляни завтра. А еще начну новый эксперимент!
🔥9👎4💩3👏2🤡2
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях
Ситуация
Ты управляешь четырьмя проектами, и на одном из них команда выросла с 5 до 9 человек из-за увеличения задач. Операционка стала забирать всё время: нужно контролировать, кто что делает, решать мелкие конфликты, следить за сроками. Ты понимаешь, что пора назначить тимлида, чтобы разгрузить себя и наладить работу внутри команды
Но в этом выборе нет очевидного ответа. В команде есть три человека, каждый по-своему подходит для этой роли, но у каждого свои особенности
Проблема
Андрей — самый опытный в команде. Он знает проект от и до, может быстро разобраться в сложных вопросах и подсказать правильное решение. При этом он часто действует слишком жестко, его манера общения давит на людей. Андрей уверен, что роль тимлида должна быть его, и говорит об этом открыто. У него уже был опыт тимлида в предыдущей компании, однако это был большой финтех проект и над ним не было менеджеров, только CTO
Екатерина — тот человек, к которому все идут за советом. Она умеет слушать, поддерживать и помогает другим чувствовать себя комфортно в команде. Атмосфера с ней точно будет хорошей. Но она не всегда уверена в себе, особенно когда нужно принять сложное техническое решение или столкнуться с жесткой критикой. При этом она недавно взяла курс системного архитектора
Максим — самый энергичный и амбициозный. Ему нравится решать проблемы и брать ответственность за сложные задачи. Он горит желанием развиваться и готов работать сверхурочно, чтобы доказать свою ценность. Но у него пока не так много опыта, и не все в команде воспринимают его как равного. Однако лучше всех разбирается в новых технологиях и у него отличные навыки ментора, так как он участвует во многих менторских программах и является энтузиастом разработчиком, контрибьютящим в Open JDK и некоторые крупные npm пакеты
Вопрос
Ты выбрал Екатерину, потому что веришь, что её подход поможет команде стать более сплочённой. Но что, если её нерешительность или недостаток уверенности приведут к проблемам? Это правильное решение?
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях
Ситуация
Ты управляешь четырьмя проектами, и на одном из них команда выросла с 5 до 9 человек из-за увеличения задач. Операционка стала забирать всё время: нужно контролировать, кто что делает, решать мелкие конфликты, следить за сроками. Ты понимаешь, что пора назначить тимлида, чтобы разгрузить себя и наладить работу внутри команды
Но в этом выборе нет очевидного ответа. В команде есть три человека, каждый по-своему подходит для этой роли, но у каждого свои особенности
Проблема
Андрей — самый опытный в команде. Он знает проект от и до, может быстро разобраться в сложных вопросах и подсказать правильное решение. При этом он часто действует слишком жестко, его манера общения давит на людей. Андрей уверен, что роль тимлида должна быть его, и говорит об этом открыто. У него уже был опыт тимлида в предыдущей компании, однако это был большой финтех проект и над ним не было менеджеров, только CTO
Екатерина — тот человек, к которому все идут за советом. Она умеет слушать, поддерживать и помогает другим чувствовать себя комфортно в команде. Атмосфера с ней точно будет хорошей. Но она не всегда уверена в себе, особенно когда нужно принять сложное техническое решение или столкнуться с жесткой критикой. При этом она недавно взяла курс системного архитектора
Максим — самый энергичный и амбициозный. Ему нравится решать проблемы и брать ответственность за сложные задачи. Он горит желанием развиваться и готов работать сверхурочно, чтобы доказать свою ценность. Но у него пока не так много опыта, и не все в команде воспринимают его как равного. Однако лучше всех разбирается в новых технологиях и у него отличные навыки ментора, так как он участвует во многих менторских программах и является энтузиастом разработчиком, контрибьютящим в Open JDK и некоторые крупные npm пакеты
Вопрос
Ты выбрал Екатерину, потому что веришь, что её подход поможет команде стать более сплочённой. Но что, если её нерешительность или недостаток уверенности приведут к проблемам? Это правильное решение?
👍11
#кейс_стади
Задача на подумать для менеджера. Итоги эксперимента
Привет, читатель!
Как ты уже, наверное, заметил, последние 5 рабочих дней я публиковал каждый день с утра по одной управленческой задаче. Это был экспериментальный контент. Хотелось проверить, зайдёт ли такой формат, оживит ли он активность в канале и не станет ли мне накладно его писать
Спойлер: "накладно не стало!" Более того, я пишу посты примерно на неделю вперёд, и проблема скорее в том, чтобы выбрать из кучи тем для кейсов, чем придумывать что-то новое
Теперь к сути. Перед запуском этого эксперимента у меня было несколько гипотез:
1. Если выпускать задачи утром (в районе 9–10 по Москве), это будет удобно для аудитории. Думал, что такой тайминг даст 2–3% прироста вовлечённости;
2. Ежедневный контент покажет, что канал более живой и активный чем обычно. Это должно было привлечь новых подписчиков — хотя бы на 20–30% больше обычного;
3. Если публиковать кейсы в формате открытых вопросов, это увеличит количество реакций и комментариев.** Ожидал прироста на 20% день ото дня.
Что же получилось на практике?
1️⃣ Утренний тайминг
Утро оказалось действительно удобным временем. Большинство просмотров собирается в первые 1–2 часа после публикации (до 57% от общего охвата). Но, увы, прироста вовлечённости на 2–3% не случилось. ERR держится в привычном диапазоне 16–24.8%.
2️⃣ Ежедневные посты
Тут интересно. Активность подписчиков стабильна, но бури новых подписчиков не случилось. За месяц +14 человек — это примерно в рамках стандартного роста. То есть аудитория оценила регулярность, но это не сделало канал виральным
3️⃣ Формат открытых кейсов
Комментарии есть, но их мало (0–2 на пост). Реакций тоже немного (в среднем 12–20). Ожидаемого прироста на 20% не произошло. Видимо, чтобы разговорить аудиторию, нужно искать другие подходы — пока этот формат работает, но без фейерверков
Дополню двумя наблюдениями
4️⃣ Длина постов.
Я пробовал оставлять задачи максимально лаконичными, без лишней воды. И это сработало. Длинные кейсы не дали никакого прироста в охвате или вовлечённости. Короткие формулировки удобнее воспринимаются.
5️⃣ Регулярность
Честно, ежедневный постинг требует дисциплины, но для меня это пока нормально. Заметил, что слишком частые публикации (каждый день) могут слегка "примелькаться", и ERR остаётся на том же уровне, что и при менее частом постинге. Может, стоит подумать над форматом "пост через день" или миксовать с чем-то большим и более глубоким
А теперь мне интересно твоё мнение! Понравился ли тебе этот эксперимент с задачами? Стоит ли продолжать?
👉 Оставить детальную обратную связь можно по этой ссылке
А если хочется просто поделиться своими мыслями — пиши в комментарии в свободном формате, буду рад почитать!
P.S. Что будет дальше - я возьму паузу до конца недели собрать обратную связь и подумать что делать с форматом. А еще вечером сегодня запущу новый, также ради теста!
P.P.S В целом выше наглядный эксперимент как запускать изменения - они должны быть с четкими гипотезами "зачем" и планом управления изменением. Я безопасно внес изменение, попробовал, ушел делать выводы. По их результатам будет наверняка что-то, что улучшит систему
Задача на подумать для менеджера. Итоги эксперимента
Привет, читатель!
Как ты уже, наверное, заметил, последние 5 рабочих дней я публиковал каждый день с утра по одной управленческой задаче. Это был экспериментальный контент. Хотелось проверить, зайдёт ли такой формат, оживит ли он активность в канале и не станет ли мне накладно его писать
Спойлер: "накладно не стало!" Более того, я пишу посты примерно на неделю вперёд, и проблема скорее в том, чтобы выбрать из кучи тем для кейсов, чем придумывать что-то новое
Теперь к сути. Перед запуском этого эксперимента у меня было несколько гипотез:
1. Если выпускать задачи утром (в районе 9–10 по Москве), это будет удобно для аудитории. Думал, что такой тайминг даст 2–3% прироста вовлечённости;
2. Ежедневный контент покажет, что канал более живой и активный чем обычно. Это должно было привлечь новых подписчиков — хотя бы на 20–30% больше обычного;
3. Если публиковать кейсы в формате открытых вопросов, это увеличит количество реакций и комментариев.** Ожидал прироста на 20% день ото дня.
Что же получилось на практике?
1️⃣ Утренний тайминг
Утро оказалось действительно удобным временем. Большинство просмотров собирается в первые 1–2 часа после публикации (до 57% от общего охвата). Но, увы, прироста вовлечённости на 2–3% не случилось. ERR держится в привычном диапазоне 16–24.8%.
2️⃣ Ежедневные посты
Тут интересно. Активность подписчиков стабильна, но бури новых подписчиков не случилось. За месяц +14 человек — это примерно в рамках стандартного роста. То есть аудитория оценила регулярность, но это не сделало канал виральным
3️⃣ Формат открытых кейсов
Комментарии есть, но их мало (0–2 на пост). Реакций тоже немного (в среднем 12–20). Ожидаемого прироста на 20% не произошло. Видимо, чтобы разговорить аудиторию, нужно искать другие подходы — пока этот формат работает, но без фейерверков
Дополню двумя наблюдениями
4️⃣ Длина постов.
Я пробовал оставлять задачи максимально лаконичными, без лишней воды. И это сработало. Длинные кейсы не дали никакого прироста в охвате или вовлечённости. Короткие формулировки удобнее воспринимаются.
5️⃣ Регулярность
Честно, ежедневный постинг требует дисциплины, но для меня это пока нормально. Заметил, что слишком частые публикации (каждый день) могут слегка "примелькаться", и ERR остаётся на том же уровне, что и при менее частом постинге. Может, стоит подумать над форматом "пост через день" или миксовать с чем-то большим и более глубоким
А теперь мне интересно твоё мнение! Понравился ли тебе этот эксперимент с задачами? Стоит ли продолжать?
👉 Оставить детальную обратную связь можно по этой ссылке
А если хочется просто поделиться своими мыслями — пиши в комментарии в свободном формате, буду рад почитать!
P.S. Что будет дальше - я возьму паузу до конца недели собрать обратную связь и подумать что делать с форматом. А еще вечером сегодня запущу новый, также ради теста!
P.P.S В целом выше наглядный эксперимент как запускать изменения - они должны быть с четкими гипотезами "зачем" и планом управления изменением. Я безопасно внес изменение, попробовал, ушел делать выводы. По их результатам будет наверняка что-то, что улучшит систему
👍29🔥8🤔2
#напутствие
Еще новый тип постов
Читатель, перед нами новый эксперимент. Мы попробуем еще один тип контента. Еще более простой и такой же регулярный. Мне бы лично очень пригодилось что-то, что позволяло пересиливать вечную хандру и демотивацию. Да, я знаю что я работаю менеджером, делаю организационные чудеса и превращаю порядок в хаос. Однако намного больше обесценивающий мыслей и демотивирующих факторов
Безусловно, существует позиция серого кардинала или менеджера-зеркала, как часто выступают скрам-мастера. Мне безусловно не говорят спасибо, но в своих глазах я герой невидимого фронта и без меня все было бы не так радужно. Поэтому да, я хочу попробовать позакидывать в канал более простой и дружелюбный контент. Этакое напутствие от меня
Еще новый тип постов
Читатель, перед нами новый эксперимент. Мы попробуем еще один тип контента. Еще более простой и такой же регулярный. Мне бы лично очень пригодилось что-то, что позволяло пересиливать вечную хандру и демотивацию. Да, я знаю что я работаю менеджером, делаю организационные чудеса и превращаю порядок в хаос. Однако намного больше обесценивающий мыслей и демотивирующих факторов
Безусловно, существует позиция серого кардинала или менеджера-зеркала, как часто выступают скрам-мастера. Мне безусловно не говорят спасибо, но в своих глазах я герой невидимого фронта и без меня все было бы не так радужно. Поэтому да, я хочу попробовать позакидывать в канал более простой и дружелюбный контент. Этакое напутствие от меня
🔥19🍾1
#напутствие
Почему я работаю менеджером
Новый год, заказчик уже мечтает запускать ракеты, а твоя команда ещё в режиме 'мандариновый дзен'. Придётся собирать всех по кусочкам: где-то подбодрить, где-то подпнуть, где-то напомнить, что дедлайн – не просто слово из прошлого года. Включай харизму и системность – они подтянутся, а ты станешь героем этого января
Почему я работаю менеджером
Новый год, заказчик уже мечтает запускать ракеты, а твоя команда ещё в режиме 'мандариновый дзен'. Придётся собирать всех по кусочкам: где-то подбодрить, где-то подпнуть, где-то напомнить, что дедлайн – не просто слово из прошлого года. Включай харизму и системность – они подтянутся, а ты станешь героем этого января
🔥38👍5
#напутствие
Почему я работаю менеджером
Команде может не нравиться джира, и они пытаются скинуть на тебя все тикеты. Но когда они увидят, что доска реально работает и экономит им время на уточнения, порядок станет их союзником. Ты строишь систему, которая избавит их от лишней головной боли – и они это заметят
Почему я работаю менеджером
Команде может не нравиться джира, и они пытаются скинуть на тебя все тикеты. Но когда они увидят, что доска реально работает и экономит им время на уточнения, порядок станет их союзником. Ты строишь систему, которая избавит их от лишней головной боли – и они это заметят
🔥44👍4
#мнение
Опять про сторипойнты и эти оценки из agile
Здравствуй, читатель! Почему относительные оценки — не серебряная пуля, но работают (иногда)
Когда речь заходит об оценке задач в а-жаль, всегда найдутся те, кто скажет: "Story Points спасут мир!". Смотри, это точнее, проще, удобнее! А абсолютные оценки (в часах или днях) — прошлый век. Давай в очередной раз разберемся: так ли это на самом деле?
Спойлер: Story Points — не магия и не гарантия успеха. Они не сделают вашу команду суперточной машиной по оценке. Но есть очевидные плюсы, которые часто упускают
Почему Story Points не идеальны?
1) Неточность заложена в подход
Оценки всегда субъективны. Что абсолютные, что относительные. Разница лишь в том, что Story Points маскируют вашу неуверенность под "умные" числа. И ими проще отбиваться от чрезмерного микроменеджмента. Как выяснилось из исследования https://onlinelibrary.wiley.com/doi/full/10.1002/spe.3333, опыт команды почти не влияет на точность. Даже эксперты могут ошибаться — просто чуть реже, чем новички;
2) Они не универсальны
Если вы работаете с новичками, они могут переоценивать простые задачи и недооценивать сложные. Если команда не привыкла к Story Points, результат будет таким же хаотичным, как и при абсолютных оценках;
3) Игра в покер — это не всегда весело
Planning Poker, конечно, классная штука. Но если вы не понимаете, как им пользоваться, он превращается в долгую, утомительную дискуссию, после которой команда хочет оценить только одно: свою усталость.
Но у них есть плюсы. И важные:
1) Они учат команду думать вместе
Когда вы обсуждаете задачу в формате "это сложнее, чем то, что мы делали вчера?", появляется общая картинка. Команда начинает лучше понимать друг друга и проект;
2) Они помогают избежать споров про часы
Story Points не про время, а про усилия. Это убирает ненужные разговоры вроде: "Как ты можешь делать эту задачу 8 часов, если я бы сделал за 3?";
3) Они проще адаптируются под реальность
Если что-то пошло не так (а в Agile это почти гарантировано), Story Points легче перенастроить, чем абсолютные оценки;
4) Они делают планирование менее неприятным
Никто не уходит с планирование с ощущением, что ему "выставили счёт". Все понимают (если это адекватно внедрено), что оценки — это инструмент, а не правда в последней инстанции.
Что важно помнить, работая с Story Points?
1. Planning Poker — это не про числа, а про общение
Не нужно затягивать процесс. Если вся команда согласилась на одну оценку — не тратьте время, идите дальше;
2. Делайте ретроспективы оценок
После каждой итерации смотрите, где вы промахнулись. Это поможет команде учиться и делать точные прогнозы в будущем;
3. Не превращайте Story Points в часы
Как только начнёте говорить "1 SP — это примерно 2 часа", весь смысл метода исчезнет;
4. Сравнивайте внутри спринта
Самое главное — держать контекст. Оценки становятся хаотичными, если вы сравниваете задачу из прошлого года с тем, что делаете сегодня.
На эту тему я уже писал раньше:
- Почему Story Points — это не ловушка https://t.me/junior_pm/99
- В целом про оценки https://t.me/junior_pm/167
И рекомендую заглянуть в исследование и его ссылки. Оно подтверждает, что Story Points эффективны, если команда сфокусирована на процессе, а не на числах. Те как не забавно и не контринтуитивно, но относительные оценки приносят пользу только когда фокус смещен с оценок на коммуникации
P.S.
Story Points — это не серебряная пуля. Но если использовать их правильно, они делают команду сплочённой, а процесс оценки — осознанным и менее токсичным. А если вы ещё не пробовали Planning Poker — самое время начать.
Что думаете? Как у вас проходят оценочные сессии? Делитесь опытом в комментария
Опять про сторипойнты и эти оценки из agile
Здравствуй, читатель! Почему относительные оценки — не серебряная пуля, но работают (иногда)
Когда речь заходит об оценке задач в а-жаль, всегда найдутся те, кто скажет: "Story Points спасут мир!". Смотри, это точнее, проще, удобнее! А абсолютные оценки (в часах или днях) — прошлый век. Давай в очередной раз разберемся: так ли это на самом деле?
Спойлер: Story Points — не магия и не гарантия успеха. Они не сделают вашу команду суперточной машиной по оценке. Но есть очевидные плюсы, которые часто упускают
Почему Story Points не идеальны?
1) Неточность заложена в подход
Оценки всегда субъективны. Что абсолютные, что относительные. Разница лишь в том, что Story Points маскируют вашу неуверенность под "умные" числа. И ими проще отбиваться от чрезмерного микроменеджмента. Как выяснилось из исследования https://onlinelibrary.wiley.com/doi/full/10.1002/spe.3333, опыт команды почти не влияет на точность. Даже эксперты могут ошибаться — просто чуть реже, чем новички;
2) Они не универсальны
Если вы работаете с новичками, они могут переоценивать простые задачи и недооценивать сложные. Если команда не привыкла к Story Points, результат будет таким же хаотичным, как и при абсолютных оценках;
3) Игра в покер — это не всегда весело
Planning Poker, конечно, классная штука. Но если вы не понимаете, как им пользоваться, он превращается в долгую, утомительную дискуссию, после которой команда хочет оценить только одно: свою усталость.
Но у них есть плюсы. И важные:
1) Они учат команду думать вместе
Когда вы обсуждаете задачу в формате "это сложнее, чем то, что мы делали вчера?", появляется общая картинка. Команда начинает лучше понимать друг друга и проект;
2) Они помогают избежать споров про часы
Story Points не про время, а про усилия. Это убирает ненужные разговоры вроде: "Как ты можешь делать эту задачу 8 часов, если я бы сделал за 3?";
3) Они проще адаптируются под реальность
Если что-то пошло не так (а в Agile это почти гарантировано), Story Points легче перенастроить, чем абсолютные оценки;
4) Они делают планирование менее неприятным
Никто не уходит с планирование с ощущением, что ему "выставили счёт". Все понимают (если это адекватно внедрено), что оценки — это инструмент, а не правда в последней инстанции.
Что важно помнить, работая с Story Points?
1. Planning Poker — это не про числа, а про общение
Не нужно затягивать процесс. Если вся команда согласилась на одну оценку — не тратьте время, идите дальше;
2. Делайте ретроспективы оценок
После каждой итерации смотрите, где вы промахнулись. Это поможет команде учиться и делать точные прогнозы в будущем;
3. Не превращайте Story Points в часы
Как только начнёте говорить "1 SP — это примерно 2 часа", весь смысл метода исчезнет;
4. Сравнивайте внутри спринта
Самое главное — держать контекст. Оценки становятся хаотичными, если вы сравниваете задачу из прошлого года с тем, что делаете сегодня.
На эту тему я уже писал раньше:
- Почему Story Points — это не ловушка https://t.me/junior_pm/99
- В целом про оценки https://t.me/junior_pm/167
И рекомендую заглянуть в исследование и его ссылки. Оно подтверждает, что Story Points эффективны, если команда сфокусирована на процессе, а не на числах. Те как не забавно и не контринтуитивно, но относительные оценки приносят пользу только когда фокус смещен с оценок на коммуникации
P.S.
Story Points — это не серебряная пуля. Но если использовать их правильно, они делают команду сплочённой, а процесс оценки — осознанным и менее токсичным. А если вы ещё не пробовали Planning Poker — самое время начать.
Что думаете? Как у вас проходят оценочные сессии? Делитесь опытом в комментария
👍24🔥11😁3👎1🕊1
#напутствие
Почему я работаю менеджером
Половина команды в отпуске, заказчик пишет капсом, а релиз уже завтра? Ты не волшебник, но точно найдёшь, как закрыть дыры. Приоритизация, временные костыли и пара срочных звонков – и ты снова превратишь хаос в управляемый бардак. Главное, ты всегда держишь процесс под контролем. А еще не забывай про крепкие словца
Почему я работаю менеджером
Половина команды в отпуске, заказчик пишет капсом, а релиз уже завтра? Ты не волшебник, но точно найдёшь, как закрыть дыры. Приоритизация, временные костыли и пара срочных звонков – и ты снова превратишь хаос в управляемый бардак. Главное, ты всегда держишь процесс под контролем. А еще не забывай про крепкие словца
🔥47👏8
#напутствие
Почему я работаю менеджером
Неделя заканчивается, а то, что обещали закрыть, всё ещё висит в воздухе. Ты-то знал, что так и будет, но вместо паники – чёткий план: выдели главное, собери команду, зафиксируй, что реально можно сделать сразу в начале недели и уже показать что работа не стоит на месте и дай возможность четко отслеживать прогресс. Время на нытье– после дедлайна, сейчас важно довести до финиша что-то полезное. Все всегда сделать нереально
Почему я работаю менеджером
Неделя заканчивается, а то, что обещали закрыть, всё ещё висит в воздухе. Ты-то знал, что так и будет, но вместо паники – чёткий план: выдели главное, собери команду, зафиксируй, что реально можно сделать сразу в начале недели и уже показать что работа не стоит на месте и дай возможность четко отслеживать прогресс. Время на нытье– после дедлайна, сейчас важно довести до финиша что-то полезное. Все всегда сделать нереально
👍30🔥17
#рецепты
Вводим больше бюрократии с помощью DoD. Часть 1
Здравствуй, читатель!
Последние полгода я, признаться, выключил DoD из наших процессов. Причина — бизнес-критикал кейсы, которые требовали моего максимального вовлечения. Иногда я работал буквально как эникейщик: от настройки инфраструктуры до тестирования багов. Мы даунгрейдили процессы ради выживания. Теперь же я возвращаю DoD и хочу рассказать, почему это намой взгляд важно
Сперва как обычно немного теории, чтобы выровняться и говорить на одном языке
Что такое DoD?
Definition of Done — это минимальные требования, которые должны быть соблюдены, чтобы задача считалась выполненной. Это не про конкретную задачу, а про общий стандарт качества. DoD отвечает на вопрос: как мы поймём, что работа сделана качественно? Например: тесты пройдены, документация написана, код соотв. принятому стилю. Если DoD выполняется по всем задачам, можно “почти быть уверенным” в качестве итогового продукта
Махровая теория: quality gate и shift left
DoD — это часть двух больших концепций: quality gate и shift left. Quality gate — это контрольные точки, где проверяется качество на каждом этапе работы. Shift left — это перенос проверок качества на более ранние стадии, чтобы выявлять проблемы как можно раньше. В этом контексте DoD — это финальный quality gate, который гарантирует, что результат полностью готов
Чем отличаются DoD, DoR и AC?
Их часто путают. Хотя все три — это quality gate, их роли различны:
- DoR (Definition of Ready): требования к задаче, чтобы её можно было начать. Если задача переходит от менеджера к команде, то DoR — это чеклист для менеджера. Например, задача должна быть чётко описана, иметь все входные данные и учтённые зависимости;
- AC (Acceptance Criteria): требования к тому, как должен вести себя результат задачи. Это простой перечень того, что результат должен уметь, чтобы заказчик сказал: «Да, это то, что мне нужно»;
- DoD: критерии, которые показывают, что задача выполнена с должным качеством. Это не только про соответствие ТЗ, но и про тесты, документацию, ревью — всё, что делает результат стабильным и готовым к использованию.
Почему DoD — «дорогая» практика?
DoD — это инвестиция, которая требует усилий.
1. Ресурсы. Нужно время на написание тестов, документации, проведение ревью;
2. Замедление работы. На первых этапах команда работает медленнее, но это снижает количество багов в будущем;
3. Повышение планки. Например, если в DoD прописано писать юнит-тесты или релиз-ноутсы, команда должна этому научиться;
4. Долгосрочная выгода. В будущем DoD снижает затраты на доработки, стабилизирует продукт и улучшает отношения с заказчиками.
В следующем посте я расскажу, как мы вернули DoD, какие шаги предприняли и какие трудности пришлось преодолеть
P.S. Если хочешь вспомнить и другие похожие аббревиатуры, загляни в https://t.me/junior_pm/35 😉
P.P.S. А еще мы решили вернуть DoD потому что стали забывать некоторые важные вещи делать и он позволяет не забывать
Вводим больше бюрократии с помощью DoD. Часть 1
Здравствуй, читатель!
Последние полгода я, признаться, выключил DoD из наших процессов. Причина — бизнес-критикал кейсы, которые требовали моего максимального вовлечения. Иногда я работал буквально как эникейщик: от настройки инфраструктуры до тестирования багов. Мы даунгрейдили процессы ради выживания. Теперь же я возвращаю DoD и хочу рассказать, почему это намой взгляд важно
Сперва как обычно немного теории, чтобы выровняться и говорить на одном языке
Что такое DoD?
Definition of Done — это минимальные требования, которые должны быть соблюдены, чтобы задача считалась выполненной. Это не про конкретную задачу, а про общий стандарт качества. DoD отвечает на вопрос: как мы поймём, что работа сделана качественно? Например: тесты пройдены, документация написана, код соотв. принятому стилю. Если DoD выполняется по всем задачам, можно “почти быть уверенным” в качестве итогового продукта
Махровая теория: quality gate и shift left
DoD — это часть двух больших концепций: quality gate и shift left. Quality gate — это контрольные точки, где проверяется качество на каждом этапе работы. Shift left — это перенос проверок качества на более ранние стадии, чтобы выявлять проблемы как можно раньше. В этом контексте DoD — это финальный quality gate, который гарантирует, что результат полностью готов
Чем отличаются DoD, DoR и AC?
Их часто путают. Хотя все три — это quality gate, их роли различны:
- DoR (Definition of Ready): требования к задаче, чтобы её можно было начать. Если задача переходит от менеджера к команде, то DoR — это чеклист для менеджера. Например, задача должна быть чётко описана, иметь все входные данные и учтённые зависимости;
- AC (Acceptance Criteria): требования к тому, как должен вести себя результат задачи. Это простой перечень того, что результат должен уметь, чтобы заказчик сказал: «Да, это то, что мне нужно»;
- DoD: критерии, которые показывают, что задача выполнена с должным качеством. Это не только про соответствие ТЗ, но и про тесты, документацию, ревью — всё, что делает результат стабильным и готовым к использованию.
Почему DoD — «дорогая» практика?
DoD — это инвестиция, которая требует усилий.
1. Ресурсы. Нужно время на написание тестов, документации, проведение ревью;
2. Замедление работы. На первых этапах команда работает медленнее, но это снижает количество багов в будущем;
3. Повышение планки. Например, если в DoD прописано писать юнит-тесты или релиз-ноутсы, команда должна этому научиться;
4. Долгосрочная выгода. В будущем DoD снижает затраты на доработки, стабилизирует продукт и улучшает отношения с заказчиками.
В следующем посте я расскажу, как мы вернули DoD, какие шаги предприняли и какие трудности пришлось преодолеть
P.S. Если хочешь вспомнить и другие похожие аббревиатуры, загляни в https://t.me/junior_pm/35 😉
P.P.S. А еще мы решили вернуть DoD потому что стали забывать некоторые важные вещи делать и он позволяет не забывать
🔥26👍5🤔4
#полезности
Вводим больше бюрократии с помощью DoD. Часть 2
Введение DoD требует участия всех, кто связан с процессом разработки. Вот ключевые шаги:
1. Собери команду. Важно, чтобы разработчики, тестировщики, менеджеры и любые другие ключевые участники обсудили, что они понимают под «готовностью»;
2. Проведи воркшоп. Вместе составьте список минимальных требований для всех типов задач (баги, фичи, техдолг). Это должна быть командная работа, чтобы все приняли DoD как свой инструмент. Важно учесть что для разных типов работы может быть разный DoD. Мы пока сделали только для фичей;
3. Протестируй DoD. Введите его на несколько спринтов, фиксируя проблемы и улучшения;
4. Закрепите DoD. После тестирования утвердите DoD как обязательный стандарт.
Важно, чтобы DoD пересматривался на ретроспективах (если их нет, то вообще была опция его обсудить и пересмотреть). Это живой документ,
Почему DoD должен охватывать весь процесс команды, а не только финальный этап
DoD часто воспринимают как чеклист для последнего этапа перед релизом. Это ошибка. Если DoD ограничивается только финальными шагами, проблемы накапливаются в процессе разработки.
Пример: если DoD охватывает только тестирование и релиз, никто не проверит читаемость и адекватность на код-ревью. Как результат, вероятность ошибки потом при апдейтах новой фичи сильно возрастет
DoD должен покрывать весь процесс. Условно:
- Стадия планирования: план разработки, систем ревью. Тут важно держать баланс с DoR;
- Стадия разработки: код проверен и покрыт тестами;
- Стадия тестирования: все критичные дефекты устранены;
- Стадия релиза: релиз-ноутсы оформлены и фича работает на проде.
Такой подход предотвращает «эффект снежного кома», когда небольшие недочёты превращаются в крупные проблемы.
Наш текущий DoD:
Вот текущий DoD, который мы используем в моей команде:
- Фича-флаг Firebase (если применимо);
- Ремоут-конфиг Firebase (если применимо);
- Диплинк (если применимо);
- Написан юнит-тест или заведена задача на его написание;
- Описание, как ревьюить;
- Описание, как тестировать;
- Заполнен дев-компонент;
- MR направлен в корректную ветку;
- Пройден код-ревью;
- QA обеспечивает тестовое покрытие (тест-кейс, чек-лист и т.д.);
- Задача протестирована, есть комментарий с результатом;
- MR влит в корректную ветку.
Это не-универсальный набор для любой задачи, пока только для сторей
Как я устанавливал и дорабатывал DoD заново
После периода «выключения» DoD я начал возвращать его шаг за шагом.
1. Анализ ситуации. Я оценил, почему прошлый DoD не сработал, и какие элементы команды были не готовы соблюдать. Например, отсутствие знаний в написании тестов или отсутствие документации. В нашем случае он был слишком абстрактным и неконкретным;
2. Собрание команды. Мы провели (и еще проведем) несколько встреч, где обсудили ценность DoD и его влияние на продукт. Важно было убедить команду, что DoD — это не просто бюрократия, а инструмент, который помогает;
3. Постепенное внедрение.** По-хорошему стоит добавлять элементы DoD не сразу, а поэтапно. Сначала — ревью, потом написание мануал тестов, затем тесты документации и так далее. Это позволит избежать перегрузок команды одномоментно;
4. Регулярные проверки. Мы обсуждаем, что работает, а что — нет. Некоторые пункты придется доработать. Например, упростить требования к юнитам;
5. Закрепление. После тестового периода я закреплю DoD как обязательный стандарт. Но уже он — неотъемлемая часть наших процессов.
В общем в лучших традициях ADKAR
Вводим больше бюрократии с помощью DoD. Часть 2
Введение DoD требует участия всех, кто связан с процессом разработки. Вот ключевые шаги:
1. Собери команду. Важно, чтобы разработчики, тестировщики, менеджеры и любые другие ключевые участники обсудили, что они понимают под «готовностью»;
2. Проведи воркшоп. Вместе составьте список минимальных требований для всех типов задач (баги, фичи, техдолг). Это должна быть командная работа, чтобы все приняли DoD как свой инструмент. Важно учесть что для разных типов работы может быть разный DoD. Мы пока сделали только для фичей;
3. Протестируй DoD. Введите его на несколько спринтов, фиксируя проблемы и улучшения;
4. Закрепите DoD. После тестирования утвердите DoD как обязательный стандарт.
Важно, чтобы DoD пересматривался на ретроспективах (если их нет, то вообще была опция его обсудить и пересмотреть). Это живой документ,
Почему DoD должен охватывать весь процесс команды, а не только финальный этап
DoD часто воспринимают как чеклист для последнего этапа перед релизом. Это ошибка. Если DoD ограничивается только финальными шагами, проблемы накапливаются в процессе разработки.
Пример: если DoD охватывает только тестирование и релиз, никто не проверит читаемость и адекватность на код-ревью. Как результат, вероятность ошибки потом при апдейтах новой фичи сильно возрастет
DoD должен покрывать весь процесс. Условно:
- Стадия планирования: план разработки, систем ревью. Тут важно держать баланс с DoR;
- Стадия разработки: код проверен и покрыт тестами;
- Стадия тестирования: все критичные дефекты устранены;
- Стадия релиза: релиз-ноутсы оформлены и фича работает на проде.
Такой подход предотвращает «эффект снежного кома», когда небольшие недочёты превращаются в крупные проблемы.
Наш текущий DoD:
Вот текущий DoD, который мы используем в моей команде:
- Фича-флаг Firebase (если применимо);
- Ремоут-конфиг Firebase (если применимо);
- Диплинк (если применимо);
- Написан юнит-тест или заведена задача на его написание;
- Описание, как ревьюить;
- Описание, как тестировать;
- Заполнен дев-компонент;
- MR направлен в корректную ветку;
- Пройден код-ревью;
- QA обеспечивает тестовое покрытие (тест-кейс, чек-лист и т.д.);
- Задача протестирована, есть комментарий с результатом;
- MR влит в корректную ветку.
Это не-универсальный набор для любой задачи, пока только для сторей
Как я устанавливал и дорабатывал DoD заново
После периода «выключения» DoD я начал возвращать его шаг за шагом.
1. Анализ ситуации. Я оценил, почему прошлый DoD не сработал, и какие элементы команды были не готовы соблюдать. Например, отсутствие знаний в написании тестов или отсутствие документации. В нашем случае он был слишком абстрактным и неконкретным;
2. Собрание команды. Мы провели (и еще проведем) несколько встреч, где обсудили ценность DoD и его влияние на продукт. Важно было убедить команду, что DoD — это не просто бюрократия, а инструмент, который помогает;
3. Постепенное внедрение.** По-хорошему стоит добавлять элементы DoD не сразу, а поэтапно. Сначала — ревью, потом написание мануал тестов, затем тесты документации и так далее. Это позволит избежать перегрузок команды одномоментно;
4. Регулярные проверки. Мы обсуждаем, что работает, а что — нет. Некоторые пункты придется доработать. Например, упростить требования к юнитам;
5. Закрепление. После тестового периода я закреплю DoD как обязательный стандарт. Но уже он — неотъемлемая часть наших процессов.
В общем в лучших традициях ADKAR
👍17🔥8