MaksWiki - Новые страницы [ru]

Инь и Ян и 5 элементов балансового учета

2019-08-26T20:32:08Z

MaksTsepkov:

Материал был опубликован на моем сайте maksiq.narod.ru 09.01.2010
Перенесен для сохранения с небольшим обновлением

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

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

Дополнение 2019. Книга доступна в электронном виде на сайте ассоциации интегральной медицины. В свое время сайт был на другом домене, который сейчас ушел другим владельцам и сайт переделали на попсовые материалы, поэтому сохраню ссылку на книгу на archive.org. На других сайтах, к сожалению, я нашел под этим названием только написанную "по мотивам" этой книги работу неизвестных авторов с поверхностной компиляцией. Что очень плохо. Автор Nguyen Van Nghi - вьетнамский профессор, работающий во Франции в институте китайской медицины, практиковавший там ее методы и обучавший им, в то время как западные ученые наблюдали ход лечения с помощью методов западной медицины и пытались разобраться. В статье вики о нем есть дальнейшие ссылки.

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

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

На схеме изображен балансовый план счетов торгово-производственной компании в виде классической пентаграммы У-Син (Википедиа: У-син). Актив - Ян, Пассив - Инь, план счетов разбит на пять разделов в соответствии с 5 элементами. Проводки естественным образом разбиты на 4 типа по времени суток.

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

Так же не является однозначным сопоставление разделов конкретным элементам. Я пробовал несколько вариантов, прежде чем остановился на представленном. Отправная точка в нем - деньги. Это металл и упадок. Их платим поставщикам, ожидая товар - минимальная активность, зима. Доставка от поставщиков, его производство - дерево, весна и ветер. Готовая к продаже продукция и имущество - огонь, лето. И продажа - земля, она приносит доход и кормит.

Все это дает поле для многих аналогий и рассуждений. Особенно имея ввиду разные варианты не равновесия Инь-Ян: больше ян, меньше ян, большой инь (мало ян и инь), меньше инь, больше инь, большой ян (много ян и инь). Можно говорить о неправильном, неравновесном балансе компании, когда имеются те или иные перекосы, о влиянии разделов и так далее.

Кстати, первоначально диаграмма визуально была другой. Менее канонической, но мне нравилась больше.

Осваиваем agile-мышление, разбирая кейсы (IT-Nights-2019)

2019-08-02T09:16:30Z

MaksTsepkov:

IT-Nights 1-3.08.2019 Иннополис, Казань 
Видео воркшопа

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

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

Эволюция технологий управления: от индустриального общества к цифровому миру

2019-06-14T04:44:46Z

MaksTsepkov:

Эволюция технологий управления: от индустриального общества к цифровому миру

Выступление на StePIR-2019  14.06.2019

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

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

Какое качество нужно вашему проекту и как организовать разделение ответственности за него (РИТ-2019)

2019-05-28T11:46:33Z

MaksTsepkov:

Доклад 28.05.2019 на РИТ-2019
Доклад на сайте конференции
Видео ожидается, а пока смотрите версию 2016 года

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

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

Социальный договор цифрового мира: работа должна обеспечивать счастье, а не только деньги

2019-05-28T09:49:33Z

MaksTsepkov:

Доклад 28.05.2019 на РИТ-2019
Доклад на сайте конференции
Видео на youtube (в статье тоже есть)
Предыстория - статья по следам AgileDays-2019

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

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

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

Доклад спровоцирован моим постом, написанным по следам AgileDays-2019 и последующих обсуждений

Лидер и племя. Дэйв Логан, Джон Кинг и Хэли Фишер-Райт

2019-05-19T22:18:05Z

MaksTsepkov:

Публикация на сайте Спиральная динамика

Книга «Лидер и племя». Дэйв Логан, Джон Кинг и Хэли Фишер-Райт. В переводе книги — подзаголовок «Пять уровней корпоративной культуры». Это — ошибка перевода, в оригинале заглавие книги «Tribal leadership. Leveraging natural groups to build a thriving organization» и там выделены группы культур людей по их языку, а не культуры организаций. Эти группы названы уровнями и вот именно с этого я хочу начать.

Тарский. Семантическая теория истины и основания семантики

2019-04-22T08:02:11Z

MaksTsepkov:

Обсуждение на FB

На прошедшей «Прикладное системное мышление» (мой отчет) школы системного менеджмента Анатолия Левенчука Прапион Медведева в своем докладе поставила вопрос о создании онтологии для описания онтологий, или, как минимум, онтики для описания онтик. На мою реплику, что такая онтика должна быть рефлексивна, то есть подходить для описания себя самой, мне вернули, что «так не работает», в при подробном обсуждении в перерыве Прапион порекомендовала статью Тарского «Семантическая теория истины и основания семантики» — она «совсем короткая, и там все это хорошо раскрыто». Впрочем, кратко мы все равно обсудили, основная претензия в том, что самоописываемые языки неизбежно оказываются противоречивыми, простейший пример — парадокс лжеца, возможность в языке утверждения «Данное предложение ложно», а всерьез это обосновано у Геделя. Меня эта противоречивость не смущает, потому что онтики у нас — для описания мира, а мир — противоречив по той самой теореме Геделя.

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

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

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

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

И в этом месте у меня вопрос: а как устроены мои модели — те, которые я строю для объяснения мира и при проектировании IT-систем? Главное, что я не считаю необходимым — это требование полноты «все предложения, задающие адекватное употребление этого термина, могут быть сформулированы в нашем языке». Модель не обязана давать все суждения о предмете моделирования, она его упрощает. Кроме того, для меня неважно требование строгой логики, в том смысле, что если модель дает альтернативные и противоречащие друг другу решения, выбор между которыми делают вне этой модели — тоже нормально. Обычно выбор делает человек, но сейчас уже есть варианты, когда выбор делает искусственный интеллект, например, в виде обученной нейронной сети.

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

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

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

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

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

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

WIAD-2019

2019-04-05T20:55:11Z

MaksTsepkov: /* Как обеспечить доступность интерфейса. Валерия Курмак из Сбербанка */

На конференции WIAD я в Петербурге был четвертый раз. Это - одна из площадок международного события World Information Architecture Day, которое проходит в третью субботу февраля по всему миру, более 70 площадок. Каждый год объявляется отдельная тема, и в этмо году было Design for Diversity, проектирование для многообразия. В Питере это организует сообщество UX Spb и там традиционно сильная программа (мои отчеты WIAD-2016, WIAD-2017, WIAD-2018). В этом году была площадка в Москве, но ее сделали позднее и она пересеклась с TeamLeadConf, поэтому подробностей не знаю. Как и в прошлые годы, на конференции вели запись докладов, но они пока не выложены. Следите за группой UX Spb.

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

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

TeamLeadConf-2019

2019-04-05T20:33:13Z

MaksTsepkov:

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

Я выступал с докладом Модели softskill для тимлида, в которой был обзор разных моделей, которые полезно знать: типов личности MBTI, командных ролей Белбина, типов менеджмента по Адизесу вместе с его жизненным циклом компании, ситуационного лидерства в двух вариантах, развития команд Такмана, краткий обзор развития моделей мотивации, включая нейрофизиологическую модель Хелен Фишер и модель ценностей Спиральной динамики. Но основная цель - показать, что модели - достаточно зрелые и формальные, чтобы их стоило использовать, подобно тому, как разработку стоит вести на фреймворках.

А теперь - о докладах. Только надо отметить (пост), что я был далеко не на всех докладах, на ряде слотов приходилось разрываться между желаниями, а часть докладов я пропустил, делая свой и участвуя вчера в митапе по управлению знаниями, посвященному новой #KnowledgeConf (26.04 в Москве), которая обещает быть очень интересной - это я уже пишу как член ПК, отбиравший доклады. О ней же я рассказывал в интервью RadioQA (второе фото). Но доклады будут доступны в записи, а хорошее общение - бесценно.

Выбор модели управления - карта для выбора (ПИР Сибирь-2019)

2019-03-17T02:00:30Z

MaksTsepkov:

Выступление на ПИР Сибирь-2019 15.03.2019

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

Пока видео с ПИР Сибирь не опубликовано, можно читать статью Agile и бирюзовые организации - ответ менеджмента на вызовы новой промышленной революции и смотреть выступления Agile и бирюзовые организации - два пути менеджмента в мир третьей волны (Круглый стол в SPb 2017-11) и Гибкость, эффективность и вовлеченность: как их получить методами нового менеджмента (семинар в Открытой школе бизнеса 2018-09).

Рефлексивная сборка собственных схем мышления на основе схем СМД — методологии (ПИР Сибирь-2019)

2019-03-15T04:15:35Z

MaksTsepkov: MaksTsepkov переименовал страницу Рефлексивная сборка собственных схем мышления на основе схем СМД — методологии (ПИР Сибирь-2019) в [[Рефлекс…

Выступление на ПИР Сибирь-2019 15.03.2019

В периоды быстрого турбулентного изменения мира требуется уметь быстро осмысливать происходящие изменения, формировать собственную модель происходящего в мире, пригодную для самоопределения. Модель такого уровня можно строить только на основе концептуальных схем, которые имеет смысл не разрабатывать самостоятельно с нуля, а черпать из накопленного культурой. Мощным источником таких схем является СистемоМыслеДеятельностная методология (СМД-методология). Школу основал Георгий Петрович Щедровицкий в 1950-х, сейчас работают его последователи. В рамках школы наработано большое количество концептуальных схем. Я познакомился с ними сравнительно недавно, примерно в 2012 году и за это время освоил часть схем, они вошли в мой арсенал профессиональной деятельности. С ними я и буду знакомить в докладе. Я рассказывал о схемах три года назад для IT-аналитиков http://mtsepkov.org/SMD-AnalystDays2016, а три схемы сформировали отдельный арсенал схем самоопределения http://mtsepkov.org/SelfDet2. В докладе будет представлена новая версия.

Эволюция технологий управления (ПИР Сибирь-2019)

2019-03-15T03:24:24Z

MaksTsepkov:

Эволюция технологий управления Agile и бирюзовые организации — ответ менеджмента на вызовы новой промышленной революции

Выступление на ПИР Сибирь-2019  15.03.2019
Видео
Пост на FB

Скрайбинг выступления

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

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

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

В 2020 вышла серия статей «Менеджмент цифрового мира» с подробным раскрытием темы, позднее опубликованная в виде книги «Менеджмент цифрового мира».

Левенчук. Утопия визуального мышления

2019-03-13T09:12:27Z

MaksTsepkov:

Пост на FB

Прочитал книгу Анатолия Левенчука «Утопия визуального мышления» (на ridero, на litres, пост Анатолия о книге со ссылками ). Основной тезис в том, что надежды на прорыв в мышлении за счет многочисленных визуальных техник — быстрого коллективного рисования схем и картинок на флипчартах, скрайбинга и многих других, которым сейчас интенсивно обучают, в том числе в в составе таких сильных движений как design thinking — это утопия. И серьезным мыслящим людям, заинтересованным в достижении существенных мыслительных результатов, то есть создании и реализации сложных концептов и систем в реальном мире, технических, социальных и социотехнических, например, больших успешно развивающихся компаний, имеет смысл понимать утопичность серебряной пули визуального мышления, и на него не рассчитывать, а использовать для мышления весь спектр методов, включая визуальные в той ограниченной области где они уместны. При этом Левенчук понимает (и пишет об этом), что одной книгой мощную привлекательную утопию не поборешь, но тут у него позиция эксперта: я предупредил, а дальше можете заблуждаться и огребать последствия, если вам такой путь нравится.

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

Из презентации https://ailev.livejournal.com/1429949.html

В основе концептуальной картины лежит схема «Спектр формальности мышления», задающей шкалу животное — интуиция — схемоид — схема — калькулятор, на котором изображены характерные профили дикаря, гуманитария, технаря-ботана с разными пиками, и идеальный профиль мудреца, объединяющего все виды мышления. Утверждается, что левая часть шкалы соответствует быстрому мышлению Каннемана, а правая — медленному. Схема развертывается в текстовое описание на 10 страниц и это как раз, по Левенчуку, пример правильного баланс между визуальным представлением и тестами.

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

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

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

Но пояснения все равно нужны. Картинку со спектром я видел в презентациях и более коротких текстах Анатолия, но в 10 страницах пояснений в книге — очень много содержания. И это — пример баланса. Другим примером хорошего баланса Анатолий полагает свой учебник по системной инженерии: 107 картинок на 400 страниц. Анатолий пишет, что когда начинал — пробовал часть ее делать в картиночном стиле (комикс-style). Результат: стоимость изготовления и изменений (развития) возрастает многократно, эффективность усвоения — чуть превышает то, что для текстов (эксперимент был на студентах). Но для меня это — не совсем честный эксперимент, если говорить именно о мышлении, потмоу что лишь означает, что для визуального представления нет эффективных инструментов работы с ним, ориентированных на быстрое внесение изменений. А еще я думаю, что позиционирование на шкале формальности мышления гораздо важнее различия между текстовым и визуальным представлениями, которые распределены по всему спектру.

Принципиальным тезисом об устройстве мышления для меня является утверждение, что мышление происходит в пространстве смыслов, которое амодально и синестезийно, и при этом скрыто, не рефлексируемо. Модальность появляется в момент проявления смыслов в сознании, и она может быть различной — визуальной, аудиальной (текстовой) или композитной, включающей телесную и другие чувственные компоненты. Тезис о том, что рациональное мышление завязано на языка, его структуру Анатолий полагает опровергнутым современным развитием лингвистики, особенно в ее компьютерном варианте работы с текстами natural language processing, и обосновывает это со ссылками. Важное отличие визуального мышления от текста в том, что текст всегда разворачивается последовательно во времени, в то время как визуальный образ схватывается одномоментно. Впрочем, еще есть фильмы, в том числе фильмы в голове — я слышал нескольких людей, которые говорили, что часто именно так мыслят. И есть средство для эффективной запаковки смыслов в мультфильмы для коммуникации — Объясняшки, Сергей Гевлич ставил перед собой задачу сделать такой софт, чтобы отрисовка мультика занимала столько же, сколько обдумывание и написание хорошего текста, пару часов. Столько же не получилось, но сравнимо — вполне. Впрочем, в книге у Анатолия этого нет, я тут отвлекся. А что Анатолий обращает внимание — так это на то, что хотя текст воспринимается в коммуникации или чтении последовательно, в голове он упаковывается структурно в смыслы, которые существуют одновременно. Кстати, чтение — коммуникация с отсутствующим, и в этом его великая сила. Даже если ты читаешь свои тексты, то тебя — прошлого, материализовавшего эти смыслы — уже нет. Я, кстати, регулярно читаю свои старые тексты как новые мысли :)

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

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

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

P.S. В посте на FB с этим отзывом - интересное обсуждение.

Agile и компании разной культуры - что ожидать в результате?

2019-03-01T09:49:28Z

MaksTsepkov:

Выступление на конференции В поисках капитана Ганта 01.03.2019
Видео на youtube

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

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

Модели softskill для тимлида

2019-02-26T17:19:29Z

MaksTsepkov:

Еще про человека, команды и организации

Доклад на TeamLeadConf-2019 в Москве 25-26.02.2019
Доклад на сайте конференции
Видео (в статье тоже есть)
По развитию доклада для Infostart опубликована статья Модели softskill для тимлида 
Дальнейшее развитие темы привело меня к книге «Инженерная модель личности» и ряду более глубоких докладов.

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

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

Тема развивается, осенью 2021 я делал доклад Модели softskill - способ быстро понять другого (ESCAPE-2021). В него вошли дополнительные модели, ориентированные на понимание между людьми. Правда, за счет того, что часть из упомянутых в этом докладе моделей пришлось исключить. И еще был доклад Модели softskill для тимлида (Infostart-2021), по нему опубликована статья.

По ряду моделей у меня есть отдельные выступления:

Модель Белбина для IT: сила и слабость разных команд (TeamLeadConf-2020)
Ряд выступлений по Спиральной динамике
Модель Хелен Фишер рассматриваю в статье Вовлеченность: от зарплаты за компетентную работу к драйву и счастью на работе вместе со Спиральной динамикой и несколькими другими
Типы личности (семинар 2008-02-12) — типология Майерс-Бриггс

Выступление Социальный договор цифрового мира: работа должна обеспечивать счастье, а не только деньги (РИТ-2019) так же затрагивает ряд моделей.

Проектирование для многообразия — конструктор и DSL вместо жесткой реализации требований (WIAD-2019)

2019-02-23T12:04:36Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Выступление на World Information Architecture Day (WIAD) 23.02.2019, площадка в Санкт-Петербурге

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

Design for Diversity: configuration and DSL instead of hard code according to requirements. I'll told about balance between two approach for design: universal constructor of data structure, algorithm and interface form, based on metadata, and hard code realization precisely according to requirements. This balance achieved due to DSL and configuration in the spots of diversity and evolution of software system.

Практики общения в Skype

2018-12-28T09:18:34Z

Александр Фимин:

Практики управления знаниями и коммуникациями

2018-12-27T10:49:26Z

Александр Фимин:

Спиральная динамика для аналитика – работа на стыке культур (AnalystDays-9 осень 2018)

2018-12-01T07:04:50Z

MaksTsepkov: /* Видео */

AnalystDays-9 30.11-01.12.2018 в Москве
Доклад на сайте конференции
Видео на vimeo

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

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

Визуальные модели корпоративного приложения (AnalystDays-9 осень 2018)

2018-12-01T07:01:31Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

AnalystDays-9 30.11-01.12.2018 в Москве
Доклад на сайте конференции
Видео на vimeo

При проектировании сложных корпоративных приложений эффективным является использование моделей, описывающих предметную область и само приложение в соответствии с подходом Domain Driven Design. При этом хорошая визуализация является непременным атрибутом модели. В выступлении обменяемся опытом построения архитектуры приложения с использованием трех основных моделей: доменной модели, представленной диаграммой классов, модели движения ресурсов, представленной диаграммами учета и модели документооборота на основе диаграммы состояний. Все это дополняется моделью бизнес-процессов на основе диаграммы деятельностей (activity diagram) и объединяется моделью архитектуры предприятия на основе Archimate, и дополняется метафорой системы в тех случаях, когда ее получается придумать. В рассказе будут приведены примеры диаграмм из реальных проектов.

Доклад прочитан как оперативная замена для докладчика, который не смог приехать на конференцию, поэтому использованы слайды доклада Визуальные модели корпоративного приложения (Meetup в Райффайзенбанк 2017-11-01).

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

2018-10-25T16:22:40Z

MaksTsepkov:

10-я лекция Корпоративное управление в девелопменте: ретроспектива и прогнозы будущего цикла лекций Школы девелопера включала две части: лекцию Светланы Бачуриной про существующие системы управления и моя лекция по методам нового менеджмента.

Анонс лекции на сайте. Цикл лекций о будущем в девелопменте близится к своему завершению в этом году, поэтому говорить будем о проблемах компании на уровне технологий управления. Отрасль девелопмента — это сегмент с традиционно самыми низкими темпами изменений — технологических, технических, организационных, управленческих. Однако вызовы 2014-2018 гг. и связанная с ними турбулентность ставят отрасль в позицию, когда необходимо или изобретать собственные практики, или воспользоваться апробированными ответами Agile, наполнив его практики своей спецификой. В этой лекции будем соединять удачные подходы Советского Союза к управлению строительством и mindset нового поколения, ответом на который стали методы Agile, конструкция бирюзовых (teal) организаций, холакратия и социократия — готовые управленческие технологии, соответствующие обществу третьей волны.

Порассуждаем о:

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

Мыслить проектно: история и современность

2018-10-12T13:34:57Z

MaksTsepkov:

Еще про архитектуру

Доклад на конференции SECR-2018 12.10.2018 в Москве
Доклад на сайте конференции
Доклад в библиотеке Стаса Фомина

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

2018-10-06T13:48:57Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про самоопределение}}

Еще про самоопределение

Выступление на COMAQA осень 2018 06.10.2018 в Минске 
Видео https://youtu.be/ExWosHbTmU0 
Предыдущий доклад Как строить свой профессиональный путь - схемы самоопределения (TeamLeadConf-2018)

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

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

Дополнение. На Saint TeamLeadConf-2019 был практикум Строим свой профессиональный путь - без видео, но слайдов больше и есть слайды про применение схем для семьи.

Роли в команде - модель Белбина (COMAQA-2018)

2018-10-06T13:41:00Z

MaksTsepkov: Массовая правка: добавление Категория:Модель Белбина

Доклад на COMAQA осенью 2018 06.10.2018 в Минске
Видео на youtube
Статья Типология ролей в команде (статья в MyType 1-2.2016) кратко излагает типологию Белбина.
Предыдущее выступление Роли в команде - модель Белбина (Максим Цепков на SPMconf-2012)
Новая версия доклада Модель Белбина для IT: сила и слабость разных команд (TeamLeadConf-2020)

Agile, бирюзовые организации, игрофикация: за каким менеджментом будущее

2018-09-27T11:01:58Z

MaksTsepkov:

Лекция 27.09.2018 в АСИ Точка кипения в Санкт-Петербурге (анонс на FB)

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

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

Гибкость, эффективность и вовлеченность: как их получить методами нового менеджмента (семинар в Открытой школе бизнеса 2018-09)

2018-09-27T10:47:14Z

MaksTsepkov:

Семинар 27.09.2018 в Открытой школе бизнеса в Санкт-Петербурге
Видео, к сожалению слайды не видны (пост на FB)

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

На семинаре мы представим сравнение различных методов.

Мы пойдем от задач трансформации бизнеса и рассмотрим такие вопросы:

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

Спиральная динамика: понимай ценности и действия людей и организаций (Лекторий тут рядом 2018-09)

2018-09-27T09:08:40Z

MaksTsepkov:

Благотворительная лекция 29.09.2018 в Лекторий тут рядом (анонсы на FB организаторов, мой)
Лекторий проводит фонд Антон тут рядом, помогающий людям с аутизмом
Видео на youtube (есть маленькие пропуски, но в целом - хорошо)

Скрайбинг Наталья Арсентьева

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

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

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

Разделение ответственности в IT-командах - практики бирюзовых организаций на каждый день (SaintTeamLeadConf-2018)

2018-09-25T11:50:12Z

MaksTsepkov:

Выступление 24.09.2018 Saint TeamLead Conf в Санкт-Петербурге
Доклад на сайте конференции
Видео на youtube

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

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

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

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

Отзыв Олега Бунина о докладе. Максим Цепков посещает множество конференций, много знает и активно делится опытом. На Saint TeamLead Conf он нам рассказал о бирюзовой организации. Все ей интересуются, живо обсуждают, но чаще всего разбираются плохо и живых примеров не видели. Сегодня мы поняли, каково это, когда ответственность за решения на исполнителе.

Agile и бирюзовые организации - ответ менеджмента на вызовы новой промышленной революции

2018-09-14T11:03:18Z

MaksTsepkov:

Еще про развитие общества

Статья опубликована в сборнике «Практики Развития 1.0» (вышел 09.2018)
Тема развивается

Доклад с видео Эволюция технологий управления (ПИР Сибирь-2019)

Статья Бирюзовые организации и agile: какие полезные практики стоят за хайпом

Серия из 59 статей Менеджмент цифрового мира (оглавление)

Собираем практики нового менеджмента в единый паззл (ПиР-2018)

2018-09-14T09:25:54Z

MaksTsepkov:

Выступление 14.09.2018 на ПиР-2018 
Записи доклада не было. Можно посмотреть семинар в Открытой школе бизнеса 27.09.2018 на ту же тему

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

В сборнике ПИР о методах нового менеджмента - моя статья Agile и бирюзовые организации - ответ менеджмента на вызовы новой промышленной революции, написанная в развитии выступления прошлого года Что могут практики Agile и холакратии и нужны ли они Вашей организации (ПиР-2017)

MySDtest

2018-08-08T13:37:15Z

MaksTsepkov:

Разделение рисков и успеха бизнеса для разных уровней Спиральной динамики

2018-07-25T23:13:42Z

MaksTsepkov:

Пост на FB

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

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

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

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

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

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

Этот конфликт я наблюдал несколько раз в реальной жизни, и он — тяжелый. Кстати, в свое время про компанию CUSTIS, где я до сих пор работаю, один человек с удивлением отозвался: «Очень интересная компания. У вас столько физтехов, и вы до сих пор вместе. Обычно при успехе такие компании разваливаются на выяснении, кто из участников круче». Для решения очень важно признать за другим его вклад, и понять его логику решений, мыслить на его уровень. А это, если рассматривать с точки зрения Спиральной динамики, требует от участников подняться даже не на зеленый, а на желтый уровень. Не обязательно осознано — достаточно в своей интуитивной картине мира. Но подняться. О желтом уровне я поговорю позже, а пока — про зеленый.

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

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

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

И, наконец, бирюзовый уровень. О нем писать сложно. Про устройство организаций желтого уровня есть исследование Фредерика Лалу, книга которого «Открывая организации будущего» (мой конспект) — именно про желтый уровень Спиральной динамики, которому в оригинале соответствовал цвет teal, а не turquoise, коллизию сделал переводчик. А бирюзовый уровень никто не исследовал, хотя прототипы, на мой взгляд, уже формируются — можно смотреть на некоторые крупные open source проекты в IT, поддерживаемые сообществами, на такие массовые движения, как живые города, на сообщество соавторов википедии, и на многое другое. Если обобщать, то внутри действует множество инициатив, каждая из которых оформляется желтой командой, самостоятельно работает со своими рисками и успехом, но при этом, ощущая себя частью более широкого сообщества, делится успехом и с другими участниками, и помогает им в случае рисков и сложностей. Пока это сильно неформально, потому что существующие механизмы фиксации договоренностей не могут эффективно поддерживаться при высокой динамике изменений, особенно в случае сильно отложенного успеха, и вклада большого числа участников, и потому жизнь идет неформальна. Но тут нам должны помочь технологии блокчейн и смарт-контрактов, которые, думаю, сильно повлияют на устройство мира в этой части.

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

Основания Спиральной динамики

2018-07-25T23:07:04Z

MaksTsepkov:

Въедливый Олег Клименко решил разобраться с научными основаниями Спиральной динамики, за что я ему очень благодарен: в обсуждениях к посту Олега в группе Спиральная динамика получилось сформулировать довольно много содержания, которое я здесь изложу в виде целостного текста. А еще обсуждение привело к совершенно неожиданному открытию: когда осенью 2013 я заинтересовался Спиральной динамикой, мне офигенно повезло. Я наткнулся на описание истории экспериментов Грейвза, которые легли в основу теории, и она вызвала уважение. Оказывается, этой истории нет в книге Дона Бека и Криса Кована. Более того, большая загадка, откуда автор текста взял эти материалы: он ссылается на сайт http://spiraldynamics.com, но ни сейчас, ни в старых версиях сайта, который помнит archive.org истории экспериментов мы не нашли, нет их и на сайте самого http://ClarewGraves.com. Так или иначе, ссылка на историю сохранилась в моем первом посте: История возникновения уровней Грейвза на сайте NLPinp. Там указан автор Ilya Goz и дана ссылка на оригинал, который лежит в большой коллекции fido по вопросам психологии (оглавление) (06.08.2024: обе ссылки ведут на archive.org, сайт loopback.ru больше не работает). Я очень благодарен Илье Гозу за этот текст, и судьбе за то, что привела меня к нему в самом начале - вполне возможно, что без этого я бы прошел мимо Спиральной динамики. И я рекомендую всем интересующимся эту статью прочитать, там немного. И если кто знает, где об исследованиях Грейвза можно прочитать подробнее, просьба мне написать.

Дополнение. Через несколько месяцев после написания статьи были найдены следующие интересные материалы.

http://www.cruxcatalyst.com/2013/09/26/spiral-dynamics-a-way-of-understanding-human-nature/ - изложение теории, в статье много ссылок на другие сайты с материалами, в частности, на сайт Грейвза
http://www.clarewgraves.com/source_content/WSP_cc_edit.html Статья на сайте Клера Грейвза, начинается изложением истории исследований. Выступление Грейвза в 1971 записал William Lee, в 1998 Кован дополнил на семинаре, опубликовано в 2002. Возможно, именно она послужила источником для описания Ilya Goz.
На сайте Клэра Гейвза лежит список публикаций http://clarewgraves.com/articles.html, в числе которых - статьи в реферируемых журналах и выступления на конференциях.

Мышление моделями как базовая компетенция (ЛАФ-2018)

2018-06-18T12:50:39Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Совместное выступление с Ириной Суровой на ЛАФ-2018

Выступление на сайте конференции
Видео - на странице доклада.

Умение выделить словарь терминов предметной области, представить предметную область через диаграмму классов, а бизнес-процессы - на диаграммы активностей имеют под собой базовую компетентность мышления - способность быстрого, в темпе проекта, построения модели предметной области, потенциально незнакомой ранее, и далее - работать в этой модели, проектируя и реализуя изменения в этой области и процессов компании с помощью разрабатываемого софта. Модель надо уметь построить, сопрячь с отраслевыми, объяснять окружающим, сделав общей моделью проекта и достраивать в коммуникации. На этом основан не только DDD, но и большинство других подходов в IT, применять эту компетенцию можно не только в профессиональной работе, но и в любом взаимодействии с миром.
Но для начала эту компетенцию необходимо получить, в чистом виде ее не готовят, хотя необходимость фундаментальных курсов математики и физики в высшем образовании, а также ряда школьных предметов обосновывают именно этим.
В нашем совместном с Ириной Суровой выступлении мы надеемся выделить моделе-ориентированное мышление в чистом виде, и поговорить о подходах к его обучению. Примерно это же сейчас делает Анатолий Левенчук совместно с рационалистами, выделяя курс "мыслительного фитнеса", основ мышление на моделях как базу для курса системного мышления (https://thpectrum.livejournal.com/3514.html).

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

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

AgileDays-2009

2018-05-17T15:55:27Z

MaksTsepkov: Массовая правка: замена Категория:Конференции на Категория:AgileDays

Был на половинке конференции Ag;)leDays’09. Жаль, что не на всей.

Пишу краткие резюме по докладам в порядке прослушивания. Если что вызовет интерес, готов расширить — пишите вопросы.

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

Роман Юферев. Внедрение Scrum от менеджера — собираем все грабли. Попал на конец, и очень жаль. Ожидаю отзывов тех, кто все слышал. Роман послушал тренинг Асхата, проникся и пошел внедрять у себя scrum. Резко и сразу. Команда была сильно не готова, дошло до психологической помощи и выбрасывании фетишей — доски и еще чего-то. А потом потихоньку практики прижились. Так что надо жалеть команду, когда внедряешь.

Из интересного — говорят, у Асхата есть мапинг обязанностей «PMI->должности scrum» (или что-то в этом роде). Интересно это увидеть.

