Разработчики жалуются, что выпускают ненужные пользователям функции — чаще всего по их же просьбам
Инженер Остин Хэнли рассказал, как стажировался в Microsoft и трижды переделывал инструмент для разработчиков. Всё потому, что они сами не объяснили, чего хотят. Пользователям Hacker News ситуация знакома — они обсудили, как подходить к пользовательским запросам и все ли стоит выполнять.
Компании, которые изучают поведения пользователей, знают: предложи клиенту новую функцию, и тот скажет «да». Ведь никто не станет противиться новым возможностям. Вопрос лишь в том, будет ли клиент ими пользоваться. И об этом фирма узнает только после релиза.
Проблему на своём опыте познал Остин Хэнли — инженер-разработчик из США. Программированием он занялся в конце 1990-х годов: сперва в Visual Basic 6.0, затем в Visual C++ 6, а после — Visual C# 2008. Всё то время он мечтал поработать в Microsoft, знакомился с сотрудниками компании на конференциях, но помощь никто не предлагал.
Тогда он отправил несколько писем двум исследовательским группам и после собеседований получил стажировку. Его новая команда работала над корпоративным инструментом для поверки кода (code review), которым еженедельно пользовались около 30 тысяч сотрудников. Теперь она хотела создать «автоматизированного рецензента», который проверял бы код на соответствие и выдавал отчёт.
Система должна была показывать историю замечаний всей команде и ускорить рабочие процессы в целом.
Сначала Хэнли изучил, как разработчики рецензируют код, взаимодействуют с системой и какими техническими характеристиками она обладает. Он записывал видео во время проверок и лично общался с инженерами. «Оставалось лишь создать инструмент, чтобы решить проблему, которая, как мы верили, у разработчиков была», — вспоминает Хэнли.
У разработчиков уже был прототип, который нужно было адаптировать под конкретную задачу. Казалось, разработка займет недели две, но возникли проблемы. Все, кто работал над прототипом, покинули компанию, а разобраться в коде самостоятельно было трудно: он содержал около 500 тысяч строк.
«Код придётся писать с нуля», — понял Хэнли. Через месяц он показал нескольким коллегам десктопную программу и получил разрешение на тестирование. Инженер составил руководство по использованию. Инструмент был готов к работе.
Вот только запустили его единицы и при этом никак с ним не взаимодействовали. Остальные к нему даже не притронулись. Хэнли знал, что «автоматизированный рецензент» был им нужен, поэтому понял, что это он что-то упустил.
Он ещё раз изучил, как разработчики проверяют код сами, а затем попросил их воспользоваться программой, не давая никаких инструкций. Оказалось, что её использование не вписывалось в привычный для программистов рабочий процесс — поэтому они не стали даже разбираться, пишет Хэнли.
После коллективного обсуждения мы представили часть функций десктопного приложения в виде расширения. Оно в фоновом режиме отслеживало изменения в коде, само запускало автоматическую проверку и составляло замечания. Рабочий процесс при этом оставался неизменным.
Хэнли и его коллеги протестировали расширение в небольшой команде, но ей оно не понравилось: приложение выдавало слишком много предупреждений, которые мешали работе. Тогда группа установила ограничения, чтобы программа «не бомбардировала разработчиков информацией»:
- Отфильтровала типы предупреждений по степени важности.
- Установила ограничение на количество отображаемых плашек.
- Попросила программу не повторять одни и те же замечания.
Инструмент в конечном счёте использовали 98 инженеров-разработчиков на протяжении 15 недель. По словам Хэнли, автоматические предупреждения нередко помогали им заметить проблему на начальных этапах разработки.
Сейчас информатик понимает, что мог бы додуматься до всего этого изначально — или хотя бы подробнее расспросить коллег о том, каким они видят потенциальное расширение. Но главное, что он вынес для себя несколько уроков:
- Человек не будет пользоваться функцией, если для этого требуется много усилий. Даже если она полезная.
- Новый инструмент не должен нарушать привычный для пользователя рабочий процесс.
- Прежде чем приступать к разработке функции, нужно определить её место в системе. Возможно, она принесёт продукту гораздо большую ценность, если её «докрутить».
- Не стоит ничего решать за пользователя — лучше с ним поговорить. А ещё нельзя его недооценивать: он гораздо умнее, чем кажется на первый взгляд.
- Оценивать промежуточный прогресс нужно постоянно и коллективно, чтобы предугадать возможные трудности.
- Нужно быть готовым изменять стратегию и переделывать продукт.
История Хэнли нашла отклик у пользователей Hacker News
Проблема оказалась хорошо знакома завсегдатаям новостного агрегатора Hacker News. Те поспешили поделиться своими размышлениями:
«Помню, говорил как-то с неопытным продакт-менеджером. Тот искренне верил, что компании нужно добавить такую-то функцию, потому что этого просит клиент. Сам я продактом не был, но в работе понял: нельзя давать пользователю то, чего он просит, — нужно понять, что ему нужно. Ведь зачастую он просто не знает, как точно сформулировать запрос».
- «Почему функцию не используют? Да тут масса возможных причин: она никому не нужна; никто не может её найти или не знает, как она работает и зачем; возможно, она на самом деле и не работает вовсе или постоянно ломается. А ещё компании иногда неправильно позиционируют свои инструменты».
- «Убедитесь, что это не единичный запрос, а желание всей аудитории. Иначе компания превратит продукт в кашу и только впустую потратит время. Если вложения не окупятся, значит нужно от них отказаться. Исключение — если функции нужны, чтобы не нарушать законы».
- «Если отказаться от ненужной функции не получается, предложите пользователю нерабочий вариант. Если все примут это как должное, то функция изначально была не нужна. Если начнут жаловаться на ошибку, то, возможно, прислушаться к желаниям всё же стоит».
- «Один мой начальник считал себя великим прагматиком — вечно давал конкретные задачи: "Добавьте кнопку вот сюда" или "Я хочу, чтобы вкладку видели только такие-то пользователи". Его клиенты об этом просили. Звучит, вроде, нестрашно, но это самый быстрый способ создать в проекте беспорядок».
- «Однажды я неделю работал над довольно сложной функцией, о которой клиенты спрашивали каждый день. А после релиза случайно встретился с одним из тех пользователей и узнал: сам он функцию не использовал и вообще о ней не знал».
- «Моя команда разработала систему управления рабочими процессами для одной компании. Она отдала за работу целых €300 тысяч… чтобы потом продукт почти не использовать. При этом платить за хостинг и поддержку компания продолжала. Через пару месяцев оказалось, что система решала слишком узкие задачи и в итоге не вписалась в их процессы».
- «Я управляю службами переадресации электронной почты. У нас был один крупный клиент с сотнями доменов для пересылки, но наш интерфейс для такого числа адресов не подходил. Он попросил нас разработать иерархическую структуру внутри системы, и мы согласились: клиент работал с нами по премиальному плану, поэтому такие запросы были для нас в приоритете. Задачу мы выполнили, но через два дня этот же пользователь перешёл на самый дешёвый план и удалил все свои домены. Та самая иерархическая структура, кроме него, оказалась никому не нужна».