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

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

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

Ранее был на 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

И у меня есть личный ЖЖ, там путешествия и другие мысли вне ИТ.

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


2017-09-19: маятник централизация - децентрализация как фактор развития

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

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

В результате получается вот такая схема.

Централизация-децентрализация и культуры Спиральной динамики (Марк Розин).pdf

Эту схему Марк показал в своем выступлении на ПиР-2017, рассказывая о трансформации РосАтома. Которая стартовала в 2005 в красной культуре силы, прошла через централизацию, получив синюю культуру правил примерно к 2011, затем — сильные дивизионы оранжевой культуры успеха к 2016 и сейчас начинает переход к зеленой культуре согласия — эффективно сотрудничающим дивизионам.

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


Источники для интересующихся

2017-09-17: Руководитель проекта - менеджер или специалист?

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

Лучше всего на этот вопрос ответ дал Scrum — он разделил эти компетенции, возложив предметную компетенцию управления продуктом на Product Owner. Произошло это в условиях жесткого дефицита руководителей проектов разработки, спровоцированного появлением персоналок: компьютеры стали доступны среднему и мелкому бизнесу, но софта — не было. И, оказавшись перед лицом проблемы редкого совмещения предметных и менеджерских компетенции, отрасль нашла выход, отбросив идеализированные представления классического управления проектов, который как раз настаивает на совмещении обоих компетенций в одном человеке.

При этом сразу был сделан второй шаг: менеджерские компетенции жестко разделили на три: (1) область самоорганизации команды, (2) область помощи команде в организации со стороны Scrum Master, и (3) область менеджера следующего уровня и специализированных служб. И тем самым заблокировали микроменеджмент прямого управления. доказавший еще тогда свою неэффективность, но продолжающий до сих пор оставаться практикой во многих компаниях — не взирая на все призывы теории управления.

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

Отмечу, что вопрос — очень старый, британская школа воспитания джентльменов еще в 19 веке утверждала, что джентльмен может руководить чем угодно, и ему не надо в этом разбираться. Оттуда этот же подход унаследовали Штаты, и программа MBA его воплощает. А вот немецкая школа утверждала, что лучший руководитель — специалист в предметной области, и германская армия и промышленность именно так обучала свои кадры, тоже с 19 века. И Российская империя, а затем СССР в значительной мере воспринял именно немецкую точку зрения.

Вынесено из моего комментария к посту на FB, где была приведена статистика и мнений, и достаточно много народа высказывало свою точку зрения.

2017-09-14: Точка сборки - аналитики Петербурга сделали замечательную конференцию

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

Я сам выступал с докладом Роли в проекте: как поделить поляну ответственности (ТочкаСборки-2017), в котором свел воедино и переосмыслил рассказываемое на эту тему на разных конференциях.

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

Пост Алексей Фёдоров жжет на #ТочкаСборки - великолепный интерактив, вывод аудитории на рассказ историй!

Аналитик - это кот ученый на дубе.

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

А серьезно - хорошая картинка про состояние потока, эмоции от задачи в координатах мастерство-сложность.

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

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

Пост #ТочкаСборки Григорий Печенкин - замечательная схема графической работы с ожиданиями и целями системы. Рисуем в формате, аналогичном диаграмме use case проблемы. которые должна решить система или цели, которые достигнет, а дальше - те функции, которые должны обеспечить решение задач. И в целом в докладе множество простых интуитивно-понятных схем, не перегруженных нотациями, которые легко использовать в работе. И в конце он показал всего 12 элементов, которых, с его точки зрения, достаточно для 80% случаев! Супер!

Пост #ТочкаСборки Николай Соколовский - добротный рассказ о реверс-иншиниринге структуры данных. Актуальная и тяжелая задача в наше время, когда продукты ставятся не на пустое место, а поверх самописных или заказных разработок, сделанных 5-10 лет назад, в которых документации часто не было изначально. И есть только работающее приложение с базой данных, которые накоплены и не должны пропасть, а должны быть перегружены в новую систему. Много практических приемов и советов.

Ну а это - фото с afterparty.

2017-09-12 Удовлетворенность стейкхолдеров - два разных смысла

#ТочкаСборки Обсуждая в кулуарах «удовлетворенность стейкхолдеров» выяснили, что у этого понятия есть несколько смыслов. А именно, многие рассматривают его в контексте client relationship, как позитивные эмоции и впечатление от сотрудничества. Ее компании, ориентирующиеся на долговременное сотрудничество, измеряют давным давно — через анкеты или другими способами. А вот удовлетворенность стейкхолдеров результатами проекта — это нечто принципиально иное. Когда стейкхолдеры начинали проект, у них были некоторые ожидания, связанные с тем, как этот проект повлияет на их бизнес, улучшит его. И вопрос удовлетворенности — именно о том, изменился ли бизнес удовлетворительным образом. В ходе проекта эти ожидания, естественно, могли измениться и измеряется относительно текущим ожиданиям, вернее, относительно того момента, когда они еще были позитивны, и «проект изменил бизнес» не сменилось на «опять не получилось».

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

Это было опубликовано на FB и вызвало обсуждения, в частности в группе Управления проектами

2017-09-09: ПиР-2017 - Россия успешно вступает в мир третьей волны

Пять дней я был на фестивале Практики и Развитие. Если кратко формулировать главный для меня вывод, то фестиваль показал, что российский бизнес достаточно успешно вступает в новый мир, мир третьей волны Элвина Тоффлера. Что меня очень радует, и дальше я расскажу об этом подробнее. Собственно, фестиваль так и назывался «Настоящее будущее». Понятно, что доклады на фестивале были не только об этой теме, было множество различных практик личного и корпоративного развития, потому что фестиваль — это грандиозная встреча тренеров, коучей, косультантов и бизнеса. Но об этом я расскажу меньше, потому что у фестиваля — 14 треков, а я физически мог быть только на одном. А еще отмечу, что у фестиваля — замечательная энергетика, я это ощутил в прошлом году, когда был на ПиРе впервые, и именно поэтому не сомневался, что ехать надо на весь фестиваль, а не отдельные дни. И это — оправдалось.

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

2017-08-28: Agile - ответ на вызовы нового мира

Agile появился как способ организации IT-разработки, потому что способы, применяемые в других отраслях, в IT не сработали. А произошло это потому, что IT оказалась первой отраслью, в которую пришли вызовы третьей промышленной революции, и Agile оказался удачным ответом на них. Сейчас эти вызовы идут в другие отрасли, и для ответа логично обратиться к опыту IT. Об этим вызовах, самым известных из которых Business Agility - моя новая статья на портале Национального банковского журнала http://nbj.ru/news/arxiv/2017/08/28/agile-otvet-na-vyzovy-novogo-mira/ - для банков тема Agile сейчас актуальна.

UPD. Вышло продолжение статьи http://nbj.ru/news/arxiv/2017/09/05/scrum-revoljutsionnyi-metod-upravlenija-proektami/, соотносящее развитие Agile и классических методов.

2017-08-19: Точка сборки - конференция аналитиков в Петербурге 09.09

Петербург замечателен своими IT-сообществами, которые объединились в PiterUnited и проводят общие встречи - IT Global Meetup трижды в год. И сами сообщества развиваются, и вот сообщество аналитиков проводит свою однодневную конференцию Точка сборки в субботу 09.09. Два трека, один - доклады, второй - мастер-классы.

TochkaSborki-2017-09.jpg

Я тоже там буду выступать вместе с другими замечательными докладчиками с докладом Роли в проекте: как поделить поляну ответственности, который развивает серию моих докладов про разделение ответственности (HappyDev-2013, AnalystDays-2015, SQADays 2016). Приходите!

P.S. Конференция - платная, но не дорогая. Потому что аренда и организация стоит денег. А ранняя регистрация дает большую скидку.

2017-07-23: Agile и игрофикация - за каким менеджментом будущее?

Это - название моего выступления на Российском игровом форуме «Южный РИФ-2017» 03 августа 2017.

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

Agile появился в нулевых, как способ IT делать проекты, в которых определяющим критерием успеха является человеческий фактор, а производительность умелого и увлеченного сотрудника на порядок (реально, в 10 и более раз) превышает того, кто относится к работе формально. Это было замечено еще в 1980-х и обосновано Томом ДеМарко в книге «Человеческий фактор» (1987). Регламенты и процедуры убивают вовлеченность на корню, и Agile появился как способ оградить сотрудников от них. сохранить их увлеченность и мотивацию, но при этом делая прозрачным целенаправленное продвижение к цели, и для самих сотрудников и для их руководства, и для заказчиков. Появление персоналок, кратно увеличившее потребность в разработчиках, предопределило успех Agile в IT. А сейчас он идет в другие отрасли, потому что вовлеченность в работу и критическая чувствительность к человеческому фактору для успеха деятельности все больше и больше проявляются во всех отраслях.

Игрофикация, как не странно, тоже базируется на достижениях IT. Но не как способ организации работ, а благодаря развитию компьютерных игр. Человек в игре - вовлечен, часто забывает о времени и вкладывает громадные усилия для достижения цели, совершенно не считая это работой. По мере развития индустрии появились модели игроков, обеспечивающие успешное конструирование вовлекающих игр. И следующий шаг - превращение работы в игру, создание такого игрового контекста, чтобы действия человека на работе отражались как продвижение в игре. Я слежу за развитием игрофикации с AgileDays-2013 и (AgileKitchen, и явно позиционировал ее как способ менеджмента будущего.

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

2017-06-25: Дневники ГосAgile - много интересного на очередной встрече

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

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

2017-06-13: В пятницу провожу семинар по Agile в МГУ

В эту пятницу 16.06 на площадке Экономического факультета МГУ я буду проводить семинар по Agile для бизнеса - как он устроен, какие бизнес-задачи может решать, как это укладывается в общую картину развития организаций и общества, которую дает Спиральная динамика. Это будет расширенная и развернутая версия моего доклада Agile - ответ на вызовы третьей промышленной революции (есть видео), ориентированная на тех, кто с Agile не знаком, хочет разобраться в сути, а в материалах видит много пиара. Для знакомых с Agile тоже будет много ценного и интересного. Приходите. Это бесплатно, но требуется регистрация.

2017-06-06: ProfsoUX-2017 - неожиданный подарок

На конференцию ProfsoUX я попал практически случайно, потому что Usability и UX — не моя специализация. Просто на WIAD при розырыше билета громко пошутил, что билет будет не на участие, а на выступление — и тут генератор случайных чисел выдал мой номер анкеты. К таким знакам мироздания необходимо прислушиваться. И в ответ мир дарит замечательные подарки.

Но за подарки — надо честно платить, поэтому сам я тоже выступал Сотрудничество с корпорациями: рецепты из практики — рассказывал, как вести проект с корпорациями и государственными заказчиками. Многие из них сейчас заинтересованы в Usability и UX своих приложений, особенно публичных сервисов. Но при этом привыкли работать совершенно иначе, чем коммерческие компании и стартапы, и на первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно и, более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. И я рассказывал о нашем опыте построения такого сотрудничества.

А теперь о подарках мироздания.

Оригинал на FB

На конференции я услышал совершенно замечательный доклад Кирилла Улитина «Brain Computer Interface: Залезть человеку в голову», о котором теперь много рассказываю. Про разработку нейроинтерфейсов известно давно, но, оказывается, она сейчас вышла на принципиально новый уровень. Появилась платформа Open Brain Computer Interface (Open BCI). Платформа представлет собой устройство, которое снимает сигнал с датчиков и проводит первичную обработку — альфа-бета и другие волны, эмоции, сосредоточенность, улыбки, моргание глаз и движение бровей и многое другое. А дальше поверх этого ты пишешь собственный обработчик. Аппаратная часть — дешевая, более того, датчики ты покупаешь в необходимом для твоих задач количестве — и ее можно было увидеть на голове докладчика во время выступления, такой забавный пластмассовый каркас с датчиками. А на ее основе можно писать любые приложения. например, управление мышкой движением бровей или глаз. которые снимаются прямо с мозга. Кирилл рассказывал про конкретное приложение, которое он на основе Open BCI сделал — использование информации для оценивания реакции при UX-тестировании интерфейсов. Дело в том, что если респондент фиксирует свои реакции самостоятельно, то картина восприятия нарушается, это известно. А тут получаются непосредственные реакции человека. Видео конференции уже выложено на страницах докладов, так что можете посмотреть на эту штуку живьем. А на конференции Кирилл давал желающим примерить :) И сам ходил в ней не только на своем докладе, но и сидел в зале — вот он на фото недалеко от меня сидит.

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

Был интересный доклад Эрика Райса, одного из классиков UX, автор «Usable Usability». Он показывал, как смотреть на usability широко, не только в IT — на примере Петербурга, отелей и других объектов. А в конце бонусом — был большой набор истории инфографики из старинных книг.

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

2017-06-02: SQAdays-21 (Москва май 2017) - зрелая конференция зрелого сообщества

Конференция SQAdays-21 прошла 26-27 мая в Москве. Это зрелая конференция зрелого сообщества тестировщиков. Которые уже понимают сложность профессии и необходимость выхода за узкие функциональные границы. Об этом свидетельствует много докладов, в которых достаточно большое внимание уделялось экономике проекта и достижению бизнес-целей. Например, в докладе Ольги Николаевой о разработке автоматических тестов: надо оценивать затраты на постановку автотестов, на процесс их поддержания и сопровождения, сравнивать с затратами на ручное тестирование. Экономическая составляющая — не единственное основание для автоматизации тестирования, time to market может быть важнее, но стоимость должна быть определена и оправдана с точки зрения бизнеса.

Зрелость отрасли показывает и круглый стол по тест-менеджменту с характерным названием ТЕСТ-менеджмент или тест-МЕНЕДЖМЕНТ. Участники четко формулировали, что разделяют управление — приоритеты задач, обеспечение time to market и работу с командой — командообразование и обучение. Первое отнесли к менеджменту, и его как раз должен делать тест-менеджер, а второе — к лидерству, и ее должен делать тест-лид, вместе с обучением профессии тестировщика, командообразование от профессиональных навыков большинство не отделяло. А вот у выступающих из зала компетенции менеджмента и лидерства часть объединены, при чем выявляется это только после наводящих вопросов модератора Леши Федорова, который приземлял тезис о том, что «лидер должен вести за собой» на конкретные обязанности, и получив в ответ «определять приоритеты, следить за выполнением обязательств» спрашивал «а где здесь лидерство?». Еще надо отметить убеждение ряда участников из зала, что тестировщики не способны определить приоритеты и вообще смотреть на задачи проекта целостно, с учетом time to market проекта, это способен только менеджер. Аргументировать это у выступающего не получалось, так что речь может идти о догме. А может — о жизненном опыте, в котором этот тезис ни разу не опровергался практикой. Совсем другой взгляд высказывал Александр Александров, старейший из российских тестировщиков: «Все люди делятся на тестировщиков и фуфло. Тестировщиков — больше, поэтому они могут справится с любым фуфлом.» Но, независимо от высказываемых взглядов конкретных участников, уровень дискуссии в целом, различие различных аспектов управления явно говорит о высоком уровне понимания управления в профессиональном сообществе, свойственном зрелым отраслям и зрелым участникам. А основной вывод круглого стола для участников заключается в том, что никакого единственно правильного менеджмента не существует, многое зависит от контекста проектов и компаний. Но при этом конструкция разделения ответственности должна строится осознанно и на достаточно четко понимаемой поляне обязанностей.

Я сам выступал на конференции с докладом Самоопределяйся технологично!, в котором рассказывал о собственной сборке схем, которые сам использую для самоопределения. Почему я решил выступить по этой теме и именно на конференции тестировщиков? Дело в том, что тестировщики за 2-3 года проходят начальную стадию набора опыта, а далее могут развиваться в очень большом количестве векторов — автоматизация, DevOps, менеджмент, usability, аналитики… И это для меня — не теоретическое знание, а опыт прошлых конференций, вопрос самоопределения стоит для очень многих участников. Поэтому я решил рассказать именно на этой конференции. А сама тема возникла для меня потому, что, с одной стороны, вопрос самоопределения для меня самого актуален, а с другой — из взаимодействия с сообществом СМД-методологов у меня появилась сборка схем по теме. А выступление — это такой способ проявления и закрепления практики, потому что в ходе подготовки кладешь на схеме не только свои кейсы, но и чужие. При этом конструкция — оригинальная, в публичных источниках ее нет, поэтому если для вас вопросы самоопределения актуальны — смотрите доклад. После доклада был BarCamp и обсуждения в кулуарах, и многие говорили, что схемы — полезны и навели на размышления.

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

На этом я завершаю краткий рассказ про SQAdays, для подробного, увы, не хватает времени. Там было много великолепных докладов...

2017-05-24: Спиральная динамика в квадрантах Уилбера

Опубликована моя статья Спиральная динамика в квадрантах Уилбера
Спиральная динамика в квадрантах Уилбера-pic1.png
Спиральная динамика в квадрантах Уилбера-pic2.png

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

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

Я написал об этом статью, и она сегодня опубликована на профессиональном портале интегрального подхода «Эрос и Космос» http://eroskosmos.org/spiral-dynamics-in-wilberian-quadrants/

2017-05-19: Моему сайту - 3 года

Пост на FB

Моему сайту уже 3 года. Или только 3 года. До этого времени был собственный блог, ему чуть меньше 7 лет - сначала на http://uml2.ru, потом на SoftwarePeople (портал закрылся), потом на http://lib.custis.ru. А три года назад я решил собрать на одной площадке не только блог, но и другие материалы. И постепенно на сайте формируются сборные странички по разным тематикам - IT-архитектуре, Agile, Спиральной динамике, СМД-методологии. И я слышал достаточно много отзывов о том, что материалы сайта - очень полезны. И я чувствую, что правильно и своевременно не просто вести сайт и репостить в facebook о новых материалах, а продвигать и позиционировать, и, возможно, создавать тематические страницы контента в FB. Только это - отдельная область компетенций и для грамотной работы - нужен специалист...

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

2017-05-15: Про конференции разработчиков и IT Global Meetup

Facebook напоминает про старые ссылки. Интересно заглядывать на 5 лет назад, читать что думал про развитие отрасли тогда, и как оно реально пошло. И понимать, что не так уж и ошибался :) Правда, страница по ссылке уже недоступна, потому что блоги uml2.ru за это время переехали на другой хостинг и ссылки поменялись. Но эта заметка доступна у меня на сайте http://mtsepkov.org/ADD-2012

Это была третья из серии конференций Application Development Days, и, как оказалась - последняя. Универсальная конференция разработчиков российского уровня плохо собирают аудиторию, хорошо живут нишевые, ориентированные на конкретные стеки технологий - .Net, Java, Web-разработка. А SoftwarePeople и ADD - прекратили работать. Остался #SECR, который по-прежнему развивается без специализации, и даже расширяет тематику, приглашая ведущих зарубежных спикеров и давая возможность заглянуть за границы своей специализации, посмотреть широко. В этом году он впервые будет в Петербурге, а не Москве.

Зато за это время появилось много региональных конференций по всей стране, достаточно широкого профиля - SECON, Стачка, CodeFest, HappyDays и другие, я перечислил только те, где сам был. А в Петербурге появился #ITGM - IT Global Meetup, который три раза в год собирает IT-шников всех специализаций. Программу готовят сообщества из PiterUnited, каждое - по своей тематике, но проходит это все в общем пространстве и там тоже можно заглянуть за рамки своей специализации, посмотреть широко. Вчера прошел юбилейный, десятый.

Там был крайне интересный для меня доклад Павла Аргентова про подход Unikernel (http://unikernel.org) - возвращаешься в те времена, когда памяти было мало, а процессоры - слабые, и операционки не весили жуткие гигабайты, и смотришь на новые подходы для такой разработки... И еще несколько докладов, круглых столов и дискуссий, включая обсуждение изменений в менеджменте на островке тестировщиков, где я активно участвовал в дискуссии. И много-много содержательного общения.

Пост на FB

2017-05-08: Питер Друкер "Энциклопедия менеджмента" - воспоминания

Пост на Facebook, запоминаю в блоге

Facebook напоминает о прошлом и выдал мне этот пост 2013 года с отзывом об Энциклопедии менеджмента Питера Друкера.


Отзыв о книге, который здесь цитируется - был в моем блоге на портале SoftwarePeople, а сейчас перенесен на мой сайт http://mtsepkov.org/DruckerBook Сам портал закрыли со всем контентом, и вместе с одноименной конференцией. Обидно, однако.

А по содержанию с того времени мое понимание сильно продвинулось. Осенью того же года я открыл для себя модель Спиральной динамики, которая объяснила мне логику развития менеджмента и Agile как частный случай, и уже в 2014 начал делиться этим знанием на IT-конференциях (http://mtsepkov.org/SD). А в прошлом году это еще вошло как составная часть в большую картину развития общества, которую на своих лекциях развертывал Петр Щедровицкий (http://mtsepkov.org/PG-srt).

Только, отмечу, что вслед за Тоффлером я склонен полагать, что приходит не просто очередная промышленная революция, а происходит слом индустриального общества, а вместо него рождается общество самореализации, с соответствующим изменением мышления. О чем я и рассказываю в последних докладах про Agile (http://mtsepkov.org/Agile). Вот такой получился сборник автоссылок вместо воспоминания :) Но, кстати, отмечу, что такой целостной картины развития другие не дают, хотя фрагменты есть во многих докладах. Например, на http://ITSpring.by Angel Diaz-Maroto в рассказе о лидерстве в Agile начал именно со связи Agile с третьей промышленной революцией.

2017-05-07: Мое знакомство с СМД-методологией

Пост на Facebook, запоминаю в блоге

Facebook напоминает о прошлом и выдал мне этот пост годичной давности, в котором я делился докладом на AnalystDays-2016 про схемы СМД-методологии.


Примерно пять лет назад я начал знакомиться с СМД-методологией - с нашей компанией начал работать Борис Маркович Островский, один из учеников Георгия Петровича Щедровицкого. Постепенно осваивал ее схемы, чему способствовало участие в играх у Петра Георгиевича в Бекасово. И вот год назад, на #AnalystDays рассказывал об этих схемах аналитикам. Потому что там наработано очень много ценного про устройство мира, и это имеет смысл использовать в практической деятельности, а не просто интересоваться как частью истории человеческой мысли. В частности, в этом году на #SQAdays у меня будет доклад по самоопределению с продолжением на баркемпе, в основу которого легли три схемы: две были в прошлогоднем докладе, а третья - схема самоопределения из лекций Петра Георгиевича по третьей промышленной революции, которые я слушал, конспектировал и публиковал конспекты в прошлом году. Когда хочешь в чем-то практически разобраться - сделай об этом доклад :) Так что приходите слушать!

2017-04-29: инженерная культура и ее ограничения

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

Agile - ответ на вызовы третьей промышленной революции - Цепков CUSTIS.pdf

То, что софт нельзя производить по регламентам и правилам было осознано на опыте проектов еще в 1980-х, и об этом есть классическая книга Тома ДеМарко «Человеческий фактор». А несколько позднее, в 1992 в статье What is software design (перевод) Ривз объяснил, почему так, в чем именно отличается разработка ПО от создания самолетов, которые у Боинга не только собираются, но и проектируются по регламентам, и почему вследствие этих отличий производство софта по регламентам не работает. Схема этого объяснения - справа.

Но инженеры — они ведь умные. Это у других не работает, а они придумают так, что заработает. И группа гуру во главе с Иваром Якобсоном (автором use case и соавтором UML) придумала RUP. Но и у них не получилось? этому есть много примеров и статистика. Конечно, всегда есть объяснение, что это не получилось по причине неправильного применения регламентов. Но квалифицированные инженеры — они осознают свои ошибки, и для меня лично достаточным основанием является факт, что практически все ведущие авторы RUP, включая самого Ивара, достаточно быстро приняли Agile, который был следующим тактом развития, и участвуют в его развитии.

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

И, что интересно, сейчас регламенты перестают работать не только в IT, но и в других отраслях. Почему так — написал другой классик, Питер Друкер в книге «Менеджмент. Вызовы XXI». Анализируя изменения в характере деятельности, связанные с повышением роли знаний, он выделил возникающие при этом вызовы, на которые традиционный менеджмент не может ответить — а они непременно придут. И они уже пришли. Зафиксированные на глобальном уровне тренды Business Agility и Цифровизации обесценивают культуру правил, делая это, однако, по-разному.

Обо всем этом я буду рассказывать сегодня в своем докладе «Agile — ответ на вызовы третьей промышленной революции», приходите. Кто был на AgileDays - тоже приходите, с тех пор доклад был доработан и дополнен.

Кстати, сама конференция мне понравилась. Разработчики разбираются с софт скилл, основательно, в том числе - добираясь до старых теорий, и я узнал про психоделическую революцию Тимоти Лири и его подходы к описанию личности в рассказе Ярополка Раша, и про связь конституции человека с его психозами в модели Эрнста Кречмера, о которой рассказывал Юрий Сорокин. Я, кстати, по ней - маниакально-депрессивный шизоид. Но позитивный. На этом, пожалуй, закончу.

2017-04-19: Новое - хорошо забытое старое (про диаграммы учета)

Пост на FB

Для проектирования учета и фиксации его правил при разработке приложений мы в компании придумали удачное фирменное средство — Диаграммы учета и успешно применяем сами. И профессиональные бухгалтеры, с которыми мы взаимодействуем, тоже проникаются идеей графического изображения и начинают использовать при проектировании учетной политики. Я даже писал об этом в профессиональном журнале «Бухгалтер и компьютер» Когда всем понятно, а другие материалы можно посмотреть в Категория:Диаграммы учета. Никто из профессионалов не рассказывал нам, что у бухгалтеров аналогичная нотация уже есть, и в книгах я ничего не видел.

Поэтому, когда примерно год назад Максим Осовский прислал мне фотку из книги Леонтия Бызова «Графические методы в планировании, статистике и учете» (1940), на которой изображен план счетов горнодобывающего предприятия, я очень заинтересовался.

Леонтий Бызов. План счетов предприятия.jpg

Леонтий Бызов. Обобщенный план счетов предприятия.jpg

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

А еще Бызов пишет, что графическая нотация для планов счетов — не его изобретение. Он ссылался на книгу Эйгена Шмаленбаха «Счетные планы». Эта книга была переведена в 1928 году и я ее тоже взял. Прочел, что схемы планов счетов были разработаны специально для обучения, увидел серию схем, одну из которых можно увидеть ниже. Фрагмент книги со схемами я отсканировал и публикую Файл:Эйген Шмаленбах. Счетные планы - фрагмент.pdf. Вообще у Шмаленбаха есть целая серия книг, но переведена на русский только одна.

Эйген Шмаленбах. Счетные планы, cхема J.jpg

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

Леонтий Бызов. Графические методы в планировании статистике и учете - фрагмент.pdf

Леонтий Бызов много занимался графическими языками, его биографию можно прочитать в очерке внука, тоже Леонтия, «Мой дед Леонтий Бызов», а в прошлом году я был на встрече, посвященной его работе по созданию графического языка.

А еще, что интересно, и на Шмаленбаха и на Бызова — достаточно много ссылок в рефератах и научных работах. И достаточно очевидно, что люди не читали оригинал, а пересказывают с чужих слов — потому что оригинал слабо доступен. А то и просто копируют в список литературы. С Бызовым вообще интересно — одна из его книг процитирована в статье «Графические методы» Большой Советской Энциклопедии, но фамилия названа с опечаткой, «Вызов» — так эта ссылка и кочует из работы в работу :) И Вы можете исправить это, проголосовав за оцифровку работ на сайте Ленинки: Леонтий Бызов, Эйген Шмаленбах

2017-04-15: ГосAgile - теперь официально

В эту пятницу прошло первое собрание группы ГосAgile, которая официально называется «Подгруппа по применению гибких подходов в государственных проектах рабочей группы по развитию проектной деятельности при президиуме Совета при Президенте Российской Федерации по стратегическому развитию и приоритетным проектам». Группа была официально запущена пару дней назад, как раз в день космонавтики :) Состав группы — очень разный, там собрались не только те, кто успешно применяет Agile, в том числе в государственных проектах, но и те, кто отвечает за формирование нормативной и методологической базы ведения проектов и, возможно, предпочли бы сохранение более консервативных подходов, однако не могут игнорировать изменения в мире. А также те, перед кем стоит задача масштабных изменений в отдельных сегментах государственного управления, и они смотрят на Agile как на возможное средство для проведения изменений и готовы ему учитьcя и адаптировать к реалиям государственных проектов. Поиому что, хотя кейсы применения Agile в госпроектах есть, и их даже довольно много, нигде не идет речи о применении чистых методов, везде строится достаточно сложная комбинация.

Disclaimer. Это - мои впечатления с заседания и они не являются официальным протоколом или пресс-релизом.

Собрание началось с формулирования направлений работы и ожиданий. Андрей Анатольевич Бадин, Заместитель директора Департамента проектной деятельности Аппарата Правительства РФ, рассказал о внешнем контексте — о других рабочих группах и их направления движения, в частности, методической группы. Основной стандарт будет гейтовый, в нем будет о контрольных точках, но не о методах их достижения. А по методам как раз работают другие подгруппы, в том числе новая подгруппа по Agile.

Далее были направления работы и ожидаемые результаты за год от Олега Качанова, Директор Департамента проектов по информатизации Минкомсвязи России, руководителя подгруппы. Затем была короткая презентация по Agile для выравнивания контекста от Ивана Дубровина, заместителя руководителя подгруппы. Иван начинал развитие ГосAgile еще в 2015 году, работая тогда в Минкомсвязи, и в ноябре 2015 во многом его усилиями прошла AgileKitchen на территории Аппарата Правительства, которая вывела это движение в публичное пространство еще до выступления Германа Грефа.

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

  • Продвижение будет идти по обозначенному набору тем, при этом список является открытым, и его даже дополнили прямо на встрече. По каждой теме есть годовой ориентир — чего хотелось бы достигнуть. В процессе он может изменяться — цель смещается по обстоятельствам.
  • Участникам было предложено определить интерес работы в одной из предложенных тем, обозначив уровень своего участия от максимального — готов самостоятельно создавать контент и участвовать во группы встречах между общими — до минимального, предполагающего только оценку материалов.
  • По каждому из направлений предложен вариант ожидаемого через месяц результата, который можно было скорректировать в обсуждении.
  • Раз в месяц будут общие встречи, на котором по каждой теме будет сообщение о достигнутых результатах и текущем статусе — демо, а также заявлен ожидаемый результат на следующий месяц.
  • А дальше — ожидается что внутри групп участники как-то сами соорганизуются вокруг общего пространства: trello для ведения задач, GoogleDocs для документов, telegram для сообщений и GoToMeeting для конференций. Использование открытых платформ на текущем этапе предполагается оправданным: закрытых материалов не ожидается, а знакомые инструменты обеспечивают низкий порог входа.

Обозначены следующие темы работ.

  • Анализ зарубежного опыта — потому что он успешно применяется во многих государствах и хороший опыт полезно взять. При этом идут бурные изменения — и надо быть в курсе нового опыта.
  • Оценка действующих нормативов, предложения по их изменениям, взаимодействие с регуляторами. И здесь по обсуждению возникло два вектора: от нормативных документов и от проблем в реальных проектов.
  • Определить границы применения гибких методологий, с предложением начать от тех точек, где он эффективнее других (что требуется обосновать).
  • Методические рекомендации по применению гибких методологий. Как в существующих условиях нормативного регулирования, так и в идеальном будущем — чтобы померить gap по нормативке и его устранить.
  • Вести и работать с пилотными проектами. Что интересно, Agile сейчас применяют не только у подрядчиков на госпроектах, но и в государственных организациях и органах управления. А пилотные проекты призваны как решать конкретные проблемы, так и расширять области применения, исследовать границы и методы на практике.
  • Мотивация в условиях применения гибких методологий. Понятно, что многие традиционные методы перестают работать, а они воплощены в нормативке и, главное, в сознании руководителей — и надо дать рабочую альтернативу применительно к условиям госуправления. Эта тема сформулировалась непосредственно на заседании. И это как раз пример реальной гибкости в работе.
« новейшие ‹ 20 более новых старейшие »