Советы для технического директора: собрать команду, выбрать методологию разработки и не сорвать дедлайны Статьи редакции

В PlanGrid работает 350 человек. Мы расположены в районе Миссия в Сан-Франциско. Пишем красивые, простые в использовании приложения для строительной отрасли, объём которой составляет $17 трлн. Мы — GitHub для строительства.

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

Наша платформа развёрнута на AWS. В бэкенде используем Python, GO и другие инструменты.

Одна из главных наших особенностей, что мы пишем нативный код для каждой платформы, поэтому у нас есть поддержка iOS, Swift, Objective-C, Android, Java и Kotlin, Web, React, а также Windows. У нас есть также приложение для Windows на .NET.

Ральф Гути, технический директор и соучредитель компании PlanGrid

Segment представляет собой единый API для сбора, организации и адаптации всех данных о покупателях в сотни сервисов. В том числе Google Analytics, Mixpanel, Gainsight, Customer.io.

Сейчас в компании работает чуть более 300 человек. Наша штаб-квартира в Сан-Франциско, но у нас есть офисы в Ванкувере, Нью-Йорке и Дублине. В команде разработки и проектирования продукта, которая занимается созданием продукта в Segment, сейчас немногим более 80 или 90 человек.

Про наш технологический стек: мы также полностью построили его поверх AWS. Как мы управляем нашей инфраструктурой: мы построили её на основе ECS, контейнерного сервиса от Amazon, и почти все наши сервисы — контейнерные.

Сегодня у нас работают около 300 различных микросервисов, которые объединяют в конвейеры данные по различным темам, читают и пишут, преобразуют данные, отправляют их туда, где они нужны. И наш бэкенд в основном написан на GO.

Кельвин Френч-Оуэн, технический директор и соучредитель Segment

Мою компанию приобрела Niantic — создательница Pokemon Go. То, что мы строили в Escher и теперь продолжаем делать Niantic, это бэкенд-технология для дополненной реальности, которая позволяет разработчикам создавать опыт AR как можно проще.

Мы имеем дело со сложными алгоритмами компьютерного зрения, взаимодействия с бэкендом, всеми непростыми вопросами рендеринга, чтобы добиться того, чтобы разработчики могли создавать простые приложения AR в считанные минуты.

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

Про технологический стек: раньше в Escher у нас был сервис, который мы размещали в AWS, но это не имело большого значения, потому что у нас все было в контейнерах Docker. Niantic является интенсивным пользователем Google Clouds, поэтому мы перемещаем всё в этот сервис.

Однако у нас есть много кода, и для нас нативный значит буквально C++, потому что для нас намного эффективнее написать код и все алгоритмы один раз, а затем кросс-скомпилировать его на всех архитектурах: Android, iOS и даже для бэкенда.

Так что когда мы запускаем некоторые CV-проекты, мы можем прототипировать их на телефоне, а затем легко переместить их на сервер, потому что наш сервер также написан на C++.

Диана Ху, сооснователь и технический директор Escher Reality

Second Measure — это компания из примерно 50 человек, мы стартовали в 2015 году и располагаемся в Сан-Матео. Мы анализируем данные кредитных карт. Анализируем миллиарды транзакций по кредитным картам и составляем карту публичных и частных компаний.

Наши клиенты — венчурные капиталисты, хедж-фонды и крупные бренды, такие как Blue Apron или Spotify. Мы помогаем им, проверить последние тренды, предоставить аналитику конкурентов или покупателей.

У нас действительно нет технического директора. Но поэтому я здесь. Я и мой соучредитель — оба технари, что было довольно удачно. Нам не нужно иметь дело со многими вызовами, связанными с основателями-нетехнарями.

Я упомянула, что наша команда состоит из примерно 50 человек, в первую очередь технических специалистов, и техническая организация составляет около 30 человек. И она делится пополам между экспертами по данным и разработчиками.

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

Ты спрашивал про технологический стек, мы также в первую очередь размещаемся на AWS, для нашего конвейера данных мы используем такие сервисы, как Lambda и Spark. Наш фронтенд основан на React, а для обработки запросов на бэкенде мы используем столбчатые хранилища данных, а именно Redshift.

