Я — Максим Цепков приветствую Вас на своем сайте

Материал из MaksWiki
Перейти к: навигация, поиск
Сейчас

03.03 — гостевая лекция ВШЭ СПб Методы Agile и бирюзовых организаций для организации работы креативных команд

Кто я?

  • Навигатор по миру Agile, бирюзовых организаций и холакратии
  • Эксперт по Спиральной динамике
  • Эксперт по трансформации бизнеса с помощью IT, архитектор и бизнес-аналитик

Выступаю, консультирую и провожу сессии разбора кейсов по всем этим темам — обращайтесь

Agile родился в IT как ответ на вызовы менеджмента 21 века (Питер Друкер) и MindSet поколения соц.сетей, и сейчас идет в другие отрасли, в которые эти вызовы успешно приходят. Активно участвуя в развитии Agile с 2007 года, я готов помочь разобраться в нем другим людям, включая практики Холакратии и Бирюзовых организаций, а также модель Спиральной динамики, которая дает общую картину развития человека и организаций через развитие систем ценностей. Я так же готов разобрать конкретные кейсы Вашей организации, сопоставить теорию с практикой, проконсультировать, какие практики Вам подходят и почему, и каких профессионалов в этой области стоит искать. Я участвую в группе по применению гибких методологий в госуправлении (ГосAgile) и готов рассказать подробности интересующимся.

Я не прекращаю работу по основной специализации — проектирование корпоративных и банковских систем в компании CUSTIS. Автоматизация открывает новые возможности развития для организаций, позволяет трансформировать бизнес и дать ему новые возможности. Поэтому создавая IT-системы мы открываем путь прогрессу и делаем мир лучше. За 30 лет работы в IT я накопил большой опыт, делюсь им в выступлениях и частных консультациях и открыт к общению на различных площадках и в соц.сетях. Я вхожу в программные комитеты конференций SECR и AnalystDays, а о конференциях, в которых выступал и участвовал публикую отчеты

Женат, двое взрослых детей, внуков пока нет. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ.

Я открыт к общению через социальные сети и по почте (лучше facebook) и обычно отвечаю на сообщение в течении 2-3 дней как минимум квитанцией о получении. Если она не пришла — значит сообщение перехватила спам-оборона и надо пробовать связаться иным образом.

Где буду

Последний пост блога 2018-09-22: Фокусы поддержки кроссфункциональной команды

В четверг на встрече HR-клуба «Как делать» по кросс-функциональным командам, были сформулированы проблемные фокуса внимания, которые надо удерживать при формировании кросс-функциональной команды, выполняющей сложный междисциплинарный проект. В принципе, они известны, но я хочу для себя записать их списком вместе с собственными размышлениями. И, думаю, этот список будет интересен не только мне. Отмечу, что по каждому фокусу есть свой набор инструментов и свои компетенции, которые должны быть в команде.

Предварить этот список я хочу вот каким замечанием. Есть холиварная тема, чем отличается команда от группы. И рассуждения о том, что для многих работ команды не нужны, достаточно группы. Не углубляясь в обсуждении, отмечу, что с моей точки зрения команда начинается там, где в совместной работе начинает проявляться синергетический эффект, команда становится больше, чем сумма участников, и способна синтезировать решения и совместно выполнять работу, которую никто из участников в отдельности не сделает, то есть появляются идеи, дела и решения, про которые нельзя сказать, кто конкретно их придумал или сделал. И многие проекты требуют именно такой команды.

