Revelio Tech | Журнал

Про управление проектами в стиле "пьяный мастер"

⚠️ Очаровательный Джеки Чан разберется

Он прекрасен на сцене. Комитет, совет директоров, разбор кризиса — и вот человек рассказывает, как вытащил горящий проект, почему его план неуязвим и как проект успешно добежит до завершения.

C-level слушает и верит –> ставку делают на него.

А потом начинается трек длиной 2, 3, 6, 12 месяцев. И здесь всю реальную работу приходится делать скучным типам, которые просто знают предметную область.

⏺️ Мы любим Джеки, но вы же в курсе, что стиль кунг-фу "пьяный мастер" в реальном бою не работает?

Да, контролируемых экспериментов по цзуй цюань нет. Но есть публичные проверки: в 2017-м мастер тайцзи вышел против MMA-бойца и лёг меньше чем за 20 секунд (BBC, 11.05.2017).

Короче, красивая хореография и монтаж работают в кино (в ИТ – на срежиссированном питче), но не способны вытащить в реальном бою (проекте).

⏺️ То же самое и в менеджементе

В 2017 проводилось исследование почти 600 руководителей – изучали связь харизмы и эффективности: она не линейная, а перевёрнутая.

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

⏺️ Как избежать ошибок?

🔹 на защите запуска проекта проводите деловую игру "идёт 3-й месяц" – ставьте РП в невыносимые условия марафона, смотрите на реакцию,
🔹 копайте от его "я" в сторону его "команды" – какой у него напарник (может есть "скучный тип", что его страхует)?
🔹 действуйте от обратного – не просите объяснить проектный план "от старта", а пусть расскажут "с конца" – т.е. с даты go live к дате старта (очевидный тест на шпиона – от 1 до 10 посчитать могут все, а от 10 до 1 – уже нет).

⭐️ Выводы

На питче проекта или при найме РП вы оцениваете способность быть яркими и убедительными 20 минут, а покупаете работу в течение 3-6-12-36 месяцев.

Поэтому чем харизматичнее и очаровательнее спикер защиты – тем более жесткими вы (и комитет) должны быть.

Подписаться

Сходили в гости на подкаст Кабушев и Штейн 🔥

(подписывайтесь, кроме забавных обложек подкаста у ребят замечательная книга для PMов)

Почему оценки проектов врут? Как назвать сроки и бюджет, которым действительно можно верить?🤑

– Как оценивать проекты точно? А зачем?
– Как заранее предсказать, что проект полетит в пропасть?
– Как сократить расходы на 10-15 млн руб / год на ИТ-штат 100 чел.?

👀 Смотреть:
👉 ВК.Видео
👉 Ютуб
👉 Рутуб

📣 Слушать:
👉 Мейв
👉 ТГ
👉 Яндекс.Музыка

Руководители и проджекты движутся меж Сциллой и Харибдой

Без проектного опыта ты не можешь грамотно направить команду на реализацию задач

Получил необходимый опыт?

Сталкиваешься с отсуствием команды – она выгорела и уволилась в рамках накопления тобой опыта

Управление персоналом в пространстве 1️⃣сроки 2️⃣стоимость 3️⃣результат есть тонкий баланс между 2 крайностями

#manifesto #humor | Подписаться

Риск, даже если он в смете ➡️ заранее оплаченный конфликт

Вдохновлено проектом кругосветного полёта Фёдора Конюхова от его сына, Оскара: 100 человек, 10 стран, поломки, бури и жизнь отца, как цена ошибки

⏺️«Надежда — не стратегия»

Они готовили сценарии, включая "плохие исходы", желая увидеть, как именно все может не получиться, какие риски могут выстрелить.

Например, бури – во время прохода циклона Оскар обсуждал риски не просто с метеорологом, а с экспертом по моделям движения воздушных потоков. Его на старте проекта активно приглашали в команду, как одного из самых знающих и делающих руками экспертов в отрасли.

⏺️В IT-проектах на кону не стоит жизнь, но психология – аналогична

Подрядчик всё-всё о вас знает: интеграции – сложные, данные – грязные, приемка – муторная. Риски в смету иногда закладывает (перестраховка), иногда – нет (желание победить).

⏺️Но не проговаривает риск с клиентом – почему?

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

⏺️Риск реализуется? Даже если он в бюджете – это конфликт

Умолчание, где за выстрелившим риском следует "мы предусмотрели" вызывает мысль "а о чем вы ещё умолчали?"

Паника, а как же – сценарий не обсуждали, выбора не дали!

Поэтому, если путь митигации был запланирован только 1 стороной, это настолько сбрасывает проект с рельс, что сжирает на устранение 20-30% ресурсов больше плановых.

⏺️Кто это – сильный руководитель проекта?

Не транслятор уверенности (иногда она же слепая беспечность), а:

1️⃣искатель – умеет найти профи, услышать сомнения и перевести риски в решения по (1) срокам, (2) ресурсам, (3) объемам.

2️⃣ распасовщик (голевой передачи) – в критический момент передает право решать тому, кто сейчас понимает ситуацию лучше остальных.

В истории полёта Конюхова при обходе циклона таким человеком стал метеоролог, а не формальный руководитель проекта.

Поэтому управление рисками – признать себе, что буря может случиться, и договориться о цене, в которую обойдется её преодолеть.

➡️ 21% готовят Gantt для себя, а 4% – для босса

Мы делимся выдержками из 5️⃣2️⃣ анкет и 1️⃣0️⃣ интервью по исследованию "Как команды планируют сроки проектов"

Самое яркое признание было в 1 из интервью:

Я не беру проекты, где нужно делать Gantt, а если его требуют – отказываюсь от проекта (респондент – PM & Delivery из big tech)

50% респондентов отметили, что оценка трудоемкости – самая затратная по времени задача, а 32%, что "определение зависимостей между задачами"

Любопытно, этот ответ давали как PM-ы (40% участников), так и бизнес (22,5% участников иссл-я), но не руководители (!) – описывая как изматывающий процесс "челленджа" и обсуждения сложности реализации задач

На основе ответов участников мы доработали наш продукт ⏺️AI-оценка как сервис

Изменения:
1. оценка трудоемкости дается для каждой задачи,
2. формируется драфт Gantt-а,
3. указываются зависимости и последовательности задач,
4. все артефакты можно скачать.

Сервис для физ. лиц – доступен по ссылке

Пилот корпоративной версии (ожидаемая экономия до 20 млн / год на 100 чел штата ИТ-команды) – запрашивайте в ЛС @reveliotech

❗️Наш мозг ошибается чаще, когда использует LLM

Возьмем 6 из 50+ когнитивных ошибок на примере задачи описания AI IS и трансформации в TO BE бизнес-процессов компании

1️⃣Ошибка планирования – переоценка сложных задач и недооценка простых. ИИ отдал текст регламента на 37 страниц за 5 мин? Внедрить этот регламент займет не 1 встречу.

Шторминг (этап “притирания” команды друг к другу) вводил регламент в жизнь за те 2-3 недели, пока он рождался в муках. Попытка исключить этот этап, ускорив процесс, приводит к иллюзии результата.

2️⃣Расщепление – попытка выполнить N дел, каждое из которых требует сознательного внимания. 57 вкладок в Chrome были с нами с 2008 по 2023. Теперь все хуже: 6-7 агентов, генерирующих тонны текста / кода.

3️⃣Амплификация – вложение в задачу усилий больших, чем требуется. Создаются лендинги с Claude / Lovable на 15-20 экранов на каждую проблему, но это не делает суть проблемы понятнее. Нехватка инвестиций человеческого времени только увеличила его стоимость.

4️⃣Иллюзия глубины понимания – ИИ усиливает её, подменяя “я осведомлен” об этом процессе на “я быстро изучил с ИИ и понимаю, как это работает”.

Средний бизнес – это 15-20 доменов и минимум 150+ процессов 2-го уровня, где даже находясь внутри системы невозможно знать каждый из процессов, особенно из смежных доменов.

