Все записи по управлению проектами, ITIL, COBIT и SCRUM
Сегодня поговорим о такой важной части управления процессами эксплуатации услуг как удовлетворённость. Под процессами эксплуатации я в частности буду иметь в виду два, которые больше всего «На виду» — управление инцидентами (Incident Management) и управление запросами на обслуживание (Request Fulfillment).
7 апреля 2016 компания Cleverics проводила в Минске деловую игру Grab@Pizza, участником которой мне посчастливилось стать.
Ниже хочу поделиться некоторыми наблюдениями по ходу игры и полученными результатами. наконец-то. Год прошёл))
Краткое пособие о том как прочитать процесс, описанный с помощью IDEF0 нотации.
IDEF0 — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Традиционно применяется для описания процессов в укрупнённых блоках, с указанием связей между ними. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность.
Начальная страница диаграммы содержит только один блок. Это «чёрный ящик», описывающий предметную область или систему в целом. Все остальные страницы называются «декомпозицией» и могут содержать произвольное количество функциональных блоков.
Мы все любим себя. В той или иной степени. Гордимся своими достижениями и стараемся при возможности их показать. Это очень сильно заметно например в тренажёрном зале. Не успел ты набрать (ну, или сбросить, в зависимости от целей) 1-2 кило как уже вместо эффективных занятий всё чаще заглядываешь в зеркала, так удачно развешанные по всему залу, поигрывать мышцами на публику и всячески себя со всех сторон осматривать. Думаю, многим такое знакомо.
Признаюсь честно, я тоже вёл себя так и очень быстро заметил, что результаты приходят медленнее, а тренировка становится не такой эффективной. Я нанял тренера, который составил мне программу тренировок и ходил за мной по залу от первого до последнего упражнения. Всё записывал и контролировал. И что произошло? Правильно, тренировка стала эффективнее, результаты заметнее и приходили быстрее. И вот какая мысль мне пришла в голову. А ведь очень часто так же происходит и с организацией работы. Ты выстраиваешь систему управления, налаживаешь процессы, пишешь регламенты и правила и дико гордишься тем, как у тебя всё хорошо работает. Но так ли это на самом деле?
Читать далее
Как всегда, идея для очередной заметки появляется после прочтения чужого материала. Вот и в этот раз статья про управление приоритетами подтолкнула к написанию данного материала.
Сразу оговорюсь, в материале ниже речь пойдёт только об изменениях, связанных с разработкой или доработкой ПО и не относится к изменениям, проводимым над оборудованием или серверным ПО.
Итак, условия задачи следующие. Есть самое обычное подразделение с n разработчиками, известной скоростью выполнения задач и средняя скорость появления новых задач. При этом новые появляются быстрее, чем обрабатываются накопленные ранее.
Введём дополнительное условие. Очередной пользователь\руководитель среднего звена получил по шее от вышестоящего руководителя за сорванную автоматизацию (не проконтролировал, не согласовал ТЗ, не принял работу и т.д.). Что имеем в итоге? Правильно, прибегает весь взмыленный заказчик с криками «а ну-ка быстро всё сделайте, надо было ещё вчера, это очень важно! Этим вопросом уже интересуется <здесь имя очень главного очень авторитетного руководителя>».
Эта новость свалилась на меня так внезапно, что я даже не успел осознать всю глубину происходящих со мной изменений. С повышением часто так бывает — происходит в самый неподходящий момент (например, перед самым отпуском, например) или тогда, когда этого совсем не ожидаешь. Например, в среду в 12:21, когда у тебя спланирована каждая минута и нужно очень постараться чтобы уложиться во все возможные графики и планы.
И вот сидишь и не можешь ничего сообразить. Потому что жизнь меняется абсолютно решительным образом. У меня ушёл целый день на то, чтобы осознать масштаб бедствия и попробовать что — то спланировать. Пытаясь изучить вопрос плавного перехода в новую должность я накопал много интересных материалов, соображениями о которых и хочу поделиться.
У Элияху Голдратта есть замечательная книга, бизнес-роман «Цель». В нём подаётся много умных мыслей, которые я не однократно пытался натягивать на разработку ПО (ведь по сути, разработка ПО сравнима с изготовлением любой другой продукции, только вместо станков — программисты, а вместо сырья — программный код и среды разработки). Но лично для себя я вынес одну мысль, которая сильно упростила процесс передачи готового ПО заказчику и оценки результатов. У всего должна быть цель. И чем более чётко цель сформирована и чем лучше её понимают все участники процесса — тем быстрее и проще происходит внедрение новых разработок.
Недавно я взялся делать газон на даче. Очистил территорию от сорняков, прошёлся пару раз культиватором, расставил маяки высоты и натянул разметочный шнур. И начал выравнивать горизонталь. Процесс дошёл до некой точки и вдруг я понял что я выбрал слишком высокий уровень для газона и мне не хватит земли для того, чтобы выровнять все неровности участка. Этого можно было бы избежать, если бы изначально я не погнался за красотой боковой линии и реально оценил бы объём земли, который мне понадобится.
Казалось бы, при чём тут управление IT отделом?
Читать далее
Такое понятие как «миссия» чаще всего применяется для уровня всей компании, и очень редко когда для отделов или департаментов компании. Но всё же применяется. Так зачем определяется миссия подразделения и что должно последовать за этим?
Этой записью хочу начать цикл материалов об организации работы IT отдела в непрофильной компании.
В Беларуси (а в России тем более) уже давно многие компании вместо услуг внешних подрядчиков формируют свои IT отделы для разработки и обслуживания своих информационных систем. Часто такие системы бывают достаточно сложными и содержат много информации, которую не хотелось бы выносить за пределы компании.
Сегодня хочу рассказать о том, почему в таких отделах не работает планирование спринта как того рекомендует методология SCRUM и как с этим жить.