Героем нового выпуска подкаста Doubletapp «Что-то на программистском», который мы записали на кэмп-конференции South HUB, стал CTO Dodo Engineering Павел Притчин. Он рассказал о своей роли в компании, какие технические решения позволили Dodo быстро стартовать и масштабироваться, сколько времени топ-менеджер должен вкладывать в планирование и почему в IT важны горизонтальные связи и нетворкинг.
Dodo – это несколько компаний. Dodo Engineering – это айтишная часть. Там находятся все цифровые профессии: продакты, разработчики, IT-менеджеры. И я там, собственно, CTO. Я отвечаю за всю техническую часть, за все производство, чтобы деливери деливерилось. У меня есть мои технические команды: хеды, архитектуры, security, мобилки. И есть еще ветка, где находятся продакты. Мой руководитель – CIO Dodo. И над ним уже просто CЕO Dodo Brands.
Значит, CIO больше про бизнес, а ты больше про технологии?
Скорее да, но я тоже про бизнес. Мой доклад [на кэмп-конференции South Hub] как раз и был про бизнес-мышление СТО.
Во-первых, надо свой бизнес понимать, потому что ты не можешь технические решения принимать, не понимая бизнес. Например, если тебе нужно резко расширяться в праздничные дни, и ты понимаешь, что у тебя в какой-то момент на 20-30% больше приходят нагрузки, конечно, ты должен под это делать всю свою инфраструктуру. Казалось бы, сугубо техническое решение, часть технической стратегии, но его можно принимать только смотря на бизнес.
А CTO может стать только человек с техническим бэкграундом, или может менеджер, продакт, проджект-менеджер вырасти в CTO?
Я считаю, что все-таки CTO должен быть с бэкграундом инженерным, с бэкграундом разработчика. Это важно, на мой взгляд, потому что, во-первых, тебе придется управлять разработчиками, и надо понимать, как эта кухня работает. Разработка – не то же самое, что работа в бизнесе с точки зрения команд. Это иначе организуется. А во-вторых, у меня есть какая-то своя экспертиза, тоже очень помогает. Если я всю жизнь занимался разработкой, был NET-разработчиком, был в инфраструктуре какое-то время, то, наверное, в этих областях я понимаю больше. Я могу в этих областях не просто собирать умных людей и спрашивать, а позицию экспертную выдавать.
Как тогда разработчику приобрести бизнес-компетенцию, чтобы стать СТО? Какими личностными качествами он должен обладать?
Могу назвать какие-то мои особенности, мои навыки, которые, наверное, помогли стать CTO. Во-первых, я не боялся принимать несколько рискованные решения как в отношении личной карьеры, так и своего дела. Например, когда мне предлагали какие-то позиции, и это было связано с кучей проблем. И это, конечно, страшно. Ты думаешь: зачем мне выходить из зоны комфорта, я здесь все знаю, а вдруг не получится, а вдруг будет плохо. Но в итоге, если ты справляешься с такими вызовами и испытаниями, то ты приобретаешь новый навык, который помогает расти дальше. То есть первое, наверное, свойство – это толика риска. Не надо быть совсем рискованным, но суперконсервативная, осторожная стратегия по жизни здесь не подойдет.
Еще одно – нужно быть в разных доменах. Нужна некоторая насмотренность, как в искусстве бывает. Ты должен быть в разных доменах, в разных местах, и тогда ты укладываешь в одной голове, как работать в стартапе, как работать в суперзрелом бизнесе, где важна надежность, стабильность, чтобы все не падало, работало и так далее.
То есть прежде чем стать CTO, нужно походить по компаниям разного формата и набраться там насмотренности?
Да. Или просто попасть в удачный стартап, который так быстро вырастет, что ты как разработчик номер один, два, три в итоге станешь СТО.
У меня весь карьерный путь был в Dodo, но внутри Dodo я переходил между разными частями и занимался разными вещами. Не обязательно приходить на рынок и искать что-то, вполне может быть что-то интересное в компании, где вы уже работаете, надо просто поискать, посмотреть.
***
Есть базовая гигиена менеджмента вроде пообщаться на «1:1», узнать, как идут дела, провести перформанс-ревью, оценить результаты, спросить: «Ты сам-то что планируешь дальше?» И люди обычно рассказывают либо, если они ничего не планируют, так и говорят. Но мне кажется, что надо предлагать. Одна из моих задач – это предлагать людям возможности. Они могут от них отказаться, и мне с этим нормально. Не все искатели приключений, кому-то хочется прокачиваться в своей сфере, уходить глубже, глубже, глубже.
Хантишь кого-то со стороны на высокие позиции?
Если нужно закрыть какую-то позицию, и внутри нет достойного кандидата, тогда да. Я, наверное, чаще просто нахожу интересного человека или интересного специалиста в какой-то области, понимаю, что у нас нет этого или не закрыта эта область, и просто придумываю под него какую-то структуру, какую-то роль. Потому что если у нас на текущий момент нет какой-то экспертизы, то мы же в ней и не понимаем ничего. Значит, нормально пригласить внешнего человека и под него придумать что-то.
Я бы сказал, что у нас достаточно стандартный путь. У нас своя собственная разработка – Dodo IS, система, которая пронизывает весь бизнес и все операционные части: прием заказа, готовка, доставка курьером, прием кадров. Это наша собственная система, которая с нуля разрабатывается с 2011 года. Конечно, сначала это был обычный, классический монолит, в котором все было накидано, который прекрасно работал первые пару лет и позволил бизнесу стартануть. Это, наверное, было первое правильное техническое решение.
Потом наступил второй этап, и нужно было сильно вкладываться как раз в технику, потому что, когда я, например, приходил (это был 2015 год), у меня не было ни одной свободной пятницы. Я просто на пятницу ничего не планировал, потому что каждую пятницу ждал, что оно сейчас упадет. И тогда наступил второй этап, и правильным техническим решением было начать бороться с этой нагрузкой.
Мы начали отпил: отделяли сначала базы данных, потом отделяли какие-то сервисы, между ними была шина данных. И это было тоже, на мой взгляд, верное решение, потому что мы упирались в перформанс-базы, когда монолитная база, в нее все приходят, а там один запрос кладет все.
И, наверное, последний этап технических решений – это то, что мы стали децентрализовать систему. То есть начали не только бороться какими-то быстрыми способами с нагрузкой вот этого нашего монолита, но и все по классике – отделять разные куски и делать между ними связанность через события. То есть, например, производство и доставка отделены от приема заказа.
И в этом есть какая-то избыточность, потому что у тебя разные способы приема заказа есть. И так, и эдак, и даже в ресторане есть касса, есть киоск, можно сделать заказ через мобильное приложение. Если что-то в моменте работает не так, как надо, то можно обратиться к другому источнику. И такая избыточность окупается, потому что дает большую надежность.
***
Это какая-то степень риска, с которой надо жить. У нас в основном бизнес в России находится, больше 80% выручки идет в России. Как быть? Может быть, надо сфокусироваться на России? Мы решили, что нет, давайте развиваться и там, и там.
То есть стратегия международного развития в целом осталась такой же. Единственное – поменялась локация. Если до 2022 года фокус был на Великобритании и открытии точек там, то после 2022-го флагманские пиццерии открываются в Дубае.
Мне кажется, тут просто вопрос в том, что есть некоторые локации в мире, в которых действительно практически невозможно российскому бизнесу что-то делать. Вот, как я сказал, Великобритания. Но мир очень большой, мир огромный. Он не ограничивается только лишь некоторыми странами Европы.
В Дубае кто целевые клиенты сейчас? Русскоязычные люди, которые там живут, или те, кто приезжает работать на более простой работе, типа таксистов? Или, может, самим коренным арабам интересно зайти и посмотреть, что это?
И те, и другие. Это очень зависит от локации, где ты открылся. Коренным арабам, скорее, больше интересно кофе и кофейный бизнес наш, Дринкит.
Первая Dodo Pizza в Дубае открылась на Марине, и понятно, что подавляющее большинство клиентов – это европейцы, и из них большинство русскоязычные. Но сейчас открылась вторая точка, уже в другой части Дубая, и, может быть, там как-то процент изменится.
Могу рассказать очень интересный пример дихотомии между европейским населением Дубая и индусско-пакистанским населением Дубая. Очень популярны в Дубае такие блюда, как болы рисовые – тарелка с рисом и топпинг-начинка. Встал вопрос, как много риса класть в этот бол. Провели тесты закрытые между аудиторией, и оказалось, что какое-то среднее количество, на наш взгляд оптимальное, для европейской аудитории – это много. Они говорят, что риса много, надо больше начинки. Но для индусской аудитории это мало, надо больше риса. В итоге ты не можешь сделать и тем, и другим, поэтому решили оставить какое-то срединное значение. Если кто-то хочет, может просто добавить дополнительную порцию.
У меня такой подход здесь: если я прекрасно понимаю, как это делается, какая это область, как это работает, я это спокойно могу делегировать. Если область неопределенности, я даже сам не могу сформулировать цель, тогда я стараюсь это делать сам. Бывают еще ситуации каких-то суперважных проектов, когда я лично подключаюсь, когда просто хочется минимизировать проблемы. Это тактически верно.
Стратегически, конечно, очень плохо, потому что я что-то знаю, я сам могу подключиться и какой-то личный проект затащить, но получается, что команда-то не учится на этом, им-то не дается вот та самая возможность вырасти в каком-то виде. Поэтому я очень точечно и осторожно к этому подхожу, плюс стараюсь не загружать себя большим количеством операционной рутины.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
12225 тендеров
проведено за восемь лет работы нашего сайта.
У меня есть такое правило, что больше 40% тойла личного у меня не должно быть. Если больше 50% – все, это аларм, пора что-то с этим делать.
Как делегировать в том втором кейсе, когда ты вообще не знаешь, что делать? Как нанять человека и быть уверенным, что он сможет затащить?
Во-первых, ты не будешь уверен никогда, и поэтому тебе нужен какой-то план B, какие-то чек-поинты, ты должен обложиться запасными вариантами и морально даже, может быть, сразу принять, что ничего не получится, потому что иначе будет сложно жить. Не должно быть, как это говорится, one way door decision – такого решения, которое неоткатываемо.
Во-вторых, надо выбирать по человеку, по личности, потому что задаче можно научиться. Личность и человек – это что-то большее, более постоянное. Мне важно, когда я работаю с лидерами, чтобы у нас был какой-то личный контакт, чтобы мы могли вместе сработаться.
Было такой кейс недавно. Нужно было нанять 1С-лида. Мы не особо занимались 1С, вопрос: как найти эксперта? В итоге я пришел к знакомым, попросил найти каких-то их экспертов, которым они доверяют, с кем они работают, и просто с экспертами пообщался на предмет адекватности личности. Я ему объяснял задачу, слушал, что он скажет, как он это видит. Если мне показалось, что эксперт нормальный, я просто говорю: да, давай собесить. Я взял нескольких экспертов, и таким образом мы с ними провели технические интервью.
Что важнее – планировать или уметь быстро реагировать на меняющиеся обстоятельства?
Мне хочется сказать, что важно и то, и другое. Собственно, я об этом немножко на South Hub'е и рассказывал, как подружить вот эти две стези между собой. Мой секрет заключается в том, что на уровне CTO тебе, во-первых, нужно и то, и другое. Ты просто не можешь не быть реактивным – [когда] все будет меняться, ты что, будешь следовать планам старым? Но, с другой стороны, ты не можешь и не иметь свой план, потому что, в конце концов, на большой дистанции ты должен прийти в ту точку, в которую ты хочешь прийти. И одно мешает другому.
Когда ты планируешь, у тебя складывается прекрасная картина, ты видишь, как прийти к этому целевому состоянию. Когда ты действуешь реактивно, ты просто решаешь проблемы. Это тоже круто, тоже надо всем. Но на большой дистанции смотришь – и пришел куда-то не туда или вообще никуда не пришел.
Я считаю, что нужна и та, и другая деятельность, важно просто их разделять во времени. То есть отдельным временным потоком ты планируешь, и на каждое будущее действие всегда есть план А, B, С, проработка какая-то. Но в реальном временном потоке ты просто действуешь по обстоятельствам. И магическим образом та проработка планов, которая у тебя была, улучшает твои реактивные действия. Это как обучение. Ты обучился и потом, когда что-то произошло, ты уже более готов к этому.
Сколько времени топ-менеджер должен вкладывать в планирование?
Я стараюсь вкладывать большую часть. Я бы не сказал, что это прям планирование, то есть нет такого, что я прямо пишу план на такой-то там день, план на такой-то проект. Это скорее аналитическая интеллектуальная деятельность, когда ты продумываешь, что будет, когда ты анализируешь ситуацию. Я бы даже сказал, что много времени уходит не на то, чтобы понять, что будет дальше, а на то, чтобы понять, что, собственно, произошло. Наверное, процентов 70 времени надо вести интеллектуальную деятельность и планировать топ-менеджеру, а какую-то часть нужно просто реагировать на обстоятельства.
Как ты сказал, операционку нужно прямо от себя отдалять и заниматься ей как можно меньше.
Отдалять. Это ловушка, быстрый дофамин. Тебе кажется, что ты просто решил проблемку, сделал дело и круто – но это не так.
Просто иногда, по моему личному ощущению, кажется, что если ты не придешь сейчас и здесь всех не спасешь, то все просто обвалится и компания перестанет существовать.
Да, иногда приходишь и спасаешь. Но надо, чтобы это «приходишь и спасаешь» в 30-40% максимум влезало у тебя.
Ты сделал ссылку к своему докладу на South Hub – расскажи, как ты измеряешь эффективность этого мероприятия для себя?
Когда ты СТО, ты всегда наедине со своими мыслями. СТО может быть в крупных компаниях и несколько, но обычно это один человек, который в одного решает проблему, и у тебя нет какого-то сообщества, тебе просто не с кем поделиться. И для этого такие мероприятия очень нужны. У меня есть много чатиков СТО, я сам записывал подкаст с СТО, чтобы занетворкаться и найти много знакомых. Можно на South Hub прийти и обсудить.
И внезапно оказывается, что ты уже не один, что те проблемы, которые у тебя есть, они у всех примерно есть, и кто-то их решил. Какие-то вещи у тебя хорошо сделаны, какие-то вещи тебе надо подсмотреть, научиться, спросить, и все с удовольствием рассказывают. Это одно из свойств нашей среды, и South Hub этому очень способствует. Мы же все понимаем, что в IT-бизнесе российском мы все в какой-то одной лодке находимся. Да, мы конкурируем, но в конечном счете все мы решаем одни и те же проблемы. Если мы будем решать это сообща, общаясь друг с другом, то мы как-то проще, быстрее решим.
А какого-нибудь ментора найти ты не пробовал, чтобы у вас регулярно были разговоры о том, какие у тебя были сложности, как бы ты их решал?
Мне больше пока нравится подход, что я просто общаюсь с другими СТО в таких горизонтальных связях. Они меня что-то спрашивают, я у них что-то спрашиваю, когда нужна экспертиза или baseline. Вот как посчитать процент успешных платежей в биллинге? Нигде не пишут об этом, поэтому это можно узнать. Я свои данные предоставлю, они свои предоставят, мы обсудим, узнаем, какие есть решения, и это получается хорошо. Ментор может помочь решить какую-то менеджерскую проблему.
Это еще иногда полезно с точки зрения моральной поддержки.
Вот это, кстати, интересный момент, потому что я считаю, что есть два вида мотивации. Тебя могут мотивировать какие-то внешние факторы, люди могут говорить, что ты молодец, ты крутой. Ты такой: да, я крутой! А есть внутренняя мотивация: ты сам понимаешь, насколько ты крутой, насколько у тебя все получается и так далее. И на позиции CTO ты обязан просто воспитать в себе внутреннюю мотивацию и самостоятельно понимать, что у тебя хорошо получается, что у тебя нехорошо получается, признавать свои заслуги и заслуги команды и рассказывать им об этом. И, конечно же, честно говорить, где ты продолбался – это тоже нормально. Поэтому с этой точки зрения я не соглашусь – надо это воспитывать в себе.
***
Я могу посоветовать книжку Канемана «Думай медленно, решай быстро». И пару лет назад у него вышла новая книга про точность принятия решений. Это книга про то, насколько много мы на самом деле делаем ошибок в принятии решений, насколько неточно мы прогнозируем, и как с этим бороться. Это очень важно понимать банально везде. Тебе нужно сделать какой-то ассессмент, какой-то performance review в компании, нужно оценивать людей. Если ты проводишь интервью, ты должен как-то давать оценку людям на входе, насколько они подходят, не подходят. И эта книга отлично рассказывает, как мы ошибаемся в точности наших прогнозов.
И последнее – как бы ты описал пятилетнему ребенку, чем ты занимаешься на работе?
Есть очень умные дядьки, они называются айтишники, и надо им помочь, чтобы мы все пришли к результату. Я просто им немножко помогаю, подталкиваю. Так-то они сами бы справились.
Выпуск подкаста «Что‑то на программистском» с Павлом Притчиным смотрите на YouTube‑канале Doubletapp и в VK Video, аудиоверсию слушайте на удобной площадке.
Уже вышли записи подкаста с гуру фронтенда Глебом Михеевым, СТО крупнейшего турецкого маркетплейса Hepsiburada Алексеем Шевенковым, специалистом по Канбан Методу Алексеем Пименовым и другими интересными собеседниками.
Подписывайтесь на канал, смотрите новые выпуски в VK Video.