Максим Гапонов. Agile глазами менеджера: выбираем правильные очки. Опыт внедрения scrum в auto.ru, куда он пришел как менеджер отдела разработки. Проблема была в том, что разработка была сильно непрозрачна для заказчика, и потому было мнение — разработчики работают плохо. А сами они считали, что нормально работают. Внедрение постепенное и итеративное (по практикам), прозрачность была обеспечена. Заодно увеличилась скорость разработки, сначала — в 3 раза. 2 команды, архитектурная команда (как я понял, из тех же людей, супервизоры), продуктовая команда (стратегия и маркетинг). В компетенции менеджера осталось планирование активности и разработки, работа с командой, координация. Когда скорость выросла в 3 раза, выяснилось, что заказчик — не готов выдавать заранее, на итерацию. такой объем работ с достаточной проработкой, и все норовит свалиться к работе по меняющимся требованиям. Плюс срочные задачи. И это даже с недельными итерациями. В целом scrum для менеджера тяжелее, потому что надо больше думать. И требует изменений у смежников. Зато дает эффект.

Михаил Ганчиков. Scrum в Fixed-Price проектах: практический опыт. Не сначала. Опыт работы scrum в fixed-price разработке с фиксированными сроками на западного заказчика с заказной web-разработкой, интегрированной в его (заказчика) корпоративную систему. Заказчик хотел scrum, но с fixed price и сроками, с рисками на подрядчике. Проект не слишком большой, 4 месяца, 1 команда, 2 недели предварительная оценка. Аналитики были у заказчика, к оценке было 12 usecase, развернутые примерно в 20 историй, разной степени подробности и веса, 50-200 идеальных часов по предварительной оценке в показанных примерах. Они рассчитывали на команду 6 человек — 4 разработчика и 2 тестера. Дальше заказчику удалось продать 6 идеальных часов в день (фактор 0.75!), накладные расходы на scrum (планирование, ретро — 1 день/итерацию), месяц на стабилизацию версии, 10 % на обработку его хотелок по feedback (пытались 30, не вышло), 1.5 человека на управление (PO + 1/2 SM). А в стоимость часа заложили, что если команду придется увеличить в 1.5 раза (до 9) и еще кто-то останется на доводке по гарантии некоторое время, то все равно будет небольшой плюс. Хотя, быть может, что-то из написанного мною как проданное тоже заложили в стоимость часа — эту часть переговоров вел не докладчик. В целом по моим прикидкам заложенный коэффициент к оценке получается 2.5-3. Оценки в идеальных часах заказчик видел и верифицировал у третьих сторон и у себя внутри, в целом нормальные.

В результате на второй месяц команду увеличили до 9 человек, сроки получились на 3 недели больше, но в целом заказчик доволен. Выходных и сверхурочных не было, на команду сильно не давили. Заказчику сделали много дополнительных хотелок, ибо стратегический партнер. Но часть — против уменьшения первоначально заявленного scope. Manager, он product owner, помимо управления и приоритетов писал и поддерживал Accept test cases — от 2 до 25 на историю. В вики. Адская работа, так как требования уточнялись и плыли, хотя и не сильно. Часть кейсов программировали и проверяли автоматически. Заказчику отгружали релизами, он тоже тестил, посылал баги, feedback («а покрасьте отчет…») и change request (а еще выгрузку в excel надо). Change request — это объем работ, который оценивается и расширяет scope, оценки высылались и проверялись заказчиком.

Из практик — помимо daily scrum с заказчиком были ежедневные вечерние обсуждения (daily status) по ходу проекта, по ним — протоколы «минутки» (обязательно нужны!). Заказчику посылались метрики — сжигание оцененных историй. Иерархия разбиения — 3 уровня, usecase — истории-задачи (уровня реализации). На начальной оценке часть usecase была совершенно непонятна по объему (например, «перегрузить данные из старой системы»), так как выяснять было некогда, то их оценивали в некоторых допущениях, которые посылались вместе с оценкой. Заказчик или одобрял допущения, или возражал — тогда оценка менялась.

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

Dan Rawsthorne. Who is your Product Owner, and what does he/she do? Увы, понимание разговорного английского оставляет желать лучшего… Но в целом было понятно и это интересно. Презентация — тренинг доя PO, но давались фрагменты. Если кратко, то PO — это Project Manager. В полном объеме. Со всеми правами, которыми он не должен злоупотреблять, так как команда — вещь тонкая. Но PO отвечает за продукт (подставляет свою шею). А еще он — team lead. И он — внутри команды. Снаружи есть еще Business Owner. А SM — лишь поддерживает процесс. По итогам итерации различается Sprint Review, которое с PO и Retrospective, которая без него. Дуализм PO — в своей роли и PO как член команды — есть. Но подробностей в эту сторону в голове не осталось. Из явного — он не участвует в некоторых мероприятиях.

Была упомянута RASCI-модель: Responsible — команда, Accountable — PO, Support — SM, Consulted — внешние эксперты, Informed — всех вокруг…

Презентовалась конструкция Scrum of Scrum — с реальной командой менеджеров продукта, в которой свои PO и SM, командами по разработке, и двумя виртуальными командами — PO и SM. Но без подробностей.

Показывалось разделение компетенций Business Owner (release goal, product roadmap, vision), Product Owner (продукт все внутри условий BO) и SM (организация команды).

Планирование — 4 уровня, Product — Capatibility — Stories — Tasks. Backlog — stories. Пример Capatibility для сайта — продавать билеты на самолеты, резервировать отели… Оценка story — size (small/medium/large) с коэффициентами, например, 2/4/8 для перевода в SP. И дальше — по опыту, мощность команды в SP. Для отбора в sprint — баланс Scope/Effort/Debt (вроде как новые фичи/исследования/долги). Tasks — на планировании, причем без PO (команда приняла Stories и сама его делит). Визуальный образ планирования — на доске, слева — backlog, правее карточки с невзятыми задачами. Может, идея прямо так и проводить, но явно это не высказывалось. Оценка задач — в идеальных часах.

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

Сурен Самарчян. Выявление и решение важнейших проблем компании. По исследованиям Гарварда, все сильно успешные компании (лидеры) отличаются от прочих наличием 5 вещей:

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

Процедуры в разных компаниях — различаются. Тойота 20 (30?) лет назад опубликовала свой, теперь его всячески изучают и пытаются использовать, но повторить с теми же результатми — пока не получилось. Сам Сурен про метод знал, но проникся — только на крутом тренинге в штатах с участием звезд. Метод называется «A3» — в честь специального бланка на формате А3, который надо заполнить по ходу решения и который концентрирует это самое решение. Требования на выходе — за 10 секунд человек, столкнувшийся с такой же проблемой должен опознать ее на бланке, и за 10 минут — понять, как надо решать. Тойота давно хочет перейти на А4, но пока не получается.

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

Лица — владелец проблемы (ответственный) и куратор. Background (задерживаются релизы). Current State (текущий задержан на 2 недели). Корень проблемы. Контрмеры по проблеме в моменте. Изменения стандартов, чтобы исключить проблему в будущем. Заполняется, естественно, по мере решения.

Для поиска корня — искать причину. Можно применять метод «5 почему». Можно — рисовать графы причинно-следственных связей, там будут циклы, а будет — коревое влияние. Пример графов — показывал, но быстро. Контрмеры — всегда эксперимент, сколько бы времени не потратили на планирование. Придумали, не получилось — анализируйте. придумывайте дальше. Когда контрмеры провалились — самый сложный момент для директора и менеджера, всегда найдется пол организации, которые будут говорить «ну вот, мы же говорили — не надо ничего менять, а это — особенно».

Принцип поиска — задавайте вопрос «почему», а не «кто». Даже если этот кто — виноват реально. Потому, что тут же есть вопрос «если этот кто создает такие проблемы, то почему он здесь работает».

При внедрении таких, или аналогичных практик — нужно участие первых лиц, лидеров. Если поручают тому, кто свободен — обречено на провал.

Интересно и полезно. Лист стоит найти.

Software Best Practices-2007

2018-05-17T15:35:47Z

MaksTsepkov: Новая страница: «<blockquote> Конференция Software Development Best Practice прошла в 2007 году. Сайт конференции http://www.sdexpo.ru/ уже…»

Конференция Software Development Best Practice прошла в 2007 году. Сайт конференции http://www.sdexpo.ru/ уже недоступен, но анонсы остались: один и другой. Далее - мой отчет о конференции, опубликованный тогда внутри компании - публичного блога у меня еще не было.

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

Ключевая вещь, которая заинтересовала и вдохновила - Agile programming и ее проявления в виде extreme programming, scrum и композитных методов. Для меня, собственно, было ново и интересно выступление менеджеров, команды которых практически используют эти методики в реальных успешных проектах. В том числе сертифицируя их применение по ISO 9000. А это означает, что имеются готовые технологии и методологии, и можно основываясь на них строить процесс производства. На уровне общих слов они сильно пересекаются с прогрессивной частью имеющихся у нас в компании методик и тенденций, однако тут важны нюансы и комплексность подхода. Поэтому было бы интересно оценить, и, возможно, претворить в практику. Во всяком случае, правильно изменения в нашей компании вести в этом русле, а не вопреки ему.

Далее по докладам.

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

Simon Monk, Momote ltd: Доклад по Agile Programing в виде Extreme programming. Основная идея - это хорошо и применимо на практике. У них небольшие этапы или проекты: 10 дней маленький, 20 - средний, 40 - большой. Это астрономический срок разработки, к этому есть стандартные времена на постановку (2-4-5) и на внедрение (3-4-5). Группы по 7 человек - менеджер, 4 разработчика, 2 тестера. Реально используют парное программирование. Говорил, что много чего меряют по самому процессу разработки и внедрения, считают структуру затрат на проект, представляют ее заказчикам.

Alexey Kovyazin GodeGear: Развитие software, 1 трек. Достаточно полный и скучноватый обзор истории развития ПО для PC, хоть и вызвавший (у меня) воспоминания по прошлому. По современным тенденциям - слабо. Очевидное противостояние .Net и Java как платформ, и как стоящих за ними корпораций, с рассуждениями, что может они договорятся, а может - нет. Но была интересная мысль, что действительно новые решения. определяющие тенденции. всегда рождались не внутри гигантов, а приносились со стороны, после чего кто-то из гигантов это, как правило, перекупал и далее развивал. То есть идеи приходят сбоку. А еще очевидная мысль, что разработчики не лояльны, и выбирают средства по текущему состоянию, а не за исторические заслуги.

Круглый стол по Agile: Участники (StarSoft, Motorola в России, Artezio) - действующие менеджеры компаний, в которых успешно все это применяется. Собственно, этим и интересно, хотя сам разговор - не очень. Они обсудили некие темы по практике применения этих методик. Из интересного - сертификация этого процесса по стандартам ISO, то есть можно вынимать нормативно положенную документацию и метрики, характеризующие качество процесса, не взирая на его экстремальный характер. Звучала цифра, что применение SCRUM удваивает производительность по сравнению с традиционными методиками. По оплате - уход от fixed cost к target cost, с делением рисков пополам с заказчиком.

Bertrand Meyer: К полностью автоматическим тестам. Доклад хорошо описал Игорь Беспальчук в своем отчете, и я не вижу смысла повторяться. Хотя меня как программиста всегда интересовало тестирование, выходящее за рамки модельных примеров, с которыми и так все понятно. И тут мне не очевидно, что из автоматических вызовов может нечто разумное получится.

Olga Ananko, Security testing: Увы, оказалось что это Web. Хотя на уровне общих слов все это применимо всюду, но с нашей практикой связано слабо. То, что они тестируют - понятно. Это ввод неверных параметров, попытки сделать незаконные по бизнесу действия или превысить границы своих прав. Я надеюсь, что наши тестеры тоже это делают, но далеко не уверен. Во всяком случае, судя по широкому и произвольному предоставлению прав в СМ, это не является большой заботой заказчика. Но конкретные примеры в докладе ограничивались Web-приложениями, и это не интересно.

Roman Elizarov: Практически доклад был о некоей системе обработки сообщений, которая должна переваривать их со скоростью до 1 млн. сообщений в секунду. Причем очень важно было избежать катастрофического падения производительности при превышении каких-то порогов. Очень интересно рассказанный, были убрана специфика конкретной системы и оставлена методологическая суть. Первое - не надо использовать MiddleWare. Потому что они реализуют некий сложный стандарт, который по природе не может быть быстрым и давать более 10K сообщений. При этом в конкретном приложении полный функционал этого стандарта обычно не нужен, на чем и экономим. Второе - если нужна хорошая производительность, это надо закладывать в архитектуру. Показаны два тонких места - синхронизация, то есть переключение процессов, и выделение памяти, которое надо мерить со сборкой мусора, а не отдельно. Ну и соответственно, как пример: для обработки сообщений оптимален типовой шаблон с итератором, позволяющий обрабатывать их пачками с внешней или внутренней синхронизацией не по каждому сообщению, и не диктующий способа выделения памяти. В общем, шаблоны полезны не только по стилю, но и по сути. Кстати, с выделением памяти: свой пул объектов, скорее всего, будет медленнее стандартного, он может быть полезен только для больших объектов, а никак не для скорости. Они добились требуемого 1M сообщений, ограничением стала 10Mb сетка, которую они грузят полностью.

Sergey Belov, StarSoft: Guerilla XP. Что делать, если заказчик не хочет extreme, а команда работает именно так. Тогда менеджеру приходится работать за заказчика. Ну и рассказывался пример проекта, история 2.5 года, 18 итераций, 17 человек команда, сейчас 1500 пользователей. По срокам итераций: ошибались пару раз на пару дней для месячной итерации. Сложнее всего - аналитику, так как он фантазирует. При планировании итерации оставляют резерв для изъятия, чтобы заменить это доработками, если аналитик не угадал. плюс усиливают команду тестеров, она тоже работает за заказчика. Используется парное программирование, задания режутся по дню, пары каждый день меняются. Плюс используется карусельный codereview - один программист из команды смотрит и рецензирует заливки за день, плюс тех.лидеры соседей. Общая идея: у программиста 3 продуктивных часа в день, пусть эти три часа он и программирует, но остальное время он тоже может приносить пользу. Используется ежедневная сборка и проверка - unit test, module test + high level test. Как-то так.

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

Решаем проблему заказчика, а не слепо выполняем задание (AnalystDays-8 2018-04)

2018-04-27T08:05:07Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Выступление 27.04.2018 на AnalystDays-8
Доклад на сайте конференции, там ссылка на видео за 1$ (есть подписка)

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

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

Solving the client’s problem rather than blindly doing the task

Clients often accompany their request for new features with an idea of what exactly it is necessary to develop. Performers, in their turn, embark on designing the features required immediately, without finding out what problems they are supposed to solve. As a result, the solution developed does not meet the client’s expectations, and this may be due to several reasons. First, the customer’s idea may not be relevant to his situation initially. Secondly, the solution may turn out to be wrong because of the details of the implementation. Thirdly, it happens that the task can be accomplished faster and easier. For this reason, the analyst should define the client’s problems as early as on the first stage of the project.

My presentation demonstrates how it can be done and provides the examples of how the immersion into the business plan of the project changes the ways of solving the problem.

Тесты по Спиральной динамике

2018-04-22T11:55:45Z

MaksTsepkov:

Мой тест по спиральной динамике: 87% бирюзового, 77% желтого и 75% оранжевого. Я прошел на http://jobEQ.net 13.10.2013, только заинтересовавшись системой - чтобы получить чистый результат. Тест тогда был доступен бесплатно на русском для личного использования. К сожалению, в России его начали активно и статистически заметно использовать для оценки персонала, а эта опция - платная, поэтому русский вариант закрыли, а английский вроде по-прежнему в бесплатном доступе есть. На GoEvolution-2016 я общался с Анной Ивановой, которая переводила его и является представителем в России, и она обещала поспособствовать интересующимся пройти тест за небольшие деньги.

