![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassВот все вроде бы правильно написано, но в общем производит впечатление какого-то сектанства - собственный язык, придумывание новых значений словам, аббревиатуры и прочее. Одна только фраза "внедрение процессов" вызывает ассоциации с работой ради работы.
Оттуда же:
2. Все изменения происходят управляемо
Практически следствие из первого пункта. В проекте не бывает и не может быть неконтролируемых изменений.
Интересно, срочное изменение формы или методики расчета налогового документа в программе, который надо сдать в инспекцию сегодня, в связи с изменением законодательства и полученными разъяснениями вчера - это контролируемое изменение? Если проводить весь цикл - сначала формальное утвеждение изменений, потом внос их в документацию, затем выдача исполнителям, разработка и тестирование - скорее всего изменение к нужному времени сделано не будет, а бухгалтер вместо специализированного программного продукта снова перейдет к использованию Excel.
Хотя вообще если по хорошему, то надо узнавать о изменениях задолго до сдачи документов(не всегда получается, в силу изменений в законодательстве, бывает что изменения надо сделать за неделю-две), утверждать их у заказчиков(а поскольку руководство заказчиков бывает занято, это может затянутся), вносить изменения в документацию, ставить задачу исполнителям, тестировать и деплоить это дело на производственную базу. Получаем что для этого надо иметь немаленький штат сотрудников, и стоимость проекта сразу возрастает, после чего оказывается, что заказчику выгоднее окажется заставить бухгалтеров вести документы опять же в Excel.
А если еще учесть, что в Беларуси закупку программного обеспечения(на госпредприятиях) еще надо обосновать, чтобы КГК не оторвал голову руководству - то руководство при высокой стоимости предпочтет все делать по старинке, запрягая бухгалтеров сидеть сверхурочно и по выходным, вместо того чтобы покупать ПО, оплачивая внедрение у подрядчиков модных современных технологий разработки.
Оттуда же:
2. Все изменения происходят управляемо
Практически следствие из первого пункта. В проекте не бывает и не может быть неконтролируемых изменений.
Интересно, срочное изменение формы или методики расчета налогового документа в программе, который надо сдать в инспекцию сегодня, в связи с изменением законодательства и полученными разъяснениями вчера - это контролируемое изменение? Если проводить весь цикл - сначала формальное утвеждение изменений, потом внос их в документацию, затем выдача исполнителям, разработка и тестирование - скорее всего изменение к нужному времени сделано не будет, а бухгалтер вместо специализированного программного продукта снова перейдет к использованию Excel.
Хотя вообще если по хорошему, то надо узнавать о изменениях задолго до сдачи документов(не всегда получается, в силу изменений в законодательстве, бывает что изменения надо сделать за неделю-две), утверждать их у заказчиков(а поскольку руководство заказчиков бывает занято, это может затянутся), вносить изменения в документацию, ставить задачу исполнителям, тестировать и деплоить это дело на производственную базу. Получаем что для этого надо иметь немаленький штат сотрудников, и стоимость проекта сразу возрастает, после чего оказывается, что заказчику выгоднее окажется заставить бухгалтеров вести документы опять же в Excel.
А если еще учесть, что в Беларуси закупку программного обеспечения(на госпредприятиях) еще надо обосновать, чтобы КГК не оторвал голову руководству - то руководство при высокой стоимости предпочтет все делать по старинке, запрягая бухгалтеров сидеть сверхурочно и по выходным, вместо того чтобы покупать ПО, оплачивая внедрение у подрядчиков модных современных технологий разработки.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2006-04-20 12:15 pm (UTC)