Менеджмент

Роль Agile Coach мертва… да здравствует агент изменений

TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать такие спецы должны не "вечно", а проектно - как спецназ внедрения изменений.

Здесь и далее: скрам-мастер и аджайл коуч тождественны.

1. Выделенная роль в команде — это кража ответственности

Постоянно приставленный к команде Agile Coach (или Scrum Master, или Delivery Manager в роли «няньки») - это прямое забирание ответственности у руководителей.

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

Если руководитель не умеет управлять динамикой команды — значит, его надо учить, а не ставить ему «костыль» в виде коуча (ну и спрашивать с него соответственно). Соответственно, большая часть работы Agile Coach → Change Agent это обучение тем навыкам, которых не хватает руководителям. Скорее всего в больших организациях уже есть T&D‑отдел, который и занимается обучением. Наша задача состыковать системно прокачивание самых актуальных навыков.

2. Коуч для руководителей и архитектор среды

Роль трансформируется в коуча для руководителей и человека, который проводит изменения (зачастую проектно).

Чаще всего наболее активная часть работы - это движение системы к зрелости через работу с лидами. Агенты по изменениям - архитекторы среды обмена опытом. Даже на разборах ситуаций по хорошему (и когда получается) надо молчать и давать слово коллегам руководителя, даже если знаешь «правильный» ответ. Система должна уметь саморегулироваться, когда нас не будет. 

Тут еще есть научная обоснованность: в модели проведения изменений ADKAR доказательно видно как CLARC (people менеджеры) это те, через кого мы проводим изменения.

3. Тест на прочность: «А что, если я уйду?»

Agile Coach делает хорошую работу, если после его ухода система радикально не ломается. Посмотрите, как быстро команды откатываются назад и насколько (например, по метрикам), когда из них убирают скрам‑мастера.

Стабильная привычка, как известно, формируется около 3 месяцев. В зависимости от масштаба изменений вы можете работать 3-6 месяцев и довести команду до определенного целевого состояния.

Нет предела совершенству, но нам с вами не туда: доводить процессы и майндсет до идеальных состояний почти никогда не стоит. Команды после нашего ухода все равно откатятся (и это нормально, главное чтоб не до нуля). С точки зрения всей системы, нам важнее дотягивать другие команды, процессы, взаимодействия, целеполагание до базового и достаточного уровня (который каждая организация определяет сама). Это даст намного более сильный результат по всей организации.

Более того, если долго работать с одной командой - возникает привыкание и порой выученная беспомощность, вы тратите свое время неэффективно. Нужно зайти, настроить, передать ответственность лидам и выйти. А потом трекать (как в настоящем стартапе) - что получается у лидов и команды, что нет - и точечно консультировать. 

4. Мы наняты бизнесом, а не командой

Прошли времена раздутых бюджетов, когда можно было плодить «аджайл ради аджайла» чтобы «оптимизировать процессы». В текущих реалиях (особенно с нынешними ставками ЦБ) каждая копейка на счету.

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

Балансировать перформанс и здоровье команды (например, удовлетворенность, отток, выгорание) - вот это реальная задача, с которой надо помочь руководителям справиться или продумать оркестрацию изменений.

Софт скилы - это новые хард скилы

Управление изменениями, оргдизайн, работа с сопротивлением и сложная фасилитация - язык не поворачивается назвать это «софт скилами». Сейчас это самые настоящие харды. И именно за эти харды бизнес готов платить.

PS: Больше об этих самых хардах и внедрении ИИ в моем телеграм‑канале.

GlowByte проведет вебинар “Как повысить точность планирования в 2026 году”

Спрос меняется молниеносно, а планы устаревают, пока их согласовывают. Знакомо?

17 февраля эксперты GlowByte проведут практический вебинар о том, как бизнесу не просто своевременно реагировать на изменения рыночных условий, а предвидеть их и использовать для оптимизации расходов с помощью IBP-платформы.

Для кого вебинар?

Вебинар будет полезен руководителям коммерческого блока, логистики и производства при участии финблока и тем, кто ищет возможность:

• повысить точность планирования без роста штата,

• уйти от Excel-моделей,

• получить единый, согласованный план по всей цепочке.

На вебинаре разберем:

• Demand Planning — как улучшить прогноз спроса.

• Replenishment Management — как продуктивно управлять запасами.

• Transportation Load Building — как эффективно формировать заказы.

• Ключевые KPI 2026-2030: точность прогноза, ускорение планирования и своевременная реакция на изменяющийся спрос.

• Что сегодня мешает компаниям достичь прозрачности и управляемости — и где именно IBP закрывает этот разрыв.

Чем этот вебинар отличается от других?

Это НЕ скучная продуктовая демонстрация, а взгляд с позиции бизнеса и экономики: как сократить запасы, высвободить капитал и синхронизировать все отделы в одной модели.

17 февраля 2026 г., 13:00 (МСК).

Участие бесплатное, необходима регистрация.

Законодательные новости февраля 2026: выходные, обжалование суда, электронные доверенности и лифты

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

Праздник и выходные в феврале:

Праздничный день - День защитника Отечества (23 февраля).
Он выпадает на понедельник, поэтому отдыхаем три дня подряд: с субботы 21 по понедельник 23 февраля.
Пятница 20 февраля сокращенным предпраздничным днем не является.

Изменение порядка обжалования решений мировых судей:

В Госдуму внесены проекты, меняющие кассационную инстанцию для решений и приказов мировых судей.
Обжаловать их, а также апелляционные определения районных судов, теперь планируется в президиум верховного суда республики, края или области, а не в отдаленный кассационный суд. Это повысит доступность правосудия.
Документы: Проекты Федеральных законов № 1136694-8 и № 1141728-8.

Упрощение оформления электронной доверенности:

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

С 1 февраля 2026 года вступает в силу Приказ Минцифры, который упрощает требования к машиночитаемой доверенности.
Больше не нужно указывать в ней детальные реквизиты паспорта представителя (серию, номер, дату выдачи и код подразделения).
Эти сведения можно вносить как дополнительные.

Машиночитаемые доверенности применяются, если электронные документы подписывает представитель по доверенности. К таким доверенностям предъявляются специальные требования. В частности, они создаются в формате XML.

Доверенность хранится в одной из информационных систем:

⦁ ЕСИА
⦁ федеральных органов исполнительной власти или органов государственных внебюджетных фондов РФ
⦁ удостоверяющих центров, получивших аккредитацию
⦁ операторов электронного документооборота, требования к которым устанавливаются ФНС России.

По общему правилу при подписании электронных документов представителем она представляется в составе пакета этих документов.

Документ: Приказ Минцифры России от 05.11.2025 № 1001.

Новые правила обслуживания лифтов в МКД:

С 1 сентября 2026 года начинает действовать закон, обязывающий привлекать для техобслуживания и ремонта лифтов только специализированные организации и ИП, включенные в федеральный реестр.
Управляющим компаниям, ТСЖ и ЖК дается 90 дней на приведение договоров в соответствие.

Лично для меня очень актуален этот закон. В нашем доме пару лет назад поменяли лифт и он постоянно ломается. Может его наконец-то нормально починят и качество обслуживания лифта повысится

Документ: Федеральный закон от 29.12.2025 № 564-ФЗ.

Что думаете об этих изменениях? Делитесь в комментариях.

Бесплатный акселератор, неожиданные грабли и куча выпитых чашек кофе: как мы проверяли гипотезы в IT‑стартапе

Привет, Хабр!

Вы когда-нибудь задумывались, почему команда опытных разработчиков, дизайнеров и QA, годами делающая успешные продукты для других, не может так же легко запустить свой? Мы тоже думали, что знаем ответ. Оказалось, что нет.

Нас четверо: бэкенд, фронтенд, дизайнер и QA. Годами работали в аутсорсе, делали понятные продукты по четким ТЗ. А потом в один день задались вопросом: "А чего это мы всё делаем проекты другим? Пора попробовать своё".

В прошлом году мы залетели в акселератор Южного IT-Парка (бесплатный, что важно). Опыт был яркий: где-то больно, где-то смешно, а где-то мы просто осознали глубину своего заблуждения.

В этом посте речь не об истории успеха. Это raw-опыт перехода из аутсорса в свой продукт и ключевые ошибки, которые мы осознали, когда привычный мир коммерческой разработки перестал работать. Надеемся, наш опыт сэкономит вам время и нервы.

Ошибка №1: Наш "MVP" оказался "MIP" (Minimum Imaginable Product)

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

Инсайт пришёл, когда ментор спросил: "Вы поговорили хоть с одним потенциальным пользователем?". Мы промолчали. Мы потратили месяц на то, что на деле было "минимально вообразимым продуктом" - тем, что мы могли вообразить и построить, а не тем, что было минимально необходимо для проверки ключевой гипотезы.

Вывод: MVP - это не про ваш технический минимум. Это про максимум неопределенности, который вы готовы закрыть одной итерацией. Теперь наша первая задача для любой фичи - не накидать макетов, а сформулировать гипотезу и придумать самый дешёвый способ её проверить (часто это даже не код, а Landing Page, опрос или эмуляция процесса).

Ошибка №2: Мы недооценили силу еженедельных дедлайнов

Акселератор - это не про деньги (по крайней мере, в нашем случае). Это про дедлайны и сообщество.

Каждую неделю нужно было показывать прогресс. Сначала мы ненавидели этот формат. Он ломает перфекционизм, заставляет выкатывать сырые фичи и признаваться, что "в этот спринт мы не угадали".

Инсайт: Привычка "идеально доделать и потом показать" убивает скорость обучения. "Криво, но сейчас" стало нашим неофициальным девизом. Эти еженедельные отчёты заставляли нас постоянно задавать себе вопросы: «Что мы узнали на этой неделе? Какая гипотеза подтвердилась? Что будем пробовать дальше?».

Ошибка №3: Мы пытались работать "как раньше"

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

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

Инсайт: Стартап - это не проект, это режим работы, где все немножко product owner и немножко предприниматель. Наша привычка "делать свою часть идеально" часто мешала сделать "целое достаточно быстро".

