Mindbox

Открыт набор в Школу разработчиков с перспективой стажировки в Mindbox

27.07.2020 18:22:43 |

Автор: admin

Школа разработчиков первый шаг к стажировке в Mindbox. Программа предназначена для студентов 34 курса и выпускников технических вузов с базовыми навыками программирования.
Первый набор Школы стартует 6 сентября, курс разбит на 8 занятий по 45 часов.

Чтобы записаться, оставьте контактные данные пришлем тестовое задание, рассчитанное на два часа. Но сначала убедитесь, что обучение в Школе разработчиков Mindbox это то, что вам нужно. Все подробности под катом.

Как появилась идея Школы разработчиков Mindbox

Стажеров мы набираем уже полтора года. Цель программы пополнить ряды разработчиков джуниорами. За это время с нами поработали 22 человека: шесть из них учатся прямо сейчас, еще шестеро устроились к нам в штат.

Чтобы молодым разработчикам было проще справиться с задачами на стажировке (а они не по силам многим начинающим), мы решили запустить бесплатную Школу, призванную помочь будущим коллегам со стартом карьеры. О том, как пройти путь от Школы через стажировку до трудоустройства, расскажу я разработчик и автор учебного курса Виталий Маргелов. Своим видением и советами поделится наш CEO Александр Горник.

О Школе разработчиков Mindbox

Чему и как обучаем в Школе

Обучение ориентировано на отработку современных подходов к .NET разработке, включает в себя практику объектно-ориентированного и функционального программирования на C# и Typescript, использования инструментов разработчика, активное изучение и применение принятых в индустрии практик командной работы (agile, scrum, code review, gitflow, continuous integration, continuous delivery). Главный навык после окончания курса умение писать полноценные веб-приложения с фронтендом, сложной бизнес-логикой и работой с базой данных.

План занятий

Базовые знания разработчика: цели, инструменты, основные понятия.
Что такое объектно-ориентированное программирование и почему оно важно.
Архитектура больших приложений.
Практические аспекты ежедневной работы программиста.
Процессы разработки и её место в компании.
Основы реализации собственного API.
Базы данных и работы с ними из C# кода.
Что бэкенд-разработчику нужно знать о фронтенде.

Расписание занятий

Первый набор Школы стартует 6 сентября, это воскресенье. Курс из 8 занятий по 45 часов (с перерывами, конечно) идет два месяца, приезжать к нам в офис нужно будет раз в неделю по воскресеньям. Приготовьтесь к интенсивной работе: в течение недели будет много домашки, около 15 часов.

О преподавателе (то есть обо мне)

Преподаю в Школе я, Виталий Маргелов. Общий стаж в коммерческой разработке около шести лет. До Mindbox три года разрабатывал высоконагруженные приложения в Лаборатории Касперского, полгода в CloudPayments, полгода занимался своей веб-студией. В Mindbox два года в роли разработчика, scrum-мастера и ментора стажеров.

Еще на третьем курсе обучения в родном НИТУ МИСиС я создал студенческую организацию, в которой четыре года преподавал программную инженерию и вел ИТ-проекты со студентами. Нами двигало желание научиться ремеслу разработки, но вуз этих знаний не давал. Нескольких месяцев работы в этой организации студентам хватало, чтобы обучиться основам, начать разрабатывать с нами коммерческие проекты или найти свою первую работу (и нашли её в итоге все). В Mindbox я стараюсь создать похожую среду, в которой студенты чувствовали бы себя вовлеченными, а свой труд ценным. На мой взгляд, это самое важное, чего не может дать вуз или самостоятельное обучение.

Как попасть в Школу

Чтобы попасть на обучение, нужно быть студентом 34 курса бакалавриата или выпускником технического вуза и обладать базовыми навыками программирования: уметь объявлять переменные, массивы и функции, писать циклы и условные операторы, понимать логические конструкции.

Для записи оставьте контактные данные отправим небольшое тестовое задание. Рассчитываем, что справитесь с ним примерно за два часа.

Комментарий CEO Mindbox, Александра Горника

В начале истории компании мы ждали от инженеров знания основ и горящих глаз. И из этих джуниоров выросли все ключевые люди. Я и сам был таким перед первой работой. Со временем мы начали нанимать всё более узких и опытных специалистов. Цель стажировки вернуть наем малоопытных, но амбициозных и трудолюбивых инженеров, чтобы из них выросли будущие архитекторы, лиды, scrum-мастера и product-ownerы.

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

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

Ожидания от стажировки оправдываются. Мы нанимаем больше, чем планировали, и уровень нанятых выше ожиданий. Уровень настолько высокий, что мы закрыли публичные вакансии junior и middle разработчиков (хотя по факту светлых кандидатов готовы брать в любых зарплатных диапазонах, откликайтесь смелее). В отношении более долгосрочных ожиданий покажет время, но ребята растут быстро.

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

О стажировке в Mindbox

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

Стажировка в Mindbox длится от трех до шести месяцев. Длительность зависит от общего впечатления от стажера оно складывается из того, как он справляется с задачами, прогрессирует, работает с обратной связью, способен ли выполнять работу без сверхопеки.
Стажировка оплачивается: 25 тысяч рублей при удаленной работе 20 часов в неделю и посещении офиса раз в неделю. Если нужно закроем производственную практику.

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

На прошлом месте работы задания выглядели, как лабораторные работы, расти было некуда. Я искал стажировку fullstack, и описание Mindbox меня зацепило.

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

Стажировка однозначно приближает меня к цели стать fullstack-разработчиком: каждая корректировка дает толчок. За первые три месяца здесь я узнал больше, чем за год на прошлом месте.

Рафик Абдряхимов, стажер

О трудоустройстве в Mindbox

Если мы довольны стажером, а в командах разработки есть места, пригласим кандидата на командное собеседование и, в случае успеха, в штат на 3040 часов в неделю. Все шестеро стажеров, которые перешли в штат, работают разработчиками, но мы готовы собеседовать и на младшие позиции product ownerа или SRE при наличии соответствующих наклонностей у стажера и запроса со стороны компании.

Я поступал в магистратуру МГТУ им. Н. Э. Баумана и искал стажировку, которая позволила бы совмещать работу и учебу. Про Mindbox ничего не знал, но вакансия показалась приятной, и я решил попробовать.

Стажировка оказалась очень полезной: для студента важно научиться взаимодействию в команде это нельзя узнать в теории, можно только попробовать на деле. Именно в Mindbox я первый раз увидел, как agile применяется на практике.

Стажировка помогла определиться с дальнейшим направлением работы: я узнал много тонкостей про С# (до стажировки моим основным языком был Python) и решил, что буду развиваться в С# и .NET. Сейчас работаю разработчиком и планирую дальше учиться и развиваться в будущем, возможно, дорасту до архитектора.

Тем, кто думает, идти ли в нашу Школу, я могу дать один совет идите! Вы получите мегаполезный опыт, научитесь крутым вещам и получите массу приятных впечатлений. Самые классные курсы в университете были те, где действующие разработчики делились опытом. Так и здесь: я видел программу Школы, она реально может заменить два года учебы в топовом вузе.

Юрий Соколов, разработчик Mindbox

Советы начинающих разработчикам от нашего CEO

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

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

Всё остальное вы сможете осознанно выбрать позже, когда разберетесь в рынке и поймете, что вам нужно. В начале карьеры очень важно заложить культуру, как с точки зрения техники (stack, инженерные практики), так и организационно (нормальный agile). Разница в производительности отделов разработки может быть даже не в разы, а на порядки. А из карьерных тупиков с возрастом выбираться всё труднее и труднее.

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

Александр Горник, CEO Mindbox

Подробнее..

Категории: Образование , Net , Карьера в it-индустрии , Обучение программированию , Mindbox , Блог компании mindbox , Стажировка , Школа

Интеграция интернет-магазина на 1С-Битрикс с Mindbox

17.07.2020 10:14:14 |

Автор: admin

Для развития систем лояльности интернет-магазины обращаются к платформам автоматизации маркетинга, Customer Data Platform (CDP). При этом иногда для успешной интеграции нужно сохранять больше данных, чем указано в документации к API.

Рассказываем, какие данные понадобились нам для интеграции магазина на 1С-Битрикс с платформой Mindbox, как их можно получить с помощью API и SDK и как использовать комбинированный подход с асинхронной отправкой данных.

С помощью сервисов Customer Data Platform ритейлеры узнают портрет своего покупателя, в том числе поведенческие данные. Эта информация хранится в CDP в защищенном виде и помогает ритейлерам в проведении маркетинговых кампаний и аналитике.

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

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

Предыстория

Интернет-магазины могут подключиться к Mindbox двумя основными способами: с помощью API либо JavaScript SDK (об отличиях мы расскажем далее).

Для выбора оптимального способа мы обратились к документации Mindbox, а если информации не хватало, то задавали вопросы менеджеру. Мы выяснили, что наше сотрудничество совпало с периодом бурного роста платформы Mindbox: среднесуточная нагрузка по вызовам API Mindbox увеличилась вдвое (до 120 тысяч запросов в минуту, в пик до 250 тысяч). Это означало, что в период Черной пятницы и прочих распродаж из-за дополнительного роста нагрузки возникал риск, что CDP-сервис окажется недоступен и не получит данные интернет-магазина, который с ним интегрирован.

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

Методы интеграции с Mindbox

Как отмечено выше, Mindbox предлагает использовать для подключения API или JavaScript SDK. Далее рассмотрим их особенности.

JavaScript SDK

Библиотека-обёртка над API, предоставляемая сервисом. Её плюсы простота интеграции и возможность асинхронной передачи данных. Оптимально подходит для тех случаев, когда нужно поддерживать только web-платформу.

Ограничения: возможна потеря данных, если Mindbox недоступен в момент отправки. Скрипты платформы не подгрузятся, если на стороне интернет-магазина есть js-ошибки.

Интеграция по API

Интеграцию магазина с Mindbox можно провести через API. Этот способ снижает зависимость от JavaScript и также подходит для настройки асинхронной отправки данных.

