Когда я работал в финтех-стартапе, я был тех-лидом крупного проекта по интеграции API с одним из наших ключевых корпоративных клиентов. Проект имел жёсткий дедлайн, привязанный к концу их финансового года, и срыв обошёлся бы им в серьёзные деньги на ручную обработку данных. За три недели до запуска аудит безопасности выявил критические уязвимости в legacy-системе аутентификации клиента, которую мы не могли безопасно интегрировать.
Мне нужно было сообщить как своему инженерному менеджеру, так и VP of Technology на стороне клиента, что мы не сможем уложиться в исходный график. Это было особенно сложно, потому что клиент уже выделил ресурсы и объявил дату запуска своим стейкхолдерам. Моя задача — донести эту новость, сохранив доверие, и предложить реалистичный план дальнейших действий.
Я тщательно подготовился перед тем, как сообщить новость:
На встрече с клиентом я:
Клиент оценил прозрачность и проактивный подход. Они выбрали компромиссный вариант, который сдвинул запуск на пять недель, но позволил внедрить нормальную аутентификацию на OAuth 2.0. Я подключил двух дополнительных инженеров к проекту, и мы выпустили всё в пересмотренные сроки.
Это укрепило наши отношения — впоследствии клиент сказал моему менеджеру, что наша готовность поставить их безопасность выше нашей выручки «доказала, что мы настоящие партнёры». Проект стал эталонным примером безопасной интеграции на нашей платформе, что помогло избежать аналогичных проблем с другими клиентами.
Я понял, что эффективно доносить сложные новости можно только при наличии подготовки, эмпатии и готовых решений. Люди способны принять плохую новость, если ты честен в оценке проблем, показываешь, что понимаешь их последствия, и демонстрируешь, что уже думал о том, как двигаться дальше.
Кандидат запланировал встречи с клиентом сразу же после обнаружения уязвимостей безопасности, не согласовав это предварительно с менеджером инженерной группы.
Новый — ещё не проверен сообществом
Вы