Лилиан Чоу, главный операционный директор Second Measure

Мы начали с того, что генеральный директор и сооснователь PlanGrid Трейси рассказала мне о своей идее поместить строительные чертежи на iPad. Это было в 2011 году, как раз после запуска iPad, и для такой технологии было ещё очень рано.

И я сказал: «Да, без проблем. Я могу это сделать, это как PDF, никаких проблем не будет». Я попытался произвести на неё впечатление, но оказалось, чтобы использовать эти гигантские изображения на слабой технике тогдашнего iPad — трудная задача.

На iPad не было даже графического чипа, и эти изображения в 20 тысяч пикселей переполняли видеопамять и приводили к сбоям. И они были в формате PDF, с которым довольно трудно иметь дело.

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

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

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

Так мы управляли всем на бэкенде. И мы, как суфлёры за кулисами, загружали все документы для наших первых 30 или 40 клиентов. Но всё, что видели клиенты, был наш прототип, который был достаточно быстрым и делал то, что они хотели. Они никогда не видели человека за кулисами. Вот небольшая история нашего первого прототипа.

Ральф Гути

Когда мы начинали, мы учились в Y Combinator в 2011 году. Тогда мы строили совсем не то, что делает Segment сейчас. Мы создавали инструмент для лекций, помогающий преподавателям получать обратную связь: что учащиеся думают среди урока.

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

Мы разработали продукт в течение лета и развернули его в Бостоне осенью. И всё это просто сломалось, так как пользователи заходили не в наш продукт, а в Facebook, на Youtube, в «Википедию». Оглядываясь назад, мы должны были предвидеть, что студенты будут так делать, если у них есть ноутбук на лекции, но мы не смотрели на это таким образом.

Начали искать новую идею, потому что мы только что подняли первоначальные инвестиции. Спросили себя: в чём проблемы нашего продукта для обучения? Одна из проблем заключалась в том, что мы не могли ответить на вопрос, как люди используют наш инструмент.

Не могли сказать, как именно используют этот инструмент в Гарварде или MIT, чем отличается его использование на уроках по антропологии и биологии. И поэтому мы снова переключились — всё ещё не на сегодняшний продукт Segment, а фактически на продукт, конкурирующий с Mixpanel или Amplitude.

Это был инструмент, позволявший группировать пользователей по различным правилам и разбивать их на сегменты, откуда и произошло название компании Segments. И после группировки можно было понять по этим данным, что делает самая активная часть клиентской базы.

Мы построили такую систему примерно за 15 месяцев. Всё это время мы раз за разом переделывали нашу бэкенд-архитектуру, выпускали релизы и пытались заполучить пользователей, однако наш инструмент никому не был нужен.

И вот, через 15 месяцев переехали обратно в район залива из Бостона, где прожили год, и мы пришли к инвесторам. И рассказали о нашей эпопее за прошедшие полтора года.

Когда мы закончили рассказ о проделанном, инвестор взял паузу, прогулялся туда-сюда и сказал: «Вау, вы только что сожгли полмиллиона долларов, и вы всё ещё на первой ступеньке?». Мы просто ответили: «Да». Он сказал: «У вас всё ещё есть остаток “полосы разгона” стартапа, попробуйте ещё раз. Запустите что-то новое».

В то время у нас был внутренний инструмент, который мы использовали как хак для получения пользователей. Идея была в том, чтобы использовать тот же API для отправки данных нам, который вы использовали, чтобы отправить в Mixpanel, Kissmetrics, Google Analytics и все подобные инструменты.

И людям действительно нравился этот единый API, они вносили вклад в нашу открытую библиотеку на GitHub, запускали и использовали её, и мой сооснователь Ян сказал: «Эй, почему бы нам не сделать из этого продукт. Почему бы нам не запустить его и не посмотреть, что будет».

И мой сооснователь Питер ответил: «Ох, это худшая идея, которую я когда-либо слышал, она не заработает». Теперь он генеральный директор, но тогда думал так. И он сказал: «Хорошо, я должен найти способ проверить эту идею невероятно быстро».

Мы привели в порядок библиотеку и запустили её на Hacker News. К нашему удивлению, в первый день она получила около тысячи звёзд на GitHub.