Ограничения: мы столкнулись с тем, что не получали некоторые данные cookie, а именно уникальный идентификатор пользователя на устройстве (mindboxDeviceUUID). Его необходимо передавать в большинстве операций Mindbox для склеивания информации по пользователю.

В документации эти cookie обязательны не для всех операций. И всё же, стремясь к бесперебойной передаче данных, мы обсудили этот вопрос с менеджером Mindbox. Выяснили, что для максимальной надежности желательно всегда отправлять cookie. При этом для получения cookie нужно использовать JavaScript SDK.

Комбинированный метод

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

Поэтому мы обратились к третьему, комбинированному методу: работаем и с API, и с JavaScript SDK, используя наш модуль очередей.

С помощью Javascript SDK мы идентифицируем пользователя на сайте (mindboxDeviceUUID). Затем на стороне сервера формируем запрос со всеми необходимыми данными и помещаем его в очередь. Запросы из очереди через API отправляются сервису Mindbox. В случае отрицательного ответа запрос повторно помещается в очередь. Таким образом, при отправке данных Mindbox получает полный комплект необходимой информации.

В приведенном далее примере класс Sender позволяет собрать и отправить запрос, выполнив первичную обработку ответа. Класс использует данные из самой команды (тип запроса/ответа, deviceUUID и др.) и из настроек модуля (параметры работы с API, токены и т.п.).

<?phpdeclare(strict_types=1);namespace Simbirsoft\MindBox;use Bitrix\Main\Web\Uri;use Bitrix\Main\Web\HttpClient;use Simbirsoft\Base\Converters\ConverterFactory;use Simbirsoft\MindBox\Contracts\SendableCommand;class Sender{    /** @var Response Тело ответа */    protected $response;    /** @var SendableCommand Команда */    protected $command;    /**     * Sender constructor.     *     * @param SendableCommand $command     */    public function __construct(SendableCommand $command)    {        $this->command = $command;    }    /**     * Сформировать массив заголовков запроса.     *     * @return array     */    protected function getHeaders(): array    {        return [            'Accept'        => Type\ContentType::REQUEST[$this->command->getRequestType()],            'Content-Type'  => Type\ContentType::RESPONSE[$this->command->getResponseType()],            'Authorization' => 'Mindbox secretKey="'. Options::get('secretKey') .'"',            'User-Agent'    => $this->command->getHttpInfo('HTTP_USER_AGENT'),            'X-Customer-IP' => $this->command->getHttpInfo('REMOTE_ADDR'),        ];    }    /**     * Сформировать адрес запроса.     *     * @return string     */    protected function getUrl(): string    {        $uriParts = [            Options::get('apiUrl'),            $this->command->getOperationType(),        ];        $uriParams = [            'operation'  => $this->command->getOperation(),            'endpointId' => Options::get('endpointId'),        ];        $deviceUUID = $this->command->getHttpInfo('deviceUUID');        if (!empty($deviceUUID)) {            $uriParams['deviceUUID'] = $deviceUUID;        }        return (new Uri(implode('/', $uriParts)))            ->addParams($uriParams)            ->getUri();    }    /**     * Отправить запрос.     *     * @return bool     */    public function send(): bool    {        $httpClient = new HttpClient();        $headers = $this->getHeaders();        foreach ($headers as $name => $value) {            $httpClient->setHeader($name, $value, false);        }        $encodedData = null;        $request = $this->command->getRequestData();        if (!empty($request)) {            $converter = ConverterFactory::factory($this->command->getRequestType());            $encodedData = $converter->encode($request);        }        $url = $this->getUrl();        if ($httpClient->query($this->command->getMethod(), $url, $encodedData)) {            $converter = ConverterFactory::factory($this->command->getResponseType());            $response = $converter->decode($httpClient->getResult());            $this->response = new Response($response);            return true;        }        return false;    }    /**     * @return Response     */    public function getResponse(): Response    {        return $this->response;    }}

Трейт Sendable содержит все возможные настройки команды для отправки запроса в Mindbox, в том числе предустановленные, такие как тип запроса/ответа, метод запроса и параметр синхронности/асинхронности. Также в нем присутствуют методы, общие для всех команд.

