Блог:Максима Цепкова

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

Профессиональный блог Максима Цепкова.

Ранее был на http://blogs.uml2.ru/blogs/maksiq и http://softwarepeople.ru/, затем на сайте компании http://lib.custis.ru/Blog-mtsepkov, а с 19.05.2014 переехал сюда.

Сейчас все посты из старых блогов скопированы на мой сайт, при этом восстановлены посты, утраченные при закрытии портала SoftwarePeople. Полный список статей можно посмотреть в оглавлении блога.

Я в соцсетях

http://www.facebook.com/mtsepkov
http://www.linkedin.com/in/mtsepkov
https://twitter.com/mtsepkov

У меня есть личный телеграм-канал https://t.me/mtsepkov

И личный ЖЖ http://maksiq.livejournal.com, там путешествия и другие мысли вне ИТ.

Последние посты


2018-02-21: Пойти работать в бирюзовой организации?

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

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

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

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

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

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

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

2018-02-18: Холакратия - почему критика часто не интересна

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

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

HolacracyBook.jpg

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

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

Итак...

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

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

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

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

2018-02-11: TeamLead Conf - впечатляющий старт

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

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

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

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

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

Пост на FB Nikolay Krapivnyy из badoo. В целом очень интересный рассказ о внутреннем устройстве быстро развивающейся компании, выпускающий два релиза ежедневно, на сложном высоконагруженном продукте с достаточно сложной организацией компании. Спасибо!

Пост на FB Nikolay Krapivnyy из badoo. Характерный штрих по темпам современной разработки. Малое изменение за пару дней, а не несколько часов это проблема. В пару дней надо укладывать мини-проект для рекламной компании, а то окно возможностей закроется. Где в enterprise мыслят в таком темпе разработки?

Пост на FB Nikolay Krapivnyy из badoo. Рассматриваем процесс разработки с точки зрения теории массового обслуживания по обработке запросов на разработку и применяем их методы оптимизации. Тут я хочу отметить, что это будет работать для типовых запросов, но плохо работает для сложных. Результаты каждый может наблюдать, когда сталкивается с организацией массового обслуживания в поликлиниках и больницах. И это - системная проблема, потому что и IT-разработка и лечение - умственный труд, плохо поддающийся регламентации, а теория массового обслуживания - для организации труда, который можно регламентировать.

Пост на FB Георгий Могелашвили (Georgiy Mogelashvili) из Booking.com. Были команды с TeamLead и Product Owner, и они решили сделать команды без teamlead - потому что бурный рост, их не хватит. Эксперимент. Получилось. Георгий рассказывает, как разложились обязанности teamlead - решение конфликтов, фидбэк сотрудникам, выставление оценки. Реально интересно. Фидбэк, например, дают парами друг другу по графику. А оценки все ставят всем за круглым столом - и работает без конфликтов. Но все это - не само, bootcamp для команды и помощь на старте. В принципе, автономия сработала. Но возникают проблемы с ротацией сотрудников - сработавшиеся команды откатываются; ростом сотрудников без поддержки и engagement (они измеряли по google research perfect team). В результате teamlead вернулся, но в ограниченном объеме - он подключается только в ситуациях необходимой поддержки. Называется это servant leader. Основной фокус теперь - рост людей, но он отстраивает среду для этого, а не сам это делает. Так что в целом эксперимент говорит о том, что команда без Team Lead работает хуже, чем с ним, однако, автономность возможна, особенно в короткую, а помогать надо точечно.

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

Пост на FB Евгений Россинский Очень интересный рассказ. У них были команды, сформированные по технологиям (backend, web, разные мобилки), где каждый руководитель был экспертом в технологии, подбирал и выращивал специалистов. Но были проблемы с time to market. И они перешли на команды по value stream. Но при этом разработчики в каждой команде правят общий код на каждой платформы, и релизный цикл - тоже по платформам. Поэтому команды по платформам - восстановились. И сформировалась довольно сложная конструкция, которую Евгений и рассказывал со многими деталями и особенностями организации и коммуникаций.

Пост на FB Nina Scheglova из Lazada (Юго-Восточная Азия, технари в Москве, Въетнаме и Сингапуре) рассказывает про матрицу компетенций тимлида. Я тут подумал, что в IT, да и в другой технических отраслях часто смешивают soft skill, как коммуникационные, эмоциональные и другие компетенции, не связанные с профессиональной работой, с профессиональными компетенциями менеджеров. Ведь менеджер - это тоже профессия, и у нее есть свои hard skill.

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

В конце презентации - слайд со ссылками. Матрица тимлида https://goo.gl/zPw4GH еще есть тестировщика, программиста и дизайнера.

В комментариях к посту есть обсуждение содержания матрицы, а еще - обсуждение разницы soft skill и hard skill менеджера, которое я скопирую.

Ekaterina Semenova Hard skills менеджера мы целенаправленно не расписывали - они очень отличаются даже в рамках одной компании. Где-то много-много специфичных инструментов, а где-то - макросы и программирование в Экселе.
Максим Цепков Екатерина, мне кажется, Вы hard skill менеджера понимаете в IT-смысле - как владение определенными IT-инструментами. А я их понимаю по-другому, а именно, как как профессиональные скилы менеджера. Они ведь есть. То есть деление на soft skill и hard skill - не по тому, используются ли какие-то технические средства, а потому, что hard skill связаны с профессией (дисциплиной), а soft skill - от нее не зависят. Менеджер - это профессия, а менеджмент - дисциплина и у нее есть свой набор hard skill, которых учат, обучая менеджменту.
Ekaterina Semenova Теперь я поняла о чем Вы. С такой трактовкой понятий получается довольно интересно. С одной стороны у тимлида должны быть hard skills команды (программирование/ тестирование). И возможно Вы правы, когда разработчик переходит в тимлиды - его скилл, например, коммуникации становится hard skill'ом. Это можно будет обсудить отдельно.
Максим Цепков Там тонко. Возьмем аналитика. У него есть soft skill коммуникации и умение писать тексты, и есть hard skill проведения интервью (с фиксацией результата), в котором коммуникация и написание текстов - важная составная часть. Наверное, что-то аналогичное и здесь.
Ekaterina Semenova Ага. И прокачать можно видимо оба скилла

Пост на FB Alexey Kataev skyeng. В целом очень хороший доклад про распределенную команду - как нанимать, как организовать общение - чтобы в целом команда работала не просто не хуже, а лучше обычной работающей в офисе. И в докладе - евангелизм удаленной работы, которая лучше обычной.

Пост на FB Alexey Kataev skyeng. Вовлеченность обеспечивает общение, а не сидение в одной комнате. Поэтому hangout, камеры и много совместных встреч по работе и даже online-игры.

Пост на FB Alexey Kataev skyeng. Крутая практика работы с тех.долгом - рефакторинг митап. Разработчики вывешивают карточки о всех костылях, которые ему известны. Потому что это - распределенное знание. Дальше уже понятно - обсуждение, превращаем в таски и приоритизируем. А входной митап - круто.

Пост на FB Артур Орлов. 8 стратагем тимлида - клевый доклад о правильных паттернах поведения тимлида, стилизованных под китайские стратагемы. Много уроков - известно опытным, но для тех, кто тимлид недавно - они не очевидны. И подача очень классная.

  • Не стоит бросаться на все амбразуры самому - герой всегда остается один...
  • Когда задачи сообразны навыкам и компетенциям - не возникает обманутых ожиданий
  • Формируй культуру бесстрашных ошибок
  • Разработка и тестирование - одна команда, объединяй, а не разъединяй!

И так далее...

Артур выложил презентацию https://goo.gl/gF7o4q

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

В комментах к посту развернулась дискуссия по этому поводу. Мне кажется, она интересна, и я ее сюда скопирую.

Максим Шаломович На мой персональный взгляд - одно из самых спорных высказываний в докладе. Возможно, спрашивающий и докладчик сильно по-разному понимают документацию.
Максим Цепков Я думаю, скорее, у спрашивающего паттерн, что документировать - это передать знания. Есть такой. Но неверный, это весьма ограничено работает. И Артур это уже знает :)
Артур Орлов Согласен с тем, что высказывание спорное, постараюсь прояснить, свой ответ. Насколько я понял вопрос, он касался документирования знаний по собственно написанному коду, и вот в этом случае, на мой взгляд, она избыточна - код и так должен давать понять что и как он делает. Что касается документации того, что не имеет отражения в коде - то, конечно, она может быть полезной, если понятно, какие задачи она решает. Задокументированный стайлгайд и какие-то базовые принципы, например - очень полезная штука, хоть и не большая.
Максим Шаломович Ну хорошо, давайте конкретизируем. Документированные требования (например, несколько юзкейсов уровня всей системы, "черный ящик", и много юзкейсов уровня каких-нибудь подсистем/компонентов/элементов, "белый ящик")? Документированная архитектура хотя бы уровня структуры, ответственности элементов и интерфейсов взаимодействия? Документированные принципы разработки для отслеживания архитектурных решений a-la тех, что пропогандирует Саймон Браун (для устранения разрыва между моделями и кодом)? Что-то из этого по Вашему мнению и (или) опыту нужно для сохранения и передачи знаний?
Максим Цепков Я вмешаюсь в дискуссию... Тезис был не в том, что документация не нужна. Тезис был в том, что для сохранения знаний необходимо организовывать специальную коммуникацию в команде, когда знания передаются от человека к человеку, а документация сама по себе передачу знаний не обеспечивает. Если мы этот тезис принимаем (а я считаю его справедливым), то вопрос о документации становится вторичным, и ее количество и формы определяются участниками коммуникации - им что-то легче описать, чем запомнить и они это делают.
Артур Орлов Да, все именно так. Собственно, потому мне кажется работающим принцип, что лучшая документация создается тем человеком, которому она понадобилась, он получил ответы на свои вопросы в команде, зафиксировал. Тогда это действительно "работающая" документация )
Максим Шаломович Максим Цепков, я принимаю тезис, несмотря на то, что живу в мире заказной разработки по ГОСТ 34, и вопрос документации для меня, как правило, определяется контрактными обязательствами))) Мне интересно именно из опыта команд, ориентированных именно на сохранение и передачу знаний - какая документация в этом им реально помогала (перечисленные мной в предыдущем комментарии примеры). С одной стороны я понимаю, что архитектурная документация (от HLD до моделей уровня кода) в первую очередь нужна архитектору, поэтому ее с трудом можно назвать эффективным способом передачи знаний от архитектора/аналитика разработчикам (в этом плане совместная работа и шаринг знаний реально должны работать лучше). С другой стороны не могу не заметить, что в крупных распределенных (во всех смыслах) проектах ротация разработчиков и даже лидов довольно высокая. И передача знаний без какого-то персистентного ее хранения (к которому я не отношу голову разработчика :-)), наверное, невозможна. Понятно, код должен быть максимально понятным, но код - это продукт реализации, до которого есть много других шагов (анализ, дизайн - пусть и в максимально легковесном варианте, в рамках гибких ЖЦ). А что еще поможет?
Максим Цепков Я тоже живу в мире заказной разработки, и для части заказчиков мы делаем документацию по ГОСТ или их внутренней нормативке, так что мне это знакомо. Архитектурная документация точно нужна. И ротация разработчиков действительно довольно высокая. Но при этом опыт устная традиция в команде/группе/подразделений является одной из форм живого персистентного хранения. Об этом говорит мой практический опыт в IT, я наблюдаю это у многих заказчиков. Например, составление годовой отчетности ни в одном крупном банке не выполняется по регламентам, хотя они кое-где встречаются, но при этом традиция - живет. А дисциплина Управления знаниями. с которой я знаком, говорит, что это - правильно, что определение, какие знания делать явными и сохранять в артефактах, а какие держать на устной традиции - предмет управления.

