Викилоги

Пятнадцатая статья серии «Менеджмент цифрового мира» рассказывает об определении областей применения Agile-методов Место Agile-команд в компании на основе анализа характера и сложности деятельности, а также наличии компетентных специалистов. Полное оглавление - на моем сайте http://mtsepkov.org/NewMngSeries Надеюсь, это тоже будет полезно и интересно.

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

Пост на FB

Четырнадцатая статья из серии «Менеджмент цифрового мира» «Полная схема Scrum — работа с бэклогом и релизный цикл» На ней я завершаю рассказ про схему Scrum. В следующей статье я переключусь с описания методов на рассказ о месте Agile-команд в большой компании, а потом опять вернусь к методам Kanban, затем — фреймворки масштабирования Agile и много другого материала, включая рассказ о кейсах трансформации. Полное оглавление — на моем сайте http://mtsepkov.org/NewMngSeries

Петр Щедровицкий опубликовал лекцию «Что такое мышление?», содержащую развернутую карту представлений о мышлении, включая историческое развитие этих представлений и самого мышления у человечества и развитие представлений ММК. Лекция интересна и я дальше расскажу о тех смыслах, которые из нее извлек и об ассоциативных размышлениях, которые она вызвала. Подчеркну: все это — моя интерпретация, а если вам интересно, что именно сказал Петр — читайте саму лекцию.

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

В то же время, именно устройство «мышления до», представляет собой наибольший интерес в наше время перехода к от физического труда к умственному труду. Потому что именно в нем творится магия, известная как Дуга Эйнштейна - интуитивное прозрение, с помощью которого разум синтезирует новые конструкции идеальных объектов или, в терминах СМД - знаковых форм. Он до сих пор не объяснен, хотя продвижение есть. И Пользуясь случае, хочу привлечь внимание не только к статье лекции Петра, но и к книге Анатолия Левенчука «Утопия визуального мышления» (на ridero, на litres, пост Анатолия о книге со ссылками, мой конспект). Там есть модель спектра формальности мышления, которая, думаю, делает шаг к объяснению.

Все это важно для IT-шников, потому что разработка софта, написание кода преимущественно представляет собой как раз «мышление до», мыслительных создание конструкций идеальных объектов, выражаемых далее на языке программирования. Впрочем, вполне можно заниматься IT или другой мыслительной деятельностью не имея особых представлений об ее устройстве. И даже успешно заниматься. В свое время исследователи управления знаниями обнаружили наличие неявных знаний наряду со знаниями формализованными — этот термин Полани (Michael Polanyi) в «Personal Knowledge» (1958) и развил в «The Tacit Dimension» (1966). Неожиданным было то, что у хороших специалистов значительная часть знаний, в том числе ключевые приемы, может являться неявными, они не знают, что именно позволяет им успешно делать свое дело. Об этом — классический пример с пекарем из книги Нонака и Такеучи «Компания — создатель знания» (2003). И IT-шники тоже могут писать программы не особо задумываясь об устройстве мышления, не рефлексируя методы своей работу.

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

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

В то время как для рассмотрения мышления в его историческом развитии необходимо работать не только с индивидуальными, но и коллективными формами мышления. Собственно, логика правильных рассуждений, восходящую к Аристотелю и схоластам посвящена именно коллективному мышлению, которое возникает при передаче концептов от одного человека другому, когда «идея овладевает массами», как называл этот процесс Ленин ☺ И современные теории мышления, такие как Desigh Thinking и System Thinking или упоминавшееся выше управление знаниями делают акцент на коллективное мышление, не говоря уже об отдельных популярных практиках, таких как мозговой штурм. Замечу, что все эти методы в значительной мере сосредоточены как раз на "мышлении до", на порождении новых мыслительных конструкций из идеальных объектов.

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

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

