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

— В смысле никаких описаний? То есть у вас совсем нигде не написано, по каким правилам у вас команды работают? Совсем-совсем?! Даже SLA? А как ты мне передашь? В смысле по памяти, а если какая-то договоренность забудется и не передастся? Как это пойму по ходу? Ох, мамочки….

У вас было когда нибудь ощущение, что голова у вас круглая, а мысль, которую вы пытаетесь думать, квадратная? Примерно так я себя и ощущала, пытаясь понять, как я буду работать. Стартап был уже не маленький — больше 200 человек, офисы в нескольких странах мира, клиенты по всему миру. И, насколько я поняла, договоренности, как работают команды разработчиков, как часто выпускают релизы, по каким правилам чинят тикеты, как отчитываются, где лежат документы и как обновляются — все решалось как-то по наитию. И это прекрасно — когда вас мало и вы все в одном месте. Но когда твоя новая команда сидит в новой локации, все остальные в других городах и даже странах, и новых людей с каждым днем все больше… мне было не по себе.

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

Система меняется из любой точки системы

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

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

Особенно их надо описывать если количество людей новеньких постоянно прирастает и процессы имеют свойство постоянно меняться. Для чего это потом пригодится:

• Напомнить людям о том, как работает процесс (например, при неисполнении)
• Ввести новенького в процесс
• Ввести изменения в процесс, ничего не упустив
• Подумать, что мы делаем не так, и оптимизировать процесс

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

Что писать

Если коротко и попроще, то инструкции и договоренности со всеми сторонами о том, как строится работа c инцидентами, проблемами, релизами, знаниями, мощностями, безопасностью и тд в нашей организации.

Если подробнее, открываем талмуд ITSM и читаем :)
Эта статья не совсем про то, что описывать, она скорее про то, как описывать и внедрять, чтобы процессы жили.

Как писать

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

Я нашла источник сопротивления, длинные инструкции о 10-30 страницах, написанные лет 5 назад, про которые все через год забыли. То есть попытки структурирования были, не сработали, и была уверенность, что и не будет работать.

Вычитывая эти документы (довольно, кстати, толковые, но длинные, слишком замудренные) я делала себе зарубки

Урок 1:Описывайте договоренности коротко и живым языком.

То, что вы не можете объяснить простым языком сложный процесс — ваша проблема, а не читающего. Возможно, вы пытаетесь воткнуть несколько процессов в один.

Урок 2 Если можно не использовать диаграмму — не используйте. Сложную диаграмму не используйте никогда.

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

Урок 3:Два коротких документа лучше, чем один длинный.

Длинные тексты никто больше не читает, с этим надо просто смириться.

Урок 4: Если можете сами не писать — не пишите.

Людям проще пользоваться тем, что они придумали и структурировали сами. Убедить кого-то в важности создания договоренности правильнее, чем написать самому. Хотя, конечно, не проще.

Урок 5: Если все таки пишете сами, то просите проверить

Очень часто документ возникает после вопроса “как у нас это делается?”. Отлично, если вы послали документ на проверку тому, у кого принимали информацию, со словами “проверь, пожалуйста, все так?”.

Урок 6: Помимо входов, выходов и исполнителей и ответственных, у каждого документа должна быть целевая аудитория

Как в маркетинге: чтобы статью прочитали, она должна быть интересна лично вам. Если пихать в один документ информацию для всех, будет длинно, а мы помним, длинные тексты пугают современных людей. Для примера, есть общее правило для всех, как мы работаем в соответствии с GDPR. На практике это три документа:

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

Что делать, чтоб было не только описано, но и работало?

Декларируйте, что вы и ваша команда управляются так, как написано.

Если что-то идет не так, я открываю документы, тыкаю в них пальчиком и говорю, мы договаривались делать так. Что нужно исправить? Если кто-то из руководства, скажем, не доволен сроками работы над тикетом, я открываю процесс, где написано,

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

и задаю вопрос, мы сейчас будем менять процесс, приоритеты тикета или что-то еще?
Это довольно сильно смягчает недовольство, облегчает коммуникацию и, самое главное, увеличивает вашу предсказуемость и прозрачность вашей работы. А где прозрачность, там доверие. А на доверии можно много чего построить еще.

Плюс дает вам умение отстоять свою команду в случае, если вина не на людях, а на неразберихе в управлении (80% случаев на самом деле).

Показывайте людям, как это работает

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

Станьте источником знаний

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

Зачем это вам

Как минимум, хаоса в голове и на рабочем месте станет поменьше.

Как максимум, вам повезет и вас заметят в этой организации как толкового менеджера, умеющего работать с процессами. :)

Мысли по поводу, довольно спорные, просто порассуждать.

У меня есть достаточно серьезное убеждение, что процессы не может написать и внедрить кто-то со стороны. Описать текущее состояние то он может, но процесс никто не будет поддерживать. И если понадобятся быстрые изменения, они случатся, а процесс будет ждать, пока его создатель внесет изменения.

Управленческие процессы — дело тех людей, которые их используют.

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