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

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

Инженер-разработчик Остин Хэнли в офисе Microsoft

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

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

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

Система должна была показывать историю замечаний всей команде и ускорить рабочие процессы в целом.

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

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

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

Как выглядят системные предупреждения в коде Остин Хэнли

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

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

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

Остин Хэнли, разработчик

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

  • Отфильтровала типы предупреждений по степени важности.
  • Установила ограничение на количество отображаемых плашек.
  • Попросила программу не повторять одни и те же замечания.

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

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

  • Человек не будет пользоваться функцией, если для этого требуется много усилий. Даже если она полезная.
  • Новый инструмент не должен нарушать привычный для пользователя рабочий процесс.
  • Прежде чем приступать к разработке функции, нужно определить её место в системе. Возможно, она принесёт продукту гораздо большую ценность, если её «докрутить».
  • Не стоит ничего решать за пользователя — лучше с ним поговорить. А ещё нельзя его недооценивать: он гораздо умнее, чем кажется на первый взгляд.
  • Оценивать промежуточный прогресс нужно постоянно и коллективно, чтобы предугадать возможные трудности.
  • Нужно быть готовым изменять стратегию и переделывать продукт.
Фото со времен стажировки Хэнли в Microsoft Остин Хэнли

История Хэнли нашла отклик у пользователей Hacker News

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

  • «Помню, говорил как-то с неопытным продакт-менеджером. Тот искренне верил, что компании нужно добавить такую-то функцию, потому что этого просит клиент. Сам я продактом не был, но в работе понял: нельзя давать пользователю то, чего он просит, — нужно понять, что ему нужно. Ведь зачастую он просто не знает, как точно сформулировать запрос».

  • «Почему функцию не используют? Да тут масса возможных причин: она никому не нужна; никто не может её найти или не знает, как она работает и зачем; возможно, она на самом деле и не работает вовсе или постоянно ломается. А ещё компании иногда неправильно позиционируют свои инструменты».
  • «Убедитесь, что это не единичный запрос, а желание всей аудитории. Иначе компания превратит продукт в кашу и только впустую потратит время. Если вложения не окупятся, значит нужно от них отказаться. Исключение — если функции нужны, чтобы не нарушать законы».
  • «Если отказаться от ненужной функции не получается, предложите пользователю нерабочий вариант. Если все примут это как должное, то функция изначально была не нужна. Если начнут жаловаться на ошибку, то, возможно, прислушаться к желаниям всё же стоит».
  • «Один мой начальник считал себя великим прагматиком — вечно давал конкретные задачи: "Добавьте кнопку вот сюда" или "Я хочу, чтобы вкладку видели только такие-то пользователи". Его клиенты об этом просили. Звучит, вроде, нестрашно, но это самый быстрый способ создать в проекте беспорядок».
  • «Однажды я неделю работал над довольно сложной функцией, о которой клиенты спрашивали каждый день. А после релиза случайно встретился с одним из тех пользователей и узнал: сам он функцию не использовал и вообще о ней не знал».
  • «Моя команда разработала систему управления рабочими процессами для одной компании. Она отдала за работу целых €300 тысяч… чтобы потом продукт почти не использовать. При этом платить за хостинг и поддержку компания продолжала. Через пару месяцев оказалось, что система решала слишком узкие задачи и в итоге не вписалась в их процессы».
  • «Я управляю службами переадресации электронной почты. У нас был один крупный клиент с сотнями доменов для пересылки, но наш интерфейс для такого числа адресов не подходил. Он попросил нас разработать иерархическую структуру внутри системы, и мы согласились: клиент работал с нами по премиальному плану, поэтому такие запросы были для нас в приоритете. Задачу мы выполнили, но через два дня этот же пользователь перешёл на самый дешёвый план и удалил все свои домены. Та самая иерархическая структура, кроме него, оказалась никому не нужна».
0
22 комментария
Написать комментарий...
Иван Миронов
"Новый инструмент не должен нарушать привычный для пользователя рабочий процесс."

И не затрагивать привычный интерфейс. Люди консервативны по своей сути. Разрешите пользователю кастомизацию и не меняйте привычные вещи - сможете избежать некоторой доли критики. 
Но несмотря на жалобы пользователей - они привыкнут.
Постоянно вспоминаю опыт "Вконтакте". Выходит обнова. Люди её критикуют (справедливо), но все равно привыкают. 

