Anna Turunova написал(а):
ImpCons
Да подход сбора информации и настройки системы может отличаться. На больших проектах в первую очередь рулит интерграция. Ее нет, все, пиши пропало, проблем не оберешься. Кто спорит Я просто привела схематичный пример. Когда много компонентов, конечно, сбор информации в части интеграции, настройки и т.д. намного сложнее.
Если у вас много-много БЕ, так что, можно собрать процентов 30 инфы и на этом успокоиться???
Но!!! Тестирование в полном объеме должно быть. Хотя бы 80-90% операций. Иначе система будет нестабильна просто, и там уже как повезет.
Anna Turunova, ну я и не против что 80-90% на любом проекте должно быть оттестировано, каким бы проект крупным или сложным не был и мы так же собираем список операций для интеграции модуля FI с FM, причем именно в введении одного общего списка с аналитиками обоих модулей чаще всего и проблема. Но практически с самого начала дискуссии я пытаюсь донести что подобрать оставшиеся 10-20% неучтенных операций в сложных и крупных проектах более реальнее на ОЭ/ОПЭ, привлекая при этом разработчика в командировку, а не взаимодействуя с ним на удаленке (что приводит к более медленному решению проблем), чем на Настройке и разработке разобрать все 100% операций.
Anna Turunova написал(а):
У меня есть знакомая, она работает тестировщиком (не знаю, как праивльно термин по-русски) программного обеспечения в США. Их таких там целая контора, которые только и делают, что тестируют.
А смысл нести в продуктив что-то, что нормально не протестировано и бизнесом не согласовано? Чтобы Акты подписать? А как люди потом на местах будут работать. Извините, но срочность несольких программистов во время продуктивного старта - я считаю, что это в корне не правильно. Это мое мнение.
Всегда есть базовые параметры (это как SAP, как круги Эйлера
), которые всегда пересекаются (да и не только для SAP). Сроки, деньги, человеческие ресурсы с определенным опытом и отношением к работе. Чем всего больше и лучше, тем и результаты лучше. Просто всегда стремятся на чем-то сэкономить. Без последствий это обычно не прокатывает.
Скажите нейрохирургу перед сложной операцией: денег нет, давай побыструхе, там еше пять человек под капельницами на очереди. Ну грустно же.
Не вижу больше смысла в дискуссии.
В общем согласен качество всегда лучше когда до ОЭ все протестируешь, но на большом проекте это выливается в такие сроки, деньги, человеческие ресурсы, что на них даже Газпром не подпишется. Хотя я тоже был бы только двумя руками за то чтобы все операции протестировать до ОЭ/ОПЭ.
На небольшом проекте работал по удаленке с разработчиком, который живет сейчас в Вальдорфе (переехал когда то туда), очень хорошо взаимодействие прошло, но его уровень квалификации очень высокий. Сейчас коллегам приходится работать по удаленке с разработчиками К1/К2 доходит до того что данные тестового примера предоставленные в спеке, эти удаленные разработчики, выводят как результат работы программы и нужно письменно до них каждый глюк доводить и разжевывать - сидели бы рядом, тестили бы вместе и экономили кучу времени. Так вот квалифицированных разработчиков, с которыми на удаленке работать эффективно, даже просто в обычном режиме, процентов 20 и наберется от общего количества разработчиков. А что говорить об исправлениях которые нужно делать когда времени на порядок меньше? Для доработки разработок, которые возникают при выявлении 10-15% операций на ОЭ/ОПЭ считаю как раз привлечение разработчика очень критично для экономии времени на доработку, т.к. его на ОЭ/ОПЭ на устранение обнаруженной ситуации в разы меньше чем на Настройке и тестировании. Сейчас у нас идет этап перехода к запуску на нем конечно по максимуму разработки будем дорабатывать и по замечаниям, данным во время предварительных испытаний, и по тому что сами дообследовали, но на ОЭ/ОПЭ все равно какой то процент не выявленных операций наберется и будем брать с собой разработчиков и наши разработчики, как и РП не против.
В общем тоже не вижу больше смысла в продолжении дискуссии на эту тему. Все уже высказались и все точку зрения друг друга поняли, так что дальше только переливать из пустого в порожнее.