Приветствую всех! Существует ли у вас в компании система разработки? Кто и как принимает решение о целесообразности доработок? Кто контролирует процесс и предотвращает расползание системы? Интересует мнение тех, у кого больше 2 программистов.

gthtl rf;lsv dsgecrjv htkbpf = "перед выпуском релиза"

(68) стараемся изо всех сил :) Но как правило - либо все гут, либо - все ппц как плохо. Вот этот ппц обычно еще больший ппц исправлять :) Список плагинов поглядел - к себе заберу changeauthor и periodictasks. Мы еще сидим на Redmine 1.2.1.stable =)

(69)(71) берите на вооружение... Я теперь не могу нарадоваться, от уменьшения количества ошибок в конфигурации.

(68) У нас хорошо прижились Сценарное тестирование и Центр управления производительностью. В общем, рулит принцип: 20% усилий на устранение 80% потенциальных ошибок. "Автоматизованная проверка конфигураций" требует усилий сверх 20%, задействуем, если найдется покупатель на эти доп.усилия :-)

(72) + ссылку забыл добавить http://snegopat.ru/forum/viewtopic.php?f=3&t=245 .

(52) +(53) Scrum+Agile = Делаем то, что просят, приоритет это время когда пришел запрос, показываем быстро, большие задачи дробим на мелкие, исправляем косяки сразу. Большие боссы ограничены всего тремя быстронахами(высший приоритет) в месяц (если все использовали, то ждите следующего месяца). Вот как-то так, знакомые фикси и работают.

(0) хранилища нет, документирование есть.

периодически берем попу в горсть и собираемся с понедельника начать (26), последний раз хватило на 3 недели.

ЗЫ 3 человека, включая начальника-неадинэсника.

оч. интересная тема.   Подпишусь.

В качестве утреннего апа. Похоже можно подводить итоги. По моим представлениям не больше 10% отделов АСУП предприятий имеют хоть какую-то систему разработки

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

(75) Про три желания (быстронаха) понравилось.

(78)Те, кто не имеют -  имеют геморрой с переработками про вечерам и выходным,скандалы с пользователями а-ля "а мы хотели совсем другое!" и бардак в базе.

Так что лучше какую-то систему иметь.  Тем более , что в этом нет ничего сложного. Просто нужно организоваться.

В общем, система проще некуда.

(79) Ваш вариант нормальный. Но он приемлем для небольших предприятий. А если делается большая система, например, на основе УПП, когда пишут код много людей, возможно для филиалов. Я о таком спрашиваю

(83)
1.Стандартный бланк заявки на доработку.
-От кого
-Причина
-Подробное описание
2. Подпись у своего нач. отдела
3. Рассмотрение заявки руководителем програмеров. При одобрении - передача на исполнение разработчику.

Это в случае если доработка небольшая.

Крупные доработки  -  все тоже самое только с ТЗ и визировнием ГенДира ,ФинДира и Гл. Буха

Собственно все. И будет порядок и благодать:-)

+ все заявки естественно подшиваются в архив, можно поднять в любой момент

(84) У крупного фикси с кучей баз при отсутствии у главразраба хотя бы основных знаний методологии PMP такая схема превращается спустя пару месяцев в "Титаник" с жутким бюрократическим бардаком на борту. И начинается бессмысленное расширение штата, ходящие по кругу кипы ТЗ, лениво отфутболиваемые друг другу, ну и прочие радости жизни.

(86)С чего это тз будут ходить по кругу?  В процессе разработки ТЗ пользователи тесно сотрудничают с нами, так что к моменту его финального релиза "на подпись" все вопросы решены. Большие боссы подписывают -  и можно браться.
Заявки тоже - обычное дело. Чаще всего просто подхлдят к руководителю и спрашивают можно ли такой бантик сделать. Если дают отмашку- идут писать заявку. ВСе работает как часики.  Только ТЗ пишется бывает долго:-)  Но это их проблемы. Им же надо.

(87) А я и не говорю, что такая схема нежизнеспособна. Попросту у нее есть свой порог, после которого эффективность падает ниже плинтуса из-за того, что постановка задачи теряет актуальность раньше, чем исполнитель ее получит.

(87) Все это конечно интересно. Но как отсечь заявку на доработку, которая идет в разрез с концепцией системы. А ее может лоббировать какой-либо туз в вашей фирме

