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

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

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

В статье рассказываем, как мы заново осмыслили и пересобрали фичу:

• продакт Настя Голованова — о том, как мы нашли value, перезапустили механику и успели в сроки размещения наружной рекламы;
• разработчик Михаил Ефанов — про то, как превратить монолит в стабильную архитектуру.

Полезно будет всем, кто работает на стыке развитии продукта и инженерии: от старта фичи до релиза и плана развитии.

Почему стартап так и не запускается, хотя «уже почти»

Многие команды проходят этот путь. Всё вроде бы работает, осталось «совсем немного», но неделя за неделей релиз откладывается...

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

Вы узнаете:

Как благое намерение "усилить команду" превратилось в механизм самоуничтожения;

Почему пассивность квалифицированного специалиста опаснее открытого саботажа;

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

Этот текст - антидот против управленческой иллюзии. Если вы хоть раз чувствовали, что "процесс работает, а результат умирает" - вы уже в эпицентре.

Представьте себе, что вы айтишник, которому достался стадион. 

Ладно, это я, если что, несколько лет назад. Я поломался в хоккее, что поставило крест на спортивной карьере, и вспомнил основную специальность. Через несколько лет стал продавать билеты: сначала — в Балашихе, а потом — в Омске на «Авангард». 

Это нелинейный ад. 

Вот представьте себе: у вас есть стадион на шесть тысяч мест, и вам надо продать билеты. Казалось бы, делов‑то: бек с API на учёт мест, фронт на сайте, в приложении, выгрузка XML дистрибьюторам — и всё. То есть надо задекларировать, какие места есть и почём, — и всё.

Ага, щас!

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

Вы купите один ради интереса — посмотреть, что будет, и вас кинут на 1 000 рублей. Потому что это был фишинговый сайт. Ещё таким же образом кинут примерно 1–5% зрителей, если с этим ничего не делать, и эти зрители перегрузят вам охрану и стюартов на входе, потому что не смогут пройти и будут очень громко кричать.

Потом вам надо выделить билеты для фанатов приехавшей команды. Рассаживать их среди ваших фанатов немного опасно. Для приезжих — в первую очередь.

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

А после этого приходит финальный босс — чёртовы перекупы. Борьба с ними — это примерно половина сложности продажи билета.

Перед матчем вы обнаружите, что у вас остались непроданные места, и побежите раздавать их бесплатно в школе напротив стадиона.

Но давайте начнём с самого начала. Итак, вам нужно интегрироваться с турникетами. Зачем? Надо!

Какими инструментами для линтинга и форматирования Python-кода вы пользуетесь? Black, Isort, Flake? Их существует множество, каждый следует своей цели, некоторые могут пересекаться по функциональности. Одни могут нравиться за автономность, другие — за возможности конфигурирования. И наверняка вы слышали о Ruff, который обещается заменить собой все.

Привет, Хабр! Я Гена, Python-разработчик в Selectel. В этой статье я опишу свой опыт перевода проекта на Ruff: что понравилось, что — не очень, к чему готовиться и, если все же решитесь, то как это сделать. Добро пожаловать под кат.

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

В данной статье будут рассмотрены: портрет руководителя Кирилла; цикл использование - подавление - слив сотрудника; результаты для Команды и Бизнеса; ключевые трансформации и мой личный опыт.

Портрет руководителя Кирилла

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

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

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

Привет! Меня зовут Елена Тупикова, я академический руководитель программы онлайн-магистратуры «Управление IT-продуктами» от Яндекса и МФТИ. В этой статье я расскажу, чем занимается продакт-менеджер в IT и для чего ему нужно разбираться в базах данных, языках программирования и машинном обучении. А ещё дам список технических навыков, которые нужны продакт-менеджеру для работы в IT.

Вы «должны» проводить 1-on-1.
А зачем?

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

Что ж, давайте разбираться:

Мир меняется. Мы чувствуем тенденции на себе. Больше информации, больше логики, больше конкуренции, больше комплексности, больше правил, больше автоматизации, больше контекста, больше скорости… 

У нас был опыт работы с Lean, Kanban, CPM/CCM, Waterfall, PMBOK, Six Sigma, Scrum, Agile, OKR+Product Discovery, GIST Planning, включая их вариации и гибриды. Некоторые – мы ценим и применяем сейчас. И тем не менее, спустя 15 лет в проектном и операционном менеджменте мы по себе знаем о чем все также плачут проджекты, продакты и управленцы. О большей точности, координации, информации, взаимодействии и сроках. 

Нам понадобилось время по-новому осознать казалось бы простую идею, о которой чуть ниже. Проекты, как и компании в целом – это ресурсы направленные на достижение целей. Время, люди, информация – ресурсы, но сами по себе они не равны достижению целей. Ценность ресурсов – в их связях и взаимодействии. Связь и взаимодействие ресурсов – краеугольный камень в достижении целей. Это и есть идея Cоntext.

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

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

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

Привет! Меня зовут Александр, я SDET-специалист в SimbirSoft. В этой статье я расскажу, как можно покрыть разрабатываемую часть проекта автотестами на ранних этапах его разработки, если в команде отсутствуют аналитики и присутствуют задокументированные требования только по основному функционалу. Эта статья будет интересна как джунам, так и техническим специалистам middle и выше, а также руководителям команд (team leads) и техническим лидам (tech leads).

Я поделюсь тем, как в такой ситуации были настроены процессы в нашей команде. Мы работаем над проектом с утвержденной микросервисной архитектурой с внутренними и внешними сервисами. Команда работает по Scrum-методологии и состоит из тимлида, разработчиков сервисов, QA и SDET-специалистов. От заказчика поступила лишь основная информация о том, что должен делать продукт и на каких платформах его можно будет использовать. Именно эта информация и была задокументирована в виде требований.

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

Почему разработчику, продукт-менеджеру или фаундеру
стоит оглянуться на Древний Рим?

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

В IV веке до нашей эры афиняне собирались на агоре, чтобы спорить, убеждать и принимать решения, cегодня мы открываем Zoom. Тогда говорили о демократии, законах и общественном благе, cегодня — о roadmap, KPI и MVP.

Вы наверняка замечали, что в начале общения ИИ кажется очень толковым и понятнливым, правда почему спустя 10-20 сообщений начинает путаться, повторно совершить те же ошибки которые уже совершал или выдавать рассчеты с ошибками. Это не случайность, а следствие мироустройства. Давай разберемся почему это происходит и как именно ИИ все “помнит” и почему его память устроена иначе чем у человека.

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

Эволюция пока не приспособила собак к городу полностью. Летом бывает горячий асфальт, песок и мелкие камни забиваются в складки, в результате — натирание лап и воспаление.

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

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

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

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

Так родился бальзам в виде стика, который и защищает, и лечит, и который можно случайно съесть.

Как часто оценка по задаче совпадает с реальными трудозатратами?

Умение точно оценить объём работ спасает от переработок, напряжённой обстановки на проекте, поддерживает доверительные отношения в команде и показывает вас с хорошей стороны перед заказчиком.

Но интуитивные и ставшие традиционными способы оценки задач дают низкую точность. Пора взять на вооружение другой способ, дающий 90+% точность в оценке.

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

Если вы хоть раз были на стороне бизнеса, наверняка слышали (или говорили):

Сколько можно делать такую простую штуку?; Они что, не понимают, как это важно?

Но тут надо смотреть шире...