Старт проекта. Как это делать?

Хочу предложить вашему вниманию серию статей «Старт проекта», еще это называют инициирование проекта. Инициирование проекта – переходной процесс между «продажниками» и исполнителями, который зачастую оказывается либо «ничейным» либо недостаточно качественно сделанным. Что уже с самого начала  проекта вносит негативные факторы. В этой серии рассмотрим наиболее, с моей точки зрения, важные вопросы, которым далеко не всегда уделяется нужное внимание.

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

Приведу немного перефразированные случаи из жизни:

  • Стартап, заказчик имеет ограниченный бюджет, которого хватит на несколько месяцев, понимает идею продукта и полностью доступен для коммуникаций. Всем ясно, что за этот бюджет скорее всего можно получить только неплохой прототип, судьбу которого далее решает инвестор.
  • Переделка довольно сложного бизнес приложения на новые технологии. Никакой документации к существующему приложению нет. Бизнес-область компании-исполнителю незнакома. Во что выльется переделка — изначально сложно даже предположить. Но скорее всего много относительно возможностей заказчика. На стороне заказчика есть специалисты по старым технологиям, которые могут в какой-то мере саботировать проект.
  • Поддержка и развитие системы с множеством версий для разных заказчиков. Долгосрочное (годы) сотрудничество, важность накопления знаний внутри команды по предметной области. Наличие другой команды-конкурента, команды могут сравниваться по производительности по количественным показателям. Заказчик диктует свои стандарты кодирования и подход к архитектурным решениям продукта. Довольно большая доля бизнеса для компании-исполнителя.

Как видно, ситуации совершенно разные, и подход – «Как делать» — тоже будет разный. И лучше договориться о нем заранее. На что обратить внимание:

  • Необходимость разбить проект на фазы, например: передачи знаний, выяснения требований, прототипа, проектирования, выполнения, внедрения и т.п. Соответственно в каждой фазе будут совершенно разные результаты работы, состав команды, продолжительность, тип контракта, методология.
    • Когда необходимо разбивать на фазы? Когда требования неясны, новая и сложная предметная область, новая технология, требуется получить точные оценки и планы работ, внедрение или долгое или отложено во времени, заказчик или исполнитель не готов делать сразу весь проект и т.п.
  • Необходимость договориться о процессах работы – это собственно процессы, поддерживающие методологии, стандарты, технологии. Обычно у компании-исполнителя есть определенные внутренние договоренности «как делать» те или иные инженерные и управленческие практики. У заказчика тоже могут быть свои соображения и по поводу процессов, и по поводу методологий, и по поводу инструментария. Сам по себе проект тоже накладывает определенные условия.
    • Задача компании-исполнителя, а особенно ответственного менеджера проекта – установить процессы, которые были бы в первую очередь полезны конкретному проекту, учитывая процессные требования как заказчика, так и компании исполнителя.
  • Необходимость понять политические факторы проекта. Их может быть великое множество. Давайте посмотрим. Кому проект выгоден, а кому может быть и не выгоден? Даже есть такое понятие «murder board». Невыгоден – пользователям заказчика, работу которых автоматизируют, т.е. вероятны сокращения штата; ит-шникам заказчика, которые «застряли» на устаревших технологиях или дорого обходятся заказчику; представители подразделений и других проектов заказчика, у которых ваш проект «отбирает» финансирование, т.е. те, кто напрямую не заинтересован в проекте. Со стороны компании-исполнителя тоже может быть набор политических факторов, таких как приоритетность заказчика или направления бизнеса среди других; состояние финансовых и договорных отношений; наличие и квалификация специалистов определенного направления и т.п.
    • По политическим факторам скорее всего нужно уделить внимание двум аспектам: а) скажем так — психологической готовности их нейтрально воспринимать; б) выбору правильных способов коммуникации и эскалации, причем с уклоном в более формальные методы.

В следующей статье рассмотрим дисциплину Управление Конфигурациями, и почему важно уделить ей внимание на старте проекта.

Tags: , , , ,

Comments are closed.