C интервалом в месяц прошли две конференции аналитиков: 21-22.05 AnalystDays в Петербурге, а 19-20.06 Летний аналитический фестиваль под Костромой на берегу Волги. Я был на обоих, писал заметки с докладов на facebook, а сейчас собираю их в общий отчет. И в начале хочу немного сравнить обе конференции, чтобы вы могли сделать выбор между ними или наоборот, решить, что вам нужно быть на обоих. Так случилось, что это были двенадцатые конференции: хотя ЛАФ начался на пару лет раньше AnalystDays, в 2010, но AnalystDays последние годы проходил дважды в год, так что нумерации сравнялись.

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

При этом, что важно, ЛАФ с самого начала была не коммерческий, его организовывало сообщество http://uml2.ru и цена была очень демократичной. И продолжает такой быть в сопоставлении с другими конференциями. При этом в этом году был ажиотажный спрос, так что сотню остававшихся на конец мая билетов раскупили практически за один день, и пришлось закрыть регистрацию. Конференция собрала 450+ участников, площадка была переполнена и часть участников поселились в соседних локациях или самой Костроме.

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

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

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

Так что выбирайте сами, какая конференция вам ближе, или участвуйте в обеих. Следующая AnalystDays будет осенью в Москве, потом опять весной, а ЛАФ - в июне. Конечно, спикеры и их доклады отчасти пересекаются, но всегда можно пойти на другой трек.

Посты на FB моя лента Анализ в ИТ-проектах

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

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

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

На ЛАФ я еще участвовал в паре круглых столов - у Димы Безуглого и в интересном круглом столе, который организовывали участники сообщества 1С чтобы "навести мосты" и понять - а как оно у других аналитиков устроено? Это интересно, но проблема круглых столов в том, что если ты активно работаешь по содержанию - то не получается делать заметки. Впрочем, про Димин круглый стол несколько мыслей записал - он шел продолжением доклада.

Дмитрий Безуглый. Мышление. Антипаттерны и лучшие практики применения различных подходов

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

Вводная часть - про конференции. Цирк Шапито переезжает между разными конференциями. Был на AgileDays - мушкетеры 20 лет спустя. Те же самые, но с детьми, рассказывают о том же.

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

Thinking - The way to do things. Мышление - это способ делать вещи.

TOC Голдратта. Цель, Цель-2 - объяснение всех важных вещей системного мышления без единого специального термина. Прекрасна тем, что в каждый момент времени на пути к цели ограничивает ровно один фактор - слабое звено. Но! Теория ограничений - только когда горит. А если не горит, то попытка определить слабое звено проваливается, каждый молчит и ждет - вдруг сосед заявится на это место. Методы дерево текущей реальности, будущей реальности, грозовая туча - круты.

Мышление - программная настройка над аппаратной частью мозга. Как запрограммировали, так и будет. Веришь в Канемана - появится система-1 и система-2. Веришь Левенчуку - появится его система мышления. Потому что ты себя программируешь.

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

BPM - куча методологий, которая пытается зафиксировать мир и поставить рамки. Глоссарий - только в одном контексте. Слова - гиперреальность, смысл которых зависит от того, к кому они попадают. Перенос стандарта системной инженерии из Европы в Россию - сразу смысл изменяется.

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

Ведро с дырочкой, где выливается вода, не давая наполниться - нарисуйте диаграмму с причинными связями.

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

Лёха Палаткин. Только вот психологически это ох какое не просто решение обычно.

Гараедаги. Как управлять хаосом и сложными процессами.

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

• Имитация.
• Инерция мышления (повторение еще и еще).
• Оптимизация отдельных частей системы.
• Переход к новым правилами игры (правила поменялись,а клоуны остались).
• Сдвиг парадигмы

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

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

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

Биологически мозг для 3 типов задач

• Транспортная история. Каждый день к одной яблони и принести яблоки. Собиратели. Вознаграждение при получении ресурса.
• Охотник. Ответ еще нужно найти. Олень всегда в новом месте. Удовольствие от процесса, поиска добычи. Встать на место оленя - пользователя, заказчика.
• Великий строитель - придумали календарь, ловить мамонтов. Трансформация. Решение дизайн-мышления на нескольких шахматных досках.

Конвергентное и дивергентное мышление как раз про поиск вариантов, выбор и исполнение - переключение режимов охотника и собирателя.

Канеман, Спиральная динамика - конкретные конструкции софта. Эксперименты 50-70-летней давности сейчас не воспроизводятся. Потому что софт, мышление поменялось с середины 20 века.

Все модели неправильные, но полезные в своем контексте.

Вопрос: что порекомендуете сейчас? Ответ: думать. Все уникально, мы живем в период трансформации и творцов.

В комментариях было интересные обсуждения.

Филипп Дельгядо. А там какая-то подложка научная под докладом есть или как? А то по тезисам выглядит, гм, спорно...

Максим Цепков. Смотри, есть книги - рекомендованные Димой: Дизайн-мышление Ленка, Линка и Лейфера, Пятая дисциплина Сенге, Теория U, Системное мышление Гараедаги, Цель и другие книги Голдратта. И, наоборот, отвергнутый Канеман. И есть конструкция, которую Дима из всего этого собрал, но структурно предъявил очень весьма смутно. Но при сборке и сопряжении концепты из книг оказываются обрезанными и частично использованными, и Дима говорил больше о том, как обрезаем, чем о взятой части и ее сопряжении с другими.

Егор Вершинин. Филипп Дельгядо, а мне наоборот зашло. Почти под каждым тезисом подпишусь на основе собственного опыта. Как печального, так и успешного. Про научную подложку - того же Голдрата успешно уже лет семь применяю в работе, практически сразу с момента первого чтения.

Максим Цепков. Егор Вершинин Критику я как раз не отрицаю. И ТОС Голдратта тоже правильная вещь, и она научно подтверждена, думаю, Филипп это знает. Хотя с оценкой, что TOC - это и есть системный подход, только без терминологической зауми, которую высказывает Дима, я не согласен. Но я не увидел целостной конструкции, в которой все эти штуки дополняют друг друга. Если она есть - расскажите.

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

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

Дальше пара тезисов:

1. Канемана опровергли нейробиологи - он много где смешал и перепутал атрибуты разных систем. Дениэл Сигел (Разум) на основе исследований вывел 9! контуров интеграции мозга.
2. Верить мало. Но обучаясь рефлексировать во фрейме определённой методологии либо подстраиваться под неё, либо отвергаешь на основе эмпирического опыта. Единственный "100% аргумент" ущербности онтологии которую предлагает Левенчук - доказанная закрытость мышления учеников этой школы, аналогично с СМД. Многие постулированные тезисы они просто не могут обсуждать. Т.е. они находятся на уровне объекта веры. Яркий пример понятие визуального мышления ...

Филипп Дельгядо. А вот про 1. есть что почитать? Про 2 - а Левенчук же именно онтологию не предлагает (кстати, как и СМДшники). Там есть проблемы/тезисы, которые сложно обсуждать в используемом языке, но если описать их как проблему языка - то и методологи и АИ вполне готовы про нее думать (ну, те методологи, что я встречал). То есть хочется узнать, кем доказана закрытость мышления? Мой опыт противоречит этому утверждению (а с методологами я много работал).

