Оценка задач фронтендера

Вступление

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

Пример процесса оценки

Работая в области рекламы, я был свидетелем наихудших способов оценки проектов, большинство из которых сводились к следующему: «Эй, есть проектик. Дизайн готов, надо сверстать и прикрутить функционал до 12-го декабря, и это — крайний срок, стартует реклама на ТВ. За сколько управишься?».

В примере выше процесс протекал следующим образом:

  1. Кто-то продает проект клиенту с заранее оговорённой датой релиза
  2. Кто-то делает для него дизайн
  3. Кто-то реализует этот дизайн

Давайте назовем этот процесс дата-центрическим.

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

Процесс, сторонником которого я являюсь и который сейчас использую: пользователе-центрический. Так как я работаю в многопрофильном консультационном дизайнерском агентстве, которое разрабатывает как цифровые, так и физические товары и сервисы, пользователь в центре внимания от начала и до конца. Я вовлечён в работу над цифровыми продуктами, и процесс выглядит приблизительно следующим образом:

  1. Разработчик сервиса продаёт клиенту проект, организовывая воркшоп, где они с клиентом вместе определяют ключевые особенности продукта
  2. Анализ, на протяжении которого мы должны определить потребности пользователей и точки соприкосновения с ними
  3. Дизайн, на протяжении которого мы приводим продукт в соответствие с потребностями пользователей, определёнными в процессе анализа
  4. Прототипирование с помощью какого-то инструмента, например Proto.io или Framer.js
  5. Внедрение дизайна

Оценка в пользователе-центрических процессах

Скажем, проект находится в состоянии, когда мы уже знаем, что будем разрабатывать цифровой сервис — например, сайт или веб-приложение. Но чтобы продолжить, клиент хочет получить оценку того, сколько это будет стоить. Естественно. Что делать дальше? Давайте я расскажу, как мы обычно поступаем с 90% вероятностью успеха.

Пользовательские сценарии

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

Вот шаблон пользовательского сценария: «Как пользователь, я хотел бы … чтобы я смог … ».

Когда создан набор таких сценариев, нужно сделать следующее:

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

Оценка задач фронтендера на базе сценариев

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

Итак … скажем, все сценарии готовы, и можно начинать оценку. Предположим, сервис, который вы разрабатываете — это веб-приложение для управления ресурсами команды. Есть список сценариев вида: «Как пользователь, я хочу иметь возможность увидеть, есть ли у работника свободный временной слот на протяжении определённого периода времени, чтобы я мог назначить его на проект».

С конкретным сценарием, приведённым выше, можно создать множество задач и подзадач. Например:

После того, как вы перечислили всё, что нужно для удовлетворения потребностей пользователей, описанных в сценарии, у вас на руках оказывается количество часов, которое можно использовать в процессе оценки. Этот конкретный сценарий требует на реализацию 32 часа. Теперь у вас есть не только количество часов, которое можно назвать клиенту, но и причина, по которой эту работу можно вам доверить. Для клиента это будет похоже на поход за продуктами. Чтобы сделать яблочный пирог, нужно определённое количество ингредиентов — некоторые из них важнее, чем другие. Но они все перед вами, и вы можете выбрать то, что нужно, чтобы приготовить вкусный пирог.

Ваша оценка и коммерческое предложение должны включать следующее:

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