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

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

Вылезаю, озираюсь по сторонам и понимаю, что забыла про то, что у меня есть я, а значит что-то кроме работы и профразвития.

Отношения и близкие люди заброшены, а социальные связи и сети безжизненны.
Сухи как пустыня, и только перекати поле подгоняемое ветром обнаруживает жизнь, пролетая мимо. И ты стоишь, вынырнувший, смотришь на все это, ветер волосы треплет и песок гонит, солнце в глаза светит, а ты понимаешь что ещё пару месяцев сюда не вернёшься.
Ну и ладно. Я ведь не жалуюсь, а радуюсь самореализации 😄

А ещё знаете, вот это, когда у тебя в жизни (да какой там жизни, я про работу конечно) все изменилось до неузнаваемости, а ты ещё полгода рассказать ничего не можешь.
Ибо ну как же рассказать — а вдруг ничего в результате не получится? Или то что ты рассказываешь «как делаю», окажется ошибкой?
Надо историю сложить, осознать и отрефлексировать опыт, а потом рассказывать.


6 лет назад я начала свою карьеру как UX-исследователь. Саня называл это вагиней глубокой UX-аналитики.

С тех пор всё изменилось несколько раз. И всё имеет цикличность.
Только сейчас, спустя 6 лет, пришло осознание, почему роль одинокого(!) начинающего UX-исследователя в большой айтишной компании так сложна и часто обречена на провал.
Об этом подробно расскажу в следующий раз 😉

Качество кода и счастье

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

Вот, к примеру, качество кодовой базы. По-идее, можно очень долго жить с горами говнокода в продакшене — просто нанимаешь в 2–3 раза больше программистов, игнорируешь высокий churn, пытаясь загасить проблему корпоративами/тимбилдингами/мотивацией, и привычно умножаешь все сроки на 3.

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

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

Вчера на сайте бюро вышел первый совет в серии о качестве кода (http://bit.ly/bureau-code-quality), с детальным рассказом о том, зачем это нужно бизнесу. Особенно совет полезен тем, у кого нет времени (или кому не дают времени) на рефакторинг.

Про изучение пользователей

230 млн лет назад (230! млн. лет назад) по Земле ходили Герреразавры — картинка внизу поста.
Это были относительно легкие двуногие хищные динозавры. У них был длинный хвост и довольно маленькая голова. Длина тела примерно 6 метров, а весили порядка 650 кг.

Строение их тела говорит о том, что они довольно быстро бегали. Стопа герреразавров имела пять пальцев, однако полностью развиты были только три средних (II, III и IV). Два остальных (I и V) не несли на себе нагрузку от тела — они были сбоку и имели только коготь. Хвост был укреплен отростками позвонков и играл роль балансира при ходьбе и беге. На первых трёх пальцах передних лап были крупные загнутые когти ими герреразавры хватали и удерживали добычу. Догнал, схватил и съел.

О зверюге, которая жила на Земле 230 миллионов лет назад (аж в голове не укладывается цифра), известно больше, чем многим известно о пользователях, для которых создаётся продукт. Если вы не знаете досконально проблемы или мотивации пользователя, то создать классный продукт меньше шансов. Зачастую команда фокусируется на дизайне и функциях, которые в дальнейшем оказываются абсолютно бесполезными.
Если делать продукты для физлиц, то там вероятность "попасть" в потребность выше, так как команда ближе к проблемам физлиц — сами же люди.
Если делать продукты для бизнеса или государства — то лучшие продукты получаются, как правило, у тех, кто либо сам в этом же бизнесе поработал, либо много времени провёл внутри бизнеса, изучая процессы.

В 2015 году, работая в заказной разработке, я был в составе большой группы, которая делала продукт регионального уровня: муниципальные услуги, сервисы для жителей, мониторинг инвестиционных проектов.
И вот мы пошли на приём к мэру одного из региональных городов — приветливый и умный дядька.
Начали обсуждать сервисы для жителей. Один из сервисов был про активных горожан — отметил место на карте, приложил фотку и отписал, что не так. Все видят, голосуют за самые острые дела, а власть расторопно всё исправляет. У жителей, вероятно спрос был бы, если бы власть реагировала на запросы. Но на деле схема оказалась неработоспособной для небогатых городов (а это почти все). Приветливый и умный дядька нам сказал: "Мы уже знаем о таком количестве проблем, на которые не хватает городского бюджета. Зачем же мы будем давать людям ложную надежду и собирать их ещё больше — мы можем реагировать только на самые острые проблемы". Сервис не зашёл.

В общем, как можно больше и как можно раньше общайтесь с теми, для кого создаёте продукт — можно избежать кучу лишней работы или избежать никому не нужный продукт.

Dropbox оппубликовала пару новых материалов на своем ресурсе dropbox.design.

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

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

---

Ниже просто приведу часть моделей, перечисленных в статье, так скажем, для закрепления:

1) Первоначальный принцип
Заключается в разборе задачи на основные элементы, которые лежат в основе задачи, их реконфигурации и сборке в финальное решение. (см. примеры в статье)