В феврале 2019 Анатолий Баляев, переводчик книги по Спиральной динамике, популяризатор и евангелист этой теории в России, тренер и консультант, использующий эту теорию на практике, опубликовал для общего использования созданный им тест. Тест был качественный, и не только выдает результат по цветам, но и ряд других характеристик. К сожалению ключевое слово тут - был. Тест был доступен на test.spiraldynamics.ru, а сейчас (01.2024) домен не доступен, а spiraldynamics.ru стал перенаправлением на spiraldynamics.pro. На этом сайте есть два других теста: по корпоративной культуре и по струнам первого порядка - какое счастье вам отзывается. А исходный тест, насколько я понимаю, больше недоступен. Жаль. Вот как это выглядело (archive.org). Интересно, что archive.org показывает не только тест, но и мой результат.

Про другие тесты, которые я проходил. Тест из Школы жизни все-таки очень поверхностный. http://sdtest.ru - он лучше, особенно потому, что выбирается несколько ответов, а не один. Но оба теста не слишком хорошо различают старшие цвета, желтый и бирюзовый. Они считают, что на бирюзовом непременно думаешь о целях всего человечества сразу. А это не так, это на зеленом от человека до счастья человечества один шаг, потому что все вместе делают дело в плоской организации (движении). А на желтом и бирюзовом организации сложные (у Лалу ясно видно). А разница в том, что на желтом ты мыслишь рамками и целями своей организации, не слишком большой, а на бирюзовом границы организации становятся полупроницаемыми, а цели начинают вырабатываться совместно, внутри и снаружи. В посте на FB насыпали еще ссылок, но их я не проходил.

Целостное представление деятельности предприятия на диаграммах учета (Соколовские чтения-2018))

2018-04-19T18:44:00Z

MaksTsepkov:

Целостное представление деятельности предприятия
через потоки ресурсов отражаемые на диаграммах учета
Integrated reflection of the business as resource flow, presented on the accounting diagram
Соколовские чтения «Бухгалтерский учет: взгляд из прошлого в будущее» Санкт-Петербург, 19-21.04.2018

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

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

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

Доклад является развитием моего доклада на Соколовских чтениях 2017 года, в котором были показаны общие принципы организации диаграмм учета. Я надеюсь, что доклад позволит участникам конференции начать применять такие диаграммы в своей профессиональной деятельности.

Agile и другие новые технологии управления для организации работы креативных команд (KazanEventExpo-2018)

2018-04-11T19:52:29Z

MaksTsepkov:

Выступление 12.04.2018 в рамках Kazan Event Expo

В выступлении был развернутый рассказ, аннотацию которого можно прочитать на странице категории, а краткие версии можно посмотреть в выступлениях Agile и бирюзовые организации - два пути менеджмента в мир третьей волны (Круглый стол в SPb 2017-11) и Что могут практики Agile и холакратии и нужны ли они Вашей организации (ПиР-2017)

Скачать весь pdf

Применим ли новый менеджмент в логистике (Конгресс по логистике 10.04.2018)

2018-04-09T22:14:54Z

MaksTsepkov:

Еще про новый менеджмент

Первый Конгресс руководителей и специалистов по логистике и цепям поставок компаний — производителей и ритейлеров 10.04.2018

Подробное изложение можно посмотреть в докладах Agile и бирюзовые организации - два пути менеджмента в мир третьей волны (Круглый стол в SPb 2017-11), Что могут практики Agile и холакратии и нужны ли они Вашей организации (ПиР-2017) и Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017). Более поздние материалы - статья «Agile и бирюзовые организации - ответ менеджмента на вызовы новой промышленной революции» и серия статей «Менеджмент цифрового мира», позднее опубликованная в виде книги «Менеджмент цифрового мира», а для тех, кто предпочитает слушать - доклад Эволюция технологий управления (ПИР Сибирь-2019).

Скачать весь pdf

Самоуправление как технология менеджмента четвертой промышленной революции (ЦЭМИ 10.04.2018)

2018-04-09T21:40:36Z

MaksTsepkov:

Выступление на круглом столе на Всероссийском Симпозиуме «Стратегическое планирование и развитие предприятий»
Центральный экономико-математический институт РАН 10.04.2018 Видео ожидается.

Прозрачность движения к результату в Agile для руководства (CodeFest-2018)

2018-04-01T02:49:37Z

MaksTsepkov:

Доклад на CodeFest-2018 31.03-01.04.2018 в Новосибирске
Доклад на сайте конференции (вместе с презентацией и видео)
Видео на youtube

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

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

Ссылки по OMG Essence

2018-03-25T18:58:24Z

MaksTsepkov:

Страница стандарта http://www.omg.org/spec/Essence/, доступен только в виде pdf

В стандарте, помимо языка, приведены следующие полезные примеры.

Методы:
- Scrum - раздел E.2.2
- Waterfall - раздел E.2.4
В разделе E.2.5 - варианты lifecycle для разных видов проектов и сопровождения
Способы расширения
- Что меняется в Scrum, если использовать User Story вместо абстрактных Product Backlog Item E.3.1 и E.2.3
- Добавление Business Analysis и нужд стейкхолдеров - A.2

Practice Library от Ивара Якобсона https://practicelibrary.ivarjacobson.com/ содержит описание большого количества методов в формализме OMG Essence. Для доступа требуется бесплатная регистрация. Ссылки дальше ведут на корневые страницы, и надо проваливаться вглубь за подробностями

Agile - https://practicelibrary.ivarjacobson.com/content/agile-essentials
SAFe - https://practicelibrary.ivarjacobson.com/content/agile-scale-essentials, включая работы с архитектурой, управление продуктом и многое другое
Некоторый вариант итеративного RUP - Essential Unified Process https://practicelibrary.ivarjacobson.com/content/essential-unified-process
- В нем отдельно интересны UseCase 2.0 https://practicelibrary.ivarjacobson.com/content/use-case-20-essentials-publication

Методы Agile и бирюзовых организаций для организации работы креативных команд (лекция 03.03.2018 ВШЭ СПб)

2018-03-03T08:12:49Z

MaksTsepkov:

Гостевая лекция Методы Agile и бирюзовых организаций для организации работы креативных команд 
прочитана 03.03.2018 в рамках майнора Высшей Школы Экономики в Санкт-Петербурге

В связи с отключением электричества видео не сохранилось. Поэтому можно смотреть доклады

