Теория когнитивной нагрузки (Cognitive load theory) Джона Свеллера, популяризированная в мире ИТ книжкой про командные топологии, не только и не столько о том, как правильно выстроить обучение и не перегрузить людей избыточной информацией. Рассуждения о том, что способствует обучению, а что мешает, безусловно, важны, но начинается теория когнитивной нагрузки с описания некоторой (путь и крайне простой) модели организации памяти. В ней память человека делится на рабочую, используемую в данный конкретный момент и отвечающую за обработку информации для текущего действия, и долгосрочную, которая хранит уже имеющуюся информацию и обогащает ей новыми знаниями. Читать далее Теория когнитивной нагрузки и архитектура предприятия
Рубрика: IT Project
Управление портфелем ИТ проектов
На недавнем вебинаре: ИТ-архитектура и управление изменениями. Обновление процесса CHG мы рассматривали процесс изнутри. Надеюсь, что это было полезным и содержательным. Однако взгляд с такой точки зрения сопровождается одним допущением – запросы на изменения поступают к нам из внешней среды случайным образом и в случайные моменты времени. Безусловно, это не так и в реальной жизни мы знаем о количестве и содержании будущих запросов на изменения немного больше, чем ничего. Особенно если наши бизнес-заказчики ведут плановое хозяйство, собирают свои пожелания на следующий год как-то устанавливают их приоритеты, классифицируют изменения, отделяют главное от самого главного, важное от срочного, появление новых продуктов от улучшения существующих. Читать далее Управление портфелем ИТ проектов
О пользе проектного офиса
В июне 2010 года я разместил в этом блоге сообщение О вреде проектного управления, а чуть позже расширил тему в кратком обзоре гартнеровской статьи Projects Today, “Change Operations” Tomorrow. По законам жанра рано или поздно должна была появиться и сегодняшняя заметка. И дело совсем не в том, что я изменил свое отношение к корпоративным проектам. Пренебрежительное отношение к диаграммам Ганта, регулярному подкручиванию процента выполнения работ, наукообразным рассуждениям о методе критического пути и инструментам, типа MS Project, предназначенным для отображения фиктивной отчетности по проектам у меня сохранилось. Точно так же сохранилось убеждение в полезности средств организации совместной деятельности, общего информационного пространства, трекеров и событийных лент. Но речь совсем не о том. Я хочу рассмотреть проектный офис как некоторый социальный институт внутри компании, форму организации совместной деятельности людей, обладающей признаком самовоспроизводимости. Читать далее О пользе проектного офиса
Requirements as a Service
Одно время в моей ленте в FB довольно часто проскакивали сообщения о реестре отечественного ПО. Полное название этого чудесного справочника Единый реестр российских программ для электронных вычислительных машин и баз данных. Кто-то искренне радовался включению в этот список своей программы. Другие искренне негодовали по поводу очередной глупости чиновников. Третьи ностальгировали по временам своей молодости, вспоминая такую штуку, как фонд алгоритмов и программ. Меня же во всей этой истории удивляло только одно: почему во второй декаде XXI века эта штука называется реестр, а не marketplace. Слово реестр устойчиво ассоциируется с документооборотом. Мол есть где-то там сами программы(вероятно в виде распечатанных исходников), но чтоб вам, дорогие друзья, их самим все не просматривать, мы подготовили для вас единый реестр. Читать далее Requirements as a Service
Руководство по разработке му́ды
Изучая статистику посещений блога по архитектуре информационных систем за прошлый год, я обнаружил, что заметка Функциональные карты и диаграммы вариантов использования оказалась безусловным лидером. Вероятной причиной тому – вымышленная история о постижении одним ведущим бизнес-аналитиком практик использования функциональных карт. Сохранив главного героя, немного ленивого, немного архаичного, но еще не забывшего основы UML и, возможно, пользующегося авторитетом в трудовом коллективе, я буду вести повествование от его имени. Итак, мы возвращаемся к нашему бизнес-аналитику в тот момент, когда он с интересом изучает план научно-исследовательских работ на текущий год. Читать далее Руководство по разработке му́ды
Роль ИТ-архитектора в организации
Несколько месяцев назад я написал заметку Когда, кому и зачем нужна Архитектура Предприятия Справедливости ради надо отметить, что полномасштабный проект по выстраиванию Enterprise Architecture встречается достаточно редко. Намного чаще услуги архитектора бывают востребованы для решения более локальных задач: структурирование приложений, процессов и данных в рамках отдельного продукта, бизнес-функции или направления деятельности организации. В таких случаях обычно говорят об архитектуре ИТ-решения, а человека который её делает называют Solution architect. Одной из задач этого уважаемого эксперта является разработка архитектуры в ИТ-проекте. На прошлом месте работы мы называли эту деятельность High Level Design Но у Solution architect есть еще одна, не менее важная задача – подготовка вариантов решения. О том как это сделать можно почитать здесь Create a solution architecture А я напишу несколько слов о том, почему это важно. Читать далее Роль ИТ-архитектора в организации
Бизнес-аналитики – друзья, соседи или дальние родственники?
Томительное ожидание выхода третьей версии свода знаний по бизнес-анализу A Guide to the Business Analysis Body of Knowledge (BABOK v3) вызывает у меня противоречивые чувства. (Поэтому я и решил полностью переписать предыдущую заметку.) С одной стороны International Institute of Business Analysis (IIBA) это довольно типичная организация по написанию и продаже дорогих книжек, развитию региональных представительств и многоуровневых систем сертификаций. Все подобные организации, правильнее их было бы назвать сектами, сделаны по одному шаблону. И проблемы у них у всех одинаковые: изменения освещаемой ими темы происходят намного быстрее, чем издаются очередные релизы их главных книжек. Адепты такого кунг-фу сильно рискуют обнаружить абсолютную ненужность приобретенных навыков к моменту достижения черного пояса. Впрочем, каждый зарабатывает, как умеет. С другой стороны контент BABOK мне кажется достаточно содержательным Читать далее Бизнес-аналитики – друзья, соседи или дальние родственники?
Консультант по развитию бизнес-приложений
В прошлом году нас в очередной раз стали учить передовым методикам сокращения времени вывода на рынок новых продуктов и услуг, т.е. пресловутому уменьшению Time to Market. Делала это одна известная консалтинговая компания, и выглядело это довольно слабо. Никто толком не разобрался в том, как у нас сейчас обстоят дела. Не потряс перед нашим носом хоть какими-нибудь эталонами моделями, не обозначил gaps. В общем, не поставив диагноз, сразу прописали agile и отпустили лечиться. Чего стоит рекомендация: «не дожидаться завершения разработки интегрируемых приложений, а использовать при тестировании вместо реальных интерфейсов заглушки». Прямо скажем, откровение из арсенала «Капитана очевидность». Одним словом, все как в анекдоте про коров, которых надо меньше кормить и чаще доить.
Естественно, мне не очень хотелось выглядеть похожим на этих персонажей при проведении Мастерской по инженерии программных продуктов. Поэтому, в декабре я потратил некоторое время на то, чтоб поразбираться с подходами к развитию программных продуктов. Не скажу, что со времен глобального увлечения CMMI что-то принципиально изменилось, но некоторые интересные моменты удалось не только узнать, но и попробовать. Читать далее Консультант по развитию бизнес-приложений
Проект IT Transformation
Наступил месяц декабрь. За окном падает легкий снег и я думаю, теперь уже можно считать, что проект ИТ трансформации у нас, наконец, закончился. Ну, в основном, закончился. У нас нет орг.структуры, у нас нет CIO, нет так же руководителя проектного офиса ИТ, менеджера основного ИТ проекта, нет стратегии, но… зато у нас есть целевая архитектура (target architecture). Не то чтоб совсем актуальная, ну да ладно. Это уже мой третий проект ИТ трансформации, поэтому если кто решил трансформировать свой ИТ, но не знает с чего(или с кого) начать, обращайтесь Читать далее Проект IT Transformation
Ресурсное планирование и отслеживание трудозатрат
Начиная эту заметку, я должен сделать два предварительных замечания. Во-первых, тема ресурсного планирования не имеет какого-либо отношения к архитектуре информационных систем. Разве что, кроме того случая, когда архитекторам начинают задавать вопрос а почему это вас так много, а архитектуру вы рисуете так долго. К сожалению, у меня в очередной раз произошел этот самый случай и мне хочется поделиться удачными и не очень удачными вариантами ответа на этот вопрос. Во-вторых, мой многолетний опыт показывает, что ресурсное планирование и отслеживание трудозатрат knowledge workers обычно никак не влияет на размер материальной мотивации, но практически всегда разрушает мотивацию нематериальную, причем делает это очень быстро. Читать далее Ресурсное планирование и отслеживание трудозатрат