Управление отделом разработки с помощью "1С:СППР"

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

Я собираюсь рассказать о нашем опыте использования типового решения фирмы «1С» «Система проектирования прикладных решений» (сокращенно СППР) в нашей компании. Я буду говорить в контексте разработки на платформе «1С:Предприятие», хотя СППР в нашем случае используется и для других задач. Тем компаниям, которые уже успешно используют СППР, либо другие системы, возможно, тоже будет интересен наш опыт.

 

Проблемы управления проектом

Какие проблемы возникают при разработке программного обеспечения?

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

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

Информация нужна:

• о том, какие изменения были произведены;
• о том, зачем конкретное изменение в программе было сделано;
• и о том, кто принимал решение для того, чтобы это изменение попало в программу.

Быстрый поиск таких вещей очень облегчает жизнь.

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

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

• Когда у вас все под рукой, вы можете быстро принимать решения. И этим во многом определяете успех проекта.

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

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

• Кто сейчас чем занимается,
• Сколько времени тратится,
• Почему на это тратится столько времени,
• И что мы можем с этим сделать.

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

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

Есть еще моменты, связанные с разработкой. Часто мы теряем связь между той идеей, которая была на входе, и тем, как это было реализовано.

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

Кроме этого, существуют еще некоторые особенности разработки для внутреннего заказчика.

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

 

Почему СППР? Возможности СППР «из коробки»

Почему СППР? Для нашей компании здесь все достаточно просто.

• Я и мои руководители уже имели опыт работы с этим программным продуктом, а это очень важно.
• Правила разработки, которые мы придумали у себя в ИТ-отделе, очень удачно ложились на методики, которые уже были реализованы в СППР.
• Также немаловажную роль сыграло то, что мы сами – 1С-ники, любой из нас мог доработать этот программный продукт.
• Развернуть конфигурацию СППР очень просто – это можно сделать за пару часов. Достаточно выполнить минимальный набор настроек – все остальное можно донастроить под себя в дальнейшем.

Возможности, которые вы получаете в СППР прямо «из коробки»:

• Проектирование
• Ведение документации
• Совместная работа
• Распределение задач
• Обработка ошибок
• Учет трудозатрат

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

 

Основные объекты СППР и их взаимосвязи

Вернемся к объектам, которые заложены в СППР и поговорим о том, как они решают вопросы и проблемы, обозначенные ранее.

На этой схеме мы видим основные объекты СППР и их взаимосвязи. Это:

• Требования;
• Ошибки;
• Технические проекты;
• Задачи.

Это – обзорная схема, а дальше я расскажу по каждому объекту, для чего он используется. Вам станет понятнее, насколько СППР может быть применима для решения ваших задач.

 

Требования

Требования – это входящая информация, которая поступает в ваш отдел.

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

 

Технический проект

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

• Планирование сроков
• Контроль разработки
• Связь с требованиями и ошибками
• Коллективная работа
• Отдельная поставка

Что может являться основанием для создания технического проекта?

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

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

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

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

 

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

Что есть интересного в техническом проекте?

• Технический проект разделен на этапы, контрольные точки, которые он проходит в своем жизненном цикле. Например:
  • Открытие проекта;
  • Подготовка концепции;
  • Проектирование;
  • Реализация;
  • Тестирование и т.д.
• При создании технический проект автоматически заполняется списком контрольных точек из настроек СППР.
• Этот список можно гибко менять – например, если у вас технический проект на исследование, и разработки в нем не предполагается, вы можете какие-то контрольные точки пропускать.
• Чтобы пройти контрольную точку, в СППР существует механизм согласования, т.е. для каждой контрольной точки при настройке СППР устанавливаются роли и участники, которые будут согласовывать данную контрольную точку. Простой пример: контрольная точка, связанная с окончанием разработки. Здесь принимают участие два человека – это может быть руководитель отдела, который утверждает, что технический проект реализован, и технический лидер, который, например, проводит код-ревью проекта. И как только эти два человека согласуют контрольную точку проекта, считается, что она пройдена. Вы можете очень гибко настраивать согласование этих контрольных точек в зависимости от специфики вашей разработки.

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

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

 

Ошибки

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

Функции, заложенные в механизм обработки ошибок в СППР, позволяют делать с ошибкой многое:

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

 

Учет фактических трудозатрат

Перейдем к учету трудозатрат. Основные требования к нему:

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

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

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

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

 

