Всем добрый день!

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

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

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

Если вы не читали статью про базовую автоматизацию, то советую сначала прочитать ее.

Анализ результатов работы с базовой автоматизацией

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

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

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

Из распространенного:

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

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

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

Преамбула

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

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

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