Руслан Антипов. Вот это подстава) только настроился на википедичный пост о докладе Дмитрия и на тебе :( цитаты кайф

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

Максим Пермяков. Бери и делай: PlantUML, VS Code и Git

Пост на FB Максим Пермяков, Sportmaster Lab. Бери и делай: PlantUML, VS Code и Git. Практический доклад о преимуществах текстового представления диаграмм по сравнению с рисованием в инструменте. Основная фишка - авторазмещение дает простоту модификации, ты добавляешь элементы - и элементы двигаются. А еще тексты можно версионировать - в вики или git. А еще, если говорить про большую компанию - единообразие диаграмм, тоже важно для большой компании.

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

Инструмент - легкий, первое внедрение после презентации - около 2 месяцев появилось 6 команд. Добровольно.

В комментариях.

Egor Doronin. PUML - легка в освоении? Когда обычно ты сам и есть единственный человек в компании из 1000 человек, кто умеет их читать и рисовать. Автогенерация хорошо работает только тогда, когда процесс/сервис из трёх элементов. Любая мало-мальски реальная диаграмма в случае автогенерации превращается в нечитаемый клубок спагетти. Я годами привожу аналогию с автотрассировкой печатных плат - программа берет на себя сохранение связей между вершинами графа (страхуя от того, что забудешь где-то стрелку поставить), но распутывать получившийся клубок приходится вручную тому, кто прекрасно это умеет и мог бы и из головы нарисовать такое. В итоге получается красота - одинаковые элементы вынесены в абстракцию, все читаемо и правильно. Минус языков для автогенерации - что нужно учить новую систему понятий каждый раз под каждое средство автогенерации.

Максим Цепков. Egor Doronin У Максима получилось сделать так, что в большой компании 30+ команд понимают и используют Plant UML. Этим его опыт как раз отличается от того, который вы обозначаете как обычный, когда единственный энтузиаст не может донести до других. И про автогенерацию - грабли супер-сложной диаграммы известны, нужна декомпозиция и переходы по ссылкам, и у них, опять-таки, получается реально решать эти задачи на больших системах, и не одним человеком, а во многих командах. Тут общих подходов Максим не сказал, и примеров вот этой части не было. Но это - можно связаться. То есть ценность доклада - в опыте решения описанных проблем.

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

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

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

Тая Толстунова и Алик Курдюков. Продуктовая работа с гипотезами

Пост на FB Тая Толстунова и Алик Курдюков. Продуктовая работа с гипотезами. Это рассказ о том, как разработку компании перестроили в проверку гипотез через эксперименты. Собрано все это из известных кубиков на основе Lean, и интерес представляет именно сборка.

И примеры. Рассказ был на примере трех совершенно разнородных гипотез: (1) повышение активных пользователей через письмо-предложение индивидуальной консультации после регистрации, (2) реинжиниринг фронтенда с монолита на микросервисы, (3) HR бренд компании.

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

Гипотезы ведут в trello и в докладе был конкретный workflow со стадиями. При чем после успеха эксперимента работа не кончается, идет масштабирование или поддержка. Проходят статусы по Kanban, слева-направо: что мешает подвинуть, какой прогресс. У каждой карточки - ответственный, и он, в том числе, может привлекать любых специалистов для работы по гипотезе. Ретроспективы изменяют процесс, и тут тоже были примеры, как менялась статусная модель. Ведет это все продуктовая команда, и в каждой команде есть минимум один представитель продуктовой команды, который рассказывает, что происходит на регулярных собраниях. Это все - краткое изложение, в рассказе и на слайдах было много конкретики. Презентации обычно публикуют быстро и ее стоит посмотреть.

Ирина Матвеева. Как учитывать влияние корпоративной культуры при реализации проектов

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

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

Начала она с того, что культура - айсберг с большой подводной частью. На карте Уилбера этот айсберг на боку, подводная часть - внутреннее, а надводная - внешнее. И внутренняя часть не всегда видна.

А дальше на карту кладутся вопросы и артифакты.

• Я-внутреннее -- Зачем, смыслы
• Я-внешнее -- Как, поведение
• Мы-внутреннее -- С кем, культура
• Мы-внешнее (они) -- Что, системы

С каждым квадрантом связаны вопросы, которые стоит задавать.

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

• Бежевый - Выживание
• Фиолетовый, племена - Идентификация. "Мы, путиловцы" - Кировский завод.
• Красный - про власть. Энергия. Мы - главные. Красный вождь "окно в Европу - прямо здесь"
• Порядок - синий. Государство и регламентация. B идет в бюрократизацию.
• Оранжевый - Успех, инновации, конкуренция
• Зеленый - Экология, ЗОЖ...
• Желтый - синергия
• Бирюзовый - устойчивый мир

Уровни видны из мемов компании, из стиля рассказа.

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

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

Заинтересованные стороны - тоже делятся на внутренних и внешних. И внутренние часто скрыты, неожиданно выходят из-за угла. Классическая схема 2*2 в квадратах Интерес - Влияние получила интересную метафору.

• Львы - высокое влияние и интерес - сотрудничать
• Слоны - высокое влияние при отсутствие интереса - вовлекать
• Белки - низкое влияние и большой интерес, они полезны и разносят позитивные слухи - информировать
• Тюлени - низкое влияние и интерес - наблюдать

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

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

• Я-внутреннее -- Зачем, смыслы -- Entrepreneur
• Я-внешнее -- Как, поведение -- Producer
• Мы-внутреннее -- С кем, культура -- Integrator
• Мы-внешнее (они) -- Что, системы -- Administrator

И с каждым идет свой язык общения.

Подводя итоги. Маркеры для экспресс-анализа

• Лингвистический анализ понятий
• Ценностные мемы - про что говорят
• На что жалуются - Маслоу
• Модель Адизеса

Если вы думаете, что вам не повезло с заказчиком, у вас просто недостаточно информации. Вероятно, стоп-фактором является культура, а вы этого не понимаете. И резюме.

• Корпоративная культура - продукт этапа развития компании и личностей отцов-основателей.
• Анализ ее - позволяет оценить готовность к изменениям
• Взаимодействие со стейкхолдерами - проектируйте.

Екатерина Лысенко. Как я стала Technical Product Manager

Пост на FB Екатерина Лысенко. Как я стала Technical Product Manager. Развитие отрасли не только порождает новые специализации, но и объединяет старые. В свое время позиции бизнес-аналитика и системного аналитика объединились, а теперь появляется позиция, объединяющая архитектора, отвечающего за конструкцию системы и product manager, отвечающего за бизнес-содержание и развитие продукта. И это человек, который умеет трассировать бизнес-составляющие продукта до технической реализации, и наоборот, понимать, как техническая реализация влияет на бизнес-фичи. Это - возможная траектория развития аналитика, и Екатерина рассказывала и о своем пути, и о необходимых компетенциях.

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

Нужно умение вести проектирование не только на уровне интерфейсов, но и умения проектировать API и объяснять их на бизнес-уровне. Тут была интересная история о том, как немецким партнерам объясняли особенности российской идентификации людей через СНИЛС и ИНН. Средство, чтобы удерживать технический и бизнес уровни одновременно - Domain Driven Design. Единый язык и замкнутые контексты.

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

Но в любом случае DDD - очень полезная техника, тут я полностью согласен. И тут была история, как после проработки понятие Пользователь превратилось в достаточно сложное понятие "Потенциальный клиент и Клиент". Книга по работе с продуктами - Ник Эль "Hooked". Еще одна книга Голден Кришна The best interface is No Interface. Потому что когда умный дом для включения света требует нажать 6 кнопок на мобильном телефоне, возникают сомнения в том, насколько он умный. А по DDD две книги Вернона и Эванс, начинать с DDD distilled Вернона. По продуктовому мышлению ей сильно помог курс Димы Безуглого Strategy mindset.

Фокус Technical Product Manager - техническое качество продуктов.

• Объединение фич и проектов в единой архитектуре
• Работа с бэклогом крупными мазками
• Шаринг рисков

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

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

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

В комментариях к посту.

Michael Stepanov. Очень интересно и познавательно. Хотя если следовать метафоре из книги "The Software Architect Elevator" Gregor Hohpe, архитектор и есть связующее звено между технарями и бизнесом.

Максим Цепков. Michael Stepanov Это если следовать. Проблема в том, что реально IT-архитекторы не мыслят на уровне бизнеса, особенно если речь идет об отдельных фичах и аспектах, важных и удобных для пользователей, а сосредотачиваются на технической составляющей софта.

Филипп Дельгядо. Максим Цепков, это не совсем так. Системные архитекторы - да, не всегда думают в продуктовой парадигме (хотя все, кого я знаю - думают и зачастую лучше продактов). Солюшен архитекторы как раз должны думать про бизнес, да и приходят чаще из бизнеса. Если же говорить про отдельные фичи, то там надо просто уменьшать число прослоек между разработчиком и бизнесом (желательно до нуля) и думать вместе, там даже архитектор лишний, не говоря уж про аналитиков. Т.е. мне кажется, что позиция Technical Product Manager - это про bad smell в процессах.

Андрей Зеров. Ошибаться аналитику – нормально, но ошибаться нужно «правильно»

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

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

• Лень. 4 часовую задачу на день начать после обеда, зная, что новых задач не будет - нормально. А вот 8-часовую начинать после обеда плохо.
• Безусловная вера на слово. Спрашиваем, но если ответ неуверенный - надо проверять.
• Copy-Paste без понимания, что именно копируешь. Часто есть похожая задача, которую предлагают взять за основу. Но вот дальше если ты работаешь с постановкой как с текстом, не в существе написанного, уместность в новой задачи и не проверяя целостность, то получаются проблемы.
• Вопросы без попытки найти ответ самостоятельно. В Google тебя не забанили. А еще есть документация, ее тоже полезно читать.
• Писать неоднозначные и непонятные требования,
• Оставлять подразумеваемый контекст, который "всем известен".

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

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

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

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

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

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

Дмитрий Шиянов. Предметная область. Метаданные. Код.

Пост на FB Дмитрий Шиянов. "Предметная область. Метаданные. Код." Рассказ, по сути, о последовательном применении DDD для ситуации многих уровней и многих ограниченных контекстов. Например, автомобили: для ГИБДД важны номера и номерные агрегаты, для нотариусов - права залога и обременения, а для ФНС - автомобиль - объект налогообложения. И потому в разных системах они представляются совершенно разными объектами с разным атрибутным составом. При этом объекты и атрибуты еще могут и назваться по-разному, для налоговой владелец - налогоплательщик, а для ГИБДД это лицо, юридическое или физическое. Это одно и то же, но в системах используют то, как написано в нормативных документах. У них получилось 4 уровня: словарь, концептуальная модель, логическая модель и физическая модель. Для концептуальной модели используют Anchor modeling - сущность, связь, атрибут и узел (перечисление), и он дает графическое представление. Между уровнями - связи. Логическая модель хранится в метаданных, которые лежат в общем хранилище. И там информация по всем контекстам, с указанием взаимосвязей между ними. А так же версионность метаданных. Для кода - naming conversion на основе концептуальной модели. В целом - рассказ о понятном решении сложной задачи ведения данных.

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

Дмитрий Смирягин. Лучше меньше, да лучше? Поговорим о размерах сервисов

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

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

• Пользователь - online-читатель
• Пользователь - плательщик
• Пользователь - получатель книги
• Пользователь - рецензент
• Пользователь - владелец личного кабинета

B если мы меняем, например, ФИО, то изменения распространяются совсем не мгновенно, а иногда только по расписанию, например, по ночам - и надо прорабатывать логику работы при неконсистентных данных.

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

Про размер сервиса была метафора стакана с рисками ограничений.

• Принадлежит одному bounded context
• Разрабатывается одной Agile-командой
• Слабосвязанные - межсервисные вызовы дороги
• Контракт взаимодействия между сервисами и совместимость при изменениях. Универсальность контракта.
• Консистентная нагруженность и надежность
• Консистентные требования к t2m
• Требования по безопасности - персональные данные, номера карт требуют отдельного контура

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

Алексей Ивакин. UX на примере кетчупа и топора

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

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

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

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

Таким образом, для UX важен не только продукт, но и пользователь, контекст использования и само взаимодействие.

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

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

Пост на FB Выступление Дмитрий Безуглый "Почему спустя 30 лет психбольница все еще в руках пациентов и что с этим делать?", как многие прошлые выступления, вызывает неоднозначные мысли. С одной стороны, проблемное поле выделено очень верно. Критика проектного подхода, который во многом представляет мертворожденную конструкцию, потому что попытался в область IT-разработки перенести методы из реального производства без учета специфики. Очень ядовитая критика пациентов психбольницы рынка цифровизации и информатизации в различных ролях, которые сами себе ставят диагноз и сами себя лечат, не имея представления о происходящем и устройстве мира. Собственно, в этом была метафора Купера, которую Дима применяет к другой области.

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

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

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

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

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

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

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

И немного избранных цитат.

• Команда переключается между системы, никто не понимает, что там написано. Некоторые любят поплакать "если бы вы правильно задокументировали..." - а вы видели разработчика, который бы прочитал всю документацию.
• ИТ-директора - бывшие сисадмины. У них сформирован проект вендоров и откатов, и неработающее выпилить нельзя.
• Руководители проектов - вчерашние студенты с полгода курса по PMBOK. Иногда играют на разработчиков в карте: PM больше, чем разработчиков и они каждую неделю делят сеньоров.
• Agile решает много проблем, но стейкхолдеры разработки - те же самые, тут конструкция психбольницы не поменялась.
• Смена парадигмы. От конного транспорта к автомобиля. Стоит ли водителю принимать советы от ямщика или кучера? А стейкхолдеры - из прошлой парадигмы. При этом чего-то такого, чтобы и их подопечные работали, и система по зеленой кнопке все делала.
• В продолжение доклада был круглый стол, я это фиксировал комментариями к тому же посту и пошло большое обсуждение. В том числе, Дима сформулировал тезисы, по которым мое изложение отличается от смысла, который он вкладывал в доклад. Читайте комментарии "как есть".

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

Максим Цепков. Егор Вершинин Да, именно это - решение. Хотя утрированное - она не совсем не обращает внимание на мнение стейкхолдеров, она их слушает, принимает во внимание и интегрирует в собственное видение продукта, насколько полагает нужным. Но окончательное решение - за командой.

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

Сергей Захаров. Максим Цепков далеко не всегда автоматизация "как есть" - это минус. Американцы скрупулёзно скопировали действия топового шеф-повара и перенесли их на робота. Статья кажется на Хабре была.

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

Сергей Захаров. Максим Цепков "Робот был создан в сотрудничестве с британским шеф-поваром Тимом Андерсоном, победителем телешоу MasterChef 2011 года. Технику приготовления и работу повара запечатлели в 3D и с помощью алгоритмов перевели в движения робота" - отсюда: https://m.habr.com/ru/company/rshb/blog/563462/

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

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

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

Егор Вершинин. Максим Цепков, в части "очень скептически относился к классическому проектному управлению, понимал большую ограниченность его применения в IT, равно как и ограниченную применимость классической работы с требованиями и много другого" - очень спорное и субъективное мнение. Для разработки Core сложных систем уровня Enterprise альтернатив пока не предложено. Agile практики применимы в подобных случаях уже позднее, когда кто-то уже заложил очень прочный и целостный фундамент как раз пользуясь классическими подходами.

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

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

Максим Цепков. Егор Вершинин Смотри тут какая штука. У тебя есть метод, который работает без гарантий и не для всех классов задач. Тогда ты понимаешь проблемы и соответственно относишься. Но проектный подход и классическое управление требованиями позиционировалось не так, оно позиционировалась как универсальная методология, гарантирующая решение. Мой скепсис касался этого. И тут еще вот какая штука. Если смотреть детали, то там появляется много тяжелых процедур, призванных гарантировать результат - но не справляющихся с этим. И вот их точно стоит выбросить, раз они не достигают цели. А это - не делают. При этом проблемы были осознаны в 1980-х, Брукс "Мифический человеко-месяц", Том ДеМарко "Человеческий фактор". Потом был эксперимент в RUP - неудачный, но это не признали. А потом - появился Agile, и дал ту же результативность (30-50%) при меньших трудозатратах. Так что уже в нулевых альтернативы появились как метод. А как практика - были и раньше, проекты делали с 60-х БЕЗ этих методов, которых тогда не было. Ну и в 90-х и я и многие другие достаточно успешно работали без них.

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

Ирина Качеровская. Максим Цепков вот! Здесь как раз ключевое — что ВЫ проблематизируете свои представления)) Потому что это ВЫ видите, ВЫ врисовываете в то, что «Дима сказал» Я не просто понимаю, я знаю, как это происходит) Вы постоянно думаете свою собственную мысль, и она начинает проступать через говорение других — но роль играет не само другое говорение, а тот смысл , что вы удерживаете у себя. А я, к сожалению, слышу, что именно говорит он сам…

