О чем говорят СТО продуктовых компаний и где их искать

СТО — соединяющее звено между бизнес-целями компании и их техническим воплощением. Он общается с ключевым клиентами по техническим вопросам, проводит совещания с рабочими группами и проектными менеджерами, участвует в брейнстормингах и интервью с потенциальными сотрудниками, обучает команды — и это только часть его задач. Проблема украинского IT-сообщества в том, что у отечественных СТО продуктовых компаний нет площадок для встреч, профессиональной коммуникации и обмена опытом. Поэтому тем для общения накопилось много, начиная от внедрения технических решений, и заканчивая вопросами создания и управления командой. Дмитрий Волошин, СТО международного онлайн-маркетплейса для поиска репетиторов Preply.com, организатор Kyiv CTO Meetup провел блиц-опрос среди своих коллег на самые актуальные для них темы: использование микросервисов и контейнеризации в их работе, а также о методах построения эффективной команды.

Применять концепцию микросервисов уместно в том случае, если продукт достаточно сложный, чтобы разделить его на отдельные компоненты. Еще необходимо следить за тем, чтобы процессы действительно были независимыми. Если компоненты совместно используют данные или передают их друг другу, вряд ли переход на микросервисную архитектуру себя оправдает. Процесс миграции на микросервисы легче всего проходит у тех команд, которые привыкли применять DevOps и Scrum или другие agile-подходы. А вот, что думают об этом мои коллеги:

Олег Черний, CТO Ria
1. Монолит или микросервисы. Что используете вы, как и почему?
Мы плавно движемся от монолита к микросервисам. В зависимости от проектов, от 10% до 70% кода переведено на микросервисную архитектуру.
В основе взаимодействия между микросервисами лежит обычный HTTP-протокол с сообщениями в формате JSON, также важным компонентом нашей микросервисной архитектуры является сервер очередей RabbitMQ. Языки реализации микросервисов самые разные: nodejs, php, erlang (elixir), perl.
Небольшая часть наших микросервисов доступна для сторонних разработчиков и уже этим летом через наши API можно будет искать и получать информацию об объявлениях.
2. Каким образом вы принимаете решение, выбирая между покупкой или созданием необходимых для проекта инструментов?
Если это наш профильный инструмент, то в первую очередь ищем бесплатную OpenSource-реализацию. Скорее будем допиливать под себя OpenSource-инструмент, чем привязываться к платному. Если же это не профильный инструмент (1С, корпоративный Gmail, Kayako) — то покупаем.
3. Как вы внедряете новые технологии? Используете ли вы альфа-превью для фреймворков? Вы переходите на новые технологии итерационно или поступательно?
По-разному, например, тестирование технологии может проходить и на альфа-версии продукта. Сейчас, например, мы учимся распознавать информацию на фото техпаспорта автомобиля, сделанного мобильным телефоном. Тесты проходят на Tesseract 4.0 alpha. Но это нас не пугает. (Улыбается)
На новые технологии мы переходим тоже по-разному: и итерационно, и поступательно. Тут как раз микросервисная архитектура предоставляет максимальную гибкость. У нас 8 независимых команд разработки и тимлид команды выбирает то, что ему больше подходит.

Тарас Мурашко (CTO Evo)
1. Монолит или микросервисы. Что используете вы, как и почему?
На данный момент наш самый большой проект prom.ua является монолитом, вокруг которого уже достаточно много микросервисов, которые выполняют специфические задачи. К примеру, рекламная сеть ProSale, каталогизатор товаров, динамический ресайз фотографий и несколько других. Но мы продолжаем работать в направлении разделения монолита на микросервисы.
2. Каким образом вы принимаете решение, выбирая между покупкой или созданием необходимых для проекта инструментов?
В большинстве случаев мы используем OpenSource-решения. Также мы достаточно много разрабатываем своих собственных инструментов и библиотек, которые, по возможности, тоже стараемся опенсорсить.
3. Как вы внедряете новые технологии? Используете ли вы альфа превью для фреймворков? Вы переходите на новые технологии итерационно или поступательно?
Во внедрении альфа- и даже бета-версий мы очень осторожны. У нас достаточно большой проект, которым пользуются миллионы пользователей, поэтому стабильная работа нам очень важна. Но в разработке новых проектов мы постоянно используем все последние версии.

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

