Командообразование AI
Статистика▪️Управление собой и людьми https://dnkpersone.bitrix24site.ru/ ▪️Исследования эффективных методов принятия решений ▪️Стратегическое управление и создание организационной культуры для реализации бизнес идей По вопросам сотрудничества @womentechpro
- Последний пост
- 13 авг.
- Последнее чтение
- 15 авг.
- Постов за неделю
- 4
- Всего постов
- 54
- Тип
- открытый
- Язык
- русский
- Категория
- Бизнес
- В каталоге с
- 12 авг.
- 1/24сутки в ленте
- 11
- 1/48двое суток
- 12
- 1/72трое суток
- 13
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
«ИИ пишем, облака в уме»: что нужно знать про IaaS и SaaS на российском рынке ссылка на полную статью подготовлена на основе предыдущего поста IaaS(Infrastructure as a Service, «инфраструктура как услуга») и SaaS(Software as a Service, «программное обеспечение как услуга») — это две разные модели облачных сервисов. Разница между ними — в том,что именно вы получаете от провайдера и за что сами отвечаете. 📖 Главное отличие простыми словами 🟡IaaS — это «железо» в аренду. Вы получаете виртуальные серверы, хранилища, сети и сами на них всё настраиваете. 🟡SaaS — это готовая программа в браузере. Вы просто пользуетесь приложением, а провайдер сам обо всём заботится. Без понимания облачной "кухни" амбициозные ИИ-задачи рискуют упереться в потолок — не хватит ни мощностей, ни рук. Итоговый вывод "ИИ“ пишем, облака в умe" — это отражение новой бизнес-логики: Цель (Пишем): Внедрить ИИ, чтобы стать эффективнее, быстрее и умнее конкурентов. Это то, что фиксируется в планах и KPI. Инструмент (В уме): Понимать, что без масштабируемой, гибкой и мощной облачной инфраструктуры (IaaS, GPU) этот ИИ не запустить. Облака стали «невидимым» фундаментом для ИИ-проектов. Но кто будет всё это настраивать? И вот тут всплывает другая проблема…
видео или голосовое, без подписи
«ИИ» пишем, облака в уме Анализ представленных материалов позволяет выделить несколько ключевых повесток, определяющих текущее состояние и будущее российского ИТ-рынка, с акцентом на облачную инфраструктуру (IaaS) и искусственный интеллект. 1️⃣ Динамика и прогноз рынка IaaS . Объем рынка: В 2025 году объем рынка IaaS (рыночная выручка) составил 96 млрд рублей, продемонстрировав рост на 28% . Прогноз до 2030 года: Ожидается, что к 2030 году рынок увеличится до 241 млрд рублей . Темпы роста: Среднегодовой темп роста (CAGR) в период 2025–2030 гг. прогнозируется на уровне 20% . Общий объем с учетом внутригрупповых расчетов: В 2025 году суммарный объем (включая потребление внутри холдингов) достиг 124 млрд рублей . 2️⃣ Взрывной спрос на инфраструктуру для ИИ (GPU) Искусственный интеллект (AI) и машинное обучение (ML) стали главными драйверами потребления ресурсов. Спрос на GPU: За первую половину 2026 года потребление облачной GPU-инфраструктуры выросло на 507% год к году . Инвестиции в ИИ: 42% компаний планируют увеличить расходы именно на внедрение AI/ML-решений . GPU-инстансы: 24% компаний зафиксировали резкий рост использования GPU-инстансов в 2025 году . Стоимость: Средний чек на GPU-серверы для задач ИИ к лету 2026 года вырос на 64%, достигнув 2,3 млн рублей . 3️⃣ Отраслевая специфика и портрет заказчика Наиболее активно облачные технологии внедряют крупные предприятия и определенные сектора экономики. Лидирующие отрасли по доле спроса: 🟡TMT (Телеком, Медиа, Технологии) — 33% 🟡Оптовая и розничная торговля (Ритейл) — 20% 🟡Финансовый сектор — 14% 🟡Промышленный сектор — 14% 🟡Государственный сектор — 11% Распределение по размеру бизнеса: Основную долю рынка занимает крупный бизнес (52%) и сегмент Enterprise (20%) На средний бизнес приходится 18%, на малый — 10% Расходы: Средние ежемесячные расходы крупных компаний на облака составляют 10–15 млн рублей, в то время как малый бизнес тратит 15–25 тыс. рублей 4️⃣ Ситуация с ИТ-кадрами Рынок труда характеризуется парадоксальным сочетанием роста числа специалистов и дефицита критически важных компетенций. Приток специалистов: В 2025 году на рынок вышло около 320–350 тыс. новых специалистов . Сокращение вакансий: При этом количество открытых вакансий сократилось на 29% (до ~505 тыс.) . Дефицитные направления: Несмотря на общую конкуренцию, сохраняется острый дефицит в DevOps, SRE , а также AI/ML-экспертов (58%) и системных архитекторов (42%) . Риски для бизнеса: 49% руководителей называют дефицит специалистов главным риском для цифровизации на ближайшие два года . Рост числа компаний: В первом полугодии 2026 года количество ИТ-компаний и ИП выросло на 64% (создано ~37 тыс. новых юрлиц), что часто связано с переходом команд на аутсорсинг и использованием ИИ для снижения порога входа в разработку . 5️⃣ Технологические тренды и импортозамещение 💛Гибридные облака: Использование гибридной инфраструктуры стало нормой для 52% компаний 💛Cloud-native: 35% компаний используют Kubernetes и инструменты оркестрации 💛Импортозамещение: 22% компаний начали активно использовать российские облачные платформы в 2022–2023 годах на фоне ухода зарубежных провайдеров . P.s: источники в канале https://t.me/selectel_IR или по ссылке я просто собрала основную повестку за пару месяцев о рынке IaaS
Философствую про амбиции и внутренний мир человека «кто я для себя, когда мир молчит?». Ха ИИ говорит что Шопенгауэр называл это побуждением воли. Отлично пусть будет так, значит я дозрела. О чем говорила? ➡️ Про «проглоченные амбиции» как масло для часов. Масло не видно снаружи, но именно оно не даёт механизму заржаветь. В юности амбиции — это пена, шум, фейерверк. В зрелости — это внутреннее давление, которое превращается в дисциплину. ➡️ Скука — это не враг, а сигнал навигатора, что сбились с курса и пытаетесь заполнить пустоту чужими целями. Принять скуку — значит сказать себе: «Здесь и сейчас мне ничего не нужно доказывать. Что я хочу сделать для себя в этой тишине? Когда перестаёте искать зрителя, наконец начинаете действовать чисто: ради самого процесса, ради изменения своей внутренней структуры, а не ради аплодисментов. Вывод про амбиции: Думаю человек без амбиций либо дозрел (амбиции внутри, тишина, глубокая работа над собой). Либо мертв при жизни (отсутствие амбиций = остановка развития).
отсылка о чем говорю https://buildin.ai/share/31dfbab0-c41d-4283-b532-ea6360f932e0?code=221TVV Тезисы: 1️⃣Суть роли бизнес-аналитика (БА): Это не просто работа с данными, а повышение общей информационной грамотности команды. БА учит коллег, делегирует рутину и, главное, умеет убеждать и доносить смысл до собственника, чтобы принимать верные решения. Без навыков убеждения он превращается в бесполезного бюрократа. 2️⃣ Проблема стандартов: классические алгоритмы сбора требований (из книг по ПО) не подходят для MVP и стартапов. Существуют три основных СТАНДАРТА (продуктовый, международный, ГОСТ), и задача БА — гибко комбинировать инструменты из разных подходов, а не слепо следовать одному. Международный стандарт ISO/IEC/IEEE 29148. Тем не менее структура IEEE 830 остается самой популярной и часто используемой в ИТ-индустрии благодаря своей простоте и логичности. Как я поняла, требования ( формирование их) к ПО, веб версиям ( их обычно сейчас делают на вайбкоде) и SaaS отличаются. Для SaaS-продуктов этот документ чаще всего называют PRD (Product Requirement Document). Нашла случайно скилл для ИИ ( промт ) __ 3️⃣Моделирование как слоеный пирог: Моделирование нужно не только на уровне ПО, но и на продуктовом, и архитектурном уровнях. Важно моделировать перед созданием системы, но это бесполезно без живого общения с заказчиком. 4️⃣Вызовы ИИ (Вайб-кодеры): При разработке через ИИ мы теряем видимость внутренней архитектуры и связей. Решение — использовать ИИ скиллы (например, MCP) для автоматической генерации диаграмм по коду, чтобы БА мог видеть эти связи и находить «дыры» в процессах. 🗃️ Инструменты для анализа кода и генерации диаграмм: 💛diagramify-ai: Анализирует твой код и генерирует Mermaid-диаграммы архитектуры, включая интерактивный HTMLhttps://www.np mjs.com/package/diagramify-ai Работает через CLI или как скилл для Claude Code. 💛repo-cartographer: MCP-сервер, который сканирует репозиторий и на его основе генерирует архитектурную диаграмму в Mermaid формате за 60 секунд https://www.npmjs.com/package/repo-cartographer. 💛RepoLens: Агентная ИИ-система, которая может ответить на вопросы об архитектуре и сгенерировать Mermaid-диаграммы по запросуhttps://github.com/Mmagdy908/RepoLens. ➡️ Расширенные возможности для рисования: 💛drawio-skill: Управлять визуалом профессионально. Оно работает с .drawio форматом, поддерживает 10 000+ официальных иконок, автолейаут (через Graphviz) и может строить диаграммы по описанию на естественном языке. Есть даже команды для импорта из кода (Python, JS/TS, Go, Rust) https://github.com/Agents365-ai/drawio-skill/blob/main/README.mdhttps://github.com/developeryogix-debug/drawio-skill. 💛mcp-uml-diagram: MCP-сервер, который генерирует 14 типов UML-диаграмм (включая классы, последовательности, компоненты) прямо из кода, используя AST и LLM для сложных случаев https://github.com/techdeveloper-org/mcp-uml-diagram.
читаю книгу «Учиться самому легко. Система быстрого усвоение новой информации» Она короткая на 3,5 часа. Там методики обсуждаются работы с инфой в каждой главе. Скорочтение это конечно особый вид мышления. Читать информацию глазами, охватывать куски, понимать ее не вникая в детали, а вытаскивать чистую суть (понимать определение слова) и конструировать внутри себя картину мира. пример. Допустим, у нас есть исходное предложение из вашей книги: «Для того чтобы эффективно применять методику быстрого усвоения информации, необходимо в первую очередь избавиться от привычки проговаривать текст про себя и научиться воспринимать строку целиком, как единый графический образ.» Как читает обычный человек (линейно, 100% слов): Читает всё подряд, спотыкаясь на союзах и предлогах. Мозг тратит время на проговаривание. Как читает скорочтенец (выбрасывает "мусор"): Оставляет только смысловые якоря (существительные, глаголы, ключевые прилагательные). Остальное — это связки, которые мозг достраивает сам Новый текст (сжатый до сути): «Эффективно применять методику — избавиться от проговаривания, воспринимать строку образом.» Еще жестче (чистая суть): «Скорочтение = отказ от речи + охват строки.» Есть 4 вида чтения, обработки инфы. Думаю про читать 1 книгу в день, это как раз про вторичную обработку данных, их 4. Скорость чтения увеличивается моментально. Сами попробуйте не читать про себя. Есть тесты онлайн скорость чтения слов в минуту и понимания их. Это вам тоже нужно знать: • на третьем году обучения ребенок читает по 150 слов в минуту; • на восьмом году – 250 слов; • средний взрослый человек – 300 слов; • средний студен вуза – 450 слов; • средний руководитель предприятия – 575 слов; • средний преподаватель вуза – читает 675 слов в минуту. На скрине метод чтения книги.
#новости Yandex B2B Tech анонсировала нового ИИ-агента для бизнеса. Его главная особенность — универсальность: он поможет снять часть нагрузки с менеджеров, аналитиков, бухгалтеров, маркетологов, специалистов по закупкам и не только. ИИ-помощник способен выполнять от 30 до 50% задач офисных сотрудников, на которые уходит до трети рабочего времени. Универсальный агент будет работать на базе технологий Yandex AI Studio. Планируется, что он выйдет до конца сентября 2026 года. Подробнее
видео или голосовое, без подписи
Задумалась о самоучении. Думаю успех человека измеряется в его успеваемости. Если откатиться назад в школьные годы, то на какие оценки он там учился и по каким предметам. Ранее нас окружали прикладные дисциплины, и точные. Думаю они и заложили всю основу умение работать с информацией и иметь те результаты, которые имеем. То есть школа дает навык осваивать информацию. Троешники похожи на тех кто мимо проходил, прочитал по диагонали, ухватил суть и побежал дальше. А может обобщил, вырвал суть, но не вник. Читаю книгу « Учиться самому легко. Система быстрого усвоение информации» Зацепила мысль: А ведь правда, все области деятельности, по сути, можно отнести либо к искусству, либо к науке. И разница между ними не только в названиях. В искусствах нет правильных и неправильных ответов. Важна точка зрения. Можно научить правильно держать кисть или настраивать камеру, но чтобы создать настоящую работу — не обязательно следовать строгим правилам. Искусство вызывает переживания, а переживания у всех свои. Поэтому и преподают его по-разному: каждый учитель привносит что-то своё. Без чётких ориентиров самоучке здесь сложнее. А в точных науках всё иначе. Скорость света — одна, дважды два — четыре, и это не обсуждается. Учитель не может изменить истину — он может только передать её. Именно поэтому науки предсказуемы и легче поддаются самостоятельному изучению. Ты всегда знаешь, куда двигаться, и можешь проверить себя по фактам. Так что, если вы решите освоить что-то новое без учителя — сперва оцените: это искусство или наука? От ответа зависит, насколько гладко пройдёт путь. А у вас в школе какие предметы давались легче — точные или прикладные?
О создании системы (продукта). Анализирую сервисы речевой аналитики на своей практике. В разработке не все нужно вытаскивать наружу , возможно детали нужно обобщить и показать пользователю только конечный элемент, а детали хоть они и важные для системы (фичи крутые) вобрать в себя и построить из них что-то целостное и концептуальное. Иначе может получиться нечто многоугольноформатное ИЗПОДВЫПОДВЕРТА.
Заметили ТРЕНД в консалтинге в нише продажах? Это речевая ИИ АНАЛИТИКА. Я уже третий проект вижу можно сказать один и тот же, но со своими нюансами. Смысл проекта в том что ИИ анализирует звонки иии .. вот тут то на что способен, образован, опытен, дозрел. В целом они мыслят в одном направлении, делают одно почти и тоже, но рынок займут не все из-за как вы думаете чего? Мне всегда вспоминается кейс на этот счет доски МИРО. " На начальном этапе развития RealtimeBoard (RTB) команда столкнулась с серьёзной проблемой — отсутствием опыта в создании технологического сервиса. Отсутствие экспертизы в области разработки привело к тому, что первые шаги давались с большим трудом. Каждый новый функционал требовал значительных временных затрат и тщательного продумывания всех технических деталей. Остро ощущалась необходимость в обучении, и компания направила существенные ресурсы на развитие своих сотрудников. За первые несколько лет на их обучение и повышение квалификации было потрачено около 100 тысяч долларов. Эти инвестиции в человеческий капитал оказались необходимыми для преодоления технологического барьера и формирования команды, способной создать масштабируемый продукт." Да я не просто так говорю про архитектуру, которая сыпается и про серьезность проекта. Сейчас пока нет, но скоро да, начнут кусать пирог. Они пока все учатся приспосабливать ИИ в колл-центр. Мне реально интересно узнать права ли я на счет моделирование ( статьи выше) или нет, у разработчика, кто в итоге откусит этот пирог.
Три уровня моделирования: почему архитектура ломается даже при правильных приоритетах В прошлых постах мы разобрали, что приоритеты не спасают, если нет модели. Теперь — ключевой вопрос: как именно моделировать, чтобы не пропустить ни одного уровня? Представьте, что вы строите дом. Вы не начнёте с крыши. Сначала — фундамент, потом стены, потом крыша. С программными системами — то же самое. 📣 Три уровня моделирования — это три этажа, и прыгать между ними нельзя. Представьте три уровня моделирования: 🟡BPMN — для того, чтобы понять заказчика (бизнес-процесс). 🟡UML — для того, чтобы спроектировать систему (объекты и взаимодействия). 🟡ERD — для того, чтобы правильно хранить данные (база данных). Если пропускаете первый уровень — не поймёте заказчика. Если пропускаете второй — будет кривая архитектура. Если пропускаете третий — упадёт производительность и потеряются данные. Моделирование — это лестница. Нельзя прыгать с первого этажа на третий. 💛 полный текст 💛 накидала план на 30 дней по внедрению ИИ в бизнес
ПРО НАВЫКИ ближ 20 лет. Если проследить эволюцию, то изначально успех и выживание определялись физической силой. Потом эпоха сместилась в сторону интеллекта — нужно было быть самым умным, чтобы быть востребованным. Но сейчас мы живём в мире, где самым важным качеством становится скорость и готовность к изменениям. Успех в ближайшие 20 лет будет определяться не тем, что ты знаешь, а тем, как быстро ты умеешь переучиваться, адаптироваться к новым технологиям, разбираться в незнакомых сферах и пересобирать себя на ходу, меняя стратегию. Почему так происходит? Потому что искусственный интеллект полностью обесценил техническую сторону вопроса — «как сделать». Теперь это уходит на машину. На передний план выходит вопрос «зачем это делать», то есть постановка правильных задач для нейросетей. Это и есть главная компетенция будущего — умение управлять ИИ, а не выполнять за него рутину. Отсюда следует, что образование должно кардинально измениться. Бессмысленно пять лет растить узкого специалиста, который умеет делать одну вещь идеально, если эту вещь уже умеет делать алгоритм. Например, юрист, который всю жизнь разбирался в хитросплетениях договоров, завтра может быть заменён нейросетью. Но тот, кто развивал мозг, учился думать, процессировать информацию и адаптироваться, — останется на коне. Мы не перепрыгиваем этап, когда был важен ум, мы просто перестраиваем его под текущие реалии. Чтобы перестроиться, нужно парадоксальным образом углубиться — в фундаментальные дисциплины. Математика, физика, философия. Это те науки, которые развивают способность воспринимать мир, анализировать его и подстраиваться под него. Они дают не узкие прикладные знания, а некую глубокую основу для мышления. НО ОДНОЙ ТЕОРИИ МАЛО. Нужно ещё иметь практическое понимание существующих инструментов. Не быть обывателем, который смотрит на ИИ со стороны, а понимать его структуру и уметь с ним работать на уровне профи. Сочетание фундаментального мышления и владения актуальными технологиями — вот что создаёт суперлюдей будущего. И тогда вообще не встаёт вопрос, какие навыки будут востребованы. Ты просто становишься человеком, который умеет учиться, понимать смыслы и менять мир вокруг себя, а не следовать инструкциям. Важно также понимать, что с популяризацией ИИ все знания и продукты, созданные человеком, начинают оседать в огромном массиве информации. Информации становится так много, что критическое мышление начинает замыливаться. Поэтому будет востребовано именно прошлое мастерство людей — те книги, те основы, тот фундамент, который был создан до текущего момента. Мы будем опираться на это человеческое наследие. Если собрать всё в конечный вывод, то необходима 1️⃣ Фундаментальные способности: быстро учиться и переучиваться, быть готовым к изменениям, обладать адаптивностью, менять стратегию на ходу, иметь системное мышление и развитый мозг для обработки больших объёмов данных. 2️⃣ Смысловые и стратегические компетенции: умение ставить задачи и задавать вопрос «зачем?», понимание целей и смысла деятельности, формирование правильных сложных запросов для нейросетей на уровне стратегии, а не техники. Здесь важно ломать шаблон общения с ИИ, переставать быть обывателем и переходить на уровень продвинутого пользователя, который не просто скидывает задачу, а выстраивает многоуровневый диалог и получает необходимые решения. 3️⃣ Фундаментальное образование — глубокая база из математики, физики и философии, которая развивает восприятие мира и аналитику. 4️⃣ Практический баланс, то есть сочетание этого глубокого фундаментального понимания с практическим владением существующими цифровыми инструментами. В итоге портрет суперчеловека будущего выглядит так: это человек, который понимает смыслы и зачем он что-то делает, обладает гибким умом, освоил фундаментальные науки, умеет пользоваться актуальными инструментами и мгновенно перестраивается под новые условия рынка.
Посмотрела видео " Жуткое будущее ИИ | Варламов и Дороничев " накидала мысли исходя из него ➡️ Суть изменений в IT (Агенты и Роль Человека) Иллюзия продукта: ИИ-агенты (как Claude) создавались не как коммерческий продукт для масс, а как внутренний инструмент, чтобы разработчики Google, могли поручить рутину (написание тестов, шаблонного кода, документации) ИИ. Цель: Ускорить создание новых версий самого Claude (или Gemini). То есть агенты помогали создавать самих себя (будущие версии ИИ) быстрее Смена парадигмы: Раньше: Программист писал код руками. Сейчас: Программист управляет агентами (оркестрирует), ставит им задачи, а код пишет ИИ. Новая роль специалиста: Работа инженеров и других специалистов меняется. Программист, например, из человека, пишущего код вручную, превращается в «уберруководителя», который управляет десятками и сотнями AI-агентов. Эти агенты берут на себя выполнение рутинных и даже сложных задач, а человек фокусируется на управлении процессами и проверке результатов. ➡️ Мысль о «Налоге на ИИ» Это неизбежный социально-экономический шаг (ответ на автоматизацию). Когда большинство профессий будут заменены или изменены нейросетями, появится новый договор между государством и обществом, где налог на ИИ-сотрудников станет реальностью. ➡️ Как внедрять в бизнес оркестрацию ИИ агента. Это у меня встал пазл после вчерашнего изучения. 📚 5 шагов, которые нельзя пропускать при внедрении ИИ в бизнес (это и есть суть моего повестования): 💛Оцифровка — упаковать все существующие процессы в данные. 💛Оптимизация — понять, что можно улучшить. 💛Автоматизация — определить, что можно отдать ИИ. 💛Оркестрация — запустить агентов и соединить их с данными. Управление — посадить сверху человека, который понимает и бизнес, и ИИ. Ключевая мысль: Нельзя перепрыгнуть через моделирование. Если ты сначала не нарисовала архитектуру "на бумаге" (оцифровала логику), а сразу кинулась писать код через ИИ — это не серьезный проект.
БЕКЛОГ И ПРИОРИТЕТЫ НЕ СПАСУТ. Почему без моделирования требований архитектура ломается каждый раз. Моделирование — это инструмент аналитика (или разработчика) для работы с требованиями. Его польза распространяется: 📈 Вверх — на архитектуру. Плохая модель требований рождает неправильную архитектуру. Исправляя требования через диаграммы сейчас, вы спасаете архитектуру от фундаментальных ошибок в будущем 💻 Вниз — на код. Модель ищет смысловые ошибки в логике, которые программист мог бы закодить. Программист, получив четкую непротиворечивую схему, напишет правильный код с первого раза. Инвестиция в моделирование требований на старте — это страховка от хаоса, дорогих доработок и сорванных дедлайнов на финише. Если модель требований построена плохо (ошибочна), то архитектор спроектирует неправильную структуру. Исправляя требования через диаграммы сейчас, вы спасаете архитектуру от фундаментальной ошибки в будущем. Модель требований ищет смысловые ошибки в логике, которые программист потом закодит. Не ищите ошибки в ТЗ и не ждите, пока их найдут в коде. Дайте ошибкам проявиться на диаграммах. Пока это стоит всего лишь стрелочки. Модель — это дешёвый черновик архитектуры. Перерисовать стрелочку на диаграмме стоит 5 минут. Переписывать архитектуру из-за того, что разработчик не нарисовал эту стрелочку — стоит недель и нервов клиентов. более плотный текст на vc.ru
видео или голосовое, без подписи
📐 ОДИН ВЗГЛЯД НЕ ПОКАЖЕТ ВСЮ КАРТИНУ Алан Марк Девис в книге «201 Principles of Software Development» (1995) сформулировал принцип, который остаётся краеугольным камнем требований и сегодня:«Никакое представление требований в одном виде не дает их полной картины» Необходима комбинация текстовых и визуальных способов представления требований на различных уровнях абстракции, чтобы получилась полная картина создаваемой системы. К таким способам относятся списки функциональных требований, таблицы, графические модели анализа, прототипы пользовательского интерфейса, приемочные тесты, деревья и таблицы решений, видеоклипы и математические формулы (Wiegers, 2006). Визуальные модели требований могут помочь выявить отсутствующие,излишние и несовместимые требования. В идеале различные представления требований должны создавать разные специалисты. Бизнес-аналитик может написать функциональные требования и нарисовать часть моделей, дизайнер пользовательского интерфейса — создать прототип, а ведущий тестировщик — написать варианты тестирования. Сравнение представлений, созданных различными специалистами в ходе разнообразных исследований, помогает выявить несоответствия, неясности, допущения и упущения, которые трудно обнаружить, когда требования представлены в одном формате. Определенные типы информации с помощью диаграмм удается передать гораздо эффективнее, чем с помощью текста. Изображения помогают преодолеть языковые барьеры и терминологические разногласия между членами команды. ______ Отсылка на посты об информационной грамотности 💛 НАУКА ПРИНЯТИЯ РЕШЕНИЙ 💛 ДАТА грамотность 💛ОСНОВНЫЕ МЕТОДЫ АНАЛИЗА ДАННЫХ: краткий обзор 📊 к этому посту приклею виды диаграмм, сейчас как раз изучаю их по книге "Разработка требований к программному обеспечению." Глава 12. Лучше один раз увидеть, чем 1024 раза услышать. ______ Самые известные правила из книги «201 Principles of Software Development» 💛Качество — это приоритет номер один: плохой продукт, сданный вовремя, никому не нужен. ➡️ Принцип 60-60: около 60% усилий в ИТ уходит на сопровождение (поддержку) ПО, и около 60% от этой доли тратится на исправление ошибок и адаптацию. 💛Стройте систему с расчетом на выброс: первый прототип всегда несовершенен, его нужно уметь переписать. 💛Раннее исправление ошибок: найти и исправить ошибку на этапе анализа требований в сотни раз дешевле, чем после релиза системы. #датаграмотность #книгиис #бизнесанализ
📖 ЗАЧЕМ ИЗУЧАТЬ ПРЕДМЕТНУЮ ОБЛАСТЬ ИЛИ С ЧЕГО НАЧИНАЕТСЯ РАЗРАБОТКА? Предметная область — это часть реального мира, которую мы собираемся отразить в информационной системе, она начинается не с кода, а с анализа. 🗃️ Она включает: 💛Сущности — о ком/о чём храним данные (Клиент, Услуга, Мастер) 💛Атрибуты — свойства сущностей (имя, телефон, цена) 💛Связи — как сущности связаны друг с другом (мастер оказывает услуги, клиент записывается к мастеру) 💛Правила — ограничения и бизнес-логика (нельзя записать двух клиентов в один слот) то есть статусы, обязательность, уникальность 📌 А ЗАЧЕМ ЭТО ВСЁ ИЗУЧАТЬ? Чтобы получить МОДЕЛЬ ДАННЫХ — схему будущей базы данных, которая: 💛архитектурный фундамент всей системы - точно отражает потребности бизнеса 💛исключает ошибки на этапе разработки -- инструмент проверки гипотез до написания кода 💛экономит месяцы переделок - защита от переделок на поздних этапах 💛является контрактом между бизнесом и разработчиками - единый язык 📌 КЛЮЧЕВОЙ ПРИНЦИП: Качество модели данных прямо пропорционально глубине понимания предметной области. Плохо поняли бизнес — получили переработки, костыли и legacy. Поняли правильно — заложили основу для масштабирования. Без первого — хаос. Со вторым — система. —— 🎯 ИТОГ: Анализ предметной области → Модель данных → Схема БД → Работающий продукт Всё остальное — следствие. Без первого пункта всё остальное теряет смысл. подробнее на доске #бизнесанализ
видео или голосовое, без подписи
видео или голосовое, без подписи