Итак, наша первая версия создавалась в ту самую первую неделю, когда мы взяли библиотеку и сделали для неё лэндинг, где говорились: «Эй, если вы заинтересованы в серверной версии этого решения, оставьте email». Около 500 человек оставили свой адрес.

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

Кельвин Френч-Оуэн

Наша история точно больше, чем про одну неделю. Я и мой соучредитель думали о создании разных вещей.

Мой коллега из робототехнической отрасли, он обладал большим опытом работы с SLAM. SLAM — это метод одновременной локализации и построения карты, один из основных алгоритмов современной AR, который помогает определить, где находится позиция камеры, в то же самое время, как вы строите карту мира.

Есть такая категория алгоритмов, которые до сих пор использовались в основном в робототехнике, а в AR их пытались использовать много раз, но безуспешно. Например, алгоритмы AR с маркерами, которые фактически не взлетели. Мы тогда подумали, почему бы не взять эти алгоритмы и не перенести их на телефоны.

Считали, что сможем это сделать, потому что, например, вычислительные возможности iPhone 7 достигли уровня Macbook Pro 2013 года. Это просто чудесно с точки зрения таких трендов, как закон Мура, или с точки зрения энергетической эффективности компьютеров.

В то время я работала и возглавляла команду экспертов по данным. И я сказала: «Хорошо, я это сделаю». Потому что думала о смене деятельности. И стала заниматься этим проектом с другим разработчиком, которому было интересно работать с нами.

Мы очень постарались, чтобы получить работающую версию. Первый продукт отображал пять кадров в секунду, что ужасно, так как хороший опыт AR требует уверенного рендеринга с частотой хотя бы 30 кадров в секунду.

Эта версия нас сильно разочаровала, так как была собрана слишком наскоро. Потом мы начали удалять весь исследовательский код, и решение стало работать, частота кадров стала больше 30 кадров в секунду.

Заметьте, что мы работали над ним более чем за полтора года до запуска ARkit. Нам это всё было интересно, а так как мы оба технари, то не понимали рыночной ниши продукта и куда с ним пойти.

Нам нужно было найти рынок. Занимаясь этим, мы проинтервьюировали множество людей, которые, как нам казалось, могли бы использовать решение, и мы нашли очень хорошую нишу на рынке игр. Мы решили сфокусироваться на нём и с этой идеей записались в Y Combinator.

Эта идея действительно взлетела. И это тоже интересная история: в первый день нашего обучения в Y Combinator компания Apple анонсировала ARkit — очень похожее решение на наше. Для нас это был момент истины: когда надо было решить, собираемся ли мы бежать или бороться.

Мы решили: «Почему нет? Давайте просто бросим вызов Apple». Решили удвоиться. До этого у нас уже была идея обработки AR не только на устройстве. Хотя мы демонстрировали все наши решения на телефоне, и у нас не было ещё ничего на стороне бэкенда.

И в Y Combinator мы сделали решение работающим с использованием бэкенда, а также запустили его на Android. И сжали дорожную карту так, чтобы план на год уместился в три месяца.

Как только мы опубликовали нашу идею и дали возможность людям регистрироваться, за неделю зарегистрировалось около тысячи разработчиков. Мы сказали себе: «Окей, похоже, мы что-то нашли». Затем нами заинтересовались многие, и среди них был Niantic. В конечном счёте эта компания нас купила. Это наше небольшое саммари.

Так как мы работали неполный день, процесс от разработки до выпуска продукта занял примерно год. Затем я занялась только этим проектом, у меня и ещё одного разработчика ушло ещё шесть месяцев. Затем в течение лета в Y Combinator мы наняли двух разработчиков и смогли ускориться и довести решение до ума.

Диана Ху

Чтобы создать первую версию продукта, нам потребовалось два или три месяца полной занятости. И большую часть этого времени заняло выяснение, каким должен стать продукт. Мы знали, что тема, над которой мы работали, обещает быть интересной.

Сначала мы сосредоточились на инвесторах, стараясь дать им актуальную информацию для решений по инвестициям, будь то хедж-фонды, публичные рынки или венчурные капиталисты на рынке частных инвестиций.

