Как описать рабочий процесс

young woman 731142 1920 Советы на день
Содержание
  1. Общее описание рабочего процесса
  2. Семь «золотых» правил описания бизнес-процессов
  3. Правило 1. Составляйте, уточняйте и подтверждайте схемы бизнес-процессов вместе с их владельцами (ответственными) и исполнителями. Делайте исполнителей и экспертов авторами процессных диаграмм.
  4. Правило 2. Используйте простые и наглядные подходы описания бизнес-процессов.
  5. Правило 3. Используйте язык, понятный владельцам и участникам бизнес-процессов.
  6. Правило 4. Создавайте схемы деятельности, а не организационных структур.
  7. Правило 5. Избегайте излишней детализации процессов, особенно на схеме «как есть».
  8. Правило 6. Избегайте составления схемы процесса ради схемы, не ведущей к дальнейшему анализу и действиям.
  9. Правило 7. Не смешивайте понятия «как есть» и «как надо».
  10. Sailet Blog
  11. «Рабочий процесс» что это и как работает
  12. Как работает рабочий процесс?
  13. Зачем использовать рабочий процесс?
  14. Программное обеспечение для управления рабочим процессом
  15. Что дает применение программы документооборота в компании?
  16. Адаптация рабочих программ
  17. Простой метод описания бизнес-процессов
  18. Выделяем основной бизнес-процесс
  19. Разделяем основной бизнес-процесс на этапы
  20. Выделяем вспомогательные бизнес-процессы из основного
  21. Разделяем вспомогательные бизнес-процессы на этапы
  22. Проходим все бизнес-процессы поэтапно и описываем каждый этап
  23. Нормализация этапов бизнес-процессов по принципу передающегося с этапа на этап результата
  24. Построение процессов с нуля: от хаоса к порядку
  25. Коммуникации в команде
  26. Планирование, исполнение и контроль задач
  27. Коммуникации с заказчиком
  28. Dev vs Ops
  29. Разработка
  30. Рефакторинг, технический долг и принцип непрерывного улучшения
  31. Внедрение Agile-методологий
  32. Bus factor
  33. Заключение

Общее описание рабочего процесса

Описание и спецификация рабочего места

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

а) название должности;

б) краткое — одна-две фразы — описание должностных функций;

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

г) условия работы и рабочая среда — температура, освещенность, уровень шума и вредные воздействия на рабочем месте;

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

На схеме 3.2.7 приведено описание рабочей должности менеджера, занимающегося вопросами производительности труда и управлением персоналом. Спецификация рабочего процесса, показанная на схеме 3.2.8, вытекает непосредственно из описания рабочего места. Она отвечает на вопрос: «Каковы черты характера и каким должен быть опыт человека для того, чтобы он успешно выполнял рабочий процесс?» Спецификация рабочего места дает информацию, необходимую для приема на работу и осуществления выбора сотрудников. Допустим, Вам требуется опытный и хорошо обученный квалифицированный рабочий; в спецификации рабочего места обязательно будут указаны необходимые уровень подготовки и стаж работника в данной должности. Если в спецификации указаны черты характера и необходимый для выполнения работы опыт, работник должен непременно отвечать этим требованиям.

Наименование должности: менеджер, занимающийся вопросами управления персоналом, производительностью труда.

Сектор: УПЛР

Дата:1 января 2002.

Схема 3.2.7. Описание рабочего процесса менеджера

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

Действия, присущие рабочему процессу

1. Участвует в общем планировании и принятии решений по созданию единой и эффективной службы занятости.

2. Разъясняет политику, проводимую организацией, на разных ее уровнях путем распространения бюллетеней, организации собраний и через личные контакты.

3. Проводит собеседования с кандидатами на должности, оценивает их квалификацию и классифицирует заявки.

4. Занимается собеседованиями и устройством на работу кандидатов на вакантные должности, а также проверяет квалификацию кандидатов.

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

6. Организует тестирование работников.

