О пирамиде ИТ услуг в сфере разработки

Почему важно правильно определить потребности заказчика

До перехода в аутсорс я много лет проработал во внутренней и продуктовой разработке. С точки зрения оказания ИТ-услуг заказчику в такой разработке все довольно просто: мы получали бизнес-требования, системные аналитики превращали их в ТЗ, разработчики его реализовывали, а тестировщики проверяли результат. В итоге заказчик получал от нас готовую фичу или целую систему.

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

В такой ситуации от правильного определения потребностей заказчика зависит очень многое:

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

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

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

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

Для начала рассмотрим процесс разработки бизнес-решения с участием ИТ. 

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

1.     Генерация бизнес-идеи

2.     Составление бизнес-требований

3.     Составление системных требований

4.     Декомпозиция работ на блоки

5.     Реализация блоков работ + контроль качества

И на каждом из этапов этого процесса у заказчика может возникнуть потребность во внешнем подрядчике.

Пирамида ИТ услуг в разработке.

Итак, на основе потребностей получается следующая пирамида ИТ-услуг.

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

Реализация блоков работ по системным требованиям (непосредственно кодирование, тестирование)

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

На входе у подрядчика	ТЗ и план работ
На выходе у подрядчика	код/тесты
Приемка результата	в виде приемки кода/тестов

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

Основные подводные камни при таком сотрудничестве:

1.     Так как заказчик получает код/тест кейсы и т.п., то приемка, как правило, сводится к обзорам полученного результата и проверки соответствия стандартам. Такие критерии могут быть субъективны и размыты. 

2.     Как правило, оплата таких работ ведется по принципу T&M, поэтому необходимо быть готовым предоставить детальное описание проведенных работ.

Реализация системных требований (разработка в общем смысле)

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

На входе у подрядчика	ТЗ
На выходе у подрядчика	готовая фича/система
Приемка результата	приемочное тестирование

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

Основные подводные камни при таком сотрудничестве:

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

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

Реализация бизнес требований в рамках систем(ы) (системный анализ)

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

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

На входе у подрядчика	бизнес анализ
На выходе у подрядчика	готовая фича/система
Приемка результата	приемочное тестирование

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

Основные подводные камни при таком сотрудничестве:

1.     Высокий уровень неопределенности при старте работ. 

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

Реализация бизнес-идеи (бизнес-анализ)

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

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

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

Основные подводные камни при таком сотрудничестве:

1.     Ультра высокий уровень неопределенности при старте работ.

2.     Необходимость работы не только с ИТ-решениями, но, вероятнее всего, и с бизнес-процессами заказчика. 

Генерация бизнес идеи (с последующей реализацией)

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

На входе у подрядчика	бизнес проблема
На выходе у подрядчика	решение проблемы
Приемка результата

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

Основные подводные камни при таком сотрудничестве:

1.     Очень сложно заранее определить, будут ли услуги действительно решать бизнес-проблемы. 

2.     Необходимость работы не только с ИТ-решениями и бизнес-процессами, но и рынком. 

Заключение

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

Менеджеру проекта эта информация позволяет: 

1.     Определить и согласовать критерии выполнения проекта;

2.     Выбрать эффективный способ управления проектом;

3.     Правильно сформировать команду проекта;

4.     Сфокусироваться на проблеме заказчика;

5.     Правильно определить круг заинтересованных лиц на стороне заказчика.