Comments 13
Пришлось навалится командой топ менеджеров и встать у руля проекта, в результате чего проект был реализован срок.
Коктейлем из чайка-менеджмента и микроменеджмента всем напихали неоплачиваемых переработок по 40 часов в неделю после чего раздали себе бонусы?
Ощущение, что автор большой энтузиаст условной жиры, который до сих пор верит, что успех проекта зависит от перестановки кроватей в борделе, а не от того, кто этот проект делает, как их число соотносится со сложностью задач, пробовали ли платить сотрудникам не ниже рынка. В такой картине мира термоядерная энергия пока не доступна, потому что не сделан правильный юзер стори маппинг на пути ее достижения.
Если честно, ожидал более едких комментариев)
Насчет чайка менеджмента - это, без спора, реальная проблема многих руководителей, но в данном кейсе как раз было наоборот, команда просрала проект и не выполнила технический майлстоун, после чего пришлось с нуля собрать команду и выстроить строгий менеджмент. Да, команде пришлось попотеть, овертаймить - о чем заранее знали все участники проекта и были готовы к этому, поэтому проект сделали за 6 месяцев из 12 отведенных (6 месяцев работы до этого пришлось выкинуть на свалку). В итоге все были вознаграждены соответствующим образом, а главное - проект был в сдан вовремя и в нужной кондиции.
Насчет энтузиазма к джире - можно вести в чем угодно проект, но это не гарантия его реализации. У команды должны быть общая цель, которую все видят и идут к ней (для этого как раз и нужны общие дашборды), а иначе это не команда, а просто компания спецов.
Ритм команды: кранч → отдых → восстановление → снова кранч → релиз на тестовый контур → хотфиксы и багфиксы → шлифовка → релиз в паблик.
Кранч - это переработки. У вас статья буквально про то, как команда, за оверпрайс, героическими переработками, спасла проект от ошибок менеджмента.
Истории опытных менеджеров наоборот скучные и предсказуемые. Выглядят примерно так: сначала долго и тщательно всё планировали, а потом сделали проект +/- в соответствии с планом. Ни героического превозмогания, ни переработок.
Прочитал комментарий и вспомнил мем
а если серьезно, то здесь "кранч" идет в контексте того, что вся команда погружена в работу и работает на результат несколько дней подряд фокусируясь только на главных целях. Было бы круто, если бы команда могла съесть ТЗ и выдать нужный результат через полгода, но к сожалению пока я таких случаев не встречал ни в теории ни в практике, поэтому приходится множество факторов, чтобы реализовать, с виду кажущийся, не сложный проект..
если бы команда могла съесть ТЗ и выдать нужный результат через полгода, но к сожалению пока я таких случаев не встречал ни в теории ни в практике,
Если ни у какой команды при работе с вами не получалось. Может дело не в командах?
Спасибо за вопрос! Да - дело не в самих командах конечно, а в системе работы с командами. Если с командой ведется постоянно работа заказчика, помощь с ресурсами и проблемами, то у такой команды всегда получается результат! Чем сложнее проект и ситуация на проекте, чем лучше должна быть организованна работа.
Статья само-реклама: автор героический герой и вытащил безнадежно безнадёжный проект, вопреки сложным сложностям, потому что он профессиональный профессионал.
Согласен с изложенным в комментариях:
Истории опытных менеджеров наоборот скучные и предсказуемые. Выглядят примерно так: сначала долго и тщательно всё планировали, а потом сделали проект +/- в соответствии с планом. Ни героического превозмогания, ни переработок.
Хрена се крутой менеджмент. Цикл из кранчей - это антименеджмент.
Вы не только не умеете управлять командами, так ещё и сжигаете их.
Ещё бы предложили оценивать объемы работ не специалистам, а ПМ и продукт оунерам.
А погодите.
Благодарю за активную позицию и честность! Хочу пояснить: ситуация действительно не была идеальной. Это не отрицаю. После этого пришлось перезапустить часть команды, пересобрать процесс и работать в ускоренном темпе. Да, были кранчи — это не здорово. Но овертаймы были обсуждены заранее, с компенсацией и с чётким дедлайном. Без неопределённости. Команда действительно выдала результат за 6 месяцев вместо 12. Это было возможно, потому что новая команда, новые условия и высокая мотивация. Полностью согласен с теми, кто пишет: идеальный менеджмент — это когда проект идёт как по нотам, без героизма. Именно туда и надо стремиться. А этот кейс — не инструкция, а честный разбор: как из сложной ситуации выбраться. В следующий раз я сам бы предпочёл путь без кранчей и переработок!
Когда я читаю как "навалиилсь на проект командой менеджеров", меня просто разбирает смех)
меня тоже разбирает смех, когда я вспоминаю, как разработчики запускали "рабочий билд", который крэшился в момент запуска и так повторялось 3 раза подряд под обещание - "ой, завтра обязательно все будет работать, локально то у меня все работает!".
И проект вытянули в итоге СЕО которому пришлось стать СТО и остальная команда управленцев компании, которым пришлось заново пересобрать всю тех. команду из лучших спецов с параллельных проектов внутри компании и добрать новых, но так бывает - не часто встретишь, когда заявление разработчика по срокам и качеству совпадают с реальностью потом. Принятие наличие такого факта упрощает взгляд на появление проблемы в проектах.
Часть 2. Почему система управления в проекте — это не просто «доска задач». От проблем к решениям