И вот дальше вот что интересно: разработка софта, особенно масштабных проектов — это тоже НИОКР, написание кода, если мы сопоставим его, например, с конструированием самолетов — это не производство опытного образца по проекту, а низкоуровневое проектирование. Кстати, именно этим объясняется то, что разработку софта не получается организовать методами регулярного менеджмента. За подробностями я отсылаю интересующихся к статье Джека Ривза (Jack W. Reeves) «What is software design» (1992, перевод ). Так вот, в этом случае получается, что организация мышления, необходимая для разработки масштабных софтверных проектов должна быть в чем-то аналогична организации мышления, необходимому для разработки научных программ, и совпадение терминов не случайно, а имеет неожиданные основания. Я всегда утверждал, что это — принципиально разное. Получается, что не совсем разное, должно быть что-то общее. Необходимо подчеркнуть, что в опубликованной статье Петра этот тезис не заявлялся совсем, хотя в других его выступлениях про возможную я слышал. В любом случае, об этом сопоставлении я еще буду думать.

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

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

В комментариях к одной из моих статей про Scrum на vc.ru, как это часто бывает, появились люди, утверждающие что никаких данных и никакой статистики, подтверждающей эффективность Agile, нет и все это - чистая пропаганда. Я знаю, что статистика есть, я ее слышал в ряде докладов, в том числе - в докладе Сазерленда на SECR-2011, ссылку на который привел. Но такие люди обычно не хотят истины, они хотят лишь увериться в правильности своего мнения. Поэтому подобные ссылки быстро объявляют предвзятым мнением, а не разбираются. И, поскольку у всякой такой дискуссии есть читатели, то я сделал еще пару шагов, результаты которых тут публикую. Я довольно быстро вышел на статью Michael Sweeney Agile vs Waterfall: Which Method is More Successful? со статистикой и ссылками и на несколько отчетов. 2013 IT Project Success Rates Survey Results, 2018 IT Project Success Rates Survey Results (на сайте есть и другие) и Standish Group 2015 Chaos Report

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

Во всех этих отчетах Agile-методы рассматриваются без разделения. Но по ним есть отдельная статистика, которую ежегодно публикует Version One https://www.stateofagile.com/ (18.07.2024: сайт не работает, но через webarchive информация доступна и ссылки на отчеты тоже работают, кроме того, отчеты активно репостили. смотрите через поиск). Пару лет назад ScrumTrek начал публиковать такую же по России, вот для примера отчет 2018 и отчет 2019. И на них можно опираться.

Отмечу еще, что многие из компаний, которые начинают применять Agile, оценивают его эффективность по внутренним показателям. И когда эти кейсы рассказывают - то говорят о цифрах эффективности или, чаще, о возможностях которые дал Agile. Примером служит доклад «Банк России: знать путь и пройти его — не одно и то же» https://youtu.be/UeXBwq7rXX8 на AgileDays-2018, в котором приводили такой пример: используя Scrum за полгода удалось сделать первый такт изменений, к которым до этого не могли подступиться полтора года, и которые по самым оптимистичным оценкам требовали не менее полутора лет. А тут решили попробовать итерациями, и получили значимый результат. Как легко догадаться формально получается, что Agile эффективнее в бесконечное число раз. Впрочем, скептики объявляют эти данные частными случаями, им нужны исследования.

