Рассмотрим классическую проблему, с которой сталкиваются многие небольшие ИТ-отделы: задачи хаотично поступают от пользователей в неудобный Service-Desk, зависают там неделями, а контроль за исполнением фактически перекладывается на самих заказчиков. В такой ситуации программисты работают в режиме тушения пожаров, руководитель не может адекватно оценить загрузку команды, а бизнес выражает крайнее недовольство качеством автоматизации.
Разберем по шагам, как выстроить прозрачный процесс управления задачами, какие методологии применить для команды из нескольких разработчиков и сисадминов, и как автоматизировать контроль качества без лишней бюрократии.
Выясним главную причину хаоса: смешивание оперативных инцидентов (текучки) и плановых доработок (проектов). Если один и тот же программист одновременно пытается писать новый крупный блок учета и отвлекается на звонки из магазинов с криками «у нас не печатается чек», он не преуспеет ни в одном из направлений.
Проанализируем ситуацию и внедрим жесткое разделение задач:
Для минимизации отвлечения разработчиков рекомендуется организовать первую линию поддержки через консультанта. Если выделить отдельного человека невозможно, распределим зоны ответственности. Закрепим за каждым сотрудником ИТ-отдела конкретные конфигурации или участки учета (например: Программист 1 отвечает за 1С:Розница, Программист 2 — за 1С:Бухгалтерия и 1С:ЗУП). Все входящие заявки по этим направлениям должны проходить предварительную фильтрацию у ответственного, который отсекает дубли и некорректные запросы.
Чистый Scrum с жесткими двухнедельными спринтами часто не приживается в небольших поддерживающих ИТ-отделах, так как входящий поток срочных задач постоянно ломает планы. Лучшим решением будет использование Scrumban — гибрида Scrum и Kanban.
Рассмотрим ключевые элементы этой методологии для внедрения в отделе:
Для успешного внедрения процессов необходим удобный инструмент. Использовать зарубежные облачные сервисы вроде Trello или Jira в современных реалиях рискованно, поэтому обратим внимание на альтернативные и встроенные решения.
Вариант A. Ведение задач непосредственно в 1С
Это наиболее органичный путь для 1С-разработчиков. Заведем справочник Задачи или внедрим готовое расширение для Канбан-доски прямо в рабочую базу 1С. Плюс этого подхода — отсутствие «двойной работы». Программисту не нужно перетаскивать карточки на внешних сайтах и отдельно отмечать выполнение в базе. Система сама может менять статус задачи при помещении кода в хранилище.
Вариант B. Российские таск-трекеры
Если ИТ-отдел занимается не только 1С, но и поддержкой инфраструктуры (системным администрированием), лучше использовать универсальные платформы:
Яндекс Трекер — мощный инструмент с поддержкой Agile-досок, спринтов и возможностью тонкой автоматизации процессов. Для команд до 5 человек он предоставляется бесплатно.Kaiten — визуально ориентированный таск-трекер, идеально подходящий под Канбан-методологию с возможностью совмещения нескольких досок на одном экране.1С:Itilium — специализированное решение для организации Service Desk на платформе 1С, поддерживающее методологию ITIL и содержащее встроенные Канбан-инструменты для распределения заявок.Посмотрим на частую проблему: программист берет задачу «Разработать блок планирования закупок» с оценкой в одну неделю. Проходит неделя, прогресса не видно, на вопрос руководителя ответ один — «в процессе». Чтобы избежать этого, внедрим обязательную декомпозицию.
Любая крупная задача должна разбиваться на подзадачи, занимающие не более 4–8 часов работы. Например, вместо одной большой задачи создадим несколько подзадач:
При таком подходе на ежедневной летучке руководитель будет наглядно видеть ежедневный прогресс разработчика, перемещающего мелкие карточки по доске.
Чтобы через год активной разработки база 1С не превратилась в «неподдерживаемое болото», внедрим правила хорошего тона при написании кода. Каждый разработчик должен комментировать свои изменения в конфигурации, привязывая их к номерам задач из трекера.
Посмотрим на пример правильного комментирования изменений кода:
// Петров 20231015 начало SD/Task-14820
// Добавлен контроль заполнения реквизита "Договор" при проведении в рознице
Если Не ЗначениеЗаполнено(ЭтотОбъект.ДоговорКонтрагента) Тогда
ВызватьИсключение "Для данного магазина обязательно указание договора контрагента!";
КонецЕсли;
// Петров 20231015 конец
Для автоматизации контроля качества кода в современных командах применяют инструмент BSL Language Server совместно с платформой статического анализа SonarQube. Эти инструменты автоматически сканируют измененный код на наличие критических ошибок, дублирования, уязвимостей и несоответствий стандартам разработки фирмы 1С до того, как код попадет в рабочую базу.
Разберем ситуацию, когда бизнес-заказчик просит реализовать сложный бизнес-процесс, разработка которого займет два месяца. Не пытайтесь сделать все сразу. Используйте принцип MVP (Minimum Viable Product).
Выделим минимально полезную часть функционала, которую можно сделать за один недельный цикл. Например, вместо автоматического распределения заказов по 35 магазинам с учетом остатков и логистики, в первую неделю сделайте простую ручную загрузку распределения из файла Excel. Дайте пользователям поработать с этим механизмом. Вы получите ценную обратную связь, на основе которой будете развивать систему в следующих недельных циклах. Это убережет команду от написания сложного кода, который в итоге окажется не нужен заказчику.
Применяя эти структурные правила, мы сможем навести порядок в любом ИТ-отделе, сделав разработку прогнозируемой, а работу сотрудников — прозрачной и контролируемой.