В настоящее время Graphite — это процветающая компания, разрабатывающая платформу для анализа кода, которой пользуются десятки тысяч лучших разработчиков. Но, как и многие другие стартапы, связанные с инструментами для разработчиков, она начинала не с этого.
В этом посте я хочу сосредоточиться на мудрости одной книги, которая стала краеугольным камнем моего обучения. Это «Спроси маму» (The Mom Test) — краткое и необходимое чтение для всех, кто решился войти в мир стартапов и разработки инструментов, внести вклад в открытый исходный код или создать продукты, ориентированные на разработчиков.
От Airbnb до основателя стартапа
До работы в Graphite я был инженером по инфраструктуре в Airbnb. Там я получил бесчисленное количество уроков, которые помогли мне стать отличным инженером-программистом. Однако я понял, что при создании чего-то с нуля, почти не важно, насколько хорошо вы это сделаете. Гораздо важнее выбрать правильную вещь для создания. Это осознание стало особенно очевидным, когда я встал на путь стартапера и стал одним из основателей компании Graphite.
Два пивота
Наша команда всегда была увлечена процессами качества ПО и релизными процессами. Первым прототипом, который мы с соучредителями создали, был инструмент для «фиксации ошибок». Несмотря на то, что прототип попал в руки широкой сети друзей, коллег по LinkedIn и даже случайных инженеров в Интернете, реакция на него была сразу же неутешительной. Мы переключились на наш следующий продукт, ориентированный на работу с релизами в iOS, и столкнулись с теми же проблемами.
Откровенно говоря, никому (кроме нескольких избранных пользователей) не было дела до того, что мы создавали. Мы начали спрашивать, почему — вот тут-то и появилась книга «Спроси маму».
Использование «Спроси маму» при разработке продукта
Если бы мы задавали правильные вопросы заранее, мы могли бы сэкономить годы труда. Это может показаться глупым, но задавать правильные вопросы может быть очень и очень сложно.
Книга «Спроси маму» объясняет решение этой проблемы: речь идет о том, чтобы сформулировать вопросы таким образом, чтобы получить правдивую, непредвзятую обратную связь даже от тех, кто по своей природе благосклонен к вам, например от вашей мамы. Когда я делился своим восторгом по поводу нашей концепции откатов (rollbacks) в iOS, реакция обычно была в подавляющем большинстве случаев положительной, но, оглядываясь назад, можно сказать, что люди просто были добры ко мне.
Конечно, мой друг говорил мне: «Откаты iOS — это отличная идея!». Но мне следовало спросить:
- Когда ты в последний раз искал в гугле способ откатить свое приложение для iOS?
- Пробовали ли ты найти ответы в Интернете?
- Ты отличный инженер, расскажи мне о том, как ты обошел эту проблему
- Учитывая, что ты обошел эту проблему, продолжаешь ли ты время от времени гуглить в поисках чего-то лучшего?
Ключевой момент — задавать вопросы, которые копают глубже, интересуясь фактическим поведением, например, активно ли кто-то когда-либо искал решение, подобное вашему. Кроме того, инженеры-программисты как группа пользователей являются одними из самых способных людей в мире в решении своих собственных проблем. Если они еще не пытались написать сценарий решения, то так ли уж велика была проблема на самом деле?
Существующие и несуществующие решения
При разработке продукта для разработчиков очень важно проверить одну ключевую деталь: существует ли уже такое решение?
Если решение не существует, должно быть верно одно из двух. Либо идея не решает достаточно серьезную проблему (как в нашем случае с откатами и отловом ошибок), либо есть фундаментальная причина, по которой решение до сих пор не может существовать. Базы данных in-memory всегда были отличной идеей, но потребовалось, чтобы оперативная память стала достаточно дешевой, чтобы эта идея была раскрыта. Чат-боты — это замечательно, но они не особо развивались пока не появились большие языковые модели.
Если вы хотите создать инструмент для разработчиков, который еще никогда не был создан, четко объясните, почему его можно создать только сейчас, и будьте готовы сразиться со многими конкурентами, которые тоже только что взялись за эту возможность.
Отличным примером того, как развитие технологий разблокировало возможности для разработчиков, является MemSQL:
23 апреля 2013 года SingleStore выпустил свою первую общедоступную версию базы данных под названием MemSQL. Ранние версии поддерживали только таблицы, ориентированные на строки, и были сильно оптимизированы для случаев, когда все данные могут поместиться в оперативной памяти. Этот дизайн был основан на идее, что стоимость оперативной памяти будет продолжать экспоненциально снижаться с течением времени, в тенденции, подобной закону Мура. В конечном итоге это позволит в большинстве случаев хранить данные в системах баз данных исключительно в памяти.
Альтернативный (и, на мой взгляд, лучший) сценарий — это когда инструмент уже существует, но имеет ряд очевидных недостатков. Часто можно найти проект с открытым исходным кодом, блог или внутренний инструмент крупной компании, который соответствует вашей идее. Это может стать для вас лучшим подтверждением того, что людям небезразлична эта проблема настолько, что они уже пытались ее решить. Осталось выяснить: испытывают ли пользователи боль от использования этого инструмента? Как вы можете сделать лучше?
PagerDuty — отличный пример такого сценария:
Первый месяц 2009-го года мы провели, обдумывая идеи и проводя исследования. Одним из способов поиска идей было рассмотрение внутренних инструментов, созданных крупными компаниями (например, Amazon, где все трое из нас работали ранее), которые могли бы понадобиться другим компаниям любого размера… Amazon создал внутренний инструмент для отслеживания вызовов и оповещения о них через пейджеры. Этот инструмент использовался во внутренних системах размещения тикетов и мониторинга, поэтому при обнаружении критических проблем через пейджер вызывались нужные люди… Проведя небольшое исследование, мы поняли, что не только Amazon создал внутренний инструмент для вызовов — Google и Facebook тоже создали свои версии. Казалось, что в этом есть явная необходимость.
В случае с Graphite, в нашем третьем и последнем пивоте подобные инструменты также уже существовали. Stacked Diffs и альтернативные платформы для ревью кода уже были изобретены и любимы в таких крупных компаниях, как Google и Facebook. Phabricator и Gerrit были с открытым исходным кодом. Пользователи активно искали решения, писали скрипты, пробовали самостоятельно их размещать на своих серверах и многое другое. Каждый месяц кто-то в Twitter писал просьбу к GitHub нативно встроить стекированные диффы. При этом пользователи жаждали большего. Это была идеальная возможность для создания нового инструмента для разработки.
Почему наши первые две попытки не увенчались успехом, а третья удалась? Дело, конечно, не в том, что качество нашей разработки за ночь выросло вдвое — оно оставалось неизменным. Ответ заключался в том, что, в отличие от двух предыдущих идей, люди действительно чувствовали боль от проблемы, которую мы решали.
Лакмусовая бумажка для инструментов разработчика
По сути, Graphite прошел «тест мамы» так, как не прошли наши предыдущие идеи. Если бы мы четко и непредвзято задали следующие вопросы, мы могли бы с самого начала выбрать правильный продукт для создания:
- Когда вы в последний раз искали подобный инструмент в гугле?
- Пробовали ли вы установить то, что нашли?
- Расскажите мне о скрипте, который вы использовали
- Когда в последний раз после создания скрипта вы искали в гугле лучшее решение?
Какие идеи прошли этот тест? PagerDuty. Очереди слияния. Дашборды метрик. Боты Slack. Раннеры CI-тестов. Список можно продолжать. Если такая система существует в крупной компании, но не существует за ее пределами, это отличная отправная точка. Если же ни одна компания не создавала такого внутри себя, вам стоит проверить свои розовые очки.
Заключительные мысли
Спустя годы работы над Graphite выводы из «Спроси маму» остаются для меня бесценными. Вся команда еженедельно ссылается на эту книгу в поисках искренней, нефильтрованной обратной связи, благодаря чему Graphite фокусируется на разработке функций, отвечающих реальным потребностям. Я настоятельно рекомендую эту книгу всем, кто занимается разработкой продуктов, особенно в сфере инструментов для разработчиков. Это не просто руководство по задаванию правильных вопросов — это дорожная карта для понимания и удовлетворения истинных потребностей ваших пользователей.