Однажды я сменил работу и прошел путь от крупной, хорошо структурированной организации до быстрорастущего стартапа.
Мне сразу все понравилось: и энергия, с которой работали люди, и профессионализм, и искренность внутренних коммуникаций.
Но в тот момент, когда мне начали передавать дела ПМ, меня ждал сюрприз: - Что значит нет описаний? То есть вообще нигде не написано о том, по каким правилам работают ваши команды? Совсем?! Даже SLA? Как ты мне скажешь? Я имею в виду, по памяти, но что, если какое-то соглашение забудется и не будет передано? Как я это пойму по ходу дела? Ой, мамочки.
Было ли у вас когда-нибудь ощущение, что ваша голова круглая, а мысль, которую вы пытаетесь додумать, квадратная? Примерно так я себя чувствовал, пытаясь понять, как мне работать.
Стартап уже не был маленьким — более 200 человек, офисы в нескольких странах, клиенты по всему миру.
И, насколько я понимаю, соглашения, как работают команды разработчиков, как часто выходят релизы, по каким правилам фиксируются тикеты, как они отчитываются, где находятся документы и как они обновляются - всё решилось как-то по прихоти.
И это прекрасно, когда вас немного и вы все в одном месте.
Но когда твоя новая команда сидит в новом месте, все остальные в других городах и даже странах, и новых людей с каждым днем становится все больше.
Мне стало не по себе.
В итоге я вспомнил одну простую мысль, так как у меня техническое образование:
Система меняется из любой точки системыИ я решил, что, наверное, буду той точкой, которая выведет систему из состояния хаоса в состояние четкой структуры.
Для программистов и других лиц, которые считают, что описание процессов управления — пустая трата времени: как код должен быть покрыт технической и пользовательской документацией, так и работа компании должна описываться инструкциями и процессами.
По тем же причинам: чем больше правил и чем они запутаннее, тем труднее их запомнить.
Их особенно необходимо описывать, если число новых людей постоянно растет и процессы имеют тенденцию постоянно меняться.
Чем это пригодится в дальнейшем:
- Напоминайте людям, как работает процесс (например, когда он не выполняется)
- Привлеките в процесс кого-то нового
- Вносите изменения в процесс, ничего не упуская
- Подумайте, что мы делаем не так, и оптимизируйте процесс.
Но нет, оказывается, технологические стартапы обычно упускают из виду сложность процессов управления и предпочитают думать, что все должно получиться само собой.
Что написать
Если кратко и просто, то это инструкции и соглашения со всеми сторонами о том, как работать с инцидентами, проблемами, релизами, знаниями, возможностями, безопасностью и т. д. в нашей организации.Для более подробной информации откройте ITSM Талмуд и почитайте :) Эта статья не совсем о том, что описывать, скорее о том, как описать и реализовать, чтобы процессы жили.
Как написать
Задача, как это описать, чтобы люди могли этим пользоваться, не очень тривиальна, особенно в условиях, когда изменения идут не сверху, со стороны руководства.При явном сопротивлении становится еще сложнее.
Я нашел источник сопротивления, длинные инструкции примерно на 10-30 страниц, написанные лет 5 назад, о которых через год все забыли.
То есть были попытки структурирования, которые не сработали, и была уверенность, что это не сработает. Читая эти документы (вполне толковые, кстати, но длинные и слишком сложные), я делал для себя пометки.
Урок 1: Опишите соглашения кратко и живым языком.
То, что вы не можете объяснить сложный процесс простым языком – это ваша проблема, а не читателя.
Возможно, вы пытаетесь склеить несколько процессов в один.
Урок 2 Если вы можете избежать использования диаграммы, не используйте ее.
Никогда не используйте сложную диаграмму.
Со стороны кажется, что все наоборот — читать, мол, труднее, чем смотреть на схему.
Я тоже так думал.
Однако сейчас у меня на руках два документа с описанием того, как мы выпускаем фичи: текст и диаграмма.
Схема не обновляется (то ли сложно, то ли нет времени), текст постоянно обновляется (не только я этим давно занимаюсь).
Урок 3: Два коротких документа лучше, чем один длинный.
Длинные тексты уже никто не читает, с этим просто нужно смириться.
Урок 4: Если не можешь написать сам, не пиши.
Людям легче использовать то, что они сами придумали и структурировали.
Убедить кого-то в важности заключения соглашения лучше, чем написать его самостоятельно.
Хотя, конечно, это не проще.
Урок 5: Если вы все-таки сами это пишете, то попросите проверить Очень часто документ возникает после вопроса «как нам это сделатьЭ» Замечательно, если вы отправили документ на проверку человеку, от которого получили информацию, со словами «проверьте, все ли правильноЭ» Урок 6: Помимо вкладов, результатов, исполнителей и ответственных лиц, каждый документ должен иметь целевую аудиторию.
Как в маркетинге: чтобы статью прочитали, она должна быть интересна лично вам.
Если запихнуть информацию для всех в один документ, то он будет длинным, но мы помним, что длинные тексты пугают современных людей.
Например, для всех существует общее правило того, как мы работаем в соответствии с GDPR. На практике это три документа:
- для всех сотрудников - описание самого правила, что можно и что нельзя делать с информацией.
- Куда и как обращаться в исключительной ситуации – для разработчиков и поддержки
- Как и где реализовано то, что описано технически - для разработчиков
Что нужно сделать, чтобы оно не только описывалось, но и работало?
Заявите, что вами и вашей командой управляют так, как написано.
Если что-то пойдет не так, я открываю документы, показываю на них пальцем и говорю, мы договорились это сделать.
Что необходимо исправить? Если кого-то из руководства, скажем, не устраивают сроки работы по тикету, я открываю процесс, где написано:
- как мы принимаем билеты на работу,
- какие этапы они могут пройти,
- в чем причина прекращения работы над билетом и
- каково среднее время на каждом этапе.
А где прозрачность, там и доверие.
А на доверии можно построить гораздо больше.
Плюс это дает возможность защитить свою команду в случае, если виноваты не люди, а неразбериха в руководстве (фактически в 80% случаев).
Покажите людям, как это работает
Часть процесса управления релизом родилась из трёх разговоров с релиз-менеджерами.На основании этого я объяснил руководству, почему подготовка релиза занимает так много времени, и вызвал на это обсуждение релиз-менеджера.
Сейчас в этом месте находится несколько документов о том, как, почему и что мы должны выпускать.
Написано, конечно, не мной, а релиз-менеджерами.
Научите людей тому, что это удобно, что освобождает их от лишних объяснений и дает возможность быть прозрачным сразу и для всех.
По вашему примеру.
Стать источником знаний
Не забываю время от времени читать небольшую лекцию о том, что письменные соглашения о формате работы намного лучше тех, которые не записаны.Мне интересно об этом говорить, поэтому каждому приходится слушать много раз.
Не первый раз, постепенно большинство наших договорённостей сползли воедино.
Вода точит камни.
Зачем вам это
Как минимум, в вашей голове и на рабочем месте будет меньше хаоса.Максимум, вам повезет и в этой организации вас заметят как толкового менеджера, умеющего работать с процессами.
:) Мысли по этому поводу весьма противоречивы, можно лишь предполагать.
У меня достаточно серьезное убеждение, что процессы не могут быть написаны и реализованы кем-то со стороны.
Он может описать нынешнее состояние, но никто не поддержит этот процесс.
А если нужны быстрые изменения, они произойдут, и процесс будет ждать, пока его создатель внесет изменения.
Процессы управления — это дело людей, которые их используют. И все же должно быть осознание того, что процессный подход – это не навязанное извне правило, а мое соглашение с внешним миром о правилах работы со мной.
Тогда процессный подход станет не тормозом развития организации (я это когда-то видел), а катализатором роста.
Теги: #Управление разработкой #Управление проектами #процессы управления
-
Укротите Свою Техподдержку
19 Oct, 24 -
А Может Быть, Весна Для Женщин?
19 Oct, 24
