Бизнес постановка задачи в разработке

«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов. Как это сделать, рассказывает руководитель проектного офиса “CleverPumpkin” Лада Ларкина.

В данной статье описывается опыт с упором на специфику работы компании именно в нашей сфере – мы занимаемся разработкой мобильных приложений на заказ, но при этом у нас есть несколько собственных продуктов в виде приложений. Если вы не увидите тут идеальных лично для вас процессов, то не переживайте, это вполне нормально, но в любом случае мы считаем, что описанное в той или иной мере может быть применимо в разных областях создания программного обеспечения.

Этап подготовки

Главное: вы сами должны четко представлять ожидаемый от разработчика результат — без этого не получится правильно описать задачи.
Отнеситесь к сбору информации ответственно: до того, как задача попадет к разработчику, вы должны сами полностью понять бизнес- и функциональные требования.
Главное требование к задаче – прочитавший её разработчик должен сразу понять, что ему нужно делать, и это представление должно совпадать с ожиданиями менеджера. А после прочтения идеально описанной задачи у разработчика появляется четкое представление, как он будет ее выполнять.

Декомпозиция задач

Проанализируйте, как задача может быть декомпозирована. Разделить большую задачу нужно так, чтобы между задачами не было пересечений и они логично дополняли друг друга. Возможно, декомпозированную задачу предстоит выполнять разным разработчикам, и важно, чтобы они не делали двойную работу, минимально пересекались и по итогам реализации было минимум конфликтов.
Если в прогрессе декомпозиции появилось несколько задач, которые нельзя делать последовательно — значит, вы перестарались. Разделять задачу нужно, если ее части можно делать одну за другой.
Но базовое правило для декомпозиции — длительность работы над одной задачей не должна быть больше одного дня. В редких случаях — больше, например, если это сложная интеграция, которую не разбить на несколько шагов. Хотя и тут речь может идти о подзадачах не функциональных, а технических.

Название задачи

В названии нужно коротко сформулировать суть задачи, чтобы ее было легко найти в таск-трекере. Мы рекомендуем использовать такую логику для названия:

[версионная особенность] [раздел] — [часть экрана] — [что сделать]

Разберем каждую часть названия:

• [версионная особенность] — это может быть версия платформы, MacOS/iPad фичи;
• [раздел] — описывает, в каком разделе добавляется функциональность;
• [часть экрана] — указывает конкретный блок на экране, если изменения касаются его;
• [что сделать] — суть изменения или фичи;

Примеры хороших названий:

• «Подключить Firebase Performance»
• «Профиль (авторизованный) — добавить пункт история заказов»
• «История заказов — реализовать загрузку и отображение списка заказов»
• «Заказ из истории — Блок итого — Добавить строку дополнительных услуг»
• «[iPad] История заказов — Реализовать просмотр конкретного заказа в split view режиме»
• «[iOS 13+] Настройки — Добавить пункт «Siri shortcuts»

Примеры неудачных названий:

• «Подключить экран к API» — (какой раздел, экран?)
• «Цветовая индикация» — (ее нужно добавить? изменить? где находится?)

Описание задачи

Описание должно быть необходимым и достаточным.

• Необходимым — не должно быть пересечений между задачами в описании. Разработчик должен понимать, какую именно часть задачи ему сейчас реализовывать.
• Достаточным — у разработчика не только не должно появиться дополнительных вопросов, но и возможности понять что-то не так. Избегайте двусмысленности в задачах.

Текст задачи должен понять любой новый разработчик на проекте. Нужно осознавать, что разработчики хуже понимают контекст проекта, чем менеджеры, вряд ли присутствовали при формировании ТЗ, разработки дизайна и т.д., а впервые видят описание необходимого обновления. Полезно написать, зачем вообще добавляется эта фича и почему она нужна пользователю — тогда у разработчика появятся понимание, что он делает, и, возможно, предложения для улучшения пользовательского опыта.

Не забудьте описать:

