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

       

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


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

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

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

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

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


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

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

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

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



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

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

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


Содержание раздела