Пост на FB Andrew Minkin Учат ответственности стажеров - делают внутренний сервис, через который люди в команде заказывают себе еду в офис :) И они видят, что такое проект в продакшн и зачем надо тестировать. И ущерб конкретный показывают - негатив. Да еще просрочки пробуют вешать на них кормление офиса...

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

В комментариях было обсуждение про эффективность подобной методики.

Эдуард Галиаскаров А практическое воплощение этой умной мысли есть?
Andrew Minkin Могу поделиться опытом как я делаю это в команде. Через несколько месяцев смогу поделиться как я это сделаю в учебном центре. Если конечно у меня получится :)
Эдуард Галиаскаров Интересно, конечно. Я пытался разыграть ситуацию: один студент пишет проектную документацию, другой ее реализует. При этом оценивается только проект, который соответствует проектной документации. В результате стал врагом номер один, похерителем гениев и талантов. Так что пока не решаюсь на повторные эксперименты :)
Игорь Бородихин Нужно измерять эффективность команды с применением этого метода и без, на короткой и длинной дистанции. Может внезапно получиться, что кроме издевательств над джунами (что само по себе неплохо в рамках их профессионального роста) для бизнеса никакого профита такая методика не приносит.
Максим Цепков Игорь, как раз рост джунов и был целью данной методики - потому что все это делали в рамках стажировки кандидатов в компанию. Эффективность стажировки компания меряет - количество и уровень сотрудников, которые пришли в компанию после стажировки против количества трудозатрат сотрудников компании на стажировку. И это - была не первая стажировка, которую компания проводит, так что они смотрят динамику, а эти методы как раз способ обеспечить эффективность для бизнеса.
К сожалению, в социальной сфере нельзя поставить чистый эксперимент: сдублировать команду, потом к одной копии применять некоторый метод обучения, а к другой - его не применять, или применить другой, и дальше сравнить результат. Поэтому такие предложения - не реализуемы.

Пост на FB Начало второго дня #teamleadconf Александр Киселев (Alexandr Kiselev) и Сергей Семенов (Sergey Semenov) - очень правильный доклад про метрики, измеряемые по коду и jira. Идея в индикативных метриках, разработанных под каждую проблему, которые привлекают внимание для разбора ситуации. В докладе - набор проблем и метрики для них. Индивидуальные проблемы - разработчики, которые почти не делают, или наоборот перерабатывают, или не дожимают задачи. Командные проблемы - недостаточно продумывание задачи, неравномерное знание о коде в команде, плохой onboard новых разработчиков, накопление технического долга. У них - стартап готового продукта, который это меряет. Но метрики - понятны, можно и самим мерить :)

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

Да, при разборе в большинстве ситуаций первый шаг - поговорить, понять причину и если действительно проблема - предъявить цифры. Часто цифр оказывается достаточно, люди просто не думают, что таковы потери (а метрики их показывают). Если не помогает - тогда надо думать.

Пост на FB Григорий Петров (Voximplant). Любопытный доклад, смесь физиологии мозга и работы со смыслами. Коммуникация, у менеджера проблема бизнеса из-за сроков разработки или бага, он приносит это сообщение, а разработчика опознает это как "менеджер ругается". Чтобы не было - надо формулировать сообщение так, чтобы оно не опознавалась как социальное взаимодействие двух людей, а как призыв выполнить социально принятый процесс. Например, переоценить сроки, или обсудить проблему. И много разных других приемчиков, включая использование и учет конотаций.

Пост на FB Егор Толстой Performance review в Avito. Масштаб - 1500 оцениваемых, около 10к оценок, в среднем каждого оценивает 9-11 человек. Системе - 3 квартала, один квартал - эксперименты, два квартала по полной. И при этом одна оценка - 10 минут у респондента, 4 часа в квартал. Понятно, что оцениваемый и его менеджер тратят больше. И отдельные метрики, которые показывают, что оценка работает как процесс, позволяет выявить системные сбои (вернее, дает гипотезы о них). Мне довольно интересно сопоставить с нашей, которой уже много лет, и которая развивается. Масштаб у нас сильно меньше. Но вот идея, что главное - не оценка, а развернутый отзыв - она есть и очень важна. Интересно, что в Авито все начинается с самооценки, а еще оцениваемый сам формирует массив профилей ожиданий от него (дает ссылки), по соответствию которым и надо оценивать. И они отдельно разбираются с ситуациями, когда респондент оценивает не по этому профилю. а по собственным ожиданиям. А еще в авито были интересные эксперименты по анонимности: начинали с полностью анонимной обратной связи, и поэтапно двигаются к тому, чтобы сделать ее открытой.

Пост на FB Круглый стол по выращиванию тимлидов. У Авито была практика "тимлид в кредит" - за знания. Отказались, потому что много людей выгорало: пытались продолжить писать код, но при этом еще работать как тимлид, не хватало сил. Теперь смотрят выявляют неформальных лидов, предлагают подтянуться и стать формальными.

Вообще круглый стол был большим и интересным, в телеграм-чате https://t.me/teamleadconf выложены фотки с досок (фиг долистаешь, но можно поиском "круглого стола"). Кстати, сам чат уже переименован в Боль Тимлида и обсуждение кейсов продолжается.

Пост на FB Оценка задач Дмитрий Симонов (Dmitriy V. Simonov) В докладе много про разные скрытые факторы, которые оценку увеличивают и приемы ее уменьшения. Например, devops - профи наладит инфраструктуры выкатки и автотестов, сократив многократно сроки этих этапов. Нет своих - ищите. А терки в команде могут увеличить работы многократно. Например, по поводу правильной расстановки скобок у if. Многое решается регламентами, например, code style. Или по взаимодействию другими командами - чтобы зафиксировать взаимные ожидания.

Пост на FB 1000 и 1 фидбэк Jane Goleva (Lamoda, в inhouse 300 IT-шников). Фидбэк надо Не принимать, но учитывать - это лишь одно мнение. И ты решаешь, насколько измениться. Учила фидбэку в клубе спикеров, где желающие готовились выступать на конференциях. Поэтому фидбэк - публичный и экологичный. Например, правило трех плюсов: не нашел их - молчи. А нашел - можешь высказаться. Но критика - в залоге, что можно улучшить, конструктив, а не негатив. И много-много других мыслей про фидбэк.

2018-02-10: схема storytelling

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

2018-02-10: вспоминая о зарубежных конференциях...

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, на которой я был последние два дня.

2018-02-07: Agile вне IT - выступаю в Москве и Питере

SilverArcherLogo.jpg

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

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

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


2018-02-06: 30 лет моей первой статье

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

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

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

Article-1987.pdf

CustisAccounting-1998-cover.jpg

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

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

2018-01-28: Семинар о полном спектре мышления

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

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

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

2018-01-27: Выступаю не TeamLead Conf

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

2018-01-24: О целях спринта

Коллеги, здравствуйте! Я начинающий agile-коуч. Столкнулся с такой проблемой: команды программистов работают по Scrum над непрерывным совершенствованием уже работающего, пользующегося популярностью продукта. Scrum стали применять недавно, месяца 3-4. Задачи на спринт накидывают овнеры команд. Они разноплановые, решают очень разные проблемы функционирования продукта. Как определять цель спринта в такой ситуации? Может ли быть несколько целей? Насколько важно в такой ситуации вообще формулировать бизнес- или потребительские цели? Не достаточно ли того, что сформулированы юзер-сториз задач?

Я привожу свой ответ, а в посте идет активное обсуждение этой интересной темы.

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

Может быть несколько разных вариантов, часть из них я перечислю.

  1. Развитие продукта - просто непрерывное добавление фич, которые поступают от пользователей, и Product Owner просто осуществляет арбитраж интересов стейкхолдеров. В этом смысле деление на релизы и, соответственно, итерации Scrum может быть техническим приемом, которые не имеет особого смысла. Это не значит, что надо отказываться от Scrum и переходить к Kanban или композитному ScrumBan (хотя возможно) - потому что Scrum с его мероприятиями хорошо обеспечивает принятие Agile mindset, а это может быть важно, особенно если команда перешла на Agile недавно. Но в этом случае к делению на итерации и релизы надо относиться технически и не заморачиваться. Хотя тут тоже может быть место целям, а именно - они должны давать ориентир команде, на какие задачи сделать акцент в том случае, когда что-то пошло не так и все задачи за спринт явно не успеть.
  2. Есть стратегия развития продукта, и каждый релиз сфокусирован на определенной группе пользователей, и должен достичь существенного приращения поставляемой им ценности, при этом для остальных категорий надо просто завязать немного бантиков (или решить проблемы). В этом случае у спринта появляется сфокусированная цель, связанная с конкретной группой пользователей, плюс некоторые задачи раскрашиваются как ориентированные на другие группы и по ним надо, например, сделать хотя бы одну для каждой группы.
  3. Промежуточный вариант, когда релиз включает в себя результат нескольких спринтов, и при этом у него есть направленность на определенные группы пользователей, но по каким-то соображениям (например, организация внешнего маркетинга и рекламы) это не делят на несколько релизов. Тогда внутри релиза можно ориентировать спринты на конкретные группы пользователей, формулируя их интересы относительно релиза и проверяя, в какой мере выбранный набор фич позволяет их достигать. И соответственно демо (sprint review по-современному) строить для них.
  4. Могут быть цели, не связанные с задачами, а нацеленные на совершенствование способа работы (из ретро). Например, выявлен тип задач, для решения которых команда хочет попробовать новые технологии или способ работы, и оценить результаты. Или выявлено узкое горло, связанное с недостаточной кроссфункциональностью - какие-то компетенции локализованы на определенных людях, и получается критическая зависимость в случае отпусков/болезней, или недостаточная производительность, если придут задачи только данного функционала - их придется брать неопытным сотрудникам тоже, и мы хотим эту ситуацию расшить.

2018-01-23: Рассказываю про Agile и бирюзовые организации 14.02 на журфаке МГУ

Интерес к Agile и другим новым управленческим технологиям распространяется, и 14.02 в рамках академического дня национальной премии Серебряный Лучник я буду рассказывать о них в своем докладе "Будущее уже наступило: от Agile к Бирюзовым организациям". Анонс выступления уже опубликован на сайте http://www.luchnik.ru/news/2241/. Академический день пройдет на факультете журналистики МГУ, участие - бесплатное, но требуется регистрация. Программа еще формируется, обещают опубликовать 01.02, пока есть анонс мероприятия http://www.luchnik.ru/news/2238/ Приходите!

Это будет обновленная версия моего доклада на днях PR и Маркетинга на Юге - за 8 месяцев много произошло и было осмыслено.

Аннотация.

Третья промышленная революция, которая была предсказана в далеком 1980 году Элвином Тоффлером в книге «Третья волна», уже перестала быть делом будущего, а становится частью настоящего. Вызовы, которые она несла, в первую очередь пришли в IT-отрасль в конце 20 века. А в начале 21 века появился ответ на них - практики Agile, которые развиваются уже полтора десятилетия, в том числе вбирая из традиционного менеджмента все ценное и применимое в будущем мире.

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

За пределами IT-отрасли тоже формируются ответы на вызовы нового мира. Фредерик Лалу в книге «Открывая организации будущего» представил результаты исследования новых организаций в самых разных отраслях, выявил общие механизмы и практики, которые лежат в основе управления их деятельностью. Он показывает, как устроены организации, объединяющие много независимых лидеров, движущихся к общей цели организации и координирующих движение. Распространение бирюзовых организаций - зримое проявление изменений mindset в современном мире.

В докладе будет описана big picture современного развития, в которой каждой из организаций предстоит самоопределиться и выбрать собственный путь. Доклад является развитием моих выступлений по темам Agile и Спиральной динамики, доступных на моем сайте http://mtsepkov.org/Agile

2018-01-23: Выступаю на WIAD-2018

В третий раз еду на #WIAD в Питер и буду там выступать: UX: делаем систему удобной? - Нет. Делаем удобной жизнь! (WIAD-2018).

В Питере - единственная площадка World Information Architecture Day в России, и там - интересно. Регистрация https://uxspb.timepad.ru/event/626238/ Мои отчеты о том, как это было - на моем сайте http://mtsepkov.org/WIAD-2016 и http://mtsepkov.org/WIAD-2017

2018-01-09: Схемы, которыми я мыслю

Два года назад я опубликовал сборку схем, которыми я мыслю Блог:Максима Цепкова/2016-01-09: Схемы, в которых я мыслю. За два года дополнений - немного, но сильно увеличилась интеграция. И именно интегрированную картину, представляющая сборку схем-флешек, да еще с возможными альтернативами я рассказываю в большинстве последних докладов.

В менеджменте, где основой сборки служит Спиральная динамика, схема которой детализирует развитие общества по волнам Тоффлера, и на которую накладывается и развитие Agile и развитие традиционного менеджмента и бирюзовые организации и игрофикация. Это можно увидеть в моих последних докладах, например, здесь Будущее уже наступило: от Agile к Бирюзовым организациям (Дни PR и маркетинга на Юге 2017) и Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017)

Интересно, потому что с развитием отрасли флешки-подходы меняются, а люди этого не замечают. потому что слова - знакомы. Изменился только смысл, который в них вкладывается, но услышав знакомые слова многие не задумываются о новом смысле. В докладе Удовлетворенность стейкхолдеров – два разных смысла (AnalystDays 2017-10 в Минске) я как раз подробно рассматриваю эту эволюцию смысла. А в докладе Как выбрать для проекта практики проектирования и работы с требованиями (Максим Цепков на AnalystDays-2017) и Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять (SQAdays-20, 2016-11) - показываю спектр имеющихся схем и акцентирую внимание на вопросах, которые надо задать, чтобы выбрать подходящие для проекта.

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

2018-01-08: праздники - время подумать о сложных концептах

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

Пост FB. В праздники добрался до лекции Петр Щедровицкий о догоняющих индустриализациях России. Замечательная BigPicture развития экономики России от Петра до Брежнева, которое инерционно сказывается и сейчас, в контексте мировой экономики. Пересказывать бесполезно, потому что очень много содержания, надо смотреть. Да, там три часа. Ну, что делать. Ссылка на видео https://youtu.be/k5o5qLAKBy0

Пост FB. Узнал, что Анатолий Левенчук вместе с коллегами пару месяцев назад начали работать над созданием курса по мышлению как таковому, при этом не научному, а прикладному, то есть для инженеров, менеджеров и всех остальных. А у меня - старая идея, что в IT есть довольно большой массив знаний, касающихся мышления, потому что проектирование и разработка - это и есть мышление в чистом виде, только с овеществленным результатом и следами. И написал об этом пост в созданном ими сообществе https://thpectrum.livejournal.com/5917.html В ЖЖ и на FB идет активное обсуждение.

2017-12-30: Как побудить организацию к изменениям

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

Культура разных организаций складывается исторически, во многом зависит от культуры основателей, а позднее - руководителей-топов. Но они решают далеко не все. Дело в том, что по мере роста организации происходит рост формальных взаимоотношений, который приводит к росту бюрократии. Концепт бюрократии в начале 20 века активно прорабатывал Макс Вебер, полагая его прогрессивным явлением, обеспечивающим прозрачность и предсказуемость работы, в противовес чиновничьему или начальственному произволу, и тогда он таким был. Но с тех пор тяга к регламентам повернулась обратной стороной и в 1950-1960-х Мишель Крозье проводил исследования механизмов как регламентация внутри корпораций и государственных органов приобретает самодвижение внутри организации, приводя к параличу работы на определенном масштабе, если ей не противодействовать. И его исследования как раз показывают, что без активного противодействия негативные стороны культуры появляются и развиваются по мере роста компании. Кстати в апреле я уже писал на эту тему.

SpiralDynamics-InUse-Tsepkov-SQAdays-2014-2.pdf

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

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

Agile vs Gamification - OTUMKA 2017-12.pdf

Разрыв структуры и процессов организации с внешним миром могут увидеть люди на самом разном уровнях организации - внизу, среди топов или руководители среднего звена в каких-то подразделениях. В том числе потому, что разные подразделения могут функционировать на разных рынках с разными условиями. Таким образом, первоначальный импульс к изменениям может появляться в разных местах организации. Основных вызовов сейчас три: business agility, требующий от организаций гораздо большей гибкости и перестройки, цифровизация, обесценивающая старые способы организации бизнеса через регламенты, и mindset поколения соцсетей, который грозят оставить без способных сотрудников классически устроенные организации.

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

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

Поддержка руководством - наиболее распространенный и пропагандируемый сценарий изменений. Но могут быть варианты, когда достаточно автономный руководитель подразделения реорганизует только его, выстраивая вокруг подразделения интерфейсы взаимодействия. Это - сложнее, но получается. Например, есть примеры внедрения Agile в IT-отделах крупных корпораций, и даже наработан способ объяснения Agile codtne директоров на MBA-PMI языке. Об этом был хороший доклад Dan Rawsthorne. Scrum: the Big Picture на AgileDays-2012 ( презентация, видео не сохранилось).

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

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

На этом я, пожалуй, закончу этот пост.

2017-12-24: Спасибо всем за прекрасный год

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

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

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

Начну я как раз с темы Agile и Спиральной динамики, и тут моя большая благодарность Marina Simonova , с сотрудничества с которой еще в 2016 году начался мой консалтинг, и ее команды Елена Пляцук (Elena Pliatsuk) и Юлия Тегель (Yuliya Tegel). Девушки, Вы - замечательные и вдохновляющие и ваша энергия заражает окружающих на движение вперед! Agile выходит за пределы IT, и у меня летом было выступление на мастерской лидерства в МГУ, за которое я очень благодарен организатору, Елена Сельвич (Elena Selvich), не только за приглашение, но и за участие в подготовке, содержательной критике материала. Спасибо. А благодаря Марина Демченко (Marina Demchenko), которая позвала меня выступить на днях пиара и маркетинге в Ростове-на-Дону у меня получилось рассказать об Agile-подходах и бирюзовых организациях миру маркетинга и пиара, и это взаимодействие продолжает развиваться. Именно с подачи Марины возникла идея сопоставить подходы Agile и игрофикации, и получился очень интересный рассказ. Большое спасибо Марине за идею. А еще в Ростове-на-Дону я познакомился с Юлия Грязнова (Julia Gryaznova), были очень интересные обсуждения, и это продолжилось на днях пиара в Москве, которые Юля организовывала. РАСО 25 лет, но вместо празднования юбилея люди решили попробовать посмотреть вперед, предсказать будущее своей профессии, и собрали замечательный состав спикеров. Я рассказывал про Agile и бирюзовые организации, своей картине будущего, и слушал других замечательных людей, представлявших свою картину. Громадное спасибо всем им, и спасибо Юле за приглашение на мероприятие.

Agile не просто идет за пределы IT-отрасли он активно идет в государственные корпорации и государственные проекты. Что для меня лично свидетельствует о больших перспективах нашего государства. И тут я благодарен Иван Дубровин за его приглашение к участию в рабочей группе по применению гибких методологий в гос.проектах, всем участникам группы и особенно Павел Алферов за его постоянное оппонирование, которое в целом очень помогает осмыслению и конструктивному продвижению. А еще - Павел Рабинович (Pavel Rabinovich) за впечатляющий рассказ о применении Agile в школе, и очень надеюсь, что этот опыт получится масштабировать. А также Андрей Малахов (Andrey Malakhov) за приглашение на встречу PMO club для рассказа про Agile, где я, совершенно неожиданно для себя, узнал, что Scrum уже год как применяется концерном Калашникова для разработки нового оружия, Федор Афанасьев (Fedor Afanasyev) за приглашение на конференцию по проектному управлению в малом и среднем бизнесе, где я познакомился со многими интересными спикерами. И Олег Смирнов и Вадим Овечкин за приглашения на Радиометрикс по этой теме. Взаимное проникновение и влияние Agile-подходов и подходов классического проектного управления - очень важно и интересно. И, завершая тему Agile-сообщества хочу сказать спасибо Алексей Пименов (Alexey Pimenov), с которым мы в течении года общались на самые разные темы.

