Для начала вообще о том кто я такой и какого фига меня можно слушать.
Я разработчик. И менеджер. Последние 4 года больше менеджер, чем разработчик.
5 лет я работал в нижегородском Intel, в команде, которая еще в 2008м году умела адаптировать процессы, работала по TDD и вообще была топовой. В 2013м так сложилась история что большое количество людей сокращали и наше подразделение в том числе, проекты уходили на аутсорс. Было стремно терять людей и я подбил еще 2х человек сделать свою компанию.
Так в 2013м появилась компания SmartStepGroup. Прошли путь от 3х человек и “не знаю как зарабатывать, щас разберемся” до 11 человек и весьма емкого бизнеса, который приносил хороший доход и умел масштабироваться без лишнего найма.
В 2017м году мы объединились с Додо. С тех пор выросли с 30 человек в разработке до 99 (название канала отсюда, хочу до найма сотого успеть), с падений при 50 заказах в минуту до спокойной жизни на 350. Не, не думайте что все идеально, проблем полно, мы их решаем. Распиливаем монолит, создаем изолированные продукты и сервисы и строим огромную экосистему Dodo IS.
В компании есть люди, которые уверены что мне надо больше мыслей выгружать в public. Окей, начнем.
О чем я буду писать?
- Просто делиться своими мыслями о том, что происходит в IT команде Додо, даже если мысли еще не оформлены. Иногда это будут сырые идеи, не принимайте их сразу за план действий.
* Про процессы и менеджмент в IT, про разные роли и ожидания от них. Я не лучший менеджер на свете. Но я знаю где таких найти и как их вырастить.
* Про культуру разработки.
* Про найм и собеседования.
* Про удачные и неудачные эксперименты.
- В целом буду писать про все что мне интересно в IT и бизнесе.
Мысли не будут ограничиваться Додо.
Я разработчик. И менеджер. Последние 4 года больше менеджер, чем разработчик.
5 лет я работал в нижегородском Intel, в команде, которая еще в 2008м году умела адаптировать процессы, работала по TDD и вообще была топовой. В 2013м так сложилась история что большое количество людей сокращали и наше подразделение в том числе, проекты уходили на аутсорс. Было стремно терять людей и я подбил еще 2х человек сделать свою компанию.
Так в 2013м появилась компания SmartStepGroup. Прошли путь от 3х человек и “не знаю как зарабатывать, щас разберемся” до 11 человек и весьма емкого бизнеса, который приносил хороший доход и умел масштабироваться без лишнего найма.
В 2017м году мы объединились с Додо. С тех пор выросли с 30 человек в разработке до 99 (название канала отсюда, хочу до найма сотого успеть), с падений при 50 заказах в минуту до спокойной жизни на 350. Не, не думайте что все идеально, проблем полно, мы их решаем. Распиливаем монолит, создаем изолированные продукты и сервисы и строим огромную экосистему Dodo IS.
В компании есть люди, которые уверены что мне надо больше мыслей выгружать в public. Окей, начнем.
О чем я буду писать?
- Просто делиться своими мыслями о том, что происходит в IT команде Додо, даже если мысли еще не оформлены. Иногда это будут сырые идеи, не принимайте их сразу за план действий.
* Про процессы и менеджмент в IT, про разные роли и ожидания от них. Я не лучший менеджер на свете. Но я знаю где таких найти и как их вырастить.
* Про культуру разработки.
* Про найм и собеседования.
* Про удачные и неудачные эксперименты.
- В целом буду писать про все что мне интересно в IT и бизнесе.
Мысли не будут ограничиваться Додо.
vc.ru
«Додо пицца» поглотила нижегородскую команду разработчиков Smart Step Group — Офтоп на vc.ru
Компания «Додо пицца» присоединила к себе нижегородскую команду разработчиков Smart Step Group, созданную выходцами из Intel. Об этом на своей странице в Facebook сообщил основатель и глава сети пиццерий Фёдор Овчинников.
👍1
Microsoft расстается с журналистами и заменяет их на AI.
Пожалуй, это очень интересная новость как для индустрии в целом. Работа с новостями выходит на иной уровень. Работа с новостями, анализ ситуации, логические выводы. Все это теперь будет делать машина.
То что может делать машина – должна делать машина.
Пожалуй, это очень интересная новость как для индустрии в целом. Работа с новостями выходит на иной уровень. Работа с новостями, анализ ситуации, логические выводы. Все это теперь будет делать машина.
То что может делать машина – должна делать машина.
TipRanks Financial
Microsoft Informs Journalists Their Services Are No Longer Needed Due to AI - TipRanks.com
Microsoft (MSFT) is terminating dozens journalists and editorial workers at its Microsoft News and MSN organizations. Microsoft instead will rely on artificial inte...
4. 14. 40. 140.
Это не IP адрес. Это не случайный набор чисел. Это не координаты долготы и широты.
Это логика роста лидеров в IT, которую я вижу по своему опыту, то количество людей, с которыми лидер работает. На каждом новом этапе лидер осознает что надо действовать иначе, принципиально иначе, а не только продолжать делать то что и раньше.
И осознание этого приходит только по достижению этапа. Из этой идеи можно строить модель роста лидерства в работе с людьми.
Читать на medium
Это не IP адрес. Это не случайный набор чисел. Это не координаты долготы и широты.
Это логика роста лидеров в IT, которую я вижу по своему опыту, то количество людей, с которыми лидер работает. На каждом новом этапе лидер осознает что надо действовать иначе, принципиально иначе, а не только продолжать делать то что и раньше.
И осознание этого приходит только по достижению этапа. Из этой идеи можно строить модель роста лидерства в работе с людьми.
Читать на medium
Medium
4. 14. 40. 140.
Это не IP адрес. Это не случайный набор чисел. Это не координаты долготы и широты.Это логика роста лидеров в IT, которую я вижу по своему…
Очень интересный тред на HackerNews про то, насколько плохим должен быть код, когда ты стартап.
Кажется, тут есть дефолтное мнение, мол, код не так важен, важна его функция, чтобы быстро расти, завоевать долю рынка, потом уже исправлять. Пример ответа парня из Uber очень круто это как раз показывает.
Но для меня один из самых любопытных вопросов: "А есть ли примеры стартапов, которые умерли (или были к этому очень близки) из-за плохого кода?"
Из-за багов – да. Из-за падений – да. Из-за плохой архитектуры и невозможности масштабироваться – да. Из-за того что ты нанял неквалифицированных разработчиков, которые проели весь бюджет стартапа (а на ранних этапах инвестиции ведь небольшие) – тоже да. Из-за этого не зарабатывает, теряет деньги и может прожесь все стартовые инвестиции. И опять мы приходим к мысли о том что понятие качественного кода – это код, который зарабатывает. Краткосрочные цели могут как перевесить долгосрочные, так и наоборот, ты можешь пожертвовать краткосрочным быстрым выходом ради более правильной архитектуры.
И вот в этом, по-моему мнению, кроется ключевой скилл Senior разработчика – понять, когда надо действовать ради краткосрочных целей, а когда вкладываться вдолгую. Все как на фондовом рынке, честное слово :).
Кажется, тут есть дефолтное мнение, мол, код не так важен, важна его функция, чтобы быстро расти, завоевать долю рынка, потом уже исправлять. Пример ответа парня из Uber очень круто это как раз показывает.
Но для меня один из самых любопытных вопросов: "А есть ли примеры стартапов, которые умерли (или были к этому очень близки) из-за плохого кода?"
Из-за багов – да. Из-за падений – да. Из-за плохой архитектуры и невозможности масштабироваться – да. Из-за того что ты нанял неквалифицированных разработчиков, которые проели весь бюджет стартапа (а на ранних этапах инвестиции ведь небольшие) – тоже да. Из-за этого не зарабатывает, теряет деньги и может прожесь все стартовые инвестиции. И опять мы приходим к мысли о том что понятие качественного кода – это код, который зарабатывает. Краткосрочные цели могут как перевесить долгосрочные, так и наоборот, ты можешь пожертвовать краткосрочным быстрым выходом ради более правильной архитектуры.
И вот в этом, по-моему мнению, кроется ключевой скилл Senior разработчика – понять, когда надо действовать ради краткосрочных целей, а когда вкладываться вдолгую. Все как на фондовом рынке, честное слово :).
99developers via @like
В конце мая мы решили вернуться к найму в IT.
Процесс собеседования:
1. Короткий технический скрининг.
2. Собеседование с HR.
3. Собеседование с командой (техническое + PO).
4. Финальное с CTO.
Начиная с июня, финальные собеседования буду проводить только в паре. Цель – сделать так чтобы каждый разработчик, менеджер, кто нанимает людей, могли лучше понимать, подойдет ли в команду кандидат и чтобы финальный этап стал не нужен.
В 2017м году, когда в Додо было всего 30 разработчиков, мы приняли стратегически важное решение – нанимать только тех, кто сильнее нас, особенно в техническом плане.
Это решение позволило укрепить команду и решить немало техническом проблем с Dodo IS, сделать ее стабильнее. Сейчас, когда нас уже 100 человек, подход остается тем же. На собеседованиях мы отвечаем на вопрос: "Усилит нас кандидат или нет?". Ответ на этот вопрос нужен на каждом этапе: на HR собеседованиях, технических, на финальном. Звучит просто, да?
Дать точный ответ на это, конечно, невозможно, но попытаться стоит. Кандидаты разделятся на: “точно нет“, “возможно” и “точно да“. Вот те кто “точно нет“, им сразу отказываем, это уже пол-дела. Остальных смотрим дальше, уточняем, в каких скиллах, подходах, он может нас усилить.
Как понять?
Тут важно не только копание технических навыков. Важно понимать задачи, которые решал человек.
Примерно 50% времени собеседования проходит в обсуждении задач кандидата. Он делал SaaS продукты со сложной доменной логикой? Работал над производительностью приложений? Может, много времени работал с интерфейсами мобильных приложений?
Решал ли он нетехнические задачи? Налаживал ли кандидат коммуникации с продактами, дизайнерами, командой operations, другими разработчиками? Важно копать глубоко и не ограничиваться ответами как все было устроено. Где были проблемы в коммуникациях, как кандидатх их менял, как находил подход к людям.
Два этих сочетания рассказывают об уровне кандидата и в сравнении с командой Додо дают ответ на вопрос – усилит человек нашу команду или нет? Обладает ли он такими навыками, которых у нас нет или их немного? Если да, стоит делать офер.
В качестве заключения, одна фраза, сказанная очень сильным разработчиком, который работает в Додо уже давно и за последние годы сильно вырос: "Саш, ты понимаешь, я вот еще в 2015м был одним из самых сильных разработчиков в Додо. А сейчас, глядя на наших ребят, понимаю что я обычный, средний разработчик. Это круто!".
Рассказать подробнее о собеседованиях?
Процесс собеседования:
1. Короткий технический скрининг.
2. Собеседование с HR.
3. Собеседование с командой (техническое + PO).
4. Финальное с CTO.
Начиная с июня, финальные собеседования буду проводить только в паре. Цель – сделать так чтобы каждый разработчик, менеджер, кто нанимает людей, могли лучше понимать, подойдет ли в команду кандидат и чтобы финальный этап стал не нужен.
В 2017м году, когда в Додо было всего 30 разработчиков, мы приняли стратегически важное решение – нанимать только тех, кто сильнее нас, особенно в техническом плане.
Это решение позволило укрепить команду и решить немало техническом проблем с Dodo IS, сделать ее стабильнее. Сейчас, когда нас уже 100 человек, подход остается тем же. На собеседованиях мы отвечаем на вопрос: "Усилит нас кандидат или нет?". Ответ на этот вопрос нужен на каждом этапе: на HR собеседованиях, технических, на финальном. Звучит просто, да?
Дать точный ответ на это, конечно, невозможно, но попытаться стоит. Кандидаты разделятся на: “точно нет“, “возможно” и “точно да“. Вот те кто “точно нет“, им сразу отказываем, это уже пол-дела. Остальных смотрим дальше, уточняем, в каких скиллах, подходах, он может нас усилить.
Как понять?
Тут важно не только копание технических навыков. Важно понимать задачи, которые решал человек.
Примерно 50% времени собеседования проходит в обсуждении задач кандидата. Он делал SaaS продукты со сложной доменной логикой? Работал над производительностью приложений? Может, много времени работал с интерфейсами мобильных приложений?
Решал ли он нетехнические задачи? Налаживал ли кандидат коммуникации с продактами, дизайнерами, командой operations, другими разработчиками? Важно копать глубоко и не ограничиваться ответами как все было устроено. Где были проблемы в коммуникациях, как кандидатх их менял, как находил подход к людям.
Два этих сочетания рассказывают об уровне кандидата и в сравнении с командой Додо дают ответ на вопрос – усилит человек нашу команду или нет? Обладает ли он такими навыками, которых у нас нет или их немного? Если да, стоит делать офер.
В качестве заключения, одна фраза, сказанная очень сильным разработчиком, который работает в Додо уже давно и за последние годы сильно вырос: "Саш, ты понимаешь, я вот еще в 2015м был одним из самых сильных разработчиков в Додо. А сейчас, глядя на наших ребят, понимаю что я обычный, средний разработчик. Это круто!".
Рассказать подробнее о собеседованиях?
Гениальная вещь! Как всегда, разработчики умеют упрощать жизнь. Легко увидеть diff: https://github.com/miripiruni/constitution-of-russia
GitHub
GitHub - miripiruni/constitution-of-russia: Конституция Российской Федерации
Конституция Российской Федерации. Contribute to miripiruni/constitution-of-russia development by creating an account on GitHub.
#найм
Какие софт скиллы мы проверяем на собеседованиях?
Во время подготовки разделили софты на то, какие можем легко вырастить в Додо, а какие нужны на старте.
Мотивация
Первый и важнейший аспект. По мере погружения работы в Додо разработчики все больше понимают возможности в IT, масштаб того, что мы строим. Однако, изначально у кандидата должна быть правильная мотивация. Правильная = долгосрочная. Что долгосрочно нужно разработчику? Правильно – рост скиллов, ответственности, сложности задач, людей вокруг. Это естественная внутренняя мотивация разработчика. Есть и внешние факторы, такие как обязательства перед семьей, например, они могут влиять, но не должны быть движущей силой.
Упертость (или упоротость, в хорошем смысле)
Умение копать, умение не отступать, когда не получается, умение искать решение лучше нынешнего. Еще одно качество, которое сильно отличает людей, когда оно есть и когда его нет. Узнать о наличии этого качество легко – по кейсам. Можно не только рабочим.
Дисциплина
Дисциплина либо есть, либо ее нет. Дисциплина – это не про вовремя приходить на встречи, она про соблюдение обязательств, коммитов своих и команды, компании. Это сложно описать или выразить в конкретных факторах, но легко сравнить двух людей и четко осознать, что один из них более дисциплинирован, чем другой. Вот дальше распишите что для вас это значит и поймете как определить это на собеседовании.
Обучаемость
Фундаментальный скилл для разработчика. Умение учиться для разработчика важно так же сильно как и скиллы текущие. Когда мы нанимаем разработчика, мы нанимаем не “его текущего”, а “его через пару лет”, того, в кого он может вырасти. Речь не только о технических скиллах, но и скиллах менеджмента, построения команд. А помните, мы ведь берем тех, кто усилит IT команду. В итоге получается умопомрачительная комбинация, когда мы и сейчас берем людей сильнее, и потенциал роста у них огромен, под любые задачи и масштабы бизнеса.
Командная работа
Команда – это нечто большее, чем группа людей. Командная химия, когда люди дополняют друг друга, позволяет добиваться лучших результатов. Спорт это легко доказывает, когда команда индивидуально самых сильных футболистов проигрывает команде, где игроки бьются друг за друга и лучше подходят друг другу.
Сложив эти факторы по первым буквам, получается даже немного смешно 🙂
Какие софт скиллы мы проверяем на собеседованиях?
Во время подготовки разделили софты на то, какие можем легко вырастить в Додо, а какие нужны на старте.
Мотивация
Первый и важнейший аспект. По мере погружения работы в Додо разработчики все больше понимают возможности в IT, масштаб того, что мы строим. Однако, изначально у кандидата должна быть правильная мотивация. Правильная = долгосрочная. Что долгосрочно нужно разработчику? Правильно – рост скиллов, ответственности, сложности задач, людей вокруг. Это естественная внутренняя мотивация разработчика. Есть и внешние факторы, такие как обязательства перед семьей, например, они могут влиять, но не должны быть движущей силой.
Упертость (или упоротость, в хорошем смысле)
Умение копать, умение не отступать, когда не получается, умение искать решение лучше нынешнего. Еще одно качество, которое сильно отличает людей, когда оно есть и когда его нет. Узнать о наличии этого качество легко – по кейсам. Можно не только рабочим.
Дисциплина
Дисциплина либо есть, либо ее нет. Дисциплина – это не про вовремя приходить на встречи, она про соблюдение обязательств, коммитов своих и команды, компании. Это сложно описать или выразить в конкретных факторах, но легко сравнить двух людей и четко осознать, что один из них более дисциплинирован, чем другой. Вот дальше распишите что для вас это значит и поймете как определить это на собеседовании.
Обучаемость
Фундаментальный скилл для разработчика. Умение учиться для разработчика важно так же сильно как и скиллы текущие. Когда мы нанимаем разработчика, мы нанимаем не “его текущего”, а “его через пару лет”, того, в кого он может вырасти. Речь не только о технических скиллах, но и скиллах менеджмента, построения команд. А помните, мы ведь берем тех, кто усилит IT команду. В итоге получается умопомрачительная комбинация, когда мы и сейчас берем людей сильнее, и потенциал роста у них огромен, под любые задачи и масштабы бизнеса.
Командная работа
Команда – это нечто большее, чем группа людей. Командная химия, когда люди дополняют друг друга, позволяет добиваться лучших результатов. Спорт это легко доказывает, когда команда индивидуально самых сильных футболистов проигрывает команде, где игроки бьются друг за друга и лучше подходят друг другу.
Сложив эти факторы по первым буквам, получается даже немного смешно 🙂
#dodois
Пожалуй, это одна из самых объемных и содержательных статей о части архитектуры Dodo IS. Почему она такая? Что там внутри? Почему мы принимает те архитектурные решения, которые принимаем.
Полезно и интересно разработчикам, кто много работает с бэком.
PS. Подписывайтесь на наш блог на Хабре. Там вообще много технических подробностей есть.
Пожалуй, это одна из самых объемных и содержательных статей о части архитектуры Dodo IS. Почему она такая? Что там внутри? Почему мы принимает те архитектурные решения, которые принимаем.
Полезно и интересно разработчикам, кто много работает с бэком.
PS. Подписывайтесь на наш блог на Хабре. Там вообще много технических подробностей есть.
Хабр
История архитектуры Dodo IS: путь бэкофиса
Хабр меняет мир. Больше года мы ведём свой блог. Где-то полгода назад нам прилетел вполне логичный фидбэк от хабровчан: «Додо, вот вы везде говорите, что у вас своя система. А что это за система? И...
99developers via @like
#найм
Один из самых интересных этапов найма – это тестовый день.
Тестовый день — это такой день, когда человек приходит в офис и работает в команде один полный день. Целый день в паре с одним из разработчиков нанимающей команды, работа идет над реальными задачами и то что ребята сделают может в этот же день попасть на продакшн. Никаких розовых единорогов, иллюзий, кандидат увидит код, с которым предстоит работать годы, если примите офер.
Тестовый день нужен и нам, и кандидатам.
Кандидатам тестовый день нужен для того чтобы выбор о смене рабоы был более осознанным, чтобы они увидели реальные условия работы, будущих коллег, код. Однажды человек отказался от нашего офера после тестового дня, сказав, спасибо за то что это произошло до того как он сменил работу.
Нам нужен тестовый день, чтобы увидеть кандидата в рабочих условиях, а не в собеседовании. Все-таки прохождение собеседований и работа – два разных навыка.
Эту практику мы придумали и реализовали еще в 2016м, до того как наша нижегородская команда присоединилась к Додо. Я помню в начале 2017ого выступал даже с небольшим докладом об этой практике на конференции. После выступления подходили люди, говорили что это очень круто и очень сложно реализовать, что у них там, сям ограничения.
Если мне когда-нибудь кто-нибудь скажет, что тестовый день в IT сложно сделать, я просто отправлю вас к нашим юристам за опытом. В Додо команда юристов начинает так же организовывать тестовые дни для кандидатов! Юристов на тестовый день, разбирать кейсы, обрабатывать входящие вопросы от сотрудников! А до этого команда Digital Design пробовала такую историю. Когда практика, казалось бы, подходящая исключительно для разработки, начинает распространяться по компании, это интересно!
Один из самых интересных этапов найма – это тестовый день.
Тестовый день — это такой день, когда человек приходит в офис и работает в команде один полный день. Целый день в паре с одним из разработчиков нанимающей команды, работа идет над реальными задачами и то что ребята сделают может в этот же день попасть на продакшн. Никаких розовых единорогов, иллюзий, кандидат увидит код, с которым предстоит работать годы, если примите офер.
Тестовый день нужен и нам, и кандидатам.
Кандидатам тестовый день нужен для того чтобы выбор о смене рабоы был более осознанным, чтобы они увидели реальные условия работы, будущих коллег, код. Однажды человек отказался от нашего офера после тестового дня, сказав, спасибо за то что это произошло до того как он сменил работу.
Нам нужен тестовый день, чтобы увидеть кандидата в рабочих условиях, а не в собеседовании. Все-таки прохождение собеседований и работа – два разных навыка.
Эту практику мы придумали и реализовали еще в 2016м, до того как наша нижегородская команда присоединилась к Додо. Я помню в начале 2017ого выступал даже с небольшим докладом об этой практике на конференции. После выступления подходили люди, говорили что это очень круто и очень сложно реализовать, что у них там, сям ограничения.
Если мне когда-нибудь кто-нибудь скажет, что тестовый день в IT сложно сделать, я просто отправлю вас к нашим юристам за опытом. В Додо команда юристов начинает так же организовывать тестовые дни для кандидатов! Юристов на тестовый день, разбирать кейсы, обрабатывать входящие вопросы от сотрудников! А до этого команда Digital Design пробовала такую историю. Когда практика, казалось бы, подходящая исключительно для разработки, начинает распространяться по компании, это интересно!
Хабр
Наш первый обед вместе: почему и как мы проводим тестовый день
Привет, Хабр! Пару месяцев назад мои коллеги рассказывали про расширение команды в 5 раз: от 50 тогда до 250 разработчиков к концу 2020 года. Как вы могли догада...
Как и где вы читаете технологические новости? А статьи?
Facebook, Twitter, HackerNews, vc, официальные блоги GitHub и Microsoft Azure. Все это агрегируется в RSS подписках или в соцсетях, но все равно, часть контента полезна, часть нет.
Я начал собирать для себя небольшой проект, куда попадают только те статьи и темы, которые мне интересны. Про стартапы, менеджмент, новые технологии. Пока он полу-ручной, полу-автоматический. Со временем сделаю его полностью автоматическим и если будет интересно, открою всем, чтобы каждый разработчик мог собрать ленту новостей под себя.
Пробник на https://news.99developers.io
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, нюансы структуры, роста. Теперь статьи будут выходить чаще.
Первые 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), там без суперзвезд никак и это принципиально иные подходы к работе с гениями.
На sports.ru вышла отличная статья, рассказывающая о том, как жил клуб, скупавший звездных игроков. Это как если вы соберете команду только из супер-звездных разработчиков. Что будет? Последний абзац этой статьи – как главная мысль всей идеи построения команд.
PS. Я не беру пока в учет истории работы над сверхсложными задачами, где делают прорывы в отрасли (как, например, история первой посадки возвращаемого модуля SpaceX), там без суперзвезд никак и это принципиально иные подходы к работе с гениями.
Sports.ru
Зависть Рауля к Бекхэму и Роналдо, вражда испанцев и легов, тусы, слив тренеров и много-много алко. Так пали «галактикос»
Роналдо, Роберто Карлос и другие суперзвезды уничтожили великую идею.
👎1
Задача по развитию и разработке большого продукта требует больших усилий. Необходимо думать о функционале, общаться с пользователями, проверять гипотезы, работать над техническим долгом и улучшать архитектуру продукта, выстраивать процессы, работать индивидуально с людьми и помогать им развиваться. Запихнуть все это в голову одного Product Owner’а (PO) можно лишь в очень маленьком продукте и когда у него есть глубокие технические компетенции.
Для того, чтобы уметь управлять разработкой большого продукта, за него отвечает не один Product Owner, а команда. И такие команды в каждом продукте. Что они из себя представляют, описал описал в статье.
Для того, чтобы уметь управлять разработкой большого продукта, за него отвечает не один Product Owner, а команда. И такие команды в каждом продукте. Что они из себя представляют, описал описал в статье.
Medium
Product Leadership Team как основа роста
Задача по развитию и разработке большого продукта требует больших усилий. Необходимо думать о функционале, общаться с пользователями…
99developers via @like
Новости на https://news.99developers.io/ теперь работают полностью автоматически, выгружает все что мне интересно.
Вам бы хотелось собрать ленту под себя?
Вам бы хотелось собрать ленту под себя?
Новая Tech Company
Мы решили выделить IT команду Додо в отдельную технологическую компанию. Мы перестаем быть командой, которая развивает Dodo IS для бизнеса пиццы, мы становимся компанией, которая развивает Dodo IS для рынка франшиз.
Нам нужно научиться управлять IT не как командой внутри структуры Додо, а как компанией внутри Dodo Brands. У нас есть клиенты на внутреннем рынке, их уже три (Додо, Дринкит, Донер 42), есть своя система управления, найма и развития людей, работа с приоритетами, стратегия развития Dodo IS. В технологической платформе мы имеем потенциал даже создавать свои продукты. Все это позволит сделать наши процессы и работу эффективнее и прозрачнее и поможет нам быстрее развивать бизнес в рамках Dodo Brands.
Я когда думал обо всем этом, оказалось, от меня давно ждут управления IT как компанией, нежели командой. За все время в Додо я, хоть и фокусировался на технических вещах, но все же было много других направлений, порой слишком много. Теперь будет проще, у нас появится CTO, фокус которого будет строго на технике. Даже когда описывали роль, больше фокусировались на том что ему НЕ придется делать 🙂
А название я пока не напишу, а то вдруг заспойлерю.
Мы решили выделить IT команду Додо в отдельную технологическую компанию. Мы перестаем быть командой, которая развивает Dodo IS для бизнеса пиццы, мы становимся компанией, которая развивает Dodo IS для рынка франшиз.
Нам нужно научиться управлять IT не как командой внутри структуры Додо, а как компанией внутри Dodo Brands. У нас есть клиенты на внутреннем рынке, их уже три (Додо, Дринкит, Донер 42), есть своя система управления, найма и развития людей, работа с приоритетами, стратегия развития Dodo IS. В технологической платформе мы имеем потенциал даже создавать свои продукты. Все это позволит сделать наши процессы и работу эффективнее и прозрачнее и поможет нам быстрее развивать бизнес в рамках Dodo Brands.
Я когда думал обо всем этом, оказалось, от меня давно ждут управления IT как компанией, нежели командой. За все время в Додо я, хоть и фокусировался на технических вещах, но все же было много других направлений, порой слишком много. Теперь будет проще, у нас появится CTO, фокус которого будет строго на технике. Даже когда описывали роль, больше фокусировались на том что ему НЕ придется делать 🙂
А название я пока не напишу, а то вдруг заспойлерю.
Слушал я тут недавно подкаст один о хантинге и рекрутинге в IT.
Там была мысль, которую считали нормой, а меня она просто бросает в дрожь: "Cкрывай что ты ищешь работу, ведь работодатель может спалить."
Это что, серьезно? Это индустрия такая и есть лишь некоторые компании, которые умеют строить культуру на доверии? Как это изменить?
Описал мысли в статье.
Там была мысль, которую считали нормой, а меня она просто бросает в дрожь: "Cкрывай что ты ищешь работу, ведь работодатель может спалить."
Это что, серьезно? Это индустрия такая и есть лишь некоторые компании, которые умеют строить культуру на доверии? Как это изменить?
Описал мысли в статье.
😁1
Лучший разбор любой методики или подхода - это разбор на конкретных кейсах. Статья о DDD и реальности.
Forwarded from Dodo Engineering
Domain-Driven Design (DDD) или предметно-ориентированное проектирование — набор правил, которые помогают проектировать ПО со сложной бизнес-логикой быстрее, чем без него. Но в самом DDD много абстракций и понятий. Всё ещё усложняется тем, что статей с разбором принципов и понятий DDD много (не считая трех разноцветных книг), а вот реальных примеров — не очень. Из-за этого на него страшно смотреть, не то, что внедрять. Чтобы убрать немного сомнений, мы написали статью о том, как с помощью DDD мы решили у себя большую проблему с «бумажными» ревизиями. Будем рады, если материал поможет, когда задумаетесь о DDD или даже захотите применить в своём проекте.
Хабр
Как DDD помог нам построить новые ревизии в пиццериях
В пиццериях важно выстраивать систему учёта и управления запасами. Система нужна, чтобы не терять продукты, не проводить лишние списания и правильно прогнозирова...
21 октября 2020 года.
Создана компания Dodo Engineering! 🥳
Начинается новая глава в нашей истории. Скоро расскажу об изменении ролей и о новом CTO.
PS. Число 21, видимо, с нами навсегда 🙂
Создана компания 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 🙂
Вообще когда речь заходит о лидерских позициях, особенно в IT, выбор между внешним человеком и ростом кого-то внутри может быть не так прост. Привести человека извне – ему нужно завоевывать авторитет, завоевывать доверие разработчиков, доказать что он может быть для них лидером. Вырастить кого-то изнутри – это, порой, долгая история, на годы, да и осознание изменений масштаба не приходит мгновенно. Об этом чем писал, кстати, ранее в статье.
В Додо развиваться может каждый. В 2015м в Додо пришел Паша Притчин, пришел разработчиком. Был в Core-команде, занимался сайтом, системой аутентификации, переводил куски Dodo IS на .NET Core, собирал команду один раз, второй раз, третий раз и каждый раз умудрялся делать свои команды все сильнее и сильнее! Затем перешел в команду Платформы и в 2019м возглавил ее, усилив развитие SRE-практик и стабильности Dodo IS.
В декабре 2020 он становится новым CTO в Dodo Engineering. За все это время я убедился в главном – Паша один из самых надежных людей, которых я встречал.
PS. Паша, я знаю, ты это читаешь. С тебя статья о том как пройти путь от разработчика до CTO 🙂