• как попасть в раздел, в который вносится доработка, если это не очевидно;
• что необходимо сделать с учетом специальных обработок для крайних кейсов, если таковые есть;
• указать, было ли ранее в приложении реализована схожая функциональность для переиспользования;
• указать, планируется ли в будущем переиспользование, что нужно предусмотреть для этого;
• что требуется для реализации — макеты, ключи доступа, инвайты и т.д.;
• указать, какие данные используются, откуда они получаются, как обрабатываются. Если данные получаются при каком-то условии, то его надо обязательно указать;
• какие запросы будут дергаться;
• как будет использоваться результат задачи, в том числе, как его сохранить и передать для другой задачи;
• есть ли задачи, которые следует связать с текущей;
• надо ли добавить аналитику по этой функции.

Описание должно учитывать платформенные особенности, не допустите ошибочных расхождений в одинаковой функциональности.

Лайфхаки и советы

1. Структурируйте и будьте аккуратны. Разделяйте задачу на логические блоки, чтобы удобно было читать и находить информацию. Для начального заполнения задачи пользуйтесь шаблоном (например, YouTrack, который мы используем в работе, автоматически добавляет формат базовой задачи с местом для верстки, логики и сразу с базовым чек-листом, всем советуем, очень удобно).
2. Не допустите пересечения параллельных задач между разработчиками. Так вы получите увеличение трудозатрат на разрешение конфликтов и дублирование.
3. Ставьте задачи на любые изменения. Без этого вы не сможете доказать разработчику, что он сделал что-то не так. Устные договоренности ничего не значат! Без задачи изменения не будут протестированы тестировщиком. Кроме того, часто поставленные задачи служат единственным источником информации о поведении приложения. Отсутствие задачи в начале — недостаток информации потом.
4. Связь задач между платформами. Обязательно свяжите задачи про одинаковые фичи между двумя платформами в системе постановки задач. Так проще поддерживать актуальность описаний задач при изменениях на обеих платформах, догоняющий разработчик сможет узнать, кто делал задачу на другой платформе, и прочитать обсуждение.
5. Визуализация для задачи. Иногда схема, диаграмма или картинка опишет разработчику что-то понятнее, чем сложный текст — или хотя бы поможет быстрее разобраться в задаче.

Чек-лист для разработчика

Чек-листы нужны для самопроверки разработчика. При первой реализации они помогают учесть больше кейсов. Всегда проверяйте:

1. наиболее старую поддерживаемую версию платформы — она же обычно и самая проблемная;
2. работу на маленьком девайсе;
3. темную тему;

Кроме того, в зависимости от задачи чек-лист может дополняться следующими пунктами:

• крайние кейсы для проверки;
• пустые состояния;
• состояния ошибок;
• подгрузка данных (если она постраничная);
• обновление данных (PTR);
• большие/маленькие данные;
• заглушки для текстов/картинок;
• горизонтальная ориентация.

При проверках по чек-листу у разработчика не должно возникать вопросов «как это должно работать в таком кейсе?» — это должно быть описано в тексте задачи.
В процессе планирования менеджер должен убедиться, что чек-лист дополнен тестировщиком. Если на первой платформе после тестирования появляются ошибки на не включенные в чек-листы моменты, то в задаче на второй тестировщик также должен дополнить описание и чек-листы.

Ожидаемый эстимейт по задаче

Следите за эстимейтом, поставленным разработчиком. Если он отличается от ваших ожиданий (и от original estimate), то важно понять почему. Возможно, не так воспринято описание задачи, возможно, что-то недооценивается или, наоборот, усложняется. Разработчик может не учесть переиспользование, а может, вы забыли об этом написать в задаче.
Если в изначальной оценке было что-то пропущено, то необходимо обсудить и, возможно, согласовать изменения функциональных требований с руководителем проекта и заказчиком.

Шаги описания задачи

Итак, зафиксируем пройденный материал:

• Получите все необходимые требования. Убедитесь, что сами понимаете, что требуется реализовать.
• Подберите правильное название задачи.
• В самом начале описания задачи поясните разработчику ценность изменения.
• Добавьте путь до изменяемого экрана, если это не очевидно.
• Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса.
• Добавьте дополнительные ссылки на артефакты, которые требуются для выполнения задачи.
• Если предполагается переиспользование для реализации, явно укажите это.
• Укажите, если в будущем будет переиспользоваться, масштабироваться или меняться результат задачи.
• Если необходимо сохранение данных для будущего использования, укажите.
• Опишите функционально задачу и убедитесь в отсутствии пробелов в логике.
• Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим, опциональность; не описывать неиспользуемые поля и указать, что их не парсим).
• Укажите, если данные получаются при каком-то условии — например, касаются только авторизованных пользователей, специальных заказов или аккаунтов и т.д.
• Укажите прошлые локальные данные, если они используются.
• Пропишите логику загрузки данных: есть ли постраничная подгрузка, активити и т.д.
• Укажите логику для пустых данных.
• Опишите разные форматы отображения для разных региональных параметров, форматов дат и т.д.
• Пропишите логику для обработки специальных ошибок.
• Если требуются какие-то ключи, то добавьте их для каждого типа сборки – QA/RC/Release.
• Убедитесь, что разработчики имеют доступ ко всем необходимым артефактам или сервисам.
• Добавьте аналитику по данной функции (возможно в другой задаче – подумайте и не забудьте).
• Дополните базовый чек-лист.
• Свяжите с задачей для другой платформы и другими задачами, если есть такая зависимость.
• Перечитайте всю задачу от начала до конца!

Важно приучить себя мысленно продумывать все эти шаги, чтобы потом на автомате учитывать все потребности и возможности для облегчения разработки. Хорошо описанная задача экономит время всем: будет меньше вопросов, ускорится тестирование и т.д.

Примеры хорошо описанных задач

Эти задачи описаны достаточно полно, не вызвали вопросов у разработчиков.

Пример 1. Описание задачи хорошо тем, что указана ценность реализации для пользователя, есть необходимые ссылки на макеты, указаны состояние при открытии, стейт во время загрузки, стейты успеха и ошибок.

Пример 2. Обратите внимание: описание разделено на логические блоки экрана, в задаче указано состояние, которое надо учесть на будущее и есть переход на ранее реализованный экран.

Пример 3. Здесь не забыли указать, что требуется предусмотреть использование для двух экранов, что подгрузка постраничная и делается немного заранее. Указаны специфичные кейсы с 0-датой, ошибкой загрузки и ошибкой подгрузки. В ответе указано, какие поля за что отвечают, явно указано, что не парсим.

Пример 4. Явно указано, что не нужно реализовывать из макета — разработчик не будет делать ничего лишнего. Указано сохранение данных для будущего использования. В чек-листе добавлены проверки на первое открытие приложения и на повторные с разным поведением.

Добавлена связь с другой задачей — по добавлению API к этому экрану.

Пример 5. Указаны кейсы для разных объемов данных (не помещается на одну строку — где-то проблема решается с помощью многоточия, где-то — переносом строки). В чек-листы также добавлена проверка.
Понятная работа с полями api. Указано, в каких форматах отображать текущий год и будущие даты.

• постановка задач
• мобильная разработка
• лайфхак
• менеджмент проектов

Источник: habr.com

Как менеджерам научиться ставить задачи разработчикам

Когда речь заходит о разработке, менеджеры и управленцы сразу вспоминают накопившийся массив задач, которые ждут своей очереди, непредсказуемые сроки их реализации, имеющие свойство постоянно меняться, натянутые отношения с IT-отделом, который использует систему «свой-чужой», и множество других проблем, тормозящих развитие бизнеса. Чтобы решить все эти проблемы, необходимо научиться грамотно ставить задачи и общаться с разработчиками. О том, как менеджеры должны ставить задачи, чтобы они были выполнены в срок и в соответствии с заданием, рассказывает Николай Хлебинский, СЕО и сооснователь платформы Retail Rocket.

Генерируйте идею правильно

В наши головы постоянно приходят идеи по доработке и улучшению продукта – как поднять конверсию сайта, ускорить работу отдела, усовершенствовать бизнес-процессы, автоматизировать какие-то функции и т.д. Существуют даже специальные должности и отделы, в обязанности которых входит мониторинг новой функциональности, которая появляется у ведущих игроков рынка. Еще одним отличным источником идей служит обратная связь от клиентов. Весь этот массив данных, мнений и предложений накапливается и требует постоянной сортировки, оценки и приоритезации.

Новые идеи двигают продукт вперед и создают конкурентные преимущества, но если бы каждый сотрудник сразу шел с возникающими идеями к разработчикам, у последних просто не оставалось бы времени на работу. Им пришлось бы либо погрязнуть в череде бесконечных обсуждений, как лучше реализовать тот или иной момент, и тогда разработка шла бы крайне медленно. Либо наоборот, стремясь как можно быстрее внедрять новые функции и фичи, пришлось бы кодить «костылями», добавляя изменения без оглядки на другой функционал, что создавало бы трудности в дальнейшем.

