Гениальная вещь! Как всегда, разработчики умеют упрощать жизнь. Легко увидеть diff: https://github.com/miripiruni/constitution-of-russia

#найм

Какие софт скиллы мы проверяем на собеседованиях?

Во время подготовки разделили софты на то, какие можем легко вырастить в Додо, а какие нужны на старте.

Мотивация
Первый и важнейший аспект. По мере погружения работы в Додо разработчики все больше понимают возможности в IT, масштаб того, что мы строим. Однако, изначально у кандидата должна быть правильная мотивация. Правильная = долгосрочная. Что долгосрочно нужно разработчику? Правильно – рост скиллов, ответственности, сложности задач, людей вокруг. Это естественная внутренняя мотивация разработчика. Есть и внешние факторы, такие как обязательства перед семьей, например, они могут влиять, но не должны быть движущей силой.

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

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

Обучаемость
Фундаментальный скилл для разработчика. Умение учиться для разработчика важно так же сильно как и скиллы текущие. Когда мы нанимаем разработчика, мы нанимаем не “его текущего”, а “его через пару лет”, того, в кого он может вырасти. Речь не только о технических скиллах, но и скиллах менеджмента, построения команд. А помните, мы ведь берем тех, кто усилит IT команду. В итоге получается умопомрачительная комбинация, когда мы и сейчас берем людей сильнее, и потенциал роста у них огромен, под любые задачи и масштабы бизнеса. 

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

Сложив эти факторы по первым буквам, получается даже немного смешно 🙂

#dodois

Пожалуй, это одна из самых объемных и содержательных статей о части архитектуры Dodo IS. Почему она такая? Что там внутри? Почему мы принимает те архитектурные решения, которые принимаем.

Полезно и интересно разработчикам, кто много работает с бэком.

PS. Подписывайтесь на наш блог на Хабре. Там вообще много технических подробностей есть.

#найм

Один из самых интересных этапов найма – это тестовый день.

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

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

Нам нужен тестовый день, чтобы увидеть кандидата в рабочих условиях, а не в собеседовании. Все-таки прохождение собеседований и работа – два разных навыка.

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

Если мне когда-нибудь кто-нибудь скажет, что тестовый день в IT сложно сделать, я просто отправлю вас к нашим юристам за опытом. В Додо команда юристов начинает так же организовывать тестовые дни для кандидатов! Юристов на тестовый день, разбирать кейсы, обрабатывать входящие вопросы от сотрудников! А до этого команда Digital Design пробовала такую историю. Когда практика, казалось бы, подходящая исключительно для разработки, начинает распространяться по компании, это интересно!

Как и где вы читаете технологические новости? А статьи?

Facebook, Twitter, HackerNews, vc, официальные блоги GitHub и Microsoft Azure. Все это агрегируется в RSS подписках или в соцсетях, но все равно, часть контента полезна, часть нет.

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

Пробник на https://news.99developers.io

Я не писал 2 недели и на то была причина. Раз в 2 месяца я провожу с IT командой Q&A. 15 июля был очередной. Должен был быть раньше, но коронавирус немного спутал планы.

Первые 20-30 минут я рассказываю о глобальных вещах, немного о том что я сам сделал и о нашем движении вперед. Этот Q&A был особенно важен, т.к. в конце 2019ого мы сломали наши процессы и начали перестройку. Он должен был подвести некую черту, итог, показать ребятам, куда мы движемся, показать им что есть план действий. Звучит просто, но сделать это не такая уж тривиальная задача, как может показаться на первый взгляд.

❄️ Q&A Декабрь 2019. Хаос. Все сломано, у ребят ощущение что нет плана, неясно что будет дальше и как будет развиваться Додо IT. Есть только идеи и уверенность в том что мы их докрутим.

⛅️ Q&A Март 2020. Идеи начинают реализовываться. Первые конкретные наметки того, как будет выглядеть вся система.

☀️ Q&A Июль 2020 (перенесен с мая). Этап пройден, все развитие собрано в общую систему, есть план развития и полная уверенность в том что будет завтра!

За полгода мы прошли путь от хаоса и разрухи до понятного процесса на 100+ человек и 18 команд. Процесс, который будет дальше масштабироваться и мы понимаем как он будет выглядеть на 200, на 300 человек. Понимаем, какие задачи будут перед нами стоять, какую роль во всем этом играет распил монолита, куда можно расти разработчикам в менеджмент.

Цель на полгода достигнута!

Вторая часть Q&A это вопросы. Вопросы открыты, их видят все. Вопросы могут быть весьма острые, про зарплаты, систему мотивации, проблемы в разработке, в скорости или в чем-то еще.

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

В середине марта, например, прозвучала фраза “Мы не знаем, переживем ли этот кризис”. Через 5 недель была фраза “Мы видим что кризис есть, но мы нормально себя чувствуем в нем”. Что стояло за этими изменения от “не переживем” до “все впорядке”? Это надо передать ребятам, чтобы они еще больше ощущали себя частью чего-то большего!

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

