От аутсорсинга до in-house, или От обычной драмы до довольных разработчиков30.09.2021 17:16

3e1f78271fbac463c49fb3208dc0c3cc.jpg

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

Если вы задумываетесь о том, чтобы перевести разработку и внедрение с аутсорсеров в in-house (или наоборот!), приглашаем под кат. Если же вы разработчик и рассматриваете предложения от интеграторов и скучного enterprise, то тоже сможете почерпнуть из этой истории что-то полезное.

Как выглядит IT-ландшафт компании средних размеров, в ДИТе которой работает 100 айтишников? Имеется два десятка IT-систем, которые внедрялись разными интеграторами и теперь ими поддерживаются. Внутренний IT-отдел — скорее админы, чем разработчики, а вся собственная разработка сводится к тому, чтобы прописывать эндпоинты и форматы выгрузок (и обмена данными во всех этих системах). Так было и у нас. Работа была довольно скучная, и потому наблюдалась текучка айтишников, которая чем дальше, тем дороже обходилась компании. 

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

Из всего обилия систем в ДИТ ВТБ Лизинга хочется рассказать про АСССК — автоматизированную систему службы сопровождения клиентов и корпоративную CRM-систему, с которой все и начиналось.

Дела давно минувших дней, преданья старины глубокой

Исторически первой была CRM-система на базе Microsoft Dynamics CRM 2011, которая внедрялась и потом обновлялась до актуальных версий нашим партнёром-интегратором. Основную работу он делал сам, а нашим IT-специалистам доставалась довольно скучная роль обслуживающего персонала: работа на подхвате, какие-то мелкие правки, обеспечение интеграций с другими системами, работа с документами. Сказать, что это не нравилось нашим коллегам, значило бы существенно преуменьшить их недовольство.

Весь процесс создания и доработок систем проходил стандартные этапы, которые должны были помочь попасть в срок и ожидания заказчиков, но это не срабатывало:

  • сбор требований;

  • написание ТЗ;

  • фиксация ТЗ;

  • расчёт стоимости работ;

  • подписание договоров;

  • календарное планирование;

  • реализация;

  • приемка;

  • подписание закрывающих документов.

Ситуация осложнялась тем, что за время ведения проекта, разумеется, появлялись различные корректировки требований и все новые ожидания…

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

Чтобы хоть как-то изменить этот печальный тренд, было решено перейти с фиксов (контрактов с фиксированной стоимостью) на T&M (время и материалы) с оплатой рабочего времени сотрудников подрядчика. Так перенесли управление проектами из зоны ответственности интегратора в нашу. Это же дало возможность распоряжаться временем сотрудников подрядчика, в рамках постановки целей и задач. Стало легче, но незначительно: накопленных проблем всё равно было слишком много. Несмотря на изменение условий договора мы замечали, что качество работы внешних сотрудников было не на высоте. Приходилось терпеть и тащить эту историю дальше. Стоимость и сроки внедрения новых функциональных возможностей росли в арифметической прогрессии. Возрастала и стоимость сопровождения: технический долг увеличивался, и под нагрузкой CRM работала всё менее и менее надёжно. Сбои во время работы и многочисленные дефекты после каждого релиза стали нормой жизни.

И этому нашлось объяснение. Вот немного откровений от Виктора — руководителя проектов, который перешёл из штата нашего контрактного подрядчика к нам в in-house:

Откровения Виктора

»Консалтинг подписывается практически на всё. Платите деньги — и мы сделаем всё, что вы хотите! А о том, что какие-то разработки при масштабировании вызовут проблемы, на этом этапе никто не думает. Проектирование идёт, чтобы выполнить задачу на будущий год. Без учёта возможного роста числа пользователей в 2–3 раза или увеличения количества данных. В итоге данные не смогут обрабатываться не потому, что там недостаёт аппаратной части, а из-за проблем в самой системе. Потому что сделанное не сможет быстро перевариться. Многие вещи, которые считаются моветоном среди разработчиков, будут использованы в угоду скорости. К примеру, есть руководитель проекта, и он говорит: надо сделать в этот срок этот релиз только потому, что у нас мало задач, которые мы сможем сдать в этот период и закрыть актами.

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

Когда находишься во внутренней команде, гораздо проще исправлять ошибки. Проще решать, что нужно взять в спринт; даже если он уже идёт — окей, давайте мы в него ещё вот это добавим. А если сроки чуть-чуть съедут в следующий спринт, то и этот вопрос решить проще, чем при работе с внешним подрядчиком».

Свой продукт с блэкджеком и сегментацией

