Разработчик знает про систему то, чего нет ни в одной документации: какие есть ограничения, что хрупкое, где «здесь нельзя так». Поэтому с ним надо говорить напрямую, а не через тимлида или тикет. Ставя задачу, давайте контекст и «зачем», а не только «что сделать» — разработчик сам думает «как», и без «зачем» он не примет ни одного разумного решения на развилке. Спрашивайте «почему это сложно реализовать» — это вскрывает ограничения. «Объясни как будто мне пять» — нормальная фраза, незнание технологии — не стыд. Не спорьте ради спора, фиксируйте договорённости письменно. Антипаттерны: кинуть тикет через стену и требовать оценку без контекста — оба разрушают доверие, на котором держится вся работа.
В начале карьеры я считал, что моя работа — написать идеальное ТЗ и отдать его разработчику, а дальше не моё дело. ТЗ были аккуратные. И всё равно регулярно всплывало «так не получится». Получалось всегда одно и то же: я проектировал в вакууме, а разработчик знал про систему такое, чего не было ни в одном документе — что вот этот сервис нельзя дёргать чаще раза в секунду, что вот это поле на самом деле не заполняется, что «просто добавить статус» — это миграция на миллион строк. Эту информацию нельзя вычитать. Её можно только спросить у человека.
Разговор с разработчиком — это не побочная часть работы аналитика, а её сердцевина. Аналитик сидит в центре команды переводчиком между мирами (про сами роли — в записи кто все эти люди в IT-команде), и качество перевода зависит от того, насколько хорошо вы умеете разговаривать с теми, кто реализует.
Почему говорить напрямую
Информация о реальных ограничениях системы живёт в головах разработчиков, а не в документации. Документация описывает, как должно быть; разработчик знает, как есть на самом деле — со всеми костылями, хрупкими местами и «исторически сложилось». Эта разница и есть самое ценное, что вы можете узнать.
Когда вы общаетесь через посредника — тимлида, проджекта, тикет, — вы получаете эту информацию через испорченный телефон, если получаете вообще. Тимлид перескажет общими словами. Тикет вернётся с комментарием «непонятно». А пять минут прямого разговора у доски вскрывают ограничение, которое иначе всплыло бы через две недели в виде «так не получится».
Прямой разговор — это не «через голову»
Иногда боятся, что общаться с разработчиком напрямую — значит лезть мимо тимлида и нарушать иерархию. Это не так. Прямой рабочий разговор по задаче — норма, а не нарушение субординации. Тимлида подключают, когда вопрос про приоритеты, сроки или спорное решение, — а уточнить ограничение или показать черновик можно и нужно напрямую с тем, кто будет это делать.
Как ставить задачу: контекст и «зачем», а не только «что»
Главная ошибка постановки — отдать разработчику только «что сделать», без «зачем». Разработчик — не исполнитель чужих инструкций, он сам решает «как»: какой подход выбрать, где срезать, где заложить запас. И каждое такое решение он принимает, опираясь на цель. Нет цели — он либо угадывает, либо делает буквально, и оба варианта часто мимо.
Сравните две постановки одной задачи:
Только «что»:
Добавить кнопку «Скачать отчёт» на странице заказов.
С контекстом и «зачем»:
Бухгалтерия раз в месяц вручную сводит заказы в Excel — уходит день.
Хотим, чтобы они выгружали готовый отчёт сами.
Поэтому: кнопка «Скачать отчёт» на странице заказов, выгрузка в Excel,
поля — те же, что они сводят руками (список ниже).Во втором случае разработчик понимает цель — и может предложить лучше, чем вы придумали: «а давайте не кнопку, а автоматическую отправку на почту раз в месяц, раз это для бухгалтерии». Без «зачем» он бы молча сделал кнопку, даже если кнопка — не лучшее решение. Контекст превращает исполнителя в соавтора, а соавтор ловит дыры, которые вы не заметили.
Вопрос «почему это сложно» работает в обе стороны
Когда разработчик говорит «это сложно» — не верьте и не спорьте, спрашивайте «почему сложно?». Часто за этим стоит ограничение, которое меняет требование: «потому что этот сервис не отдаёт историю старше года». Отлично — значит, требование «показать все заказы» физически невыполнимо, и хорошо, что узнали сейчас. Тот же вопрос аналитик задаёт и вверх — продакту «почему мы это делаем?». Вниз — «почему это сложно?», вверх — «зачем это нужно?». Между этими двумя вопросами и живёт ваша работа.
«Объясни как будто мне пять» — это нормально
Аналитик не обязан знать технологию глубже разработчика — это его, разработчика, профессия. Стыдно не «не знать, что такое идемпотентность», стыдно сделать вид, что знаешь, и спроектировать дыру. Поэтому фраза «объясни, пожалуйста, как будто мне пять» — рабочий инструмент, а не признание слабости.
Более того, она часто помогает самому разработчику: объясняя на пальцах, он сам замечает, что в его решении не сходится. А вы получаете понимание, на котором можно строить требования, а не пересказ, в котором половина слов — заклинания. Лучше десять «глупых» вопросов на старте, чем одно неправильное требование, по которому две недели делали не то.
Не спорить ради спора, фиксировать письменно
Две привычки, которые отличают разговор, двигающий дело, от разговора, который его топит.
Не спорьте ради спора. Цель разговора — найти хорошее решение, а не победить. Если разработчик прав — соглашайтесь сразу, без «но я всё же считаю». Если не уверены — задавайте вопросы, а не возражайте. Аналитик, который спорит, чтобы настоять на своём, быстро перестаёт получать ту самую ценную информацию об ограничениях: с ним просто перестают делиться.
Фиксируйте договорённости письменно. Устная договорённость живёт до первого «а я думал, мы решили иначе». После разговора — короткое резюме в тикет или чат: «договорились: отчёт выгружаем в Excel, поля такие-то, историю старше года не показываем, потому что сервис её не отдаёт». Это не бюрократия — это защита и ваша, и разработчика: через месяц никто не вспомнит, о чём именно договорились, а запись вспомнит. Про то, как фиксировать решения системно, — в записи как написать ТЗ.
Антипаттерны: как сломать доверие
Вся работа с разработчиком держится на доверии — на готовности делиться неудобной правдой о системе. Две привычки убивают его быстрее всего.
Тикет через стену
«Кинуть тикет через стену» — это отдать задачу без контекста, без обсуждения, без готовности отвечать на вопросы, и исчезнуть. Разработчик остаётся один на один с формулировкой, которую некому уточнить, и либо угадывает, либо делает буквально. Так аналитик из соавтора превращается в генератор тикетов, а команда — в конвейер по производству «не того». Задача — не документ, который вы перебросили, а разговор, который вы ведёте.
Требовать оценку без контекста
«Сколько времени займёт?» — на задачу, которую разработчик видит впервые и в которой половина деталей не определена, — это требование угадать. Любая названная цифра будет враньём, и потом этим враньём будут бить по команде («вы же сказали два дня»). Хотите оценку — дайте контекст, дайте время разобраться и спросите вместе с «что неясно?». Оценка — это результат понимания задачи, а не первое слово в разговоре о ней.
Откуда это взялось
Идея, что прямое человеческое взаимодействие важнее формальных процессов и документов, — прямо из Agile-манифеста 2001 года. Один из его четырёх тезисов звучит как «люди и взаимодействие важнее процессов и инструментов». До этого господствовал водопадный подход: аналитик пишет толстое ТЗ, передаёт «через стену» разработке, и живого диалога между этапами почти нет — отсюда и сам образ «стены», через которую перекидывают задачи. Agile эту стену осознанно ломал: вместо толстого документа — короткая история и постоянный разговор. Поэтому умение говорить с разработчиком напрямую — не софт-скилл «для общения», а методологический принцип: так задумано, что аналитик и разработчик договариваются вживую, а не обмениваются бумагами.
Частые вопросы
Как аналитику общаться с разработчиками?
Говорите напрямую, а не через тикет или тимлида — так вы узнаёте реальные ограничения системы, которых нет в документации. Ставя задачу, давайте контекст и «зачем», а не только «что»: разработчик сам решает «как» и без цели не примет разумных решений. Спрашивайте «почему это сложно реализовать», не стесняйтесь просить «объясни как будто мне пять», не спорьте ради спора и фиксируйте договорённости письменно. Не кидайте тикеты через стену и не требуйте оценку без контекста.
Почему нельзя просто отдать разработчику тикет с задачей?
Потому что тикет без контекста и обсуждения — это «через стену»: разработчик остаётся один на один с формулировкой, которую некому уточнить, и либо угадывает намерение, либо делает буквально — и часто мимо. Задача для аналитика — это не переброшенный документ, а разговор, который он ведёт: даёт «зачем», отвечает на вопросы, ловит ограничения. Без диалога теряется ровно та информация о системе, ради которой и стоит общаться с разработчиком.
Стыдно ли аналитику не знать технологию и переспрашивать?
Нет. Аналитик не обязан разбираться в технологии глубже разработчика — это профессия разработчика. Стыдно не переспросить, а сделать вид, что понял, и спроектировать дыру. Фраза «объясни, как будто мне пять» — рабочий инструмент: она даёт вам понимание для требований, а разработчику, объясняющему на пальцах, нередко помогает самому заметить нестыковку в решении.