'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Откуда берутся зависимости
Первый источник — нарезка команд. Когда каждая отвечает за технический слой или отдельный компонент, любая заметная функция требует работы троих, и появляется очередь.
Второй — общие ресурсы. Один архитектор на пять команд, единственный человек с доступом к промышленной среде, общая тестовая площадка. Такие узкие места создают ожидание независимо от того, как устроены процессы.
Третий — внешние стороны: смежные подразделения, подрядчики, регуляторные согласования. Их убрать нельзя, зато можно перестать узнавать о них в последний момент.
Полезно помнить закон Конвея: система получается такой, каковы каналы общения внутри организации. Структура команд проявляется в архитектуре продукта, и обратное тоже верно.
Как убирать
Самый действенный способ — собрать команду вокруг функции, чтобы она доводила результат до пользователя самостоятельно. Шаг тяжёлый организационно и снимает большую часть очередей разом.
Второй способ — снять узкое место в общих ресурсах: научить людей в командах делать то, ради чего они ходят к единственному специалисту, дать доступы, размножить среды. Часто это дешевле, чем кажется, и всегда дешевле постоянного ожидания.
Третий — договориться об интерфейсах между областями заранее. Когда границы описаны, команды работают параллельно и встречаются на согласованном стыке.
Как жить с остатком
Часть зависимостей останется всегда. Задача — сделать их видимыми и предсказуемыми, чтобы ожидание перестало быть сюрпризом.
Каждая зависимость получает три вещи: кто ждёт, чего именно и к какой дате. Формулировка «нам нужна помощь смежников» зависимостью не является — по ней нельзя ни спланировать, ни спросить.
Полезная привычка — называть зависимости на общем планировании вслух и записывать их в одном месте, доступном всем командам. Половина срывов происходит из-за того, что о зависимости знали двое.
Отдельно отслеживайте те, что появились в середине периода: их доля показывает, насколько формально проходит планирование.
Очередь к общей команде
Если без общей команды не обойтись — платформа, безопасность, инфраструктура, — сделайте её работу видимой очередью с ограничением. Тогда становится понятно, сколько ждать, и появляется предмет для разговора о приоритетах.
Худший вариант — обращения к такой команде через личные договорённости. Работа идёт в порядке настойчивости обратившихся, а срок предсказать невозможно.
Хорошая практика — обещание по времени реакции на типовые запросы и открытый список того, что в работе.
Что измерять
Считайте число зависимостей на период и время ожидания на стыках. Снижение первого показателя — прямое свидетельство того, что структурные изменения работают.
Отдельно смотрите долю зависимостей, о которых узнали внезапно. Она говорит о качестве планирования лучше, чем любые опросы участников.
Источники зависимостей и что с ними делать
| ИСТОЧНИК | ПРИЗНАК | ЧТО ДЕЛАТЬ |
|---|---|---|
| Нарезка по слоям | Любая функция требует троих | Собрать команды вокруг функций |
| Единственный специалист | Очередь к одному человеку | Обучить людей в командах, дать доступы |
| Общая среда или стенд | Команды ждут своей очереди | Размножить среды или расписать окна |
| Общая платформенная команда | Запросы идут через личные связи | Видимая очередь с ограничением и обещанием по сроку |
| Внешняя сторона | Согласование всплывает в конце | Заводить как зависимость с датой на планировании |
Работа с зависимостями поставлена
Зависимость становится управляемой, когда у неё есть имя, дата и владелец. Проверьте по пунктам за последний период.
Отмечено 0 из 7
Как сделать зависимости видимыми в Shtab
Свяжите задачи разных команд между собой: зависимость перестаёт быть устной договорённостью и получает срок, владельца и место в истории.
- Связи задач между проектами показывают, кто кого ждёт, прямо в карточке.
- Отдельный статус «ждёт другую команду» делает ожидание видимым в отчёте по времени.
- Ограничение незавершённой работы у общей команды превращает поток запросов в управляемую очередь.
- Форма приёма запросов к платформенной команде заменяет обращения через личные связи.
- Контроль сроков реакции задаёт обещание по типовым запросам.
- Диаграмма Ганта показывает, как сдвиг на стыке двигает общий срок.
Частые вопросы
Полностью — нет, и стремиться к этому не стоит. Реалистичная цель: убрать те, что порождены нарезкой команд и узкими местами в ресурсах, а оставшиеся сделать видимыми и предсказуемыми. Обычно после пересборки команд остаётся четверть от прежнего количества.