У нас было несколько идей, мы думали: «Инвесторы хотят прогнозов, они хотят знать, взлетят ли квартальные продажи публичных компаний». И краткий ответ был: «Да, но нет». Это не было похоже на стабильную бизнес-модель, поэтому мы немного сместились в другую сторону.

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

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

Мой сооснователь сосредоточился на создании аналитической части продукта и фронтенд-приложении. И вместе мы построили конвейер данных и их преобразования. Думаю, некоторые важные решения, которые мы приняли тогда, — те же, с которыми некоторые сталкиваются прямо сейчас. Например, какую технологию выбрать для построения решения.

В итоге мы решили создать первое приложение на Groovy, используя фреймворк Grails, он не идеальный, не так много людей им пользуются, но мы имели в нём больше всего опыта. Мой сооснователь Майк строил на нём большие масштабируемые продуктивные системы, обслуживающие сотни тысяч одновременных пользователей, и он за неделю создал на Groovy костяк приложения.

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

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

Лилиан Чоу

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

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

Этот баланс точно изменился с момента нашего старта. Когда вы нашли рыночную нишу продукта, многие задачи меняются, система усложняется, команда растёт, и гораздо больше людей разрабатывают код системы. Система может сломаться множеством способов, и при этом на продукт полагаются гораздо больше пользователей.

Мы писали юнит-тесты, чтобы каждый разработчик проверял работу своего кода. Затем ввели непрерывную интеграцию и развёртывание (CI/CD), чтобы убедиться, что этот код будет работать в рамках всей системы.

Наш директор по разработке начал развивать и формализовывать лучшие практики, такие как разборы кода, тестирование и так далее. И определять эти процессы, встраивать всё большее количество элементов управления в систему, чтобы сломать её стало труднее.

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

Лилиан Чоу

Мы пытались развить свой MVP, так как код в продукте был сырой. Это продолжалось, даже когда предлагали сервис клиентам.

Полноценно использовать продукт мы начали только после присоединения к Niantic, потому что теперь нам необходимо интегрировать наши технологии в такие игры, как Pokemon GO.

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

Диана Ху

У нас в компании Segment было три отдельных фазы развития. Первая из них была тогда, когда мы работали в режиме хакатона. Тогда у нас точно не было ни тестов, ни непрерывной интеграции. Мы с вероятностью 80% могли выбросить результаты в течение двух недель, потому что собирались пробовать следующий продукт.

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

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

Думаю, мы перешли к следующей фазе, когда пригласили нашего первого разработчика TJ Holowaychuk. Те из вас, кто знаком с сообществом Node.js, знают TJ, он один из лучших разработчиков, с которыми я работал, думаю что 90% разработок на Node.js используют хотя бы часть его кода.

Он пришёл в Segment, огляделся, посмотрел на тот бардак, который мы развели, на наш продукт и сказал: «Ок, я не могу здесь работать». Вход в работу был ужасным. Думаю, только установка ноутбука заняла у него целую неделю.

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

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

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

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

К этому мы пришли, когда у нас появились корпоративные клиенты, которые платят верхние шестизначные суммы в год. Мы начали думать: «Да, нам надо позаботиться о том, как мы обращаемся с такими данными, потому что эти клиенты реально полагаются на них, чтобы делать свой бизнес».

Кельвин Френч-Оуэн

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

PlanGrid участвует почти во всём, что строится в Калифорнии: больницы, тюрьмы, капитальное строительство дорог, технологические кампусы, различные государственные здания. Так что безопасность была для нас ключевой с первого дня. У нас не было другого выбора, как только суперосознанно относиться к безопасности.

Да и к масштабируемости, если на то пошло, так как мы полезны нашим клиентам только тогда, когда они могут построить весь свой проект. Мы заменяем собой чертежи, а это в строительной отрасли означает, что если мы работаем неправильно, то возникают ошибки и в строительстве. А остановка строительства даже на один день может серьёзно повлиять на результаты строительной компании.

Для нас безопасность и масштабируемость всегда были ключевыми. При этом масштабируемость — непростая штука, потому что я не знаю способа добиться её без некоторого реагирования на проблемы.

