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

Так что мы про это паримся довольно сильно.

Да, сложная дилемма. Но если человек стремится сделать херню и не внимает нормальным неоднократным объяснениям, то не попадает ли это под правило «не работай с идиотами»?

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

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

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

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

Я не знаю решения, к сожалению. Хорошая документация это решает, но ее нигде кроме космоса и оборонки нет.

Тикеты в трекерах точно такой документацией не являются.

А кто-то задумывается об этом в современной культуре разработки? Ну, просто пока все действительно забудут, там уже произойдёт 2 миграции, 3 переписывания на новые модные технологии и 1 пивот:)

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

И это тоже :)

для этого конфлюенс вроде)

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

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

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

какая разница какой инструмент 🙂

ну вот у нас уже в этом контексте возникает восстановление требований снова :(
и в подходе Самата я не вижу вариантов, как требования можно восстановить, кроме реверсинжиниринга, меня это смущает очень сильно

у конфлюенса есть два состояния: "пустой" и "устаревшая каша"

для разных задач разные инструменты, вот и вся разница)

А зачем их восстанавливать? Так вроде как бы можно из общего обзора архитектуры более-менее достать, по крайней мере высокоуровневые, но требования «на тогда» и «на сейчас» могут бесконечно различаться. Если есть возможность найти отличия и хотя бы примерно проследить изменения, на уровне коммитов или там тасков - то тогда вроде как данных должно быть достаточно.