И что в итоге? Стоило ли оно того?

Пока не знаем.

Заработали ли мы на пачку чипсов? Нет.
Кончился ли кофе? Да, много раз.
Получили ли мы то, за чем шли?

Абсолютно да.

Мы поймали тот самый драйв - делать продукт быстро, тестировать гипотезы, спорить и мириться, и чувствовать, что это наше. Мы вышли из зоны комфорта и увидели продукт со стороны бизнеса, а не только технической реализации.

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

P.S. Если вы тоже думаете о своём продукте или уже на этом пути — делитесь в комментариях, с какими граблями столкнулись вы?

Описывайте проблему вместо конкретных рецептов

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

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

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

В своем канале о разработке в стартапах делюсь опытом, заходите, буду рад!

Берегите себя и своих коллег от рецептов, ставьте проблему и не сужайте пространство решений.

Сколько я плачу за AI инструменты и как они у меня взаимосвязаны

Claude — мой основной AI инструмент уже как 9 месяцев — Плачу за него 100$

Состоит из Claude Desktop, Claude Code UI и Claude Code CLI

Если хочу работать в приятном UI с текстом → Claude Desktop
Если работаю локально с кодом → Claude Code CLI
Если хочу поправить код с телефона → Claude Code UI

Коротко что все это такое
• Claude Desktop — как чат GPT, но с поддержкой MCP + Skills и еще всякими штуками
• Claude Code — UI для работы с вашим репозиторием
• Claude Code CLI — Command Line Interface Агент. По сути это микс Claude Desktop + Claude Code по функционалу, но без интерфейса и работает внутри вашего компьютера. Мое любимое развлечение последних двух месяцев

Claude Code CLI — пока что самый прокачанный на рынке CLI агентов

———

OpenAI, который chatGPT — за него плачу 20$

• ChatGPT UI — им почти перестал пользоваться, только ради генерации картинок иногда залетаю. Они после недавнего релиза стали их генерировать на уровне с Nano Banana
• Codex UI(Аналог Claude Code) — UI для работы с вашим репозиторием
• Codex CLI (Аналог Claude Code CLI) — чуть менее прокачанный как Command Line Interface, но зато их модель Codex 5.2 Extra-high уделывает OPUS 4.5 в плане UI дизайна и продумывания/рефакторинга сложных вещей

Но в Codex CLI вроде как отсутствует аналог ESC + ESC из Claude Code CLI для откатки написанного кода, без него тяжко жить 🍌

OpenAI недавно признали то, что их гонка с Claude за тем, чтобы сделать лучший кодинг агент, привела к тому, что 5.2 потеряли человечность в общении и стали сильно более директивными и сухими

Это помогает при работе с кодом, но общаться с ней сложнее

———

Экосистема Google — плачу 8$ за Plus подписку

Google у меня для трёх вещей: картинки через Nano Banana, NotebookLM и Antigravity для просмотра кода. Халява за 8$

• Nano Banana, иногда Veo 3 для генерации картинок / видео — лучшие генераторы картинок / видео на рынке
• NotebookLM — прикольный RAG UI, всем советую потестить
• Antigravity — Fork VS Code по типу Cursor, но с продвинутым Agent Workflow. Есть доступ к Gemini Pro + почему-то Claude моделям. Плюс Antigravity может генерировать картинки сразу вам в код через Nano Banana, такой вот бесшовный воркфлоу

Ни Gemini UI ни Gemini CLI я особо не пользуюсь. Мне они кажутся сильно сырыми по сравнению с Claude Code | GPT

———

Как выглядит мой воркфлоу

Claude Desktop для задач, где мне хочется иметь приятный UI и фичи именно Desktop интерфейса. Например написание постов, создание табличек, графиков и всего такого — те задачи, где CLI сильно проседает по UX

Claude Code UI почти не использую, только когда нужно изменить репозиторий с телефона, например на улице или в поездке

Claude Code CLI — мой day to day tool для работы с кодом. Пишу на Opus 4.5. Для сложных задач прошу создать промпт для Codex.

Antigravity юзаю для просмотра кода и папок, иногда запускаю Gemini 3 pro как третье мнение

Codex, как я уже и говорил, требует особого навыка общения. так как она может думать по 40 минут и перековырять вам весь код, но зато она у меня всегда находит те корнер кейсы, которые не находит ни Opus 4.5 ни Gemini 3 pro. По стилю общения вы будто общаетесь с Сеньёром, который вас презирает, зато резалт пушка

———

Прикольные фишки, которые я постоянно применяю

1. Через Antigravity прошу генерировать изображения со вставкой сразу в код, получается бесшовный воркфлоу Prompt => Generation => Insertion

2. Используй Claude CLI Opus 4.5 для Day to Day задач

3. Используй Codex CLI xhigh для задач на рефакторинг или поиск corner cases, он сильно тщательнее это делает

4. Планируя новую фичу, проси Claude создать локальный MD с планом, а затем Codex xhigh + Gemini 3 pro пусть покритикует этот план и напишет ниже свои комменты

