Привет! Хочу поделиться практическим опытом реинжиниринга нашей системы под названием «Портал поставщика» – рассказать о том, как мы выстроили процесс работы в команде, как наладили общение с бизнесом, какие поймали подводные камни и какие удалось выработать интересные решение. А ещё поговорим об особенностях китайского менталитета.

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

Так как преобладающее большинство поставщиков у нас иностранное (а в большей ее части — китайское), то и пользователи у нас в большинстве своем китайские.

Преамбула

Думаю, многие из вас сталкивались с тем, что вам в руки попадала какая-нибудь MVP-система с большим количеством legacy-кода или другими подобными вариациями, которые делались под лозунгом «Давай сейчас как-нибудь сделаем, чтобы работало, а потом разберемся».

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

Расскажу о том, как нам удалось сломать этот порочный круг костылей и как мы выбрались в более или менее стабильную и качественную систему с комфортным масштабированием.

Получение системы

На момент запуска Портала у нас был план — обеспечить стабильную работу для 400 поставщиков. Сейчас мы уже перевалили за эту цифру, сложность оказалась в том, что у нас более одного бизнеса: как минимум, мы делимся на Спортмастер и O’STIN, а у каждой из этих систем более одного источника данных. То есть у нас большая интеграционная часть, около 4 источников, минимум 3 потребителя — логистические, документационные и финансовые системы. На момент запуска планировалось 3 полноценных функционала, сейчас мы уже добрались до цифры 10, то есть бизнес-процесс растет, и мы автоматизируем как можно больше частей.

Но что же нам досталось на старте?

А досталась нам неоптимальная система GWT (Google Web Toolkit). Я не настоящий разработчик, так что не буду спорить насчет того, оптимальный ли этот фреймворк сам по себе или нет, но вот то, что у нас получился абсолютно интуитивно непонятный интерфейс — это было ясно как белый день. Никто не думал о том, как должно быть удобно. Все думали о том, что нужно сделать, чтобы сюда перейти и получить какой-то результат.

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

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

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

И не менее важная составляющая, менталитет — у китайского пользователя он построен совсем по-другому. Китайцы никогда не признаются, что не понимают чего-то, не допустят ситуации, когда могут «потерять лицо». Обучение проходили по видеосвязи, само собой, тогда все они говорили, что всё поняли. А затем все основные вопросы прилетали на обезличенную поддержку.

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

Как бы то ни было, пилот себя оправдал, так что систему нужно развивать дальше. Однако по обозначенным выше причинам это становилось все более и более проблематично. Поэтому было принято решение переехать на новые технологии. Стартовая задача звучала как «Перенесем все как есть и дальше будем разбираться». 4 раза мы пытались так и сделать — то архитектура ломалась, то мы договориться не могли, то еще какие-то проблемы вылезали. ТЗ постоянно переписывалось, а проблемы не решались.

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

Знакомьтесь, попытка №5.

Выбор «Мыслителя»

Хочется начать с чего-то более абстрактного, но при этом очень важного — с выбора мыслителя

Мыслитель в моем понимании — это тот участник команды, который ведет основную линию идеи

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

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

Моя идея в том, что должен быть выбран один основной человек в команде — «Мыслитель».

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

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

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

PS Если вы никогда не проводили в команде «Тест Белбина», то попробуйте. Мы проводили его уже не раз, вы сможете понять, кто вы, какой участник команды какое место на самом деле занимает: кто чаще фантазирует, кто больше задач доводит до конца, кто более ответственно относится к вопросам, кто дотошный, кто не очень. В общем, сможете оценить, подходит ли ваша команда для проведения пилотов, или вы больше для стабильной разработки по требованиям.

Инциденты

После выбора мыслителя мы приступили к сбору больных мест нашей системы, чтобы понять, что же нам нужно починить или выпилить на самом старте

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

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

Все это сложили в две кучки.

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

Третье — проанализировали все, что мы получили, и разделили на две группы:

1.  Технические проблемы

2.  Бизнесовые ограничения

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

После ряда плодотворных встреч где-то обновился бизнес-процесс, какие-то ограничения стали мягче, а какие-то и вовсе ушли

