Вступление
Замечаю, что часто люди подстраиваются под инструменты для работы, а не наоборот: процессы и поведение в целом деформируется под ограничения и логику треккеров и других методологических инструментов
Хотел бы в свободной форме порассуждать в статье о том, почему так происходит, и что с этим делать
Что происходит?
На уровне отдельно взятого человека происходят изменения в мышлении. Человек перестаёт думать "что именно нужно сделать", задача подгоняется под инстумент
Если инструмент делает что-то сложным — люди перестают это делать, даже если это важно. Если делает что-то лёгким — делают это чаще, даже если это не нужно
Привычка подменяет целесообразность. "Мы так делаем, потому что так работает наша система" — это становится достаточным обоснованием
На уровне команды тоже всё плывёт. Процессы формируются вокруг возможностей инструмента, а не вокруг реальных потребностей. Таск-треккер и его доска диктуют методологию, а не методология — структуру доски
Ритуалы обслуживания инструмента становятся самоцелью — обновление статусов, заполнение полей, ведение отчётов — работа ради работы
Метрики определяются не тем, что важно, а тем, что инструмент умеет считать. Измеримое побеждает значимое
Почему так происходит?
Адаптироваться к инструменту проще, чем настраивать инструмент под себя — это раз
Инструменты предлагают готовую модель мира — легче принять чужую модель, чем строить свою — это два
Когда команда адаптировалась — отклонение от "инструментальной нормы" воспринимается как отклонение от командной нормы — это три
На мой взгляд это основные, но не единственные причины
Что с этим делать?
Во-первых, признать проблему. Нужно её явно проговорить с командой. Без этого никуда
Во-вторых, легализовать обходные пути. Если люди систематически делают что-то "мимо" инструмента — это не нарушение дисциплины, а информация о том, что инструмент не отражает реальность. Разберитесь с причиной, а не боритесь с симптомами
В-третьих, не путать "работу в инструменте" с "работой". Двигать карточки по доске — не работа. Заполненный отчёт — это не результат сам по себе. Если команда тратит ощутимую часть времени на обслуживание инструмента — что-то пошло не так
И последнее — выработайте в команде принципы, которым все будут придерживаться. Инструменты меняются, практики адаптируются, принципы остаются. Если команда не может сформулировать свои принципы отдельно от названия инструмента (jira, youtrack etc) — она уже подчинена ему
Комментарии (3)

kenomimi
27.04.2026 05:46Замечаю, что часто люди подстраиваются под инструменты для работы, а не наоборот
А это так и есть, и разрушает бизнес сие явление медленно, но мощно. Инструмент только не виноват, виновата банальная лень, и слепая вера авторитетам. Люди берут инструмент, и, не задумываясь, сразу пускают его в работу, начиная подгонять под его требования свои бизнес-процессы. "Ну вот так в методичке от менеджера тойоты сказано, у них работает, значит и у нас будет". Не будет, каждый бизнес уникален, и попытка подогнать свое предприятие под чужие правила обычно заканчивается наведением огромной бюрократии, ритуалов, и прочих откровенно вредных вещей. Причем изнутри увидеть дерьмо очень сложно, так как этот рак растет медленно, и все успевают к нему привыкнуть...
Из веселого. Внедрил не так давно у себя нормальный ci/cd - сделал красивый PoC, но ветки в примерах git flow назвал типа example/, test/, и прочими - ну, чтобы пришедшие девопсы (которых изначально не было на большинстве команд) потом переименовали, ибо названия в разных командах чуток отличаются (чехарда с main/master/develop как минимум)... Угадайте, что произошло? Верно - концептуальные названия ушли в продуктив, и всех под них подогнали, хотя было явно написано "переименуйте это как вам удобно".

GorkyUser
27.04.2026 05:46Что с этим делать?
Написать свой инструмент. А если нет времени, желания, компетенции, денег, то адаптироваться к имеющемуся, проявив изобретательность.
MAXH0
Опять менеджмент с Jira бесится?