Если говорить о будущем, то в этом году я познакомился с совершенно замечательным человеком - Лев Гордон (Lev Gordon), один из лидеров движения Живые города. И благодаря его приглашению смог глубже заглянуть внутрь этого движения и немного поучаствовать. И хотя пока у меня не получилось найти свое место внутри этого движения, даже взгляд со стороны на способы, которыми это движение организует и координирует деятельность - очень вдохновляет. Собственно, это те самые механизмы будущего мира, результативность которых совершенно невозможна с точки зрения классического менеджмента индустриального общества, но которые действуют и достигают результатов - уже здесь и сейчас, в нашей стране. И я благодарен всем участникам движения, с которыми пересекался на протяжении года на разных событиях и в переписке. И я, в частности, с интересом смотрю за тем, как Анатолий Баляев (Anatoly Balyaev), вдохновленный теми подходами, которые показывает Лев, разворачивает живой университет в рамках этого движения. Анатолию я хочу сказать отдельное спасибо за конференцию Великая октябрьская эволюция, в которой я в этом году участвовал третий раз, на этот раз в форме бесед, а не монологов - с самим Анатолием о практиках бирюзовых организаций и с Ольга Гусева (Olga Guseva) об Agile.

А еще осенью, на встрече по бирюзовым организациям в Питере, где движение Живых городов представлял Александр Адамчик, я, благодаря Борис Юшенков (Boris Yusenkov) познакомился с другим движением - центр прикладной урбанистики, которое тоже практически реализует в своей работе принципы нового менеджмента. И я очень благодарен организаторам встречи Сергей Федоров (Sergey Fedorov) из Открытой школы бизнеса и Тимофей Левицкий (Tim Levitskiy) за такую замечательное мероприятие. Еще одна интересная встреча по бирюзовым организациям произошла в Минске, я очень благодарен Андрей Мирошниченко за организацию, за возможность познакомиться с такими замечательными людьми, и Артур Пинчук (Arthur Pinchuk) за общение и идеи. Встреча была в минском офисе по управлению знаниями, с Сергеем и Артуром я знаком по этому сообществу, в котором участвую с 2010 года, хотя и находясь несколько в стороне. К сожалению, в этом году у меня не сложилось принять участие в ежегодной конференции KM Russia из-за других активностей. Но, пользуясь поводом, я хочу передать привет и благодарности Вадим Ширяев, который стоял у истоков и с которым мы регулярно на этих конференциях встречались и, думаю, еще не раз встретимся.

А еще я хочу поблагодарить Марк Розин за его великолепную Бирюзовую проповедь, и Марк Кукушкин и Ekaterina Lefterova за ПИР, на котором в этом году так явно проявился современный вектор развития общества и бизнеса в сторону того будущего общества третьей волны, в которое бирюзовые организации входят составной частью. И всем участиникам ПИР тоже - за доклады и активное общение, и особенно Дмитрий Риман (Dmitry Riman), Илья Руднев и Вероника Стрелец, чей рассказ о бирюзовой трансформации в самарской компании Бизнес-гарант - замечателен. Особенно прекрасны два момента. Во-первых, не было целью непременно провести трансформацию, были потребности бизнеса, для которых выбрали это средство. Во-вторых, в результате появилась мозаичная компания, части которой находятся на разном уровне, в соответствии и с бизнес-окружением и представлениями самих сотрудников, но при этом всем открыта информация и пути развития.

Картину будущего третьей промышленной революции разворачивает Петр Щедровицкий, курс лекций которого в 2015 окаал на меня очень большое влияние. Но я благодарен Петру не только за курс лекций, но и за серию игр в Бекасово, в которой я несколько лет принимаю участие. Грандиозность замысла и поставленных целей, их временные горизонты заставляют по-иному взглянуть на собственные цели. А интеллектуальная работа дает новые идеи, за что я благодарен участникам нашей группы Игорь Злотников (Igors Zlotnikovs)Кирилл Гайдамака (Kirill Gaydamaka) и вообще всем участникам игр. Отдельная благодарность - Максим Осовский, за приглашение к участию в серии игр в его группе.

И, говоря о СМД-сообществе, я хочу сказать отдельное спасибо Борис Островский, который впервые меня познакомил с СМД-схемами, а главное - научил самоопределению, научил смотреть на себя как на проект, который ты сам развиваешь. Без этого точно не было бы моего нынешнего этапа развития. Потому что одного желания - мало, для осуществления желания надо действовать. То, что у меня получилось узнать, я пробую передать другим, в этом году как раз появился доклад про схемы самоопределения.

