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

Что же обычно происходит на этом этапе?Мы будем исходить из допущения, что у вас уже состоялся официальный старт проекта, kick-off созвон с клиентом, у вас есть собранная команда и подписанный контракт.

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

Контроль

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

  •     Непосредственная визуальная проверка результата
  •     Контроль через отчет
  •     Контроль через другие каналы получения информации (устная беседа с исполнителем, ежедневные статусные совещания и т.д)

Контроль хода всего проекта

  •     Использование формул Управления освоенным объемом (Earned Value Management)
  •     Контроль выполнения проекта относительно изначального плана (исполнение расписания, исполнение бюджета), используя диаграмму Ганта, сетевые графики, графики кривых хода работ и т.д.
  •     Контроль в контрольных точках проекта (milestone)
  •     Контроль соблюдения регламентов и процессов, следования выбранной методологии.

Контроль может различаться по частоте его проведения:

  • Контроль в моменты окончания работ (метод “0-100”)
  • Контроль в моменты 50%-ной готовности работ (метод “50-50”)
  • Контроль в определенных точках проекта (метод контроля по вехам)
  • Регулярный оперативный контроль (через равные промежутки времени)
  • Контроль “по запросу” (требование заказчика узнать статус проекта)

Корректирующие действия можно условно поделить на несколько основных групп:

  • Пересмотр бюджета
  • Изменение сроков выполнения
  • Изменение объема работ или снижение качества
  • Прекращение проекта

Как видно из этих групп, корректирующие действия находятся в рамках “проектного треугольника”: бюджет — сроки — объем работ (содержание) проекта.
Основные сценарии такие:

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

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

Сбор информации и отчеты

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

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

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

Общение с заказчиком происходит в рамках культуры коммуникации, принятых в компании заказчика (более формальный подход, строго по делу или более дружеская беседа с добавлением личных историй о прошлых выходных), а после каждой встречи или созвона необходимо отправлять письмо с результатам, принятыми решениями и оставшимися открытыми вопросами. К принятым решениям, если необходимы дальнейшие действия, указываются ответственные за их исполнение лица и сроки. Аналогичная информация указывается к открытым вопросам. Зафиксированные решения могут сыграть за или против вас. Не зафиксированные – точно сыграют против. Решения придется объяснять и аргументировать, возможно даже не один раз, будьте всегда готовы обосновать выбор архитектуры, технологии, инструмента, подрядчика и последовательность работ по проекту. Зафиксируйте основания для решений в документах или протоколах совещаний команды.

Качество

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

Риски

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

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

Команда

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

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

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

Документация

В компании может быть PMO и стандарты документации, описано где она хранится (google drive, SharePoint, OneDrive, Confluence, локальный сетевой диск и т.д) и в какой форме (excel, word, pdf и т.д). 

Если такого стандарта не принято, ПМ выбирает исходя из своего опыта, посоветовавшись с командой, что им будет удобнее для работы, с учетом обеспечения безопасности информации по проекту, которая может попадать под NDA (соглашение о неразглашении). На моем опыте на одном из проектов в компании, где я работал, был скандал, когда оказалось, что гугл индексирует личный гугл драйв и пароль к админке большого корпоративного сервиса, который мы разрабатывали, можно было просто найти в гугле, потому что ПМ хранил проектные файлы в личном аккаунте гугл драйв.Безопасной практикой считается не размещать документы, содержащие финансовую информацию или содержащие личные данные в местах, которые не обеспечивают соответствующего уровня безопасности (к ним относятся, например, мессенджеры, личные аккаунты в облачных хранилищах и т.д).

Содержание/обьем работ проекта (scope)

Процедуру управления/согласования запросов на изменение (CR) я подробно описывал в разборе кейса на эту тему

Основная сложность этой области контроля — четко понимать влияние изменений на проект и принимать меры до того, как накопившиеся изменения превратятся в оползень, который разрушит изначальную архитектуру вашего проекта и приведет к серьезным переработкам уже сделанного обьема. Вполне возможно в какой то момент заказчик поймет, что изначальные цели более не соответствуют бизнес запросу и нужно будет переработать многие основополагающие документы проекта (устав, цели, бюджет, календарный план и т.д), фактически перезапустив проект. Из моего опыта такие радикальные действия предпринимаются крайне редко и в большинстве случаев заказчик будет стараться изменить курс проекта с помощью внесение изменений в изначальные планы. ПМ показывает заказчику влияние этих изменений, их стоимость и долгосрочное влияние, помогая принимать информированные бизнес решения, связанные с внесением этих изменений.

Все проходит намного легче, если вы работает по типу контракта T&M и с использованием гибких подходов к разработке. Это сильно снижает цену таких изменений, но всегда помните, что несмотря на то, что подход гибкий — архитектура вашего проекта чаще всего имеет весьма ограниченную гибкость и ее переработка всегда дорого обходится. В идеале, мы закладываем архитектуру с определенным обьемом гибкости и далее вносим изменения в изначальные планы, которые укладываются в этот заложенный обьем гибкости. Мы стараемся соблюдать некоторый баланс по стоимости всех движущих частей проекта. Если мы будем закладывать слишком общую архитектуру сразу — она может быть не так эффективна в большинстве случаев и поддержка ее в этом виде будет отнимать больше времени разработки. Если мы сразу заложим самую эффективную архитектуру, специализированную под только один тип задач и условий, то можем оказаться заложниками этого решения в дальнейшем, если увидим, что изменился бизнес контекст или на основании обратной связи от наших пользователей.

Сроки/календарный план

Когда проект начинает отклоняться от базового плана, необходимо предпринять корректирующие действия для того, чтобы вернуться на прежнюю траекторию. В английской литературе указывают 2 основных способа, без изменения сроков и обьема работ — Crashing и Fast-tracking. Ниже указаны все действия и к какой из терминов они описывают. Если проект начинает опаздывать по срокам, то мы можем:

  1. добавить больше ресурсов (разработчиков) на те этапы проекта, которые можно выполнять параллельно, чтобы выполнить эти этапы быстрее. Сильно зависит от наличия ресурсов и наличия буфера бюджета на это. (crashing)
  2. изменить дату старта некоторых работ. Например мы можем начать разработку раньше, не дожидаясь пока дизайн будет закончен полностью. Это несет риск того, что позже нам придется что-то переделать из-за того, что дизайн изменился. (fast-tracking)
  3. перенести срок сдачи проекта.
  4. уменьшить обьем работ, то есть просто исключить какой то функционал из списка работ или изменить содержание какого то пакета работ на другой, более короткий.

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

Немного больше про это я писал в разборе кейса про коммуникацию о проблемах на проекте

Очень внимательно относитесь к тем дедлайнам, которые назначил клиент. Очень важно понять, чем на самом деле мотивированы именно такие сроки. Если вы сможете узнать что стоит за выбором даты, вы сможете понять, насколько эта дата может меняться и что может на это повлиять. Перенос сроков часто рассматривается как негативное явление, но это совершенно необязательно, ведь изначальные сроки могут быть выбраны просто “на глазок”, до составления каких бы то ни было реалистичных планов реализации проекта.

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

Спасибо Белковец Александр. Оригинал статьи тут

прочли: 543

Получай сообщения о новых видео, статьях, документах и событиях раз в неделю!

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

LAMPOVOE IT: сообщество не программистов will use the information you provide on this form to be in touch with you and to provide updates and marketing.