<?phpdeclare(strict_types=1);namespace Simbirsoft\MindBox\Traits;use RuntimeException;use Bitrix\Main\Context;use Simbirsoft\MindBox\Type;use Simbirsoft\MindBox\Sender;use Simbirsoft\MindBox\Response;use Bitrix\Main\Localization\Loc;use Simbirsoft\MindBox\Contracts\SendableCommand;Loc::loadMessages($_SERVER['DOCUMENT_ROOT'] .'/local/modules/simbirsoft.base/lib/Contracts/Command.php');trait Sendable{    /** @var string Метод отправки (GET/POST) */    protected $method = Type\OperationMethod::POST;    /** @var string Тип операции (sync/async) */    protected $operationType = Type\OperationType::ASYNC;    /** @var string Тип запроса (json/xml) */    protected $requestType = Type\ContentType::JSON;    /** @var string Тип ответа (json/xml) */    protected $responseType = Type\ContentType::JSON;    /** @var array Вспомогательные данные */    protected $data = [];    /**     * Название операции.     * @return string     */    abstract public function getOperation(): string;    /**     * Формируем данные.     *     * @return array     */    abstract public function getRequestData(): array;    /**     * HTTP метод запроса     *     * @return string     */    public function getMethod(): string    {        return $this->method;    }    /**     * Тип операции     *     * @return string     *     * @noinspection PhpUnused     */    public function getOperationType(): string    {        return $this->operationType;    }    /**     * Тип запроса.     *     * @return string     *     * @noinspection PhpUnused     */    public function getRequestType(): string    {        return $this->requestType;    }    /**     * Тип ответа.     *     * @return string     *     * @noinspection PhpUnused     */    public function getResponseType(): string    {        return $this->responseType;    }    /**     * Вспомогательные данные запроса     *     * @return void     */    public function initHttpInfo(): void    {        $server = Context::getCurrent()->getServer();        $request = Context::getCurrent()->getRequest();        $this->data = [            'X-Customer-IP' => $server->get('REMOTE_ADDR'),            'User-Agent'    => $server->get('HTTP_USER_AGENT'),            'deviceUUID'    => $request->getCookieRaw('mindboxDeviceUUID'),        ];    }    /**     * Получить вспомогательные данные запроса     *     * @param string $key     * @param string $default     *     * @return string     *     * @noinspection PhpUnused     */    public function getHttpInfo(string $key, string $default = ''): string    {        return $this->data[$key] ?? $default;    }    /**     * Выполняем команду.     *     * @return void     *     * @throws RuntimeException     */    public function execute(): void    {        /** @var SendableCommand $thisCommand */        $thisCommand = $this;        $sender = new Sender($thisCommand);        if ($sender->send()) {            throw new RuntimeException(Loc::getMessage('BASE_COMMAND_NOT_EXECUTED'));        }        $response = $sender->getResponse();        if (!$response->isSuccess()) {            throw new RuntimeException(Loc::getMessage('BASE_COMMAND_NOT_EXECUTED'));        }        if (!$this->prepareResponse($response)) {            throw new RuntimeException(Loc::getMessage('BASE_COMMAND_NOT_EXECUTED'));        }    }    /**     * Обработка ответа запроса.     *     * @param Response $response     *     * @return bool     */    public function prepareResponse(Response $response): bool    {        // $body   = $response->getBody();        // $status = $body['customer']['processingStatus'];        /**         * Возможные статусы:         * AuthenticationSucceeded - Если пароль верен         * AuthenticationFailed         - Если пароль не верен         * NotFound                          - Если потребитель не найден         */        return true;    }}

В качестве примера рассмотрим событие авторизации пользователя. В обработчике события авторизации мы добавляем в нашу очередь объект класса AuthorizationCommand. В этом классе происходит минимально необходимая подготовка информации, поскольку в момент выполнения команды данные в базе могут измениться, и нужно их сохранить. Также устанавливаются соответствующие параметры для запроса в Mindbox, в данном случае это название операции (узнаем в админ. панели Mindbox). Дополнительно можно указать тип запроса/ответа, метод запроса и параметр синхронности/асинхронности согласно трейту Sendable.

<?phpdeclare(strict_types=1);namespace Simbirsoft\MindBox\Commands;use Simbirsoft\Queue\Traits\Queueable;use Simbirsoft\MindBox\Traits\Sendable;use Simbirsoft\Queue\Contracts\QueueableCommand;use Simbirsoft\MindBox\Contracts\SendableCommand;final class AuthorizationCommand implements QueueableCommand, SendableCommand{    use Queueable, Sendable;    /** @var array Данные пользователя */    protected $user;    /**     * AuthorizationCommand constructor.     *     * @param array $user     */    public function __construct(array $user)    {        $keys = ['ID', 'EMAIL', 'PERSONAL_MOBILE'];        $this->user = array_intersect_key($user, array_flip($keys));        $this->initHttpInfo();    }    /**     * Название операции.     *     * @return string     */    public function getOperation(): string    {        return 'AuthorizationOnWebsite';    }    /**     * Формируем данные.     *     * @return array     */    public function getRequestData(): array    {        return [            'customer' => [                'email' => $this->user['EMAIL'],            ],        ];    }}

Схема взаимодействия модулей

В нашем проекте мы выделили три модуля:

Базовый

Служит для хранения общих вспомогательных классов и интерфейсов (например, интерфейсов команд), которые можно потом использовать во всем проекте.

Модуль очередей

Взаимодействие с Mindbox реализовано через команды. Для их последовательного выполнения мы используем наш модуль очередей. Этот модуль сохраняет поступившие команды и выполняет их, когда наступает время выполнения.

Модуль интеграции с Mindbox

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

Модуль Mindbox отслеживает на сайте события и сопутствующую информацию, в том числе из cookie, формирует из них команду и помещает её в очередь. Когда модуль очередей извлекает команду из очереди и выполняет её, происходит отправка данных. Если ответ от Mindbox отрицательный неудачно выполненная команда переносится в конец очереди, если положительный успешно выполненная команда удаляется из очереди.

Таким образом, с помощью описанного выше комбинированного метода мы смогли обеспечить бесперебойную передачу данных в Mindbox.

Подводя итоги

В этой статье мы рассмотрели, какими способами интернет-магазин может подключиться к Customer Data Platform для развития систем лояльности.

В нашем примере в документации Mindbox были описаны два основных способа подключения: через Javascript SDK и через API. Для повышения надежности передачи данных, даже в случае временной недоступности CDP-сервиса, мы выбрали и реализовали третий, комбинированный способ: с помощью API и Javascript SDK, с асинхронной отправкой данных.

Спасибо за внимание! Надеемся, эта статья была для вас полезна.

Подробнее..

Категории: Программирование , Маркетинг , Разработка под e-commerce , E-commerce , Блог компании simbirsoft , 1с-битрикс , Управление e-commerce , Битрикс , Ритейл , Mindbox , Javascript sdk , Customer data platform , Модуль очередей

Управление разработкой в горизонтальных компаниях расшифровка онлайн-встречи. Часть 2

18.11.2020 16:23:31 |

Автор: admin

На прошлой неделе мы выпустили расшифровку первой части онлайн-встречи Управление разработкой в горизонтальных компаниях, где приняли участие СТО Райффайзенбанка, Mindbox и руководитель разработки в Циан.

Сегодня публикуем вторую и последнюю часть митапа: это вопросы из зала, которые задали слушатели гостям. Пост получился объемным, поэтому, если не хотите читать, то посмотреть видео можно ниже (запустится сразу с нужного момента там, где закончилась первая часть).

Гости

Сергей Кононенко, CTO в Райффайзенбанке

Никита Прудников, CTO в Mindbox

Михаил Юматов, руководитель разработки в Циан

Ведущий: Алексей Рыбак, CTO Везёт.

Темы второй части

Чем leadership внутри плоской команды отличается от менеджмента?
Как в горизонтальной структуре решаются вопросы безопасности?
Какие плюсы от открытых зарплат в Mindbox?
Как команда соблюдает technical excellence?
Как в горизонтальных компаниях шарятся ресурсы?
Есть ли у вас и как устроен Performance Review?

Чем leadership внутри плоской команды отличается от менеджмента. Как решаются вопросы безопасности. Technical excellence. Решение конфликтов

Алексей Рыбак: Давайте сейчас перейдем к вопросам из зала. Я начну зачитывать те вопросы, которые есть в текстовом чате. Первый вопрос был от Димы Кушникова. Сергей, а чем leadership внутри команды отличается от менеджмента?

Сергей Кононенко: Менеджмент command and control. Command and control никто из этих троих людей, которые входят у нас в leadership team, не занимается.

Алексей Рыбак: Понял. Следующий вопрос тоже от Дмитрия. Банковское обслуживание довольно регулируемая индустрия. Наверняка есть огромное количество требований, которые необходимо соблюдать, чтобы регулярно проходить аудит безопасности? Что случилось с политикой безопасности в процессе трансформации?

Сергей Кононенко: Ничего не случилось, они все с нами. Аудиты есть не только по безопасности, есть много других аудитов, которые мы регулярно проводим: как внутренние, так и внешние, так и групповые из Raiffeisen Group.

Алексей Рыбак: Следующий вопрос был тоже от Дмитрия. Сергей, кто и как контролирует, что команда соблюдает договоренности, technical excellence? Как происходит изменение требований technical excellence?

Сергей Кононенко: Бездушные роботы контролируют. Есть соответствующие механизмы, которые просматривают все артефакты команды и смотрят, попали в threshhold выполнения или не попали. Как происходит? Все изменения болезненны обычно для организации, поэтому происходят желательно мягко, с большим количеством информации: почему это происходит, когда это произойдет, зачем это происходит.

Алексей Рыбак: Хорошо, следующий вопрос. По-видимому, уже всем. Вопрос от Вадима Назарова. Отличный, кстати вопрос. Как организуется решение конфликтов, если платформенной команде в рамках своего проекта требуются какие-то доработки от продуктовых команд, а у продуктов тоже свой бэклог?

Сергей Кононенко: Мне, наверное, проще всего ответить. У нас нет платформенных команд, которым нужны какие-то особенные доработки. Платформенные команды выставляют definition of done, что значит разработка на их платформе. Если этот definition of done под продуктовые команды не соблюден, то их инкремент просто не принимается в платформу.

Алексей Рыбак: Понятно. Никита, как у вас?

Никита Прудников: Через разговор. Чаще всего команда, если она берется за какое-то изменение, затрагивающее других, то базовое решение, которое она может принять это сделать это изменение сама и уведомить другую команду, что намерена такое изменение сделать. Если оказывается, что те ребята против, то это классическое разрешение через вето-встречу.

Алексей Рыбак: То есть через какую-то специальную встречу, где происходит какая-то договоренность. Хорошо, тогда такой вопрос. Во всех liberated структурах есть всегда такой стиль, когда ты, с одной стороны короче, вежливое нет, вежливое постоянное нет. Структура позволит это сделать, но в случае, если постоянно идет отказ: Да, но не сейчас. Нет времени, слушай, такой важный проект. Да, техдолг, но не сейчас, и постоянно, постоянно откладывается. Что произойдет? Встречаемся: Слушай, не могу, не можем.

Никита Прудников: Подожди, в чем заключается уведомление? Я сейчас моделирую ситуацию, про которую ты говоришь.

Алексей Рыбак: У тебя есть платформенная команда, которая переходит с одной версии API или базы данных на другую. И логику надо переписать, потому что тот SQL, который я написал, или тот API, который я использую, новым софтом не поддерживается. Я должен переписать достаточно важный кусок. Я не хочу его трогать, оно поломает дофига всего. Я объяснил это продакту, который говорит: Не-не-не, вы вчера сломали что-то. И в прошлом месяце что-то сломали. Нет, сейчас мы делать не будет, потому что у нас очень важные планы, бла-бла-бла

Никита Прудников: Да, я понял, могу ответить.

Алексей Рыбак: Ну, привет! А когда? Вы встретились, сказали: Встретимся через две недели и поговорим. За две недели произошло еще что-то, через две недели тоже. Вот такой сценарий. Дальше?

Никита Прудников: Я хочу остановить твой сценарий на том моменте, когда команда принимает решение так сделать. У нее есть несколько вариантов выбора. Во-первых, она может что-то сделать сама, уведомив продакта. И тогда продакт окажется не в суперпереговорной позиции, в смысле может ей запретить через вето. И тогда это вето разрешится. И одна из опций разрешения этого вето это то, что продуктовая команда запулит

Алексей Рыбак: Кто влезет в бизнес-логику? Платформенная команда влезет в бизнес-логику, перепишет какие-то вызовы, платформу?

Никита Прудников: В том числе она может так сделать, конечно.

Алексей Рыбак: Я понял. У вас были такие кейсы? В реальности были такие ситуации или нет? Как они разрешались?

Никита Прудников: Давай подумаем. У нас часто нет такой суперантогонизации между ролями команд. То есть, если такие кейсы возникали, чаще всего не было конфликта. Платформенная команда договаривалась с продуктовой, у которой вообще-то есть выделенный постоянно ресурс на технический долг, который она может тратить. И они решали, что эту часть чуваки сделают у себя, потому что это business critical, и они очень сильно в домене это знают, эту часть запулит себе платформенная команда.

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

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

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

Алексей Рыбак: Это применимо только для таких задач, которые ты можешь сформулировать на языке продукта. У тебя может быть конфликт вокруг задач, которые продукт даже не может понять.

Никита Прудников: Может быть, но я не могу вспомнить пример такой задачи, если честно. Из-за того, что очень близко коммуникация С одной стороны, всё привязано к бизнесу, и мы обучаем архитекторов мыслить от бизнеса. То есть нам не нужны рефакторинги в воздухе, они всегда замотивированы чем-то. И спустя годы архитекторы могут объяснить продукту, зачем им это нужно, потому что они работают с продуктом в одной команде постоянно и занимаются приоритезацией части роадмэпа.

Алексей Рыбак: Хорошо. Михаил, у вас конфликты тоже решаются больше на более ранней стадии общения? Или можешь вспомнить какие-то примеры, когда они выплеснулись куда-то, не смогли решить?

Михаил Юматов: Бывают ситуации, когда команда платформы не может договориться с продуктовой командой. В этом случае они подключают меня или это может дойти до уровня CTO, где мы можем разрешить этот конфликт. И это либо укладывается в квартальное планирование, если это какие-то большие истории, которые затрагивают много продуктовых команд, и нужно разрезать весь этот проект продуктовым командам плюс платформе. Либо это какие-то небольшие истории в рамках квартала. И, соответственно, либо продуктовые команды самостоятельно договариваются вместе с платформой, либо не договариваются и эскалируют выше. И мы уже вместе принимаем решения.

Открытые зарплаты: какие от них плюсы. Рыночные зарплаты, воронка кандидатов. Описание задач

Алексей Рыбак: Ясно, спасибо. Никита, к тебе вопросы. Два вопроса. Первый вопрос от Димы Кушникова. Какие плюсы вы получаете от открытых зарплат?

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

Алексей Рыбак: Да, но, с другой стороны, появляется в том числе и определенное давление отрицательного характера, которое никуда не деть, а так бы его могло бы и не быть.

Никита Прудников: А какого отрицательного давления?

Алексей Рыбак: Например, произошла какая-то ошибка или необходимо удержать сотрудника. И закрытые зарплаты позволяют сделать определенный дисбаланс. Но поскольку он не является открытым, то он не оказывает никакого отрицательного

Никита Прудников: Да, компания в организационным смысле более ограничена. Сейчас не самый, возможно, адекватный пример приведу. Если строить отношения с контрагентами на полной прозрачности и честности, то ты ограничиваешь пространство своих действий. Если ты их не обманываешь, то ты, возможно, дополнительную выручку не получишь, у тебя пространство твоих решений меньше. Но при этом, возможно, стратегически, долгосрочно это приведет тебя к тому, что ситуация доверия, например, и транзакционные издержки упадут.

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

Алексей Рыбак: То есть ты думаешь, что настолько все привыкают, в том числе к такого рода культуре, что и уже уходить некуда? Ты это имеешь в виду?

Никита Прудников: В каком-то смысле я это вижу. У нас компания, с точки зрения нагрузки, серьезная. Именно day-to-day workload большой. И мы даже со своей стороны, сейчас интересный минус расскажу открытых зарплат, мы до сих пор не придумали хорошего процесса, чтобы люди самостоятельно пушили свою зарплату.

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

И мы сейчас с HR, с каким-то таким вещами занимаемся. Возможно, восприму твой совет про один на один, что надо реструктурировать в этом месте. То есть такая проблема есть.

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

Алексей Рыбак: Разные бывают ситуации, особенно когда большие коллективы. Такой еще вопрос, перекликается с одним из последних, по-моему, вопросов. А как часто вы делаете рыночный обзор зарплат? И есть ли у вас процесс, который оценивает, произошел ли gap up? Или люди скромно работают, а потом в какой-то момент им поступает предложение и они находятся в ситуации, когда: Блин, нифига себе. Это почему у нас

Никита Прудников: Ну, gap большой. Но это то, про что я рассказал.

Алексей Рыбак: Вопрос был довольно прямой: рыночные ли у вас зарплаты? Я здесь развернул: как часто у вас происходит такого рода ревью? Что из себя представляет этот процесс?

Никита Прудников: Ревью обычно происходит с точки зрения вакансий. Я и еще ряд людей, мы занимаемся интерированием вакансий на HeadHunter. И нам, естественно, с учетом того, что полностью открыты зарплаты внутри компании, этот гэп понятен. То есть у нас есть какая-то вилка на HH, к нам приходят какие-то люди по воронке

Алексей Рыбак: Прости, Никита, не понял. Как он вам понятен? С HeadHunter вы взяли эту информацию?

Никита Прудников: Мы делаем вилку на HeadHunter в вакансии, и к нам в воронку приходят какие-то люди. У нас нон-стоп конвейер собеседований. У меня каждый день примерно по одному собеседованию C#, лидов, я участвую.

Алексей Рыбак: Правильно я понимаю, что вы собираете это с потока входящих?

Никита Прудников: Да, во-первых, входящий поток. Иногда мы смотрим статистику, например, ту же самую у HeadHunter покупаем. И через это сравниваем с зарплатами внутри, с распределением. Но, смотри, обращаю твое внимание, вопрос интересный, насчет открытых зарплат отставания есть определенные.

Алексей Рыбак: С потоком такая проблема. Ты ошибся, ты получаешь достаточное количество людей, но не получаешь определенных людей. У тебя получается ошибка смещенной оценки. С одной стороны, ты получаешь достаточное количество людей, которые зааплаились и что-то назвали. И при этом какую-то часть не видишь.

Никита Прудников: Но я в этот момент рефлексирую вилку, с ней же тоже процесс есть, она меняется. Если я вижу, что воронка работает не на меня, в этот момент я ее меняю.

Алексей Рыбак: Хорошо. У тебя есть понимание, какая текучка внутри компании?

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

Алексей Рыбак: То есть 2%? Если 50 человек

Никита Прудников: Я тут боюсь обмануть, честно тебе скажу. Просто я сейчас что-то из памяти вспоминаю. Кажется, оценка такая.

Алексей Рыбак: В любом случае это какие-то части. Давай двинемся дальше. Был еще вопрос, тоже, Никита, тебе. У нас минута Mindbox. Вадим Назаров спрашивает. Чем занимаются архитектор? Есть ли он? Кто ему ставит задачи? Кому подчиняется? Взаимодействует ли он с командой?

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

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

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

Алексей Рыбак: Понял. Никита, спасибо большое. У нас есть первый смелый. Спасибо большое, Георгий. Поднял руку, оказался на панели среди спикеров. Георгий, у вас вопрос. Прошу вас. Только включите, пожалуйста, микрофон.

Георгий: Всем привет. Во-первых, спасибо, Алексей, за такое мероприятие, интересно послушать, как бывает у людей. У меня вопрос к ребятам, к коллегам. Много было сказано по поводу задач. А кто занимается описанием задач? Участвуете ли вы в этом? Насколько глубоко описываются у вас задачи?

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

Алексей Рыбак: Спасибо большое. Кто хочет ответить из вас?

Сергей Кононенко: Давайте я отвечу. Задачи прорабатываются внутри команды. Если задача не имеет понятного acceptance-критерия, то есть критерия, по которому мы поймем, что задача сделана, то, скорее всего, она будет сделана не сразу, не очень качественно, и у нас будут сюрпризы. Поэтому, пока команда не поймет, что они понимают, что нужно сделать, скорее всего, задача в работу не пойдет.

Алексей Рыбак: В связи с этим у меня вопрос. Это искусство описывать задачи, в том числе это искусство Мы это всегда называли PRD, спеки не важно. Спеки более технический текст, PRD более продуктовый. Там идет взаимодействие с дизайнером, там идет взаимодействие, может быть, не с одним продактом. Продакт, если будет описывать задачу, зашьется. Дизайнер не всегда готов описывать. UX-человек, если есть отдельный UX-специалист или UX-дизайнер, то он, может быть, каких-то аспектов продуктовых не знает. То есть это всегда магия.

Два вопроса в связи с этим. Как добиться того, чтобы не умерли все эти люди в процессе описания, потому что иначе это будет бесконечно. И кто все-таки это делает? Кто это делает и как добиваемся того, что это не занимает бесконечное время?

Сергей Кононенко: Все очень просто. Команда делает команда описывает. Если команда описала сначала так, что потом не смогла сделать, то они это поймут, дадут себе обратную связь и в следующий раз сделают иначе.

Алексей Рыбак: Давай представим себе, что мы члены команды, а ты продакт. Ты принес идею, которая вообще никаким образом не описана, просто ее на словах принес. И дальше все остальные сели и сказали Появилась некоторая задача, которая должна быть описана. Но это же часть бэклога, получается, описать такую-то задачу?

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

Алексей Рыбак: Спасибо, Сергей. Михаил, ты включал микрофон, видимо, хотел что-то ответить.

Михаил Юматов: У нас все опять же зависит от команды. Где-то, может быть, в наиболее сложной предметной области есть project-менеджер, который берет какую-то идею сырой от продакта и описывает уже более детально. И с этим детальным описанием уже выходит к команде разработки, где вся команда ревьюит это дело.

Где-то, где, может быть, история попроще, это может быть идея от продакта, ребята собираются, вместе накидывают какие-то вопросы, там же на месте фиксируют какие-то договоренности, детали и так далее. После чего декомпозируют уже на сторисы.

Как решаются вопросы безопасности

Алексей Рыбак: Следующий вопрос был Уже вопросы из Youtube пошли. Вопросы безопасности как решаются в ваших структурах? Я так полагаю, что так или иначе вопросы безопасности идут через платформенные команды. И они есть как в Mindbox, так и в Циане.

А есть ли платформенные команды все-таки у вас, Сергей? И вопросы безопасности каким макаром решаются? Потому что команда собралась и сама решила, как делать с точки зрения безопасности это не самый лучший set up.

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

Алексей Рыбак: У меня в связи с этим следующий вопрос. Во-первых, резюме. Достаточно мощная служба безопасности, автоматизация процесса деплоя таким образом, чтобы происходили почти все проверки автоматически.

Ревью. Означает ли это, что это какой-то процесс фоновый, или означает ли это, что каждый коммит должен пройти ревью безопасника?

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

Алексей Рыбак: Вы не практикуете забыл, как это называется у безопасников эмуляцию атаки, причем иногда вслепую, когда люди даже не предупреждены. Практикуете такие вещи?

Сергей Кононенко: Chaos Monkey?

Никита Прудников: Я думаю, скорее, пентест ты имеешь в виду.

Алексей Рыбак: Больше пентест, но нормальный пентест, когда никто не предупрежден.

Сергей Кононенко: Пентесты и BCP практикуем обязательно. Но совсем без предупреждений мы не можем, потому что банк работает 24/7. Вы, извините, приедете на заправку, а у нас пентест, и вы не сможете заплатить карточкой.

Алексей Рыбак: Почему пентест приведет к тому, что я не могу заплатить карточкой.

Сергей Кононенко: А мало ли, пенетрейшн удастся, и система упадет.

Алексей Рыбак: Ах, в этом смысле. Хорошо. Давайте дальше, про безопасность сообразили.

Как в горизонтальных компаниях шарятся ресурсы. Performance Review. Как техлиды оценивают разработчиков не из своего стека

Алексей Рыбак: Михаилу вопрос. Как вы шарите ресурсы между командами, если шарите?

Михаил Юматов: Ресурсы это люди, наверное? Если люди, то стараемся этого не делать. Вот такой ответ. Иногда такое бывает, но это ад и для команд, и для человека.

Алексей Рыбак: Использует ли кто-то таймшиты? Если нет, то почему? Я не знаю, что такое таймшиты. Видимо, какая-то диаграмма или какое-то расписание?

Михаил Юматов: Это, видимо, отчетность по времени, как я понимаю.

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

Есть ситуации, когда нам необходимо, допустим, чтобы посчитать TCO системы или стоимость проектной деятельности, понять, сколько сил разные команды вложили в конкретный проект. Тогда мы считаем просто процент от сторипоинтов. Сколько задачи, которые были для конкретного проекта сделаны, отняли процентов времени команды. И из стоимости команды считаем процент, который идет в стоимость проекта.

Практика заставлять людей писать, сколько времени они чем занимались, порочная. Мы стараемся этого не делать, конечно.

Алексей Рыбак: Кто-нибудь еще хочет ответить?

Никита Прудников: Во-первых, мы стараемся очень сильно лайнить продукты с командами. То есть команда редко что-то делает, не относящееся к их продукту. Но процессы бюджетирования похожи, только мы вместо сторипоинтов просто используем эти блоки, карточки и также пропорционально делим. И из этого строим продуктовый P&L.

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

Алексей Рыбак: Хорошо. Ребята, еще быстрый вопрос всем. Просто давайте да или нет. Есть ли у вас performance review? Никита?

Никита Прудников: Все сложно. Что ты подразумеваешь под performance review?

Алексей Рыбак: Performance review это когда у тебя есть процесс, когда ты оцениваешь работу каждого человека в отдельности.

Никита Прудников: Если этот человек заводит карточку на повышение зарплаты, а это происходит автоматически, публично. В смысле, он же там пишет цели и то, чего он достиг.

Алексей Рыбак: Если он не завел эту карточку?

Никита Прудников: Если он работает как работает, в смысле нет вопросов с точки зрения стейкхолдера и других чуваков, то регулярного performance review нет. Если есть вопросики, тогда да, поехали. То есть on demand.

Алексей Рыбак: Сергей, как у вас?

Сергей Кононенко: Есть performance review команды. У команды есть performance-цели. И раз в год команда оценивается, и от этого зависит, получит команда бонус или не получит команда бонус.

Алексей Рыбак: Раз в год и всей командой?

Сергей Кононенко: Да.

Алексей Рыбак: Понял, спасибо. Как у вас, Михаил?

Михаил Юматов: Есть как оценка вовлеченности команды. Но это, скорее, больше про здоровье команды. И конкретного сотрудника тоже в том числе.

Алексей Рыбак: То есть у конкретного сотрудника есть performance review?

Михаил Юматов: Да.

Алексей Рыбак: Раз в какое время?

Михаил Юматов: Если говорить про какой-то общий процесс, то это может быть раз в полгода или год. Но на регулярной основе с лидом на one-to-one это постоянный процесс скорее.

Алексей Рыбак: Окей, то есть он такой Процесс performance review, если этот процесс, то у него есть определенный таймлайн, подготовка, заранее известные сроки, сколько раз в год. У кого-то один раз, у кого-то четыре раза. Хорошо, ладно.

Алексей Рыбак: Давайте двинемся дальше. Опять два вопроса Никите. Как техлиды оценивают технический уровень разработчиков не из своего стека?

Никита Прудников: У нас практически full stack. Просто из-за специфики компании У нас нет мобильной разработки, у нас очень ограниченный фронт, по сути, ограниченный облачной админкой нашего продукта. И очень много бэка. И большой проблемы с тем, что человек не разбирается в соседнем стеке, нет. Нам буквально только-только потребовались фронтенд-heavy истории. И в одной из команд появился выделенный фронтенд-лидер, который формулирует архитектуру фронта и все такое. И есть точка экспертизы и с точки зрения другого стека. Тут большой проблемы нет: ни в тех командах, где нет фронта, ни в той команде, где есть фронт. А с ним самим работаем совместно.

Алексей Рыбак: И следующий еще был вопрос, тоже, Никита, тебе. Про T-shape. В процессе работы компании возникает специалист с уникальным набором навыков. Как и надо ли это как-то выравнивать с рынком?

Никита Прудников: Если честно, я не совсем понял вопрос. В смысле, что он недооценен становится или в смысле, мы не понимаем, сколько ему платить? Давайте на какой-нибудь из этих вопросов отвечу.

Мне кажется, с этой точки зрения сильно помогают как раз открытые зарплаты. Просто из-за того, что мы не можем сформулировать суперформальные критерии, что такой человек с таким набором навыков стоит вот столько. Это случается органически, потому что этот человек работает в команде с другими людьми. И по сути вопрос в ценности. То есть насколько этот конкретный T-shaped ценен для команды и компании. Это и элайнится с зарплатой в итоге.

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

Сторипоинты. Системы премирования, мотивационные схемы. Перерасход людей

Алексей Рыбак: Хорошо, мы поговорили про эстимейты. И кто-то использует эстимейты, кто-то не использует, кто-то использует сторипоинты, кто-то не использует. Вопрос был: расскажите про детали использования сторипоинтов. Кто-нибудь может рассказать, что из себя они представляют? Как вы с ними работаете? Как происходит оценка через сторипоинты? Я так понимаю, что Никита делал.

Никита Прудников: У нас нет сторипоинтов. У нас пулятся карточки одинакового размера.

Алексей Рыбак: То есть мы примерно посчитали, что это недельная задача или на несколько дней задача, и мы просто оценили, что в неделю таких карточек команда может взять не больше пяти.

Никита Прудников: Это уже команда внутри делает. Скрам-мастер изобретает любой удобный ему процесс с командой, как ему удобнее ставить себе совместно с PO на следующую каденцию. Но обычно они ориентируются: Мы прикинули, вот сколько карточек. Обычно мы столько делаем.

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

Алексей Рыбак: Михаил, Сергей, у вас есть сторипоинты?

Сергей Кононенко: Есть, работаем по классике. То есть команда, planning poker, все дела.

Алексей Рыбак: Какие есть варианты сторипоинтов? Сколько: 1 2, 1 5, 1 48?

Сергей Кононенко: Обычно это исправленное Фибоначчи, то есть: 1, 2, 3, 5, 8, 10, 20.

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

Сергей Кононенко: Можно использовать все что угодно, главное, чтобы команде было комфортно квантифицировать свой got feeling сделаем или не сделаем, много или мало.

Алексей Рыбак: Понял. Что у вас, Михаил? Сторипоинты есть?

Михаил Юматов: Нет, у нас сторипоинтов нет, у нас часы обычные.

Алексей Рыбак: Окей, вопрос от Коли Крапивного. Что происходит, если при текущих приоритетах бизнеса какая-то команда оказывается перегружена, какая-то недогружена? Есть ли процесс ребалансировки? Если есть, то как часто за последний год менялись составы команд в связи с изменением нагрузки?

Сергей Кононенко: Мне, наверное, проще всего ответить. Никакой ребалансировки нет, потому что каждая команда отдельная структура, которая живет в своих реалиях.

Алексей Рыбак: Вопрос, мне кажется, задан больше в предположении, что какая-то есть в компании смесь между какая-то именно матрица, когда есть какая-то большая функциональная часть, у нее есть какие-то подчасти. Как-то побили, а потом оказалось, что побили неверно, потому что что-то куда-то навалилось. Если, с другой стороны, стримы продуктовые разбили изначально и достаточно жестко поделили, то кажется, что и такой ребалансировки быть не должно.

Алексей Рыбак: Следующий вопрос. Евгений Волк спрашивает. Как работают мотивационные схемы, система премирования, распределение премий между командами, внутри команд? Попробую по-другому задать вопрос. Тут получается так. Есть ли премии? Как часто? На команду или внутри команд? Сергей, давай с тебя начнем.

Сергей Кононенко: Да, мне, наверное, проще всего. Есть годовые премии, они выделяются на команду. Выделяются по определенной формуле, которая учитывает перфоманс банка, перфоманс команды, перфоманс группы, в которую входит Райффайзенбанк Россия. Внутри команды распределяется тоже по определенным формулам, в зависимости от конкретных сотрудников, ролей, которые они занимают, уровня их экспертизы.

Алексей Рыбак: Означает ли это?.. Сейчас, у меня тут уточнение. Что может быть? Может быть такая ситуация, что это распределение произошло почти автоматом, просто по грейдингу. Подходов к этому несколько, я просто пытаюсь понять. Один подход это когда согласно общему перфомансу выделился бюджет, который потом как-то раскидался. Это один подход.

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

Сергей Кононенко: У нас есть определенный бюджет, который из всех переменных складывается. И он по определенным формулам раскидывается по командам. Внутри команд это история, связанная с грейдами.

Алексей Рыбак: Понял. Михаил, как у вас?

Михаил Юматов: У нас, кроме повышения в рамках роста между грейдами или внутри грейда, нет никаких премий.

Алексей Рыбак: А как у вас в Mindbox, Никита?

Никита Прудников: Профшаринг.

Алексей Рыбак: Не понимаю, разъясни, пожалуйста.

Никита Прудников: Часть прибыли компании распределяется среди команд. Там тоже формула непростая: частично мы учитываем выручку продуктов или иногда рост выручки, если мы понимаем.

Внутри команд обычно рулит стейкхолдер, именно распределением ПШ. В некоторых командах полная демократия, они голосуют и как-то договариваются. В командах, в которых я больше заказчик, я стараюсь выделить себе какую-то часть, которую я сам распределяю, и часть распределяет сама команда. С одной стороны, чтобы учесть усилия, за которыми я не уследил, с другой стороны, у демократии есть плохая специфика, что она размазывает все. Если возник какой-то outstanding performance, в смысле долгосрочной ответственности, то он недостаточно премируется. И на этот случай я себе кусочек отжимаю и напрямую конкретным людям отдаю в своих командах.

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

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

Запускаем новый продукт и говорим: Ладно, мы продуктовая компания, нам нужна микрокоманда вокруг этого продукта. Кто нам для нее нужен? Очевидно, нам нужен тот человек, который будет делать фронт. Если мы делаем при этом какое-то мобильное приложение, значит, нам нужен и iOS, и Android. Нам нужен бэк, обязательно нам нужен QA, QA на все. Одного QA на такое количество людей мало. Ой, bus factor, давай по два. Ой, раз два, давай еще добавим QA. В результате команда разрастается.

Сталкивались ли с подобными вещами при планировании структуры? Как это решали? Наверное, в первую очередь вопрос, Сергей, к вам.

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

Алексей Рыбак: Но все-таки

Никита Прудников: Я, кстати, соглашусь, у нас похожая история. В смысле, мы стараемся

Алексей Рыбак: Но iOS разработка и бэкенд совсем разные.

Сергей Кононенко: Да-да-да, все правильно, поэтому у нас команды, которые прямо совсем full stack, допустим R-Mobile какой-нибудь, банковское приложение клиентское, там, пожалуйста и Java, и Scala, и Kotlin, и iOS, и базы данных, и DB2 чего там только нет. Но в момент один собирается по одному одному человеку из каждой экспертизы. А до конца года у них цель, чтобы каждый освоил еще две экспертизы.

Алексей Рыбак: Понятно. Михаил, что-нибудь можете добавить?

Михаил Юматов: Я немножко прослушал сам вопрос. Цель собрать команду, подсосать откуда или что?

Алексей Рыбак: Нет. Когда мы делаем новые направления, бывают команды, которые выпускают консюмерные продукты не в каком-то стриме большом, а например, игры делает или какие-то социальные приложения. Делают какие-то небольшие кусочки, эксперименты. И, когда запускается программа, команда, у которой есть мобильная история, веб-история, то у тебя появляется сразу же определенное количество мобильщиков, фронтендеров, QA. И команда сразу становится достаточно большой. Хотя кажется, что для того, чтобы выполнить такой проект, его можно было бы подмешать к какой-то другой команде, более большой, или нужно было бы выделять целую отдельную команду?

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

Да, действительно есть проблемы с тем, что, условно, разработчик iOS, он умеет только iOS. Есть у нас и мы поощряем это ребята, которые развиваются из С# во фронт, с фронта в Python, с Python в C#, и так далее. Но это, наверное, такие кандидаты, которых нужно как раз рассматривать для того, чтобы не раздувать ее.

Алексей Рыбак: Георгий снова тянет руку. Георгий, еще раз вас включу, и, наверное, это будет последний вопрос.

Георгий: Да, у меня есть еще два небольших вопроса. Первое насколько, как у CTO в организациях, ваши возможности ограничены? Что вы можете сделать, что нет? Какие-то есть у вас ограничения или нет?

И второй вопрос про команды. Есть у вас удаленные команды? Вы нанимаете только русскоговорящих или у вас есть иностранцы? Есть ли какие-то ограничения с этой стороны?

Никита Прудников: Кто готов ответить? Давайте я. Ограничение роли CTO. Учитывая специфику организации, в принципе, инициировать я могу любое решение, но оно должно быть мотивировано про пользу. Иначе будут несчастливые люди, процессы вето и дальше эскалация, если захочется через всю цепочку вето пройти до совета директоров или до голосования акционеров, если надо. Так любое решение могу принять, какое необходимо, главное, чтобы оно было мотивировано пользой. И главное уведомить про это решение людей, на которых оно повлияет. Если они окей с ним, то все, принято.

А про удаленные команды у нас сейчас нет. Нет опыта, и нет команд удаленных, вся локация в офисе.

Михаил Юматов: Про ограничения мне довольно сложно ответить. Тут, мне кажется, любое решение это будет, скорее всего, результат какого-то обсуждения, навряд ли я буду какие-то истории единолично принимать, но я не CTO.

Если говорить про удаленку, то мы нанимаем ребят со всей России. И планируем продолжить после локдауна и коронавируса оставаться на удаленке, мы и до этого так были.

Алексей Рыбак: Русскоговорящая?

Михаил Юматов: Да.

Алексей Рыбак: Окей, мультиязычных команд нет. Ещё быстрый вопрос. Ребята, когда последний раз писали код? Из YouTube вопрос.

Никита Прудников: Вчера.

Михаил Юматов: Сегодня. Но я должен оговориться, что это просто какие-то автоматизации своих

Алексей Рыбак: Понятно. Хорошо, ребята вышли уже даже за время, два часа пролетели. Спасибо вам огромное за эту встречу. Постарались ответить на все вопросы.

Еще раз спасибо огромное всем, кто поучаствовал, гостям. Тема нашего митапа была Управление разработкой в горизонтальных компаниях. Сегодня у нас в гостях были Никита Прудников из Mindbox, Михаил Юматов из Циан и Сергей Кононенко из Раффайзенбанка. Спасибо вам большое.

Если у вас остались вопросы, то можете задать их прямо под этим постом.

У нашего сообщества есть Фейсбук-группа Управление и разработка крупных IT-проектов и канал @feedmeto с интересными публикациями из корпоративных (преимущественно забугорных) техноблогов, и канал автора @rybakalexey про управление разработкой в продуктовых компаниях.

Подробнее..

Категории: Управление проектами , Конференции , Scrum , Управление персоналом , Управление продуктом , Управление разработкой , Управление командой , Циан , Mindbox , Cto , Райффайзенбанк , Performance review

Где работать в ИТ в 2020 Mindbox

17.12.2020 14:07:58 |

Автор: admin

Герой нового выпуска Где работать в ИТ платформа автоматизации маркетинга Майндбокс. На наши ~~каверзные~~ вопросы ответили технический директор Никита Прудников и директор по информационным технологиям Игорь Кудрин. Ребята рассказали об эволюционном развитии команд, о том, как нанимают спецов и какие условия работы для них создают. А ещё о том, что вся компания (а не только разработка) работает по принципам эджайла и самоуправления.

На Хабр Карьере сотрудники оценили Майндбокс на 4,6 из пяти, и у компании есть неплохие шансы попасть в наш ежегодный рейтинг лучших работодателей, который выйдет в начале следующего года.

Оценивайте своих работодателей на Хабр Карьере, чтобы поделиться мнением с теми, кто ищет работу в ИТ. Ваша оценка останется анонимной.

оценить компанию

Навигация по статье:

О Mindbox

Компания с 2006 года занимается автоматизацией маркетинга для электронной коммерции, ритейла и других B2C-компаний с десятками и сотнями тысяч клиентов. В 2020 году доросли до 115 человек, из которых половина разработчики.

Вы точно сталкивались с услугами Майндбокс, если делали покупки в издательстве МИФ, в Ситилинке, в аптеках Ригла, в Детском Мире или в Связном; ели в Burger King, Додо Пицце или KFC; брали машину или самокат в Делимобиле Список можно продолжать довольно долго ребята входят в десятку крупнейших SaaS-сервисов для бизнеса России.

Если посмотреть подробнее на оценку на Хабр Карьере, увидим три лидирующие качества, за которые сотрудники так любят Майндбокс: комфортные условия работы, профессиональный и карьерный рост. Вот ссылка на подробную оценку компании в 2020 году.

Текущая оценка Mindbox на Хабр Карьере

Про условия работы

Какой в вашей компании сложился рабочий график и какое отношение к переработкам?

Никита (технический директор): У нас свободный рабочий график: мы не следим за рабочими часами, а смотрим на результат. Начинать можно хоть в 8:00, хоть в 13:00. Главное, договориться с командой, чтобы была комфортная точка пересечения для статуса. Особенно на этапе онбординга, когда надо много коммуницировать с ведущими, иначе будет сложно влиться в команду.

Никита Прудников, CTO Mindbox

Игорь (директор по ИТ): Стратегически мы не одобряем переработки, потому что в итоге они приводят к снижению производительности у сотрудников хуже и им, и компании. Но бывает, что новичок ставит себе амбициозные цели или работа просто не идет в рабочее время, и в итоге человек старается нагнать вечером или в выходные. Такие переработки весьма логичны и хорошо стыкуются с принципом работы на результат.

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

Какие бытовые условия ждут нового сотрудника на рабочем месте?

Игорь: Мы стараемся создать комфортные условия: бизнес-центр класса А со Старбаксом, панорамное остекление с шикарным видом на Москву, свежий ремонт. Можно попросить стол с регулировкой высоты. Чай, кофе, сладости, закуски это само собой.

Игорь Кудрин, CIO Mindbox

У разработчиков есть выбор: топовый MacBook или Intel Core i7, i9 плюс монитор 4K, выдаем наушники с шумопоглощением. Покупаем нужный софт даже за рамками стандартного пакета. Еще из интересного есть игровой компьютер с беспроводным VR-шлемом HTC Vive Pro. Ребята собираются по вечерам и играют в SUPERHOT и прочие VR-игры.

Есть ли возможность удаленной работы?

Никита: Еще до пандемии на уровне инфраструктуры мы хорошо поддерживали удаленную работу. То есть у нас считалось нормальным, когда человек какое-то время работает из дома, потому что надо встретить курьера или он просто заболел: без больничного можно брать до трех дней. За время самоизоляции мы оборудовали Zoom Rooms: дают возможность собираться большими группами людей в одном месте и подключать удаленщиков, чтобы они видели нас, а мы видели их.

У каждой команды разработки своя комната

Сейчас у нас около 60% разработчиков работают удаленно. Процессы так построены, что, если ты разработчик, для работы достаточно Гитхаба. Доступ к пайплайну есть, не нужно сложных VPN, только двухфакторная авторизация включена для безопасности. Всё общение в Slack, Trello, Google Docs никакой почты и Microsoft офиса. То есть ты открываешь сайт, авторизуешься через Google и работаешь.

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

Какой социальный пакет получают сотрудники?

Игорь: У нас предусмотрено софинансирование обучения, спорта и лечения. В год выделяется 100 тысяч рублей на каждого сотрудника. И пока сотрудник их не превысил, компания оплачивает до 80%. После 100 тысяч процент падает, но не бывает такого, что этих денег не хватает. Еще у нас есть библиотека книги закупаются за счет компании, в том числе электронные

Какие бонусы, премии и компенсации предусмотрены в компании?

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

Какие есть перспективы для образования и личного развития у сотрудников?

Игорь: Сотрудник может пойти на любое обучение по профессии. У нас также есть целый перечень курсов по развитию софт-скиллов и против выгорания. Каждому разработчику составляется индивидуальный план обучения: там и курсы, и книги, и лекции на YouTube.

О найме в Mindbox

Во сколько этапов проходит найм и что на них ожидает соискателя?

Никита: Найм проходит в два этапа: техническое и командное собеседование. На техническом этапе мы проверяем пересечение между навыками кандидата и тем, что нам нужно. Пример вопроса на этом этапе: нужен ли индекс по гендеру в базе? Командное собеседование это проверка на соответствие ценностей кандидата и команды. В этот момент мы понимаем, насколько подходим друг другу.

Даете ли вы тестовое задание кандидатам? Как оно устроено?

Никита: Сейчас у нас нет технического задания, вместо него просто просим прислать пример кода.

Как отличается подход к найму в зависимости от позиции и стека?

Никита: Команды сами нанимают себе сотрудников и обычно сами размещают вакансии. Исключение C#, тут за найм отвечает CTO. В зависимости от уровня кандидата на собеседовании присутствуют либо только члены команды (для джунов и мидлов), либо дополнительно СТО (для синьоров и тимлидов). А если нанимаем тимлида, то перед этим прескриним его, чтобы понять опыт и ускорить собеседование.

Карта офиса Майндбокс

Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?

Игорь: Никакая, у любой фразы есть контекст. Но иногда бывает, что по каким-то признакам мы сразу понимаем, что кандидат не подходит. Например, если видим пренебрежение к деталям, безответственность. Если на вопрос о том, кто после его ухода будет поддерживать то, что он разрабатывал, кандидат отвечает: Мне плевать!. Но в любом случае мы стараемся провести собеседование до конца, просто потому, что человек дошел до этого этапа и потратил свое время. Идем дальше, пытаемся с разных сторон посмотреть.

Кого последнего вы уволили и почему?

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

Как происходит онбординг нового сотрудника?

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

О команде

Какая методология разработки у вас используется и почему?

Игорь: Смесь Scrum, Kanban с примесью всяких веселых штук в духе социократии. Мы регулярно находим новые идеи, интегрируем то, что кажется нам правильным, ошибаемся, пробуем дальше. Как и в любой компании, которая практикует гибкие процессы разработки, у нас микс из практик, уникальный набор процессов, которые мы сами вырабатываем. Работаем по спринтам, но это скорее отсечки, потому что у нас непрерывный роадмап.

Каковы размеры и структуры команд?

Никита: Восемь-десять человек разного уровня, от джуна до тимлида. Если говорить о структуре команды, то есть три ключевые роли: стейкхолдер, техлид / архитектор и скрам-мастер. Ни одна из них не является ролью начальника. В некоторых командах могут быть, например, два продакт-оунера, в некоторых SRE или фронтенд-разработчик.

Стейкхолдер отвечает за выручку продукта, над которым работает команда. Это, по сути, продакт-менеджер, который точно знает, что нужно рынку. Он управляет 70% бизнес-роадмапа команды и генерирует его.

Техлид (или архитектор) отвечает за надежность продукта команды и совместно со стейкхолдером работает над роадмапом. Помогает оценить технические риски, экономику, понимает, как масштабироваться дальше, формулирует оценки. Плюс, он детализирует истории до момента, когда они подъезжают к пулу команды, чтобы команда могла сама их запулить. Техлидом обычно становится член команды, который постепенно берет ответственность за части продукта.

Скрам-мастер отвечает за то, чтобы команда была функциональной. Улучшает процессы, чтобы команда предсказуемо и постепенно улучшала производительность. Эта роль выбирается командой.

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

По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?

Игорь: Формальной разбивки у нас нет, чаще всего подразумевается уровень ответственности за выпускаемые фичи и ожидания по зарплате. Мы оцениваем человека на собеседовании относительно рынка. И если он хочет зарплату больше, чем, по нашим оценкам, то мы готовы пойти ему навстречу, но с ожиданием, что через полгода он достигнет нужного уровня.

Кто чаще возглавляет команды продуктовый специалист или технический?

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

Офисная библиотека с книгами и настолками

Как часто люди меняют команды?

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

Что важнее, софт-скиллы или хард-скиллы?

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

Как много собраний у вас проводится? Есть ли особые подходы к ним?

Никита: Мы проводим еженедельные статусы и ежемесячные демо, где команда рассказывает, что сделано. Есть архитекторские встречи, потому что нам нужно много синхронизироваться между командами. Если ты просто код пишешь, тебя никто трогать не будет, но если ты хочешь расти, брать ответственность за какие-то куски продукта, то тебе придется чаще синхронизироваться на встречах.

Как вы боретесь с выгоранием сотрудников?

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

О технологиях

Какие языки, фреймворки и библиотеки используются на проекте?

Никита: .NET, С#. Фронтенд React. База данных на SQL (суммарно 50 ТБ баз под большой нагрузкой), Кассандра. Часть продакшена на наших серверах в одном из московских дата-центров, часть в Яндекс.Облаке. Соответственно, там .NET Core под Linux в Kubernetes-кластере. Инфраструктура: Terraform, Ansible. Deployment через Octopus Deploy + Helm 3. За мониторинг отвечают Prometheus, Grafana.

Что вы можете рассказать об архитектуре проектов?

Никита: Она крайне высоконагруженная и микросервисная: 300 тысяч бизнес-транзакций в минуту. Это сложные распределенные транзакции нескольких микросервисов. А базах данных у нас 20 тысяч транзакций в секунду в каждом инстансе. Внутри системы бизнес-событий у нас порядка 2 миллионов событий в минуту, отправляем полтора миллиарда имейлов в месяц. У нас очень сложный процесс надежности, чтобы поддерживать доступность 24/7 и при этом выкладывать новые изменения несколько раз в день на всех клиентов.

Какая у вас принята политика код-ревью?

Никита: Ревью добровольное, но в целом принято, что все просят друг у друга ревью. Процесс работы с бранчами у нас Trunk-based Development, то есть разработка в бранчах, но живут они меньше дня. Это хорошо укладывается в культуру ревью. Если попросишь большое ревью (+/- 1000) могут и отказать.

Как тестируется код?

Никита: Код тестируется автоматически: у нас пирамида тестов, порядка 20 тысяч. Они автоматически прогоняются на каждый коммит в каждом бранче, проходят за примерно 20 минут.

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

Как устроен процесс документации и ведения базы знаний на проектах?

Никита: У нас самодокументируемый код. Текстовую документацию стараемся писать только для критичных решений в виде ADR. Они хранятся в репозитории прямо рядом с кодом по строгому заведенному шаблону. Мы стараемся минимизировать количество текста, потому что текстовое описание имеет свойство быстро устаревать, так как не связано с кодом. Для клиентов Mindbox документация к API автогенерируемая, то есть создается автоматически под код.

Семейное фото команды

Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

Никита: 30% времени всех команд инвестируется в надежность, масштабируемость, поддержку и обновление кодовой базы. Архитектор совместно с командой решает, как приоритизировать, чтобы можно было дальше с прежней скоростью разрабатывать и масштабироваться. Команда напрямую вместе с архитектором управляет этой полосой. Бывает, что там едут рефакторинги, бывает что-то другое.

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

Оценивайте своих работодателей на Хабр Карьере, а если понравилась компания Майндбокс и хочется узнать о ней побольше пишите вопросы в комментах, мы призовем кого-нибудь из ребят отвечать.

оценить работодателя

Подробнее..

Категории: Управление персоналом , Карьера в it-индустрии , Блог компании хабр карьера , Хабр карьера , Карьера ит-специалиста , Mindbox , Где работать в it , Майндбокс

Из песочницы Data Science в обувном магазине предсказали поведение клиентов и увеличили конверсию сайта на 16

22.09.2020 14:11:12 |

Автор: admin

Российский производитель обуви Mario Berluchi автоматизировал маркетинг, внедрил привычные для интернет-магазинов механики, но не остановился на этом и запустил направление Data Science. Теперь магазин с помощью алгоритмов машинного обучения предсказывает действия клиента: что он сделает после добавления товара в корзину купит или уйдет, а если уйдет, то когда вернется.

Предсказание помогает в нужный момент побуждать клиента к покупке или, наоборот, не трогать его, если он купит и так. В рамках AB-теста механика персонализации сайта на основе предсказания помогла увеличить конверсию интернет-магазина на 16,5% и ARPU на 35,7% относительно контрольной группы.

Азамат Тибилов, директор по маркетингу Mario Berluchi, рассказывает о механике с предсказанием, измерении результатов, истории запуска направления Data Science и делится советами для интернет-магазинов, которые тоже хотят растить выручку за счет полезного и основанного на данных маркетинга.

Mario Berluchi российский производитель обуви, сумок и аксессуаров с пятью офлайн-магазинами в Москве и онлайн-магазином.

Масштаб. 200 тысяч посетителей сайта в месяц.

ИТ. Сайт на Bitrix, бэк-офис на 1С, платформа клиентских данных Mindbox.

Задача. Повысить выручку за счет работы с накопленными данными.

Результат. Рост конверсии сайта на 16,5% в рамках AB-теста, рост ARPU на 35,7%, снижение доли брошенных корзин на 17,2%.

Как работает механика персонализации сайта на основе предсказания

Когда клиент заходит на сайт, мы записываем его действия и прогоняем через алгоритм предсказания: купит в текущей сессии или не купит и вернется в течение 7 дней или не вернется. Предсказание пересчитывается раз в 10 секунд для каждого клиента.

Условия срабатывания механики:

если в корзине есть товары,
если не применен скидочный купон,
если по предсказанию вероятность покупки меньше 30%,
если по предсказанию клиент не вернется в течение 7 дней.

Если условия выполнены, клиент видит в корзине попап и решает, купить ли товар в текущей сессии или нет:

Попап всплывает в корзине, если по предсказанию алгоритма клиент в текущей сессии не оформит заказ и не вернется позже

Результаты механики с предсказанием

АB-тесты с достоверностью 95%

Часть клиентов в рамках теста находилась в контрольной группе и не видела попап для неё механика была отключена, а другая часть видела. Мы сравнили в этих группах конверсию, ARPU и долю брошенных корзин получили статистически значимые результаты с достоверностью 95%:

16,5%
Рост конверсии сайта относительно контрольной группы по методу t-test

35,7%
Рост ARPU по методу bootstrap

17,2%
Снижение доли брошенных корзин по методу z-test

Сравнение конверсий и ARPU: в мае 2019 и мае 2020 после внедрения механики с предсказанием

Конверсия до и после внедрения механики с предсказанием

ARPU до и после внедрения механики с предсказанием

Зачем запустили направление Data Science

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

Для сквозной аналитики было необходимо собирать данные о поведении пользователей в базу Google BigQuery. Помимо стандартных действий пользователей добавления товара в корзину, посещения продуктовой карточки товара, совершения покупки мы собирали еще много действий с контентом сайта хитов. Ежедневно накапливалось более 20 тысяч строк хитов, и эти данные у нас хранились в базе, за которую мы, конечно же, платили.

При нашем трафике более 200 тысяч пользователей в месяц было достаточно данных, и мы проводили стандартную аналитику, например действий пользователей с контентом после каких-либо изменений, покупок после проведения акций. Потом провели брейнсторм с владельцем компании и решили попробовать помимо простой аналитики и AB-тестов построить что-то более интересное: попытаться предсказывать поведение клиентов на сайте с помощью алгоритмов машинного обучения на наших исторических данных. К таким идеям мы относимся как к внутреннему продукту, в который готовы вкладывать деньги и время, чтобы потом получить результат рост бизнес-метрик.

В итоге собрали отдел Data Science и за полгода реализовали механику с предсказанием действий пользователя, которая повысила выручку. Таким образом мы открыли для себя новое направление бизнеса, которое приносит нам более 30% выручки и хорошо окупается.

Какие специалисты понадобились для Data Science

Каждый этап запуска механик с предсказанием подразумевает работу специалистов разных по функционалу, но из смежных областей. В штате у нас:

Аналитик. Анализирует данные, находит аномалии и проводит AB-тесты.

Два специалиста Data Science. Пишут алгоритмы, которые возвращают ответы-предсказания в виде вероятности того или иного действия пользователя на сайте.

Маркетолог. Разрабатывает и запускает механики с применением алгоритмов.

Разработчик. Внедряет механики и алгоритмы на сайте.

Как технически устроена механика с предсказанием

1. Размечаем исходные данные Google Analytics с помощью Google Tag Manager и используем стриминг OWOX BI для сбора данных в базе Google BigQuery. Эти шаги занимает мало времени с первой минуты можно видеть, как данные укладываются в базу.

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

3. Специалисты Data Science создают признаки (feature engineering) из визитов и контента, например количество просмотренных товаров, количество добавлений товаров в избранное, количество добавленных товаров за сессию в корзину.

Распределения весов признаков алгоритма на их основе предсказываем поведение клиента

4. Обучаем модель на исторических данных. Допустим, мы хотим предсказывать, будет ли у пользователя следующий сеанс или вернется ли он к нам в течение 7 дней. Для этого берем исторические данные, признаки и реализуем алгоритм. Для предсказания мы используем классификацию биномиальный ответ в виде 1 или 0.

5. Валидируем модель на исторических данных: точность прогноза, бизнес-метрики.

Прежде всего мы смотрим на долю accuracy (долю правильных ответов) и ROC-AUC (площадь под кривой ошибок):

Accuracy (доля правильных предсказаний) 0,88 говорит о том, что в 88% случаях мы точно предсказываем, что пользователь вернется или не вернется. Precision (точность) о том, какая доля предсказаний, что пользователь вернется, оказалась правильной. Recall (полнота) о том, какую долю реальных возвращений мы предсказали.

AUC ROC (площадь под кривой ошибок) используем для оценки качества работы алгоритма на выборке данных

Помимо ответов алгоритма 1 и 0 есть еще вероятность действия в процентах. И здесь мы задаем порог: если вероятность возврата пользователя более 30% и такие пользователи чаще всего действительно возвращаются, то ответ 1.

6. Прогнозируем действия пользователя.

7. Маркетолог разрабатывает механики для применения прогноза.

8. Запускаем АB-тест только на новых пользователях, которые познакомились с нашим сайтом прямо сейчас. Тест длится около трех недель, и в течение этого времени мы смотрим, как меняется накопительный p-value. В какой-то момент разница между группами становится значимой, понимаем, что скоро тест можно завершать и выкатывать механику в продакшен.

9. Аналитик измеряет результаты механики.

На основе каких клиентских данных работает предсказание

Visit-based. На основе действий на сайте: просмотр карточек товаров, добавление товаров в корзину, покупки.

Content-based. На основе действий с контентом сайта. Сначала собираем данные о действиях пользователей: открытие таблицы размеров, добавление товара в избранное, чтение отзывов. Затем смотрим, как эти действия влияют на прокси-метрики (промежуточные конверсии до заказа) это нужно, потому что данных по этим метрикам больше, чем заказов. Затем смотрим корреляцию прокси-метрик с показателями конверсий в покупку и возвратов.

Подходы visit based и content based пересекаются. Но в visit based мы оцениваем поведение пользователя, а в content based сам контент.

CRM-based. Обогащение данных из CRM интернет-магазина, учет истории покупок.

Советы интернет-магазинам

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

2. Рост конверсии, ключевой метрики интернет-магазина, самый сильный фактор развития вашего бизнеса.

3. Не бойтесь строить инфраструктуру и внедрять новые технологии в ваш бизнес. Внедрение машинного обучения позволяет сделать шаг вперед и уйти в отрыв от конкурентов.

4. Научитесь считать ROI от инвестиций в новые технологии. Большинство компаний боятся выделять бюджет на новые инструменты, потому что не совсем понимают, какую выгоду они получат.

Дальнейшие планы по развитию маркетинга

Сейчас у нас в работе динамическое ценообразование мы будем оценивать, когда на какой товар дать скидку или, наоборот, не дать. Звучит всё просто: товар часто покупают не даем скидку, редко покупают даем. Но мы подходим чуть глубже и шире смотрим, где этот товар находился в каталоге, в каких маркетинговых механиках участвовал, сколько раз этот товар просматривали, сколько раз добавляли в корзину.

А следующий шаг динамическое ценообразование для каждого пользователя.

Как повторить механику с предсказанием в вашем интернет-магазине

Мы развиваем сотрудничество с Mindbox и предлагаем клиентам платформы внедрить нашу механику с предсказанием. Если хотите повторить в вашем интернет-магазине пишите коллегам.

***

Авторы:
Азамат Тибилов, директор по маркетингу Mario Berluchi
Мария Байкаускас, менеджер Mindbox
Сёма Сёмочкин, редактор Mindbox

Подробнее..

Категории: Machine learning , Data science , Data engineering , Mindbox , Mario berluchi , Cdp

	Русский
	English

Mindbox

Открыт набор в Школу разработчиков с перспективой стажировки в Mindbox

Как появилась идея Школы разработчиков Mindbox

О Школе разработчиков Mindbox

Чему и как обучаем в Школе

План занятий

Расписание занятий

О преподавателе (то есть обо мне)

Как попасть в Школу

О стажировке в Mindbox

О трудоустройстве в Mindbox

Советы начинающих разработчикам от нашего CEO

Интеграция интернет-магазина на 1С-Битрикс с Mindbox

Предыстория

Методы интеграции с Mindbox

JavaScript SDK

Интеграция по API

Комбинированный метод

Схема взаимодействия модулей

Базовый

Модуль очередей

Модуль интеграции с Mindbox

Подводя итоги

Управление разработкой в горизонтальных компаниях расшифровка онлайн-встречи. Часть 2

Гости

Темы второй части

Чем leadership внутри плоской команды отличается от менеджмента. Как решаются вопросы безопасности. Technical excellence. Решение конфликтов

Открытые зарплаты: какие от них плюсы. Рыночные зарплаты, воронка кандидатов. Описание задач

Как решаются вопросы безопасности

Как в горизонтальных компаниях шарятся ресурсы. Performance Review. Как техлиды оценивают разработчиков не из своего стека

Сторипоинты. Системы премирования, мотивационные схемы. Перерасход людей

Где работать в ИТ в 2020 Mindbox

О Mindbox

Про условия работы

Какой в вашей компании сложился рабочий график и какое отношение к переработкам?

Какие бытовые условия ждут нового сотрудника на рабочем месте?

Есть ли возможность удаленной работы?

Какой социальный пакет получают сотрудники?

Какие бонусы, премии и компенсации предусмотрены в компании?

Какие есть перспективы для образования и личного развития у сотрудников?

О найме в Mindbox

Во сколько этапов проходит найм и что на них ожидает соискателя?

Даете ли вы тестовое задание кандидатам? Как оно устроено?

Как отличается подход к найму в зависимости от позиции и стека?

Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?

Кого последнего вы уволили и почему?

Как происходит онбординг нового сотрудника?

О команде

Какая методология разработки у вас используется и почему?

Каковы размеры и структуры команд?

По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?

Кто чаще возглавляет команды продуктовый специалист или технический?

Как часто люди меняют команды?

Что важнее, софт-скиллы или хард-скиллы?

Как много собраний у вас проводится? Есть ли особые подходы к ним?

Как вы боретесь с выгоранием сотрудников?

О технологиях

Какие языки, фреймворки и библиотеки используются на проекте?

Что вы можете рассказать об архитектуре проектов?

Какая у вас принята политика код-ревью?

Как тестируется код?

Как устроен процесс документации и ведения базы знаний на проектах?

Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

Из песочницы Data Science в обувном магазине предсказали поведение клиентов и увеличили конверсию сайта на 16

Как работает механика персонализации сайта на основе предсказания

Результаты механики с предсказанием

АB-тесты с достоверностью 95%

Сравнение конверсий и ARPU: в мае 2019 и мае 2020 после внедрения механики с предсказанием

Зачем запустили направление Data Science

Какие специалисты понадобились для Data Science

Как технически устроена механика с предсказанием

На основе каких клиентских данных работает предсказание

Советы интернет-магазинам

Дальнейшие планы по развитию маркетинга

Как повторить механику с предсказанием в вашем интернет-магазине

Категории

Последние комментарии