Анонс на сайте ВШЭ
О конструкции новых управленческих технологий и о том, как они отвечают на вызовы нового мира, включая приход нового mindset поколения соцсетей в своей лекции будет рассказывать Максим Цепков http://mtsepkov.org/Agile, IT-архитектор и бизнес-аналитик, эксперт и навигатор по миру Agile и Спиральной динамики.
Грядущая промышленная революция положит конец современному индустриальному обществу, что приведет к переосмыслению ценностей и новым способам управления общества и бизнеса. Это предсказал Элвин Тоффлер в книге «Третья волна» в далеком 1980 году. Прошло почти 40 лет, и сейчас новые способы организации бизнеса уже не являются каким-то неопределенным будущим, они оформлены в конкретные новые технологии управления: методы Agile, возникшие в IT-отрасли более 15 лет назад, технологии бирюзовых организаций, игрофикацию. О конструкции новых управленческих технологий и о том, как они отвечают на вызовы нового мира, включая приход нового mindset поколения соцсетей в своей лекции будет рассказывать Максим Цепков (http://mtsepkov.org/Agile), IT-архитектор и бизнес-аналитик, эксперт и навигатор по миру Agile и Спиральной динамики.
Приходите на лекцию! Вам жить в новом мире третьей волны и применять эти технологии в действии!

Будущее уже наступило: от Agile к Бирюзовым организациям (Серебряный Лучник-2018)

2018-02-13T18:44:31Z

MaksTsepkov:

Серебряный Лучник - академический день
Анонс выступления 
14.02.2018, Москва, факультет журналистики МГУ

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

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

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

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

CustIS Accounting (1998)

2018-02-06T08:34:27Z

MaksTsepkov:

CustIS Accounting — передовая технология автоматизации учета и анализа финансово-хозяйственной деятельности

Рахтеенко В. Е., Хомюк С. В., Цепков М. А.

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

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

Если Вы почитаете рекламные материалы и поговорите с персоналом фирмы, производящий продукт, то с некоторым раздражением заметите, что все предлагаемые продукты на первый взгляд одинаковы: все «идут от документа», все «работают в технологии клиент-сервер», практически все имеют версию системы, работающую на Oracle и т. д.

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

Все эти недоумения рассеиваются несколько позже. При более внимательном рассмотрении Вы начинаете понимать, что под терминами «клиент-сервер», «документы» и даже «технологии Oracle» часто понимаются достаточно разные вещи. Что же касается предметной части, то нередко вы убеждаетесь, что предлагаемая Вам система не полностью отвечает (или полностью не отвечает) Вашим потребностям. Естественно, сразу встает вопрос о доработке продукта конкретно для Вас, и бойтесь тех, кто скажет, что это дешево.

Тяжела задача авторов этой статьи — надо Вас как-то убедить, что предлагаемая система CustIS Accounting (действительно одна из многих-многих), решает конкретный класс задач лучше, чем кто-либо другой. Исходя из этого, определим вначале такие задачи, а потом (куда деваться!) — начнем по косточкам разбирать, какими характеристиками должна обладать система, чтобы такие задачи решать хорошо, и как эти характеристики реализованы в CustIS Accounting.

Зная на своем опыте, как тяжело вникать в объемные теоретические построения, мы решили построить изложение материала на живом примере.

Кроме этого, последняя треть статьи посвящена изложению примера реализации в CustIS Accounting конкретного документа.

Технология согласования некоторых алгоритмов с архитектурой векторно-конвейерных ЭВМ (Вопросы Кибернетики 1987)

2018-02-06T01:00:20Z

MaksTsepkov:

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

IT-источники знаний о мышлении

2018-01-27T23:47:39Z

MaksTsepkov:

Оригинал в ЖЖ, сообщество thpectrum

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

После этой преамбулы перехожу к идеям.

1. Разработка софта, включая написания кода - чистое мышление, соответствует этапу проектирования (НИОКР) для других отраслей деятельности (например, разработки самолетов). Тезис - старый, насколько я знаю, был впервые сформулирован Ривзом (Reeves) в 1992 в статье http://www.developerdotstar.com/mag/articles/reeves_design.html (перевод http://lib.custis.ru/Reeves). Но при этом результаты этого мышления непосредственно зафиксированы в коде программ. Об этом свидетельствует закон Конвея (https://en.wikipedia.org/wiki/Conway's_law), гласящий что структура системы соответствует структуре коммуникаций в команде, которая разрабатывала эту систему. Таким образом, в коде софта мы можем наблюдать результат коллективной мыслительной деятельности команды разработки. А практика хранения кода в системе контроля версий позволяет прослеживать не только текущие результат, но и логику развертывания этого мышления во времени. Если к этом добавить концептуальный слой проектирования, история которого зафиксирована в версиях вики, а также сопутствующую этому переписку в таск-трекере, которая содержит основания для изменений в коде, то получается большой массив первичных данных для исследования мышления. При чем он доступен в исходном виде для большого количества открытых проектов самого разного размера. При чем это мышление касается практически всех областей деятельности человека, а так же физического мира, поскольку все они в той или иной мере поддержаны и воплощены в софте.

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

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

2. Эрик Эванс, разрабатывая DDD (Domain Driven Design, https://en.wikipedia.org/wiki/Domain-driven_design) в своей концепции ограниченных контекстов перенес шаблоны проектирования объектно-ориентированного подхода (ООП) на онтологическую работу - построение понятийной модели предметной области (домена). При этом сформулировал, что прежняя практика построения единой и непротиворечивой модели и связанного с ней понятийного аппарата является слишком сложной для реализации в темпе проекта (как и построение монолитного софта), и потому онтологии предметной области должны быть модульными, с точками расширения, и следует применять для их построения те же приемы, которые наработаны для построения софта в ООП (наследование, библиотеки общих частей, изоляция разных областей, инкапсуляция и т.п.). Последующее развитие DDD показало, что именно это является наиболее ценной частью концепции. Но сформулировано все это на языке IT и для IT-инженеров, и, как водится, It-шники не слишком заботятся о том, чтобы обратным ходом попробовать включить это в "большую науку", переформулировав в принятых там терминах и связав с другими концептами. Мне кажется, в рамках формулирования курса могло бы быть интересным подумать о включении в него и этой составляющей тоже.

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

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

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

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

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

2018-01-27T07:25:16Z

MaksTsepkov:

Еще про самоопределение

Выступление на TeamLead Conf 8-9.02.2018 в Москве 
Доклад на сайте конференции
Пост на FB
Видео, о докладе рассказано в числе других в посте о конференции на хабре
В 2022 доклад был доработан Как строить образ будущего и идти к нему - схемы самоопределения (Saint Teamlead-2022) и Самоопределение: чего я хочу от жизни и работы (SQAdays-2023) и написана серия статей в Категория:Самоопределение

Рассказ будет новой версией моего весеннего доклада Самоопределяйся технологично!

Дополнение. Тема развивается, следующая версия Как строить свой профессиональный путь - схемы самоопределения в QA-контексте (COMAQA-2018), а на Saint TeamLeadConf-2019 был практикум Строим свой профессиональный путь - без видео, но слайдов больше и есть слайды про применение схем для семьи. Существенное расширение на AnalystDays-2022 Как строить образ будущего и идти к нему с фокусом на создании вдохновляющего образа будущего, и по тем же слайдам был доклад на конференции школы Левенчука с фокусом на конструкцию схем самоопределения. Тема развивается, текущее состояние смотри Категория:Самоопределение.

Управление знаниями: какие документы нужны и что в них фиксировать (TeamLeadConf-2018)

2018-01-27T07:20:33Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Выступление на TeamLead Conf 8-9.02.2018 в Москве 
Доклад на сайте конференции
Расшифровка доклада в статье на habr
Пост на FB

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

Маленький пример: в формате user story "как <роль> я хочу <сделать что-то> для того чтобы <достичь целей>" часть с целью появилась не сразу. Она нужна, чтобы разработчик мог поставить себя на место пользователя, если в процессе реализации надо выбрать между несколькими альтернативами. Казалось бы, можно спросить, однако прерывание разработки – дорого, и разработчики часто додумывают за пользователя, и часто ошибались. Указание цели пользователя позволяет уменьшить число неверных решений. Кстати, сам формат появился при переходе к итеративной разработке как средство обеспечить инкрементальную поставку ценного продукта.

Долговременная документация проекта тоже служит коммуникации: ты-нынешний с тобой-будущим, которому надо быстро вспомнить контекст; ты и пользователи системы и другие.

Подход к проектированию документации аналогичен проектированию интерфейсов: описываешь кейсы коммуникаций, определяешь, какими документами и артефактами это обеспечивается, понимая, что каждый документ имеет свою цену, и потому часть можно оставить в головах людей. И только после определения документов стоит выбирать, какими инструментами пользоваться: Wiki, Google Docs, что оставить в Task tracker и так далее.

Управление знаниями имеет еще один аспект, который находится за рамками проекта - обмен профессиональными знаниями между специалистами разных проектов. Здесь я рассчитываю поделиться практиками и кейсами, знакомыми мне из участия в сообществе Knowledge Management Russia, в конференциях которого я принимаю участие с 2010 года (отзывы на моем сайте http://mtsepkov.org/KM).

В целом доклад развивает мое выступление Agile и управление знаниями в ИТ-проектах на конференции KM Russia 15-16.12.2016.