Comments 13
Я правильно понимаю что у вас есть видение что такая работа с тех долгом должна помочь, но факты будут самое раннее через 6 месяцев? Потому что по опыту первые две недели все идет согласно плану а потом ресурсы растаскиваются по горячим проблемам и в результате меняется примерно ничего.
А как техдолг аналитики влияет на продукт и разработку?
Как в прошлом аналитик, а теперь разработчик считаю, что: После того как фича выставлена в прод вся написаная документация по ней, теряет гарантированную актуальность.
Единственное среди документов которые должны быть обязательны - это актуальная спецификация API
Функциональному сопровождению проектная документация нужна для разбора инцидентов. Сотрудники саппорта не полезут в код смотреть реализацию. Они работаю с документами.
Solution-архитекторы используют архитектурные документы на систему для проектирования новых решениях, в которых эта система будет использоваться.
Эксперты по информационной безопасности также смотрят документацию и проводят на её основе экспертизу системы в своей области.
В Банке у документации множество потребителей. Они не читают код. И поэтому документация должна соответствовать реализации. А несоответствие документации и реализации - это проблема, которую надо решать
Плюс когда работающий на бою код приходит на доработку (не знаю как у вас, у нас на уровне EQ это сплошь и рядом - поменялся бизнес-процесс или появились новые требования...) актуальная документация очень помогает быстро разобраться где именно требуется доработка. Особенно это касается кода, реализующего сложную бизнес-логику (возможно, это опять особенности уровня EQ).
Так что на своем уровне всегда стараемся максимального соответствия FSD коду. И наоборот (вплоть до вставки пунктов FSD в комментарии - "этот кусок кода реализует этот пункт FSD" и т.п.)
А создание документации на основании кода не рассматривали? OpenAPI, парсить коменты из кода, e.t.c.
А как вы справляетесь с накоплением техдолга во время исправления техдолга? :)
т.е. в то время пока вы актуализируете артефакты аналитики разработка ведь продолжается? и актуализируемые артефакты опять устаревают) или актуализация выполняется по завершении разработки какого то функционального модуля?
В идеале артефакты работы аналитика должны появляться вместе с артефактами работы разработчика. Т.е. выкатили в бой функционал. А он в свою очередь покрыт документацией. Если функционал выкатился без появления/ актуализации документации, возникает техдолг аналитики на этот конкретный функционал.
Внимания заслуживает ситуация автоматического закрытия техдолга. Хороший пример - проект миграции, когда аналитики не актуализируют документы на старую систему. В этом нет смысла, т.к. скоро ей на замену придёт новая со своей документацией
Но какой ценой была достигнута цель спринта? Ростом нагрузки на сеть. Увеличением времени обработки запросов клиентов. Таймаутами. Решение было неоптимальным. У команды образовался техдолг.
Довольно-таки дискутируемый вопрос, даже вне контекста.
Есть ли деньги на разработку оптимального решения?
Каковы критерии оптимальности решения?
Много ли таких клиентов, которым надо отправлять пачку платежек?
Как вы в этом тысячелетии умудрились разработать клиент-банк, который отправляет платежки поштучно?
Отвечу и на вопросы.
Есть ли в вашей компании процесс управления техдолгом в целом и техдолгом аналитики в частности? - нет, технического долга собирается довольно мало, а делать что-то красивое вместо некрасивого обычно настолько затратно, что контролируется это верхним руководством, а не внутри команды к.-л. проекта
Как он организован? - всё в рамках управления проектом, если есть насущная нужда осовременить или доработать нечто - то это включается в план работы.
Какими инструментами пользуетесь? - JIRA
По большому счету, техдолг от бэклога в моем случае недалеко ушел.
Как вы в этом тысячелетии умудрились разработать клиент-банк, который отправляет платежки поштучно?
Это зависит не только от клиент-банка. Тут еще на стороне АБС должен быть сервис-модуль, обрабатывающий платежки в пакетном режиме.
Т.е. все выглядит примерно так: "мы тут новую фичу хотим запилить, сделайте нам вот такой вебсервис и сервис-модуль".
В принципе, для АБС выгоднее получать пакет из 100 платежек, нежели 100 платежек по одной штуке т.к. есть возможность сразу распараллелить обработку на несколько потоков (заданий) и тем самым сократиь время.
Но все это будет делаться уже на стороне АБС, силами других команд и на совершенно другом технологическом стеке.
Аутсорсным командам скорее всего не получится официально заниматься техдолгом, если у них почасовая оплата.
Как мы управляем техническим долгом аналитики