(88)Было и такое у меня.  Когда поток требований и доработок зашкаливал за разумные пределы.  Тогда даже вышеозначенная схема не помогала. Но если вообще никак не систематизировать этот шквал - в нем вообще утонешь

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

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

первая большой отдел порядка 4-5 админов, 10 инженеров , 10 - 1с программистов.
3 - отдел из админа и 3х программеров.

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

в первой и третей работать было вполне комфортно.

(91) Причем- не причем...Это о другом. Система в результате может уйти в полную необновляемость типовыми релизами.

(93)Нам проще. У нас она и так напрочь нетиповая:-)

(93) А если что так и предупреждаешь, что перестанет обновляться и трудозатраты возрастут , т.е. каждое обновление будет троебовать кучу времени и прочие доработки и хотелки будут откладываться.  И если решат что пусть, ну что ж...Будешь обновлять ручками.

(89) Крупный холдинг, много региональных хотелок. Стоит система Сервис дэск, пользователь размещает заявку в системе. На каждую тему заявки (БУ, УУ, ОК) определен согласующий комитет из представителей методологов и директоров. Заявка прошла согласование, далее тех. РП дает техническое заключение и предполагаемую концепцию решения. Программер кодит, советуясь с Тех. РП. Вкратце так работаем.

(96) + Используется хранилище

Отличная тема, что называется "подпишусь на каменты".

У нас зоопарк. Есть центральная система, ServiceDesk, в нее заводятся все задачи. Трудозатраты фиксируются в другой системе. Техподдержка ведется в SD и веб-системе. Документация централизованно не хранится.
Аналитик или программеры описывают задачи у пользователей. Если аналитик - описание может принимать вид простенького техзадания.
Развернуто хранилище для доработок внешних исполнителей.
Шеф контролирует все более-менее крупные задачи.

(93) Хм, термин полная необновляемость типовыми, меня несколько смущает. Может именно "трудозатраты на обновление типовыми релизами существенно вырастут..."

100!

(9) Вывод может и верный, только основан он на недостаточных данных: после вопроса в 15:34 до момента формирования "вывода" 15:52 прошло 18 мин.
Опрашивающий (т.е. ты) считает, что за эти 18 минут в ветке обязательно отметились ВСЕ фикси. И конечно же выводы уже можно делать на основании этих всех отметившихся...

Британский ученый? :)

(98) Но, думаю, где то лет за 6, все-равно ориентация в системе теряется, и на вопрос "зачем это было нужно?" ответить становится трудно.

(102) Если нормально документировать, вопросов не будет

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

(104) Чаще вопросы возникают, почему это ТАК сделано, с корявой структурой, с непонятными отчетами. Но к сожалению, система кроме как комментария к задаче для предков не передает цейтнота, "хочу", "гребаного законодательства" и т.д.

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

(0) Большая компания, куча программистов, куча баз, куча пользователей, куча юр лиц, большой документооборот, куча сторонних программа = Полная *опа. (Это стандарт в 1С)

(78) У вас есть система разработки на продажу?

(108) Я не продаю. И цель топика не в том.

Есть у кого-то хоть какая-то система для v8, в которой изменение конфигурации жестко связано с системой контроля задач (биллинга решений и пр.)?
(109) Жаль, я мог бы купить. А в чем цель топика?

(110) скорость хранилища от 1С не позволяет делать мелкие коммиты, поэтому приходится в одном коммите писать #123 , #212, #140 для закрытия задач.
Так же хранилище не позволяет делать ветки, а как удобно было бы - это тестовая ветка, эта разработки. К тестовой прогоняем тесты и привязываем тикеты, если че нибудь сломалось.
Это мечты... Возможно, что либо изменится с 8.3 и выгрузкой/загрузкой конфигурации.

(110) У нас есть своя система фиксации доработок написанная на V8. Она неотторгаема. Это основа.+Хранилище.  Остальное организация.
А суть интереса в том, что мой бывший сотрудник пришел на работу в большой ИТ-отдел и пребывает(пребывал) в растерянности. Типа, строительства китайской фанзы...

(112)Ну тогда передай мой ему совет: если хочет изменить, пускай начнет с себя, ведет задачи, в хранилище указывает номер задачи закрытой и т.д.

У меня через 2 месяца сказали, да ведем задачи в Redmine и пришлось срочно свои проекты вырезать из базы.

(113) Ссылку дал

