Как научиться правильно ставить задачи разработчикам и ускорить процессы в 2 раза

Одна из основных проблем в ИТ проектах — взаимопонимание двух миров: бизнеса и разработки. Одни хотят быстро и красиво, другие хотят получить исчерпывающее описание хотелки. Переговоры занимают много времени, но еще больше — исправление ошибок. Как эффективно выстроить процесс, рассказывает зам технического директора музыкального сервиса «Звук» Кирилл Ларин.

Так как разработка (+тестирование) — самое дорогое звено в создании ИТ-решения, то необходимо экономить время разработчика любым способом.

Если задача поступает в разработку с неполным описанием, то есть в ней нет всех Use cases и Corner cases, то разработчик тратит массу времени на выяснение нюансов. Или не хочет вступать в полемику и делает все, опираясь на свою картину мира, по принципу “художник так видит”.

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

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

Однако часто бизнес не знает, что требуется разработчику, чтобы сделать задачу верно и в срок. Как найти общий язык?

Сквозь слёзы и пот мы в Звуке сформировали стандарт, который позволяет получить 90% информации, необходимой для решения любой it-задачи.

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

Для этого заказчику необходимо описать следующие аспекты задачи:

• Требование
• Проблема, которую надо решить
• Продуктовые требования
• Технологические требования
• User stories
• Use cases
• Corner cases

Рассмотрим подробно каждый аспект.

Для точного определения, что требуется сделать в постановке задачи используется принцип SMART:

• Specifiс. Задача должна быть конкретной. Куда мы пойдем, чего мы хотим достичь?
• Measurable. В чем должен измеряться результат и какой результат будет для нас хорошим
• Attainable. Достижимые цели. Здесь мы проверяем, находятся ли наши цели в реальных пределах
• Relevant. Все задачи должны относиться к бизнесу и должны вести к цели проекта
• Time-bound. Обязательное ограничение во времени. Большие задачи надо стараться разбить на более мелкие

Какую проблему заказчик пытается решить?

Какие метрики будут оцениваться, какие показатели будут достигнуты в ходе решения задачи?

Какие технологические требования и ограничения предъявляет заказчик к функционалу?

Какая функциональность ожидается?

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

• Они не являются детальным описанием требований (то-есть того, что система должна бы делать), а представляют собой скорее обсуждаемое представление намерения (нужно сделать что-то вроде этого).
• Они являются короткими и легко читаемыми, понятными разработчикам, заказчикам и пользователям.
• Они представляют собой небольшие инкременты ценной функциональности, которая может быть реализована в рамках нескольких дней или недель.
• Они относительно легко поддаются оценке, таким образом, усилия, необходимые для реализации, могут быть быстро определены.
• Они не занимают огромных, громоздких документов, а организованы в списки, которые легче упорядочить и переупорядочить по ходу поступления новой информации.
• Они не детализированы в самом начале проекта, а уже более детально разрабатываются «точно в срок», избегая таким образом слишком ранней определенности, задержек в разработке, нагромождения требований и чрезмерно ограниченной формулировки решения.
• Они требуют минимум или вовсе не требуют сопровождения и могут быть безопасно отменены после имплементации.

Текст самой US должен объяснять роль/действия пользователя в системе, его потребность и выгоду, которые пользователь получит после того как история случится.

Как, <роль>, я <что-то хочу получить>, <с такой-то целью>.

Важно:

• Есть одна Роль
• Есть одно действие
• Есть одна ценность/влияние

US можно оценить по критериям INVEST:

• Independent. Меньше зависимостей — легче планировать
• Negotiable. Детали появляются в ходе обсуждений команды разработки и заказчика
• Valuable. Измеримая история — какие метрики изменились
• Estimable. Большая или расплывчатая история — невозможно точно оценить трудозатраты
• Small. Небольшая история разрабатывается в рамках недели
• Testable. Простой критерий готовности

Важно помнить, что:

• Лучше написать много историй поменьше, чем несколько громоздких.
• Каждая история в идеале должна быть написана избегая технического жаргона — чтобы суть была понятна и бизнесу и разработке.
• Истории должны быть написаны таким образом, чтобы их можно было протестировать.
• Тест-план должен быть написан до кода.
• Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
• Каждая история должна содержать оценку.
• История должна иметь концовку — т.е. приводить к конкретному результату.
• История должна помещаться в итерацию.

