Не надо заставлять, надо автоматизировать

Этот пост — логическое продолжение моего старого поста об ограничениях и выработке полезных привычек. Вкратце напомню его идею: если не получается себя заставить что-то делать, не надо заставлять себя это делать — надо поставить себя в такие условия, при которых не выполнить уговор с собой будет невозможно или нецелесообразно.

В этом посте — о том, что это работает не только в уговорах с собой, но и в общем случае.

Порядок, правила, инструкции

Я очень часто ошибаюсь. Опечатываюсь, путаю ветки, выхожу не на той станции метро, пишу телефон вместо почты и наоборот, заказываю такси не на тот адрес… Короче, ошибаться — это вот про меня.

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

Дело в том, что «создать правило» ≠ «этому правилу следовать». Просто потому что «следовать правилам» скучно и быстро надоедает — я ж ленивый.

Для меня решение нашлось в том, чтобы менять контекст вокруг себя так, чтобы делать неправильно было неудобно. А точнее — чтобы делать неправильно было менее удобно, чем правильно.

Например

Далеко ходить за примерами не нужно, посмотрим на опыт градостроителей. Ограничение скорости в городах — тема больная и давно изученная.

ПДД работают не очень, потому что их легко нарушить. Когда ничего не мешает ехать быстро, желание ехать быстро — логично. Однако, как только быстрая езда становится неудобной, люди сбавляют скорость сами. Cузить проезд, поднять пешеходный переход, сделать шахматную парковку — всё это работает как искусственные ограничители, которые делают опасное вождение неудобным.

Сужение дороги перед пешеходными переходами заставляет автоматически сбрасывать скорость
Сужение дороги перед пешеходными переходами заставляет автоматически сбрасывать скорость

Та же история — с ручным тестированием в проектах. Людям лень тестировать проекты. Нам надоедает делать одни и те же действия раз за разом, особенно — если для них требуется какое-то значительное количество ресурсов: концентрации, внимания, мыслетоплива. В итоге мы начинаем пренебрегать инструкциями и чеклистами.

«Страх наказания» не работает. Да, человек будет тревожиться и переживать, что его накажут, но лень это не переборет. Надо автоматизировать процесс или менять контекст.

Инструкции не работают, человеческая лень — вот, что работает

…Поэтому когда я замечаю, что «пишу инструкцию» для кого-то, я начинаю думать:

  • могу ли я автоматизировать процесс?
  • могу ли я изменить контекст так, чтобы делать «неправильно» стало менее удобно, чем правильно?

В жизни

Я постарался принести эту философию в разработку Тяжеловато.

Мы сейчас переезжаем на conventional commits, но поменять привычку писать комиты так, как я привык, мне было тяжеловато (no pun intended). Поэтому мы пилим ветку с линтером, который не будет пропускать комиты не по стандарту. А для мотивации писать нормальные комит-сообщения мы будем каждый комит переносить в автоматически сгенерированный чейнджлог.

Ещё пример: работу над проектом мы ведём в ветках. В мастере у нас — только то, что непосредственно на продакшене. Когда в команде становится больше разработчиков, поддерживать консистентное именование веток становится сложнее.

«Написать инструкцию, как называть ветки» — решение плохое, всем пофиг на инструкции, да и мне самому было бы пофиг, наверное. Поэтому при создании CI для тестовых окружений я настроил правило, что автоматически на тест деплоятся только ветки с префиксами, о которых мы договорились. То есть называть ветки всё ещё можно как угодно, только с «неправильным» названием надо будет запариться с выкладкой на тест вручную — а этим заниматься очень лень, проще назвать ветку, как договорились.

А не манипуляция ли это?

Это тонкий вопрос.

Я считаю такую стратегию манипуляцией при совпадении двух факторов:

  • она не служит безопасности и «лучшим практикам»;
  • её нельзя обсудить и изменить.

Первое понятно — сужение дороги перед переходом спасает жизни, тут не важно, бомбит водителям или нет. А вот «как называть ветки» — это более серая зона. С одной стороны есть best practice, с другой — это похоже на директивное управление.

Но анальные огороды директивное управление отличается тем, что директивные решения нельзя оспорить и изменить правила. Если же «манипуляцию» можно обсудить и изменить модель поведения — это уже не манипуляция. Если же решения можно обсудить заранее — то это уже просто договор. А договор — это лучший инструмент управления в принципе.

Почитать на тему

У меня в блоге:

Не у меня в блоге:

Тяжеловато: