Викилоги

Специализация в IT все возрастает, и все они нужны в разработке. Раньше достаточно было разработчика широкого профиля вместе с аналитиком, потом появилась специализация на front-end и back-end. А сейчас есть специализации на каждую мобильную платформу, и в целом количество специализаций превышает ограничение численности эффективной команды 7±2. В посте была описана именно такая ситуация, и сейчас я пишу по мотивам обсуждения. Там был дан пример команды.

1. Аналитик
2. BackEnd разработчик
3. Разработчик АБС (Банковская система)
4. Веб-разработчик
5. iOs разработчик
6. Android разработчик
7. Тестировщик

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

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

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

Выношу из поста на FB, чтобы сохранить ссылку на статью

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

Как ломаются сложные системы

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

Из репоста Никита Зимин Вот это просто вау. Очень близко к тому как я представляю себе работу даже не столь уж сложных систем как например какое-нибудь SaaS приложение.

Почему я пишу в блоге о том, что Ивар Якобсон приезжает на SECR? Потому что Ивар приезжает второй раз, он уже был в 2013 году и я тогда был на его мастер-классе. И меня поразила энергия, с которой он проводил мастер-класс в свои 70+ лет - это была не просто лекция гуру, это была работа в группах, и он подходил, спрашивал о ходе обсуждения и результатах в конкретной группе (понятно, что участники обсуждали по-русски), давал оценки. А еще меня восхищает в Иваре концептуальное мышление, и, что более важно - его способность к обновлению, способность отказываться от своих же признанных теории и кооперативно(!) делать новое.

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

По мотивам моего поста в FB

Вчера выступал в #pmoclub, рассказывал об эволюции проектов и руководства ими, тех изменениях которые приносит Agile, и которые придут следом. Было много слушателей, интересное общение.

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

Вынесено из FB, фото Андрея Малахова

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

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

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

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

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

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

• Краткое описание уровней Спиральной динамики — мое короткое описание с примерами из повседневной работы
• Марк Розин «Успех без стратегии» как книга для бирюзовых организаций — мой конспект книги для тех, кто еще ее не читал.
• Путешествие по спирали — статья Марка Розина, где он сопоставляет корпоративные культуры уровням Спиральной динамики. Именно он придумал соответствующие уровням названия культур. соответствующих уровням: принадлежности, силы, правил, успеха, согласия и синтеза.
• ПиР-2017 — Россия успешно вступает в мир третьей волны — мой отчет о ПиР.
• Видео выступления Марка Розина на youtube

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

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

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

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

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

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

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

Фото на FB - Владимир Воловиков

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

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

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

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

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

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

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

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

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

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

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

Фото на FB - Анна Абрамова

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

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

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

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

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

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 и классических методов.

UPD-2. Копии статей на сайте Agile - ответ на вызовы нового мира и Scrum - революционный метод управления проектами

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

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

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

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

Анонс на FB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оригинал фото

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

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

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

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

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

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

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

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

Такой взгляд представляется достаточно интересным, чтобы его рассмотреть подробнее, так как он позволяет заметить определенные закономерности развития. Что я и сделаю далее, используя общие положения и иллюстрируя их собственным примером — развитием сотрудника в незнакомой организации, в которую он пришел на проект. Пример выбран потому, что меня преимущественно интересует развитие организаций и человека в них, а не личное развитие или развитие общества в целом. При этом я буду опираться не только на книгу Дона Бека и Криса Кована и другие материалы по спиральной динамике, но и на книгу Фредерика Лалу «Открывая организации будущего», посвященную организационному развитию, в которой он дал собственную интерпретацию уровневой схемы. Я знаю, что уровни Лалу несколько отличаются от уровней спиральной динамики (и даже кратко остановился на этом в своем конспекте книги Фредерика Лалу), и помню об этих отличиях во время написания статьи.

На этом окончим введение и перейдем к подробному рассмотрению.

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

Пост на FB

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

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

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

Пост на 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 с третьей промышленной революцией.