Потерянные версии документов, поиски актуальных планов и отчетов, несоответствие статус проекта и реального состояния... Такое знакомо многим и менеджерам проектов, и спонсорам, и командам (которые считают, что проще написать заново). Дело не в плохих людях, а в отсутствии системы, которая учитывает статусы и этапы проектов.
Так как придумывать контент оказалось задачей не простой, а придумывать СТОЯЩИЙ контент почти невыполнимой, а писать тем не менее что-то хочется, то я немного снижу планку своего перфекциониста.
И пока вокруг все разговаривают про гендерное неравенство в разных областях и сферах работ, я бы хотела поисследовать, что делать со сложными проектами, которые идут сразу не туда, куда хочется и не так, как нужно.
В целом, редкие проекты строго двигаются к своим запланированным и четко сформулированным целям, а какой-то хаос в предстоящих итерациях стоит закладывать сразу, смело отводя на него внушительную долю запланированного времени. А еще здорово, когда выстроены процессы ОТ и ДО, но как мы все знаем, суровая реальность далека от идеала. Поэтому аки фокусник тебе так или иначе придется выполнять разные роли и задачи из разных областей рабочих обязанностей. Потому что, если ты архитектор или инженер, то какие-то мелкие договоренности о встречах, адресах или настройках легче проводить самостоятельно и глупо дергать РП (если вообще таковой на проекте имеется) для каждой фиксации мелочи, а с другой стороны где-то надо искать грань, когда количество времени на организаторскую работу превышает мыслимые и немыслимые пределы и вместо архитектурной или инженерной работы (на какую ты собственно и договаривался словами через рот) ты занимаешься какой-то сплошной тратой времени, когда вот эти мелкие задачи занимают настолько много времени, что становятся скорее рутиной, нежели неприятным, но быстрым обязательством, которое ускорит достижение цели, сократит человекочасы, потраченные на проект и в целом поможет сделать все хорошее, против всего плохого.
Я расскажу вам о своем опыте тимлида командой разработки в крупном банке, где старые управленческие привычки иногда брали верх над здравым смыслом. Это субъективная точка зрения на реальную ситуацию, где я — Д«Артаньян, а все остальные — редиски.
OpenAI впервые раскрыла реальную статистику использования ChatGPT: 73% запросов не связаны с работой
Компания OpenAI опубликовала первое масштабное исследование поведения пользователей ChatGPT, проанализировав 1,5 миллиона реальных диалогов за период с мая 2024 по июнь 2025 года. Результаты оказались неожиданными и развенчали многие мифы об использовании ИИ.
Ключевые выводы:
700 млн пользователей в неделю - каждый десятый взрослый житель планеты
73% запросов личные, только 27% связаны с работой (год назад было 50/50)
Женщины обогнали мужчин - 52% vs 48% пользователей
Программирование - всего 4,2% от всех запросов (а не основное применение, как многие думали)
Три главные категории: практические советы (29%), поиск информации (24%), создание текстов (24%)
Неожиданные факты:
→ В развивающихся странах ChatGPT растет в 4 раза быстрее, чем в богатых
→ 10% всех обращений - это обучение и репетиторство
→ Больше половины "письменных" задач - редактирование существующих текстов, а не создание нового контента
Исследование показало, что ChatGPT превратился из нишевого инструмента для программистов в массовый помощник для повседневных задач - от рецептов до домашних заданий.
Однажды я записался на ProductCamp, придумал игру, которая была бы моим вкладом в команду «развлечений», не нашел свободных слотов, не поехал, но идею той игры полюбил и начал развивать.
Эта статья посвящена описанию вариации Spaghetti Challenge (далее Спагетти Челленджа) — игры для вечеринок, корпоративов, тимбилдингов, мастер‑классов по управлению, инженерному мышлению и кооперации.
Описанная версия игры добавляет в классический Спагетти Челлендж новую роль: Продуктологов. Участники в этой роли тренируются преподносить свои идеи и продавать их Строителям, и сразу смотреть: решают ли их продукты проблемы, и какую пользу они приносят.
Говорите по‑русски: не «OPEN» а «ОТКРЫТО». Ваш код — следующий? Всем коммитить по‑русски!
порассуждаем о будущем
Мы решили встроить ИИ в систему управления проектами и посмотреть, что из этого выйдет. Спойлер: получилось лучше, чем мы ожидали.
Сегодня речь пойдёт о том, как превратить приблизительные оценки сроков выполнения задач в надёжные прогнозы, и о том, как рассказывать об этих прогнозах другим.
Оценка сроков выполнения задач — это важное дело. Но, в то же время, подобные оценки доставляют массу неприятных эмоций множеству инженеров и программистов. Оценки сроков являются источником напряжения, которое возникает между командами разработчиков и всеми теми, кто так или иначе с ними взаимодействует. Это — менеджеры, другие отделы компаний, клиенты.
Всё дело в том, что почти все до сих пор неправильно рассказывают другим об этих оценках.
Привет, Хабр!
Сегодня рассмотрим метод, который может стать для вас интересным инсайтом в стратегическом планировании разработки — Wardley Mapping.
Если кратко, Wardley Map — это схема, где мы располагаем все компоненты нашего продукта или системы в двух измерениях: по оси «ценность для пользователя» (вертикаль) и по оси «эволюция/зрелость» (горизонталь).
Зачем вообще нужна дизайн-система? В первую очередь, для стабилизации и ускорения проектирования с разработкой. Затем — для унификации пользовательского опыта. Идея хорошая, однако иногда вместо этого мы просто получаем барьер на каждом шаге. Перекрасить кнопку? Согласование. Новый элемент или паттерн? Дизайн-комитет. А/В-тест? Сначала в ДС.
Команда учится делать не «лучше», а «правильнее». Развитие продукта замирает, потому что «в системе так не принято». Это и есть ДС-тюрьма: удобно сторожам, плохо заключённым.
Эта заметка развернулась из комментария к статье: Таски есть, системы нет.
С моей точки зрения, заглавие разсматриваемой стати верно. Однако в содержании перечислены проблемы-следствия, без разкрытия ключевой затронутой проблемы.
В заметке я постараюсь выйти на эту ключевую проблему и затронуть вопросы вида:
Из чего такая система должна произрастать? Какие к ней требования? Есть ли примеры?
Один и тот же тренинг. Кому-то все понятно и доступно. Кто-то раздражен — материал кажется очевидным и бесполезным. А кто-то полностью потерян — слишком абстрактно, оторвано от практики. Материал один, результаты — разные.
Представьте идеальную IT-команду: блестящие специалисты, амбициозный проект, всё для успеха. Но проходит несколько месяцев, и что-то ломается. В чатах исчезают мемы и жаркие споры об архитектуре, остаются лишь сухие «залил пул-реквест». Разработчик, горевший своим делом, теперь молча соглашается с любым решением. Даже успешный релиз не хочется отмечать — будто это не победа, а просто конец очередного марафона.
Это не просто усталость. Это — тихое выгорание. Не громкий скандал, а методичный отказ системы. Не «я устал», а «мне всё равно». И самое тревожное, что менеджмент часто замечает проблему лишь с заявлением об уходе, когда человек мысленно уже месяц как не с нами.
Правда в том, что люди уходят не только из-за денег. Гораздо чаще — из-за ежедневного обесценивания, абсурдного контроля и ощущения бессмысленности. 58% IT-специалистов готовы на меньшую зарплату, но не готовы мириться с токсичной культурой управления (Harvard Business Review).
Эта статья — для тех, кто чувствует, как команда теряет энергию, но не хочет с этим мириться. Для разработчиков, которые видят, как гаснут их коллеги. Для менеджеров, которые хотят вести команду к целям, не сжигая людей. Мы разберем, какие управленческие ошибки убивают мотивацию, и какие практики помогут вернуть команде огонь, устойчивость и желание делать классные продукты.
Как в России защищают дизайн? Работают у нас авторские права или нет? А что если я случайно придумал что-то похожее на чужую работу?
Я юрист по интеллектуальным правам, и как-то раз у меня было одно особенно интересное судебное дело на эту тему.
Речь пойдет про крупные компании, но история пригодится даже тем, кто работает в небольших фирмах или только начинает бизнес — неважно какой, закон в части дизайна работает везде примерно одинаково.
Итак, одна большая американская компания делала краскопульты и продавала их по всему миру. Однажды американцы обнаружили, что в России продаются аппараты с похожим, как они посчитали, внешним видом.
Игра «найдите десять отличий», американский аппарат слева, наш — справа…
Всем привет! Меня зовут Роман, я руковожу разработкой. Когда‑то начинал разработчиком, потом тимлид, сейчас управляю лидами.
В моём багаже опыта — работа работа в интеграторе, потом в небольшой компании из сферы 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. Хочу рассказать о граблях, на которые наступал в своей карьере я и команды разного уровня зрелости под моим руководством. То есть расскажу об антипаттернах, с которыми вы можете столкнуться, и как их можно преодолеть, чтобы успешно запускать проекты.