Вы либо слишком сильно проектируете и рискуете не вывести продукт на рынок, либо в конце концов сталкиваетесь с проблемами, связанными с масштабированием. Мы старались проектировать решение так, чтобы оно работало в обозримом будущем, но потом это обозримое будущее наступало, и кто-то из наших клиентов находил первые признаки проблем масштабирования.

И чтобы вы могли лучше понять масштабы, о которых мы говорим: у нас есть клиенты с примерно 500 тысячами чертежей, огромным количеством их изменений и иногда более чем 5 миллионами примечаний в одном проекте. А так как мы работаем в том числе в офлайне, всё это скачивается в кэш на устройстве.

Наше приложение занимает до 100 Гб на iPad для некоторых проектов. У нас были всевозможные проблемы масштабирования, которые надо было решать. Мы искали баланс между проектированием на год, но не на три года вперёд, в этом необходим компромисс. Найдите свой компромисс сами.

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

Что касается лучших практик разработки — часть кода из первой версии до сих пор присутствует в продукте.

Сейчас у нас есть CI/CD, мы запускаем интеграционные тесты, есть команда тестирования пользовательского интерфейса.

Для правильного теста масштабирования продукта можно потратить дни для загрузки и выгрузки всех данных, поэтому мы для перепроверки используем множество функциональных тестов.

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

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

Ральф Гути

Я бы назвала нас Agile-ориентированными. Мы не принимаем полностью никакую из этих методик. В основном мы находим то, что лучше работает для нашей команды. Мы используем спринты и проводим ежедневные стендапы, включаем некоторые элементы методик в нашу разработку.

Решая много задач в своей организации, вам следует находить, что лучше работает для вас. Имеет смысл взять работающую для вас часть инструментов и приспособить для своей организации.

Непростая задача — просто постоянно развивать методы работы. Совсем разные вещи — работать в маленькой команде из четырёх человек, где каждый знает всё, либо работать в команде из 30, 50 или нескольких сотен человек.

Нужно постоянно переоценивать, подходит ли данный стиль работы или эта методика для текущего этапа жизни компании.

Лилиан Чоу

Развитие подходов к работе — это то, чем мы много занимаемся. В Esher создавали продукт всего четверо разработчиков. Было много суеты, мы просто старались двигаться быстро. Поэтому документация отсутствовала, всё решалось на доске, держалось в голове.

Мы не использовали спринты, потому что части разработчиков они не очень нравились, а больших задач слишком много. И мы доверяли каждому брать свою область, а затем интегрировали их. Но теперь всё сильно изменилось.

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

Так что мы стали работать с документацией. Мы привыкли, что все разбираются во всём, но теперь код должен запускаться на всевозможных архитектурах — Linux, Mac OS, Android, x86, ARM, iOS и так далее. Мы действительно запускаем тесты, в каждом находим много багов. У нас есть тестовое покрытие, но ещё надо учить команду уживаться с большим количеством процессов.

У нас нет как таковых спринтов, но есть еженедельное планирование и сбор команд. И я полагаю, что разделение на подкоманды работает. Люди погружаются то в одну область, то в другую. Мы разделились на три основных области: бэкенд, клиентская часть (клиентские кроссплатформенные приложения), API.

Ещё одна часть значительная часть команды реализует алгоритмы компьютерного зрения. Забавно, что в итоге каждый в команде стал тренированным разработчиком в области компьютерного зрения, так как это ядро. Алгоритмы компьютерного зрения работают как на сервере, так и на клиенте — как алгоритмическое ядро.

Вот так у нас всё устроено, хотя мы и не имеем как таковых установленных процессов. Сейчас Niantic использует OKR. Мы начинаем строить более долгосрочные планы. Раньше у нас была общая идея, куда двигаться дальше, а сейчас мы планируем конкретные результаты.

Диана Ху

У нас в Segment нет конкретных процессов, которым должна следовать команда. У нас есть отдельные самоорганизующиеся команды разработчиков, как в Spotify, которые сами организуют себя и могут работать, как хотят. Если они хотят работать спринтами, круто. Если хотят использовать Jira или Asana, они могут работать, как им удобно.

