Викилоги

Facebook напомнил, что то представление об #Agile, которое я даю в нынешних лекциях и докладах, например, на лекции во ВШЭ http://mtsepkov.org/Agile-HSE-2018 я впервые сформулировал 6 лет назад после AgileDays-2012 в статье, опубликованной на портале SoftwarePeople. Указанная в посте ссылка на статью сейчас не работает, но статья доступна на моем сайте Agile как IT-форма современного менеджмента В общем-то, интересно сравнить свое существующее понимание с тем, старым, и осознать, что концепт изменился не сильно, но появились новые основания и более глубокое понимание.

Прошла очередная, уже 12 конференция #AgileDays. Как и прошлые конференции, она позволяет составить релевантное представление о жизни Agile-сообщества России, которое за последние пару лет характеризуется мощным развитием, и продвижением за пределы IT-отрасли, включая использование Agile для организации работы госорганизаций, освоение практик бирюзовых организаций, а так же мощное освоение soft skill. Об этом свидетельствует и более 1500 участников конференции.

Но, вместе с тем, на ряде докладов возникает стойкое ощущение де жа вю: тебе рассказывают про поиски пути и решение проблем, о которых ты слышал 5 и более лет назад на прошлых конференциях. И проблемы эти часто связаны с неверным или неполным пониманием agile-фреймворков. Например, с отказом от роли Scrum Master и возлаганием его функций на Product Owner, становящихся очень похожих на продуктовых менеджеров. С понятным результатом: в одних командах проваливается продуктовый фокус, другие - не могут соорганизоваться, третьим - везет, они оказываются слаженные, а PO держит продуктовый фокус. В общем-то все эти результаты можно было предсказать, а не неожиданно обнаруживать...

Хорошая новость - в том, что команды успешно справляются с этим проблемами, о чем и были рассказы в докладах. Но при этом справляются - за счет эмпирических поисков решения, а не за счет опоры на прошлый опыт Agile-сообщества и теоретического знания, которое имеется. И, наверняка преодолеть проблемы получается далеко не у всех - просто те, кто не смог - не выступают на конференциях, а рассказывают, что "Agile не работает".

И здесь надо отметить, что в принципе такая ситуация закономерна в период ажиотажного спроса на новые технологии - а с технологиями Agile мы сейчас имеем именно такую ситуацию. И она связана не только с рекламным hipe, модой и поисками волшебной таблетки, она объективна, поскольку вызовы, приведшие к возникновению Agile в IT идут в другие отрасли. Впрочем, об этом можно прочесть в моей статье Agile - ответ на вызовы нового мира, а здесь я не буду углубляться в тему.

Я лишь отмечу, что такая же ситуация возникает не только в управленческих технологиях - с техническими технологиями ситуация обстоит ровно так же, как было, когда всем компаниям резко потребовались сайты, или мобильные приложения, или интуитивно-понятный интерфейс: профессионализм резко падал и вместо теоретически обоснованных решений приходила эмпирика, которую каждый разработчик накапливал как мог. Но, впрочем, тут необходимо отметить, что в технических аспектах проблема осознана и преодолевается - за счет форумов, общения в профессиональных сообществах, евангилизма новых технологий и многих других инструментах. А в Agile-сообществе по-прежнему практикуются лишь более традиционные формы распространения знаний - тренинги и наставничество, сертификация и стандартизация, на которой и сосредоточен фокус многих институтов распространения Agile. А ведь это все формы - из прошлого, и они плохо работают в новом мире.

Впрочем, думаю, по мере роста разнообразия ситуаций применения Agile, все более будет приходить такое же отношение к управленческому фреймворку, которое присуще техническим фремворкам, когда у тебя есть целостная функциональная структура, узлы которой ты заполняешь элеметами конструкции, реализующими эти функции, заботясь о сопряжении соседних элементов, а не изменяя элементы абы как, с образованием функциональных дыр. Тем более, что уже есть формализм, ориентированный на такой подход - OMG Essence.

А теперь вернемся к конференции. Ее содержание не ограничивалось упомянутыми выше докладами о поиске пути. Было очень много крутых докладов, из которых мне особенно хочется упомянуть два.

• Первый - рассказ о применении Канбана в Центральном банке, при чем не в IT, а в функциональном подразделении. Очень по делу, с крутыми фишками по организации Kanban-доски, и ясным пониманием решаемых задач, и представлении о достигаемом эффекте. Agile-методы тут выступают как средство, и их внедряют для более эффективной работы, а не для отчета.
• Второй - рассказ Павла Рабиновича о применении Agile в школе для организации уроков. Который вписан в существующее нормативное регулирование школ - оказывается, оно нормирует результат и форму его проверки, а не процесс, который вполне можно перестроить. И особенно импонирует целевая аудитория: речь идет не об элитных школах, действие развертывается в рядовых подмосковных школах, а эффект измеряется из сравнения успеваемости того же класса с тем же учителем при старой организации и при новой - при том, что успеваемость проверяется теми же самыми контрольными работами, они не реорганизуются, потому что являются нормативно определенной формой контроля результата.
• А еще был замечательный доклад Александра Горника о бирюзовой организации MindBox с открытыми зарплатами, раскрывающий способы самоуправления, и путь, которым они постепенно шли к открытым зарплатам, выравнивая перекосы.

На этом я, пожалуй, закончу обзор, и далее соберу те посты на FB, которые я делал на самой конференции. Как обычно, хочу отметить, что я слушал, наверное, 1/8 от общего числа докладов, во-первых, потому что параллельно шло 5 треков конференции и можно было быть только на одном, а, во-вторых, главное на конференции, все-таки, не доклады, а общение, которого у меня было очень много. И на часть интересных докладов я не пошел, потому что на других конференциях уже слышал примерно об этом и предпочел неизвестное. А доклады можно послушать потом, в записи. Хотя, надо отметить, ыто уже несколько лет ScrumTrek ленится и обрабатывает только лучшие доклады конференции, а не все. Это, на мой взгляд, - неправильно, потому что выбирая между докладами на конференции, где часто параллельно идет несколько интересных докладов, ты рискуешь не услышать нужного тебе. Я надеюсь, что все-таки вернется практика выкладывания всех докладов.

Да, на конференции, как это сейчас распространено, вели скрайбинг докладов и пару фоток я здесь публикую. Многие из них вызвали интересное обсуждение на FB, так что стоит сходить по ссылкам.

→ продолжить чтение…

Прошел двенадцатый IT Global Meetup - очередная встреча IT-сообществ Санкт-Петербурга. Помещение, в котором проводили расширилось, добавился еще один зал - и потому участников было больше, чем в прошлые разы - 850 участников. Было много интересны докладов, и очень много общения. Дальше - мои впечатления о докладах.