Ответить
Развернуть ветку
Полина Лааксо
Автор

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

Ответить
Развернуть ветку
Антон Смуров

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

Ответить
Развернуть ветку
Куприян Ермаков

Я сейчас всё объясню.
1) Дело в том, что разработчики мои, вы обычно всё через задницу делаете (ну я сам не отличаюсь сообразительностью, тоже так же делаю), причём скилы тут вообще не играют роли, будь ты рукожопом или нет, всё рано через задницу. Потому что банально, прогеры просто (большинство, но не все) шизоиды (не путайте с шизофрениками, хотя, кто живёт в США, для тех это одно и то же - по законодательству) и интроверты... 
2) А давай ка мы эту фичу будем включать после доплаты, - решили разработчики. А пользователи в ответ подумали, - идите на куй, и продолжили делать всё по старому, а у разработчиков статистика начала показывать, что функцией мало кто пользуется... 

Ответить
Развернуть ветку
Артем Гарбарт

Не переносите свой субъективный опыт общения с программистами на всех программистов. Мы не «шизоиды», в основной массе :)
А все эти приколы, что мы не моемся неделями, смотрим аниме и постоянно сидим дома – не более чем приколы.

Ответить
Развернуть ветку
Aidar S
А все эти приколы, что мы не моемся неделями, смотрим аниме и постоянно сидим дома – не более чем приколы.

Ну вот что вы за всех так сразу..

Ответить
Развернуть ветку
irmr

Вайтишечку не смог, диванный эксперт?)

давай ка мы эту фичу будем включать после доплаты, - решили разработчики

Вот это уровень экспертизы, вот это познания о сфере

Ответить
Развернуть ветку
Максим Федоров

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

то есть из-за таких, как вы это и происходит

Ответить
Развернуть ветку
Михаил Белов

Разработчики делают код фичи. Но требования к ней пишет руководитель продукта от бизнеса. Ну или CEO, если компания небольшая. Что попросят, то и запилят.
Вы сейчас продемонстрировали полное непонимание процессов в it. Ещё и зачем-то на разработчиков наехали.  

Ответить
Развернуть ветку
Владимир Ульянов

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Лев Александров-грачевский- фельдманн

ТЗ от заказчика :  сделайте хорошо, а плохо не делайте. Спасибо.

Ответить
Развернуть ветку
Аналитик Толян

SCRUM? Нет, не слышал.

Ответить
Развернуть ветку
Михаил Лабинцев

Охерительные истории от компании, которая меню пуск сдвинула на середину и сделала так, что нужно лишний клик делать, чтобы добраться до полноценного контекстного меню.И продает это как новую операционную систему. Кто их просил?!  На кой нужны все эти умные мысли, если по итогу всё равно говно какое-то выходит? Очень здорово, что разработчик все это понял. Пускай теперь пойдет и руководству объяснит.

Microsoft, сделайте уже реплаи в Teams и нормальную загрузку интерфейса.  Почему всё лагает и тормозит? Это же просто текстовые сообщения. Какого оно грузит по 600 метров оперативы, когда просто диалог открыт? Почему Дуров может сделать нормально с командой в 15 человек, а гигантская корпорация нет? 

Ответить
Развернуть ветку
Айдар Висимо

Все это дойка быдла.

Ответить
Развернуть ветку
sagrer128 .

Потому что Дурову пофиг что C++ это "нимодна", поэтому клиент у него написан нормально а не на каком-нибудь электроне.

Ответить
Развернуть ветку
Дмитрий Николаевич

БУду первый :) То есть  разрабы(и те кто с ними связан) прост не читали про лин стартап, про "Спроси маму", маркетолог типа Уэлча - то есть вообще игнорировали опыт других компаний и настоятельные рекомендации от успешно набивших шишки
.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
sagrer128 .

"Кто все эти люди?" (с)

Ответить
Развернуть ветку
Артем Салютин

Читал летом про стартап, кажется RevOps или DevRev называется. Суть в том, чтобы за выручку отвечали программисты, то есть предлагали фичи и делали их сами. И это чудо собрало 50 млн посевных! 

Ответить
Развернуть ветку
ValKo

Попробуйте заняться Аутлук  - ui ux недоразумение 

Ответить
Развернуть ветку
Иван Рязанов

Microsoft огромная компания, ужас!

Ответить
Развернуть ветку
19 комментариев
Раскрывать всегда