Доброго дня, форумчане!

Руководство поставило задачу написать сабж.
У кого есть какие мысли по сабжу?
Замечания, предложения или готовые тексты и т.п. и т.д. и ...
Предлагаю обсудить тему.

1. Программист 1с всем должен
2. Все имеют право чморить программиста.
3. Прграммист 1с не имеет права выражать своё недовольство и всё, что неправильно введено в его программу, считается неправильной работой его программы и подлежит наказанию

Смотря какая структура ИТ-отдела, есть линия поддержки и сколько их (линий).

Если прог один то просто пишешь "Все обращения через хелпдеск, остальное игнорируется" и все.

1. Все имеют программиста, но он закалён и его ипать, только йух тупить.
2. Программист посылает всех на йух, и никто ничего ему не может сделать , кроме как уволить.
3. Линейная или не очень суперпозиция п.1 и п.2

(2) (3) Программист один на предприятии - хелпдеска нет. Если знаете какой, поделитесь

(5)[Программист один на предприятии - хелпдеска нет.]
стандартный еженедельный скрам + бэклог в 1С

(5) В 1С документ добавь "Тикет". Пускай туда пишут.

(6) Срам на одного человека?

(8) скрам на N функциональных заказчиков

(8) Без него ща никуда, ты ч0

(9) Один програмист перед N заказчиков будет рассказывать каждому, что он для него сделал, а остальные N-1 будут тупо терять своё время?

У нас вот такой регламент :)
https://drive.google.com/file/d/1938S-a4ixcLdy8pO8LjccpMxDkTW92tD/view?usp=sharing

(11) Не надо рассказывать, все довольно просто.

Заводится доска магнитная, таблички с надписями.
На каждой табличке пишется имя заказчика и задача кратко с ее номером.
По номеру задачи можно полное описание в веб-системе посмотреть и поправить и история там общения изменения.

Ну и все таблички на доске выстроены в порядке очереди.
Любой новый заказчик или старый с претензиями где его задача отправляется взглянуть на доску...

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

.. выпилены процессы В КОМПАНИИ

(13) угу, это хорошо.
я вел список задач-прjблем в http://www.worksection.com
и сейчас веду.
и пользователи - когда порядок был - туда же писали.

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

(5) Для такой ситуации подходит п.2 из (4)

Я вот думаю набросать конфу на коленке типа вопрос-ответ, что бы история обращений сохранялась в чем-то типа чата,
но это технически, а надо узаконить приказом по организации взаимоотношения между программистом и пользаками.
А для этого нужен регламент. Типа Пользователь сам пытается решить проблему, читает хелпы, ИТС, Главбух и прочие источники, а в случае не способности уже обращается к программисту. Что-то типа такого.
Ну чтобы программист не превращался в заштатного сотрудника бухгалтерии, а как-то оградить его от всякого рода припахивания по любому поводу.

(19) Зачем это одинокому программисту? Делать что ли нечего?

(0) Вот держи приме регламента:
https://pandia.ru/text/80/481/86256.php

(13) Это не срам, это канбан. Колхозный.

Вот еще: https://basegroup.ru/share/support-reglament.pdf

(19) присоединяюсь к (20)
нахрена это? если есть свободное время и делать нечего - можно этим заняться. А так - с вопросом не по существу - посылаешь вежливо нафиг и работаешь дальше.

я в свое время кучу регламентов и обучалок по текущим процессам написал. Ничего более в конторе кроме моего такого - нет (всякие мутные словоблудливые "должностные инструкции" которые для проформы - посылаем нафиг).

Например: 1С БП - рабочий инструмент буха. он ДОЛЖЕН УМЕТЬ им пользоваться. обучение не входит в работу программиста 1С. когда ко мне приходят с тупыми вопросами - есть время - отвечаю, нет - говорю "ищите сами". не можете искать\лень\не умеете - работатйе по старинке, с главной книгой, журналами-ордерами, ведомостями - я не запрещаю.

для того, чтобы "регламенты" работали - в рамках компании д.ю. подразделение\ответсвенный, который определяет КАК будет работать комания и СЛЕДИТ И ОБЕСПЕЧИВАЕТ это. если такого нет - то вякие регламены - это по большей мере ИБД.

(25) У регламентов есть ещё одна важная функция: обеспечение частоты задницы. Чем бумаги больше, тем задница чище.

Пользователь - Начальник пользователя- Начальник программиста - Программист

Это если нет хэлпдеска

(22) Переставляй таблички по тикетам и будет тебе скрам.
В бэклоге все в очереди приоритета, на текущем спринте те над которыми работаешь, далее или сделано или обратно в бэклог или остается на следующий спринт.

(26) это канает только тогда когда регламенты обязательны к исполнению. а это автоматом приводит к необходимости наличия "инфраструктуры" их разработки, утверждения и контроля исполнения. а это - допрасходы.

(22) о юный падаван, ощути всю Силу Скрама канбасом бэклога

(30) От падавана юного слова сии слышу!

(28) +100500
важно стравить между собой зам.генерального/начальников отделов и спокойно сидеть на мисте

(0) 10 к рублей

А задачи какие? Консультации, доработки, разработка нетленки с нуля, внедрение ЕРП?
Если банальный хелпдеск - ищи по шаблону SLA какого-нибудь, пункты стандартные - в какое время производится обслуживание, как подаются заявки, какие сроки реакции, выполнения и т.п.
Если проектная деятельность, то там другая документация. Хоть скрам/эджайл, хоть водопад. Хоть по ГОСТу.

(29) Это канает всегда, просто не всегда доходит до разборок "по закону"

(1) нулевой пункт забыли

0. Пользователи перечисляют программисту по 100к рублей 5-го и 20-го числа каждого месяца, в складчину или из средств фирмы.

и дальше уже пункты

1. Программист 1с всем должен
2. Все имеют право чморить программиста.
3. Программист 1с не имеет права выражать своё недовольство и всё, что неправильно введено в его программу, считается неправильной работой его программы и подлежит наказанию

Ухтыжкакаятема

(19) Регламент. Регламент не нужен. У пользователя есть должностная инструкция. Если там чего о не хватат- дополнить. Если делать нефик, кто ж тебе запретит почтовый клиент изобретать? Если хватит духу наступить на своё желание поконфигурит, просто воспользуйся эл.почтой.

капец

(13) такая?
http://catalog.mista.ru/upload/iblock/27d/27d6f989e880b7a99ff6455ca7a97041.jpg

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

(0) Вот еще нашел: http://catalog.mista.ru/public/16934/

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

Можно лишь выстроить орг работу более четко. Например, использовать листу учета рабочего времени, где фиксировать трудозатраты по задачам. Листы требований - это как ТЗ но на мелкие задачи. Еще чек-листы можно. Ну а регламент это ведь по сути алгоритм действий. Ну вот и описать как у вас обычно проходит эта работа и подкрепить документами сопроводительным. Вот вам и регламент :). Не благодарите :)

(42) Дело не в хрени или в помощи решать задачи а в наглядном отображении для себя и других текущего состояния.
И постоянного напоминания или отмазок для новых задач или почему еще не сделано.

Какой пендель и за что? Придет желающий дать пендель посмотрит на ФИО тех от кого задачи и тихо уйдет.

Первое с чего надо начать - ответить на вопрос что ждет от отдела владелец. Может для него поддержка невсралась, а нужно решать более важные задачи
Второе - система приема заявок и задач. Готовое ли решение на 1с, или ДО, или самописка, или Жира - не важно, должна быть система учета, для того что бы внятно ответить что было неделю\месяц\год назад
Третье определиться и зафиксировать какие задачи важны, какие нет, исходя из этого строить план работ. В идеале этим должна заниматься третья сторона.
Четвертое - скурпулезно вести этот учет

(46) Предлагаешь вместо выделения денег и найма еще спецов (прогов, консов, саппорта, админов и т.д.) потратить деньги на систему учета, канцелярщину с бюрократией и дополнительными кадрами в лице третьей стороны?

Это когда на одного Васю десять начальников и прочих обслуги, а сокращают первым Васю если что.

(47) А как ты обоснуешь что надо еще спецов?
Система учета пишется за пару часов, не надо сказки рассказывать, вся эта канцелярщина не более часа в неделю занимает.

(48) Особенно когда у тебя нет непосредственного руководителя?

(48) "Руководство поставило задачу написать сабж." из (0)

Вероятно там нехрен делать вот и поручают еще самоавтоматизацию.

На ИС есть за СМ вполне годные вещи. + можно в ДО.

(50) Нормальный процесс совершенно.

(51) Все это для целей "Регламент взаимоотношений" заменяет (13) :)

(53) Но это чисто оперативная расстановка, и имеет смысл когда задач немного.
Работал я по такой схеме, но там что бы бумажка пошла на доску - перед этим 2 административных фильтра

А если любой подойди и налепи - то через неделю утонешь

Но согласен что некая система описания и учета задач (с номерами), причем веб нужна.

(56) Да блин примитивная канбан доска на ДС за пару часов пишется.

(54) (55) Хоть залепись но вперед приоритета не вылезешь из бэклога.
Или или к тем кто поставил задачи с приоритетом выше и двигай их.

(58) А это уже и есть та самая бюрократия, которой быть не должго.
Совещания о смене приоритетов и так далее)

(57) Ну про доску я та для примера привел, автоматизации подручными средствами.
По уму надо в браузере это делать

(59) Они без исполнителя проходят, ему пофиг кто там вперед из банки пролезет ))

(60) Ты устал от c++, отдохни) Для 1го - 5 человек 1сного решения достаточно)

(61) От исполнителя только примерная оценка срока выполнения каждой задачи и все.
Дальше хоть засовещайтесь.

(62) Так я и отдыхаю тут, переключаясь.

(62) Потом да, конечно jira удобнее.

Завтра вот на Хакатончик пойду ))

(65) Не вижу большой разницы с Trello

(67) А она есть. trello как то урезаннее что ли? я в жире могу все, трелло, когда я его в последний раз видел, примитивнее что ли был

(21) Спасибо.
(24) Для того и нужно, чтобы законно (в рамках приказа) отправить пользака изучать матчасть, а не оказывать ликбез по глупым вопросам. А иначе программист получается тварь бессловесная и отказать никому не вправе, вот и нагружают его все кому не лень, лишь бы самому не разбираться. Прав (26) - это прикрытие.
(38) Интересное предложение - поменять буху должностную и вписать туда пункт о компьютерной грамотности и уровне знания программ 1С.
от (44) и ниже - Хелпдеск нужен. Нужен, хотя бы для оценки загруженности программиста. И, думаю, большинство со мной согласятся, что сейчас все больше и больше требуются не программисты, а консультанты-методисты которые знают функционал той или иной конфигурации и одновременно знают методики учета - зачастую основные вопросы от бухов - я не могу сделать то-то и то-то и возникают они  по причине банального не знания функционала программы и неумения ею пользоваться, а удел программиста все-таки разработка, кодинг, автоматизация, настройка и обслуживание баз и конечно исправление ошибок - если это касается технической части. А так как порой программист на предприятии один, во на него и валится все. ПОЭТОМУ и нужен регламент.

(11) Это делается любым багтрекером или корппорталом.

(48) вряд ли на одного программиста более десятка заказчиков. поэтому можно тупо взять бесплатный битрикс на 12 рыл, загнать туда заказчиков, пусть смотрят на выполнение задач. задачи ставить только в письменном виде,  можно письмом на почту - битрикс вполне нормально ставит задачи из почты.  Будет видна и загрузка программиста. и поток выполнения задач. и выполнение задач, и даже глупость постановщиков.

Тоже интересно почитать! У нас схожая ситуация. Первоначально требовался программист (корректировка, настройки, обслуживание). Сейчас все кому не лень звонят по любому вопросу, доходит до того, что советуются на какой счет им что отправить (бухгалтерия).
Сначала заявок было не много, в принципе не напрягало, ответил, все довольны. Но сейчас ножки свесили и сидят, даже не могут справкой нормально пользоваться. Чуть что сразу волна возмущения.
Сейчас веду с ними борьбу, формируем правила обращения и разграничиваем обязанности. Иначе я уже не программист, а техподдержка какая-то.
Бурчат, жалуются, но другого выхода не вижу.

Солидарен со многими. Мне довелось работать в нескольких фирмах. Когда бухгалтера помоложе и покладистей, то проблем нет, все понимают. Но на одном месте работы сидели тетки, с которых песок сыпался. Сколько я с ними нервов потратил. Пока не послал одну из них не успокоилась.

(72) ну вот попроси их написать вопрос "на какой счет" почтой. А потом это письмо покажи директору и поинтересуйся - соотвествует ли их квалификация требуемой. а вопросы - вопросам к программисту.

(74) Да так и получилось. Не поленился и фиксировал все их вопросы, потом с этим списком к руководству. С этого момента война. Но зато меня теперь только по делу спрашивают и все официально. Согласно приказа я их могу вежливо послать и заниматься тем чем должен.

(71) Последний раз на одного программиста было порядка 150 пользаков по 37 базам на 17 различных конфах - уволился. Теперь 45 пользаков на 3 конфы плюс дикие обмены - так что никак не десяток - 10 пользаков это даже не мечта.

(75) Не поделитесь текстом приказа?

(77) Бьюсь об заклад, что пользователи Ваши вредные тетки или бабули.

(77) Привыкшие работать так, как привыкли. Любые изменения - истерика.

(0) Сколько программистов в распоряжении?
Как разделены между ними обязанности?
и т.д. по мере ответов

(5) Тогда выход один
1. Всех младших сотрудников обязать четко  (по возможности) формулировать хотелки.
   Хотелки принимать в эл. почтой, не заморачивайся с хелп фигней и другой лабудой, навязанной спецу мего гуру с курсов, под предлогом - "А так типо по инновации" :)
2. Всех кого не сможешь построить, придется самому записывать задания от таких ВИП персон :)

(36) С таким подходом, вашего программиста размажут за год, и будут искать нового программиста :)

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

(69) А у тебя самого что в ДИ написано??? Мне как-то сложно представить, что в конторе кто-то будет пересматривать ДИ бухгалтеров с целью облегчения жизни ИТ.
Все это нереалистично и смешно

(1) +1. Все так и есть. На нескольких работах подписывал это.

(77) Сам текст приказа досконально не помню. В нем несколько пунктов:
1. Ссылка на должностную инструкцию пользователей (бухгалтера, продажники). Там уже пришлось дописать, что они обязаны знать базовый функционал, уметь обращаться со справочными материалами и т.д.
2. Ссылка на должностную инструкцию программиста 1с. Тут уже расписаны полные правая и обязанности программиста.
3. Ссылка на документ схема взаимодействия пользователей и программиста. Вопросы ранжированы по степени важности и приоритетности.

(84) в том то и дело - ДИ типовые, что у бухгалтеров, что у программиста, но есть желание не облегчить жизнь программисту а упорядочить взаимодействие, тут одними ДИ не отделаться. Программист не только же с бухами работает, есть еще и другие участки где работает 1С

(87) Не прокатит. Мечтай о высоком

(87) Если хочешь упорядочить работу и не заморачиваться по всякой фигне, переводи на работу через СЗ. Поскольку подраделения разные, то подписывать СЗ будет куроводитель. И если он не дурак, то откровенную фигню не выпустит за рамки своего подраделения, а если и выпустит, то куроводитель программистов в ответе на СЗ может это разложить по полочкам. Но взятое в работу придётся выполнять в срок.

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

(17) "емайлы отвергнуть напрочь" - пффффф... Емайл - это очень хорошо. Намного лучше телефонного звонка: "сделайте нам хорошо".

(87) Если понадобился регламент - значит у вас нехватка ресурса (в данном случае "программистов 1С").

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

(91) +1, Email это первый уровень, для одного программиста и небольшого количества задача вполне достаточно. Если начинаешь путаться в письмах, тогда уже нужно думать о каком то сервисдеске.

Кстати, администрировать базу саппорта, объяснять юзерам, как в ней работать - тоже отдельная работа. Кто и как это проблему решает?

(92) не обязательно. это может быть нагружение ресурса несвойственным ему задачами.
Если "программисты1с" будут вместо программирования объяснять, какой счет использовать - то "потребность в ресурсе" сильно возрастет. но это совсем не значит, что нужны именно программисты.

(94) Массовая разовая демонстрация для всех / для глав отделов перед внедрением ("как это будет выглядеть и работать"), далее инструкция по созданию заявки и ведению переписки и принятию или отлупу задач в письменном виде в общий доступ с посыланием конечного заявителя туда

(96) И карательные меры, без них ничего не работает.

(97) На прошлом фиксе это решалось без карательных мер - просто инициатор не может создавать новых задач и писать комментарии к задачам, если мяч хотя бы по какой-то задаче на его стороне. Быстренько оперативно стали отвечать )

(98) Иногда такую "пургу" гнаьт начинают... И если прог один, то большинство мячей всяко останется на его стороне.

(87) А у вас руководитель есть? Он чем-то помогает или что-то советует?

(99) Конечно же нет, ибо если пурга то задача возвращается автору на уточнение постановки вплоть до момента когда она перестает быть пургой, либо отсекается. А уж не пургу надо делать - с этим ничего не поделаешь.

(101) Всё проще, нужно только лишь определить список тех, кто может писать по задачам. Тогда на всякий бред вообще можно не отвечать.

(102) Это "строгий" вариант, простым людом может быть воспринят в штыки. Как вариант не запрещать, но визирование его начальником сделать обязательным.

(103) У нас контора немаленькая, приходится поступать жёстко.

(95) Это один хрен недостаток ресурса и попытка нагрузить этим имеющиеся в зоне доступа.

(1) глупости.

(87) простая действенная схема:
1. пользователь через корпоративный чат обращается с вопросом к программисту, получает ответ (тут можно регламентировать максимальное время на ответ);
2. по результатам п.1 возможен созвон, для уточнения и обсуждения вопроса (тут регламентируется максимальное время телефонной консультации, допустим 5 минут);
3. если по итогу п.1 и п.2 решение вопроса пользователя не найдено - оформляется заявка на электронную почту, где подробно описана суть проблемы, условия ее возникновения, указано поведение системы и ожидаемое поведение, со ссылками на инструкции/методику.
4. раз в неделю/месяц разгребаем чат/почту, собираем отчет по выполненным обращениям, анализируем, если по каким то вопросам становится много повторных обращений - переделываем эту часть, проводим обучение, пишем инструкции.

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

Какое-либо изменение должностных инструкций бухгалтера (любого другого пользователя 1С) - это идиотизм. Никому ведь не приходит в голову вписать в должностную инструкцию каждого сотрудника обязанности выкидывать мусор строго в корзину, а не на пол, сливать за собой в туалете, уходя  домой выключать свет в кабинете и т.п. Для таких вещей как раз и существуют регламенты, распорядки и инструкции (не говоря об общепринятых нормах проведения - соблюдать чистоту).

Обычно упоминание об умении пользоваться ПО ограничивается одной или двумя фразами. И это правильно. В противном случае можно к каждой ДИ прикладывать руководство пользователя к десятку программ (ведь помимо 1С ещё существуют всяческие офисные приложения), к операционной системе, инструкцию по пользованию калькулятором, принтером, ксероксом и т.п.

ИМХО, регламент должен содержать буквально несколько пунктов в свободной форме (отдельно по поддержке и отдельно по разработке (доработке) нового функционала:
1. Каким образом должно происходить обращение за поддержкой. Тут достаточно просто - никаких заявок по телефону (естественно за исключением топов - они всё равно будут звонить напрямую). Если есть какая-либо система типа HelpDesk (HD) - то через эту систему, если нет - то только по электронной почте.
2. Прописать скорость реакции на заявки - например, в течении рабочего дня задача должна быть либо решена, либо по ней должны быть определены сроки решения (дни, недели, месяц).
3. Всё общение максимально через систему HD или по через почту. Общение по телефону только когда это реально требуется и в рамках поданной заявки.
4. Порядок согласования заявок на доработку систем. Такие заявки должны быть исключительно через служебную записку с приложением хотя бы краткой постановочной задачи. Кто может инициировать доработку (любой пользователь или только руководители, например, отделов), кто должен её утвердить (что она реально нужна и именно в том виде, в котором запрашивается), кем согласовываются сроки исполнения (исходя из озвученных программистом трудозатрат и утвержденных приоритетов и всех прочих задач в очереди). Роль двоих последних обычно исполняет тот, кто является непосредственным начальником программиста.
5. Порядок тестирования, приёмки и перевода в продуктив доработок.

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

(87) По факту нужен не программист, а консультант-методист который как справочное бюро разъяснял бы как и что делать в программах 1С

(92) По факту нужен не программист, а консультант-методист который как справочное бюро разъяснял бы как и что делать в программах 1С

(98) Шикарное решение - надо взять на вооружение

(112) > Шикарное решение.

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

За что должен отвечать программист?

(114) За базар

(109) Немного не соглашусь. Очень много зависит от руководителя программиста, ведь как только он будет вежливо отшивать пользователей за несоблюдение регламента, то побегут к нему. Всё-таки работа с людьми и выстраивание взаимодействия - это работа руководителя.

А до этого на предприятии не было программиста? Как они решали свои задачи?

(116) Это уже частности, зависящие от конкретных условий и конкретных людей. Может быть очень и очень по-разному. Например, если программист подчиняется директору или кому-то из его замов (в условиях отсутствия вообще отдельной ИТ-службы со своим руководителем), то вряд ли директор будет париться на тему выстраивания взаимодействия для программиста - это не его уровень, ему нужно, чтобы задачи выполнялись и системы работали стабильно, а не сопли за 1С-никами вытирать.

(118) Чьи задачи?

(119) Ну явно предприятие раньше пользовалось 1 С и кто-то занимался его сопровождением. Имею ввиду задачи по 1С как-то же решались ранее.

(117) До этого программиста на предприятии не было. Франч настроил конфу и пока она не умерла, работали в ней.

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

Предлагаю текст регламента, сильно по почкам прошу не бить. Собрано из разных источников в интернет и переработано. Заранее прошу прощения, если кого сплагиатил - не корысти ради, а истины для.

Регламент взаимодействия пользователей.

Основные положения
1.    Настоящий регламент определяет правила взаимодействия пользователями программных продуктов компании «1С» и программистом 1С.
2.    Положения данного Регламента обязательны к исполнению всеми участниками взаимодействия в ходе эксплуатации, сопровождения и развития программных продуктов компании «1С» используемых на предприятии.
3.    Основными участниками процесса взаимодействия являются:
3.1.    Пользователи – сотрудники предприятия, в своей повседневной деятельности использующие программные продукты «1С»,
3.2.    Руководители подразделений, в которых работают пользователи
3.3.    Руководители подразделений, ответственные за данные в базах по направлениям учета
3.4.    Руководитель подразделения, в котором работает программист 1С
3.5.    Программист 1С
4.    За данные в базах программного продукта отвечает руководитель подразделения по направлению учета.
5.    За доступ к данным отвечает руководитель подразделения по направлению учета. Он определяет, кому, и с какими правами дать доступ к данным в базах. Он своевременно оповещает программиста 1С о прекращении полномочий пользователей в виде служебной записки на закрытие (ограничение прав).
6.    Любые изменение прав доступа любого пользователя оформляются только в письменном виде руководителем подразделения пользователя на имя лица, отвечающего за ведение данных в базах по своему направлению. Допускается указание лица с аналогичным набором прав для копирования настроек доступа – это значительно сократит время настройки прав конкретного пользователя. Программист 1С может изменять права доступа только после визирования служебной записки лицом, отвечающим за ведение данных в базах.
7.    Датой запрета изменения данных управляет руководитель подразделения по направлению учета, либо назначенное им лицо, из числа своих подчиненных.
8.    Программист не отвечает за внесение (ввод) данных в базы, не делает заполнение справочников, не перепроводит документы, не производит настройки учета и не выполняет подобного рода операции, которые можно выполнить без использования кодирования.

Возникновение задачи

Программисту для работы над задачей необходимо держать в голове громадный объем данных, что-бы не упустить что-нибудь важное. Отвлечение от работы просто пускает "под откос" наш, уже разо-гнавшийся "локомотив" и поставить его обратно на рельсы занимает очень много времени, сильно раздражает, и что хуже всего, способствует появлению новых ошибок. - этот абзац нужно переделать - написать казенным языком

Пользователь пытается найти ответ на вопрос самостоятельно, используя материалы ИТС; нормативно-правовую базу методологии учета; методические материалы компании «1С» в части использования типового функционала; информацию, переданную консультантами исполнителя по внедрению программного продукта в части работы с доработанным функционалом. В случае неудачи Пользователь обращается за консультацией к программисту по телефону.
1.    Программист по телефону оказывает только консультативную помощь.
2.    Если задача не решается в рамках телефонного разговора, она может быть оформлена служебной запиской на доработку, устранение ошибки или на изменение прав доступа к данным.
3.    Служебная записка должна быть завизирована руководителем подразделения пользователя и согласована с лицом, отвечающим за ведение данных в базе. Если это одно и то же лицо, достаточно одного согласования.
4.    В служебной записке обязательно указывается автор и его контактные данные.
5.    Время решения задания программистом определяется исходя из сложности задания и того, на-сколько полным было описание задания в служебной записке. Программист вправе задавать уточняющие вопросы как путем диалога (например, по телефону) так и в письменной форме.
6.    Пользователь - инициатор задания не может создавать новых задач, если хотя бы по какой-то од-ной своей задаче он не ответил. Бессодержательные ответы будут возвращены пользователю обратно.
7.    По выполнению задачи пользователю дается определенное время на проверку решения, в зависимости от сложности от 1 дня до недели. Пользователь обязан протестировать решение и дать оценку, установив нужный статус. По истечении этого времени претензии к выполнению - от-дельной заявкой.
8.    Обращения, по которым в течение месяца не было никакого движения – автоматически считаются выполненными.

Постановка задачи.
Это самый важный момент.
ПОМНИТЕ, ЧЕМ ЧЕТЧЕ ПОСТАВЛЕНА ЗАДАЧА, ТЕМ БЫСТРЕЕ И ТОЧНЕЕ ОНА БУДЕТ СДЕЛАНА!
1.    Программист получает задания только в письменной форме в виде служебной записки на бумаге или по электронной почте. В заголовке служебной записки должно быть указано название задачи и пометка о срочности/важности выполнения. Программисту запрещено принимать задачи устно, по чату, по телефону, по SMS-сообщению, в ICQ или Skype, а так же других формах передачи информации.
2.    Каждая задача оформляется отдельной служебной запиской, подзадачи отдельными пунктами служебной записки. Недопустимо в одной служебной записке высылать несколько задач.  
3.    Пользователь может указывать сроки исполнения задач, но эти сроки расцениваются как желательные. Пользователь может сделать ремарку - «срочная», «приоритетная», «не срочная», и при-вязать сроки к календарю, ориентируясь только на рабочие дни. Приоритетность задания программист определяет самостоятельно, после анализа задачи.
4.    В случае отправки служебной записки по почте заголовок служебной записки указывается в теме письма. Любые дополнительные материалы к задаче должны прилагаться к письму. В теле письма должно быть указание на то, что сообщение отправлено с приложением. Ничего лишнего к задаче прилагаться не должно.
5.    Текст служебной записки должен содержать максимально детализированное описание задачи с указанием всех документов, отчетов, печатных форм и других объектов, имеющих отношение к задаче, а также подробное описание функционала работы указанных объектов. Для печатных форм прикладываются образцы макетов, шаблонов и т.п. виды содержимого бумажных документов. Описание задачи должно быть конечным и не содержать двойственного и субъективного толкования.
 
если, что упустил - дополняйте

Занятный регламент.
Только это не регламент, а памятка для пользователей, которую читать никто не будет.
Регламент должен быть формализован, к нему прикладывается SLA, всё это утверждается у высшего руководства и под подпись отдаётся всем руководителям подразделений на ознакомление.

Но для начала тоже сгодится, в принципе.

Кто ж эту прпостыню читать будет

(123) Все конечно по делу по тексту, но у нас к примеру набирают контингент продавашек которые НДС выделить из суммы не могут. Хотя при найме все весело гривой машут что знают 1С , знаю много регламентов продаж и т.д. , у некоторых за плечами в ТК более 5 лет работы и бла бла бла.

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

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

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

(0) Ты как челобитную царю (программисту 1С) подаешь холоп? (любой пользователь 1С, кроме главбуха и гендира)

(124) это уже детали оформления

(126) Куча плюсов вам - ибо все сказанное прочувствовано на собственной шкуре. Сломать такую систему можно только административным путем. Поэтому и необходим регламент - что бы как-то расставить точки на Й. большинство пользователей даже не видят разницы между программистом и консультантом-методистом. А так как, обычно, программист, на предприятии в одном лице - валят все на него.

Удачи! Потом поделитесь как пройдет внедрение регламента.

(131) Регламенты, регламенты... Надо быть клиентоориентированым и будет Вам счастье. Ваша задача - решать проблемы пользователей, а не программировать ради программирования

>Ваша задача - решать проблемы пользователей

Задача энтерпрайз разработчика - решать проблемы бизнеса и помогать его развитию, что ооочень часто идёт вразрез с хотелками пользователей.

(134) Давно бизнес перестал быть пользователем?

(133) А если у пользователя ПМС - тоже решать?

(0) У нас было так:

Если рядовой пользователь (бухгалтер/менеджер обращается непосредственно к программисту - штраф 500 руб.)
Если начальник отдела обращается к программисту - штраф 1000 рублей.
С программистом взаимодействует только директор, он же хозяин фирмы. Конфигурация самописная. Директор дает задание на доработку, принимает работу, доводит новый функционал до начальников и разбирается с претензиями. Начальники в свою очередь ведут аналогичную работу со своими подчиненными. На мой взгляд идеальный вариант для небольшой компании.

(135) Давно

(135) Если это не ларек - пользователь никогда там не был бизнесом.
Если всех и каждого целовать в жпо - никакого развития не будет, ибо никаких ресурсов не хватит.
Если выполнять все хотелки - начнётся бардак, ибо хотелки одних будут противоречить работе/хотелкам других.
Пользователь может вносить предложения по оптимизации того кусочка процесса, в котором он участвует. А вот принимать решения о целесообразности этой оптимизации, понимая всю структуру процессов, их цели и маршруты, он не может. Этим занимаются аналитики, архитекторы и прочие компетентные люди под руководством топ-менеджеров, вносящих свой "одобрямс".
Поэтому "поддержание штанов" на основе хотелок пользователей - полная чихня, ведущая к костылям, велосипедам, разброду и шатанию в информационной системе.

(134) Поддерживаю. Бизнес не пользователь - бизнес заказчик. Пользователи - сотрудники бизнеса. вещи разные.

(136) Если ПМС у ГлавБуха, а ты хорошо зарабатывающий архитектор 1С, то должен решить и эту проблему

(140) Бизнес - это люди

(141) А решить лично или можно нанять исполнителя?

(143) ПМС надо решать головой, а не головкой

(0) если встает такой вопрос, то нужно уже второго программиста искать

(145) Поддерживаю, на предприятиях от 1000 человек должен быть 1 консультант 1С и 1 программист 1С, причем на внедрение нужно брать дополнительные силы.

(137) какая-то ерунда. А если по каким-либо причинам были искажены данные, ГД должен принимать решение, кто будет их корректировать? Ему , похоже, делать нечего, как этим заниматься. Никакой ГД никогда не будет таким заниматься, ему проще полконторы уволить, чем пятую точку на такое дело поднять. Не фантазируйте.

(146) на таких предприятиях есть отдел ИТ. Там есть подразделение разработчиков и подразделение сопровождения, тк свет клином на одной 1с не сошёлся.

(123) Всё-таки у программиста есть хоть какой-то руководитель. И вы своим так называемым регламентом посылаете его нафик. Не вздумайте эту писанину показать или ему или другому руководителю. Упадёте в их глазах.

(149) а причем тут руководитель программиста?

(149) Задание на разработку такого регламента я получил именно от руководства. Ему (руководству) важно навести порядок, а не разбирать постоянные перекладывания типа "моя работа - не моя работа" и жалобы по любому поводу - "программа не работает", и мне, как программисту, регламент нужен, что бы не вздрагивать от каждого звонка от бухов ии не выступать в роли няньки - консультанта когда у них, что то не получается.

Идеи иссякли?

Все это пустые хлопоты.

(151) консультант по 1С всё равно нужен, никуда от этого не денешься.
Либо нанимайте еще одного человека либо целую компанию

(137) Директор дает задание на доработку, принимает работу, доводит новый функционал до начальников и разбирается с претензиями.

Я не знаю, насколько маленькая должна быть компания, чтобы это работало, может 20 пользователей? Если даже 50-100 пользователей директор  уже не в состоянии разобраться со всеми особенностями программы, задач, работы пользователей.

(12) оставить только искреннее сочуствие

(0)
1. Все постановки задач от одного лица или от нескольких руководителей подразделений.
2. Строгая очередь задач. Пприоритет выставляет одно лицо или рук-ли подр-й
3. Строго описать что ты делаешь и что не делаешь. Например перетаскивать компы. Или запправлять принтера. Вопросы касательно винды или офиса мимо кассы.

итп

А вы изначально с какими условиями устраивались на работу? Почему сейчас начинают свешивать все работы, от которых вы пытаетесь откреститься? Мне кажется вам изначально нужно обговорить с руководством ваши обязанности и донести это до пользователей. У них уже не будет возникать желания обращаться к вам по любому поводу. Если у меня есть обязанности программиста, то я не консультирую какую кнопку им нажать, чтобы 5 рублей с одного счета ушли на другой - если это базовый функционал. Но если я делаю доработку формы, проводки или обмена, то уже по этому поводу я проконсультирую пользователя,если нужно напишу мануал (а потом на этоту инструкцию их благополучно посылаю).

(158) А изначально была должностная инструкция скачанная из интернета в которой программист обязан разрабатывать методы и формы ведения учета товарооборота и штат юзеров с возрастом 50+, плюс неправильная автоматизация франчем, который переводил с КА и перевел на ЗУП Проф + БП Корп + УТ, через обмены - в них дописали все, что было интересного в КА (вот бы официально сделать аудит проекта и выставить франчу ... ), плюс не было штатного программиста 1С на момент перехода - вообщем все как всегда, список можно продолжать до бесконечности и, думаю, каждый практикующий программист сталкивался с подобным. Вопрос как навести порядок, как грамотно обозначить функционал программиста 1с, чтобы он не превратился в офисного уборщика на которого свешиваю свою некомпетентность юзверя. Программист 1С - это специалист или санитарка для уборки жизнедеятельности в базе? Прав у такой должности то совсем нет никаких.
У большинства людей, и не важно в какой организации, ложное, на мой взгляд, представление о том, чем должен заниматься программист 1С. Поэтому и поднял этот пост.

(159) Ну это понятно, что на предприятии были свои тараканы. Я имел ввиду, при устройстве на работу вас же должны были ввести в курс дела, чем вы будете заниматься?

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

(0) цель какая? Что этот регламент должен дать такого, чего без него нет?

(13) это когда ты сам себе режиссёр и один в поле воин. А когда у тебя на стороне бизнеса одна задача, а у тебя их десять у разных исполнителей, доска это превращается в геморрой с кулак.

(161) Цель? Административно заверенный документ, разграничивающий деятельность программистов и пользователей.

(163) любой опытный пользователь этим документом подотрется банальной фразой "У меня вся работа встала из-за программиста, который мне ботинки не чистит!" и директор скорей всего встанет на его сторону "ну тебе же не сложно, помоги ему".

(164) В таком цирке проекты не взлетают

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

https://ru.wikipedia.org/wiki/Соглашение_об_уровне_услуг

(159) "Вопрос как навести порядок, как грамотно обозначить функционал программиста 1с, чтобы он не превратился в офисного уборщика на которого свешиваю свою некомпетентность юзверя. Программист 1С - это специалист или санитарка для уборки жизнедеятельности в базе? Прав у такой должности то совсем нет никаких. "

Ну так и пропиши, что ты считаешь должен делать, а что нет. Оформи как в (167), отдай на утверждение

Тут главное не переборщить с регламентом. Иногда директор к юзерам больше прислушивается.

(168) смотри (123)

(163) это "блаблабла", а не цель. Какую твою _проблему_ должен решать этот регламент? Или - не твою.

(171) Проблему перекладывания пользователями части своего функционала на программиста, например ведение различных справочников, управление датой запрета изменения данных, поиск ошибок (всегда проще сказать, что программа глючит), само исправление ошибок (сделай, ты же умеешь ...) ну и т.д. Вот и я спросил у народа высказать свое мнение о разделении функционала: где поле работы программиста, а где пользователя. А документ нужен на уровне приказа, что бы все понимали чем должен заниматься программист. А кто лучше самих программистов скажет о своем функционале?

(172) А кто будет решать, кому какие вести справочники, кто будет управлять датами запрета и корректировать регистры? Не Вы же? Кто-то должен выполнять функции администратора 1С.

С таким подходом, пользователи могут сказать, я хочу работать в программе, которая не глючит. Моя обязанность вводить данные, и он уверен, что данные верные, а программа не считает. Вы считаете, что в этом случае тоже пользователь должен разбираться?
Исходя из всей переписки получается следующая картина: в вашем случае одного программиста мало, нужен консультант, нужен администратор 1С, т.е. + 2 человека. Ели таких нет и не предвидится, то вся подобная работа будет складываться на вас.
Если  даже вы пропишете регламент, не трогайте меня, я только кодить буду, без дополнительных специалистов не видать вам такой работы.

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

(174) Работу консультанта методиста точно не надо перекладывать на программиста. Функционал Администратора 1С можно разделить с пользователями, я же не прошу их заводить учетные записи пользователей и раздавать права доступа, я только спрашиваю кому и какие права настроить.

А вот по поводу "Моя обязанность вводить документы" отвечу фразой возможно даже с этого форума, к сожалению, не назову автора
"Программы 1С - инструмент пользователя (а не программиста). Пользователь должен знать свою предметную область и квалифицированно применять имеющиеся знания с использованием инструментальных средств. При нынешних объемах информации требование для пользователя отличного знания работы в программах «1С» - безусловное требование к любому специалисту. Кто не удовлетворяет этим требованиям - идет в ОПЕРАТОРЫ, с записью в трудовую книжку именно "оператор" а не «специалист». Программа за Пользователя думать не будет, а если нет знаний в своей области, тогда незачем занимать должность специалиста."

Да и первичку в основном вводят клавощики, снабженцы и т.п. а бухи обрабатывают уже введенные документы. и как как бухгалтер и должен проверять правильно ли у него отчет сформирован или нет, а если делал доработку у программиста, то обязан ее принять и протестировать.

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

8.    Обращения, по которым в течение месяца не было никакого движения – автоматически считаются выполненными.
- Лучше так:  Обращения, по которым в течение месяца не было никакого движения – автоматически закрываются с пометкой "неактуально".  В конечном итоге ты сможешь проанализировать, кто тебя грузит реальными задачами, а кто - всяким "шлаком".

Программисту для работы над задачей необходимо держать в голове громадный объем данных, что-бы не упустить что-нибудь важное. Отвлечение от работы просто пускает "под откос" наш, уже разо-гнавшийся "локомотив" и поставить его обратно на рельсы занимает очень много времени, сильно раздражает, и что хуже всего, способствует появлению новых ошибок. - этот абзац нужно переделать - написать казенным языком
  - просто убрать.

В регламенте описывается порядок работы и ответственные лица. А тут описана причина. Причину в регламенте указывать не нужно.

(0) Никакие регламенты вам не помогут.У вас изначально неверная позиция.Программист-консультант может случиться в компании 2-5 человек,не больше.Вам просто это надо принять как аксиому.

(177) По п. 8 согласен с вами. а п. 6 как раз и выступает в качестве защиты от спама

(172) Желание понятное и цель в принципе верная, но ...
Как правило все упирается в фигуру генерального папы. Обычно ему фиолетово кто и как разгребает косяки, главное чтобы проблема была решена. А программист это сделал или юзер по инструкции - ему не важно. В случае конфликта папа обычно на стороне юзеров. В подписании каких-либо Регламентов папа обычно не заинтересован, конфликты решаются в режиме "ручного управления".
В свете этого шанс получить Регламент невелик. И даже если он получен - ты его еще попробуй соблюсти. Вот есть у тебя Регламент, ты написал кучу инструкций для юзеров, на все случаи жизни. И тут на работу принимают тупого родича генерального ... Он нихрена не умеет, инструкциями пользоваться не желает. Чуть что - орет и зовет прога чтоб разгреб его косяки. Руководство тебе скажет "Вася, у нас конечно есть регламент, я помню, но тут такое дело, сделай что он просит"
И вот тут надо иметь просто чугунные яйки чтобы не поддаться. Ибо если один раз прокатит - про любые регламенты можно забыть навсегда
Так вот много ли таких прогов, которые скажут боссу "Полиграф Полиграфыч, я Вас конечно уважаю, но делать за кого то не буду. Пусть читает инструкцию" ???

(181) Сначала статься с итс,если далее изображает тупняк то идем на ступеньку выше.В 70% прокатывает,бывает сложные случаи конечно

(181) Верно пишете. Для генерального главное, чтобы работа выполнялась. И как правило,часто в таких случая прилетает не юзеру, а программисту)

(180) "По п. 8 согласен с вами. а п. 6 как раз и выступает в качестве защиты от спама" - ты рассматриваешь задачу со стороны программиста. Нужно помнить, что основная задача ИТ-отдела (пусть даже в лице одного сотрудника) - повышать эффективность бизнеса в целом.  И если владелец бизнеса скажет тебе "Надо, Федя! Надо!" - будешь делать. Короче говоря, вариант "инициатор задания не может создавать новых задач, если хотя бы по какой-то од-ной своей задаче он не ответил" работать не будет.

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

(184) [ариант "инициатор задания не может создавать новых задач, если хотя бы по какой-то од-ной своей задаче он не ответил" работать не будет.]Будет если подписать у генерального и если нач ИТ отдела не губошлеп

(183) Вот я и хочу в какой то мере защитить программиста

(182) Я чаще всего наблюдал картину что никакого регламента на фирме нет, папа сам решает кому какой косяк разгребать. Это часть его власти, неотъемлимая и очень важная.

Второй случай - регламент есть, но довольно быстро он начинает нарушаться. Сначала для кумовьев/племянниц, потом для некоторых заслуженных лиц ("Ну ты пойми, Сидор Степаныч у нас заслуженный работник, да и в возрасте уже, некогда ему инструкции читать, сделай ему сам ..."), потом для группы таких лиц ("Федя, бухгалтерия зашивается, у них квартальный отчет, а ты тут со своими инструкциями ..."), а потом для всех подряд. Через полгода регламент превращается в пипифакс

Отстаивать работу по регламенту - надо иметь недюжинные нервы, мало кто решается на конфликты с верхними боссами

(188) У меня наоборот наблюдение,при этом я на этом берегу уже обговариваю этот момент.Если нет фактически исполняемого регламента то вряд ли пойду к таким.И отстаивать не моя забота,я доступно поясняю что и как

+ к (189) Кстати,по моим наблюдением это в большей мере беда регионов,в столичных менее развито

(175) >> Весь этот функционал - это действия руководителя отдела пользователя, либо лица. ответственного за учетную политику.

А в фирме есть лицо, официально ответственное за учётную политику? Это скорее всего крупный начальник - гл.бух, например. И как это будет выглядеть в реале? Гл.бух сидит - и корректирует права на дату изменения данных каждого кладовщика и мастера смены. А руководителям подразделений это предоставить - что будет? Начальник цеха шасть - дал доступ своему мастеру на корректировку прошлого месяца. Гл.бух глядь - баланс перекосился. Периодически возникающие косяки в данных сами юзеры могут найти и исправить далеко не всегда. Не каждый кладовщик будет по регистрам копаться.

(191) Ну и кто, по вашему мнению, должен этим заниматься? Как должно быть по правильному?

(192) Расписывает права главбух, а непосредственно назначает - прог конечно

(192) Гл.бух.Но чаще бывает вариант,что делает прог и дергает постоянно буха главного

(192) Вы администрированием базы данных заниматься не хотите, считаете, что это не ваша обязанность. Вряд ли это сможет делать главбух - ему есть чем заняться и без этого, да и некомпетентен он в этом за очень редкими исключениями. Ответ: нужен консультант или администратор 1С. Который знает конфигурацию в целом и понимает, как и где аукнется то или иное изменение данных. Пользователи должны ему подчиняться. Бывает, такого человека называют программистом 1С, это может быть его должность.

(192) Ситуация: у кладовщика не проводится расходный документ. В хрен знает каком периоде накосячено с партиями, перекрёстно. По регистрам эти партии выщемлять кто будет? Главбух? Кладовщик?

(196) Главбух?\\\ бывает.
А с правами не нужно доводить ситуацию до абсурда и переоценивать их роль, значение и возможности.

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

(198) :) одобряемое поведение закрепляется поощрением, неодобряемое -- наказанием :)

Поощрения программистов бесполезное занятие - это вам любой эй чар расскажет. Поэтому прочитал регламент - усвоили кто в доме хозяин и если какие отклонения, то сразу административным ботинком под его ленивое брюхо.

(200) я как-то без эй чаров справляюсь ;)

(192) если у вас организация меньше 50 юзеров - то эти должен заниматься 1С ник он и прог и консультант и администратор баз, если у вас организация 200-300 юзеров то этим должен заниматься специально нанятый человек

(202) золотые слова :)

(201) без эйчаров ни одна серьезная организация обойтись не может. Значит вы работаете в ларьке.

200-300 юзеров. Чем занять эту шаблу людей. У меня вот 15 .. да если их будет 150 , то я устану катриджи менять

(204) значит :)

(205) 150 юзеров будет специальный мальчик для замены картриджей, хотя сейчас всё чаще печать на аутсорс выносят

(207) ну выносят, только доп. головная боль от этого вынесения :(

(205) тогда организация работы будет совсем другая, уже не ставят принтер на каждый стол, стоит такой монстр один на этаж, который печатает по специальным командам, в закрытые лотки, которые открываются по индивидуальным картам с чипом, системы мониторинга и управления печатью

(208) да я понимаю, но как эти конторы себя рекламируют красиво )

Проблема в том, что круг задач сотрудника полностью зависит от предприятия и его потребностей.
Руководителю нужно решать проблемы предприятия и при этом он исходит из целесообразной эффективности.
Если целесообразно, чтобы программист менял картридж в принтере - значит будет менять, если особо некому. Или нафиг с пляжа.
Целесообразно вытирать сопли бухам - будет вытирать. Или искать другую работу.
Если прог балду гоняет, а бухи не справляются с завалом в учете - элементарно впрягут помогать. Потому что это целесообразно.
Целесообразность регламентов растет с увеличением нагрузки и количества сотрудников. Появляется целесообразность в более строгом разделении обязанностей и соответственно в регламентах взаимодействия.
Если прог один и не справляется с нагрузкой из-за соплей бухов, тогда обычно просто поток управления заявками и приоритетами по ним на кого-то возлагается. На того же главбуха, если бухгалтерия - основной заказчик. Она сама сопли вытрет, кому надо, если горят более важные задачи.
Обычно на этом этапе даже сервис-деск не нужен. Но лог задач полезно вести в любом случае.

(0) в комментах указано 3 базы и 45 юзеров, в принципе нормальная нагрузка на одного прога, если это не внедрение новой системы, можно успеть еще и с секретаршей заигрывать и на форуме трындеть. 1С-консультанта или администратора нанимать незачем, вы вдвоем будете по полдня в носу ковырять.
Хелпдеск надо делать, регламент надо писать.
Я бы посоветовала в работе искать "узкие места", закрывать их обучением и инструкциями.

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

(0) Добрый день! Я консультант-методолог 1С, у нас на предприятии существует HELPDESK, но 1 линия от заявок по 1С бежит как черт от ладана, если таковые все-таки туда попадают. Принят след регламент, примерно как у (107) простая действенная схема:
1. пользователь через корпоративный чат обращается с вопросом ко мне, получает ответ;
2. по результатам п.1 возможен созвон, для уточнения и обсуждения вопроса;
3. если по итогу п.1 и п.2 решение вопроса пользователя не найдено - оформляется заявка на корпоративную электронную почту, где он подробно описывает суть проблемы.
4. Журнал заявок ведем в Excel, раз в месяц собираем отчет, анализируем и т.д.
5. Решение отправляется пользователю на корпоративную электронную почту.

Если вы хотите узаконить, составьте регламент по предприятию или приказ, утвердите руководством.  Это чтобы пользователи не могли отказаться делать заявки, а то бухг. любят по телефону рассказать и всё.

(212) Это как раз внедрение новой системы - переход с умершей КА на ЗУП-БП-УТ через обмены. новый интерфейс, новый подход к деятельности, низкая обучаемость имеющегося штата и франч который стремится свернуть проект с тучей недоработок по обменам.

(214) ВООТ!!! У вас есть консультант-методолог.  Вот оно зерно истины.

(215) значит надо дрючить франч активнее
если вы возьмете консультанта на постоянку, внедрение закончится, что вдвоем дальше делать будете?

А без консультанта методолога и программист не нужен. Кто же ему будет задачи ставить? Уж не пользователи же

(217) три конверта же

(217) Консультант и на поддержке пригодится

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

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

(216) Да)))). Спасибо, и это я. И ещё, между 4 и 5 пунктом стоит фирма франч 1С, но это отдельная тема.

И еще секретарь, что бы правильно документы оформляла. А то пользователи понапишут не тем шрифтом, что в регламенте, а непорядок он с малого начинается. А не может же начальник бух воспитывать, для этого есть делопроизводитель обученный.

(221) и не забыть начальника, итого 5 специалистов на 45 юзеров

(222) всяко может быть,не всегда с точки зрения логики и полезности решают

Зато начальник в таких условиях наконец то может руководить ресурсами. А то лезешь под стол мышь подключить, а тут к тебе уже за катриджем пришли и еще кто-то подскакивает из расчетного отдела что вычет не считается правильно, и времени на форум нет совсем.
Но наверное с регламентами эффективность выше и зарплаты. Ну как минимум у начальнкивов.

(220) для небольшой организации консультант, который немного кодит, полезнее, чем прог, который не консультирует. На кайняк есть удаленщики, франчи и инфостат

(227) еще забыли руководителя проекта, который будет общаться с франчем и следить за внедрением.
Итого самый минимум 7 человек.

(214) Вот молодцы! Такой геморрой устроили!

(230) Почему?

(231) очень много лишнего и не разумного.
Во первых. Вы не всезнайка и многих проблем лучше чем пользователь не знаете.
Во вторых. Пользователь не новичок и способен самостоятельно обрисовать проблему.
3. А если вас по какой-либо причине нет- все стоп машина?
И многая ещё чего, типа протестировать проблему(у вас есть модель базы?), пояснить пользователю суть решения, оценить стоимость решения, оценить время решения проблемы и тп.
ПС. Заявка- это первое. Далее на входе документооборота, есть он у вас или все врукопашную делается, регулировщик направляет заявку по службам, службы дают резолюцию либо делать, либо нет, либо нужна консультация. Отчёт выпускается по заявкам.

интересно, а сколько надо зарабатывать организации, что бы иметь регулировщка для заявок ?

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

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

(235) так ведь "ИТ фуфло, денег не дам ни копейки" (с)

Ну, нет , я просто считаю, что игры в айти имеют смысл когда организация ощущает от него пользу и может содержать. Там уже можно и регламенты делать и функции распределять. А так .. просто какой-то человек который за компом что-то сидит и из него выжимает.

(235) нет, не млрд. Просто есть такое понятие в управлении предприятием, как бюджет. Вот и надо нужным лицам с ним познакомиться.

(238) не очень понимаю) у нас есть бюджет - в эксельке ведется. Но изменить статьи бюджета невозможно. А так как там с трудом умещается скромная зарпалата и пару компов, то где там взять денег еще на что-то не понятно.
Вот два года выпрашивали почтовый сервер. После того как мейл ру и яндекс и гугл перестали справляться с нашими ежедневными рассылками .. нам его все таки одобрили.. а то бывало что надо было по дню ждать пока письмо уйдет .. дождется очереди)

(237) лучше хотя бы 2