(111) >>приходится в одном коммите писать #123 , #212, #140
Это нормально. У вас как-то перехватывается комментарий "#123 , #212, #140" при коммите? Список измененных/новых объектов как попадает в ту задачу, по которой они были изменены/добавлены?

>>не позволяет делать ветки
При такой структуре хранения конфигураций, как в v8, с ветками почти "швах". То есть, можно созадть, но последующее слияние только через штатное "Сравнить и объединить". В 7.7 операцию слияния веток выполняем полу-автоматически для подготовленных проектов.

(112) у вас система фиксации доработок связана с хранилищем или сотрудник сначала фиксирует решение в хранилище и потом пишет об этом в систему фиксации доработок?

(115) да в redmine отслеживает по шаблону номер задачи и автоматом коммит привязывает к задаче.
Измененные/добавленные объекты к сожалению не определяет, но есть желание приделать выгрузку отчета о конфигурации в txt файл и тогда по задаче будет видно сразу какие объекты метаданных изменились.

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

(116) >>да в redmine отслеживает по шаблону номер задачи
Вместо штатного хранилища используете fossil, я правильно понял?

+ (117) Или снегопат перехватывает комментарий из конфигуратора и отправляет в redmine?

К сожалению полностью от хранилища пока не могу отказаться. В основном из-за проблем с обновлением конфигурации поставщика в хранилище.

fossil использую для удаленщиков или же когда сам на серверах заказчиков работаю. Так же использую fossil для внешних обработок/отчетов - неудобно их хранить в кофнигурации с хранилищем, т.к. теряются типы реквизитов. На работе используется redmine c задачами и вики.

На работе схема такая: redmine - багтрекер, в нем подключен git репозиатрий, из хранилища каждую ночь выгружаются версии конфигурации, загружаются в пустую базу, делается выгрузка модулей  и  commit в git репозитарий тем же комментарием который и в хранилище. В Redmine получается дерево конфигурации только модулей без форм и без изменений реквизитов. Так же для внешних обработок используем git репозиторий. (Я пока не сделал работу с git из снегопата приходится пользоваться извращениями с экспортом импортом из fossil в git истории коммитов).

Дома, на удаленке, мелких проектах использую fossil: в fossil хранится cf и внешние обработки, задачи и вики. Когда заказчика нецелесообразно подключать к хранилищу использую fossil.

(0)В моей комнате 2 архитектора, 3 программиста и 4 аналитика. По всей стране разбросано ещё 20 программистов. Контролируем версии всех конфигураций посредством хранилища конфигурации. Всё по ТЗ, все подсистемы максимально независимы, чтоб можно было всегда доработать одно не сломав при этом остальное.

Есть отдельная база "1С:Управление проектами". Самый интересный узелок информационной базы, связанный с управлением проектными задачами http://www.iteam.ru/publications/project/section_36/article_2495, наподобие MS Project, разрабатываю лично. Ни в одной конфигурации-тиражнике мы этого просто не нашли - потому сами делаем. Интерфейсы-то красивые есть, а вот математического ядра, выстраивающего задачи в последовательность и ищущего критические пути, нету и в помине.

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

(119) ох, как сложно! Могу, в принципе, рассказать и показать наши наработки и достижения, какому количеству человек в вашем регионе это может быть интересно?
(120) >>Контролируем версии всех конфигураций
А кто в вашем случае делегирует захват объектов в хранилище или захват корня хранилища при добавлении объектов?
>>По всей стране разбросано ещё 20 программистов
Случались ли на вашей стройке несчастные случаи (программист захватил корень хранилища и затих на неделю-две, например)? :-)

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

(123) Если двоим интересно, приезжайте http://www.cio-summit.ru/
(109) Хотите нашу попробовать в работе или хотя бы узнать более детально?

Доработки - это требования бизнеса на тот или иной функционал. Можешь обеспечить не допиливая конфу -обеспечь, не можешь -напильник в руки и вперед.

(124) а описало вашей системы где посмотреть?

(126) Внутри системы, в зависимости от выбранной глобальной роли (контрагент или сотрудник/разработчик/тестировщик/внедренец). Открытая часть еще разрабатывается, какие у вас есть вопросы, чтобы учесть при подготовке описания?

