Стартап внутри корпорации

    Привет, меня зовут Андрей Ванин и я занимаюсь разработкой и запуском брокерских и финтех-продуктов. Сегодня ровно год как я работаю в БКС, где в команде из восьми человек мы развиваем проект fintarget.ru.

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

    image

    Intro


    Забудьте про все Agile-манифесты и создание комфортной рабочей среды, если вы хотите добиться результата. В управлении безнадёжными проектами на первый план выходят не наличие в офисе PlayStation и обязательность scrum ритуалов, а амбиции и личная мотивация команды.

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

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

    На старт


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

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

    Но был озвучен срок – выпустить в сентябре. И мы сели работать.

    Двойной Pivot


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

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

    image

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

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

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

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

    О команде


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

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

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

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

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

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

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

    В-четвертых, мы (вынужденно) жестко разграничили функционал разработчиков. На каждый сектор был выделен отдельный разработчик-«микросервис», который отвечал только за свой сегмент. Таких сегментов у нас в проекте пять: интеграция с внутренними системами, интеграция с биржевыми системами, продуктовые алгоритмы ядра, OpenAPI и фронт.

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

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

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

    Первого августа у нас было собрано ядро системы, проведены практически все подготовительные работы, собрана бета-версия OpenAPI, нарисован и сверстан фронт и оставалась еще неделя, чтобы отшлифовать алгоритмы и дождаться выхода на работу фронтендера, который должен был «всего-лишь» собрать всё это в работающий MVP.

    Деревья событий


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

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

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

    Подробности этой истории заслуживают отдельной статьи, но ключевое, чего удалось добиться состоит из нескольких пунктов:

    1. Интегрируясь с боевыми контурами мы исключили проблемы синхронизации тестовых сред смежных систем. Когда твой процесс линейно завязан на цепочку «фронт – бэкенд – crm– бэкофис – интеграционная шина – бэкенд – фронт», а тестовые среды реализованы так, что не умеют взаимодествовать между собой, вариантов тестирования продукта остается не так уж и много
    2. Тестирование на собственных деньгах на каком-то подсознательном уровне включает кнопку управления рисками и не только продакт спрашивает «а что если что-то пойдет не так», но и разработчик видит процесс «как клиент» и осознает стоимость бага в денежном выражении.
    3. Подход тестирования на «препроде» кратно повысил вовлеченность разработчиков, позволил проверить UX на практике еще до выпуска продукта во внешний мир и, главное для проекта, отладить корректность работы алгоритмов системы на реальных рыночных и клиентских данных.


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

    image

    Что в итоге


    Работающий MVP проекта был собран в конце августа, параллельно была реализована версия эмулятора для аккредитации программы в НАУФОР и написано полторы сотни страниц сопроводительной документации для регистрации ПО. Первые реальные сделки по системе под радостные крики команды прошли 31 августа. Юридические изменения в документы компании и клиентские регламенты вступили в силу с первого сентября, и до аккредитации системы у нас оставалось время на отладку и вылизывание интерфейсов.

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

    17 сентября ПО Fintarget было внесено в реестр аккредитованных программ автоследования, и уже на следующий день мы увидели первых подключающихся к системе клиентов. Впереди было еще много работы над расширением функционала и доведением MVP до состояния полноценного и самодостаточного продукта, но это уже совсем другая и менее интересная история: релизы, спринты, бэклоги и бесконечная клиентская аналитика.
    BCS FinTech
    Компания

    Комментарии 3

      0
      Звучит все это очень круто, но непонятна мотивация на действия типа: «ходить по головам и решать любую задачу».

      Мотивация в обычном стартапе мощна и глобальна — получить сверхприбыль, осчастливить человечество, стать широко известным. Ради этого многие готовы не спать ночами и проч.

      Зачем «ходить по головам» в рамках ФГ БКС?

        0

        Было интересно прочитать про историю развития стартапа)) спасибо за статью.

          0
          Спасибо, хороший материал! Примерно представляю, как это всё у вас происходило, уверен, в реальности было еще интереснее, чем описано в тексте :-)

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

          Самое читаемое