?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Задачка-водокачка № 15
psilonsk
И снова с нами наша любимая рубрика "Задачки-водокачки" - реальные управленческие задачи, которые возникают в реальных рабочих ситуациях. Сегодняшняя задача прилетела от одного давнего читателя моего блога.

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

В этом банке, как и во всяком современном банке, все работает до тех пор, пока работают банковские IT-системы. Одну из этих систем создавали специалисты банка. По каким-то причинам система получилась далекой от совершенства, и в какой-то момент количество глюков в ней стало мешать работе банка (проблема была в базе данных, над которой, собственно, банковские программисты и трудились).

К решению проблемы привлекли разработчиков-аутсорсеров - компанию, которой вы руководите. Разработчики сделали "заплатку", которая решала основные проблемы. С этими проблемами база не работала вообще.
К сожалению, эта "заплатка" породила новые проблемы, возникающие лишь при определенных условиях. Например, платежи, в которых в коде ИНН есть ведущий ноль, вообще не отправлялись банком.

Как ваша компания попала в проект банка? Вы продавали ему программу для интернет-банкинга, которая работает с той самой БД. "Заплатка", которую сделали ваши специалисты, позволяла программе работать с базой, невзирая на ошибки.
При этом ваши сотрудники, по их словам, ставили в известность представителей банка о проблемах с БД, но банк не отреагировал.

Из-за того, что платеж не прошел, у банка возник конфликт с крупным корпоративным клиентом. Поскольку клиент тесно связан с криминальным миром, на банк "конкретно наехали" и заявили, что он должен выплатить неустойку за непереведенный вовремя платеж.
Руководство банка в гневе и ярости, директор банка по ИТ срочно ушел в отпуск. Банкиры спустили претензию вашим разработчикам: это же из-за их "заплатки" возникла проблема с клиентом, пусть они разбираются и расплачиваются.

Еще вчера вы чувствовали себя уверенным и опытным руководителем ИТ-компании, а сегодня вздрагиваете, когда у кого в мобильнике играет мелодия из "Крестного отца". )) Исправить ошибку и выпустить новую "заплатку", конечно, можно, но никто не застрахован от появления столь же критичных ошибок (и разъяренных клиентов) в будущем.

Итак, ваши действия по урегулированию конфликта?


Комментарии к этой задачке открыты. Ответы принимаются до пятницы. Если нужны дополнительные данные, то спрашивайте в комментах, читатель постарается через меня ответить на вопросы.


promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

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

1. прекратить врать
2. прикрыть зад - заплатку вы же не сами принимали решение ставить, а IT-служба банка, после каких-то проверок и под какой-то документ - перевести вопрос на то, что процессы изменений продуктивного ПО в банке также должны быть как-то отрегулированы и проводиться не формально
3. определиться кто владеет кодом СУБД - уже вы или всё ещё программисты банка, если второе - научиться плотнее с ними сотрудничать
4. изготовить ещё одну заплатку, вместе со специалистами банка принять патч под честной процедурой приёмки
5. на предупреждение проблем в будущем навесить на АБС мониторинг по слежению за неисполненными или искаженными документами - сделать это для банка в рамках доброй воли

Традиционно российский способ (применять при изготовлении первой заплатки):
под подпись в письменном виде уведомить заказчика об особенностях заплатки. Получить принципиальное согласие руководителя заказчика (тоже письменно). Аргументировать тем, что или вот так, или никак. Если заказчик говорит: "Никак", значит никак. Т.е. никаких "банк не отреагировал" не принимаем. Реакция должна быть задокументирована.

Если этого не было сделано, то тут сложнее. Урегулируем конфликт, чтобы нам как аутсорсинговой конторе выйти из проблемы сухими и разорвать отношения с банком? Или с банком отношения нужно сохранить?




Edited at 2013-11-19 01:28 pm (UTC)

почему "чисто российский"?