Но вся эта активная жизнь в новой ветке своего развития не отменила активного участия в IT-сообществе, а наоборот, довольно тесно интегрируется с ним, потому что многие темы естественным образом присутствуют в обоих пространствах. И тут я благодарен довольно тесному сообществу, которое организует IT Global Meetup в Питере, конференции SECR, AnalystDays, SQAdays, ProfsoUX, WIAD, и новую коференцию ТочкуСборки. Хотя это - отдельные конференции, и каждую из них делает свой коллектив, персоналии сильно пересекаются и преимущественно находятся в Питере - такая уж аура у этого города :) Отдельно хочу назвать и сказать спасибо Алексей Фёдоров (Aleksei Fedorov) и Тая Толстунова (Thaya Tolstunova) за активные эксперименты над форматом выступлений, Анна Абрамова (Anna Abramova)Anna GorbatenkoJulia KryuchkovaYuri VedeninДмитрий Безуглый (Dmitry Bezuglyy) Ирина Сурова (Irina Surova) за совместную работу и активное общение на самые разные темы, а также кураторам моих выступлений, с которыми мы активно обсуждали содержание и устраивали прогоны. Организаторам конференций Николай Пунтиков (Nick Puntikov) и Владислав Орликов (Vladislav Orlikov) - тоже мое большое спасибо. А еще я хочу поблагодарить организаторов IT-Spring Валерия Зайцева (Valeriya Zaitseva) за приглашение на конференцию в Минск, которое позволило мне не только выступить, но и услышать много замечательных докладов. И организаторов Meetup в Райффайзене по визуальным моделям Ksenia Ragozina И отдельное спасибо Sergey Omegian Kadomsky за его выступление на осенней AnalystDays с рекомендацией книги братьев Хиз "Ловушки мышления". Замечательно изложено!

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

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

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

На этом - все. В посте было упомянуто очень много разных событий, о которых можно прочитать в моем блоге, а выступления - посмотреть у меня на сайте.

А, нет, еще есть вишенка на торте. В этом году мы продолжили сотрудничество с Елена Смирнова (Elena Smirnova) и сделали еще один клип по песне Александра Суханова, за что ей большое спасибо. А еще - всем писателям, блоги которых с рассказами, сказками и историями я читаю в ЖЖ, включая Мария Бережная (Maria Berezhnaya)и замечательное сообщество txt_me, которое ведет Макс Фрай.

2017-12-16: Product manager и Product Owner

Сохраню здесь свой комментарий к посту Димы Безуглого на FB.

Agile Product Owner управляет задачами команды, Product Manager - решением проблемы клиентов. КЭП

Это все творческие вопросы. Ну, то есть с одной стороны правильно, с другой стороны, ДВА таких человека на одном продукте - точно не нужны. Сазерленд (в книге про Scrum) формулирует модель, в котором Product management - коллективный, стейкхолдеры, а задача PO - разобраться в их потребностях, value и приоритетах, и на основании этого сделать бэклог, и транслировать все это в команду. Поэтому у него там полная ставка и преимущественная работа вне команды. Scrum Guide все это формулирует скромнее и суше.

Понятно, что если на проекте есть хороший Product Manager, у которого есть vision продукта, то он заодно может выполнять функции Product Owner, или взять помощника, с которым поделить работу на разных горизонтах, стратегию и тактику, и назвать того PO чтобы выдержать терминологию, но это - несколько другое разделение труда. Дальше вопрос: если такого Product Manager как персоны нет - то что? С моей точки зрения, найти его - практически невозможно, правильно собирать коллективного. А вот тогда и возникает ключевая роль PO. Потому что, что бы там не накреативили участники коллективного Product Manager, продукт будет именно таким, которым его PO донес до команды, установив приоритеты. Именно поэтому он Owner.

2017-12-16: У меня появился телеграм-канал

Собственно, subj. У меня появился телеграм-канал https://t.me/mtsepkov. Наверное, поздновато, но лучше поздно, чем никогда, правда? Пока туда буду транслировать свой блог, как и на Facebook, а дальше посмотрим.

2017-12-10: Пиар ищет свое место в изменяющемся мире

В пятницу был на интересном мероприятии Дни PR-2017 в Москве. Интересно оно тем, что это не просто встреча профессионального сообщества. Российскому Сообществу по связям с Общественностью (РАСО), которое организовывает мероприятие — 25 лет, но они решили не праздновать юбилей, а наоборот, попробовать спрогнозировать будущее профессии пиарщика. Поэтому было два такта — аналитический, на который были приглашено много интересных спикеров из разных областей, и проектная, на которой рабочие группы пытались сформировать видение будущего. Аналитическая часть удалась хорошо, было реально много интересных докладов, о которых я напишу дальше. Проектная — несколько меньше, и об этом я тоже напишу — я думаю, тут та ситуация, в которой взгляд со стороны будет интересен. Если кратко, то они парадоксальны: как сказал Черчилль, генералы готовятся к прошлой войне, и это — наблюдается. Но любопытно, что одновременно эти же генералы ведут новую войну, новыми средствами — но сами же этого нового у себя не замечают :)

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

2017-12-04: online-конференция по управлению проектами - очень сильный состав спикеров

Pmonline-2017-11-photo.jpg

Чуть больше недели назад, 25.11 я выступал на бесплатной online-конференции «Управление проектами в малом и среднем бизнесе» http://pmconf.online/. Конференция собрала очень сильный состав спикеров. К сожалению, я смог послушать только вторую половину. Особенно хочу отметить доклад Вениамина Кизеева «Как собрать команду первоклассного проекта», в котором было очень много разных классификация и подходов, используемых для формирования команды.

Все материалы доступны на сайте конференции, Федор Афанасьев, который ее организовывал, сегодня их выложил. Смотрите презентации, смотрите видео. Мой доклад есть также у меня на сайте Agile для тех, кто хочет разобраться: что он дает для управления проектом и на какие современные вызовы отвечает (PMonline 2017-11).

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

« новейшие ‹ 20 более новых старейшие »