1

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

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

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

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

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

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

2

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

Методология

Ее сформировали, отталкиваясь от ряда критериев:

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

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

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

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

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

Аспекты организации работы

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

Дальнейшее использование двух систем оказалось явно лишенным практического смысла, и эксперты приняли решение прекратить эксплуатацию Битрикс24. Данную систему сохранили только для отслеживания данных по клиенту внутри компании. Все процессы в русле разработки интернет-магазина были сосредоточены в YouTrack, где исполнители применяли Канбан и пользовались приоритезацией по задачам. Одновременно с этим оформлялась ежедневная отчетность в Google-таблицах. Разработчики рассчитывали в своей отчетности прогресс решения задач в процентах, а также предоставляли статистику по плановым и реальным затратам человеко-часов.

3

Итоги

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

Говоря об итоговой экономии для заказчика с учетом его трат на внутренних специалистов, то компания смогла сберечь порядка 50% на контракте с аутсорс-командой.