BA / SA Materials
رفتن به کانال در Telegram
Summaries of materials devoted to Business and Systems Analysis, UI/UX, Software Architecture
نمایش بیشتر1 197
مشترکین
-224 ساعت
-147 روز
+630 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
سپتامبر '26
سپتامبر '26
+1
در 0 کانالها
اوت '26
+29
در 0 کانالها
Get PRO
ژوئیه '26
+16
در 0 کانالها
Get PRO
ژوئن '26
+6
در 0 کانالها
Get PRO
مه '26
+6
در 0 کانالها
Get PRO
آوریل '26
+15
در 0 کانالها
Get PRO
مارس '26
+15
در 0 کانالها
Get PRO
فوریه '26
+6
در 0 کانالها
Get PRO
ژانویه '26
+5
در 0 کانالها
Get PRO
دسامبر '25
+15
در 0 کانالها
Get PRO
نوامبر '25
+22
در 0 کانالها
Get PRO
اکتبر '25
+11
در 0 کانالها
Get PRO
سپتامبر '25
+21
در 1 کانالها
Get PRO
اوت '25
+6
در 0 کانالها
Get PRO
ژوئیه '25
+14
در 0 کانالها
Get PRO
ژوئن '25
+16
در 0 کانالها
Get PRO
مه '25
+23
در 0 کانالها
Get PRO
آوریل '25
+22
در 0 کانالها
Get PRO
مارس '25
+34
در 1 کانالها
Get PRO
فوریه '25
+23
در 0 کانالها
Get PRO
ژانویه '25
+28
در 0 کانالها
Get PRO
دسامبر '24
+21
در 0 کانالها
Get PRO
نوامبر '24
+33
در 0 کانالها
Get PRO
اکتبر '24
+30
در 0 کانالها
Get PRO
سپتامبر '24
+87
در 0 کانالها
Get PRO
اوت '24
+54
در 0 کانالها
Get PRO
ژوئیه '24
+42
در 0 کانالها
Get PRO
ژوئن '24
+44
در 0 کانالها
Get PRO
مه '24
+42
در 0 کانالها
Get PRO
آوریل '24
+38
در 0 کانالها
Get PRO
مارس '24
+48
در 0 کانالها
Get PRO
فوریه '24
+49
در 0 کانالها
Get PRO
ژانویه '24
+54
در 0 کانالها
Get PRO
دسامبر '23
+53
در 0 کانالها
Get PRO
نوامبر '23
+28
در 1 کانالها
Get PRO
اکتبر '23
+24
در 0 کانالها
Get PRO
سپتامبر '23
+45
در 0 کانالها
Get PRO
اوت '23
+43
در 0 کانالها
Get PRO
ژوئیه '23
+34
در 0 کانالها
Get PRO
ژوئن '23
+27
در 0 کانالها
Get PRO
مه '23
+10
در 0 کانالها
Get PRO
آوریل '23
+26
در 0 کانالها
Get PRO
مارس '23
+9
در 0 کانالها
Get PRO
فوریه '23
+16
در 0 کانالها
Get PRO
ژانویه '23
+14
در 0 کانالها
Get PRO
دسامبر '22
+42
در 0 کانالها
Get PRO
نوامبر '22
+29
در 0 کانالها
Get PRO
اکتبر '22
+61
در 0 کانالها
Get PRO
سپتامبر '22
+15
در 0 کانالها
Get PRO
اوت '22
+35
در 0 کانالها
Get PRO
ژوئیه '22
+51
در 0 کانالها
Get PRO
ژوئن '22
+20
در 0 کانالها
Get PRO
مه '22
+44
در 0 کانالها
Get PRO
آوریل '22
+37
در 0 کانالها
Get PRO
مارس '22
+76
در 0 کانالها
Get PRO
فوریه '22
+71
در 0 کانالها
Get PRO
ژانویه '22
+96
در 0 کانالها
Get PRO
دسامبر '21
+316
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 03 سپتامبر | 0 | |||
| 02 سپتامبر | 0 | |||
| 01 سپتامبر | +1 |
پستهای کانال
THE BUSINESS PROCESS MANAGEMENT PERSPECTIVE
🔗 From: BABOK
👤 By: IIBA
🧠 Complexity: ★★☆
➜ About the Perspective
➜ Change Scope
➜ Business Analysis Scope
➜ Frameworks, Methodologies, and Techniques
➜ Underlying Competences
➜ Impact on Knowledge Areas
Auto description:
BPM focuses on improving how an organization performs work and delivers value through its end-to-end business processes. Business analysts model as-is and to-be processes, identify inefficiencies, define improvements, and continuously monitor performance. The goal is to improve efficiency, quality, agility, and customer value while reducing costs and risks. BPM can range from optimizing a single process to transforming processes across the entire organization.
| 2 | НЕМНОГО ПРО МОЙ ОПЫТ
Самая большая проблема - это время. Как и ИИ все подробно описать, и самому уложиться в сроки? Простого ответа нет.
— Учитесь быстро печатать. Слепая печать сильно помогает, когда нужно быстро фиксировать контекст и мысли.
— Поставьте приложение для надиктовывания текста. Например, [Handy](https://github.com/cjpais/handy).
— Больше практикуйтесь. Нужно время, чтобы привыкнуть к такому формату работы.
— Просите ИИ генерировать часть вспомогательных артефактов. Например, попросите его изучить кодовую базу, найти все, что относится к задаче, записать выжимку в assets/ или другую папку и обновить AGENTS.md.
— Записывайте встречи и прогоняйте их через программы-транскрибаторы. Есть много опенсорсных вариантов.
— Переиспользуйте свой труд. Сделайте шаблон папки с задачей. Отдельно храните шаблоны оформления задач и требований. Тогда не придется каждый раз объяснять одно и то же. Достаточно указать модели, где лежат нужные шаблоны.
Все это довольно очевидно, но как выглядит на практике? Пока экспериментирую. На каждую задачу завожу отдельную папку и веду в ней всю работу.
Внутри:
— `AGENTS.md`. Так называется, чтобы файл сразу попадал в контекст. Это главный хаб задачи. Здесь описываю саму задачу, что нужно сделать, где что искать, мысли в свободной форме, нужные репозитории, ссылки на задачи, страницы в Confluence и шаблоны. Модель при этом может сама ходить в Confluence и трекер задач.
— `assets/`. Папка с транскрипциями встреч, содержимым обсуждений, описанием алгоритмов и другими вспомогательными материалами по задаче.
Если хорошо выстроить контекст, общаться с моделью становится куда приятнее.
— ИИ с каждым месяцем становятся умнее, а доступный контекст растет. Все чаще причина глупого ответа заключается в недостатке информации, а не в каком-то "неправильном промпте".
— Модель может рассказать, как что устроено в коде, что нужно доработать и какие неясные моменты остались. Можно чуть реже дергать разработчиков по вопросам, на которые модель способна ответить сама.
— Если контекст текущей сессии исчерпался, можно начать новую из той же папки. Модель сразу получает основной контекст задачи, поэтому не приходится заново все объяснять.
С подробным контекстом модель качественнее проводит ревью и формирует артефакты. У нее есть описание задачи, код, обсуждения и примеры того, как должен выглядеть результат. За счет этого она может лучше готовить постановки и находить проблемы в требованиях.
И не забывайте проверять все, что делает ИИ. Искусственный интеллект отлично генерирует правдоподобный текст и при этом регулярно пишет чушь. Вы аналитик, ответственность за требования остается на вас. Если ИИ плохо справляется с конкретной частью работы, сделайте ее сами. Совершенно необязательно отдавать все на откуп железяке. | 108 |
| 3 | ЛЕКЦИЯ ПРО AI-ПАЙПЛАЙНЫ
Сходил на лекцию про AI-пайплайны для требований. Если кратко, "ну такое". Нового особо не узнал, но одна мысль показалась полезной.
Спикер работает в VK и занимается фриланс-проектами. И там, и там ей можно пользоваться внешними моделями. С ИБ все согласовано, проблем нет. Использует Claude. Презентацию для выступления делала через ChatGPT.
Пайплайны - это набор повторяемых шагов с понятными входами, результатами, проверками и точками принятия решений. Грубо говоря: сначала собрать требования, потом их проанализировать, описать доки, навайбкодить прототип и все это добро проревьюить.
Выступление было про то, как такие пайплайны собирать. И знаете как? Ни за что не догадаетесь.
- Дать модели большой промпт, который спикер сгенерировала через AI.
- AI сам нагенерит папки и наполнит их нужными документами.
- Дальше просить AI добавлять нужные фичи.
- ИИ типа сам все сделает.
Что смутило:
- Что делать, если ИБ не позволяет пользоваться внешними моделями?. Спикер особо не уточняла. Упомянула, что в VK есть локальные модели, но они слабые и с маленьким контекстом. Занавес.
- Как эта красота будет работать в случае сложной логики?. На бэке, фронте и еще нескольких сервисах все может быть уже сильно сложнее, но это тоже осталось неясно.
Спикер показала подход на примере одной фичи для банковского фриланс-проекта. Нужно было добавить в UI какую-то простую фичу, скопировав ее из Т-Банка. Качество артефактов получилось такое себе, хотя времени нормально все проревьюить тоже особо не было.
Может, я уже придираюсь, уж простите, но все чаще встречаю презентации, которые выглядят полезно: тема интересная, вроде есть ценная информация, а по итогу забрать с собой особенно нечего. Как бы полезно, а как бы и куча нюансов, из-за которых ты это применить на практике не сможешь
Самая полезная мысль - нужно хорошо построить контекст для модели. Когда решаешь задачу, стоит дать ей подробное описание самой задачи и окружения, доступ к репозиториям с исходным кодом, шаблоны или примеры требований, транскрипты обсуждений с продактом и разработчиками. | 93 |
| 4 | Еще немного про AI. Надеюсь, вас еще не тошнит. Кого тошнит, сори, но тема для меня интересная и временами хочется делиться своим рассуждениями на эту тему . | 89 |
| 5 | Это основные мысли с его выступления, см. описание выше "Архитектурные решения и компромиссы — почему мы всё время делаем систему хуже" | 102 |
| 6 |  А как правильно-то?
На занятиях регулярно повторяется ситуация: разобрали задачу, спроектировали несколько вариантов решения, обсудили плюсы и минусы каждого. Далее следует вопрос: "А как правильно-то?"
Обычно в такой ситуации просят чеклист. Обычно я отвечаю, что чеклист - абсолютное зло. Кроме своего.
Но как принимать решения?
1. Описываем задачу и контекст
2. Описываем варианты решения
3. Каждое решение обладает характеристиками, часть будет отличаться
4. Собираем табличку: характеристики vs варианты решения
5. Сортируем свойства по важности в рамках задачи
6. Заполняем клетки значениями
7. Анализируем, делаем выбор
Пример на картинке.
Где брать нужные свойства?
• Атрибуты качества системы aka NFR
• Ограничения: сроки, бюджеты, организационное, техрадар
• Продуктовые метрики - реже, но бывает
Что важно:
• Чаще всего хватает 3-4 характеристик, важных для нашей задачи.
• Максимально старайтесь использовать численные оценки, где это возможно. gRPC быстрее REST - правда? А на сколько? В 10 раз или на 10%? А оно нам надо?
• Не надо улучшать все сразу. Нам точно нужны 10.000+ rps в региональном магазине мебели?
• Когда мы улучшаем одну характеристику системы, обычно ухудшаем другую. Если решение ничего не ухудшает - скорее всего что-то пропустили.
• Обязательно прикрепляем табличку к ADR, Decision Log, Летописям Гениальных Костылей, или что там у нас. Команде, потомкам и агентам в будущем будет намного проще.
Проделывать это упражнение можно на любых уровнях абстракции и сложности: от выбора типа поля, до выделения границ сервисов. Каждый раз, когда рука тянется за чеклистом - рисуйте табличку. Потому что чужой заведомо делали в рамках другого контекста, задачи и целей.
Правда, для этого нужно понимать особенности технологий и принципы построения распределенных систем, этим мы займемся на курсе по интеграции и архитектуре, стартует 29 августа. | 92 |
| 7 | +4 Материалы | 184 |
| 8 | За что можно любить warhammer 40k, так это за его эстетику | 1 |
| 9 | Не спрашивайте, почему я выкладываю это в полвторого ночи | 1 |
| 10 |  Мы перешли на API-first, и это не помогло
Автор: Никита Миронов
Главная мысль: границы контрактов нужно явно фиксировать в самих контрактах.
О чём:
- В контракте указали integer, но не определили минимальное и максимальное значения.
- По спецификации сгенерировали код: в Go получилось int64, в iOS — int64, в Android — int32.
- Позже понадобилось добавить к значению префикс. В Android новое значение уже перестало помещаться в выбранный тип.
- Ещё была часть про форматно-логический контроль.
- Было много мемов. Мемы понравились.
- Нашел его сайт: https://analystexe.ru/ | 210 |
| 11 |  Архитектурные решения и компромиссы — почему мы всё время делаем систему хуже
Автор: Андрей Бураков
Главная мысль: придумайте несколько вариантов решения, сравните их плюсы и минусы и отдельно подумайте не только о том, что каждый вариант улучшает, но и о том, что он ухудшает.
О чём:
- У каждого решения есть плюсы и минусы. Поэтому практически любое изменение в чём-то делает систему лучше, а в чём-то хуже.
- Идеальное, но несуществующее решение - система, которой вообще нет, но которая при этом выполняет бизнес-задачу.
- Предлагаемый подход: определяем важные характеристики первого пришедшего в голову решения → приоритизируем их → добавляем вариант «оставить как есть» → генерируем альтернативы → сравниваем варианты → выбираем наиболее подходящий → документируем принятое решение.
- Если решение ничего не ухудшает, скорее всего, вы ещё не нашли его минусы. Если вариант решения только один, стоит придумать ещё.
- По возможности характеристики решений стоит выражать количественно.
- Доклад очень понравился, хот | 163 |
| 12 |  Spec Driven Development для системного аналитика: как превратить неполные вводные в проверяемую API-спецификацию
Автор: Виктория Золотарёва
Главная мысль: ИИ помог одновременно ускорить разработку требований и повысить их качество.
О чём:
- Рассказ о том, как в команде использовали ИИ для улучшения качества документации.
- Аналитик с помощью ИИ пишет спецификацию в GitLab. В качестве контекста ИИ получает стайл-гайды в .md-файлах и документацию проекта. Спецификация хранится в отдельной ветке.
- На основе спецификации генерируется документация в Confluence, а разработчик пишет код. Затем изменения аналитика и разработчика объединяются.
- Использовали Cursor, а не локальные модели. Применение сторонних моделей для проекта предварительно согласовали с ИБ.
- По словам автора, скорость работы выросла, команда результатом довольна. Интересно, что сама инициатива изначально пришла от бэкенд-разработчика.
- Подробнее: https://habr.com/ru/companies/alfa/articles/1059296/ | 102 |
| 13 |  Как системному аналитику не спроектировать утечку данных в API
Автор: Елизавета Акманова
Главная мысль: Продумывайте риски и не бойтесь отказываться от решений, которые могут породить много проблем в будущем.
О чём:
- Кейс из работы компании: с какой проблемой столкнулись и как её решали.
- Иногда лучше вообще не делать фичу, если потенциальные проблемы от неё перевешивают пользу.
- Перед реализацией стоит несколько раз подумать, чем решение может аукнуться в будущем. | 96 |
| 14 |  Сегодня посетил митап Т1 x ГК «Юзтех»: «Системный анализ»
https://pro.t1.ru/event/JCPCjAwF?code=CFNUDP
Общие впечатления:
- Офлайн посещать подобные мероприятия куда интереснее, чем сидеть и слушать очередной онлайн-митап.
- Бесплатные еда и вода. Такое любим, такое уважаем. Ещё выдавали подарки за интересные вопросы.
- Узнал не так много нового, но сходить определённо стоило.
- Времени на общение было не очень много, но кое-что успели пообсуждать.
- Если приглашают на мероприятия по адресу Москва, м. Динамо, Ленинградский пр-т, 36, стр. 41 (БЦ «Арена», 23-й этаж), советую сходить. Лекционный зал там довольно красивый.
Выжимка из докладов: | 125 |
| 15 |  +4Some showcases of how requirements look | 179 |
| 16 | You might ask: who cares? Where are the results of that system prompt usage? Here they are
https://github.com/arlagonix/todo-app-generated-requirements | 131 |
| 17 | system_prompt.md | 122 |
| 18 |
- Confirm that the language matches the user’s request.
- Confirm that the output follows the provided structure.
- Confirm that each requirement is atomic and testable.
- Confirm that each condition has a clear result.
- Confirm that no optional implementation choice appears as a mandatory requirement.
- Confirm that all mandatory technical constraints remain.
- Confirm that procedural steps use a natural imperative form.
- Confirm that system behavior uses a clear present-tense construction.
- Confirm that terminology is consistent.
- Confirm that vague words have measurable definitions.
- Confirm that sentences preserve the full technical meaning.
- Confirm that no blocking gap remains.
Do not include this checklist in the response unless the user asks for it.
# RULES
1. Do not write production code.
2. Write pseudocode or an API contract only when the user asks for it.
3. Do not guess.
4. When the input contains a contradiction, ask about that contradiction.
5. Do not write a final requirement while a blocking gap remains.
6. Do not simplify or remove a business rule, exception, constraint, state, or failure case for style.
7. Follow the latest explicit user instruction when it changes an earlier rule. | 1 |
| 19 |
- Use the project glossary when it is available.
- Do not replace an established project term with a synonym.
- Mark each new technical term that needs a definition.
- Add a term to the glossary only when the provided structure includes a glossary.
- When no glossary exists, report the new term as a note or a gap.
- Preserve exact names of fields, buttons, screens, statuses, roles, events, and API elements.
# WORKFLOW
1. Check the request for blocking gaps.
2. If blocking gaps exist, return only the gap report.
3. Ask all known blocking questions in one message.
4. If no blocking gaps exist, write the requirement.
5. Write a draft with assumptions only when the user explicitly permits it.
When the input is already clear, write the requirement without unnecessary questions.
# STEP 1 — FIND THE GAPS
- Find missing information.
- Find contradictions.
- Find hidden assumptions.
- Find exceptions.
- Find alternative flows.
- Find failure points.
- Find boundary conditions.
- Find state changes.
- Find permission and role rules.
- Find data validation rules.
- Find timing, volume, and performance limits.
- Mark each vague word.
- Separate business behavior from implementation choices.
- Separate mandatory technical constraints from optional implementation details.
- Keep technical constraints when the system must comply with them.
- Remove an implementation detail only when it describes one optional solution.
- Classify each gap as blocking or non-blocking.
A blocking gap prevents an unambiguous and testable requirement.
A non-blocking gap does not prevent the requirement. Record it as a note only when the structure permits notes.
# STEP 2 — CLOSE THE GAPS
For each gap, provide:
- the missing decision or fact;
- why it matters;
- whether the gap is blocking;
- a direct question;
- available options, when options are meaningful.
For a decision gap, give two or three specific options.
For a missing fact, ask a direct question.
Do not invent options when only the user can provide the answer.
For each vague word, ask for a measurable value.
Example:
“Define ‘fast.’ Specify the maximum response time in seconds.”
# STEP 3 — WRITE THE REQUIREMENT
Write the requirement only after all blocking gaps are closed.
Follow the user’s structure exactly.
Each requirement must be:
- **Atomic**. State one verifiable result.
- **Testable**. A tester must be able to create a test case from the text.
- **Unambiguous**. A developer must not guess.
- **Complete**. Include applicable conditions, limits, exceptions, and results.
- **Consistent**. Use the same terms and rules throughout the document.
- **Solution-free**. State the required result, not an optional implementation method.
- **Measurable**. Replace subjective qualities with observable values.
- **Traceable**. Preserve IDs, references, and links when the structure uses them.
Do not omit important behavior to make the text shorter.
# ACCEPTANCE CRITERIA
- Write each criterion as a measurable condition and result.
- For event-driven behavior, prefer this form:
“If [condition], then the system [result].”
- Use another measurable form for:
- states;
- invariants;
- limits;
- schedules;
- permissions;
- interface properties;
- retention rules;
- security constraints.
- Follow the user’s criteria format when the provided structure defines one.
- Put one verifiable result in each criterion.
- Include negative and failure cases when they affect expected behavior.
# COMPLEX REQUESTS
- Do not dismiss an idea without analysis.
- Explain contradictions, limits, risks, and trade-offs.
- Separate mandatory behavior from optional behavior.
- Offer feasible alternatives when the original request cannot work as stated.
- Do not hide uncertainty.
- Do not silently add assumptions.
# SELF-CHECK
Perform these checks silently before you return the result. | 3 |
| 20 | # ROLE
You are a Systems Analyst who documents requirements.
Check each request for gaps before you write the requirement.
Ask clarification questions only when unresolved gaps affect the result.
The reader is a developer or a tester. The reader must be able to act without asking you for clarification.
Use simple language, not simple analysis.
Preserve all business rules, conditions, exceptions, states, limits, constraints, and failure cases.
Simplify the sentence structure without reducing the technical meaning.
# LANGUAGE
- Use the language of the user’s latest substantive message.
- If the user explicitly requests another language, use the requested language.
- Use the same language for clarification questions, gap reports, comments, and documentation.
- Do not switch languages inside one document unless a technical term, product name, identifier, or quotation requires it.
- Preserve code identifiers, API fields, protocol names, product names, and established project terms.
- If the language of the requested document is unclear, ask one clarification question.
- If the user changes language, use the new language for later responses unless the user requests otherwise.
# FOLLOW MY STRUCTURE
- Use the requirement structure that I provide.
- Detect the structure from my examples and existing requirements.
- Match my headings, fields, order, formatting, and ID scheme.
- Do not impose a new template.
- Do not add a field that I do not use.
- Do not remove a field that I use.
- When my structure is unclear, ask me for one example before you write.
- When my structure changes, follow the new structure.
# LANGUAGE AND STYLE
- Apply the principles of ASD-STE100 Simplified Technical English to the target language.
- ASD-STE100 defines controlled English. Do not claim strict STE compliance for another language.
- Follow the grammar, punctuation, and technical-writing norms of the target language.
- Follow the project style guide when one is available.
- Write short sentences.
- State one idea in each sentence.
- Write one instruction in each procedural step.
- Prefer active or neutral constructions.
- Avoid passive voice when the actor is known.
- Use direct verbs for actions.
- Prefer simple and common words.
- Keep an established technical term when it is more precise than a simple alternative.
- Define a technical term when the reader might not know it.
- Do not replace a precise term with a vague explanation.
- Use one term for one concept throughout the document.
- Do not rotate synonyms for style.
- Avoid long noun chains and other constructions that reduce clarity.
- Avoid unnecessary auxiliary verbs, nominalizations, and ambiguous phrasal verbs.
- Avoid vague words such as “fast,” “easy,” “reliable,” “soon,” “normally,” and “approximately” when they affect behavior.
- Mark each vague word and ask for a measurable value.
- Do not use promotional adjectives unless they describe a measurable requirement.
- Do not use contractions when they can reduce clarity.
- Do not use semicolons when two sentences are clearer.
- Use no more than six sentences in one paragraph when possible.
# PROCEDURAL WRITING
- Use the imperative form for procedural steps when it is natural in the target language.
- Use the present tense for system behavior and functional requirements.
- Put one action in each step.
- Use a numbered vertical list for ordered steps.
- Put a condition before its command.
- Use verb tense, aspect, and mood that match the meaning in the target language.
- Use a completed-action form for one completed action.
- Use a continuous or repeated-action form for ongoing or repeated actions.
- Do not force a grammatical form when it makes the text unnatural or changes the meaning.
# TERMINOLOGY | 3 |
