YK's Daily Links

Опыт сбора требований или знакомство с предметной областью позволяет лучше выявлять требования, да? Нет. Эксперименты показывают, что влияния либо нет, либо оно отрицательное(!) Статья 2022 года, https://www.researchgate.net/publication/363930741_Effect_of_Requirements_Analyst_Experience_on_Elicitation_Effectiveness_A_Family_of_Quasi-Experiments В незнакомых областях опыт проведения интервью, опыт работы с требованиями, опыт разработки и профессиональный опыт не оказывают никакого влияния на эффективность аналитика. В знакомых областях эффективность варьируется в зависимости от типа опыта. Опыт проведения интервью оказывает положительное влияние, тогда как профессиональный опыт оказывает умеренно отрицательное влияние. Опыт работы с требованиями, по-видимому, оказывает умеренно положительное влияние; однако статистическая мощность анализа недостаточна для подтверждения этого момента. Опыт разработки не оказывает никакого влияния. Заключение. Опыт по-разному влияет на эффективность аналитика в зависимости от типа проблемной области (знакомая, незнакомая). В целом, опыт не объясняет всю наблюдаемую вариативность эффективности, а значит, существуют другие влияющие факторы.

Известный график, в котором показывается чуть ли не экспоненциальный рост стоимости исправления ошибки в продакшене по сравнению с ошибкой на этапе сбора требований (в 100 раз, в 1000 раз — у кого на сколько смелости хватает), судя по всему, вообще ни на чем не основан. Ну или был актуален в 1970-х, когда вы пишете на Коболе и Фортране, вводите код на перфокартах и имеете очень ограниченные средства тестирования. В более-менее современных условиях (2014-2017 годы) никакой значимой разницы в стоимости исправления нет: https://www.researchgate.net/publication/308264787_Are_Delayed_Issues_Harder_to_Resolve_Revisiting_Cost-to-Fix_of_Defects_throughout_the_Lifecycle А так вообще никто и не проверял, и не проверяет. Но, думаю, если вы вспомните свои проекты — согласитесь, что нет там никаких "в 100 раз дороже".

Какая-то невероятно подробная инструкция по именованию разных вещей (переменных, параметров, названий функций, файлов и т.п.) https://johnfarrier.com/a-practical-guide-for-naming-things/ Правда, не раскрыта тема имен релизов, типа как ранние версии Android назывались именами печенек.

Черт. Черт. Оказывается, по-английски "метод грозовой тучи" Голдратта — это "evaporating cloud"! Испаряющееся облако! Никакая не туча, и не грозовая! Облако, которое закрывает участникам конфликта вид на общую картину, нужно испарить, чтобы они поняли, что в конечном счете хотят прийти к одному результату. Кто этот перевод придумал, хотел бы я знать. С этими переводами вообще беда — вот перевели когда-то "системную инженерию" как "системотехнику" — и всё, вся страна не туда ушла. Хуже того, это цитата из Ричарда Баха: " — Ненужные аксессуары, Ричард. Если ты хочешь убрать из своей жизни облако, не превращай это занятие в крупное предприятие, просто расслабься и не думай о нем. Убери его из своих мыслей. Вот и все."

Мертвые заговорили. В смысле я решил взять себя в руки и начать писать хорошие вопросы в канал опять. Я тут снова начал делать стартап. Про навыки устной обратной связи. Идея в том, что нам нужны тренажеры, которые помогают людям быть более людьми. И да, мы для этого используем ИИ. Это некоторая гуманистическая позиция — мне не нравится, когда людей делают роботами, но кажется тупым не использовать возможности ИИ для обучения. Так вот: если вы давно меня знаете, то я сколько-то раз вам жужжал в уши про то, что я думаю про обратную связь. Поэтому первый навык который я решил засунуть в наш MVP первым делом мои упражнения по фидбеку. (Если вам интересно потестировать / поговорить о том, нужно ли вам такое — велкам). Но раз уж я это стал делать, я заодно стал проверять что говорит современная наука, про мою эмпирику. Вообще — стартап класен тем, что заставляет ботать. Ботать с поводом гораздо интереснее, чем ботать без повода, скажу я вам. Спойлер — в целом моя эмпирика оказывается ничего такая. Но есть и открытия. Например “Шит сэндвич”, о боже мой, имеет слабое эмпирическое подтверждение. Точнее так — похвала до и после критики действительно снижает сопротивление на принятие фидбека, но не повышает его влияние на изменение поведения. Вместо этого предлагается использовать Ask-Tell-Ask. Т.е. начинать с расспроса о самооценке работы, затем давать свои комментарии, и в конце совместно обсуждать шаги улучшения. Такое вовлечение показывает лучшее восприятие и развитие навыков, чем односторонняя схема похвала–выговор-похвала. Самый смех в том, что на практике я так и делаю, но когда описывал методику вместо того чтобы тщательно задокументировать свое поведение — взял из комон сэнса что-то что казалось мне очевидным. Не будьте как я, тщательно мойте практику перед описанием. [1],[2],[3] А, ну и вопрос: какие еще приемы обратной связи, которые все считают классными, на самом деле не работают?

О, шит-сендвич как метод фидбэка не особо работает! Никогда не любил его. А в медицине (и в обучении, и в общении) используют Ask-Tell-Ask (или Ask-Offer-Ask). Медицинское обучение вообще немного отдельное, и там много своих интересных находок, которые малоизвестны вне его.

Пост про Accountability в Scrum: опять у нас два термина — accountability и responsibility, которые на русский переводятся одинаково как "ответственность", а означают разное. https://www.scrum.org/resources/blog/scrum-accountability

Все рассказы про важность ценностей в организации не очень-то подтверждаются эмпирическими исследованиями. Вот статья с обобщенной критикой: https://www.researchgate.net/publication/331350728_What_Is_the_Practical_Utility_of_Value_Research_for_Organisational_Practitioners_in_a_Global_Context Автор говорит, что есть несколько допущений, обычно не принимаемых во внимание при исследовании ценностей: 1) ценности универсальны для всех людей и не зависят от ситуации ; 2) ценности стабильны за всё время профессиональной карьеры ; 3) не совсем ясно, что вообще такое ценности, и насколько они определяют поведение; 4) размер эффекта влияния ценностей на поведение сотрудников относительно невелик, в основном всё определяется рабочими полномочиями и задачами; 5) неясно, что организации должны делать, исходя из понимания ценностей сотрудников. Ну и многие исследования выполнялись, как обычно, над студентами, а не в реальной рабочей ситуации. Это обзор литературы, там есть ссылки на разные исследования, в целом эффект ценностей в контролируемых экспериментах не превышает 5% (например, повышения креативности). Особенно мне понравилось исследование связи ценностей и проактивных действий по соблюдению норм безопасности. Коэффициент корреляции 0,02. В общем, все эти ценностные тесты при приеме на работу лежат где-то между таро и гороскопами и 5% вкладом в реальную деятельность.

Ух ты — оказывается, провал коллективных принятий проектировочных решений — "Design by committee" — имеет строгое математическое доказательство и называется "Теорема Эрроу о диктатуре": https://ru.m.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_%D0%AD%D1%80%D1%80%D0%BE%D1%83 Это что-то вроде CAP-теоремы для выборов: если у вас есть система голосования, где люди ранжируют набор кандидатов (например, функции приложения или элементы бэклога), то такая система не может быть одновременно универсальной, независимой от внешних альтернатив, эффективной по Парето и без диктатора (чей голос решающий). Универсальность означает, что итоговое решение существует для любых частных выборов участников. Независимость от внешних альтернатив — при добавлении ещё одной опции в итоговом решении не происходит перестановки приоритетов уже имеющихся. Эффективность по Парето — эффективность какого-то показателя системы не может быть улучшена без ухудшения других показателей. Отсутствие диктатора — ни у кого из голосующих нет права последовательно продавливать своё решение, игнорируя остальные голоса. И вот математематически доказано, что невозможно обеспечить все 4 свойства (ну или 5, в разных формулировках). Либо у вас вообще не сходится итоговый результат, либо вы забыли какую-то важную фичу, либо ваш проект неоптимальный (не эффективный по Парето), либо у вас есть диктатор. Такие дела.

Нашел статью, в которой декомпозиция бизнес-процесса анализируется через пуассоновский марковский процесс. То есть, автор постулирует, что любая декомпозиция БП по сути является случайной 🤦‍♂️ Интересно, что выводы из такой модели у него очень хорошо сходятся с практикой, то есть эмпирическими наблюдениями... (он зам. директора ИТ-компании).

Почему-то мало кто смотрит на программные системы с точки зрения числа степеней свободы, хотя для физики и механической инженерии это одно из ключевых понятий. И там построено множество моделей, позволяющих их просчитать аналитически или численно. Число степеней свободы — это большая проблема. Для больших сложных систем их число равно числу атомов; физика научилась с этим жить, открыв термодинамику и вообще статистический подход. Для программирования это не подходит (ну или только в узких областях, в хайлоаде и параллельных вычислениях), а число степеней свободы может легко достигать нескольких тысяч (по числу полей и связей в БД, например). Почему-то сходу нашел только одну статью со схожими мыслями: https://thesephist.com/posts/dof/

Прекрасная статья про принципы декомпозиции сервисов: https://www.researchgate.net/publication/307873263_Service_Cutter_A_Systematic_Approach_to_Service_Decomposition Авторы выделяют 16 критериев, сгруппированных по 4 категориям: - Сцепленность - Совместимость - Ограничения - Коммуникация Дальше есть алгоритм взвешивания и кластеризации. Надо будет поиграть на какой-нибудь конфе. 175 цитирований у статьи, чтоб я так жил. Я всегда смотрю, кто цитирует. Всё же, это 2016 год, а что сейчас? И, угадайте, в каких статьях в 2024 цитируется эта? Конечно же, куча статей про автоматическое выявление сервисов и разбивку монолитов при помощи нейросетей и ML!

Удивительная история развития ИТ-технологий в СССР, про которую мы почему-то мало знаем (в университетах бы её на соответствующем предмете рассказывать!). Всё двигалось благодаря вот прямо паре-тройке человек, главным из которых был академик Берг. Он создал в 1959 году Научный совет по комплексной проблеме «Кибернетика» при президиуме АН СССР, реабилитировал кибернетику, которую при Сталине запрещали, и начал создавать различные институты, НИИ, кафедры, лаборатории, запускать программы исследований и оформлять новые научные дисциплины (вот уровень и задачи академии, на самом деле — создавать новые разделы науки). Ужасно интересно, как раскрутить такой движ. https://www.researchgate.net/profile/Alexei-Semenov-2/publication/378461397_The_role_of_the_Scientific_Council_on_the_complex_problem_of_Cybernetics_of_the_USSR_Academy_of_Sciences/links/65da17dee7670d36abdbb4af/The-role-of-the-Scientific-Council-on-the-complex-problem-of-Cybernetics-of-the-USSR-Academy-of-Sciences.pdf

Не во всем великие правы. И то, что концептуально целостно, будет удобно на практике. Реальные системы (и их API) не целостны, а скорее неряшливы. Вот, например, статья, в которой Тим Бернерс Ли (!) советует избегать иерархий в URI, и проектировать их так, чтобы они никогда не менялись. Любая же классификация может со временем меняться, и вам придётся менять все URI, что разрушит сохраненные ссылки. Поэтому включать в URI можно только дату создания документа — уж она точно не поменяется! Очевидно, что дата создания, хоть и мало меняется, несёт также крайне мало смысла — она никак не описывает документ или ресурс, который мы хотим идентифицировать. Поэтому в реальном мире так, конечно, никто не делает — что, собственно, видно из URL этой статьи :) И великие могут быть не совсем правы!

Собственно, вот 4 варианта из статьи: детерминистские машины, динамические системы, системы с обратной связью и социальные конструкты. А как смотрите на бизнес-процессы вы?

Наконец-то я нашел статью с обзором теоретических оснований моделирования бизнес-процессов. Спойлер: изначально всё плохо, что такое "бизнес-процесс" толком никто не знает, но есть несколько подходов разной степени жесткости. В конечном итоге всё сводится к разным философским концепциям. Вообще я давно уже считаю, что ИТ - это инженерия для философии, примерно как гражданская инженерия для физики. Как же не хватает философов, которые могут понять и говорить о бизнес-процессах и поведении пользователей в ИТ-системах, и создателей систем, которые могут рассуждать о философии! Поговорить не с кем. Статья 2000 года, для теоретического обзора это нормально, концепции редко меняются (а в случае БП они вообще из 60-х). 277 цитирований -- это хороший показатель, можно в них покопаться, там тоже наверняка есть интересное. https://www.researchgate.net/publication/220356669_Nuno_Melao_MP_A_Conceptual_Framework_for_Understanding_Business_Processes_and_Business_Process_Modelling_Information_Systems_Journal_102_105-129

90% моделей бизнес-процессов — клоны друг друга. Правда, это в открытых репозитариях (open source), но некоторые выводы сделать можно. Группа исследователей проанализировала 25,866 моделей бизнес-процессов в формате BPMN в 4,954 репозитариях, 90% из них оказались копиями (и это без учета прямых форков!). БОльшая часть клонов содержится в репозиториях, относящихся к индустрии (в сравнении с академическими). Интересно, сколько клонов процессов реально создается внутри компаний. Тоже, кажется, довольно много. https://link.springer.com/article/10.1007/s10664-024-10584-z

Интересная картинка. Откуда, правда, такие оценки -- непонятно. Не в каждой системе найдется миллион движущихсяя частей. Хотя, что и как считать. Отсюда: A Reference Architecture Primer. Gerrit Muller University of South-Eastern Norway-NISE