Есть несколько вопросов, которые мне задают практически каждый день. Сколько данных нам нужно для надежного прогнозирования доставки? Что делать, если у нас нет исторических данных? Что если у нас много данных, но мы им не доверяем? Как выбрать “скользящее окно” данных для прогнозирования доставки?
Наверняка вам приходилось слышать от знакомых или коллег, что их организация пошла по пути Agile в управлении поставкой ценности клиентам. И часто в таких разговорах говорят, что мы, конечно, используем гибкие методы управления разработкой, «но» есть несколько вещей, которые мы делаем по-другому. Вам такое знакомо? Вы когда-нибудь представляли степень влияния этого «но»? Мы гибкие, но: Мы до сих пор используем модель водопада. Мы по-прежнему составляем полный план проекта / релиза. Нам все ещё нужно убедиться, что все требования полностью прописаны. Меняющиеся требования наших клиентов сводят нас с ума. Нам все ещё нужно готовить массу документации. Наши заказчики хотят только ускорения…
Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки, сколько заявок приходит от какого филиала, сколько распределяется на какого специалиста поддержки, что чаще всего ломается и требует внимания. Понять объективно, а не в ощущениях. И понимать регулярно. Нет, я не помешан на метриках и отчётах. Знаю много случаев, когда управленческие решения принимаются вовсе без данных, и оно срабатывает. Что уж там говорить, с 2009 года, когда появился Cleverics, мы в нашей компании принимаем сотни решений каждый год,…
Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их необходимо создавать и развивать. При этом, если ваша организация – это не недавно созданный стартап, то скорее всего она жила и функционировала уже какое-то время. А значит гибкий команды, по сути, будут состоять из тех же самых людей, что поддерживали развитие бизнеса через внутреннюю разработку ИТ-продуктов всё время существования компании. Изменения не всегда могут приветствоваться людьми, которых они затрагивают. Есть устоявшиеся процессы, в которых сотрудники чувствуют себя комфортно. Им может казаться, что организовать работу другим способом просто невозможно. Часто…
С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным камнем для производства, и они очень любят знать все правила и сроки, прежде чем вписаться в проект. Приёмы мотивации других работников не срабатывают для разработчиков просто потому, что их деятельность сильно отличается. Но не волнуйтесь, здесь приведены лучшие советы о том, как ускорить процесс разработки программного обеспечения, не став предметом ненависти сотрудников. В этой статье мы поговорим о том, как общаться с заказчиками, клиентами и разработчиками, чтобы быстрее достичь целей. Получайте обратную связь…
Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями – как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
Любое серьёзное преобразование в компании, от “внедрения” какого-либо нового ИТ-процесса до пресловутой цифровой трансформации, является организационным изменением: требуется изменить уже имеющиеся системы управления, чтобы они стали работать по-новому, или обрели новые свойства и способности. Приходится работать с формальной стороной (регламенты), культурной стороной (как у нас принято делать дела), технической составляющей, политической и так далее. Это – очень интересная работа, проводить организационные изменения в средних и крупных компаниях. К счастью, в области управления орг.изменениями накоплено достаточно знаний и опыта – есть замечательные публикации, методики, инструменты. Некоторые из них применяются уже десятки лет, другие являются относительно новыми. В частности, некоторые эксперты выделяют…
Каждые 50-60 лет происходит смена парадигмы, которая влияет на социальный, деловой и экономический порядок. Цифровая эпоха открывает новую.
“Странный вопрос!” – подумал я. Но я стараюсь быть осторожным в своих суждениях. Некто спросил меня, считаю ли я, что управление ИТ-продуктами – это действительно управление продуктами? Это не было провокационным вопросом, но я подозреваю, что сейчас многие из тех, кто работает над созданием внутренних инструментов поддержки, отреагирует на него недоброжелательно. Суть этого вопроса скрывает опасение, что такая строчка в резюме может помешать потенциальной карьере менеджера продукта. Это явная неправда. Разумеется, развитие продукта, созданного для внутренних пользователей, является управлением продуктом. И всё же должна быть какая-то причина, которая заставляет сомневаться в статусе менеджера ИТ-продукта. Возможно, некоторые люди думают так, поскольку…