Хабрахабр

Зачем программисту стажировка на кухне — разговор с «Додо пиццей» про гембу, .NET и открытость

Бизнес компании оплетен сетью технологичных сервисов, о своей истории они написали книгу, стек технологий и архитектура системы расписаны прямо на сайте, в паре кликов от главной страницы. Про «Додо пиццу» уже известно много. Даже самые неприятные факапы они спокойно и открыто обсуждают на публику.

Но нам было интересно понять, так ли это на самом деле. Все это здорово, и создается романтичный флер — кажется, что в «Додо пицце» по умолчанию круто работать.

Как люди относятся к открытым камерам на кухнях? Нет ли в открытости перегибов и подводных камней? В конце концов, пока IT гиганты вокруг зазывают разрабов пожизненным запасом печенек и личными кофеносцами, «Додо» продвигает периодический труд на кухне — чтобы прочувствовать боль клиентов и обычных сотрудников. Не являются ли технологии просто маркетинговым украшением?

Мы с fillpackart обо всем этом расспросили, и нам ответил Александр Андронов, СТО «Додо пиццы».

Зачем пиццерии технологии

— Как Федор открыл так быстро пиццерию, после работы обычным кассиром?

Взял и сделал. — Нет ничего сложного. Для этого не нужна сверх подготовка и сверх деньги.

— А по-моему это достаточно дорого.

Там нужно 15-20 миллионов инвестиций. — Это дорого, если открывать пиццерию где-нибудь в Москве, в пределах третьего транспортного кольца. Там не было ресторана, она работала только на доставку, и инвестиции были небольшие. А первая «Додо пицца» открывалась в глубине Сыктывкара, в подвале.

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


Федор Овчинников, основатель «Додо пиццы».

— Идея делать упор на технологии была сразу?

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

Почему пицца? — Когда людей тянет к технологиям, пищевая сфера, ресторанный бизнес — часто далеко не в первых рядах среди их интересов.

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

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

— Значит, вы еще не получаете профит от технологий?

Например, мы консолидируем все каналы продаж, у нас единая система колл-центров. Если говорить глобально, то профит только-только начинает проявляться. Там тебе нужно созваниваться с конкретной пиццерией, которая привезет твой заказ. Ни у Dominos, ни у Papa John's такого нет.

— Но это же не так.

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

Что у вас главнее — пицца или технологии? — Ок.

Без пиццы технологии не имеют смысла. — Они неразрывны. Но без технологий была бы просто ещё одна пиццерия, и мы скорее всего не смогли бы так масштабироваться.

Это то же самое, что спросить: важнее разработчики или QA-инженеры.

— (Фил fillpackart) Разработчики, конечно

На вопрос нельзя однозначно отвечать. — Ты не прав. Когда все уже разработано, кто важнее? Все зависит от того, в каком времени ты находишься. Ими будут вынуждены стать разработчики. Вы будете плакать, если у вас не хватает QA инженеров.

И ровно также технологии и пицца не существуют друг без друга.

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

Иногда объяснить разработчикам, что мы делаем — это проблема. — Это может показаться на первый взгляд. 1С настроить?» Их первая реакция: «что там, сайт для продажи пиццы делать?

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

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

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

— В случае с Zume Pizza — не перегиб с технологиями?

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

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

Додо ИС

Через пару месяцев после открытия первой пиццерии появилась Dodo IS — информационная система, на которой держится работа всей компании. Это набор микросервисов собранных в одну инфраструктуру. Ей пользуются менеджеры, клиенты, кассиры, повара, тайные покупатели, сотрудники колл-центра — все.

Первая — для клиентов. Условно Dodo IS делится на две части. Вторая направлена на партнеров-франчайзи. Туда входят сайт, мобильное приложение, колл-центр. Через систему проходят накладные от поставщиков, управление персоналом, вывод людей на смены, автоматический расчет зарплат, онлайн обучения для персонала, аттестация управляющих, система проверки качества и тайных покупателей. Она помогает управлять пиццериями.

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

— (Фил) Система сложная. Много оказалось просчетов в архитектуре, допущенных с самого начала?

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

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

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

Если бы его не сделали быстро, возможно «Додо пиццы» просто бы не существовало. Но я не могу назвать старый сайт просчетом.

— (Фил) Остались неправильные решения, которые сейчас мешают?

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

А вы говорите, что у вас все быстро. — (Фил) Любое изменение в крупных компаниях занимает целую вечность. Как это получается?

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

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

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

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

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

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

— (Фил) Почему у вас не боятся брать на себя такую ответственность?

А когда ты не боишься, когда тебе доверяют — ты позволяешь себе рисковать. Людей, которые берут ответственность, никто не накажет.

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

Какие технологии стоят за пиццериями

— (Фил) В 2011 году .NET не был очевидным выбором. Почему выбрали его?

NET — Просто наши ребята знали .

А как переходили на . — (Фил) Исчерпывающе. NET Core?

