И избегайте их зомбирования

Утро понедельника.

Вы изо всех сил пытаетесь встать с постели.

Ваша энергия истощена.

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

Каким-то образом этот проект был передан нескольким командам, и все же ... кажется, что он так и не был завершен.

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

Руководство уже вложило миллионы долларов во внедрение технологии, но, похоже, она никуда не денется.

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

Это всегда происходит почти в каждой крупной компании. Компании тратят миллионы долларов на внедрение технологий, а иногда они так и не доставляются. Просто спросите Герца, который в настоящее время судится с Accenture на 32 миллиона долларов из-за провалившегося проекта!

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

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

Немедленно устраните препятствия

В технологических проектах каждый день возникают препятствия.

Может быть, у кого-то нет доступа к набору данных, команды A и B не согласны с дизайном, или, возможно, вы ожидаете одобрения покупки программного обеспечения от директора, который только что уехал в отпуск.

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

В крупных компаниях большинство технических команд работают сразу над несколькими проектами. Это позволяет использовать препятствия для оправдания того, почему команды не выполняют работу над вашим проектом; блокпост снимает давление с соседних команд. Если вы технический руководитель проекта (TPM) или даже технический руководитель проекта, вы не можете позволить препятствиям стать оправданием и потерять импульс.

Как только импульс утихает, трудно начать снова.

Команды должны будут помнить, что они делали для вашего проекта, им нужно будет пересмотреть свой код / ​​требования, и они, вероятно, сделают ошибки, потому что работа не так свежа в их сознании. Вот почему препятствия могут быть смертельными для проекта. Игнорирование их и предположение, что они позаботятся о себе сами, - это один из способов гарантировать, что ваш проект никогда не завершится.

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

Создать вехи

Быть ответственным не всегда приятно, но это необходимо.

Мы все избегаем этого, и некоторые из нас убеждают руководство, что нам это не нужно.

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

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

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

Да, руководство всегда будет стремиться к тому, чтобы дела выполнялись быстрее, но действительно есть предел скорости, с которой вы можете работать. Установление контрольных точек не только обеспечивает подотчетность технических команд, но и заставляет руководство пересматривать свои собственные потребности.

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

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

Общение - ключ к успеху

Это клише, правда?

Наверное, тысячи статей говорят о ценности общения во всех технических областях.

Так почему люди продолжают это говорить?

Потому что хорошее общение помогает всем понять, что происходит.

Общение держит всех в курсе.

Это помогает TPM знать, где есть препятствия, а также что на самом деле делается. Большинство TPM просто смотрят на вещи с более высокого уровня. Это означает, что они доверяют инженерам различных команд честно сообщать статусы.

Без общения может быть трудно понять, какие шаги можно предпринять, а что сдерживают.

Уточните свою конечную точку

Если вы не знаете, куда вы идете и чего хотите от готового проекта, то как вы узнаете, что там окажетесь?

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

Возможно, нынешние заинтересованные стороны просто продолжают менять то, что они хотят.

Это известно как смещение области видимости.

Сначала все начинается с малого и не кажется большим делом.

«Эй, мы можем просто добавить сюда этот дополнительный столбец или эту дополнительную кнопку там?»

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

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

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

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

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

Заключение

Уберечь проекты от зомбирования не всегда легко.

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

Правда в том, что поддерживать продвижение проектов легко, пока это не так. Здесь в игру вступают отличные TPM. Как маэстро перед оркестром, они контролируют общую картину.