Битрикс24 для IT-компаний: задачи, спринты и учёт времени по проектам

Коротко о главном

• ⚡ IT-компания обычно платит за пять разных сервисов: таск-трекер, CRM, учёт времени, базу знаний и мессенджер — Битрикс24 закрывает их одной подпиской.
• ⚡ Разработка ведётся в Scrum-модуле со спринтами и бэклогом, а внутренние заявки и продажи — в CRM.
• ⚡ Учёт времени по задачам даёт основу для выставления счетов заказчику и расчёта рентабельности проектов.
• ⚡ База знаний закрывает вечную проблему передачи контекста при смене разработчика на проекте.
• ⚡ Подбор и адаптация разработчиков автоматизируются кадровым модулем — это заметно ускоряет выход нового сотрудника на продуктивность.

Сколько сервисов оплачивает средняя IT-компания

Типичная студия разработки на 15–30 человек использует набор из пяти-шести отдельных инструментов. Таск-трекер для разработки, отдельная система для продаж и договоров, сервис учёта времени, база знаний, корпоративный мессенджер, что-то для хранения файлов. Каждый оплачивается отдельно, у каждого своя учётная запись, и данные между ними не связаны.

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

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

Разработка: спринты, бэклог, доска

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

Бэклог наполняется задачами с описанием, критериями приёмки и приоритетом. При планировании спринта задачи перетаскиваются в него с учётом скорости команды — система запоминает, сколько очков команда закрывала в предыдущих спринтах, и подсказывает реалистичный объём. Внутри спринта задачи движутся по доске: к работе, в работе, на проверке, готово.

Для проектов с фиксированным объёмом и сроком, где гибкая методология не подходит, удобнее классическое управление проектами с диаграммой Ганта и зависимостями между этапами. Обе схемы могут сосуществовать: продуктовая разработка идёт спринтами, заказная — по календарному плану.

Для мелких повторяющихся работ вроде правок по поддержке хорошо работает канбан-доска без спринтов — задачи просто текут по колонкам.

Учёт времени и рентабельность проектов

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

На выходе получается несколько вещей, которых обычно не хватает. Фактические трудозатраты по проекту в сравнении с оценкой — видно, где команда систематически недооценивает работу. Основание для счёта заказчику при почасовой схеме: отчёт по времени выгружается и прикладывается к акту. Доля оплачиваемых часов по каждому сотруднику — показывает, сколько времени уходит на внутренние задачи и встречи.

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

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

Продажи и работа с заказчиками

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

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

Механика простая: при переходе сделки в стадию оценки робот ставит задачу техническому директору с дедлайном в два-три дня. Просрочка поднимается руководителю.

Коммерческие предложения и договоры формируются по шаблонам через генерацию документов. Для компаний с абонентским обслуживанием удобны регулярные сделки: ежемесячный счёт по договору поддержки создаётся автоматически.

Техподдержка и обращения клиентов

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

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

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

База знаний и передача контекста

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

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

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

Найм и адаптация разработчиков

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

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

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

Что стоит оставить в специализированных инструментах

Честная оценка границ применимости избавляет от разочарований. Битрикс24 хорошо закрывает управление задачами, спринты, учёт времени, коммерческий контур, документы и коммуникации.

Он не заменяет систему контроля версий, среду непрерывной сборки, мониторинг продакшена и специализированные инструменты тестирования — это отдельный класс задач. Крупным командам от 30–40 разработчиков со сложными процессами ветвления и релиза обычно удобнее оставить привычный таск-трекер, связав его с порталом обменом данными: задачи живут в трекере, а часы, договоры и счета — в Битрикс24.

Оптимальный сценарий для студии на 15–30 человек — перенести всё, кроме инженерной инфраструктуры. Запуск занимает около двух недель, и начинать логичнее с коммерческого контура и учёта времени: там эффект виден сразу, а разработка подключается следующим шагом. Общая последовательность разобрана в статье про внедрение Битрикс24 в Казахстане.