Итак, фокусы поддержки.

  1. Эффективная коммуникация в группе. Умение слышать и слушать друг друга, во-время убирать эмоции. Здесь работают различные техники фасилитации, и, в целом, эти практики достаточно проработаны. Хотя распространенность их далеко не такая хорошая, как хотелось бы и эффективность совещаний во многих компаниях оставляет желать лучшего. При этом одного фасилитатора недостаточно, компетенция должна быть у большинства участников команды.
  2. Умение действовать командой, продвигаясь к общей цели. Здесь работают техники тимбилдинга и командообразования, проведения команды по пути от группы до команды. Здесь модели и практики тоже проработаны. Но в современных условиях есть несколько «но».
    • Большинство подходов рассчитаны на то, что команду притирают достаточно долго, месяц-другой, а потом она долго и эффективно работает. И раньше было все хорошо — были длинные проекты. А теперь все больше коротких проектах, на пару месяцев, а то и на пару недель. При этом команда над ними должна работать совместно, желательно как команда, а не группа, с синергетическим эффектом от совместного творческого решения задач.
    • А еще подходы рассчитаны на стабильную команду. А даже в проектах, которые идут год и более, состав команды часто меняется. Не кардинально, но кто-то приходит, кто-то уходит, это — рабочий процесс. В теории после этого команда вываливается в storming, а на практике это не допустимо, потому что время performing становится слишком маленьким.
    • В современных командах появляются люди с неполной занятостью, которые, тем не менее, несут необходимые компетенции. И чем дальше, тех их будет, по-видимому, больше — а во всех теориях этот фактор выступает как крайне нежелательный.
  3. Достаточный набор компетенций в группе. Это как раз вопрос формирования состава команды, и хотя в теории это вообще не является проблемой: выпиши нужные компетенции, и привлеки людей, практически тут далеко не так просто.
    • Если собирать людей для того, чтобы покрыть всю функциональную область сложного междисциплинарного проекта, быстро оказывается, что нужно очень много людей, нарушается предел эффективных коммуникаций в 7-9 человек. А еще надо ведь обеспечить кроссфункциональность команды, то есть работоспособность ее в ситуации, когда кто-то из участников заболел или ушел в отпуск. Теоретический выход — включайте только ключевых — не слишком реализуем на практике. Практический подход — сложно структурировать команду проекта, выделять ядро и ассоциированных участников, и по-разному организовывать взаимодействие, учитывать это в командообразовании.
    • Надо проверять не только функциональную полноту компетенций, но и использовать другие ролевые модели, например, модель Белбина, фиксируя провисающие или конфликтные фокусы, ослабляющие команду и предпринимая действия для их компенсации. При этом использовать критерии хорошей команды по Белбину в условиях дефицита квалифицированных сотрудников, скорее всего, не получится, надо именно предусматривать компенсирующие механизмы.
    • Парадоксальный вывод из дефицита квалифицированных сотрудников: большинство проектов будет выполняться некомпетентными командами. Компетентные люди могут быть — но они, с большой вероятностью, предпочтут знакомым задачам другие проекты, которые несут для них вызов. В лучшем случае они доступны частично, как эксперты. Такая вот ситуация. Отмечу, что Agile-подходы это могут обеспечить, потому что формировались именно в таких условиях: с появлением персоналок резко выросла потребность в разработчиках софта, а подготовка специалистов не увеличилась, и разработку пришлось вести некомпетентным командами. С этим Scrum справился. Это — на Западе, в России в это время куча народа из разваливающейся оборонки пришли в IT, и это компенсировало ситуацию
  4. Совместное мышление, обсуждение и выработка решений в условиях, когда различные участники команды имеют собственные онтологии и картины мира. Здесь речь идет не о коммуникативных навыках, а об умении быстро строить онтологии и участников коммуникации и «переводить с русского на русский». Фасилитации тут недостаточно, необходимо разбираться в содержании обсуждаемых вопросов, потмоу что каждый говорит из своего профессионального контекста. Типичный пример — коммуникация между менеджером, отстраивающим процессы исполнения заказов, и маркетингом, озабоченным удовлетворенностью клиентов и репутацией компании — они говорят на разных языках. Если к ним добавить еще юристов, бухгалтеров и службу безопасности, то можно представить себе спектр различий в моделях мира. Профессиональные компетенции в этой области есть у IT-аналитиков, и есть даже подход Domain Driven Design, в котором как обязательная часть предполагается построение единого языка проекта, с сопряжением его с другими понятийными системами и онтологиями. Есть также современные подходы у философов-рационалистов или в системном мышлении. И в команде должна присутствовать эта компетенция, желательно у нескольких участников.

На этом все. Сама встреча была интересная. Сообщество очень живое, профессиональное и хорошего уровня, а встречи проходят в неформальной обстановке, с активным общением участников и работе в группах. Меня позвали как эксперта, но формат предполагает не монологи экспертов, а активное включение их в работу групп. Для себя, помимо общего знакомства с сообществом и многих мыслей я вынес ссылку на книгу Six Simple Rules о работе со сложностью и модель хорошей команды, на краткое описание которой обещали позднее прислать ссылку с авторством :) Я попробовал ее быстро найти по запомненному контексту, не получилось, зато наткнулся на сайт, где командообразование достаточно систематично изложено и характеристики команды похожи на те, что рассказывали (но их сильно больше, и это снижает ценность).

Так что спасибо организаторам за приглашение.



Главное и новое

Мир третьей волны: Agile, Категория:Бирюзовые организации, Спиральная динамика

Ведение проектов

Я руководил проектами в IT, а внедряя софт — участвовал в перестройке бизнеса. Поэтому общие подходы в области командной работы и менеджмента лежат в сфере моих интересов, и я готов делиться теоретическими знаниями, а так же примерять их к конкретным кейсам Вашей организации.

IT: архитектура и анализ

Преимущественно корпоративных и банковских систем, хотя часть статей касаются общих подходов.

Мой блог — полное оглавление здесь


Весь блог…

Я буду рад любым комментариям и обсуждениям. Авторизация для этого через регистрацию на сайте или OpenID.

MaksWiki содержит 324 статей.