Единственное, что мы ввели за последние два года, — это методика, аналогичная OKR. Если кто не знает, это модель, разработанная в Google: «O» означает цели, а «KR» — это ключевые результаты, то есть у вас есть одна цель, к которой вы стараетесь прийти, а ключевые результаты, служат объективными измерителями движения к цели. Когда вы достигаете всех ключевых результатов, они суммируются в достижение цели.

Во всей компании принято, что каждая команда собирается вместе за неделю до начала квартала и создаёт свои OKR, а затем три месяца выполняет этот план. Часть команд оценивают достижение результатов каждую неделю, собираясь и задавая вопрос: «Где я относительно этих целей?». Некоторые команды оценивают результаты каждый месяц, это не так важно.

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

Мне всё равно, что обсуждают на этих встречах, до тех пор, пока мы всегда говорим о наиболее важных проблемах. Мы верим, что инструменты и процессы должны служить нам, не наоборот.

Кельвин Френч-Оуэн

Мой опыт в PlanGrid отражает сказанное коллегами. Мы Agile-ориентированные и самоорганизующиеся. Каждая команда выбирает инструменты по желанию. С самого начала мы с пользой применяли в каждой команде разработчиков те же ежедневные стендапы. Необходимо общаться каждый день.

Разработчику может быть иногда трудно захотеть общаться каждый день, вместо того чтобы кодировать, как проснётся, но это всего 15 минут, и стендап можно проводить удалённо через Slack, например, зато это очень полезно.

Ещё есть временные окна. Многие управленческие методики завёрнуты в абстрактную философию, но спринты — это как раз метод временных окон, в котором ты не можешь работать над чем-то бесконечно.

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

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

Ральф Гути

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

Помню, как писал наше решение, и оно мне очень нравилось, и отдавал ей планшет, и как только она прикасалась, приложение падало. Я не знаю, то ли она трясла iPad, то ли вращала его по три раза, но точно находила способ сломать написанную мной программу, и это про прекрасно для тестирования в начале. Так что это один из способов применения вашего нетехнического основателя.

Также надо научиться проверять указанные сроки. Я никогда не бы силён в этом, всегда чересчур оптимистичен. Даже сейчас я могу сказать: «О, это займёт у меня неделю».

Как-то говорил с другими лидерами-разработчиками, которые ведут отдельный блокнот для нетехнических основателей. Который показывают им и говорят: «Окей, вот такие сроки», а сами имеют другой отдельный блокнот, в который они записывают то, что на самом деле думают о сроках завершения работы.

Также нужно планировать даты тестирования и релиза. Потому что часто люди не понимают, что iOS имеет свой график релизов, который не зависит от разработчиков и контролируется Apple.

Управление проектами может быть полезно при общении с нетехническими сооснователями. Если они хороши в этой области, их также можно задействовать.

Ральф Гути

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

Позже я стал использовать способ в отношении дедлайнов: разговоры один на один. Когда ты спрашиваешь каждого лично, что будет происходить в следующие три или четыре недели. И спрашивая один на один, я обнаружил, что при разговорах наедине на людей не влияют ответы других, и вы получаете объективный взгляд. Это заставляет каждого подумать о ближайшем будущем.

Каждый внимателен к той области, над которой работает сам. Поэтому вы получаете более точный фидбек по проблемным местам в компании. В итоге получается отзыв с оценками работы от трёх или четырёх человек.

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

Кельвин Френч-Оуэн

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

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

Так что нередко как технический сооснователь вы становитесь ответственным за продукт и его разработку. И создаёте чёткую коммуникацию и договариваетесь об ожиданиях по срокам.

Это довольно непросто. Всегда есть разрыв между ожиданиями разработки и продукта или бизнеса. Разрыв по поводу сроков получения результатов, о которых приходится чётко договариваться.

Диана Ху

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

На начальном этапе многие основатели создают продукты и пишут код, особенно если вы один из технических сооснователей. Но так будет не всегда. Я практически прекратила программировать через год работы в компании. И для меня это было сильным изменением.

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

Лилиан Чоу

Мы начали с построения команды через наём сотрудников на полный день.

