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