Статьи

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

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

Пример из жизни, как это бывает.

Разрабатывали площадку Интернет-торговли для компании с мировым именем. Система состояла из трех компонентов: подсистема on-line заказов, подсистема обработки заказов службой поддержки клиентов и подсистема подготовки и сопровождения каталога продукции. Были определены этапы промежуточных поставок и срок ввода системы в опытную эксплуатацию.

Проект продвигался успешно. Подсистема on-line заказов была поставлена и протестирована клиентом в срок. Подсистема обработки заказов – тоже. А на третьем этапе, как это часто бывает, столкнулись с ошибкой промежуточного ПО, для которой, сколько ни старались, не смогли найти обхода. Если коротко, то использованная система просто не масштабировалась на такой объем данных, с которым собирался работать Заказчик. Применение данного ПО было одним из технических условий контракта, на котором настоял Заказчик. Ничего не смог предложить и уважаемый разработчик этого программного продукта. Да, он признал, что ошибка в его программе есть, да, он подтвердил, что обходное решение этой проблемы ему неизвестно, да, он включил исправление этой ошибки в план очередного релиза, который будет поставлен приблизительно через год.

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

Первое. Вариант «проиграл/проиграл». Заказчик аннулирует контракт (де-юре он, мог бы это сделать), мы возвращаем ранее полученные по контракту деньги. Результат: само собой разумеется, убытки несет наша компания; убытки в виде упущенной прибыли из-за отсутствия автоматизированной системы несет заказчик.

Второе. Вариант «выиграл/проиграл». Мы включаем в контракт дополнительный пункт по разработке той функциональности, которая не доступна в базовом продукте за дополнительную (и немалую, поскольку функциональность сложная) плату. Результат: мы выигрываем - получаем дополнительную прибыль по контракту; Заказчик несет дополнительные расходы.

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

Мы пересмотрели контракт. Суть изменения состояла в следующем. Для того, чтобы ввести систему в эксплуатацию Заказчику требовалось, используя нашу подсистему подготовки и сопровождения каталога (как раз тот компонент, который не был готов), конвертировать его текстовую версию, с которой они работали прежде, в структуру данных новой системы. В силу большого объема информации это была хоть и разовая, но достаточно трудоемкая и, следовательно, дорогая работа. Мы предложили, за те деньги, которые оставались по контракту на разработку третьего компонента написать утилиту, которая хоть и не полностью автоматизирует импорт, но позволит существенно сократить объем рутинной ручной работы при этой операции. А разработку системы подготовки и сопровождения каталога было принято решение перенести на следующий год, когда поставщик промежуточного ПО исправит ошибку, которая стала препятствием в нашей работе.

В результате. Мы «выиграли», потому что получили дополнительную работу. Заказчик тоже «выиграл», потому что смог серьезно сэкономить на ручной конвертации каталога и смог ввести автоматизированную систему в эксплуатацию раньше срока. А поскольку бизнес Заказчика был устроен так, что каталог продукции обновлялся только раз в год, то внедрение третьего компонента нашей системы можно было безболезненно отложить на год.

И еще один интересный факт из этой истории. Описанная история происходила на фоне кризиса, в котором оказался Заказчик после теракта 11 сентября 2001 года. В компании было объявлено тотальное 30-типроцентное сокращение. Но в результате внедрения новой системы количество заказов возросло настолько, что службу поддержки клиентов не только не сократили, но и расширили ее штат.

Источник: С.Архипенков, “Руководство командой разработчиков программного обеспечения. Прикладные мысли”, Москва, 2008.