(240) Ну два это когда один не в отпуске. У меня вот начальник на следующий неделе в отпуске, а это значит что я буду проводить время не на форуме, а под столом вставляя сетевые разъемы. А вы говорите регламенты. До них надо дорасти.
Тут вот был в банке на обеде, так там два отпрыска вдове меня моложе обсуждали чисто виртуальные кейсы по взаимоотношения заказчика исполнителя. Слова там какие то умные говорили, процедуры эмитировали .. там понятно все это есть, работает. А когда три рубля в кармане, то как все это оплатить.

(241) 2 -- это про млрд.
из (235)

(242) ну 2 да, это серьезно. Тут бы наверное деньги нашлись.

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

(172) >А кто лучше самих программистов скажет о своем функционале?
это происходит потому, что у тебя нет этапа передачи функционала в эксплуатацию.

Общий подход такой:
1. Вся работа делится на сопровождение и развитие
1.1 сопровождение - это такие заявки, по которым нужен один и только один программист, чтобы выполнить работу, которую нет смысла декомпозировать на более чем одну задачу, и которая не вносит существенных изменений в поведение системы
1.2 развитие - это все прочее, где можно и нужно делить на задачи, раздавать разным исполнителям и что существенно меняет систему
2. Задачи сопровождения решаются по заявкам в хелпдеске
3. Задачи развития решаются только по заявкам от заказчика изменений.
3.1 Сначала этот заказчик в рамках этой заявки ставит тебе задачу. В рамках этого ты задачу можешь не принять потому что тебе что-то не понятно.
3.2 Потом ты ведешь разработку не просто в воздухе, а [разработку по заявке такой-то от заказчика такого-то]. Тут я сознательно упустил кучу магии, связанной с проектированием, оценкой и планирование - это здесь не суть.
3.3 Далее ты по заявке передаешь заказчику функционал. Прямо, мать его, акт приема-перадачи. Можно в ЭДО, можно на бумаге прямо по-хардкору. В регламенте должно быть написано, что с момента передачи за данные и корректность выполнения пользовтельских операций отвечает заказчик, а ты отвечаешь за корректность функционирования, которая определяется соответствием этого функционирования тому, что явно написано в связанной с заявке проектной документацией, принятой тобой.

такие вот общие трататульки.

но это по большому счету все ни хрена толком не работает в инхаус-разработке потому, что, ну, пусть продолбал какой-то конкретный роководятел, пусть он даже обкосячился до небес - это все признают потом, но выбираться из ЖПО, в которую вы пришли, вам всем вместе

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

(246) Когда пожар, такие писюльки горят в первую очередь/// так то так, но не так :)
Пожар должен идти по расписанию.

(246) если стоит вопрос, кого лишать премии за косяк, то тут писульки помогут

(245) Угу и тут в хелпдеске выплывает заявка "новая ККТ по 54-ФЗ не пробивает" или "а у нас по ЕГАИС/маркировке данные не отправляются"

(249)+ А система то оказыватся на 1С 7.7, поддержки разработчиков давно нету а программиста который есть (один на сопровождении) просто отчетики писать и админить с подтиранием за юзерами только успевает.

А на развитие "денег нету" ))

На прежней работе в основном занималась сопровождением. Была организована четкая система заявок через СЭД документолог. Это в Казахстане. Там заявку отправляли в конкретную службу. Нужен электрик - тоже туда)) Наш рук. боролся с тем, чтобы пользователи именно отправляли заявки.И чтобы по звонку мы по минимуму их обслуживали. Там же отчитывались о разработках и написании инструкций. ТЗ тоже туда можно подцепить. Во-первых видно, что мы работаем. Во-вторых видно подготовку пользователей. Рук. защищал свой отдел. Потому что юзеры любители сваливать все на программу. Она сама. А меня там и рядом не стояло. Хотя конечно это не всегда работало. Звонит юзер. Говорю - Не вижу заявку! Начинает верещать в трубку, что срочно. Что стоит клиент и тд. Ну помогаю конеш. Заявки юзеры очень сопротивлялись писать)) Ну понятно, что не хотят светиться своими косяками)

Я сейчас 1 ИТ-специалист(эникей, и жнец и швец и т.д. и т.п.) в компании, юзеров ПК ~50-65, есть удаленщики(~10 человек). В задачи сейчас входит и администрирование по всем вопросам связанным с ПК, сетью, принтерами, серверами, обслуживание и доработками 1С, консультированием, в общем всё.
-----------------
По частым вопросам пишу инструкции, в некоторых случаях батники(перезапуск службы печати например).
Руководители отделов отвечают за обучение своих сотрудников в работе 1С, если вопрос остается не разобранным, подключаюсь я.
Приоритеты задач выставляю самостоятельно, в зависимости от срочности и важности.
Часть задач по доработкам 1С отсекаю, если они не нужны совсем, или нет целесообразности.
Часть из них формулирую(с учетом специфики, взаимосвязей с другими отделами, с учетом бизнес логики и т.д.), согласовываю, и ставлю в очередь, по приоритетам. Сроки ставлю приблизительные, могу сдвигать, но стараюсь укладываться в заданный промежуток, так как форс мажор и заявки менее часа никто не отменял.
Задачи веду в Excel по отделам, вносятся заявки на решение которых требуется больше чем 1 час, все остальные решаются по ходу, без фиксации.
Заявки на доработку/разработку в 1С от пользователей отсекаются, обсуждаются только с руководителями отделов.
-----------------
С учетом роста кол-ва сотрудников и соответственно задач, убедил руководство нанять Админа, чтобы разделить обязанности, и заниматься собственными задачи связанными только с 1С, так как есть определенные задачи на которые не хватает времени для их выполнения с учетом текущих заявок.
P.S. приходится подтирать сопли сотрудникам по всем вопросам, они же как дети, только взрослые))) Тут важно именно Ваше отношение к этому, работа делается, общий индекс удовлетворенности 4.0-4.5 по 5 бальной шкале, к каждому есть свой подход, в некоторых ситуациях жестко и бескомпромиссно, довольно таки редко. Сразу отсек обращения по "у меня телефон тормозит, посмотри", "дома комп не работает", "ролик на стуле отвалился", "лампочку надо сменить".

У тебя есть шанс выстроить работу самостоятельно, менее геморойной, более эффективнее и правильнее, так как считаешь правильным в текущей ситуации с учетом особенностей организации в которой работаешь. Но эти регламенты, листы задач на вебе и т.д. тебе не нужны, это в крупных организациях полезная вещь, и то смотря как этим распоряжаться. Бывает наоборот вредит, от всяких эффективных менеджеров, а так же руководителей, которые не могут отстоять свое мнение и не имеют профессионального представления о своих подчиненных

(252) "общий индекс удовлетворенности 4.0-4.5 по 5 бальной шкале" // Как получаешь обратную связь для подсчета этого индекса?

по сабжу есть принятый закон

https://base.garant.ru/70547858/

(253) При сдаче задачи, интересуюсь на сколько оперативно и качественно прошла задача от начала постановки до решения. Не все, поэтому размазал на 4.0-4.5

(255) +++ не на прямую типо("на сколько вы оцениваете бла-бла-бла"), а именно общая оценка удовлетворенности. В сроки успели, отлично. Задача выполнена так как обговаривали и выполняет поставленный функционал, отлично. А вот тут я улучшил малость, вот круто. В таком ключе, без опросников.

JOB: Существуют ли Правила общения с программистами?

(256) Неанонимный опрос нерепрезентативен

(257) Нашел в коментах, проорал в голос ))) http://catalog.mista.ru/public/16934/

(259) Я ка консультант поддерживаю всё вышесказанное. Мне очень нравится наблюдать кредитовое сальдо на активном счёте. Всё лучше чем вагоны разгружать

(259) смешно, но там половина пунктов про субконто и"кредитовое сальдо на активном счёте" - это не проблема программиста, это проблема отвественного буха или главбуха