Итак, вы - руководитель аутсорсинговой компании, которая занимается разработкой программного обеспечения. Один из ваших клиентов - коммерческий банк.
В этом банке, как и во всяком современном банке, все работает до тех пор, пока работают банковские IT-системы. Одну из этих систем создавали специалисты банка. По каким-то причинам система получилась далекой от совершенства, и в какой-то момент количество глюков в ней стало мешать работе банка (проблема была в базе данных, над которой, собственно, банковские программисты и трудились).
К решению проблемы привлекли разработчиков-аутсорсеров - компанию, которой вы руководите. Разработчики сделали "заплатку", которая решала основные проблемы. С этими проблемами база не работала вообще.
К сожалению, эта "заплатка" породила новые проблемы, возникающие лишь при определенных условиях. Например, платежи, в которых в коде ИНН есть ведущий ноль, вообще не отправлялись банком.
Как ваша компания попала в проект банка? Вы продавали ему программу для интернет-банкинга, которая работает с той самой БД. "Заплатка", которую сделали ваши специалисты, позволяла программе работать с базой, невзирая на ошибки.
При этом ваши сотрудники, по их словам, ставили в известность представителей банка о проблемах с БД, но банк не отреагировал.
Из-за того, что платеж не прошел, у банка возник конфликт с крупным корпоративным клиентом. Поскольку клиент тесно связан с криминальным миром, на банк "конкретно наехали" и заявили, что он должен выплатить неустойку за непереведенный вовремя платеж.
Руководство банка в гневе и ярости, директор банка по ИТ срочно ушел в отпуск. Банкиры спустили претензию вашим разработчикам: это же из-за их "заплатки" возникла проблема с клиентом, пусть они разбираются и расплачиваются.
Еще вчера вы чувствовали себя уверенным и опытным руководителем ИТ-компании, а сегодня вздрагиваете, когда у кого в мобильнике играет мелодия из "Крестного отца". )) Исправить ошибку и выпустить новую "заплатку", конечно, можно, но никто не застрахован от появления столь же критичных ошибок (и разъяренных клиентов) в будущем.
Итак, ваши действия по урегулированию конфликта?
Комментарии к этой задачке открыты. Ответы принимаются до пятницы. Если нужны дополнительные данные, то спрашивайте в комментах, читатель постарается через меня ответить на вопросы.
2. прикрыть зад - заплатку вы же не сами принимали решение ставить, а IT-служба банка, после каких-то проверок и под какой-то документ - перевести вопрос на то, что процессы изменений продуктивного ПО в банке также должны быть как-то отрегулированы и проводиться не формально
3. определиться кто владеет кодом СУБД - уже вы или всё ещё программисты банка, если второе - научиться плотнее с ними сотрудничать
4. изготовить ещё одну заплатку, вместе со специалистами банка принять патч под честной процедурой приёмки
5. на предупреждение проблем в будущем навесить на АБС мониторинг по слежению за неисполненными или искаженными документами - сделать это для банка в рамках доброй воли
под подпись в письменном виде уведомить заказчика об особенностях заплатки. Получить принципиальное согласие руководителя заказчика (тоже письменно). Аргументировать тем, что или вот так, или никак. Если заказчик говорит: "Никак", значит никак. Т.е. никаких "банк не отреагировал" не принимаем. Реакция должна быть задокументирована.
Если этого не было сделано, то тут сложнее. Урегулируем конфликт, чтобы нам как аутсорсинговой конторе выйти из проблемы сухими и разорвать отношения с банком? Или с банком отношения нужно сохранить?
Edited at 2013-11-19 01:28 pm (UTC)
У меня была похожая ситуация, новые арендодатели пытались выгнать из офиса, не продлять аредну. Удалось разрулить переговорами, даже цену не подняли, как сразу пугали.
В нашем мире корпорации действуют по беспределу, единственный выход по мне - вести себя максимально честно и открыто.
Для этого проанализируем наши вводные:
1) Что прописано в вашем договоре с клиентом? Лежит ли на банке ответственность за тестирование? Лежит ли на вас ответственность за убытки банка вызванные сбоем в системе? Каков максимальный размер этой ответственности? (не говорю, что срочно нужно идти в суд, но договор - хорошее начало для продуктивной логической беседы).
2) Кто в банке отвечал за постановку задачи и приемку результата? Доступен ли этот человек? Принимает ли он на себя ответственность за плохое тестирование?
3) Каково соотношение убытка от проблемы и прибыли которую получает ваша компания от этого клиента (например, за год)?
4) Насколько важен этот клиент для вашей компании? Можете ли вы позволить себе потерять его без существенных долгосрочных последствий?
5) Насколько вы важны для вашего клиента? Легко ли ему будет заменить вас, если вы откажетесь с ним работать?
Ответив на эти вопросы можно начать выстраивать стратегию переговоров.
1. Действовать в рамках договора. Но есть риск потерять клиента.
2. Возможно проявить гибкость и понести солидарную ответственность . Но все равно пересмотреть договоры.
В идеале было бы вообще найти контакт с бандитами, чтобы иметь возможность отслеживать ситуацию с их стороны (стейкхолдеры, как ни крути).
Дальше решаем, нужен ли нам дальше этот клиент, если да - то по наработанной схеме:
1. разъясняем, что первую "заплатку" мы ставили в соответствии с требованиями, и работы были приняты
2. дальше говорим "да, очень неприятно, что так получилось, мы с радостью Вам поможем"
3. делаем "заплатку" для банка в рамках доброй воли и готовности пойти навстречу (естественно, все делаем по правилам, со сбором требований, определением приемщика, организацией самой приемки "заплатки" и т.д.)
4. предлагаем договор на комплексное допиливание системы, "чтобы сие не повторялось впредь"
5. PROFIT!
PS: если формальная сторона "заплатки" подкачала, подсчитываем возможный ущерб, все равно выпускаем "заплатку №2", и параллельно предлагаем опять-таки договор на допиливание со скидкой размером меньше ущерба по договору. И волки сыты, и овцы целы.
Комментарий от источника задачки
2) Ни тестирование, ни ответственность за его качество на разработчиках системы интернет-банкинга не лежит. Более того: между поставкой системы и запуском ее на реальных пользователей прошел месяц.
3) Ответственный в банке доступен, но с ним все неясно, поскольку конфликт уже вышел на уровень руководства.
4) Расторгать отношения невыгодно обоим, и банку, и разработчикам. Разрабы теряют крупного клиента. Банку придётся переустанавливать систему интернет-банкинга.
Re: Комментарий от источника задачки
Думаю, в обоих случаях единственный способ -- честно описать причины возникшей ситуации и четко, обоснованно описать в чем конкретно были просчеты банковского IT. А после этого нужно разрабатывать совместный план действий.
Т.е. весь смысл наезда в том, что не прошел один платеж, но если удастся показать, что без действий исполнителя не прошел бы вообще ни один платеж, то теоретически можно попробовать повернуть ситуацию в свою сторону, если удастся выйти на того, кто над банком. Т.к. банкиры откровенно сливаются и ищут на кого спихнуть свою ответственность.
К.И.
Поскольку ни топ-менеджерам, ни владельцам банка не скажешь, как нужно по ситуации, "Сам дурак", разговаривать можно только на формальные темы.
Система принята? Принята. Вот акт (надеюсь, он есть.)
Чья подпись на акте, тот дальше за нее и отвечает.
Наши программисты предупреждали о возможных ошибках, но кем-то было принято решение не дорабатывать систему дальше и сэкономить на наших услугах.
Вот результаты экономии.
(ИТ-директор блеет, что ему никто ничего не говорил, но позиция у него слабая)
Мы готовы дорабатывать за отдельные деньги любые выявленные ошибки системы, но всегда есть риск невыявленных ошибок, и он уже относится к выбору самой системы. И это исключительно выбор и ответственность клиента (обычно это четко и однозначно прописывается в договоре).
Если руководство из-за эмоций не идет на принцип, мы получаем заказ на доработку и вопрос снимается увольнением ИТ-директора. 60%
Если идет, то увы, вопрос решается только рекомендацией других разработчиков или другой системы (Попробуйте вот это, если не хотите нас). Возможно, попробовав и поняв отсутствие разницы, клиенты вернутся, возможно нет. 40%
вообще же, защищаться, как и обычно, нужно бумажками. опись-протокол-сдал-принял. после того, как положена под нос бумага о сдаче работ с такими то оговорками (в конце концов, управленцы айтишной конторы ведь не с марса приехали, должны понимать-с где живут и с чем имеют дело) с росписью ответственного лица, можно смело разворачиваться и напомнить об оплате счета.
мне, конечно, не понятно, почему в этом уравнении отсутствует "суд" ну да ладно. но вообще я не удивлюсь, если это такой красивый спектакль.