“Иногда замедлиться — это лучший способ ускориться”
—Майк Вэнс
Spike (с англ. “всплеск”) — активность, которая применяется в Agile (если вы до сих пор не знаете, что такое аджайл — бегом смотреть этот крутой видосик) и помогает получить знания, необходимые для снижения рисков, лучшего понимания требований и оценки задачи.
Спайк используют разработчики. Когда в спринте появляется неясная задача (user story) с кучей потенциальных проблем и неопределимой сложностью, вместо нее в работу берется спайк. Спайк — это работа, необходимая для того, чтобы дать ответ или решение, а не выкатить фичу.
Например, задача — сделать авторизацию в приложении. Но разработчики не понимают, какую технологию лучше использовать. И вместо того, чтобы бросаться пилить на чем попало, они тормозят разработку и изучают технологии в поисках наиболее подходящей с учетом всех требований.
Чем хорош спайк:
- Помогает работать в условиях неопределенности и неясности;
- Снимает необходимость “что-то делать”, но при этом мотивирует устранить неопределенность;
- Исключает недо- или переоценку неясных задач.
В зависимости от объема работы и количества других задач, спайк может представлять из себя локальную проектную задачу (user story) или же целый спринт (spike sprint) в котором все ресурсы полностью посвящаются исследованию.
Дизайнеры сталкиваются с неясными задачами постоянно: “спроектируйте дашборд руководителя”, “нужно сделать удобно и привлекательно”, “попробуйте еще поиграть”.
Такие задачи сложно оценить, потому что нет понимания, что конкретно нужно сделать. Оценку можно дать на глаз, но есть риск профакапить сроки или выкатить сырую ерунду.
Когда мне приходит дизайн-задача с неясными требованиями, я использую дизайн-спайк. Вы и сами могли его использовать, даже этого не осознавая 🙂
Я объясняю руководителю проекта, что мне придется разделить задачу на 2 части и сначала заняться исследованием: Что должно быть на панели руководителя? Что для наших пользователей удобство и что может их привлечь? Что мы хотим увидеть в результате?
Порой, ответ на эти вопросы — самостоятельная большая работа. И без нее я не могу хорошо выполнить исходную задачу.
Я даю оценку спайку: “на исследование мне потребуется неделя , т.е. половина спринта. Далее мы обсудим результаты и я либо продолжу исследование, либо начну работу над дизайном”.
Если в вашем проекте организованы спринты, и задачи формулируются в виде user story, попросите создать и назначить вам user story с названием Design Spike и связать ее с исходной задачей. Так вы сможете взять спайк в спринт согласно методологии проекта и ваша работа будет задокументирована.
Загвоздка в том, что спайки (как, например, баги у разработчиков) трудно оценивать. Проще сказать, сколько потребуется на разработку новой формы, чем на то, чтобы понять, почему не работает старая.
Также и с дизайн-спайками. Проще оценить работу по отрисовке дашборда, чем по исследованию того, что на нем должно быть.
Поэтому лучше не пытаться оценить спайк, а ограничить его по времени. Именно это я и имею в виду, говоря, например, “мне нужна неделя”. Исследование может длиться долго, но по окончании недели я смогу либо получить валидные результаты, либо понять, что исследование придется продолжить.
Среди последователей аджайл до сих пор много споров о том, оценивать спайки или нет. Споры связаны со story point’ами и с тем, что с их помощью измеряется ценность, приносимая бизнесу конкретной задачей. И спайк ценности для бизнеса не несет, ведь он делается исключительно для специалиста. С другой стороны, спайк (как и любая задача) требует ресурсов, которые также измеряются в story points.
Вы можете сделать выбор, исходя из условий проекта и ваших ощущений. Я, например, всегда даю дизайн-спайкам оценку, даже в аджайл-проектах со story points. Это позволяет мне понять, какие еще задачи могут быть взяты в спринт, а какие придется отложить.
Если на вашем проекте вообще не используют story point, то и проблем нет — используйте оценку в часах.
Иногда я слышу “а набросать хоть ЧТО-НИБУДЬ побыстрее нельзя?”
Нельзя.
Мои наброски без исследований — лишь гипотезы. И, если их не проверить, есть риск не попасть в потребности пользователей, испортить UX. Это отрицательно скажется на проекте и придется тратить средства на переделки.
Если заказчик настаивает на немедленной генерации макетов, спросите, готов ли он взять риск за ваши фантазии на себя.
Однажды я услышала в ответ “почему я должен брать риск, вы же профессионал”. Я потому и профессионал, что разделяю свои представления о пользователях и реальность. Мои теории о потребностях пользователей могут не совпадать с тем, что им в действительности нужно, особенно в сложной предметной области. И это нормально. Именно поэтому существуют пользовательские исследования. Но они требуют времени, как и любая работа. Если этого времени у нас нет — я буду опираться на свое видение и не гарантирую правильность решения.
В случае, если руководство отказывается от дизайн-спайка, ваша задача — обезопасить себя и передать ответственность тому, кто против. Если все понимают и принимают риски — дизайн остается на ваше усмотрение и основывается на ваших гипотезах и додумках.
Помните, что в идеале такой дизайн нужно провалидировать: провести коридорное или юзабилити-тестирование.
Загрузка...
