Дмитрий Романюк - Стратегическое управление в IT

Почему нейросети врут? Что такое галлюцинации искусственного интеллекта. Если вы пользовались ChatGPT, Claude или DeepSeek, вы наверняка сталкивались с ситуацией, когда нейросеть выдает идеально уверенный ответ… который полностью не соответствует действительности. В индустрии это называют «галлюцинациями» ИИ. В этом видео я разбираю суть этого явления: почему это не баг, а фундаментальная особенность архитектуры больших языковых моделей (LLM), и почему в корпоративной среде (Enterprise) к этому относятся максимально серьезно. 📌 В этом видео: • Что такое галлюцинации ИИ простыми словами. • Почему модель никогда не говорит «Я не знаю». • Чем опасны ложные ответы нейросетей для бизнеса и финтеха. 🔗 Читайте полный текстовый разбор на моем сайте: https://xn--80ahmq.xn--90ais/%d1%87%d1%82%d0%be-%d1%82%d0%b0%d0%ba%d0%be%d0%b5-%d0%b3%d0%b0%d0%bb%d0%bb%d1%8e%d1%86%d0%b8%d0%bd%d0%b0%d1%86%d0%b8%d0%b8-%d0%b8%d0%b8/ 📖 Краткая расшифровка видео (для тех, кто предпочитает читать): Главная проблема LLM в том, что они работают как «Т9 на стероидах». Модель не хранит базу фактов, она предсказывает следующее слово на основе вероятностей. Если она не знает точного ответа, она генерирует наиболее вероятное сочетание слов, чтобы ответ звучал логично. Плюс, при обучении модели штрафовали за ответы «Я не знаю», из-за чего она запрограммирована выдавать ложь с абсолютной уверенностью. В Enterprise-среде (банки, медицина, IT) такая ошибка может стоить миллионов долларов, поэтому ИИ никогда не дают финальное право голоса без проверки человеком. #AI #ИскусственныйИнтеллект #Нейросети #LLM #ChatGPT #DeepSeek #ГаллюцинацииИИ #Технологии #IT #SRE #EnterpriseAI

🎬 Что такое человеко-часы? Полный разбор метода оценки трудозадач в IT Оценка в человеко-часах — это классический метод прогнозирования времени, необходимого для выполнения задачи. В этом видео мы детально разбираем, как работает этот подход, в каких случаях он эффективен, а когда превращается в иллюзию контроля. Это видео будет полезно тимлидам, руководителям проектов, разработчикам, менеджерам и всем, кто работает с оценкой трудозадач в IT. Тайм-коды для навигации — ниже 👇 ⏱️ Тайм-коды: 0:00 — Что такое человеко-часы (human-hours) и как работает метод 0:05 — Плюсы оценки в человеко-часах для бизнеса 0:15 — Минусы и ограничения метода 0:25 — Где и когда оценка в человеко-часах действительно работает 0:35 — Где человеко-часы не работают (сложные и нестандартные задачи) 0:45 — Почему прогнозы всё равно срываются (вопрос на засыпку) --- ➕ Плюсы оценки в человеко-часах: ✅ Простота и понятность для бизнеса, заказчиков и CEO ✅ Лёгкость в расчётах и коммуникации ✅ Подходит для рутинных задач и Fixed Price проектов ✅ Не требует специальных навыков или сложных инструментов ✅ Удобно для внешних контрактов и T&M проектов ➖ Минусы человеко-часов: ❌ Не учитывают сложность задачи и технические риски ❌ Игнорируют разницу в уровне опыта разработчиков ❌ Не учитывают прерывания и переключение контекста ❌ Зависят от конкретного исполнителя ❌ На нестандартных задачах дают ложную точность ❌ Создают иллюзию контроля и жёсткие ожидания 📍 Когда оценка в человеко-часах работает: ✅ В стабильной, зрелой команде ✅ На однотипных, повторяющихся задачах ✅ Когда производительность разработчиков примерно одинаковая ✅ Когда требования и условия работы предсказуемы 🚫 Когда человеко-часы не работают: ❌ При сложных и нестандартных задачах ❌ Когда есть высокие риски и неопределённость ❌ Когда опыт и скорость разработчиков сильно отличаются ❌ При внедрении новых технологий и архитектур ❌ В условиях частых изменений требований (Agile-среда) 💣 Вопрос на засыпку: Если человеко-часы такие простые и понятные, почему твои прогнозы до сих пор срываются? 💡 Что можно использовать вместо человеко-часов? Альтернатива — сторипоинты (Story Points). Это относительная оценка задач в Agile, которая учитывает сложность, объём и риски. Оценка в сторипоинтах не привязана к часам, что даёт команде больше гибкости и точности. 📌 Для кого это видео: 🔹 Тимлиды и руководители проектов 🔹 Разработчики, участвующие в планировании спринтов 🔹 Скрам-мастера и Agile-коучи 🔹 Менеджеры по продукту и владельцы продуктов 🔹 Все, кто работает с оценкой трудозадач в IT 🎥 Это видео — часть серии разборов по оценке задач, управлению проектами и Agile-методологиям. 📌 Больше материалов по управлению IT, SRE, оценке эффективности и Agile — на моём сайте: https://дима.бел 🔔 Подписывайтесь на канал, чтобы не пропустить новые видео по управлению командами, IT-стратегиям и наблюдаемости. --- Хештеги: #человекочасы #оценказадач #управлениепроектами #Agile #Scrum #Kanban #прогнозирование #тимлид #управлениеразработкой #человекочасы #humanhours #effortestimation #projectmanagement #ДмитрийРоманюк

Сторипойнт: что это и как оценивать задачи в Agile Сторипойнт (Story Point) — это не часы, не дни и не "средняя температура по больнице". Это относительная оценка трудозатрат, основанная на трёх компонентах: сложность, объём и риски. В этом видео я объясняю, как работает story point, почему большинство команд используют сторипойнты неправильно, и когда стоит декомпозировать задачу. --- Что такое Story Point? Story point — это относительная оценка задачи, которая позволяет сравнивать сложность, объём и риски разных задач. Если одна задача в 2 раза сложнее другой — она получает в 2 раза больше storypoint. Это не абсолютная шкала, а система сравнения, которая помогает команде выработать общий язык для оценки. Три компонента сторипойнта: 1️⃣ Сложность — насколько трудно реализовать задачу технически. Влияет ли она на другие модули? Требует ли рефакторинга? Есть ли зависимость от внешних систем? 2️⃣ Объём — сколько работы предстоит сделать. Объём может быть большим даже при низкой сложности (например, переименовать 100 полей в базе данных). И наоборот — сложная архитектурная задача может быть небольшой по объёму. 3️⃣ Риски — неопределённость, неизвестные зависимости, скрытые сложности. Чем выше риск, тем выше оценка. Оценивая задачи в сторипойнтах, мы оцениваем их друг относительно друга по этим трём параметрам. Пример: - Задача А — 1 storypoint. Это базовая задача, которая уже хорошо известна команде. - Задача Б в 2 раза сложнее, с тем же объёмом и рисками → 2 storypoint. Никаких часов. Только сравнение. --- Декомпозиция крупных задач: почему 13 или 21 сторипойнт — сигнал к действию Если при оценке задача получила 13 или 21 storypoint, такую задачу желательно декомпозировать. Это ускорит разработку и даст более точные оценки. Почему это важно: - Крупные задачи сложнее контролировать - Ошибка в оценке растёт с размером задачи - Декомпозиция позволяет параллелить работу - Снижается риск "зависания" задачи на несколько спринтов Как делать декомпозицию: 1. Разбейте задачу на независимые подзадачи 2. Оцените каждую часть отдельно 3. Убедитесь, что каждая часть может быть выполнена в рамках одного спринта 4. Проверьте, что части можно разрабатывать параллельно --- Главная ошибка при использовании сторипойнтов Привязка сторипойнтов к человеко-часам. Например: «Примем 1 сторипойнт за 1 день». Это ломает всю систему относительных оценок. Команда перестаёт думать о сложности и начинает гадать о времени. Почему это проблема: - Story point перестаёт быть относительным - Появляется ложное чувство точности - Velocity теряет смысл - Команда начинает "играть" в оценки - Заказчик получает ложные ожидания Реальность: если вы привязываете сторипойнты к часам, вы не используете их преимущества — вы просто заменяете одну календарную метрику другой. --- Почему Story Points лучше человеко-часов Исследования Microsoft показывают, что в динамично меняющемся мире Agile-подходы с относительной оценкой повышают шансы на успешное завершение проекта по сравнению с оценкой в человеко-часах. Ключевые выводы: - Команды с оценкой в storypoints реже срывают сроки - Они быстрее адаптируются к изменениям - Прогнозирование становится точнее - Снижается уровень стресса в команде - Заказчики получают более надёжные прогнозы Почему работает: относительная оценка сглаживает индивидуальные различия разработчиков и позволяет команде использовать коллективную экспертизу. Она также стимулирует коммуникацию в команде, потому что требует обсуждения. --- Для кого это видео 🔹 Тимлиды, которые хотят наладить оценку задач 🔹 Руководители проектов и продуктовые менеджеры 🔹 Разработчики, участвующие в планировании спринтов 🔹 Скрам-мастера, которые хотят улучшить процесс --- Что вы узнаете: ✅ Что такое сторипойнт и как его использовать ✅ Почему 13–21 storypoint — сигнал к декомпозиции ✅ Главную ошибку: привязку сторипойнтов к часам ✅ Почему относительная оценка работает лучше в Agile --- Структура видео: 0:00 — Что такое Story Point 0:05 — Как оценивать задачи в сторипойнтах 0:30 — Декомпозиция крупных задач 0:50 — Главная ошибка: привязка к часам 1:15 — Исследования Microsoft 1:40 — Заключение --- 📌 Больше материалов по управлению IT, SRE, оценке эффективности и Agile — на моём сайте: дима.бел Подписывайтесь на канал, чтобы не пропустить новые видео по управлению командами, наблюдаемости и IT-стратегиям. --- Хештеги: #сторипойнт #storypoint #storypoints #agile #оценказадач #управлениепроектами #ITуправление #ДмитрийРоманюк #тимлид #скрам #декомпозиция #velocity #agileestimates #управлениеразработкой #NoEstimates #flowmetrics --- Кстати: если у вас есть вопросы по оценке задач в вашей команде — пишите в комментариях. Делитесь своим опытом и спрашивайте, что непонятно. Подписывайтесь, чтобы не пропустить следующие видео по управлению IT-проектами и командами. В следующем выпуске разберём тему NoEstimates — когда оценки вообще не нужны.