Ирина Качеровская. Максим Цепков и вот на вашу реплику к Егору Вершинину. Просто надо различать процедуры, которыми облекли проектирование при реализации конкретных проектов — они часто мхом подернуты — и саму технологию мышления проектирования.

Это надо четко различать, методологически уметь говорить именно про технологию мышления проектирования… 🤓

Дмитрий Безуглый. Действительно был очень сложный опыт общения , после 3-х дней работы на курсе David Clutterbuck по Организацонному менторингу где мне пришлось интенсивно поработать над собственными ментальными моделями, все таки школы Орг.Дизайна очень разные, (Хвостик даже пришлось совмещать), я принимал участие в мероприятии Ирины. Это была ошибка . Проблемы:

1. Разительный контраст между современным уровнем структурирования, подачи информации у Davida и аттавистических представлениях практически обо всех сферах от мышления (Стенфордская школа придерживается гипотезы коллективного мышления), до разработки и проектирования у Ирины и коллег. Как доказательство приведу цитату Ирины " Мне не нужно разбираться в том что такое разработка ПО чтобы их всех научить думать, потому что они не умеют вообще"
2. Ригидность мышления свойственная адептам ММК в защите онтологии порожденной 30 лет назад. Такое впечатление что мышление на уровне принятия факта множественности онтологий им недоступно, по крайней мере Ирине. Как факт приведу пример что мы с Игорь Беспальчук потратили 1,5 часа на попытку объяснить что термин "Программирование" и выводы из его понимания делаемые Ириной и ее Коллегами в том числе Щедровицким , является просто активно пестуемым мифом, и не соответствует ни истории ни текущей ситуации. Она с трудом согласилась что лучше не говорить об этом в курсе для Руководителей Продуктов , но ни в коем случае не согласилась как то адаптировать свои суждения ( Кажется это так у них называется)
3. Восприятие ясности или неясности мышления существенно зависит от совпадения онтологического аппарата. Когда смысл слов не совпадает говорить об оценке способности мыслить не приходится. Но этот уровень рефлексии также не доступен Ирине и ее некоторым коллегам. Движение по структура Мир-Модель (ментальная модель) - Метамодель . Недоступно "аппаратно" в силу аксиоматического базиса из 80-х годов прошлого века ...

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