Вы строите продукт или компанию и развиваете свои ключевые компетенции. Поэтому помните, что на раннем этапе вы сами изучаете продукт и то, как его примут клиенты.

Выносить эти знания за пределы компании — большая потеря. Можно нанять человека по контракту как способ оценить возможных новых сотрудников. Но должно быть намерение создать свою команду.

К вопросу об аутсорсинге: здесь то же самое — следует смотреть, в чём ключевая компетенция, в которую вы инвестируете, в чем интеллектуальная собственность. Не следует отдавать её на аутсорсинг, а если вы так делаете, то вы скорее просто маркетинговая компания.

Разные бизнес-модели могут потребовать разного, и для некоторых из вас может иметь смысл отдавать на аутсорсинг большую часть того, что вы строите.

Что касается нас, мы немного экспериментировали с аутсорсингом. Наш подход заключался в том, чтобы убедиться, что такие проекты чётко определены, чтобы мы могли экспериментировать. Внешние кадры — это особые проекты с точки зрения управления, и вы можете подобным способом попробовать, работает ли это для бизнеса. Если работает, отлично, если нет, тоже хорошо.

Брать удалённых или постоянных сотрудников в офис — зависит от того, какую культуру вы хотите построить. Для нас было очень важно держать команду вместе, поэтому мы наняли локальную команду. Затем мы стали пробовать нанимать удалённых разработчиков. С этим связан некоторый культурный сдвиг.

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

Это хорошо по многим причинам, в том числе потому, что по мере роста коммуникации становятся одной из труднейших проблем для решения.

Лилиан Чоу

Мы не отдавали на аутсорсинг ключевые технологии компании. Только несущественные: построение 3D-моделей, частично дизайн, сайты, написание технологической документации и подобное.

Что касается удалённых или локальных сотрудников: так как мы строим настолько сложные вещи, мы выбрали культуру работы в офисе. И до сегодняшнего дня мы всё ещё строим локальную команду.

Есть много историй компаний с удалёнными командами, но начинать с удалённой команды не стоит.

Диана Ху

В самом начале мы нанимали сотрудников исключительно на полный рабочий день. Мы не экспериментировали с сотрудниками на контракте. Единственный вариант, когда мы что-то отдаём на аутсорсинг, — когда, например, AWS берёт на себя часть инфраструктуры, которую мы строили, или выпускает новую функцию, и мы можем строить поверх этого.

Это правильный подход, особенно на раннем этапе, когда стартап ещё хрупкий и вы хотите, чтобы группа людей работала в одном направлении.

Про локальных либо удалённых сотрудников: мы начали нанимать только удалённых. Мы работали в разных opensource-сообществах на GitHub, таких как Node.js. Это были люди, с которыми мы уже сотрудничали несколько лет, и когда мы были готовы нанимать, мы просто говорили им: «Эй, хочешь поработать с нами более плотно?».

Мы получали доступ к талантливым людям, не находящимся в районе залива Сан-Франциско, но с которыми мы при этом уже работали. И они принесли невероятную ценность для Segment.

С другой стороны, более сложной для налаживания была коммуникация и направление всех в одну и ту же сторону в отношении перспектив продукта. Поэтому хотя сначала мы наняли 10 или 15 сотрудников удалённо, а следующий рост на примерно 70 сотрудников был чисто локальным.

Снова нанимать удалённых сотрудников мы стали совсем недавно. Сейчас у есть достаточно мощностей, чтобы создать действительно хорошую культуру удалённой работы, сделав акцент на документации и коммуникации.

Кельвин Френч-Оуэн

Именно компромиссы следует держать в голове прежде всего

Расскажу про первых двух нанятых нами сотрудников. Один из них помог нам организовать наши счета и офисные вопросы, а другой помог нам развить некоторые технологии. Я работал с ним в компании John Hopkins.

У нас не было денег, чтобы платить ему, он был моим другом, и мы заплатили ему долей в бизнесе. В итоге он присоединился к нам как наш первый разработчик и помог компании построить действительно ключевую технологию. Это было прекрасным пополнением для PlanGrid.

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

Иногда на управление наёмным сотрудником приходится тратить больше времени, чем на работу с постоянным.

Ральф Гути