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

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

Сегодня на Flow будем обсуждать ассессмент системных аналитиков, то есть оценку компетенций: самооценку, оценку коллег, оценку независимым центром и назначение оценки: внутренняя оценка в компании, независимая оценка "для себя", оценка перед подготовкой к интервью / новой работе...

А вы проходили оценку навыков? Как впечатления? Что думаете по этому поводу? Была ли польза? Видели какие-нибудь классные инструменты для оценивания?

Upd: что-то тема не вызывает отклика, вас что, на работе и при приеме не оценивают?!

Уфф, закончилась онлайн-часть Flow. Кстати, сегодня был community day, записи доступны бесплатно (после регистрации).

Я сам почти ничего не смог послушать — сначала вел интервью с Максимом Цепковым про DDD, и как обходиться на проекте без требований, а потом был экспертом на докладе Кати Гончаровой про применение AI инструментов в повседневной работе бизнес-аналитика (там ещё потом интересная дискуссия была).

Сейчас выдохну, и напишу своё резюме по всем докладам, есть интересные мысли.

Stay tuned!

Во-первых, хочу написать про доклад-иинтервью с Максимом Цепковым про DDD и работу без требований. Сам формат интересный, можно задать вопросы и направлять этим рассказ, а не идти в логике докладчика. Хотя 45 минут — это очень мало, понимаю теперь, почему у Дудя интервью по 2-3 часа длятся.

Что я вынес из разговора с Максом:

1️⃣ Словом требования называют разные по назначению сущности. Первая - это требования внешних стейкхолдеров, которые вообще-то не говорят о том, как система должна быть устроена внутри, а выражают некоторые пожелания или ограничения по её свойствам и возможностям. Вторая — требования как постановка задачи архитекторам и разработчикам, промежуточный артефакт внутри процесса производства ПО. То есть, бизнес-аналитики строят модель предметной области (бизнес-модель, модель использования системы, концепцию операций...) а системные аналитики и архитекторы строят модель самой системы. И заголовок интервью — про вторые требования, без них можно жить, если использовать единую модель. Забегая вперед, идея пересекается с моим докладом про скрытое проектирование, и с работами Пола Ральфа, который первый вид требований предлагает называть "desiderata", чтобы не путаться. Ну или попросту "хотелки" 😆

2️⃣ И вот если мы меняем способ общения между людьми внутри проекта, нам не нужен "переводчик" с языка заказчика на язык разработки, как часто называют аналитика. У нас общий язык! Ubiquitous language, одна из ключевых идей DDD. Не нужно фиксировать отдельно бизнес-требования, а отдельно их превращать в функциональные требования (спецификации), тексты в тексты. Нужно построить модель, которую поймут все - и заказчики, и разработчики, причем это должна быть одновременно модель бизнеса, и она же - модель системы.

3️⃣ Таким образом, DDD - это, в первую очередь, про способ общения, про коммуникацию между людьми. (Да что там, всё наше производство софта - это на 2/3 про коммуникацию - от сбора требований до проектирования архитектуры, развертывания и мониторинга.)

4️⃣ Соответственно, модель должна быть понятной и разработчикам, и стейкхолдерам. И тут нужно разделять модель и диаграмму - как некоторое представление модели (или одного из аспектов модели). Модель - формализованное упрощенное представление системы. Диаграмма или описание -- представление одного из аспектов модели (Максим показывал расположенные рядом диаграмму активности и диаграмму состояний - довольно наглядно, что на каком шаге происходит). Тут, конечно, бооольшой вопрос - как такую модель построить, и что это за средства и формализмы для её построения. В практике у нас тут в ИТ используются в подавляющем большинстве эвристические модели, то есть умозрительные - кто что придумал, как смог представить, так и ладно. Математических моделей у нас, как правило, нет. Пожалуй, единственная математически строго обоснованная модель -- это реляционная, да и то там есть проблема с 5НФ, которая на практике не решается чисто математически, без понимания бизнес-правил.

Тут подключился Денис Бесков, и мы немного поговорили про нотацию моделирования: у Макса в примерах UML, а Денис говорил про Event Storming. Я, со своей стороны, тоже склоняюсь к ES - и именно в контексте понимания - кажется, она гораздо лучше понимается и стейкхолдерами, и разработчиками, и содержит почти всё необходимое.

5️⃣ Имея единую модель системы, мы можем оценивать "хотелки" стейкхолдеров в отношении этой модели, не заглядывая в саму систему (если гарантировано, что система имплементирует именно эту модель). Так можно, а так нельзя, а вот это будет сложно сделать. Тут мы поговорили про нефункциональные требования (которые всё-таки внешние, зависят от сценариев использования, или, в широком смысле, от операционной концепции - см. ConOps и OpsCon). Про сценарии использования Максим таки проговорился, что они всё же есть, но "это просто текстовые описания" :) Вот тут, кстати, Event Storming дает фору, так как включает сценарии (через реакции актора на события).

6️⃣ Ограниченные контексты. Создать такую единую модель для всего предприятия, да и просто для большой системы - дело неподъемное. И на практике не нужное. DDD освобождает нас от необходимости объять необъятное, и разрешает строить изолированные модели для отдельных областей и думать больше о том, как их связать (и тут есть разные паттерны).

В общем, идея в создании единой модели и коммуникации вокруг неё, а не кучи разрозненных описаний и диаграмм, непонятно как связанных. Что мне очень нравится.

Что осталось за кадром, но о чем хочется ещё поговорить:
➡️ как, всё-таки, строить именно модель, а не отдельные диаграммы?
➡️ как научить стейкхолдеров читать модели и согласовывать именно их, а не многостраничные тексты (TAGRI, They Ain't Gonna Read It)
➡️ как работать с изменениями модели
➡️ как воплощать модель в код

Попробовал распознать запись дискуссии через гугл документы (запустил на телефоне и положил рядом с микрофоном). Получился бредок, но! ChatGPT это понимает и выдает нормальное summary.

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

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