p.s. Это кстати тоже пример закрытого информационного пузыря. Точка зрения из него всегда структурирован по образу и подобию базовой структуры. И когда происходит не сдвиг а смена парадигмы эволюционная трансформация практически невозможна .

Дмитрий Безуглый. Максим Цепков Спасибо тебе за твой труд. Но c моих слов записано НЕ ВЕРНО. Прости, нужно было посмотреть заметку сразу после доклада и круглый стол был бы круглым столом :) Давай зафиксирую пару главных Моментов:

1. Образ продуктовой команды - это не команда которая игнорирует стейкхолдеров. Это команда которая ОБЛАДАЕТ экспертизой не только в том как делать, но и берет на себя задачи про что и зачем , и таким образом выходит не только за рамки Requirements management но и Requirements Development, В метафоре "Психбольницы в руках пациента" Продуктовая команда не хирург который спрашивает где вам разрезать и какими стежками зашить. А врач который делает диагностику и назначает решение, и к которому пациенты идут за здоровьем, а не манипуляциями ...
2. Я в принципе не имею ничего против проектного подхода в имплементационном контексте , например Даже проект Олимпиады может что-то выиграть от продуктового подхода ( и даже использует его) Проектный офис и руководство страны не формирует требования к тому как должны работать спортивные сооружения . Но в целом абсолютно корректно и правильно применять проектный подход. Я КАТЕГРИЧЕСКИ против переноса механизмов и онтологии ПРОИЗВОДСТВА на ПРОЕКТИРОВАНИЕ и СОЗДАНИЕ Программного обеспечения. В 95% случаев в сфере SOFTARE ENGINEERING слепое копирование ENGENERING менталитета признак профнепригодности. Развитие цифровых систем это не Complicated Domen, а Complex и поэтому управляется по другим законам ..
3. Хотя это не новая мысль , но лежащая в основе. Нельзя путать Информатизацию и Цифровизацию. Происходит не сдвиг парадигмы а ее смена. Цифровые организации не строятся по пирамидальному принципу , в котором главная сложность и компетенция сосредоточена управлении основным источником прибыли - Операционном труде людей (СРТ). Операции передаются машинам. В Цифре , как сказал CEO "Райффайзен": "Пришло время учится думать".