5️⃣Конфирмация – интерпретация информации под свою точку зрения. Например, при формализации бизнес-процессов начать описывать их самостоятельно по своим же зоны с LLM – означает обрабатывать контекст через свое зеркало (свои промты, свои .md, свои установки, свой метод декомпозиции задачи), как владельца процесса.

6️⃣Чрезмерная редукция – многоэтапное упрощение сложного к простому, иногда с многократной суммаризацией / выжимкой информации до “костяка”, приводящее к ошибкам изложения.

Неужели люди, общаясь с LLM, чаще допускают эти ошибки?

Чаще – да, но не как % от мышления (мозг слабо изменился и за последние 2000 лет, а тем более в последние 5 лет существования LLM), а в связи с ростом объемов обрабатываемой информации.

В диалоге 2 профессионалов на ошибки есть кому указать.

В диалоге с ИИ "гигиеническим минимумом" станет сделать частью своего пайплайна “QA на когнитивные ошибки”.

Давайте не забывать, что:

свою голову на плечи другому – не прикрепишь, поэтому пока решения принимают люди, передача контекста – самое трудное, что остается в эпоху сгенерированных данных.

А какие вы когнитивные ошибки замечали за собой?

2️⃣8️⃣июля, ВТ, 1️⃣6️⃣⏺️0️⃣0️⃣
Эфир «Консалтинг в эпоху ИИ: что остается без красивых презентаций»

Спикеры:

1. Александр Поломодов, автор канала «Книжный куб» и 🏦CTO Т-Банк

Наш отзыв: один из лучших каналов про фундаментальные вопросы в ИТ. Рекомендации книг и нишевых, не примелькавшихся спикеров каждую неделю.

2. Александр Воронцов, бизнес-консультант и партнёр Revelio

Поговорим в прямом эфире на темы:

0. спойлер — почему 1/2 консалтинговых проектов бесполезна,

1. в чем ценность консалтинга, когда убедительные документы генерируются за минуты?

2. когда отношения между бизнесом, ИТ и внешним консалтингом в проекте похожи на мексиканскую дуэль, как «выруливать» на счастливый конец?

3. что ждёт бизнес, где скорость генерации идей и запуска изменений превышает способность их осознать?

Ссылка на эфир, не пропустите!

Ищем Project-менеджеров / PMO и всех, кто работал с диаграммами GANTT последние 1️⃣2️⃣ месяцев

Мы управляем проектами и тратим по 2-5 часов / нед., чтобы план был актуален. Обидно, когда он устаревает на следующий день, и его надо переделывать?

Хотим упростить эту работу, поэтому изучаем, как именно специалисты превращают проектные требования в календарные планы.

➡️ Пройдите этот опрос (12 вопросов) на 3-5 минут:
https://forms.gle/Pwe6VHNunbwJ2QsY8

Опрос анонимный, контакты оставлять опционально (участникам, оставившим контакт в анкете, пришлем результаты и выдадим подарок – подумаем какой 😄)

Нужно ли планировать проект в диаграмме Ганта?

⭐️5 плохих паттернов project-ов в конце – забирайте для самопроверки

У Gantt плохая репутация... большая, тяжелая, немного мёртвая – длинная простыня из 236 задач, зависимости и полосочки, в которые никто не верит уже через 1 неделю.

Я понимаю почему ей пользуются – (1) ее требует начальство, (2) плохой план лучше, чем его отсутствие, когда надо успокоить тревогу и коллег, и менеджмента.

"Смотрите, у нас все под контролем" (с) Хотя под контролем в лучшем случае Excel 😂

Но хороший план все же нужен – он говорит:

"это должно случиться, чтобы мы успели", "эти ресурсы или двигаем дату".

Получается, делаем Gantt. А откуда начать? И как не попасть в ловушку своего же мышления?

⭐️ 1-й способ – идти с начала

Выписываем задачи, кладем в этапы, оцениваем, растягиваем продолжительность, ставим завсимости.

