Менеджмент

Всем привет! Меня зовут Роман, я руковожу разработкой. Когда‑то начинал разработчиком, потом тимлид, сейчас управляю лидами.

В моём багаже опыта — работа работа в интеграторе, потом в небольшой компании из сферы SMS‑маркетинга, череда позиций в in‑house разработке в разных отраслях. А сейчас я снова в айтишечке, в заказной разработке.

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

Казалось бы, инструментов хватает: Jira, YouTrack, Trello, GitLab, Confluence и ещё десятки. Но если копнуть глубже, становится понятно: каждый из них решает только кусочек головоломки. Целостной картины всё равно нет. Она появляется только в голове после погружения, но и тут засада — голов в проекте много, и у каждой своя картинка.

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

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

Вроде бы работа кипит, команда старается, вы делаете всё по процессам, но в ответ — постоянное ворчание, претензии и недовольство. «Почему вы не предупредили?», «Я думал, всё будет иначе!», «Это слишком долго и дорого».

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

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

Продуктовые роли не появились из воздуха. Их не придумали с нуля бородатые дядьки в Долине или выглаженные воротнички из Купертино. Профессии Product/Project Owner/Manager выстраивались на протяжении почти столетия — и всё ради того, чтобы сейчас мы с вами плевались, читая вакансии на хедхантере. Кто главнее: PM или PO? Что должен делать проджект? И что ещё за AI PM и Data PM?

Давайте разбираться. И копнём аж до начала прошлого века.

Что делать, когда у тебя есть €20,000 гранта на маркетинг, новый сложный SaaS-продукт (конструктор Mini Apps), и ноль данных о том, как привлекать клиентов? Мы решили использовать этот бюджет не на погоню за ROI, а на полноценный R&D в Telegram Ads. В этой статье — подробный лог нашего эксперимента. Мы разберем, почему воронка через сайт с треском провалилась (€69 за регистрацию), как мы научились отличать «хороших» подписчиков от «плохих» на глаз, и почему самый дорогой на входе бот может оказаться самым перспективным.

Привет, Хабр. Меня зовут Алексей Бруевич, я руковожу продуктовой разработкой в Почте Mail. Хочу рассказать о граблях, на которые наступал в своей карьере я и команды разного уровня зрелости под моим руководством. То есть расскажу об антипаттернах, с которыми вы можете столкнуться, и как их можно преодолеть, чтобы успешно запускать проекты.

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

Похожие посты выходят ежедневно в моем Telegram канале!

Что такое «ретроспективный день»

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

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

У каждого в компании свой фетиш: кто-то мечтает об очередной «железке» из правого верхнего угла квадранта Гартнера, а кто-то — о снижении издержек и росте маржи. Одни играют в «поставим DLP — и пусть будет», другие считают: «Если это не приносит доход, то зачем вообще тратить?» В этой статье разберемся, почему CEO и CFO смотрят на кибербез не как на «щит и меч», а как на статью расходов с непонятной рентабельностью. И как безопасникам перестать быть невидимыми самураями, и начать приносить бизнесу реальную, понятную и осязаемую пользу. С цифрами, доводами и без капчи.

Привет, Хабр! Меня зовут Алексей Лукацкий и последние три года я работаю в Positive Technologies бизнес-консультантом по безопасности и Chief Evangelist Officer. До этого больше 18 лет проработал в CISCO. За свою карьеру совмещал множество ролей, я — программист, админ, аудитор, маркетолог, продавец, консультант, преподаватель, rCISO, писатель и ИТ-евангелист. Автор проекта «Бизнес без опасности, написал пять книг и больше 30 курсов по ИБ. А в кибербезе уже, страшно сказать, больше 30 лет.

Настало время покопаться в шедеврах мировой классики, и выискать там Agile. Мой взгляд сразу упал на любимицу дам Джейн Остин и её «Гордость и предубеждение», потому что это идеальная иллюстрация Agile, как «из книжек», в котором есть и непрерывная обратная связь, итеративность, ретроспектива, реагирование на изменения, и успешное завершение трудного проекта. Всё как мы любим.

Решаем общую проблему всех команд — перегруженность задачами при ограниченных ресурсах на примерах:

Учимся интуитивно отделять важное от второстепенного.

Решаем общую проблему всех команд — перегруженность задачами при ограниченных ресурсах на примерах:

Составляем беклог продукта. 

Планируем спринт.

Решаем личные задачи.

Сравниваем MoSCoW другими методами, RICE, ICE, Kano и Buy a Feature.

Искусственный интеллект (ИИ) призван помогать человеку выполнять самые разные задачи, особенно рутинные и однотипные. А в бизнесе таких полно, значит, автоматизировать рабочие операции и делегировать их ИИ сам Бог велел. На рынке регулярно появляются новые решения как специализированные, так и универсальные. Казалось бы, здорово — экономия времени и ресурсов, повышение качества работы. Но ИИ вовсе не так умен, как многие могут подумать. В этой статье я предлагаю обсудить, в каких сферах от «текущего ИИ» есть польза, а в каких — нет, а также поговорить о тех деформациях и проблемах, которые создает новая технология для бизнеса. Материал — попытка объективно взглянуть на нейросети и предназначен больше для руководителей, нежели технических специалистов.

Не тот, кем кажется

Сам вопрос «Где уместно применять ИИ?» возникает потому, что люди ожидают от искусственного интеллекта именно интеллекта. Люди его очеловечивают, наделяют антропоморфными качествами. На самом же деле искусственный интеллект не умеет рассуждать, самостоятельно в чем-то разбираться, проявлять инициативу. Современный генеративный ИИ лишь предугадывает наиболее вероятные следующие события (слово, ноту, пиксель), а это — чисто математический процесс.

Я был удивлен, но даже люди, обучающиеся цифровизации, нередко считают ИИ самостоятельным. Например, некоторые предлагают поручить GenAI управление производственным станком в надежде, что машина сама разберется в чертежах. Нет, я не спорю, не исключено, что антропоморфных роботов люди будут считать полноценными членами семьи — подобное давно можно найти в художественной литературе и кинематографе. Возможно, это и произойдет, но точно не в ближайший год-два. Пока же у генеративного ИИ — множество ограничений. Но упаковать его в продукт и использовать во благо бизнеса, впрочем, можно.

Всем привет!

На связи Дмитрий Углев, ex‑руководитель группы инженеров по применению продукции (presale‑инженеров) компании «Прософт‑Системы», которая работает в сфере автоматизации промышленных объектов.

В данной статье я хочу поделиться с уважаемой публикой своими мыслями относительно пресейла в АСУТП, а именно его продуктового и проектного направлений.

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

Сразу оговорюсь, что моя точка зрения относится к автоматизации любой отрасли, кроме электроэнергетики, в которой я не имею опыта работы. И еще: смею предположить, что нижеприведенные мысли можно распространить и на сферу ИТ/ИБ.

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

Как у пилота, у нас есть разные показатели: одни помогают удерживать курс, например lead time и cycle time, другие вовремя указывают на критические отклонения, а третьи позволяют заранее увидеть «турбулентность» и предсказать риски срыва сроков.

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

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

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

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

Почему ChatGPT врет вам в лицо (и как OpenAI наконец объяснила, откуда берутся галлюцинации ИИ)

Статья по горячим следам сенсационного исследования OpenAI от 4 сентября 2025

Ваша модель только что выдала вам три разных неверных даты рождения одного человека. В десятом туре подсчета букв в слове "DEEPSEEK" она называет цифры от 2 до 7, хотя правильный ответ - 1. Знакомо?

Раньше мы думали: «Ну, технологии, что поделать, дообучат - и все наладится». Оказалось - нет. Галлюцинации - это не баг, а математическая неизбежность, заложенная в сам процесс обучения.

4 сентября OpenAI опубликовала революционное исследование "Why Language Models Hallucinate", которое переворачивает представление о главной головной боли современного ИИ. Впервые математически доказано: модели врут не из-за плохих данных или недоработок архитектуры. Они врут, потому что мы сами их этому учим.

В своей статье я разбираю это исследование без воды и объясняю простыми словами:

✅ Почему формула «ошибки генерации ≥ 2 × ошибки классификации» объясняет все галлюцинации
✅ Что такое singleton rate и почему 20% редких фактов = минимум 20% вранья
✅ Как система оценки превратила ИИ в вечных студентов на экзамене, где лучше соврать, чем признаться в незнании
✅ 4 конкретных способа от OpenAI, как сделать модели честными уже сегодня

Самое шокирующее: проблема решается не улучшением технологий, а изменением того, как мы спрашиваем и оцениваем ответы.

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

Готовы перестать быть жертвой красивой лжи и начать строить по-настоящему надежные ИИ-системы?

Мой канал

Бережливое производство (Lean Production) – это подход к управлению, нацеленный на максимизацию ценности для клиента при одновременном устранении потерь. Его корни лежат в производственной системе Toyota, где были разработаны многие из инструментов, о которых пойдет речь.

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

Частенько тимлидов беспокоит одна ситуация: команда из кросс-функциональных специалистов собирается решить важный вопрос, а процесс превращается в бесконечный спор. Каждый тянет одеяло на себя, вето любого участника способно затормозить прогресс, и в итоге решение либо принимается слишком долго, либо вообще откладывается. В поисках способа ускорить принятие решений и при этом учитывать мнение каждого, естьподход под названием Sociocracy 3.0 (S3). Сегодня я расскажу, что это за методика, как она помогает командам принимать решения на основе согласия без бесконечных обсуждений и вето, и как её можно пилотно опробовать в проекте.

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

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