Имя: Пароль:
1C
 
Agile, scrum и все, что касается проектного управления?
0 DTX 4th
 
05.03.20
09:57
1. Используем Agile 50% (1)
2. Свой вариант 50% (1)
3. Отказались от Agile 0% (0)
Всего мнений: 2

Сейчас ситуация достаточно печальная. Задачи падают в service-desk, который максимально неюзабелен. Задачи висят, контроль лежит на самих пользователях со всеми вытекающими.
Кто что использует для управления проектами и прочими мелками задачами? Как лучше организовывать подобные процессы?
1 Lama12
 
05.03.20
10:00
(0) Кто расставляет приоритеты? Кто контролирует работу программиста?
2 piter3
 
05.03.20
10:00
Задачи висят, контроль лежит на самих пользователях со всеми вытекающими.
Организации нет,Sd не при чем
3 DTX 4th
 
05.03.20
10:04
(1) Начальник пытается расставлять
Пытается контролировать
Дается тяжело

(2) >Организации нет
Никто не спорит. Вот хотим организовать, поэтому и спрашиваю
4 piter3
 
05.03.20
10:05
(3) Поменять начальника не предлагать?
5 Волшебник
 
модератор
05.03.20
10:07
заведите справочник Задачи в 1С (или бизнес-процесс с задачами)
Практика показала, что это эффективнее, чем Service Desk
6 VladZ
 
05.03.20
10:10
(0) Несколько лет назад я устроился на должность руководителя ИТ-отдела. Для меня это было как новая ступень развития, вопросов было - куча. Прихожу, значит, к своему товарищу "на рюмочку чая". Спрашивал  у него и про ИТИЛ, и про Agile и прочие "волшебные вещи". Он мне сказал следующую фразу: "Если руководитель с головой - все это не обязательно. А если руководитель никакой - то и никакая "волшебная пуля" не поможет".

Так что, вам нужен "правильный" руководитель отдела.
7 fisher
 
05.03.20
10:12
Организуйте недельный цикл. Раз в неделю собирайтесь, определяйте и раскидывайте на неделю наиболее приоритетные задачи из общего пула задач на каком-нить канбане (чтобы наглядно было видно, какие из взятых в работу задач на каком этапе и кем выполняются). Через неделю разбор полетов, раскидывание новых задач и так далее. Неделя - оптимально. Элементы аджайла на всякую такую фигню ложатся почти идеально.
Чтобы каждый момент времени каждый работник четко понимал, куда копает, что в ближайшее время с него об этом спросят и вся эта инфа не похоронена в бесконечном списке, а вот - на ладони и без лишнего мусора.
8 VladZ
 
05.03.20
10:13
Про какие задачи идет речь? Это вопросы касательно поддержки системы? Или задачи на доработку?
9 Арбузов
 
05.03.20
10:17
(0) Да хоть Редмайн тот-же вполне подойдёт. Основной вопрос эффективного применения всяких эджайлов - вы делаете продукт в совместной разработке, или просто каждый пилит конкретную задачу по доработке чего-то уже работающего.
10 Lama12
 
05.03.20
10:18
(3) Жесть. Начальник слаб. Если есть желание, можешь залезть на его место организовав порядок. Это не сложно. главное что б была поддержка сверху. Если начальник и поддержку организовать не может, но плохо дело.
11 DTX 4th
 
05.03.20
10:21
Начальник хорошо контролирует работу сисадминов
Прогов тоже он должен контролировать? В моем представлении это скорее зона ответственности тимлида. Или это не так много времени, чтобы еще и тимлида лепить из своей команды?

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

(8) Про обе стороны вопрос. Как лучше разделять задачи по текучке и доработке?
12 piter3
 
05.03.20
10:21
(11) Написали 10 пунктов со сроками реакции.Так и живем
13 piter3
 
05.03.20
10:22
Кстати а зп он получает за руководством кем?
14 Garykom
 
гуру
05.03.20
10:23
(6) >Если руководитель с головой

