Блог:Максима Цепкова
SPMconf-2013
Третья конференция SPMconf проходила в Казани. Она явно высветила современный тренд в управлении — работу с людьми. Было много мастер-классов и докладов по психологии, работе с ценностями и другими аналогичным вопросам, и они вызывали очень большой интерес. Собственно, на первом слоте я недоумевал: почему в залах с докладами так мало народа. Пока не поднялся на второй этаж, где проходил мастер-класс Дмитрия Лазарева по принятию решений в командах, — участники были там (смотри фото справа). И это был не единственный доклад по психологии общения. Правда, остальные не включали практику, а это куда менее интересно.
Был интересный доклад Димы Безуглого с мощным троллингом Agile-подходов, у которых не получилось сделать гибкое ПО, - софт получается жесткий, под конкретный случай. Только, к сожалению, у других подходов часто вообще не получается сделать ПО: мир и требования к софту меняются быстрее, чем успевают провернуть тщательный процесс. По факту, то, что работает, — это симбиоз из подходов гибкой разработки и хорошо проработанных раньше подходов к проектированию, и сейчас их в больших проектах снова «извлекают из шкафов» и экспериментируют. В общем, закон отрицания отрицания в действии. А еще метод Fail Fast: прототипируйте, проверяя критичные ограничения. Как Google Glass: до него куча дорогостоящих фейлов по аналогичным устройствам была потому, что получались недопустимо тяжелые вещи. И они начали с того, что определили предельный вес устройства, что можно сделать почти бесплатными экспериментами, а уж потом придумывали начинку в этом жестком ограничении. И в целом доклад — фейерверк троллинга («Видели мы ваш Захман-фреймворк, утопитесь сами»), его стоит послушать.
Еще был любопытный доклад Асхата Уразбаева про культуру, с Schneider Culture Model. И о том, что основная проблема изменений в большой компании — это масса менеджеров среднего звена. Они пережили CMMI, пережили Agile, и все остальное — переживут, они это умеют. И впрочем, на мой взгляд, тут было много поверхностного, включая методы работы.
Неожиданно содержательный получился круглый стол «Образование и ИТ», о котором я написал отдельный отзыв. Особенно в контексте открытия в Казани университета, который будет давать ИТ-программу Карнеги-Меллона и в котором будет преподавать западный штат профессоров. Для него строится отдельный город-спутник — Иннополис. Правда стоимость обучения зашкаливает. Ректор Саша Тормасов переехал в Казань из Москвы и сейчас поднимает это дело.
Я сам тоже неожиданно выступил с докладом Agile в контексте большого менеджмента – тренды развития (SPMconf-2013) (доклад на сайте конференции). Один из докладчиков неожиданно отказался, и меня позвали заменить. Но была интересная тема, по которой хотелось поделиться мыслями, и как раз уместная на этой конференции. Сопоставить Agile, как способ менеджмента в ИТ, и «большой менеджмент», способ управления деятельностью в других отраслях. У меня есть мнение, что Agile представляет собой продвинутый способ менеджмента, и в других отраслях к этому постепенно приходят. Но при этом первоначальный импульс Agile-методов, который дал достаточно интенсивное развитие, сейчас исчерпан, поэтому лидеры строят сложные продвинутые конструкции, противники говорят, что давно ожидали, когда оно выдохнется, а любители серебряных пуль жалуются, что их опять обманули. Об этом был доклад и обсуждение потом.
Так что в целом конференция прошла ожидаемо хорошо.
UPD Отзыв на круглый стол об образовании в IT, опубликованный мной во время конференции на сайте SoftwarePeople исчез вместе с сайтом - восстанавливаю здесь.
Неожиданно получился содержательным. Многие из экспертов - едины в двух или даже в трех лицах: руководители проектов, тренеры ИТ, преподаватели.
Дальше тезисы без авторства в некотором логическом порядке.
- Бизнес к образованию относится как к данности: какое есть, такое есть. Знает качество вузов. Где-то помогает, основывает кафедры, сотрудничает с преподавателями. Где-то закрывает проблемы сам.
- ВУЗам нормальное образование для бизнеса по большому счету не нужно. У них - другие KPI. И там где идет - оно, скорее, на личном факторе, вопреки.
- Центры образования ряда крупных ИТ-компаний готовят кадры не только внутрь, но и для отрасли, вопросы конкуренции тут не играют.
- Некоторые ИТ-компании готовы отказаться от своих корпоративных университетов, если ВУЗы начнут выдавать адекватных специалистов. mail.ru, Itransition. Сейчас готовы, потому что образование - непрофильная деятельность, отвлекает. Но они вынуждены ее развивать и через несколько лет ВУЗы им просто станут не нужны, они будут уверены, что сделают все лучше.
- Основная претензия к ВУЗам - даже не плохое образование. Нынешние ВУЗы калечат людей: если на первом курсе глаза горели, то к пятому они потухают. Способные просто уходят работать и для них ВУЗ становится обузой - для корочки и армии.
- Программы в ВУЗах устарели безнадежно. Архитектура и прочие программы ИТ-шных инженеров написаны в 70-х(!) На Западе лучше не сильно: программа Карнеги-Мелон, которую тиражируют по миру и сейчас в Казани, Иннополисе - это конец 90-х :(
- В теории ВУЗ должен давать базовое образование, это все признают. Это нужно бизнесу и это как раз то, что он не дает в своих центрах. Только вот для него достаточно двух семестров, 3-4 года не нужно. Ну и по факту дают его плохо.
- На Западе ВУЗы передовые не за счет программы. Просто рядом с каждым ведущим Университетом есть сильный Research-центр. При чем туда уходят люди, проработав в индустрии лет 15, чтобы реализовать силами студентов и аспирантов свои идеи. Часть из которых стреляет - Oracle, Linux, VMWare - зарождалось так. Карнеги-Мелон - не исключение, более того, у него - один из самых сильных центров.
- А у нас ИТ-шник из бизнеса не может уходить в ВУЗы. Задают вопросы про степень и прочее. Предлагали - а давай оформим другого, а ты будешь работать. И прочие дурацкие вещи. В результате ИТ-шники уходят в тренера - Дорофеев, Куприянов...
- И мы так и не выяснили, кому нужно, чтобы ВУЗ поставлял бизнесу нормальные кадры. Бизнес - приспособился. Над ВУЗами - не каплет. Государство как заинтересованную сторону никто не рассматривает, во всяком случае его методы вызывают общий скепсис.
- На глобальном уровне может сыграть конкуренция с Китаем, когда он мощно выйдет на глобальный рынок. Индусов не боятся.
- А еще все позитивные примеры - из советского времени. А это - "прошлая война". Надеяться будущую войну выиграть старыми методами - глупо, мир - изменился.
ADD-2013
В Минске прошла четвертая конференция Application Developers Days. Конференция ориентирована на разработчиков, но с этим произошла вот какая штука. Как известно, разработчики, помимо собственно разработки, занимаются всякими сопутствующими вещами: управлением проектами, работой с требованиями, налаживанием командного взаимодействия. А еще ищут работу или, наоборот, собеседуют сотрудников. И во всем этом тоже хотят прокачиваться. А те, кто еще не занимается, все равно интересуются, потому что рост предполагает расширение сопутствующих занятий и хорошо бы понимать, с чем придется иметь дело. И конференция давала возможность такой прокачки, причем на адекватном для разработчиков уровне. А вот с собственно технической составляющей, которая является основой работы разработчика, было хуже (хотя я не хочу сказать, что их не было вообще). Наверное, это закономерно, потому что эта техническая составляющая значительно более разнообразна и для тех, кто занимается профессионально, уместно общение в более специализированных сообществах. А людей, способных рассказать общезначимые вещи на доступном широкому кругу участников уровне, — очень мало.
Из интересных для меня докладов хочу отметить рассказ Александра Мартинкевича из Парка высоких технологий» про ситуацию в ИТ и проблемы образования. ИТ в Белоруссии — экспортно-ориентированная и дает треть валютной выручки страны (если мерить по сальдо), и поэтому она поддерживается государством через Парк высоких технологий, при этом государство понимает, что отрасль — сложная. И сейчас развитие отрасли уперлось в нехватку кадров, как сказал Александр, «сверло уперлось в бетон». Говорит, у них есть 5 лет на изменение ситуации, и они взялись за выработку профессиональных стандартов, чтобы на их основе поставить образовательные курсы в университетах или непосредственно в компаниях. Используют и зарубежный опыт (мы потом с Александром говорили, он рассказал, что смотрели британскую SFIA, гонконгскую систему, европейскую, польскую) и опыт собственных фирм, формируя консолидированное мнение. И поскольку от всей этой деятельности ожидается внятный практический результат, она востребована, то может получиться реально ценная и практичная вещь. Интересно.
Еще был любопытный доклад Ольги Юрковской про то, как договориться в команде, — о различных коммуникациях. Хотя, с моей точки зрения, это достаточно поверхностный уровень. Все-таки коммуникации в ИТ нацелены не на поиск компромисса при достаточно ясных позициях сторон, а на создание, придумывание ранее неизвестного решения. То есть это не классические переговоры, а некоторое совместное творчество, а этого в докладе не было. Но, в любом случае, коммуникации важны, а техники контроля эмоциональной составляющей разговора и управления ей, когда из-за эмоций теряется конструктив, в том числе через выдачу дозированных эмоций на заказ — это интересно. Запомнил новое имя автора методики — Марк Пальчик. Думаю теперь, может научиться :)
Из технических запомнился доклад Романа Бугаева про создание правильного и логичного API — о чем стоит думать. Автор занимается интеграцией со многими сторонними системами, и доклад — можно сказать, крик души о наболевшем. Почему у людей получаются столь уродливые вещи? Вроде, они по природе — думающие...
Евгений Шишкин из Wargaming сделал несколько сумбурный доклад про масштабирование различных баз данных, которое, естественно, зависит от характера приложения. Основной вывод был несколько парадоксальный: сами по себе NoSQL базы данных масштабирования не дают, а если вы знаете, как масштабировать ваше приложение с помощью NoSQL, то вы сможете масштабировать и с помощью SQL.
Еще был интересный доклад Леонида Выговского про сложное управление в Git, который так и назывался «Черная и белая магия Git», где он показал ряд сложных трюков, хотя успел не все.
На этом я обзор закончу, об остальных докладах конференции писать не буду.
HappyDev-2013
На конференцию HappyDev-2013 меня позвали выступить с докладом по DDD, и я совершенно не жалею, что согласился. Хотя это было и тяжело — в пятницу SPMconf в Казани, а в субботу-воскресенье — HappyDev в Омске. И прямой самолет, которым я планировал лететь и на который купил билеты, - отменили, пришлось лететь через Москву. А не жалею, потому что в Омске я впервые плотно почувствовал атмосферу изменений, которые сейчас происходят в IT и не только там. Это интенсивное развитие самоорганизующихся сообществ, которые объединяются в рамках городов. Собственно, сообщества IT-шников для общения возникли довольно давно и успешно существуют вокруг интернет-площадок. Как знакомые мне примеры — сообщества тестировщиков, возникшие вокруг форума software-testing.ru, или аналитиков — вокруг форума uml2.ru, но я знаю, что есть и другие, в том числе, связанные с разными интересными языками программирования — Ruby, Haskell. Сообщества не ограничивались интернет-общением, рядом с ними возникли и проводятся конференции, а сообщество тестировщиков переросло в городские клубы.
А на HappyDev я узнал про новый импульс в этом движении, когда отдельные сообщества в городе координируются, проводят регулярные встречи и вообще совместно действуют, и это не в одном городе, а во многих. В Омске уже год проходят IT-субботники, при этом летом была конкуренция за выходные. А еще Омские компании, которые раньше сотрудничали с университетом и проводили лекции и курсы, индивидуально договорились в этом году о совместной деятельности. В Питере сообщества образовали метасообщество Piter United, и организуются регулярные мероприятия. При этом «-ся» здесь очень уместно — мероприятия организуются сами: на Github есть база данных организаций, готовых бесплатно предоставить помещения для встреч с контактными лицами, а дальше любой инициативный человек может кинуть клич через гугл-группы: «Есть тема для встречи, давайте?», и если появится отклик, — договориться о месте встречи. И это реально работает. Еще были примеры Пензы, где IT-сообщества работают при поддержке администрации губернатора, и Ульяновска. И для меня это свидетельство нового шага вперед к самоорганизующимся конструкциям совместной деятельности. Которые превращаются из просто дополнительного клуба по интересам в реальную действующую и организующую силу.
Кстати, сам HappyDev тоже можно рассматривать как часть этого процесса. Потому что организаторы поставили перед собой задачу: собрать в Омске сильных IT-шников, которые своими докладами и общением помогли бы местному IT-сообществу развиться, дали бы ему дополнительный импульс. Потому что, если судить по докладам, то сейчас речь идет преимущественно о не слишком больших web-проектах, а есть желание делать и более крупные. Для усиления воздействия они в этом году попробовали новый формат — выходные за городом на турбазе Стрельникова — чтобы общение не ограничивалось докладами. И это удалось. Интересно, что сам HappyDev тоже развивался в процессе организации. Возник управленческий трек, которого изначально не было в замысле, появился трек по дизайну и юзабилити интерфейсов. Участники не только слушали доклады, но и активно обсуждали проблемы на баркэмпах. И, я думаю, опыт конференции поможет участникам в развитии своей деятельности, в переходе к более крупным и сложным проектам.
Если говорить о докладах, то их уровень вполне сравним с другими конференциями. Был замечательный доклад Кирилла Мокевнина про Ментальное программирование — о стилях разработки кода, обеспечивающих его хорошую понимаемость. Правда, я по своему опыту знаю, что там есть и другая крайность, когда вместо объекта с сотнями методов возникают сотни объектов с парой методов, да еще обернутые интерфейсами или сервисами с получением реализации через локаторы, от чего легче не становится. И когда мы обсуждали, Кирилл сказал, что да, такой перекос возникает, и потом надо учиться искать баланс, но это, по его опыту, уже следующая ступень совершенства (и в этом я согласен).
Я рассказывал про применение Domain Driven Design в части проектирования и работы с требованиями, где он дает существенный выигрыш на больших проектах, особенно если предстоит многолетнее развитие системы. Николая Рыжиков говорил про Design архитектуры, как с применением DDD, так и в более легких вариантах, для получения ясной архитектуры. Потому что архитектура сама по себе не цель, а средство обеспечить хорошую разработку и дальнейшее развитие системы, и способы достижения этого могут быть разными. Еще были разнообразные технические доклады про разные этапы и аспекты разработки системы: непрерывную интеграцию, методы работы с распределенными системами контроля версий, Jscript, NoSQL и многое другое.
На управленческом треке был хороший доклад Алексея Пименова про мотивацию 3.0, который я, правда, слышал на AgileKitchen. В перерыве перед докладом Алексей сделал экспресс-обзор еще нескольких своих выступлений. Я рассказывал варианты разделения ролей в проекте, которое тоже надо проектировать для конкретных проектов с учетом специфики, потому что единственно правильного решения не существует, и про визуальный образ для этого на основе V-диаграммы. И доклад Дмитрия Лобасева про Agile-разработку в быстро меняющихся требованиях с макетированием и апробацией на заказчике. Потому что в реальной жизни заказчик далеко не всегда знает, что он хочет получить на выходе и тщательное проектирование конечной системы невозможно. После доклада Димы было обсуждение разных подходов работы с требованиями, и фотка этого обсуждения от Пименова с провокационной подписью «отбиваются #эджайлнеработает» вызвала длинный тред комментов в FB.
А еще был трек про обучение ИТ в разных формах — в вузах, в школах. Где люди делились своим опытом и разговаривали о решении конкретных проблем в реальных условиях, а не мечтали о том, что кто-то что-то должен исправить в образовании. Вообще конференция была очень конкретная, нацеленная на практику, а не высокую теорию.
И было много баркэмпов, на которых я как-то не был, хотя, наверное, зря, надо было послушать и поучаствовать. А вечером первого дня была вечеринка и общение по самым разным вопросам. Вообще IT-шные тусовки отличаются разговорами на профессиональные, а не посторонние темы — потому что именно это и составляет круг интересов большинства IT-шников.
В общем, конференция удалась, и я рад, что принял в ней участие.
KM Russia-2013
На KM Russia этой осенью я был уже четвертый раз, с самой первой конференции в 2010 году. И каждый год она меня удивляет, потому что характер конференции меняется. На первой собрали всех, кто имеет отношение к управлению знаниями, включая научные направления: надо было сорганизоваться. Вторая была более камерной, потому что многое было рассказано на первой, а за год изменения не столь велики. Зато происходило вписывание в мировое сообщество. В прошлом году маятник резко качнулся: на конференции было много региональных блогеров, и происходило их обучение эффективным методикам работы, нацеленной на результат, — прямо во время конференции. В этом году маятник вернулся назад: было больше рассказов об управлении знаниями в разных организациях, при этом не только в крупных, таких, как РЖД, но и в среднем бизнесе, и это очень интересно. Но блогеры тоже были. И еще было обучение практикам совместной работы со знаниями в залоге проработки конкретных проектов и обмена опытом, непосредственно в ходе конференции и для всех участников. Причем в довольно жестком push-режиме, впрочем, воспринимаемом участниками как возможность, а не как обязанность.
А еще были доклады и прямые включения зарубежных экспертов. Которые показывают, что и мероприятие, и само управление знаниями в России — вполне на мировом уровне. Что, кстати, подтверждается участием и выступлениями наших экспертов на KM Asia в Сингапуре и встречах в Лондоне. Кстати, говорят, что в Европе аналогичного мероприятия нет. К сожалению, уровень knowledge management не столь высок, как хотелось бы и мечталось, но это я воспринимаю как возможность для деятельности, а не повод для сетований. Так что мероприятие — интересное, а его уровень отражает состояние управления знаниями в целом.
Лично для меня оно дало возможность очередной раз сверить свои представления и идеи с мировым уровнем. В целом то, что я услышал, вписалось в мою картину мира, дополнило и расширило ее. Позволило обсудить изменения с людьми, знакомыми по прошлым конференциям. А еще позволило узнать, обменяться опытом, дало контакты с людьми, которые работают с управлением знаниями в разных областях. И, думаю, взаимодействие по контактам будет развиваться. Потому что будущее — за совместной деятельностью: не только людей, но и организаций в совместном создании нового. И принципы этого существенно отличаются от концепции единого организованного движения и напоминают мозаику с многочисленными нитями различных связей. Что, кстати, соответствует изменениям, происходящим сейчас в моей отрасли, — в ИТ.
А теперь — об интересных для меня докладах. Только надо учитывать, что из-за разных обстоятельств я пропустил вторую половину второго дня, так что обзор заведомо не полон. Ну и это мое личное восприятие, я мог не услышать или счесть очевидными какие-то вещи, которые другим покажутся важными и нетривиальными, и потому не отмечу их в обзоре.
2013-11-25: Спиральная динамика - проблемы знания
Я писал, что схема спиральной динамики — это знание, которое вызывает проблемы. Не потому, что оно теоретическое и не работает, — с такими схемами как раз проблем нет: познакомился и выкинул. А вот схема спиральной динамики очень хорошо вписалась в мою картину мира, дополнила и расширила, а местами и замкнула ее. Настолько, что исходя из нее, начинаешь мыслить и делать выводы. И тут-то возникают проблемы.
Прежде всего — проблемы в коммуникации.
- Потому что схема сложная, у других ее нет, а значит надо передавать весь контекст, да еще в связи с другими схемами. И в рамках частного вопроса это явно не получится.
- А еще схема не общепринятая, не авторитетная и совсем не бесспорная, поэтому просто ссылаться на нее — невозможно, надо переформулировать ее общую логику в контексте ситуации и аргументировать на этом уровне, а это — непростая задача.
- А еще в данном случае у меня своя интерпретация. Она отличается от представленной схемы, при этом я понимаю причины различий и считаю, что мой вариант лучше описывает действительность. Однако, в коммуникации это позиция «я самый умный», и она — слабая в убеждении.
- А еще я не профессионал в этой области, это знаю и понимаю уровень зыбкости отдельных фрагментов схемы — а в работе с конкретными кейсами важны именно фрагменты, а не схема в целом. И понимаю опасность укладывания ситуации в схему, когда упускаешь важные аспекты конкретной ситуации и предпринимаешь неверные шаги из-за неправильной интерпретации в рамках схемы.
Тем не менее, поскольку я уже понял схему, поумнел, и отказываться, выдирать ее из своей картины мира обратно не могу и не хочу — надо с ней жить и действовать.
И на этом этапе самое правильное — сформулировать, записать, что именно ты понял, зафиксировать текущее понимание. Что я и делаю. При этом я не буду повторять свое восприятие спиральной динамики как таковое, за этим отправляю в свой предыдущий пост Blog:Максима Цепкова/2013-10-18: Спиральная динамика. С тех пор мое понимание продвинулось, но это требует отдельного изложения, так что этот пост — тоже не последний.
Итак, каким образом схема спиральной динамики вписалась в мою картину мира. Я тут буду говорить о аспектах, связанных с бизнесом, производственной деятельностью общества в широком смысле. Потому что есть еще аспекты политики, эволюции семьи, экология и другие, и в этом направлении я плотно не думал, ибо в моменте — для меня не актуально.
Надо отметить, что для меня эта схема — не только про людей, но и про организации, — как и у Адизеса его витамины — он их тоже применяет и к людям, и к подразделениям, и к организации в целом. Только у Адизеса отдельно — типы, и отдельно — жизненный цикл, а здесь это совмещено в одном. Собственно, это соответствует тому, что сказано у авторов концепции, хотя многие рассматривают уровни спиральной динамики с точки зрения ценностей индивидуума.
Начну я с Питера Друкера, который, как известно, заложил основы современного менеджмента как науки. У Друкера есть «Энциклопедия менеджмента» (в английском издании — The Essential Druker), которая представляет собой объединение его работ с учетом сохранившейся актуальности, собранная уже в начале 21 века (2001) как раз для передачи его идей при обучении, и я опираюсь на нее. В своих работах, помимо непосредственных вопросов менеджмента, Друкер много говорит про будущее, про общество, управляемое знаниями. Он говорит это начиная с конца 60-х, а сейчас это общество интенсивно наступает, и многие его аспекты, сформулированные, предсказанные Питером, — осуществляются: это видно в окружающей жизни. И весь этот процесс очень хорошо ложится на схему спиральной динамики. Традиционный менеджмент, особенно в крупных корпорациях, — это синий уровень. При этом «топы» работают на оранжевом уровне. И Друкер, прежде всего, говорит о том, что и многие другие, во всяком случае менеджеры среднего звена и работники интеллектуального труда точно, должны в будущем перейти на оранжевый уровень. Но дальше, когда он начинает говорить о мотивации этих людей и развитии системы в будущем, то он выходит на желтый уровень: самореализация как основной фактор, при котором старые способы привлечения сотрудников перестанут работать. И на бирюзовый уровень, который у Друкера еще смутен, но необходим — ибо большие проекты и системы не делаются индивидуально, им нужны адекватные организующие конструкции.
С тех пор прошло много времени, и верхние уровни уже вполне определились. Это хорошо видно в ИТ, где я работаю, и частично можно проследить в других динамичных отраслях. В ИТ в начале 2000-х возник Agile, первоначально — как сформированный протест против процедур синего уровня, который носил отчетливо-зеленый цвет: все вместе будем делать дело. Но сам по себе зеленый уровень не слишком продуктивен, у него плохо с продуктивностью и, как следствие, — с экономикой. Поэтому достаточно быстро был осуществлен переход на желтый уровень — самореализацию совместно действующих индивидов, и далее к бирюзовому, на котором эти индивиды организуются в продуктивную сеть. Наблюдая и участвуя в развитии Agile в России, которая в ИТ в целом не отстает от остального мира, я это вижу достаточно отчетливо.
Это, естественно, не означает, что все ИТ-компании вышли на этот уровень. Они — разные, тем более, если брать небольшие компании. Более того, практики Agile можно успешно применять на большинстве уровней. Не все из них привьются, что мы и видим на примере различных компаний и, отчасти судя по этому, и по содержанию, вкладываемому в практики, можно говорить об уровне организации по шкале спиральной динамики.
А вот передний край развития: «желтых» компаний — достаточно много, и это тот дух, который отчетливо виден во многих стартапах. А большие организации пытаются перейти от синего к бирюзовому уровню. Дело в том, что большая производящая организация может существовать только на этих двух уровнях. И сложившихся, зрелых «бирюзовых» в мире пока нет, хотя на этом пути — многие, и идут эксперименты, создание нового. Многие из экспериментов по реорганизации — это попытка сделать «зеленую» компанию, а этот уровень контрпродуктивен. И даже если экономика деятельности обеспечена тем или иным образом, соразмерных результатов не наблюдается. Но я готов обсудить конкретные примеры.
Несмотря на тезисы Друкера о будущем, первые из которых он писал еще в 70-х, и даже несмотря на реализацию этого в отдельных местах, современный менеджмент по-прежнему находится между синим и оранжевым уровнями. Там же работает большинство бизнес-консультантов, и там находятся проблемы большинства организаций (еще красный может добавляться). Правда, ограничения синей модели уже вполне понимают, и, как следствие, пытаются преодолеть.
Если посмотреть с этой точки зрения на систему Адизеса, то давая рекомендации по построению зрелой организации для того, чтобы избежать «ловушки основателя» или оздоравливая большие бюрократические организации через восстановление предпринимательских элементов, он работает с балансом синего и оранжевого. Однако одновременно, выходя на ценностный уровень и на коллективную работу, он вносит элементы следующего яруса — желтого и бирюзового. Насколько они будут восприняты организацией, и насколько они артикулируются, — вопрос отдельный. Потому что они сейчас не находятся в тренде, не осознаются как ценности. Однако, через практики коллективной работы, которые заложены не в книгах, а в практическом применении системы Адизеса, которую его институт ставит в организациях, они определенно присутствуют.
С моей точки зрения, желтый и бирюзовый уровни определенно присутствуют, просто под другим видом, во многих современных и не очень современных, но ставших актуальными сейчас теориях и мемах. Толерантность и сопутствующие явления — зеленый уровень, он контрпродуктивен. А вот поколение Y — это, скорее, желтый, чем оранжевый уровень, а поколение Z — бирюзовый. Хотя сама схема поколений сильно условная, плюс построена на американском материале. «Мотивация 3.0», «работа в потоке», о которой говорит Михай Чиксентмихайи, — тоже с этих уровней. И поэтому на современном этапе актуальным является не баланс между оранжевым и синим, а организация прокола, перехода на желтый и бирюзовый уровень. Как индивидуально, так и для организации в целом. И я тут не согласен с теорией, говорящей исключительно о последовательном развитии. Да, на переднем крае иначе невозможно, потому что ты строишь новое. Однако, если оно уже где-то построено, то имея знания, воспринимая ценности, можно достаточно быстро уйти сразу на высокие уровни. В ИТ, на мой взгляд, вполне можно наблюдать переход с красного уровня, на котором человек полагается исключительно на себя, свои выдающиеся способности, сразу на желтый. И организации тоже так могут, наверное. А с синего можно пробовать перейти не на оранжевый, а внеся достаточно элементов желтого — на бирюзовый. И организация этого перехода — основной вопрос современных персональных тренингов развития и современного менеджмента.
И это наблюдается в реальной жизни. Не только в виде востребованности темы саморазвития, и многочисленных тренингов, и других мероприятий, призванных помочь человеку не только найти свое дело, но и — внимание! — вписать его в реальную экономику. Но и в серьезном бизнес-построении корпораций. Про Адизеса я уже говорил. А некоторое время назад я был на бизнес-завтраке, где основным спикером был Александр Фридман. У него основная тема — построение профессионального управления, это синий уровень с оранжевыми «топами». Вопросы самореализации тоже присутствуют, но неявно, в фоне. А потом выступал Антон Солопов, он в своих компаниях явно реализует желтый уровень. И это кажется новым, необычным и пугающим: как так, работать в бизнесе в условиях самореализации. Но — компании существуют и работают. Да, это все — моя интерпретация, они в таких терминах не говорили. Таким образом, конструкция интенсивно движется в реальную жизнь, там меняется в соответствии со схемой.
И, возвращаясь к началу поста. Я понимаю, что это может быть ложным знанием, ложной структурой и может давать искаженную картину. Но просто отказываться от структуризации на этом основании — неправильно, потому что любая структура лучше ее отсутствия, работы с миром из позиции разнообразных явлений, понимаемых лишь индивидуально. И я пробую держать это в фокусе, сопоставлять картину с реальным миром, проверять на применимость в разных ситуациях. Пока картина складывается. Так что тема будет продолжена.
2013-11-10: SQAdays - потрясающая энергетика
Закончилась SQAdays-14 во Львове. Все-таки, эта серия конференций обладает потрясающей энергетикой. Наверное потому, что у тестировщиков наиболее ярко проявляется идея предназначения «Мы делаем мир лучше, повышая качество программных продуктов и, как следствие, радость людей от жизни в этом мире». При этом они наименее интровертны среди ИТ-шников.
Конференция собрала много участников и проходила на стадионе, так что можно с полным основанием говорить, что конференция тестировщиков собирает стадионы :) И, кстати, Львов — прекрасный город, который я хотел посмотреть и потому приехал сильно рано. Впечатления и фотки — у меня в ЖЖ.
Было много докладов от новичков и для новичков, особенно в первый день: те, кто сделали успешные шаги делятся с другими тем, что и как они делают. Потому что они помнят о своем трудном пути, и хотят поделиться с другими, чтобы им было легче делать свое. В таких докладах нет идеи «сделай как я и будет успех», но и нет еще достаточно опыта чтобы представлять альтернативы и уместность тех или иных практик в условиях конкретных проектах и подать материал на таком уровне.
Да, все или многое из этого можно было получить из систематического обучения. Но его на пост-советском пространстве нет, причины известны. И, я думаю, уже не будет, но по другим причинам. Дело в том, что образование перестраивается, и традиционные системы должны сильно измениться. Где-то это получится эволюционно, но, думаю, что большинство старых структур просто отомрет, будучи вытеснено новыми. Это, конечно, не дело пары лет, но думаю в пределах десятилетия.
Так что во многом это конференция не профессионалов, а дилетантов. Они не следуют каким-либо стандартным методикам, они пробуют различное и конструируют свое. И у них нет систематического образования — они делают свою работу на ходу, в потоке. Лучше ли этот способ чем сначала получить систематичное образование, а потом его применять — вопрос открытый. Но он закономерен, и все развивающиеся отрасли через него проходили. А IT — развивающаяся, поэтому в ней так будет. И не только в ней, это тренд современного мира, работа как часть самореализации жизни, а не как скучный способ зарабатывания денег. Впрочем, об этом в другой раз.
Но если говорить об общих пожеланиях ко многим докладчикам, то оно такое. Рассказывая о своих успешных практиках и достижениях попробуйте представить, кому, в каких проектах и ситуациях они могли бы пригодится другим, а для каких ситуаций лучше поискать другие пути. В конце концов, Вы сами искали варианты, пробовали различные методы.
Во второй день конференции было больше докладов от профессионалов. И для тех, кто ездит на конференцию постоянно, он скрасил сдержанные оценки первого дня. Но я слышал и обратные отзывы — о том, что доклады первого дня были более интересными, практическими, а не теоретическими. И это понятно — участникам разного уровня, из разных проектов нужны разные доклады.
Сам я, кстати, во второй день совершенно неожиданно тоже оказался в роли докладчика — один из докладчиков почему-то не явился на собственный доклад и организаторы были вынуждены искать замену с колес. Поэтому я рассказывал свой прошлогодний доклад на SPMconf про модель командных ролей Белбина. По отзывам — получилось очень удачно и уместно, несмотря на то, что у меня не было времени даже просмотреть слайды.
Если говорить о темах конференции, то я бы выделил интеграцию, различного рода ETL-процедуры и сервисы, работающие без интерфейса. На эту тему было довольно много докладов, как от подходах к тестированию, так и об инструментах, и это — относительно новая тема. Продолжалась тема с методиками тестирования на представительных наборах данных, техники pair-wise, которые позволяют избежать комбинаторного взрыва вариантов. И в этом сегменте есть инструменты, которые позволяют автоматически формировать представительный набор вариантов на основе распределений и описания множества значений различных параметров.
Кстати, если говорить об инструментах, то большинство современных тестировщиков не используют какую-нибудь одну среду, а пользуются множеством подходящих инструментов различного назначения. Которые как-то несложно совмещаются и интегрируются друг с другом. И у профессионалов при этом получается довольно цельный фреймворк, который они, к тому же, легко модифицируют под разные цели проектов, попутно дописывая свое по необходимости. Подробнее можно посмотреть доклад Никиты Гавриша — как они собирали фреймворк. Если говорить об аналогах, то это похоже на Linux и Java-мир, в отличие от подхода комплексных фреймворков одного вендора, который больше напоминает мир Windows и .Net с его Visual Studio. И это логично, потому что мир проектов сейчас очень разнообразен, технологии развиваются быстро, и производители фреймворков за этим не успевают, в то время как написать отдельные утилиты можно гораздо быстрее, это делают компании, занимающиеся тестированием, и, что интересно, многие из них выкладывают в свободный доступ, или распространяют за небольшие деньги — в отличие от тяжелых вендорских фреймворков. Обзоры инструментов и рассказ про конкретные были во многих докладах, и я бы хотел тут отметить прекрасный доклад Мясникова и Косарева на эту тему, который они сделали за один день как замену другого доклада. Этот тренд — компоновка цельных фреймворков из различных утилит — я уже отмечал на прошлых конференциях.
Еще стоит отметить, что сама по себе автоматизация тестирования уже довольно давно не воспринимается как фишка. Большинство подходит к этому разумно, выстраивая баланс между автоматическим и ручным тестированием, между разными видами тестов, исходя из целей проекта. И рассказывают о том, что у них получилось. Если б еще рассказывали почему так и какие варианты были, было б совсем замечатльно, но так делают не все.
Было несколько докладов про совмещение ролей аналитика и тестировщика. Интересно, что несколько лет назад я делал доклад на SQAdays об этом. Тогда перед конференцией статью с тезисами доклада опубликовали на форуме software-testing и в дискуссии оппоненты говорили, что совмещение не получится, потому что тестировщик нацелен на разрушение, а аналитик — на созидание. Что мне это было странно, потому как у нас в компании такое совмещение есть с самого начала. С тех пор веяния изменились, и теперь совмещение никого не удивляет, а воспринимается конструктивно и правильно, доклад вызвал интерес у участников.
А еще на конференции было много докладов в теме «другое». И это правильно — потому что время узких специализаций прошло, и надо выходить из этих границ. Интересно, что в Европе специализация тестировщика постепенно исчезает, это звучало в обсуждениях. Хотя я думаю, значительный вклад в это даент аутсорс тестирования в Индию и к нам, в Россию, Украину и Белоруссию. И будет ли эта ниша конкурентроспосбоной, или мы ее перерастем, оказывая комплексные, а не специализированные услуги — время покажет. В любом слуаче, надо смотреть вокруг, понимать свое место в нем. Поэтому доклады про личностный рост и коммуникации — уместны и востребованны участниками.
И перед обзором хочу отметить те доклады, которые мне особенно понравились.
- Андрей Ребров. Тестирование в Agile для больших команд: путь трансформации. Рассказ был про конкретный кейс в одной из компаний. И успешный: повысили скорость поставки фич в 5 раз, поставки стали регулярными 2-3 раза в неделю, ушли от работы по выходным и по ночам. Повысилась удовлетворенность работой.
- Владимир Кривенко. Особенности тестирования NoSQL приложений. В блиц-доклад Владимир уложил все: от ликбеза до достаточно сложных особенностей NoSQL-тестирования. Круто.
- Никита Гавриш. Внедрение автоматизации на Selenium в highload-проект. Речь шла о разных кейсах команд-проектов внедрения техники автотестов, постановки процесса. С чем надо быть готовым столкнуться.
- Дарья Костюк. Альпинизм в тестировании или восхождение на вершину карьеры. Доклад про планирование личностного роста и следование плану. Начало было совсем замечательное: вдохновение профессии, про самореализацию в том, чтобы сделать мир лучше.
- Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лида. Очень хороший обзор различных вспомогательных инструментов, нужных тестировщику. Которые позволяют эффективно решать очень многие задачи.
Кстати, если что-то понравилось мне — это не значит, что оно понравится вам. А еще надо учитывать, что параллельно шло несколько треков и многие доклады я слушал частично — так что запросто мог пропустить что-то ценное. И да, были доклады, на которых меня не было, поэтому я ничего не могу написать.
А теперь — обзор докладов по темам, внутри доклады упорядочены по месту в программе. Впечатления от английского дня в предыдущем посте.
2013-11-07: SQAdays - английский день
Сегодня прошло новое мероприятие в формате SQAdays-14 во Львове — английский день. Два трека докладов англоговорящих спикеров из разных стран Европы и США, многие из которых приехали с конференции EuroSTAR. И это важно, потому что дает возможность соотнести себя и свою компанию с мировым уровнем, понять свое место в глобальном сообществе. Отметим, что конференция шла на английском языке и без перевода, что было фишкой и служило тем же целям. И даже Влад Орликов открывал этот день по-английски.
Если говорить об уровне докладов, то он примерно соответствует тому, что я слышал на российском варианте SQAdays, и в этом смысле, соотнося себя с мировым уровнем, можно быть вполне спокойным. Более того, доклад от некоторых грандов — повышает самооценку. Потому что куча разработчиков почувствуют себя удовлетворенно — у них точно не хуже, а даже лучше, чем в Wikimedia. А у кого этого нет, тоже могут удовлетворенно подумать «ну, это ж вон кто, а мы — маленькие».
Тут надо отдельно сказать про позицию конференции. Она ориентирована не столько на лидеров отрасли, сколько на основную массу компаний. Потому что крупные компании, такие как Яндекс, Касперский или Luxoft, например, задают высокую планку и продукта, и сотрудников, и стоимости услуг, если говорить о сегменте заказной разработки того же уровня. И они не могут удовлетворить не то что все, а даже большинство потребностей рынка. И есть место для развивающихся, начинающих компаний, в которых сотрудники не столь квалифицированные, но своя ниша на рынке у них есть. Если говорить о мировом разделении труда, то эту нишу преимущественно занимают индийские разработчики, но для компаний стран СНГ и Восточной Европы место тоже есть. И для сотрудников этого сегмента тоже необходима площадка профессионального общения, роста.
Но это же сказывается и на докладах. Многое из того, о чем говорилось в них, для больших компаний и крупных проектов — вещи очевидные и, более того, в столь простом виде не применимые, там используются более сложные конструкции. Но для небольших компаний все это более чем уместно. И это надо учитывать, читая обзор докладов: когда я говорю, что в докладе были достаточно известные вещи, это вовсе не означает, что они реально применяются в вашей конкретной компании, и потому вам не стоит посмотреть этот доклад в записи. А еще надо учитывать, что на многих докладах я был кусочно, переходя между треками.
А из общего пожелания докладчикам и организаторам конференции я бы отметил две вещи. Во-первых, надо жестко запретить примеры про форму логина. Потому что она настолько тривиальна, что скучна. Во-вторых, смерть от PowerPoint докладчики изучили (не все, только продвинутые), и теперь им надо объяснять, что когда на слайде креативная картинка, под которую долго-долго что-то говорят, то это тоже плохо. Особенно, когда говорят монотонно. Мне лично слайды, где много букв даже больше нравятся — при условии, что докладчик их не читает — получается документ, который можно на досуге внимательно прочесть. Вот так.
Итак, обзор докладов.
2013-10-26: SECR удался
SECR-2013 определенно удался. Два дня я слушал доклады, практически на всех слотах были интересные мне доклады, и это замечательно. Более того, я совершенно точно пропустил много хороших докладов, и даже доклад JetBrains про Kotlin и мастер-класс Макса Дорофеева по оценке проектов, потому что приходилось выбирать между параллельно идущими треками, которых в первый день было 4, а во второй — 5(!). Да, как сопредседатель программного комитета, я знал про тезисы большинства докладов и участвовал в рецензировании. Но тезисы сильно отличаются от живого доклада, воспринимаются по-другому, и, послушав доклады на конференции, я достаточно много узнал. Появились новые мысли. И все это не означает, что на конференции были только хорошие доклады высокого уровня. Казалось бы, можно было уменьшить число треков и поднять уровень. Но по тезисам, даже развернутым, доклад оценить нельзя, кроме того, разным участникам интересны не только доклады на разные темы, но и доклады разного уровня — потому что для применения в практической деятельности доклад должен попасть и в тему и в уровень восприятия. Поэтому доклады были разные. И участники — могли выбрать, а докладчики — увидеть реакцию и в следующий раз — сделать новый доклад лучше.
А еще на конференции было замечательное общение и, собственно, в этом — профит участия в современной конференции, потому что все доклады — доступны. Презентации уже есть на сайте, а через месяц-другой появится видео докладов. Но вот пообщаться с докладчиками и другими участниками по свежим следам, по темам докладов можно только там. И такое концентрированное общение, выход их повседневной текучки позволяют почувствовать изменения, тренды отрасли. А это критически важно в такой динамичной отрасли, которой является ИТ.
И конференция сильно обращена в будущее, о грядущем было достаточно много докладов, причем не от очень разных спикеров. Ивар Якобсон рассказывал про SEMAT — Essence: это только в конце прошлого года появившаяся в относительно законченном виде конструкция. Вил ван дер Аалст рассказывал про Process Mining — свежее, но уже оформившееся течение, основателем которого он является. Джим Стайклетер, директор по стратегии и инновации из Dell, рассказывал про тот мир инноваций, которым он живет, и это очень концентрированная картина, которую получаешь за доклад. А у Дэйва Томаса в презентации и докладе было много парадоксальных трендов современности, над которыми лично я планирую еще внимательно подумать.
И в этом мире компаниям и разработчикам надо жить и развиваться, успевать за этим миром. И началась конференция докладом Дмитрия Лощинина, президента Luxoft, о стратегии успешной компании. И были доклады и дискуссии, направленные на развитие стартапа, превращение продукта или его идеи в успешное предприятие. Кстати, был забавный кейс: продажи одного продукта плохо шли. Сделали тот же продукт, но для юристов, внешняя адаптация, в 10 раз увеличили цену, запустили рекламу — продажи серьезно выросли, и при этом продаж вдвое больше, чем активаций.
А еще многие ведущие компании — JetBrains, Parallels, Дойче Банк, Luxoft, Яндекс и другие — делились своими процессами, рассказывали о них, и это были не выступления первых лиц, а рассказы сотрудников, работающих внутри разработки. И было замечательное шоу Свена Петерса из Attlassian про современную разработку.
Но при всем этом на конференции было очень много технических докладов, и это тоже правильно. Был Крис Латтнер, главный архитектор в LLVM Compiler и директор разработки в Apple, он рассказывал про принципы и архитектуру LLVM и Clang, которые являются основой многих промышленных решений. Были доклады JetBrains, доклады из Parallels, секция мобильной разработки, которую вел Дмитрий Мартынов из Google. Я был далеко не везде, но слышал много отзывов. Были качественные узкоспециализированные доклады, например, профессора Бориса Штейнберга по высокопроизводительным вычислениям, при этом я от нескольких участников слышал, что тема оказалась им очень вовремя.
Я надеюсь, что в следующем году получится сделать конференцию еще лучше, интереснее и шире. А сам перехожу к обзору тех докладов, на которых я был. Читая их, помните, что это меньше четверти всех докладов конференции, и среди остальных тоже наверняка есть много хороших докладов. Презентации всех докладов уже доступны на сайте конференции, а через месяц-другой там появится видео.
И до встречи на SQAdays, которая начинается через полторы недели во Львове и где, в дополнение к обычному формату, будет отдельный день с иностранными докладчиками.
2013-10-23: SECR. Мастер-класс Ивара Якобсона Use-Case 2.0
Очень понравился мастер-класс Use-Case 2.0, который проводили Ивар Якобсон (Ivar Jakobson) и Иэн Спенс (Ian Spence) в рамках SECR-2013. Ивар и Иэн рассказывали о развитии механизма Use Case, которое он прошел за более, чем 25 лет истории (первая идея — 1987), и расширившее его применение в разных направлениях так, что он по-прежнему адекватен современным потребностям разработки.
- Scaling Up with use cases. From small team to large project.
- Scaling out — not only req, also analysis, design, UX and so on.
- Zoom in — focused on essential, show big picture.
И это была не просто лекция, в которую иногда превращаются мастер-классы от мэтров. Был интерактив и практическая работа над заданиями в группах. Да, местами было повторение известных практик, знакомых большинству присутствующих, например, оценки, а местами достаточно сложные и интересные вещи были даны пунктиром из-за недостатка времени, но мастер-класс в целом я бы оценил высоко. Было последовательно показано применение Use Case при работе с требованиями.
Существенно новой для меня была конструкция Use Case Slice, деление Use Case в процессе работы. Суть в следующем. У нас есть цельный Use Case со всеми альтернативными сценариями. Естественным образом мы их приоритизируем, выделяя важные и примерно относя к релизам. Для этого можно использовать технику MoSCoW: Must/Should/Could/Want. Но вот когда мы говорим, что Use Case — must, это вовсе не означает, что таковыми являются все его сценарии. Мы делим Use Case на пакеты сценариев, кусочки, которые и называются slice. Они должны быть некоторым образом закончены, должна быть возможность их поименовать, их реализация должна давать некоторое business value и быть относительно независимой. И далее планирование релизов и итераций идет уже в терминах slice, которые приоритизируются и реализуются по отдельности. Естественно, с учетом зависимости, и в первый slice идет base flow, с учетом minimum viable value.
Но при этом Use Case сохраняется, он обладает целостностью более высокого порядка. А разработчики, проектируя реализацию (design), знают о других кусочках Use Case, которые надо будет сделать в будущем и учитывают их. Важно, что хотя декомпозиции на slice в конечном итоге подвергаются все Use Case, она выполняется по мере необходимости, а не изначально.
Вообще этот принцип детализации по необходимости применяется очень активно. И не только к декомпозиции Use Case, но и к различным артефактам, например, описанию Use Case и связанных с ним историй. И не в форме благих пожеланий к постепенной детализации, а через определение трех-четырех уровней детализации с формальными критериями и рекомендациями, для каких целей какие из них предназначены и на каких этапах появляются. При этом они не должны быть одинаковы по проекту, потому что Use Case и другие объекты имеют различную важность и сложность, и детализация должна быть им соразмерна.
В частности, была показана матрица техник для уровней описания Use Case в зависимости от критичности (относительно неверной работы) и частоты использования. Ожидаемо, что для критичных Use Case надо гораздо детальнее определять Test Case. А вот описание самого кейса больше зависит частоты использования: для ежедневных эффективнее краткое описание с активной коммуникацией, а вот для редко используемых, например, связанных с концом года, нужны подробные описания.
Помимо декомпозиции Use Case на slice были рассказаны следующие техники.
- Преобразование Use Case Slice в Test Case, которыми каждый slice снабжается и которые также могут иметь разный уровень детализации. Кстати, base flow может быть разложен на два или более slice, отличающихся именно Test Case: сначала делаем реализацию для единичных хороших данных, а потом — наращиваем вариативность и мощность.
- Преобразование нефункциональных требований в Use Case Slice со своими Test Case. При этом выбором Use Case, в которых это появится, заодно определяется область применения таких требований. Это можно делать не только с производительностью и масштабируемостью, но и с удобством использования (Test Case — 5 человек без обращения к помощи выполнили задание не более чем за…).
- Использование Use Case для больших компонентных систем, преобразование больших Use Case в соответствии с декомпозицией на Use Case для отдельных систем.
- Использование Use Case для требований на инфраструктурные аспекты кода, такие как аудит, лог изменений или безопасность.
А еще мастер-класс был элегантной демонстрацией Essence, разработанного SEMAT. Не в виде отдельных слайдов, а как практическое использование. Понятия — Use Case, Use Case Slice, Story — были представлены как альфы, для них описаны состояния, и уровни детализации для артефактов. Например, Use Case имеет состояния goal established → story structure understood → simplest story fulfilled → sugnificant story fulfilled → all stories fullfiled; а Use Case Slice — состояния scored → prepared → analyzed → implemented → verified, и для некоторых приводились checklist перехода. А уровни детализации, применяемые для историй и описаний, — sketch — base essential — enhansed — expanded — future expanded — с раскрытием каждого уровня и областями применения.
На этом я кончаю рассказ. Надо отметить, что на сайте Ивара доступна для скачивания после регистрации книга Use-Case 2.0 с материалами мастер-класса.
2013-10-18: Спиральная динамика
Если ты поумнел, поглупеть обратно волевым усилием нельзя. Получение нового знания — один из необратимых процессов в природе. Иногда об этом сожалеешь, потому что понимаешь, что теперь надо прилагать усилия и умнеть дальше по конкретному направлению. Вот так у меня получилось со спиральной динамикой: я хотел посмотреть, что это такое, посмотрел — и теперь придется разбираться, вписывать в картину мира. Потому что вещь — интересная, в нужной области и под ней есть годные основания и базовые положения. Только вот на них сейчас построено такое здание идеологизированных умозрительных конструкций, что продираться через них, чтобы увидеть основания, — тяжело, а здание целиком, с моей точки зрения, настолько мутно и умозриетнльно-идеологизированно, что взять «как есть» у меня не получится.
Этот пост — фиксация положения для себя, чтобы потом вернуться к разбирательству. А еще пишу его в надежде — вдруг кто уже разобрался, или заинтересуется, разберется и мне расскажет. Все-таки для меня эта область — не совсем профильная деятельность. Но обо всем по порядку.
Началось это во второй половине сентября, когда я был на тренинге института Адизеса по их подходам. В качестве бонуса по запросу аудитории нам за 10 минут рассказали, как они подходят к набору персонала. Одна из важных составляющих для них — система ценностей человека, поскольку в их подходах ценности и культура играют очень важную роль. И в качестве способа для работы и оценки системы ценностей кандидата они используют спиральную динамику, считая ее наиболее продвинутым на настоящий момент инструментом. Для меня это было достаточным, чтобы сделать заметку — посмотреть, что это за зверь, — спиральная динамика. Я там же поискал статьи, чтобы убедиться, что названия и имена — те, что надо, а дальше пару недель у меня это висело в браузере. И на этих выходных я добрался и прочитал.
Вот что я читал:
- Спиральная Динамика;
- Уровни Грэйвза. История возникновения;
- Типология систем ценностей Клэра Грейвза;
- Спиральная динамика - опасное знание;
- 7 стадий зрелости Лидера;
- Перевод на русский статьи из Википедии о теории Спиральной Динамики (оригинал).
- UPD 2018: статьи вики доступны только в archive.org: перевод, оригинал, статью в вики удалили в 2015 и потом сделали перенаправлением на Дока Бека
Читал я именно в этом порядке, и это во многом определило мой интерес и мою оценку вещи как годной. Потому что во второй статье был рассказ про исследования Клэра Грейвза.
Грейвз вел исследования в 60-70-х. Вообще это было время, когда зарождались многие теории — Друкер, Белбин, Майерс-Бриггс — это все та эпоха. Для Грейвз предметом были представления о модели нормального человека, а релевантной группой служили студенты, которых он обучал психологии. Для начала они описывали собственную модель нормального человека. Дальше — обсуждали ее с другими в произвольных группах (а Грейвз наблюдал из-за стекла). И писали, что изменилось, или, наоборот, не изменилось и почему. После этого их сталкивали с авторитетными моделями, и опять-таки они писали — изменилось ли что-то или нет, и почему. И вот так — 8 лет с каждым курсом. При этом все работы передавались внешним экспертам, каждый год — разным, задачей которых было провести кластеризацию и выделить принципы. В целом — хороший подход, мне нравится.
Так вот, в результате кластеризации получилась схема из 4 квадратиков: 4 отчетливых группы, разложенные по двум дихотомиям.
И, что интересно, переходы позиции в этих рамках были не произвольны, а шли по единственному пути развития.
Однако, были позиции, которые не совсем укладывались в эту картину, и они были статистически значимыми. И на основе этого Грейвс расширила эту классификацию, плюс связала ее с системами ценностей общества, сменявшими друг друга в ходе исторического развития. В результате получились следующие 8 уровней.
- Бежевый — автоматическое, инстинктивное мышление. Охотники-одиночки. Экспрессивный тип. Цель — биологическое выживание. Работают только базовые биологические инстинкты: голод, размножение и т.п.
- Фиолетовый — анимистичное, племенное. Племя. Жертвенный тип: индивидуальность приносится в жертву выживанию племени. Цель — безопасность, выживание племени, семьи. Мир воспринимается полным духов, загадочных сил, которые следует ублажать.
- Красный — эгоцентричное, силовое. Боги и герои. Экспрессивный. Попытка гиперреализации себя, импульсивно, любой ценой. Цель — личная власть, расширение сферы контроля. Мир — это джунгли, выживает сильнейший. Время великих путешественников и героев.
- Синий — абсолютистское, священное. Жертва ради идеи. Жертвенный. Пожертвовать чем-то, чтобы получить награду позднее. Свои желания приносятся в жертву идее, высшему порядку. Чувство долга. Цель — стабильность, порядок, соблюдение ритуалов. На этом уровне появляются крупные религии, преследование ересей и т.п. «Мыслить локально – действовать глобально».
- Оранжевый — материалистическое, ориентированное на достижения. Большая игра. Экспрессивный. Проявляю себя обдуманно, в том числе и за счет других. Реализация себя в конкуренции с другими, причем собственно процесс ценится выше результата. Проигравшему потом возвращают проигрыш, чтобы сыграть еще раз. Появляется профессиональный спорт, конкурсы красоты и т.п. Цель — успех, влияние. «Мыслить локально – действовать локально».
- Зеленый — социоцентрическое. Человек превыше всего. Жертвенный. Жертвую одним сейчас ради другого сейчас же. Жизненное кредо: бесплатных пирожных не бывает. Внимание к потребностям других людей. Появляется концепция экологии. Давайте лишимся завода, но будет чистый воздух. Цель — гармония, взаимный рост, сотрудничество. «Мыслить глобально – действовать глобально».
- Желтый — системное, интегрирующее. Интеграция. Экспрессивный. Выражаю себя, но не за счет других. Стремление к интеграции конфликтов, удовлетворению всех потребностей. Цель — независимость, свобода, достоинство, интеграция в глобальную систему. Системный подход, учет контекста. «Мыслить глобально – действовать локально».
- Бирюзовый — глобалистское, модернизаторское. Глобальное сознание. Пока что характер этого уровня не вполне ясен. Жертвенный тип. Приспособление себя к базовым принципам устройства мира. Глобальное сообщество, восприятие человечества как целого, интеграция на уровне культур.
Подробности желающие могут посмотреть по ссылкам или в других источниках, а здесь я это привожу, поскольку представление о них важно для дальнейшего.
Как легко увидеть, теория в целом не следует из экспериментального материала. Но это как раз нормально, между экспериментом и теорией лежит прозрение ученого — дуга Эйнштейна. Однако, приличные науки полагают правильным подвергать построенные теории дополнительной экспериментальной проверке, чтобы убедиться, правильно ли нас привела эта дуга. Однако, приличных наук сейчас почти нет, и, говорят, даже теоретическая физика перестала желать экспериментальной проверки. Впрочем, это уже другая история.
Если же говорить о Спиральной динамике, то проверкой пренебрегли. Более того, теорию начали строить дальше и дальше, и сейчас теория далеко обгоняет факты. Строит теорию уже не Грейвз, а последователи, и попутно грызутся — кто правовернее. Историю можно посмотреть в последней статье: это перевод английской вики (но я не проверял). Мне это напомнило историю с соционикой — там тоже сейчас несколько школ выясняют, кто из них правильнее понимает теорию, а общий уровень практики — весьма низок.
Но это — общая претензия к обоснованности. А теперь — конкретные претензии к той конструкции, которая сейчас получилась.
Это — явно оценочная конструкция. Да еще выделен принципиальный переход — второй ярус. Кстати, более политкорректное крыло последователей говорит, что второй ярус, возможно, был выделен основателем из маркетинговых соображений. А другое крыло на нем настаивает. И это при том, что сама конструкция — достаточно мутная. Тесты для определения уровней отсутствуют, и, более того, утверждают, что человек одновременно может быть на нескольких уровнях.
Кстати, если смотреть чисто на закономерности развития, как они выделены у Грейвса, то второй ярус, понимаемый как второй виток спирали развития, а не как качественный переход, явно имеется. Но начинается он не там, где его Грейвс выделил. На нынешнем уровне знакомства я могу обосновать, что гомология с бежевым начинается на оранжевом. Или, что интереснее, на зеленом, при этом по дихотомии я–мы получается движение в противофазе — умозрительно эта конструкция интереснее, хотя и сложнее. Естественно, я понимаю, что верно только одно, но для решения надо копать и нормально разбираться с бирюзовым: а говорят, что он мутный.
А еще есть неразбериха с движением по уровням. Исходные опыты были не про смену парадигмы, а про ее представление. Испытуемые — студенты, которые формулировали свою парадигму, а потом обсуждали ее. Понятно, что в процессе этого они ее и осознавали. Поэтому изменение может говорить не о развитии ценностей человека, а лишь об их вербализации и сложности формулирования определенных конструкций, а не об изменении самих ценностей. В то же время сейчас теоретики говорят, что движение строго последовательно и нельзя перейти через уровень. Как это сочетается с тем, что человек на нескольких уровнях одновременно, и может быть не только подъем, но и откат, — сильно непонятно.
А еще последовательное движение явно противоречит другим теориям, например MBTI. Поскольку последовательные уровни отличаются по дихотомии я–мы в смысле, очень близком к дихотомиям мыслящий–чувствующий и интроверт-экстраверт. А MBTI говорит, что позиционирование в типах личности стабильно и закладывается генетически или в раннем детстве.
Так что, в целом основания теории — довольно слабые, а пафос обобщений и оценочные суждения — весьма велики.
А еще наблюдается сильная аберрация близости и плюс влияние западной культуры в верхних уровнях, ибо все исследования были в Америке. И сами верхние уровни весьма малочисленны, что сказывается на достоверности. С другой стороны, историческая проекция основана на весьма схематичном, упрошенном понимании исторического процесса, который очень много схлопывает. А соответствие ценностей уровням исторического развития — одно из оснований теории.
Могут возразить, что претензии претензиями, но это же работает. На самом деле, я понимаю, почему это работает: любая разумная структуризация лучше, чем полное ее отсутствие. Ибо позволяет строить общие конструкции на основе обобщений, а не работать с конкретными фактами. Структуризация здесь в целом нормальная, дает достаточно многообразия, хотя местами и устарела. И с ней можно работать, особенно если игнорировать оценочную составляющую. А еще спиральная динамика опирается на сильные мемы, которые находят отклик, и это дает уверенность в правоте теории.
Итак, что я понимаю. Работать с системами ценностей — актуально. А говорят, что спиральная динамика — лучшее, что есть сейчас, и я склонен доверять авторитету института Адизеса. Хотя готов рассмотреть варианты. А пока — буду укладывать в картину мира и иметь ввиду.
Да, разбираясь со всем этим, я прошел тест на jobeq.net — его упоминают в одной из публикаций. Мои цвета — бирюзовый, желтый и оранжевый. В общем-то, бирюзовым я несколько удивлен, хотя про желтый и оранжевый соответствуют самоощущению. Но, значит, я продвинутее, чем думал, это — хорошая новость :)
2013-10-12: Впечатления с AgileKitchen
Серия осенних конференций началась с AgileKitchen. В конце месяца будет SECR с Иваром Якобсоном, потом — SQAdays во Львове с отдельным днем европейских докладчиков, а в начале декабря — SPMconf в Казани. Это — те, на которых я планирую быть, чтобы услышать, почувствовать новые тренды отрасли, узнать новые практики. И удачное начало этому было положено на AgileKitchen в эту пятницу, на территории Лаборатории Касперского.
Несмотря на название и позиционирование как обмен мнениями «на кухне», это было достаточно серьезное мероприятие. И по числу участников — думаю, было около сотни, хотя могу ошибаться, — которые сидели в большом зале, объединенном из трех переговорных с тремя большими экранами, и по уровню организации. И, главное — по характеру выступлений. На AgileKitchen выносятся темы, которые сейчас на острие развития, не успели обрасти серьезными теориями и практиками, но которые пробуют изучать и применять. И люди обмениваются опытом. А еще — там делятся практическим опытом решения задач, которые почему-то не становятся менее актуальными, несмотря на, казалось бы, давно известные подходы к решению. Их решают в конкретных условиях, и каждое новое решение имеет свои особенности, дает какой-то новый опыт, который тоже интересно обсудить.
Собственно, обсуждение практического опыта — самая важная составляющая мероприятия. И его было много: в перерывах между докладами, на OpenSpace, после конференции.
2013-06-10: По следам MS DevCon-2013
В конце мая я был на MS DevCon-2013, где весьма продуктивно послушал о трендах развития отрасли по версии Microsoft. К сожалению, сразу по возвращении возникло много работы, так что реплика по этому поводу появилась только сейчас.
Я уже писал осенью под впечатлением от Patterns&Practices: «Пока мы наступаем, Microsoft меняет рельеф местности». Это впечатление сохраняется, и, более того, изменения рельефа постепенно проясняются.
2013-05-27: AnalystDays-2013
Вторая конференция Analyst Days. Мне понравились все доклады на которых я был. Это не значит, что все они несли ценность и новые мысли для меня - все-таки у меня достаточно высокий уровень и большой опыт работы, однако они будут интересны и полезны многим аналитикам, и не только начального уровня. И это не только мое мнение, я разговаривал с другими участниками, слушал отзывы в перерывах между докладами. А я для себя - тоже вынес определенные мысли и идеи, которые буду применять в своей деятельности. Очень хорошая, может быть даже превосходная, Модель аналитика, которая была в докладе Димы Безуглого и Ирины Суровой. Идея Контекста проекта из доклада Кристины Ерофеевой, у нас есть аналогичные артефакты, но взгляд на них под этим углом зрения дает новые грани. Хороший практический доклад о применении Impact Mapping Дмитрия Петрашева. Книга Сэм Кеймер "Руководство фасилитатора", о которой рассказывал Саша Байкин. Хорошие метафорические названия - "метод соломенных чучел" Ани Абрамовой, для ситуации, когда для вытягивания информации представляешь на растерзание заведомо неполную модель, и схема "луна за облаками" Сергея Горицкого - "Руководство тоже озабочено проектом, если мы не сможем договориться - сходим к руководству".
На нескольких слотах я разрывался между параллельно идущими треками. А ряд докладов пропустил полностью, потому что параллельно шло более интересное для меня. И, по отзывам участников, среди них были хорошие. Так что если вы хотите посмотреть доклады в записи - а они будут выложены через некоторое время - то ориентируйтесь не только на мой обзор.
Местами конференция сумбурновата. И этому есть основания. Попытка построить стройные модели аналитической деятельности и проектирования, архитектуры и другие - кончились провалом в рамках отрасли. Получаются схемы верхнего уровня, наполненные общими рассуждениями и без строгих определений, трактуемые по-своему, или тяжелые запутанные конструкции описания процессов, слабую практическую пригодность которых знает каждый эффективный действующий аналитик. И поэтому в докладах приходится представлять частные схемы, или создавать свои. А многие аналитики-практики - сенсорики (по Майерс-Бриггс, не путать с соционикой), это очень эффективно в проектах, в которых дьявол в деталях, а деталей - много. Но концептуальные конструкции им создавать тяжело. А аналитики-интуиты - они часто берутся за достаточно глобальные построения, те самые, на которых в отрасли нет хороших моделей - меньший уровень не является для них вызовом - но модели не слишком получаются, потому как это дело реально сложное, я по себе знаю.
Прежде чем переходить к докладам, я хочу отдельно отметить высокий уровень организации. Потому что когда что-то сделано хорошо, то это как-то не замечают и не отмечают :) А вот когда что-то плохо - да, во всех отчетах напишут. А на этой, как и на других конференциях Влада Орликова уровень организации - очень высок. В фойе предусмотрены места для общения. В течении всего времени конференции, а не только в перерывах, есть чай кофе и плюшки, в этот раз добавился еще фруктовый лимонад. И это создает возможности, стимулирует общение участников с докладчиками и между собой. Создает особую атмосферу сообщества. Что замечательно.
А еще надо отметить, что многие докладчики на конференции звали на ЛАФ, Летний Аналитический Фестиваль, который несколько лет проходил в Иваново, а в этом году будет проходить в Этномире. И который, по опыту прошлых лет, собирает теплую компанию аналитиков с хорошими докладами и живым общением.
2013-04-29: SQAdays-13 (весна 2013)
Конференция SQAdays-13 в Питере в очередной раз дала новые мысли и заряд общения. На самом деле, я регулярно колеблюсь - ехать ли на конференцию или нет, потому что тестирование - это непрофильная для меня область, а время - единственный ресурс, который утекает безвозвратно. Но вспоминая мысли и идеи, полученные на прошлых конференциях, а так же большой заряд общения, которое давали прошлые конференции, решаю поехать.
С каждым разом на конференции все больше народа. Эта конференция проходила в Park Inn Прибалтийская и собрала больше 600 человек. Реально гигантские залы, и полные. С задних мест докладчик - где-то вдали, на горизонте, особенно в большом зале - поэтому стоят плазмы, идет трансляция и экрана и докладчика. Думаю, следующая конференция будет еще более многолюдная. Она состоится во Львове, будет 3 дня вместо обычных двух и там будет день западных спикеров.
Интересным на этой конференции была секция блицев с переполненным залом, правда самым маленьким. Вообще, это парадокс: в блицы выжимают не очень сильные доклады, а народ на них охотно идет, потому что жесткий таймбоксинг концентрирует изложение и повышает качество доклада. И даже если будет не очень удачным, то недолго :) Это, кстати, подтверждает опыт AgileDays, где под блицы был отдан главный зал. Некоторые опытные докладчики это уже поняли, и сами подают блицы. Кстати, после блицев получается своеобразное отравление, даже очень хороший по уровню доклад, но со спокойным изложением материала воспринимается не слишком хорошо, не хватает динамики.
Дальше я расскажу о том, что я вынес с конференции, какие тренды и практики увидел. Потом - немного о докладах вообще, и об образовании тестировщиков. И там - некоторая классификация докладов. А потом будет обзор докладов. Он не сгруппирован по приведенной классификации, хотя в начале доклада я ее часто указываю. Потому что конкретный доклад ищешь все-таки от проблем, а не от его уровня.
Естественно, я был не на всех докладах, и выбирал из своих профессиональных интересов. Но на многие я забегал, и их - тоже отмечаю в обзоре, особенно хорошего уровня - может, это побудит кого-то посмотреть этот доклад, хотя понимаю, что по краткому пребыванию вполне мог ошибиться с классификацией. И отмечу, что я сознательно не ходил на доклады Microsoft, потому что знаю этот материал из других конференций. Так что отзывы об этих докладах ищите у других, а я скажу, что в целом Microsoft старается не просто представить свои инструменты, а рассказать об их комплексном использовании, показывая прохождение процессов - в функциональном описании продуктов этого момента обычно нет.
2013-04-20: Питер Друкер - Энциклопедия менеджмента
Питер Друкер "Энциклопедия менеджмента". Как написано в предисловии автора, творчески собрана из его книг за 60 лет с участием его самого и представляет введение в теорию управления. Получилось емкое и концентрированное изложения, касающегося менеджеров и вообще работников умственного труда (оказывается, это - его термин, 1969). Но еще - получился обзор развития общества, начиная с середины 19 века (а местами и раньше), и до конца 20 века (книга издана в 2001, работы 1999 учтены). При этом материалы рассыпаны по тексту, что дает взгляд с разных сторон. А еще - свидетельствует о цельной картине у автора, который легко начинает с верхнего уровня и погружается в детали под уместным в конкретном месте углом зрения. И это - превосходно, потому что подобные картины - большая редкость.
И в этой картине - много о вызовах современного постиндустриального общества - общества, основанного на знаниях. Питер начал об этом писать в 60-х, в том числе - говоря о вызовах, стоящих перед людьми, живущими в этом обществе и о его противоречиях, требующих решения в развитии. И многое из того, что происходит сейчас - проявления этого развития, решение стоящих противоречий. Включая то, что происходит в мире с образованием, например. А также - с кризисом общества социальных пособий, распределяемых бюрократами - что мы видим в Европе. И, в общем, в свете этого как-то странно слышать стоны о неожиданности происходящего. Впрочем, на проблемы и противоречия, изложенные спокойным языком в конструктивном залоге обычно не обращают особого внимания, это вам не вопли о всеобщем крахе... Да, конкретно про Россию там не слишком много, но мир - он един, и это уже дело читателя - примерить изложенное к России.
А еще читатель может примерить изложенное к своей профессиональной деятельности и своей отрасли. Я тут понял, что Agile появился в IT вполне закономерно - как в ответ на неспособность менеджеров в своей массе отвечать тем новым вызовам современного общества знаний, о которых пишет Друкер. И естественным образом это проявилось наиболее сильно в той отрасли, которая развивалась интенсивнее всего, и где потому сильнее была потребность в новых менеджерах. Менеджеры же продолжали мыслить по-старому, пытаясь свести деятельность к процедурам. И потому возникли предпосылки к революции, "верхи не могут, низы не хотят" - и она произошла. Но она не просто произошла, она породила SCRUM - инструмент, во-многом отвечающий тем потребностям менеджера в освобождении себя от текучки, о которых говорит Питер. Правда, целью этого освобождения для многих из IT-менеджеров были вовсе не менеджерские активности, а проектирование и разработка софта, которой они предпочитали заниматься. А для тех, кто предпочитал именно менеджмент этот инструмент дал способ масштабирования своей деятельности - такой менеджер может управлять несколькими agile-командами, не имея внизу полноценных менеджеров с полным набором обязанностей и компетенций. Кстати, об этой проблеме, как о типичной и требующей решения - Питер тоже пишет. А дальше agile постепенно впитал в себя многие позитивные менеджерские практики - что и должно было случиться, в соответствии с естественной логикой диалектического развития, смотри закон отрицания отрицания.
Кстати, последний тренд, gamification - он тоже реакция на изменение ситуации, о котором говорит Друкер - когда не люди конкурируют за рабочие места, а организация выбирает, а наоборот, когда люди выбирают организацию, исходя из своей самореализации. И геймификация - конкурентное оружие организаций и менеджеров за кадры. Это общий тренд интеллектуальных отраслей, не только IT. Конечно, многием менеджеры понимают ее упрощенно, как еще один способ интенсификации труда и всяких KPI в новой форме. Но такое применение - точно проигрышно.
Есть и еще одна задача читателя, вернее, возможность - применить прочитанное к себе, к своему собственному развитию. Тут надо сказать, что многие известные практики, например GTD Аллена, являются как раз методами решения тех самых проблем, о которых Питер пишет как о стоящих перед работниками умственного труда. Но у Друкера проблемное поле - целостно, а не фрагментарно, что дает возможность лучше осозновать стоящие задачи и вызовы. И я думаю, это мне позволит лучше управлять собственным развитием.
Да, про agile - это, естественно, в мировых масштабах, а не про нашу компанию, и даже не про Россию - в России как раз было не так, поскольку в отрасль в 90-х во многом приходили из советской науки, а там нормально управляли интеллектуальными проектами.
2013-04-14: Конференция SoftwarePeople-2013
В целом конференция - удалась. За два дня было довольно много хороших докладов. Сергей Мартыненко в первый день трижды порвал шаблон, говоря об оценках проектов. Дима Безуглый рассказывал об эмоциональном интеллекте и управлении им как необходимых скилах руководителя, и о различных стилях управления. Максим Дорофеев устроил шоу аттестации с мат.моделью программиста на основе детского носка с цветными шариками, и практически показал влияние вариаций и использование карт Шухарта для работы с ними. Были и другие доклады хорошего уровня.
Еще были доклады практиков о своем реальном опыте. Да, многие грабли, которые они преодолевали - известны. Но, в конце концов, это очень программистский подход - пробовать самим, а мануал читать только в крайнем случае. Они так часто подходят не только к всяким программам, но и процесса и людям. Может, именно тут играет роль отличие практического знания от теории верхнего уровня, и вполне возможно, что именно через такие доклады можно, узнав в них свои проблемы, соотнести теорию со своей практикой.
Иностранные докладчики в этом году, увы, не порадовали. Они все в прекрасном и великом прошлом, которое знают энциклопедично. А настоящее - больше на уровне трендов и мемов. Ну, будем надеяться, что в будущем будет лучше - ведь был же в прошлом году Джефф Де Люка, а в позапрошлом - Нил Мейден и другие.
Сам я выступал на конференции, рассказывал об опыте применения Domain Driven Design. Прямое отражение модели в код на основе шаблонов Domain Model и Rich Objects, о котором говорят авторы подхода, вызывает в больших многолетних проектах определенные проблемы, и для их решения мы разрабатываем в проектах набор более сложных правил отражения, который назвали Технологическими рельсами. Доклад вызвал интерес, были вопросы. И еще из нашей компании выступал Коля Гребнев, рассказывал о создании самоорганизующихся процессов в командах. Его доклад тоже слушали с интересом.
А теперь о докладах подробнее. Надо учитывать, что я был далеко не на всех докладах. Я пропустил Кириленко потому что мой доклад стоял параллельно. Не был на Орлопанках, слушая параллельный трек - там были наши ребята и, я думаю, они донесут ценное, что там было. Еще был большой трек Microsoft ALM, о котором я знаю из других источников и трек мобильной разработки, которая (пока?) вне сферы моих профессиональных интересов, туда я зашел только на Дмитрия Мартынова из Google чтобы почувствовать тренды. А еще во второй день мне пришлось уехать в 15 часов, увы.
2013-04-10: Мастер-классы Эдварда Йордана
Перед конференцией SoftwarePeople прошли два мастер-класса Эдварда Йордана CIO’s at Work и IT Project Estimating. Я был на обоих. Первый из них был довольно дорогой - организаторы хотели камерности, и им эту удалось, я бы сказал даже более чем. Свою роль сыграла не слишком понятная программа мастер-класса: сама книга есть только на английском, а анонсе обещано обобщение опыта CIO различных крупных компаний. На втором же было более 50 человек.
На первый я пошел, надеясь получить видение уровня отрасли на мировом уровне. В этом был определенный риск, который, к сожалению, реализовался. Наиболее точной будет следующая аналогия. Если вы идете в лес смотреть животных в естественной среде, то сопровождающий может оказаться биологом, и тогда вы не только увидите внешние проявления, но и многое узнаете о внутреннем устройстве и его причинах. А в менее удачном случае вы увидите преимущественно внешние проявления, а внутреннее устройство будет на уровне общих рассуждений и примеров. Только вот редко хорошие биологи еще и водят группы по лесу. Так и в этом мастер-классе реализовался больше второй вариант, чем первый. Но показ внешних проявлений был на уровне. И, хотя я сам не новичок в этом лесу и многое знаю, представление в целом было полезным.
Мастер-класс был на хорошем английском, даже записывая, я продолжаю воспринимать то, что он говорит, а это - ценно. В электронных материалах - много линков. Сами материалы - это оглавление рассказа, каждый пункт был раскрыт и иллюстрирован историями, которые хорошо рассказаны. Йордан знает опыт в отрасли - середины 60-х. Технологии - меняются, а люди - не очень. Книга CIO’s at Work, на основе которой построен мастер-класс - реальные интервью, 16 штук. Я ее полистал, и по-моему не слишком интересно. А в мастер-классе - обобщение этого опыта. А я дальше немного расскажу об интересных для меня моментах, дополнив своим видением. Естественно, передать полностью не получится, даже опубликовав презентацию - потому что оглавление не передает содержание текста, и по нему вы можете лишь оценить - знаете ли вы об этих вопросах вообще, а никак не соотнести свое знание с позицией автора.
Что любопытно - далеко не во всех компаниях получается найти и идентифицировать CIO, несмотря на важность информационных технологий. А еще они часто довольно закрыты для внешних контактов в описании своей работы. В целом CIO компаний - относительно традиционные и консервативные менеджеры, не взирая на все громкие крики о быстрой динамике отрасли и высоких требований, предъявляемых к освоению нового. Не все осваивают - и работают.
С освоением технологий явно лучше, чем с освоением менеджерских аспектов. И те тренды ориентации на людей как ключевого фактора для успеха проектов, и которые, говорят, зародились в далеких 60-х в космической отрасли штатов, были, казалось бы, освоены IT-отраслью в изложении Peopleware Тома ДеМарко, а в последнее время воплотились в Agile-Lean процессы - остаются лишь баззвордом.
Был представлен список приоритетов CIO. Из него видно, что преимущественно они заняты текучкой, операционной работой. А стратегия - увы, даже не в верхней половине списка. Еще интересно сравнить списки приоритетов 2010 и 2011 года. Список 2010 года содержит вполне понятные цели и задачи - по поддержке основного бизнеса со стороны IT, по эффективности самой IT-работы. И довольно мало мемов, которые "должны волновать всех" (Cloud, broadband и connectivity), и это - не есть хорошо для жрецов соответствующих мемов. В списке 2011 содержательные пункты сгруппированы в 1-2 группы со своими баззвордами, и за счет этого освобождено место для мемов. В 2012 число мемов еще увеличивается - portal, mobile... Все это хорошо согласуется с еще одним трендом современного общества - переходом от содержательных понятий к мемам.
Поговорили также о мемах и баззвордах, не вошедших в список приоритетов, некоторые из которых обозвали tools, например, virtualization или social media :) К сожалению, форма представления в виде списков так же несет отпечаток консервативности. Здесь более уместны семантические сети или другие визуальные формы, потому что приоритеты и другие понятия перекрываются и связаны. Увы, этого не было.
Дальше были темы, вокруг которых CIO согласны, и темы, традиционно вызывающие холивары, такие как peopleware, наука против творчества или роль MBA и финансов. Да и согласие тоже относительно - все согласны, что социальные сети влияют сильно, но вот как. А еще - темы, по которым традиционно громкие слова не подтверждаются делами, как в контактах с подчиненными, отказ от жесткого иерархического контроля.
Дальше перешли к трендам развития в мире. Они известны, но тут получился обзор в комплексе, относительно интересный. В целом получается устойчивый тренд на совмещение рабочего и личного (семейного) пространства - через личные девайсы, совмещение календарей и систем индивидуального планирования, смешение в соцсетях рабочих и личных контактов с достаточно публичным общением. И в результате есть тренд к смене характера взаимодействия - взаимодействие фирм через взаимодействие людей. Впрочем, по-моему, если рассматривать в исторической перспективе, то в свое время личное взаимодействие и было основой взаимодействия фирм, а в Китае, например, оно до сих пор считается нормой, и некоторые западные исследователи рассматривают это как "незрелость" общества. А тут взаимодействие людей возвращается, на новом уровне, в полном соответствии с диалектикой развития :)
И в конце были достаточно интересные слайды про поколение F, от facebook, которое осваивает соцсети еще в школе. Штука в том, что достаточно много стереотипов поведения, приобретаемых при активном общении в соцсетях, противоречат стереотипам поведения, принятым в большинстве компаний. И есть опасение, что компании могут ждать большие потрясения, как только туда придет достаточно много сотрудников нового поколения. Потому что один из демонстрируемых стереотипов - легкая самоорганизация в группы, со своим лидерством, которое определяется поведением, а не назначается, с высокой мобильностью по этим группам. А еще один - активная публичность, открытость информации, использование ее чтобы приобрести последователей. При этом люди достаточно адаптированы, и умеют существовать там, где их меньшинство. А потом, вдруг - самоорганизуются и берут управление. На слайде выписано достаточно много факторов по этой статье, это любопытно.
Так что в целом получился довольно интересный, хоть и поверхностный обзор современного состояния и трендов. Второй же мастер-класс, посвященный оценке IT-проектов, обернулся большим разочарованием. Потому что 3/4 времени в нем говорили о проблемах и сложностях оценки, они были рассмотрены исчерпывающе и иллюстрированны примерами. Только вот эти проблемы - старые, известны много лет. А вот на позитивную часть осталась 1/4 времени, и потому докладчик начал просто читать оглавление на слайдах. Я думаю, это был сознательный шаг. Потому что решения у старой IT-школы - нет. Проблемность подходов, названных на слайдах второй части - хорошо рассказана в первой. И если сказать тоже самое в залоге "следует обратить внимание, учесть и избежать..." - то ведь решения не появится.
Надо сказать, что в отрасли ответ на задачи оценки проектов - появился, в рамках agile-практик. И там не два подхода к оценке (в попугаях и в размерах), а больше, различающиеся еще тем кто, когда и для какой цели оценку проводит. А в определенных процессах оценка признана ненужной, а предсказания делаются другим способом. Да, с этим тоже есть проблемы, но это - другие, новые проблемы, конечно, многие из них похожи на старые, но вот контекст - уже сильно другой. Все это старой школой не освоено, хотя слова - да, они их знают. И даже вписали их в PMBOK и SWEBOK как смогли, весьма эклектично. Собственно, в этой форме подходы к оценке во многом и были представлены на слайдах.
Может, оно и нескромно, но Эдвард показал мне то будущее опытного IT-шника, живущего представлениями прошлого и снисходительно смотрящего на современные подходы без глубокого погружения в них, которого я для себя - точно не хочу. Думаю, он вполне достойный эксперт, который помогает избежать конкретных ошибок в больших проектах, основываясь на своем опыте. Но вот понимания современных практик ведения IT-проектов у него, увы, нет. А значит организовывать их или обучать новое поколение - не получается. Жаль.
2013-04-07: Agile и классический менеджмент
В одной семье была стряпуха, которая готовила совершено замечательные блюда. По нынешним временам оно редкость и потому повадились к ним гости часто ходить, а хозяев это устраивало. только вот стряпуха не успевать стала - она обычно праздничную еду за день-два начинала готовить, чтобы спокойно все сделать, и обычной едой тоже кормить. а такой возможности не стало. Сначала хозяева попробовали ей помочь современными инструментами - кухонный комбайн, мультиварка и прочее. Но не прижилось: кухонный комбайн, конечно, режет быстро, но не так, как надо, и вообще - опасно это с ножами всякими. А мультиваркой вообще непонятно как пользоваться - туда же надо загрузить все продукты, а потом, когда готовиться - даже пробовать нельзя, а то вся жидкость паром выходит и подгорает оно.
Тогда решили хозяева нанять помощницу. Правда, с выбором тоже сложности возникли. Молодые - они как раз любили современные средства использовать, а не по-старинке готовить. Те же, кто соглашались всему учиться - ничего не умели и будет ли от них помощь - было непонятно. Еще были те, кто умел готовить традиционным образом, но они хотели много денег, а быть помощником - их не устраивало, хоть и не умели они готовить так вкусно. В результате наняли молодую и бойкую, велели смотреть и помогать новыми инструментами, ну и самой учиться, чтобы хотя бы простые блюда так же вкусно готовить.
Ну и началась у них совместная работа со всякими подколками. Стряпуха говорила, что вкус не получается потому что нарезано неправильно, сок не дает или наоборот, в кусочки в пюре превращаются. Или потому что кто ж кладет сразу все специи, как в мультиварке приходится, да не пробует пока готовит. А молодая - что копается стяпуха больно долго, вручную нарезая, а в комбайне все быстро, и сразу можно салат смешивать, хоть и не каждый. А в мультиварку загрузил продукты, поставил программу - и другим занимайся, а не помешивай да пробуй каждую минуту.
Быстрая нарезка в комбайне впечатление производила, так что начал стряпуха его использовать. Хотя и ворчала, что мало там ножей и терок, не получается как надо. Так и сказала представителю фирмы, который делал опрос потребителей. Тот заинтересовался, спросил, какие ножи добавить и та начала длинный список перечислять. Но когда тот поинтересовался, что не страшно ли, что тогда потребуется много места для хранения, сказала, что нет, так быть не должно, она уже со всеми инструментами много места занимает. Так и разошлись недовольные.
А молодая - присматривалась к стряпухе, чтобы ее рецепты перенять. Только вот готовить по ним, да при этом использовать новые инструменты, получалось плохо: тесто в комбайне не такое пышное выходило, некоторые салаты норовили в пюре превратиться. А с готовкой вообще сложно получалось: стряпуха добавляла ингридиенты последовательно, да еще помешивала и пробовала часто, а с мультиваркой так нельзя. Так что требовалось не просто сделать так же, а пробовать и адаптировать, понять. что можно положить вместе, а что - добавить потом и когда, все-таки один-два раза мультиварку открыть можно, только ненадолго и воды потом добавить - а то выходит она с паром. Постепенно успехи были - и с тестом, и с некоторыми блюдами.
Так и работали вместе. Во всяком случае, хозяева были довольны.
А при чем тут agile и менеджмент спросите Вы? А при том, что скрам и канбан - это современные инструменты управления IT-проектами. Которые сильно не похожи на ранее применявшиеся. И потому менеджеры, воспитанные в классической традиции, не спешат их осваивать, да и не так просто это. А в умелых руках - они эффективны, хотя, естественно, имеют свои ограничения и не обеспечивают весь спектр деятельности менеджера - как и любой инструмент. Но, что интересно, они настроены на те же ценности, что и классический менеджмент.
А рассказ - он не закончен. И хотя он из тех историй, в которых финал означает начало новой, в нынешнем текущем виде он совсем не завершен. Но я могу представить много финалов: с зародившимся сотрудничеством и без него, счастливых для обоих, или только для одной, или для обоих несчастных. А какой финал представили бы Вы? Напишите в комментариях. Или альтернативную историю, если это начало не вдохновляет, но метафора кажется удачной.
2013-03-30: AgileDays 2013 - между скрамом и будущим
Конференция AgileDays. Как всегда - на хорошем уровне, много общения и интерактива, живых докладов. Чувствуешь тренды отрасли, открываешь для себя полезные практики. Основных трендов два: разочарование в SCRUM-Канбан и gamification, о них далее. Мне они не так, чтоб нравились, но глупо обижаться на пейзаж за окном, и тем более на само окно, которое его показывает.
А сначала - пара слов о том, зачем я хожу на конференции. Живое общение позволяет реально увидеть и оценить тренды, соотнести между собой. А рассказы об использовании практик в реальных ситуациях, которые накладываются на твою, показывают неожиданные грани практик, о которых мог знать раньше, не предавая особого значения этому теоретическому знанию. А еще выключение из рабочего процесса и целенаправленное восприятие информации иногда производит инсайт, осознание или даже создание новых идей, которые ты решаешь претворять в практику почти немедленно.
Да, сама конференция - многолюдная. 667 участников, 54 доклада. Реально переполненные залы. Были косяки, но ко второму дню организаторы учли уроки, и, главное, организовали трансляцию из второго зала в холл, что позволило желающим слушать доклад хотя бы из-за двери. Как они шутили "fast fail у нас был - значит дальше будет хорошо".
И лично мне очень понравились блиц-доклады, по 15 минут в главном зале. Потому что когда время так сокращается, от доклада остается суть. И даже если она не очень актуальна, времени не так жалко. Так что я бы приветствовал этот формат и дальше.
А теперь - о трендах и обзор докладов, на которых я был.
2013-03-28: Как появляется PBL - Jeff Patton на AgileDays
Вчера и сегодня был на тренинге Джефа Паттона. Он рассказывал о том, откуда и каким образом получается самый важный артефакт SCRUM - Product Backlog, который является источником для всего остального. В описаниях процесса SCRUM об этом говорят реально мало, хотя практики известны. Джеф представил цельную конструкцию подходов к формированию продукта и его релизов, с фокусами ответственности и особым упором ценность продукта и user experience.
Хотя практические занятия были ориентированны именно на создание нового продукта, процесс и практики могут использоваться и при развитии продукта. Они сработают не только в продуктовой, но и в заказной и inhouse разработке - это я уже утверждаю из своего опыта. А еще - ряд из них, такие как сегментация и персонификация пользователей - может быть использована и при проектировании процессов разработки в компании.
А еще тренинг включал в себя обучение эффективным формам коллективной работы - collaboration. И, как сказал Джеф, "Collaboration - это не разговоры и обсуждения. Это - совместная работа, и желательно - молча."
Так что, хотя называется тренинг "Создание продуктов, которые полюбят ваши клиенты: Сертифицированный курс Product Owner", реально это - авторский тренинг, прочитанный звездой, как и тренинг Книберга два года назад. И я хочу сказать организаторам конференции спасибо за такие тренинги.
А я дальше не поленюсь и кратко раскрою содержание тренинга. К сожалению, кусок второго дня я пропустил, так что есть лакуны. Да. часть про SCRUM как сбалансированный процесс и agile как систему ценностей я опущу, потому что полагаю ее знакомой. Она не заняла много времени, но задала контекст для дальнейшего.
Замечу также, что изложение шло не с начала процесса и до конца, а от простого - к сложному. А наиболее сложной является формирование механизмов концептуальной части продукта - и именно они были ближе к концу тренинга, хотя при конструировании находятся ближе к началу процесса.
[ Хронологический вид ]Комментарии
А взглянуть на страницу результатов теста можно? Еще хотелось бы услышать ваше мнение о времени первого появления достаточно крупных цветовых сообществ.
В общем, не проблема, ниже вырезка из результатов в части спиральной динамики. А про появление цветовых сообществ - я не понял. Где, в каком объеме. Потому что есть сильная неравномерность - в общественной жизни, в науке, в бизнесе (деловом сообществе). Отдельные представители были всегда (ну, с античности), и они объединялись в какие-то кружки. То есть нужен более развернутый вопрос.
Ага, спасибо.
Ваши тексты мне нравятся, хотя тема тимбилдинга не близка.
Мне кажется, ваша профориентация (на бизнес) несколько деформирует общее видение картинки (бизнес таки оранжевый мем). В частности, видится ошибочным представление, что "уровень понимания" начинается с оранжа. О попытке "отождествления" оранжевых с желтым неплохо имхо сказано в этом эссе (и вообще замечательный текст): http://gregory.pp.ru/sd/main.html
О времени появления - ну вот тут примерно даны некоторые оценки: http://www.plot.su/other/166-spiral-dynamics.html
Мне эти оценки не нравятся. Считаю, что значимые проявления новых мемплексов связаны с качественными изменениями технологического развития общества. Эта мысль в отдельных материалах по СД проскальзывает, но конкретные точки перелома не описаны. Некоторые свои мысли (не слишком причесанные) по этой теме оформил тут, возможно, вам будет интересен еще один взгляд на модель: https://docs.google.com/document/d/11gJfUH7P2EIWslN848nVWeK138SSSaUCgJPAztKrxWc/pub
Ну и ссылку на страничку с результатами своего теста оставлю, тоже проходил его пару лет назад: http://www.jobeq.net/PPE/VSQ_UserFeedback.php?LANver=RU&XID=209897&TID=5464
зы Почему-то не получил уведомления о вашем ответе, хотя на комменты подписан.
Нет, если воспринимать бизнес как деятельность, то он есть на всех уровнях, при том разный. Я со времени поста, чтобы детальнее разобраться и как-то уложить свое понимание сделал пару докладов про спиральную динамику на ИТ-шных конференциях. И вроде как хорошо укладывается, что традиционный менеджмент (Друкер, Адизес) это красный + синий + оранжевый, и в жизненном цикле корпораций Адизеса эти составляющие хорошо видны. А текущее развитие менеджмента - Agile в ИТ - начинался как зеленый протест, ушел на желтый уровень, а сейчас пытаются строить бирюзовый, но успех пока не достигнут. Как статья это не оформлено, но тут Спиральная динамика - логика развития системы ценностей (Максим Цепков на AgileDays-2014) есть презентация и видео - если интересно.
И да, я окончательно пришел к выводу, что второй ярус начинается с оранжевого, но это - не "уровень понимания". вообще каждый уровень вносит что-то новое, что дальше сохраняется, это общий принцип. А ярус выделяется просто исходя из аналогии уровней. И поскольку сейчас движение общества уже хорошо видно, по сравнению со временем исследований Грейвса, то можно посмотреть на верхние уровни и сделать выводы про аналогию.
Да, эссе - смотрел, не понравилось - слишком поверхностно. И поэтому местами там, на мой взгляд, идет наклеивание ярлыков без достаточных оснований.
Вашу модель посмотрел, интересно. Во многом согласен. Но вот однозначное сопоставление уровней с формациями считаю неправильным, потому что надо расщеплять формацию на смесь деятельностей (государственное управление, общественное движение, бизнес, ...), переход по уровням переходит неравномерно и реально существует смесь. Когда же приписываешь уровень формации целиком, то это просто запутывает.
Про уведомления - я посмотрю. Возможно, чтобы они ходили, надо подтвердить адрес электронной почты, это в Настройках (придет письмо, кликнуть ссылку).
Английская статья "Spiral Dynamics" из википедии (http://en.wikipedia.org/wiki/Spiral_Dynamics) сейчас является перенаправлением на биографию Дона Бека. Оригинальную статью удалили 15.03.2015, а 10.08.2015 - сделали статью с перенаправлением. Основания для удаления - оценена как промо книги.
Я не нашел, как извлечь из википедии оригинальную статью, которую я читал в 2013, но archive.org все помнит. Я читал примерно вот это, а последняя версия перед удалением эта.
Я бы сказал, что логика очень странная. С другой стороны, на момент удаления в статье стало столько ссылок на книгу, что можно было так оценить, наверное. А в 2013 библиография была более сбалансирована.
Русский перевод тоже доступен только в архиве.
И, что интересно, эти изменения со статьей по Спиральной динамике - замена отдельной статьи на перенаправление на биографию Дона Бека произошли практически в момент смерти Криса Кована 15.07.2015. В в его некрологе рассказывается. в том числе, о расколе между соавторами книги.
Сохраняю для себя.
А это - ссылка на пост Макса Богуславского с впечатлениями о конференции, FB принес в ленте воспоминаний.
Есть книга-исследования "Введение в организации будущего" - Фредерик Лалу. Автор попытался найти работающие бирюзовые организации, и изучить их ценности и процессы изнутри. Некоторые организации в исследовании желтые, но некоторые и врпавду можно отнести к бирюзовым. Это к вопросу о переднем крае развития организаций
Большое спасибо! Я посмотрел ознакомительный фрагмент, купил электронную версию, буду читать. Для меня тут интересны не только механизмы управления внутри, но и масштаб и сложность достигаемых результатов и способ вписанности в экономику.
Тренинг не записывали, но кусочки техники ведения видны на видео доклада на сайте конференции или на youtube на 11 минуте (и на других тоже), а в начале доклада видна камера, подключенная к компу. В презентации кусочки 9-12 слайды, 88-91 слайды и еще разбросано внутри
Сохраняю ссылки.
История Денверского аэропорта - Демарко Том и Тимоти Листер "Вальсируя с медведями" Глава 3 .Пересмотр истории международного аэропорта в Денвере: здесь есть начало главы бесплатно, дальше просят денег за книгу.
Максим, интересно, что изменилось за 7 лет?
Изменилось довольно сильно, я как раз на РИТ вспоминал про этот пост в своем докладе про счастье на работе. Если в 2012 первый мир был в меньшинстве, хотя уже не был исключением, то теперь именно он - норма. И скепсис по отношению к нему со стороны второго мира сильно уменьшился. Выбор места работы поэтому происходит более сознательно. Третий мир в том виде, в котором был в 2012 - практически ушел в прошлое. Естественно, сейчас есть люди, которые прочитав этот пост говорят "понимаю, что я в третьем мире". Но при разборе фактуры оказывается, что условия все-таки сильно мягче. Идея штрафов за опоздание, например, воспринимается как явно нереалистичная, а тогда оно было.
Максим, поздравляю с выходом на новую платформу. Планируете ли прикрутить RSS-ленту, чтобы можно было удобно Вас читать?
Спасибо! А RSS-лента - есть, подписываться можно на Блог, на обновление отдельных Категорий и на все изменения (но все изменения - не слишком интересно). Правда, "из коробки" сделано не слишком удобно, кроме блогов.
Чтобы подписаться на изменение блога надо на странице блога (Блог:Максима Цепкова) нажать на значок Atom, который появляется в панели меню слева. А все остальное делается со страницы Свежие правки, тоже доступной из панели слева: по мере того, как фильтруешь запрашиваемый список правок, меняется url у значка Atom - получается нужная rss-лента.
Да, всё работает :)
Дополнение. Сейчас выложены все 8 частей, но, к сожалению, там уже pdf, а не rtf :(
Почти презентация, зато с задачами и упражнениями
К докладу "Слагаемые хорошего курса подготовки бизнес-аналитиков в среде Agile Scrum" попробовала собрать все по оценке БА на странице http://allbait.blogspot.com/2014/10/blog-post_47.html
Пост на FB - чтобы найти
Спасибо за интересное описание других докладов и хороший отзыв на мой! Я рад, что доклад был понят как описание "анти-догматичного процесса" - это действительно была одна из целей, о которых я думал при написании доклада. Любопытно, что про совместное использование обоих методов я говорил http://de.slideshare.net/AlexeiVinogradov/notestscases (слайд 17), и даже рекомендовал (в приемочном тестировании). И еще в самом конце (слайд 27) - говорил про то, что не призываю сломя голову использовать, я руководствоваться контекстом и учитывать особенности (там как раз не один Кэп, а сразу три на слайде:)). Я гляну еще, когда будет готово видео, потому что я это озвучивал голосом, на слайдах это может быть неоднозначно понятно.
Понятно. Значит момент про совместное использование я упустил. Поправлю.
А что учитывать особенности - это большинство докладчиков понимают и призывают, а слушатели почему-то часто воспринимают делай 1-2-3. Но я имел ввиду более подробное рассмотрение, для каких проектов и процессов такая замена разумна и в каком объеме, если такой опыт имеется, например, Вы пробовали в различных проектах и там оказалось несколько по-разному или на одном проекте границы нащупывали и двигали.
На совсем подробноее рассмотрение всего интересного не хватало времени доклада, но я тогда посчитаю эту фразу вопросом и отвечу в блоге, после того как вывесят видео. Такого рода вопросов есть уже много, это опять же радует. Сразу отмечу, что ответ не будет в стиле "это правильно, это неправильно", а будет описывать личный опыт и свои мысли по этому поводу и приглашать к дискуссии :).
Максим, спасибо за ссылку на книгу Левенчука! И за Ваш блог в целом.)
P.S. почему-то у меня не получилось зайти через OpenID аккаунт Google.
Максим, привет! Всегда приятно и интересно читать твои емкие обзоры. Спасибо.
Спасибо! А ты кто? А то по регистрации это нельзя понять.
К сожалению, сайт конференции gamefest.biz - был утрачен организаторами. На новом сайте конференции материалы и информация прошлых лет - отсутствует. Видео на сайте GameTrek http://gametrek.ru/archives/2175 - сохранилось.
Мне кажется что на эту тему надо смотреть шире, а именно попытаться понять почему принимается решение о взятии долга. Результаты разбора (статья, доклады) и много интересных ссылок можно посмотреть тут http://www.maxshulga.ru/search/label/техдолг. В том числе есть мнение, что не надо тратить время на отслеживание долга: http://swreflections.blogspot.ru/2015/02/dont-waste-time-tracking-technical-debt.html
Максим, спасибо за ссылки. А по отслеживанию долга все просто: любая практика (code review, парное программирование и другие) может быть уместной и лишней в конкретном проекте. Для нее надо понимать - какие цели мы через нее достигаем, являются ли они существенными и нельзя ли их достичь через более легкие практики.
Ссылки на материалы с обсуждения на Facebook
Алексей Шершнев опубликовал свою презентацию на встрече.
Массив схем развивается и можно посмотреть два текущих среза
Прочитав книгу Марка Розина "Успех без стратегии" добавил в набор схем типологию организаций 4F, тем более, что она сопрягается со Спиральной динамикой. Подробности Блог:Максима Цепкова/2016-08-01: Марк Розин "Успех без стратегии" как книга для бирюзовых организаций#Типология компаний 4F
В список не попали естественно-научные схемы устройства мира с соответствующим аппаратом рассуждений из математики и физики. Их наличие для меня очевидно, так что я не стал даже фиксировать. Сформировались в старшей школе, особенно математика - я уже тогда из интереса читал ВУЗовские материалы по матану и аналитической геометрии, решал задачки. А институт их расширил.
Навел фокус - Блог:Максима Цепкова/2018-01-09: Схемы, которыми я мыслю. Изменений немного.
Очередной фокус (2023-05).
При обсуждении мне рассказали, что в интегральной теории Уилбера, на которую тоже ссылается Лалу, различаются уровни teal, соответствующий желтому Спиральной динамике и turquoise, соответствующий бирюзовому. Среди российских специалистов по интегральной теории принято переводить teal как изумрудный.
Максим, добрый день. Большое спасибо за такое полное и структурированное изложение книги и идей Лалу.
Прочитала ее с большим удовольствием, но при этом не покидало странное ощущение, похожее на то, которое возникает при чтении различной эзотерической литературы - "прикольно, но разве так бывает?" :)
Встречали ли лично Вы в России организации, близкие по духу к "бирюзовым"? Есть ли среди них IT-компании?
Оксана, тут вопрос - насколько близкие. А главное - близкие по духу или по практике? Потому что наша компания по духу, по ценностям - достаточно близка, однако с практиками не экспериментирует, применяя наработанное в более ранней культуре.
На AgileDays-2013 был очень интересный рассказ Антона Волкова из «Танки онлайн» про эксперименты с их практиками, в 2014 он приезжал и в кулуарах рассказывал про развитие практик. На последней AgileDays был доклад Станислава Сажина "Зарплату мне назначают сотрудники" - там очень много близкой практики по самоорганизации. По частным разговорам я знаю, что в Киви двигаются в этом направлении. А в небольших ИТ-компаниях и стартапах такой дух вообще часто встречается, но по мере роста он может трансформироваться в разные стороны.
Про доклады можно почитать в моих отзывах на конференции Категория:Конференции
Максим, большое спасибо :) Обязательно почитаю. А вот про отрыв духа от практики - это интересно, неужели более традиционные практики не мешают ценностям более высокого уровня по спирали развития? А насколько практики Вашей организации более традиционные? Если говорить по классификации Лалу - они ближе к "зеленым" или еще более ранних уровней?
Нет, ближе к синим (по Спиральной динамике, по Лалу - янтарный) и оранжевым - классическая организованность. По спиральной динамике последующий уровень включает в себя предыдущие, так что если практики применять осмысленно и в уместном объеме, понимая их ограниченность, то они не мешают. Более того, отчасти становится проще, потому что внешний мир ждет от компании именно традиционного взаимодействия. Хотя есть опасность в том, что начнут работать стереотипы и осмысленность потеряется - это надо рефлексировать. При этом teal-практики agile в компании тоже есть и работают, так что организация смешанная.
Этот отзыв был снабжен иллюстрациями и опубликован на портале Спиральная динамика 21.06.2016.
Постом в Facebook об этой публикации: "Представляем вашему вниманию исключительно качественный конспект и блестящий анализ книги Фредерика Лалу от Максим Цепков" поделились более 30 раз. Мне запомнилась высокая оценка Максима Каленова "Кто слышал где-то про Лалу и разноцветные организации - найдите время прочитать анализ от Максим Цепков. ИМХО это лучшее дополнение к книге. Сильно снижает "миссионерское" настроение книги, чем переводит её в разряд полезных инструментов :)"
Добрый день, Максим. Прочел Ваши рефераты по книгам Розина и Лалу и появился вопрос. Бирюзовые организации отличаются от традиционных тремя вещами:
1) Социальная адаптивность - всякий может выбрать любое доступное ему занятие и роль.
2) Гибкость и самостоятельность решений - всякий может принять любое (в т.ч. и финансовое) решение, но существуют механизмы контроля: полная открытость информации, совет с теми кого это затронет, способы решения конфликтов.
3) Люди организованы не в процессную иерархию, а в набор более-менее самодостаточных команд.
И тут возникает проблема. Самоуправляемая команда может быть эффективнее многоступенчатой иерархии. Но увеличивая свою эффективность, самодостаточная команда рано или поздно придет к тому, что лучше генерировать доход себе, а не владельцу бизнеса. Противоречие эффективность/контролируемость традиционно решается в виде маятника централизации/децентрализации. А как насчет бирюзовых организаций?
На этот вопрос можно отвечать с нескольких точек зрения. Для начала, вот какой вопрос. Если самодостаточная команда может поставлять конечный продукт то чем. собственно, владелец бизнеса владеет? Каков его вклад? Если никакого - то команда замечательным образом уйдет. И это будет логично, вообще удивительно что она работала у какого-то там владельца. Но обычно владельцы бизнеса владеют какими-то конкретными вещами, которые у команды отсутствуют, и тем самым они нужны команде. То есть команда не является самодостаточной. Ну и достаточно часто маленькая команда не может выдать конечный продукт.
Опыт бирюзовых организаций показывает, что даже если на операционном уровне команды достаточно автономны, все равно есть аспекты, на которых сказывается эффект масштаба и для которых команда - слишком мала чтобы их осуществлять. Это касается инфраструктурных вещей типа бухгалтерии, юристов и управления финансами, хотя их можно аутсорсить в сервисные компании. И это касается развития бизнеса - обучения персонала, расширения сферы деятельности, и так далее - возникает внутреннее профессиональное сообщество и другие поддерживающие структуры. Роль центрального аппарата при этом сильно меняется. У Лалу это хорошо показано на кейсе медбратьейв Buurtzorg. Но я вижу примерно такие же вещи и в IT, хотя там много небольших компаний.
При этом жесткость границ организации действительно размывается, они становятся более подвижны и децентрализованы, их нельзя централизовать силой - однако в области разумной кооперации федерация сохраняется. Примерно так.
Можно попробовать рассмотреть это подробнее на кейсах.
И просьба - если можно, ссылку на Ваш профиль в соцсетях, хочется представлять, с кем я веду диалог.
Спасибо, теперь идея понятна. Ищутся не способы контроля, а построения культуры композиции долговременных интересов. При этом замковым камнем системы может быть что угодно: материальные активы, социальные связи, или даже умения фасилитации как у Семлера... ЗЫ. Давно хотел завести себе Фейсбук и, раз нашелся повод, то вот мой профиль https://www.facebook.com/and.kuzn
Да, именно так. Долговременные интересы для совместной деятельности, и кооперация вокруг них. При этом соблюдается автономность действующих агентов. особенно в принятии решений. А человек - вовлечен во много потоков такой деятельности. Это очень хорошо видно в холакратии с ее кругами.
Спасибо большое за статью, рекомендую ее моим студентам. Мы в Метаверситете какое-то время разглядываем спиральную динамику с разных сторон и даже положили ее в основу нескольких цепочек занятий. Все равно остается всегда много недоговоренного, и Ваша сборка дает хорошее целостное видение. Спасибо.
Рад, что оказалась полезной в образовании. А цепочка занятий по Спиральной динамике в Метаверситете - круто!
https://www.mann-ivanov-ferber.ru/books/otkryivaya-organizaczii-budushhego-illyustrirovannoe-puteshestvie - иллюстрированное издание для менеджеров и детей 8)
Да, видел эту книгу. Но внимательно с точки зрения содержания не разглядывал. Те, кто смотрели, говорят, что текст сохранен, только картинки добавлены. Получается развлекалка для тех, кто лонгриды не может осилить...
Facebook выдал в воспоминаниях фотку с конференции
Обнаружил, что забыл упомянуть интересный доклад Дмитрия Абрамова "Scrum не для всех. Люди, которые разрушат вашу команду" - о том, почему при начальном переходе на Scrum правильно расстаться с определенными типами людей, несмотря на профессионализм, для обеспечения перехода. При этом Дима подчеркивал, что после внедрения ценз снижается, потому что человек приходит уже в сложившуюся культуру.
Доклад станислава Сажина на сайте конференции, там же видео.
Для истории. Анонс 3 модуля был здесь. Помимо этих лекций есть достаточно много доступных лекций разных лет по этой же теме на сайте фонда Г.П. Щедровицкого http://www.fondgp.ru/lib/mmk/180
Для истории - пост в FB
Статья выложена у меня на сайте Проекты — для достижения результата, а не для освоения бюджета
Комментарий от Димы Безуглого при repost
Максим Цепков Опубликовал отличный обзор наших дискуссий и доклада на #AnalystDays. Часть комментариев на мой взгляд очень хорошо дополняют, то что прозвучало на докладе.
Однако он смягчил ряд тезисов.
Дальнейшее обсуждение читаем на FB.
Денис Бесков в комменте дал ссылку на русский перевод Александра Остервальде Построение бизнес-моделей. Я уже скачал с litres, читаю.
Схема переведена на английский с использованием оригинала из книги Бэкона Specialization of scientists by Francis Bacon
Осенью 2020 мне написал Yves-Michel Marti из The Baconian Company, что он нашел эту схему, она ему показалась интересной, и он хочет включить ее в статью для сборника (это анонс), который должен выйти в январе 2021. Позднее он прислал текст статьи «How Intelligence feeds Innovation. Merchants of Light of the Elizabethan Renaissance», принятый к публикации. В статье приведена эта схема и высоко оценена «An astute Russian researcher, Maxim Tsepkov, had the brilliant idea of describing the information processing process with process mapping software». Пользуясь случаем, я хочу поблагодарить Максима Осовского, который в свое время вдохновил меня на перевод.
Из комментариев Сергей Косовский: Огонь! Давно эта проблема у меня в голове висела! Спасибо за решение.
Из комментариев Эдуард Галиаскаров: Очень похожий подход я использую и студентам даю по use cases. А подсмотрел его у Арлоу и Нейдштадт в книге UML2 и унифицированный процесс. С другой стороны сам uml предлагает сворачивать каждый сценарий в отдельную деятельность.
Я: надо будет запомнить книгу
Еще обсуждения идут в группе Анализ в ИТ-проектах
Дополнение. При автоматизации важно предусмотреть в системе возможность зафиксировать результат разбора с кейсом-инцидентом. Например, если контрагент не согласен со стоимостью поставки и мы пошли на уступки - как это зафиксировать в системе? Это может быть отдельный документ о списании долга или возможность добавить скидку или изменить цену в старых накладных. Или если при проверке отчета обнаружена необходимость его исправить, при том, что документы нужным образом исправить нельзя. Впрочем, последний случай в принципе решается, если отчет можно экспортировать в Excel и исправить там - но хорошо бы, чтобы в системе оставались следы.
А регистрация и типизация инцидентов и автоматизация взаимодействия по ним - это уже следующий уровень.
Из поста на FB
В качестве ответа на статью Марк Мельник написал две статьи, в которых предлагаю термины, к которым мы более привычны: сценарий, типовой сценарий, рассматриваю ограничения нотации BPMN в моделировании сценариев. Там же я выдвигаю требования к ИС, которые хотелось бы видеть в реализации: https://habrahabr.ru/post/304242/ https://habrahabr.ru/post/305016/
Статьи интересные, мне понравились. На FB по ссылке можно посмотреть обсуждение.
Обсуждение на FB исторических примеров, которые я прописал весьма диагонально
Из комментов на FB
Игорь Беспальчук: Очевидное место исследований в ИТ - это исследования существующих продуктов, компонент, технологий. С целью изучения их свойств и границ возможностей.
Максим Цепков: Это интересная тема. Если быстро, то я подумал, что это получается как-то странно: изучаем отраслевой же искусственный мир. А потом вспомнил, что многие химические и фармацевтические компании изучают вновь синтезированные вещества для оценки потенциала применения в своей области. То есть получается цепочка R-D-R-D-...
Обсуждение на FB. Там несколько репостов, и в каждом - свои ветки дискуссий.
"По мере фокусировки на основном проекте семьи — рождении и воспитании детей, — будет происходить уже осознанная работа на желтом уровне и дальнейшее движение к бирюзовому во взаимодействии с новыми структурами образования." - самый спорный, на мой взгляд, пункт пересборок. Ибо самый базовый и самый мистический. Свыше показаны человечеству примеры "запрета", тормоза на размножение в истории нескольких тысячелетий и сотен поколений. Так что оптимистичная, на Ваш Максим взгляд, история не есть единственно верная из возможных историй. Хочется быть позитивистом, но здесь именно, в этом прогнозе мне предпочтительней осторожность. Моё предложение иметь выборку нескольких социальных уровней по этническому, социокультурному или территориальному признаку чтобы анализировать "пересборку семейного уклада", поскольку в этом вопросе однозначно присутствует функция фильтра и "за бортом" процессов останется колоссальное количество населения планеты.
Обсуждение на FB. В комментах есть интересная тема про вектора в сегменте малого бизнеса, я его не выделил отдельно, а, возможно, зря. И еще немного про blockchain
Сохраняю из комментариев facebook.
Елена Верещагина: Эх... не так страшен Agile, как эйфория вокруг него... https://vc.ru/p/agile-victims
С большим уважением отношусь к автору поста. Но не могу не заметить о странности противопоставления Agile и "всему остальному" опыту, накопленному в проектном управлении.
Успех того или иного проекта определяется, на мой взгляд, не сколько методологией, сколько профессионализмом участников, понятными целями и сыгранной командой. Разве не так?
И мой ответ.
Елена, к сожалению, статья тиражирует много ложных мифов. И, более того, пытается подкрепить их ложными фактами. Первое - о том, что Agile подходит только маленьким компаниям. Реально Agile подходит и большим компаниям, хотя с его внедрением есть определенные сложности (о которых я писал). Более того, Microsoft и IBM внедряют у себя Agile-подходы уже несколько лет. При чем начали это делать именно потому, что лишились лучших выпускников - они уходили в небольшие стартапы за той свободой самореализации и отсутствием регулирования, которое дает Agile. Далее, успех проектов по Agile в IT выше, чем успех проектов, сделанных в классической методологии. Хотя цифры для сложных проектов - невелики. При этом достигается кратно дешевле. Подробности можно посмотреть, например, в докладе Джефа Сазерленда на SECR-2011 (видео и презентация опубликованы) и в других источниках.
Один из известнейших провалов классической методологии - отсрочка запуска уже построенного нового Денверского аэропорта на полтора года (!) из-за того, что не смогли запустить софт управления доставкой багажа. И неудача американской системы страхования, на которую ссылается автор статьи - это тоже провал классического подхода, а не Agile. Ген.подрядчиком вроде был IBM, а разработка обошлась 1.7 млрд $, так что провал был впечатляющим. И именно после него Обама озверел и потребовал принять Agile-методологию как обязательную для ведения ИТ-проектов с для государства в штатах. Так что дело обстоит ровно наоборот, чем пытается представить автор статьи. Что касается классического проектного подхода, то о его провале говорит то, что начиная с 6 версии PMBoK авторы пытаются включить в стандарт Agile-подход. Получается печальная эклектика. Вот так.
Так что Agile не страшен, и за ним - будущее.
Елена
Максим, больше всего вокруг шумихи про Agile мне не нравится высокий эмоциональный тон дискуссии - в духе "кто не с нами - тот против нас". Вот и Вы не правы, утверждая, что автор говорит о неприменимости Agile к крупным компаниям, просто расставляет некоторые акценты - на что стоит обратить внимание.
Да и признаюсь, меня бы эта история не зацепила, если бы воочую не наблюдала провалы многих проектов и инициатив в ИТ (в основном, крупных компаний), связанных именно с "внедрением Agile".
Автор говорит о вполне конкретных вещах - необходимости интеграционного и регрессионого тестирования, об архитектурной целостности системы и т.п.
Там, где Agile внедряется - это как правило компромисс и микс, а не ортодоксальное отрицание накопленного опыта.
Методологии приходят и уходят, а инженерные практики остаются. На голом энтузиазме далеко не уедешь...
Как я знаю, многие ИТ специалисты, наевшись "гибких практик" ищут компании, где можно просто достойно делать свое дело, не гоняясь за всякими безумными нововведениями ради "красного словца" людей, которые делают на этом имя... Вопрос - правда, какое и для кого...
Мой ответ Дискуссии вокруг Agile могут быть с разным эмоциональным накалом, в зависимости от позиции участвующих. Так же как и все остальные дискуссии. Что касается данной статьи, то я указал на конкретные проблемы у автора приведенной статьи с пониманием темы и владением материалом. При том, что он позиционирует себя в качестве эксперта. Автор, с моей точки зрения, не расставляет акценты, а явно говорит о слабой применимости Agile. При том что в ряде крупных компаний он успешно используется. А статистика говорит о сравнительной успешности Agile-проектов. Провалы внедрения Agile, о которых я тоже знаю, связаны как раз со слабым профессионализмом тех, кто этим занимался. И это характерно не только для Agile, а для многих эффективных инструментов, ставших модными из-за своей эффективности - их пытаются внедрить не разобравшись.
И я отдельно хочу подчеркнуть, что Agile - это вовсе не энтузиазм, а как раз набор организационных и инженерных практик, которых в нем много. Включая интеграционное и регрессионное тестирование, которое автор почему-то выносит за пределы Agile. Ряд из практик Agile я перечислил, отвечая выше Екатерине Филатовой. И да, эти практики работают.
Ссылка на пост FB - репосты и обсуждения в комментах.
Историю про приписывание провала ObamaCare методологии Agile в статье на которую сослалась Елена Верещагина рассказал в группе GosAgile, которая началась чуть больше года назад с AgileKitchen в Аппарате правительства, на которой Асхат рассказывал, что провал сайта медицинских страховок инициировал как раз обязательное применение Agile вIT-проектах для государства в Штатах.
Коммент Дмитрий Синяев А пруфы привести сможете?
Просто обзор заметок по данной теме лично у меня сформировал следующее мнение (возможно ошибочное) 1. Когда при запуске начались проблемы, ряд СМИ написал, мол обгадились из-за того, что не использовали "современные подходы", то же New Yorker писал что вот Agile, Scrum.
Только вот потом другие порталы писали, что подрядчики по проекту (их было несколько), в частности, те кто пилил front-end и back-end использовали Agile. И что проблема глубже, а использование agile еще не гарантирует, что вы на проекте не обгадитесь.
ИМХО журналисты которые первыми написали, зарабатывали себе очков на неудачном запуске, не особо вникая в детали.
2. Что касается "послужила причиной перехода" - это тоже как-то не вяжется например с тем, что проекты по разработке ПО с использованием Agile реализовывались в 2012 году в FBI. А проблемный запуск Obamacare был в 2013 году. ИМХО параллельные активности, но консультанты Agile считают по-своему.
3. Для проекта, КМК, намного критичнее было, то что его республиканцы сливали, в сенате, в верховном суде и всячески вставляли палки в колеса, это в итоге привело к тому, что в 2014 году была проблема с согласованием бюджета.
4. Сейчас Трамп прикроет всю эту программу и тогда это будут просто выкинутые деньги на ветер, и будет не важно Waterfall, Agile или магия вуду использовались на проекте.
Мой ответ
Пруфы - легко. Тем более, что они есть в моем отчете с AgileKitchen http://mtsepkov.org/GosAgile-2015-11 Презентация Асхата http://www.slideshare.net/ScrumTrek/agile-55075828 История HealthCare.gov в вики https://en.wikipedia.org/wiki/HealthCare.gov, история US Digital Service на их сайте https://www.usds.gov/story
Из них видно, что фейл проекта произошел при запуске осенью 2013 года. Отдельные подрядчики могли работать как угодно, но в целом проект велся по классической водопадной технологии. Для меня достаточным признаком является обнаружение проблем с регистрацией практически перед запуском. Что означает отсутствие интеграционного тестирования, а возможно и вообще практики continuous integration в рамках проекта, и отсутствие итеративных поставок конечного продукта. То есть базовых практик Agile. Не говоря о многократном возрастании стоимости.
И поскольку облажались все регулирующие структуры, в которых, по-видимому, сидели апологеты проектного метода, то после этого фейла, в 2014, Обама организовал в составе аппарата Белого дома US Digital Service. Который занялся не только разработкой норм на ведение проектов, но и практической реанимацией HealthCare.gov.
А политика - она поверх этих технических фейлов наворачивалась, это производная. Как не валили проект в сенате, бюджет подрядчики освоили, шутка ли 1.7 млрд $ за сайт, пусть со сложным бэк-эндом.
Мое дополнение. Кстати, на той же AgileKitchen был интересный рассказ Марины Макарчук из Ростехнадзора - о том. что они уже два года перешли на Agile с 3-недельной поставкой релизов для своего основного комплеска из 17 подсистем. Чем избавились от конкретной боли. когда после очередного полугодового релиза всех подсистем 1-2 месяца шло утаптывание их интеграции в боевой конфигурации - при том, что установленные законом 2-недельные сроки для обработки Ростехнадзором обращений других организаций никто не отменял. Теперь все нормально. Правда, чтобы убедить подрядчика, который бsk сторонником классического подхода и уверял, что "Agile не работает" в таких проектах потребовалась эскалация до замминистра. Так вот, Agile работает.
Правда, мои ссылки Дмитрия не устроили, и там пошел разбор на тему качества и доказательности различных ссылок. Кому интересно - читайте, начиная отсюда
Для себя сохраню следующий собственный коммент
Печальный для сторонников классического проектного метода факт состоит в том, что проект разработки HelthCare.gov - государственный проект и он велся по тем методикам проектного управления, которые были приняты в США как стандарт. Там на эту тему есть регулирование. И блистательно провалился. И, более того, по результатам разбора и анализа этого кейса администрацией президента было принято решение не просто наказать виновных или изменить нормы, а создать отдельную организацию, не связанную с предыдущими, которая должна была построить новые нормы ведения IT-проектов. основанные на Agile. И именно этим она занималась как основной деятельностью, заодно работая по конкретным проектам.
Таким образом, провал ранее принятых стандартов проектного подхода был зафиксирован делом, а не словом.
Обсуждение в группе Бирюзовые организации продолжается.
Коммент Igor Panyuta Поддерживаю мнение Елены Верещаги. Во-первых, она практик и занимается реальным делом ежедневно. В вопросах IT её мнение для меня входит в пятёрку самых интересных. Наблюдаем ещё один пример перманентного конфликта между тем, кто делает и тем, кто учит. Воистину – “Кто умеет - тот делает, кто не умеет — тот учит” (Бернард Шоу). Подозрение вызывает уже сам по себе факт очередной активной шумихи. На этот раз это AGILE. Начинаешь разбираться и понимаешь, что по сути это один из инструментов в УП (Управлении Проектами) или PM (Product Management). Этих инструментов существует десятки и сотни. Почему вдруг один из них вдруг стал панацеей от всех бед? Это как если слесарь вдруг будет утверждать, что рожковый ключ на “17” самый главный и универсальный инструмент. И много он таким инструментом наработает? PM занимается не только IT. Круг использования инструментов PM достаточно широк и в бизнесе, и в быту. Во всех случаях инструментарий решения вопросов свой. Не представляю, как можно один единственный объявлять самым-самым? Если вернуться к аллегории со слесарем, то самыми универсальными инструментами являются молоток и зубило, древние и проверенные. Профессионализм связан со знанием как можно большего количества инструментов. Предлагать AGILE как универсальный инструмент? На все случаи жизни? Смешно, Максим. На мой взгляд, приведенная Еленой статья более объективная и взвешенная, упоминаются как достоинства, так и недостатки, ограничения AGILE. Доверия к приведенным фактам выше, чем к эмоциональным восторгам и опровержениям. Метафора с “Карнавальной ночью”? Всё это весело в кино или пока это тебя не касается лично в реальной жизни. А когда останавливается бизнес, останавливается денежный поток – это близко к катастрофе, а репутационные потери посчитать невозможно. Мой личный успешный опыт решения проблем в реализации проектов связан с высокой квалификацией исполнителей и здравомыслием, и никак не связан со знанием инструментария PM. ;-)
Мой ответ
Я тоже практик и занимаюсь реальным делом ежедневно. Коучингом и тренингами занимаются другие. Впрочем, у них - тоже реальное дело. А еще я вижу историю развития Agile и проектного менеджмента, и их взаимодействие. Так вот, в приведенной Еленой статье видно отсутствие владения фактическим материалом человеком, который полагает себя экспертом. И приписывание Agile тех недостатков, которыми он не обладает. Автор почему-то уверен, что практики тестирования в Agile отсутствуют. При этом все провалы из-за поставки некачественного ПО списывает на использование Agile-методов, не потрудившись разобраться. Особо ярким примером выступает история ObamaCare, проблемы с которой автор приписывает методологии Agile, в то время как проект велся именно по классической методологии проектного управления. А провал его осенью 2013 инициировал создание весной 2014 отдельного US Digital Service в аппарате президента, которое начало вводить нормы Agile для ведения IT-проекта и разбираться конкретно с проблемами проекта сайта страховок. Подробности можно прочитать https://en.wikipedia.org/wiki/HealthCare.gov и https://www.usds.gov/story
Далее, именно значительные успехи Agile, которые было невозможно игнорировать привели к тому, что держатели PMBOK были вынуждены включить эти практики в версию PMBOK-4 в 2008. Получилась эклектика. Впрочем, развитие идет, и стандарты подтягиваются вслед за практикой. А практика развивается в рамках Agile. При этом накопленный опыт прошлого - осмысляется и включается. Хотя держатели старых стандартов пытаются представить процесс другим образом - дескать, это Agile - лишь один из инструментов. Так что нет никакой панацеи. Есть разнообразно развивающееся, создающее практики новое - Agile, и есть старое, традиционное которое на это новое заглядывает и передовые практики оттуда забирает когда игнорировать становится невозможно. Нормальная эволюция.
А еще было конструктивное обсуждение с Екатериной Филатовой, с интересными ссылками на ролики.
Вопрос Екатерины подскажите, пожалуйста, где можно прочитать про принципы agile в более прикладном варианте? какая у него автоматизация, механизмы взаимодействия. Аллегория мне понятно - хотелось бы про механику прочитать (у меня IT проект)
Мой ответ тут вопрос сложный, в том смысле что ответ - очень объемный. Agile - это зонтичная конструкция, зонтиком являются ценности и принципы, сформулированные в Agile Manifesto http://agilemanifesto.org (там есть вариант на русском). Под этим зонтиком собираются многие методы, наиболее известные из которых - Scrum и Kanban, есть еще их комбинация Scrumban, Lean и другие. Про Scrum надо читать Сазерленда "Scrum - революционный метод управления проектами", хорошая для ознакомления (но старая, это надо учитывать) книга Книберга "Скрам из окопов" (Scrum from the Trenches), про Lean - "Lean Software Development" Мэри Поппендик. При этом, если говорить про IT-проекты, то к организационным методам надо добавлять технические - DDD, FDD, TDD, BDD, Continuous Integration и Continuous Delivery и многие другие. Автоматизируется все это в любом современном таск-трекере - Jira, TFS, есть специализированные инструменты для ведения досок, коллективной работы и много других. Потому что Agile в IT на западе - просто стандарт. При этом какие именно методы применять - сильно зависит от специфики вашего проекта. Для разных проектов подходят разные методы. Если Вы расскажете, я могу посоветовать подробнее. Можно здесь или в переписке.
Екатерина Про скрам и иже с ними знакома давно, а вот про DDD и прочими "DD" пока не понимаю их расшифровки) Про Agile нашла уже занятное видео, которое отвечает на мой вопрос. может быть будет интересно - делюсь. видео Про DDD можете расшифровку дать?
Еще видео
Мой ответ Первый ролик посмотрел, там понятная организационная конструкция в целом в рамках Agile (при условии, что механизмы, применяемые лидерами профессии и главой племени им соответствуют). Но пока эта конструкция - без организации процессов внутри, в рамках нее можно запускать Scrum или Kanban или другой вариант процесса, в зависимости от характера потока задач. Расшифровка xDD - Domain Driven Design, Feature Driven Development, Test Driven Development, Behavior Driven Development. И это далеко не полный список. А еще есть детальные практики, например. эталонный Scrum предполагает использование user story, однако они могут быть заменены на use case, если это уместно.
Второй ролик - это Книберг, один из мировых гуру, в переводе Вольфсона, который один из экспертов-практиков у нас. По книге Книберга я в 2008 знакомился с Scrum, а позднее - был на его тренинге. В ролике - классный ликбез и основы для знакомства с Agile. И от этого можно отталкиваться.
Продолжение обсуждения в комментариях на FB. Для меня много ценного, различные точки зрения. Сохраняю и для себя и для других читателей.
Комментарий Екатерина Филатова Все разговоры и непонимание происходит из-за того, что каждый по-своему видит Agile... Кто-то знает, что это манифест с 4-мя пунктами, а кто-то видит в этом целый инструмент. На сколько я понимаю, Agile - это религия) Люди знают, что убивать опасно, но им нужны были 10 заповедей. Мы все давно работаем по agile и вот только сейчас узнаём, как этот зверь называется)) (я про себя) теперь могу форсить, рассказывая "невеждам" про "Эджайл" )) Предполагаю, что ваши различия во мнениях имеют общую правду в корне, в глубине души.
Мой ответ Если б люди добирались до ценностей манифеста (которых 4) и принципов (их еще 12)... У очень многих цепочка рассуждений обрывается гораздо раньше: "непривычное -> много говорят -> фуфло" или "непривычное -> много говорят -> не для меня -> рационализируем". А потом другие читают подобную рационализацию, как в приведенной выше статье и получают подтверждение своей оценке. То есть срабатывает стереотип, отвергая непривычное. В принципе, хороший стереотип, позволяющий быстро принимать решения, особенно в современном мире.заполненном рекламой и информационным шумом. Только надо уметь во-время от него отказываться, чтобы не оказаться в прошлом. И начинать разбираться самому. А это было тяжело во все времена, люди часто глухи к новому. И, что интересно, даже реакция Грефа, который поглубже посмотрев на Agile почувствовал себя лузером(!) стереотипы многих людей не пробивает. Они ж лучше знают :) Вот так.
Так что правда - она есть, но не все включают ум, чтобы до нее докопаться.
Екатерина Филатова Максим Цепков )) у меня дилемма)) вы говорите справедливо, но я не понимаю, зачем вы это говорите. Всё правда.
Мой ответ Я это говорю чтобы побудить и автора комментария и, главное, читателей разобраться в Agile глубже, а не поверхностно отвергнуть непривычное.
Agile - это не религия. Это набор ценностей, позволяющих сотрудничать с миром и приносить ему пользу, и набор методов, способов и инструментов, позволяющих это сделать - первоначально в области IT, но сейчас это расширяется. Познакомившись с ними и начав применять можно работать лучше. Естественно, выбирая конкретные инструменты из большого набора, подходящие для конкретной задачи.
Екатерина Филатова Максим Цепков теперь поняла. Мне свойственно иронизровать. Иногда это приводит в замешательство. Религия - это метафора. Сам по себе "эджайл" не инструмент. Инструменты внутри этой красивой коробочки, как 10 заповедей внутри религии.. мы опять же говорим об одном и том же, но под разным углом. Мне метафора про карнавальную ночь понравилась. Она иллюстрирует эджайл.
Мой ответ Понятно. Просто сравнение Agile с религией я слышал от многих с негативными коннотациями - как тотальную догматичность мышления его сторонников. Догматичные сторонники, конечно, тоже встречаются. как у любой идеи, но их немного. Но к подобным сравнениям я поэтому отношусь настороженно. А мы с Вами действительно во многом говорим об одном и том же. И рад, что понравилась метафора.
И еще один содержательный тред комментариев Елена Верещага 25-28.12 (перенесено позже)
Максим, спасибо за столь подробный ответ на мой комментарий.
Признаюсь я несколько “утонула” в том объеме информации, которую Вы вытащили на поверхность данного контекста ))
Прежде всего, хочу сказать, что при углублении в тему - вижу довольно много общих точек соприкосновения - мысли, что Вы излагаете, мне также созвучны. И в этом права также Екатерина, которая заметила, что часто мы по-разному понимаем нечто или напротив - разными словами называем одно и то же.
Какие высказанные Вами идеи мне созвучны:
Далее под этим комментом я напишу еще несколько мыслей - в продолжение
С некоторыми суждениями я готова поспорить:
Максим, в любом случае, спасибо за Ваше неравнодушие, а также за стимуляцию лично моего развития в теме - Вы подняли достаточно большой пласт информации, куда стоит посмотреть.
Было бы интересно продолжить разговор предметно - разбирая конкретную практику из арсенала Agile и где она хорошо применяется, какие могут быть проблемы и почему.
Также замечу, что мы похоже, вышли за пределы круга Agile - все-таки не все *DD имеют к нему непосредственное отношение. По кр.мере, для меня эта связь на данный момент не очевидна.
Максим Цепков Елена, я очень рад, что мои комменты вызвали такой отклик. По пунктам, которые вы затронули в комментарии, я отвечу детально (только уже завтра), потому что их интересно разобрать конкретно. Но если говорить в общем, то у нас различается взгляд на логику развития ведения IT-проектов, которая породила Agile.
В Вашей логике Agile - преимущественно организационные практики (хотя не только они), которые родились как развитие проектных практик PMBOK и по мере вызревания были в него втянуты.
С моей точки зрения, Agile возник наоборот, как резкое отрицание PMBOK и вообще процессного подхода (который достаточно ярко проявился в RUP). Отрицание начал еще Том ДеМарко в 1987 "Человеческий фактор", и оно очень ярко выражено в первой редакции книги Бека Extreme Programming и Agile-манифесте, который как раз декларирует иные ценности. Далее он развивался, порождая собственные способы IT-разработки (Scrum - первый массово успешный из них), в том числе, используя ранее наработанные практики как источник идей, но сильно адаптируя их к собственным ценностям - в соответствии с диалектикой развития "тезис-антитезис-синтез". А когда успех стал очевиден - пошел еще обратный вектор.
При этом ряд людей восприняли Agile в конструкции ярко выраженного отрицания классического подхода и до сих пор это высказывают, возражая против синтеза.
Характерно, что наши различия во взглядах, как я вижу, больше касаются именно представлений о логике развития, а вовсе не взгляда на идеальное представление об IT-разработке, которое у нас обоих синтетично включает множество практик.
Елена Верещага Максим, спасибо за интересную дискуссию! Буду ждать Ваших детальных комментариев. А "свою историю" про Agile я напишу позже - уже видимо, послезавтра ))
Максим Цепков Елена Верещага Отвечаю по пунктам, как обещал.
1. Про Agile и PMBOK я уже написал в своем комментарии, они противопоставлены логикой развития, и тем, что для нас целое - Agile, втянувший лучшие практики классического подхода, или наоборот, классические подход, втянувший (с моей точки зрения - лишь попытавшийся) втянуть лучшие практики Agile. Для меня Agile и классика - это разные mindset, конструкции устройства мира. При этом я понимаю и могу рассуждать в обоих, но Agile считаю следующим этапом развития.
2. Долгосрочное планирование является проблемным независимо от Agile, про это есть множество исследований. И интеграционное взаимодействие тоже. Так что "а у нас Agile" - это просто очередная причина. Если смотреть глубоко, то Agile утверждает следующее: (а) долгосрочное планирование не должно быть фетишем; (б) трезво оценивайте свою способность к реалистичному планированию. И дальше как практический способ - держите product backlog на том горизонте, на котором можете, на коротком горизонте (1-3 месяца) он должен быть конкретным и пригодным для детального планирования спринта, а на длинном (полгода и более) - достаточно детальным для представлений о развитии продукта. Сроки - ориентировочные. В обучение Product Owner'а это входит (правда, я проходил тренинг Jeff Patton, он гуру, говорят, все бывает по-разному).
Что касается интеграции. в том числе от разных подрядчиков. то как только Заказчик жестко требует 2-3 недельного периода выпуска обновлений на пром, подрядчикам просто некуда деваться от налаживания интеграционного тестирования. На эту тему есть характерный кейс Ростехнадзора (там подрядчик у 17 подсистем был один, но команды разные). Классический выпуск приводил к тому, что после релиза раз в полгода комплекс 1-2 месяца приводили в чувство, а трехнедельные релизы это устранили. Кейсу уже 4 года, Заказчик счастлив. Подробности можно посмотреть http://mtsepkov.org/GosAgile-2015-11 (рассказывала Марина Макарчук, она - Заказчик).
Подводя итоги: трудности есть, но они не в методах, а в головах. Метод как раз жестко нацелен на то, чтобы проблемы были решены, ты не можешь выдать DoD "мы внедрили метод", не решив эти проблемы.
3. Я тут посмотрел автора поглубже. Если пойти на сайт компании, где автор - CEO, то компания ПРОДАЕТ Agile и DevOps крупным заказчикам. Либо автор продает то, во что не верит, либо журналист исказил его мысли до неузнаваемости. И получается. что к статье нельзя относиться, как к мнению эксперта. При этом, помимо CEO в компании два человека "старой школы"...
Конечно, Agile проще внедрять в маленьких компаниях, но это - вообще тривиальная мысль. Что, скажите, сложнее делать в маленьких компаниях. чем в больших? Разве что вести себя деструктивно и насаждать бюрократию :) Так что эта мысль не стоит большой статьи. Автор-то при этом ничего не пишет про то, как в больших компаниях это делать. А за развитие Agile тут наработаны практики и методы, например, SAF.
Xто касается "инноваций раде инноваций", то мы тут недавно обсуждали это дело, и возникла гипотеза, похожая на правду, что ряд менеджеров внедряет новое как приобретает новые гаджеты - все надо попробовать. При этом еще есть исследования, которые показывают. что регулярные изменения для компаний в целом очень полезны :)
4. Continuous Integration, на мой взгляд, must уже 10+ лет (хотя я понимаю, что есть реликты), с delivery сильно сложнее. Тем не менее, есть крупные компании (например, badoo), где это реально применяется. Есть много разных практик, как это делать, в том числе для разных сложных проектов. Включая DWH, такие рассказы я тоже слышал. Фишка в том, что при непрерывной поставки мы делаем малый квант изменений, который проверить и даже исправить гораздо проще, чем большой. И в некоторых компаниях именно так и делают. Если интересно, можно обсуждать уже технические задачи, опыт организации обновлений при том, что работа идет с большими массивами данных у меня есть.
5. Неправильно выстроенные процессы и отсутствие головы у тех, кто их выстраивал приводят к большим проблемам независимо от того, по какой методологии это все делается. А крики про то, что нельзя оперировать сроками больше 2 недель свидетельствуют лишь о незнании предмета кричащими.
На самом деле, в Agile есть довольно много практик работы с требованиями. Userstory с планированием релизов по MVP. Use case, как альтернативный вариант, при чем он не так давно был довольно интересно адаптирован Якобсоном для гибкого планирования (UseCase 2.0). Domain Driven Design для корпоративной разработки. Сложная архитектурная работа в SAF.
B при этом есть отдельные практики. касающиеся того. как предотвратить необоснованные метания, но сохранить требуемую гибкость. Ведь основная-то проблем - именно в тоем, что характерный временной лаг изменений бизнеса во многих областях - 2-4 недели. И IT должно успевать, иначе оно становится ограничением для бизнеса. Такой сейчас мир.
Елена Верещага Максим Цепков , спасибо! Как всегда - детально и обстоятельно.
Позже соберусь - и тоже приведу примеры.. А сейчас за неимением времени отвечу коротко.
В моем понимании "чистых методологий" не существует - ни Agile, ни RUP не внедряется в чистом виде - а "пилится под себя". То, что развитие состоит в том, что отрицаются некие предыдущие подходы - да, в этом собственно оно и состоит. Но никогда я не видела внедрение какой-то методологии "из коробки". А всякие попытки сохранить "чистоту подхода" как раз и приводят с высокой вероятностью к провалу. Однако соглашусь с Вами, что есть ключевые принципы - и их надо придерживаться - ради чего это и затевается (нужно понимать - какая проблема прежнего подхода решается и за счет чего). Вот тут как раз хотелось бы остановиться подробнее. Но не в этот раз ))
И в чем, мне кажется, мы с Вами сходимся, но как бы с разных сторон - это в том, что во многом все зависит от специалистов, применяющих метод, нежели от самой методологии. В хороших руках любая методология будет "жить". Проблемы провалов связаны как правило, не с методом ведения проекта - а как оно делается.
Долгосрочное планирование - всегда сложность и искусство. Проблема в том, что многие с криками "у нас Agile" на это забивают. Действительно - зачем, раз так сложно? Проще с шашками.
И поймите - я не против Agile. Я за! )) Я прекрасно вижу ограничения того же RUP. Там есть хорошие идеи и в этом есть развитие. НО! Меня коробит, когда это романтизируется, охватывается ореолом "инновационности" и преподносится как "серебряная пуля". К тому же он вовсе не в-новинку - об eXtreme Programming заговорили (а кое-где и внедрили, правда те еще приколы были) более 10 лет назад...
В любом случае - продолжаем беседу... Обменяться живым опытом (как + , так и -) всегда интересно! ))
Максим Цепков Про внедрение методологий подход классики (RUP, PMBOK) и Agile тоже кардинально отличается. Классика говорит - возьмите исчерпывающий многостраничный guide, вычеркните ненужное и используйте. Agile говорит другое - возьмите простой метод "из коробки" - Scrum, Kanban, внедрите "как есть", а потом - запустить совершенствование, точки, где это происходит процессно встроены в метод (ретро). При совершенствовании - используйте набор практик как готовый, а не подходит - придумывайте свое. Но при этом есть иерархия сверху-вниз, от ценностей и принципов к конкретным практикам, и трассировку надо сохранять.
В инновационности и романтике надо разбираться более конкретно - потому что в чем-то она есть, а в чем-то - нет. XP и Scrum появились 15 лет назад, но при этом продолжают развиваться, а применение Scrum вне IT, что сейчас делают - является определенной инновацией. То есть надо работать прагматично.
А те, кто продает серебряные пули и светлое будущее - они были, есть и будут, и будут продавать все новое, вернее, все КАК новое. Их породил маркетинг начала 20 века. Это не проблема Agile, это особенность развития современного мира. А он - таков как есть, другого у нас нет, живем в этом.
И да, продолжаем беседу!
Я, оказывается не рассказывал в блоге про песни, только в ЖЖ и на facebook. А было вот как. Когда я слушаю некоторые песни - то у меня в голове разворачивается цепочка образов. И у меня была давняя мечта - чтобы эти образы появились в виде мультика, стали доступны. На встрече ПИР, благодаря вечерним посиделкам с песнями под гитару и рояль, скрайбинг-летописи ПиРа, общению с Сергеем Гевличем, автором объясняшек, у меня сложилась мозаика и я понял, что технология, с помощью которой я могу осуществить свою давнюю мечту - увидеть мультики по некоторым песням - готова. Интересно, что про [http:xplainto.me объясняшки] я знал уже несколько лет, но вот все вместе сложилось только на ПиР.
Первая песня, которую я выбрал - "Дракон" Суханова. Я написал Сергею, он порекомендовал Елену Смирнову, художника - и получился прекрасный мультик. Я его выложил на youtube и рассказал об этом в ЖЖ и на facebook.
Думал, потом будет перерыв. Нет. Идея следующей песни пришла почти сразу и результат вы видели. Сохраняю тут ссылки youtube,ЖЖ, facebook. В процессе работы был альтернативный вариант, на совсем другое исполнение - Никитин и К, несколько голосов. Елена его тоже дорисовала.
Главная фишка состоит в том, что технология объясняшек - дешевая и общедоступная. Программа создавалась не как профессиональный инструмент для мультиков, а как широко доступный инструмент видеопрезентаций. Он такой получился, я сам видел, как ролики в нем делаются за пару часов, правда сначала надо придумать сюжет и текст, на это тоже пара часов уходит. И он доступен - я знаю, что некоторые учителя обучают детей на факультативах, и те дальше используют его как форму сдачи докладов и других школьных тематических работ. Так что мультик, получается, может нарисовать каждый. Правда, iPad нужен, но это не очень большая редкость.
А теперь - Дракон.
Публикация в FB вызвала довольно много репостов. В публикации в группе AgileRussia было интересное обсуждение - Алексеей Пименов, Слава Цирульник, Tony Granton, Владимир Каленов, Сергей Баранов.
Из отзывов ведущих
Запись видео
Войдите, чтобы комментировать.