Hi-Tech

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

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

Свежее

Вакансии

Написать

Уведомлений пока нет

Пишите хорошие статьи, комментируйте,
и здесь станет не так пусто

Войти

Опыт чётырех основателей компаний PlanGrid, Segment, Escher Reality, Second Measure.

В закладки

При поддержке школы стартапов Russol. Переведено волонтёрами Y Combinator по-русски. Волонтёры также проводят бесплатные просмотры переведённых лекций в инкубаторах, коворкингах, и университетах Пензы, Саратова, Кишинева, Астаны и других городов. Цель инициативы — передать русскоязычному пространству опыт создания и развития компаний вроде Airbnb, MixPanel или Twitch. Участвовать в просвещении, получить знания и перенять опыт.

О компаниях

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

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

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

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

Ральф Гути

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

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

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

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

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

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

технический директор и соучредитель Segment

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

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

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

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

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

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

Диана Ху

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

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

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

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

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

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

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

Лилиан Чоу

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

Продукт на ранней стадии

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

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

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

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

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

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

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

Ральф Гути

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, алгоритмы 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 костяк приложения.
В итоге мы решили создать первое приложение на Groovy, используя фреймворк Grails, он не идеальный, не так много людей им пользуются, но мы имели в нём больше всего опыта.

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

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

Лилиан Чоу

Скорость разработки или безопасность и масштабируемость

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

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

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

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

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

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

Лилиан Чоу

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

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

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

Диана Ху

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

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

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

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

Вход в работу был ужасным. Он пришёл в 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. Вот так у нас всё устроено, хотя мы и не имеем как таковых установленных процессов. Раньше у нас была общая идея, куда двигаться дальше, а сейчас мы планируем конкретные результаты.
Мы начинаем строить более долгосрочные планы.

Диана Ху

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

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

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

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

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

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

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

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

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

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

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

Ральф Гути

Как быть с дедлайнами

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

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

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

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

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

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

Ральф Гути

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

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

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

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

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

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

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

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

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

Диана Ху

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

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

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

Лилиан Чоу

Как структурировать свою первую команду разработчиков

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

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

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

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

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

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

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

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

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

Лилиан Чоу

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

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

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

Диана Ху

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

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

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

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

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

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

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

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

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

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

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

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

Ральф Гути

#plangrid #segment #escherreality #secondmeasure #russol

Блоги компаний

Показать еще

Push-уведомления

{ "page_type": "article" }

["\u041f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435-\u043f\u043b\u0430\u0446\u0435\u0431\u043e \u0441\u043a\u0430\u0447\u0430\u043b\u0438
\u0431\u043e\u043b\u044c\u0448\u0435 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u0430 \u0440\u0430\u0437","\u0425\u0430\u043a\u0435\u0440\u044b \u0441\u043c\u043e\u0433\u043b\u0438 \u043e\u0431\u043e\u0439\u0442\u0438 \u0434\u0432\u0443\u0445\u0444\u0430\u043a\u0442\u043e\u0440\u043d\u0443\u044e
\u0430\u0432\u0442\u043e\u0440\u0438\u0437\u0430\u0446\u0438\u044e \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0443\u0433\u043e\u0432\u043e\u0440\u043e\u0432","\u0413\u043e\u043b\u043e\u0441\u043e\u0432\u043e\u0439 \u043f\u043e\u043c\u043e\u0449\u043d\u0438\u043a \u0432\u044b\u043a\u0443\u043f\u0438\u043b
\u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044e-\u0441\u043e\u0437\u0434\u0430\u0442\u0435\u043b\u044f","\u041a\u043e\u043c\u0430\u043d\u0434\u0430 \u043a\u0430\u043b\u0438\u0444\u043e\u0440\u043d\u0438\u0439\u0441\u043a\u043e\u0433\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430
\u043e\u043a\u0430\u0437\u0430\u043b\u0430\u0441\u044c \u043d\u0435\u0439\u0440\u043e\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u044c\u044e","\u041a\u043e\u043c\u043f\u0430\u043d\u0438\u044f \u043e\u0442\u043a\u0430\u0437\u0430\u043b\u0430\u0441\u044c \u043e\u0442 email
\u0432 \u043f\u043e\u043b\u044c\u0437\u0443 \u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 \u043c\u0435\u043c\u043e\u0432","\u041d\u0435\u0439\u0440\u043e\u043d\u043d\u0430\u044f \u0441\u0435\u0442\u044c \u043d\u0430\u0443\u0447\u0438\u043b\u0430\u0441\u044c \u0447\u0438\u0442\u0430\u0442\u044c \u0441\u0442\u0438\u0445\u0438
\u0433\u043e\u043b\u043e\u0441\u043e\u043c \u041f\u0430\u0441\u0442\u0435\u0440\u043d\u0430\u043a\u0430 \u0438 \u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0432 \u043e\u043a\u043d\u043e \u043d\u0430 \u043e\u0441\u0435\u043d\u044c"]

Приложение-плацебо скачали
больше миллиона раз

Подписаться на push-уведомления

Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть