🚀 Всем успешной доставки!
Сегодня хочется поговорить про очень сложную тему - эффективность IT-команд.
По моему мнению эффективность команды — это когда вы делаете больше, тратя меньше (времени, денег и нервов). В IT это означает:
-Быстро, но без косяков: задачи выполняются в срок, а баги не плодятся как кролики.
-Минимум переделок: чтобы не приходилось переписывать код, как школьное сочинение.
-Довольные клиенты: чтобы они не писали гневные письма, а ставили лайки.
Можно попробовать сформировать показатели эффективности
-Скорость выполнения задач (Throughput)
Сколько задач команда закрывает за неделю? Если это число растет, вы на правильном пути. Если нет, возможно, пора пересмотреть приоритеты (или купить больше кофе).
-Время выполнения задач (Lead Time)
Сколько времени проходит от поступления задачи до ее завершения? Если Lead Time растет, это повод задуматься.
-Качество продукта
Сколько багов вы находите после релиза? Если их больше, чем звезд на небе 😏, пора усилить тестирование .
-Удовлетворенность клиентов
Что говорят клиенты? Если они счастливы, вы молодец. Если нет, пора включать режим "спасатель".
Получается, эффективность IT-команд — это не про скорость, а про умение работать с умом.
Чтобы достичь максимума, важно:
-Использовать метрики для анализа и улучшения процессов.
-Внедрять инструменты и практики, которые повышают продуктивность.
-Учитывать обратную связь от клиентов и команды.
-Инвестировать в обучение и развитие сотрудников.
А как вы повышаете эффективность своей команды? Делитесь опытом в комментариях!
А еще можно послушать про эффективность в подкасте "Письма Лиды Таймовны", как раз вышел новый сезон 👍
Сегодня хочется поговорить про очень сложную тему - эффективность IT-команд.
По моему мнению эффективность команды — это когда вы делаете больше, тратя меньше (времени, денег и нервов). В IT это означает:
-Быстро, но без косяков: задачи выполняются в срок, а баги не плодятся как кролики.
-Минимум переделок: чтобы не приходилось переписывать код, как школьное сочинение.
-Довольные клиенты: чтобы они не писали гневные письма, а ставили лайки.
Можно попробовать сформировать показатели эффективности
-Скорость выполнения задач (Throughput)
Сколько задач команда закрывает за неделю? Если это число растет, вы на правильном пути. Если нет, возможно, пора пересмотреть приоритеты (или купить больше кофе).
-Время выполнения задач (Lead Time)
Сколько времени проходит от поступления задачи до ее завершения? Если Lead Time растет, это повод задуматься.
-Качество продукта
Сколько багов вы находите после релиза? Если их больше, чем звезд на небе 😏, пора усилить тестирование .
-Удовлетворенность клиентов
Что говорят клиенты? Если они счастливы, вы молодец. Если нет, пора включать режим "спасатель".
Получается, эффективность IT-команд — это не про скорость, а про умение работать с умом.
Чтобы достичь максимума, важно:
-Использовать метрики для анализа и улучшения процессов.
-Внедрять инструменты и практики, которые повышают продуктивность.
-Учитывать обратную связь от клиентов и команды.
-Инвестировать в обучение и развитие сотрудников.
А как вы повышаете эффективность своей команды? Делитесь опытом в комментариях!
А еще можно послушать про эффективность в подкасте "Письма Лиды Таймовны", как раз вышел новый сезон 👍
🔥4❤3👍2
🚀 Всем успешной доставки!
А как вы оформляете значимые для вас документы? Например обоснование зачем нужно делать именно эту фичу?
Сегодня поговорим про такой формат документов как 1-Pager и 6-Pager.
Что такое 1-Pager?
1-Pager — это краткий документ, который умещается на одной странице. Его цель — быстро донести ключевые идеи и предложения🔥 .
Структура 1-Pager:
Проблема: Краткое описание проблемы или задачи.
Решение: Основные идеи или предложения.
Преимущества: Почему это решение стоит рассмотреть?
Действия: Что нужно сделать для реализации?
Преимущества 1-Pager:
-Быстрое чтение и понимание.
-Подходит для презентации идей на встречах.
-Помогает сосредоточиться на главном.
Пример использования:
Если вы хотите предложить новую функцию продукта, 1-Pager поможет быстро донести идею до заинтересованных лиц.
Что такое 6-Pager?
6-Pager — это более детализированный документ, который занимает до шести страниц. Он используется для глубокого анализа проблемы и предложения решений.
Структура 6-Pager:
Введение: Краткое описание проблемы и цели документа.
Контекст: Почему эта проблема важна?
Анализ: Данные, исследования и факты, которые поддерживают предложение.
Решение: Подробное описание предлагаемого решения.
Преимущества и риски: Какие выгоды и возможные проблемы?
Рекомендации: Что нужно сделать для реализации?
Преимущества 6-Pager:
-Глубокий анализ проблемы.
-Подходит для принятия стратегических решений.
-Позволяет учесть все аспекты предложения.
Пример использования:
Если вы предлагаете масштабное изменение в продукте или процессе, 6-Pager поможет детально обосновать ваше предложение.
Как выбрать между 1-Pager и 6-Pager?
Используйте 1-Pager, если:
-Нужно быстро донести идею.
-Решение простое и не требует глубокого анализа.
-Время на принятие решения ограничено.
Используйте 6-Pager, если:
-Проблема сложная и требует детального анализа.
-Решение имеет долгосрочные последствия.
-Нужно убедить ключевых стейкхолдеров.
Итог
1-Pager и 6-Pager — это мощные инструменты для документирования идей и решений. Чтобы использовать их эффективно, важно:
-Выбирать подходящий формат в зависимости от задачи.
-Сосредоточиться на главном и избегать лишних деталей.
-Подкреплять аргументы данными и фактами.
У вас уже внедрен 1 pager или 6-pager? Для чего вы его используете?
#1pager #6pager #полезное
А как вы оформляете значимые для вас документы? Например обоснование зачем нужно делать именно эту фичу?
Сегодня поговорим про такой формат документов как 1-Pager и 6-Pager.
Что такое 1-Pager?
1-Pager — это краткий документ, который умещается на одной странице. Его цель — быстро донести ключевые идеи и предложения
Структура 1-Pager:
Проблема: Краткое описание проблемы или задачи.
Решение: Основные идеи или предложения.
Преимущества: Почему это решение стоит рассмотреть?
Действия: Что нужно сделать для реализации?
Преимущества 1-Pager:
-Быстрое чтение и понимание.
-Подходит для презентации идей на встречах.
-Помогает сосредоточиться на главном.
Пример использования:
Если вы хотите предложить новую функцию продукта, 1-Pager поможет быстро донести идею до заинтересованных лиц.
Что такое 6-Pager?
6-Pager — это более детализированный документ, который занимает до шести страниц. Он используется для глубокого анализа проблемы и предложения решений.
Структура 6-Pager:
Введение: Краткое описание проблемы и цели документа.
Контекст: Почему эта проблема важна?
Анализ: Данные, исследования и факты, которые поддерживают предложение.
Решение: Подробное описание предлагаемого решения.
Преимущества и риски: Какие выгоды и возможные проблемы?
Рекомендации: Что нужно сделать для реализации?
Преимущества 6-Pager:
-Глубокий анализ проблемы.
-Подходит для принятия стратегических решений.
-Позволяет учесть все аспекты предложения.
Пример использования:
Если вы предлагаете масштабное изменение в продукте или процессе, 6-Pager поможет детально обосновать ваше предложение.
Как выбрать между 1-Pager и 6-Pager?
Используйте 1-Pager, если:
-Нужно быстро донести идею.
-Решение простое и не требует глубокого анализа.
-Время на принятие решения ограничено.
Используйте 6-Pager, если:
-Проблема сложная и требует детального анализа.
-Решение имеет долгосрочные последствия.
-Нужно убедить ключевых стейкхолдеров.
Итог
1-Pager и 6-Pager — это мощные инструменты для документирования идей и решений. Чтобы использовать их эффективно, важно:
-Выбирать подходящий формат в зависимости от задачи.
-Сосредоточиться на главном и избегать лишних деталей.
-Подкреплять аргументы данными и фактами.
У вас уже внедрен 1 pager или 6-pager? Для чего вы его используете?
#1pager #6pager #полезное
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍3🔥2
🚀 Всем успешной доставки! А в вашем продукте есть платформенные команды? Если нет, то это фатальная ошибка 😁
Давайте попробую раскрыть зачем нужны такие команды.
Платформа — это набор инструментов, сервисов и решений, которые упрощают разработку и эксплуатацию продуктов. Это может быть:
-Техническая платформа: инфраструктура, API, библиотеки, фреймворки.
-Бизнес-платформа: экосистема, которая объединяет продукты, сервисы и пользователей.
Платформа позволяет продуктовым командам сосредоточиться на создании ценности для клиентов, а не на решении рутинных задач.
Зачем нужны платформенные команды?
Платформенные команды — это специализированные группы, которые разрабатывают и поддерживают платформу. Их основные задачи:
Создание инфраструктуры - разрабатывают инструменты и сервисы, которые используют другие команды. Например, CI/CD-пайплайны, системы мониторинга, шаблоны микросервисов.
Упрощение разработки - создают готовые решения, которые ускоряют разработку. Например, библиотеки компонентов, API для интеграции, шаблоны проектов.
Обеспечение стабильности - следят за тем, чтобы платформа работала стабильно и безопасно. Это включает мониторинг, устранение инцидентов и обновление инфраструктуры.
Преимущества платформ и платформенных команд
Ускорение разработки - готовые решения, которые позволяют командам быстрее создавать продукты.
Снижение затрат - централизуют разработку инструментов, что снижает дублирование усилий и экономит ресурсы.
Повышение качества - стандартизация процессов, что снижает количество ошибок и улучшает качество продукта.
Масштабируемость - легко масштабировать продукты и сервисы, добавляя новые функции и интеграции.
Итог
Платформы и платформенные команды — это мощный инструмент для ускорения разработки и повышения качества продуктов. Чтобы создать успешную платформу, важно:
-Определить цели и задачи.
-Разработать архитектуру, которая поддерживает текущие и будущие потребности.
-Сформировать сильную платформенную команду.
-Собирать и учитывать обратную связь от пользователей.
А как вы используете платформы в своей компании? Делитесь опытом в комментариях! 😊
P.S. Полезная книга Team Topologies
#платформа #платформенныекоманды
Давайте попробую раскрыть зачем нужны такие команды.
Платформа — это набор инструментов, сервисов и решений, которые упрощают разработку и эксплуатацию продуктов. Это может быть:
-Техническая платформа: инфраструктура, API, библиотеки, фреймворки.
-Бизнес-платформа: экосистема, которая объединяет продукты, сервисы и пользователей.
Платформа позволяет продуктовым командам сосредоточиться на создании ценности для клиентов, а не на решении рутинных задач.
Зачем нужны платформенные команды?
Платформенные команды — это специализированные группы, которые разрабатывают и поддерживают платформу. Их основные задачи:
Создание инфраструктуры - разрабатывают инструменты и сервисы, которые используют другие команды. Например, CI/CD-пайплайны, системы мониторинга, шаблоны микросервисов.
Упрощение разработки - создают готовые решения, которые ускоряют разработку. Например, библиотеки компонентов, API для интеграции, шаблоны проектов.
Обеспечение стабильности - следят за тем, чтобы платформа работала стабильно и безопасно. Это включает мониторинг, устранение инцидентов и обновление инфраструктуры.
Преимущества платформ и платформенных команд
Ускорение разработки - готовые решения, которые позволяют командам быстрее создавать продукты.
Снижение затрат - централизуют разработку инструментов, что снижает дублирование усилий и экономит ресурсы.
Повышение качества - стандартизация процессов, что снижает количество ошибок и улучшает качество продукта.
Масштабируемость - легко масштабировать продукты и сервисы, добавляя новые функции и интеграции.
Итог
Платформы и платформенные команды — это мощный инструмент для ускорения разработки и повышения качества продуктов. Чтобы создать успешную платформу, важно:
-Определить цели и задачи.
-Разработать архитектуру, которая поддерживает текущие и будущие потребности.
-Сформировать сильную платформенную команду.
-Собирать и учитывать обратную связь от пользователей.
А как вы используете платформы в своей компании? Делитесь опытом в комментариях! 😊
P.S. Полезная книга Team Topologies
#платформа #платформенныекоманды
❤4👍2
🚀 Как превратить ваш тасктрекер в помойку? 😳
Типичные ошибки:
1.100500 статусов в workflow
— «В работе», «Почти в работе», «Ждет Саши», «Проверить у Марьиванны», «На паузе»...
— Чем плохо? Команда тратит больше времени на перетаскивание карточек, чем на работу.
2.Задачи без DOR/DOD
— DOR (Definition of Ready): Когда задача готова к работе.
— DOD (Definition of Done): Когда задача считается завершенной.
— Чем плохо? Разработчики берут в работу сырые задачи, а тестировщики не понимают, что проверять.
3.«Забытые» карточки годами в бэклоге
— Задача «Обновить логотип», созданная в 2020-м, до сих пор висит в бэклоге.
— Чем плохо? Бэклог превращается в свалку, а приоритеты теряются.
Чеклист: как навести порядок в вашем тасктрекере
Шаг 1: Аудит
— Удалите дубликаты задач.
— Закройте всё, что неактуально (если страшно — переместите в архив).
Шаг 2: Упростите workflow
— Оставьте 3-5 ключевых статусов которые полностью отражают ваш процесс производства (например: To Do, In Progress, Review, Done).
— Удалите лишние переходы между статусами.
Шаг 3: Внедрите DOR/DOD
— Пример DOR: «Задача имеет ТЗ, оценку и приоритет».
— Пример DOD: «Код проверен, тесты пройдены, документация обновлена».
Шаг 4: Разберите бэклог
— Удалите задачи старше 6 месяцев (кажется если задачу не делают больше 6 месяцев, то она "протухла" и делать ее уже не будут).
Шаг 5: Настройте автоматизацию
— Уведомления для заблокированных задач (например: «Висит в Review > 3 дней», не меняла статуса n дней).
Шаг 6: Запланируйте регулярный аудит
— Раз в месяц(определите эту периодичность самостоятельно) удаляйте мусор и проверяйте актуальность DOR/DOD.
Что вы получите?
✔️ Команда тратит на 30% меньше времени на «администрирование» задач.
✔️ Задачи закрываются быстрее, потому что все понимают, что делать.
✔️ Бэклог больше не вызывает панических атак.🙂
А ваш тасктрекер уже идеален? Делитесь лайфхаками в комментариях! 💬
#jira #jiraгигиена #метрики #workflow
Типичные ошибки:
1.100500 статусов в workflow
— «В работе», «Почти в работе», «Ждет Саши», «Проверить у Марьиванны», «На паузе»...
— Чем плохо? Команда тратит больше времени на перетаскивание карточек, чем на работу.
2.Задачи без DOR/DOD
— DOR (Definition of Ready): Когда задача готова к работе.
— DOD (Definition of Done): Когда задача считается завершенной.
— Чем плохо? Разработчики берут в работу сырые задачи, а тестировщики не понимают, что проверять.
3.«Забытые» карточки годами в бэклоге
— Задача «Обновить логотип», созданная в 2020-м, до сих пор висит в бэклоге.
— Чем плохо? Бэклог превращается в свалку, а приоритеты теряются.
Чеклист: как навести порядок в вашем тасктрекере
Шаг 1: Аудит
— Удалите дубликаты задач.
— Закройте всё, что неактуально (если страшно — переместите в архив).
Шаг 2: Упростите workflow
— Оставьте 3-5 ключевых статусов которые полностью отражают ваш процесс производства (например: To Do, In Progress, Review, Done).
— Удалите лишние переходы между статусами.
Шаг 3: Внедрите DOR/DOD
— Пример DOR: «Задача имеет ТЗ, оценку и приоритет».
— Пример DOD: «Код проверен, тесты пройдены, документация обновлена».
Шаг 4: Разберите бэклог
— Удалите задачи старше 6 месяцев (кажется если задачу не делают больше 6 месяцев, то она "протухла" и делать ее уже не будут).
Шаг 5: Настройте автоматизацию
— Уведомления для заблокированных задач (например: «Висит в Review > 3 дней», не меняла статуса n дней).
Шаг 6: Запланируйте регулярный аудит
— Раз в месяц(определите эту периодичность самостоятельно) удаляйте мусор и проверяйте актуальность DOR/DOD.
Что вы получите?
✔️ Команда тратит на 30% меньше времени на «администрирование» задач.
✔️ Задачи закрываются быстрее, потому что все понимают, что делать.
✔️ Бэклог больше не вызывает панических атак.
А ваш тасктрекер уже идеален? Делитесь лайфхаками в комментариях! 💬
#jira #jiraгигиена #метрики #workflow
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥5👍1💯1
Минусы и ограничения Kanban 😂
Никогда не думал, что буду писать про минусы Kanban, но на конференции (когда я рассказывал про Kanban) мне задали такой вопрос. Давайте попробую ответить.
Отсутствие чёткого таймбокса
Нет спринтов (ужас) → сложно планировать релизы, если нужен фиксированный ритм.
Для команд, которые привыкли к "sprint-goal, sprint-done" — может быть непривычно и даже тревожно.
Кому больно: продуктовым менеджерам, которым нужен план на ближайшие 2 недели.
Сложно оценить производительность "в моменте"
Без накопленных данных метрики работают хуже.
Нужно время, чтобы набрать историю, увидеть закономерности, строить прогнозы.
Кому больно: тем, кто хочет сразу видеть impact от изменений.
Риски перегруза без WIP-лимитов
Без строгих WIP-ограничений команда может тащить слишком много задач одновременно.
Кажется, что "работа кипит", а по факту — всё стоит.
Типичная ловушка: "Ну давай ещё одну задачку в «In Progress»".
Низкая мотивация без целей
Нет цели спринта → меньше чувства завершённости.
Команда может чувствовать себя как белка в колесе, если нет точек празднования побед.
Как лечить: добавлять review-моменты, ретро.
Может стать “Task Zoo”
Если не поддерживать порядок, доска превращается в хаос:
100500 задач в “To Do”
старые задачи не закрываются
дубли, баги, техдолг — всё валится в одну кучу
Лекарство: регулярный груминг + правила “что мы сюда вообще кладём”.
Не для всех ролей прозрачен
Стейкхолдерам без контекста сложно понять: где прогресс? когда релиз?
Kanban хорош для команды, но требует превращать поток в репорты для внешних глаз.
Как спасаться: генерировать отчёты, выжимки, дашборды для бизнеса.
🧠 Бонус: Культурные проблемы
Команды, привыкшие к командно-контрольной модели, могут сопротивляться «самоорганизации».
Без культуры ответственности и доверия Kanban может развалиться в «ничего не понятно — и никто не отвечает».
Теперь вы знаете про минусы и можете их победить, значит Kanban у вас станет еще лучше🔥
Никогда не думал, что буду писать про минусы Kanban, но на конференции (когда я рассказывал про Kanban) мне задали такой вопрос. Давайте попробую ответить.
Отсутствие чёткого таймбокса
Нет спринтов (ужас) → сложно планировать релизы, если нужен фиксированный ритм.
Для команд, которые привыкли к "sprint-goal, sprint-done" — может быть непривычно и даже тревожно.
Кому больно: продуктовым менеджерам, которым нужен план на ближайшие 2 недели.
Сложно оценить производительность "в моменте"
Без накопленных данных метрики работают хуже.
Нужно время, чтобы набрать историю, увидеть закономерности, строить прогнозы.
Кому больно: тем, кто хочет сразу видеть impact от изменений.
Риски перегруза без WIP-лимитов
Без строгих WIP-ограничений команда может тащить слишком много задач одновременно.
Кажется, что "работа кипит", а по факту — всё стоит.
Типичная ловушка: "Ну давай ещё одну задачку в «In Progress»".
Низкая мотивация без целей
Нет цели спринта → меньше чувства завершённости.
Команда может чувствовать себя как белка в колесе, если нет точек празднования побед.
Как лечить: добавлять review-моменты, ретро.
Может стать “Task Zoo”
Если не поддерживать порядок, доска превращается в хаос:
100500 задач в “To Do”
старые задачи не закрываются
дубли, баги, техдолг — всё валится в одну кучу
Лекарство: регулярный груминг + правила “что мы сюда вообще кладём”.
Не для всех ролей прозрачен
Стейкхолдерам без контекста сложно понять: где прогресс? когда релиз?
Kanban хорош для команды, но требует превращать поток в репорты для внешних глаз.
Как спасаться: генерировать отчёты, выжимки, дашборды для бизнеса.
🧠 Бонус: Культурные проблемы
Команды, привыкшие к командно-контрольной модели, могут сопротивляться «самоорганизации».
Без культуры ответственности и доверия Kanban может развалиться в «ничего не понятно — и никто не отвечает».
Теперь вы знаете про минусы и можете их победить, значит Kanban у вас станет еще лучше
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥3👍1👎1
🔥 Друзья, нужна ваша помощь!
Скоро в Перми снова пройдёт конференция Ural Digital Weekend — и я собираюсь подать заявку на доклад. Но вот дилемма: не могу определиться с темой 😬
Очень хочется выбрать живую и полезную тему, которая откликнется не только мне, но и вам - моим подписчикам.
Напишите в комментариях, о чём вы бы с интересом послушали, если бы пришли на конференцию. Что из тем по end-to-end процессу, изменениям, Канбану, метрикам — вам реально актуально?
Спасибо всем, кто откликнется 🙌
Скоро в Перми снова пройдёт конференция Ural Digital Weekend — и я собираюсь подать заявку на доклад. Но вот дилемма: не могу определиться с темой 😬
Очень хочется выбрать живую и полезную тему, которая откликнется не только мне, но и вам - моим подписчикам.
Напишите в комментариях, о чём вы бы с интересом послушали, если бы пришли на конференцию. Что из тем по end-to-end процессу, изменениям, Канбану, метрикам — вам реально актуально?
Спасибо всем, кто откликнется 🙌
❤3🔥2
Я Delivery Manager🚀
🚀 Всем успешной доставки! В апреле, а точнее 25 апреля я буду в Екатеринбурге выступать на конференции DUMP Буду рассказывать про практики и метрики (про что мне еще рассказывать😁), которые помогают команда улучшать свои процессы, причем практики и метрики…
Всем привет, уже в эту пятницу буду на конференции DUMP, приходите обязательно!
❤4👍3
Всем привет! Сегодня выступал на конференции DUMP в Екатеринбурге, очень крутая конференция.
Проходит 14 год, собирает 2000+ участников, мне показалось у меня на докладе было 100+ человек, всем советую🚀
Презентацию с выступления приложил.
Проходит 14 год, собирает 2000+ участников, мне показалось у меня на докладе было 100+ человек, всем советую🚀
Презентацию с выступления приложил.
dump-ekb.ru
DUMP 2026 — самая крупная ИТ-конференция на Урале
Конференция DUMP для разработчиков, менеджеров разработки, дизайнеров и тестировщиков.
❤2
🎯 Output != Outcome: не путай важное с второстепенным
В разговорах про эффективность часто звучат два похожих термина - output и outcome. Пора разобраться, в чём разница и зачем они нужны.
🔹 Output - это то, что мы делаем:
-Оформленные WiKi-страницы
-Проведён аудит процессов
-Настроенные каналы коммуникации
-Запущенный пилот в Jira
Это всё про действия и результаты работы команды. Можно пощупать, посчитать, зафиксировать в отчёте.
🔸 Outcome - это то, что изменилось благодаря output:
-Уменьшилась доля кривых запросов с 40% до 15%
-Бизнес стал чаще давать положительный CSAT
-Ускорилось согласование типовых документов
-Юристы теперь отвечают в течение 2 дней, а не недели
Это уже про ценность для бизнеса и пользователей. Outcome показывает, зачем всё это вообще затевалось.
📌 Почему это важно?
Когда фокус только на output — ты создаёшь активность, но не факт, что она кому-то нужна.
Когда фокус на outcome — ты решаешь реальные проблемы, и команда работает с ощущением смысла.
🔧 Как применить:
— Определи, какой outcome ты хочешь достичь
— Спланируй конкретные output’ы, которые к нему ведут
— Отслеживай прогресс и меняй курс, если результат не тот
#delivery #outcome #output #ценность #эффективность #канбан #tgканал
В разговорах про эффективность часто звучат два похожих термина - output и outcome. Пора разобраться, в чём разница и зачем они нужны.
🔹 Output - это то, что мы делаем:
-Оформленные WiKi-страницы
-Проведён аудит процессов
-Настроенные каналы коммуникации
-Запущенный пилот в Jira
Это всё про действия и результаты работы команды. Можно пощупать, посчитать, зафиксировать в отчёте.
🔸 Outcome - это то, что изменилось благодаря output:
-Уменьшилась доля кривых запросов с 40% до 15%
-Бизнес стал чаще давать положительный CSAT
-Ускорилось согласование типовых документов
-Юристы теперь отвечают в течение 2 дней, а не недели
Это уже про ценность для бизнеса и пользователей. Outcome показывает, зачем всё это вообще затевалось.
📌 Почему это важно?
Когда фокус только на output — ты создаёшь активность, но не факт, что она кому-то нужна.
Когда фокус на outcome — ты решаешь реальные проблемы, и команда работает с ощущением смысла.
🔧 Как применить:
— Определи, какой outcome ты хочешь достичь
— Спланируй конкретные output’ы, которые к нему ведут
— Отслеживай прогресс и меняй курс, если результат не тот
#delivery #outcome #output #ценность #эффективность #канбан #tgканал
❤7👍5
Я Delivery Manager🚀
Всем привет! Сегодня выступал на конференции DUMP в Екатеринбурге, очень крутая конференция. Проходит 14 год, собирает 2000+ участников, мне показалось у меня на докладе было 100+ человек, всем советую🚀 Презентацию с выступления приложил.
Всем привет, пришли фоточки с конференции DUMP.
Мой доклад занял 2-е место в секции Team - огромное спасибо всем, кто слушал, задавал вопросы и подходил после!
-Полезно
-Было интересно послушать про определение уровня своей команды. Про продажу внедрения метрик команде
-Легкий к пониманию доклад, живая подача
-Отличный доклад
-Четко по делу, есть инфа и для новичков и для опытных, круть
-Чётко, структурировано
-Многие моменты стали понятнее
-База. Известно, применяется
-Полезно, было бы здорово сослаться на источники, что почитать
-Интересные практики, уже в очереди на внедрение. Огромное спасибо за выступление
-Доклад отличный, тема интересная и актуальна
-Классный практический доклад с конкретными инструментами. Исписал три страницы тезисов
-Все супер, понятно, полезно. Можно чуть медленнее переключать слайды
-Очень конструктивно! Отличный спикер
-Отличный доклад
-Просто мастхэв дял тимлидов. Лучший доклад
Спасибо DUMP и всем, кто был в зале. Было мощно! 💪
Если вы еще не скачали презентацию, то она тут
Мой доклад занял 2-е место в секции Team - огромное спасибо всем, кто слушал, задавал вопросы и подходил после!
-Полезно
-Было интересно послушать про определение уровня своей команды. Про продажу внедрения метрик команде
-Легкий к пониманию доклад, живая подача
-Отличный доклад
-Четко по делу, есть инфа и для новичков и для опытных, круть
-Чётко, структурировано
-Многие моменты стали понятнее
-База. Известно, применяется
-Полезно, было бы здорово сослаться на источники, что почитать
-Интересные практики, уже в очереди на внедрение. Огромное спасибо за выступление
-Доклад отличный, тема интересная и актуальна
-Классный практический доклад с конкретными инструментами. Исписал три страницы тезисов
-Все супер, понятно, полезно. Можно чуть медленнее переключать слайды
-Очень конструктивно! Отличный спикер
-Отличный доклад
-Просто мастхэв дял тимлидов. Лучший доклад
Спасибо DUMP и всем, кто был в зале. Было мощно! 💪
Если вы еще не скачали презентацию, то она тут
🔥13❤4👍1
🚀 Всем успешной доставки!
CI/CD - это практика, которая помогает IT-командам быстро и безопасно доставлять продукт пользователям. Даже если вы не сталкивались с этими терминами, сейчас разберёмся.
Что такое CI/CD?
CI (Continuous Integration / Непрерывная интеграция):
Разработчики регулярно заливают код в общий репозиторий, и система автоматически проверяет его на ошибки с помощью тестов.
CD (Continuous Delivery / Непрерывная доставка):
Если тесты прошли успешно, код автоматически выкатывается в тестовую или рабочую среду. Без ручной волокиты и сбоев.
Зачем всё это?
💡 Главная цель - быстро и безопасно доставлять ценность клиенту.
На практике это значит:
✅ Новые функции попадают к пользователям быстрее
✅ Ошибки ловятся на раннем этапе
✅ Меньше релизного стресса - больше предсказуемости
✅ Команда сосредоточена на создании полезного, а не на выкладках
Когда CI/CD нужно?
CI/CD особенно полезен, если:
-У вас частые релизы или вы стремитесь к ним
-Команда большая или распределённая
-Нужно быстро откатываться при ошибках
-Вы хотите тестировать гипотезы и получать обратную связь как можно раньше
Когда можно не спешить?
-Если проект на стадии MVP или пилота с редкими изменениями
-Нет ресурсов на автоматизацию (и команда маленькая)
-Вы работаете над "одноразовым" решением, которое не предполагает регулярные релизы
💡 Даже в этих случаях CI (интеграция и автотесты) всё равно будет полезна - для минимизации ручных ошибок.
А кто всё это настраивает?
Важно выделить отдельную команду или хотя бы специалистов, которые займутся этим направлением:
🛠 Настроят пайплайны
🔍 Подключат автотесты и мониторинг
🔁 Поддержат процесс улучшения доставки
Это не "по остаточному принципу". Хорошая автоматизация — фундамент стабильных релизов и довольных пользователей.
CI/CD — не просто техника, а стратегия быстрой, безопасной и ценной доставки.
CI/CD - это практика, которая помогает IT-командам быстро и безопасно доставлять продукт пользователям. Даже если вы не сталкивались с этими терминами, сейчас разберёмся.
Что такое CI/CD?
CI (Continuous Integration / Непрерывная интеграция):
Разработчики регулярно заливают код в общий репозиторий, и система автоматически проверяет его на ошибки с помощью тестов.
CD (Continuous Delivery / Непрерывная доставка):
Если тесты прошли успешно, код автоматически выкатывается в тестовую или рабочую среду. Без ручной волокиты и сбоев.
Зачем всё это?
💡 Главная цель - быстро и безопасно доставлять ценность клиенту.
На практике это значит:
✅ Новые функции попадают к пользователям быстрее
✅ Ошибки ловятся на раннем этапе
✅ Меньше релизного стресса - больше предсказуемости
✅ Команда сосредоточена на создании полезного, а не на выкладках
Когда CI/CD нужно?
CI/CD особенно полезен, если:
-У вас частые релизы или вы стремитесь к ним
-Команда большая или распределённая
-Нужно быстро откатываться при ошибках
-Вы хотите тестировать гипотезы и получать обратную связь как можно раньше
Когда можно не спешить?
-Если проект на стадии MVP или пилота с редкими изменениями
-Нет ресурсов на автоматизацию (и команда маленькая)
-Вы работаете над "одноразовым" решением, которое не предполагает регулярные релизы
💡 Даже в этих случаях CI (интеграция и автотесты) всё равно будет полезна - для минимизации ручных ошибок.
А кто всё это настраивает?
Важно выделить отдельную команду или хотя бы специалистов, которые займутся этим направлением:
🛠 Настроят пайплайны
🔍 Подключат автотесты и мониторинг
🔁 Поддержат процесс улучшения доставки
Это не "по остаточному принципу". Хорошая автоматизация — фундамент стабильных релизов и довольных пользователей.
CI/CD — не просто техника, а стратегия быстрой, безопасной и ценной доставки.
❤5🔥3