ScrumTrek

«По отдельности они сделают в два раза больше» — так обычно характеризуют тему парного программирования. Аргумент железобетонный, если считать часы, а не прирост продукта. Цифры Cockburn и Williams говорят другое: часов уходит на 15% больше, а не вдвое, дефектов на 15% меньше, кода на 20% меньше. А читаем мы код раз в десять дольше, чем пишем. Сергей Баранов обновил статью про парное программирование, добавил раздел про AI. Что внутри: 🧡пять стилей: штурман/водитель, строгий пейринг, пинг-понг под TDD, смешанный, mob; 🧡почему это навык, а не рассадка двух людей рядом, и три антипаттерна, которые убивают сессию; 🧡пара джун-сеньор: как не дать сеньору стать Keyboard Dominator; 🧡что делать, когда знаний не хватает одному партнёру, и что — когда обоим (иногда задача не решается вообще); 🧡AI в паре. Не «разработчик + AI», а «два разработчика + AI»: машина снимает механику и ровно поэтому поднимает цену ошибки штурмана. 17 минут чтения, в конце шесть шагов для старта. 🔗 Изучить полезное чтиво

Семь раз отмерь. Один раз назови срок заказчику 📐 Разумеется, нет и не может быть таких специалистов, которые идеально предсказывают сроки в 100% случаев. Однако научиться базировать сроки на точных данных, управлять ими и называть наиболее точный дедлайн, не так сложно, как это малюют. Спойлер: всё, чтобы в следующий раз назвать самый приближенный к реальности срок — у вас уже есть, и нет, это не просто экспертность и прошлый опыт (хотя и они тоже). Завтра, 22 сентября, в 19:00 (МСК) Александр Рыжков на вебинаре «Как прогнозировать сроки без гаданий?» расскажет, как при формировании сроков оперировать этими понятиями: 🧡lead time 🧡throughput 🧡перцентили 🧡SLE За такую оценку и ответственность нести не стыдно и аргументировать всегда будет чем. Для продактов, скрам-мастеров, руководителей и всех, кому приходится называть сроки. 🔗 Зарегистрироваться на бесплатный вебинар

Как проходит фестиваль 🎉 Собрали самые красивые моменты этого дня, чтобы вы почувствовали атмосферу через экран, если сегодня не тут, или с теплыми воспоминаниями пересматривали, если всё же смогли побывать AgileDays FEST 🧡

❣️У хорошей конференции всегда есть соучастники❣️ До AgileDays ФЕСТ 2026 — уже совсем немного. И пока мы собираем последние детали, хочется поблагодарить тех, кто помогает создавать атмосферу завтрашнего дня. Ингосстрах, Единый ЦУПИС и Т1-Сфера — партнёры AgileDays ФЕСТ 2026, благодаря которым у участников будет ещё больше поводов задержаться между докладами, познакомиться, пообщаться и увезти с собой что-то на память. Для участников они подготовили памятные подарки, а Ингосстрах ещё и встретит гостей на собственном стенде — с активностями и дополнительными подарками. За игристое настроение в этом году отвечают наши партнёры Bruni. Их prosecco родом из Венето и Пьемонта, а на фестивале станет частью фуршета и вечерней атмосферы. В итоге получается конференция, в которой есть место всему: рабочим идеям, случайным знакомствам, живым разговорам, маленьким открытиям и бокалу игристого в подходящий момент. Спасибо партнёрам, которые помогают нам собирать этот день вместе. ✨Уже завтра увидимся на AgileDays ФЕСТ 2026!

Вебинар про подготовку встречи уже сегодня❗️ У фасилитации всегда есть невидимая сторона — работа с запросом. Сегодня в 18:30 на бесплатном эфире Дарья Охохонина разберёт и структурирует практические аспекты этой работы. Что унесёте с эфира: 🧡вопросы, которые задают заказчику, чтобы понять точно понять его запрос; 🧡как честно взвесить свои силы и свою роль в предстоящей встрече; 🧡по каким признакам видно, что формат стоит поменять или сессию вообще не проводить. Полезно тем, кто только осваивает фасилитацию, ведёт встречи как руководитель команды или проекта, собирает стейкхолдеров как продакт или фасилитирует внутренние сессии в роли HR. Длительность: 45 минут Платформа: Zoom 🔗Записаться на бесплатный вебинар