Q&A для меня – это продукт. Продукт, где я сам отчитаюсь перед ребятами о своей работе, расскажу новости и отвечу на любые, даже самые жесткие вопросы. И судя по отзывам, с третьего раза Q&A у меня начал получаться!

Далее я буду рассказывать подробнее о структуре, как мы ее изменили и как собираемся масштабировать. Буду постепенно выкладывать все детали, что рассказывал на Q&A, нюансы структуры, роста. Теперь статьи будут выходить чаще.

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

На sports.ru вышла отличная статья, рассказывающая о том, как жил клуб, скупавший звездных игроков. Это как если вы соберете команду только из супер-звездных разработчиков. Что будет? Последний абзац этой статьи – как главная мысль всей идеи построения команд.

PS. Я не беру пока в учет истории работы над сверхсложными задачами, где делают прорывы в отрасли (как, например, история первой посадки возвращаемого модуля SpaceX), там без суперзвезд никак и это принципиально иные подходы к работе с гениями.

Задача по развитию и разработке большого продукта требует больших усилий. Необходимо думать о функционале, общаться с пользователями, проверять гипотезы, работать над техническим долгом и улучшать архитектуру продукта, выстраивать процессы, работать индивидуально с людьми и помогать им развиваться. Запихнуть все это в голову одного Product Owner’а (PO) можно лишь в очень маленьком продукте и когда у него есть глубокие технические компетенции.

Для того, чтобы уметь управлять разработкой большого продукта, за него отвечает не один Product Owner, а команда. И такие команды в каждом продукте. Что они из себя представляют, описал описал в статье.

Новости на https://news.99developers.io/ теперь работают полностью автоматически, выгружает все что мне интересно.

Вам бы хотелось собрать ленту под себя?

Новая Tech Company

Мы решили выделить IT команду Додо в отдельную технологическую компанию. Мы перестаем быть командой, которая развивает Dodo IS для бизнеса пиццы, мы становимся компанией, которая развивает Dodo IS для рынка франшиз. 

Нам нужно научиться управлять IT не как командой внутри структуры Додо, а как компанией внутри Dodo Brands. У нас есть клиенты на внутреннем рынке, их уже три (Додо, Дринкит, Донер 42), есть своя система управления, найма и развития людей, работа с приоритетами, стратегия развития Dodo IS. В технологической платформе мы имеем потенциал даже создавать свои продукты. Все это позволит сделать наши процессы и работу эффективнее и прозрачнее и поможет нам быстрее развивать бизнес в рамках Dodo Brands.

Я когда думал обо всем этом, оказалось, от меня давно ждут управления IT как компанией, нежели командой. За все время в Додо я, хоть и фокусировался на технических вещах, но все же было много других направлений, порой слишком много. Теперь будет проще, у нас появится CTO, фокус которого будет строго на технике. Даже когда описывали роль, больше фокусировались на том что ему НЕ придется делать 🙂

А название я пока не напишу, а то вдруг заспойлерю.

Слушал я тут недавно подкаст один о хантинге и рекрутинге в IT.

Там была мысль, которую считали нормой, а меня она просто бросает в дрожь: "Cкрывай что ты ищешь работу, ведь работодатель может спалить."

Это что, серьезно? Это индустрия такая и есть лишь некоторые компании, которые умеют строить культуру на доверии? Как это изменить?

Описал мысли в статье.

Лучший разбор любой методики или подхода - это разбор на конкретных кейсах. Статья о DDD и реальности.

Domain-Driven Design (DDD) или предметно-ориентированное проектирование — набор правил, которые помогают проектировать ПО со сложной бизнес-логикой быстрее, чем без него. Но в самом DDD много абстракций и понятий. Всё ещё усложняется тем, что статей с разбором принципов и понятий DDD много (не считая трех разноцветных книг), а вот реальных примеров — не очень. Из-за этого на него страшно смотреть, не то, что внедрять. Чтобы убрать немного сомнений, мы написали статью о том, как с помощью DDD мы решили у себя большую проблему с «бумажными» ревизиями. Будем рады, если материал поможет, когда задумаетесь о DDD или даже захотите применить в своём проекте.

21 октября 2020 года.

Создана компания Dodo Engineering! 🥳

Начинается новая глава в нашей истории. Скоро расскажу об изменении ролей и о новом CTO.

PS. Число 21, видимо, с нами навсегда 🙂

Новый CTO в Dodo Engineering

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

В Додо развиваться может каждый. В 2015м в Додо пришел Паша Притчин, пришел разработчиком. Был в Core-команде, занимался сайтом, системой аутентификации, переводил куски Dodo IS на .NET Core, собирал команду один раз, второй раз, третий раз и каждый раз умудрялся делать свои команды все сильнее и сильнее! Затем перешел в команду Платформы и в 2019м возглавил ее, усилив развитие SRE-практик и стабильности Dodo IS.

