Всё это - ЛЮДИ Archives – Страница 14 из 59

Анонс весенне-летнего сезона вебинаров CleverTALK

Уже в этот четверг начинается шестнадцатый сезон вебинаров по управлению ИТ CleverTALK. В этой новости представлено описание каждого вебинара: дата проведения, программа и ведущий. Начало каждого вебинара традиционно в 11:00. 16 мая. ITIL Practitioner – актуальная книжка или уже нет? Ведущий: Игорь Гутник, директор по обучению Cleverics, ITIL Expert, ITIL Practitioner, DevOps Master Программа: – Публикация «ITIL Practitioner Guidance», вышедшая в 2016 г. описывает подход к реализации ITSM-инициатив и иногда упоминается как «инструкция по применению ITIL».– Как соотносится содержимое этой публикации с содержимым публикации «ITIL 4 Foundation», вышедшей в 2019 г.? (Спойлер: Сильно пересекается)– Как структурировать подход к реализации ITSM-инициатив?…

Как соотносятся роли Service Owner и Service Level Manager

Думаю, следует сразу уточнить, что рассматривать соотнесение ролей будем в контексте ITIL V3. В ITIL4 Foundation детального описания ролей, участвующих в практиках, нет, так что ждём. Мысль рассмотреть эти две роли, что называется, в связке, возникла не просто так. На неё навели вопросы слушателей курсов линейки ITIL Intermediate. Многих по-прежнему несколько сбивает с толку обилие вариаций названий ролей, начинающихся со слова “service”. А также до сих пор в некоторых компаниях циркулирует словосочетание “Service Manager”, которого в ITIL уже давно нет. Апофеоза эта путаница достигает в контексте процесса управления уровнем услуг (Service Level Management). Попробую структурировать информацию из первоисточника. Итак, согласно…

Роль Agile-лидеров сейчас важна как никогда прежде

В наш бешено рвущийся вперёд век организации имеют дело с изменениями, происходящими в значительно ускоренном темпе. Мало кто может избежать этого всеохватывающего влияния, и многим нужно переосмыслить свои прежние подходы, чтобы успешно развиваться в этой новой динамичной среде – там, где Agile-лидеры чувствуют себя как рыба в воде. Традиционно, изменения в компаниях инициировались сверху. Кому-то из высшего руководства приходила в голову отличная идея и этот кто-то задавался вопросом: «Как получить поддержку этой идеи у всех в компании?». Но такой подход не только слишком часто терпел неудачу, он вообще больше не имеет смысла в сегодняшней рабочей среде, где сотрудники нового поколения…

Новостной поток, 29 апреля 2019, последний комментарий 8 мая 2019

Как правильно распределить 6 заявок на 4х сотрудников?

