Преемственность продуктов

Преемственность продуктовКолесников Степан

Степан Колесников @karakazyablek

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

Поехали!

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

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

"А как же с преемственностью программных продуктов" - скажете вы мне. Откуда я что-то знаю про неё? Минуточку терпения. Сейчас расскажу.

Всё началось 4 года назад, когда я пришел в компанию 2ГИС разработчиком на единственный на тот момент внутренний продукт в компании. Продукт был довольно большим: сотни тысяч строк кода на плюсах и десятки тысяч строк на VBA. Тогда мне казалось, что количество времени и сил, которые разработчики разных поколений вложили в разработку этого продукта сопоставимо с ресурсами на постройку Саяно-Шушенской ГЭС

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

Я успел побывать на обеих сторонах барикады. Я участвовал и в строительстве нового мира с новыми программными продуктами

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

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

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

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

Вывод первый:смена продуктов должна быть своевременной.

Здесь появляется первый вывод

Начинайте думать о преемнике, пока ваш старый добарый продукт ещё не впал в коматоз

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

Но мы подумали о преемнике вовремя и начали думать, как нам разрабатывать новый продукт. У нас было 2 варианта. Первый из них - обратиться к системным интеграторам. К счастью, они запросили слишком много и мы решили делать всё своими руками.

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

Вывод второй:знай чего хочешь до того, как написана первая строчка кода

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

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

Хотя для того, чтобы узнать больше, нужно уметь очень немногое: правильно задавать вопросы.

Правда, не очень понятно, какие именно вопросы разработчики новой системы могут задать программистам из старой. На самом деле это зависит от того, насколько должны быть похожи старая и новая системы. Стоит обязательно поговорить про:1. Глоссарий. У 2-х команд возникнет гораздо меньше трудностей в общении и в интеграции, если разработчики из разных команд будут оперировать одними и теми же терминами2. Часто изменяемые части системы.

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

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

Вывод третий:задавай вопросы, это бесплатно!

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

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

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

Вывод четвёртый:не играйте в догоняжки - передавайте эстафету

Самым плохим исходом, к которому может привести игра в догоняжки является холодная война между командами. Когда для команды новичков типичным является утверждение, что старому продукту (да и команде!) место на свалке истории. А команда ветеранов троллит новую команду тем, что у них после года-полутора-двух разработки так и не произошло ни одного успешного внедрения.

Одним из симптомов нездоровой ситуации в отношениях между командами может служить желание меряться всем чем можно: "а у нас клиент толще!"

А у нас юзер-стори длиннее!

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

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

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

Вывод пятый:запланируйте задачуочистки данных после миграции

Подумайте об интеграции старой и новой систем. Скорее всего она вам понадобится.

Вывод шестой:учите матчасть.В данном случае - шаблоны интеграции

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

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

Говорят, что часто в этих спорах у кого данные правильнее выигрывал тот, у кого харизма выше.

Вывод седьмой:для всех данных должна быть определена единственная мастер-система

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

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

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

Добиться этого не легко, но возможно. Например, можно выделить на пару спринтов по 1-2 человека из каждой команд в одну команду интеграции. Желательно ещё и посадить их рядом, чтобы они могли свободно общаться между собой.

Вывод восьмой:собери их все!

Вопросы?Степан Колесников, @karakazyablekkarakazyablek@gmail.com

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