Comments 14
«Обожаю» ситуацию когда твой результат зависит от реализации соседнего проекта. Ты понимаешь что там все не оч хорошо, но команда того проекта упорно продолжает отчитываться о успехах и генерит эти самые «арбузы») Про «арбузы» запомню.
Но в этом есть и хорошая сторона... Попавший в такую ситуацию менеджер соседнего проекта будет заинтересован вовремя вскрыть арбуз перед общим начальством, даже, подпортив личные отношения с людьми с соседней команды, чтобы вовремя "отвязаться" по своим KPI от лузеров, и не попасть.
Иначе же, вскрывать вообще никому, из тех, кто держит свечку, не выгодно. Сейчас то проект зелёный, и все молодцы, а, как начнёт нутро лезть сквозь кожуру, то или проект отменят, или высшее руководство сменится, и требования все заново перепишет, или будешь в другой команде работать, или на повышение уйдешь, или, вообще работу сменишь...
Рад, что вам понравился этот термин. Знакомая ситуация. Возможно, существуют и другие проекты, которые также имеют критичные зависимости от вашего и того, другого проекта. Для улучшения ситуации видится целесообразным выявить и объединить все связанные проекты в программу или в портфель. Это поможет установить все зависимости, расставит приоритеты, централизовать и скоординировать работы. Если это уже реализовано, то о выявленных вами рисках следует проинформировать ответственного за реализацию программы/портфеля проектов руководителя.
Изначально под давлением заказчика были поставлены нереальные сроки.
Причём был свободный выбор: либо согласиться со сроками заказчика, либо не получить от него никаких денег. Иными словами, заказчику надо сделать вовремя, а не в прекрасном далёко. Но исполнитель не желает так работать. Как же тут поступать?
Неверная оценка бюджета, ресурсов и их доступности.
Да, эта обычная ситуация. На первом же обсуждении исполнитель заявляет, что надо будет платить, а денег нет. Или, например, исполнитель заявляет, что нужно купить оборудование либо расходные материалы, а отдавать на это фонд оплаты своего труда не хочет. Получается противоречие: исполнитель ещё ничего не заработал, а уже хочет потратить. Ещё страшнее ситуация выглядит, если исполнитель обещает долгосрочную выгоду, то есть в этом году не заработает ничего.
существующие отклонения и причины их возникновения.
То есть должно быть прямо указано, в чём исполнитель виноват и почему его надо уволить.
В идеале отчёт должен содержать план возврата к «зелёному» статусу
и перечень изменений в проекте, которые потребуются для его реализации.
Причём так, чтобы не изменять исходного проекта. Например, если исполнитель напишет, что для работы ему нужен компьютер с устройствами — тогда в отчёте должно быть указано, откуда он возьмёт себе этот компьютер и эти устройства. А если исполнитель напишет, что ему нужны телефонные переговоры или доступ к интернету — в отчёте должно быть указано, откуда он возьмёт всё это.
С помощью дополнительного внимания можно ...
получить дополнительное финансирование.
Увы, нет, так никогда не бывает. Если в самом начале финансирование ограничилось фондом оплаты труда, то дальше оно будет только уменьшаться. Ведь пока исполнитель не принёс прибыли, платить ему, по сути, неоткуда.
обсудите ситуацию со всеми стейкхолдерами, чтобы "красный" статус
не стал для них полной неожиданностью.
Так ведь они не хотят, да и не обязаны это обсуждать.
Запросите дополнительное время.
Да, можно и ночью работать, начальство не возражает.
Запросите дополнительные человеческие ресурсы.
Откуда же они возьмутся? Нанимать других людей нету денег, да и штатное расписание будет согласовано учредителем только к началу будущего года. А нанимать людей из своей зарплаты исполнитель не хочет.
У вас какой-то абстрактный «исполнитель» фигурирует, которому присуща некая «своя зарплата», ещё какой-то «доступ в интернет». В статье ведь вообще ничего про фриланс/контракт нет, она про проектный менеджмент внутри компании.
Давайте представим, что вы пришли на работу в компанию и заключили трудовой договор. Вы хотите, чтобы вам дали рабочее место, ресурсы и оборудование, чтобы исполнять трудовые задачи. Но директор компании хочет, чтобы вы сами обеспечили себе рабочее место, сами оплатили свои ресурсы и оборудование.
Все конфликты, описанный в статье, возникают из того, что компания просто не может платить за все потребности каждого работника. У неё хватает только на оклад, а дважды в год на премию.
Статья ни о чём
А по ситуации есть книга
Йордон Эдвард. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте.
Так статья про корпоративный булшит. Где проектом может быть переделывание страницы пользователя по полгода
Добрый день. Спасибо, что поделились своим мнением.
Эдвард был отличным программистом в Америке 70-90х. Книгу 1997 года выпуска спустя почти 30 лет можно назвать занимательной и интересной, автор приводит примеры из своего опыта в 1983-1999гг. и активно рекомендует подходы и инструменты проектного управления, большинство из которых на сегодняшний день являются «базой» и включены в международные стандарты, а также в ГОСТ Р ИСО 21500—2014.
Есть нюанс, книга про конкретный тип проектов и работу с ним, в ней идет речь про «безнадежные проекты».
Под безнадёжным проектом (death march) я понимаю такой проект, параметры которого изначально отклоняются от нормальных значений по срокам, ресурсам, бюджету и требованиям по крайней мере на 50%, вероятность провала свыше 50%. Путь камикадзе. Эдвард Йордон.
Несомненно, такой тип проектов существовал, существует и будет существовать, но совершенно неуместно называть проекты, которые попали в "красную" зону системы мониторинга "безнадежными". Благодаря современным методологиям, стандартам и процессам, запуск "безнадежных" проектов стал скорее исключением, чем правилом, прерогативой стартапов и небольших компаний, в которых культура разработки ПО и компетенции проектного управления отсутствуют или находится на уровне ниже среднего.
Отсутствие стандартов и методологии само по себе может превратить проект в безнадёжный. Путь камикадзе. Эдвард Йордон.
В своей статье не является «индивидуальной проектной рекомендацией») я делюсь информацией о том какие бывают статусы проектов в современных системах управления, делюсь личным мнением о том, что приводит проекты в "красную зону" и предлагаю алгоритм работы с ними. Все это актуально для проектов из среды крупных IT и Fintech компаний с развитыми стандартами разработки ПО и системами управления ИТ-проектами, а также для небольших команд с экспертом по проектному управлению на борту.
В части моего личного мнения по участию в "безнадежных проектах", о которых Эдвард написал свою книгу: частично соглашусь, но абсолютно уверен, что любой "безнадежный" проект при должном внимании можно трансформировать в окупаемую и реализуемую инициативу.
Самое главное – это осознать и понять в самом начале безнадёжного проекта свою собственную мотивацию с тем, чтобы вы могли принять взвешенное решение – участвовать в проекте или поискать другую работу. Путь камикадзе. Эдвард Йордон.
Картинками из статьи можно ввести человека в экзистенциальный ужас. Если уж генерите, то проверяйте результат, арбуз с шипами внутри добавил мне новую фобию.
А статья какая-то... пустая. Я лично из неё сделал вывод, что проект становится красным, если его нельзя реализовать в поставленные сроки/деньги( но пытаются сделать вид, что можно, впихивая ключевую реализацию в конец дедлайна) либо произошло что-то непредвиденное и чтобы её решить нужно просто... запросить ещё сроков/денег, чтобы решить возникшую проблему? Причем никак не затронут вопрос, если, например, после введения новых законов/изменившихся условий ваш проект вообще перестал быть рентабельным и что делать в таком случае, или если ваша команда не прошла испытание факторов автобуса и ушёл ключевой разработчик с большей частью знаний, как в таком случае замещать потерю?
Добрый день, спасибо, что поделились своим мнением.
Я лично из неё сделал вывод, что проект становится красным, если его нельзя реализовать в поставленные сроки/деньги либо произошло что-то непредвиденное..
Все верно, система статусов «зеленый-желтый-красный» используется в проектном управлении крупных компаний для мониторинга «здоровья» проекта. Она позволяет агрегировать результаты мониторинга (проектных работ, использованных ресурсов, бюджетов, закупок, рисков, результатов и их качества) и проинформировать всех заинтересованных лиц об имеющихся отклонениях.
чтобы её решить нужно просто... запросить ещё сроков/денег, чтобы решить возникшую проблему?
Неверно, в первую очередь необходимо определить и проанализировать причины возникших отклонений, которые привели проект в красную зону. Далее потребуется подготовить план необходимых изменений для продолжения реализации проекта. Проблема не «решается» изменением сроков или бюджетов, она требует подробного анализа, выводов и поиска возможных решений. Одним из решений может быть выделений дополнительных ресурсов или бюджета, но это только одно из возможных решений. Как я указал в статье:
«Потребуется запросить у лиц, принимающих решения, конкретные изменения, которые помогут стабилизировать ситуацию.»
Причем никак не затронут вопрос, если, например, после введения новых законов/изменившихся условий ваш проект вообще перестал быть рентабельным и что делать в таком случае, или если ваша команда не прошла испытание факторов автобуса и ушёл ключевой разработчик с большей частью знаний, как в таком случае замещать потерю?
Это отличные вопросы, которые требует подробного обсуждение, подойдет для новой статьи. Одним из объектов управления в проектном управлении являются риски. На этапе планирования проекта все или часть указанных в ваших вопросах рисков могут быть идентифицированы, проанализированы и запланирован план действий в случае реализации.
Давайте вместе раскроем тему. Что из вашего опыта наиболее эффективно в сложившихся ситуациях? Вот мои варианты нивелирования и реагирования на перечисленные риски:
Отрицательная рентабельность - пересмотр фин. модели, ТЭО, CF, сокращения расходов, поиск новых статьей доходов и окупаемости проекта. При провале - варианты переиспользования или реализации промежуточных результатов проекта на рынок.
Человеческие ресурсы и ключевые компетенции — страхование участников, кадровый резерв, параметры трудового договора с ключевым игроками (key players) предусматривающие дополнительную мотивацию при успешном завершении работ, а также применение финансовых санкции при преждевременном выходе участника из проекта.
Что делать, если статус вашего ИТ-проекта стал «красным» и что такое проекты «арбузы»?