Впрочем, зарубежный опыт говорит, что упертых защитников старого можно убедить только директивно. Во всяком случае, история зарубежного опыта, которую я услышал AgileKitchen в аппарате правительства в 2015 (мой конспект http://mtsepkov.org/GosAgile-2015-11) говорит, что именно так были вынуждены поступить правительства Великобритании и Штатов, когда после крупных провалов проектов, управляемых традиционно, делали применение Agile обязательным для госпроектов, в 2011 и 2014 годах соответственно. В Англии подробности можно посмотреть на https://www.gov.uk/government/organisations/government-digital-service, а в Штатах - в истории https://www.usds.gov/mission

По-прежнему продолжаю описывать схему #scrum новая статья Завершение спринта в Scrum – демо и ретро. О проблемах получения релевантной обратной связи и о том, как быть, если не успели. Это - тринадцатая статья серии «Менеджмент цифрового мира», оглавление можно увидеть на моем сайте http://mtsepkov.org/NewMngSeries

Пост на FB

Продолжаю описывать схему Scrum. Двенадцатая статья серии «Менеджмент цифрового мира» - Схема Scrum – ежедневная работа внутри спринта. Казалось бы, о чем тут писать? Бери задачи, и делай - и будет результат. Оказывается, там есть много нюансов, определивших успех метода.

Полное оглавление серии статей - у меня на сайте http://mtsepkov.org/NewMngSeries

Пост на FB Репост в AgileRussia - там обсуждение

Первая статья описания схемы скрам, наличие которой делает этот метод фреймворком Итерации Scrum – целостная схема, а не прикольная картинка. Я наивно надеялся уложить это в одну статью. Явно не получается, объем слишком велик.

Эта статья - одиннадцатая в серии Менеджмент цифрового мира, и в предыдущих я уже говорил про Scrum, описывая разделение ответственности и другие изменения, которые он принес в организацию работы, а также работу с досками. Полное оглавление - у меня на сайте http://mtsepkov.org/NewMngSeries Продолжение следует...

Пост на FB

Десятая статья из серии «Менеджмент цифрового мира» Доска - визуализация текущего состояния работы. Казалось бы, что об этом писать отдельную статью? Но за время развития Agile было наработано много эффективных приемов работы. А опыт внедрения показывает, что сама по себе визуализация работ на доске позволяет существенно повысить эффективность работы даже без перестройки других механизмов управления, просто за счет прозрачности ситуации для всего коллектива. Полное оглавление серии статей - у меня на сайте http://mtsepkov.org/NewMngSeries Там же можно поддержать проект.

Пост на FB

Девятая статья серии «Менеджмент цифрового мира» начинает рассказ про Scrum: Scrum - пять изменения организации команды, принесшие успех Agile. Если материал кажется ценным, можно поддержать серию. Много не надо - достаточно угостить виртуальной чашечкой кофе :)

Пост на FB, репост в AgileRussia - много обсуждений, много других репостов.

Facebook напомнил про конференции шестилетней давности SPMconf и HappyDev. Полезная у него функция, перечитал отчеты, вспомнил, опубликовал репост в ленте. И утащу посты в блог, чтобы не потерялись.

Пост на FB Шесть лет назад, на #SPMconf был хороший круглый стол об образовании для IT, который прошел под заключительным слайдом презентации Максим Дорофеев (Maxim Dorofeev) - ее не выключили. Дмитрий Безуглый (Dmitry Bezuglyy), Владислав Орликов (Vladislav Orlikov), помните? Я опубликовал конспект в отчете http://mtsepkov.org/SPMconf-2013 сейчас перечитал - интересно.

А еще на этой конференции я впервые рассказал публично мое осмысление Agile как альтернативы регулярному менеджменту в IT http://mtsepkov.org/AgileVsBigManagement. С тех пор тема очень сильно развивалась, выросла в осмысление развития менеджмента цифрового мира, о чем я прямо сейчас пишу и публикую серию статей, здесь оглавление http://mtsepkov.org/NewMngSeries Их уже восемь, и это - начало пути.

Пост на FB Шесть лет назад, #happydev в Омске, рассказ о ролях в IT, который сфотографировал Алексей Пименов (Alexey Pimenov). Тема с тех пор сильно развивалась, сейчас это уже развивающаяся серия докладов http://mtsepkov.org/Roles Правда, роли Хорек-Паникер так и не пояилось :) Там же был второй доклад про DDD, тоже часть развивающейся серии http://mtsepkov.org/Category:DDD

А вообще было интереснейшее мероприятие, спасибо Анна Тарасенко (Anna Tarasenko) Сейчас перечитал отчет http://mtsepkov.org/HappyDev-2013 - много хороших докладов и общения, а обсуждение доклада Dmitry Lobasev про Agile вызвало на Facebook дискуссию в коментах которую интересно перечитать столько лет спустя и сравнить понимание с сегодняшним. Собственно, в этом польза отчетов и воспоминаний: сравниваешь то прошлое с настоящим, оцениваешь развитие общества и свое собственное.

Восьмая статья серии "Менеджмент цифрового мира" Agile – ответ IT на вызовы цифрового мира рассказывает общую конструкцию Agile: ценности, принципы организации работы, обеспечивающие воплощение ценностей и конкретные методы, которые их реализуют. Подробное рассмотрение методов будет в следующих статьях серии, начиная со Scrum, потому что именно его успех определили распространение Agile.

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

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

