Разработчики жалуются, что выпускают ненужные пользователям функции — чаще всего по их же просьбам

Инженер Остин Хэнли рассказал, как стажировался в Microsoft и трижды переделывал инструмент для разработчиков. Всё потому, что они сами не объяснили, чего хотят. Пользователям Hacker News ситуация знакома — они обсудили, как подходить к пользовательским запросам и все ли стоит выполнять.

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

Проблему на своём опыте познал Остин Хэнли — инженер-разработчик из США. Программированием он занялся в конце 1990-х годов: сперва в Visual Basic 6.0, затем в Visual C++ 6, а после — Visual C# 2008. Всё то время он мечтал поработать в Microsoft, знакомился с сотрудниками компании на конференциях, но помощь никто не предлагал.

Тогда он отправил несколько писем двум исследовательским группам и после собеседований получил стажировку. Его новая команда работала над корпоративным инструментом для поверки кода (code review), которым еженедельно пользовались около 30 тысяч сотрудников. Теперь она хотела создать «автоматизированного рецензента», который проверял бы код на соответствие и выдавал отчёт.

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

У разработчиков уже был прототип, который нужно было адаптировать под конкретную задачу. Казалось, разработка займет недели две, но возникли проблемы. Все, кто работал над прототипом, покинули компанию, а разобраться в коде самостоятельно было трудно: он содержал около 500 тысяч строк.

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

Вот только запустили его единицы и при этом никак с ним не взаимодействовали. Остальные к нему даже не притронулись. Хэнли знал, что «автоматизированный рецензент» был им нужен, поэтому понял, что это он что-то упустил.

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

Хэнли и его коллеги протестировали расширение в небольшой команде, но ей оно не понравилось: приложение выдавало слишком много предупреждений, которые мешали работе. Тогда группа установила ограничения, чтобы программа «не бомбардировала разработчиков информацией»:

Инструмент в конечном счёте использовали 98 инженеров-разработчиков на протяжении 15 недель. По словам Хэнли, автоматические предупреждения нередко помогали им заметить проблему на начальных этапах разработки.

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

Проблема оказалась хорошо знакома завсегдатаям новостного агрегатора Hacker News. Те поспешили поделиться своими размышлениями:

#разработка #функциональность