Напомним, что характер отношений разработчика и заказчика
существенно зависит от той стадии, на которой находится
разработка программной системы. То есть ее жизненный цикл.
Поэтому, прежде всего, напомним, что разработка программных
систем — это многофакторная оптимизация с учетом
тех атрибутов качества, которые на самом деле, на каждом этапе
являются бизнес-критичными для заказчика.
Это могут быть сроки, стоимость, то есть глобальные критерии,
которые определяют наш проектный треугольник, а могут быть
другие атрибуты качества, такие как скажем, сопровождаемость,
эргономика, безопасность и так далее.
Приоритетность, естественно, определяется характером
и масштабом проекта. То есть ключевыми требованиями кроме
всего прочего, которые возникают у заказчика и пониманием
этих требований разработчикам.
Напомним, кроме того что жизненный цикл продукта и проекта
существенным образом отличаются и вообще говоря, жизненный
цикл продукта, как мы видим на схеме, включает большее
количество этапов. Но тем не менее в зависимости от того,
на каком этапе мы находимся, можно повторить,
что существенным, определяющим является именно этот этап,
с точки зрения взаимоотношений разработчика и заказчика.
И в этой связи имеет смысл еще раз вспомнить жизненный цикл
разработки с точки зрения тех этапов, которые у нас происходят.
Это первичное инвестирование, когда мы фактически вкладываем
в то, что называют в «Бостонской матрице» «знаком вопроса»,
в тот продукт, который еще не взлетел, у которого может еще
и нет конкретного потребителя, так сказать, просто производим
некоторый обстрел рынка. Пытаемся понять, кому мы можем
этот продукт предложить и действительно правы ли наши
маркетологи, говоря, что этот продукт имеет право на жизнь.
После этого происходит выход на рынок. Достаточно быстрый
рост. Если все хорошо— возврат инвестиций, достаточно
хорошие продажи. После чего наступает зрелость
и определенный упадок продукта, когда ему уже сложно
конкурировать с соседями.
Другое представление, это «Бостонская матрица»,
«знак вопроса», «восходящая звезда», «дойна корова»
и «кусачая собака». Все те же самые стадии, когда сначала мы
не имеем полного понимания того, каким образом продукт
выйдет на рынок и будет там работать.
Затем «восходящая звезда», достаточно быстрый рост продаж
и получение первой прибыли, мы выходим на окупаемость,
если все хорошо с нашим жизненным циклом
и с взаимоотношениями с заказчиком.
Затем «дойная корова», когда идут продажи без особых усилий.
И наконец, «кусачая собака», когда каждая продажа скорее
отнимает ресурсы, чем прибавляет и нам все сложнее
конкурировать. В любом случае надо понимать, что на каждой
из этих стадий, наше отношение с заказчиком строятся немного
различным образом.
Напомним, что модели жизненного цикла,
которые определяют то, каким образом взаимодействуют
разработчик и заказчик на разных стадиях, также существенным
образом определяют приоритеты и атрибуты качества:
такие как скажем сопровождаемость, такие важные
характеристики как возврат инвестиций, риски, дисциплина
разработки, которая, скажем, является бизнес критичны
прежде всего для объективного ориентированного подхода.
А при недисциплинированной разработке вырождаются в модель
проб и ошибок. При этом естественно нужно учитывать,
что некоторые модели оказываются настолько сложными, что,
как скажем модель синхронизации – стабилизации не получают
широкого распространения внутри той компании
(скажем, как «Майкрософт»), которая собственно создала этот
подход. В любом случае выбор жизненного цикла критически
влияет на отношения с заказчиками, качество продукции
и на результат проекта, а также на стратегию управления
изменениями, рисками и в целом на продуктивность
взаимоотношений разработчика и заказчика.
Поэтому выбор модели жизненного цикла и методологии
разработки являются действительно очень важным
стратегическим решением при начальной стадии разработки,
когда разработчик и заказчик только определяют и формируют
взаимоотношения.
