work engineering-management

Создание эффективной инженерной культуры с помощью принципов UX-дизайна

7 марта 2023 г.

Не заставляйте меня думать

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

Как дизайнер, мы хотим предвидеть потребности наших пользователей и потенциальные ошибки, проектируя таким образом, чтобы пользователю было трудно (или даже невозможно) совершить ошибку. В своей книге "Дизайн повседневных вещей" Дэн Норман доходит до того, что утверждает, что в любой ошибке пользователя виноват дизайн, а не пользователь.

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

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

Исследования показали, что сосредоточенность и самоконтроль подобны мышцам — вы получаете ограниченное количество в день, пока оно не истощится. Кэл Ньюпорт в своей книге «Глубокая работа» пишет, что большинству людей доступно максимум 1,5 часа «глубокой концентрации» в день (именно такая концентрация нужна для задач с большой умственной нагрузкой — решения проблемы, которую вы не имеете). невиданный ранее, творческий мозговой штурм, изучение новых сложных знаний, в отличие от более простых задач, таких как проверка электронной почты или ввод данных).

Естественно, время тоже является ограниченным ресурсом. Каждый раз, когда разработчик тратит 1–2 часа (или 5 минут, или 10 секунд снова и снова) на решение проблемы, вызванной болевой точкой, которую можно было бы предвидеть и избежать, — это 1–2 часа, которые он не может сделать. их важная работа и оставляет их с истощенной концентрацией, доступной для их остающихся задач в течение дня. Если одна и та же проблема требует времени от нескольких разработчиков в разных командах, это быстро складывается.

Вместо того, чтобы «не заставлять моих инженеров думать» , мы хотим не заставлять наших инженеров думать, когда им это не нужно, чтобы они могли сэкономить свое время и глубокие размышления для решения важных задач.

Как применять философию «Не заставляйте меня думать»

Каковы примеры применения (или неприменения) этой философии в инженерной организации?

В кодовой базе:

Пишите чистый код.

Я беру свою философию написания кода из книги "Чистый код", которая заключается в том, чтобы сделать мой код как можно более читабельным, сделав его как можно ближе к письменной английской прозе. Это означает многословие — описательные слова в именах функций, как правило, отказ от аббревиатур, отказ от вложенных троичных элементов, обычно (хотя и не всегда) предпочтение операторам if/else троичным. Сравните: if (isEntryValid) {submitForm()} else {displayError()} vs { this.quantity.isInteger() && this.name.length : submit() ? отображениеОшибка()}. Первый предполагает меньше размышлений и расшифровки, чтобы понять, что происходит.

* Приведите код к наименьшему знаменателю.

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

* Напишите (и автоматизируйте!) модульные тесты.

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

* Используйте линтер для обеспечения соблюдения стандартов кодирования.

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

* Уделите приоритетное внимание рефакторингу и очистке заявок .

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

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

Управление репозиторием:

Отдавайте приоритет написанию и ведению сопроводительной документации .

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

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

2. Вводная документация выходит за рамки «как настроить репозиторий» и включает в себя список основных технологий, используемых в репозитории (и, возможно, ссылки на рекомендуемые руководства по этим технологиям), URL-адреса общих групп с закладками. и расширения для браузера, а также ссылки на внутренние документы, такие как стандарты кодирования, глоссарий проекта или устранение неполадок. Одна компания, в которой я работал, использовала менее известную библиотеку React State, и я даже не слышал о ней до трех месяцев работы в ней. Как только я это сделал, я нашел учебник, изучил основы и нашел код намного более понятным. Мне бы очень хотелось получить эту информацию в первую же неделю.

3. Документ по устранению неполадок — это место, где мы собираем скриншоты и решения распространенных проблем, возникающих в течение первых нескольких месяцев работы с репозиторием, прежде чем вы настолько освоитесь с кодовой базой, что перестанете создавать их инстинктивно. Всегда ли забывание запустить npm install вызывает определенную неразборчивую ошибку? Большой. Приводит ли осознание того, что вы находитесь не в той среде, абсолютно пустой браузер без ошибок? Прохладный. Для новых разработчиков (и для опытных разработчиков, которые случайно допустили старую ошибку) хранение всех этих данных в одном месте может сэкономить много времени.

* Выберите «скучную технологию».

Написанная Дэном МакКинли в 2015 году статья "Выберите скучную технологию" утверждает, что у существующих технологий меньше "неизвестных неизвестных" (ошибок и сбоев, которые еще предстоит обнаружить), а также больше документации и поддержки. С другой стороны, у более новых, захватывающих технологий не было таких же возможностей для использования, проверки, документирования и устранения ошибок. Часто это помогает вашей компании и вашим разработчикам сделать выбор в пользу задокументированных, известных технологий, а не интересных и рискованных технологий.

* Автоматизация линтеров и модульных тестов.

Использование линтеров для обеспечения соблюдения стандартов кодирования упоминалось в последнем разделе, и по умолчанию разработчики должны вручную запускать команду для запуска линтеров и модульных тестов. Конечно, даже самые внимательные к деталям сотрудники иногда забывают о таких вещах, и не стоит тратить время компании на то, чтобы рецензенты кода указывали на неудачные модульные тесты или на наличие ошибок линтера (и затем требовали дополнительного толчка, тестирования). и проверка кода).