Поэтому первая и самая важная проблема, которую нужно решить – это процесс генерации идей.

У нас в Retail Rocket идею может сгенерировать любой член команды, и она заносится на определенную доску в Trello. В своей работе мы используем идеологию Канбан и для каждого процесса в компании, для каждого отдела, есть своя доска. Идеи по продукту записываются в определенный столбец, но чтобы это сделать, менеджер (или любой сотрудник) должен сформулировать ее краткое описание. То есть не просто «ограничить количество символов в отзывах» или «добавить кнопку быстрого заказа», а внятное описание, из которого будет понятно, зачем нужна новая функция и чем она будет полезна.

То есть человек, у которого появляется идея, не идет сразу в отдел разработки, и даже не идет в продакт-менеджеру, а прежде всего пытается сформулировать идею в слова. Это позволяет избежать множества проблем и вопросов при дальнейшей разработке и внедрении новых функций.

Поэтому первое правило: Задача может быть внесена в идеи, только если человек готов сформулировать её краткое описание.

Описывайте задачу максимально подробно

После этого в дело вступает продакт-менеджер – это отдельная роль, которая занимается управлением продуктом. Задача этой роли – сбор требований и подготовка этих требований к передаче в разработку. То есть постановщик идеи не общается с разработкой напрямую.

Продакт-менеджер должен составить описание, по которому разработчики будут принимать решение о том, как реализовывать эту конкретную идею и оценивать сроки выполнения задачи.

Отсюда второе правило: первоначальная функция продакт-менеджера состоит в том, чтобы поставить и описать задачу так, чтобы снять все вопросы у разработки.

Например, в случае задачи ограничения количества символов в отзыве, должно быть описано, что происходит, если отзыв длиннее заданной величины, должен ли быть счетчик символов, меняются ли CSS-стили при приближении счетчика к нулю или показывается сообщение об ошибке и т.д. На все эти вопросы должны быть ответы, чтобы разработчикам не пришлось уточнять детали в процессе.

Третье правило: product-менеджер должен сформировать список тех, кто будет тестировать фичу и определять ее эффективность.

Это значит, что во-первых, идея не может идти в разработку, пока не определен список тех, кто будет отвечать за ее проверку, после того, как она выйдет из IT-отдела. И во-вторых, пока не будут четко определены критерии эффективности.

То есть сотрудник, который заказывает новую фичу, должен сказать: «Тестировать будут эти конкретные люди, и тестирование будет считаться успешным, если наступило такое событие».

Оценивайте каждую задачу

Самый важный момент, который происходит на этом этапе – получение оценки по задаче в деньгах. Это означает, что любая задача, которая дается в разработку, должна быть оценена в деньгах ее постановщиком, т.е. сотрудник должен посчитать, сколько бизнес на этом заработает. Многим кажется, что невозможно оценить, сколько денег принесет выполнение той или иной задачи, но это не так.

Да, это может быть сложно, но опыт показывает, что по большинству задач это вполне реально. А если нельзя – именно эти задачи оказываются бизнесу не нужны. Если вы не знаете, сколько принесет задача, точно ли нужно тратить на нее время?

Четвертое правило: каждая задача должна быть оценена в деньгах

Приведем пример. Существуют триггерный сценарий – письмо о «брошенной корзине», которое интернет-магазин отправляет пользователям, которые добавили товар в корзину, но не оформили заказ. Один из клиентов попросил отправлять повторное письмо в случае, если цена на один из товаров в корзине снизилась.

Чтобы посчитать стоимость этой задачи, менеджер продукта пришел с запросом к аналитикам и попросил посчитать, на какое количество товаров снижается цена за неделю на 5% и более. Аналитики посчитали, что около 10% товаров, оставленных в корзине, в сегменте fashion за неделю снижают цену на 5% и более. Это означает, что мы можем увеличить количество отправок писем о брошенной корзине на 10% и, соответственно, получить на 10% больше заказов. Таким образом за неделю мы получили оценку задачи в деньгах.

И все эти процессы происходят пока без участия разработчиков, т.е. мы не отрываем их от текущих задач.

Приоритезируйте задачи

