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

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

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

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

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

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

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

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

Например

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

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

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

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

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

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

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

В жизни

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

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

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

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

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

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

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

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

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

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

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

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

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

Тяжеловато:

Fullstack React with TypeScript Свобода от тревоги. Часть 2