
Комментарии 5
Эх, статья по сути похожа на призыв за-всё-хорошее-и-против-всего-плохого!
Например, на хабре была переводная статья про разработку космических ракет в США.
Полвека назад разработали, создали, запустили.
Наши дни: команда хочет повторить, документация вся есть. Пытаются сделать согласно документации - нереализуемо. Вот даже сделать не могут. Находят оригиналы (осталось штук 5 ракет в музеях и на складах), прикладывают одно к другому - не совпадает.
Реальные конструкции не совпадают с документацией.
Разные реальные конструкции не совпадают между собой.
...
В общем, чтиво интересное. Но если переводить на тему Вашей статьи, то выкристаллизовывается пара вариантов:
повторный запуск проекта/производства должен проводиться как новый проект, "с нуля". Это вывод американских ракетчиков;
повторные запуски проекта/производства должны производиться достаточно часто. Команда проекта при этом должна постепенно обновляться: между запусками немного инженеров уходит, немного приходит. Полной смены команды нет - и тогда есть шанс, что это будет работать. В качестве примера можно вспомнить программные продукты "на десятилетия" (например, Microsoft Windows 95/98/2000/NT/XP/Vista/7/10/11).
Вариант "а давайте всех разгоним, пройдёт время, и потом соберём новичков" (по-моему) работать не будет от слова совсем.
Чтоб осознать полноту документации в смысле статьи заказчику надо иметь у себя людей, способных эту документацию прочитать. Ну то есть зачем тогда подрядчик? :)
Подрядчик делает работу. Заказчик должен уметь её принять — это разные вещи. Если внутри нет людей, способных прочитать документацию и понять, что именно передано, заказчик не контролирует проект, а просто доверяет на слово. Если этого внутреннего контура нет, получается обратная история: заказчик платит не только за работу, но и незаметно покупает зависимость. Завтра захочет сменить подрядчика — а не сможет, потому что никто, кроме той команды, не понимает, как всё устроено.
(del)
Потеря инженерной памяти объекта