Егор Вершинин. Дмитрий Безуглый в таком изложении все заиграло верными красками.

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

Максим Цепков. Дмитрий Безуглый А про пункты 2 и 3 - перенос производства на проектирование и разработку софта и про разницу информатизации и цифровизации - я в целом согласен, просто переформулировал это своими словами со своими акцентами. Как и все остальное. Я интерпретирую и делюсь мыслями по поводу, а не даю точного изложения. Если важна точность - напиши статью. А так я могу даже ставить к изложению твоих докладов дисклеймер "все цитаты - неточные, все мысли - интерпретированные" - как я часто делаю в своих публикациях про выступления Щедровицкого после того, как он посетовал, что не слышавшие его выступления, но прочитавшие мое изложение приходят к нему с вопросами о том, как он мог сказать такие вещи...

Андрей Степенко. Замечательно что кто-то говорит что умственный труд не операционный, а какой? Про хирургов мне нравится аналогия. Медицина в целом использует как-то и где-то стандартизацию компетенций, сказал бы Минцберг. Хотя все рисуют схемы процессный или результатной стандартизации. Но инерция у аналитиков сильна. Только артефакты! Но что такое умственный труд? Что такое исследования если не смотреть как на источник прибыли? Источник чего? Как развернуть модель и рамку рассмотрения?

