На прошлой неделе я заказала разработку нашего нового проекта у команды разработчиков. И началось... Бесконечные вопросы, уточнения, согласования и тому подобное. В таком формате заниматься собственными задачами становится практически невозможно. Приходится постоянно переключаться, разбираться, что от тебя хотят, вспоминать, что ты сам вообще хотел сделать, потому что ТЗ было написано 3 месяца назад и ты уже не помнишь, что и почему ты там написал.
Я много писала последнее время про описание задач,
что это дает,
почему это сложно, как этому научиться и какие преимущества можно получить. И могу добавить, что оно также уменьшает количество вопросов разработчиков к вам уже в процессе выполнения задачи. Но почему же я сама погрязла в уйме вопросов от разработчиков, если знаю, как хорошо описывать задачи? Потому что в случае вопросов разработчиков одного хорошего описания недостаточно.
Я уже говорила, что разработка иначе смотрит на систему, потому что у нее другой набор знаний, более глубокий в технической области. И даже разработчики из другой сферы не смогут предсказать многие проблемы во время разработки в незнакомой им среде. И даже в чужом проекте на тех же технологиях. Везде есть своя специфика. Разработчик, смотря на задачу, видит вопросы более глубокие, касающиеся реализации и технических нюансов разработки. Этой информации просто не может быть в изначальном описании задачи. Автор просто не знает таких нюансов. Так что же получается, невозможно избавиться от постоянных, бесконтрольных вопросов во время разработки?
Здесь вам на помощь приходят процессы. Не просто так в большинстве компаний есть регулярные встречи по уточнению бэклога и оценке. Именно они помогают бизнесу дополнить описания задач с участием разработки, чтобы заранее, в специально отведенное для этого время, решить все вопросы разработки и доработать задачи с учетом этих вопросов. Как проводить такие встречи мы подробно разбираем в нашей книге по построению процессов работы команды
"Гибкие методологии на практике". Научившись правильно работать по этим процессам, вы освободите свое время и до минимума сократите количество потока бесконечных вопросов от команды.
Итак, я получила кучу вопросов от разработчиков по моему ТЗ. И хочу поделиться с вами самым большим моим провалом среди этих вопросов. Как пример того, что все продумать невозможно и ошибки все рано будут случаться. Главное их видеть и думать, как избежать их в будущем.
Приложение с прохождением чего-то вроде опросника, где динамически меняются вопросы в зависимости от ответов пользователя. Дизайнер нарисовал внизу классическую нумерацию шагов "шаг 3/6", мне показалось это логичным, поэтому я внесла это в ТЗ. Во время разработки мне пишет менеджер с просьбой внести в АПИ количество вопросов в каждом опроснике. Я начинаю объяснять, что количество вопросов динамическое и зависит от ответов пользователя. На что он мне присылает этот скриншот с комментарием, что посчитать финальное количество шагов в динамическом опросе невозможно.
Лучше всего конечно такие нюансы всплывают во время разработки, когда ты уже в контексте и думаешь, как именно будет реализована задача. С другой стороны дизайн уже отрисован и изменения приходится вносить буквально на ходу. И не всегда это получается делать гладко и без доработок. Поэтому такие ошибки иногда могут встать поперек горла. Поэтому стоит учиться
описывать задачи как можно точнее.
А какие у вас были недочеты в описании задач? Забывали что-нибудь критичное? Или вам приходил запрос сделать что-то невозможное? Делитесь в комментариях.х вопросов от команды.