В организационных процессах:

Четкие и подробные тикеты для активных задач — один из наиболее важных способов, с помощью которых организация может сократить ненужные временные затраты. Это включает в себя проверку ВСЕХ требований и наличие «критериев приемлемости», которые сообщают, что должно присутствовать для выполнения заявки.

Кроме того, если тикет создан из беседы в неактивном состоянии, включите ссылку на беседу в неактивном состоянии. Обычно в слабых комментариях есть много контекста, которые не включаются в тикет. Например, одна команда, с которой я работал, помечала заявки как «готовые к работе» после того, как они были обработаны, даже если у них были нерешенные вопросы по дизайну или продукту, на которые нужно было найти ответы. Это означало, что когда разработчик был готов приступить к задаче, ему приходилось тратить время на поиски коллеги (возможно, ожидание в течение нескольких часов, если у него был плотный график совещаний , или дней, если он был ООО), чтобы получить ответ, прежде чем он мог начаться. Им придется решить, следует ли им взяться за другую задачу, пока они ждут ответа (они не знают, получат ли они ответ через 2 минуты или 5 часов).

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

* Рассмотрите возможность добавления разделов «заметки разработчиков» в заявки.

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

* Найдите практичные способы управления объявлениями о необходимых задачах и обновлениях.

Одна компания, в которой я работал, сообщала об обновлениях личных сред разработки через Slack. Эти объявления будут быстро заглушены другими сообщениями. Многие из этих обновлений потребуются — «мы только что отправили x, после вашего следующего извлечения вы должны запустить команду y, иначе репозиторий больше не будет работать локально для вас».

Конечно, люди, как правило, не будут тянуть, пока не закончат тикет, над которым работают, что может произойти через несколько дней или через неделю. В обязательном порядке через неделю или две после этих объявлений вы увидите, как разработчики просят о помощи, потому что что-то не работает, и обычно им требуется 1-2 часа, чтобы возиться и получать предложения от других, прежде чем кто-то запомнит это объявление. .

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

* Держите ретро.

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

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

В своей книге «Углубленная работа» Кэл Ньюпорт рассказывает, что существует особый тип концентрации — «глубокая концентрация» , — который требуется для решения сложных задач. Переключение контекста требует не только времени, но и концентрации . Крис Парнин, исследователь из Ninlabs, обнаружил, что разработчикам требуется 10–15 минут, чтобы восстановить свой рабочий процесс кодирования после прерывания, и что прерванная задача кода занимает вдвое больше времени и содержит вдвое больше ошибок. как непрерывная задача. Если вы планируете собрания команды, постарайтесь запланировать их таким образом, чтобы у разработчиков было достаточно времени для непрерывного написания кода.

* Не вознаграждайте "тактические торнадо".

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

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

Одна компания, в которой я работал, настроила так, чтобы статусы тикетов Jira автоматически обновлялись в зависимости от изменений кода : создание ветки автоматически устанавливало для тикета статус «в процессе», создание запроса на вытягивание устанавливало для него статус «на рассмотрении», слияние установило для билета статус «Готово». Существуют интеграции с slack, которые автоматически установят ваш slack на «нет» (с отключенными уведомлениями), когда вы находитесь на собрании в своем календаре. Может быть легко не тратить время на очистку инженерных процессов организации, потому что задачи, стоящие перед клиентами, кажутся наиболее срочными, а сотрудникам платят за то, чтобы они были здесь, чтобы решать и решать проблемы. По словам бывшего менеджера, «они взрослые люди, они разберутся».

Хотя для разработчика определенно менее приятный опыт работы, когда ему приходится прыгать через обручи или постоянно преодолевать ненужные препятствия, в конце концов, расплачивается за это компания. Когда разработчики тратят несколько часов в месяц на исправление проблем, которые можно было бы автоматизировать, эти часы можно было бы потратить на создание новой интересной функции, ориентированной на клиентов. Когда команде приходится отказаться от своей дорожной карты на шесть недель, чтобы получить за последние 6 месяцев рабочую функцию во втором наборе компонентов, созданном другой командой, это 6 недель разработки всей команды, которые компания не получит обратно. Когда через 2 года в унаследованном коде есть ошибка без документации, 3 недели вместо 1 недели, которые требуются для диагностики и исправления ошибки, — это время, которое компания никогда не вернет. Когда новым разработчикам требуется 6 месяцев вместо 2, чтобы почувствовать себя комфортно в новом репозитории, это на 4 месяца меньше, чем могла бы достичь компания. Мы уже понимаем, что предвидеть и уменьшать болевые точки — это то, как мы поддерживаем наших клиентов («они взрослые, они могут понять это» — образ мышления, который приведет к большому количеству потерянных клиентов и доходов), если мы адаптируем этот образ мышления к инженерным культур, мы поддерживаем наших разработчиков уже сейчас, а также долгосрочную отказоустойчивость нашей кодовой базы.