Latest posts
Системный сдвиг
21 Sept, 16:26
Знаю, что в Яндексе работает много аналитиков данных, или BI-аналитиков — тех, кто перемалывает массивы данных и извлекает из них всякие интересные инсайты.В принципе, роль смежная — я и сам неоднократно решал задачи построения хранилищ для аналитики и обеспечения бизнеса актуальными и интересными данными. Но я не считаю себя крутым экспертом именно в таком анализе. Тем интереснее послушать, как это устроено в больших масштабах. Ну а заодно посмотреть на то, как ребята осваивают ИИ.У Яндекса есть подкаст от аналитиков для аналитиков "Доверительный интервал" — это регулярные встречи, где они обсуждают свои задачи и актуальные боли. Последний выпуск там был про ИИ: у них тоже идёт освоение, adoption, есть сомневающиеся, есть и ментальные блоки "ой, я попробовал, ничего эти агенты не умеют".Интересно, что все с разных сторон заходят — кто-то начал с кода, кто-то с презентаций, кто-тоСистемный сдвиг
18 Sept, 16:26
Дальше культурно-историческая теория деятельности (в изложении Энгестрема) говорит о противоречиях — contradictions, или о напряжениях — tensions. Зачастую эти противоречия уже существуют, сложились исторически ещё до внедрения ИТ-системы, а система может их гасить или усугублять, или вводить новые напряжения.Эти же напряжения являются на самом деле движущей силой для эволюции системы деятельности, в том числе для создания ИТ-систем. Интересный вопрос — какое напряжение, какое противоречие стало поводом создать вашу систему?Энгестрем выделяет структурно 4 уровня противоречий:1. Противоречие в одном узле деятельности: например, правила противоречат друг-другу, или инструменты несовместимы/делают принципиально разное, в разделении труда одна задача назначена двум ролям, у деятельности несколько разных объектов и целей.2. Противоречие между узлами: инструменты не соответствуютСистемный сдвиг
17 Sept, 18:52edited
Что-то перерывы между постами стали совсем длинными. Надеюсь в ближайшее время вернуться в ритм, и поставлять вам неочевидные приемы и темы, про которые вы вряд ли у кого-то ещё прочтете.Но сначала продолжение предыдущего поста.Итак, я сел выписывать список заинтересованных сторон. Требования ведь берутся только от заинтересованных сторон, больше неоткуда.Получился вот такой список: 💻 те, кто непосредственно работают с системой (пользователи); 🪪те, кто приводят систему в работоспособное состояние, устанавливая настройки и наполняя контентом (прикладные администраторы); 🎁те, кто получает пользу от работы системы (заказчики, клиенты); 💸те, кто выделяет ресурсы и несет риски в связи с созданием и работой системы (топ-менеджмент, инвесторы, юристы,
Системный сдвиг
29 Aug, 08:43
Сел тут выписывать категории стейкхолдеров. В проекте положено делать анализ стейкхолдеров, да? Обычно его либо не делают, либо с умным видом рассказывают про "луковичную диаграмму" (и иногда даже рисуют её).Луковичная диаграмма делит стейкхолдеров на круги, или слои. Конкретные названия слоев варьируются.Йэн Александер (собственно, автор методики и книг «Writing Better Requirements» и «Discovering Requirements: How to Specify Products and Services» — кстати, не вижу, чтобы они переводились на русский, а это вам не Вигерс, это конкретное руководство про выявлению и написанию требований) предлагает следующие:0 слой: сам продукт 1 слой: "наша" система: продукт + операторы + инструкции/правила по работе с системой 2 слой: объемлющая (содержащая) система: наша система + бенефициары нашей системы (кто получает пользу от её функционирования, но сами могут не пользоваться ей) 3 слой:Системный сдвиг
18 Aug, 16:16
Глядя на разрастание объема требований в очередном проекте, вспомнил шутку про поправочный коэффициент π×e, на который нужно умножать число выявленных требований, чтобы получить число реальных.Эта формула имеет геометрический смысл: R×π×e,где R - число требований, число π в этой показывает круг, который нужно пройти для каждого согласования, а число e - скорость, с которой заказчики придумывают новые требования.При многоступенчатом процессе согласования уже нужно брать интеграл по поверхности требований, но итоговая формула получается тоже простой: 2π×R×h×e, где h - число уровней согласования.В среднем получается ~8.54, что очень похоже на большинство проектов.Математики до сих пор не уверены, является ли это число иррациональным, но мы-то знаем...Обратите внимание, что π в данном случае показывает разворот требований на 180°, то есть строго в противоположную сторону. ЕслиСистемный сдвиг
15 Aug, 14:04
Я часто вижу среди рекомендаций по системному анализу книгу Донеллы Медоуз "Азбука системного мышления" ('Thinking in Systems. A Primer'). Тут у меня дошли руки прочитать её.И вот что я вам скажу — те, кто её рекомендует, либо сами не читали, либо ничего не поняли. Потому что главный вывод, который можно сделать после прочтения — то, что мы называем системами в ИТ, на самом деле системами не является. Или является ими не в том смысле, в каком их понимают ученые, занимающиеся системным анализом.Ну да, это известная проблема с одинаковыми названиями двух совершенно разных дисциплин: системного анализа и системного анализа. Первый — кусок из кибернетики/теории управления, с математическим моделированием, теорией оптимизации и принятия решений, исследованием операций и всяким таким. Второй — набор практик для выявления требований и проектирования ИТ-систем. Вот "Азбука системного
Системный сдвиг
12 Aug, 10:38
Вы используете прототипы интерфейсов? Наверняка используете. Для согласования, например. И чтобы вообще было, что обсуждать. Читать тексты человеку очень сложно, а уж представить себе по тексту, как это будет выглядеть, вообще мало кто может. А если и представит — совершенно не факт, что два человека представят одинаково.Поэтому прототипы часто используются в качестве стимульного материала: чтобы хотя бы начать или предметно продолжить разговор. Нужна визуализация, а ещё лучше — исследование действием. Дайте предмет, поставьте задачу и пусть пользователи попробуют решить эту задачу при помощи этого предмета. А мы увидим, с какими проблемами они сталкиваются. Поэтому, кстати, "просто показать прототип" не работает — нет задачи и нет попытки её решить. В лучшем случае вы получите набор случайных замечаний, часть из которых будет нерелевантна, при этом многие важные вещи будут пропущены.Системный сдвиг
7 Aug, 15:27edited
За летними делами пропустил историческую новость: в протокол HTTP добавили новый метод! Не каждый день бывает.Добавление свежее, июньское, RFC 10008. Статус у него — Proposed Standard, но с таким статусом множество технологий живет, это значит — в целом норм, можете уже реализовывать в своих системах. В Nginx новый метод уже поддерживается. Называется этот метод QUERY. используется он примерно так: QUERY /products/search HTTP/1.1 Host: api.example.com Content-Type: application/x-www-form-urlencoded Accept: application/json q=distributed+systems&category=books&min_year=2025&sort=relevance То есть, это фактически официальный GET с телом.Проблема была в чем: если вы хотите найти что-то по сложному условию и множеству параметров, можно использовать GET, но параметры поиска можно передать только в строке запроса. Тела запросам GET не положено — его можно передать, но сервер или любойСистемный сдвиг
29 Jul, 17:11
В одном из обсуждений поста про ритуалы и дейлики возникла тема про доверие. Человек отреагировал очень резко: синхронизация под запись в чате?! Да никогда! Это же всё сохранится и может быть заскринено и использовано!Я, честно говоря, даже немного опешил. За 28 лет я с такой культурой встречался, пожалуй, только раз — в одном государственном проекте, где всегда нужно было думать, что и кому ты говоришь, взвешивать слова и понимать, кому твои слова будут переданы и в каком виде, и как будут использованы (скорее всего, с целью навредить). Долго я там работать не смог, естественно. Вообще не представляю, как работать в среде с низким уровнем доверия.Тренеры по лидерству тут любят вспоминать Патрика Ленсиони и его книгу "5 пороков команды" (дисфункций), где он описывает пирамиду "пороков": отсутствие доверия ➜ боязнь конфликтов ➜ необязательность ➜ избегание ответственности ➜Системный сдвиг
27 Jul, 15:08
Знаете, что меня больше всего бесит в процессах "типа agile"? Неприкрытый формализм. Особенно ярко это проявляется в регулярных событиях, которые предписывает, например, Scrum (в Kanban они тоже есть). Подавляющее большинство людей вообще не понимают их смысла.Почти в каждой команде, практикующей что-то подобное, я вижу, как ежедневные стендапы превращаются в бессмысленное рутинизированное мероприятие, от которого скорее хочется избавиться или в отчет перед руководителем (изображающим скрам-мастера). А бесконечные тягучие планирования спринта?..В общем, это явный признак, что тут что-то не то (в любом деле, если вам хочется поскорее от него избавиться и вы мучаетесь, что-то не то).События в Scrum не зря называются "церемониями" или "ритуалами" (хотя в Scrum Guide они нзываются просто "событиями", но Майк Кон в выступлениях их называл "церемониями"). Сам термин "церемония"Системный сдвиг
20 Jul, 18:23
Каждый раз, когда приходится стартовать проект с нуля, не перестаю удивляться количеству вещей, про которые нужно подумать и принять решение. В первый раз, помню, поразился, когда понял, что разные виды обеспечения из ГОСТ 34.602 — это не "вода", как многие считают, а реально нужные и полезные разделы. Например, правовое обеспечение системы, или лингвистическое (за казенными формулировками не всегда понятно, что "лингвистическое обеспечение" — это, в том числе, тот самый ubiquitous language из DDD, а вовсе не "подписи в интерфейсе системы должны быть выполнены на русском языке").Второй раз я был шокирован, когда понял, что у меня в проекте разворачиваются все 43 процесса из ISO 12207, и все их мне нужно контролировать! Все вот эти процессы приобретения, поставки, менеджмента решений, и даже менеджмента повторного применения активов! Ну, я-то, как нормальный программист, читал толькоСистемный сдвиг
16 Jul, 17:37
Интересно, что конфликты с точки зрения цветов выглядят по-разному:Черный-белый с точки зрения белых: борьба добра со злом, а с т.зр. черных: борьба личности с зависимостью от других.Черный-зеленый: прагматизм против расточительства или сохранение против эксплуатации (угадайте, где чья перспектива)Зеленый-синий: равновесие против дестабилизации или совершенствование против самодовольства.Синий-красный: ясность мысли против импульсивности или яркая жизнь против холодного расчета.Красный-белый: свобода против ограничений или хаос против порядка.Здесь ни один цвет не прав абсолютно. Ни один цвет нельзя вычеркнуть. Мир без белого погрязнет в анархии, без синего — не будет развиваться, без черного — провалится в коллективную дистопию типа замятинского "Мы", без красного не будет огня для действий, а без зеленого — оторвется от корней.Поэтому для баланса, если мы говорим про
Системный сдвиг
16 Jul, 17:37
Тема MtG не отпускает. Особенно в связи с разговорами про этику и т.п. Вот смотрите: в Magic the Gathering пять цветов: белый, синий, черный, красный, зеленый. Каждый цвет исповедует свои ценности и связан со своей стихией. Ричард Гарфилд, создатель MtG, вообще-то профессор математики, а не психологии. Но колесо цветов, или color pie он считает одной из главных фишек игры.Впрочем, он решал практическую задачу — сделать так, чтобы нельзя было собрать в одну колоду самые сильные карты в игре. В основе MtG всегда про баланс, и цвета тоже введены для балансировки сил: самые мощные карты невозможно собрать в одной колоде, потому что они разных цветов и для их вызова нужна разная мана (а собрать все источники маны не получится). А ещё у цветов есть базовые конфликты, вокруг которых тоже развивается игра. И всё это дает повод примерить базовые ценности цветов на себя и на коллег, если мыСистемный сдвиг
14 Jul, 16:57
forwarded from @the_good_question
Я написал инструкцию для себя: как получать от ИИ пользу, не теряя себя и смысл деятельности. Вам тоже может пригодиться.(она же на гите: https://github.com/kulakov/statement)Краткий список тезисов: 1. Все выводы делай сам. 2. Посылай людям только то, что написал сам. 3. Явно помечай места в черновике от ИИ, где сомневаешься. 4. Не выдавай работу ИИ за свою. 5. Не ссылайся на ИИ как на авторитет. 6. Складывай контекст в git и делай его пригодным к использованию. 7. В каждый момент держи связь того, что делаешь, с целью. 8. Исследование начинается с выбора источников. 9. Нет критерия качества — нет пользы от ИИ.Дальше — подробнее каждый из тезисов.1. Все выводы делай сам — будь готов повторить путь до вывода Самое главное правило: любой вывод делаешь самостоятельно, своей головой. Никакой вывод не должна сделать за человека машина. Проверка: будь готов вслух рассказать, какGitHubGitHub - kulakov/statement: Манифесты и заявления — личные тексты, на которые можно ссылатьсяМанифесты и заявления — личные тексты, на которые можно ссылаться - kulakov/statementСистемный сдвиг
14 Jul, 16:57
Леша Кулаков делится инструкцией по, как бы это сказать... этичному?.. безопасному?.. применению ИИ, если речь идет о документах. (Не уверен, что подойдет, если речь идет о коде, код генерируется со страшной скоростью и большими объемы, но его проще проверять более формальными методами — тестами, линтерами, правилами проверки архитектуры и т.п.)А вот документы и концепции, сгенерированные ИИ, уже достали. Непонятно, было тут участие человека, или он просто вкинул ответ ИИ, не читая.Особенно интересная позиция комментатора: пометка "я тут не согласен с ИИ". Мы всё ещё нащупываем режим работы с ИИ и смену ролей, и это, мне кажется, один из вариантов — оппонент/критик ИИ. Ладно, писать я это не писал, но я хотя бы прочитал и отнесся. А то непонятно, читал ли кто-то это вообще.Ещё я бы добавил пункт про регулярное вытаскивание ключевых решений и позиций. Вот это мы точно решили, иСистемный сдвиг
7 Jul, 16:41
Раз уж мы заговорили об играх: вот игра, одна из самых сложных из всех, в которые реально играют люди. Это MtG, Magic the Gathering. Выглядит как карточная игра, где каждый игрок использует свою колоду, вызывает себе на игровое поле существ, разыгрывает заклинания и накладывает чары. Цель — победить противника тем или иным способом, например — отняв жизни, которых изначально по 20.Внутри возникает комбинаторный взрыв: с 1993 года выпущено более 30 тысяч уникальных карт, колода состоит из 60 карт, каждая карта может повторяться в колоде только 4 раза — то есть, возникает огромное чиcло вариантов колод (для зануд — в играх по правилам Standard легальны примерно 4400 карт, в Legacy — 31465). 189 свойств карт, для которых есть специальное название, а отдельные карты могут иметь свои уникальные механики, которые как-то модифицируют игру. Поэтому практически про каждое правило нужноСистемный сдвиг
26 Jun, 17:23
Невозможно не реагировать на мировые новости и повестку. Вот, например, футбол. Я вообще не фанат, но чемпионат мира можно и посмотреть!И, конечно, извлечь для себя что-то полезное. Во-первых, можно смотреть на тактику разных команд. Кто как строит игру, у кого есть звезды, у кого вся команда более-менее ровная; как распределяются роли; насколько команда способна адаптироваться; кто как работает с риском; кто использует постоянно одни и те же схемы, а кто импровизирует по ситуации — всё наглядно видно. Можно интересные выводы сделать для себя. Исследования работы в группе же в основном из спорта пришли. И даже роль такую придумали: Agile Coach, то есть тренер. По идее, он должен всеми этими интересными вещами заниматься, а занимается обычно внедрением ритуалов. Эти задачи традиционно падают на менеджера или тимлида, получается "играющий тренер" — практика, от которой в спорте давно
Системный сдвиг
24 Jun, 13:45
Удивительно, но я оказывается не писал здесь про 6D's фреймворк: 6 'Ds' цифровизации. То есть, что нам цифровизация вообще дает? Это аналитический фреймворк Питера Диамандиса, показывающий, что происходит с вещами и процессами при цифровизации. Если мы говорим не просто об автоматизации какой-то деятельности, а о её цифровизации, по фреймворку можно проследить — что будет происходить дальше, если мы в какой-то процесс пустили цифру.Начинается всё с цифровизации, перевода данных в цифровую форму, digitized. Это дает базу для всех дальнейших эффектов: данные в цифровой форме можно универсальным образом и без искажений хранить / обрабатывать / передавать. Совмещать при этом данные из разных источников и разной природы (то, что когда-то называлось "мультимедиа"), добавлять интерактивность и изменять принципы и возможности обработки без изменения аппаратного слоя.Одновременно с этим
Системный сдвиг
22 Jun, 14:48edited
Кусочек из продуктового управления. Для описания сути продуктов используются разные формулы. Часто можно услышать формулу: "Мы верим, что..."1. Мы верим, что [наше убеждение о мире, людях или индустрии]. 2. Поэтому мы создаем [наш продукт, услуга или решение]. 3. Чтобы помочь [указание на целевую аудиторию] [конкретная польза или изменение в жизни клиента].Пример:«Мы верим, что знания можно использовать, только когда они подкреплены практикой. Поэтому во всех наших курсах участники делают много практической работы. Чтобы помочь аналитикам не просто получить информацию, а попробовать новый способ действия.»Но эта формула апеллирует к вере, что ставит нас немного в слабую позицию, а наших критиков заставляет играть роль Станиславского: "верю/не верю".Гораздо больше энергии несет другая формула, мне тут подсказали коллеги, занимающиеся социальными проектами. У них все жестче, неСистемный сдвиг
19 Jun, 13:41
В продолжение предыдущего поста — зашел посмотреть, что сейчас делает Алистер Коберн. Он, конечно, делает!Написал в 2025 году книгу про связь User Story, Use Cases и User Story Maps. То, что я много раз рассказывал на тренингах, но в книгу не оформил, да даже и на конференциях ни разу не рассказывал, думал, это слишком просто. А вот нет, нужно говорить и писать! Впрочем, приятно чувствовать себя на одной волне с великими.Что он пишет:User Story — значимое для пользователя изменение в системе (показатель прогресса), что-то, что пользователь может увидеть и пощупать.Use Case — перечисление способов, которыми пользователь может достичь своей цели (или не достичь).Story map — раскладка карточек, где слева направо идёт процесс, а сверху вниз — приоритеты.Основные принципы: 1. Глаголы подразумевают продолжительное действие 2. Раскладывайте глаголы на более короткие (по
Related Channels
Other channels in the same section of the catalogue.
