Хочу обсудить вопрос развития учетной системы предприятия с учетом пожеланий пользователей. Для себя разделил клиентов на 2 группы:
1. Постоянные изменения. Каждый пользователь генерирует задачи под себя.
2. Предприятие внедряет какой-то продукт и практически не генерирует новых задач, либо задачи собираются где-то в одном месте и анализируются нужно ли их выполнять.
Больше клиентов с вариантом 1. Но по моему это самый пагубный путь развития. Через какое-то время, не важно штатный прог или франч, система превращается в винегрет из мелких доработок под каких-то пользователей, которые давно, может быть, и не работают на этом предприятии. Если посмотреть в целом на эту систему, то затраты на поддержание такой системы возрастают, возрастают и риски. При этом в целом предприятие, с точки зрения прибыли мало что получает. Это мое мнение. Такой вариант я бы назвал развитие снизу. Лично мне сложно поддерживать таких клиентов из-за того что нет конечного результата. Постоянно появляются новые задачи и в какой-то момент теряется понимание функционала. Я могу конечно некоторые особо глупые задания отказаться выполнять (просто завысим стоимость выполнения), но это не всегда прокатывает.
Есть клиенты которые внедряют почти типовой продукт. Естественно есть доработки. Но их не так много их можно задокументировать. Понятное дело, что типовые конфигурации подходят не под все отрасли. Но 90% всех изменений делается на этапе внедрения. В итоге поддержка такой системы достаточно не дорога. Изменения системы носят эпизодический и достаточно глобальный характер. Этот вариант я бы назвал развитие сверху. Понятно что все "хочу" и "неудобно" при таком внедрении выполняются редко.
Как по вашему, как должна развиваться учетная система компании для максимизации соотношения "эффективность/максимальная адаптация под бизнес" к "затратам на содержание этой системы"? Прошу учитывать не только рублевые затраты, но и затраты на время и риски.
Например когда штатный сотрудник пишет конфигурацию с нуля сам под свое предприятие это хорошо. Но документацию он скорее всего не сделает. Или не будет ее содержать в актуальном состоянии. Поэтому при уходе такого сотрудника есть большой риск начать внедрять новую систему. А это время, деньги и нервы.
Я не говорю о предприятиях у которых в одной базе работают больше 100 человек. У меня таких нет и не предвидится в ближайшие пару лет. Есть также уверенность что в больших базах (более 100 пользователей) первый вариант просто не возможен.
Прошу так же указывать как у вас обстоят дела с заданиями? Кто у вас имеет право выдавать задания? Есть ли у вас план изменений системы на какой-то период?

не читал. КГ/АМ по умолчанию

пора почитать макконела

(2) Это который Экономикс?

(3)
нет.
это который "совершенный код"

+(4)
макконнел

+5
макконнелл

У нас 50+ пользователей учетной системы, изменение УС может быть инициировано абсолютно любым сотрудником (т.е. ответ "3"), далее хотелка оформляется в виде требований, проходя через руководителя инициатора (т.е. ответ "2"), ну а далее, если не бороданули, поступает в экспертный совет (почти что "1").

(4) Так читал еще в институте. Как она согласуется с реалиями 1С-ника?

1. Стараемся определить Заказчика - отв. лицо от клиента за процесс внедрения.
2. Вариант доработок только через Заказчика. Задачи письмом в адрес своего руководителя, а от того - отв. лицу.
Такая схема при ограниченном бюджете.
Если бюджет позволяет или очевидно, что требования объективны (тут можно промахнуться), то "хотелки" реализуются. Объективные "хотелки": от пользователя оперирующего большими объемами данных - тут должно быть удобно, поэтому "хотелки" реализуются по максимуму. Остальные - через "парламент".

(8)
макконнелла в институте читать как крейцерову санату в 3 классе - бессмысленно

(10) У меня должен быть бумажный вариант. Точно помню что покупал. Перечитаю.

(8)

вобщем управление процессом (в том числе и разработкой )
сводится к оптимицации 3 параметров :  сроки, затраты, риски.

фактически имеется 3 модели желаемая, описанная декларируемая, программная

беда разработчиков 1с, что они используют типовые решения
и ленятся описывать модели декларируемые, и боятся их требовать у бизнесса.

в результате имеем хаос . тк неструктурированные и не управляемые отношения бизнесса и инструмента ПО.

при таком упрощении управление измененими в инструменте довольно затратно тк нет модели - нет целевой ф-ции.

нет статистики ошибок реализации модели -> нет управления
качеством разработки.
 
реалии 1с-ника феодальны.
хотите управлять - откажитесь от феодальных 1-ников
переходите к капиталистическим менеджерам и управлением
разделения труда.

это применимо и к 1 разработчику.


собственно ск - подобие капитала маркса: статистичекки выевленные закономерности в отношениях моделей  объект-описание - програмная модель.

(12) Какой процент заказчиков готов такому подходу. Тут проблема, по моему глобальная. Она далеко не только к ПО относится. Сам бизнес(читай собственник, управляющий) должен быть готов к системному подходу. По моему таких заказчиков в лучшем случае 10%.

(0)
>Прошу так же указывать как у вас обстоят дела с заданиями?
>Кто у вас имеет право выдавать задания?
>Есть ли у вас план изменений системы на какой-то период?

Хотелки конкретного клиента, выходящие за собственный план разработок, имеет смысл отрабатывать тогда, когда они повышают потребительскую стоимость продукта и для других клиентов тоже. Критерием оценки служит моё профессиональное мнение, в т.ч. знание предметной области. При отсутствии каких-то очень узких знаний консультируюсь с другими профессионалами, компетентными в данной области.

(7)(9) А у вас доработки где-нибудь документируются? Будет ли пользоваться доработкой новый сотрудник пришедший на место заказавшего?

(13)
тут проблема не только в готовности бизнеса
но и отсутствии в 1с-индустрии квалифицированных кадров.

поэтому управление изменениями - больше формальная техническая задача. управление сроками зачастую превращается в политику лояльности.

управление рисками в завышении стоимости либо сроков.

управления качеством , как целевой ф-ции приближения к модели быть не может.  

тк нет моделей.

опять же при все своей сложности платформы 1с8

разработка для 1с остается прототипной, вследствии отсутствия декларированных фирмой 1с для своих типовых

моделей, по которым строится ПО.  


для прототипов как свойственно отсутствие описаний.

(15) документируются в виде инструкций и в описании бизнес-процессов компании только масштабные доработки, затрагивающие нескольких участников бизнес-процесса и собственно зачастую его и меняющие.
Если же доработка представляет из себя какой-нибудь отчет для руководителя отдела или заполнялку табличной части или проверку перед записью документа, то вряд ли потомок инициатора будет о ней знать и пользоваться.

Нужен руководитель данных изменений, парнишка на столько с здравый, чтоб начальство доверяло ему посылать пользователей нах.

Кроме того, не всем пользователем должно быть дано право общаться с этим небожителем

В одной из контор порядок задач был такой:
пользователь, его начальник, методолог, начальник 1С-ов

(18) Фу блин, столько ошибок сделал. Я сегодня с утра как обдолбаный, прошу простить