7. Разрабатывает системы обучения персонала.

8. Разрабатывает систему оценки деятельности службы занятости и обучает менеджеров методам оценки деятельности подчиненных.

9. Составляет файлы по учету работников.

10. Выполняет другие обязанности, связанные с его деятельностью.

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник

Семь «золотых» правил описания бизнес-процессов

Семь «золотых» правил описания бизнес-процессов

sergey kovalev

Сергей Ковалев — руководитель и ведущий консультант консалтинговой компании БИТЕК (Бизнес-инжиниринговые технологии). Имеет 20-летний опыт организационного проектирования и управления бизнес-процессами. Автор публикаций, семинаров и книг по стратегическому и процессному управлению и развитию.

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

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

Правило 1. Составляйте, уточняйте и подтверждайте схемы бизнес-процессов вместе с их владельцами (ответственными) и исполнителями. Делайте исполнителей и экспертов авторами процессных диаграмм.

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

Правило 2. Используйте простые и наглядные подходы описания бизнес-процессов.

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

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

Правило 4. Создавайте схемы деятельности, а не организационных структур.

Пример. Где заканчивается процесс «Поставка товара от поставщика»?

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

Правило 5. Избегайте излишней детализации процессов, особенно на схеме «как есть».

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

Пример. Спор о накладной

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

Правило 7. Не смешивайте понятия «как есть» и «как надо».

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

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

Источник

Sailet Blog

undraw Process re gws7

«Рабочий процесс» что это и как работает

Время для чтения: Приблизительно 7 минут

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

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

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

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

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

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

Как работает рабочий процесс?

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

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

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

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

Зачем использовать рабочий процесс?

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

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

Программное обеспечение для управления рабочим процессом

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

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

Что дает применение программы документооборота в компании?

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

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

Адаптация рабочих программ

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

Источник

Простой метод описания бизнес-процессов

В любой компании разных бизнес-процессов как минимум несколько. Примеры бизнес-процессов:

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

Но тогда нужно понимать, что как бизнес-процесс описан, так его интегратор и настроит в CRM. Иногда лучше доверить вопрос описания бизнес-процессов профессионалам.

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

Выделяем основной бизнес-процесс

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

Разделяем основной бизнес-процесс на этапы

В таблице выписываем последовательные этапы основного бизнес-процесса.

Выделяем вспомогательные бизнес-процессы из основного

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

Разделяем вспомогательные бизнес-процессы на этапы

Мы это уже делали с основным бизнес-процессом. Со вспомогательными нужно сделать то же самое.

Проходим все бизнес-процессы поэтапно и описываем каждый этап

Каждый этап в итоге должен содержать следующие данные:

Вот так будет выглядеть основной бизнес-процесс после детализации:

Нормализация этапов бизнес-процессов по принципу передающегося с этапа на этап результата

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

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

Источник

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

eox2dc22pp

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

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

Исходные данные нашего отдела: небольшая (5–10 человек), частично распределенная (некоторые сотрудники работают удаленно, некоторые в офисе) продуктовая команда с заказчиками внутри самой компании. Веб-проекты. Нет специалистов по системному администрированию внутри отдела, но есть занимающиеся этим отделы в компании.

Коммуникации в команде

abr4b6vwehelqgjtdlr9iqo5nlk

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

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

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

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

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

Для начала мы завели чат в Telegram. Но потом, в связи с ростом команды, мы поняли, что в одном чате нам уже тесно, и перешли в Slack. Там мы разбили общий поток на тематические каналы и установили четкие правила — по каким поводам в какой канал писать. Это помогло избежать смешения полезной информации и флуда.

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

Планирование, исполнение и контроль задач

image loader

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

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

Для борьбы с этим мы разработали и внедрили свою культуру ведения задач:

Коммуникации с заказчиком

image loader

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

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

В таком подходе кроется сразу несколько проблем:

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

