Управление проектами *

Формулы Microsoft Excel позволяют мгновенно и без ошибок производить сложнейшие расчеты. Их ценность возрастает в разы, когда приходится работать с огромными массивами данных. Стоит запустить правильный алгоритм, и Excel за считаные секунды перелопатит тонны информации, выдав готовый результат.

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

Привет, Хабр! Я Максим, руковожу разработкой систем наблюдаемости и надежности в ижевском ИТ-хабе Т-Банка. Моя статья — часть проекта «20 в 20», в котором мы рассказываем о региональных ИТ-хабах и о том, как в них растут команды и инженерные практики.

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

Так появился Sage Observability — платформа, через которую мы видим состояние всего ИТ-стека: от инфраструктуры до бизнес-метрик, клиентских приложений и инцидентов.

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

Рассказываю свою историю, добро пожаловать под кат!

В современной разработке компоненты с открытым исходным кодом (Open Source Software, OSS) стали абсолютным стандартом. От небольших библиотек до целых фреймворков вроде Spring или Hibernate — FOSS (Free and Open Source Software) значительно ускоряет разработку и снижает издержки.

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

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

Каждый ноет на ретро. Мы научились ныть так, что работать стало комфортнее и эффективнее. В статье расскажу, что нам помогло.

Хороший разработчик не всегда становится хорошим тимлидом. Управление людьми требует совсем других навыков: делегирования, обратной связи, лидерства и эмоционального интеллекта. В этой подборке — восемь книг, которые стоит прочитать до перехода в менеджмент. Одни помогут подготовиться к новой роли, другие позволят понять, действительно ли она вам нужна.

Допустим, вы разработчик. Вам в Jira прилетает задача — сделать на странице пользователя кнопку «Дать денег». Вы делаете кнопку, она появляется на странице, нажимается, запрос уходит на бэк, бэк отвечает 200 OK. Технически все выполнено верно, но заказчик недоволен и вопрошает: «Я уже пять раз нажал на кнопку, почему деньги так и не пришли?».

И где-то между «в ТЗ было написано просто добавить кнопку» и «давайте срочно переделаем фичу до релиза, перепишем кнопку на тумблер и подрубим биллинг» возникает вопрос: кто виноват и почему именно аналитик?

Привет, Хабр. Я Арина, системный аналитик в Selectel. Я пишу требования к внутренним сервисам, ботам, интеграциям и прочим штукам, которые сначала кажутся маленькими, а потом обрастают ролями, статусами, ретраями, правами доступами и фразой «а это точно MVP?». 

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

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

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

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

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

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

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

Все цены и условия — по публичным данным на официальных сайтах на начало июня 2026.

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

С марта 2022-го из России стремительно исчезают иностранные компании. Большинство зарубежных вендоров, включая Atlassian, Microsoft, Notion и Wrike, перестали продавать лицензии и продлевать подписки. Несмотря на это, около 70% российских компаний продолжают сидеть на серых джирах.

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

В статье — подробный обзор Аспро.Cloud, YouGile, Мегаплан, Битрикс24 и Планфикс. Расскажем про возможности каждой системы и дадим советы по выбору. В конце — сравнение CRM для управления проектами в удобной таблице для быстрого принятия решения.

Расширенная версия моего кейноута на ISC.AI 2026 в Пекине. Фреймворк и инструмент открыты — берите, ломайте и присылайте мне, что найдёте.

Привет! Меня зовут Андрей Терёхин, я руковожу маркетингом в Projecto. 

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

В статье расскажу об Arctic Trucks — международному бренду по тюнингу автомобилей, который работает в России уже 16 лет, — и о том, как они переехали в систему управления проектами, какие проблемы решили и что поменялось в их работе.

Однажды я зашёл в компанию через неделю после крупного падения и попросил показать постмортем. Мне показали — с гордостью. Таймлайн поминутно, five whys, аккуратный список action items, owner напротив каждого, разослано по всем спискам. Красиво. «Видите, мы серьёзно подошли».

Я задал один вопрос: а постмортем по прошлому такому же падению — где? Нашли. Открыли. Те же action items. Слово в слово. С прошлого раза не закрыт ни один.

То есть полгода назад уже собирались, уже всё проанализировали, уже назначили ответственных — и ничего не сделали. А потом упало снова, по той же причине, и они снова собрались, снова проанализировали, снова назначили. С тем же результатом, который будет и в следующий раз.

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

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

Привет, Хабр! На связи Наталья Воронько из РТЛабс. Я RTE Аналитической Платформы и ЕЛК, а в прошлом — руководитель проектов и функциональный руководитель. Сегодня хочу поделиться своим взглядом на новую редакцию PMBOK® Guide от Project Management Institute (PMI).

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

Официального русского перевода PMBOK® Guide 8^th edition у меня нет. Я читала английскую версию, поэтому некоторые термины могут отличаться от будущего официального перевода. Для точности буду указывать в скобках оригинальные названия и термины.

Ссылки на информацию о Стандарте и на другие источники института PMI буду прикладывать, но открываются они только с помощью VPN.

Всем привет! Я Светлана Забирова, лид аналитики в Центре разработки и машинного обучения компании «Инфосистемы Джет». В ИТ работаю уже больше десяти лет, из них половину – в заказной разработке.

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

По заданному контексту ИИ хорошо справляются с кодом, миграциями, OpenAPI, сценариями и документацией. Но агентная разработка быстро начинает буксовать, если входной артефакт остается большой постановкой в Confluence, Word или Jira без строгой структуры и трассировки. Модель теряет важные условия, смешивает уровни детализации, дублирует требования или додумывает недостающие связи.

ИИ не будет работать лучше, если аналитики просто «начнут промптить». Задача решается уровнем выше: требования должны стать инженерным артефактом. То есть относиться к требованиям нужно так же, как разработчики относятся к коду.

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

Мы решили проверить подход на одном из пилотных проектов, где было все: аналитика, архитектура, backend/frontend-разработка, тестирование и DevOps.

Как мы перевели аналитику из Confluence/Word в SDD-контур и что из этого получилось, рассказываю под катом.

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

В ИТ ошибка во входных данных обычно ведёт себя честно. Неверный тип, некорректный формат, нарушенная схема — система останавливает выполнение и показывает, что именно пошло не так. На складе всё гораздо коварнее: ошибка в данных не падает в лог, а уезжает в операционный контур, где превращается в лишние перемещения, недогруз, пересборку паллет и сбой в отгрузке.

Именно поэтому принцип GIGO — garbage in, garbage out, «мусор на входе — мусор на выходе» — в логистике звучит особенно буквально. Если в мастер-данные попал неверный габарит товара, WMS не начнёт спорить с пользователем. Она просто будет добросовестно рассчитывать всё дальше на основе неправильной цифровой модели.

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

Есть много типологий сотрудников, но мне очень нравится модель Айсберг, потому что в ней только два критерия и главное она помогает понять руководителю не только как работает сотрудник, но и увидеть свои ошибки в управлении.
Итак, модель Айсберг включает два критерия:
1. сколько обещает сотрудник сделать;
2. сколько реально сотрудник делает.
и по соотношению этих двух показателей можно легко определить, кто есть кто в вашей команде и что необходимо изменить вам как руководителю в своей деятельности.

1.тип сотрудника. "Много обещает/Мало делает."
Деструктивный тип личности. Red flag.

Что делаем с таким сотрудником:
Выясняем почему нет результата, даём возможность исправить модель поведения.
Если ничего не меняется - увольняем.
Обычно команда бывает очень рада избавиться от такого коллеги, так как они за него/неё всё делали.

2.тип сотрудника "Сколько обещает/столько и делает"
Адекватный человек.
Тут может быть вопрос в мотивации сотрудника.

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

3.тип сотрудника "Мало обещает/много делает"
Это золотой фонд команды, талантливый сотрудник.
Но это может быть звоночек для руководителя, почему сотрудник не сообщает о своей деятельности, может он предлагал варианты улучшения, но его не слушали и он решил, что проще ничего не говорить, а просто делать.

MAGNIT TECH — это технологическое ядро крупнейшей розничной сети страны. Более 5 000 инженеров, аналитиков и продуктовых команд разрабатывают, поддерживают и масштабируют свыше 260 ИТ-продуктов и проектов, а также 800 информационных систем — от алгоритмов прогнозирования спроса в 33 000 магазинах до касс самообслуживания с собственным ПО. 

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

Привет! Меня зовут Евгений, я работаю в БКС Мир инвестиций владельцем сервиса «Портфель».

Если объяснять просто, «Портфель» — это раздел, где клиент смотрит свои активы: деньги, ценные бумаги, валюту, фонды, облигации, фьючерсы, финансовый результат и общую картину по инвестициям.

Для клиента это обычный экран в приложении или личном кабинете. Открыл, посмотрел, что происходит с деньгами, принял какое‑то решение.

Но внутри компании за этим экраном стоит много всего. Backend‑сервисы, frontend, интеграции, биржевые данные, банковские продукты, сетевой путь, мониторинги, SLA, обращения клиентов в контактный центр, поддержка, аналитика, релизы и ожидания бизнеса.

На стыке всего этого и появляется роль Service Owner.

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

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

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

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

Всем привет! Меня зовут Константин Ушенин, я — ведущий научный сотрудник в AIRI, занимаюсь приложениями искусственного интеллекта в химии и фармакологии. В конце марта 2026 года мы с коллегами выиграли суточный хакатон от Сбера, ИТМО и СПБ ГБУ Молодёжного пространства «ПРОСТО» по созданию ИИ‑ассистента для планирования синтеза в лаборатории органической химии. Мероприятие прошло три месяца назад, однако мы завершили рефлексию результата только сейчас и решили сделать полный разбор.

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

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

В общем, получилось довольно остросюжетно, приятного чтения!