Хоть сколько будет голов у руководителя, если нет исполнителей для задач вменяемых то сам руководитель ничего не успеет.
15 mikecool
 
05.03.20
10:31
(0) какой скрам? максимум на канбан потянете
16 Xapac
 
05.03.20
10:33
(6) Вот ну хоть кто то с головой!
17 Xapac
 
05.03.20
10:34
(14)Если нет исполнителей - то это не руководитель.
18 Арбузов
 
05.03.20
10:34
(11) Текучка - Задачи, доработка - Проекты :))
19 ejikbeznojek
 
05.03.20
10:42
Я думаю, что стоит озвучить количество разработчиков.
У нас вот 3 (включая руководителя), и разработка не командная, а каждый пилит свой проект.
Раз в неделю руководитель узнаёт чем мы планируем заниматься.
Иногда меняет порядок планируемых задач.
+ по каждой задаче от пользователя (а они чаще всего приходят в нашем маленьком отделе от пользователей), мы должны получить от него письмо с текстом "да, делать."
А дальше в нашу работу почти не вмешивается, если ничего не случилось.

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

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

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

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

Хотя бы с этого начните.
21 DTX 4th
 
05.03.20
11:02
Ладно, как лучше начать контролировать выполнение задач? Раз в неделю спрашивать, что было сделано, и потом выдавать новые задачи? Звучит громоздко. Несколько раз пробовали подобную схему.. Хватает на пару месяцев, а потом отваливается

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

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

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

За февраль было 57 задач. Думал, объем больше.
22 8 bit
 
05.03.20
11:07
Что-то мне подсказывает, что дело тут не в агиле (или аджайле, если нравится), а в отсутствии управления процессом техподдержки.
Обычно задачи делят по направлениям, на каждое направление должен быть назначен ответственный, который:
1. Определяет необходимость выполнения заявки, как таковой. Считайте, что отсеивает идиотские, возвращает на доработку неполные, отклоняет то, что уже реализовано и т.д.
2. Определяет приоритет заявки, т.к. пользюки так и норовят на всю свою херню установить максимальный приоритет.
3. Назначает исполнителя и сроки.
4. Контролирует исполнение заявки.

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

Выполнение задач неплохо отслеживать в самой системе, если она есть. Должно быть видно чем нагружен тот или иной исполнитель, какие сроки, что просрочил, вообще делает ли что-нибудь. Там уже раздавать или волшебные люли, или подкидывать пару тыщенок в виде премии за хорошую работу.
23 Irbis
 
05.03.20
11:08
>> Раз в неделю руководитель узнаёт чем мы планируем заниматься.
Это очень редко.
Я два раза в день справляюсь, а по отдельным задачам и чаще.
24 DTX 4th
 
05.03.20
11:09
(23) Сколько программистов?
Если бы меня раз в день пинали, я бы взвыл)
25 Irbis
 
05.03.20
11:11
В отделе 9 человек. Взвывший отправится искать другую работу или останется без годовой премии при значительных косяках.
26 VladZ
 
05.03.20
11:14
(22) Тут проблема в целом в отсутствии управления процессом.
Процесс не управляется. Либо руководителю не хватает мозгов (как вариант, руководитель - "хороший знакомый" нужного человека), либо нет нужно мотивации.  Удаленно это не диагностируется.
27 DTX 4th
 
05.03.20
11:14
(25) Для 9, наверн, норм. А админов много, тоже ими руководишь?
28 Арбузов
 
05.03.20
11:14
(23) Каким образом "справляетесь"? В код смотрите?
29 VladZ
 
05.03.20
11:21
"3 прога, два админа, руководитель" - Отлично. Отдел небольшой. Поэтому нет смысла выделять отдельного рук-ля для прогов.

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

По поводу контроля: можно каждый день (вечером) спрашивать статус задачи. Лезть в технические детали имеет смысл, когда "на проблемку напали". Обычно хватает уровня: "Проблемы есть? В сроки укладываемся? Помощь какая-то нужна?". Если есть проблемы с организацией взаимодействия с другими подразделениями - руководитель должен оперативно разрулить.
30 Irbis
 
05.03.20
11:22
(27) Нет, это отдельный отдел, и техподдержка по железу тоже отдельный отдел.
(28) Нафейхоа? Да я и в большинстве разработок не специалист, но отличить "сделано" от "не сделано" могу.
31 Арбузов
 
05.03.20
11:24
(30) Тогда как? Подходите к разработчику, и спрашиваете - а ты чо седня сделал ваще? Или как-то по-другому?
32 8 bit
 
05.03.20
11:26
(26) Несколько жалоб на службу поддержки, направленные на руководителя организации, вполне могут решить проблему.

Нихерасе, "нет нужной мотивации" - с такими предъявами человек сразу пошел бы нафиг, за забор. Зарплата ему не мотивация? Выполнение должностных обязанностей за которые он получает деньги - это не мотивация? Нет? Тогда за забор. Взяли моду - видите ли их надо уговаривать, чтобы они делали свою работу. У меня была пара таких, хоть и спецы отличные, но зажрались и охамели. Выгнал без сожаления и когда звонили те, к кому они хотели устроиться, с просьбой дать характеристику, то отвечал честно - демагог-бездельник, хотите - берите.
33 ejikbeznojek
 
05.03.20
11:26
(21) Примерно 30% это текучка, 50% это доработки, 20% это ничего не делание (иногда минут на 20 прерываюсь в бомбермена поиграть, чего-нибудь по качать сходить кофе попить)
34 Irbis
 
05.03.20
11:27
Есть задача, часто даже с описанием на много страниц. Я смотрю только на результат. Если меня устраивает, согласую перенос на продуктив, и готовлю нормативку на передачу в эксплуатацию. Если нет пилим дальше. Также и с внешними разработчиками.
35 8 bit
 
05.03.20
11:28
(31) зачем ходить? Статус выполнения заявки отмечается в системе. Просрочил контрольную дату - объясняй причины и лови снижение KPI.
36 ejikbeznojek
 
05.03.20
11:32
(31) Ну на самом деле если периодически проводить код ревью. Например сравнивая конфигурацию хранилища недельной давности, с текущим кодом (у нас это делается раз в месяц примерно перед накатыванием конфигурации в живые базы, для описания доработок для тех. поддержки и тестировщикам). И соблюдаются правила оформления кода
//Петров 21.02.20 начало
//Придумал офигенную фичу

//Петров 21.02.20 конец
То примерно можно оценить +\- лапоть, совсем уж человек бездельник или делает вид, что работает.
37 Арбузов
 
05.03.20
11:35
(34) А два раза в день то это делать зачем?
38 Арбузов
 
05.03.20
11:36
(35) А если одна задача оценена сроком в неделю, как каждый день прогресс проверять?
39 ejikbeznojek
 
05.03.20
11:38
(35)
KPI нужны в 2х случаях, либо чтобы было что написать руководству почему какой-то сотрудник молодец.
Либо если отдел большой.

(38)
Обычно в таких случаях разбивают на подзадачи со сроками выполнения в 1-2 дня или меньше.
40 pechkin
 
05.03.20
11:41
системой управления задач - это не решается. ведь это всего лишь инструмент.
а должен быть тот для кого этот инструмент (то бишь начальник)
41 8 bit
 
05.03.20
11:43
(38) для этого существует "декомпозиция".
42 Irbis
 
05.03.20
11:43
(37) У меня тоже руководители есть. И время совещаний и оперативок моей с ним и его с генеральным разное. Чтобы не докладывать неактуальную информацию, и не мычать про сейчас узнаю.
43 Арбузов
 
05.03.20
11:44
(39) А кто разбивает на подзадачи? Сам программист?
44 Арбузов
 
05.03.20
11:47
(41) Ага, пишем подзадачи - создать справочник - 1 час, создать документ - 2 часа, создать форму документа - 1 час? А нахрена, спрашивается, если в продуктив пойдет только вся задача целиком, так как кусок задачи бизнес-заказчик никогда в продуктив не согласует, ибо плевать ему, какие там документы и справочники, если всё в целом не работает, как он хочет.
45 ejikbeznojek
 
05.03.20
11:52
(43) Я думаю, что возможны оба варианта.
Как некий ведущий сотрудник  на ежедневной 5 минутной утренней летучке.
Так и сам разработчик, когда пишет себе план на день\неделю и отправляет ведущему сотрудник. И получает в ответ либо "ок", либо "Ты охренел?"

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

Используем Agile
47 Арбузов
 
05.03.20
11:58
(45)Вот тут и начинаются всякие нюансы, на самом то деле. В которых утонуть не просто, а очень просто.
48 pechkin
 
05.03.20
11:58
(44) подзадачи нужны чтобы видеть итоговый прогресс
49 VladZ
 
05.03.20
12:01
Кстати, по текущим задачам нужно провести аудит. Возможно, есть задачи, которые уже "протухли".
50 8 bit
 
05.03.20
12:08
(44) Вот поэтому рядовой исполнитель должен только выполнять то, что ему поручили, а не рассуждать о вещах, в которых он не разбирается по факту, но считает себя профи.

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

Никого не волнует "справочник 1 час, документ 2 часа". Это ты на фрилансе можешь рисовать идиотам в части обоснования своих хотелок по деньгам.
51 Timon1405
 
05.03.20
12:21
(0) начните с контроля задач в http://catalog.mista.ru/public/552480/
52 mTema32
 
05.03.20
12:29
(50)"для начала согласуй предлагаемые изменения в структуре данных с архитектором"
Забавно. :)
53 pechkin
 
05.03.20
12:32
(50) если есть архитектор - то декомпозицию он и производит
54 Paint_NET
 
05.03.20
12:36
(6) Есть ещё нюанс. Если рычагов влияния на пользователей нет - все регламенты идут по зызде. Так что даже хороший начальник сразу выстроить уютный ламповый итиль в бардаке не сумеет, нужно время и административный ресурс.
55 DTX 4th
 
05.03.20
12:40
Попробую резюмировать, глядя на (22)

1. Назначаем ответственных. Прог1 - Бухглатурия и Финансы, Прог2 - Розница и ЗУП
2. Задачи падают на service-desk
3. Прог1 и Прог2 просматривают задачи и назначают исполнителя и сроки. Создается карточка на канбан доске
4. Задачи выполняются
Кто двигает карточки в канбан доске, и кто закрывает задачи в service-desk?
56 DTX 4th
 
05.03.20
12:41
Еще отдельный вопрос про кодревью. Кто-нибудь делает? Местами качества кода оставляет желать лучшего, и если пустить в прод, через год все это только усугубится
57 pechkin
 
05.03.20
12:43
(55) должна быть линия поддержки - консультант. ибо не все задачи должны доходить до прога
58 DTX 4th
 
05.03.20
12:47
(57) У нас два с половиной прога. Как быть?
59 Timon1405
 
05.03.20
12:47
(56) для начала http://catalog.mista.ru/public/574829/
дальше можно гиты сонары вот это все
https://1c-syntax.github.io/bsl-language-server/diagnostics/
60 Timon1405
 
05.03.20
12:49
(58) расширяться или продолжать работать за пятерых, а какие еще варианты.
61 Irbis
 
05.03.20
12:50
Кто такие прог1 и прог2, чтобы назначать исполнителя? На каком основании они это будут делать? Это вообще их работа или их исполнитель может слать подальше?
62 pechkin
 
05.03.20
12:51
(61) исполнители - это сами прог1 и прог2
63 Irbis
 
05.03.20
12:52
(62) Тогда с какого перепуга они берут на себя функционал руководителя?
64 pechkin
 
05.03.20
12:53
(63) ну по разделу: задача по ут - первому. по бп-зуп - второму
65 DTX 4th
 
05.03.20
12:55
(59) Ничеси, интересный комбайн

(61) Ну да, логично. Тогда оставляем либо начальника, либо ведущего прога.
Остался вопрос двойной работы. Надо двигать карточки на канбан доске и закрывать задачи в Service-desk. На прогов повесить такую обязанность?
В идеале, конечно, интегрировать канбан доску с сервисдеском..
66 Irbis
 
05.03.20
12:55
(64) Херня и бардак. Задачи распределяет куроводитель! Иначе бардак обеспечен.
67 Irbis
 
05.03.20
12:58
Задачу сдают заказчику. Только он может закрыть в SD как решённую или написать мотивированное возражение. Автоматически (по сроку) закрываются задачи, которые заказчиком не закрыты по истечение регламентированного промежутка времени.
68 Надо работать
 
05.03.20
12:59
(36) надо так писать

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

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

//Петров 20200221 конец
69 Irbis
 
05.03.20
13:00
(68) +
// Петров огрёб звиздюлей за не согласованную офигенную фичу
// Фичу не трогать
70 Арбузов
 
05.03.20
13:01
(50) Вот поэтому я такой херней и не занимаюсь, есть задача, есть срок, утвержденный бизнесом и ИТ, а то, что внутри, какие там согласования с архитектором и документы - кому какое собачье дело, если всё будет закончено качественно и не позже установленного срока.
71 Irbis
 
05.03.20
13:06
(70) И даже документацию успеете в срок без согласования разработать и сделать?

Свежий пример. В приказе написали "Срок: ежемесячно до 17 часов 11 числа", вместо "Срок: ежемесячно 11 числа до 17 часов". Куча народу согласовала, а вчера удивились что я работу исполнил 04.03, а не как они написали 11.03.
72 Арбузов
 
05.03.20
13:11
(70) В сроке документация обычно заложена, согласование - тут уж как у кого заведено, если есть нормированные сроки на согласование от бизнеса, то можно и включить. Но понятно, конечно, что всё это работает, когда одну задачу пилит один разработчик. Если же разработчиков на одну задачу несколько, вот тут уже без декомпозиции и ежедневной "сверки часов" никак. И применять, скорее всего, надо немного разные подходы.
73 Irbis
 
05.03.20
13:22
(72) Когда работает два жида в три ряда, вообще ничего из написанного не нужно.
74 Арбузов
 
05.03.20
13:29
(73) А вдруг контора вырастет? И в этом случае процесс поставить будет на порядок труднее, если сейчас не начать. Есть сейчас такая история на виду, когда всё запустили к чертям, а сейчас 1С-ников в регионе ищут от 160 на руки, и начальников отделов 1С от 200...
75 Арбузов
 
05.03.20
13:38
Кстати, интересная статейка об оценке проектов https://habr.com/ru/company/maxilect/blog/489604/
76 Asmody
 
05.03.20
13:46
(0)
Agile, scrum – fuck you, I'm Russian.
Khuyack-khuyack to production!
77 Irbis
 
05.03.20
13:47
(74) А вот тут О'Хара была права: "Об этом я подумаю завтра"
78 Арбузов
 
05.03.20
13:59
(77) Может быть. Но нужное направление мыслей надо пытаться в головы начальников внедрять как можно раньше :))
79 Irbis
 
05.03.20
14:02
(78) А вот это делать не нужно. По крайней мере, до тех пор пока сами начальники не попросят об этом. Иначе это будет поперёд батьки в пекло, и инициатива отымеет инициатора во все физиологические отверстия, а возможно и в пару новых, нештатных.
80 Арбузов
 
05.03.20
14:11
(79) Ну тут кому как нравится :))
81 VladZ
 
05.03.20
14:48
Ну и не забываем про "ж*пу и форточку": https://www.youtube.com/watch?v=-uGdaKFboHo