Часто бывает, что заказчик, вместо того чтобы прийти с проблемой, приходит с просьбой о реализации уже выдуманного им решения. Чтобы не удивлять ни себя, ни заказчика результатами работы по ТЗ, составленному «на салфетке», мы создали базовый чек-лист вопросов для заказчика. Уже на основании этих ответов легче понять и заказчику, чего же он хочет на самом деле, и команде разработки, что от нее требуется. А потом настает черед задавать какие-то наводящие вопросы для уточнения или выявления требований.

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

Список вопросов для заказчика:

Также в рамках этого пункта мы постарались искоренить классический антипаттерн «чайка-менеджмент», когда заказчик или менеджер прилетел, «наложил» задач — и улетел в полной уверенности, что раз он задачу поставил, то непременно на выходе получится отличный результат. Как показала практика, результат при таком подходе получался не самый впечатляющий. Как с этим бороться? Тут тоже нет какого-то универсального совета, какой-то волшебной фразы, изменяющей поведение людей. Для этого необходимо разговаривать, просвещать, объяснять, показывать, можно сказать воспитывать. Только просветительская работа и либо очень наглядные, либо очень измеримые (а желательно и то, и другое) позитивные и негативные примеры помогут в достаточной мере побороть «чайка-менеджмент».

Dev vs Ops

image loader

И последняя важная наша проблема — проблема в коммуникациях между отделами Dev и Ops.
Мы столкнулись с классической ситуацией, когда разработчики не очень хорошо понимают, как работает сервер, а сторонняя команда админов не очень представляет, как работает приложение. Каждое затруднение на стыке этих двух сфер давалось нам с болью и большими временными затратами. Трудно было даже диагностировать, на какой стороне проблема:

Разработка

miedif5uox5f4d 66zcklwdrp5o

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

Рефакторинг, технический долг и принцип непрерывного улучшения

1khes2nxirn

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

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

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

В нашем случае нам, разработчикам, удалось объяснить и показать бизнесу важность погашения технического долга. Как мы это сделали? Мы на практике продемонстрировали такие ситуации, в которых, если не провести рефакторинг или какие-то другие структурные изменения текущего проекта, разработка новой функциональности или изменение старой будет невозможна в принципе (либо возможна, но в разы медленнее).

Внедрение Agile-методологий

hy5k5jl82o ar2z6wnf 8wh85g4

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

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

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

Также мы перешли от длинных релизов к коротким. Раньше мы получали ТЗ, неделями или месяцами делали целый пак фич и только тогда показывали заказчику. В результате часто оказывалось, что заказчик либо передумал, либо ожидал не совсем того, и мы начинали переделывать все или часть того, что уже сделали. А вносить изменения в уже готовый большой набор фич — это сомнительное удовольствие. Сейчас мы демонстрируем каждую фичу как можно раньше, чтобы заказчик принял решение — то ли это, что он на самом деле хотел, или надо что-то изменить. Чем быстрее он либо утвердит, либо отправит на доработку, тем меньше трудозатрат мы вложим, следовательно, тем быстрее фича придет в продакшен. В результате фичи стали поступать в продакшен быстрее, быстрее проверяются гипотезы, быстрее пошло развитие проекта.

Bus factor

image loader

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

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

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

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

Заключение

В заключение хотелось бы отметить, что ни одна из вышеуказанных проблем не решалась сразу и безупречно. Организационные изменения — это всегда долгий и методичный труд. Нельзя просто сказать «теперь делаем так» и надеяться, что теперь все станет иначе. Любые решения, которые вы примете, любые мероприятия, которые вы организуете, требуют контроля, обучения и просвещения людей, времени на адаптацию как команды к новым методикам, так и самих методик к конкретной ситуации. Также замечу, что навязывание людям какой-то методологии является очень трудоемким и малоэффективным процессом. Люди будут упираться, заб(ы/и)вать, возможно даже саботировать.

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

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

Автор: Евгений Антонов, руководитель группы разработки Positive Technologies

Источник

Оцените статью
Добавить комментарий

Adblock
detector