В декабре 2020 он становится новым CTO в Dodo Engineering. За все это время я убедился в главном – Паша один из самых надежных людей, которых я встречал.

PS. Паша, я знаю, ты это читаешь. С тебя статья о том как пройти путь от разработчика до CTO 🙂

Отвечаем на разные вопросы о разработке в Додо на сессии AMA (Ask Me Anything) а группе в Facebook.

Про QA, конские релизы, монолит, процессы и много чего еще.

Присоединяйтесь и задавайте вопросы 🙂

Инсайт ценою в миллион

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

Главной целью 2020ого было прийти к такой понятной и простой (относительно) структуре, когда развиваются и продукт, и команды. Мы пришли к понятной матричной структуре:
- продуктовые вертикали. Они ориентированны на бизнес, выручку, стабильность, P&L пиццерий. Это фича-тимы, где с необходимыми компетенции для развития продукта.
- горизонтальные функции. Их задача которых – стандартизация подходов и качество этих самых функций, т.е. они ориентированы на конкретную экспертизу.

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

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

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

Если ретроспективно смотреть на все остальные горизонтальные функции что у нас есть (дизайн, работа с данными, архитектура, SRE, mobile), все они подкреплялись небольшими командами, которые так же были фича-тимами, имели у себя компетенции для развития функции. Дизайнеры работали вместе с верстальщиками и фронтенд разработчиками, Mobile работают с мобильными разработчиками и мобильными QA, чтобы запустить систему тестирования. 

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

И увы, человека и денег уже не вернуть. Что ж, научился, разобрался, работаем дальше!

Первый рабочий день прошёл необычно. Мой ноут с разбитым экраном, а новый доедет завтра, поэтому день провёл чисто с телефоном и планшетом. Интересный опыт.

Одно могу сказать точно. Я этот опыт буду повторять и не раз. https://twitter.com/alex4zero/status/1348749770727239682

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

- Автономия и принятие решений
- Problem solver -vs- Resource utilization
- Прозрачность во всем
- Взаимодействие с бизнесом
- Прямые коммуникации, минуя менеджеров
- Разработчики для разработчиков
- Идеи и их реализация

И вот все это в совокупности дает рост бизнеса, причем иногда там, где вы даже не предполагали что можно расти.

Почитайте статью, она очень любопытна.

GDPR. Истории.

Эта статья написана на основе данных, которые собрала наша команда юристов, за что им безмерное уважение!

General Data Protection Regulation, GDPR (Общий Регламент защиты персональных данных Европейского союза) действует с мая 2018 г. и применяется ко всем компаниям, обрабатывающим персональные данные резидентов и граждан ЕС, независимо от местонахождения такой компании.

Административный штраф за несоблюдение GDPR установлен в статье 83 и составляет до 20 тыс евро или до 4% от общего годового мирового оборота за предыдущий финансовый год. Выбирается та сумма, которая окажется больше.

Еще раз – БОЛЬШЕ, а не меньше.

В 2019м Google  получил штраф 50 млн евро. Нарушение требований прозрачности в отношении получения согласия от клиента на получение рекламы.

ЕЩЕ РАЗ! 50 МИЛЛИОНОВ ЕВРО за нарушение прозрачности получения согласия на рекламу. Они не теряли данные, их не украли, просто был не совсем очевидный UX. Если вам лень читать по ссылке историю про Google, вот небольшая цитата:

> When an account is created, the user can admittedly modify some options associated to the account by clicking on the button « More options », accessible above the button « Create Account ». It is notably possible to configure the display of personalized ads.
That does not mean that the GDPR is respected. Indeed, the user not only has to click on the button "More options" to access the configuration, but the display of the ads personalization is moreover pre-ticked

Будьте аккуратны с галочками. Они могут стоить вам больших денег.

Еще больше историй.

Dodo Open Source 2020 → 2021

В прошлом году мы начали проект Dodo Open Source, чтобы помогать разработчикам выводить проекты в Open Source, и рассказывать о наших OSS-проекты во внешний мир (ну и внутри тоже).

Результаты:

— Опубликовали 9 репозиториев (без учета GitHub Actions) на GitHub.
— В работе над репозиториями поучаствовало 22 человека.
— Собрали 100 звездочек в сумме по всем проектам.
— К нам пришло 2 внешних контрибьютера: один писал реальный код и присылал PR'ы, другой пришел в issue.
— Провели Dodo Hacktoberfest.

Результаты довольно скромные, но важнее, что работа над Open Source положительно сказывается на культуре работы с кодом и другими проектами. Однако, большинство наших проектов специфичные, да и продвигать OSS-проекты оказалось сложнее, чем казалось. Это из минусов:)

Сейчас работаем над планами Dodo Open Source 2021, и хотели немного «подытожить» результаты за 2020. Большая благодарность всем, кто помогал и участвовал в OSS-проектах, и Мише Кумачеву, как овнеру:) Оставайтесь с нами!