Из старых перевели процентов двадцать пять. Все новые сервисы делаются на Core. Первый — это заход на ASP. Мы объединяем перенос с распилом монолита, и это делается в несколько этапов. Там уже легче будет миграция на сам Core, но это по прежнему полный фреймворк, который работает на IIS. NET Core с полным фреймворком. Затем перевод на . Все дело отделяется со своей базой, и вот у тебя уже физически отдельные инстансы. NET Core

А дальше контейнерами в Кубер. Следующим шагом мы переводим это на Kestrel. Если что-то пойдет не так, и они отвалятся — мы переживем. Но сейчас у нас Кубер не готов для полноценного внедрения, мы запускаем там только наименее критичные сервисы. Но мобильное API в Кубер завернуть пока нельзя, мы к этому еще не подготовились.

Зачем вам это? — (Фил) По стеку кажется, что вы специально пытаетесь быть в тренде.

Здесь два фактора. — Это не просто тренд ради тренда. Второй фактор — банальная экономика. Когда ты пишешь на новых технологиях, тебе всегда легче привлекать людей, потому что люди хотят работать с новыми вещами. Линуксовые сервера стоят дешевле, Kestrel выдерживает больше нагрузки чем IIS, аккуратнее работает с тредами.

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

Он был реально долгий, но выиграл React. Когда принималось решение делать новый сайт, был устроен большой батл между React и Angular. Там до сих пор остается каша из разных версий Ангуляра — был и первый, и второй, и где-то даже четвертый. В бэкофисе история грустнее и старее. Если миграция со второго на четвертый относительно простая, то миграция с первого на второй — это как все выбросить и переписать. А между первым и вторым разница как небо и земля.

Но мы принципиально решили, что все новые вещи делаем на React. Еще там был JQuery и остается до сих пор. Стараемся потихоньку перетаскивать и старые тоже.

Ангуляр полностью уйдет, JQuery тоже. Постепенно весь бэкофис обрастет Реактом.

— (Фил) У вас JavaScript или TypeScript?

Команде было проще работать со статической типизацией. TypeScript.

NET стратегически себя оправдал? — (Фил) Выбор .

Нас ничего не останавливает от того, чтобы делать новые сервисы на другом стеке. Я каждый раз задаю себе этот вопрос, и каждый раз не знаю на него ответ. Естественно весь Machine Learning, например, строится на Python. В микросервисной архитектуре это нормально работает.

NET (особенно . С другой стороны, я понимаю, что . Во-первых, она относительно новая. NET Core) это такая технология, в которую сейчас самое время инвестировать. Он делает то, что должен был сделать десять лет назад, но все пошло не так. Во-вторых, скажем так, Microsoft сейчас отдает долги.

Там огромное количество синтаксического сахара и понятных конструкций, которые можно нормальным логическим образом объяснить. А с точки зрения самого языка — C# прекрасный, замечательный и офигенный.

У индустрии до сих пор крайне негативное отношение к . Есть сложности с тем, чтобы искать разработчиков. Наверное, если бы мы были на Java стеке, разработчиков было бы в разы больше. NET.

Совсем нет». — (Фил) Цитата из вашей вакансии «и да у нас нет WCF. Чем он вам так не зашёл?

Но знаю — и сам сталкивался на практике — когда WCF был просто выстрелом себе в ногу даже не из дробовика, а из гранатомета. Я помню только очень редкие кейсы, когда человек поработал с WCF не сильно глубоко, и ему было нормально. WCF — безумно офигенская технология, когда тебе нужно поддерживать кучу разных протоколов, когда тебе недостаточно http, когда тебе недостаточно REST обмена json-ами, WCF тебе зайдёт и даст кучу вариантов, что делать.

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

Все — нет . — (Фил) Если Microsoft исчезнет и перестанет поддерживать свои технологии, насколько дорого это вам обойдётся? NET, нет Azure.

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

NET, разработчики никуда не денутся. А если вдруг исчезнет . Мы понимаем, что новые сервисы нужно сделать на каком-то другом стеке — Java, Go, Python, неважно — мы просто начнем постепенно переделать и поддерживать операционную работу того, что есть сейчас. Переход на другой стек, конечно, нас затормозит, но я не думаю, что окажет значительное влияние. Возможно, это замедлит развитие в каких-то странах, потому что будет меньше времени на новое.

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

Что делать в офисе, что на удаленке, и как общаться с бизнесом

— Где у вас офис разработки?

Есть офис в Сыктывкаре, небольшой офис в Нижнем Новгороде, и несколько человек на удаленке в разных городах. — Главный офис в Москве. Именно инженеров у нас 57 человек, но есть понимание, что их не хватает, и мы планируем расти до 250 человек.


Офис в Сыктывкаре

— Вам без разницы — в офисе или удаленно?

Он подразумевает, что все люди должны быть co-located, в одном месте. — Основной процесс, который отвечает за бизнес разработку, это LeSS. Но мы понимаем, что у нас этот процесс не будет единственным.

И есть выделенная команда, которая этим занимается. Там, где высокая степень неопределённости, например, в Китае, нужно фигачить эксперимент за экспериментом и пытаться найти работающую бизнес модель. Она состоит из разработчиков в Москве, Нижнем Новгороде и Ухане (Китай).

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

