В работе над инструментом Perfetto для отладки производительности автор сталкивается с вопросом: «Как разбить трассировку Perfetto на несколько файлов?» Вместо прямого ответа он спрашивает: «Что заставляет вас собирать трассировки, которые нужно разбивать?» Это главный принцип работы. Когда пользователь задает странный вопрос, нельзя просто разгадать его как загадку. Лучше понять причину этого вопроса. Такой разговор полезен обоим: пользователь лучше поймет философию инструмента, а разработчик узнает, где продукт сбивает людей с толку. Иногда это даже показывает, что сам продукт требует изменений.
Вопросы бывают простые и рутиновые, но интересные случаи, когда что-то нетипично, требуют осторожности. Нужно проверить, встречалось ли это раньше, звучит ли вопрос разумно по сравнению с другими, и не борется ли пользователь с архитектурой инструмента не осознавая этого. После выявления странности автор спрашивает, в чем заключается широкая проблема, которую пытается решить клиент. Обычно это приводит к трем вариантам: пользователь не понимает философию инструмента, правильный путь скрыт в возможностях, которые неочевидны, или продукт действительно должен измениться.
Часто пользователи приходят без четкого понимания задачи. Команды часто работают в условиях дефицита времени и ресурсов, поэтому они ищут инструменты, которые работают не так, как ожидается. Типичный пример: люди приходят в Perfetto, видят, что трассировка — это детальная запись активности устройства, и считают её универсальным решением для любых метрик. Хочется узнать частоту кадров — посчитайте их в трассировке. Хочется узнать использование памяти — посмотрите на выделение и освобождение памяти. Теоретически любую метрику можно вычислить. Но это плохая идея. Сбор и обработка всех данных системы требует огромных ресурсов. Гораздо эффективнее использовать систему, настроенную на сбор конкретных метрик выборочно.
Другой случай, когда инструмент спрятал правильный ответ. Команда понимает проблему, но не видит, как совместить имеющиеся средства. Инструменты мощны, но другие команды могут не знать всего их потенциала. Пример с разделением трассировок. Пользователи хотят разрезать длинные записи на части для удобства визуализации или производительности. Но автор напоминает о поддерживаемых периодических снимках трассировки — коротких повторных записях вместо одной длинной. Пользователи пытаются решить проблему, которой у них не должно быть вообще. Это очень приятно видеть, когда после такого объяснения говорят: «Именно это мне и нужно!».
Иногда запрос открывает путь к созданию чего-то нового, но рисковать рано. Стоимость ошибок в фундаментальном ПО высока. Лучше не строить функционал, пока его отсутствие сильно не вредит. Обычно одного запроса мало, чтобы понять суть задачи, поэтому ожидание оказывается мощным инструментом. Пример с кастомизацией интерфейса Пользователи хотели менять UI под свои нужды и жаловались на сложность. Разработчики позволили это сделать, но быстро набрали огромный технический долг. Каждая новая фича мешала всем остальным, и масштабирование стало невозможным. Ушло около года, чтобы исправить это с помощью правильной API для плагинов. Реальная потребность — возможность персонализировать интерфейс для своей команды или задачи, не влияя на других. Никто не мог назвать это требование заранее, но задача была распознана вовремя.
Разрешение слияния трассировок — пример успешного подхода. Люди постоянно спрашивали об этом, но разработчики сопротивлялись, указывая на обходные пути. Они знали, что реализация требует много работы и легко может быть ошибочна, поэтому ждали. В прошлом году они наконец построили это решение надежным способом именно потому, что так хорошо поняли область проблемы. Главный вывод: первый вариант вопроса редко отражает реальную суть. Нужно спрашивать «почему» перед тем как отвечать. Ответ может научить пользоваться инструментом, показать скрытый путь или указать на то, что строить пока нечего. Методика проста, но её легко пропустить из-за желания быстро откликнуться. Каждый быстрый ответ кажется продуктивным, но стоит сделать шаг назад. В итоге обе стороны почти всегда уходят с большим收获ом, чем пришли.