К примеру:

Пользователи портала поставщика всю свою отгрузку формируют в рамках «Грузовой партии». Данный объект получает при создании маршрут, который в дальнейшем не может быть изменен пользователем. Но переброс груза на новый маршрут, ввиду разных обстоятельств, достаточно частая история.

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

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

После этого ограничение было снято и мы добавили эту возможность в реинжиниринг, чем упростили жизнь поставщику и сняли нагрузку в лице 189 инцидентов с поддержки

Выделяя промежуточные плюсы из вышесказанного:

1.  Наличие «Мыслителя» помогает не потерять связи разрабатываемого функционала и уменьшить хрупкость системы

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

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

Процесс

Выше я писал, что надо выбрать мыслителя, пускай один человек ведет всю линию, а все остальные — боком. Может возникнуть вопрос: «Это же узкое место, так не делают, это неправильно. Зачем?». 

На самом деле скорее нет, чем да!

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

Это как продажа идеи — ты тренируешься на кошках, а потом уже продаешь это бизнесу. 

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

Техническая декомпозиция

Этой штукой хочется искренне гордиться. 

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

Потом доходит до середины ТЗ и вдруг «А я не понимаю, что это такое». Идет к аналитику, задача зависает, идет в ожидание, соседние системы недовольны, все недовольны.

Техническая декомпозиция выглядит так: мы собирали встречу, на которой выносилась задача, на ней был аналитик, тестировщик и участники разработки с каждого слоя, то есть БД, Rest, UI.

За несколько часов декомпозировали весь сложный функционал.

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

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

В чём плюсы?

Аналитик может сразу ответить на две трети бизнес-вопросов, которые есть у разработчика, зафиксировать какие-то сложные вопросы и ответить на них после (сходив с ними к бизнесу), освежить в голове команды, как это должно работать.

Когда аналитик слушает, что придумали разработчики, он может ребят остановить и сказать: «Вы не туда пошли, не надо» или «Вот этого кейса никогда в жизни не будет». 

На выходе получается, что, когда задача уходит в поток на разработку, у разработчика уже в принципе не бывает бизнес-вопросов, не бывает блокеров, не бывает застревания задачи. Максимум, что они могут спросить: «Слушай, вот здесь вот в логике, если выскочит эта ошибка, какое уведомление мне показать или что мне сделать?». Ответ занимает 5-10 минут, максимум — час.

Презентации и прототипирование

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

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

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

Как пример: на одной из презентаций, когда мы показали прототип бизнес подумал, что мы уже сделали сайт ????

Минимальный выбор

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

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

Локализация

Один из немаловажных аспектов.

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

Инструкции

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

Мы разбили инструкции на отдельные подтемы:

• Как работать со списком,

• Как использовать блок фильтров,

• Как работать с объектом,

• Как написать запрос на изменение.

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

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

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

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

2.  Техническая декомпозиция убирает недопонимания, застревания задач в процессе, всем разработчикам, тестировщикам, аналитикам понятен бизнес-процесс. 

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

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

5.  Большую инструкцию заменили на мелкие и понятные инструкции, которые просто найти и прочитать / посмотреть. Такой подход упрощает жизнь пользователям и поддержке.

Итоги

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

Автоматизировали все, до чего смогли дотянуться.

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

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

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

Мы облегчили нагрузку на поддержку, это была моя головная боль.

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

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

Вот так мы ее переделали, как видите, больше ничего нигде вводить больше не надо, он просто нажимает «Создать», мы все посчитали за пользователя.  

Для такого расчёта нам не хватало одного параметра. Мы просто сходили к бизнесу и спросили: «А не хотите нам его отдать?».

Они ответили: «А мы вам его уже отдаем, вы не берете, оказывается». 

Соответственно, мы его быстренько забрали, и вся калькуляция сразу заработала. Два клика, 30 секунд вместо 2,5 минут — очень хорошее ускорение. 

Вот так выглядел старый список грузовых партий.

А так выглядит новый.  

В общем, не бойтесь меняться, не бойтесь экспериментировать и внедрять что-то новое.  

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