Менеджмент

Проведенные исследования показывают, что во время создания ИТ-продуктов могут материализоваться 105 универсальных рисков. Также было обнаружено, что одним из критериев зрелости ИТ-субъекта является наличие результативных и эффективных мер превентивного воздействия на данные риски. Цель: проведение анализа ранее выявленных универсальных рисков, возникающих во время создания ИТ-продуктов в рамках выполнения спринтов, фаз жизненного цикла ИТ-проектов и (или) контрактов. Методы: теория управления рисками и ИТ-проектами. Анализ универсальных рисков был осуществлен с помощью методов 5W, SWIFT и коэффициентов Харрингтона. Результаты: ИТ-субъект должен заблаговременно, до заключения контракта, проводить экспресс-оценку универсальных рисков и превентивно воздействовать на них, в том числе за счет формализации в тексте контракта действий и (или) бездействий, которые должны выполнять заинтересованные стороны для элиминирования наиболее опасных рисков. Также были разработаны схемы причинно-следственных связей универсальных комплаенс- и проектных рисков, что позволило выявить часто встречаемые и наиболее опасные рисковые события. Благодаря созданным схемам был идентифицирован негативный сценарий, который продемонстрировал наихудший вариант развития событий во время выполнения ИТ-проектов. Данный сценарий дает возможность ИТ-субъектам заблаговременно разрабатывать меры «достойного» принятия рисков, не допуская наступления наиболее радикального исхода.

План проекта, фокус-фактор, управление бэклогом, гайды по канбану, НФТ, управление изменениями, неэффективная эффективность и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Мой путь в IT начался в 2007-м. Тогда мир ломался: появился первый iPhone, соцсети обещали демократию, а я, верил, что код - это новая латынь, универсальный язык силы. Я ошибался. Код был лишь алфавитом. Настоящая сила заключалась в том, чтобы заставить этот код писать, продавать и нести за него ответственность других людей.

Рынки переживают всплеск интереса к компаниям, связанным с искусственным интеллектом — во многом схожий с ажиотажем вокруг электромобилей (EV) несколькими годами ранее. Тогда почти каждый новый EV-стартап быстро оказывался в фокусе инвесторов и медиа, зачастую ещё до появления устойчивой бизнес-модели.

Опыт EV-бума позволяет рассмотреть как эволюцию технологических идей, так и поведение инвесторов в периоды массового ожидания прорыва. Показательно, что сами электромобили вовсе не являются чем-то новым: первый электрический экипаж был создан в 1832 году — почти за полвека до автомобиля с двигателем внутреннего сгорания (ICEV).

В этой заметке описана концепция организации производства ПО «Merge Request как транзакция изменения системы, и где в ней возникает eventual consistency». Описывается идея, что МР должен содержать полный список изменений по каждой таске, какие плюсы и минусы этой концепции свойственны а также как её внедрять.

Привет, меня зовут Юля, я тимлид VIP‑поддержки в МТС Линк. Подобная работа, связанная с большим объемом коммуникаций, идеальна для выгорания. Так, например, нам может прилететь одновременно несколько обращений от разных клиентов с высокой степенью срочности, необходимостью глубокого погружения и поиска нетривиальных способов решения. В таких ситуациях замедляется первая и последующие реакции сотрудника, а выгорание и усталость приближается с космической скоростью. 

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

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

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

Очень часто, когда обсуждают подходы к проектированию и проектному управлению проводят аналогии со строительством или машиностроением. Не стала исключением и моя статья про аджайл https://habr.com/ru/articles/972230/
Конечно всякие аналогии имеют свои границы применимости, но в случае сравнения строительства и разработки ПО об этой границе забывают. Между тем она есть и даже люди далекие и от первого и от второго быстро поймут эту разницу, если просто о ней написать.
Основная разница заключается в сравнении стоимости проектирования и создания итогового продукта. Для сравнения я также решил привести пример из машиностроения с созданием серийного продукта. Имеются фундаментальные различия экономических моделей этих отраслей в аспекте тиражирования решений и распределения стоимости по этапам жизненного цикла.

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

В 2020–2021 годах казалось, что Agile-коуч нужен каждой компании. Стартапы, корпорации, банки, ритейл, госсектор одновременно приобщались к Agile: нанимали коучей, запускали трансформации и рисовали красивые роадмапы изменений.

А дальше что-то пошло не так.

С 2023 года вакансий стало меньше, требования ужесточились, а бюджеты начали сжиматься. И в комьюнити всё громче зазвучали вопросы: «Agile умирает или ��то взросление? А что будет с профессией Agile Coach дальше?».

Привет, Хабр! Меня зовут Константин Левкин, я Head of Agile в Райффайзен Банке. Не смог пройти мимо этой темы и решил основательно разобраться и собрать факты о том, что происходило в последние годы. Как изменился рынок труда, что происходит с зарплатами, ролями, какие региональные различия возникают и есть реальные результаты прошедших трансформаций. Хочу поделиться нарытыми данными и выводами на их основе. Совсем далёкие прогнозы в наши нестабильные времена делать опрометчиво, поэтому ограничусь своим видением изменений в профессии Agile Coach до 2029 года.

Во многих местах статьи есть умышленный уклон на данные рынка США, так как многие тренды в IT проходят путь США-Европа-Россия за 2-3 года. То есть та реальность и те данные в отчетах по рынку США сегодня, вполне могут стать нашей реальностью через пару лет.

Если сильно упростить, Agile прошёл тот же путь, что и многие управленческие идеи до него.

2019–2020
Agile это про команды. Scrum, спринты, ретроспективы, velocity.
Agile-коуч — это фасилитатор и тренер.

2021–2022
Рынок перегревается. Спрос растёт быстрее качества. Зарплаты Agile-коучей в США за два года вырастают на 30–50%.

Когда я был разработчиком, мне казалось, что оценивать задачи просто. Я знал код, понимал проект и верил, что 40-часовая неделя — надёжная рамка, в которую помещается всё нужное. 

Реальность быстро показала обратное. В каждом спринте оставались незакрытые задачи, сроки сдвигались, а чувство «я где-то ошибся» становилось постоянным фоном — даже если работал честно и много.

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

Со временем мои оценки стали точнее. Но став тимлидом, я понял простую вещь: проблема не в людях и не в оценках.

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

Привет! Меня зовут Виталий, и я управляю проектами в KTS. 

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

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

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

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

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

Сегодня попробую рассказать о решении, которым сам пользуюсь, а именно про применение Structure.

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

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

Новая история от продуктового лидера, который строил-строил лояльность в продукте, да так и не достроил.

Спойлеры:

3 измерения: Потребность → Цель → Мотивация 

5 типов клиентов (неприбыльные, пленники, новые, постоянные, лояльные) 

Формула пленников

Правило 70/30 для драйверов мотивации 

3 грабли, которые стоит избежать 

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

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

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

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

Меня зовут Евгений Иванов, я Agile Cluster Lead кластера Облачные технологии в компании MWS Cloud — команды, которая создала MWS Cloud Platform. И в этой статье я расскажу, почему мы считаем наш кластер анклавом процессных практик и какие плюшки и сложности мы с этого имеем. На тему наших процессов мой коллега Саша Стерлигов уже написал подробную статью. Почитайте.

В начале декабря прошла шестая большая IT-конференция — ЮMoneyDay, на которой эксперты ЮMoney делились, как устроен финтех под капотом. К событию подключилось более 1000 слушателей. В этой статье мы подводим итоги конференции и рассказываем об её обратной стороне: зачем спикерам без опыта нужен бизнес-тренер, как выступать после дыхательной практики и почему стресс — тоже тема для IT-доклада.