Автор: Алексей Янчук

Этот простой и вместе с тем сложный вопрос нам часто задают коллеги. Сложный он потому, что на него невозможно дать однозначный ответ. В самом деле, может показаться, что мы говори об одном и том же: делаем проект, получаем продукт, оказываем услугу. Частенько молодые спецы приводят приблизительно такой аргумент: возьмем обувную мастерскую, и предствим, что вы – клиент. Вам надо поставить новую набойку. Так вот набойка – это продукт, постановка набойки – проект, собственно постановка – это услуга. Так же и в ИТ, что ж тут непонятного?

Забудем ненадолго о проектах
Тем не менее в нашей ИТ индустрии разница между этими понятиями существует.

Для начала давайте забудем ненадолго о терминах «проект» и «услуга». Классическое определение термина «проект» выделяет три отличительные черты: это уникальный (1) кусок работы, имеющий определенное начало (2) и определенный конец (3). Теоретически обсуждать проекты трудно потому, что многое зависит от того, как именно определен конкретный проект. Говоря о проекте вообще, мы делаем много явных или не очень допущений и оперируем большим количеством неизвестных и переменных. Как то: кто исполнители, как устроен менеджмент, кому проект отчитывается, где его рамки, и что собственно должно получиться на выходе. Проекты так же могут дробиться на под-проекты и объединятся в программы проектов.

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

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

1. Пакет работы (Work Package)
Когда речь заходит о непосредственной работе над программным кодом, нам больше нравится термин «пакет работы», work package по-английски. Пакет работы – это задание, уникальное или не очень, которое надо выполнить исполнителю. Поставить ту же набойку. Сделать презентацию для менеджмента компании. Выполнить исследование рынка. Поверить экспериментальным прототипом правильность концепции, и т.п. Ключом является то, что определенные входные данные трансформируются в опеределенные выходные результаты. Применительно к ИТ, на вход дали требования, на выходе получили программные артефакты, такие как, например, схема базы данных, скрипты развертывания, программный код, документация, отчеты от тестировании, и т.д. Работа как правило итеративна и так или иначе вращается вокруг реализации функциональных требований.

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

Самым важным для продукта является:
- установление корпоративного управления продуктом, а так же
- канал продвижения и продаж в случае коробочного (или около-коробочного) ПО.

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

3. Консалтинг
Если Вы показываете клиенту презентацию, где пытаетесь его убедить, что очередной проект лучше делать на С#, а не на С++, -- Вы ни на секунду не консультант. Вы всего лишь высказали свое экспертное мнение за деньги.

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

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

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