Доклад "Blockchain для корпоративных решений: варианты применения" - хороший концептуальный обзор технологии blockchain - общие составляющие (распределенность, блоки, транзакции и др.), точки вариации - алгоритмы консенсуса (ресурсные и голосовательные в разных вариантах) и содержание транзакции, смарт-контракты как транзакции, содержащие вызов кода, который тоже хранится в системе и варианты версионирования и сохранения данных в реализациях. И платформы (hyperledger, ethereum, finchain), которые дают готовые реализации и позволяют строить свои в разных вариантах. С преимуществами, проблемами и примерами применений. На мой взгляд, если представить учебник по blockchain, то в докладе - введение в каждую из глав. При этом учебника по blockchain - нет, потому что технология развивается и учебник непрерывно дописывается. И в этом смысл доклада - он позволяет в целом, в контексте твоего проекта понять - стоит посмотреть на применение blockchain в конкретном варианте для них, наряду с другими, или смысла нет. Естественно, об этом есть статьи, могут быть альтернативные способы знакомства. Но мне доклады на конференциях нравятся больше. Спасибо Александр Урмазов (если я верно записал имя, в программе нет :( )

Ping yourself Ирина Матвеева на островке СПб СоА (Сообщество аналитиков Санкт-Петербурга) - работа по рефлексивному самоопределению по пирамиде Дилтса, индивидуально, с обсуждением в парах и группах. Это как раз к вопросу об уровне самосознания IT-шников - работа со специальными инструментами soft skill на уровне рядовых сотрудников. А я, заглянув на это выступление, соотнес для себя пирамиду Дилтса со схемой самоопределения Щедровицкого, о которой рассказывал прошлой весной на #sqadays и недавно на #teamleadconf, и которую мы будем обсуждать с Алексей Фёдоров на островке тестировщиков позднее. А еще эти активности показывают профит #itgm как точку кооперации сообществ - Ирина из IT HR, и ее позвали к аналитикам.

На #itgm был очень интересный трек SPB SQA Group. У него была сквозная тема - разделение труда в тестировании, и доклады и обсуждения нанизывались на эту тему. Я был только на последнем слоте, где мы вели обсуждение про схемы самоопределения, но открывая слот Алексей Фёдоров повторил для всех, включая вновь пришедших, содержание предыдущих серий - углубление специализаций, выделение отдельных, подвижность границ между тестировщиками и смежными специализациями - разработчиками, менеджерами, аналитиками. И потом как раз перешел к теме слота - схемам, которые помогают в этом самоопределиться.

Из доклада Как строить свой профессиональный путь - схемы самоопределения (TeamLeadConf-2018)

Из доклада Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять (SQAdays-20, 2016-11)

И началось все как раз с определения тестирования, которое я нарисовал на V-диаграмме - между разработкой и эксплуатацией, и тоже с подвижными границами. И тут же был пойман на несоответствии современным практикам, включающим тестирование требований, тестирование дизайна и другие подобные вещи, которые на V-диаграмме особо нет - и пришлось уже диаграмму жизненного цикла альф OMG Essence, показать путь по ней от гипотезы о возможности через требования к системе, и назад во внедрение, и там кусочки, к которым в принципе применимо слово тестирование - а уж делают их тестировщики, или аналитики, или кто-то еще - вопрос второй.

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

А в ответах на вопросы вернулись к тому, как убеждать других участников команды, что тестирование требований - это правильно. Тут я вспомнил ценностного предложения - Деятельность пользователя, в данном случае - команды, в ней - боли и выгоды, о которых надо договориться, потому что это ты можешь думать, что постоянные переделки - это боль, а оказывается - это источник дохода компании. А дальше против них - Тестирование требований как Средство, которое как-то снимает боли и увеличивает выгоды.

Facebook напомнил про мои доклады двухлетней давности на конференции AgileDays. У меня было два доклада, по разным темам. Обе темы получили развитие, и я, пользуясь случаем, хочу о нем рассказать.

Два года назад выступал на #AgileDays Действуй опираясь на ценности (Максим Цепков на AgileDays-2016). Книга Лалу тогда только вышла, и я рассказывал о ней и о Спиральной динамике, и о соотнесении всего этого с Agile и его методами. Кстати, по Спиральной динамике это было уже второе выступление, первое было на AgileDays-2014 году (http://mtsepkov.org/SpiralDynamics-AgileDays), когда я только познакомился и оценил эту концепцию, понял ее силу. А в прошлом году тему продолжил (http://mtsepkov.org/AgileAgainstThirdWave), уже в контексте третьей промышленной революции.

В этом году AgileDays - через неделю. Я там буду, хотя и без выступления. Ожидается много интересных докладов с практическими кейсами, которые показывают, как все эти концепты развивается и воплощаются в реальной жизни компаний, корпораций и государства. Думаю услышать много интересного.

А это - мой второй доклад на #AgileDays 2016 Agile - то что на самом деле нужно госзаказчикам (Максим Цепков на AgileDays-2016). И представленный там концепт развертывания проекта не от естественного для инженеров порядка разработки, основанного на связях системы, а от ценностей доставляемого результата, из которого выделяется MVP для внедрения, а внутри него - серия демо, ориентированного на конкретные целевые группы пользователей, я с тех пор рассказывал в других докладах и обучающих лекциях. По сути, это переворачивает привычное планирование проекта, потому что когда мы представили сценарий демо с точки зрения развертывания коммуникации с Заказчиком в хорошем темпе, оказывается, что разработать функционал для этого сценария - не так уж просто, и это - отдельная инженерная задача, разработчики, аналитики и PM ищут удовлетворительное решение.

Отмечу, что я не претендую на принципиальное открытие - многие идеи почерпнуты из тренинга Джефа Паттона для Product Owner, который я проходил в 2013 (http://mtsepkov.org/JeffPatton-PO), и где он рассказывал о планировании продукта от целевых групп пользователей которых мы хотим получить. Джефф вообще произвел на меня большое впечатление, а его фразу "Collaboration - это не разговоры и обсуждения. Это - совместная работа, и желательно - молча." - о часто цитирую. Ну а мы в CUSTIS адаптировали эти идеи для заказной разработки для наших крупных корпоративных заказчиков со многими особенностями.

В докладе было не только это, но и много другого о сотрудничестве с корпорациями. В несколько сжатом виде я в 2017 делился всем этим на ProfsoUX (http://mtsepkov.org/CorpCoop) - с тех пор, как в госпроектах начали обращать внимание и заказывать UI/UX перед многими небольшими компаниями актуальная задача - научиться взаимодействовать с миром иной культуры :)

Ну и в заключении - напоминаю, что через неделю состоится AgileDays. Можно участвовать лично, можно смотреть трансляцию.

В эти выходные - я снова в Петербурге на #ITGM. Мы с Лешей Федоровым будем глубже разбираться с ролями в проекте и с тем, кто их занимает - сам человек или его марионетка. Про актеров все понятно - они по Станиславскому в роль вживаются, чтобы хорошо ее сыграть. А на сколько это актуально в жизни? Сам концепт позаимствован у Петра Щедровицкого, я его рассказывал на #SQADays и #TeamLeadConf в докладе "Самоопределяйся технологично" (http://mtsepkov.org/SelfDet). Будем разбираться детальнее.

Полная программа IT Global Meetup, как всегда, очень интересна. Правда, как пишут организаторы "На данный момент регистрация закрыта, но вы можете узнать промокод у активистов сообщества. Также 16 марта в 09:00 будет открыта регистрация еще для 100 участников!". Так что попасть - можно.

Я приеду за пару дней, так что если у кого из Петербургских знакомых есть желание встретиться и что-то обсудить - то можно не только на ITGM, пишите.

Facebook напомнил: вот уже 5 лет, как я познакомился с OMG Essence из этого обзора Анатолия Левенчука и поделился им. Обзор был несколько раньше, я прочитал с опозданием. Тогда же, в 2013 Ивар Якобсон приезжал на SECR и на его мастер-классе по Use Case 2,0 (мой отчет http://mtsepkov.org/UseCase-2-0) я увидел Essence в действии - как рабочую карту, на карту который кладутся методы, описываются их входы и выходы. При том, что сам инструмент Ивар не объяснял - вы же не объясняете ER-диаграммы, когда рисуете схемы данных, предполагается, что люди их знают или интуитивно поймут. И вот здесь потенциал интуитивного восприятия инструмента был довольно высокий, потому что мое знакомство было очень поверхностным.

Но мое освоение было не быстрым - я начал включать схему альф OMG Essence как карту для рассказа только в 2015 (в докладе Развитие управления проектами и критериев качества в ИТ http://mtsepkov.org/BigPicture-PM-IT), а жизненный цикл - только в 2016 (в докладе Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять http://mtsepkov.org/Responsibility4quality). И освоение продолжается - OMG Essence дают хорошие карты, на которые удобно раскладывать материал.

А осенью 2017 Ивар снова приезжал на SECR, и у него был доклад по использованию OMG Essence как средства для метаописания всех методов (видео и слайды доклада http://0x1.tv/20171021AL, а мой отзыв с обсуждениями http://mtsepkov.org/SECR-2017), а еще был однодневный матер-класс Ивара по управлению рисками проектов, на котором сначала был качественный обзор существующих методов, а затем - управление рисками через отслеживание состояний альф OMG Essence.

Из моего доклада на SQAdays 14.11.2014

Примерно неделю назад я прочитал пост Ивана Дубровина о том, как интенсивно шагает Kanban в традиционных госструктурах — Центральный банк, Федеральное канзначейство, региональные структуры. И в коментах мы обсудили, как там строят Kanban-доски при внедрении. Оказывается — по полной программе, с рассмотрением организации в сервисной модели, определением создаваемых ценностей подразделением. И я подумал, что это — очень радует. Происходит разморозка, возвращение смысла в деятельность организации.

Большим организациям свойственно бюрократизироваться, это в середине века исследовал Крозье (я об этом недавно писал), об этом же говорит жизненный цикл корпорации Адизеса, по которому корпорация уходит в аристократизм и бюрократию, а затем умирает. А Kanban — способен ее эволюционно оздоровить. Здесь уместно вспомнить схему из Спиральной динамики на рисунке справа. Она говорит о том, что эволюционные изменения возможны только если разрыв между состоянием организации и окружающим миром — не слишком велик, иначе необходима революция. Таким образом, эволюционное, а не революционное развитие наших крупных государственных организаций, откликающихся на внедрение Kanban, означает, что в целом наше государство в целом адекватно потребностям общества, способно к изменениям и развитию, и делает это. Что не может не радовать.

Собственно, я бы написал это неделю назад, но примерно тогда же на FB началась еще одна интересная дискуссия о том, что лучше для команды, переходящей на Agile — Scrum или Kanban. Там тема Kanban, его отличий от Scrum была достаточно активно затронута в обсуждением с Алексеем Пименовым, и я решил сначала завершить обсуждение там.

Из моей лекции в ВШЭ 03.03.2018

И здесь надо отметить, что для новой команды основное отличие Scrum от Kanban — как раз в эволюционном или революционном изменении не столько процессов, сколько системы ценностей. У любой организации есть две стороны, культура и процессы. Есть красивая схема-метафора кораблика, показывающая этот дуализм и придуманная Марком Розиным. И справа на схеме показана конструкция Agile в этой метафоре. Я тут процитирую один свой комментарий из того поста — но советую прочитать всю дискуссию, а может — и принять участие.

У этого вопроса есть два аспекта: ценности, процессы. С точки зрения процессов выбор зависит от того, есть ли в работе реальное квантование по поставке ценности потребителю — выпуск релизов. Scrum ориентирован на разработку, в которой ценности поставляются пакетами. Сейчас это, отчасти, снимается практикой continuous delivery, однако если новый функционал необходимо рекламировать, привлекать пользователей, то это все равно делается периодическими компаниями. А вот Kanban ориентирован на непрерывный поток задач, каждая из которых несет самостоятельную ценность и изолированно доставляется потребителю.

А вот с точки зрения трансформации культуры и принятия новых ценностей Scrum — гораздо лучше, потому что он резко перестраивает процесс, что влечет за собой осмысление и принятие людьми нового подхода к работе — или, наоборот, четкий провал в случае неприятия. Это происходит благодаря многочисленным встроенным встречам, которые значительно сфокусированы на ценностях, благодаря постановке целей на каждый спринт и другим подобным аспектам. И Scrum очень сложно внедрить без трансформации культуры. А Kanban с точки зрения ценностей — гораздо мягче, он вписывается в любую культурную среду, постепенно размораживая ее благодаря визуализации потока ценности, и благодаря старту постоянных улучшений. Поэтому его внедрение проходит мягче, но больше опасность, что трансформация будет ограниченной и затухнет. В IT это не слишком проявляется, потому что Kanban появился позже, чем Scrum, основные ценности и принципы Agile-манифеста уже были приняты сообществом, проявились успехи, и на повестку дня встал вопрос о мягкой трансформации больших компаний (ну и о работе с эксплуатацией и развитием систем, где нет четких релизов). Именно Kanban хорошо подходит для эволюционного размораживания и оздоровления больших бюрократизированных структур — он через доски workflow и побуждает задавать вопрос — несет ли конкретная работа ценность потребителю или нет, и кто вообще является потребителем для работ конкретного подразделения.

Если в терминах Спиральной динамики — то Kanban — может хорошо оздоровить бюрократизированный синий, без трансформации на следующие уровни (но в перспективе — трансформация запускается), а Scrum — пробует дотянуть до желтого достаточно интенсивно.

Из моей лекции в ВШЭ 03.03.2018

Последний абзац как раз иллюстрирует вторая схема. После того, как Agile успешно развился и вышел на желтый уровень Спиральной динамики, как показано на левой, восходящей, ветви, и его методы доказали свое конкурентное преимущество, начались многочисленные попытки взять при внедрении только процессную часть Agile, не меняя ценности компании. Это показано на левой, нисходящей ветви. Впервые я показал эту схему в выступлении на AgileBusiness-2017, и на него был комментарий Андрея Павленко «адаптации» Аджайла к незрелым уровням спиральной динамики — это же почти исчерпывающий справочник фейлов при «внедрении» Аджайла. С одной стороны, это - так, и эффект от внедрения Agile в этих случаях является гораздо меньшим, чем при переходе организации на желтый уровень. Но, с другой стороны, организация должна быть адекватна своему окружению, и если внешние условия не требуют непременного перехода организации - то он - не обязателен. А вот оздоровление бюрократической организации и возвращение осмысленности деятельности - все равно происходит, и это - как раз элемент развития. И дальше можно развиваться, работая со смыслами деятельности. Но при этом надо помнить первую схему, которая говорит о том, что хотя эволюция гораздо экологичнее революции, она далеко не всегда возможна.

На этом - все.

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

Кстати, именно с этим докладом у меня - аномально большое количество проблем. Основная запись первого доклада на эту тему на AgileDays-2016 "Действуй, опираясь на ценности" пропала, в результате сводили с использованием резервных каналов полгода. Осенью 2017 на PMonline отказалась запускаться трансляция слайдов с моего ноута, и Федор Афанасьев листал слайды для трансляции со своего... И вот опять :(

Но современная техника нас спасла: я еще перед лекцией выложил презентацию на своем сайте, смотрел ее на ноуте и называл номера слайдов, а студенты с телефонов могли следить за рассказом. Но вот запись на камеру второй половины лекции - пропала, потому что камера была включена в сеть, а не работала от аккумулятора.

А презентацию - смотрите, кому интересно, http://mtsepkov.org/Agile-HSE-2018 Да, большинство слайдов там не новые, я уже рассказывал их на других докладах. Но лекция не является полным повторением. От лекции к лекции у меня самого происходит новое осознание, какие-то фрагменты развертываются, другие - свертываются. И сейчас я впервые попробовал положить культурные и процессные аспекты методов нового менеджмента на схему "Кораблик", которую придумал Марк Розин. Получилось интересно.

В целом впечатления о лекции у меня очень позитивные. В перерыве довольно активно общались со слушателями, и там были вопросы по-существу, с хорошим знанием менеджмента, был хороший диалог. Так что я очень благодарен Наталия Белякова за приглашение!

В эти выходные (пятница-воскресенье) я снова в Петербурге. В субботу читаю гостевую лекцию в петербургском кампусе ВШЭ. Оказывается, уже несколько лет в Вышке действует система дополнительных курсов по выбору - майнор, с очень разнообразной тематикой. И, помимо курсов, проводятся гостевые лекции с приглашенными лекторами, вот я и попал в их число - с рассказом про новый менеджмент - Agile и бирюзовые организации. В пятницу и воскресенье относительно свободен, так что если у кого-то из моих питерских друзей есть идея встретиться - пишите.

Дал интервью на Радиометрикс Наталии Беляковой о необходимостях и принципиальных возможностях и не-возможностях Agile. Видео на youtube https://youtu.be/vnRGRYIwCBM

Эти выходные был в Петербурге.

Оригинал на FB

→ продолжить чтение…

Периодически мне приходят вопросы о том, куда можно пойти работать в бирюзовую организацию. Люди многое читали, слышали и хотят попробовать. Желание — понятное. Но осуществить его не так просто по нескольким причинам. Во-первых, полноценных, то есть реализующих все аспекты бирюзовых компаний, практически нет ни в России, ни в мире. Все компании, которые целенаправленно работают в этом направлении — в процессе становления, в той или иной мере. Для интересующихся списками — у меня есть страничка Кейсы бирюзовых организаций в России, я ее периодически обновляю. И есть группа Бирюзовые организации в которой тоже можно искать информацию.

Из московских — интересен кейс «Доктор на работе», но это — небольшая IT-компания, и это подойдет не каждому. Что интересно — они не строили бирюзовую компанию, у них «само получилось». Есть интересный кейс самарской компании «Бизнес-гарант», они как раз целенаправленно перестраивали структуру управления под бирюзовую компанию. И при этом естественным образом убедились, что компания должна быть бирюзовой не по площади, а там, где это уместно и соответствует потребностям рынка. А там, где есть сложившиеся эффективно работающие подразделения, в которых сотрудники удовлетворены своей работой — форсировать развитие не нужно, и даже вредно. Но возможности, естественно, должны быть открыты. Еще есть ВкусВилл, он — работает на ценности здорового питания, это — основа сотрудничества и вовлечения персонала. Но при этом торговля — достаточно нормированная отрасль, и самоорганизация и возможность широкой автономной инициативы в значительной мере сосредоточена в офисе, а не на местах.

Еще интересны движения развития городов «Живые города» и «Центр прикладной урбанистики», которые представлены во многих городах России. Но они тоже не строили бирюзовое управление, у них оно получается. А еще они плохо укладываются в понятие «устроиться на работу» — в обоих смесь платных и бесплатных проектов, договариваешься об участии на конкретном проекте, это получается скорее фриланс, чем обычная работа. Будущее — именно за такой организацией работы, но не факт, что Вы сами к ней сейчас готовы.

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

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

И тут имеет смысл присмотреться не только к бирюзовым организациям, но и к кейсам Agile за пределами IT, но лучше не в крупном корпоративе, потому что там часто речь идет о ценностной перестройке компании. Информацию можно найти в группе «Agile вне IT». Еще имеет смысл смотреть кейсы, которыми делятся в рамках движений «Счастье в деятельности» (Филипп Гузенюк) и «Бизнес со смыслом» (Бехтеревы). Но при этом надо понимать, что многие из организаций только начинают путь перестройки, и потому непонятно, насколько по нему смогут продвинуться. А главное — оценивать, насколько Вам созвучны цели организации и ее способ принести пользу миру. Если Вы видите именно в этом свою самореализацию — хорошо, если нет — то зачем идти чужим путем?

Удачи всем в поиске работы, которой и процесс и результат будут приносить радость самореализации.

Обнаружил, что в конце прошлого года "Эксмо" выпустили книгу "Холакратия. Революционный подход в менеджменте". (Правда, у них там, видимо, по принципу "сапожник без сапог" отсутствует фото обложки) - https://eksmo.ru/book/kholakratiya-ITD827626/

Ну и, для поддержания кислотно-щелочного баланса - попалась мне тут занятная критическая статья "Холакратия – это тупик" ...

То, что Эксмо выпустили книгу - прекрасно. На Озоне, где ее можно купить, фото обложки есть и в посте оно оттуда.

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

Итак...

Давным давно, в 1986 году я смотрел Музыкальный ринг с группой Аквариум. Это было их первое выступление на телевидении, шла перестройка, люди пытались разобраться. И там выступал один товарищ из Ленинградского обкома, рассказывал о том, как он искренне пытался понять группу и причины ее популярности при полном отсутствии официальной поддержки - слушал записи, читал тексты, ходил на мелкие выступления - и ничего не понял. И это - не удивительно, другой mindset, другие ценности.

Так вот, товарищ эксперт смотрит на холакратию через свою призму традиционного управления - и ничего не понимает. И вот черты этого непонимания, и общий тон - знакомы еще по аналогичным статьям про Agile 10+ лет назад. И разбираться с этим по фактуре - нет смысла, потому что проблема в другом mindset, а он тут явно не сформулирован. Не, по фактуре проблемы тоже есть, это Алексей Ильичев (Alexey Ilyichev) выше написал, но вот смысла в этой дискуссии нет никакого. А на уровне mindset - каждый находится на своем уровне, и для роста должны быть внутренние причины, дискуссия в этом не убеждает ни разу.

Это, кстати, по опыту Agile и Scrum поняли авторы Холакратии. Поэтому они так жестко сформулировали свою конструкцию - для тех кто хочет попробовать, понять и принять в действии, по принципу Shu-Ha-Ri, в котором путь начинается с бездумного повторения за учителем. Зря, на мой взгляд, в современном мире такое воспроизводство ремесленного обучения не является эффективным. Хотя опыт Scrum подтверждает, что при опытном наставнике - работает. И экспериментов с отдельными практиками они не запрещают - просто жестко требуют не называть это Холакратией, надеясь не повторить те кейсы, когда Scrum сначала произвольно меняют, он не взлетает и дальше заявляют, что это не у них мозги кривые, а "Scrum не работает". В общем - их право на позицию.

В любом случае - нынешний этап - не пропаганда для завоевание мира, а сбора единомышленников, которые готовы пойти. А завоевание мира придет с подтвержденным успехом эффективности и распространением метода. Как с Agile для меня маркером успеха стал 2010-2012 года, когда IBM и Microsoft начали работать над переходом на Agile, ломая свою корпоративную культуру. При том, что оба были эффективными лидерами своих рынков. Причина проста: лучшие выпускники американских университетов перестали конкурировать за их оферы, уходя в стартапы со словами "вы, конечно, лидеры, но я выбираю свободу самореализации". И они поняли, что если так пойдет, то они останутся без лучших - и перестанут быть лидерами. И потому начали меняться. То же произойдет с бирюзовыми организациями и холакратией, и успех, естественно, будет не у нынешней первой версии - Scrum тоже прошел долгий путь эволюции до успеха, рядом появились другие методы, в частности Kanban. То же будет и здесь.

Часть видео опубликована на Хабре с конспектом докладов. 
В июне все видео были опубликованы на сайте конференции

Два дня, 08-09.02.2018 был на новой конференции Олега Бунина для тимлидов TeamLead Conf. 474 участника, и два трека очень хороших докладов. Очень высокий уровень по содержанию, по подготовке докладов, по компоновке программы. Я был на многих конференциях, достаточно много знаю в IT, так что ситуация, когда доклады в каждом слоте несут ценную для меня информацию, вызывают размышления - редкость. Тут было именно так. И, надеюсь, дальше будет не хуже. Потому что путь от разработчика к тимлиду - это актуальная тема. Я, кстати, специально не пишу "руководитель команды", потому что современный тимлид - он не классический руководитель. И вообще тимлиды - они очень разные, прежде всего потому, что компании - разные, у них очень разное распределение ответственности и обязанностей между сотрудниками, и, как следствие, очень разные тимлиды. И это разнообразие было в полной мере представлено на конференции.

Было очень круто! Спасибо докладчикам, спасибо вам, Олег Бунин, Александр Зиза, Роман Побочий, и всем остальным организаторам за работу над замечательной программой!

Я выступал с двумя докладами по совсем разным темам: Управление знаниями: какие документы нужны и что в них фиксировать и Как строить свой профессиональный путь - схемы самоопределения, презентации и аннотации можно посмотреть на страницах докладов. Приняли хорошо и было много обсуждений в кулуарах.

Дальше в посте - мои заметки про доклады. Хочу отдельно отметить, что потоков было два, а я - один. И в ряде случаев я выбирал между двумя интересными докладами. И иногда даже не мог выбирать, потому что сам делал доклад, и поэтому поэтому пропустил доклад Александра Зиза про поиск тимлида... Так что не воспринимайте написанное далее как полный список хороших докладов конференции. Их - больше.

Началась конференция очень грамотной раскаткой докладов: Nikolay Krapivnyy из badoo рассказывал про рост компании от десятка до сотен, а за ним Георгий Могелашвили из Booking.com рассказывает про рост IT от 400 до 1500. Пост на FB.

→ продолжить чтение…

Сергей Гевлич - тот самый, кто придумал объясняшки написал крутую статью про истории с разбором внутренней структуры историй на схеме. И это - очень ценно, что есть схема - потому что с ней можно соотноситься, Я знаю, что многие мои доклады построены не как истории - потому что они про карту мира, а не про поход в этом мире. Но, во-первых, многие - не значит все, а во-вторых, хорошее представление карты мира должно включать в себя истории путешествий, и я их включаю. И теперь у меня есть схема, с которой можно соотноситься. Раньше схемы не было, было просто текстовое описание "идеальной истории" (его же в школе учат, но в сокращенном варианте), с которым соотносить сложно. Это, кстати, как раз про пользу схем.

Facebook напомнил: Четыре года назад был на Software Quality Days в Вене. Был у меня такой период, когда я съездил на несколько зарубежных конференций - MODELSWARD в Барселоне, Software Quality Days, потом еще GoToCon в Копенгагене. Интересно было заглянуть, но в целом российские конференции - не хуже и ближе :) Так что дальнейшего развития эта тема не получила. Хотя, может, зря. А отчеты можно посмотреть у меня среди других отчетов http://mtsepkov.org/Conf: MODELSWARD-2013 - первые впечатления, MODELSWARD-2013 - подвожу итоги, Software Quality Days 2014, GoToCon-Cph-2014. А скоро к ним добавиться отчет с #teamleadconf, на которой я был последние два дня.

Через неделю, в среду 14.02, я выступаю в рамках Академического дня «Серебряного Лучника» на журфаке МГУ с докладом Будущее уже наступило: от Agile к Бирюзовым организациям. Я уже писал об это раньше, но тогда не было опубликовано всей программы мероприятия. Сейчас программа опубликована, выступать будет много интересных людей и из университетской среды, и их технологических компаний. Так что мероприятие получается очень любопытное, приходите. Участие - бесплатное, требуется регистрация, а если вы хотите получить прилагающийся сертификат, то он - стоит денег.

А через две с половиной недели, в воскресенье 25.02, я провожу workshop Пробуем новые технологии менеджмента (Agile, бирюзовые подходы) в Открытой школе бизнеса в Петербурге. Мероприятие ориентировано на владельцев и руководителей, которые чувствуют потребность в изменениях, слышали о новых инструментах управления, и хотели бы практически оценить их применимость. Будут такты лекций, групповой работы и обсуждений, в ходе которых участники смогут не только познакомиться с материалом, но и обсудить их уместность и способы применения на кейсах своих компаний. Участие - бесплатно, это первый воркшоп в таком формате. Требуется регистрация.

Это все были выступления об Agile и практиках бирюзовых организаций вне IT-отрасли. На IT-конференциях я тоже продолжаю выступать, на этой неделе будет два интересных доклада в Москве на TeamLead Conf, а 24.02 - на WIAD-2018 в Петербурге.

Разбирая старые книги обнаружил журнал со своей первой статьей «Технология согласования некоторых алгоритмов с архитектурой векторно-конвейерных ЭВМ», написанной в соавторстве в далеком 1987 году в сборнике «Вопросы Кибернетики». Я тогда работал в Студенческой лаборатории компьютеризации МФТИ, которую создал Олег Бацуков, вместе с Володей Рахтеенко, Виктор Яницкий, Дмитрий Северов, с которыми работаю до сих пор, а Yuri Panchul, Сергей Рыжков и Сергей Вакуленко - читаю и иногда - пересекаюсь....

Статья посвящена реализации алгоритмов на Советском аналоге Cray-1, который, правда, так и не был воплощен в железе, но на эмуляторе которого на БЭСМ-6 я работал, начиная с первого курса в институте. Сначала писал реализацию элементарных функций — квадратный корень и экспонента, и эти реализации были включены в официальную библиотеку. Но о них я рассказывал на студенческой конференции МФТИ, печатной статьи не было. А эта статья вышла уже на третьем курсе, и моя часть — библиотека макросов для макроассемблера, которая позволяла писать структурные операторы — циклы, if-then-else и другие.

На картинке - обложка журнала и начало статьи, если перейти - можно посмотреть скан статьи целиком.

А вторая статья CustIS Accounting — передовая технология автоматизации учета и анализа финансово-хозяйственной деятельности была написана через 10 лет и опубликована в журнале «Компьютер в бухгалтерском учете и аудите» 2-1998.

Она рассказывает историю создания ядра CustIS Acconting и распределенной АБС на его основе для ЛипецкКомБанка (ЛКБ) примерно за полгода в 1997 году. Работы вызваны изменением с 01.01.1998 банковского плана счетов бухгалтерского учета и ЛКБ принял решение заказать новую систему CUSTIS. Работы начались летом 1997 года, а 1 января система была запущена в боевую эксплуатацию на серверах всех филиалах банка с репликациями метаданных и документов. Полный текст CustIS Accounting (1998).

Я выношу в этот пост свои размышления по семинару Как пользоваться полным спектром мышления: от интуитивного через вероятностное до формального - представлению нового курса ментального фитнеса, прошедшему в пятницу. Фитнес тут понимается приведение аппарата мышления человека в здоровое состояние готовности к мыслительному действию. Курс делает Пион Гайбарян, о чем она писала пару постов назад, а Анатолий Левенчук планирует включить в набор курсов школы системного менеджмента, возможно, сделав предикатом к курсу системного мышления и системной инженерии, чтобы приходя люди уже знали - что есть мышление. Я хочу, с одной стороны, зафиксировать свои мысли на будущее, а, с другой - дать обратную связь авторам курса и потому этот пост - в сообществе, а не только у меня в блоге.

И, на всякий случай, я в самом начале хочу сделать disclaimer: все дальнейшее является моей личным восприятием услышанного. Все цитаты - неточные, а все смыслы - интерпретированные. Но я интерпретирую в ответственной позиции и готов разъяснять слова - обращайтесь. Итак, поехали.

→ продолжить чтение…

Выступаю на TeamLead Conference (Москва 8-9.02), программный комитет отобрал для выступления два доклада из трех заявленных (http://teamleadconf.ru/2018/author/2253 ). Я этому очень рад и буду стараться хорошо подготовиться и рассказать. Темы интересные: Как строить свой профессиональный путь - схемы самоопределения и Управление знаниями: какие документы нужны и что в них фиксировать Приходите на конференцию, там много других интересных заявок, а не только мои!