В редакцию портала поступил вопрос: Вопрос про конвеер заявок. Допустим поступает 5 заявок на 4х сотрудников. 4 раздаются автоматом, а как бысть с 5й? Варианты: 1) Заявка висит в очереди, пока кто-то не освободится и не закроет свою, а после этого назначается на первого освободившегося. 2) 5 заявка назначается сотруднику 1, 6-я — сотруднику 2. В итоге сотрудники уже имеют в работе по 2 заявки одновременно. Но тогда появляется ситуация, что OLA (расчетное время выполнения одной задачи) посчитано по одной заявке, а время идёт сразу по двум (т.е. получаем что либо сотрудник должен в два раза быстрее теперь справиться, либо…

Вопрос из зала, 15 апреля 2019, последний комментарий 15 мая 2019

Достижимая стадия?

Прочитал на днях записки одного бизнесмена. В них он описывает стадии развития своей компании. По его мнению, таких стадий три (я думаю, что только ими весь генез не исчерпывается, но это текущее мироощущение автора тех записок). Краткий пересказ. Стадия 1. “Я лидер, я сказал!”. На этой стадии самый “умный” – лидер. Остальные – его “слуги”. Лидер говорит, что им делать, они выполняют. Задача лидера на данной стадии развития компании – говорить, что именно, и кому делать. Стадия 2. “Бюрократия”. Описаны процессы, прописаны регламенты. Внедрены штрафы. Система! Всё крутится, работает ровно, но ошибки всё равно возникают. Ищут виновных, потом наказывают, штрафуют….

Денис Денисов, 15 апреля 2019, последний комментарий 17 апреля 2019

DevOps: лошади и единороги

В своей свежей статье Paul Wilkinson делится с нами немного юмористическим “классификатором компаний”, прокладывающих свой путь к “состоянию DevOps” или только планирующих в него перейти. Кто хочет стать “единорогом“? Найдите себя (текущего или будущего) в этом списке. И постарайтесь быть объективными. Классификация, предложенная автором, появилась не случайно. На её создание автора натолкнули вопросы, стоящие перед компаниями, представители которых принимали участие в бизнес-симуляции “Проект Феникс – DevOps на практике“. Многие из них пытались оценить текущий или перспективный уровень своих DevOps-практик, опираясь на какую-то понятную классификацию. Итак, вот она! Работает “по запросу” Движется наугад Цель не ясна Слепо следует рекомендациям “хороших практик”…

Новостной поток, 3 апреля 2019, последний комментарий 9 апреля 2019

Обратная связь: подход к использованию

Поделюсь озарившей меня идеей без претензии на серъезную и исчерпывающую проработку концепции. В своей практике организации работы поставщиков услуг я неоднократно сталкивался с проблематикой получения обратной связи, как таковой – трудно склонить пользователей услуг тратить время на ее формирование. В практике предоставления обратной связи об использованных продуктах или услугах я и мои близкие неоднократно сталкивались с ситуацией, когда данная обратная связь была истолкована ограниченно или очевидно не могла иметь конструктивных последствий. В определенный момент вся эта противоречивая картина сложилась для меня в некую систему. Для начала представим ее графически: Итак, что мы имеем. Вариант контакта по поводу обратной связи может…

Андрей Шилов, 25 марта 2019, последний комментарий 1 апреля 2019

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

Рассмотрим кейс. Предположим, есть продуктовая команда – группа высококвалифицированных специалистов, создающая и развивающая продукт, основанный на информационных технологиях. Команда отвечает и за выявление потребностей, и за доработку ИТ-систем, и за развёртывание изменений, и за эксплуатацию всего решения. Предположим также, что данная команда переносит наработки в среду эксплуатации через релизы (накопленные изменения) и имеет сложности с регулярностью и частотой релизов: много изменений собираются вместе, влияют друг на друга, разом тестируются через “регресс”, не все тесты проходят успешно, уходим на второй круг, снова куда-то ушли месяц или два. Есть и целый букет технических сложностей, связанных с выделением ИТ-ресурсов для разных сред, низкой…

Олег Скрынник, 22 марта 2019, последний комментарий 25 марта 2019

Улучшаем пользовательский опыт: четыре совета

По мере того, как растёт количество ИТ-систем, увеличивается масштаб и важность их для бизнеса, мы иногда упускаем из виду, что для каждой системы, которая развёртывается в продуктивной среде, возникает сообщество пользователей, полностью зависящих от неё при выполнении своей ежедневной работы. Практически любой бизнес теперь завязан на технологиях для выполнения своих основных повседневных задач во всех ролях организации, больших или малых. Подобный рост приводит к тому, что мы, как ИТ-специалисты, должны инвестировать больше времени, энергии и своего внимания в такую область как пользовательский опыт (User Experience, UX). Кевин Смит (Kevin J. Smith) в своей заметке даёт четыре совета по улучшению пользовательского…

Новостной поток, 10 марта 2019, последний комментарий 21 марта 2019

Четыре способа повысить эффективность подрядчиков

Что значит “хорошо управлять подрядчиками”? Как оценить, хорошо вы это делаете или не очень? Автор данной заметки в качестве итога своих рассуждений приводит следующий тезис: Хорошо управлять подрядчиками – это значит обеспечить прозрачность и управляемость взаимодействия, направленного на то, чтобы подрядчик получал удовольствие от процесса и предоставлял нам качественные услуги тогда, когда они нам необходимы. Даже в литературном переводе приведённой цитаты сразу видна основная идея. Необходимо выстроить прозрачную и понятную систему принципов, на которую будет опираться взаимодействие с подрядчиками. Автор статьи предлагает четыре конкретных аспекта, о которых следует задуматься. Стимулируйте коллективную ответственность за успех Вам не нравится, что подрядчики пытаются…

Зачем нужен Change Management?

Вопрос без подвоха. Ну почти. Его контекст довольно-таки прост. Если конкретизировать, то он звучит так: “как сформулировать для руководства бизнеса и ИТ, а также для персонала ИТ-департамента преимущества от инвестиций в постановку и автоматизацию процесса управления изменениями?”. То есть нужно максимально просто и понятно объяснить указанным заинтересованным сторонам, зачем нужно упорядочить и формализовать деятельность по управлению изменениями. Для начала попробуем наморщить лоб, с умным видом пошелестеть страницами умных книг (вы знаете, каких) и выдать “научную” формулировку. Во всем известной библиотеке ITIL, в книге Service Transition написано довольно много слов про “назначение и задачи”, “ценность для бизнеса”, “организационные преобразования”, “формирование культуры”…

Артём Мукосеев, 24 февраля 2019, последний комментарий 17 марта 2019

Портал №1 по управлению цифровыми
и информационными технологиями

Всё это – ЛЮДИ