Представьте себе, что вы работаете над важным проектом, где нужно внедрить новую функцию – например, динамическую пользовательскую панель с обновлениями в реальном времени. Разработчик уверенно заявляет: «Я уже ознакомился с требованиями. Это должно быть несложно, на все уйдет день-два». Кажется, все идет отлично, пока не приходит день, когда функция должна была бы быть готова, а вместо этого вы слышите: «Оказалось, что есть проблемы с API, и нужны изменения в архитектуре кода».
Теперь проект задерживается на целую неделю, а вы начинаете сомневаться, действительно ли разработчик понимал всю сложность задачи с самого начала или просто не подумал и теперь вы «получаете на орехи» от клиента.
Такие ситуации часто возникают, когда заранее не задаются правильные вопросы. Дело не в том, что разработчик врет или относится к проекту невнимательно. Просто каждый из нас погружен в свои контексты и поэтому видит мир с определенного угла.
Чтобы вы научились переводить с разработчицкого на понятный и отслеживать потенциально проблемные ситуации мы подготовили 4 истории в которых произошел факап и список вопросов, которые могли бы этого не допустить.
Как внедрение новой функции может превратиться из легкой задачи в проблему
Что говорит разработчик
«Я ознакомился с требованиями для новой функции пользовательской панели, которая включает динамический интерфейс с обновлениями в реальном времени, используя React и Redux. Согласно моему опыту, это должно быть довольно просто. Обработка данных через REST API кажется управляемой, и я хорошо знаком с необходимыми паттернами управления состоянием. Я думаю, что внедрение займет один-два дня, если не возникнет неожиданных проблем с API или сериализацией данных.»
Факап
Позже разработчик сталкивается с проблемами совместимости и производительности, что затягивает процесс на неделю. Заказчик начинает сомневаться, действительно ли разработчик учел все возможные сложности.
Как можно было это предотвратить
Список вопросов, которые помогают избежать таких факапов:
- Какие конкретно шаги ты планируешь предпринять для внедрения этой функции? С какими сложностями мы можем столкнуться на каждом шаге?
- Проверил ли ты документацию API и совместимость с нашим текущим стеком технологий? Какие нюансы следует учесть?
- Планируешь ли тестирование после интеграции?
Что будет, если совместить «ежа с ужом»
Что говорит разработчик
«Я сделал предварительную проверку нашей инфраструктуры в AWS, включая существующие EC2, конфигурации VPC и группы безопасности, и уверен, что мы можем интегрировать новый платежный шлюз без значительных изменений. Наш бэкэнд на Node.js должен поддерживать необходимые API вызовы. Возможно, придется немного настроить роли IAM, но серьезных проблем я не предвижу. В общем, это должна быть гладкая интеграция.»
Факап
После начала интеграции оказывается, что шлюз использует другие протоколы, требующие дополнительных ресурсов и зависимостей. Заказчик начинает сомневаться, действительно ли разработчик проверил все требования совместимости.
Как можно было это предотвратить
Еще в первом разговоре с разработчиком стоит задать несколько вопросов:
- Проводил ли ты полную проверку совместимости инфраструктуры клиента с новым платежным шлюзом? Какие именно проверки ты делал?
- Мог бы ты подробнее объяснить, какие обновления или изменения могут быть необходимы в инфраструктуре клиента?
- Есть ли у тебя опыт интеграции подобных сервисов?
А чтобы решить проблему недопонимания и стать «своим» для разработчиков, приходите на курс Techmind. Прокачайте техническую экспертизу, чтобы делать реалистичные оценки сроков и стоимости, а также деливерить проекты при любых условиях.
За 2 месяца вы овладеете терминологией SDLC, техниками работы с Jira, навыками написания проектной документации, и научитесь общаться с программистами на одном языке.
Не только на разработке можно обанкротиться
Что говорит разработчик
«Я проверил несколько вариантов для отправки уведомлений пользователям, включая Twilio для SMS и Firebase для push-нотификаций. Twilio кажется подходящим, потому что он широко поддерживается и, насколько я понял, стоимость незначительна на нашем уровне использования. Предлагаю начать с SMS, а если будет необходимость, со временем можем переключиться на push-нотификации.»
Факап
Через неделю клиент получает значительный счет из-за большего объема использования SMS. Заказчик чувствует, что разработчик мог не до конца изучить ценовую политику.
Как можно было это предотвратить
На самом деле, чтобы избежать такой ситуации достаточно всего одного-двух вопросов:
- А можно расчет стоимости каждого из предложенных сервисов с учетом ожидаемых объемов использования? Учтено ли использование для всех регионов?
- А бесплатные решения есть?
Все четко и понятно, пока не начинаешь работать
Что говорит разработчик
«Я просмотрел документацию API от поставщика, и на первый взгляд она кажется довольно стандартной. Выглядит так, что мы сможем мапировать большинство объектов ответа к нашим существующим моделям данных. Я думаю, что интеграция должна быть завершена до конца недели, если API будет работать так, как ожидается.»
Факап
Во время интеграции возникают многочисленные проблемы, такие как лимиты скорости и неожиданные форматы ответов. Заказчик начинает сомневаться, действительно ли разработчик внимательно прочитал документацию.
Как можно было это предотвратить
Здесь вообще все просто – перед тем как перейти к работе не ленитесь и задайте разработчику несколько вопросов по документации. Например: «Есть ли в документации ограничения, которые могут повлиять на нашу интеграцию?» Если документация не была изучена, вы сразу это увидите.
Общение с разработчиками может быть непростым, особенно если вы не знаете, какие вопросы задавать и как обеспечить прозрачность в работе. Но помните, что эффективное сотрудничество строится на взаимном доверии, четкости и деталях. Не надо думать, что все вокруг врут, помните, чаще всего каждый человек хочет выполнить свою работу хорошо. Проблема в том, что все мы – люди и поэтому задача менеджера – предугадывать ситуации, когда невнимательность приводит к настоящим проблемам. Чтобы делать это эффективно – учитесь разговаривать с разработчиком на одном языке.