5. Не забывай про кнопку ESC + ESC в Claude Code CLI

6. Claude Code CLI в начале сессии загружает себе CLAUDE.MD, Codex загружает в себя AGENTS.MD, а Gemini — GEMINI.MD.

7. Команда /context покажет контекст текущей сессии, старайся держать его как можно ниже
   Good context engineering means

Однокоренные слова, но...

Класс защиты и класс защищенности – это не одно и то же. Более того, ранжирование у них идёт в разных направлениях. Они лишь звучат похоже.

Из-за того, что эти понятия путают, получаются ситуации, когда два человека друг друга не понимают. Возникает такой конфуз на разных вебинарах и созвонах, затрагивающих обмен данными через СМЭВ.

Например, если микрофинансовой организации необходимо проводить проверку действительности паспорта заёмщика, то с этой целью её информационная система может через СМЭВ стучаться в МВД. Но просто так сходить туда нельзя – необходимо соблюсти определенные требования по информационной безопасности.

МВД требует от информационной системы подтверждения соответствия по шкале класса защищенности на уровне их ГИСа – это К1. При этом обмен данными в СМЭВ идёт по защищенной сети, участники которой используют криптосредства класса защиты КС3.

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

Так в чём разница?

Я объясню сильно по-простому и естественно это будет грубым объяснением, но достаточным для понимания различий. Данный пост написан для менеджеров, а не специалистов по информационной безопасности.

Класс защищенности (К1 > К2 > К3) – это шкала, которая применяется к государственным информационным системам (ГИСам). Чем выше число в обозначении, тем слабее. Данный класс относится ко всей информационной системе целиком (процессы, меры, средства защиты информации, сегментация, доступы, аудит, уязвимости, контроль, аттестацию и т.д.).

Определена эта шкала приказом ФСТЭК РФ от 11 апреля 2025 г. N 117 (вступает в силу с 01.03.2026 г.). Цитирую:

Самый низкий класс - третий, самый высокий - первый. Класс защищенности информационной системы (первый класс (далее - К1), второй класс (далее - К2), третий класс (далее - К3)) - определяется в зависимости от уровня значимости информации (далее - УЗ), обрабатываемой в этой информационной системе, и масштаба информационной системы.

Класс защиты (КС1 < КС2 < КС3 < КВ1 < КВ2 < КА) – это классы средств криптографической защиты информации (СКЗИ) – то есть стойкость к атаке и условия применения конкретной криптозащиты (VPN, криптошлюз, криптопровайдер, шифрование канала и т.п.), а не про защищенность всей информационной системы. И тут наоборот: чем больше цифра, тем сильнее.

Градируется класс защиты по модели атак приказами ФСБ РФ от 18 марта 2025 г. N 117 и от 27 декабря 2011 г. N 796:

• КС1 – базовый класс: атаки вне контролируемой зоны, то есть нарушитель не имеет доступа в помещение, где размещены СКЗИ;

• КС2 – сильнее: атаки в пределах контролируемой зоны, но без физического доступа к СКЗИ;

• КС3 – еще сильнее: атаки в пределах контролируемой зоны с физическим доступом нарушителя к СКЗИ;

• КВ – более высокий класс: высококвалифицированный нарушитель использующий недокументированные возможности ПО;

• КА – наивысший класс: высококвалифицированный нарушитель использующий недокументированные возможности как ПО, так и железа.

P.S.: Наличие или отсутствие циферки у "КВ" и "КА" зависит от конкретного документа и упоминаемых в них СКЗИ.

Как запомнить и не перепутать?

Средства криптозащиты это лишь часть информационной системы, тогда как второе более широкое понятие. И чтобы не запутаться, проще всего запомнить разницу по длине слова: "защита" – короткое слово, значит, узкая тематика, относящаяся к классификации СКЗИ, "защищенность" – длинное слово, то есть более широкое понятие, относящееся к классификации информационных систем.

– – –

С вами был Неминущий Никита, ведущий инженер‑программист финансового маркетплейса «Выберу.ру»

🎬 Видео с новогоднего CTF по мультиагентным системам

🎯 Что внутри:
Разбираем создание и применение AI-агентов для узких задач + настройку взаимодействия между ними

📊 Детали:
Автор: Андрей Чуян @Andrey_Chuyan
Направление: AI-инжиниринг
Сложность: 4/10
Формат: CTF (Capture The Flag)

🔗 Где смотреть:
VK - https://vk.com/video-232485571_456239027
YouTube - https://youtu.be/kVnOxzG0zEM?si=SFvBpDGOlMxrEdsf

💬 Есть вопросы?
Обсуждаем в чате → https://t.me/DebugSkills_chat

Межведомственная комиссия (МВК) по 115-ФЗ: как подать жалобу на банк или Банк России?

Межведомственная комиссия (МВК) — это второй уровень реабилитации, куда можно обратиться, если не удалось решить вопрос напрямую с банком или Банком России.

Важное правило: без прохождения первого уровня (см. посты 1 и 2) ваше заявление в МВК не примут.

