Как выстроить работу IT-отдела на базе Битрикс24

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

Исходные данные

В IT-отделе у нас:

• Несколько PHP-программистов, занимающихся разработкой собственной ERP-системы;
• Программисты 1С;
• Системный аналитик Битрикс24;
• Бизнес-аналитик процессов компании.

Организация рабочих групп

На каждое направление создаётся отдельная группа в Битрикс24, где регистрируются задачи:

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

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

Пользователь создаёт задачу по шаблону:

Какую проблему нужно решить?

Краткое описание функционала или проблемы, контекст важен для реализации.
Что будет являться результатом?

Детальное описание.
С помощью каких данных будет производиться проверка?

Пример данных.
Сценарии тестирования:

Этот шаблон оказался очень удобным и был заимствован у одной крупной IT-компании.

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

Приоритизация задач

Приоритет задач определяется следующим образом:

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

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

Как выглядит Канбан группы разработки

Перед каждым спринтом происходит:

1. Просмотр задач User Story. Если они не разобраны, они анализируются и декомпозируются.
2. Все задачи в стадии «Квалификация» (новые User Story) проходят анализ.
3. Задачи в разделе «Анализ» уточняются, если требуется, и отправляются в стадию «В спринт на бэклог». Отсюда они перемещаются в другую группу (Scrum) через исходящий вебхук.

GROUP_ID — группа скрама

https://$$$.bitrix24.ru/rest/TOKEN/tasks.task.update.json?taskId={{ID}}&fields[GROUP_ID]=463

Так задачи автоматически попадают в бэклог Scrum-группы.

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

Работа с другими направлениями

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

В отдельной статье я расскажу, как регистрировать и отслеживать выполнение инцидентов в Битрикс24.

Формирование правил работы

На основании структуры были разработаны следующие правила работы:

1. Глобальные задачи от пользователей

• Задачи обозначаются тегом #userstory.
• Находятся в статусе USERSTORY.
• Каждая задача декомпозируется на подзадачи, представляющие конкретные действия.
• Приоритизация задач обсуждается на ежемесячном собрании руководителей отделов.
• Приоритеты фиксируются в таблице Google.
• Каждая задача имеет ведущего разработчика, который может привлекать коллег или внешние ресурсы.

2. Работа с задачами

• Сотрудник начинает и завершает задачу, меняя её статус. Это помогает отслеживать загруженность.
• Мелкие задачи перемещаются на Канбан-доску USERSTORY в статус «В работе».
• Все создаваемые задачи должны быть привязаны к #userstory как подзадачи.
• Технические задачи (например, обновления или устранение долгов) привязываются к основной задаче для отслеживания.

3. Инциденты

• Инциденты должны быть закрыты в течение 24 часов.
• Если требуется больше времени:
  • Инцидент закрывается и преобразуется в задачу.
  • Задача привязывается к глобальной задаче #userstory или выполняется отдельно.

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