Дмитрий Безуглый. Максим Цепков Исследования по Куперу заканчиваются знаниями и продуктовой командой, (которая технически не может появится в проектного конвейере). Знаниями которыми: не обладает и не должен обладать "заказчик". Ты же не хочешь заказать себе мобильный телефон? Вдруг там шарлатаны?

Дмитрий Безуглый. Андрей Степенко Умственный труд - оксюморон.

Андрей Степенко. Dmitry Bezuglyy у тебя есть более точный термин? В студию!

Дмитрий Безуглый. Андрей Степенко Для себя для оргдизайна пользуюсь термином Система Разделения Компетенций. Функции не хватит.

Андрей Степенко. Дмитрий Безуглый? Генерация знаний где-то там происходит? Как система разделения компетенций задаёт дизайн этого процесса?

Игорь Беспальчук. Дмитрий Безуглый Компетенции - это чем обеспечено. Как насчёт "система разделения ответственностей"?

Максим Цепков. Дмитрий Безуглый Разделение труда на физический и умственный - достаточно устоявшаяся концепция, можно копать по ссылкам, кто это придумал (я думаю, будет несколько источников). Так что умственный труд - не оксюморон. Система разделения компетенций - так тоже можно, но компетенции - это потенциал человека, который может проявляться в конкретном проекте или не проявляться (я умею писать хорошо код на SQL, но во многих проектах этого не делаю, а занимаюсь другим). Так что разделение ответственности - лучше, при этом в обоих смыслах - sharing и division, потому что области нечеткие и перекрываются. Но разделение (компетенций, ответственности) - это статика, а нужна еще динамика деятельности - через процесс, фазы или иным образом.

Максим Цепков. Дмитрий Безуглый Но, возвращаясь к Куперу. Откуда бы не появилась продуктовая команда (я согласен, что она обычно не из проектного конвейера возникает), она вполне может оказаться в ситуации, что делает нафиг никому не нужное, воспроизводя ситуацию, описанную Купером. Мой тезис - в этом.

Дмитрий Безуглый. Андрей Степенко Какого процесса? Пу сути это модель сети создания ценности, как на макро так и на микро уровне. Процессы это про операционку. Мета процессы работают плохо.

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

Евгений Адамов. Метафора шикарная. На мой взгляд интересный вопрос, почему при понятном в целом подходе к лечению (ebm и др подходы основанные на данных) так мало лечащих врачей?

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

Дмитрий Безуглый. Евгений Адамов Здесь спрос определяет предложение , для симптоматического лечения современная концепция медицины "достаточно" хороша и воспроизводима. "Правильный врач" как продукт в биологической форме не реализуем ( гипотеза) Что то на тему изменения порядка сложности для системы необходимой для полного моделирования исходной системы "класса" complex. Поэтому врачу человеку всегда доступен только отдельный аспект целого... Но то о чем говорит Максим уже реализуется в контексте персональной медицины и комплексных исследований включающих особенности генома. Если мне не изменяет память количество основных геномов покрывающих "ядро" человечества около 1000, приемлемая база для исследований 2000 , полное покрытие практически пока не достижимо :))

Максим Цепков. Дмитрий Безуглый Да, к персонализированной медицине - идут, но, во-первых, медленно, а во-вторых - методологически неверно, по-моему. Потому что они хотят проскочить этап кластеризации. Как проскакивают его для симптоматического лечения - все инструкции которые я видел кластеризуют симптомы, но не кластеризуют людей, а одни и те же симптомы у полных и худощавых, у разных возрастных групп и так далее могут давать весьма разную картину. Это - печалька...

Николай Сапцин. Коллеги, а можно уточнить: у кого из вас есть медицинское образование и соответствующий опыт работы ?

Максим Цепков. Николай Сапцин Насколько я знаю - образования нет. Но есть задача заботиться о собственном здоровье и здоровье других близких, для этого в нынешних условиях надо разумно выбирать врачей и методы лечения - а для этого должна быть адекватная картина ситуации в медицине в целом, иначе это будет "выбор по слухам". Вот этой картиной мы тут и обмениваемся - в контексте решения этой актуальной задачи. Если в хотите внести своей вклад - welcome.

Дмитрий Безуглый. Николай Сапцин Мама врач, сестра врач. А с парнем который двигает персональную медицину в Барселоне познакомился на физтехе. Собственно с какой целью интересуетесь? Мучали ли меня атавистическими и эмпирическими теориями 9 лет в меде? Нет, больше 30 лет только проблематикой сильно выходящей за рамки базового курса.

Юлия Ерина. Как вытащить себя за волосы из болота: проектный подход к изменению себя и своего психологического состояния

Пост на FB Юлия Ерина "Как вытащить себя за волосы из болота: проектный подход к изменению себя и своего психологического состояния". У меня впечатление неоднозначное. С одной стороны, доклад безусловно содержательный и полезный - о том, как именно относиться к себе как к проекту, как делать проекты изменений себя. С большим количеством полезных знаний и практик. Это структура проекта изменений: выгода, рост, эффективность, управление рисками и экологичность, соблюдение ценностей. Это модель Левина разморозь - измени - заморозь и модель ADKAR. Доска в Миро по целям, Юлия ежегодно подводит итоги и ставит новые цели. Метрики продвижения к целям. А еще - ежедневные метрики как прошел день, чтобы отслеживать ресурсность текущего состояния и разбираться с его падением. И практические советы как идти поступательно.

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

Но это уже вопрос личной картины мира и своего места в этом мире. И это включает как целевую картину, образ идеала, так и ограничения, которые ты ставишь на пути к этому образу, двигаясь экологично и контролируя допустимость изменений. В общем, оно у всех разное. И если эти методики брать для себя, то это надо безусловно учитывать. У меня тут другие образы и ограничители. Более того, я не провожу изменения по плану, я ожидаю для этого подходящих случаев, которые предоставляет мир. Это похоже не предпринимательскую бдительность. А отличие между теми, кто идет по плану и теми, кто ждет случая - это дихотомия Решающие - Воспринимающие (Judging-Perceiving J-P), по Майерс-Бриггс (MBTI) и статистика говорит, что деление людей тут примерно пополам.

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

Отмечу, что если вы увидите, что действия по плану - не для вас, это не значит, что с вами что-то не так. Просто вы другие. Это дихотомия Решающие - Воспринимающие (Judging-Perceiving J-P), по Майерс-Бриггс (MBTI) и статистика говорит, что деление людей тут примерно пополам. Я - воспринимающий, поставив цели, я не действую по плану, а ожидаю для этого подходящих случаев, которые предоставляет мир. В бизнесе это называется предпринимательская бдительность.

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

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

Для интересующихся модель ADKAR:

A — Awareness — Осведомленность о необходимости изменения

D — Desire — желание участвовать в изменениях

K — Knowledge — знание, что именно требуется сделать для изменений

A — Ability — умение/способность воплощать изменения

R — Reinforcement — подкрепление реализованных изменений

Андрей Бураков. REST, что ты такое?!

Пост на FB Andrey Burakov. REST, что ты такое?! Рассказ о том, какие представления скрываются за словом REST-протокол у разных людей. Самый распространенный - что это протокол, предусматривающий любую передачу Json поверх http. В то время как реально REST не является протоколом, не обязательно предполагает http, зато формулирует принципы организации приложения, обеспечивающие масштабирование и простоту взаимодействия. Вот они, тут Андрей опирался на Филдинга, который его создал.

• Клиент-серверная модель. Разделение UI и серверной бизнес-логики
• Stateless обработчики запроса
• Кеширование - все ответы сервера должны иметь пометку, можно ли его закешировать
• Единообразие интерфейса для всех объектов
• Независимость клиента и сервера от организации промежуточных узлов для балансировки нагрузки или кэширования
• Гипермедиа - ссылки на связанные сущности и действия

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

Дмитрий Федорец. Империя против Матрицы

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

А выводы интересны.

• В иерархической модели руководитель становится не нужен после половины спринта, а в в матричной организации руководитель нужен до конца
• Руководитель оказывает слабое влияние на процесс, главное влияние в обоих случаях оказывает клиент.
• Клиент получает больше удовлетворения и быстрее в матричной организации
• Однако, в иерархической организации у клиента value будет больше
• Наибольшее влияние - компенсация, то, что клиент отдает обратно в организацию.
• При ограниченных ресурсах и результатах любой ценой - иерархии предпостительнее, а при ограниченных сроках - матричная бизнес-архитектурах (в модели время не является ресурсом). Если ограничений нет, или ограничений оба - то можно выбирать любую систему.
• Гибкость - меняем архитектуру организации работы в зависимости от ограничений
• Самый уязвимый - исполнитель, а именно он определяет value
• Взаимодействие с клиентом и его удовлетворенность напрямую влияют на результат, а они зависит в первую очередь от команды

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

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

Ирина Метелева. Планирование трудозатрат в условиях неизвестности

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

Комментарий Ирина Гертовская: Презентация доклада Ирины уже размещена на ресурсах conf.uml2.ru. А мне чрезвычайно приятно, потому что изначально задача была решена для отдела системного анализа и несколькими годами ранее я докладывала на Analyst Days 2017 "Оценка трудозатрат аналитика, практика применения": https://www.youtube.com/watch?v=YmYjLku6Al0. У Ирины Метелевой - обобщение (как я сейчас понимаю, доклад пока не смотрела). Привязка к информационным объектам, для дальнейшего отслеживания всех трудозатрат на документ (инф.объект) - ценно. Сбор всех затрат от БА до ТЕ - тоже плюс. Иногда очень пригождается. Да, однажды с Ириной Немцовой рассказывали на ЛАФе (во Владимире) в рамках мастер-класса для руководителей подразделений.