Техническое задание еще не управление проектом

– Привет. Давно не виделись. Как ты? Кем работаешь?

– Рад видеть. Да давненько. Да вот устроился менеджером ИТ-проекта в одну крупную компанию.

– Круто. Scrum, TDD, Agile. Сложно?

– Да не особо. Пишу технические задания и пересылаю между технарями и клиентами. Ерунда в общем.

К сожалению такой диалог вполне реален. Диалог является актуальным для многих, кто не входит в число крупных вендоров или интеграторов, у которых все процессы отлажены лучше чем швейцарские часы, а проекты являются действительно проектами. Зато в компаниях малого и среднего бизнеса зачастую игнорируется понятие “проекта”, а работа ведется как получится. Менеджер проектов в таких компаниях скорее надсмотрщик, который ставит программистам задачу разработать функционал как можно быстрее, потом просит тестировщиков ее проверить, затем следит чтобы все это развернули на продакшне и передает клиенту. Получает от клиента список багов и круг повторяется. Такой менеджер не различает критичность и важность требуемого функционала и багов. Если клиент сообщает даже о мелкой проблеме, то разработчики слышат в свой адрес “Все сломалось”. Такая ситуация является крайне нездоровой. И о ней я хочу рассказать в этой статье.

Зачем об этом говорить?

Управление проектами доступно каждому. Не верите? В бизнесе, все есть процесс и все есть проект. Нужно только немного потрудиться.

В любой компании в один прекрасный момент появляется проект. Будь-то выпуск нового продукта или услуги, создание рекламной кампании, внедрение нового программного обеспечения, подключение новой производственной линии и тому подобное. В такой момент предстает выбрать руководитель проекта (координатора или куратора) среди сотрудников или искать внешнего специалиста, который сделает все наилучшим образом. Однако данный процесс выглядит не так безоблачно как кажется на первый взгляд. И связано это вот с чем:

• Бизнес еще не знает что такое проект. По факту ничего сложного нет: цели, задачи, бюджеты, риски, распределение ресурсов, отчетность. Однако некоторые из этих компонентов постоянно игнорируются и в результате: бюджет уходит за рамки (ошибка планирования); задачи пересекаются, накладываются, блокируют работу друг друга. В результате результат оказывается под угрозой неосуществления, что бьет по интересу заказчика хоть внешнего, хоть внутреннего.
• Забывают делать переоценку рисков или оценку рисков вообще. Риски есть в любом проекте, хоть большом, хоть маленьким. Возникновение любого риска ставит весь проект под угрозу. Оценка риска должна быть проактивной – то есть до того как риск проявит себя. На долгосрочных проектах, оценка рисков должна пересматриваться через определенные промежутки, в зависимости от длительности проекта.
• Бизнес увлекается методологией и забывает о цели работы, тратя время на формальности методологии. Этим грешат как крупные компании, так и стартапы. Причины у всех разные: кто-то стремится соответствовать современным тенденциям; кто-то считает что так надо делать потому что проект выглядит солиднее и серьезнее. Нередко в погоне за следованием стандартам методологии и правильной организации документов, митингов и т.п. теряется быстрое и качественное выполнение собственно работы.
• Менеджеры проектов – самая неопределенная категория сотрудников. В ИТ-компаниях с этой должностью все более менее в порядке, если на эту должность берется выращенный внутри компании человек. Но если в ИТ-компании менеджером над техническим проектом решают взять вчерашнего выпускника гуманитарной специальности, то тут шансы что повезет взять толкового 50/50. Еще хуже обстоят дела в сферах, где для менеджера проектов критически важно иметь релевантное образование, опыт и т.п. В таком случае отбор должен быть крайне критичным, а лучше всего проводить его среди внутренних резервов.
• При работе с проектами учитываются задачи и ресурсы только одной из сторон. У любого проекта есть холдер (исполнитель) и заказчик, который ждет результаты его осуществления. Проект всегда должен быть нацелен на интересы заказчика, которые должны быть исполнены любой ценой. При правильном управлении проектами необходимо учитывать интересы всех участников проекта, а их действия по его реализации должны быть согласованными.
• Страх загоняет проект в кризис. Сотрудники могут бояться сообщить о реальном положении дел, особенно о возможном срыве сроков или перерасходе бюджета. Это может вылиться в выполнение проекта с крайне низким качеством работ или вообще опустить проект в состояние безнадежности. У руководителя проекта должны быть инструменты для мониторинга и контроля проекта, которые позволят избегать таким ситуаций насколько возможно.
• Работу менеджера проекта тяжело измерить, если вообще возможно. Но все же некоторые пытаются навесить KPI на менеджеров проектов. В таком случае руководитель проекта вместо того чтобы следить за качеством и скоростью работы начинает выполнять план, чтобы получить премию. Такой подход постепенно снижает ответственность менеджера за результат и размывает ее на остальных участников.
• Отсутствие границ проекта. Расплывчатое понимание масштаба проекта может превратить его в долгострой, либо устремить в бесконечность.
• Проблемы связанные с коммуникацией, в том числе внутренней. Изначально, менеджер проекта – лидер и проводник, задача которого координировать и направлять команду. Но иногда случается, что менеджер считает, что проект находится исключительно в его власти и все должно быть сделано только так как он скажет и никак иначе. Он начинает ставить себя выше всей команды и игнорирует все что ею предлагается, либо скатывается в микроменеджмент или пытается сам закрыть все задачи. Команда в итоге учится молчать. Но проектная – это в первую очередь команда которая его делает, а не ее руководитель. Именно – коммуникация внутри команды движущая сила любого проекта. Поэтому она должна быть прозрачной и информативной, а все участники проекта в курсе всех дел связанных с этим проектом, чтобы быть готовыми к любым событиям и рискам.
• В проектной работе почти всегда есть место вездесущему принципу Парето. А именно 20% команды делает 80% работы или что еще хуже 20% работы делает 80% команды. Можно мириться этими вещами, но лучше грамотно стимулировать команду, чтобы она стала по настоящему эффективной.

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

Три кита управления проектами

Управление проектом любого размера в компании любого размера стоит на трех китах: время, бюджет, границы проекта; и умении менеджера проекта балансировать ими несмотря на постоянные вмешательства высшего руководства.

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

Стоимость (бюджет) – параметр, который требует отдельного внимания. Его сложность в то, что стоимость проекта должна быть подсчитана и озвучена заранее, а непредвиденные обстоятельства и риски не должны оказывать значительного влияния на стоимость. В процессе реализации необходимо контролировать движение денежных средств и фиксировать поступления и траты. Тщательный подход к экономике проекта снимает много проблем и устраняет корпоративные разборки.

Границы проекта – это оценка масштаба проекта и строгое следование: требованиям заказчика, техническому заданию, паспорту проекта. Техническое задание – броня исполнителя, так как он использует его чтобы объяснить объем работ и ограничения. Для успешного ТЗ нужно собирать требования, распределять их по этапам проекта, согласовать полученное с заказчиком. В идеале в техническом задании должно быть прописано не только то, что будет сделано, но и то, что делаться не будет.

Как управлять проектом?

Одной статьей невозможно охватить всю тему касающуюся управления проектами. Но можно выделить несколько правил, которые доступны не только крупным компаниям, но и малым, и средним:

• Соблюдайте треугольник ограничений управления проектами: сроки, стоимость, границы. Таким образом бизнес (и команда) будут управляться более качественно и прозрачно.
• Не бойтесь стартовать параллельно несколько проектов – при грамотном распределении задач и ресурсов это даст выигрыш во времени и в коненом итоге вы сможете работать быстрее и с более высоким качеством.
• Если проект начинает разваливаться – сроки давно уже протухли, границы размылись, остановитесь. Проанализируйте причины и проблемы. Перезапустите задачи. Проблемы могут крыться в объеме задач проекта. Но если крупные задачи разбить на небольшие, что все пойдет лучше.
• Собирайте отчеты, проводите ретроспективы и анализируйте проблемы и достижения. Это позволит вам избегать будущих проблем. Если решение оказалось успешным, не стоит сразу праздновать успех, вначале разберитесь в причинах успеха, а уже после празднуйте и внедряйте находку.
• Не ошибитесь с выбором руководителя проекта. Помните, что это не человек с наличием определенного образования и не оратор, а человек, который разбирается в теме проекта и должен построить отлаженную систему, которая по итогу даст толчок к следующему процессу. Однако без навыков коммуникации, делегирования и работе в команде не обойтись.
• Управляйте изменениями. Если в проекте появляется что-то новое, обработайте. Ни в коем случае не отстраняйтесь и не отказывайтесь от изменений. Но не выходите за границы треугольника: сроки, стоимость, границы.
• Задачи проекта должны быть реалистичными для исполнения и поставлены исходя из оценки всех имеющихся ресурсов.
• Определите экономическую эффективность и целесообразность проекта. Неумение или нежелание оценивать эффективность привело к гибели много стартапов. Безусловно можно заняться производством деревянного электромобиля или разработкой приложения для подсчета убитых комаров. Но это проекты ради проекта, здесь нет ни эффективности, ни целесообразности. Оцените заказчика или объем рынка, до того как начнете проект. Этот пункт относится и к некоммерческим организациям в том числе.
• Планируйте загрузку с учетом горизонта. Так вы будете понимать кто чем занят, какие ресурсы задействованы сейчас и будут задействованы в дальнейшем.
• Ведите документацию проекта. Все документы проекта должны быть собраны в одном месте и содержать исчерпывающую информацию и том, что происходило в проекте.
• Не погружайтесь слишком глубоко в методологии. Лучше всего подбирайте лучшую методологию для каждого проекта отдельно. Методология должна работать на вас, а не вы на нее.
• Не забывайте закрывать проект. Это кажется смешным, но проект должен быть завершен полностью. Не допускайте частично завершенных проектов, долгостроев, пауз в одном шаге от завершения. Хоть закрыть проект и бывает порой довольно сложно.

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