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