Причины, по которым ваш процесс должен быть с открытым исходным кодом

Причины, по которым ваш процесс должен быть с открытым исходным кодом

21 февраля 2023 г.

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

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

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

Процесс — это то, как мы работаем вместе

Первое, что нужно понять о Процессе, это то, что он уже существует, признаете вы это или нет. Процесс — это то, как мы работаем вместе.

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

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

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

Процесс может быть проблематичным

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

Проблема с Process заключается в том, что он живет своей собственной жизнью.

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

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

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

Что бы вы ни решили, вы видите проблему и меняете поведение команды, чтобы попытаться решить эту проблему в будущем. Это процессная работа.

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

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

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

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

Что, если бы Process был гибким и динамичным?

Как должен выглядеть идеальный Процесс?

* Это было бы плавно и динамично. Легко адаптируется к потребностям организации. * Внутри него будет хороший контекст. Это упростит внесение изменений. * Это было бы ясно, лаконично и актуально. * Это был бы источник правды, чтобы на него можно было положиться.

Относитесь к процессу как к коду

Короче говоря, хороший процесс немного похож на хороший код:

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

Решение: процесс с открытым исходным кодом

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

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

Хотя это может быть много работы, это также может быть очень проясняющим. И это может придать сил, чтобы иметь возможность сказать: то, как мы работаем вместе, записано. И любой может внести в него изменения.

Преимущества письменной культуры

Запись процесса — основная практика организации с письменной культурой. Запись имеет ряд преимуществ:

* Письмо более четкое мышление. Это требует точности. Он обеспечивает ясность. * Запись асинхронна и всегда доступна. Письмо более масштабируемо, потому что не требует встречи для обмена информацией. * Таким образом, писать лучше для распределенных команд.

Основной недостаток заключается в том, что документация требует усилий для ведения.

Как открыть исходный код вашего процесса: инженерное руководство

Итак, как создать письменную культуру и создать гибкий, удобный процесс для организации?

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

Я делал это много раз. Вот общие шаги, которые я рекомендую.

1. Выберите формат для своего инженерного справочника

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

2. Загрузите содержимое

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

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

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

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

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

3. Выберите сопровождающего: возможно, это вы

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

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

4. Сообщите, как все это работает, и внедрите изменения

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

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

Правила процесса

Каковы правила документирования процесса? Вот чем я хочу поделиться.

1. Ответ с документацией

Первое, чем я хотел бы поделиться, это концепция ответа с документацией. Обычно я делюсь им со всей командой инженеров, на собрании всех инженеров или в информационном бюллетене для организации. А я попробую смоделировать сам. Что такое «ответ с документацией»?

Когда кто-то задает вам вопрос, в идеале вы хотите ответить URL-адресом, который отвечает на этот вопрос. Вы делаете это, заходя на вики, убеждаясь, что ответа там нет, и добавляя его, если его нет. Затем вы отправляете им URL.

Это делает несколько вещей:

  1. Это гарантирует, что в будущем на вопрос можно будет ответить без необходимости отвечать на него.
  2. Он обучает человека спрашивать, где он может найти ответы на будущие вопросы.

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

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

2. Это не официально, пока не появится в справочнике

Следующее правило я постоянно повторяю руководству. Это не официально, пока вы не поместите это в справочник. Всякий раз, когда менеджер вносит изменения или развертывает план, я говорю, что план должен включать URL.

* Команда переходит на двухнедельные спринты? Это должно быть в справочнике. * Кто-то переходит в другую команду? В справочнике должен быть список людей из этой команды.

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

3. Редактирования документа процесса недостаточно для внесения изменений

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

Вам понадобится страница, описывающая, как работают изменения. Обычно я называю это чем-то вроде «Как изменить то, как мы работаем». Он описывает:

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

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

4. Процесс должен включать контекст и историю

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

Добавление истории может помочь людям понять изменения, которые были сделаны с течением времени. А контекст может помочь людям понять, как формировать будущие изменения.

Перейдите на следующий уровень: сделайте это общедоступным

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

Это радикальный шаг, и, вероятно, он не подходит для многих компаний. И может быть трудно привлечь людей к этой идее. Но у него есть некоторые преимущества:

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

Компания, наиболее известная этим, — Gitlab. Руководство по Gitlab — это руководство по эксплуатации для компании, и оно очень хорошо сделано.

Спасибо

Бьорн Фриман-Бенсон предложил идею и практику размещения процесса New Relic в Github.< /p>

Ребекка Кэмпбелл несколько лет была моим партнером по преступлению с документацией процесса New Relic. Я многому научился за то время, когда мы поддерживали там документацию процесса.

Алекс Кроман попросил меня написать инженерное руководство New Relic, которое, по сути, было нашей книгой о том, как мы разрабатывали продукты. Он включал наши методы, роли и стандарты.

Габриэль Рикар познакомил меня с идеей ответа с документацией.

Изображение с сайта Pexels Pixabay

Если вам понравился этот пост, подпишитесь на мой информационный курс по инженерному лидерству или на мой курс по менеджменту на переднем крае.


Также опубликовано здесь


Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE