Сейчас ситуация достаточно печальная. Задачи падают в service-desk, который максимально неюзабелен. Задачи висят, контроль лежит на самих пользователях со всеми вытекающими.
Кто что использует для управления проектами и прочими мелками задачами? Как лучше организовывать подобные процессы?

(0) Кто расставляет приоритеты? Кто контролирует работу программиста?

Задачи висят, контроль лежит на самих пользователях со всеми вытекающими.
Организации нет,Sd не при чем

(1) Начальник пытается расставлять
Пытается контролировать
Дается тяжело

(2) >Организации нет
Никто не спорит. Вот хотим организовать, поэтому и спрашиваю

(3) Поменять начальника не предлагать?

заведите справочник Задачи в 1С (или бизнес-процесс с задачами)
Практика показала, что это эффективнее, чем Service Desk

(0) Несколько лет назад я устроился на должность руководителя ИТ-отдела. Для меня это было как новая ступень развития, вопросов было - куча. Прихожу, значит, к своему товарищу "на рюмочку чая". Спрашивал  у него и про ИТИЛ, и про Agile и прочие "волшебные вещи". Он мне сказал следующую фразу: "Если руководитель с головой - все это не обязательно. А если руководитель никакой - то и никакая "волшебная пуля" не поможет".

Так что, вам нужен "правильный" руководитель отдела.

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

Про какие задачи идет речь? Это вопросы касательно поддержки системы? Или задачи на доработку?

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

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

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

Начальников уже четыре сменилось

(8) Про обе стороны вопрос. Как лучше разделять задачи по текучке и доработке?

(11) Написали 10 пунктов со сроками реакции.Так и живем

Кстати а зп он получает за руководством кем?

(6) >Если руководитель с головой

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

(0) какой скрам? максимум на канбан потянете

(6) Вот ну хоть кто то с головой!

(14)Если нет исполнителей - то это не руководитель.

(11) Текучка - Задачи, доработка - Проекты :))

Я думаю, что стоит озвучить количество разработчиков.
У нас вот 3 (включая руководителя), и разработка не командная, а каждый пилит свой проект.
Раз в неделю руководитель узнаёт чем мы планируем заниматься.
Иногда меняет порядок планируемых задач.
+ по каждой задаче от пользователя (а они чаще всего приходят в нашем маленьком отделе от пользователей), мы должны получить от него письмо с текстом "да, делать."
А дальше в нашу работу почти не вмешивается, если ничего не случилось.

(11) Так сразу не ответишь. Нужна дополнительная информация: сколько у вас пользователей? Как организовано взаимодействие между пользователями и сотрудниками ИТ-отдела?
Какой объем задач по доработкам? Сколько админовв штате? Сколько программистов?

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

Поток задач по доработкам должен контролируемым. Задача упала в "отстойник". В понедельник собрались, взяли задачи из этого отстойника на неделю. Разработали. В конце недели выпустили релиз. Вот вам Agile и Канбаном.

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

Хотя бы с этого начните.

Ладно, как лучше начать контролировать выполнение задач? Раз в неделю спрашивать, что было сделано, и потом выдавать новые задачи? Звучит громоздко. Несколько раз пробовали подобную схему.. Хватает на пару месяцев, а потом отваливается

(19) Какое соотношение доработок к текучке*

(20) 3 прога, два админа, руководитель. 35 магазинов. Магазинами не занимаюсь, но оттуда постоянно сыпятся мелки задачи, объем оценить не могу. Но кажется, что что-то идет не так. Видимо, надо посмотреть, что там за задачи, и попытаться понять их объем.
Консультанта для магазинов нет.

Про недельный отбойник идея нравится.
Видимо, надо попробовать начать с Trello

За февраль было 57 задач. Думал, объем больше.

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

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

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

>> Раз в неделю руководитель узнаёт чем мы планируем заниматься.
Это очень редко.
Я два раза в день справляюсь, а по отдельным задачам и чаще.

(23) Сколько программистов?
Если бы меня раз в день пинали, я бы взвыл)

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

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

(25) Для 9, наверн, норм. А админов много, тоже ими руководишь?

(23) Каким образом "справляетесь"? В код смотрите?

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

В принципе, в (22)  все расписано (как вариант).

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

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

(30) Тогда как? Подходите к разработчику, и спрашиваете - а ты чо седня сделал ваще? Или как-то по-другому?

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

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

(21) Примерно 30% это текучка, 50% это доработки, 20% это ничего не делание (иногда минут на 20 прерываюсь в бомбермена поиграть, чего-нибудь по качать сходить кофе попить)

Есть задача, часто даже с описанием на много страниц. Я смотрю только на результат. Если меня устраивает, согласую перенос на продуктив, и готовлю нормативку на передачу в эксплуатацию. Если нет пилим дальше. Также и с внешними разработчиками.

(31) зачем ходить? Статус выполнения заявки отмечается в системе. Просрочил контрольную дату - объясняй причины и лови снижение KPI.

(31) Ну на самом деле если периодически проводить код ревью. Например сравнивая конфигурацию хранилища недельной давности, с текущим кодом (у нас это делается раз в месяц примерно перед накатыванием конфигурации в живые базы, для описания доработок для тех. поддержки и тестировщикам). И соблюдаются правила оформления кода
//Петров 21.02.20 начало
//Придумал офигенную фичу

//Петров 21.02.20 конец
То примерно можно оценить +\- лапоть, совсем уж человек бездельник или делает вид, что работает.

(34) А два раза в день то это делать зачем?

(35) А если одна задача оценена сроком в неделю, как каждый день прогресс проверять?

(35)
KPI нужны в 2х случаях, либо чтобы было что написать руководству почему какой-то сотрудник молодец.
Либо если отдел большой.

(38)
Обычно в таких случаях разбивают на подзадачи со сроками выполнения в 1-2 дня или меньше.

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

(38) для этого существует "декомпозиция".

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

(39) А кто разбивает на подзадачи? Сам программист?

(41) Ага, пишем подзадачи - создать справочник - 1 час, создать документ - 2 часа, создать форму документа - 1 час? А нахрена, спрашивается, если в продуктив пойдет только вся задача целиком, так как кусок задачи бизнес-заказчик никогда в продуктив не согласует, ибо плевать ему, какие там документы и справочники, если всё в целом не работает, как он хочет.

(43) Я думаю, что возможны оба варианта.
Как некий ведущий сотрудник  на ежедневной 5 минутной утренней летучке.
Так и сам разработчик, когда пишет себе план на день\неделю и отправляет ведущему сотрудник. И получает в ответ либо "ок", либо "Ты охренел?"

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

как то так

(45)Вот тут и начинаются всякие нюансы, на самом то деле. В которых утонуть не просто, а очень просто.

(44) подзадачи нужны чтобы видеть итоговый прогресс

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

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

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

Никого не волнует "справочник 1 час, документ 2 часа". Это ты на фрилансе можешь рисовать идиотам в части обоснования своих хотелок по деньгам.

(0) начните с контроля задач в http://catalog.mista.ru/public/552480/

(50)"для начала согласуй предлагаемые изменения в структуре данных с архитектором"
Забавно. :)

(50) если есть архитектор - то декомпозицию он и производит

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

Попробую резюмировать, глядя на (22)

1. Назначаем ответственных. Прог1 - Бухглатурия и Финансы, Прог2 - Розница и ЗУП
2. Задачи падают на service-desk
3. Прог1 и Прог2 просматривают задачи и назначают исполнителя и сроки. Создается карточка на канбан доске
4. Задачи выполняются
Кто двигает карточки в канбан доске, и кто закрывает задачи в service-desk?

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

(55) должна быть линия поддержки - консультант. ибо не все задачи должны доходить до прога

(57) У нас два с половиной прога. Как быть?

(56) для начала http://catalog.mista.ru/public/574829/
дальше можно гиты сонары вот это все
https://1c-syntax.github.io/bsl-language-server/diagnostics/

(58) расширяться или продолжать работать за пятерых, а какие еще варианты.

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

(61) исполнители - это сами прог1 и прог2

(62) Тогда с какого перепуга они берут на себя функционал руководителя?

(63) ну по разделу: задача по ут - первому. по бп-зуп - второму

(59) Ничеси, интересный комбайн

(61) Ну да, логично. Тогда оставляем либо начальника, либо ведущего прога.
Остался вопрос двойной работы. Надо двигать карточки на канбан доске и закрывать задачи в Service-desk. На прогов повесить такую обязанность?
В идеале, конечно, интегрировать канбан доску с сервисдеском..

(64) Херня и бардак. Задачи распределяет куроводитель! Иначе бардак обеспечен.

Задачу сдают заказчику. Только он может закрыть в SD как решённую или написать мотивированное возражение. Автоматически (по сроку) закрываются задачи, которые заказчиком не закрыты по истечение регламентированного промежутка времени.

(36) надо так писать

//Петров 20200221 начало SD/Jira 65455

//Придумал офигенную фичу

//Петров 20200221 конец

(68) +
// Петров огрёб звиздюлей за не согласованную офигенную фичу
// Фичу не трогать

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

(70) И даже документацию успеете в срок без согласования разработать и сделать?

Свежий пример. В приказе написали "Срок: ежемесячно до 17 часов 11 числа", вместо "Срок: ежемесячно 11 числа до 17 часов". Куча народу согласовала, а вчера удивились что я работу исполнил 04.03, а не как они написали 11.03.

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

(72) Когда работает два жида в три ряда, вообще ничего из написанного не нужно.

(73) А вдруг контора вырастет? И в этом случае процесс поставить будет на порядок труднее, если сейчас не начать. Есть сейчас такая история на виду, когда всё запустили к чертям, а сейчас 1С-ников в регионе ищут от 160 на руки, и начальников отделов 1С от 200...

Кстати, интересная статейка об оценке проектов https://habr.com/ru/company/maxilect/blog/489604/

(0)
Agile, scrum – fuck you, I'm Russian.
Khuyack-khuyack to production!

(74) А вот тут О'Хара была права: "Об этом я подумаю завтра"

(77) Может быть. Но нужное направление мыслей надо пытаться в головы начальников внедрять как можно раньше :))

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

(79) Ну тут кому как нравится :))

Ну и не забываем про "ж*пу и форточку": https://www.youtube.com/watch?v=-uGdaKFboHo