На панельной дискуссии Y Combinator технические основатели успешных технологических компаний поделились практическим опытом создания стартапов с нуля. Руководители PlanGrid, Segment, Escher Reality и Second Measure обсудили эволюцию своих технологических стеков, дилемму между скоростью разработки и качеством кода, а также методы управления командами. Главный вывод встречи заключается в том, что успешный продукт строится вокруг потребностей пользователей, а не идеальной архитектуры на старте.
🛠️ Знакомство со спикерами и их технологическими стеками 0:00
Модератор дискуссии Джаред Фриден (Jared Frieden), партнер Y Combinator, представил участников панели, каждый из которых прошел путь от написания первой строчки кода до руководства крупной инженерной организацией.
Участники панели представляют следующие компании и технологические решения:
- PlanGrid (Ральф Гути — Ralph Gootee, сооснователь и CTO) — компания насчитывает 350 человек и создает программное обеспечение для строительной индустрии объемом 17 триллионов долларов. Продукт работает по принципу «GitHub для чертежей», обеспечивая контроль версий строительных планов. Бекэнд компании изначально мигрировал на AWS и написан преимущественно на Python с вкраплениями Go. Для фронтенда используется React, а мобильные приложения пишутся нативно: Objective-C для iOS, Java и Kotlin для Android, а также полноценное приложение для Windows.
- Segment (Кальвин Френч-Оуэн — Calvin French-Owen, сооснователь и CTO) — платформа предоставляет единый API для сбора, организации и маршрутизации клиентских данных в сотни сторонних инструментов, таких как Google Analytics, Mixpanel, Customer.io. В компании работает более 300 человек, инженерно-продуктовый департамент насчитывает около 90 специалистов. Инфраструктура полностью развернута на AWS ECS (Amazon Container Service). Технологическая архитектура состоит из порядка 300 микросервисов, обрабатывающих потоки данных через брокер сообщений Kafka, бэкэнд написан на Go.
- Escher Reality (Диана Ху — Diana Hu, сооснователь и CTO) — компания разрабатывает бэкэнд-технологии для дополненной реальности (AR), упрощая создание многопользовательских AR-приложений. Недавно стартап был поглощен компанией Niantic (создателями Pokémon GO). Первоначально инфраструктура размещалась в контейнерах Docker на AWS, но после сделки мигрировала в Google Cloud. Основная часть кода написана на C++ для оптимизации алгоритмов компьютерного зрения и возможности кросс-компиляции под Android, iOS и серверные платформы.
- Second Measure (Лиллиан Чоу — Lillian Chou, операционный директор / COO) — стартап запущен в 2015 году, штат составляет 50 человек, из которых 30 — технические специалисты, разделенные поровну между инженерами и дата-сайентистами. Продукт анализирует миллиарды транзакций по кредитным картам для предоставления аналитики венчурным фондам, хедж-фондам и крупным брендам, таким как Blue Apron или Spotify. У компании нет выделенного CTO, так как оба сооснователя обладают техническим бэкграундом. Бэкэнд работает на AWS с использованием AWS Lambda и Apache Spark, фронтенд — на React, а для обработки тяжелых запросов применяются колоночные базы данных, такие как Amazon Redshift.
🚀 Истории создания первых версий (V1) и поиск соответствия рынку 8:43
Опыт участников показывает, что путь к первой работающей версии продукта редко бывает линейным, а первоначальные идеи часто терпят крах.
Ральф Гути рассказал, что идея PlanGrid родилась в 2011 году сразу после запуска первого iPad. По его словам, первая попытка загрузить огромные чертежи разрешением около 20 000 пикселей в формате PDF полностью провалилась: устройство зависало из-за отсутствия графического чипа и нехватки видеопамяти. Опираясь на свой опыт работы в анимационной студии Pixar, Гути за месяц разработал кастомный движок для отображения графики. Интересно, что в первой версии веб-интерфейса кнопка удаления находилась всего в одном пикселе от кнопки публикации и не имела подтверждения действия. Из-за этого команде приходилось вручную загружать документы «за кулисами» для первых 40 клиентов.
Кальвин Френч-Оуэн поделился долгой историей пивотов Segment, начавшейся в YC в 2011 году. Изначально команда создавала инструмент для лекций, помогающий профессорам получать обратную связь от студентов в реальном времени. По признанию спикера, проект полностью провалился, так как студенты просто отвлекались на социальные сети. Затем команда 15 месяцев создавала конкурента Mixpanel под названием Segment, потратив половину привлеченного сид-раунда в размере 500 000 долларов. Пол Грэм тогда отметил, что команда сожгла полмиллиона и вернулась на исходную точку, но имеет взлетную полосу для новой попытки. Успех пришел неожиданно: библиотека с открытым исходным кодом, которую основатели использовали как внутренний инструмент для привлечения трафика, набрала 1000 звезд на Hacker News за первый день. Настоящая первая версия была создана в режиме хакатона всего за одну неделю.
Диана Ху отметила, что алгоритмы одновременной локализации и картирования (SLAM), используемые в робототехнике, легли в основу Escher Reality. Первая сборка работала на скорости всего 5 кадров в секунду, что недопустимо для дополненной реальности. После очистки исследовательского кода от лишних элементов скорость выросла до необходимых 30 кадров в секунду. В первый же день участия стартапа в YC компания Apple анонсировала ARKit — фактически прямой аналог их технологии. Как вспоминает Диана Ху, команда решила принять вызов и конкурировать с Apple, сократив свой годовой план разработки бэкэнда и версии для Android до трех месяцев. Это позволило привлечь 1000 разработчиков за неделю и привело к последующему поглощению со стороны Niantic.
Лиллиан Чоу сообщила, что на создание первой версии Second Measure ушло около 2–3 месяцев работы, большая часть которой была потрачена на определение сути продукта. По ее словам, инвесторам сначала предлагались готовые прогнозы продаж публичных компаний, но эта модель оказалась нежизнеспособной. Затем команда предоставила сырой доступ к аналитическим срезам данных, что перегрузило пользователей. В итоге стартап пришел к созданию self-service платформы с готовыми аналитическими сценариями. Лиллиан подчеркнула, что первую версию они написали на фреймворке Grails (язык Groovy), просто потому что сооснователь имел в нем огромный опыт масштабирования систем, что позволило собрать каркас приложения за неделю. По мнению операционного директора, на старте критически важно использовать именно те технологии, которые команда знает лучше всего, ради высокой скорости итераций.
⚖️ Дилемма «скорость против качества»: когда внедрять тесты и CI/CD 22:38
Один из главных вопросов ранних стартапов — баланс между скоростью выкатки фич и соблюдением инженерных практик.
Лиллиан Чоу выразила мнение, что скорость на ранних этапах имеет первостепенное значение, поскольку никто не станет платить за идеальное покрытие тестами, если продукт не решает реальную проблему. В Second Measure полноценные процессы тестирования, автоматической сборки (CI/CD) и код-ревью были формализованы примерно через полтора года после запуска, когда команда инженеров утроилась, а сложность системы резко возросла.
По словам Дианы Ху, первая версия Escher Reality была полностью написана на коленке. Полноценные лучшие практики кодинга команда внедрила только после слияния с Niantic, поскольку возникла необходимость интеграции в игры калибра Pokémon GO со стомиллионной аудиторией, что потребовало полной переработки кодовой базы.
Кальвин Френч-Оуэн выделил три этапа в эволюции Segment:
- Режим хакатона (первые 9–10 месяцев) — отсутствие тестов и CI, фокус исключительно на выживании и привлечении пользователей. По мнению Кальвина, вероятность того, что код будет выброшен через две недели, составляла 80%, поэтому тратить время на инфраструктуру не имело смысла.
- Появление первого наемного инженера — известный в Node-сообществе разработчик TJ Holowaychuk пришел в компанию и не смог быстро развернуть проект на ноутбуке, это заняло неделю. Его приход заставил команду внедрить автоматическое тестирование, CI и обеспечить воспроизводимость сборок.
- Выход на Enterprise-рынок (последние 3–4 года) — появление клиентов с шестизначными суммами контрактов кардинально изменило цену ошибки. Только на этом этапе компания начала массово инвестировать в сквозное (end-to-end) тестирование и жесткие стандарты безопасности данных.
Ральф Гути предложил разделять безопасность, масштабируемость и инженерные стандарты. Поскольку PlanGrid используется на стройках госструктур, тюрем и госпиталей, безопасность была приоритетом с первого дня. Относительно масштабируемости Гути считает, что стартапы неизбежно действуют реактивно: либо вы тратите слишком много времени на оверинжиниринг и не выходите на рынок, либо решаете проблемы по мере их поступления. Некоторые проекты в PlanGrid содержат по 500 000 чертежей и до 5 миллионов аннотаций, а кэш на iPad может занимать до 100 ГБ. Спикер призвал проектировать архитектуру с запасом на один год вперед, но не на три года. Ральф также критически отозвался о некачественном применении TDD (разработки через тестирование): по его наблюдениям, неопытные разработчики часто тратят слишком много времени на написание запутанных тест-фреймворков и тестирование собственных моков вместо выпуска продукта.
🔄 Методологии разработки: гибкость без догматизма 34:34
Ни одна из компаний на панели не придерживается жестких методологий (Scrum, Канбан или Extreme Programming) в их классическом виде.
Лиллиан Чоу описала подход Second Measure как «Agile-ish». Команда использует элементы спринтов и ежедневные стендапы, но адаптирует их под текущие нужды, избегая догматизма. По мнению Лиллиан, ключевая задача лидера — постоянно оценивать, соответствует ли текущий стиль работы масштабу компании при переходе от маленькой группы к штату в сотни человек.
Диана Ху поделилась, что в Escher Reality при пяти инженерах документации не было вообще, а задачи фиксировались на маркерных досках. В Niantic команда выросла в три раза за 8 месяцев, что потребовало внедрения развитой системы CI, тестирующей код под множество архитектур, таких как Linux, macOS, Android x86/ARM и iOS. Вместо классических спринтов они используют еженедельное планирование, разделяя команду на три фокус-группы: бэкэнд, кроссплатформенный клиент (Unity) и интеграция алгоритмов компьютерного зрения. Также компания перешла на квартальное планирование по системе OKR.
Кальвин Френч-Оуэн рассказал, что в Segment отдельные инженерные команды полностью автономны и сами выбирают инструменты (Jira, Asana, спринты) по аналогии с моделью внедрения в Spotify. На уровне компании уже два года действует модель OKR (Objectives and Key Results), разработанная в Google. Команды формируют свои цели за неделю до начала квартала и затем оценивают прогресс. Сам Кальвин проводит еженедельные плановые встречи и ежедневные стендапы, отмечая, что инструменты и процессы должны служить людям, а не наоборот.
Ральф Гути поддержал коллег, отметив высокую ценность 15-минутных ежедневных стендапов (которые можно проводить и удаленно в Slack) для быстрого устранения блокирующих факторов. По его мнению, методология тайм-боксинга (ограничения времени на задачу) необходима, так как оценки инженеров часто ошибочны, и задача вместо недели может занять месяц. Также Гути настоятельно рекомендует практиковать еженедельные встречи один на один (1-on-1), чтобы понимать эмоции, потребности и карьерные ожидания сотрудников.
🤝 Взаимодействие с нетехническими сооснователями и управление дедлайнами 41:46
Управление ожиданиями внутри команды — критически важный навык для технического лидера, особенно если его партнеры не пишут код.
Ральф Гути с юмором отметил, что нетехнический сооснователь — это отличный инструмент для тестирования. Его партнер Трейси умела уникальным образом ломать приложение (например, встряхнув или повернув iPad три раза), что помогало находить скрытые баги на раннем этапе. Гути признался, что инженеры по природе оптимистичны, поэтому дедлайны всегда приходится закладывать с запасом. По его словам, некоторые технические лидеры даже ведут «двойную бухгалтерию»: называют нетехническим партнерам одни сроки, а в уме держат другие, более реалистичные. Также важно учитывать внешние факторы, такие как циклы модерации приложений в Apple App Store.
Кальвин Френч-Оуэн использует метод «мудрости толпы» для оценки сроков. На встречах один на один он спрашивает каждого инженера, что произойдет в ближайшие 3–4 недели. Благодаря этому сотрудники не подстраиваются под ответы коллег, дают несмещенную оценку и подсвечивают риски в тех зонах, за которые сами не отвечают. Среднее арифметическое из этих ответов дает максимально точный прогноз дедлайна.
Лиллиан Чоу затронула тему личной эволюции основателя. По ее наблюдениям, примерно через год после запуска технический лидер практически перестает писать код. Роль смещается от поиска соответствия продукта рынку к построению организации и человеческой системы, которая сможет функционировать и развиваться без его прямого операционного участия.
👥 Команда: аутсорсинг, подрядчики и удаленная работа 47:19
Вопрос формирования штата вызвал оживленную дискуссию о допустимости аутсорсинга и удаленной работы.
Лиллиан Чоу категорически не рекомендует отдавать на аутсорс ключевые компетенции стартапа и его интеллектуальную собственность. Как считает операционный директор, если полностью нанять сторонних разработчиков, компания превращается просто в маркетинговое агентство. Second Measure привлекает подрядчиков только на жестко очерченные проекты, не находящиеся на критическом пути. Говоря об удаленной работе, Лиллиан отметила, что они долго нанимали только локально в целях сохранения культуры, но за последний год начали привлекать распределенных инженеров. Это стало отличным стимулом для улучшения внутренней документации.
Диана Ху согласилась с этим тезисом: в Escher Reality на аутсорс отдавались следующие некритичные задачи:
- Создание 3D-моделей
- Графический дизайн
- Написание технической документации
- Поддержка и верстка веб-сайта
Ядро технологии создавалось исключительно инженерами в офисе. По мнению Дианы, эффективная распределенная работа возможна только в том случае, если компания изначально строится по принципу remote-first.
Кальвин Френч-Оуэн рассказал, что Segment на первых порах нанимал удаленных сотрудников из числа активных контрибьюторов их open-source библиотек на GitHub. Это дало доступ к талантам экстра-класса вне Кремниевой долины. Однако из-за сложностей с синхронизацией продуктового видения, следующих 70 сотрудников компания наняла строго локально в офис, и лишь недавно снова открыла удаленный наем, выстроив сильную культуру письменной фиксации решений.
Ральф Гути поделился историей о том, что первыми двумя сотрудниками PlanGrid были подрядчики, причем один из них согласился работать за долю в капитале из-за нехватки денег у стартапа, став впоследствии ключевым инженером. При этом Гути развеял иллюзию основателей о том, что подрядчики не требуют внимания: по его опыту, управление контракторами отнимает колоссальное количество времени у фаундера, порой даже больше, чем управление штатными сотрудниками. Сейчас PlanGrid полностью открыта к удаленному формату и нанимает лучших специалистов по всему миру независимо от локации.
💬 Советы по ускорению разработки и обратная связь от пользователей 56:03
В завершение панели спикеры ответили на вопросы из зала о том, как бы они ускорили процессы, если бы запускали бизнес заново.
Диана Ху заявила, что они потратили слишком много времени на разработку технологии в вакууме. По ее мнению, необходимо как можно раньше выходить к пользователям и тестировать гипотезы, поскольку собирать фидбек от реальных людей гораздо эффективнее, чем бесконечно спорить внутри команды.
Кальвин Френч-Оуэн поддержал эту мысль, добавив, что сейчас он бы сознательно создавал две или три ранние версии продукта с намерением полностью выбросить их после тестирования, чтобы быстрее пройти цикл обучения.
Ральф Гути с высоты своего опыта признался, что если бы он начинал сейчас, то выбрал бы кроссплатформенный фреймворк для мобильной разработки вместо поддержки четырех разных нативных платформ. Кроме того, по мнению Гути, техническому основателю следует прекратить писать код и переключиться на наем сотрудников гораздо раньше, чем это обычно происходит, поскольку фокус на привлечении сильных инженеров ускоряет компанию значительно сильнее, чем личное написание фич.