Лимит — это для вас какая-то шутка? 🧮 Представьте, договорились вы с командой: больше десяти задач в работе не держим. Через месяц смотрите на доску, а их там уже пятнадцать + новые добавляются в геометрической прогрессии, лимит становится для всех какой-то шуткой, а о том, что все задачи зарелизятся в срок можно и не мечтать. Обычно когда это всплывает варианты ответов совершенно стандартные. Кто-то оправдывается тем, что сейчас пожар, потом разгребём, кто-то обещает, что со следующего спринта так точно не будет, кто-то просит всё-таки соблюдать договорённость, не зря же обсуждали. И всех можно понять. Потому что WIP-лимит — это лакмусовая бумажка. Он показывает те места, где выстроенный процесс даёт слабину. Разберите любое нарушение и очень часто человек окажется ни при чём. Например, команда взяла одиннадцатую задачу, потому что делать было нечего, какие-то из задач ждут ревью и мяч не на вашей стороне. Формально в работе десять, фактически меньше и когда заказчик спрашивает про сроки, вы считаете по десяти, но это не репрезентативно. Ну или заказчик продавил задачу вне очереди, потому что утверждает, что это архи-срочно и архи-важно. Встречи, где решают, что берём следующим, нет. Правил, что считать срочным, тоже. Остаётся один способ добиться результата — аргументировать и продавливать. И раз получилось один раз, в следующий будет то же самое. Либо ещё одна классика жанра: тимлид видит, что тестировщик (либо любой другой член команды) сидит без задач и даёт ему что-то вне очереди, допустим, из тех долга. А задач у тестировщика хватало: очередь копилась в разработке (либо в любом другом отделе), туда приходит больше, чем выходит. Новая задача доехала до этой очереди и сделала её длиннее. Ни один случай не лечится ни дисциплиной, ни умением отстаивать границы. В первом надо разбираться с блокировками, во втором договариваться о том, какие типы срочных запросов бывают и как с каждым обращаться, в третьем искать узкое место вместо того, чтобы занимать свободные руки. Поэтому нарушенный лимит — это, можно сказать, хорошая новость! Он помог вам понять, в каком именно месте процесс даёт сбой. Хуже, когда лимита нет вовсе или когда лимиты нарушаются систематически. Правда, кривой процесс видно, а цену такой ошибки — нет. Понимание приходит позже, вместе с сорванными сроками и потерянными деньгами. 6–7 октября Александр Рыжков проводит двухдневный онлайн-тренинг «Основы Канбан-систем (KSD)» — как раз про то, как читать эти сигналы и чинить процесс. Ставить WIP-лимиты и опираться на статистику Throughput, находить задержки в потоке, называть срок с вероятностью 80–90%. 👉 Записаться на тренинг