Станислав Скляровский (CTO Lun/Flatfy)
1. Структура команды: функциональные или кросс-функциональные команды, наподобие squads в Spotify. Что работает для вашей компании и почему?
В ЛУНе мы перешли на кросс-функциональные команды (называем их «продуктовыми»). По сути, они «от и до» занимаются проектом. В нашем случае это позволило уменьшить коммуникационные задержки в разработке любой фичи, улучшило понимание всеми того, что они делают, зачем и почему именно в таком порядке.
2. Как вы измеряете перформанс dev-команды?
Чистых dev-команд у нас нет. Все работают по продуктовым KPI. В них и измеряем.
3. Нанимать больше junior или senior специалистов? Покупать таланты или растить их? Fullstack или узкоспециализированные разработчики?
Всем хочется уже готовых, тех, кто прямо здесь и сейчас все сделает. (Улыбается.) Мы привлекаем как начинающих специалистов, так и специалистов с опытом. С опытными разработчиками иногда возникают ситуации, в которых их опыт — их же враг. Поэтому для нас интересны, в первую очередь, правильные по soft skills люди, мы даем им возможность очень быстро расти в hard skills. Это актуально и для людей с опытом.
Понятие «fullstack» все больше уходит в прошлое, у нас в каждой команде есть как бэкенд-разработчики, так и фронтенд.

Тарас Полищук (CTO TripMyDream)
1. Структура команды: функциональные или кросс-функциональные команды, наподобие squads в Spotify. Что работает для вашей компании и почему?
В TripMyDream несколько команд, которые по структуре являются кросс-функциональными. Они работают по Scrum Framework, при этом у каждой команды свой фокус. Одна команда больше сфокусирована на продукт и технологию, другая — на е-коммерс и так далее. Узкоспециализированные специалисты шейрятся между командами по необходимости. Также, недавно мы перешли на систему целей OKR (Objectives and Key Results) и ежеквартально делаем переконфигурацию команд между собой в зависимости от целей компании.
2. Как вы измеряете перформанс dev-команды?
Перформанс измеряется успешной разработкой инкрементов продукта, запланированных на спринт. Фокус идет не на количество выполненных задач, а на качество ключевых user stories. Самое сложное — успешно запланировать спринт. Чем успешнее прошло планирование, тем более Happy команда и тем лучше результат.
3. Нанимать больше junior или senior специалистов? Покупать таланты или растить их? Fullstack или узкоспециализированные разработчики?
У нас есть правило не нанимать junior специалистов, так как ими нужно заниматься. В этом большое отличие между стартапом и средней/крупной компанией. В стартапе у тебя физически нет времени вовлекаться в полноценное обучение. Однако, как и у каждого правила, всегда есть исключения, подтверждающие это правило. К нам пришел trainee, даже не junior, который хотел переквалифицировать в front-end разработчика, при этом не являясь инженером. До этого он работал директором магазина. Он предложил поработать бесплатно с полностью самостоятельным обучением до тех пор, пока не начнет выдавать нормальный результат. Через 4 месяца работы парень стал частью команды, и полностью закрыл собой часть важных функций по разработке. Есть и антипримеры, полностью противоположные, когда профессионал не выдает результат. Поэтому, на первом месте Attitude (отношение человека к работе и его мотивация), и уже на втором месте Execution.

А что по этому поводу думаете? Оставляйте свои комментарии и приходите на следующий Kyiv CTO Meetup, который состоится уже 1 июля.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ответ был получен в чёткости тот, который хотел вопрошающий. Всё лишнее, так понимаю, просто вырезано. Итого: попытка вбросить.

Думаю, что на Kyiv CTO Meetup делать откровенно нечего, особенно реальным СТО. Разве только выучить пару-тройку моднявых слов, для тех кто не знает английский.

Подписаться на комментарии