Comments 6
Жаль что в реальности всем вышеописанным самому программисту и приходится заниматься.
Очень типичное поведение для производителей таких продуктов: вместо того, чтобы вникать в потребности заказчиков, попытаться заставить этих заказчиков мыслить внутренними категориями системы. Этим грешат разработчики практически всех систем автоматизации бизнес-процессов (включая ERP, банковские и прочие).
«Что вы там мямлите про новую инструкцию ЦБ? Вы мне дайте перечень бизнес-объектов, матрицу ролевого доступа и опишите триггеры для проверки данных!»
А проблема решается только так: между заказчиком и программистом должен стоять бизнес-аналитик, способный переводить с одного языка а другой. А не «консультант и методолог».
«Что вы там мямлите про новую инструкцию ЦБ? Вы мне дайте перечень бизнес-объектов, матрицу ролевого доступа и опишите триггеры для проверки данных!»
А проблема решается только так: между заказчиком и программистом должен стоять бизнес-аналитик, способный переводить с одного языка а другой. А не «консультант и методолог».
Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90%выполняете работу программиста.
В 90% случаев, получив от аналитика такое техническое задание я его бы и посадил программировать :)
Изначально подход не верный. 1С служит для решения проблем бизнеса. Задачи надо ставить исходя из той проблемы которую в данный момент надо решить.
1. Не описывайте формы ввода информацией, описывайте состав информации, которой владеет пользователь на начало бизнес-процесса. И, как правильно описано, состав команд — действий, которые доступны пользователю.
2. Не описывайте алгоритмы, описывайте физический смысл этапов бизнес-процесса и ограничения, которые требуется применять к каждому этапу.
3. Запомните, контрольные процедуры не относятся к формам данных, они относятся к бизнес-логике. Ни один нормальный программист не станет делать контроль сразу в форме ввода информации. Тем более правила сверки, матрицу доступа или что-либо еще. Все это делается уже имея схему данных и модель взаимодействия.
4. Про характеристики модели данных сказано хорошо, но важнее не то, какие будут характеристики (их вычислить ничего не стоит), важно то, какой физический смысл должен быть у объектов бизнес-логики. Не надо объекты процессов и взаимодействия описывать моделью данных — это задача программиста.
5. Автоматическое заполнение данных — это уж точно не то о чем нужно думать. Нужно думать «Зачем в данный момент надо заполнить так, а не иначе?», «Почему я суда должен подставить это?». См. пункт 2. Если программист не понимает физический смысл, он не понимает задачу. А это значит не сможет ее решить оптимально.
6. Формы вывода информации аналогичны пункту 1. Стоит описать не то, как будет выглядеть формочка (названия колонок в таблице отчета не скажут программисту ровно ничего), нужно описывать то, что ожидает увидеть пользователь в результате работы этапа бизнес-процесса. Т.е. те промежуточные данные, которые доступны в ходе выполнения и общий результат, который нужно отобразить. Не связывая этап бизнес-процесса с выводом информации вы просто рискуете получить какую-то ерунду, непонятно откуда взятую (например программист решит выбрать данные из регистра, который заполняется только в следующем этапе бизнес-процесса).
Ну и как показывает практика, хорошему программисту 1С освоить питон удается в разы быстрее, чем хорошему программисту-питонисту освоить 1С:)
Плюсик за попытку.
Изначально подход не верный. 1С служит для решения проблем бизнеса. Задачи надо ставить исходя из той проблемы которую в данный момент надо решить.
1. Не описывайте формы ввода информацией, описывайте состав информации, которой владеет пользователь на начало бизнес-процесса. И, как правильно описано, состав команд — действий, которые доступны пользователю.
2. Не описывайте алгоритмы, описывайте физический смысл этапов бизнес-процесса и ограничения, которые требуется применять к каждому этапу.
3. Запомните, контрольные процедуры не относятся к формам данных, они относятся к бизнес-логике. Ни один нормальный программист не станет делать контроль сразу в форме ввода информации. Тем более правила сверки, матрицу доступа или что-либо еще. Все это делается уже имея схему данных и модель взаимодействия.
4. Про характеристики модели данных сказано хорошо, но важнее не то, какие будут характеристики (их вычислить ничего не стоит), важно то, какой физический смысл должен быть у объектов бизнес-логики. Не надо объекты процессов и взаимодействия описывать моделью данных — это задача программиста.
5. Автоматическое заполнение данных — это уж точно не то о чем нужно думать. Нужно думать «Зачем в данный момент надо заполнить так, а не иначе?», «Почему я суда должен подставить это?». См. пункт 2. Если программист не понимает физический смысл, он не понимает задачу. А это значит не сможет ее решить оптимально.
6. Формы вывода информации аналогичны пункту 1. Стоит описать не то, как будет выглядеть формочка (названия колонок в таблице отчета не скажут программисту ровно ничего), нужно описывать то, что ожидает увидеть пользователь в результате работы этапа бизнес-процесса. Т.е. те промежуточные данные, которые доступны в ходе выполнения и общий результат, который нужно отобразить. Не связывая этап бизнес-процесса с выводом информации вы просто рискуете получить какую-то ерунду, непонятно откуда взятую (например программист решит выбрать данные из регистра, который заполняется только в следующем этапе бизнес-процесса).
Ну и как показывает практика, хорошему программисту 1С освоить питон удается в разы быстрее, чем хорошему программисту-питонисту освоить 1С:)
Плюсик за попытку.
пример такого ТЗ с 1С если можно выложите плз
Sign up to leave a comment.
Как правильно написать ТЗ на систему или доработку системы 1С