Работа с метаданными

Также в СППР есть «плюшки», позволяющие упростить работу разработчиков 1С, в частности – работа с метаданными.

Фактически, в СППР вы имеете, при необходимости, все метаданные, которые есть в конфигураторе.

Для чего это может быть необходимо? Это может быть необходимо в том случае, если вы проектируете новую функцию. Например, вы технический лидер, и у вас есть разработчик, которому поручено спроектировать какую-то функцию. Разработчик читает концепцию и начинает проектировать. Он может проектировать в конфигураторе, на листке бумаги или иным способом, но для нас важно, чтобы после этого в техническом проекте СППР были отражены две вещи:

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

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

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

 

Основные настройки программы

Вернусь к настройкам программы. Основные из них:

• Настройки пользователей и прав
• Настройки параметров системы
• Настройки интеграции
• Настройки проектов + дополнительные характеристики проектов

Настройка СППР достаточно простая – покупается продукт, разворачивается, делаются минимальные настройки, и все.

СППР построена на «1С:Библиотеке стандартных подсистем», поэтому настройки там для вас будут знакомые, ничего нового.

• Отличие будет в настройках для проектов. В рамках СППР проект – это информационная система. Сколько вы разрабатываете информационных систем, столько проектов у вас и будет.
• Для каждого проекта вы настраиваете список контрольных точек и исполнителей (согласующих).
• Также для каждого проекта можно добавить дополнительную аналитику в виде разделов проекта – это разделение разрабатываемого продукта на какие-то функциональные дополнительные блоки и версии.
• Дополнительным сервисом в техническом проекте является отправка уведомлений. Можно настроить СППР таким образом, что при определенных событиях, например, при переходе технического проекта из одной контрольной точки в другую, вы получаете на почту уведомление. Это достаточно удобно, не требует от вас заходить каждый раз в СППР, проверять, сделана ли работа и в каком состоянии технический проект.

 

Технология разветвленной разработки

Пару слов скажу про разветвленную разработку. Технология разветвленной разработки:

• Один техпроект – одно хранилище
• Хранилище разработки на поддержке основного хранилища
• При необходимости актуализация хранилища разработки
• После тестирования и проверки помещение в основное хранилище

СППР ориентирован именно на разветвленную разработку.

• Разработка каждого технического проекта ведется в отдельном хранилище, которое стоит на поддержке основного хранилища;
• Вы можете автоматически создавать хранилище для технического проекта;
• Можете загружать в него изменения метаданных из основного хранилища;
• После окончания разработки над техническим проектом изменения помещаются в основное хранилище.

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

Технология разветвленной разработки в нашем случае выглядит следующим образом:

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

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

Поддержка СППР разветвленной разработки

• Автоматическое создание хранилищ технических проектов
• Планирование сроков встраивания технических проектов в основное хранилище
• Загрузка измененных метаданных из хранилища технического проекта
• Анализ изменений метаданных с помощью отчета о сравнении конфигурации технического проекта и основного хранилища

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

 

Чего нам не хватало в СППР

Но также существуют моменты, с которыми в СППР могут возникнуть сложности.

• Например, мы столкнулись с тем, что в понятиях СППР проект – это все-таки система, а для нас проект – это немного больше, мы считаем, что проект может охватывать несколько систем. Это вносит определенные сложности. Мы идем по пути того, чтобы добавить единые классификаторы, чтобы объединить несколько проектов в какую-то другую сущность и таким образом получать необходимые для нас отчеты.
• Также мы добавили возможность контроля переносов сроков, т.е. мы контролируем перенос контрольных точек, существующих в рамках проекта, и получаем отчеты.

 

Итоги

Подводя итог, хочу сказать, что:

• Наверное, СППР подойдет большинству ИТ-отделов, особенно тем, которые работают для внутреннего заказчика.
• Не думаю, что у вас может возникнуть сложность в установке, настройке этого продукта. Важно, что вы получите не только продукт, но и методологию – продукт можно написать самим, но создать методологию, которая уже проверена не только временем, но и используется самим вендором – это, на мой взгляд, очень здорово.
• Берите и дорабатывайте СППР, делайте для него необходимые отчеты – вопросов с тем, чтобы как-то изменить ее под себя, тоже не существует.
• Что интересно, мы используем СППР не только для приложений 1С, но и на других проектах.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.