Нам как менеджерам проще 👇 работать с ИИ-агентами, чем исполнителям, даже технарям. (это #дайджест постов Кактуса в новом формате) Если помните, я писал про эксперимент Итана Моллика: студенты MBA без навыков программирования за 4 дня сделали с ИИ больше, чем прежние потоки за семестр. Им помогли как раз навыки управления. Вот что руководители делают с агентами "на автомате": 1️⃣Ставят задачу как живому сотруднику. Дают контекст и чек-лист, по которому агент проверит себя сам, а главное — озадачивают ИИ именно тем, что хорошо делегируется. Когда отдавать задачу ИИ выгодно. 2️⃣ Не микроменеджат. Указывают главное, что не так с результатом, и просят самого агента обновлять свои инструкции. Как перестать микроменеджить ИИ. 3️⃣Легко выбрасывают плохие результаты ИИ, и уж тем более не правят их сами. Когда умение говорить «нет» агенту становится активом человека и компании. 4️⃣Выстраивают прозрачный адаптивный процесс с human in the loop. В котором агент сам предлагает решения и улучшения, но согласовывает их с человеком. «Скрам» для ИИ-агента. ➿➿➿ Правда, чисто менеджерского подхода к работе с ИИ бывает мало, так что люди-"исполнители" тут тоже нужны. Я (Алексей Евдокимов) скоро напишу об этом. А пока накидывайте плиз в комментарии: в чем видите практические отличия между управлением агентами и людьми?

Ненужную встречу можно распознать на десятой минуте, а испортили её накануне Заказчик пришел с запросом на сессию по стратегии, фасилитатор взял в работу и начал придумывать упражнения. Непосредственно на встрече выясняется, что заказчику надо было просто сообщить уже принятое решение, половина участников пришла без контекста, а решение, которое они собирались принять совместно не пойдет в работу дальше. Упражнениями здесь не помочь. Здесь только исследовать и выяснять конкретный запрос за неделю до. 16 сентября в 18:30 проводим открытый эфир про подготовку к фасилитации сессий. Сорок минут плюс вопросы. Тема: Подготовка встречи: какие вопросы перед встречей стоит задать себе и заказчику Разберём как устроен этап подготовки: ❣️ какие вопросы задать заказчику; ❣️ какие вопросы задать себе, чтобы честно оценить свои силы, роль, и на что смотреть, чтобы распознать ситуации; ❣️ где фасилитатору лучше отказаться от выбранного формата или проведения сессии вообще. Ведёт Дарья Охохонина: Agile-коуч, бизнес-тренер, фасилитатор в гештальт-подходе. Зарегистрируйтесь и мы пришлём вам инструмент для самостоятельной проверки необходимости встречи. 📣 Регистрация на эфир 16 сентября

Большие трансформации похожи на восхождение. Кто-то только начинает подниматься, кто-то уже близко к вершине, кто-то идёт обратно — потому что взял от маршрута всё, что мог, и теперь ищет следующую точку роста, а кто-то остановился где-то посередине. Что, если вы свернули слишком рано? 🗺 В этом году мы посмотрели на AgileDays ФЕСТ через метафору горы и базового лагеря.

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

В реальном бизнесе всё сложнее. Agile для разных компаний сегодня выглядит совершенно по-разному: кто-то только внедряет его и пока не видит результата, а кто-то уже движется дальше — к адаптивности, клиентократии и новым моделям управления. И здесь возникает важный вопрос: если мы не дошли до результата с Agile — не повторим ли тот же маршрут с ИИ? 🗺️ Можно годами идти в правильном направлении — и так и не дойти до вершины. Поэтому базовый лагерь — место не для соревнования, а для обмена важными деталями, стратегиями и маршрутами. На конференции AgileDays ФЕСТ 2026 будет возможность остановиться, оглянуться на пройденный путь и понять: куда идти дальше? И главное — до какой вершины вы на самом деле хотите дойти. 17 сентября, Москва, Goelro Space.

Как прогнозировать сроки без гаданий? Вы наверняка замечали, что прогноз погоды не утверждает, что будет дождь, а говорит, что вероятность осадков 70%. Американская метеослужба перешла на такие прогнозы в 1965-м, а до этого публиковала всего одно слово: дождь или ясно. При определении сроков многие до сих пор руководствуются методами из 1964-ого, отвечая только "дождь" или "ясно". Магне Йоргенсен свёл опросы практик оценки в разных компаниях и получил следующее: от 62 до 86% сроков называют экспертным суждением, то есть, холодный расчёт остаётся в меньшинстве, уступая наитию, прошлому опыту, либо конкретному дедлайну. Есть ещё более-менее наукообразный способ —по среднему, но он очень коварный. Скажем, за квартал команда закрыла сто задач: 60 за 5 дней, 25 за 12, 10 за 25 и 5 за 45 дней, соответственно. Средний срок выполнения задачи — 11 дней, только в эти 11 дней не уложились сорок задач из ста, а половина закрылись за пять. Среднее сильно увеличили те пятнадцать штук, что шли дольше всех и быть валидным оно перестало. Ещё добавим к этому буфер (запас, который накидывают к оценке), чтобы перестраховаться, умножим 11 на два и обозначим заказчику срок в 22 дня, ведь в 22 дня действительно укладываются 85 задач из ста. Но если мы посмотрим на исходные данные ещё раз, то поймём, что 85 задач итак закрываются за 12 дней. То есть, ровно ту же надёжность мы могли пообещать вдвое меньшим сроком. На самом деле, для более точного определения сроков считать почти ничего не надо. Всего лишь отсортировать задачи от быстрых к медленным и посмотреть три из них. 50-я идёт 5 дней, так выглядит обычная задача, 85-я идёт 12 дней: в этот срок мы попадаем в 85 случаях из ста. 95-я — 25 дней, это почти гарантия. При таком раскладе можно назвать заказчику два числа: срок и вероятность. За 12 дней закрываем в 85 случаях из ста, но если нужно надёжнее, тогда срок 25 дней. Он выбирает сам, так же как вы сами решаете, брать ли зонт при вероятности 50% дождя. Выбранная пара чисел называется SLE (Service Level Expectation). Дальше команда замеряет сроки по ней: сколько задач за месяц уложилось в обещанные 12 дней. Если заметно меньше 85, то в процессе что-то изменилось и обещание пора пересматривать. 🗓 22 сентября в 19:00 Александр Рыжков, тренер Scrum и Kanban в ScrumTrek, покажет на бесплатном вебинаре, как собрать такой прогноз, оперируя данными: lead time, throughput, перцентили и SLE. Зарегистрироваться на бесплатный вебинар «Как прогнозировать сроки без гаданий»

История одного маленького сообщества, которое смогло!   В середине 2010-х российский ИТ-рынок переживал бум гибких методологий. Компании массово внедряли Agile, команды бежали быстро, фичи поставлялись ежедневно. Однако возник побочный эффект: за скоростью процессов не всегда поспевала техническая база. Системы становились сложнее, монолиты начали рассыпаться на сотни микросервисов, а цена архитектурной ошибки выросла до миллионов.   На рынке существовало множество конференций для разработчиков (про конкретные языки) и для менеджеров (про процессы), но архитекторы — люди, которые стоят на стыке бизнеса и технологий — чувствовали себя «бездомными». Им не хватало площадки для обсуждения высокоуровневого проектирования.   Так появилась первая ArchDays - классический пример того, как профессиональное сообщество перерастает рамки «просто обсуждений» и создает свою собственную конференцию.   В последние годы ArchDays окончательно закрепила за собой статус главной архитектурной площадки страны (да, мы не самые скромные люди). Повестка стала еще глубже: 1. От микросервисов к здравому смыслу: Стали чаще обсуждать, когда микросервисы не нужны и как правильно нарезать границы контекстов. 2. DevSecOps и Platform Engineering: Архитектура стала рассматриваться не как «рисунок на бумаге», а как живая среда и инфраструктура. 3. Импортозамещение и суверенитет: После 2022 года конференция стала важнейшим местом обмена опытом по миграции с западных облачных решений и СУБД на альтернативные стеки.   27 ноября 2026 года мы встретимся вновь. Первые спикеры уже на сайте.   ПРОДОЛЖЕНИЕ СЛЕДУЕТ….

Грань между развитием и результатом: три дилеммы эффективного управления ✅ Что делать руководителю, когда команда и организация требуют времени на развитие, а бизнес — результата уже сейчас? Иногда правильное управленческое решение совсем не похоже на то, чему нас учили. Развивать сотрудника или расставаться? Делегировать или вмешаться в процесс? Быть максимально прозрачным или сохранить информацию при себе? ⭐️На AgileDays ФЕСТ 2026 Алексей Павлихин, исполнительный директор финтеха Webbankir, разберёт три реальные управленческие дилеммы и покажет, почему универсальных «правильных» решений в работе руководителя не существует.

За 10 лет Алексей прошёл путь от Product Owner и Agile Coach до уровня заместителя CEO. Сегодня он отвечает за P&L и производственную эффективность компании численностью более 500 человек.

В докладе — практические кейсы и разговор о том, где начинается ответственность руководителя за бизнес-результат. А в финале — практическая модель, которая поможет понять, когда стоит инвестировать в развитие, а когда — занимать жёсткую позицию и принимать непопулярные решения. Потому что иногда лучший способ помочь бизнесу двигаться вперёд — вовсе не выбрать самый «правильный» управленческий подход. AgileDays ФЕСТ 2026 ⏺ 17 сентября.

Друзья, мы тут только разогнались с анонсами спикеров, а очных билетов осталось всего 35-30 максимум!😱 Поэтому, если ваше участие на согласовании где-то внутри, вы нам хоть маякните, поставим бронь. Писать @AKhamitskii

Запись вебинара Сергея Баранова «Определение объектов и границ объектов NFR» уже доступна: Youtube: https://www.youtube.com/watch?v=7sLMNBNCMi8 VK: https://vkvideo.ru/video-184472537_456239215 Презентацию можно скачать в канале Сергея. Приятного и полезного просмотра!

Как 10 одинаковых задач за 10 месяцев могут принести вам разное количество денег? 🤔 Делится Александр Рыжков, тренер Scrum и Kanban в ScrumTrek: Лично я называю Kanban методом “здравого смысла”. Многие практики метода кажутся довольно очевидными при знакомстве с ними, но почему-то многие до сих пор не используют эти очевидные практики. Естественно, при слове Kanban многие сразу же начинают вспоминать про WIP лимиты. Если кто вдруг не знает, то это ограничение незавершенной работы. “У тестировщиков одновременно в работе может быть не более 5 задач” – значит WIP лимит на этапе тестирования у нас 5. Это если совсем упростить. Возьмем простой пример – у нас есть 10 задач, каждая задача выполняется 1 месяц. Давайте представим идеальный мир без задержек, смещения сроков, неточных оценок и прочего. Значит эти 10 задач у нас будут делаться 10 месяцев. Имеет ли разницу, будем мы делать эти задачи последовательно или параллельно? Можем даже исключить фактор переключений между задачами, на который тратится немного времени. Если мы будем делать первую задачу, потом вторую, потом третью и т.д. до десятой, то мы справимся за 10 месяцев. В данном случае у нас WIP лимит 1. А если мы будем делать задачи равномерно? Скажем, поработали немного над первой, потом немного над второй и т.д. Мы тоже справимся за 10 месяцев! Тут WIP лимита у нас нет. Получается, что в любом случае через 10 месяцев мы получим сделанные 10 задач. Тогда зачем нам WIP лимит? Какая разница, сколько у нас в параллель работы, если за какой-то отрезок времени мы все эти задачи сделаем? Дело в том, что когда мы говорим слово “Задача”, мы подразумеваем некие изменения в функционале, которые будут приносить нам “пользу”. Слово “польза” написано в кавычках, потому что все мы понимаем о какой пользе для бизнеса идет речь – это деньги. Соответственно, если задача выполнена и приносит (или экономит) деньги, то разница между последовательно и параллельно у нас колоссальная. Я думаю, что вам уже стало очевидно, что я имею ввиду (а может было всегда очевидно), но позвольте прописать это в явном виде: в первом случае задача начинает нам приносить деньги уже со 2 месяца и приносит последующие 8. Скажем, если она приносит 1 миллион рублей, то по окончанию 10-ого месяца мы уже получим 9 миллионов с нее. Если задача номер 2 приносит также 1 миллион, то мы получим после 10-ого месяца с нее 8 миллионов. И так далее по остальным задачам. А если же мы все задачи доделаем одновременно в 10-ый месяц, то после него мы будем иметь 0 рублей и того с 11-ого увидим первые деньги, тем самым упустим огромную выгоду. Понятно, что реальный мир устроен немного очень сильно сложнее и вы вряд ли встретите 10 задач, которые делаются за один и тот же срок, да еще и приносят одну и ту же сумму. В реальном мире многие часто ошибаются в точных сроках, а денежный выхлоп от задачи не оценивают даже примерно. Но в любом случае упрощенный пример выше показывает, что ограничение незавершенной работы помогает нам закрывать задачи с большим экономическим выхлопом. Сюда нужно добавить еще правильную приоритизацию задач, сильного продакта и все такое. Но это уже совсем другая история.

Насколько часто вы планируете квартал и начинаете говорить о каких-то прокси-метриках. Ваша команда вас понимает, но любое взаимодействие со стейкхолдерами других команд или руководством выше не приводит к продуктивным результатам. Вы погрязли в собственных метриках, что абсолютно нормально для любого продакт-менеджера, но теряете фокус на целях всей компании. Чем это обычно заканчивается? Как правило сценария 2, либо вы уходите в квартал разработки, положившись не на цифры и экономику, а на потенциальное ощущение, что должно стать лучше; либо приоритеты вашей команды отправлены на задворки, ресурс вам не дали и вы в 1.5 землекопа пытаетесь сделать что-то полезное. И это произошло не потому, что вы плохой менеджер и не разбираетесь в продукте, а потому, что в какой-то момент нужно научиться смотреть на уровень выше. Вам важно научиться говорить с C-левелом и смежными стейкхолдерами на языке целей и метрик компании и обсчитывать все свои идеи и ресурсы, полагаясь на них. На «Менеджере продукта 2.0» три дня фактически направлены на устранение этого разрыва. После тренинга вы: ❣️научитесь строить гибкий roadmap, согласованный с бизнес-целями и сможете обосновывать приоритеты на языке метрик и экономики; ❣️освоите расчёт unit-экономики и P&L продукта, чтобы связывать продуктовые решения с финансовыми результатами; ❣️сформируете видение и стратегию продукта с учётом рисков и возможностей AI-эпохи; ❣️встроите AI в исследования рынка, конкурентный анализ и подготовку данных, чтобы discovery шёл быстрее. Из этого складывается аргументация на уровне бизнеса – какую ценность для компании продукт принесет за квартал и сколько это будет стоить, – что позволит вам сохранить нервные клетки при обосновании этих тезисов коллегам. Цена до завтра включительно: 69 000 ₽, с 09.09 уже 74 000 ₽. Считайте это вложением в навык, благодаря которому вы сэкономите и принесете своему бизнесу гораздо больше. ☝ Стать Серцифицированным Product Manager-ом 2.0

Операционная модель ИИ-трансформации 💻

Главная проблема внедрения ИИ — это не технологические ограничения, а высокая степень неопределенности и стоимость дорогих экспериментов.

Чем активнее бизнес внедряет новые технологии, тем важнее становится другой вопрос: как не потратить бюджет на эксперименты, которые так и не дадут результата? Особенно когда успешных отраслевых кейсов немного, а цена ошибки высока. На AgileDays ФЕСТ 2026 Евгений Денисов, начальник отдела цифрового развития «Ингосстрах», расскажет, как выстроить ИИ-трансформацию так, чтобы управлять не только технологиями, но и неопределённостью вокруг них. В докладе поговорим о том: ⏺как оценивать риски инвестиций в ИИ; ⏺что делать, если проверенных кейсов почти нет; ⏺как формировать программу ИИ-проектов; ⏺и как работает операционная модель ИИ-трансформации на практике. Потому что ИИ-трансформация — это не про то, чтобы запустить как можно больше экспериментов. Это про то, чтобы понимать, какие из них действительно стоит запускать. Увидимся на AgileDays ФЕСТ 2026, 17 сентября.

Практически любое обучение способно вложить в вашу голову новые знания, но вот привычки команды и отдельных коллег в частности, так быстро не перекроить и не подогнать под определенные стандарты 📚 Когда мы говорим про внедрение Scrum-методологии, лучше всего выстраивать процесс итеративно и рассматривать каждый пример в индивидуальном порядке, поэтому мы в Школе Scrum Master стараемся, чтобы учебным материалом была ваша собственная команда, то есть, раз в неделю вы уносите с занятия инструмент, до следующей среды пробуете его на своей команде, а потом приносите наставнику то, что получилось и разбираете вместе. Программа строится следующим образом: запуск и самодизайн, роли скрам-мастера и проведение событий, техники работы с бэклогом, планирование и метрики, групповая динамика, а на финише обзор спринта и ретроспектива. Теория занимает не больше 30% времени, остальные 70% - это игры, симуляции и разбор полетов. По окончанию обучения вы получаете двойной сертификат ScrumTrek + OKademy: он подтверждает прохождение углублённой программы с практикой на реальных проектах и знания, которые вы защищаете на выпускном экзамене. Плюс освоенные инструменты: StarMap, канвас команды, покер делегирования и другие. 🗓️ Старт уже 8 октября. 💰Стоимость: 86 000 ₽ (до 17 сентября) Записаться в Школу Scrum Master

NFR – это требование к чему именно? Наверняка у всех вас в том или ином виде описаны атрибуты качества, такие как безопасность, производительность, масштабируемость. На первый взгляд все в порядке: они указаны и даже заданы количественно или качественно. Однако при детальном рассмотрении часто выясняется, что совершенно непонятно, к какому объекту относится требование. Требование производительности – к чему конкретно? К продукту? К отдельному модулю? К сервису? К данным? К конкретному пользовательскому сценарию? К каким проблемам это может привести? ▪️Компания берет на себя обязательства, которые невозможно проверить и защитить перед клиентом или регулятором: не зафиксировано, к какому именно объекту относятся эти обязательства ▪️Архитектурный артефакт невозможно однозначно спроектировать и протестировать, если NFR сформулированы без привязки к нему ▪️Требования нельзя проверить на полноту и согласованность между командами, поскольку отсутствует воспроизводимая практика определения объектов и границ NFR В Школе Архитекторов мы подробно разбираем сценарии атрибутов качества. Одна из обязательных частей такого сценария – объект, к которому относится требование. На вебинаре обсудим два вопроса: ▪️Какими бывают объекты NFR? ▪️Как определить границы этих объектов? Вебинар проведет Сергей Баранов. 🗓 8 сентября, 17:00 МСК 🔗 Подключение: https://scrumtrek.ktalk.ru/sccu2uneqagt Регистрация не требуется – добавляйте событие в календарь, чтобы не забыть 🙂

Несчетное количество раз совет директоров пытался договориться о приоритетах на год и каждый раз обсуждение упиралось в то, что у трёх вице-президентов было три разных представления о будущем компании, так что стратегия на очередном квартальном совещании снова «дорабатывалась», а по факту откладывалась. Когда они пришли к нам, стало ясно, что писать ещё один многостраничный документ бессмысленно — кто-то один всё равно сядет и сформулирует его по-своему, а остальные снова начнут спорить на следующей встрече, поэтому мы собрали всю управленческую команду в одной комнате на пять дней подряд: формат Strategy Sprint, где внешний фасилитатор держит рамку и не даёт разговору соскользнуть в прокрастию. К концу недели на доске висели три цели уровня компании и девять ключевых результатов, каждый с конкретными цифрами, владельцем и датой проверки, то есть с тем, чего раньше не было ни в одной версии стратегии за полгода обсуждений. Результат: количество инициатив в работе, которые команды пытались тянуть параллельно, сократилось с 24 до 9, потому что стало видно, какие из них на самом деле работают на цели компании, а какие существовали просто потому, что их когда-то одобрили. Через квартал шесть из девяти KR оказались в зелёной зоне и это стало возможно именно потому, что впервые появился общий язык, на котором разные отделы могли сверяться друг с другом, не тратя недели на согласование формулировок. По сути, дело было не в самой методологии OKR, с тем же успехом можно было бы использовать другой фреймворк, а в том, что решения принимались в моменте, в живом симбиозе людей, сидящих за одним столом, а не растягивались на переписку между отделами, где каждое письмо ждёт ответа по три дня. Если ваша стратегия существует в виде презентации, которую последний раз открывали на защите бюджета, приходите на диагностику – разберём, на каком именно этапе она застряла. 📈 Обсудить стратегию