Разработчики — важнейшая часть команды: они создают ПО, которое стимулирует рост и развитие бизнеса. Без них в лучшем случае компанию ждет застой, а в худшем — полный провал. Несмотря на это, необязательно относиться к ним как к небожителям. Однако научиться правильно общаться с разработчиками все-таки стоит.
Коммуникация с программистами будет отличаться от взаимодействия с другим персоналом, так как часто это не самые социально активные люди. Я сам был разработчиком, затем тимлидом и СТО в крупных компаниях, а сейчас руковожу собственной веб-студией YuSMP Group. За это время я хорошо понял, как эффективно и результативно общаться с теми, кто говорит на языке кода.
Если самостоятельно выстраивать этот процесс сложно или не хватает времени — возьмите на себя только принятие решений, а постановку задач доверьте профильной команде. В услугу бизнес-анализа в YuSMP Group входит перевод целей бизнеса в понятные разработчику требования и сопровождение проекта на всех этапах.
Говорите точно и предметно
Этот совет может показаться очевидным, но не все понимают, о чем говорят, когда речь заходит о продукте. Перед встречей с разработчиками разберитесь с целями, составьте план или запишите способы их достижения. Чем больше вы будете знать о предмете разговора, тем эффективнее будет общение.
Задокументируйте свои цели
Теперь, когда вы знаете, о чем говорите, важно все задокументировать. Если у вас есть хорошо сформулированный письменный документ о целях и процессах, он даст вашим разработчикам четкое представление о том, что необходимо сделать. Этот инструмент здорово облегчит работу программистам.
Обоснуйте каждое обращение
Когда вы просите разработчика сделать что-либо, расскажите, зачем нужно выполнить ту или иную задачу. Не потому, что «так надо», а потому, что этот запрос важен с точки зрения веб-сайта компании или стека приложений.
К обоснованным просьбам разработчики относятся уважительно и быстрее их выполняют.
Четко формулируйте требования
Здесь все просто: чем точнее будет описан проект или функциональность, которую хотите увидеть, тем больше вам понравится результат. Важно подробно донести до разработчиков, как выглядит готовый продукт в вашей голове (или в голове заказчика, генерального директора). Будьте конкретны и убедитесь, что под всеми характеристиками вы подразумеваете одно и то же.
Разберитесь в базовых терминах, но не пытайтесь программировать
Нетехническому заказчику не нужно учиться программировать, но полезно понимать базовые термины — так проще формулировать задачи и оценивать сроки. Когда разработчик использует непонятное слово, сразу попросите объяснить проще: большинство специалистов относятся к этому спокойно, а вот попытки самостоятельно придумать псевдотехническое объяснение чаще вызывают недоумение, чем уважение.
- Бэклог — список задач, которые ещё не сделаны, упорядоченный по приоритету.
- Деплой — момент, когда код выкатывают на сервер и он становится доступен пользователям.
- Баг — ошибка в работе продукта, а не намеренная функция.
- MVP — минимальная версия продукта с базовым набором функций для проверки идеи.
Не шутите про код, если вы его не знаете
Общаясь с разработчиками, не пытайтесь казаться крутым и показывать, что вы в теме, если это не так. Не пытайтесь использовать псевдокод (описание шагов алгоритма простым языком), когда разговариваете с программистами. В лучшем случае над вами только посмеются.
Проводите регулярные короткие созвоны
Одна из частых ошибок заказчика — либо полное отсутствие связи с командой между спринтами, либо, наоборот, звонки по любому вопросу в течение дня. Оба сценария вредят проекту. Оптимальный ритм — одна-две статус-встречи в неделю по 15–20 минут: что сделано, что в работе, какие блокеры. Остальные уточнения — в трекере задач или почте, чтобы не отвлекать разработчиков точечными звонками.
Ведите задачи в одном трекере, а не в переписке
Если требования и правки живут одновременно в почте, мессенджерах и на созвонах, часть из них неизбежно теряется. Заведите единый трекер — Jira, Trello, Notion или Youtrack — и фиксируйте там все задачи, уточнения и договорённости. Разработчику так проще: не нужно поднимать историю переписки, чтобы вспомнить, что обсуждали неделю назад. Если самостоятельно настроить процесс сложно, для этого в YuSMP Group есть готовый генератор технического задания — помогает быстро превратить пожелания в документ, понятный команде разработки.
Не «меняйте масштаб»
Вы составили план проекта, и ваши разработчики усердно над ним трудятся. Внезапно кто-то из руководства решает провести «изменение объема работ», в результате чего крайний срок проекта окажется под угрозой провала.
Если изменение объема неизбежно, лучше всего сначала провести неформальную встречу с разработчиками, чтобы предупредить о вероятных переменах. Будьте готовы вразумительно объяснить, почему происходят изменения и задокументировать новые требования.
На самом деле разработчики — такие же люди, как и все. Общайтесь с ними уважительно, посвящайте в детали и изменения в проекте. Вообще, я придерживаюсь таких принципов со всеми сотрудниками: стараюсь всегда быть корректным и по возможности постоянным в своих решениях. Считаю, что это залог отличных результатов.
Частые вопросы об общении с разработчиками
Как объяснить разработчику задачу, если сам не разбираешься в технологиях?
Не пытайтесь использовать технический жаргон, которого не понимаете — опишите результат и бизнес-цель простыми словами, а конкретное техническое решение разработчик предложит сам.
Сколько раз в неделю нужно созваниваться с командой разработки?
Для большинства проектов достаточно одной-двух коротких статус-встреч в неделю по 15-20 минут плюс общий трекер задач для остальных вопросов — ежедневные долгие созвоны отвлекают команду от работы.
Что делать, если разработчик не понимает задачу?
Попросите его своими словами пересказать задачу перед началом работы — это сразу покажет, где возникло недопонимание, и сэкономит часы переделок.
Как понять, что требования сформулированы недостаточно точно?
Если два разных разработчика могут по-разному интерпретировать одно и то же требование, значит его нужно конкретизировать: добавить примеры, ограничения и критерии готовности.
Нужно ли заказчику вести задачи в Jira или Trello самому?
Нет, обычно трекер ведёт менеджер со стороны подрядчика — заказчику достаточно заходить в общую доску, чтобы проверить статус, а не создавать задачи вручную.
Можно ли менять требования в процессе разработки?
Да, но изменения стоит фиксировать и обсуждать на плановой встрече, а не вносить на ходу через мессенджер — так команда успевает пересчитать сроки и не потерять другие задачи.
Как быстро разработчик должен отвечать на сообщения заказчика?
Разумный ориентир — в течение рабочего дня, а не мгновенно: постоянные прерывания сбивают разработчика с фокуса и в итоге увеличивают сроки всего проекта.
Нужна разработка под вашу задачу?
Обсудим проект и соберём команду — оценка за 2 дня, бесплатно.
