Оценка задач фронтендера
Вступление
Давайте, черт побери, будем честны: оценка задач — это худшая часть нашей работы. Мы на такое не подписывались. В школе этому не учили. Но если вы сумеете разобраться, то жизнь станет значительно легче. Нет ничего хуже, чем облажаться с оценкой и не уложиться в срок, превысить бюджет или работать допоздна, внося очередные исправления.
Пример процесса оценки
Работая в области рекламы, я был свидетелем наихудших способов оценки проектов, большинство из которых сводились к следующему: «Эй, есть проектик. Дизайн готов, надо сверстать и прикрутить функционал до 12-го декабря, и это — крайний срок, стартует реклама на ТВ. За сколько управишься?».
В примере выше процесс протекал следующим образом:
- Кто-то продает проект клиенту с заранее оговорённой датой релиза
- Кто-то делает для него дизайн
- Кто-то реализует этот дизайн
Давайте назовем этот процесс дата-центрическим.
Вместо того, чтобы сфокусироваться прежде всего на пользователе, процесс фокусируется на том, чтобы сделать что-то к определённой дате. Иногда выделен хороший бюджет и достаточно времени, что позволяет вовлечённым людям попробовать несколько вариантов и улучшить UX. Но обычно всё делается в спешке от начала и до конца, так как дедлайн определяется не разработчиками проекта.
Процесс, сторонником которого я являюсь и который сейчас использую: пользователе-центрический. Так как я работаю в многопрофильном консультационном дизайнерском агентстве, которое разрабатывает как цифровые, так и физические товары и сервисы, пользователь в центре внимания от начала и до конца. Я вовлечён в работу над цифровыми продуктами, и процесс выглядит приблизительно следующим образом:
- Разработчик сервиса продаёт клиенту проект, организовывая воркшоп, где они с клиентом вместе определяют ключевые особенности продукта
- Анализ, на протяжении которого мы должны определить потребности пользователей и точки соприкосновения с ними
- Дизайн, на протяжении которого мы приводим продукт в соответствие с потребностями пользователей, определёнными в процессе анализа
- Прототипирование с помощью какого-то инструмента, например Proto.io или Framer.js
- Внедрение дизайна
Оценка в пользователе-центрических процессах
Скажем, проект находится в состоянии, когда мы уже знаем, что будем разрабатывать цифровой сервис — например, сайт или веб-приложение. Но чтобы продолжить, клиент хочет получить оценку того, сколько это будет стоить. Естественно. Что делать дальше? Давайте я расскажу, как мы обычно поступаем с 90% вероятностью успеха.
Пользовательские сценарии
Может быть, вы слышали про пользовательские сценарии, а может и нет, но они очень важны для успешной оценки и профессионально сделанного коммерческого предложения. Сценарии должны быть ключевой частью любого дизайна, а если вы разработчик, то скорее всего уже используете их в рамках скрама. В смысле, это первое, о чём вы говорите на самом первом митинге с клиентом. Именно они помогают клиенту действительно понятно рассказать, что он хочет. Если клиент не знает — следует помочь ему и выяснить это вместе. Можно сделать это в формате воркшопа, как я уже упоминал ранее. Если у вас есть ресурсы, то следует пообщаться с потенциальными пользователями, выслушать их потребности и включить их в пользовательские сценарии.
Вот шаблон пользовательского сценария: «Как пользователь, я хотел бы … чтобы я смог … ».
Когда создан набор таких сценариев, нужно сделать следующее:
- Обозначить их как критичные и не критичные. Если бюджет ограничен, то будет ясно, на чём следует сосредоточиться.
- Можете начинать создавать дизайн, который бы соответствовал сценарию. Каждый из них, в свою очередь, будет отдельной задачей.
- В процессе имплементации дизайна сценарии можно использовать для постановки задач.
Как видно из этого списка, если пользовательские сценарии станут краеугольным камнем проекта, то мы получим продукт, полностью сконцентрированный вокруг удовлетворения потребностей пользователей.
Оценка задач фронтендера на базе сценариев
Как я уже упоминал, вы будете использовать сценарии при постановке задач в проекте. Если вы были вовлечены в проект непосредственно перед фазой внедрения дизайна и должны оценить его, то сделать это исключительно просто, если работа построена вокруг пользовательских сценариев. Если нет — предстоит серьёзно потрудиться. Придётся создавать искусственные сценарии на базе разработанных мокапов. Это наихудший случай, но вам всё равно нужно их сделать, так как это может помочь обнаружить просчёты в UX.
Итак … скажем, все сценарии готовы, и можно начинать оценку. Предположим, сервис, который вы разрабатываете — это веб-приложение для управления ресурсами команды. Есть список сценариев вида: «Как пользователь, я хочу иметь возможность увидеть, есть ли у работника свободный временной слот на протяжении определённого периода времени, чтобы я мог назначить его на проект».
С конкретным сценарием, приведённым выше, можно создать множество задач и подзадач. Например:
- Создать календарь, который показывает занятость работника
- Создать компоненту календаря (14 часов)
- Реализовать API календаря (2 часа)
- Задача 3 (4 часа)
- Задача 4 (2 часа)
- Задача 5 (10 часов)
После того, как вы перечислили всё, что нужно для удовлетворения потребностей пользователей, описанных в сценарии, у вас на руках оказывается количество часов, которое можно использовать в процессе оценки. Этот конкретный сценарий требует на реализацию 32 часа. Теперь у вас есть не только количество часов, которое можно назвать клиенту, но и причина, по которой эту работу можно вам доверить. Для клиента это будет похоже на поход за продуктами. Чтобы сделать яблочный пирог, нужно определённое количество ингредиентов — некоторые из них важнее, чем другие. Но они все перед вами, и вы можете выбрать то, что нужно, чтобы приготовить вкусный пирог.
Ваша оценка и коммерческое предложение должны включать следующее:
- Кратко о том, что должно быть сделано (чтобы убедиться, что между клиентом и вами нет недопонимания)
- Описание концепции (чтобы клиент видел, что вы её поняли)
- Список пользовательских сценариев, созданных на базе этой концепции
- Список задач, созданный на основе сценариев
- Оценка, которая включает
- Задачу
- Результат
- Количество часов
- Стоимость (стоимость часа вашего времени, умноженная на необходимое количество часов)
- Резюме
К процессу создания последних оценки и коммерческого предложения, которые я делал не далее, как вчера, я привлёк клиента, выслав ему ссылку на гугл-док, где мы вместе создали список сценариев и задач. Это важно, так как теперь я не просто сделал оценку и выслал ему красиво оформленный PDF, с которым клиент мог согласиться или нет. Это привело к возникновению дискуссии и пониманию того, почему всё именно так, а не иначе. Теперь клиент уже сам принимал участие в формировании стоимости проекта, а не получал с моей стороны требования денег и времени.