Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2009 г.

Руководство командой разработчиков программного обеспечения
Прикладные мысли

С. Архипенков

Назад Содержание Вперёд

Глава 3. Эффективное взаимодействие

Думать и действовать в духе «выиграл/выиграл»

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

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

Для иллюстрации рассмотрим условную кризисную ситуацию в ядерном противостоянии двух сверхдержав: стороны А и Б. Кризис заключается в том, что в заранее определенный момент времени «Ч» каждая из двух сторон может нажать или не нажать на «ядерную кнопку». В случае, если обе стороны одновременно нажимают кнопку, итоговый проигрыш каждой из сторон составляет по 30% промышленного потенциала. Если сторона А наносит удар в момент «Ч», а сторона Б нет, то итоговый проигрыш стороны А составит лишь 10%. Если, наоборот, сторона Б наносит удар в момент «Ч», а сторона А нет, то итоговый проигрыш стороны А увеличится до 80%. Рассуждая в соответствие со стратегией игры с нулевой суммой за сторону А мы должны составить для себя матрицу наших потерь:
  Сторона Б
Наносит удар Не наносит удар
Сторона А Наносит удар 30% 10%
Не наносит удар 80% 0%

Следующим нашим шагом должно быть решение задачи минимизации математического ожидания потерь при неизвестной стратегии стороны Б. Поскольку стратегия нам неизвестна, мы будем полагать что события сторона Б «наносит удар» и «не наносит удар» равновероятны и равны 0.5.

Тогда математическое ожидание потерь игрока А при обоих возможных стратегиях будет:

А (наносит удар) = 30 * 0.5 + 10 * 0.5 = 20 (%)

А (не наносит удар) = 80 * 0.5 + 0 * 0.5 = 40 (%)

Исходя из нашего стремления уменьшить возможные потери мы со всей очевидностью должны избрать для себя стратегию «сторона А наносит удар».

Однако, адекватное понимание обеими сторонами того, что данная ситуация не описывается теорией игр с нулевой суммой приводит к единственно правильному решению — не наносить удар, которое гарантирует взаимовыгодное отсутствие проигрыша как для стороны А, так и для стороны Б.

Думать и действовать в духе "выиграл/выиграл" — это особый настрой, направленный на постоянный поиск взаимной выгоды при всех взаимодействиях людей друг с другом. «Выиграл/выиграл» означает, что все договоренности и решения обоюдно выгодны и удовлетворяют обе стороны. В условиях взаимозависимой реальности любой выбор, меньший чем «выиграл/выиграл», будет слабым и бледным и окажет негативное влияние на долгосрочные отношения.

История 4. «Третья альтернатива»

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

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

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

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

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

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

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

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

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

Руководителю дана власть, у него всегда есть возможность использовать ее и действовать в конфликте в духе «выиграл/проиграл». «Выиграл/проиграл» соответствует авторитарному стилю руководства: «Будет по-моему, а не по-твоему!». Люди с установкой «выиграл/проиграл» склонны использовать свое положение или личные качества, чтобы всегда добиваться своего. Но попробуйте применить принцип «выиграл/проиграл» к клиентам своей компании, много их у вас после этого останется?

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

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

Назад Содержание Вперёд

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (9)
Среда 22.11, 19:04
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...