контроля коммуникаций в виде "а обсудили ли вы вот это" нет. Команда развивает продукт, этот результат уже измеряется какими-то метриками. На уровне CPO и CTO – прямое взаимодействие со всей leadership team (можно раз в неделю, можно раз в 2 недели, раз в месяц, не важно), по развитию продукта, проблемам и т.д.
Можно сказать что да, с собственными ошибками. Ошибочные решения прошлых лет, ошибки технических решений, ошибки в приоритизации работы с техдолгом собрались в снежный ком и стрельнули. Это история о том что бывает, если не отдавать техдолг вовремя.
Мораль не в некомпетентности. Если когда-нибудь у вас будет спор с бизнесом и продактами на тему техдолга — просто покажите ему эту историю.
В тестовом дне есть 2 фактора: с одной стороны, мы смотрим на кандидата в реальных условиях. С другой, кандидаты смотрят на то как у нас устроена dodo is, что за код, что за команда, процессы и тд. В итоге они принимают решение уже не на основе собеседований и абстрактных бесед, а на основе того что увидели. Понимают, с чем предстоит работать. Выбор становится более осознанным. За почти 2 года что у нас действует эта практика всего 2 человека из сотни отказались от тестового дня со словами: "вы же не фейсбук чтобы к вам ехать". От остальных реакция примерно:"офигеть круто, я что, смогу прям с продакшн кодом поработать? Ого"
у нас моделей еще нет, тут дело не в количестве заказов, а чтобы заняться, проанализировать и построить их. У нас пока работает всего лишь одна модель для доп.продаж, когда уже в корзине показывает «Рекомендуем попробовать».
Мы ж не мудаки чтобы делать это специально. Но я давно не припомню таких проблем, они были, не отрицаю. Если у вас такое было, напишите в ЛС, пожалуйста
А вот тут уже играет роль культура внутри компании и то, насколько самокритично люди в компании могут относиться к тому что делают. Да, у кого-то подобные подходы могут скатиться в KPI, в то что разработчики будут в поддержке работать. А кто-то будет понимать, что разработчики могут вывести компанию на новый уровень, сделать то, что другие не смогут. И мы начнем адаптироваться под рынок. К примеру, вот резко и неожиданно появляется возможность открыть сразу несколько пиццерий в новой стране. Там свои законы по персональным данным, свои особенности эквайринга, касс, язык и еще куча-куча всего. И если у вас внутри компании культура, при которой люди готовы резко сорваться и начать открывать новую страну — вы откроете. Мы так открыли. Если культура того что все обвязано KPI, а менять их нельзя — ну да, выйдет не очень.
Планы важны, я не спорю. Но мы не сможем составить четкий план на годы вперед. Сейчас, например, я понимаю что долгосрочно мы будем вкладываться в ML. И да, мы активно растим ML команду. Но это нельзя назвать прям конкретным планом, проблемой бизнеса, задачей в бэклоге и т.д.
Еще раз, это не красивая цифра. Статья прошла слишком много редактур, надо было выпускать ее максимально эмоциональной как в начальном варианте :) Цифра — лишь ориентир, который говорит нам о том, что надо расти. Расти в компетенциях, расти в процессах, подходах, технических скиллах и т.д.
Ее сейчас нет, я ж написал что мы ее сделаем. 7 миллионов клиентов ведут себя совершенно по-разному. Я сам немного прифигел, когда увидел количество подписавшихся на пуши.
Такое поведение надо персонализировать. У нас 7 миллионов клиентов и они все ведут себя по-разному. Сорри что сейчас один flow для заказа, но мы обязательно сделаем подобные механики персонализируемыми.
По поводу бизнеса, это все-таки вопрос доверия прежде всего. Если мы объясняем, что нам нужно сделать для стабильности или улучшения, если мы показываем, какой будет профит — все просто. Если нет, честно, иногда бывают кейсы вида: «Ребята, поверьте, так надо». И доверие есть.
То что в этой цели есть число — это способ увидеть скорость, с которой мы растем и иметь большую амбициозную цель. Цель, которая заставит думать и действовать нестандартно.
Естественно, мы не с шашкой наголо пошли нанимать джуниор разработчиков. Идем постепенно, костяк растет качественно, люди, вокруг которых строятся новые команды, растут и готовы собирать команды. В общем, работа идет.
а у кого самая высокая роль?
контроля коммуникаций в виде "а обсудили ли вы вот это" нет. Команда развивает продукт, этот результат уже измеряется какими-то метриками. На уровне CPO и CTO – прямое взаимодействие со всей leadership team (можно раз в неделю, можно раз в 2 недели, раз в месяц, не важно), по развитию продукта, проблемам и т.д.
Мораль не в некомпетентности. Если когда-нибудь у вас будет спор с бизнесом и продактами на тему техдолга — просто покажите ему эту историю.
Благодаря тестовом дню можно не проникаться речами, а увидеть реальность, всю правду без преукрашиваний и решить, хочется в это ввязываться или нет
В тестовом дне есть 2 фактора: с одной стороны, мы смотрим на кандидата в реальных условиях. С другой, кандидаты смотрят на то как у нас устроена dodo is, что за код, что за команда, процессы и тд. В итоге они принимают решение уже не на основе собеседований и абстрактных бесед, а на основе того что увидели. Понимают, с чем предстоит работать. Выбор становится более осознанным. За почти 2 года что у нас действует эта практика всего 2 человека из сотни отказались от тестового дня со словами: "вы же не фейсбук чтобы к вам ехать". От остальных реакция примерно:"офигеть круто, я что, смогу прям с продакшн кодом поработать? Ого"
У нас команды и решили сами, когда им проводить стендапы. У китайской команды одно время вообще было в 8:15, норм
У нас для этого есть тестовый день. На 1 день прийти к нам поработать, увидеть код, посмотреть на команду, увидеть человека в деле
Переход на core не мгновенный, делаем постепенно, в 2019м по максимуму уедем в кубер
Планы важны, я не спорю. Но мы не сможем составить четкий план на годы вперед. Сейчас, например, я понимаю что долгосрочно мы будем вкладываться в ML. И да, мы активно растим ML команду. Но это нельзя назвать прям конкретным планом, проблемой бизнеса, задачей в бэклоге и т.д.
Еще раз, это не красивая цифра. Статья прошла слишком много редактур, надо было выпускать ее максимально эмоциональной как в начальном варианте :) Цифра — лишь ориентир, который говорит нам о том, что надо расти. Расти в компетенциях, расти в процессах, подходах, технических скиллах и т.д.
Естественно, мы не с шашкой наголо пошли нанимать джуниор разработчиков. Идем постепенно, костяк растет качественно, люди, вокруг которых строятся новые команды, растут и готовы собирать команды. В общем, работа идет.