Про «Додо пиццу» уже известно много. Бизнес компании оплетен сетью технологичных сервисов, о своей истории они написали книгу, стек технологий и архитектура системы расписаны прямо на сайте, в паре кликов от главной страницы. Даже самые неприятные факапы они спокойно и открыто обсуждают на публику.
Все это здорово, и создается романтичный флер — кажется, что в «Додо пицце» по умолчанию круто работать. Но нам было интересно понять, так ли это на самом деле.
Нет ли в открытости перегибов и подводных камней? Как люди относятся к открытым камерам на кухнях? Не являются ли технологии просто маркетинговым украшением? В конце концов, пока 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.NET Core с полным фреймворком. Там уже легче будет миграция на сам Core, но это по прежнему полный фреймворк, который работает на IIS. Все дело отделяется со своей базой, и вот у тебя уже физически отдельные инстансы. Затем перевод на .NET Core
Следующим шагом мы переводим это на Kestrel. А дальше контейнерами в Кубер. Но сейчас у нас Кубер не готов для полноценного внедрения, мы запускаем там только наименее критичные сервисы. Если что-то пойдет не так, и они отвалятся — мы переживем. Но мобильное API в Кубер завернуть пока нельзя, мы к этому еще не подготовились.
— (Фил) По стеку кажется, что вы специально пытаетесь быть в тренде. Зачем вам это?
— Это не просто тренд ради тренда. Здесь два фактора. Когда ты пишешь на новых технологиях, тебе всегда легче привлекать людей, потому что люди хотят работать с новыми вещами. Второй фактор — банальная экономика. Линуксовые сервера стоят дешевле, Kestrel выдерживает больше нагрузки чем IIS, аккуратнее работает с тредами.
То есть, выбор технологий экономически оправдан.
Когда принималось решение делать новый сайт, был устроен большой батл между React и Angular. Он был реально долгий, но выиграл React. В бэкофисе история грустнее и старее. Там до сих пор остается каша из разных версий Ангуляра — был и первый, и второй, и где-то даже четвертый. А между первым и вторым разница как небо и земля. Если миграция со второго на четвертый относительно простая, то миграция с первого на второй — это как все выбросить и переписать.
Еще там был JQuery и остается до сих пор. Но мы принципиально решили, что все новые вещи делаем на React. Стараемся потихоньку перетаскивать и старые тоже.
Постепенно весь бэкофис обрастет Реактом. Ангуляр полностью уйдет, JQuery тоже.
— (Фил) У вас JavaScript или TypeScript?
TypeScript. Команде было проще работать со статической типизацией.
— (Фил) Выбор .NET стратегически себя оправдал?
Я каждый раз задаю себе этот вопрос, и каждый раз не знаю на него ответ. Нас ничего не останавливает от того, чтобы делать новые сервисы на другом стеке. В микросервисной архитектуре это нормально работает. Естественно весь Machine Learning, например, строится на Python.
С другой стороны, я понимаю, что .NET (особенно .NET Core) это такая технология, в которую сейчас самое время инвестировать. Во-первых, она относительно новая. Во-вторых, скажем так, Microsoft сейчас отдает долги. Он делает то, что должен был сделать десять лет назад, но все пошло не так.
А с точки зрения самого языка — C# прекрасный, замечательный и офигенный. Там огромное количество синтаксического сахара и понятных конструкций, которые можно нормальным логическим образом объяснить.
Есть сложности с тем, чтобы искать разработчиков. У индустрии до сих пор крайне негативное отношение к .NET. Наверное, если бы мы были на Java стеке, разработчиков было бы в разы больше.
— (Фил) Цитата из вашей вакансии «и да у нас нет WCF. Совсем нет». Чем он вам так не зашёл?
Я помню только очень редкие кейсы, когда человек поработал с WCF не сильно глубоко, и ему было нормально. Но знаю — и сам сталкивался на практике — когда WCF был просто выстрелом себе в ногу даже не из дробовика, а из гранатомета. WCF — безумно офигенская технология, когда тебе нужно поддерживать кучу разных протоколов, когда тебе недостаточно http, когда тебе недостаточно REST обмена json-ами, WCF тебе зайдёт и даст кучу вариантов, что делать.
Но в нашем кейсе, это как из пушки по воробьям. А он достаточно сложный в настройке, малейшая неаккуратность в конфигах — и ты получаешь ошибки, уровня «где-то там в моделях что-то не смержилось, иди разбирайся, что».
— (Фил) Если Microsoft исчезнет и перестанет поддерживать свои технологии, насколько дорого это вам обойдётся? Все — нет .NET, нет Azure.
— Насчёт Azure. У нас глобальное направление — это контейнеризация в Кубер, и по факту неважно, где он запускается. Экстренное восстановление и переход на другую платформу у нас занимает где-то пять часов. С точки зрения операционки мы потеряем четыре-пять часов работы.
А если вдруг исчезнет .NET, разработчики никуда не денутся. Переход на другой стек, конечно, нас затормозит, но я не думаю, что окажет значительное влияние. Мы понимаем, что новые сервисы нужно сделать на каком-то другом стеке — Java, Go, Python, неважно — мы просто начнем постепенно переделать и поддерживать операционную работу того, что есть сейчас. Возможно, это замедлит развитие в каких-то странах, потому что будет меньше времени на новое.
Проблемы с тем, что все развалится, нет. Всё продолжит работать, но будет медленнее развиваться. Я не думаю, что у других компаний с этим иначе.
Что делать в офисе, что на удаленке, и как общаться с бизнесом
— Где у вас офис разработки?
— Главный офис в Москве. Есть офис в Сыктывкаре, небольшой офис в Нижнем Новгороде, и несколько человек на удаленке в разных городах. Именно инженеров у нас 57 человек, но есть понимание, что их не хватает, и мы планируем расти до 250 человек.
— Вам без разницы — в офисе или удаленно?
— Основной процесс, который отвечает за бизнес разработку, это LeSS. Он подразумевает, что все люди должны быть co-located, в одном месте. Но мы понимаем, что у нас этот процесс не будет единственным.
Там, где высокая степень неопределённости, например, в Китае, нужно фигачить эксперимент за экспериментом и пытаться найти работающую бизнес модель. И есть выделенная команда, которая этим занимается. Она состоит из разработчиков в Москве, Нижнем Новгороде и Ухане (Китай).
Поэтому на одну часть работы мы хотим собирать людей в Москве, чтобы они все физически находились здесь, а другую часть мы можем спокойно отдавать и на удаленку, и даже внешним командам. По общим прикидкам процентов 60-70 работы будет делаться в Москве.
— Что можно отдать на удаленку?
— К примеру система контроля качества — проект, связанный с расписанием проверок ресторанов. Там низкая степень неопределенности, процесс отработан, и можно отдать проект внешним командам.
Или сейчас есть основное мобильное приложение для заказа, но у ребят в мобильной разработке еще несколько разных запросов. Например, не так давно мы делали принтер маркировок. Когда в пиццерии сотрудники нарезают, например, томаты, их нужно промаркировать. Срок годности — 24 часа, и после этого их нельзя использовать.
Раньше маркировки были ручные. Ты наклеил наклейку, написал ручкой (ручкой!) во сколько ты это сделал, но их вечно невозможно прочитать. Это приводило к постоянным ошибкам в маркировке. И это катастрофа.
Ты эти томаты… устанешь маркировать! И только когда разработчик сам пойдет в пиццерию, он все ощутит и поймёт на своих руках. Мне вот было реально плохо, когда я маркировал восемь лексанов томатов. Запутался быстро.
Ребята из мобильной разработки тоже ходили работать в пиццерию и прочувствовали всю боль. Они сделали принтер с мобильным приложением, который автоматом тебе выдает маркировку, когда заканчивается срок годности — просто наклеиваешь и относишь. Культура близости к клиентам очень хорошо сработала.
Но этот проект для команды мобильной разработки не является ключевым. Его можно сделать только в небольшой паузе между основными проектами. Такие вещи мы тоже можем отдавать и на удаленку, и внешним командам.
— Как эти 57 человек распределяют между собой гору работы?
— В основном у нас фича-команды, то есть команды, которые могут взять практически любую часть системы. У них нет привязки к определенным вещам. Раньше были, и это приводило к проблемам нехватки компетенций.
Есть несколько выделенных команд — это команда, которая занимается всей облачной инфраструктурой Azure, и мобильная разработка.
— Как разработка взаимодействует со всеми остальными?
— Раз в две недели проходит планирование вместе со всеми стейкхолдерами и продактами. Ребята могут спокойно задать вопросы бизнесу, каких целей он хочет достичь, чтобы понять, что делать через одну-две недели, когда стартанет новый спринт.
Ещё одна встреча — это спринт-ревью. Тоже раз в две недели по пятницам. Все стейкхолдеры смотрят, что сделано за две недели (а сделано для нас — это вытащено в продакшн) и дают обратную связь.
От продактов ребята получают обратную связь каждый день по несколько раз, потому что они физически рядом находятся, и могут очень быстро обо всем пообщаться.
У продактов со стейкхолдерами есть отдельная встреча, где они заранее готовят задачи разработчикам. Дальше разработка узнает об этих задачах на общей встрече в середине спринта, через неделю они берут их в работу, и через две недели показывают стейкхолдерам.
— Разработка не завалена работой по самую макушку? У всех по десять идей и двадцать комментариев в день.
Не двадцать комментариев в день, а пятьдесят. И ещё в два раза больше идей. Это абсолютно нормально. Важно просто расставлять приоритеты, понимать ограничение пропускной способности, сколько мы можем сделать из этих задач.
Зачем разработчикам работать на кухне
— Это серьезно, что разработчику надо проходить стажировку на кухне?
— Пока эта штука опциональная, но от неё очень большой профит. У нас вся компания кроме разработчиков проходит обязательную стажировку, но не в пиццериях, а в учебном центре в Сыктывкаре.
Для IT мы пробовали запустить стажировки в Москве — на шесть смен выходить на работу в пиццерию. Человек десять-двенадцать прошли.
— Как они реагируют?
— Восторженно. Есть такое понятие, как Гемба. Это когда ты идешь на место производства, где создается сама ценность. Для Тойоты, которая придумала гембу — это производственный завод. Для нас это кухня.
Ты приходишь в гембу не потому что тебе весело и захотелось отвлечься от компьютера, покатать пиццу. Ты идешь для того, чтобы словить инсайты, понять, как твой бизнес работает в реальности, и из этого сделать выводы, придумать улучшения. Например поэтому для продактов и аналитиков гемба — это обязательная часть работы.
— Как реагируют на предложение поработать, а не на сам процесс?
— Кто-то говорит «я не хочу». При том, что это офигенский разработчик. Но окей, они просто упускают момент и возможность лучше понять клиентов.
Людей со стороны перспектива стажировок на кухне не отпугивает?
Отпугивает, и ладно. Да, это всегда сложный момент и всегда дискуссионный вопрос. Если человек отреагирует так, что «я ни в коем случае не пойду на кухню, и из-за этого даже не буду с ними разговаривать», я не могу представить, что движет этим человеком, не могу понять мотивации.
При этом у нас много кейсов, когда люди говорят прямо: «я не хочу идти на кухню. Но я хочу быть разработчиком и фигачить кучу кода, делать продукты». И они это делают. Но они пришли поговорить, они обсудили, и это нормально.
— Почему только для разработчиков не сделали гембу обязательной?
— Потому что это нужно не во всех частях системы. Есть часть, где это крайне полезно, но например команда инфраструктуры — для них клиенты, это разработчики. То есть их гемба не в пиццерии, а в разработке. При том, что там есть люди, которые ходили на кухню и понимали, зачем мы все это делаем.
Зачем при найме нужно проходить тестовый день
— Что человек должен уметь и знать приходя к вам?
— Во-первых это софт скиллы, определенный уровень культуры, когда понимаешь, что не просто пишешь код, а создаешь продукты. Тебе важно общаться с бизнесом, с командой, ты должен этого не бояться.
— Нет шанса, что с таким подходом вы возьмете необразованного болтуна?
— Ценится не тот человек, который постоянно говорит. Ценится тот, кто умеет в правильное время задать правильные вопросы. Среди софт скиллов должна быть готовность к изменениям. Мы живем в ситуации, когда у нас резко появляются задачи, и весь фокус переходит на них.
А с точки зрения техники, нам важно хорошее знание .NET. Очень хорошее знание. Дальше есть два аспекта. Первый связан с базами данных, второй — с фронтом. Если человек неплохо понимает, как работать с базами, что такое транзакции, почему распределенные транзакции — это тяжело, и если он понимает все на глубоком уровне, то добро пожаловать в «Додо».
Если базы данных он понимает не очень глубоко, но при этом хорош в Реакте или Ангуляре — тоже добро пожаловать. Если у него что-то одно из этих трёх аспектов, то мы, скорее всего, не возьмем. Но расскажем, как по нашему мнению стоит прокачиваться, что почитать и изучить.
— (Фил) То есть вы формируйте команды из фулстеков?
— По большей части да. Идеальная команда для нас — это пять человек, среди которых один QA инженер, четыре разработчика, и как минимум один из них с фокусом на фронтенде. Полностью выделенных фронтенд разработчиков у нас всего три человека на всю компанию.
Я не вижу с этим больших проблем. Если у нас начинаются трудности во фронте, то матерый чистый фронтендер идёт в команду и проводит там неделю или месяц. Его задача не просто сделать работу, но и передать свои знания, чтобы команда могла все это поддерживать.
То есть у нас есть и фуллстек разработчики, которых большинство, и разработчики со специализациями.
— (Фил) Бывало, что вы не брали разработчика, потому что он токсичный?
— Я не верю, что токсичный человек токсичный постоянно. В 99% случаев в этот день у него что-то пошло не так. Вот у меня вчера ребенок истерику устроил, и я был токсичный, пришел на интервью в плохом настроении.
Но мы стараемся особым образом сформулировать вопросы, чтобы докопаться. Если ты видишь, что человек хочет подгадить текущему работодателю, то это не очень хорошо. Я не оправдываю такие вещи, но до мотивов надо докопаться.
— Если у человека гениальное инженерное , но на собеседовании он запарывается на банальной ошибке в теории, какой вы сделаете вывод?
— Мы пригласим его на тестовый день — это один из наших этапов отбора. Человек приходит к нам поработать, обычно с девяти до трёх. Это работа в паре с одним из наших разработчиков над реальной задачей. Стараемся сделать так, чтобы в конце дня задач уехала в продакшн, но не всегда это получается.
Это работает очень хорошо. У нас были кейсы, когда после собеседования мы говорили «да», но после тестового дня понимали, что вообще не хотим видеть этого человека в команде. Были кейсы, когда человек не очень хорошо проходил собеседование, но на тестовом дне становилось понятно, что он мега крут, и его надо брать.
А однажды человек пришел, мы хотели его взять, но после тестового дня он сказал: «ребята, я не хочу работать с вашим легаси». Это абсолютно нормальная история. А если бы мы сделали ему оффер, он бы его принял, разочаровался и ушел бы через месяц-другой.
— Многие компании тратят месяца по три на адаптацию сотрудников, а тут он должен прийти и в первый день окунуться в продакшн?
— Да.
— Думаю, многие хорошие люди могут на этом отсеяться.
— Я такого не встречал. Драйв идет с нашей стороны, иногда мы даже готовим специальные задачи под тестовый день. Вообще я помню только один случай, когда кандидат отреагировал: «Вы же не Google или Facebook чтобы к вам идти на тестовый день». Остальные в восторге. Для них это реальная возможность изнутри увидеть, с чем предстоит работать, с кем быть в одной команде. Хорошие разработчики это очень ценят.
— За тестовый день платят?
— Нет.
Что значит полная прозрачность и открытость
— Как вам живется в условиях полной прозрачности?
— Прекрасно.
— Прекрасно?
— Конечно! Прозрачность — это такая штука, на которую надо смотреть с двух сторон. Первая сторона, это прозрачность наружу, когда мы открыто говорим, что происходит у нас внутри. Успехи, факапы — все. Вторая — это открытость внутри. Возможность спокойно пойти и дать обратную связь кому угодно, хоть Федору.
Прозрачность и открытость мотивируют и заставляют быть в тонусе. Ты можешь сжечь мосты, и у тебя не останется возможности зафакапить.
— Если говорить о кухне, тебе не кажется, что это ужасно, когда люди работают под камерами?
— А почему это ужасно?
— Люди чувствуют себя под наблюдением постоянно.
— Да. Это очень сильно мотивирует делать свою работу хорошо.
— Разве это не давит? Получается вынужденная мотивация.
— Вот ты как предпочитаешь делать свою работу? Тебе дали задачу, ты говоришь «ребят, я пока уйду, обещаю, что сделаю всё хорошо и вернусь с результатом». Это достаточно специфичный подход. Где-то на середине пути ты поймешь, что неплохо бы получить обратную связь.
Придешь с промежуточным результатом к человеку, который дал тебе задачу. И ты начнёшь по-любому открывать то, что ты делаешь. Банально ради обратной связи. Открытость не только показав результат, но и показав процесс, как ты это делаешь, даст тебе больше доверия со стороны клиентов.
— Это нормально — идти и получать обратную связь добровольно. Но под камерами? Такие люди, наверное, читают Оруэлла, и не понимают, что там страшного.
— Когда это возведено на уровень культуры, ты не смотришь на открытые камеры. Ты понимаешь, что не сделаешь ничего, если не получишь обратную связь на какую-то часть работы. Камеры — это та же самая мотивация и обратная связь. Если кто-нибудь не дай бог увидит, что ты ингредиент с пола поднял, тебе сразу накидают кучу обратной связи, пиццерии могут снизить рейтинг.
Но здесь нет элемента запуганности. Если ты сделаешь что-то не так, тебя не накажут. Это будет повод обратить внимание и сделать как-то по-другому. И это как психология распространяется не только на пиццерию. Это везде. Когда ты знаешь, что за твою работу тебя не накажут, тебе и скрывать нечего. В этом смысл.
Вообще, камеры есть только на начиненни. На кухне их нет. Это мотивационный момент открытости для клиентов, условно говоря, «нам нечего скрывать, в твою пиццу не плюнут и ничего не подложат». Внутри есть помещение, где ты можешь спокойно покушать. Сотрудники тоже отдыхают. Они не круглосуточно под камерами.
Это не Дом-2. Нет такого, что давайте следить, как развивается жизнь сотрудников пиццерии.
Плюс места, где готовят пиццу, часто бывают в торговых центрах. Там и так много людей, которые ждут заказы, и ты перед ними готовишь. Почему, когда над тобой камера — это плохо, а когда человек на тебя смотрит — это нормально?
— Зарплаты у вас тоже открытые?
— Нет. Ты не можешь некоторые вещи сделать прозрачными легко: «а давайте с завтрашнего дня откроем все зарплаты» или «давайте с завтрашнего дня станем прозрачным ещё где-то» просто так. Нужна подготовка.
Даже к камере на кухне есть определенная подготовка. Это выверенные стандарты, тренировка пицца-мейкеров, чтобы они везде следили за чистотой, мыли руки. То есть готова система, при которой мы можем спокойно всё открыть.
Когда ты строишь систему, а потом делаешь шаг к открытости — это сжигание мостов. Пути назад уже нет, ты открылся.
Автор: Артем Малышев
