Викилоги

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

Зато уже через два месяца - следующая конференция SQAdays, на этот раз в Москве. И, может быть, кто-то прочитав этот отчет вдохновится, и решит съездить, а может быть даже сделает доклад! Организаторы этому всегда рады!

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

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

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

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

Итак, есть два принципа.

1. В организацию (сообщество, движение) объединяются люди, разделяющие общее целеполагание организации и готовые им руководствоваться в своих действиях.
2. Признается и уважается право любого участника на собственную интерпретацию целеполагание и действий, исходя из своего понимания целей.

Исходя из них формулируется примерно следующая процедура.

1. Каждый кому пришла в голову хорошая идея, реализация которой работающая на цели организации, может собирать необходимых ему единомышленников для реализации, включая обеспечение ресурсами и финансами, если они необходимы.
2. О планах по реализации информируются все потенциально заинтересованные члены организации (или вообще все).
3. Мнения - выслушиваются и принимаются во внимание. В том числе - предложения о возможном увеличении предполагаемой пользы. Но решение принимают инициаторы.
4. А вот возражения, касающиеся потенциального вреда от реализации плана действий из-за конфликта должны быть решены с поиском решения исходя из целеполагания движения в целом.
5. А дальше - реализация.

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

1. Форма инициативного предложения.
   1. Безличная форма "А не сделать ли нам ..." (продукт, мероприятие, ...) годится только чтобы "прощупать ситуацию" на предмет резких возражений. А дальше надо переходить к одной из двух позиционных форм.
   2. Я думаю, что будет полезно сделать то-то (для таких-то целей и в такой-то конструкции), но не готов сам это делать
   3. Я готов сделать то-то (для таких-то целей и в такой-то конструкции).
   • Может показаться, что 1.2 и 1.1 - это одно и то же. На самом деле, нет. Заявляя форму 1.2 говорящий показывает, что выдвигает идею, но готов предоставить инициативу другим. И это важно показать явно. И понятно, что для того, чтобы предложение реализовалось, кто-то должен высказать его в форме 1.3.
2. В ответ на предложение в форме 1.3. от других участников ожидается одна из трех позиций:
   1. Поддерживаю, готов участвовать
   2. Поддерживаю/не возражаю, но не готов участвовать
   3. Считаю неправильным, потому что ...
3. Понятно, что чтобы занять позицию могут требоваться уточняющие вопросы, на них инициатор должен ответить. Могут быть вопросы, на которые ответ труден (не продуман), и тут может быть встречный вопрос "а что для тебя от этого зависит?"
4. Позиция 2.1 рассматривается как предложение о сотрудничестве, и может сопровождаться идеями/условиями. Предложение не обязано приниматься, переговоры - разумно потом, когда сняты возражения про вред (2.3).
5. В позиции 2.3 важно отличить возражения от мнения.
   1. Мнение: "Такой продукт не найдет спроса...", "На такое мероприятие никто не придет..."
   2. Возражение: "Этот продукт будет конкурировать с уже существующим успешно распространяемым, которым я (возражающий) развиваю, и при этом не привлечет новых потребителей"