Какой сценарий необходимо пройти, чтобы достичь цель?

Что UC включают в себя:

• Кто пользуется системой
• Что пользователь хочет сделать
• Какая у пользователя цель
• Шаги к достижению цели
• Как система реагирует на действия пользователя

Что UC не включают в себя:

• Реализацию на специфическом языке (терминология и т.п.)
• Информацию про интерфейсы

В зависимости от глубины и сложности того, что вы хотите или должны достичь, UC описывают комбинацию следующих элементов:

• Актер — кто или что выполняет действие.
• Предварительные условия — что должно быть/случиться до и после прохождения UC.
• Триггер — какое-то событие, которое стало причиной запуска UC.
• Главный успешный сценарий — прохождение UC по ожидаемому сценарию.
• Альтернативный сценарий — вариации главного успешного сценария. Происходит, когда что-то пошло не так на системном уровне.

Для написания UC используются следующие шаги:

• Определить кто будет пользоваться системой.
• Выбрать одного пользователя.
• Определить, что этот пользователь будет делать с системой. Каждое действие станет UC.
• Для каждого UC определить курс событий, когда этот пользователь использует систему.
• Опишите основной курс в описании для UC. Опишите его с точки зрения того, что делает пользователь и что система делает в ответ, о чем пользователь должен знать.
• Когда базовый курс описан, рассмотрите альтернативные курсы и добавьте их, чтобы «расширить» UC.
• Ищите общие черты среди UC. Объедините их как UC одного курса.
• Повторить шаги с 2 по 7 для всех пользователей.

Для того чтобы избежать непредвиденных сценариев в работе фичи, необходимо описать все возможные CC. По сути, CC отвечает на вопрос А что будет, если ...? СС должны покрывать большинство вариантов и указывать на причины возникновения вариантов.

Чтобы описать CC нужно определить, какие факторы влияют на фичу и описать результат/сценарий при всевозможных комбинациях этих факторов.

Для этого целесообразно использовать таблицу, в которой на пересечении факторов будет описан результат/сценарий.

С теорией всё понятно, но как дело обстоит на практике? Разберем упрощенное описание задачи на примере сохранения настроек приложения.

Требование

Сохранять настройки приложения

Проблема

В ходе опроса было выявлено, что пользователь ожидает, что приложение запоминает его последнее состояние (настройки). По аналогии с другими сервисами.

Продуктовые требования

Использовать распространенный UX для реализации решения

Технологические требования

Сохранять настройки приложения на серверной стороне в связке с данными пользователя

User story

Как пользователь, я хочу, чтобы приложение запоминало мои настройки, чтобы мне не приходилось указывать их каждый раз при авторизации

Use cases

— Пользователь открывает приложение.

— Пользователь входит в учетную запись в приложении.

— Пользователь устанавливает настройки приложения.

— Система сохраняет настройки.

— Пользователь выходит из учетной записи в приложении.

— Пользователь входит в учетную запись в приложении (+ на другом устройстве).

— Система передает сохраненные настройки в приложение.

— Приложение отображает сохраненные настройки пользователя.

Corner case

Обеспечить обратную совместимость со старыми клиентами.

Первое. Объяснить команде боль. Как известно, если вы указываете причину внедрения, конверсия увеличивается.

Второе. Показать пример, поставить некоторое количество задач для начала по стандарту, показать заказчикам, как это надо делать, как оно работает.

Третье. При внедрении обязательно собрать обратную связь по стандарту. Ответить на все вопросы, внести корректировки. Тогда будет коллективный труд, порог вхождения ниже.

Четвертое. Воспринимать все нововведения, как эксперимент. Если он удался (были достигнуты цели), он приживется сам собой, так как мотивация у людей будет осознанной. Если не удался, можно вернуться к прежнему состоянию.

Пятое. Закрепить нововведения фактами в виде цифр — сравните с периодом до внедрения. Производительность увеличилась на столько-то, количество ошибок упало на столько-то.

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

В «Звуке» после внедрения стандарта скорость и качество работы увеличилось в 2 раза. Мы получили положительные отзывы от всех участников команды и решили основную проблему.

#бизнес_процессы #звук #стриминг #музыка #приложение #управление