Постановка задач и метрики в Uber

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

Постановка задач

Большая часть команды – это инженеры, которые работают или над продуктом, или на платформе.

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

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

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

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

Есть инженеры, которые работают с платформой, то есть сразу с несколькими продуктами в одной оболочке. У них проще: есть технические более предсказуемые метрики – количество пользователей, объем обрабатываемых данных и тп – которые нужно поддерживать на обоговренном уровне.

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

Метрики

Понять, какие метрики важны и как их оценивать – 30% самого качества. Нужно не просто измерять результат, но и четко понимать, как вы его достигли, чтобы повторить успех, определять приоритеты.

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

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

Если команда 6 месяцев работала над задачей и зашла в тупик – это очень плохо. За это могут понизить в уровне или отправить на performance information program (PIP). В рамках программы инженеры более высокого уровня посмотрят на недостатки и дадут более четкие задачи. А затем будут следить за их выполнением. Чаще всего, если такая ситуация возникает, то человек просто увольняется из Uber, потому что тяжело воспринимать это психологически.

У инженеров Uber есть простой принцип: не тупо выполнять задания, а принимать участие в жизни проекта, следить за его развитием, спрашивать себя и других «не фигню ли я делаю». И если ответ: «да», уметь быстро менять направление.
При этом в компании не требуют 100% результата, потому что считается, что если они достигли этого показателя, значит цель изначально был заниженной. 70% – абсолютно нормальный результат.
Любое использование материалов разрешается только при указании прямой ссылки на источник. 

Присоединяйтесь к #maliktrip, чтобы увидеть, как работают и учатся в Америке.  
Автор: Руслан Гафаров
Читайте также
Фото-отчет: как проходила встреча с Александром Трещевым
Как собрать команду мирового класса. Советы из Founder Institute
Founder Institute – это акселератор, который специализируется на ранней стадии развития стартапов. Их основной продукт – 4месячная программа в рамках которой участники строят собственную компанию.
Один в поле не воин: командный микс в дизайн мышлении.

В этой статье представитель SAP продолжает рассказывать о процессе дизайн мышления. 

В Америке говорят - не стоит работать одному. Нужно получать фидбэк (обратную связь) от коллег, от разных людей и от каждого. В SAP мы в основном работаем на прототипы, мы отдаем их на проверку каст - консультантам.