Гибкость и обязательства

24.03.2015 11:33

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

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

Все должно быть просто, а на деле - нет

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

Даже простые на вид требования часто оказываются неясными. Например, что может означать требование «Пользователь имеет возможность ввести свой телефонный номер в систему»? Это может значить, что пользователь вводит номер в поле, а система просто его сохраняет. А может, однако, означать, что система должна проверить, что введенное значение - это именно номер телефона, преобразовать, если надо, в нужный формат, удостовериться, что номер соответствует указанному пользователем местоположению, а если что не так - попросить пользователя ввести заново, а если тот продолжает вводить неправильно, закрыть ему доступ, и так далее. В зависимости от того, что требуется на самом деле, количество прилагаемых усилий будет сильно разниться.
Многие требования вообще не указываются. Как правило, они фундаментально важны, клиент считает их за данность и вообще не признает за требование - что-то вроде пожелания, чтобы дисплей и клавиатура были на одной стороне телефона: резонно, всем понятно - и можно не проговаривать.
Неоднозначная формулировка: «Принеси мне из магазина литр молока и, если там есть яйца, принеси шесть» - и вы получите шесть литров молока, потому яйца в магазине были. Лингвистические недоразумения часто становятся источником неправильного толкования требований.
Во время работы над проектом могут измениться правовые нормы или бизнес-процессы. Да и сами требования часто меняются. Поскольку бизнес по природе своей динамичен, цели проекта часто представляют собой подвижную мишень.
При уточнении требований в плане производительности, взаимодействия с пользователем, дизайна уже во время проекта вдруг обнаруживается, что технические последствия этих требований - совсем не те, что предполагалось. И разница может быть очень существенной.

Из-за этих недостатков и неполноты требований и дальнейших технических рисков, оценка стоимости ПО - штука очень приблизительная. Оценка на основе детально расписанного ТЗ обычно имеет разброс от -33% до +50% - даже если тот, кто делал оценку, поработал очень добросовестно. А на практике эта неопределенность часто еще больше.

Операция прошла успешно. Пациент мертв

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

Однако этот подход проблематичен, если основной целью написания техзадания становится полное описание требований с тем, чтобы изначально устранить все непонятные моменты для оценки стоимости. Даже если написание такого ТЗ возможно (чего на практике никогда не бывает), усилия были бы чрезмерно велики: ведь надо не только покрыть все функциональные и нефункциональные требования, но и сопоставить все нефункциональные требования с функциональными в количественном выражении. Например, нефункциональное требование «система должна быть производительной» размыто, неизмеряемо и потому особой пользы не несет. Даже несколько более конкретное «система должна открывать новый экран не более, чем за две секунды» тоже не особенно поможет. Ведь останется ряд вопросов: «Какова мощность компьютера, на котором это будет тестироваться? Насколько хороша будет скорость сети во время теста? Сколько пользователей будет работать с системой одновременно? Сколько приложений будет запущено? Насколько обширными будут тестовые данные, и будут ли они иметь отношение к реальным?» Кроме того, эти 2 секунды вряд ли будут адекватны для всех экранов. Для абсолютной точности потребуется описать все манипуляции пользователя с системой.

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

Предположим, что у проекта есть бюджет в миллион евро. В чем польза, если, допустим, удалось сделать ТЗ, которое с точностью ±10 % может сказать, что ПО будет стоить 700 000 евро, но разработка этого ТЗ уже обошлась в 500 000? Конечно, такое ТЗ во время реализации проекта очень поможет, но ту же информацию эффективнее и проще было бы собрать уже во время проекта. На основании точной спецификации можно предсказать, что денег недостаточно, но их было бы достаточно, будь сама спецификация попроще. Операция прошла успешно, пациент мертв. Необходимо декларировать и принять тот факт, что разработка программного обеспечения несет в себе высокий уровень неопределенности. В зависимости от определенных контрактом соглашений, эта неопределенность может привести к различным последствиям для проекта, разрабатываемого продукта и самих сторон договора, как будет описано ниже.

Мы - герои

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

Оно кое-как, но работает

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

В конце концов последним средством остается лишь полная разработка заново. Подрядчик, в особенности если на него давят сроки и бюджет, может не устоять перед соблазном реализовать требования настолько дешево, насколько это возможно, за счет качества. Поначалу у клиента создается впечатление, что его давление привело к успеху: ПО делает то, что нужно. Может, внешний вид не очень и взаимодействие с пользователем не блещет, но ничего такого, на что стоило бы жаловаться подрядчику или инвестировать дополнительные средства в исправление. Чего заказчик не видит - это существенных недостатков «под капотом». И чего он не знает: каждая последующая разработка будет все дороже и дороже, и от подрядчика ему теперь уже никуда не деться, потому что только он и способен понять исходный код. В конце концов, и сам подрядчик сдается перед лицом хаоса. Хорошее ПО имеет свою цену. И нежелание платить ее в конечном счете может обойтись дороже. Поэтому заказчик может попытаться контролировать качество кода. Но как?

Патрули полиции кода

Убедиться в качестве функционала и юзабилити относительно просто, но лишь «по верхам», как мы отмечали выше. Проверка качества исходного кода и дизайна ПО - дело дорогостоящее, она может быть произведена лишь случайным образом. Выполнить ее могут лишь эксперты, и немногие клиенты обладают для этого требуемой квалификацией. Не менее проблематичное решение - нанять другую IT-компанию для проверки. Трудозатраты и соответствующие издержки не будут соответствовать качеству проверки. Более того, неизбежны конфликты между подрядчиком и проверяющей стороной, поскольку многие решения в плане дизайна можно оценить лишь субъективно, и не существует простых и понятных правил на каждый случай. Заказать «качественную архитектуру» загодя - это существенно ограничить самого подрядчика, кроме того, дизайн должен меняться во время проекта. Жесткая привязка к изначальной идее может стать для проекта катастрофой. По сути, у клиента нет никакого мощного, полного и эффективного способа проконтролировать, что там «под капотом» у ПО. В этом заключается фундаментальная проблема разработки по контракту с фиксированной ценой: подрядчик заинтересован реализовать требования с наименьшими возможными усилиями. Если долгосрочное сотрудничество не предполагается, то это прямое предложение подрядчику поступиться качеством.

Кирпичи оплачиваются отдельно

В то время, как неискушенные подрядчики играют в игру «мы герои», многие другие предпочитают иную игру: «Мы продаем вам дом! (Кирпичи в стоимость не входят)» Подрядчик делает самое заманчивое предложение из возможных, лишь бы получить заказ. После того, как оффер принят, он пытается продать как дорогие дополнительные функции то, что в ТЗ было описано неточно или неоднозначно. Например, повышение производительности стоит дополнительных денег, потому что утверждение в ТЗ, что система должна быть мощной, однозначным не назвать; кроме того, валидация того, что вводит пользователь тоже повышает стоимость, потому что в ТЗ описано, что он может вводить, но не описано, что не может, и т.д. Клиент, который надеялся получить то, чего хочет, за фиксированную цену, действительно получает то, о чем он сказал, будто этого хочет. Только это несколько не то. И выходит, что в таких типах контрактов цена куда менее фиксирована, нежели рассчитывал клиент. Однако так для клиента выходит даже хуже.

Страховка для разработчика

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

Заключение

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

Об авторе: Гуннар Хард. Изучив физику в Германии и Новой Зеландии, Гуннар работал инженером по разработке ПО, затем IT-консультантом и руководителем проектов. С 2007 года он отвечает за разработку нескольких IT-систем в Группе Контроля Качества в «Фольксвагене» и стратегически и методически улучшает взаимодействие IT и бизнеса. Харде является «владельцем продукта» по методу скрам и экспертом по гибкому управлению проектами.

Источник: http://re-magazine.ireb.org/issues/2015-[...]uling-complexity/agility-and-obligation/

Перевод: Александра Родсет

Попробуйте сейчас!