Я не говорила "Чисто"))). "Традиционно" значит часто используемый у нас. (чисто - это если только у нас, но это же не только наш прикол). У британцев научилась культуре переписки по проекту. Что нужно ставить в копию всех заинтересованных лиц. Письменное подтверждение действий очень помогает против конфликтов. Просто когда один человек говорит другому, то может что-то не так быть понято или интерпретировано. Поэтому нужно все писать.

я собственно к тому же, ага, что это дело универсальное :)

Совет к текущей ситуации уже малоприменим. ) А так да.

Про текущую ситуацию: для айти конторы выйти из ситуации без проблем (при этом можно разорвать отношения с банком) или задача и с банком отношения не разорвать?

Я думаю, надо максимально хорошо выйти из ситуации. Если можно не терять клиента - то это большой плюс.

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

А в худшем случае можете просчитать ситуацию? )

Я бы проконсультировался с юристами, насколько правомерный этот прессинг. Если это тупо наезд, слал бы на хуй. Если есть к чему придраться, смотрел бы по ситуации, подстраховывался. Судя по описанию, бумажка с уведомлением о проблеме у меня есть.
У меня была похожая ситуация, новые арендодатели пытались выгнать из офиса, не продлять аредну. Удалось разрулить переговорами, даже цену не подняли, как сразу пугали.
В нашем мире корпорации действуют по беспределу, единственный выход по мне - вести себя максимально честно и открыто.

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

Для этого проанализируем наши вводные:
1) Что прописано в вашем договоре с клиентом? Лежит ли на банке ответственность за тестирование? Лежит ли на вас ответственность за убытки банка вызванные сбоем в системе? Каков максимальный размер этой ответственности? (не говорю, что срочно нужно идти в суд, но договор - хорошее начало для продуктивной логической беседы).
2) Кто в банке отвечал за постановку задачи и приемку результата? Доступен ли этот человек? Принимает ли он на себя ответственность за плохое тестирование?
3) Каково соотношение убытка от проблемы и прибыли которую получает ваша компания от этого клиента (например, за год)?
4) Насколько важен этот клиент для вашей компании? Можете ли вы позволить себе потерять его без существенных долгосрочных последствий?
5) Насколько вы важны для вашего клиента? Легко ли ему будет заменить вас, если вы откажетесь с ним работать?

Ответив на эти вопросы можно начать выстраивать стратегию переговоров.

Наверняка, если бы я продавал банковское ПО, я бы обязательно содержал юриста.
1. Действовать в рамках договора. Но есть риск потерять клиента.
2. Возможно проявить гибкость и понести солидарную ответственность . Но все равно пересмотреть договоры.

Для начала, нужно проверить всю формальную сторону пред.договора с банком на "заплатку", т.к. бандиты на нас "наезжать" 100% не будут, это не их тема, тем более им куда интереснее получить "компенсацию" с банка, чем с какой-то там ИТ-конторы. Соответственно, если формальная сторона чистая, можно перестать бояться мелодии из "Крестного отца", мы тут рискуем только потерять клиента.
В идеале было бы вообще найти контакт с бандитами, чтобы иметь возможность отслеживать ситуацию с их стороны (стейкхолдеры, как ни крути).
Дальше решаем, нужен ли нам дальше этот клиент, если да - то по наработанной схеме:
1. разъясняем, что первую "заплатку" мы ставили в соответствии с требованиями, и работы были приняты
2. дальше говорим "да, очень неприятно, что так получилось, мы с радостью Вам поможем"
3. делаем "заплатку" для банка в рамках доброй воли и готовности пойти навстречу (естественно, все делаем по правилам, со сбором требований, определением приемщика, организацией самой приемки "заплатки" и т.д.)
4. предлагаем договор на комплексное допиливание системы, "чтобы сие не повторялось впредь"
5. PROFIT!

PS: если формальная сторона "заплатки" подкачала, подсчитываем возможный ущерб, все равно выпускаем "заплатку №2", и параллельно предлагаем опять-таки договор на допиливание со скидкой размером меньше ущерба по договору. И волки сыты, и овцы целы.

Комментарий от источника задачки

