Процесс разработки


Начальное обследование

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

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

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

Также на этом этапе выявляется цель автоматизации.

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

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

На каждый проект компания «Смарт-Ком» назначает менеджера проекта

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

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

Описание текущего и будущего бизнес-процессов

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

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

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

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

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

Вторым важным элементом для старта работ является согласование конечной точки работ

Другими словами, описание того бизнес-процесса, который заказчик хочет видеть по окончании проекта. Это своего рода «идеальная картина», к которой он стремится.

На этом этапе также важно плотное взаимодействие с заказчиком.

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

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

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

Разработка функциональной спецификации

Функциональная спецификация (ФС) — это формализованное описание программного продукта, которое объясняет, что и на основании чего будет делать система.

ФС отвечает на общий вопрос «что мы реализуем», достаточно детально показывает строение всех модулей и их взаимодействие с учетом проектных ограничений

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

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

Типичные компоненты функциональной спецификации:

  • Базовая информация о проекте;
  • Обоснование необходимости;
  • Предположения;
  • Роли;
  • Процедуры, ограничения;
  • Требования к реализации;
  • Требования к хранению данных;
  • Требования к отчетности;
  • Интерфейсы;
  • Сценарии тестирования и т.д.

Важно, чтобы Функциональная спецификация описывала все требования к реализации, а, главное, очерчивала области проекта

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

Грамотная ФС — это залог гармоничных отношений между заказчиком и разработчиком

Заказчик никогда не сможет требовать большего, чем прописано в спецификации, а Разработчик – выполнить меньше, чем там прописано.

Напротив, отсутствие или плохо составленная ФС – это весьма вероятная причина последующих разногласий.

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

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

Окончательный документ должен быть подтвержден заказчиком.

Разработка технического задания

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

ТЗ отвечает на общий вопрос «как мы реализуем», часто содержит системные, архитектурные требования и требования к тестированию, детально описывает структуру всех модулей, при необходимости, форматы взаимодействия с существующими модулями или системами

Обычно ТЗ — это продукт взаимодействия между IT-структурами заказчика и исполнителя, который появляется уже после формулирования всех бизнес-требований.

Обязательными компонентами технического задания по ГОСТу являются:

  • Общие сведения;
  • Назначение и цели создания (развития) системы;
  • Характеристика объектов автоматизации;
  • Требования к системе или реализации;
  • Состав и содержание работ по созданию системы;
  • Порядок контроля и приемки системы;
  • Требования к составу и содержанию работ;
  • Требования к документированию;
  • Источники разработки.

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

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

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

Разработка ПО

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

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

Компания «Смарт-Ком» использует современные методологии ведения проектов.

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

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

Такой промежуток времени называется — Cпринт.

Обычно он составляет от 1 до 4 недель, в зависимости от объема проекта, и жестко фиксирован по времени.

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

По существу, Спринт — это итерация в SCRUM, в ходе которой происходит постоянное развитие программного продукта.

Часто SCRUM называют «методологией гибкого создания программных продуктов».

Преимущества такого подхода:

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

Кроме того, для исполнителя это также предоставляет внутренние преимущества, это:

  • Эффективная организация работы команды и каждого ее члена;
  • Стимулирование эффективного общения членов команды;
  • Возможность оценить эффективность отдельных работников;
  • Упрощение вхождения в команду новых игроков за счёт ясности процесса.

Сопровождение внедрения

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

В этот момент готовая к реализации версия системы поступает на тестирование заказчику*.

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

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

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

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

Идеально, если эти условия заранее оговариваются при написании ТЗ (пункт «порядок контроля и приемки системы»).

Обычно все выявленные на этом этапе проблемы и рекомендации можно поделить на следующие группы:

  • Ошибки, «баги» — мелкие или незначительные ошибки в системе, которые Исполнитель легко устраняет за свой счет до передачи системы в продуктивную эксплуатацию;
  • Критические ошибки (так называемые “show stoppers”) — ошибки, при которых эксплуатация системы невозможна или не имеет смысла. Это может быть и как неправильная программная реализация, так и недостатки в проектировании, которые были не учтены при описании будущего процесса. Такие ошибки также должны быть устранены до старта. Зачастую они задерживают внедрение системы в работу;
  • Некритические ошибки — ошибки, который не влияют на общую работоспособность системы, позволяют ей выполнять свою основную функцию. Однако они могут влиять на какие-то второстепенные процессы или снижать эффективность работы пользователя. Обычно такие ошибки приоритизируются и исправляются после ввода системы в эксплуатацию;
  • Улучшения — это пожелания, предложения, очевидные усовершенствования, которые совершенствуют систему, повышают ее эффективность. Они не должны откладывать намеченный старт, и внедряются обычно в рамках CIP (Continuous Improvement Process, система непрерывного совершенствования).

После окончания тестирования принимается решение о дате старта системы

Однако, есть еще ряд мероприятий, которые необходимо провести до этого события:

  • Установка и настройка продуктивной инфраструктуры,
  • Заполнение или перенос мастер-данных (при необходимости, другой информации),
  • Заведение ролей и пользователей,
  • Обучение сотрудников,
  • Утверждение моделей поддержки и другое.

Ключевым моментом внедрения любого нового процесса в компании является участие в нем высшего руководства.

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

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

Преодоление этих изменений обычно не под силу компании-разработчику и, более того, не входит в сферу ее полномочий.

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

*На самом деле, как указывалось в разделе «Разработка ПО», у pаказчика есть возможность познакомиться с отдельными модулями системы или ее частью уже на этапе разработки. При использовании методологии SCRUM демонстрация функционально-законченных разработок происходит по мере готовности продукта. Это позволяет учитывать требования Заказчика и вносить коррективы в процесс, не дожидаясь полного окончания процесса разработки.

Дальнейшая поддержка

Старт системы и начало ее продуктивной работы — ключевой этап проекта.

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

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

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

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

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

Оно включает в себя выполнение регламентных работ (комплекс операций по поддержанию работоспособности программного обеспечения), устранение неисправностей в работе программного обеспечения в процессе его эксплуатации по внеплановым вызовам заказчика

Самым эффективным (и наиболее распространенным) способом поддержки является трехуровневая структура:

  • 1 уровень — Функциональные эксперты, ключевые пользователи;
  • 2 уровень — IT-служба заказчика (при наличии);
  • 3 уровень — служба поддержки исполнителя.

Все «звонки» поступают на первый уровень. Здесь происходит их классификация и, своего рола, фильтрация.

Обычно достаточно бывает элементарной помощи эксперта для решения проблемы пользователя.

На практике, около 70% поступающих «звонков» решаются уже на уровне Функциональной поддержки. При необходимости проблема эскалируется на уровень выше.

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

Компания «Смарт-Ком» имеет собственную cлужбу технической поддержки

Наши специалисты принимают входящие проблемы, используя различные способы (телефон, e-mail, специальные инструменты, типа TFS), и перенаправляют их техническим экспертам.

На протяжении всего времени разрешения проблемы специалисты cлужбы поддержки оповещают заказчика о текущем статусе вопроса.

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

Доступность службы поддержки, время решения проблем и объем регламентных работ определяются отдельным договором, в котором прописываются все условия:

  • Модель поддержки - режим работы;
  • SLA (Service Level Agreement) – максимальное время решения инцидента;
  • Управление релизами (выкладками новых версий ПО);
  • Плановые отключения системы;
  • Мониторинг работы;
  • Консультации.

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