Эта статья изначально была размещена на PragmaticLead.com
Спойлер: этот пост не о гибкой методике разработки и не о том, как она решит все проблемы. Речь идет о том, как подходить к проекту с самого начала и что делает проект успешным.
Быть руководителем проекта может быть непросто. Есть так много переменных, чтобы все в итоге получилось. Но если все идет хорошо, это будет полезным опытом. Следование нескольким простым рекомендациям может привести к успеху любой проект.
Поймите, как выглядит успех, разработайте план выполнения, привлеките к ответственности людей и себя, знайте, когда следует обострять ситуацию.
Проект - термин расплывчатый. Некоторые проекты могут занять несколько лет, в них задействованы тысячи человек. Остальные могут сделать два человека за неделю. И еще есть все, что посередине. Независимо от размера вашего проекта, в первую очередь нужно знать, что означает успех. Начните с конца и двигайтесь в обратном направлении. Это одна из 7 привычек высокоэффективных людей.
Планирование начинается с четкого определения масштабов и критериев успеха. Что входит в объем, а что нет. Все участники должны понимать, что означает успех. И какой срок. Одностраничный документ или PRD (документ с требованиями к продукту) - довольно стандартная практика. Вы и ваша команда должны иметь возможность с уверенностью сказать, когда проект будет завершен.
При создании программного обеспечения программисты разбивают его на более мелкие компоненты, классы, объекты и утилиты. То же самое и с управлением проектом. Разбейте его на более мелкие части, затем возьмите их и снова разбейте, пока не получите задачи. Первым шагом в этом процессе является создание вех. Они должны служить картой того, как завершить проект. Каждый из них должен быть мини-проектом с четкими результатами и сроками. Успешно и вовремя выполняя этапы, вы можете быть уверены, что все под контролем. И наоборот, если есть проблемы с одним из этапов, под угрозой оказывается весь проект. Используйте их как свою дорожную карту, чтобы добраться до большой финишной черты.
Проекты не выполняются изолированно. В игре всегда есть группа людей, у которых есть скин. Заинтересованные стороны - это люди, которые работают с вами над проектом, например, менеджеры по продукту, дизайнеры, руководители программ. В некоторых случаях в проектах могут участвовать другие команды или отделы, такие как маркетинг, бизнес, финансы. Определите все заинтересованные стороны, их роли и уровень вовлеченности, чтобы держать их в курсе всех событий.
Все задачи, включая уточнение требований, доставку активов и кодирование, должны иметь владельцев. Задача без владельца никогда не будет выполнена. Это не означает человека. Собственником может быть команда или человек, пока есть договоренность. Как только владельцы выяснят, все должны нести ответственность за выполнение взятых на себя обязательств в срок. Есть несколько способов сообщить о прогрессе и блокировщиках остальной части команды: ежедневные стендапы, еженедельные проверки, отчеты о состоянии и многие другие. Выберите ритм, который работает для команды при условии прозрачности и подотчетности. Любое постоянное собрание лучше, чем регулярно пинговать людей в Slack, чтобы получать обновления, когда что-то будет сделано.
Если есть препятствия или неожиданная сложность, оцените, какое влияние они могут оказать на текущую веху и проект в целом. Обсудите это с человеком, который столкнулся с проблемой, постарайтесь решить ее и при необходимости договоритесь обострить проблему. Другие люди могут потенциально помочь решить проблему. TPM могут помочь с внешними зависимостями, инженерные менеджеры могут перераспределять ресурсы, а менеджеры по управлению проектами могут повторно согласовывать объем, сроки или приоритеты.
Всякое случается. У каждого проекта есть риски, и большинство из нас ожидает, что произойдут неожиданные вещи. Команда редко создает одно и то же программное обеспечение снова и снова. Каждый раз в миксе появляется что-то новое. Мы постоянно сталкиваемся с неизвестными проектами, задачами, проблемами, ошибками. Все это делает проекты в некоторой степени непредсказуемыми. Несмотря на все это, руководство потребует некоторых графиков и бюджетных оценок, потому что создание программного обеспечения - это средство для достижения цели. Конечная цель программного обеспечения - поддерживать или развивать бизнес. А бизнес работает в рамках бюджета и времени. Мы все еще делаем все возможное, чтобы оценить усилия, но точно сказать не можем.
Есть много причин, по которым все может пойти не так. Распространенными ошибками являются увеличение объема, сложность реализации, нечеткие требования, недостающие активы, унаследованный код. Ключевым моментом является прозрачность, знайте, когда дергать за шнур и уведомлять заинтересованные стороны и руководство о наличии проблемы. Эскалация чисто, помните, что ваши коллеги преследуют ту же цель. Когда все закончится, все будут помнить, как вы реагировали и как относились к другим больше, чем к результатам проекта.
Эта статья изначально была размещена на PragmaticLead.com, посетите веб-сайт для получения дополнительных сведений о руководстве в сфере технологий. Вы можете найти меня в Твиттере.
