Опишите задачу — подскажу решение
Хороший 1С-программист обычно это не совсем программист. Совсем не потому что язык программирования какой-то не такой. А потому что часто работает не по техническому заданию, а с бизнес-задачей.
Малый и средний бизнес (откуда большинство моих заказчиков) редко может позволить себе платить аналитику за описание процессов, постановку задачи и написание техзадания. Поэтому задача для 1С-программиста может выглядеть например так:
— у нас затраты учитываются котловым методом, а нам надо позаказно.
Тут пока нечего программировать.
Я бы спросил Заказчика какие вообще виды затрат у них бывают и как нужно учитывать каждый из видов.
А если нет списка видов то предложил бы взять затраты за период, разбить их по видам и подумать над каждым видом.
В результате этой работы пожелание Заказчика оформится в то что можно пытаться реализовать на тестовых данных. И только если это не получится реализовать настройками потребуется программирование.
Представим себе что удалось реализовать все пожелания, Заказчика устраивает как все работает на тестовых данных. Все молодцы, расходимся? Нет, впереди еще много интересного)
Нужно внести изменения в рабочую базу.
Но предприятие работает, затраты уже учитываются котловым методом, есть заказы в работе. Надо определиться как считать затраты на такие переходные заказы.
Заказчик должен понимать что если изменения настроек планируются сделать где-то посередине отчетного периода то в дальнейшем будет некорректно сравнивать такие отчетные периоды.
Работа на каких-то участках изменится. Соотв. сотрудников надо предупредить/обучить, дать инструкции, быть готовым оказать поддержку в день Х.
Выводы:
1. 1С-программист не просто пишет код, а помогает формулировать задачу, разбирается в бизнес-процессах, задаёт вопросы и превращает размытые пожелания в конкретные требования.
Особенно ценно если 1С-программист уже сталкивался с подобным типом задачи, получил опыт и готов поделиться этим опытом с Заказчиком.
2. Программирование не всегда первый шаг.
Часто задачу можно решить через настройки системы, без кода. Важно сначала разобраться в данных и логике учета, протестировать решение, и только потом писать код при необходимости.
3. Внедрение изменений может быть сложнее разработки.
Нужно учитывать текущие процессы, обучать сотрудников, поддерживать работу в момент изменений и объяснять последствия для отчетности.
Добавить комментарий