После оценки задачи в деньгах, нужно получить оценку выполнения задачи по времени – на этом этапе подключается отдел разработки.

По описанию, которое составил менеджер продукта, разработчики обсуждают, как можно выполнить поставленную задачу и сколько времени это займет. Для оценки мы используем Planning Poker.

После оценки всех задач в бэклоге, можно их приоритезировать, т.е. понять, какие из задач можно выполнить максимально быстро и какие принесут наибольшую финансовую отдачу. За них нужно браться в первую очередь.

Пятое правило: первыми в работу должны идти в работу задачи, которые принесут наибольшую финансовую выгоду и требуют минимальных затрат по времени.

Только теперь начинается работа IT-команды над задачей.

Сначала создавайте MVP

Когда доходит дело до разработки, важно первую версию фичи сделать максимально дешевой и простой в производстве, чтобы максимально быстро протестировать гипотезу. То есть создать MVP (Minimal Viable Product). На этом этапе важно проверить критерии эффективности, которые были определены при описания задачи.

На примере задачи с уведомлением о снижении цены на товар в корзине, не нужно сразу делать интерфейс, маркетинговые материалы и т.д. Мы просто пишем код, который срабатывает практически вручную, предлагаем нескольким магазинам на тестирование, чтобы проверить, как это повлияет на продажи и подтвердить расчеты аналитиков на практике. Проводим тестирование в ручном режиме и измеряем результаты. И только после того, как мы получили доказательства того, что гипотеза сработала, в зависимости от результатов, мы принимаем решение, стоит ли разрабатывать полноценную фичу (разрабатываем интерфейс, рисуем дизайн, делаем верстку и т.д.).

Шестое правило: разрабатывайте полноценную версию фичи после подтверждения ее эффективности через MVP

Увеличивайте продуктивность команды разработки

Никто, кроме менеджера продукта и, возможно, генерального директора, не должен общаться с разработчиками. Они должны находиться в отдельной комнате и никто не должен к ним заходить. Это поможет в разы увеличить эффективность работы IT-отдела. Потому что человеку, чтобы сконцентрироваться даже на простой задаче, нужно потратить 15-20 минут, чтобы только приступить к выполнению.

И если через 15 минут к нему подходит кто-то с вопросом (а такое случается постоянно, и чем больше компания, тем чаще), человек выходит из состояния концентрации. А значит, ему снова нужно 15-20 минут для погружения. Т.е. как минимум 30-40 минут уже потеряно впустую. И если 5-7 человек в день подойдут к разработчику с вопросом, можно считать, что за день он ничего не сделал.

Седьмое правило: Ограничьте до минимума круг тех, кто общается с разработчиками. В идеале это должен быть только менеджер продукта и в некоторых случаях генеральный директор.

Мы решили эту задачу выделив под IT отдельную комнату, вход в которую всем остальным сотрудникам запрещен. На двери висит отдельный замок, ключ-карта к которому есть только у самих инженеров и еще нескольких людей в компании.

Еще один важный момент: нужно построить вокруг IT-отдела «защитный купол», т.е. оберегать от любых проблем, решать все вопросы, обеспечить инфраструктуру, чтобы они не занимались ничем, кроме производства кода. Неслучайно в корпорациях, таких как Яндекс или Google, офисы полностью обустроены так, чтобы человеку можно было практически не уходить домой. Если сотрудник будет заниматься поисками чая, кофе или батарейки для мышки, он будет гораздо меньше времени тратить на свои непосредственные обязанности. Обеспечить дорогостоящих квалифицированных специалистов всем необходимым гораздо дешевле, чем тратить их время на нецелевые действия.

Восьмое правило: организуйте инфраструктуру и обеспечьте разработчиков всем необходимым

Это важно еще и потому, что хороших разработчиков действительно мало, и конкурировать за них только по цене бесполезно, потому что всегда найдется тот, кто готов платить больше. Поэтому чем более комфортные условия вы сможете создать, тем более продуктивной сможет стать команда разработки и тем большую лояльность будут проявлять сотрудники.

Станьте своим

Еще один простой, но очень эффективный способ более эффективно общаться с разработчиками – это научиться разговаривать на их языке. Пройти курсы по HTML, CSS (например на codecademy.com), т.е. потратить 10-20 часов своего времени, чтобы в будущем гораздо лучше понимать IT-команду.

Источник: retailrocket.ru