2) Инверсия
Заключается в рассмотрении сценариев ровно противоположных желаемому результату. Формируется образ «антирезультата» и, отталкиваясь от него, формируется путь поиска решения.

3) Лестница абстракций
Используется для поднятия на уровень абстракции выше, чтобы «увидеть лес за деревьями». Начинается с отправной задачи, от которой можно опуститься ниже для детализации, либо подняться выше для поиска альтернативного решения. Для погружения вниз стоит использовать вопрос «Как». Для уход на уровень выше стоит использовать вопрос «Зачем».

Хороший маршрут здесь — подняться от текущей задачи на уровень выше, спросив «зачем», а потом с верхнего уровня пойти в параллельную сторону внизу, спросив «как». (см. примеры в статье)

---

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

Я рекомендую самостоятельно глянуть полную версию статьи, там и с примерами проще понять, о чем речь, и более подробное описание можно почитать — https://dropbox.design/article/mental-models-for-designers

Core Protocols

Когда я пришел в ManyChat, я первый раз услышал про LeSS и пошел читать методичку. А в методичке по LeSS я наткнулся на отсылку к Core Protocols, про которые не слышал раньше, и тоже пошел читать про них.

И если вкратце, Core Protocols — это система фасилитационных техник, направленных на улучшение коммуникации внутри команд.

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

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

На деле получилось 2 списка: список коммитов (обязательств) и список самих протоколов, которые выложены в открытый доступ с открытой лицензией, как софт, и которые со временем дополняются, изменяются, актуализируются.

Сегодня хочется просто привести здесь первую часть, а именно список коммитов. По сути это внутренние обязательства, которые по умолчанию берут на себя все члены команды, тем самым соглашаясь, что они все играют по одним правилам и готовы их соблюдать.

Я их переведу на русский со своими комментариями, и если вы найдете более емкие формулировки, то пишите, я дополню/исправлю:

1) Я обязуюсь участвовать, когда присутствую
Это про то, что если участвуешь во встрече, то участвуешь, а не залипаешь в ноутбуке. Дополнительно расширяется на личную внутреннюю осознанность. Если что-то делаешь, то понимаешь зачем.

2) Я буду стремиться больше воспринимать, чем быть воспринимаемым
Это про то, чтобы слушать и пытаться понять аргументы, а не продавливать свою точку зрения любыми средствами.

3) Я буду использовать команды, особенно при выполнении сложных задач
Это про помощь. Ты должен пользоваться всеми видами помощи, которые можешь получить от людей вокруг, а не пытаться супергеройски вытащить проект, перегореть и уволиться.

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

5) Я буду предлагать и принимать только рациональное, ориентированное на результат поведение и общение
Понимаешь, что разговор эмоциональный, не про цель, на высоких тонах, отмечаешь это и не вписываешься в такую игру.

6) Я буду избегать непродуктивных ситуаций
Если понимаешь, что 23 встречи в неделю не приводят к результату, отмечаешь это, и стараешься не участвовать им, не мешая при этом другим.

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

8) Я буду стремиться двигаться к цели, смещая свое поведение в сторону действия
Всегда разгоняй активным действием, создавай положительную инерцию, которую сложно остановить даже самыми тупыми действиями и комментариями.

9) Я буду использовать протоколы, когда это применимо
Всегда помнишь про протоколы и стараешься их применять каждый раз, когда они нужны.

10) Я никому не причиню вреда—и не потерплю причинения вреда—за его или ее верность этим обязательствам
Если закомитились на core protocols, то не нужно закатывать глаза и проявлять агрессию (даже пассивную), когда тебе кто-то подсветил, что ты наваливаешь не в ту сторону.

11) Я никогда не буду делать ничего глупого нарочно
Вот да!

Это только верхушка, в следующий раз посмотрим на сами коммиты.

Вообще очень рекомендую прочитать оригинал текста с коммитами вот здесь — https://liveingreatness.com/core-protocols/the-core-commitments/

Артём Полтавцев написал о формах записи в салоны красоты

Часто салоны работают с сервисами вроде YClients и Sonline. Виджет сервиса не общается с сайтом салона, и все параметры записи пользователь выбирает через виджет: услуга, студия, мастер, время. В этом случае структуру сайта лучше максимально упростить.

Сервис GBooking можно связать с сайтом по API. Логика заказа: выбор первой услуги → выбор студии → добавление услуг → выбор мастера и времени. Выбор первой услуги ограничивает выбор студий, так как не везде может быть одинаковый набор специалистов и оборудования.

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

https://vc.ru/design/70728