1) Качество патча и возможные глюки после его установки не оговаривались. На тот момент банк не работал вообще, и им надо было хоть как-то его запустить, любой ценой.
2) Ни тестирование, ни ответственность за его качество на разработчиках системы интернет-банкинга не лежит. Более того: между поставкой системы и запуском ее на реальных пользователей прошел месяц.
3) Ответственный в банке доступен, но с ним все неясно, поскольку конфликт уже вышел на уровень руководства.
4) Расторгать отношения невыгодно обоим, и банку, и разработчикам. Разрабы теряют крупного клиента. Банку придётся переустанавливать систему интернет-банкинга.

Re: Комментарий от источника задачки

Истерика банка вполне понятна, но, скорее всего, либо руководство не понимает что происходит, либо намеренно истерит, чтобы сделать хорошую мину при плохой игре.
Думаю, в обоих случаях единственный способ -- честно описать причины возникшей ситуации и четко, обоснованно описать в чем конкретно были просчеты банковского IT. А после этого нужно разрабатывать совместный план действий.

Много тут сказали про сбор аргументов. Соглашусь. А еще хочу добавить, что раз разработка самой заплатки никак оформлялась, то может есть зацепки за ситуацию, когда только возникла необходимость в заплатке? Работа банка ведь стояла, а значит наверняка руководство банка ходило на ушах и возможно были какие-то факсы от них с криками "спасите" или благодарностями по результату в адрес исполнителя?
Т.е. весь смысл наезда в том, что не прошел один платеж, но если удастся показать, что без действий исполнителя не прошел бы вообще ни один платеж, то теоретически можно попробовать повернуть ситуацию в свою сторону, если удастся выйти на того, кто над банком. Т.к. банкиры откровенно сливаются и ищут на кого спихнуть свою ответственность.

К.И.

Ох уж эти анонимные комментаторы... )))

По-моему, основные проблемы тут из-за эмоций и выхода конфликта на верхний уровень.

Поскольку ни топ-менеджерам, ни владельцам банка не скажешь, как нужно по ситуации, "Сам дурак", разговаривать можно только на формальные темы.

Система принята? Принята. Вот акт (надеюсь, он есть.)
Чья подпись на акте, тот дальше за нее и отвечает.

Наши программисты предупреждали о возможных ошибках, но кем-то было принято решение не дорабатывать систему дальше и сэкономить на наших услугах.
Вот результаты экономии.
(ИТ-директор блеет, что ему никто ничего не говорил, но позиция у него слабая)

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

Если руководство из-за эмоций не идет на принцип, мы получаем заказ на доработку и вопрос снимается увольнением ИТ-директора. 60%
Если идет, то увы, вопрос решается только рекомендацией других разработчиков или другой системы (Попробуйте вот это, если не хотите нас). Возможно, попробовав и поняв отсутствие разницы, клиенты вернутся, возможно нет. 40%


Люди же, куда ж без эмоций...

В похожей ситуации помогло выйти напрямую на пострадавшую братву и по понятиям побазарить за правых, виноватых и вообще за жизнь. После базара братва повторно наехала на стрелочника с конкретным предложением оплатить издержки. Но вот может ли аутсорсер побазарить по понятиям с братвой, имеющей возможность конкретно наехать на банк - очень сомневаюсь :)

Вот не знаю... Ну их, этих ребят, общаться еще с ними...

не очень понятно, зачем сохранять хорошие отношения с подобной организацией? чего ради? еще одного истеричного проекта?
вообще же, защищаться, как и обычно, нужно бумажками. опись-протокол-сдал-принял. после того, как положена под нос бумага о сдаче работ с такими то оговорками (в конце концов, управленцы айтишной конторы ведь не с марса приехали, должны понимать-с где живут и с чем имеют дело) с росписью ответственного лица, можно смело разворачиваться и напомнить об оплате счета.
мне, конечно, не понятно, почему в этом уравнении отсутствует "суд" ну да ладно. но вообще я не удивлюсь, если это такой красивый спектакль.

Я за сохранение отношений до последнего... В Мухосранске другого клиента может и не быть. )

  • 1