Я — Максим Цепков приветствую Вас на своем сайте
К разделам ⇓ Современный менеджмент ⇓ Модель личности ⇓ IT: архитектура и бизнес-анализ ⇓ Блог ⇓ О конференциях
Я в сетиTelegram канал Linkedin
Кто я и что делаю?
Что я делаю?
На сайте - мои доклады и статьи, 175 отчетов с конференций, конспекты книг, также блог, который я веду с 2010 и другие материалы. Дальше - тематический список основных материалов и ссылки на тематические разделы сайта. Я открыт к общению через социальные сети и по почте (лучше телеграм) и обычно отвечаю на сообщение в течении 2-3 дней как минимум квитанцией о получении. Если она не пришла — значит сообщение перехватила спам-оборона и надо пробовать связаться иным образом. Подробнее обо мне можно прочитать на этой странице. |
|
Современный менеджмент и развитие обществаТематические страницы: Agile, Бирюзовые организации, Спиральная динамика, Управление проектами, статьи «Менеджмент цифрового мира» Я знаком с Agile-методами с 2007, а знакомство со Спиральной динамикой в 2013 дало понимание, что Agile-методы - не просто особый подход к управлению в IT, а зарождение менеджмента цифрового мира, вызовы которого пришли в ИТ раньше других. Спиральная динамика описывает современное развитие общества через изменений конструкции ценностей, подробности в этой статье. Знакомство с книгой Фредерика Лалу «Бирюзовые организации» показало альтернативу, которая встроена в общую картину. Как результат осмысления, зимой 2019-2020 была написана серия из 59 статей, по которой в 2022 опубликована книга «Менеджмент цифрового мира». Тема продолжает развиваться. Материалы для знакомства с big picture современного менеджмента.
Пара визионерских докладов о будущем развитии мира
Помимо докладов, которые дают big picture, у меня есть доклады на отдельные актуальные темы
|
|
Самоопределение и модели личностиМодели soft skills позволяют строить эффективную коммуникацию и управление проектами, а взгляд архитектора помог мне на основе моделей нейрофизиологии и психологии собрать в 2024 единую модель в книге «Инженерная модель личности: Меняя себя и других — понимай устройство», доступной также в виде серии статей. С моделями soft skills тесно связана тема личного самоопределения, и зимой 2022-2023 у меня вышла серия статей по самоопределению. Тематические страницы: Модели softskill, Самоопределение, Модель личности, Спиральная динамика, Модель Белбина По этим темам у меня есть большое количество докладов, часть из них легло в основу статей, другие - развивают тему. В книге изложение идет от базы к прикладным вопросам, а в большинстве докладов - наоборот, от практических задач и прикладных моделей для их решения. Вот основные доклады.
Новые доклады
Доклады про отдельным моделям
|
|
IT: архитектура и анализТематические страницы Архитектура и анализ, DDD, Системное мышление, Акторная модель
|
|
Мой блогПоследний пост блога 2024-12-10: Александр Бындю. Антихрупкость в ИТ (оглавление блога) Прочитал книгу Саши Бындю «Антихрупкость в ИТ», пару лет она лежала у меня в очереди. Это — очень полезная книга для тех, кто хочет и кому нужно разобраться в устройстве современных ИТ-проектов. А нужно это тем руководителям, которые выступают как заказчики ИТ-проектов или хотят завести у себя ИТ-разработку. Не факт, что они хотят в этом разбираться, но тогда это превращается в игру «повезет — не повезет», которая знакома почти всем, кто искал себе бригаду для ремонта или, что серьезнее, психолога или врача в не очевидном случае. Это не значит, что прочитав книгу, и разобравшись в ней ты сам сможешь делать ИТ-проекты. Но ты сможешь вести квалифицированный диалог с ИТ. При этом в книге — множество ссылок для тех, кто захочет разобратья глубже в конкретных вопросах. В книге описано множество граблей, которые являются типичными в ведении ИТ-проектов. И современные методы, которые правильно применять. Прежде всего это касается организации работ, включая модель «fix time and budget, flex scope», а также техник выявления целей проекта — impact mapping, user story mapping. Об этих техниках я хочу заметить следующее: в них содержание важнее формы, однако форма гарантирует, что содержание будет адекватным. Как применение scrum при соблюдении формы гарантирует отказ от микроменеджмента, от чрезмерной специализации и еще от ряда проблем в ходе проекта. Так и impact mapping гарантирует понимание целей и ценности проекта в виде изменений в деятельности конкретных стейкхолдеров и синхронизацию этого представления между разными стейкхолдерами. Естественно, для этого использование формы должно быть не догматичным, надо понимать лежащие за ними смыслы и достигать их. Что касается части книги, посвященных трансформации монолита в микросервисную архитектуру, то я бы к ней сформулировал следующее замечание. Эдвард Йордан в книге «Смертельный марш» пишет, что каждое новое поколение ИТ-шников уверено, что с помощью новых. современных методов оно сможет успешно делать проекты, а не проваливать бюджет и сроки, как предыдущие поколения, но эта уверенность всегда оказывалась ложной. Йордан пишет это на основании 30-летнего опыта, увидим несколько поколений, и эти слова продолжают быть актуальными. Кстати, книгу Йордана я всем рекомендую, она остается актуальной, не взирая на многократную смену технологий разработки и ее организации. Так и тут: в книге — уверенность, что микросервисная архитектура — решение проблем, не взирая на увеличение сложности общей конструкции, о которой он говорит. Реально микросервисная архитектура появилась для того, чтобы обеспечить горизонтальное масштабирование производительности, которое не могло обеспечить железо. за счет разворачивания множества инстансов и гибкого управления этим. Заодно повысилась отказоустойчивость в целом. За это платят сложностью конструкции, и увеличение нестабильности работы при обработке конкретного запроса пользователя. И вот этот эффект от микросервисов нужен не столь часто. Позднее был обнаружен появился еще пара эффектов. Во-первых, если разбивать на микросервисы достаточно мелко и хорошо покрывать тестами, то можно не беспокоиться, что когда-то придется разбираться в сложном коде старого сервиса, его можно будет просто относительно дешево переписать. Во-вторых, поскольку обращения между сервисами — много дороже внутренних вызовов, предусмотренная архитектурой изоляция сервисов реально присутствует в коде, это борьба с влиянием закона Конвея. При этом API можно еще проконтролировать внешними средствами на соответствие спецификации. Вот эти причины реально играют при выборе микросервисной архитектуры, хотя не всегда осознаются. Хотя закон Конвея так просто не победишь, все равно появляются микролиты — комплекс микросервисов с сильным взаимодействием. А вот с поставкой фич — сложнее. Она возрастает только в том случае, если новые фичи преимущественно реализуются за счет изменений 1-2 микросервисов. Это сильно повышает требования к декомпозиции, и этого удается достичь не всегда. Чаще запрос пользователя отрабатывает некоторый конвейер микросервисов, и для новой фичи его надо достраивать более, чем в одном месте. Это как с бизнес-процессами при функциональной организации компании: они протекают через большое количество отделов, и реорганизация затрагивает многие. Но если вы выбрали микросервисную архитектуру, то книга дает очень хорошее описание, как они устроены. Что важно — это описание уровня заказчика, которое позволяет обсуждать архитектуру и реализацию с разработчиками. Обсуждать — важно, потому что они за полгода сделают проект и уйдут на другой, а заказчику жить с этим годы. Так что неплохо представлять, как оно устроено, какие заложены возможности масштабирования и развития и каким образом их предполагается реализовывать, когда потребуется. Так что эту часть книги я тоже рекомендую всем, кто выбрал микросервисную архитектуру. Или тем, кто рассматривает ее как один из вариантов — там показано, в чем вам придется разбираться. Что касается заключительных глав, посвященных low-code подходу, различным стратегиям трансформации старой системы, а также работе с техническим долгом, то они, опять-таки, актуальны для всех проектов, независимо от того, выбрали вы микросервисную архитектуру, или какую-то другую. Кстати, если говорить про low-code, то я помню предыдущую волну визуального программирования в начале нулевых, когда многие были уверены, что разработчики сделают платформы, некоторых конечные пользователи будут собирать системы, просто двигая квадратики. BPMN-движки родились именно тогда, как одна из ветвей этого подхода. И мы тоже для наших заказчиков примерно в те годы пробовали сделать платформу, где бы логику приложения бизнес-технологи заказчика настраивали через метаданные, хотя и не визуально. Оказалось, что сложновато, настраивали наши аналитики. Правда, во многих случаях — без обращения к разработчикам. Так что скепсис Саши по поводу повсеместной применимости, которые пропагандируют авторы платформ, я разделяю. Что не означает отсутствия преимуществ, о них в книге тоже хорошо написано. На этом — все. Книга мне доставила реальное удовольствие, и я жалею, что так долго до нее добирался.
 Cкрайбинг моего выступления Будущее уже наступило: от Agile к Бирюзовым организациям (Дни PR и маркетинга на Юге 2017)
|
Другие разделы сайтаМои Доклады и Статьи, Отчеты с конференций, О книгах, Управление знаниями, СМД-методология, Общество, Экономика. |
Я буду рад любым комментариям и обсуждениям. Авторизация для этого через регистрацию на сайте.
MaksWiki содержит 2684 страниц.
