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

объявляется тестосрач!

выстроить работу правильно, вот что надо сделать

и "оценивать и тестировать" надо до начала разработки и не после внедрения

(2)Она выстроена правильно.

(0) "забываем чего сделали неделю назад"
Комментируйте код: дата, кто ставил задачу, кто выполнял, кратко суть (если по коду не понятно)

(0) Разруха в головах, а не в клозетах (с)

Документировать доделки по каждому объекту.
Ну и стараться решить штатными методами, не ломая логику поставщика конфы. В большинстве случаев это возможно.

(0) может документирование поможет + в коде ссылки на пункты в документации, для которых писался код

(1)  дада))
(0) пишите автотесты

(0) такая же беда. пока решили запилить вики с тэгами, чтоб было видно пересекающиеся механизмы

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

самый ПРАВИЛЬНЫЙ способ избежать сабжа - поддерживать пользовательскую инструкцию в актуальном и полном состоянии.

(5)Да там дело не в коде. А в пересечении "хотелок" глав подразделений, а их около 12 человек. Владельцы бизнеса просят, чтобы мы взяли на свой контроль ситуацию по пересечению интересов подразделений, связанных с программой. Ну банальный пример - ограничение прав доступа.

еще можно делать файл хоз операций с конкретнтыми проводками.

так сказать технологическую карту...

(13)
1. НачОтдела1 просит изменить Объект1
2. Смотришь по правам, что этим объектом пользуются Отдел2 и Отдел3
3. Идешь к НачОтдела2 и НачОтдела3 и обсуждаешь с ними хотелку НачОтдела1
4. Приходите к общему решению

(15)Это пипец как затянет и излишне забюрократизирует работу. И мы и наши клиенты привыкли к мобильности. Да и не посмотреть  все досконально что затрагивает - много настроек пользователей, много профилей и т.д. и т.п. Без прохождения полного круга БП получается невозможно, но это еще 2 человека нужно и обучить их еще нужно.

(16) это называется согласование. и это норма(с)

(16) "не посмотреть  все досконально что затрагивает"
Роли + Поиск ссылок на объект + глобальный поиск по тексту = 100% что и кого затрагивает

Да, перделки - они такие :-(, всегда наслаиваются...

А в реальности делается это просто, надо, чтобы за все изменения в программе отвечал ОДИН человек, причем, по возможности не программист, а человек клиента, и, соответственно, чтобы начальники отделов шли не напрямую к программистам, а к этом единственному человеку, который заведует всем этим хозяйством. Сам работал на таком проекте, таким человеком был ГБ, через него все и решалось...

(19) т.е.перевалить контроль на заказчика

(19) Причем этот отважный герой должен обладать полномочиями послать проект любой новой хотелки на... доработку.

(4) БУГАГА

(0)Сами бардак наводите, потом слезы на мисте льете за пожалеть..

(20)-(21) Именно так, причем по своему опыту могу сказать, что все это очень неплохо работает, конечно полномочия у этого одного человека должны быть действительно достаточны для того, чтобы послать заказчиков в баню, подобных полномочий у обычных программистов быть не может по определению, а без них нормальную работу в базе не построить никаким образом...

(24) у меня такие права уже лет этак 15 есть :)

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

И все хотелки согласуются именно с этим руководством...

а) "Мы хотим навести порядок"
б) "Мы хотим сохранить быструю /мобильную работу"

Выбирайте любой из этих пунктов, но не оба сразу.

(25)"у меня такие права уже лет этак 15 есть :"
права согласовывать перделки? ))

(25) С чем и поздравляю, но если прочитать сабж, то дословно: "мы дописываем программу для одного клиента". Мне очень сильно кажется, что данная фраза означает, что эти самые "мы" работают по договору и я очень сильно сомневаюсь, что программисты работающие по договору могут послать заказчика в сад, потому что это разрушает логику реализованную в программе. Да и руководство пользователя, даже если оно имеет место быть, вряд ли сторонний программист может заставить прочитать пользователей, я уж не говорю о том, что составление этого самого руководства по времени занимает не меньше, чем написание кода, а оплачивать его стороннему программисту вряд ли кто будет...

(28) когда я работал во франче я посылал в лес несуразные задачи например ГлавМосСтроя.

Единственное отличие, что мотивировку нужно более тщательно готовить...

(29)+ Или для примера компанию "Виктори" (кто в теме - знает), для них я делал вообще мимо их заявок, но когда показывал - брали мое а свои задачи снимали...

(29-30) :-) - Завидую!!!

(31) Завидуешь работе с неадекватными клиентами?

(0) покрывайте все тестами

(32) Завидую, что клиенты достаточно адекватны, чтобы признать свою неправоту, мои попытки некоторым своим клиентам сказать нечто подобное вызывали ответ, дескать, вы или программируйте, или мы других программистов найдем, конечно, долго с такими не уживался :-(

(0) Я видел как 2 раза решили эту проблемму.
В первом случае - все хотелки согласовывал 1 человек.
Во втором случае - был создан отдел методологии, который тоже согласовывал все хотелки и вел документацию.
Честно говоря во втором случае работать мне было работать программистом прям в кайф в каком-то плане.
Во всех остальных случаях - дальше разговоров решение этой проблемы не шло. Поговорили, решили что программисты виноваты все ломают и забыли.

(33)Единственный вариант. И это существенные дополнительные затраты для клиента. Нужно будет подумать над грамотным обоснованием.

(0) сколько человек работает в команде?
Когда работал во франче работал принцип трансляции - когда ставили задачу одному прогу, весь отдел слышал про задачу и мог ее скорректировать.

Думаю лучше всего провести обследование перед выполнением задачи

прибить все хотелки под выход новой типовой по предварительной договоренности - больше половины как правило уже не надо, а про вторую половину может никто давно и не знает

(38) это очень сложно, и ни один франч не пойдет сам по пути упрощения конфигурации и приведению ее к типовой.

ты-бы предложил еще спислить сук на котором сидит 10 дармоедов :)