И куда нас это приводит? Чаще всего не в дедлайн, а в следующий год, зато красноречиво демонстрирует амбицию.

⭐️ 2-й способ – планировать с конца

Есть у нас дата финала – запуск / совет директоров / начало сезона / конференция? Мы идем от неё назад:

🔹Что должно быть готово перед запуском?
🔹Когда закончиться тест?
🔹Где точка невозврата?

Мы видим не «как нам хотелось бы», а какую версию результата выдерживает реальный срок.

Когда проджект под давлением без опыта создает Gantt по 1-му пути, рождаются эти5️⃣плохих паттернов:

1. В плане "от начала" соберем красивый результат, затем увидим дедлайн и болезненно обрежем свою же песню.

2. Нам не хватает 2 недель до дедлайн? Равномерно все задачи сдвинем на 10% – успеем!

3. Запарелелим этапы? Начнем аналитику и инфраструктуру одновременно, сэкономим 2 месяца.

4. Запараллелим основные работы, но не добавим время на мердж / синхронизацию / исправления.

5. Базовое – примем трудоемкость за продолжительность, не проверив промежуточные зависимости.

Почему возникают эти ошибки?

Тот, кто делает план балансирует между тревогой команды: «нас заставят невозможное» и тревогой бизнеса: «мы не понимаем, когда будет результат и можно ли на вас опереться».

Тот, кто читает план, ищет даже не подтверждение даты, он хочет ощутить уверенность:

🔻Видят ли эти люди риски?
🔻Понимают ли зависимости?
🔻Отличают желание от обязательства?
🔻Скажут ли неприятную правду тому, кому её говорить страшнее всего?

Поэтому иногда лучшей план – не детальный, а наглядный, после которого можно принять решение: переносить срок, резать объём, менять подход, добавлять людей, убирать зависимость или честно не делать проект в таком виде.

План с начала показывает масштаб желания. План с конца показывает цену срока.

Какой выбираете вы?

🖱 Подпишитесь на канал

Мы пишем и говорим про (1) проектное управление, разработку, (2) консалтинг и культуру в командах, (3) наши продукты, (4) интересные байки с рынка

Статьи команды:

🔳Forbes | От Excel к ML: как бизнесу перейти на динамическое ценообразование
💜Sostav | Геймификация и мини игры в маркетинге

Подкасты:

🏦в гостях у InSAйт и Павла Каравашкина, Head of Dev Т-Банк | У системных аналитиков нет комьюнити: миф или реальность
🏦в гостях у Code of Leadership с CTO Т-Банк | Групповая динамика и модель BART
⏺️в гостях у TellMeAboutTech | Консалтинг в эпоху ИИ: что остается без красивых презентаций?

Исследования:

⏺️Как выбрать CDP / Loyalty / Comms платформу в 2026?
⏺️Как команды планируют сроки проектов?
⚡️Coming Soon | Рынок АЗС России 2026: приложения, программы лояльности и клиентский опыт

Посты:

⏺️Риск в смете ➡️заранее оплаченный конфликт
⏺️5 когнитивных ошибок мозга при работе с LLM
⏺️Как правильно делать GANTT: с начала или с конца?

Нажимайте «Подписаться», чтобы ничего не пропустить!

Все материалы доступны на сайте в разделе "Медиа": https://revelio.tech/media/, а этот пост – будет пополняться

Если знаете кого-то, кому наш канал будет полезен — поделитесь ссылкой: https://t.me/revelio_tech

🦄 Зачем нужна команда разработки, если я могу накодить с ИИ? – ровно 3 раза я услышал это с понедельника

НЕТ, ДРУГ, НЕ МОЖЕШЬ!

Написали этот пост, чтобы и ваш ответ на эту фразу был понятным и цензурным ➡️

– У вас нет справочников, не нормализована структура данных
– Ваши договора не бьются между 1С и ЭДО
– Товарные остатки в eCom конфликтуют с данными в отчетах
– Менеджеры считают цены в Excel и у каждого он свой
– 20 человек, а тем более 150 не начнут пользоваться продуктом, который ты сделал для себя
– Твой интерфейс будет понятен только тебе

Код и разработка всегда были 15-20% от продукта. В 2026 узкое место в скорости никуда не исчезло, оно переместилось в:
– договоренности в команде,
– нормальную аналитику,
– обучение и объяснение,
– данные и процессы.

Мы накодили сквозную аналитику с ИИ на замену SMARTIS, сейчас будем цифры сводить

Через 4 недели этот застройщик поймет, что специализованное решение сквозной аналитики существует не просто так, и количество договоренности с партнерами / коннекторов / бэкенд-логики / склеек не повторяемо с его ресурсами.

Заказчик говорит сделает это за вечер с ИИ, объясни почему ты оценил в 17 млн?

К слову, в этом случае огромный респект говорившему, он за 2-3 минуты понял почему.

⭐️ Взгляните на график в посте ⭐️

Это средняя продолжительность времени и количество труда, необходимое, чтобы условная компания с Коммерцией на 20–100 человек трансформировала процессы Продаж (Закупки –> Ассоритимент –> Цены –> Точки –> Мерчендайз –> Объемно-календарка и т.д.)

Это не 10 отчетов, поверх которых LLM должна начать давать ответы на вопросы "а почему у меня у этого кластера точек снизилась маржнальность по KVI?"

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

Затем классическая математика (k-means, случайный лес и вот это всё). И лишь поверх и в конце LLM, которая может быстро нафигачить интерфейс или дать ответ на вопрос пользователя.

"Продукт за вечер" это может быть:
– красивая иллюзия комптентности,
– возможный образ результата,
– микро-инструмент личного пользования.

Но не решение для 150 человек в корпоративном бизнес-процессе.

Продукты сделанные с ИИ – как трусы с Aliexpress,

– очень хочется заявить так, но это будет глупость.

Скажу иначе,
бизнес, который начал делать MVP с AI, мы сами видим прирост скорости и ценим ваш энтузизам, но:

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

С разработкой и продуктами так же – написать код, как и написать регламент – лишь крошечная часть задачи.

Подписаться на канал

⭐️ Release notes продукта "AI-оценка ИТ-проекта"

1. Результат оценки теперь доступен в интерфейсе

2. Упрощен онбординг: убрали вопросы с min влиянием на рез-тат

3. Доступ к результатам оценки по коду из почты, которую указывает пользователь

⭐️ Промокод на бесплатную оценку
JULY26

⭐️ Обратную связь пишите в комментарии или DM @reveliotech

#releasenotes #15072026

Ответ: рядом с левой дорожкой

Значит ли это, что страх и угроза в пользовательских интерфейсах (а плакат в парке – тоже интерфейс) работает лучше, чем просьба?

Да, именно поэтому страхом потери так аккуратно пользуются цифровые сервисы – попробуйте отказаться от подписки "Плюс" или прервите изучение испанского с Duolingo. Наблюдаете юмор, угрозы и легкие манипуляции? 👀

По Канеману люди воспринимают потери в 2 раза болезненнее, чем приоберетения.

Используйте и вы, но не переступая границы этики. А теперь наша манипуляция 👻

До ~70% ИТ-проектов тщательно проходят фазу "Инициация", но на выходе всё равно получают перерасход / убытки / срыв сроков / невыполнение изначальных задач.

Чтобы снизить этот риск мы создали AI-оценку: 1️⃣ загрузить БТ/ФТ → 2️⃣ ответить на вопросы → 3️⃣ проанализровать выявленные AI риски / сроки / ограничения / трудозатраты.

Безопаснее свериться с опытом 300+ аналогичных проектов, чем двигаться наощупь "по граблям".

⭐️ Бесплатный тест по промокоду JULY26

#юмор_по_понедельникам

Подписаться на канал

В далёком 2015, в Custis, меня учили странному для junior-аналитика:
– ты здесь не для того, чтобы быть «аналитиком»,
– и не «руководителем проекта»,
– будь инженером.

Слабо я понимала смысл, хотя это одна из самых полезных профессиональных максим в моей жизни.

Меня учили способу мышления, ведь инженер – не обязательно человек, пищуший код. Он соединяет смысл, систему и последствия.

Последние пару лет узкие роли становятся сложно применимы:

🔹Аналитик, который «только пишет требования», слишком далек от решения

🔹Разработчик, который «только пишет код», слишком далек от пользователя

🔹Руководитель проекта, который «только двигает сроки», слишком далек от бизнес архитектуры.

🔹Архитектор, который «только рисует концепцию», слишком далек от реальной жизни системы
Это напомнило мне "пухососы", которые милые и важные, но буквально пару недель в году

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

🔹Аналитик становится инженером смысла. Он не просто фиксирует, что «заказчик попросил кнопку». Он понимает, какую боль эта кнопка должна закрыть, какие сценарии за ней стоят, какие данные нужны, какие исключения появятся, где пользователь может ошибиться, а где система начнёт врать.

🔹Разработчик становится архитектором поведения системы. Не в смысле «теперь все архитекторы», а в смысле — каждое техническое решение влияет на будущее: на скорость изменений, наблюдаемость, поддержку, безопасность, стоимость ошибки.

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

🔹Тестировщик перестаёт быть человеком, который «проверяет после всех». Он становится инженером качества: помогает команде заранее увидеть риски, слабые места, неочевидные сценарии и цену дефектов.

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

Это, конечно, не значит, что все должны уметь всё.

Сильная команда — не толпа универсальных солдат. Это люди с разной глубиной экспертизы, но с общей способностью видеть систему шире своей должностной инструкции.

А сейчас, с появлением и развитием ИИ, когда писать код становится быстрее, дороже становится другое: понять, что именно мы строим, где границы решения, какие сценарии мы забыли, чему можно доверять, как проверить результат и что будет с системой через полгода.

В DORA 2025 от Google Cloud ИИ описан как amplifier: он усиливает не только сильные стороны организации, но и её слабые места. Максимальная отдача появляется не от самого инструмента, а от зрелости процессов, культуры и инженерных практик команды.

С 2018 по 2024 команду можно было строить как конвейер: один понял, второй описал, третий сделал, четвёртый проверил, пятый выкатил, шестой поддерживает.

Сейчас такой конвейер слишком часто ломается на стыках, где живут самые важные решения:
– между пользователем и данными,
– между фичей и архитектурой,
– между скоростью и надёжностью,
– между «мы обещали» и «это вообще возможно поддерживать».

В 2026-27 вопрос при сборе команды звучит так:
какие уровни инженерного мышления у нас закрыты?

Есть ли в команде человек, который:
– понимает пользователя?
– кто понимает систему?
– кто видит данные?
– кто держит качество?
– кто умеет превращать неопределённость в решение?
– кто думает о жизни продукта после релиза?

И ещё важнее: умеют ли эти люди разговаривать друг с другом не как представители функций, а как соавторы одного решения?

⭐️ Наш продукт AI-оценка – взгляд на ИТ-разработку именно с такой позиции. Бесплатный тест по промокоду JULY26

Revelio Tech | Журнал pinned «⭐️ Release notes "AI-оценка ИТ-проекта за 3-5 минут" 1. Теперь декомпозиция задач и их оценки доступны в CSV 2. Улучшены вектора и взаимосвязи в RAG, добавлены новые оценки по проектам DWH и ecommerce платформам 3. Ваши ответы на вопросы не будут потеряны…»

⭐️ Release notes "AI-оценка ИТ-проекта за 3-5 минут"

1. Теперь декомпозиция задач и их оценки доступны в CSV

2. Улучшены вектора и взаимосвязи в RAG, добавлены новые оценки по проектам DWH и ecommerce платформам

3. Ваши ответы на вопросы не будут потеряны, приходят на почту вместе с вопросами

⭐️ Как работает AI-оценка? (для гостей канала)

1. Переходим по ссылке: https://revelio.tech/evaluate/

2. Добавляем БТ/ФТ/ТЗ/юзерстори – любой документ с требованиями (форматы PDF, DOC, DOCX). Можно загрузить сразу несколько документов.

3. Отвечаем на вопросы по загруженным документам.

4. Получаем результат (декомпозиция, ресурсы, оценка, ограничения, риски, допущения) на почту или по указанным контактам.

Промокод на бесплатную оценку
JULY26

⭐️ Обратную связь пишите в комментарии или DM @reveliotech

#releasenotes #06072026

2026 год – сложный. Даже не 30-40% по кредитной линии страшат, а нарастающая тревога.

Она звучит так: меньше денег –> больше генерить идей –> больше задач –> меньше ошибок –> цикл.

Пропадает способность планировать вдолгую, а команды "хватаются за всё" и теряют фокус "что мы можем, а что НЕ можем и почему?"

Некоторые запускают структурные и технологические изменения одновременно всех вертикалей – и, конечно, бизнес и персонал просто не может переварить такое количество изменений.

Кажется, что на каждое изменение "всего-то" нужен расчет: часы, бюджет, роли, сроки.

На деле оказывается, что до расчёта нужно задать правильные вопросы.

🔹Что в инициативе уже понятно?
🔹Где есть противоречия? Какие задачи недоописаны?
🔹Где изменения споткнутся об обучение персонала?
🔹Где подрядчик заложил риск, но не объяснил его?
🔹Наше любимое: почему конкретно этим пользоваться не будут, ведя двойной учет – в системе и в Google Docs?
🔹Что внутренняя ИТ-команда считает очевидным, хотя для бизнеса это совсем не очевидно?
🔹Наш топ-2: какими данными мы не обладаем? И доверяем ли мы нашим данным в целом?
🔹Где оценка выглядит точной, но держится на предположениях?

Именно поэтому мы собрали сервис, который помогает бизнесу пройти этот первый слой – завалидировать инициативы:

🔹Загрузить существующие требования.
🔹Получить вопросы к ним.
🔹Проверить (1) подрядчика, (2) своё ИТ, (3) свой бизнес н в формате недоверия, а в формате здравого челленджа.
🔹Увидеть, где проект уже можно оценивать, а где сначала нужно прояснить задачу.

Тестировать сервис

Это не заменяет человека и не делает оценку «истиной».
Но может сильно упростить старт, сократив вероятность ошибок по неооценке/неверным срокам/непонятным результатам

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

Сервис "AI-оценка проекта за 3-5 минут"

⭐️ Как работает?

0️⃣ Если Вы Project / Product / бизнес, который оценивает трудоемкость / сроки разработки ПО

1️⃣ Переходим по ссылке: https://revelio.tech/evaluate/

2️⃣ Добавляем БТ/ТЗ/юзерстори – любые требования (форматы PDF, DOCX). Можно загрузить сразу несколько файлов

3️⃣ Отвечаем на вопросы от AI-агентов

4️⃣ Получаем результат (декомпозиция, ресурсы, оценка, ограничения, риски, допущения) на почту / в интерфейсе по коду в почте

⚡️ Что важно:

🔹продукт обучен на ~300 реальных план-фактах (мы посчитали, члены команды с 2018 года выполнили 1000+ оценок)

🔹домены: контакт-центр, продажи, маркетинг, привлечение, лояльность, ITSM, HR, коммерция, закупки, данные и др.

🔹индустрии: eCom, retail, travel, банки, брокеры, страховые, обрабатывающая промышленность, агропром

🔻не предназначен для оценки проектов создания инфраструктуры, сетей, ЦОДов, ведения консалтинга и поддержки

Основная идея: дать “третье мнение”, когда нужно:

🔹отвалидировать оценку своей команды или команды подрядчика

🔹найти пропущенные места: не только через цифры, но и через вопросы, о которых легко забыть на старте.

О продукте:
https://revelio.tech/ai-evaluation/

Тестировать в 1 клик:
https://revelio.tech/evaluate/ (промокод JULY26)