6. Как с этим работаем?
   1. С возражением - работаем, ищем решение win-win и возражающий должен сотрудничать, как я описывал в [[ранее. Что надо сделать, чтобы новый продукт не деструктивно конкурировал со старым, а привлекал новых потребителей? Изменить сам продукт? Доработать его маркетинговую стратегию? Что-то еще?
   2. Возражать можно только "за себя", из своей деятельности - нельзя искать решение "от имени другого".
   3. Мнение - лишь учитывается инициатором на его усмотрение. Участник, высказывающий мнение может как угодно оценить цели и план действий, которые предлагает автор инициативы. Но никто, кроме самих инициаторов, не является судьей, определяющим, правильно это мнение, или нет, хорошо ли сформулированы цели, или не слишком.
   4. Исключение - мнение, что реализация нанесет вред деятельности другого участника сообщество, который не проинформирован об этих планах.
7. Отдельно следует отметить работу с мнениями или возражениями, которые говорят о потенциальных рисках потерь, которые возникают при неудаче. Хорошо, когда это мнение обосновывается какими-либо прошлыми уроками организации или внешнего мира, о которых инициатор может просто не знать. Но часто оно является лишь некоторым экспертным заключением говорящего. И в этом случае его следует принять в рассмотрение и подумать: если говорящий прав и риск реализуется - как мы сможем раньше заметить поворот событий в нежелательную сторону и предотвратить или уменьшить ущерб? И учесть это в своем плане. При этом если говорящий говорит об ущербе позиционно, из своей деятельности в организации - то с этим работают совместно, как с возражением, а иначе - как с мнением.

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

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

Agile стремительно распространяется за пределы IT-отрасли, и это несет свои особенности. О них - в моей беседе с Мариной Симоновой на сайте AgileSpace. В публикации на FB идет обсуждение.

Для хорошего восприятия модель спиральной динамики надо объяснять на примерах. Иногда темы примеров предлагают сами слушатели чтобы приземлить модель на важную для них область, а заодно и проверить, насколько модель для автора рабочая, а не умозрительная. Из такого примера про различное понимание блага для города на разных уровнях родилась статья Счастье для всех – мелодии разноцветных струн Спиральной Динамики, опубликованная сегодня на портале Спиральной динамики. Спасибо Анатолию Баляеву за критику и помощь в работе.

Картинка и схема - из статьи.

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

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

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

Это если кратко. А теперь тоже самое в развернутом виде, на основе книги Фредерика Лалу "Открывая организации будущего", в которой тот подробно разбирает практики решения конфликтов в разных организациях (мой конспект) как сфокусированное изложение.

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

World Information Architecture Day-2017 в Петербурге - великолепный набор докладов, хорошо раскрывающих концептуальные вещи на мировом уровне. Программа встречи.

На открытии конференции было видео-обращение Richard Saul Wurman, который придумал понятие Информационной Архитектуры, а также конференции TED. По образованию и основной деятельности он архитектор. И он когда-то предложил сказал своим друзьям, которые занимались информацией и использовали слово design, что это - неправильное слово, потому что дизайн - это про то, как сделать, чтобы хорошо выглядело. А организуют информацию для другого, обеспечивая, чтобы у нее была хорошая структура. И это - архитектура, а не дизайн. WIAD в целом проводит и координирует Международный некоммерческий институт информационной архитектуры в третью субботу февраля во всем мире, в этом году был в 58 местах в 24 странах. В России - единственная площадка в Санкт-Петербурге, организует UX-сообщество вместе с SEMRush, за что им большое спасибо. Мероприятие проходит в третий раз, масштаб увеличивается - помимо основного трека докладов был второй трек и воркшопы.

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

После моего доклада был замечательный доклад Дмитрия Кудрявцева (СПбГУ) Онтологии и информационная архитектура: соотношение терминов и потенциал совместного использования с обзором способов организации онтологий и примерами конкретных онтологий, и соотнесения онтологий с информационной архитектурой.

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

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

После обеда был доклад Эдуарда Христусь про объектно-ориентированный дизайн (OOD), которые не следует путать с объектно-ориентированным программированием (ООП) - объекты в них разные. А также отличать от Domain Driven Design, Value Driven Design и других. В докладе OOD был представлен на основе создания сайтов, преждде всего - сложных и интерактивных, в которых объектов много. OOD предусматривает создание первым этапом модели объектов, которая обсуждается с заказчиком и часто структурирует коммуникацию, а далее позволяет параллельно запустить процессы детального проектирования (дизайна), разработки SEO (поисковой оптимизации) и наполнение копирайтерами сайта контентом. При обычном подходе SEO и копирайтеры могут подключиться только позднее, после проработки дизайна.

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

Но я был только на одном треке, и не мог услышать доклады, которые шли параллельно, и не знаю, что именно было на воркшопах. А там было интересно.

Лента конференции на Facebook - по тагу #wiad17, есть очень подробный отзыв Дмитрия Кудрявцева, фото моего выступления - из отзыва.

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

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

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

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

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

1. Люди информируют других о планах, способом, закрепленным в регламентах. Информация распространяется заранее, а решения принимаются на специальных управленческих встречах (но это не принципиально).
2. На самой встрече есть несколько стадий обсуждения решения: Представление автором - Уточняющие вопросы - Мнения по кругу без дискуссии - Обновление предложения автором - Возражения - Принятие решения
3. Мнения свободны, но они лишь принимаются во внимание.
4. Возражение - это фиксация конфликта интересов и они строго определены:
   1. Будет вред, которого раньше не было
   2. Вред подтверждается опытом либо критичен для работы
   3. Вред будет для назначения или обязанности из роли возражающего
5. Оба человека ведут переговоры (из своих ролей), чтобы найти решение win-win.
   1. В ходе переговоров возражающий должен раскрыть механизм вреда, чтобы были выявлены элементы, реализация которых нанесет вред и было место поиска компромиссов. Он не должен доказывать, что вред - будет, оценка - за ним, но вот механизм - должен показать.
6. Если возражающий отказывается от переговоров или не сотрудничает в генерации версий, его возражения не принимаются - отказ от сотрудничества делает их несущественными.
7. Стороны по согласованию могут позвать третьих лиц, которые расскажут прецеденты, помогут в генерации идей или дадут другие советы, но права на решение у них нет.
8. Если решение win-win не найдено, или найдены только компромиссные альтернативы, право выбора конкретной альтернативы - за инициатором. Который учитывает возражения, но принимает решение сам.

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

Те, кто хочет узнать подробнее, я отправляю к презентации Алексея Ильичева на AgileDays-2016, управленческая встреча описана на слайде 18, в видео с выступления это 23:40-28:50, больше 5 минут. Но, в общем, интересно посмотреть видео целиком. Также можно обратиться к сайту http://www.holacracy.org, на котором представлена Холакратия. Там материалы немного закопаны, но они есть, управленческая встреча описана в отдельной статье и в разделе 3.3 статьи 3 Конституции, а на этой странице есть раздел Implementation Resources со ссылками на другие материалы.

Кроме того, за практиками можно обратиться к книге Фредерика Лалу "Открывая организации будущего", в которой тот подробно разбирает практики решения конфликтов в разных организациях (мой конспект).

В третью субботу февраля проводится World Information Architecture Day - на площадках по всему миру. И в этом году, в третий раз сообщество UX SPb проводит его в Петербурге. Пока это - единственная площадка в России, но активные желающие могут присоединиться и организовать у себя тоже. Я ездил и выступал на нем в прошлом году, поеду и в этом.

Программа встречи опубликована, она интересна и мне лично нравится. Кроме меня, выступать будут Евгений Николаев (директор по маркетингу Яндекс.Деньги), Лара Симонова (Информационный архитектор в Collectrium, the Christie’s company; IA и ко-фаундер channelkit.com), Эдуард Христусь (основатель и руководитель производства в Func), Влад Аюкаев (Head of UX в Toughbyte из Хельсинки), Юрий Солоницын, Никита Ефимов и Юрий Веденин. Мероприятие - бесплатное, но регистрация - обязательна, и по опыту встреч Piter United места кончаются быстро. Так что думайте и регистрируйтесь!

Я буду рассказывать про построение моделей предметной области. 20 лет назад делали большие монолитные ERP, но сейчас нет сомнений, что гибкий и быстро развиваемый софт должен быть модульным, а объекты – инкапсулировать сложность. Тот же путь проходят системы понятий и модели, описывающие предметную область, и Domain-Driven Design перенес наследование, полиморфизм, инкапсуляцию, плагины и другие подходы к разработке софта на работу с онтологиями и моделями предметной области.

В это воскресенье 15.01 в 15:00 выступаю на Радио Медиаметрикс: Agile – это не процессы и готовые рецепты, это, прежде всего, новое мышление, новый mindset сотрудников, вовлеченных в работу.

Выступил. Видео на странице передачи. Очень удачно получилось.

Мой анонс на FB.

О чем именно я хочу рассказать.

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

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

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

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

1. Countinuous Integration и его современное развитие - Countinuous Delivery. Предназначен для поддержки системы инкрементальной разработки продукта вплоть до непрерывной поставки. Входит в базовый, гигиенический набор практик. Обычно включает исполнение автоматических тестов, но не обязательно.
2. Автоматическое тестирование. Обеспечивает стабильность продукта в условиях непрерывного развития и непрерывного рефакторинга - которые являются платой за гибкость разработки. Это - не обязательная практика, у нее есть альтернативы в виде технологичного ручного тестирования, либо применения практик работы с продуктом, ориентированных на качество кода (FDD, DDD), но является основой практик BDD и TDD, о которых дальше.
3. TDD - Test Driven Development. Разработку начинаем с тестов, это выделилось из XP. Эта практика обеспечивает входное тестирование на достаточность требований: может ли разработчик на их основе написать проверку функционирования системы как черного ящика? Если да - то значит требования достаточно ясные и определенные, и можно начинать продумывать конструкцию системы внутри. Опыт показывает, что слишком часто конструкцию начинают придумывать, не разобравшись с запросом пользователя, и в результате делают совсем не то. что нужно. Кстати, это встречается и в других областях, например. в маркетинге - люди начинают творить не задумавшись о желаемом результате. а лишь наметив область. А еще TDD способствует достаточно ясному и удобному для использования API.
4. BDD - Behavoiur Driven Development. В принципе является дальнейшим развитием форматов userstory, с одной стороны, и TDD с другой и нацелен на прозрачность коммуникации между разработчиком и заказчиком или конечным пользователем. Разработчик получает ожидания пользователя о поведении системы в достаточно формализованном виде, и это является таким контрактом на поведение системы как черного ящика. В пределе это описание на псевдо-естественном языке (формализованном подмножестве естественного), которое может быть играть роль автоматического теста системы.
5. FDD - Feature Driven Development. Придумал Джефф де Люка. Это организационная поддержка декомпозиции системы, базирующаяся и овеществляющая закон Конвея. Мы делим системы на кусочки и за каждым закрепляем ответственного и говорим, что API на границах является контрактом, изменение которого - предмет фиксируемой договоренности двух ответственных. Кусочков достаточно много, каждый ответственный за несколько, и при перегрузках можно передавать друг другу. Дополнительная фишка: ответственный - это обычно ведущий (senior, старший) разработчик, у которого есть 1-3 подчиненных, которых он растит (и которым можно передавать ответственность). Получается организация мини-команд, которая достаточно эффективна (почти каждый ведущий легко берет 1-3 подчиненных, в отличие от руководства командой), и мы получаем размер команды в 30-50 человек, или даже более, в зависимости от связности-модульности системы. Практика обеспечивает удержание архитектуры в условиях меняющихся требований и непрерывного развития. Она обеспечивается за счет мелкодисперсной структуры. При этом на архитектуру интеграции напрямую ограничений не накладывается.
6. DDD - Domain Driven Design, Эрик Эванс. Это - наиболее продвинутый метод работы с требованиями для сложных предметных областей.
   • DDD обеспечивает коммуникацию всех участников проекта с обсуждением системы не в виде черного ящика, как делает BDD, а раскрытием ее внутреннего устройства через построение модели системы, то есть позволяет заказчику обсуждать систему как прозрачный ящик. Для этого в рамках проекта создается специальный Единый Язык (ubiquitous language), описывающий предметную область, используемый для работы с требованиями и описания модели предметной области - которая является предметом согласования (контракта) разработчика с заказчиком. В отличие от обычной многостадийной формулировки требований с переводами (модель предметной области на одном языке, проект системы на другом, и так далее). При этом объекты модели должны трассироваться в код реализации, то есть перевод модели в код идет формально - что и позволяет говорить о представлении системы как прозрачном ящике.
   • А еще DDD сделал очень важный практический шаг в части работы с понятиями. Было замечено, что даже в относительно небольшой предметной области (например, банк или торговая компания) создать полную и непротиворечивую модель - сложно, так как разные люди (например, продажники, логистики и финансисты) используют термины по-разному. В рамках DDD вместо формального требования "единый словарь" эта проблема была осознана и предложено асимметричное решение. Единый язык создается не для всей области, а для некоторого ограниченного контекста (bounded context). Мы держим карту контекстов (context map). Но при этом, поскольку область одна, то в контекстах получается много пересекающихся понятий. И Эванс предложил использовать для них весь аппарат, накопленный ООП для объектов - наследование, полиморфизм, или наоборот изоляция и трансляция. Это реально круто, потому что снимает проблемные холивары о "правильных" системах понятий, которые возникали между специалистами, редко взаимодействующими между собой в деятельности.
   • И, наконец, DDD содержит большое количество шаблонов, применяемых для построения модели. При этом подходы и шаблоны ООП переносятся на уровень организации бизнеса.

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

А в заключении хочу отметить следующее.

1. Для сложных систем этого все равно недостаточно, там нужна координация работы с архитектурой и согласованное изменение составных частей. Для этого разработан SAF - Scaled Agile Framework, в котором достаточно много соответствующих активностей. Хотя он больше находится в организационной плоскости, нежели в инженерной.
2. Организационные и инженерные практики должны быть поддержаны инструментально. Здесь в базовый набор входит система контроля версий, например, Git, Task tracker, Wiki-системы ведения документов, средства непрерывной интеграции, автотестов и конвейера поставки продукта. Наглядные Scrum-доски, как правило, не заменяют, а дополняют их, хотя часто начинать можно с этих средств. А вот если вместо task tracker и Wiki-систем у вас почта и свалка документов на файловом сервере, то процесс работать не будет, независимо от гибких методологий.
3. Практики дополняют друг друга, собираясь как паззл в метод разработки. Применяемый метод должен быть адекватен проекту, а в пределе - каждый проект разрабатывается собственным адаптированным методом. И недавно разработан формализм для технологичной работы с индивидуализированными методами IT - разработки - OMG Essence. Но это уже тема отдельного поста.

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

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

И я хочу пожелать всем в Новом году плодотворной деятельности, счастья, здоровья и приятных сюрпризов. И еще раз поделиться со всеми самым неожиданным для меня результатом года прошедшего - песней, ставшей новогодней сказкой! https://youtu.be/28uQ6afWsxU

В посте - мое понимание услышанного и мысли по поводу. Цитаты неточные, смыслы - интерпретированные.

Последняя, 24-я лекция Петра Щедровицкого по СРТ была месяц назад, 25.11. Но я в этот день был на SQAdays в Минске - выступал с докладом и активно общался, а потом участвовал и выступал еще на нескольких мероприятиях. И только сейчас послушал лекцию и пишу эти заметки. В конце отчета будет мое самоопределение в новом мире 3 промышленной революции, а начну я с содержания лекции.

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

В кулуарах KM Russia рассказывал про Agile. Тема интересует многих — понять, что содержательно стоит за тем информационным шумам. И меня спросили: «А можешь коротко объяснить про Agile ребенку, или нет, ребенку-то можно идеальной лапши навешать, а объясни деду, которому 70-80 лет, который понимает разницу между лозунгами и реальным миром». Коротко объяснить Agile можно только через метафоры, и я начал вспоминать наработки СССР. Потому что Agile — это во многом про практическую реализацию тех идеалов.

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

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

Так что метафора получилось богатой и содержательной, она иллюстрирует очень многие аспекты. Ведь Agile — о том, как сделать способ работы, показанный в Карнавальной ночи, нормой производства. Там люди вынуждены экспериментировать, придумывать на лету. И это неизбежно, потому что они придумывают новый способ. А потом логика развития неизбежно приводит к следующему шагу — обмену эффективными практиками и их кристаллизация в виде методов работы. Что и было проделано в Agile, и сейчас мы имеем готовые методы — Scrum, Kanban, SAF и другие, и множество практик Lean по совершенствованию методов, и разных других практик. И все их можно использовать в своей работе, создавая собственный метод конструированием из готового, а не с нуля. И даже техника конструирования метода с согласованием разных практик, доработки метода через точки расширения, как это принято при разработке софта, тоже придумана — это OMG Essence. Что вовсе не ограничивает эксперимента и поля творчества — просто изобретая новый велосипед, целесообразно посмотреть на существующие и напитаться идеями. Тем более, что сейчас интересно строить не велосипеды, а автомобили, масштабируя Agile на большие корпорации и проекты. С этим пока не так радужно, хотя наработки и примеры имеются, и есть прорывы в виде практик бирюзовых организаций.

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

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

Два дня 15-16.12.2016 был на конференции KM Russia-2016. Краткое ощущение от того, что происходит с управлением знаниями вынесено в заголовок статьи. Раньше Knowledge Management в России носил преимущественно догоняющий характер, мы брали современные практики и подходы, проработанные и распространенные в разных компаниях по всему миру и учились внедрять и использовать их в российских компаниях. И этот процесс, безусловно, продолжается, процесс управления знаниями как составная часть новой индустрии, ставится и развивается во многих компаниях. Но в этом году стал виден новый процесс на ряде предприятий и отраслей. Они восстанавливают инженерные наработки и культуры времен СССР, развитие которой было оборвано его распадом, и интегрируют их в современную культуру управления знаниями. При этом обнаруживаются достаточно интересные открытия, хотя их необходимо смотреть детальнее. А в области проработки стандартов Россия, похоже, не только выходит из провала, вызванного развалом СССР, но и занимает опережающие позиции в мире (или в Европе), во всяком случае, рассказ о профессиональном стандарте ИТ-менеджера вызывает такие мысли. Все это - замер по лидеру, а не основной массе, но куда основная масса денется, если лидер уже там. Добежит чуть погодя.

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

Это краткие впечатления. А теперь подробный рассказ об услышанном и мои размышления на эти темы.

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

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

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

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

А пока я выкладываю свою презентацию.

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

Жизнь идет быстро и я не успеваю публиковать хронику. Так что будет все вместе.

1. 25-26.11 был на SQA Days в Минске. Выступал с докладом Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять и активно общался на баркемпе. Отчет ожидается…
2. В прошлый четверг, 01.12 в Петербурге Скаут-академии была открытая встреча «Спиральная динамика и теория бирюзовых организаций», на которой я разбирал конкретные кейсы и отвечал на вопросы. Сегодня опубликовано видео.
3. В среду 14.12 выступаю вместе с Мариной Симоновой и Еленой Пляцук на встрече Agile вне IT. Будут рассказы для тех, кто интересуется, и хочет разобраться для себя — пропустить этот модный гаджет или использовать с пользой.
4. А потом два дня, 15-16.12 — на конференции KM Russia, тоже выступаю во второй день с докладом «Управление знаниями: уроки ИТ».

Вот такая жизнь.

В посте - мое понимание услышанного и мысли по поводу. Цитаты неточные, смыслы - интерпретированные.

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

• Платформы дают возможность и побуждают индивидуумов и мелкие группы стать предпринимателями и строителями собственной судьбы. Вот примеры (Петра и мои).
  • Uber предоставляет возможность любому стать водителем-предпринимателем с собственными способами привлечения клиентов.
  • Алибаба предоставляет возможность мелким фирмам торговать со всем миром, снимая логистические и другие инфраструктурные проблемы. А если она обеспечит единое азиатское таможенное пространство, как в Евросоюзе, но без европейской бюрократии, то импульс развития будет столь мощным, что сложно оценить последствия.
  • AppStore и GoogleStore дают возможность мелким разработчикам и компаниям прямой доступ к конечному потребителю.
  • Facebook и LiveJournal теснят и заменяют современные СМИ как источники информации, при этом люди работают и зарабатывают там индивидуально.
  • В высокотехнологичных областях все развивается медленнее, поскольку предмет гораздо сложнее, однако и там возникают платформы для серийного предпринимательства и 6D моделирования Toshiba.
  • Кстати, серийное предпринимательство на платформе дает кратный просто производительности: если индивидуально один человек разворачивает бизнес примерно 10 лет, то команда из 10 человек с разделением труда может за 10 лет развернуть 100 бизнесов, запуская их параллельно.
• А еще платформы предоставляют возможность им создавать собственные знания, делая их всеобщим достояниям и давая шанс на известность в соревновании с другими, без промежуточных корпоративных фильтров.

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

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

И профессии тоже исчезнут, что вполне может привести к революциям против развития. Об этом Петр говорил в 20 лекции на примере мексиканской революции.

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

Петр выделяет три этапа становления технологий управления.

1910-1930 - Планирование операций, Диспетчеризация, Контроллинг

1930-1950 - Оргпроектирование, Управление проектами, Логистика

1950-1970 - Программирование, Стратегирование, Cценирование

Это замер по лидерам, то есть в тех отраслях и странах, где создавались сложные решения.

C 1960-х управленческие технологии интенсивно развивались во многих направлениях.

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

Схема Программирования разработана у Георгия Петровича Щедровицкого. Схема приведена на рисунке справа, ее следует читать сверху-вниз и слева-направо, но при этом помнить, что она представляет результаты, а не процесс, хотя эти результаты и выражены в процессном залоге. Петр применяет ее уже около 30 лет и утверждает, что ничего более современного управленческая наука не создала.

Мощь схемы состоит в том, что она выделяет несколько уровней деятельности, позволяя при этом запускать работы на разных уровнях и по разным потокам параллельно.

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

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

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

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

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

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

Но вообще интересно было бы посмотреть через призму программирование на развитие крупного OpenSource с различными интересантами, например, PostgreSQL или LLVM-Clang.

А еще один фактор носит чисто технологический характер, но так же способен принципиально повлиять на организацию управленческой деятельности. Речь идет о подборе персонала и комплектовании рабочих групп не людьми, как это происходит сейчас, а рекомендательными системами, построенными на основе машинного обучения. И это - очень близкое будущее, уже сейчас HeadHunter переключил алгоритмы рекомендаций на нейронную сеть, и она будет выдавать рекомендации без участия человека. Но это пока в рамках традиционного подбора на позицию в компанию. Штука в том, что нейронная сеть способна учесть много больше требований к человеку, включая требования на его соответствие не только деятельности, но и формируемой команде. И поэтому следует ожидать резкое уменьшение кванта для подбора - сотрудника будут искать не на должность, а на короткий проект. Кстати, именно так сейчас ищут freelance-программистов и не только их, при чем для коллективной работы в коротких (полгода - уже долго) высокотехнологичных стартапах. И абсолютно все равно, где человек географически - команды распределенные. Так вот, а помимо таких платформ для подбора сотрудников будут другие, предлагающие конкретному человеку различные курсы и другие обучающие мероприятия, так же проходящие преимущественно дистанционно. Как легко догадаться, оба типа систем очень быстро начнут обмениваться данными относительно зарегистрированных в них людей, появятся некоторые координирующие алгоритмы.

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

Вообще вот этот обратный ход, от технологий, меняющих материал, на котором разворачивается деятельность, к изменению самой деятельности - он важен. Петр не игнорирует технологии, более того, началась лекция как раз с обзора технологических трендов последнего времени. Которые в принципе можно начинать с Богданова, который в своем романе 1913 года про инженеров будущего, втом числе, предсказывал технологии, ошибившись лишь в двух из 10 - неплохое попадание на 100 лет вперед. И плеяды писателей-фантастов 1960-х - Азимов, Лем и другие. Но подробный рассказ Петр начал с Тоффлера (1980) и Рифкина (2000), которые дали свое видение будущего. Затем - Умный завод немецких инженеров (2010), который работает самостоятельно без людей. Тренды, тогда же сформулированные у нас в рамках центра стратегических разработок "Северо-Запад". Технологические тренды Гартнера в 2015, когда впервые технологическим трендам на их кривой через раскраску приписали ориентировочные сроки развертывания, добавив время. Предсказание 2016 года Тони Себа.

И вот фишка в том, что эти технологии после разворачивания - меняют организацию деятельности. При чем совершенно независимо от того, была ли эта организация промыслена, готовы ли модели. Я наблюдал два таких процесса. Первый - когда появились персоналки, потребовалось много разработчиков и разрабатывать стали люди, которые этому совершенно не учились. И у них получалось. Но для более сложных проектов нужна была организация, а чтобы сделать ее традиционным образом - не хватало руководителей групп. Как ответ на этот вызов возник Agile-менеджмент. А второй кейс интереснее, потому что напрямую касается мышления. Для моделирования реального мира и алгоритмов в ИТ развивалось несколько альтернативных подходов - объектно-ориентированный, реляционные базы данных, функциональный и взаимодействующих акторов. Первые два были достаточно теоретически проработаны, под них были абстракции, формализмы и схемы, а другие появились позднее. Но все они существовали независимо, были отдельные языки разработки и среды. А лет пять назад Microsoft для чисто утилитарной цели бесшовной работы приложения с базой данных взял и принес в объектно-ориентированный язык функциональную и реляционную парадигмы, а позднее - еще и акторную, до кучи. И разработчики сейчас практически на такой смеси разрабатывают, не имея, вообще говоря, никаких годных абстракция и схем. Они их точно изобретут. И научатся такими объектами мыслить. И это, с моей точки зрения, приведет к достаточно сильному прорыву мышления с точки зрения организационного моделирования, представления коммуникаций и вообще схематизации человеческой деятельности. Что, в свою очередь, откроет потенциал для ее реорганизации - потому что у тебя появятся схемы с гораздо большим потенциалом сложности.

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

В посте - мое понимание услышанного и мысли по поводу. Цитаты неточные, смыслы - интерпретированные.

Замечание. 24.11 Петр сказал, что решил не включать лекцию во вторник 22.11 в нумерацию, а считать ее дополнением. Так что эта лекция стала второй, а не третьей в модуле.

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

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

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

В посте - мои мысли по поводу услышанного на лекции. Цитаты неточные, смыслы - интерпретированные.

Замечание. 24.11 Петр сказал, что решил это была не лекция, а просто дополнение. И в нумерацию она не входит.

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

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

Итак, модель хозяйственной деятельности. Выделяется три уровня: материалы природы; субъекты, ведущие деятельность и воспроизводящие условия жизни и формы организации хозяйственной деятельности. Мы можем мысленно отделить формы деятельности от самой деятельности - как и у Поланьи. Есть четыре формы деятельности.

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

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

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

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

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

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

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

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

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

В посте - мои мысли по поводу услышанного на лекции. Цитаты неточные, смыслы - интерпретированные.

Приведенный disclaimer особенно относится к названию поста. В нем я попробовал сформулировать основной смысл лекции, как я его понял. Основные тезисы, на мой взгляд, таковы.

1. Маркс сформулировал, экономический и социальный процесс как поступательное развитие производительных сил, от которых производственные отношения отстают, а потом - резко преодолевают разрыв в революционных событиях.
2. Однако, Маркс не указал механизм, связывающий производственные силы и производственные отношения. И с тех пор экономическая наука не продвинулась в этом вопросе.
3. Тезис Петра состоит в том, что механизмом, связывающим производительные силы и производственными отношения, является система разделения труда. Именно СРТ вовлекает человеческий материал в морфологию производственных отношений, связывая их с процессом развития производительных сил (в терминах системного подхода). И это, в частности, снимает вопрос о первопричине и главном факторе: важность конкретного фактора определяется ситуативно историческим контекстом, и сам фактор (география, например) проявляется лишь в той мере, в которой играет роль относительно текущей СРТ. В целом это было на предшествующих модулях.
4. СРТ как составляющая часть экономической науки была выведена из поля внимания в середине 19 века, и после Маркса туда не вернулось. Поэтому вся последующая экономическая наука была эмпирикой чистой воды, без онтологических оснований, представляя, таким образом, без по кругу с вечными дискуссиями о главных факторах.
5. Петр напомнил, что основной социальных наук являются типологии, он говорил об этом в прошлых модулях. развертывая цепочку Миль - Дельтей - Виндельбанд - Вебер. Ведер поделил типологии на генетические и репрезентативные (реализация идеальных типов). И это - хорошо.
6. К сожалению, многие ученые не затрудняют себя ни рассмотрением происхождения явления (генезисом), ни разработкой системы идеальных типов. Они ограничиваются выделением единственного идеального типа, а все остальное классифицируют относительно него. Например, делят общество на до-индустриальное, индустриальное и пост-индустриальное, выделяя признаки только для индустриального общества. Или конструируют противоположный тип, объявляя далее всю историю как борьбу по этой дихотомии - как Герберт Спенсер, построивший военное общество как антитезу промышленному, которое он защищал. Подобные типологии представляют себя очки, надев которые мы начинаем видеть в мире неполную и искаженную картину. При этом свидетельства несоответствия часто игнорируются.
7. Подобным образом Маркс построил периодизацию процессов производства на европейском материале, выделив известные формации - рабовладельческую, феодальную и буржуазную. А потом, когда выяснилась ограниченность - ввел азиатский способ производства, без всякого рассмотрения логики развития - и в 30-е годы те, кто решил это копнуть, рассматривая развитие нашей Средней Азии обнаружили много интересного...
8. Исключением из эмпирической экономической школы, пытавшемся искать онтологические основания экономики, объяснять ее устройство был Карл Поланьи. Не так, чтобы ему удалось, но попытки интересные.
9. Петр напомнил, что начиная с Менгера, экономическая наука включает два не связанных сегмента. В лекции были оригинальные термины, но я сформулирую это в современных, о которых Петр тоже говорил в прошлых модулях. Это микроэкономика, занимающаяся рациональным поведением гомо экономикуса, который рационально экономит свои усилия, соизмеряя цель и средства. И макроэкономика, занимающаяся анализом экономической составляющей социальных процессов, обеспечивающим общества средствами существования. При этом две эти половины науки принципиально разорваны, так как микроэкономика говорит о субъективном выборе человека, работе его сознания, амакроэкономика - о взаимодействии с природой и объективных законах.
10. Карл Поланьи спорил с Мизесом про капитализм и социализм (1920-е). Мизес утверждал, что в экономике есть только субъективный фактор - то, что изучает микроэкономика, только надо рассматривать не умозрительного гомо экономикуса, а реального предпринимателя. А Карл обращал внимание как раз на объективную макроэкономическую составляющую.
11. В макроэкономической составляющей Карл разделял хозяйство как процесс индивидуальной экономической деятельности, и институциональные формы, которые ему способствуют или, наоборот, препятствуют. При этом он утверждал. что институты развиваются независимо, а не фиксируют исторически складывающиеся индивидуальные формы (в отличие от Мизема). И строил типологию связи хозяйства с институтами, поскольку именно они придают цельность. Такой вот дуализм. При этом в современном ему времени он выделял социалистический и корпоративный типы институализации.
12. Карл утверждал, что европейская рыночная экономика с ценообразующими рынками, изучаемая большинством экономистов, как экономическая доминирующая реальность присутствовала только в Англии на протяжении всего 30 лет (1830-1860). Для доминирования она требует трех условий, которые дальше не повторялись: профицитный рынок труда, золотой стандарт и свободная торговля. Он утверждал, что на этом крайне ограниченном материале были сделаны обобщенные наблюдения, которым придали статус общих законов, развиваемых экономистами и поныне. И когда через эти ограниченные очки смотрят на реальную хозяйственную деятельность, то восприятие сильно искажается, и не удивительно, что развитие оказывается вовсе не таким, как говорят эти законы. Антропологи, изучающие хозяйственную процессы общества не могут их описать в принятых экономических терминах - их недостаточно.
13. В поисках генетических оснований происхождения рынка Карл обратился к древним временам и выявил два этапа эволюции. Самый древний связан со сбором дани в натуральной форме на центральные склады, а затем - централизованной торговле ими с другими странами через морские или караванные порты древнего мира. Деятельность - групповая, купец был чиновником, посланным правительством. Более новая, рыночная форма возникла в Древней Греции для решения задачи снабжения армий, которые шли по дружественно территории. Отнять продукты было нельзя, а купить значительное количество продовольствия у местных - тоже. Поэтому стратеги и полководцы поощряли торговцев, в том числе и кредитами. И те же торговцы покупали награбленную входе военных действий добычу. Там была интересная история про медные деньги - чтобы не платить серебром и вообще не таскать ценный металл полководец договорился с торговцами, что те будут принимать у солдат медь за продовольствие, и смогут этой медью расплатиться на аукционе за добычу, а если останется излишек, то его после компании обменяют на серебро. При этом этот рынок был локальным и цены не устанавливал. От себя отмечу, что история разумная, но объясняет далеко не все. Особенно в части возникновения государственной торговли, которую вели чиновники. а не купцы. Интересно, какая там документальная первичка, в том числе в части возникновения денежного оборота.

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

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

Продолжение следует.