(122) (123) Как правило с одним хранилищем работают программисты, сидящие в одной комнате, а не со всей страны. Принято помещать в конце дня все доработки в хранилище. Бывало дело и разок я оставил захваченные объекты - мне звонили на сотовый и решали что делать.
А вот в базу УП поступают заявки со всей страны. Это необходимость, так как имеют место однотипные подсистемы, разрабатываемые у нас, которые встраиваются практически во все базы сразу. Скажем перепиленная нами "Управление вводом данных" или "Универсальный отчет" вкупе с "Варианты отчетов" и "Рассылка отчетов". Написал один раз такую вот независимую подсистему - и встраивай куда не лень, красота :-))).

(128) а если не готово? Если задача вроде на 2 часа а занимает 2 дня и код еще не дописан в захваченных объектах? Если то, что готово ломает базу?

(127) я пока не понял, как вашу систему поглядеть :)

(129) А для этого предусмотрена такая штука, как комментарии и метки рядом с рабочими версиями конфигурации. Если не готово - то мы загружаем из хранилища не текущее состояние, а самую свежую РАБОЧУЮ версию. Ну или просто выгружаем cf-ник последней рабочей версии и накатываем на рабочую базу - вариантов действий много. Если помимо МЕТА данных нужно заменить ещё и УЧЕТНЫЕ данные - пишем сопутствующие обработки и информационные письма. Накатыванием хранилищ на рабочие базы, как правило, занимается руководитель группы программистов - у него эти движения отточены до уровня спинного мозга :-))).

(131) понятно, ручная выгрузка/загрузка конфигураций все равно присутствует и сверка измененных объектов с списком есть.

(132) Работа с хранилищем - это далеко не самое интересное и сложное в управлении проектами. Над самым интересным по этой части (базой "1С:Управление проектами") ещё работать и работать, чтобы до международного признания довести систему.

(133) согласен, но все же хотелось бы лучшего взаимодействия с хранилищем.

(133) Ого!! Прям уж и до международного? Вы фикси?

(0)
>>Существует ли у вас в компании система разработки?
Что имеется ввиду?

>>Кто и как принимает решение о целесообразности доработок?
Специалист-внедренец, которому ставится задача, что вот надо этакую загогулину, что делать. Часто он консультируется с другими специалистами, в иногда согласовывает с вышестоящими руководителями.

>>Кто контролирует процесс и предотвращает расползание системы?
На проекте нужен хотя бы один человек, который бы следил за разработкой в целом, или хотя бы по крупным блокам. Это или сам рук. проекта, или тех. руководитель проекта. Этот человек должен понимать, что хорошо, а что плохо при внесении изменений в систему.

(135) На данный момент фикси. Самим-то для фирмы дай Бог сделать. До международного уровня - этим уж ЗАО 1С пусть занимается. У них, видимо, тоже ничего ещё особо не готово. С кадрами, могущими делать подобные аппараты http://www.iteam.ru/publications/project/section_36/article_2495 , очень серьезный напряг в России судя по тому, что я видел в кодах имеющихся тиражников (((.

(134) Для этого нужно разрабатывать свою фирменную МЕТОДИКУ работы с хранилищем. Но нам пока и так хватает.

(137) Напряг потому что найти отличного кодера со знанием предметной

(137) Напряг потому что найти отличного кодера со знанием предметной области и мотивацией, достаточной чтобы такой аппарат разработать практически невозможно. А ведь его (аппарат) еще потом надо продать. А кодер продать не сможет. И кодить бесплатно в течение нескольких месяцев (на такой аппарат нужно много времени) он не сможет. Значит такой проект под силу только или очень универсальному солдату, или серьезной организации. А у серьезных организация и так работы хватает...

(130) Если хотите посмотреть со стороны заказчика, необходимо заказать доработки, заключить договор.
Если хотите посмотреть со стороны исполнителя и у вас есть, как минимум, 1 клиент (заказчик), 1 руководитель проекта, 1 или несколько разработчиков/тестировщиков/внедренцев (зависит от числа проектов и распределения ролей), предоставлю систему в пользование на 30 дней.

