«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов. Как это сделать, рассказывает руководитель проектного офиса “CleverPumpkin” Лада Ларкина. В данной статье описывается опыт с упором на специфику работы компании именно в нашей сфере – мы занимаемся разработкой мобильных приложений на заказ, но при этом у нас есть несколько собственных продуктов в виде приложений. Если вы не увидите тут идеальных лично для вас процессов, то не переживайте, это вполне нормально, но в любом случае мы считаем, что описанное в той или иной мере может быть применимо в разных областях создания программного обеспечения. Главное: вы сами должны четко представлять ожидаемый от разработчика результат — без этого не получится правильно описать задачи. Отнеситесь к сбору информации ответственно: до того, как задача попадет к разработчику, вы должны сами полностью понять бизнес- и функциональные требования.Главное требование к задаче – прочитавший её разработчик должен сразу понять, что ему нужно делать, и это представление должно совпадать с ожиданиями менеджера. А после прочтения идеально описанной задачи у разработчика появляется четкое представление, как он будет ее выполнять. Проанализируйте, как задача может быть декомпозирована. Разделить большую задачу нужно так, чтобы между задачами не было пересечений и они логично дополняли друг друга. Возможно, декомпозированную задачу предстоит выполнять разным разработчикам, и важно, чтобы они не делали двойную работу, минимально пересекались и по итогам реализации было минимум конфликтов.Если в прогрессе декомпозиции появилось несколько задач, которые нельзя делать последовательно — значит, вы перестарались. Разделять задачу нужно, если ее части можно делать одну за другой.Но базовое правило для декомпозиции — длительность работы над одной задачей не должна быть больше одного дня. В редких случаях — больше, например, если это сложная интеграция, которую не разбить на несколько шагов. Хотя и тут речь может идти о подзадачах не функциональных, а технических. В названии нужно коротко сформулировать суть задачи, чтобы ее было легко найти в таск-трекере. Мы рекомендуем использовать такую логику для названия: Разберем каждую часть названия:  — это может быть версия платформы, MacOS/iPad фичи;  — описывает, в каком разделе добавляется функциональность;  — указывает конкретный блок на экране, если изменения касаются его;  — суть изменения или фичи; Примеры хороших названий: «Подключить Firebase Performance» «Профиль (авторизованный) — добавить пункт история заказов» «История заказов — реализовать загрузку и отображение списка заказов» «Заказ из истории — Блок итого — Добавить строку дополнительных услуг» «[iPad] История заказов — Реализовать просмотр конкретного заказа в split view режиме» «[iOS 13+] Настройки — Добавить пункт «Siri shortcuts» Примеры неудачных названий: «Подключить экран к API» — (какой раздел, экран?) «Цветовая индикация» — (ее нужно добавить? изменить? где находится?) Описание должно быть необходимым и достаточным. Необходимым — не должно быть пересечений между задачами в описании. Разработчик должен понимать, какую именно часть задачи ему сейчас реализовывать.  Достаточным — у разработчика не только не должно появиться дополнительных вопросов, но и возможности понять что-то не так. Избегайте двусмысленности в задачах. Текст задачи должен понять любой новый разработчик на проекте. Нужно осознавать, что разработчики хуже понимают контекст проекта, чем менеджеры, вряд ли присутствовали при формировании ТЗ, разработки дизайна и т.д., а впервые видят описание необходимого обновления. Полезно написать, зачем вообще добавляется эта фича и почему она нужна пользователю - тогда у разработчика появятся понимание, что он делает, и, возможно, предложения для улучшения пользовательского опыта. Не забудьте описать: как попасть в раздел, в который вносится доработка, если это не очевидно; что необходимо сделать с учетом специальных обработок для крайних кейсов, если таковые есть; указать, было ли ранее в приложении реализована схожая функциональность для переиспользования; указать, планируется ли в будущем переиспользование, что нужно предусмотреть для этого; что требуется для реализации — макеты, ключи доступа, инвайты и т.д.; указать, какие данные используются, откуда они получаются, как обрабатываются. Если данные получаются при каком-то условии, то его надо обязательно указать; какие запросы будут дергаться; как будет использоваться результат задачи, в том числе, как его сохранить и передать для другой задачи; есть ли задачи, которые следует связать с текущей; надо ли добавить аналитику по этой функции. Описание должно учитывать платформенные особенности, не допустите ошибочных расхождений в одинаковой функциональности. Структурируйте и будьте аккуратны. Разделяйте задачу на логические блоки, чтобы удобно было читать и находить информацию. Для начального заполнения задачи пользуйтесь шаблоном (например, YouTrack, который мы используем в работе, автоматически добавляет формат базовой задачи с местом для верстки, логики и сразу с базовым чек-листом, всем советуем, очень удобно).  Не допустите пересечения параллельных задач между разработчиками. Так вы получите увеличение трудозатрат на разрешение конфликтов и дублирование.  Ставьте задачи на любые изменения. Без этого вы не сможете доказать разработчику, что он сделал что-то не так. Устные договоренности ничего не значат! Без задачи изменения не будут протестированы тестировщиком. Кроме того, часто поставленные задачи служат единственным источником информации о поведении приложения. Отсутствие задачи в начале — недостаток информации потом. Связь задач между платформами. Обязательно свяжите задачи про одинаковые фичи между двумя платформами в системе постановки задач. Так проще поддерживать актуальность описаний задач при изменениях на обеих платформах, догоняющий разработчик сможет узнать, кто делал задачу на другой платформе, и прочитать обсуждение. Визуализация для задачи. Иногда схема, диаграмма или картинка опишет разработчику что-то понятнее, чем сложный текст — или хотя бы поможет быстрее разобраться в задаче.  Чек-листы нужны для самопроверки разработчика. При первой реализации они помогают учесть больше кейсов. Всегда проверяйте: наиболее старую поддерживаемую версию платформы — она же обычно и самая проблемная; работу на маленьком девайсе; темную тему; Кроме того, в зависимости от задачи чек-лист может дополняться следующими пунктами: крайние кейсы для проверки; пустые состояния; состояния ошибок; подгрузка данных (если она постраничная); обновление данных (PTR); большие/маленькие данные; заглушки для текстов/картинок; горизонтальная ориентация. При проверках по чек-листу у разработчика не должно возникать вопросов «как это должно работать в таком кейсе?» — это должно быть описано в тексте задачи.В процессе планирования менеджер должен убедиться, что чек-лист дополнен тестировщиком. Если на первой платформе после тестирования появляются ошибки на не включенные в чек-листы моменты, то в задаче на второй тестировщик также должен дополнить описание и чек-листы. Следите за эстимейтом, поставленным разработчиком. Если он отличается от ваших ожиданий (и от original estimate), то важно понять почему. Возможно, не так воспринято описание задачи, возможно, что-то недооценивается или, наоборот, усложняется. Разработчик может не учесть переиспользование, а может, вы забыли об этом написать в задаче.Если в изначальной оценке было что-то пропущено, то необходимо обсудить и, возможно, согласовать изменения функциональных требований с руководителем проекта и заказчиком. Итак, зафиксируем пройденный материал: Получите все необходимые требования. Убедитесь, что сами понимаете, что требуется реализовать. Подберите правильное название задачи. В самом начале описания задачи поясните разработчику ценность изменения. Добавьте путь до изменяемого экрана, если это не очевидно. Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса. Добавьте дополнительные ссылки на артефакты, которые требуются для выполнения задачи. Если предполагается переиспользование для реализации, явно укажите это. Укажите, если в будущем будет переиспользоваться, масштабироваться или меняться результат задачи. Если необходимо сохранение данных для будущего использования, укажите. Опишите функционально задачу и убедитесь в отсутствии пробелов в логике. Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим, опциональность; не описывать неиспользуемые поля и указать, что их не парсим). Укажите, если данные получаются при каком-то условии — например, касаются только авторизованных пользователей, специальных заказов или аккаунтов и т.д. Укажите прошлые локальные данные, если они используются. Пропишите логику загрузки данных: есть ли постраничная подгрузка, активити и т.д. Укажите логику для пустых данных. Опишите разные форматы отображения для разных региональных параметров, форматов дат и т.д. Пропишите логику для обработки специальных ошибок. Если требуются какие-то ключи, то добавьте их для каждого типа сборки – QA/RC/Release. Убедитесь, что разработчики имеют доступ ко всем необходимым артефактам или сервисам. Добавьте аналитику по данной функции (возможно в другой задаче – подумайте и не забудьте). Дополните базовый чек-лист. Свяжите с задачей для другой платформы и другими задачами, если есть такая зависимость. Перечитайте всю задачу от начала до конца! Важно приучить себя мысленно продумывать все эти шаги, чтобы потом на автомате учитывать все потребности и возможности для облегчения разработки. Хорошо описанная задача экономит время всем: будет меньше вопросов, ускорится тестирование и т.д.  Эти задачи описаны достаточно полно, не вызвали вопросов у разработчиков. Пример 1. Описание задачи хорошо тем, что указана ценность реализации для пользователя, есть необходимые ссылки на макеты, указаны состояние при открытии, стейт во время загрузки, стейты успеха и ошибок.  Пример 2. Обратите внимание: описание разделено на логические блоки экрана, в задаче указано состояние, которое надо учесть на будущее и есть переход на ранее реализованный экран.  Пример 3. Здесь не забыли указать, что требуется предусмотреть использование для двух экранов, что подгрузка постраничная и делается немного заранее. Указаны специфичные кейсы с 0-датой, ошибкой загрузки и ошибкой подгрузки. В ответе указано, какие поля за что отвечают, явно указано, что не парсим.  Пример 4. Явно указано, что не нужно реализовывать из макета — разработчик не будет делать ничего лишнего. Указано сохранение данных для будущего использования. В чек-листе добавлены проверки на первое открытие приложения и на повторные с разным поведением. Добавлена связь с другой задачей — по добавлению API к этому экрану.  Пример 5. Указаны кейсы для разных объемов данных (не помещается на одну строку — где-то проблема решается с помощью многоточия, где-то — переносом строки). В чек-листы также добавлена проверка.Понятная работа с полями api. Указано, в каких форматах отображать текущий год и будущие даты.   Маркетолог в CleverPumpkin