Системный сдвиг

Ещё одна конференция в сентябре, на этот раз именно для аналитиков — Flow 2023. Она тоже 4-5 сентября, буду разрываться :) Но к Flow внимания больше — там я и член программного комитета, и выступаю с докладом Скрытая работа аналитика по проектированию систем и ещё буду экспертом на других докладах, работы много. Как член программного комитета, скажу: мы отобрали самые лучшие доклады по анализу и проектированию систем, программа получилась просто огонь! Так что приходите 4-5 сентября в онлайне и 11-12 сентября в офлайне — обсудим горячие темы системного анализа, а на моем выступлении — насколько профессия системного аналитика всё ещё про анализ, а не про проектирование (я считаю, что давно уже про проектирование, и анализ в чистом виде мало где встречается, вот только не все это окончательно осознали). Встретимся на Flow!

Летом в отпуске положено читать книги. Книг по системному анализу вообще мало. А художественных почти и нет. Но я неожиданно нашел! "Парк Юрского периода" - уже не помню, что там в фильме, а книга-то вся про системный анализ, с небольшими вкраплениями динозавров, просто для антуража. Там же весь набор: - эксперты не выдают ключевую информацию, потому что считают её несущественной/ошибочной/редким частным случаем (эксперты вообще склонны рассказывать про типовой опыт, а не про отклонения -- хотя именно отклонения и частные случаи "убьют" вашу систему. В книге про это тоже есть - "вы исследуете не систему, как она есть на самом деле, а систему, как вы её ожидали увидеть", говорит персонаж-математик); - заказчики не выдают полной картины назначения и использования системы, а только частные ТЗ на отдельные модули - и пытаются из этого собрать работающую целостную систему, с предсказуемым результатом; - потом те же заказчики требуют от программиста всё бесплатно доделать, и думают, что им за это ничего не будет; - нанимают системного аналитика, а потом игнорируют его рекомендации - классика! Отличный план для реализации сложной системы! Какие ещё являения описаны очень жизненно: во-первых, сочетания множества безобидных факторов, приводящих к катастрофе. Ну там: работы на центральном пульте управления, баг в управляющем контуре, одновременно с этим начинается гроза, одновременно с этим по каналам связи передается большой объем данных, одновременно с этим один сотрудник случайно пропустил нужный поворот, одновременно от ветра падает дерево... ну, понятно, заканчивается это тем, что кого-то съели. Я смотрел анализ крупных катастроф - они почти все были результатом сочетания многих факторов. Очень часто вмешивается природный или какой-то внешний фактор: ночь, дождь, туман, гроза, снегопад, или наоборот жара; повышение потребления, высокий трафик или наоборот - резкое падение... Мой однокурсник делал знаменитую пятерку новостей (ещё до закручивания гаек, когда всё было по-честному) - и рассказывал, что они очень быстро вычистили все часто встречающиеся ошибки - ну, вероятность которых больше 0,00001% - то есть, происходят на главной Яндекса по нескольку раз в день. Уже на вероятностях 0,001% это были сочетания трех-четырех маловероятных факторов. Дальше пошли сочетания 6-7 крайне маловероятных факторов - то есть, человек вообще про такие штуки редко думает, а уж представить, что будет при их сочетании заранее очень сложно. Между тем, в современных высоконагруженных системах такие события происходят гораздо чаще, чем мы ожидаем. В книге это очень достоверно показано. во-вторых, создатели парка явно не изучали методические документы ФСТЭК по безопасности, поэтому у них там куча дыр и с точки зрения защищенности (чтобы защитить свои данные и ноу-хау), и собственно в безопасности (чтобы снизить вред для пользователей, операторов и окружающей среды). Например, в книге очень ярко показано, что может натворить внутренний нарушитель с высоким потенциалом и со следующими возможными целями (мотивами): "Причинение имущественного ущерба путем мошенничества или иным преступным путем. Любопытство или желание самореализации (подтверждение статуса). Месть за ранее совершенные действия. Выявление уязвимостей с целью их дальнейшей продажи и получения финансовой выгоды. Непреднамеренные, неосторожные или неквалифицированные действия". в-третьих, создатель парка впадает в типичную ловушку всех визионеров: пытаться одновременно внедрить сразу несколько инноваций. Чувак, у тебя и так уже динозавры, чего ещё?! Но нет - ещё мы сделаем уникальную систему автоматического управления, чтобы людей поменьше нанимать, и впихнем в неё системы распознавания образов, автономные автомобили и сложный BI, завязанный на безопасность. Кто реально занимался сложными системами, знает железное правило: одно инновационное изменение за раз! Иначе будет невозможно локализовать проблему.

Представим, что на дворе 1930-е годы. На выставке инструментов для лесного хозяйства фирма Андреаса Штиля только что представила бензопилу, способную сделать революцию в отрасли. Герои нашей истории работают в небольшой компании, занимаются валкой леса. Её менеджеры только что вернулись с выставки. Просто взять и начать валить деревья с большей скоростью — это прекрасно. Но ведь нельзя просто так взять и посадить первого попавшегося представителя какой-нибудь из заинтересованных сторон за стол и попросить его написать требования для закупки бензопилы. Системное мышление заставляет задуматься: как же эта новая технология будет применяться с точки зрения бизнес-операций? К сожалению, менеджмент также не может с пользой для дела прийти к заинтересованным сторонам, видимым с точки зрения бизнес-операций, и попросить их сформулировать потребности и требования к возможностям, открываемым новой бензопилой. Операционные менеджеры ведь управляют лесорубами, которые работают топорами. А эти серьезные мужчины вряд ли смогут рассказать, что им придется делать с новым инструментом: они никогда этого не делали, их никто не учил, не проводил инструктаж по безопасности или обслуживанию пилы. Или, что более вероятно, не захотят помогать: ведь в лучшем случае им придется переучиваться. А в худшем вообще остаться без работы. Похожая ситуация с отделом снабжения. Его сотрудники знают своё дело — и в мельчайших подробностях! Сколько топоров ломается на кубометр поваленного леса (и сколько нужно закупить и доставить) известно. Но совершенно непонятно, как поддерживать работу новой бензопилой: что делать с топливом, смазкой, где всё это хранить, сколько запчастей и какие закупать, как часто. Как вообще узнать, что всё это нужно? Перед тем, как на уровне бизнес-операций кто-то сможет ответить на все эти вопросы (то есть, выполнить требования), на уровне бизнес-менеджмента необходимо решить, как и зачем внедрять технологию на предприятии. Предприятию нужны эти бензопилы, чтобы быстрее валить деревья? Или скорость работы должна остаться такой же, просто выполнять ее хочется эффективнее (например, уволив несколько сотрудников)? В любом из этих случаев придется решить, что делать с людьми: переучивать ли их или нанять новых? Обслуживание топоров устоялось: торговцы не просто продают инструмент, но и отвечают за его состояние. Сломалось топорище? Просто отправляем его торговцу, он заменит. Затупилось лезвие? Снова к торговцу: он заточит. А с кем и как вести дела, если закупить бензопилы? Как поддержать снабжение? Как перевозить материалы — топливо, масла — с которыми сегодня в компании никто не работает? Как их хранить, с учетом пожароопасности? Как утилизировать просроченные остатки? Как и кто эту новую способность предприятия (все эти двигатели, цепи) будет поддерживать? Как поменять структуру организации? Как внедрять эту новую способность: выдать всем операторам бензопилы сразу, командам по очереди или начать с каких-то определенных регионов? Если начать валить деревья быстрее, нужно ли будет найти дополнительный транспорт для перевозки материала? Не придется ли расширять лесопилку? В конце концов, бизнес-менеджменту придется решить, стоит ли поставлять больше продукции и наводнить ею рынок, обрушив таким образом цены.

Если бы я попал на необитаемый остров, и мог бы взять с собой только одну книгу по системному анализу и разработке требований, я бы взял Руководство по написанию требований от INCOSE (Международный совет по системной инженерии). Что удивительно, это руководство есть в переводе на русский язык, я даже немного участвовал в его создании (настолько немного, что я не упомянут среди команды переводчиков и рецензентов). Руководство, хотя и фокусируется именно на текстах требований, но также вводит само понятие требований, причем разделяет потребность и требование; описывает свойства и атрибуты качественных требований; говорит о верификации и валидации системы, а также про управление требованиями. В Руководстве определяются уровни потребностей и требований, а также представлена типовая последовательность работ от выявления потребностей и ожиданий до создания системы, и даже V-модель. Разделение на потребности и требования мне представляется очень важным. Потребности (и ожидания) — это те самые desiderata, о которых говорит Пол Ральф. Это ещё не требования. Требование — это обязательство, принятое каким-то субъектом (организацией, командой или человеком) по реализации системы, выполняющей определенную функцию или обладающей определенным качеством. Потребность может транслироваться в несколько требований, и одно требование может закрывать несколько потребностей. Требования не могут быть противоречивыми, а потребности и ожидания — постоянно. Когда мы говорим про согласование требований разных стейкхолдеров — на самом деле мы говорим про согласование ожиданий и потребностей. Руководство говорит, что требования происходят из потребностей путем формальных преобразований, в этом и есть инженерный подход. При этом сами потребности не берутся из ниоткуда и не выдумываются, а тоже, в свою очередь, являются результатом формального преобразования некоторых концепций. Концепции в данном случае -- не просто идеи, а совершенно конкретные документы: концепция деятельности и концепция эксплуатации. Концепция деятельности (ConOps) — это стратегический документ, содержащий цели и миссию, а также стратегию их достижения (альтернатива ConOps - Стратегический бизнес-план). Это изложение деятельности с точки зрения стейкхолдеров. Концепция эксплуатации (Operational Concept, OpsCon), в свою очередь, описывает систему, которая реализует стратегию или её часть. То есть, это когда мы уже приняли решение, что у нас вот тут будет какая-то система, и описываем, как мы собираемся с ней работать. Уже из этой концепции мы, путем формальных преобразований, можем прийти к анализу потребностей и, наконец, к требованиям. Всё это звучит довольно заумно, но в Руководстве есть отличная история, живо показывающая всю цепочку (я прямо узнал все свои проекты, и вздрогнул, а также вспомнил анекдот про японскую бензопилу):

Привет! Если вы меня потеряли — я ушел в творческий отпуск :) Но совсем отключиться не получилось — буквально в чистом поле меня поймали организаторы подкаста FlowLive и записали со мной выпуск про создание образовательных продуктов для аналитиков: https://www.youtube.com/watch?v=wGGwncJSMcM (выходит завтра, поставьте колокольчик, чтобы не пропустить!). Поговорили про то, какие темы востребованы, и что главное в учебном курсе. Enjoy! Ну и жду вопросов и обсуждений 🙏🏻

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

Небольшой опрос: с какой проблемой вы сталкивались или сталкиваетесь сейчас в работе, но эта проблема не описана ни в одной книге или стандарте, и непонятно, как её решать? Напишите в комментах 👇

Попробовал на одной картинке показать — на каком уровне работают разные методы групповой работы по выявлению требований и идей — Impact mapping, User story mapping, Event Storming. Получилось похоже на водопад, но это не он. Тут скорее как в JBGE — максимум пара недель на начальное моделирование, а потом уже в цикле по итерациям, корректируя более высокие уровни. IM и ES как раз по несколько часов занимают.

Почему-то аналитики раньше были обделены митапами. У программистов они были, у UX-еров, у тестировщиков, а у аналитиков как-то не особо. А теперь — и сообщество созрело, и аналитиков стало больше, и задачи сложнее, и компании наконец поняли, в чем польза от аналитиков (это сейчас самая востребованная ИТ-профессия после программистов). Ну и после пандемийного безальтернативного онлайна пошёл откат — люди хотят встречаться вживую. И начались аналитические митапы! В Москве, а теперь и в Питере — можно прийти, посмотреть на коллег, задать вопросы и обменяться опытом 🙂 Ниже — объявление о первом митапе от команды системных аналитиков Тинькофф, а я, со своей стороны, хочу обратить внимание на дискуссию про то, куда развиваться системному аналитику, если он уже очень сеньорный, но в менеджмент переходить не хочет. Есть ли рост после сеньора, куда, и правда ли это уже архитектор — это всё крайне интересные вопросы, которые меня очень волнуют в последнее время. Интересен взгляд изнутри крупной компании.

Ещё в 2013 году многим было уже понятно, что то, что мы называем "требованиями", на самом деле, конечно, никакие не требования, а зафиксированный результат совместных галлюцинаций предположений, или, как тут красиво сказано — креативных размышлений —пользователей, заказчика и аналитика о том, что было (rear-view), что будет, о том, как всё это выглядит, и что в принципе возможно. А результат работы, конечно — выдать клиенту в точности то, что ему нужно, но о чём он не задумывался и мечтать не мог.

Если вы затрудняетесь в оценке полезности вашего документа и его уровня JBGE (Just Barely Good Enough) — воспользуйтесь формулой CRUFT[1]: Полезность документа = C*R*U*F*T, где C — correct — доля корректной информации в документе, R — read — вероятность того, что документ вообще будут читать, U — understood — %% информации в документе, которую поймут его читатели, F — followed — шанс, что требованиям и указаниям, содержащиеся в документе, будут следовать, T — trusted — вероятность того, что документу будут доверять. Если по формуле у вас получаются низкие значения, то выходит не документ, а CRUFT, то есть "хлам" в переводе. Обратите внимание, что в формуле перемножаются вероятности, то есть ценность документа падает очень быстро (снижение каждого показателя на 20% приводит к итоговой общей ценности документа в районе 32%). Для оценки корректности и полноты требований в случае применения BRUF-подхода (Big Requirements Up Front, попытки разработки всех требований в начале проекта) можно взять 45% — средний показатель доли начальных требований, действительно реализованных в итоговом продукте (по данным Chaos Report). Соответственно, формула показывает и направления улучшений в ваших документах и процессах. [1] https://www.drdobbs.com/architecture-and-design/dr-dobbs-agile-modeling-newsletter/201001273

На тренингах мы часто говорим, что работа над требованиями — это кривая убывающей полезности: каждый следующий шаг детализации после какого-то предела уже не даёт серьезного прироста ценности. Но есть и более радикальный взгляд: продолжение работы после оптимального значения не просто приносит мало пользы, а даже вредит! И артефакты нужно делать JBGE: Just Barely Good Enough, не более того. А вы как думаете, в какой момент стоит остановиться?