Shit happens подсказывает опыт. При разработке продукта случаются ошибки, срываются сроки, приходится переделывать целые куски. Разбирая причины фейлов, часто замечаю фразу «не так поняли».
Недопонимание случается на всех этапах работы: от обсуждения первоначальных требованиях до конечной реализации. Причем возникает в совершенно неожиданных местах — то, что очевидно для тебя, коллеги воспринимают иначе и действует согласно своему восприятию. В результате — делается не то или не так.
Нас же этому учили, ну
После очередного фейла с недопониманием, один из программистов предложил элементарное решение — явно вводить определения для новых понятий. Как в университете. Начинается новая тема — определяем основные термины. Пока не поняли термины дальше идти смысла нет.
Как говорил наш преподаватель по матанализу «Если не знаешь определения, тебе даже тройку не за что ставить».
— Пф… зачем тратить на это время? И так же все понятно!
Курьез в том, что оно кажется понятным ровно до того момента, как начинаешь формулировать. Простая вербализация выявляет много неожиданного — крайние случаи, условия, нестыковки…
Определяя понятие, стоит сразу обозначить зачем оно вводится, с чем взаимодействует и как себя ведет. Скажем, нужно ли его хранить / обновлять / удалять, когда и где оно существует, при каких условиях изменяется. Если в системе есть похожие понятия — уточнить чем они друг от друга отличаются.
Визитор — посетитель / пользователь / юзер. Определяем по cookie браузера или по UserID, если пользователь авторизован. Два визитора склеиваются, если у них одинаковый email.
Визит — посещение / сессия. Отрезок времени, в течение которого визитор что-то делает на сайте. Если он бездействует 30 мин, визит закрывается. У одного визитора может быть много визитов. Визит без визитора не существует.
Определения помогают выявить ошибки проектирования
Во-первых, если вы пытаетесь определить понятие, но не можете — значит вы придумали фигню 🙂 Во-вторых, если вы что-то упустили, другие члены команды могут легко это найти, спросив, например, «а во всех ли случаях так?».
Кстати, определять стоит не только для понятий из предметной области, но и экзотические дизайнерские элементы. Скажем, говорите вы «эти шаги сделаем аккордеоном» или «подсказки будут на всплывашке» — надо чтобы все понимали, что это и как оно себя ведет. Нет гарантий, что под «всплывашкой» все понимают одно и то же.
Попап — всплывающее модальное окно, закрывающее собой страницу. Пока визитор не закроет попап, он не может взаимодействовать со страницей.
Нотификация — немодальное окно, всплывающее поверх страницы. Не мешает пользователю взаимодействовать с контентом, в том числе прокручивать. Как правило, нотификация меньше попапа и всплывает сбоку.
Определения облегчают взаимодействие с командой
- Когда от руководства или маркетинга поступает задача, она чаще всего сформулирована невнятно. Если первым делом выделить и определить важные понятия и проговорить их, то за минимальное время снимите множество вопросов.
- В основном дизайнер или проектировщик общается с программистами. А они — народ технический и мыслят абстрактными моделями и четкими понятиями. Определяя термины, вы облегчите им работу, ускорите процесс и заработаете себе дополнительный респект. А главное, будете уверены, что вас поняли.
- В продуктовой компании есть куча народу, которые не имеют прямого отношения к разработке — менеджеры, маркетинг, техподдержка и др. Часто бывает ситуация, что они не знают как сервис работает изнутри. Им некогда читать спецификации, а вот определения вполне могут осилить. Это позволит им лучше представлять себе продукт и грамотнее формулировать вопросы и хотелки разработчикам.
Форма важна
И да, в определениях критичен стиль текста. Никакой канцелярщины, деепричастных оборотов и прочего мусора. Цель определения — прояснить смысл, и добиться однозначного понимания всеми участниками, а вовсе не напустить важности. Умничать не рекомендуется. Использовать спецтермины, непонятные части команды — тоже. Четкости формулировок можно поучиться у Максима Ильяхова.
Нет
Онлайн визитором является посетитель, находящийся на нашем сайте и осуществляющий какие-либо действия (в том числе переходы между страницами, сабмиты форм обратной связи, совершение покупок и др.). Соответствующие евенты присылаются на бекенд в режиме реального времени. Таймаутом активности считается 20 секунд с момента регистрации последнего евента.
Да
Онлайн визитор — это посетитель, который сейчас на сайте. Считаем, посетителя онлайн, если от него пришло хотя бы одно событие (обновил страницу, нажал на кнопку др.) за последние 20 секунд.
Бонус — авто-пополнение базы знаний
Если собирать определения в одном месте, то сама собой сформируется база знаний по основным терминам, к которой можно будет обращаться в спорных ситуациях и отсылать к ней новых сотрудников.
Мы, кстати, так не делаем, поэтому периодически сами забываем элементарные вещи, и юные падаваны задают одни и те же вопросы. Стоит внедрить 🙂
Я не призываю занудствовать, формализовать все используемые в проекте термины и разводить бюрократию. Также не утверждаю, что определения — панацея. Но вводя новое понятие не лишним будет сформулировать, что это и как оно согласуется с остальной системой. Это упростит и сделает более прозрачным проектирование, снизит энтропию, ускорит разработку и улучшит взаимодействие с командой.