Поделиться
Дмитрий Макаров, «Яндекс» — Как возглавить внедрение инноваций в корпорации
Современные технологии развиваются стремительно — и важно обладать гибкостью и обширной экспертизой, чтобы быстро адаптировать новые инструменты к задачам бизнеса. Дмитрий Макаров, старший разработчик мобильных приложений в «Яндекс», в своей карьере часто выполнял роль пионера в сложных проектах, связанных с внедрением новых технологий и решений. В этой колонке Дмитрий рассказывает, какими навыками нужно обладать для работы в таких условиях, и как настроить процессы в масштабных проектах со сжатыми сроками.
Сложности в работе с инновациями
Одна из сложностей при работе с масштабными проектами на базе новых технологий — ошибка в оценке сроков, вплоть до разницы в 4 раза. Если неправильно оценить сроки, придется или перенести релиз и вызвать негатив у менеджера, или прибегнуть к переработкам, что может привести к выгоранию и усталости команды. Чаще всего сложно поставить дедлайны на первых этапах работы, а ближе к завершению сроки становятся яснее — важно объяснить это менеджеру, чтобы не допустить овертайма.
Еще одна сложность — необходимость постоянно проводить эксперименты, чтобы обеспечить наилучший результат. Новые технологии всегда непредсказуемы, поэтому нужно быть толерантным к ошибкам и понимать, что это часть процесса.
Довольно трудно находить баланс между полным пониманием системы и попаданием в сроки — поэтому в зависимости от контекста можно выбирать что-то одно. Например, когда система слишком объемна, сложно изучить ее целиком — и работающее решение подбирается опытным путем.
Все эти сложности приводят к избыточным процессам и коммуникациям. Например, при разработке ленты рекомендаций в «Яндекс.Маркете» нам приходилось на ходу менять план, потому что появлялись новые детали и условия. Приходилось срочно пересматривать приоритизацию или выделять дополнительные ресурсы. А для этого нужно было устраивать новые встречи и созвоны.
Также всегда существует риск того, что новая технология не подойдет для реализации проекта. В этих случаях я рекомендую подобрать максимально компромиссное решение, которое позволит соблюсти дедлайн — а затем можно подумать над более подходящей реализацией.
Хард и софт скиллы для работы с новыми технологиями
Чтобы развиваться на сложных проектах с новыми технологиями, уже сейчас важно прокачать себя в генерировании гипотез — советую пользоваться эвристиками, которые сокращают путь до правильного ответа. Также нужно подготовиться к проведению множества экспериментов — для этого понадобится умение настроить оптимальную конфигурацию. И, конечно, важны фундаментальные знания computer science: от структур данных и алгоритмов до работы сетей и архитектуры компьютера. Они позволят формулировать эвристические гипотезы, быстро читать, анализировать и синтезировать документацию и код.
Не менее важны и софт скиллы, которые помогут эффективно погружаться в новые проекты. Например, вам понадобится гибкость в общении со смежными командами, которые могут больше рассказать о нужной технологии. Также важно быть готовым к множеству ошибок, как к неотъемлемой части рабочего процесса. И в целом, при работе с новыми технологиями придется побыть увлеченным детективом с непреодолимым желанием разобраться в проблеме и сделать всё идеально.
Организация команды в условиях неопределенности
Чтобы испытывать меньше сложностей при работе с командой, важно изначально правильно ее собрать. Например, для стажеров и джунов нужны хорошие фундаментальные знания, желание расти в важных для команды направлениях, мотивация к развитию и проактивность. Для миддлов и сеньоров — системное видение, умение декомпозировать задачи и ставить реалистичные сроки, самостоятельность, возможность проводить интервью и менторить новичков. И независимо от уровня, сотрудник должен быть вовлеченным в процесс, готовым помогать и учиться новому, а также не просто решать текущую задачу, но и улучшать ее.
Перед началом проекта необходимо оценить со стейкхолдерами его важность и value. Стартовать можно только если все согласны с тем, что проект принесет плюсы. После нужно проверить возможности реализации с помощью имеющихся средств: инфраструктуры, архитектуры, фреймворков, компетенций и т.д. Если их недостаточно, то разработка дополнительных инструментов включается в отдельный этап или выносится в самостоятельный проект. После можно собирать необходимые требования, согласовывать контракт и ресурсы.
При высокой степени неопределенности вырастают издержки на синхронизацию между продуктом, разработчиками, тестировщиками и смежными командами. Для их снижения я рекомендую ввести регулярные процессные встречи:
- Дейли — ежедневные короткие встречи внутри команды для актуализации статуса задач и рабочего общения. Это позволит каждому участнику понимать зоны ответственности и быть в курсе работы коллег.
- PBR — регулярные встречи для уточнения бэклога проекта: детализации, оценки, приоритизации, декомпозиции и пояснения задач. PBR проводится еженедельно или по потребностям команды.
- Продуктовое планирование
- Покер
- Попроектные синки — встречи со стейкхолдерами, где обсуждаются все текущие вопросы по проекту: от от статуса до планирования задач, от изменений контракта до инфраструктурных моментов.
Обучение коллег новым технологиям
На мой взгляд, лучшее обучение — это практика. Во время менторинга я придерживаюсь такой тактики: 70% практических задач + 20% теории + 10% на коммуникацию и обмен опытом через выступления и презентации. Чтобы обучение проходило успешно, я советую выбирать технологии, которые не только будут полезны в команде, но и в которых заинтересован сам сотрудник — а после обучения я рекомендую сразу применять знания на подходящем проекте.
Развитие можно начинать с любой позиции — если человек уже находится в команде, значит, его навыков достаточно, чтобы брать на себя больше ответственности. Но стоит следить за тем, чтобы обучение подходило позиции — например, даже способный джун вряд ли справится с составлением стратегии или выстраиванием сложного пайплайна. Но ему можно давать атомарные задачи на уровне компонента приложения с полной ответственностью за качество и скорость.
При составлении плана развития я рекомендую проговаривать чек-поинты и желаемые результаты. Например, результатом может быть полноценный проект на новой технологии, самостоятельная работа с компонентом, написание документации, проведение обучения для коллег или достижение целевых метрик процесса или продукта.
Как оценивать крупные проекты
Метрики зависят от доменной области проекта или приложения. Например, для маркетплейса ключевыми метриками являются GMV, рекламная выручка, выкупаемость корзин, мультикатегорийность. Но если цель — дать пользователю возможность поисследовать рынок, то можно оценивать здесь timespent, retention, показы и переходы по рекламе. Например, в приложении «Яндекс.Маркета» мы собираем около 5000 различных метрик для различных экранов, сценариев и воронок (и это только ключевые).
Помимо продуктовых метрик, рекомендую собирать и метрики производительности: время показа первого кадра, размер ответа бэкенда, процент пропуска кадров, плавность скролла, тайминги бэкендов. Эти метрики напрямую влияют на продуктовые — чем быстрее пользователь загрузит и откроет приложение, тем скорее совершит покупку.
Важно регулярно проверять и актуализировать метрики, потому что иногда они устаревают. В «Яндекс.Маркете» за четыре года мы несколько раз пересматривали ключевую агрегированную метрику по GMV и эффективности рекламы. Переход на новую метрику происходил из-за внешних изменений, после которых старый показатель не позволял корректно оценить наилучшие для «Маркета» результаты.
В заключение
Использовать новую технологию только ради инноваций не стоит, потому что это требует дополнительных ресурсов и обучения. Подходить к такому решению нужно осознанно, учитывая издержки в виде неопределенности, возможных новых точек отказа и поломки, вероятных сдвигов дедлайнов и других расходов.
Однако если потенциальный выигрыш от перехода на новую технологию существенно выше издержек, то игра стоит свеч. Как правило, новая технология улучшает метрики, закрывает боли от устаревших подходов и открывает новые возможности для развития проекта или приложения. Это может быть, например, ускорение разработки, снижение нагрузки на команду инфраструктуры, ускорение релизного процесса, увеличение числа запусков и экспериментов, и даже рост денежных показателей — GMV, рекламной выручки и других.
Короткая ссылка
