"Просто надо набрать блестяще умных, мотивированных, лично эффективных, при этом все еще достаточно скромных людей которые не считают зазорным не только "творить великое", но еще и делать это в срок, и сопровождать это качественной коммуникацией в сторону клиента."
Распечатаю и буду применять как визитку утопических ответов.
Основные метрики мониторят время. Дедлайн на выполнения вопроса.
Есть ли хитрецы играющие со статусами? Например "отписка наообум т.к. ничего не делал и изменил статус с "В работе" на "Тестируется пользователем", а потом пользователь проверят и возвращает задачу в работу, т.к. отписка не работает"...
Как вы предлагаете оценивать работу сервисных отделов ИТ. По отзывам сотрудников? По количеству выполненных задач? Просто потому что они приходят на работу?
Я согласен с вами в том, что оценка качества это очень сложная тема и требует индивидуального подхода к оценке задач и людей учитывая их специфику.
Автор предложил систему учёта и оценок. Называет её рабочей и успешной. Хотелось бы конечно услышать мнение сотрудников по этому вопросу.
Интересно как вы группируете задачи? Интересно название метрик которые вы оцениваете. Интересны оценки ежедневные и кто этим занимается?
Какие сложности внутри команды были? Провокации? Саботаж?
Поддержку сложно оценивать. Если разработку ещё можно оценить по Скраму или Канбану, то поддержка это вечный ватерфол со спецификой сотрудника. Один решая задачу напишет инструкцию и при следующих обращениях будет кидать в ответ ссылку, а другой замкнет на себе столько процессов пользователя и будет делать их за пользователя, считая себя полезным и незаменимым.
Еще интересно, как автор объяснял систему контроля топ руководству. Ген.диру или собственникам.
Спасибо за ответы.
Джон7 TQM возьму для себя на заметку к изучению. Спасибо за развернутый ответ автора.
Во-первых, спасибо за то, что делитесь опытом. От этого ИТ сообщество становится лучше и на рынке больше порядка должно быть.
Во-вторых, философский вопрос про бизнес ценность. Соглашусь, что если речь идёт об автоматизации нового бизнес процесса, то да, без всей автоматизации его часть не имеет ценности. Но если её грамотно разробить на задачи то начинает иметь, а вот поддержка или доработка существующего автоматизированного функционала почти всегда это бизнес ценность.
Привожу примеры: новый блок автоматизации, задача автоматизировать 100% выборочный контроль продукции новой партии товаров (2 упаковки нужно проверить из 200, к примеру). ТЗ: документ заказ на 100% ВК, печатная форма к заказу, документ проведения контроля, печатная форма проведения, отчёт для руководителя по всем заказам и результатам. Что я хотел сказать: часть "документ заказ на 100% ВК, печатная форма к заказу" уже бизнес ценность и может быть выложена заказчику как 1 этап.
Пример 2. Автоматизированный контроль каждой продукции в ходе производства детали и прохождения ею этапов производства. Уже есть документ ввода значений брака, представим его себе таблицей где сотрудник вводит новую строк, выбирает товар и далее заполняет в строке таблицы 10-15 колонок. Так вот, пока я не увидел то, что они для 30-40 однотипных случаев все это делают руками по каждой строке не было новой, конечной бизнес ценности сделать фичу заполнения этих 10-15 колонок по выделенным строкам. А это условно 30 сек. на строку, что 15-20 минут высвобожденного времени для сотрудника заняться другой работой.
Идея группировок тасков хороша. Я её применял на проект целиком. Проект имеет свою ценность, общая сумма. Проект делю на этапы (бюджет этапа). Этап включает в себя таски.
Как-то так)
Вопрос: вы этот инструмент ведения под себя писали или брали что-то готовое?
Сбой как то комментируют официально? У нас вроде все ок, работает тимс и почта
Великолепная цитата:
"Просто надо набрать блестяще умных, мотивированных, лично эффективных, при этом все еще достаточно скромных людей которые не считают зазорным не только "творить великое", но еще и делать это в срок, и сопровождать это качественной коммуникацией в сторону клиента."
Распечатаю и буду применять как визитку утопических ответов.
Ещё раз спасибо за наводку на ценную литературу.
Получается ваша система приследует основную цель: напоминание сотрудником о задаче и сроках. Это здорово.
А какое количество задач в среднем поступает в день всего и в расчете на одного человека?
Спасибо за развернутый ответ.
Основные метрики мониторят время. Дедлайн на выполнения вопроса.
Есть ли хитрецы играющие со статусами? Например "отписка наообум т.к. ничего не делал и изменил статус с "В работе" на "Тестируется пользователем", а потом пользователь проверят и возвращает задачу в работу, т.к. отписка не работает"...
Как контролируете качество выполнения задач?
Как вы предлагаете оценивать работу сервисных отделов ИТ. По отзывам сотрудников? По количеству выполненных задач? Просто потому что они приходят на работу?
Я согласен с вами в том, что оценка качества это очень сложная тема и требует индивидуального подхода к оценке задач и людей учитывая их специфику.
Автор предложил систему учёта и оценок. Называет её рабочей и успешной. Хотелось бы конечно услышать мнение сотрудников по этому вопросу.
Интересно как вы группируете задачи? Интересно название метрик которые вы оцениваете. Интересны оценки ежедневные и кто этим занимается?
Какие сложности внутри команды были? Провокации? Саботаж?
Поддержку сложно оценивать. Если разработку ещё можно оценить по Скраму или Канбану, то поддержка это вечный ватерфол со спецификой сотрудника. Один решая задачу напишет инструкцию и при следующих обращениях будет кидать в ответ ссылку, а другой замкнет на себе столько процессов пользователя и будет делать их за пользователя, считая себя полезным и незаменимым.
Еще интересно, как автор объяснял систему контроля топ руководству. Ген.диру или собственникам.
Спасибо за ответы.
Джон7 TQM возьму для себя на заметку к изучению. Спасибо за развернутый ответ автора.
Давайте в комментах накидаем действительно классные курсы или книги по теме.
Во-первых, спасибо за то, что делитесь опытом. От этого ИТ сообщество становится лучше и на рынке больше порядка должно быть.
Во-вторых, философский вопрос про бизнес ценность. Соглашусь, что если речь идёт об автоматизации нового бизнес процесса, то да, без всей автоматизации его часть не имеет ценности. Но если её грамотно разробить на задачи то начинает иметь, а вот поддержка или доработка существующего автоматизированного функционала почти всегда это бизнес ценность.
Привожу примеры: новый блок автоматизации, задача автоматизировать 100% выборочный контроль продукции новой партии товаров (2 упаковки нужно проверить из 200, к примеру). ТЗ: документ заказ на 100% ВК, печатная форма к заказу, документ проведения контроля, печатная форма проведения, отчёт для руководителя по всем заказам и результатам. Что я хотел сказать: часть "документ заказ на 100% ВК, печатная форма к заказу" уже бизнес ценность и может быть выложена заказчику как 1 этап.
Пример 2. Автоматизированный контроль каждой продукции в ходе производства детали и прохождения ею этапов производства. Уже есть документ ввода значений брака, представим его себе таблицей где сотрудник вводит новую строк, выбирает товар и далее заполняет в строке таблицы 10-15 колонок. Так вот, пока я не увидел то, что они для 30-40 однотипных случаев все это делают руками по каждой строке не было новой, конечной бизнес ценности сделать фичу заполнения этих 10-15 колонок по выделенным строкам. А это условно 30 сек. на строку, что 15-20 минут высвобожденного времени для сотрудника заняться другой работой.
Идея группировок тасков хороша. Я её применял на проект целиком. Проект имеет свою ценность, общая сумма. Проект делю на этапы (бюджет этапа). Этап включает в себя таски.
Как-то так)
Вопрос: вы этот инструмент ведения под себя писали или брали что-то готовое?