Как определения экономят десятки рабочих часов

Безумные котики

Shit happens подсказывает опыт. При разработке продукта случаются ошибки, срываются сроки, приходится переделывать целые куски. Разбирая причины фейлов, часто замечаю фразу «не так поняли».

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

Нас же этому учили, ну

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

Как говорил наш преподаватель по матанализу «Если не знаешь определения, тебе даже тройку не за что ставить».

— Пф… зачем тратить на это время? И так же все понятно! 

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

Определяя понятие, стоит сразу обозначить зачем оно вводится, с чем взаимодействует и как себя ведет. Скажем, нужно ли его хранить / обновлять / удалять, когда и где оно существует, при каких условиях изменяется. Если в системе есть похожие понятия — уточнить чем они друг от друга отличаются.

Визитор — посетитель / пользователь / юзер. Определяем по cookie браузера или по UserID, если пользователь авторизован. Два визитора склеиваются, если у них одинаковый email.

Визит — посещение / сессия. Отрезок времени, в течение которого визитор что-то делает на сайте. Если он бездействует 30 мин, визит закрывается. У одного визитора может быть много визитов. Визит без визитора не существует.

Определения помогают выявить ошибки проектирования

Во-первых, если вы пытаетесь определить понятие, но не можете — значит вы придумали фигню 🙂 Во-вторых, если вы что-то упустили, другие члены команды могут легко это найти, спросив, например, «а во всех ли случаях так?».

Кстати, определять стоит не только для понятий из предметной области, но и экзотические дизайнерские элементы. Скажем, говорите вы «эти шаги сделаем аккордеоном» или «подсказки будут на всплывашке» — надо чтобы все понимали, что это и как оно себя ведет. Нет гарантий, что под «всплывашкой» все понимают одно и то же.

Попап  всплывающее модальное окно, закрывающее собой страницу. Пока визитор не закроет попап, он не может взаимодействовать со страницей.

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

Определения облегчают взаимодействие с командой

  1. Когда от руководства или маркетинга поступает задача, она чаще всего сформулирована невнятно. Если первым делом выделить и определить важные понятия и проговорить их, то за минимальное время снимите множество вопросов.
  2. В основном дизайнер или проектировщик общается с программистами. А они — народ технический и мыслят абстрактными моделями и четкими понятиями. Определяя термины, вы облегчите им работу, ускорите процесс и заработаете себе дополнительный респект. А главное, будете уверены, что вас поняли.
  3. В продуктовой компании есть куча народу, которые не имеют прямого отношения к разработке — менеджеры, маркетинг, техподдержка и др. Часто бывает ситуация, что они не знают как сервис работает изнутри. Им некогда читать спецификации, а вот определения вполне могут осилить. Это позволит им лучше представлять себе продукт и грамотнее формулировать вопросы и хотелки разработчикам.

designer_and_programmers

Форма важна

И да, в определениях критичен стиль текста. Никакой канцелярщины, деепричастных оборотов и прочего мусора. Цель определения — прояснить смысл, и добиться однозначного понимания всеми участниками, а вовсе не напустить важности. Умничать не рекомендуется. Использовать спецтермины, непонятные части команды — тоже. Четкости формулировок можно поучиться у Максима Ильяхова.

Нет

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

Да
Онлайн визитор — это посетитель, который сейчас на сайте. Считаем, посетителя онлайн, если от него пришло хотя бы одно событие (обновил страницу, нажал на кнопку др.) за последние 20 секунд.

Бонус — авто-пополнение базы знаний

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

Мы, кстати, так не делаем, поэтому периодически сами забываем элементарные вещи, и юные падаваны задают одни и те же вопросы. Стоит внедрить 🙂

Я не призываю занудствовать, формализовать все используемые в проекте термины и разводить бюрократию. Также не утверждаю, что определения — панацея. Но вводя новое понятие не лишним будет сформулировать, что это и как оно согласуется с остальной системой. Это упростит и сделает более прозрачным проектирование, снизит энтропию, ускорит разработку и улучшит взаимодействие с командой.

Подпишитесь на рассылку новостей. Никакого спама!

Оцените статью
Поделитесь статьей с друзьями
madcats.ru
X