Александр Турханов и Rafael Asanov поделились публикацией.
Прошёл давеча тренинг по Agile Product Ownership у Vladimir Gorshunov. Докладчик матёрый, тренинг содержательный; будут предлагать - берите два.
Но, как человек, неизлечимо больной хронической эпистемологией, я смотрел на премудрости продуктового дела с такой острой онточувствительностью, что нередко приводило к черепно-мозговым спазмам.
В agile-коммуне народ во всяческих организациях и самостоятельно изобретает способы, как дисциплинировать потоковую разработку продуктов, так чтобы уменьшить когнитивную нагрузку, повысить качество результата при снижении времени на процесс и с этим вписаться в инженерную среду ИТ-компании, что имеет известные особенности. При этом всё agile. В общем, задача по обобщению опыта - нужная и благородная.
Обобщение с построением некой модели или схемы — это в системной инженерии называется онтологизация, онтологическая работа. Дисциплина по имени "онтологическая инженерия" уже такого возраста, что ей в трамвае нужно место уступать. Но в коммуне продукт-манагерских методологов место ей в трамвае не уступают. И это бесчеловечно.
Вот пример онтологизации на коленке, один из многих. При всём почтении к господам Ron Jeffries и Bill Wake, их подходы к систематичной оценке качества user stories, под аббревиатурами 3С https://ronjeffries.com/…/…/expcardconversationconfirmation/ и INVEST https://xp123.com/a…/invest-in-good-stories-and-smart-tasks/ соответственно - это именно онтологизация на коленке. Объясняю.
Во-первых. Я понимаю всю привлекательность красивых аббревиатур, и пущую запоминабельность (а точнее - marketability) терминов, но "война - не покер, её нельзя объявлять когда вздумается" (с) Как нельзя загонять такую важную штуку, как инженерная концептуализация в какой-то литературный гламур. "Card, Conversation, Confirmation"; "Independent, Negotiable, Valuable, Estimable, Small, Testable" - это линейные онтологии, явные спецификации категорий оценки объектов. И по приведённым спискам видно, как безжалостно изобретатели хреначили по онтологии киянкой, положа на колено, чтобы добиться лингвистических симметрий.
Нельзя жертвовать семантиками ради прикольного синтаксиса. Прагматика будет страдать.
Во-вторых. Задачи для этих подходов:
1) определить проблемы, которые подход решает;
2) специфицировать целевые характеристики качества пользовательских историй;
3) определить список использующих практик, которым юзер стори нужны как артефакты;
4) мотивировать введение характеристик (2) в контексте практик (3), как эффективно решающих проблемы (1)
5) добиться soundness & completeness: согласованности и полноты группы характеристик (2), чтобы оные решали все проблемы (1) без перерасхода когнитивных, организационных и прочих ресурсов на решение чего-то сверху ненужного;
6) указать и связать с характеристиками (2) группы практик, обеспечивающих нужное качество.
Если, конечно, мы разрабатываем современный инструмент, для массового промышленного производства, а не палку-копалку. Или тут что-то лишнее указано?
Кому интересно, проинспектируйте определения 3C и INVEST по данной (собранной на коленке во время написания поста) системе категорий. Или по какой-то иной - но она должна быть. Это и называется "иметь метод".
В-третьих. Желания как-то запинать до смерти эти подходы у меня нет. Они тоже возрастные, по 15 лет и более каждой. Можете сами поупражняться на SMART, PURE, CLEAR и прочих - их пинать просто. Но есть масса организационно внедряемых онтологий с теми же проблемами без всякого синтаксического гламура. Внедряемых просто потому что они есть, а не потому, что они хорошие.
Дело даже не в конкретно тех или иэти, а в том, что онтологизация без дисциплины - это обычное дело. Тот факт, что программирование без дисциплины или строительство мостов без дисциплины - это плохо или фатально уже осознан, а вот с онтологизацией пока всё не так ясно. А проблема в том, такие фольк-онтологии, распространённые гораздо шире, чем вы думаете, и которые сейчас может запросто собирать каждый ушлый практикант, в силу как раз отсутствия дисциплины, технологии, метода, затрудняют масштабирование, удлиняют релизные циклы, пожирают качество, крадут деньги. Как и любая другая практика, которая выполняется без дисциплины в большом масштабе.
Может ли это работать? Конечно - если хорошие руки смогут к правильному месту приблудить, доработать напильником и насверлить монтажных отверстий в нужных местах. Пока именно так и работают.
В-четвёртых. Всё так пока и останется. Пока кажется, что мест, где вырастает осознанная потребность в онтологической работе, ещё меньше, чем людей, которые могут это сколь-нибудь методологично делать.
Архитекторы, продакты, манагеры, онтологи - все дармоеды. Только лишнее топливо жрут.
Александр Турханов поделился публикацией.
Мозг - как шкаф с картотекой. Когда вы кладете в него любимый свитер, он попадает не только на полку, но и в разные карточки. "Любимые вещи", "Синяя одежда", "Теплая одежда", "Деловой кэйжал", "Можно носить с галстуком", "Подходит к коричневым брюкам". Этот шкафчик с полками и картотекой называется онтологией. Хорошая онтология позволяет быстро доставать идеи, правильно их структурировать, чтобы было удобно с ними работать и рождать новые идеи. Плохая онтология запутывает вас и других.
Шкафы бывают Икея, а бывают фабрики Большевичка. Эргономика и удобство у них разное, хотя и то и то шкаф. Если долго тренироваться, то можно и в Больщевичке достаточно быстро находить вещи и вам будет казаться, что ничего, нормальный шкаф. Пока вы не встретитесь с человеком, который научился укладывать и доставать в икеевский шкаф. И тогда вам становится понятна цена вашего шкафа. Тут главное не обижаться и на говорить: "Ну конечно, это же целый шведский R&D пятьдесят лет разрабатывал самый лучший дизайн, а я на распродаже купил за пять копеек, вон зато сколько смолы в ДСП, я китайскую болгарку сломал, когда подрезал его по высоте". Надо просто купить нормальный шкаф, а старый вывести на помойку.
С другой стороны, придет менеджер и скажет: "Чего это вы шкафами раскидались? Где обоснование необходимости закупки?" Тут тоже важно не встать в моральную позицию и начинать говорить, что все нормальные разработчики с Икеей работают и только вы тут на коленке доморощенные онтологии мастерите. Не вздумайте про качество заикаться или про то, что работу надо делать хорошо, иначе как же так, профессиональная гордость за работу и качество продукта. В тот же момент сольете спор потому что не сможете ответить на простой вопрос менеджера: "Я сейчас пойду к заказчику и могу сказать, что мы либо еще две фичи на прод выкатим либо мы тут онтологию предметной области подправим. Давай ты пойдешь со мной и сам ему обоснуешь, почему это мы должны вот этим заниматься?" Потому что деньги рулят миром и вести спор надо в экономических терминах. И у онтологической и у архитектурной работы есть экономическое обоснование, его надо знать так, чтобы оно от зубов отскакивало.
А дальше читайте Егора, он хорошо написал. Правда, слово эпистемология пару раз все же использовал, но вы не пугайтесь, закон Купера про незнакомые слова в техническом тексте все еще действует.