Менеджмент

Рынки переживают всплеск интереса к компаниям, связанным с искусственным интеллектом — во многом схожий с ажиотажем вокруг электромобилей (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-доклада.

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

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

А я сажаю рядом Оппонента и даю ему возможность пару раз оспорить каждое правило.

Привет, я Владимир Князев, Agile-коуч трайба HR Tech в ОТП. В прошлом году мы активно собирали новые команды. Наш трайб вырос почти в три раза: с 13 до 38 человек. У новых ребят в команде было много вопросов о том, кто за что отвечает и к кому идти, если коллега в отпуске или заболел.

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

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

Что-то фундаментально не так с индустрией. Может она повзрослела, а я нет.

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