(140) Да вот у Питер-Софт, ИТ-Лэнд и у самой ЗАО 1С не вижу этого самого "аппарата". Много написали они всего по "1С:Управлению Проектами" - и отчеты красивые с диаграммой Ганта, и построители блок-схем, а этот самый паршивый узелок, без которого вся программа существенно теряет полезность, всё никак не готов (((((.

(140) От себя добавлю - я как раз-таки один из тех, кто САМ вызвался на разработку таких вещей :-). Но одного меня явно маловато да и моя математическая подготовка, полученная в ВУЗе оставляет желать лучшего (такой, как при СССР уже, боюсь, не будет)(((.

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

кроме того я фри, в составе разных команд. там двойное документирование работ - добавляется еще учет почасовки и плана-факта оплат.

перед разработкой больше 8ч планирую в проджикте, очень удобно когда работ на 100 и больше часов. например когда в Управление страховой компанией 8.2 переносил остатки из самописной 1С7.7

(141) а это конфа 1С? Или что?

(0) решение о принятии целесообразности разработок.. хехе. У фикси это практически вне компетенции.

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

Мне на данный момент довелось поработать на двух проектах на фикси - оба - доработка УПП.

На первом было 3 разработчика, технический писатель - он же - бета-тестер и архитектор системы. Плюс директор по ИТ - методолог и вдохновитель. Разработка шла по классическому проекту - сначала описание концепции ВСЕЙ системы (довольная крупная доработка 1С для логистики, хотело получить 1С Совместимо), затем планирование работ (по этапам), ну и собственно разработка. Имелось хранилище, а вот системы учета тикетов не было. Главная мысль - тут было немного "нестандартное" фикси, так как начали изначально писать то, что полностью бы устраивало ключевых пользователей. Принцип доработок - создание отдельных объектов, типовые - максимально неизменяемые, доработка форм - исключительно программными методами. А не по мелочи дорабатывали, получая в итоге монстра.

Теперь к монстрам - на втором рабочем месте пришлось столкнуться со страшной семиглавой гидрой - дописанная УПП 1.2.5.1. Там процесс изменения системы шел с точностью до наоборот. Когда-то начались дописки по любому писку пользователя - этот ад трудно себе вообразить, практически ВСЯ конфигурация за около 5 лет доработок превращена в полностью необновляемую. Это второй путь, так сказать.Хотя хранилище там было и когда я туда пришел - пытались наладить нормальную работу. То есть - система заявок - otrs, хранилище. Решения о выполнении заявок, начальник №2 (описанный в посте (35)) всегда принимает положительные, руководствуясь правилом "пользователь всегда прав". С одной стороны это заявление на фикси трудно оспорить, с другой - сейчас я уже только  со слезами могу смотреть на то,с чем приходится работать.
В отрс фиксируется только время на заявку, плюс описание проблемы - описание решения (кратко),без описания изменений объектов.

Розница, производство, финансы разделены по программистам, начальник пишет тз и контролит сроки, все гуд)

(148)Специализация же узкая..."К пуговицам претензии есть?". А ну как один в отпуске?

блин, какие все умные тут! я восхищен...
сам не веду никаких багтрекеров, репозитариев и прочего. да и объемы у меня не тем, +1 сам. в системе управления проектами веду тодо+регламенты+инструкции, стараюсь все документировать - что надо сделать (если внезапно мысль), какие баги, глюки. Пытаюсь приучить юзверей писать в групваре свои запросы в отдел ИТ - но с трудом.. с трудом...
.
инновации, доработки, вкусности - восновнм предлагаю сам руководству. согласовываем нужность/важность - далее все сам...

(145) Это примерно:
1) Управление требованиями - RMS (собственная разработка на php).
2) Управление версиями - CVS (open source) + gcomp.exe для v7.7 (open source) + V8Parser для v8 (собственная разработка по разборке/сборке *.cf), жестко связана с управлением требованиями
3) Методика коллективной работы.
Вспомогательные инструменты:
Araxis Merge (куплен) или kdiff3 (open sourse) - средства сравнения файлов и папок.
1С:Сценарное тестирование, 1С:Центр управления производительностью.
WinCVS - клиент для CVS (open source)
ОС: FreeBSD

(147) Спасибо. Интересно

из предложений по сабжу я-бы такую фишку предложл реализовать 1с

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

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

(142) Спроса нет потому что. Спроси у своих знакомых, что такое сетевой график и критический путь, мало кто даст ответ, большинство переспросят: "Чо?". А раз нет спроса, значит нет и предложения. Если кто-то и ощущает реальную потребность в таком инструменте, то начинает писать под себя, в итоге получается продукт, заточенный под одну контору и не способный к размножению (тиражированию). К тому же в одиночку такие проекты пишутся годами, и когда он наконец появляется под 7.7, у всех уже стоит 8-ка, а когда на 8-ке кто-то сподобился подобное написать, везде уже УФ. Крупным разработчикам это тоже неинтересно: бигбоссы такими проектами не увлекаются, так как отдача от них придет нескоро, а если полявляется одиночка-энтузиаст, то из него делают "человек-отдел", где он в одиночку все пишет, понимая по пути, что через год его отдел будет должен компании пару лямов денег за его зарплату, аренду и прочие расходы, и в итоге весь пыл угасает вместе с проектом. А даже если он проект до конца доведет, то потом контора начнет на нем зарабатывать, а сам он будет в лучшем случае получать мизерные отчисления с продаж и круглосуточно сидеть на поддержке и исправлении ошибок. В общем пока не появится человек с 3-мя миллионами денег, готовый вложиться в разработку такого "аппарата", аппарата у нас не будет...

подписался на тему

(69) А почему сейчас этого нет. Ни в Рарусе ни в 1с?

(0) На каждую разработку составляется:
- требование на доработку с обоснование (утверждается)
- проектное решение на утвержденные разработку (проходит стадию согласования с Архитектором)

(154) Почему-же все-таки Европа и США давно использует сетевое планирование на полную катушку, а мы - всё никак? У нас что, серьезных организаций и проектов нету?

(158) у серьезных организаций и проектов - в нашей стране - серьезные проблемы. и вопрос по сабжу - на данном уровне развития бизнеса - незначим со ссовей пользой/вредом на фоне прочего.. как-тотак.. да и нет "делового обычая" вести работу КАК НАДО. потому что такое ведение работы сразу же подразумевает СИЮМИНУТНЫЕ ЗАТАРТЫ (см.154). а выхлоп - в среднесрочной/долгосрочной перспективе. а у нас я думаю не любят далеко загадывать.. далеко загадывать - это стратения, а совы тактикой не занимаются... так и будет прозябать... пока наличие такой системы у игроков рынка/бизнеса не будеть давать ОЩУТИМЫЕ/ВАЖНЫЕ преимущества...

Если руководство [censored], то в основном решения принимаются хаотично в процессе совещания "ни о чем" или по звонку высокопоставленного юзверя "а вот хотелось бы..."
Если есть добросовестный начальник - старается контролировать, но за всем не уследить, поэтому по-любому система расползается (допустим когда есть много разных баз)
Явления эти не зависят от масштабов компании, все из-за "человеческого фактора"
Так было везде где посчастливилось работать :)

(156) Есть, причем оно там очень эффективно работает. Поверьте: создать продукт, который будет одинаково хорошо работать на десятках тысяч предприятий с разными видами деятельности и с различными особенностями учета - это мегазадача. Потому что надо написать так, чтобы исправление одной ошибки у одного клиента не поломало все у десятка других. И учесть все нюансы при такой разработке просто нереально. Львиная доля ошибок отлавливается тестировщиками, но они тоже люди и тоже все отловить не могут, поэтому ошибки в релизах будут всегда, от них никуда не деться. Если уж айфоны от перегрева взрываются и космические аппараты падают, то что говорить о ТОРе.
(158) Потому же, почему Европа и США ездят на мерседесах и кадиллаках, а мы дальше КАЛины не ушли: софт у нас пишется так же, как и автомобили проектируются и собираются. Мы такая нация.
(159) Полностью согласен

(160) КонецЦикла, скинь контакты как можно с тобой связаться... А то почта и Аська в ЛК не отвечают.

>>Потому же, почему Европа и США ездят на мерседесах и кадиллаках, а мы дальше КАЛины не ушли: софт у нас пишется так же, как и автомобили проектируются и собираются. Мы такая нация.

Да-да, я это называю "производство по русски". Типа сделаем тяп-ляп, а на месте сами допилят.

(163) И еще потому что производители софта им не пользуются, так же как работники автоваза не ездят на своей продукции )

(22) потому что решение об этом принимают обычно некомпетентные люди

(159) (161) МЕНТАЛИТЕТ нации - вот и вся проблема.

вот еще на Исе наткнулся, может пригодится кому-нибудь:
http://infostart.ru/public/80290/

(167) Цитата оттуда: "прохождение заявки по типовому процессу" - все, досвидос, как всегда шаг влево шаг вправо от типового БП, и все ломается, потому что реализовать такое изменение БП на лету (отменить/добавить один или несколько этапов) практически невозможно.

(167) Спасибо - вдруг, да поможет.