Статья Три вызова цифрового мира завершает первый блок моей серии статей «Менеджмент цифрового мира». Серия будет продолжаться, второй блок будет про Agile, затем Спиральная динамика, в конце статьи я анонсирую подробно. Получается объемная работа, и если статьи для вас несут ценность, вы можете поддержать меня. Или сделать это позднее. Много не надо, достаточно угостить виртуальной чашечкой кофе.

В начале ноября был на Highload-2019 и свое основное впечатление с конференции я сформулировал по горячим следам в этом посте на FB: Web-Scale IT for Enterprise сделал очередной такт развития. Напомним, шесть лет назад, в 2013, Gartner анонсировал на 2014 год новый тренд Web-Scale IT for Enterprise - применение технологий, наработанном в публичном Web для разработки "серьезных" enterprise-приложений. В 2015-2016 годах этот тренд пробовали учесть на конференциях #SECR и #RITfest, но тогда это было про будущее. А эта конференция показывает, что этот тренд за прошедшие годы развернулся в очень широко. Для банков, которые активно переходили в интернет-пространство, этот тренд развернулся естественным образом уже давно. Тинькофф, Сбербанк, Альфа, Райффайзен активно представлены на IT-конференциях. А сейчас эти технологии активно осваивает Retail, в том числе тот, который производит товары, а не просто их продает. На конференции стояли стенды Lamoda, Леруа, Спортмастера и других. Был целый трек, на котором они рассказывали о своих проектах, о переходе с традиционных технологий на современные и технологический стек там вполне современный - ClickHouse, Elastic, Kafka, Go и многое другое. И используются эти технологии на хорошем уровне, характерном для высоконагруженных приложений публичного Web. На прошлом Highload это было гораздо менее выражено: стенды стояли, но меньше, а доклады если и были, то больше про технические аспекты, а не про решение бизнес-задач. Так что очередной такт развития цифровизации бизнеса пройден, ждем следующих.

А еще на Highload второй год вручается премия за вклад в развитие IT. Номинанты 2019 - интереснейшие люди, я всем рекомендую зайти на страницу и почитать. Было две системы голосования: экспертный совет и публичное, и один из номинантов получил сразу обе премии. Всех лауреатов я не записал, а на сайте список еще не опубликован. Но помню, что среди них точно был Алексей Натёкин, организатор бесплатных DataFest, собиращих тысячи участников, Кирилл Мокевнин, Сергей Федоров из jug.ru и другие. Кстати, вручение проходило интересно: показывали ролик с кандидатом, где лицо было скрыто, но шли комментарии, а дальше аудитории предлагалось угадать :) Надеюсь, ролики тоже выложат, вместе со списком лауреатов. А лауреатов прошлого года можно увидеть на странице премии.

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

Итак, доклады, которые я услышал.

Пост на FB Первый доклад Олег Филиппов Распределенная система, которая работает везде и на всём. Про технологии, на которых работает современный fasion retail, кейс SELA. С требованиями устойчивой работы на любом оборудовании, которое стоит у франчайзеров в разных небольших точках (поэтому без JVM на клиенте), offline или через очень слабый интернет, работа с внешним оборудованием (поэтому не Web), 400+ узлов базы данных. Мне это очень знакомо, потому что в Спортмастере мы такую систему строили с начала нулевых, с аналогичными требованиями, и задачи-то - не изменились. Сейчас построение продолжается, но, как обычно, в технологиях влияет история, поэтому узнать о решениях на новых технологиях было интересно.

Что я для себя вынес? 1C на фронте - основной вариант, потому что работает на всем железе, отслеживает изменения законодательства, и ее все кассиры знают, не надо обучать.

