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

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

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

Вмире стартапов назревает сдвиг: классический подход Minimum Viable Product (MVP) больше не гарантирует успеха. Если раньше пользователи были готовы мириться с сырыми прототипами, которые «просто работали», то в 2025 году планка качества поднялась так высоко, что одной лишь функциональности уже недостаточно. Современные пользователи ожидают продуманный и приятный UX с первого касания — продукт должен не только работать, но и вызывать восторг. Здесь на сцену выходит концепция Minimum Lovable Product (MLP): стратегия запуска, ориентированная на создание любимого продукта с первого дня. Разберёмся, почему MVP теряет актуальность, чем отличается MLP и как компаниям адаптироваться, чтобы завоёвывать сердца пользователей в 2025 году.

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

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

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

Итак, поехали!

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

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

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

Много о рисках проекта, стори-пойнты и почему они не работают, обзор ИСУП, пирамида Минто и FFF, приоритезация бэклога и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

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

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

Но для начала я напомню суть модели архитектуры TOGAF.

Что делать, если ваш руководитель не может найти для вас 5 минут?

Привет, Хабр! Меня зовут Мария Архипова, я работаю в департаменте информационных технологий РСХБ-Интех и активно занимаюсь развитием soft skills в ИТ. Иногда ИТ-специалисты сталкиваются с трудностями в коммуникации как внутри своих команд, так и с другими отделами. Я начала исследовать различные подходы к улучшению коммуникаций на примере своей команды в РСХБ и в этой статье хочу поделиться опытом.

Хочется стремиться к здоровому рабочему балансу. Мы в Clevertec спросили коллег:

Какие личные системы помогают не выгорать?
Как они планируют время, как отдыхают?
И вообще когда можно считать себя продуктивным?

Как вы думаете, нужно ли архитектуру на вашем текущем проекте подвергнуть масштабному пересмотру и исправлению? Ставлю на то, что большинство читателей ответят положительно. И эта часть именно про это. В ней мы рассмотрим:

1. Когда сложившаяся архитектура подлежит масштабным изменениям.

2. Что не менее важно, когда лучше оставить, как есть.

3. Ключевые признаки проблем в архитектуре.

4. Основные способы исправления таких проблем.

Но для начала мы вспомним, что было в предыдущих сериях. В первой части мы прошлись по теории и выяснили:

1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;

2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;

3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;

4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.

Во второй части мы уже перешли к практике построения архитектуры с нуля. Мы узнали:

1. Что попытки угадать с архитектурой до старта проекта обычно проваливаются.

2. Что маленькие команды работают буквально в разы эффективнее, чем большие.

3. Что лучший способ разделить софт между командами - делать это постепенно. Начать с одной команды и уже затем дробить систему по обнаруженным в процессе разработки границам.

Теперь перейдем к вопросу, что же делать, если «все уже украдено до нас».

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

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

Всем привет! Это Александр Бондаренко, CPO в Garage Eight. Моя вторая часть статьи про развитие продукта при помощи улучшений и инноваций (часть 1 здесь). Она посвящена ТОП-13 худшим инновациям. На реальных примерах показываю, как качественные прорывы в продуктах разрушают репутацию компаний.

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

Модифицированная файловая архитектура по методу P.A.R.A (с небольшими изменениями).

С давних времен люди объединялись в группы, проводили собрания и совещания для того, чтобы озвучить существующую проблему и найти её решение совместными усилиями. Условия и способы для поиска решения были всегда разнообразными, создавались новые методы генерирования идей. Один из таких способов был разработан в 1939 году Алексом Осборном и получил название «Мозговой штурм» (англ. – Brainstorm).

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

За семь лет проведения воркшопов по Story Points я наблюдаю одну и ту же картину: команды изучают технику, применяют её несколько спринтов, а затем постепенно возвращаются к старым паттернам. И если на маленьких масштабах работы с одной командой или тремя кажется что Story Points прекрасный подход, на текущем масштабе — около 50 команд в IT — 60% используют Story Points, 40% не используют - я вижу совершенно иную картину. И вот что интересно: те 60%, которые используют, делают это крайне по-разному.

Причем конверсия в правильное использование Story Points 3 месяца после тренингов составляет дай бог 20%. Проблема не в самом инструменте, а в том, как мы его используем и для каких целей.

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

Звучит абсурдно? Разберёмся, что происходит с рынком труда, и почему даже идеальные кандидаты получают отказы.

Привет, меня зовут Анатолий Чикирев, и сегодня я расскажу вам о Lean-практиках сокращения потерь в IT-сфере. Для начала давайте договоримся о терминологии. Lean и бережливое производство — это синонимы. Я буду использовать оба термина, но речь пойдёт об одном и том же. Но сначала пара слов обо мне и моём опыте. 

Я работаю продактом в SM Lab с 2022 года, в целом в IT пришел  в 2018 году — тогда я занимался заказной разработкой. Впервые я узнал о бережливом производстве в Высшей школе экономики, где изучил базовую теорию и основные понятия. Уже тогда мне показалось это интересным, но, разумеется, практики ещё не было никакой. Потом я пришел на свою первую работу на завод, где участвовал в пилотном проекте по внедрению Lean с привлечением консультантов. Там я руководил проектным офисом, поэтому сам проект видел больше с административной точки зрения и только несколько раз выходил «в поле» с руководителем проекта, а глубже в суть методологии погрузился уже позже.

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

Когда я перешёл в IT (сразу после той самой FMCG-компании), у меня возник большой вопрос: «А работает ли Lean здесь?». Я понимал, что теоретически — должно. Но как именно это применять? Как перенести инструменты, которые я применял на производстве, на IT-процессы? Поначалу это было неочевидно. Со временем, когда я освоился и в IT, и в роли продакта, и в самой SM Lab, всё встало на свои места. Я разобрался, как Lean может работать здесь, начал внедрять его на практике — и применяю до сих пор.

Когда команда разработки делится на два лагеря из-за ИИ, а релиз вряд ли подождёт, возникает ступор и вопрос — что делать? В статье — как я решал эту проблему, шерстил исследования, форумы и вытащил у коллег 10 рабочих промптов для ускорения работы.