Як staff-інженер знаходить проблеми, варті роботи

Staff-інженер, який працює над інструментом продуктивності Perfetto, виклав відповідь, яку дає колегам, що готуються до підвищення: як знаходити проблеми, варті роботи. Його метод — не виділена в календарі година «стратегічного мислення», а звичка вбирати інформацію, як губка, і дозволяти проблемам накопичуватися.

Вбирайте проблеми, а не запити

Люди постійно розповідають про свої труднощі — на зустрічах, у чатах, презентаціях і листах. Коли щось стосується його ділянки, автор тягне за нитку: питає, чи вирішила б проблему гіпотетична функція або яку частину сценарію покриває вже наявна, замість того щоб сприймати запит буквально. Користувачі, зауважує він, зазвичай просять конкретне рішення, а не описують корінь проблеми.

Коли проблема видається вартою уваги, він стає активнішим: сидить із командою, дивиться на її робочі процеси, сам намагається відтворити помилки, які вона досліджує. Він також шукає людей, які бачать організацію ширше за нього — власників критичних систем, інженерів, що працюють у кількох командах, — бо вони часто вже помітили ту саму проблему в кількох місцях.

Дайте проблемам накопичитися

Його вже пекло від надто швидкої реакції на запит гучної команди: функцію збудували, а користувалися нею майже ніхто. Тож він робить нотатку й чекає. Проблема, що незалежно виринає в кількох командах, — сильніший сигнал; різні на вигляд проблеми можуть мати спільну форму, яку закриває одне рішення; іноді сама команда розуміє, що функція їй не потрібна.

Коли ідея набуває обрисів, він перевіряє її проти інших проблем у голові — часто під час довгих прогулянок Лондоном. До відчуття елегантності ставиться обережно: одну ідею, яка, на його думку, вирішувала дві проблеми одразу, після RFC і прототипу довелося розділити навпіл, бо їх краще було обробляти окремо, і обидві частини вже випущено.

Від запитів на функції до розширень

Perfetto показує записи системної активності на часовій шкалі з рядків, які називаються треками. Роками команди просили вузькі функції інтерфейсу: тримати їхні треки вгорі, відкривати запис уже наближеним до потрібної ділянки, показувати власну агрегацію. Автор дійшов висновку, що справжня потреба — не окрема функція, а можливість розширювати інтерфейс, не нав'язуючи вибір однієї команди всім іншим. Плагіни були, але вимагали відкрити весь код плагіна, що багатьом внутрішнім командам не підходило.

Він обговорив пропозицію з менеджером, колегами та командами-клієнтами, написав два RFC, провів низку розмов і доповідей, а тоді спроєктував і випустив макроси як «легкі розширення» та extension servers, щоб команди могли ними ділитися. Сьогодні десятки команд усередині Google користуються макросами й extension servers, а кілька інших компаній використовують extension servers у себе.

Чому це важливо

Як далеко він піде далі, залежить від упевненості: частину змін просто робить, сумнівні ідеї перевіряє одноразовим прототипом, а більші вимагають тижнів чи місяців на побудову підтримки. Віддача накопичується: інженери, яким він допоміг, повертаються раніше й приводять колег, що розширює його бачення. Одне застереження: такий підхід вимагає автономії команд у формуванні дорожніх карт, а її має не кожна компанія.