A
Size: a a a
2020 January 22
AM
по поводу Питера - можно в эту пятницу/субботу, кому как удобней.
Там по опросу вроде человек 15-18 давали согласие, кто из них готов на этой неделе?
Там по опросу вроде человек 15-18 давали согласие, кто из них готов на этой неделе?
/me
A
Как вариант. Но если по хорошему, когда делается проект под конкретного заказчика, нужен период опытной эксплуатации. Ну и на этапе ТЗ и эскизного проекта обязательно вовлечение эксплуатирующих организаций. К сожалению, на это Заказчик забивает, и копипастит в ТЗ всякую хрень из маркетоложеских высеров разных компаний, совершенно не задумываясь, а нужно ли оно ему, и выполнимо ли.
v
На протяжении всего периода жизни изделия.
Обязательно. У нас самый лучший буст в плане качества продукта, возник во время начала массовой инсталляции - потому что начали получать фидбэк от пользователей. Да на 1м году жизни, он не всегда был положительный, но позволил внести ОЧЕНЬ много исправлений, благодаря которым, он доставлял меньше проблем следующим заказчикам.
Или например даже имея лабы для нагрузочного тестирования, пока не появился заказчик с необходимостью инсталяции на очень большое количество серверов - мы точно так же, не знали о ряде проблем, которые не всплывали на нагрузочном тестировании. Это так же позволило внести ряд доработок по качеству.
Однако заслуги тестировщиков тоже не стоит принижать, очень много багов вылавливается ими. Но всё же, каждый раз убеждаюсь - продакшн среда, каждый раз подкидывает какие-то новые сюрпризы, которые не способна выявить тестовая.
Или например даже имея лабы для нагрузочного тестирования, пока не появился заказчик с необходимостью инсталяции на очень большое количество серверов - мы точно так же, не знали о ряде проблем, которые не всплывали на нагрузочном тестировании. Это так же позволило внести ряд доработок по качеству.
Однако заслуги тестировщиков тоже не стоит принижать, очень много багов вылавливается ими. Но всё же, каждый раз убеждаюсь - продакшн среда, каждый раз подкидывает какие-то новые сюрпризы, которые не способна выявить тестовая.
v
A
Обязательно. У нас самый лучший буст в плане качества продукта, возник во время начала массовой инсталляции - потому что начали получать фидбэк от пользователей. Да на 1м году жизни, он не всегда был положительный, но позволил внести ОЧЕНЬ много исправлений, благодаря которым, он доставлял меньше проблем следующим заказчикам.
Или например даже имея лабы для нагрузочного тестирования, пока не появился заказчик с необходимостью инсталяции на очень большое количество серверов - мы точно так же, не знали о ряде проблем, которые не всплывали на нагрузочном тестировании. Это так же позволило внести ряд доработок по качеству.
Однако заслуги тестировщиков тоже не стоит принижать, очень много багов вылавливается ими. Но всё же, каждый раз убеждаюсь - продакшн среда, каждый раз подкидывает какие-то новые сюрпризы, которые не способна выявить тестовая.
Или например даже имея лабы для нагрузочного тестирования, пока не появился заказчик с необходимостью инсталяции на очень большое количество серверов - мы точно так же, не знали о ряде проблем, которые не всплывали на нагрузочном тестировании. Это так же позволило внести ряд доработок по качеству.
Однако заслуги тестировщиков тоже не стоит принижать, очень много багов вылавливается ими. Но всё же, каждый раз убеждаюсь - продакшн среда, каждый раз подкидывает какие-то новые сюрпризы, которые не способна выявить тестовая.
Полностью согласен.
Только до массовой инсталляции еще долго идти :)
Как вариант - позиционирование изделия в нескольких ипостасях - открытый вариант (без КСЗ, но с базовой функциональностью, тех-поддержка без SLA), вариант "академический", и вариант для целевых заказчиков...
А еще есть большая разница в "продакшене". Для одних "большая" система - это 50 серверов, для других 15 тыс. серверов - это маленький дата-центр...
Только до массовой инсталляции еще долго идти :)
Как вариант - позиционирование изделия в нескольких ипостасях - открытый вариант (без КСЗ, но с базовой функциональностью, тех-поддержка без SLA), вариант "академический", и вариант для целевых заказчиков...
А еще есть большая разница в "продакшене". Для одних "большая" система - это 50 серверов, для других 15 тыс. серверов - это маленький дата-центр...
РМ
а СБ - это Служба безопасности? А зачем Службу безопасности привлекать к составлению ТЗ?
РМ
Потому что это был карманный проект. Потому что заказчику был нужен не результат, а процесс. Потому, что не согласовали с СБ заказчика. Потому, что не хватило понимания и квалифицированных кадров для внедрения. Потому, что не заключили с разработчиком договор на поддержку, а с ИЛ - на инспекционный контроль.
Результат - нет внедрения, нет поддержки, и исход закономерный. Бобик сдох.
Возможно, что в известном Вам, Роман (я полагаю) проекте будет то же самое... Ибо у заказчика пока даже понимания архитектуры нет. Но это уже не тема для открытого обсуждения.
Результат - нет внедрения, нет поддержки, и исход закономерный. Бобик сдох.
Возможно, что в известном Вам, Роман (я полагаю) проекте будет то же самое... Ибо у заказчика пока даже понимания архитектуры нет. Но это уже не тема для открытого обсуждения.
и тут вы тоже про согласование с СБ говорите
A
а СБ - это Служба безопасности? А зачем Службу безопасности привлекать к составлению ТЗ?
От СБ режимного предприятия идет финальный аппрув. Если ТЗ делается как для коммерсов, а не как для гос-конторы, с учетом требований к ГИС(АСЗИ), то это фэйл.