Доброго времени суток, уважаемые коллеги.
Обращение, в большей степени не к программистам, а к тем, кто программистами руководит...
Собственно хочу узнать кто как решает задачу с планированием оперативки у своих подчиненных.
Для разбега мысли приведу исходные данные:
полный рабочий день (фикса)
закрепленные участки учета за каждым разработчиком (весь спектр вопросов - от разработки до консультирования)
доступный для разработчика список задач к реализации
оклад + некоторый разбег в виде премий (максимум 50% к окладу)
недельное планирование: задачи примерно оценены (программером по согласованию с начальником) по трудоемкости и в плане фигурируют в объеме на 4 дня. Один день выделяется под оперативку.
Собственно проблема: случается порой так, что к концу недели разработчики выходят из бюджета времени под оперативку в ущерб плановых задач. Причины называются какие угодно и эта политика не обсуждается...
Кто как решает вопрос?!
Заранее спасибо за конструктив.

оперативка - это память или совещание?

"Причины называются какие угодно" - а конкретно?
"и эта политика не обсуждается... " - кем не обсуждается? Кто управляет программистами?

>Причины называются какие угодно и эта политика не обсуждается...

если эти причины "проглатываются" - вообще смысла нет трясти воздух

>к концу недели разработчики выходят из бюджета времени под оперативку в ущерб плановых задач

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

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

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

Если на оперативку времени не хватает, значит надо увеличить ресурсы на оперативку, за счет плановой работы или увеличением кол-вом программеров. Бывает так, что ресурсов не хватает, а требуют выполнения - "Иванов, но ты же коммунист!" - менять работу.

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

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

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

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

>воспитывать их нужно, развивать их...

а они хотят?

один спрашивает, второй отвечает... оба при деле

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

нормировать, с 9 до 13 - консультант, с 14 до 18 - разработчик, отобрать телефон, забаррикадировать дверь и отключить интернет

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

(0) Ежедневный детальный отчет выполненных работ с детализацией "оперативки". Потом анализировать накопленную статистику и делать выводы.

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

(12) это неконструктивно. по крайней мере у нас и в текущий момент времени...
а вы пробовали так организовывать работу? мне просто интересна реакция пользователей, которые привыкли васе звонить в любой удобный ему момент, а тут понимаешь с 9 до 13 только. фигасе...

(14) так то вы правы:)

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

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

(16) Я проработал в крупной компании руководителем отдела разработок, меня хватило на 3 месяца. Проги так же меня саботировали, типа не успеваем. Хватило ума бросить это, компания взяла профессионального управленца, который не знал 1С но знал как заставить программистов работать. Моб. телефоны у прогов отбирали, на выходные в офисе запирали. Юзерам вход в программерскую был закрыт, из всех прогов только один был на телефоне/саппорте по графику, остальные сидели и делали свою работу.

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

(20) вот это уже конструктив пошел.

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

подобную практику кто-нибудь применял?

(10) а вот как раз нужно чтобы захотели...
и по моему решение в (23) - тому очень хорошее подспорье.

в 18 часов никто не расходится, в 17:45 все сдают отчет по работе за день, если прог не справился с задачей по объективным причинам - сроки выполнения корректируются, если нет - то сидит и доделывает работу в овертайм.
(24) кнут, пряник - пробовали?

(25) не, ну это классика:)
работаем примерно по вот такой схеме: есть план и если разработчик видит, что он не успевает - он подходит ко мне и говорит, вот есть конкурирующие задачи, завтра ндс, а  клавдия ивановна... бла... бла... бла...

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

кардинально новых мыслей не услышал, НО!!!
спасибо Господину ПЖ за посты (3) и (10), товарищу в (14), за "вызов" сделанный в (15), за посты (18) и (27) и вообще всем, кто сюда заглянул.
во время этого небольшого обсуждения меня посетили мысли, которые в ближайшие пару недель я применю.
на какое-то время покидаю тему и очень хотелось бы почитать ваши схемы по планированию оперативной работы у программистов.
кстати, а есть тут приверженцы agile методологии? по scrum работает кто-нить?

(28) Вы лично пытались программировать, если к Вам с интервалом 5-15 минут кто-нибудь обращается со своими проблемами?
Это невозможно. Вы пытаетесь совместить несовместимые обязанности.
Как вариант: все звонки, письма и обращения должны поступать на одного человека, а он уже, если сам не справится, обратится к соответствующему программисту. В следующий раз такую проблему он решит сам.
ИМХО, в Вашей ситуации это единственная работающая схема.

(11) "...которые не брезгуют поконсультировать в ущерб плановым задачам." - собст-на корень траблы ты описал.

Исходя из принципа родина вас не забудет, но и не вспомнит. Хотят трпаться - пусть треплются; не успели с основной задачей - хлопай деньгами.

заводите отдельного программиста на оперативку
работал с одним - у того всё рабочее время съедала оперативка

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

Все зависит от проекта. Консультант в отделе это конечно слабое назначение. Обычно в отделе 1го программиста раз в неделю назначают для решения таких задач, остальные работают над проектом. Проект строится как графы. Обычно несколько задач уходят в одну, на такую задачу закладывают доп. 100% превышения времени.
Для доп. мотивации закрытие проекта дают премию.

Выше описание решение нормально для столицы. В провинции обычно все носит очень убогий характер. Я в Новосибирске не встречал даже крупную торговую компанию, которые бы хоть немного использовали от ИТИЛ.

(0) задачи эти как учитываете?

(0) Разработчик не должен консультировать пользователей - он должен заниматься разработкой и проблемы пользователя его вообще интересовать не должны. Заставлять разработчика консультировать пользователей - это как минимум не уважение а как максимум диверсия. При таком подходе ни разработки нормальной не будет ни консультирования...

(35) зависит от того, кого именно называют разработчиком и того, что имено называется разработкой

3.14здёж, болтовня и разбор полётов это отдельная высокооплачиваемая должность

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

Вы похоже случайный человек в руководстве ИТ-подразделения. Так сказать, посадили поруководить. Ведь это очень просто, за компом кнопки нажимать.
Рекомендации. Или понимание основ управления придет с опытом. Или надо немножко в шкуре рядового программера посидеть.

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

2) Ставить хорошего программиста решать проблемы клиентов, которые может решить и кто нить менее дорогой - как минимум расточительно

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

4) Деньги не мотивируют. Отсутствие денег сильно демотивирует. Но начни платить программисту в 2 раза больше, и он не будет работать в 2 раза эффективнее.

5) Разбитие ответственности по секторам приводит к огромным рискам от эффекта грузовика


Что бы делал я в такой ситуации:
1) Программистов и консультанта/консультантов в отдельную комнату, в которую не смогут проникнуть пользователи
2) Ввести багтрекер - куда будет падать вся оперативка. Должен быть человек, который может правильно расставить приоритеты между задачами оперативки и разработки. Это может быть консультант.
3) Создал бы линию техподдержки. В идеале наполнить ее симпатичными коммуникабельными девушками, которые с одной стороны могут выслушать проблему и записать ее в багтрекер, или решить ее в случае простого или повторного случая, а с другой, которым не смогут отказать программисты в помощи. Важно, что все случаи обращения должны записываться
4) Периодически просматривать все обращения пользователей и анализировать их. Могут выяснится комплексные проблемы, на которые можно поставить защиту от дурака, написать инструкцию или организовать бизнес-процесс, чтобы и пользователи смогли работать сами и разгрузить техподдержку от повторных обращений

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

(36) Написание отчетов\обработок не является разработкой. Разработкой является наращивание (развитие) функционала конфигурации.

(41) согласен, но в таких организациях как правило нет руководителей ИТ (зачем человеку с семью пядям во лбу еще и начальник)

(40) хорошо расписано.
(6 сентября 6 лет 6 месяцев 6 дней :) )

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

(0) во, блин, работа!
типа, подскажите, граждане, как подчиненных пинать! )))
щас, сомлею )))

(44) не спеши. автор 86-го года

реально - всех выгнать и собрать свою команду..

+ (47)всё понятно - багтрекер, техподдержка, коммуникабельность, анализ, доминикана

(48) Тут можно нарваться - реально выгонят и оставят старую команду, т.к. новых не нашли, а старые все таки как то, но работаю :)

(47) видел - был удивлен, но факт есть факт - написано все правильно (на мой взгляд)

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

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

лучше нанять руководителя за двухкратный оклад

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

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

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

(47)(51) вы еще не переболели этой темой? Ей лет 5 уже
(49) вы меня с кем то путаете
(53) само собой все не разрулится и серебряной пули нет, так что или будоражить болото и наносить непоправимую пользу или не стонать
(55) гуру нужен. В идеале, чтоб компетентных было как минимум 3ое - программист, консультант и ИТДиректор. Вот только не хватает на всех гур. И "фапабельные гламурные тян" сделают ситуацию только хуже. Нужны просто милые девушки

кстати, Паркинсон, на закон которого так любят все ссылаться, не был ни ученым, ни РП, ни руководителем... Он был юмористом, одна из шуток которого увековечила его имя.

Почему работает этот закон и как ущерб от него можно снизить хорошо расписано в критической цепи. Вкраце можно прочитать тут http://habrahabr.ru/post/25621/

Это не тот в честь которого названы трясущиеся конечности и голова? Закон есть закон..

(60) закон Паркинсона
паркуешь там, где есть свободное пространство
трясёшь там, где можно трясти
работаешь столько, за сколько платят
Паркинсон вездесущ

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

и потери на кросс-курсе бывают огромными..

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

+40 Что делать - расписано толково. В отдел поддержки можно набрать студентов. Должна быть инструкция (а лучше база знаний) для сотрудников отдела поддержки. Это облегчит обучение новых сотрудников. Базу знаний должны пополнять как отдел поддержки, так и отдел разработки. Примерный вид базы знаний: "проблема - решение".

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

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

полный рабочий день (фикса) + некоторый разбег в виде премий (максимум 50% к окладу)

интересно где ты таких лохов находиш?

если фикса - плати оклад и баста, иначе сделка и свободный график

(68) причем тут лохи? В Мск встречал - оклад 130. Прогеры закрыли проект, который вели около года. Все успешно. Доп премия была больше оклада.

(67) +много. сам в таком состоянии. текучка занимает >80% времени. оставшееся свободным время размазано кусками по полчаса а то и меньше в течение дня - что либо программировать да и просто обучаться практически нереально. увы.

Как вариант
1) Все вопросы принимать через почту с копией начальника пользователя и начальника ИТ. 80% тупых вопросов исчезнет. На телефон посадить заправщика картриджей чтобы неповадно звонить было (в вашем случае неопытного консультанта).
2) Вопросы пользователя перенаправлять более опытному пользователю с того же участка (а лучше административно назначить его).

В любом случае вопросы через почту не так сильно из потока выбивают. И по своему опыту, программисты не любят, когда их постоянно дёргают, что-то ТС не договаривет.

(16) >>мне просто интересна реакция пользователей, которые привыкли васе звонить в любой удобный ему момент, а тут понимаешь с 9 до 13 только. фигасе...

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

(0) Убери у разработчика закрепленные участи учета по которым он должен делать "все" за 1 день в неделю, и где у тебя неограниченный объем работ.
И все - плановые задачи попрут.
Вообще это бред... либо ты даешь зону ответственности ну и в нагрузку по мере возможности плановые задачи (что у тебя есть сейчас).
Либо плановые задачи, а на поддержке оперативке у тебя отдельные люди.
Кроме того доработки по плановым задачам имеют свойство накапливаться с количеством плановых задач. Например обычное дело - плановая задача -сделать выгрузку из одной базы в другую - ты сделал - потом еще постоянно занимаешься доработками, так как там постоянно че-то меняется. С одной стороны вроде и сделал уже плановую задачу, а с другой оказалось - что она после выполнения подразумевает регулярную поддержку и доработку.

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

(71) "1) Все вопросы принимать через почту с копией начальника пользователя и начальника ИТ. 80% тупых вопросов исчезнет. На телефон посадить заправщика картриджей чтобы неповадно звонить было (в вашем случае неопытного консультанта)." - фигню говоришь. Разберем ситуацию: бухгалтерия. В отделе, допустим, 5 человек. Возникла проблема у одного бухгалтера. Бух идет к своему начальнику, согласовывает задачу. Выясняется, что задача "супер-мега-важная", согласовывает с руководителем ИТ. Дальнейшую цепочку пока прервем. Возникает проблема у другого бухгалтера. Бух №2 идет к своему начальнику и все опять повторяется. А если проблемы возникают поочередно у всех пяти сотрудников??? Причем пользователь рассказывает проблему: 1. сначала своему начальнику, 2. потом рук-лю ИТ. 3. В конце концов тому, кто эту проблему будет решать. Как следствие :решение проблемы затягивается. Загружаются руководители двух подразделений. Причем загружаются какой-то лажей.

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

Упс, опечатка: *решать те проблемы

(74)
1) там не согласование, а просто копия в адреса

(76) А смысл?

+77 Заспамить двух руководителей?

ITIL читать предлагали уже?

(74) Вообще-то я писал просто в копию начальников ставить, чтобы знали что программист не бездельничает, а пользователи тупят. Можно и более облегчённый вариант без копий, но обязательо через почту. А согласование это для ТЗ по доработке программы скорее.

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

(0) "Проблема в безграмотном руководителе, не умеющим организовать работу своего отдела" было?

Прогер.. что за слово такое? Программист, разработчик, сервис-инженер... Научись сначала уважать своих подчиненных как специалистов

(38) "все не читала, извиняюсь. Но фиксы-проги закрепленные за участком - и плановые задачи вообще не совместимы.
Точнее плановые задачи это творчество художника и форс-мажор, а уделять внимание МарьИванне это оплачиваемое рабочее время. Если у фиксов при этом че то не работает - они верблюды.." - не согласен.
Уделять внимание МарьИвановне должне коснультан, это отдельная оплачиваемая должность. А делать плановые задачи - должен программист, это другая оплачиваемая должность. А попытка заставить программиста уделять внимание МАрьИВановне - это все равно, что заставить портного печь пирожки, а повара заставить кроить платье.
Каждый должен заниматься СВОИМ делом.

(81) Ну уж... отсутствие отдела тестирования в организации это никак не косяк программиста :)

(85) Полностью согласен. Обвинить программиста в косяках можно только в том случае, когда составлено детальное ТЗ (включающее сценарий тестирования) и программа не проходит предусмотренные ТЗ тесты.

(85) В данном случае даже на поддержку не могут выделить человека. Какие уж разговоры про отдел тестирования? К тому же в небольших организациях тестирование можно повешать и на программистов. Связка "программирование + тестирование" всяко продуктивнее связки "программирование + поддержка".

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

(87) "В данном случае даже на поддержку не могут выделить человека." - тогда единственный выход, поддержка строго по расписанию. Например с 11.00 до 12.00. В остальные часы обязать программистов игнорировать пользователей, а пользователям запретить беспокоить юзеров.  За нарушение штрафовать, при чем обоих. Юзеров если побеспокоят программистов, а программистов если ответят на вопрос пользователей в неположенное время.
"К тому же в небольших организациях тестирование можно повешать и на программистов." - да, тоже вариант. Программер пишет ТЗ, сценарий тестирования, подписывает у ответственных лиц и выполняет.

(87) Вот в такой связке в которой программирование+тестирование - программист всегда будет виноват в том что программа работает "неправильно".

(89) "Например с 11.00 до 12.00" - не будет работать. Всяко будут проблемы в другое время, которые нужно решить быстро.

(90)+ плюсом, к тому что программирование+тестирование одним человеком - это вообще бред. Вот мы все решали задачи по математике - пол часа решали - решили, вроде все верно. Учителю отдали - он нашел ошибку. А ты сам сколько не проверял  - не видел ее. А программист работает так же, но решает задачу этак часов 20-30-40... и уж он сам точно потом как не затестируется ничего не найдет серьезного. Ибо "глаз" замылен. Но виноват будет по любому... нафиг... А в случае с 1С, будет еще виноват за то что 1С так напрограммировали и предумали именно такую систему работы, а не так как там у вас на фирме захотели.

(20) что-то подобное. Только привело к тому, что с проблемами перестали обращаться - делают где-то в эксельке или говорят между делом

(90), "Вот в такой связке в которой программирование+тестирование - программист всегда будет виноват в том что программа работает "неправильно"." - если сделать как в (89) то не будут

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

(92) Да, в своем коде глаз "замыливается". Отсюда выход: программист тестирует задачи соседа. Как вариант, тестировать всем отделом вместе с руководителем. Что-то вроде мозгового штурма "завали программу". Чья прога "завалилась" приносит печенюшки - дополнительной мотивация.

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

(96) тестируют вообщето не с целью завалить. а с целью удостоверится что все работает

(98) Есть при тестировании ставить цель "завалить" то это поможет выявить проблемы и подводные камни, которые не возможно было определить простым тестированием и которые не учли на этапе постановки задачи.

сто?

Сам нахожусь в такой же ситуации. Как я не пытался донести до руководства, что нельзя к программисту во время работы просто так подходить без предупреждения и озадачивать его вопросами, на которые нельзя ответить мгновенно. Например, экономист подходит ко мне и спрашивает "Как у тебя считается столбик ХХХХ в отчете YYYYY.
или "В документе ХХХХ у тебя ответственный берется из основного менеджера или из договора или из автора...

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


Вот вчера ко мне подошел директор и экономист. Директор узнал сосотояние дел, сросил когда будет проект по закупкам закончен. Я сказал, что в середине следующей недели. Он спросил возможно ли закончить к пятнице. Я сказал, что нет.
Он сказал - тогда жду в понедельник. Я сказал что сейчас я перепровожу документы всей базы, восстанавливаю последовательность, устраняю ошибки проведения, возникшие из за того, что в единицах измерения старых позиций поменяли вес. Общее перепроведение занимает 3 суток. Только после него можно рассчитывать зарплату.

Я сказал им, что если у меня проведется все без проблем, то я успею к понедельнику. Если будут проблемы, то сообщу.
В результате выявилось море проблем и я понедельнику я не только не смогу закончить, я и проведение не успею сделать. Так что вот. Опять окажусь не прав в глазах руководства. Но иного выхода нет. Им же не понять, что нельзя требовать всего и сразу.

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

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

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

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

(105) Тогда остается ответить - это невозможно. Выбирайте, то или это. Расставляйте приоритеты, что вам важнее.

(105) Это потому,что ты дедлайном обозначил середину следующей недели.

(106) Это было возможно, но в той вероятной вселенной где Кей оставил чаевые.

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

А если Я уволюсь, то пострадают на время все, но после этого, другие программисты будут уже работать в нормальных режимах работы.

И ещё в таких ситуациях козырь руководство такой "Скажи срок когда это будет готово". если ты называешь срок, то от тебя требуют, чтоб это было сделано в срок. Если ты не укладываешься, то никого не волнует причины. Сорвал срок - получи наказание.

(109) Я таким методом повысил ЗП отделу программистов на прошлом месте работы :)

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

(110) А выхи нельзя поработать?

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

(110) Есть руководитель ИТ отдела?

(113) Вообще то в выходные люди отдыхают.

(116) Не знал об этом. 20 лет руковожу, а не знал

(117) Эт сколько те лет сейчас?

(118) Жениться еще не поздно

(119)ну есть и в 90 женятся ))) просто, насмотрелся я, руководителей после института, жалкое зрелище ЧСВ овер 9000, а умения решать проблемы и находить подходы к подчиненным 0.

(120) Ну, судя по всему я-то успел "обуркаться"

(121) хорошим тоном, если что-то заявляешь, дать пощупать подтверждение )))

(28) Поздно заметила тему, но отпишусь по Agile. У нас как раз началась эта тема. Часть команд работает по скраму, часть по канбану. В целом это применимо к 1С-разработке. Внедрение идет медленно потому что люди "сопротивляются", боятся что это будет кнутом, поэтому пока только тим-лиды сидят в этом, но со след неделе уже программистов туда загоним.
Из бюджетного варианта сделайте доску на которой будете клеить листочки с задачами (ну тот же agile :) ).

Ну а про разделение консультантов и прогеров уже написали.

(119) замуж поздно, жениться рано..

На саппорт отдельного спеца. Если не может ответить на вопрос, то он сам консультируется у разработчика в определенное время или по ацки важным вопросам (если босс прикажет) то в любое время. Юзеров к прогам не пускать, пофиг что они друг к другу привыкли. Качество саппорта некоторое время снизится но можно отмазаться что это временно

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