О бюрократии замолвите слово

Бюрократию никто не любит, особенно в ИТ. Кровь в жилах стынет, когда вспоминаешь недельные переписки с каким-нибудь хозяйственным отделом, который требует заполнить многостраничный шаблон на получение шариковой ручки, к которому нет инструкции. Причем, вроде, все вы делаете свою работу, и в отдаленной перспективе цель у вас одна, но это совершенно не помогает.

Изображение с сайта https://memegenerator.net/img/images/14240797.jpg

Но есть и совершенно обратные ситуации. Когда правил, инструкций и регламентов нет, и все попытки внедрить что-то новое похожи на строительство песочных замков - строить легко, сохранить очень сложно.
Сегодня я попробую разобраться, где же находится тонкая грань между хаосом и бюрократией.

В разработке есть такое понятие как code style - набор правил и соглашений по оформлению кода. Табы или пробелы, расстановка скобок, наименование переменных и много других визуальных вещей. Часто к стилю еще добавляется набор принятых в команде практик, которые касаются уже логики программ, а не только их визуального оформления. Кроме самих правил, у разработчиков в арсенале есть набор инструментов, которые позволяют эти правила эффективно применять. Например, настройки среды разработки, сервисы для проверки соблюдения стиля, практики проведения review кода.

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

• не тратить время на решение мелких и совершенно не важных в контексте разработки вопросов, вроде "ставить ли скобку здесь или строкой выше",
• быстро ориентироваться в чужом коде, потому что он написан в привычном и понятном стиле. 

Как сказал бы Максим Дорофеев - это позволяет экономить мыслетопливо. Я добавлю, что code style позволяет абстрагироваться от рутины оформления кода. 

Мне кажется, что принципы code style - прекрасный ориентир для написания внутренних регламентов, инструкций и правил. Их цель в том, чтобы убрать рутину и сэкономить мыслетопливо. При этом, полученные документы должны быть легковесны и "читабельны", иначе они сами начнут потреблять мыслетопливо тех, кто с ними работает.

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

Тогда можно написать простенькую инструкцию: 

Шаг X. Передача в тестирование 

1. Разработчик выкладывает сборку в Y
2. Разработчик переводит задачу в Jira в статус В тестирование
3. Разработчик высылает письмо на Руководителя тестирования, с копией на Руководителя разработки.
   Шаблон письма:
   <Очень красивый шаблон письма с темой и дефолтным текстом>

Да, пример из waterfall. И да, рассылку можно настроить в Jira. Но смысл примерно такой: типовые действия описаны, действующие лица описаны (причем в терминах ролей), шаблон письма есть.  

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

Какие правила написания инструкций я определил для себя:

• Писать максимально простыми фразами без канцелярита. 
• Формулировать действия в терминах ролей, а не конкретных людей. 
• Максимально упрощать работу по пунктам: добавлять ссылки, шаблоны. 
• Определять действия так, чтобы их выполнение можно было мониторить. 

Что еще важно: 

• Сделать доступ к инструкции максимально простым. Чтобы было проще ее открыть, чем делать как придется или по памяти. 
• Поддерживать инструкции в актуальном состоянии. Например, проводя периодические обзоры. 
• Мониторить выполнение инструкций. Если они выполняются только частично, это повод либо для действий, либо для пересмотра инструкций. 
• Менять инструкции, если в этом появляется необходимость. Цели первичны, инструкции вторичны. 
• Удалять устаревшие инструкции. Или по крайней мере переносить в архив, а потом удалять. Устаревшая документация создает ощущение заброшенности. А это в свою очередь ведет к эффекту разбитых окон. Но это тема отдельного разговора. 

На правах резюме добавлю, что если все работает без бюрократии, то разводить ее и не стоит. Но если какие-то действия регулярно факапятся, или при выполнении рутинных действий в команде возникает разброд и шатание, то это повод, чтобы взяться за перо и написать парочку инструкций.