Основная БД - PostreSQL и MS SQL с репликациями из центра в периферию с фильтрацией и обратным сбором данных. И на слабом оборудовании локальная БД всегда будет ломаться и теряться, поэтому не заморачиваются с бэкапами, а вместо этого всегда можно переключиться на работу с центральной БДб запустив параллельно восстановление локальной и занимает 20 минут. Для, для отключения и восстановления нужен интернет, и если одновременно упала локальная БД и интернета нет, то печалька, но считаем, что что-то одно есть. А при этом для данных бонусной системы - CouchDB, она позволяет распределенную сетевую репликацию с резервными узлами, легко конфингурируется, есть легкий вариант PouchDB для развертывания на клиентах. Система сбора бизнес-логов ClickHouse, а не Elastic+ELK, потому что Elastic дорог, стоимость логов получается как продакшн. При этом там для бизнес-задач структурированных данных хватает, текстовый поиск не нужен. А вот технологические логи, сбор потока сознания в журналах 1С - на Elastic, потому что там проблемы без поиска по regexp не найдешь. И все выведено на Grafana

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

Пост на FB Денис Карасик из Badoo. Кафка. Описание одной борьбы. Заглянул внутрь конфигурирования Кафки для обеспечения скорости и надежности. Люблю такие доклады, потому что через них понимаешь внутреннюю логику работы системы. И это реально полезно. Спасибо.

Пост на FB Алексей Скоробогатый из Lamoda. Starship Enterprise Evolution: архитектура e-commerce-платформы. Очень интересный и содержательный доклад про эволюцию от традиционной архитектуры обработки данных, включающей huge-монолиты, мелкие сервисы с SOA и cron-driven reporting, и передачу всего в DWH, где обработка данных, в общем случае, идет в суточном ритме к event-driven архитектуре обработки потоков событий, позволяющих получать результат почти-real-time, за несколько секунд. Для этого исторически сложившиеся монолиты, например, содержащие данные о заказах, выдают события по созданию заказа и изменению состояния, которые попадают в Кафку, обрабатываются сервисами на Go и возвращают свои события, на которые подписываются потребители, и хранение состояния сервиса в собственной Postgres-базе. При этом монолит разгружается от многочисленных обращений потребителей данных по заказам, а сервисы сами хранят необходимые данные. Существующие сервисы частично переиспользованы, но вместо request-responce сделан прием событий и выдача событий-результатов. И уже над ними, где надо, надстроено API, которое может дождаться ответа для синхронного вызова.

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

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

Пост на FB Игорь Цупко. Потерянные знания: что делать с непонятным легаси. Митап KnowledgeConf неожиданно собрал громадное число слушателей, что переместились из маленькой комнаты в Сингапур и он почти заполнен. Но Сингапур был свободен только один слот, на второй - переместились в фойе и фото - оттуда.

Оригинал на FB

Рассказ о болях начался с философского вопроса: если ваш руководитель направил нас на легаси-проект, то надо бежать или принять испытание судьбы?

Дальше - заметки в вольном стиле.

Как появляется легаси? А очень просто: быстро запилили фичу и забыли. И через год-два у вас жуткое количество фич, и никто не знает, что они делают.

Запросы посмотреть чужой позитивный опыт:

• У нас монолит, мы пытаемся покрыть тестами, а уже потом реинжинирить. Кто-нибудь прошел этот путь?
• Что перспективнее: Постепенно выносить монолит в небольшие модули, или собрать технический долг, и перестроить монолит внутри?

Жизненный цикл легаси Ctrl-Alt-Del: взять под контроль, заменить, удалить...

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

А еще микросервисы могут превратиться в распределенный монолит,, может надо научиться монолиты готовить...

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

Если трамвайчик разгоняется, и мы не можем объяснить, что надо приостановиться и сделать рефакторинг, и руководство не понимает - стоит ли пробовать уговорить, или лучше сразу идти на headhunter?

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

Паттерн, когда новичка бросают на легаси-участок, а потом дают другие проекты. Жестко, но есть разумное зерно: если бизнес построен над легаси, то надо проверить совместимость человека.

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

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

Продолжаю серию статей про менеджмент цифрового мира. Четвертая статья https://vc.ru/future/94791-kultura-i-processy-dve-storony-kompanii - про взаимосвязь процессов и культуры и про отсутствие в цифровом мире единственного образа правильной культуры компании - это влияние mindset поколения соцсетей.

Продолжаю серию статей про менеджмент цифрового мира. Третья статья - про изменение mindset, которое несет поколение соцсетей

