Мессенджер как инструмент «ручного» управления проектом

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

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

Продукт за три месяца

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

Строительство на 14 объектах в семи городах России должно было начаться не позднее ноября 2017. На разработку продукта, согласование, закупку, мобилизацию людей на местах было всего три месяца. Текущего инженерного состава было явно недостаточно для реализации всех задач в этот срок. Было принято решение о привлечении фрилансеров. В их задачу входила потоковая разработка технических решений под управлением ГИПов. Инженерная проработка и увязка планировочных, архитектурных, инженерных, инфраструктурных и технологических решений в комфортные сроки, как правило, выполняется последовательно от этапа к этапу с минимально необходимым «перехлестом» в задачах. В моем проекте речь шла о параллельной разработке в один этап без права на переработку – все замечания должны быть отработаны с федеральными и региональными кураторами в режиме онлайн.

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

Семь причин срыва сроков

Разберем семь распространенных причин срыва сроков при разработке продукта в разрезе реализации описываемого проекта.

1. Правила коммуникаций не адаптированы под проект

Члены команды – профессионалы, но работают в обычном режиме и привычном формате коммуникаций. Ручное управление, ненормируемый рабочий день и неопределенность в исходных данных вносят дискомфорт в привычный размеренный ритм большинства сотрудников.
Адаптация правил коммуникаций не определена в списке приоритетных задач проекта и пущена на самотек. У руководителя проекта нет опыта подстройки правил коммуникаций.
Руководитель проекта и менеджер по продукту действуют по существующим в компании стандартным регламентам и правилам коммуникаций step-by-step без учета графика проекта. При ручном управлении удаленным проектом по разработке продукта роли руководителя проекта и менеджера по продукту лучше объединить, так как классический подход к управлению сроками классического РП разбивается о ежедневные нюансы разработки и не работает.

2. Правила есть, но не исполняются

Члены команды не соблюдают дисциплину и работают в привычном режиме и формате.
Руководитель проекта/менеджер по продукту не в авторитете. При ручном управлении слаженная работа коллектива особенно зависит от личных качеств и вовлеченности руководителя.
Команда подобрана неверно. При ручном управлении разработкой требуется особый настрой и мотивация членов команды. Но и при высокой мотивации не все могут справиться. Способность быстро войти и держать ритм проекта необходимо учитывать при подборе персонала и рассматривать наравне с экспертностью.

3. Цель неясна или задача поставлена некорректно

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

4. Никто не управляет изменениями

Задачи участникам не синхронизированы друг с другом и общим планом. В проекте хаос.
Руководитель проекта не в состоянии оценить влияние изменений на результат и пускает на самотек или бесконтрольно делегирует эти функции инженерам. Так как инженеры заняты только разработкой руководителю проекта целесообразно подключить администратора проекта для контроля изменений.
Изменения оговорены контрактом с паушальной ценой. Их стоимость учтена в смете в составе основного объема работ. В проектах с фиксированной ценой контракта изменения могут быть включены в состав разработки. Облик продукта может меняться на протяжении всего цикла работы. Привыкая к «корзинной» работе, команда не ведет проектный учет изменений, так как не мотивирована на получение дополнительной прибыли от ее результатов.

5. Нет «бэкапа» экспертов

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

6. План-график «дрейфует» и не обновляется

Объем изменений и неопределенность ключевых технических решений «размазывают» сроки.
Руководитель проекта не отслеживает ключевые точки проекта. При ручном управлении контроль и обновление плана-графика должно вестись на ежедневной, а в особых случаях и на ежечасной основе.
Заказчик сдвигает промежуточные сроки, не сдвигая окончательные.

7. Нет Skype-звонков и мозговых штурмов онлайн

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

Особенности удаленной работы команды ГИПов

ГИП (главный инженер проекта) – особая категория опытных инженеров высшей квалификации. Организация работы группы из нескольких сильных ГИПов – отдельная управленческая задача. В этом проекте я решил ее, применив свое проверенное на практике правило «3Д» (Договоренности, Доверие, Дисциплина).

Договоренности. До начала работ каждому эксперту были озвучены условия работы и оплаты. Привожу некоторые из условий: ненормируемый рабочий день, всегда на связи, бэкап коллеги (в случае болезни, командировки), выполнение черновой работы в случае необходимости, работа «с листа», многократная полная переработка проекта в тот же срок, ответственность за результат в своей специализации, нахождение в проекте до конца, гибкий график.
Доверие. В ручном режиме управления большая часть поручений и задач ставится в свободной форме. После постановки задачи я был уверен в ее выполнении в срок, а ГИП был уверен в гибкости своего графика и рассчитывал на уступки. Напоминать о просроченных задачах мне приходилось крайне редко, ГИПы сами отслеживали статусы по промежуточным задачам.
Дисциплина. Наличие первых двух пунктов бессмысленно без обязательств их исполнения.

Мессенджер как инструмент проектного управления

Мессенджер имеет перед классическими инструментами (почтовые программы, SMS, MMS) ряд явных преимуществ:

Моментальная доставка сообщений и оповещение о них. Смартфон у всех под рукой и риск пропустить сообщение при наличии интернета сводится к нулю.
Лишних нет. Не нужно тратить время на выбор адресата, набирать копии сотрудников в строке адрес. В чате находятся все, кто вам нужен. За списком участников следит администратор.
Наглядное представление. В ленте сообщений вы видите целое дерево сообщений с комментариями, не нужно открывать каждый раз новое письмо, если темы писем разные, а специализация одна.
Удобный интерфейс. Текст, файлы, звуковые сообщения, фото и видео отправляются в два клика.
Чат-боты. Эти цифровые помощники помогают формализовать, организовать и помочь контролировать работу участников чата через удобные меню и моментальные ответы, подсказки и руководства к действию.

Семь общих правил коммуникаций в мессенджере

Ниже список разработанных и проверенных в проекте общих правил работы с мессенджером.

1. Управление. Одна специализация = один чат = один ответственный главный инженер.

Каждый технический чат должен управляться одним ответственным «технарем» и контролироваться одним РП. Один главный инженер ведет не более двух чатов, общее количество чатов в проекте не более 10.

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

2. Контент. Никакого спама! Все сообщения только по теме чата. Шутки, лирические отступления по теме, приколы выносить в отдельный чат. Ответы на вопросы и пояснения даются по телефону, не отвлекая остальных участников от сути. Каждый из участников несет ответственность за содержание чата. Ясность изложения, четкость формулировок, конкретика и уважение к участникам – основные ограничения при написании сообщений. В тексте лучше не использовать лишние значки, они отвлекают от контента. Тогда отставшим от чата всегда легко и быстро удастся найти глазами в ленте важные и срочные задачи и включиться. Аудиозаписи голоса старайтесь использовать по минимуму. Спустя время через поиск вы не найдете записанную в них информацию, а прослушивать все записи заново займет много времени.

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

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

5. Вопрос-ответ. Лимит времени для ответа на простой вопрос — 15 минут. Ответ на сложный вопрос — 1 час. Если ответ на вопрос требует отвлечения более чем на 1 час, вопрос разбивается на насколько простых, либо уводится в отдельный чат.

6. Документооборот. Готовые к оформлению документы обсуждаются в чате, но должны дублироваться в официальные источники проекта (почта, серверы, CRM). При этом версионность документов должна фиксироваться в чатах в виде ссылок на новую версию и комментариев к ее особенностям. Коллективная работа со старыми версиями документов зачастую приводит к финансовым потерям, попадая в разряд бросовой.

7. Живое общение. Длительное общение онлайн часто замыкает участников на тотальную переписку. Задача руководителя проекта/менеджера по продукту – организовывать регулярные конференц- и скайп-звонки для общения. В результате участники получат необходимую эмоциональную разрядку, а поток в чатах будет быстрее и конкретнее.

Семь решений

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

1. Правила коммуникаций. Проектное решение — четкое понимание правил до старта проекта: отсеивает лишних и настройка оставшихся.

2. Дисциплина исполнения. Проектное решение – авторитетный РП полностью вовлечен в проект. Внедрено правило «3Д». Применение семи правил работы с мессенджером дисциплинирует участников.

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

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

5. «Бэкап» экспертов. Проектное решение – с каждым экспертом до начала проекта был согласован его бэкап-функционал.

6. План-график. Проектное решение – ежедневный апдейт, графика и анализ событий на критическом пути показывает точки невозврата. Управление отклонениями – немедленное и адресное.

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

***

Ручное управление при параллельном выполнении задач разработки продукта требует максимальной самоотдачи от каждого участника команды. Проверять вновь сформированную команду на таком проекте я вам не советую — нет времени на «притирку». Но даже в самой неопределенной ситуации в проекте заранее согласованные правила коммуникаций и удобный инструмент онлайн-управления способны не только удержать ситуацию, но и обеспечить выполнение обязательств в срок!

+10253 Владимир Зонзов Директор по производству, Украина 25 января 2019, 12:19

Виктор Королько,

спасибо за эмоциональную устойчивость и конструктивный ответ. Поясню, что мне не понравилось в Вашей статье; и (очень кратко) как я понимаю работу ГИП-а при удалённости участников команд проектов.

1. Не указана область деятельности. Строительство – это слишком обширная деятельность. 3 месяца для полного цикла «разработка проекта – согласование проекта – строительство по проекту» – категорически нереальный срок. У Вас же (как я понял по ссылке в Вашем профиле) всего лишь – «слаботочка». И даже эту область надо сузить – «охранная сигнализация».

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

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

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

2. По каждому заказу, работая ГИП-ом, Вы лично делаете следующее:

2.1.Общаясь с заказчиком, выясняете задание для работы.
2.2.Дробите работу на части, соответственно имеющемуся набору спецов.
2.3.Выдаёте части по п.2.2 соответствующим спецам. Техника этого дела – отдельный вопрос; но, очень важный (из-за удалённого режима работы спецов).
2.4.Контролируете-координируете-корректируете работу каждого спеца. То же самое делаете и в части средств организации общей удалённой работы.
2.5.Крайне важно для удалённой работы обеспечивать каждому участнику команды (по каждому проекту) его понимание его места в работе и зависимости общего результата от его частных результатов.
2.6.Также крайне важно позаботиться о мотивации труда каждого из участников команд проектов. Собственно, с этого надо начинать общение по п.2.3.

3. И только после «прорисовки» предельно простого (насколько возможно без потери сути) «скелета рыбы» (или «основных веток дерева»), можно приняться за усложнения; приняться описывать подробности типа "Особенности ...", "Семь общих правил ...", и т.д.. Только в этом случае, внимание читателя не потеряется в усложнениях; и читателю будет понятно куда «складировать» подробности. Иначе, получается не чтение статьи, а участие в ералаше.

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