Что МВК рассматривает? (Основные случаи):

1. Отказ банка в открытии счета или операции (если банк сам оставил свой отказ в силе).
2. Применение банком жестких мер (блокировка операций по п.5 ст.7.7 115-ФЗ). Это обязательный досудебный этап!
3. Отказ Банка России изменить высокий уровень риска.

Что МВК НЕ рассматривает?

Обжалованию в МВК не подлежат:

⦁ Ограничение дистанционного банковского обслуживания (интернет-банка) и блокирование банковской карты.
⦁ Отказ в выпуске или перевыпуске банковской карты.
⦁ Расторжение договора банковского счета по инициативе банка (в случае двух и более отказов в проведении операции в течение года по п. 11 ст. 7 закона № 115-ФЗ).
⦁ Длительное рассмотрение банком заявления о расторжении договора банковского счета.
⦁ Взимаемые банком комиссии и его тарифная политика.
⦁ Решения об отказе от заключения договора банковского счета (вклада) или проведения операции, принятые не по основаниям пунктов 5.2 и 11 статьи 7 закона № 115-ФЗ.
⦁ Решение об отказе в предоставлении кредита.
⦁ Отнесение Банком России клиента к группе средней степени риска.
⦁ Решения об отказе, принятые на основании пунктов 2 и 8 статьи 7.2 закона № 115-ФЗ.
⦁ Решения уполномоченных органов (например, Росфинмониторинга) о приостановлении операций.

Как подать заявление в МВК?

Заявление подается через Банк России одним из способов:
1. Через интернет-приемную ЦБ (выбрать тему «Обращение в МВК»).
2. По почте или лично в экспедицию Банка России в Москве.

Требования к заявлению:

⦁ Должно строго соответствовать Положению Банка России № 842-П.
⦁ Нужно приложить огромный пакет документов (по разным приложениям к Положению 842-П в зависимости от случая): полные данные о компании, финансовая и налоговая отчетность, сведения о контрагентах, копии всех предыдущих обращений и отказов.
⦁ Срок рассмотрения МВК: не более 20 рабочих дней + еще 3 дня на уведомление вас о решении.

Что дальше?

Решение МВК можно обжаловать в суде. Если вы одновременно подадите и в МВК, и в суд, приоритет будет у суда, а МВК откажет в рассмотрении.

Рекомендация: Подготовка заявления в МВК — сложнейшая техническая работа. Малейшая ошибка или неполный пакет документов приведет к отказу в рассмотрении. Лучше всего обратиться к опытному юристу для сохранения шанса на реабилитацию.

Привет, Хабр!

Хотел написать небольшой пост по причинам провалов проектов 1С. Но погрузился в тему, что люди пишут, и вижу, что получится неплохая статья. А пока собрал основные причины - мои, от ИИ и из Сети, и получил список. Дополняйте в комментариях. Потом в статье рассмотрю подробнее.

Сначала главные причины:

• Критичные изменения (смена руководства и т.д.)

• Отсутствие команды Заказчика, либо её невовлечённось, саботаж, отсутствие времени

• Неконтролируемая волна хотелок (НВХ)

• Неготовность к изменениям - внутренним и внешним

• Неправильный выбор подрядчика, чрезмерное доверие или недоверие.

Ещё причины, вытекающие из основных

• Непредоставление информации Заказчиком.

• Неправильный выбор продукта, разочарование в продукте, несовершенство и сложность продукта

• Отсутствие технического планирования (железо)

• Чрезмерно сжатые сроки

• Не хватает денег

• Неотлаженные бизнес-процессы

• Проблемы с данными

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

Буду благодарен всем, пополнившим коллекцию.

Еще один способ организовать рабочие чатики

Я пробовал организовывать рабочие чатики самыми разными способами: иногда просто в отдельную папочку, иногда – в папки по проектам.

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

И некоторое время назад я придумал (вряд ли я, но в моём мире – именно я), как иначе организовать рабочие чатики – по срочности.

Сделал 4 папки:
🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю
🔹Hourly – то, на что нужно посмотреть в течение часа
🔹Daily – пробежаться раз в день, узнать, что происходило
🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)

В результате стало гораздо легче ориентироваться и не отвлекаться на лишний шум.

Группировка

Грех номер один при работе с электронными таблицами — ручная группировка данных.

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

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

Как избежать ручной работы? Использовать группировку по столбцам в Google Sheets:

1. Собрать один длинный список сотрудников.

2. Добавить и заполнить столбцы Отдел и Город.

3. Преобразовать список в таблицу.

4. Нажать на стрелку рядом с названием столбца «Отдел» и выбрать «Столбец "Основание группировки"».

5. Сохранить получившийся фильтр под названием «Сотрудники по отделам».

6. Проделать аналогичную операцию для столбца «Город».

Итог: получилась одна таблица с данными и два её представления: «Сотрудники по отделам» и «Сотрудники по городам», между которыми можно переключаться в два клика.

К сожалению, в Excel такой функции нет.

Что с Релизом ?!

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

Тема релизов очень отзывается у меня и накопилось много "материала" на эту тему. В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов.
Подписывайтесь, будем вместе создавать синергию знаний !

За 15 лет в разработке я участвовал на разных ролях в создании совершенного разного типа продуктов, как по способу запуска(десктоп, веб и тд), типу поставки(desktop, saas, onprem) так и по зрелости продукта(прототип, mvp, плановое развитие зрелого продукта, полное переписывание внутренней системы крупного банка и тд и тп).

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

В этом посте расскажу одну историю. Если тема "зайдет", то подробно систематизирую все известные мне архетипы и напишу уже полноценную статью.

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

Часть, относящаяся к менеджменту релиза также удивляла как ни странно своим отсутствием и незримостью и непрозрачностью для большей части команды разработки.
Все это происходило из за сочетания типа поставки: saas (вернее отсутствия onprem поставки и строгих проверок на стороне клиентов, как говорится "все свое" ) и факта сосредоточения функций релиза в умах 1.5 человек, 0.5 из которых уже давно не относилось к отделу разработки.

Назовем такой тип релиз-менеджмента "one man release managment". Он неплохо работал, пока разработка шла по привычному процессу в рамках небольших изменений логики. Все быстро и удобно. Один человек знает и код и деплой, описывать ничего не надо, планов развертывания строить не надо, планов отката также. И ответственность тоже шарить не надо ;)

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

Всем добра и тихих релизов !

Как проводить встречи эффективно

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

Подготовка
– Избегай звонков без необходимости – большинство вопросов решаются в чате
– Не дергай “на минутку” – если прод не упал, значит, не срочно
– Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате
– Проверяй доступность участников через календарь
– Ограничивай время – 30 минут обычно хватает, 1 час — максимум
– Готовь повестку заранее: тема, пункты обсуждения, цель встречи, – уважай чужое время
– Рассылай материалы и документы до встречи
– Предупреждай об отмене или задержке как можно раньше
– Опаздываешь? Не опаздывай 🙂

Старт встречи
– Начинай вовремя – без «ждём ещё кого-то»
– Проверь комнату ожидания и список участников
– Напомни повестку – это фокусирует команду

Фасилитация
Модное слово для процесса организации групповой работы
– Держись повестки и возвращай к цели встречи
– Дай слово молчунам, притормози болтунов.
– Подводи итоги каждые 10–15 минут: «Итак, договорились, что…»
– Следи за чатом и поднятыми руками
– Делись экраном, глаза – тоже канал восприятия
– Включай камеру по возможности
– Не перебивай – сначала дослушай, потом задавай вопросы.
– Паркуй спорные темы после трёх заходов
– Уважай выделенный слот – если нужно больше времени, спроси
– Веди пост-мит в реальном времени

После встречи
– Напиши постмит, опубликуй до конца дня, тегнув участников

Качественное обновление и снижение расходов на ERP: 3 и 5 февраля ICL SOFT проведет вебинары для бизнеса

3 февраля в 11:00 руководитель отдела разработки 1С ICL SOFT Владимир Капитонов проведет вебинар на тему «Технология успеха: качественное обновление сильно доработанных решений ERP/ERPУХ». Спикер разберет пошаговую методологию безопасного перехода на современные версии ERP и ERP УХ, а также расскажет, как превратить сложное обновление в управляемый и технологичный процесс. Участие бесплатное по регистрации.

5 февраля в 11:00 руководитель отдела сопровождения 1С ICL SOFT Мария Ефремова проведет вебинар «Как сократить расходы на ERP на 30%». Участники узнают, почему стоимость владения ERP выходит из-под контроля, какие есть эффективные инструменты для снижения затрат и как спрогнозировать бюджет и повысить качество сервиса. Участие также бесплатное по регистрации.

Импортозамещение по-бразильски.  

Пост из серии «никогда бы не подумал». Если попросить назвать крупных производителей самолётов, то скорее всего (не беря советских/российских конструкторов) услышишь названия Boeing, Airbus и Embraer. И вот про последнего я всегда думал, что это какая-то европейская компания, пока не узнал, что это аббревиатура Empresa Brasileira de Aeronáutica. Стереотипно, но я в жизни бы не подумал, что именно Бразилия всего за несколько десятилетий создала одного из лидеров авиапромки.Немного оправившись от удивления, я, само собой, решил понять, как такое вообще получилось и что стало причиной такого вертикального роста:

1. Embraer начиналась как госкорпорация в 1969 году (что по меркам такой индустрии не то чтобы очень давно), которую запускало правительство и ВВС Бразилии. Там люди поняли, что зависимость от авиагигантов — дело опасное и надеятся на то, что Boeing и Airbus не будут выкручивать руки целой стране - вообще не стоит. Ну и при этом страна гигантская, и её концы надо как-то соединять, чтобы удаленные участки не оказались отрезанными от ключевых хабов и центров. Причём желательно соединять их дёшево и надёжно, так как экономическая ситуация в Бразилии не самая простая.

2. В итоге был быстро создан простой и надёжный турбовинтовой самолёт EMB 110. Модель была настолько крутой, что её начали активно покупать американцы, французы, канадцы. Особенно для того, чтобы перевозить пассажиров из малых городов и связывать хабы с малыми локациями. Самолёт был небольшим, неломким и очень рентабельным по сравнению с монстрами Boeing и Airbus. Сыграло роль правильное ТЗ. Нужно было не чудо на крыльях, а рабочий инструмент, который закроет базовые потребности перевозки. Плюс ко всему у руля проекта стоял Озорио Сильва — инженер, военный лётчик и фанат авиации, собственно, что и позволило сделать крутой продукт.

3. Колоссальный успех первой модели дал толчок к развитию компании и новым запускам. Но, как любой госаппарат, он в момент стал супергромоздким и, не смотря на все победы, столкнулся с финансовыми проблемами, высокими затратами и риском банкротства. Тогда, чтобы не хоронить такую компанию и наработанные технологии, правительство позволило приватизировать компанию, сохранив за собой право вето на некоторые решения. Частный капитал быстро переработал рабочие процессы и поменял стратегический курс.

4. Параллельно с этим между Boeing и Airbus была война гигантов. Они как одержимые пытались переплюнуть друг друга в огромных лайнерах, игнорируя небольшие самолёты. Ребята из Embraer быстро поняли, что спрос — вот он, и запустили E-Jets, которые быстро решили головную боль многих авиаперевозчиков, которым вообще не нужны были джеты на 300 мест. Принцип был похожий с первым их проектом: надёжно, дёшево и удобно для пассажиров.

5. Уже в 2000-х они пошли по пути диверсификации, продолжая работать с коммерческими самолётами, партнерились с ВВС и запустили бизнес-джеты, которые вообще были золотым дном. До сих пор направление бизнес джетов имеет огромную маржинальность.

6. При этом, будучи в стране с крайне непростой экономической ситуацией, они активно внедряли lean (бережливое производство), так как надо было добиваться крутого качества за приемлемые деньги. Таким образом, они стали одними одними из амбассадоров концепта lean (не все Тойотой единой)

Вот так вот. По итогу Embraer устроил такой забег: от госкорпорации ради импортозамещения, через приватизацию, до корпорации, которая по разным типам самолётов держит от 40% до 70% рынка и продолжает уверенно развиваться.

Всем кому было интересно читать и кто хочет больше узнавать про бизнес и менеджмент - зову на свой канал

Высокий уровень риска ЦБ: как оспорить статус в Банке России самостоятельно?

Ситуация: Банк России через платформу «Знай своего клиента» (ЗСК) присвоил вашей компании или ИП высокий уровень риска. Ключевой момент: банк, где у вас счет, еще не применил из-за этого жесткие меры (блокировку операций).

Важно: Если банк уже применил меры (заблокировал счет), обжаловать нужно именно их действия, а не статус в ЦБ. Это другой алгоритм (см. следующий пост).

ШАГ 1: Проверьте свой статус.

⦁ Узнать, попали ли вы в список высокорисковых, можно через специальный сервис на сайте Банка России.

ШАГ 2: Подайте заявление о пересмотре уровня риска напрямую в Банк России.

⦁ Это можно сделать через интернет-приемную на сайте ЦБ, выбрав тему «Обращение в Банк России о пересмотре высокого уровня риска».

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

⦁ Срок ответа Банка России: 15 рабочих дней с момента получения заявления.

Возможные решения ЦБ:

⦁ Принять решение об изменении уровня риска. Поздравляем, проблема решена на первом уровне.

⦁ Оставить свое решение в силе (отказать в изменении статуса).

Что дальше?

Если Банк России отказал, у вас есть право в течение 6 месяцев обжаловать этот отказ в Межведомственную комиссию (МВК) или сразу обратиться в суд.

Рекомендация: Требования к заявлению в ЦБ строго регламентированы (Указание № 6853-У). Неправильно составленное обращение приведут к отказу. Лучше всего обратиться к опытному юристу для подготовки убедительного и технически грамотного пакета документов, чтобы с первого раза добиться снятия статуса.

Количественные и качественные индикаторы достижения Product-Market Fit

Product-Market Fit (PMF) — это качественное состояние продукта, которое невозможно измерить какой-то одной метрикой. Однако его достижение или приближение к нему можно верифицировать с помощью комплекса исследований и ключевых показателей.

1. Качественные исследования или «Тест на сожаление»

Довольно информативный метод - опрос существующих клиентов. Анкетирование следует проводить сегментированно, отдельно анализируя ответы первичных и повторно покупающих пользователей.

Ключевой вопрос: «Насколько вы были бы разочарованы, если бы этот продукт перестал существовать?»
Варианты ответов: «Очень разочарован», «Немного разочарован», «Не разочарован» (или аналогичная шкала).

Интерпретация: Если доля респондентов, ответивших «Очень разочарован», составляет 40% и более, это считается ярким сигналом наличия PMF.

2. Индекс лояльности (Net Promoter Score, NPS)

NPS измеряет готовность клиентов рекомендовать ваш продукт другим людям. Методология предполагает оценку по 10-балльной шкале в ответ на вопрос: «Насколько вероятно, что вы порекомендуете наш продукт коллеге или знакомому?»

• Сторонники (Promoters): 9-10 баллов.

• Нейтралы (Passives): 7-8 баллов.

• Критики (Detractors): 0-6 баллов.

Расчёт: NPS = (% Сторонников) – (% Критиков).

Интерпретация: Положительный и растущий NPS указывает на формирование лояльности, что является косвенным признаком PMF. Высокий NPS (>30) часто коррелирует с устойчивым ростом.

3. Коэффициент удержания (Retention Rate)

PMF проявляется в формировании устойчивой привычки использования продукта. Необходимо анализировать не общее число пользователей, а процент клиентов, которые продолжают активно пользоваться продуктом или совершают повторные покупки через определенные промежутки времени (например, через 1, 3, 6 месяцев).

Интерпретация: Кривая удержания со временем должна выходить на «плато», демонстрируя, что значительная часть пользователей нашла в продукте непреходящую ценность. Отсутствие резкого спада — ключевой индикатор.

4. Операционные и бизнес-метрики роста

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

• Устойчивый рост ключевых метрик (выручки, числа клиентов) без пропорционального увеличения маркетинговых затрат (CAC).

• Высокая конверсия на всех этапах воронки, особенно из лида в платящего клиента.

• Превышение жизненной ценности клиента (LTV) над стоимостью его привлечения (CAC) в 3 и более раза.

• Возникновение органических каналов роста: "сарафан", прямые заходы, упоминания в профильных сообществах.

• Операционная масштабируемость: поток заказов/запросов начинает требовать расширения команды и оптимизации процессов. Иными словами, проснулись, и поняли - уже не справляемся с потоком заявок. Это точно "оно!"

Заключение
PMF - это зона, вход в которую подтверждается конвергенцией сразу нескольких сигналов: высокие качественные оценки пользователей, растущая лояльность (NPS), здоровая кривая удержания и, как следствие, — устойчивая и эффективная с точки зрения unit-экономики модель роста. Системный мониторинг этих индикаторов позволяет командам объективно оценивать прогресс на пути к рыночному фитнесу.

Почему IT продукты дорожают но их реальная ценность падает?

Почему так происходит и справедливо ли это по отношению к пользователю?

Почему IT продукты дорожают
Есть инфляция и другие экономические причины.
Но, на мой взгляд, есть еще одна причина – псевдоценности.

Продукты обрастают фичами, становятся сложнее и неповоротливее. Растут и издержки бизнеса на его поддержку/развитие. Продукт подорожал не потому, что стал лучше для пользователя, а потому что в нем появилось 50 дополнительных фич. И эти фичи нам предлагают как ценности. Что же с ними не так? 

Почему падает реальная ценность
Ценность продукта построена на механиках и фичах
Некоторые фичи дают реальную ценность, возможно не именно нам, но дают. Некоторые дают ценность, но не там где нужно (супер аппы).
А вот фичи с псевдоценностями просто есть и дают только прирост цифр бизнесу.

Как же их тогда покупают?
Их не покупают – Бизнес строит модель +фича +деньги за нее, а пользователь ей не пользуется. Он пользуется тем за что выбрал продукт, но платит больше.

Продают обманом – Бизнес выстраивает маркетинг на псевдоценностях. Для этого он подменяет понятия и запутывает клиента, чтобы он не понял что эта фича несет ценность только для бизнеса, а для него нет. И ведь это не всегда происходит осознано! Иногда бизнес обманывает и сам себя выпуская таки фичи в релиз (.
Не будем упоминать недобросовестное списание денег по причине "потому что мы так решили"

Но самое абсурдное это когда бизнес решает проблему которую сам и создал :(

Пример
В пятёрочке постоянно крутят объявления в аудио формате. Недавно я услышал такую запись – пятерочка заботится о вас, поэтому мы дарим вам пять минут тишины. Сами создали проблему, сами ее решили, а выдают за ценность.

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

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

Вывода в этом посте нет, этот просто открытое рассуждение.

Что думаете об этой проблеме и с чем сталкивались? Делитесь в комментариях 👇

Если хотите упаковать ценности вашего продукта качественно, записывайтесь на бесплатную консультацию, тут на Хабре https://career.habr.com/product-unit

Как понять, к чему мы стремимся?

Всегда ли техническая стратегия очевидна с самого начала? Может ли простой инженер с крутой идеей переубедить топ-менеджеров? Стоит ли идти напролом, если уверен в своей правоте? Как «продать» идею внутри компании и где искать вдохновение для неё?

Гость нового выпуска подкаста «Свободный слот» — Анатолий Панов, CTO Яндекс Карт. Вместе с ведущими Пашей Федотовым и Сашей Афёновым обсуждаем, по каким признакам понять, что пора создавать техническую стратегию. Говорим также о смелом решении — смене основного стека технологий в компании — и о том, как его выигрышно провести. А в финале выясняем, кого в первую очередь нужно убедить в стратегии и какие процессы в итоге должны поменяться.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.