Между первой и второй - перерывчик небольшой :) Вторая статья из серии о менеджменте цифрового мира https://vc.ru/future/94043-cifrovoy-mir-ot-fizicheskogo-truda-k-umstvennomu о переходе от организации физического труда к организации умственному, которую регулярный менеджмент делать умеет плохо.

В разговорах на #TeamLeadConf кто-то посетовал, что я не конспектирую в репортажах собственные доклады, и я задумался об этом упущении. А недавно я осознал, что полная сборка слайдов по интересной для меня теме менеджмента цифрового мира, включающая agile, бирюзовые организации, модель спиральной динамики, историю управления проектами в IT включает более 200 слайдов и не помещается даже в 3-часовую лекцию. И поэтому я решил сделать серию статей, просто подробно рассказывающую эту сборку, по 1-2 слайду на статью и сегодня начинаю эту публикацию статьей Менеджмент цифрового мира (пост на FB). Публикация будет идти на vc.ru, ссылки дублироваться на facebook, в мой блог и на канал в телеграм. И я надеюсь выдержать темп 2-3 поста в неделю.

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

Оригинал на FB

Оригинал на FB

В пятницу-субботу, 08-09.11.2019 я был на конференции 40 лет ОДИ. Для тех, кто не знает, ОДИ - это Организационно-деятельностные игры, разработанные Георгием Петровичем Щедровицким как один из способов способ прикладного применения методов Системо-Мысле-Деятельностной методологии (СМД-методологии) для ее практического применения - решения масштабных проблем и выработки программ деятельности. Первая ОДИ прошла сорок лет назад, в 1979, за 1979-1993 годы он провел 74 игры с широким вовлечением участников, и это послужило распространению и развитию ОДИ как в полной форме, так и в разнообразных редуцированных и производных формах, как пример тут можно привести Rapid Forsight, о котором на конференции Дмитрий Песков, один из его создателей, говорил как о спиноффе (или бастарде) методологической традиции.

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

Мое знакомство с СМД-методологией и ОДИ началось в 2012 году, когда Борис Маркович Островский, один из учеников Георгия Петровича, начал работать с нашей компанией CUSTIS для ее развития, как раз в форме проведения ОДИ-сессий, одной из редуцированных форм ОДИ. Так что это был опыт не изучения, а вовлеченного в деятельность объекта, который мог стать субъектом, а мог так и остаться объектом. Такое вовлечение и предложение, требующего личного самоопределения - одна из принципиальных особенностей ОДИ. У меня стать субъектом получилось, и получилось начать знакомиться с СМД-методологией. Сначала - в той форме, в которой Борис Маркович рассказывал об этом на консультациях и докладах в ходе игры, что подразумевало не систематичное изложение, а подачу ограниченного материала в необходимом количестве для решения возникающих в игре ситуаций. А затем - через более изучение различных материалов, и обсуждение их с игротехниками на наших сессиях и лекции Бориса Марковича. Несколько лет я участвовал в играх Бекасово, слушал и конспектировал в 2016 цикл лекций Петра Георгиевича о системах разделения труда и новой промышленной революции. И тогда же в 2016 году я рассказывал на конференции AnalystDays о схемах СМД-методологии как о вполне прикладном инструменте и их возможном применении для IT-аналитиков. Из части этого доклада, дополненной схемой самоопределения из лекций Петра получился доклад и тренинг по самоопределению, оказавшийся востребованным, и мне представляется важным не просто его проводить, а явно указывать на источники в надежде, что люди заинтересуются. И этот отчет логично продолжает эту линию.

Ну а теперь, после этой преамбулы - о самом мероприятии.

Disclaimer: все цитаты неточные, все смыслы - интерпретированные. 

К написанному выше это тоже относится.

Конференция 40 лет ОДИ не просто фиксировала знаменательную дату, она еще связывала уже уходящее поколение учеников Георгия Петровича и приходящее им на смену новое поколение последователей, которые по-своему интерпретируют полученное в наследство. И доклады были поделены на два дня так, что в первый выступало старшее поколение, 60+ (только Волков немного не дотянул), а во второй - более молодые. Но я их объединю по-другому, хотя начну, кончено, с открывающего доклада Петра Щедровицкого.

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