Я являюсь частью внутренней команды разработчиков программного обеспечения в розничном бизнесе. Сейчас мы работаем над крупным проектом, и, скорее всего, он провалится. На данный момент все почти закончилось.
За последние два года это будет вторая громкая неудача команды, не только с точки зрения невыполнения того, что просили, но и с точки зрения предоставления чего-либо ценного вообще. Больше ничего за это время мы не сделали.
Несколько членов команды разработчиков узнали от разных людей в бизнесе, что менеджер команды, который последние два года был только менеджером по разработке, теперь винит в этой неудаче команду разработчиков перед остальным руководством, включая управляющий директор.
Это полная неверная характеристика того, почему этот и предыдущие проекты потерпели неудачу. Все причины провала были связаны с управлением. Это список причин, которые, как мне кажется, привели к провалу проектов.
Бизнес-системы были выбраны руководством, не задумываясь о том, как и можно ли с ними интегрироваться. Они не соответствуют тому, как работает бизнес, и не соответствуют нашим текущим рабочим процессам. Остальная часть бизнеса не желает менять рабочий процесс, чтобы соответствовать новым системам.
Все советы команды игнорируются менеджером по развитию. Каждый старший член команды с самого начала проекта говорил, что это было совершенно неосуществимо, просто не было технического решения, которое мы могли бы реализовать, которое сняло бы ограничения выбранной платформы и позволило бы бизнесу работать как оно хотело. Советы и предупреждения не только игнорировались, но и активно преследовались; люди, поднявшие предупреждения, были наказаны.
Все предупреждения никогда не появлялись за пределами нашей команды. Ни один другой член управленческой команды не знает о серьезных недостатках проекта. В нашей команде нет прозрачности. Внешне все сообщается, что все в порядке и идет по графику, несмотря на то, что мы внутренне знаем в течение нескольких недель, что все никогда не сработает. Внешние отделы знают о пропущенных сроках только за несколько дней, несмотря на то, что мы можем предупредить их заблаговременно.
Управление проектами и командами неэффективно и совершенно некомпетентно. Задачи расплывчаты и неконкретны. Критические решения, которые необходимы, не принимаются до последней минуты, что создает дополнительную работу и серьезные проблемы с существующими предполагаемыми решениями. Пограничные случаи игнорируются, когда это неудобно. Вся работа выполняется несколькими членами основной команды, поэтому, хотя мы все должны быть заняты, это ситуация, когда некоторые заняты, а другим приходится постоянно просить, чтобы они что-то сделали. Связь ужасна; люди, которые подняли проблемы, исключаются из звонков и собраний, поэтому они не знают, что происходит, и не могут внести продуктивный вклад. Информация о проблемах и предлагаемых решениях считалась совершенно секретной и скрывалась от большинства людей.
Произвольные сроки, которые совершенно не привязаны к работе, которую нужно сделать.
Команда разработчиков работала до предела, работая дополнительно, включая некоторые выходные, чтобы попытаться создать решение. Неудача не связана с отсутствием у нас обязательств или технических возможностей.
Как мы можем противостоять обвинениям в этой неудаче? Мы думаем о коллективной просьбе о встрече с управляющим директором, чтобы обсудить наши опасения. Это хорошая идея? Как лучше всего подойти к такой встрече?
Хорошие менеджеры знают, что вина всегда лежит на руководстве, а плохие менеджеры пытаются переложить вину с себя. Это очень легко увидеть, потому что единственные менеджеры, обвиняющие кого-либо, — это плохие менеджеры.
Тогда есть два сценария:
В сценарии 1 у вас все хорошо. В сценарии 2 вы никогда не были хорошими и должны уйти, если это вообще возможно.
Поведение вашего менеджера неважно, важна реакция вашего высшего руководства на его поведение.
Попросите провести ретроспективное совещание по проекту, чтобы вы могли проанализировать провал проекта вместе с вашим менеджером и высшим руководством, чтобы вы могли извлечь уроки из ваших коллективных неудач, чтобы определить, что нужно изменить, чтобы вы все не провалились. третий раз. Принесите с собой любые имеющиеся у вас доказательства того, что вы сделали в ОП, чтобы вы могли подтвердить свои выводы.
Кроме того, вы можете провести некоторое исследование в области управления проектами Agile и, возможно, использовать эту возможность для лоббирования того, чтобы ваш бизнес стал Agile. Было проведено исследование, которое показало, что вероятность провала проекта при «традиционных» структурах управления проектами значительно выше, чем при Agile-структурах, а Agile-процесс был разработан, чтобы помочь решить многие проблемы, которые у вас возникали.
Прямые ответы, за которыми следуют некоторые более общие советы:
Как мы можем противостоять обвинениям в этой неудаче? Мы думаем о коллективной просьбе о встрече с управляющим директором, чтобы обсудить наши опасения. Это хорошая идея? Как лучше всего подойти к такой встрече?
Общие советы
епископ