Во время изучения очередного пула задач от службы сопровождения клиентов мы подумали, что можно сделать отдельную от большой CRM систему АСССК, предназначенную только для этого направления бизнеса. Уровень неопределённости на начальном этапе был большой, и именно поэтому реализовывать систему по Waterfall’у было странно, но начали делать именно так. 

Несмотря на то что формально предлагалось создать и внедрить ещё один продукт в том же сегменте, предполагаемые плюсы этого решения перевешивали недостатки:

  • вместо большого и дорогого комбайна со всеми опциями по максимуму, которым являлась CRM-система, — конкретное решение под определённого заказчика;

  • вместо привязки к релизам и доделкам большого продукта — независимые обновления и минимизация зависимостей частей системы друг от друга;

  • вместо большой и хрупкой системы с множественными связями и сотнями потенциальных точек отказа — небольшая.

Что же, финалист определён, новый контракт подписан: новый проект для АСССК, новый интегратор и даже новый стек (с Microsoft Dynamics CRM — DotNet, MS SQL, вот это всё — мы планировали перебраться на 1С). В общем, всё по-новой…

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

Мы всё переосмыслили

В этот момент мы поняли, что waterfall точно не подходит и налицо все «признаки Scrum’a». Антикризисным решением стало создание своей команды разработки, которую на первых порах усиливала команда интегратора. Это решение должно было обеспечить безопасность компании и увеличить скорость внедрения изменений. Одновременно с этим — привить новую культуру, которая позволила бы достичь высокого уровня взаимопонимания между разработчиками и стейкхолдерами.

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

Где фактура, Лебовски?

Кто-то скажет:, а где фактура? Даты, сроки, имена? По понятным причинам названия интеграторов указать здесь я не могу, зато могу сказать про сроки и этапы. Сравните: компания, взявшаяся за написание АСССК, чуть больше чем за полтора года смогла сделать только часть функциональных модулей. При том, что этот срок выделялся на весь проект! Когда нанимаешь интегратора, имеешь довольно высокие, но справедливые ожидания: все необходимые компетенции для нужд проекта, возможность гибко управлять количеством людей на проекте, большой и разнообразный опыт (не только технологический, но и продуктовый), но самое главное — выполнение задач в срок. Увы, все преимущества интегратора не смогли помочь в реализации последнего, но самого важного ожидания.

После того как мы провели Agile-трансформацию проекта, появился владелец продукта. Мы начали нанимать людей в октябре 2020 года и укомплектовали команду к маю 2021 года. Размер собственной команды составил пять человек плюс пара работников от компании-подрядчика. Сегодня подрядчики участвуют только в сопровождении и баг-фиксинге продукта.

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

Отзыв продакт-оунера Влады

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

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

Ещё хочу отметить бережное отношение команды к продукту. Несмотря на то, что есть сроки, команда старается сделать всё аккуратно, без костылей. И это правильно: нам не просто нужно сдать продукт к сроку (как, например, бывает с подрядчиками), но ещё и поддерживать его в будущем. Поэтому чем качественнее получится продукт сейчас, тем легче нам будет дальше работать над его развитием и поддержкой».

Итогом внедрения второго этапа стал отзыв ключевого заказчика Сабины:

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

Опыт успешного внедрения собственной продуктовой команды на этом продукте положил начало преобразованию компании. Глядя на нас, другие бизнес-юниты тоже захотели реализовывать свои системы именно с помощью in-house разработки. Вместо тяжёлого и неповоротливого монолита мы идём к IT-ландшафту, который будет естественно повторять оргструктуру компании. Вдобавок интересные проекты дают второе дыхание сотрудникам и упрощают наём кандидатов, что критично в условиях постоянного расширения нашего бизнеса. Мотивация тех людей, которые перешли к нам работать из команд подрядчиков, выросла, и теперь задачи стали интереснее, появилась возможность создавать «от» и «до» действительно крутые продукты и видеть, как они приносят пользу клиентам. Больше дела, меньше бюрократии. Больше гибкости в принятии решений. Лучшая проработка и проектирование решений — ну, а какой разработчик не любит проектировать и создавать по-настоящему хороший продукт? Так, несмотря на отсутствие магической «шкатулки» с людьми и компетенциями, своя команда смогла сделать то, что не смог сделать подрядчик.

Как ни посмотри, вовремя принятый на себя риск открыл новые возможности и для компании, и для её работников. Так что можно считать, что эта история закончилась успехом. А был ли у кого-то из вас подобный опыт? Расскажите в комментариях!

© Habrahabr.ru