Везде долги: мужской, супружеский,

гражданский, родственный и дружеский,

долг чести, совести, пера,

и кредиторов до х*ра.

И. Губерман

Ко мне тут пришло одно уважаемое айтишное издание и попросило комментарий на тему технического долга . Как бы, сразу возникают два вопроса. Вопрос номер раз — им это зачем? И вопрос номер два — а я тут при чем? (есть люди, которые гораздо лучше в теме разбираются). Но как то они сами не сказали. А я как то не спросил…

Вот сижу теперь и вспоминаю те (счастливые на самом деле) времена, когда я был product ownerом Intel VTune . Жили мы тогда по Scrum-у. Немного доморощенному, но на то она и методология, чтобы ее модифицировать под себя.

Не открою Америки, сказав, что техдолг — это вечное яблоко раздора между product ownerом и архитекторами. Архитекторы всегда хотят чистоты и гармонии. А у product ownera три беды — баги, дедлайны, и кастомеры. А кастомеры всегда жаждут новых фич (features). Ну, точнее, они всегда говорят, что жаждут. Как эти фичи потом используются — глубоко отдельный вопрос. И так получается, что роль продукт оунера - такая «двурушная». C одной стороны, ты постоянно висишь над девелоперами

- Родные, ну давайте эту фишку до конца спринта допилим. Я ее Google (Microsoft, Netflix) еще в прошлом году обещал. Они скоро со мной здороваться перестанут…

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

- А че? Cразу-то по-человечьи нельзя было сделать??? ? Но тут в едином порыве поднимались архитекторы и девелоперы

- Ты же сам каждый день торопил нас!

И начиналось…?

Но у нас вопрос решался относительно просто. Дело в том, что в больших конторах помимо продуктовых ролей существует еще иерархическая структура. Как то так получилось, что у нас product owner был (чисто по совместительству ?) начальником всей команды. Ну, и, как это часто в жизни бывает, прав был не тот, кто прав, а тот, у кого палка… Не знаю, насколько это правильно. Если бы была возможность, я бы наверно и по-другому попробовал. Но колесо истории назад не открутишь…

Но я-то еще ладно. Я был относительно консервативным продукт оунером. И своих архитекторов, хотя бы иногда слушал. А вот до меня ВТюном рулил Тема Куанбеков. Вот он был прям «настоящим» ( И думаю, что в этой роли он был лучше меня). Тема не стеснялся называть вещи своими именами. Все «истории на рефакторинг» Артемий без обиняков именовал «код дрочингом». Где-то я с ним согласен — есть у нашего брата-программиста излишняя склонность к перфекционизму. Другое дело, я думаю, что ее далеко не всегда надо пресекать на корню…

Как итог — техдолг VTune рос как при Теме (несколько быстрее) так и при мне (чуть медленнее). Но, позвольте, так сказать, пару слов «в защиту обвиняемых». Ну мы, типа, теоретически знаем, что бывает когда техдолг становится неподъёмным. Добавление новых фич замедляется, Maintenance cost растет до небес и тд. Рано или поздно команда сталкивается с ситуацией, когда проще переписать продукт «c нуля», чем поддерживать текущий. Но фишка в том, что знаем мы это, по большинству из рассказов «бывалых». Мой пойнт в том, что время «переписывать все с нуля» наступает, как правило, гораздо быстрее, чем тебя успевает «накрыть» технический долг. Просто появляется, какая то новая технология. Ну например, распределенные базы данных. Или HTML + JS GUI. Или Processor Trace. И ты понимаешь, что всю поделку надо переделывать заново. Кстати говоря, сам VTune только на моей памяти так переписывали два или три раза… Но, слава Богу, не в мою бытность продукт оунером. ?

Рассуждая таким образом, я прихожу к теории неких «продуктовых циклов». Вроде того, что на первых стадиях жизни продукта идет агрессивное добавление новых фич. Затем мы приходим к балансу между новыми фичами и тех долгом. Ну а на последней стадии задача product ownera и команды сводится к тому, чтобы просто поддерживать продукт "на плаву". Вот только в моей интерпретации риск проекта дожить до второй стадии минимален. А до третьей - исчезающе мал. Если вдуматься, звучит эта теория довольно мрачно.Когда мы пишем код - нам хочется делать это «на века». Однако, надо понимать, что вечного ничего нет. И, увы, все сводится к удовлетворению данного конкретного кастомера, в данный конкретный момент времени, в данной стадии продуктового цикла…

При этом, я хорошо понимаю, что опыт мой точно не стоит переоценивать. Будем честны друг с другом, Intel VTune — все же достаточно компактный продукт. Думаю, что по количеству кода он вполне сравним с нынешним OpenCV. Как выглядит жизнь продукт оунера в гигантских продуктах типа Microsoft Office или Amazon Web Services я не знаю ( и не уверен, что хочу знать ?). Еще важный момент — грамотная архитектура продукта. И должен сказать — что VTune был очень хорошо спроектирован. Коллектора, базы данных, GUI — все было модульным. Это скорее, не наша с Темой заслуга,а предыдущих поколений разработчиков. И далась она кровью, но все же переписывания продукта «c нуля» не прошли даром. И так получилось, что мы с Артемием рулили VTunом на ранних стадиях продуктового цикла (ну или это нам так казалось). С момента последнего переписывания прошло лет 5-7. Технический долг был еще относительно невелик и продукт оунер мог, по сути, воротить что хотел…

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