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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно:

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

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

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

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

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

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

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

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

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

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

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

Требование

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

Проблема

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

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

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

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

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

User story

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

Use cases

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

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

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

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

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

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

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

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

Corner case

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

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

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

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

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

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

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

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

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