— Что можно отдать на удаленку?

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

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

Ты наклеил наклейку, написал ручкой (ручкой!) во сколько ты это сделал, но их вечно невозможно прочитать. Раньше маркировки были ручные. И это катастрофа. Это приводило к постоянным ошибкам в маркировке.

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

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

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

— Как эти 57 человек распределяют между собой гору работы?

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

Есть несколько выделенных команд — это команда, которая занимается всей облачной инфраструктурой Azure, и мобильная разработка.

— Как разработка взаимодействует со всеми остальными?

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

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

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

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

У всех по десять идей и двадцать комментариев в день. — Разработка не завалена работой по самую макушку?

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

Зачем разработчикам работать на кухне

— Это серьезно, что разработчику надо проходить стажировку на кухне?

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

Человек десять-двенадцать прошли. Для IT мы пробовали запустить стажировки в Москве — на шесть смен выходить на работу в пиццерию.

— Как они реагируют?

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

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

— Как реагируют на предложение поработать, а не на сам процесс?

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

Людей со стороны перспектива стажировок на кухне не отпугивает?

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

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

— Почему только для разработчиков не сделали гембу обязательной?

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

Зачем при найме нужно проходить тестовый день

— Что человек должен уметь и знать приходя к вам?

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

— Нет шанса, что с таким подходом вы возьмете необразованного болтуна?

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

NET. А с точки зрения техники, нам важно хорошее знание . Дальше есть два аспекта. Очень хорошее знание. Если человек неплохо понимает, как работать с базами, что такое транзакции, почему распределенные транзакции — это тяжело, и если он понимает все на глубоком уровне, то добро пожаловать в «Додо». Первый связан с базами данных, второй — с фронтом.

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

— (Фил) То есть вы формируйте команды из фулстеков?

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

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

То есть у нас есть и фуллстек разработчики, которых большинство, и разработчики со специализациями.

— (Фил) Бывало, что вы не брали разработчика, потому что он токсичный?

В 99% случаев в этот день у него что-то пошло не так. — Я не верю, что токсичный человек токсичный постоянно. Вот у меня вчера ребенок истерику устроил, и я был токсичный, пришел на интервью в плохом настроении.

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

— Если у человека гениальное инженерное мышление, но на собеседовании он запарывается на банальной ошибке в теории, какой вы сделаете вывод?

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

У нас были кейсы, когда после собеседования мы говорили «да», но после тестового дня понимали, что вообще не хотим видеть этого человека в команде. Это работает очень хорошо. Были кейсы, когда человек не очень хорошо проходил собеседование, но на тестовом дне становилось понятно, что он мега крут, и его надо брать.

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

— Многие компании тратят месяца по три на адаптацию сотрудников, а тут он должен прийти и в первый день окунуться в продакшн?

— Да.

— Думаю, многие хорошие люди могут на этом отсеяться.

Драйв идет с нашей стороны, иногда мы даже готовим специальные задачи под тестовый день. — Я такого не встречал. Остальные в восторге. Вообще я помню только один случай, когда кандидат отреагировал: «Вы же не Google или Facebook чтобы к вам идти на тестовый день». Хорошие разработчики это очень ценят. Для них это реальная возможность изнутри увидеть, с чем предстоит работать, с кем быть в одной команде.

— За тестовый день платят?

— Нет.

Что значит полная прозрачность и открытость

— Как вам живется в условиях полной прозрачности?

— Прекрасно.

— Прекрасно?

Прозрачность — это такая штука, на которую надо смотреть с двух сторон. — Конечно! Успехи, факапы — все. Первая сторона, это прозрачность наружу, когда мы открыто говорим, что происходит у нас внутри. Возможность спокойно пойти и дать обратную связь кому угодно, хоть Федору. Вторая — это открытость внутри.

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

— Если говорить о кухне, тебе не кажется, что это ужасно, когда люди работают под камерами?

— А почему это ужасно?

— Люди чувствуют себя под наблюдением постоянно.

Это очень сильно мотивирует делать свою работу хорошо. — Да.

Получается вынужденная мотивация. — Разве это не давит?

Тебе дали задачу, ты говоришь «ребят, я пока уйду, обещаю, что сделаю всё хорошо и вернусь с результатом». — Вот ты как предпочитаешь делать свою работу? Где-то на середине пути ты поймешь, что неплохо бы получить обратную связь. Это достаточно специфичный подход.

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

Но под камерами? — Это нормально — идти и получать обратную связь добровольно. Такие люди, наверное, читают Оруэлла, и не понимают, что там страшного.

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

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

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

Нет такого, что давайте следить, как развивается жизнь сотрудников пиццерии. Это не Дом-2.

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

— Зарплаты у вас тоже открытые?

Ты не можешь некоторые вещи сделать прозрачными легко: «а давайте с завтрашнего дня откроем все зарплаты» или «давайте с завтрашнего дня станем прозрачным ещё где-то» просто так. — Нет. Нужна подготовка.

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

Пути назад уже нет, ты открылся. Когда ты строишь систему, а потом делаешь шаг к открытости — это сжигание мостов.

Теги
Показать больше

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

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

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

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