Работа над ошибками

Штатные разработчики компаний — это «сотрудники за семью печатями». Рынок редко узнает их истории успеха или неудач при создании новых продуктов. Журнал RUБЕЖ смог убедить одного из бывших руководителей R&D-направления в крупном холдинге — на условиях полной анонимности — рассказать о своем опыте запуска такого проекта.

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

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

НО: на аутсорс НЕЛЬЗЯ отдавать проектирование, сбор требований, разработку архитектуры, документирование. Немаловажный плюс собственного отдела разработок — люди внутри компании рано или поздно будут в теме рынка, создаваемого продукта, его особенностей. Поэтому ими будет проще управлять.

НО: к процессу управления НЕЛЬЗЯ привлекать ни коммерческий отдел, ни отдел продаж, ни техническую поддержку.

КЕЙС ИЗ ПЕРВЫХ РУК

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

НАЧАЛЬНЫЕ УСЛОВИЯ ПРОЕКТА

1. Видение требуемого программного продукта у заказчика состоит из:
2. примеров аналогичных продуктов других производителей;
3. списка необходимых функций, разбитого на группы по логическому признаку.
4. Поверхностно сформулированные в электронном виде или на бумаге функциональные требования и нефункциональные требования, базирующиеся на функционале ПО компаний-партнеров. Сценарии взаимодействия, дизайн приложения отсутствуют.
5. Аналитический отдел, в котором есть люди с пониманием того, какой функционал необходим в продукте, отсутствует.
6. Нет тестировщиков, обученных работать с системным ПО, а также с навыками по проведению нагрузочного, регрессивного, автоматизированного тестирования.
7. Разработчиков нет.
8. Нет определенности с платформой, на которой должно работать ПО (ОС, СУБД, технологии разработки).
9. Инфраструктура (система контроля версии, баг-трекинга, система управления требованиями, документирования) находится в процессе создания. Уверенности в том, что создаваемый набор сервисов будет удовлетворять потребности создаваемого отдела, нет.

Этап I. Становление команды, старт работ, проектирование

Длительность этапа: 1-3 месяца.

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

Минимальный состав, с которым можно начать работу

• Руководитель проекта. Несет всю полноту ответственности за ход и успех проекта, является движущей силой всего процесса.

Осуществляет: управление проектом;

планирование работ;

подбор ресурсов и управление ими;

принятие решений в сложных ситуациях;

разрешение разногласий внутри команды;

защиту команды от внешних влияний;

контроль над ходом работ;

соблюдение сроков (и бюджета по необходимости);

налаживание внешних и внутренних коммуникаций;

взаимодействие с заказчиком;

координацию работы команды в целом.

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

подбор ключевых персонажей, их создание и детализация;

составление списка целей, которые должен достигать потребитель при использовании продукта;

разработка сценария использования продукта;

проектирование продукта;

отсечение ненужных, мало востребованных функций;

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

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

сбором требований и их анализом;

систематизацией и документированием требований: составлением спецификаций, технических заданий;

управлением требованиями;

составлением сопроводительной документации: руководств, инструкций по настройке,  справочных материалов;

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

построением модели предметной области.

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

разработки архитектуры системы (ориентируясь на спецификации и ТЗ);

подбора правильной платформы (ОС, СУБД, технологии разработки, библиотек) для реализации продукта;

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

контроля за техническим состоянием кода проекта;

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

контроля за общим состоянием используемой системы;

документирования всех технических аспектов технического решения (архитектуры решения,  потока данных, интеграционных интерфейсов, метаданных и т.д.).

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

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

участие в проектировании продукта;

составление документов для проведения тестирования (тест-план, тест-кейсы, приемосдаточные испытания, программы и методики испытаний);

подбор инструментов, способов, методологий и метрик тестирования и определение качества продукта и/или его отдельных версий;

проведение необходимых видов тестирования;

автоматизация тестирования (написание скриптов, использование различных инструментов);

составление корректных и грамотных баг-репортов в системе баг-трекинга.

Этап II. Создание прототипа

Длительность этапа: нецелесообразно тратить более 8-12 недель.

Прототип создается по ранее намеченному плану, ТОЛЬКО с основными функциями/сценариями в минимальном исполнении.

Состав команды: 8-10 человек.

Создание прототипа может проходить в несколько коротких итераций (обычно 2-3). Самое главное — после утверждения прототипа его код НЕЛЬЗЯ брать за основу приложения, так как код прототипа реализуется без соблюдения каких-либо техник и методологий разработки.

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

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

Этап III. Разработка приложения версии 1.0

Длительность этапа: 9-18 месяцев.

Состав команды: 20-40 человек.

В течение третьего этапа команда может быть расширена. Итеративная разработка приложения будет проходить по методологии SCRUM (методология гибкой разработки ПО, акцент на качественный контроль процесса разработки. — Прим. ред.).

Методология SCRUM дает следующие преимущества:

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

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

Этап IV. Развитие продукта

По своей сути этап IV и все последующие по своей структуре будут напоминать этап III. Как правило, выпуски последующих версий идут по стандартному сценарию.

1. Составление и согласование требований на версию.
2. Планирование версии.
3. Разработка версии.
4. Стабилизация версии.
5. Выпуск версии.

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

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

В первом приближении длительность процесса выпуска версии 1.0 составляет:

• оптимистичная оценка — 13 месяцев;
• пессимистичная оценка — 27 месяцев;
• реалистичная оценка — 18 месяцев.

Основное влияние имеют следующие факторы:

• скорость набора персонала;
• профессиональный уровень персонала;
• объем требований;
• доступность ключевых носителей требований.