Неопределённость — это нормальное рабочее состояние для ИТ-команды в 2026 году. Требования меняются в процессе. Технологии, которые казались стандартом, устаревают быстрее, чем завершается проект. Заказчик сам не до конца понимает, что ему нужно, пока не видит первый прототип. Но есть нюанс – большинство команд выстроены под её отсутствие. По данным исследования State of Team Alignment 2026, только 31% команд используют совместные методы оценки задач, которые позволяют выявить скрытую сложность ещё на этапе планирования. При этом 55% команд оценивают работу во времени, а не в сложности, что скрывает реальную неопределённость и делает оценки систематически неточными. ➖Что отличает команду, устойчивую к неопределённости? 1⃣ Она умеет задавать вопросы раньше, чем начинает писать код. Команда задаёт неудобные вопросы заранее: что мы не знаем? где наши предположения могут оказаться ошибочными? что произойдёт, если требования изменятся? 2⃣ Она фиксирует решения и понимает, почему они были приняты. Одна из главных потерь при смене участников команды — контекст, понимание того, почему система устроена именно так. Команды, которые документируют архитектурные решения и их логику, восстанавливаются после изменений значительно быстрее. 3⃣ Она умеет останавливаться и пересогласовывать. Большинство команд под давлением сроков продолжают движение даже тогда, когда цель изменилась. Команда, устойчивая к неопределённости, умеет сказать «стоп, нам нужно пересмотреть приоритеты», и делает это до того, как потрачен весь бюджет. ➖Что это значит при найме и онбординге? Устойчивость к неопределённости проверяется вопросами: «Расскажи о проекте, где требования кардинально менялись. Как ты действовал?» и «Что ты делаешь, когда понимаешь, что задача поставлена некорректно?».
· 02.09
Самая сложная часть - отличить системную причину от удобного объяснения "виноват человек". Если один сотрудник ошибся один раз, это ещё не обязательно дефект процесса. Но если разные люди регулярно теряют одну и ту же информацию, обходят правило или срывают один и тот же этап, нужно смотреть на входные данные, роли, мотивацию, инструменты и точки передачи ответственности.
В проектах хорошо работает вопрос: "Что должно измениться в процессе, чтобы обычный человек при обычной загрузке не мог повторить эту ошибку?" Не всегда ответом будет автоматизация. Иногда достаточно явного владельца решения, короткого чек-листа или убрать лишнее согласование.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён