Интересная картинка сравнения возможностей проприетарных и открытых моделей. По кодингу и умениям делать выводы GPT-4 пока впереди, а вот по написанию "просто текстов" и по гуманитарным вопросам Викуна уже практически сравнялась.

Ну и собственно самое главное.

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

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

Ну и минорное - авторы выпустили новые модели Vicuna v1.3 размерами от 7 до 33 миллиардов параметров. Веса забирать здесь.

ProductSense и Нетология выпустили очередное исследование про менеджеров продуктов, а так как я как раз он, любопытно было взглянуть на коллег и настроения в отрасли. Из интересного: 37 человек (из 1121) таки назвали себя Technical Product Manager, я уж думал их в РФ совсем нет. Вместе с Platform PM (11%) — это интересная смежная роль, куда могут переходить системные аналитики, если хотят больше влиять на развитие своих систем (в принципе, это похоже на мой карьерный путь).

Интересно, что 221 человек (20%!) сказали, что работают продактами в B2G. Не очень понимаю, они продакты сервисов для государства? То есть, их пользователи — это госслужащие и бюджетники? Или это разработчики гос.сервисов для граждан, типа, B2G2C? В любом случае, интересный процент, думал, это скорее экзотика. Мало того - чем "сеньорнее" продакт, тем больше вероятность, что он работает именно с B2G или с платформой. Типа, раз уж начали в это играть, то возьмем сразу крутых чуваков.

Интересный показатель -- размер компании. Почти половина всех продактов работает в крупных компаниях (от 1000 сотрудников, 28% — от 5000 сотрудников). Выглядит так, что в управление продуктом играют только те, кто может себе это позволить, а остальные как-то так обходятся. При этом в маленьких компаниях легче получить должность Head of Product или CPO (ну да, я в своё время просто попросил, чтобы должность называлась директор по продуктам, и так стал CPO 🤷🏼‍♂️).

По индустриям: банки, edTech, доставка еды и маркетплейсы. Именно в таком порядке! Даже не знаю, какой из этого сделать вывод. Как говорила Алиса у Кэрролла, наводит на мысли, только неясно, на какие. Ну, кроме того, что я классно выбираю отрасли: 10 лет в финтехе, и вот скоро будет 10 лет как в эдтехе, самый топ. Ну и можно представить себе, как человек берет кредит, тратит его на обучение, заказывает еду, чтобы не отрываться от просмотра видео, а потом распродает вещи, чтобы этот кредит вернуть. И идёт работать продактом, очевидно.

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

В общем, если нанимаете продактов или хотите стать продактом — рекомендую, любопытное чтение!

Если вы затрудняетесь в оценке полезности вашего документа и его уровня 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

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

А результат работы, конечно — выдать клиенту в точности то, что ему нужно, но о чём он не задумывался и мечтать не мог.

Почему-то аналитики раньше были обделены митапами. У программистов они были, у UX-еров, у тестировщиков, а у аналитиков как-то не особо.

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

Ну и после пандемийного безальтернативного онлайна пошёл откат — люди хотят встречаться вживую. И начались аналитические митапы! В Москве, а теперь и в Питере — можно прийти, посмотреть на коллег, задать вопросы и обменяться опытом 🙂

Ниже — объявление о первом митапе от команды системных аналитиков Тинькофф, а я, со своей стороны, хочу обратить внимание на дискуссию про то, куда развиваться системному аналитику, если он уже очень сеньорный, но в менеджмент переходить не хочет. Есть ли рост после сеньора, куда, и правда ли это уже архитектор — это всё крайне интересные вопросы, которые меня очень волнуют в последнее время. Интересен взгляд изнутри крупной компании.

Попробовал на одной картинке показать — на каком уровне работают разные методы групповой работы по выявлению требований и идей — Impact mapping, User story mapping, Event Storming.

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

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

Напишите в комментах 👇

Подвожу итоги опроса: многие написали про, как бы это правильно назвать — персональное развитие и управление собственным временем, знаниями и компетенциями. Как структурировать рабочий день? Как бороться с выгоранием и спадом мотивации? Как всё успевать и как при этом отдыхать? Как менеджерить самого себя, но не скатиться в микроменеджмент?

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

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

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

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

Если бы я попал на необитаемый остров, и мог бы взять с собой только одну книгу по системному анализу и разработке требований, я бы взял Руководство по написанию требований от INCOSE (Международный совет по системной инженерии). Что удивительно, это руководство есть в переводе на русский язык, я даже немного участвовал в его создании (настолько немного, что я не упомянут среди команды переводчиков и рецензентов).

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

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

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

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

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

Похожая ситуация с отделом снабжения. Его сотрудники знают своё дело — и в мельчайших подробностях! Сколько топоров ломается на кубометр поваленного леса (и сколько нужно закупить и доставить) известно. Но совершенно непонятно, как поддерживать работу новой бензопилой: что делать с топливом, смазкой, где всё это хранить, сколько запчастей и какие закупать, как часто. Как вообще узнать, что всё это нужно?

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

Летом в отпуске положено читать книги. Книг по системному анализу вообще мало. А художественных почти и нет. Но я неожиданно нашел! "Парк Юрского периода" - уже не помню, что там в фильме, а книга-то вся про системный анализ, с небольшими вкраплениями динозавров, просто для антуража.

Там же весь набор:
- эксперты не выдают ключевую информацию, потому что считают её несущественной/ошибочной/редким частным случаем (эксперты вообще склонны рассказывать про типовой опыт, а не про отклонения -- хотя именно отклонения и частные случаи "убьют" вашу систему. В книге про это тоже есть - "вы исследуете не систему, как она есть на самом деле, а систему, как вы её ожидали увидеть", говорит персонаж-математик);
- заказчики не выдают полной картины назначения и использования системы, а только частные ТЗ на отдельные модули - и пытаются из этого собрать работающую целостную систему, с предсказуемым результатом;
- потом те же заказчики требуют от программиста всё бесплатно доделать, и думают, что им за это ничего не будет;
- нанимают системного аналитика, а потом игнорируют его рекомендации - классика!
Отличный план для реализации сложной системы!

Какие ещё являения описаны очень жизненно:

во-первых, сочетания множества безобидных факторов, приводящих к катастрофе. Ну там: работы на центральном пульте управления, баг в управляющем контуре, одновременно с этим начинается гроза, одновременно с этим по каналам связи передается большой объем данных, одновременно с этим один сотрудник случайно пропустил нужный поворот, одновременно от ветра падает дерево... ну, понятно, заканчивается это тем, что кого-то съели. Я смотрел анализ крупных катастроф - они почти все были результатом сочетания многих факторов. Очень часто вмешивается природный или какой-то внешний фактор: ночь, дождь, туман, гроза, снегопад, или наоборот жара; повышение потребления, высокий трафик или наоборот - резкое падение... Мой однокурсник делал знаменитую пятерку новостей (ещё до закручивания гаек, когда всё было по-честному) - и рассказывал, что они очень быстро вычистили все часто встречающиеся ошибки - ну, вероятность которых больше 0,00001% - то есть, происходят на главной Яндекса по нескольку раз в день. Уже на вероятностях 0,001% это были сочетания трех-четырех маловероятных факторов. Дальше пошли сочетания 6-7 крайне маловероятных факторов - то есть, человек вообще про такие штуки редко думает, а уж представить, что будет при их сочетании заранее очень сложно. Между тем, в современных высоконагруженных системах такие события происходят гораздо чаще, чем мы ожидаем. В книге это очень достоверно показано.

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

в-третьих, создатель парка впадает в типичную ловушку всех визионеров: пытаться одновременно внедрить сразу несколько инноваций. Чувак, у тебя и так уже динозавры, чего ещё?! Но нет - ещё мы сделаем уникальную систему автоматического управления, чтобы людей поменьше нанимать, и впихнем в неё системы распознавания образов, автономные автомобили и сложный BI, завязанный на безопасность. Кто реально занимался сложными системами, знает железное правило: одно инновационное изменение за раз! Иначе будет невозможно локализовать проблему.

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

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

Так что приходите 4-5 сентября в онлайне и 11-12 сентября в офлайне — обсудим горячие темы системного анализа, а на моем выступлении — насколько профессия системного аналитика всё ещё про анализ, а не про проектирование (я считаю, что давно уже про проектирование, и анализ в чистом виде мало где встречается, вот только не все это окончательно осознали).

Встретимся на Flow!

Без юскейсов не построить физическую модель данных.

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

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

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

В Event Storming этой связке уделено специальное понятие: модель чтения. Помните -- результатом ES является "Картинка, которая объясняет всё". Это тот самый ответ на вопрос "какие данные нужны для того, чтобы пользователь принял решение и отдал команду, в результате исполнения которой произойдет событие". И, подумав о модели чтения, можно выбрать и подходящую форму хранения (может, вам вообще не реляционная база нужна, а графовая), и физическую модель определить.

Если вы хотите изучить новые слова и выражения на английском, попросите ChatGPT написать вам рекомендации для LinkedIn.

Мне пришлось через фразу лезть в оксфордский словарь! Хотел бы я знать, на каком курсе все эти фразы можно изучить (чтобы звучать, как нейтив). Я выделил курсивом слова и обороты, которые до этого, кажется, вообще нигде не встречал, ну или не придумал бы использовать в таком контексте:

"[Your Name] has consistently demonstrated a remarkable ability to seamlessly blend profound architectural insights with a visionary product perspective. Their unique aptitude for comprehending product strategies, UX design, and user satisfaction truly set them apart. With a keen eye for detail and a deep understanding of both technical and product domains, [bla-bla...] From understanding product strategy to UX design and user satisfaction, [Your Name] excels across the board. I want to highlight his unique ability to blend a deep understanding of software architecture with a product-centric vision, coupled with a knack for understanding user needs and designing intuitive user interfaces. I wholeheartedly recommend them for roles like Head of Product, where his expertise would undoubtedly shine."

Ну и если вам вдруг стало грустно, или вы почувствовали "синдром самозванца" -- почитайте хвалебную оду себе, насколько вы прекрасны! Всех с пятницей! 😜