Иногда руководитель проекта не показывает заказчику промежуточные результаты работы команды. В итоге заказчик не понимает, как идёт процесс разработки и что вообще происходит. Причины могут быть разными, но такой подход нередко приводит к плачевным результатам. В моей практике было как минимум четыре таких случая.
Случай первый
Руководитель проекта считал, что продукт работает не совсем верно. Хотя, с точки зрения разработчиков, это было не так. Мы были второй командой на этом проекте и пришли на смену предыдущей. Когда принимали дела, руководитель первой команды сказал, что рад избавиться от проекта, потому что совершенно не понимает, чего хочет этот руководитель. К сожалению, у нас не было доступа к представителям заказчика, и мы не могли показать хотя бы промежуточный результат. Понимая, что заказчик вечно ждать не будет, команда неоднократно просила провести демонстрацию. Руководитель проекта игнорировал эти просьбы и до последнего уверял, что всё будет хорошо. Проект в итоге закрыли, и заказчик так и не увидел, что было сделано.
Случай второй
Ещё был случай, когда руководитель проектов показал работу команды только тогда, когда проект был завершён, но ожидания заказчика не совпали с тем, что он увидел. Проект закрыли, уволив несколько руководителей, включая руководителя проектов. Стоит отметить, что в отличие от предыдущей ситуации, в этой все руководители, вплоть до руководителя команды разработки, не поднимали вопрос о показе промежуточных результатов, а на замечания сторонних наблюдателей никак не реагировали или отвечали в резкой форме. Была какая-то вера в то, что всё будет хорошо. После того как проект закрыли, начался поиск виновных. В моей практике это был единственный случай, когда так поступили: всю команду собрали в одной комнате и попросили каждого анонимно написать имя того, кто, по мнению опрашиваемого, больше всего виновен в закрытии проекта.
Случай третий
Руководитель проекта всячески избегал показа промежуточных результатов. Однако в обход него руководитель команды разработки связался с представителем заказчика и показал ему эти результаты. Его обвинили в неправильном поведении с заказчиком и саботаже. Было много шума, но, на мой взгляд, проект удалось спасти. Заказчик, увидев результаты и реакцию руководителя проекта, изменил подход к контролю выполнения работ и сам стал настойчиво требовать проведения таких показов, чтобы иметь возможность корректировать выполняемую работу.
Случай четвертый
В четвёртом случае проект успешно сдали, но заказчик отказался от дальнейшего сотрудничества, что сильно ударило по доходам компании. Причина была в слишком долгом процессе выяснения требований и оформлении документации. Пока аналитики общались с заказчиком, разработчики простаивали, а оплата за них шла. Промежуточных результатов заказчик не видел, а значит, не понимал, какие проблемы возникали в процессе работы над проектом и на что тратится время его участников. В итоге он посчитал, что цена за выполненную работу сильно завышена, и ушёл к другой компании.
Понятно, что у каждого случая есть своя особенность, и причина не только в нежелании показывать промежуточные результаты. Но, мне кажется, такие демонстрации могли бы исправить положение и спасти проект.
Что лежит в основе таких провалов
Во всех описанных случаях присутствовал скрытый организационный конфликт. Каждая сторона по-своему видит процесс разработки продукта и имеет собственные опасения. Как минимум можно выделить два типа конфликтов: интересов и доверия.
Конфликт интересов
Заказчик хочет вовлечённости, предсказуемости и контроля.
Руководитель проекта стремится к стабильности и тишине, действует по принципу: "довести до конца, а потом покажем".
Команда хочет ясности, поддержки и уверенности в адекватности заказчика.
Конфликт доверия
Руководитель проекта не доверяет команде: "Покажем — опозоримся".
Команда не доверяет руководителю проекта: "Он нас не слышит".
Заказчик не доверяет подрядчику: "Они меня игнорируют".
Сокрытие промежуточных результатов может происходить по разным причинам:
Организационные барьеры. Прямой доступ к заказчику либо невозможен, либо затруднён. Это может быть связано с условиями договора или внутренними требованиями компании. Например, показ сторонним организациям допускается только после внутренней сертификации, которая может занимать длительное время.
Сложный заказчик. Во время демонстрации он может вести себя экспрессивно: кричать, что всё пропало, менять требования, превращать обсуждение в допрос с пристрастием, пытаться увеличить объём работ без пересмотра условий контракта.
Проблемы на стороне клиента. Иногда в проект вовлечено несколько человек с разными взглядами и требованиями к продукту. Либо наоборот — заказчик не проявляет интереса к промежуточным результатам и избегает контакта.
Страх ошибки. Руководитель проекта хочет, чтобы все было идеально и боится оступиться. Во время демонстрации промежуточных результатов могут всплыть различные недоработки - что-то не учли, что-то забыли. Некоторые руководители боятся, что их могут обвинить в некомпетентности после такой забывчивости и предпочитают что-то показывать только тогда, когда максимально уверенны в проделанной работе.
Финансовые риски. Руководитель проекта стремится уточнить все требования заранее, чтобы точно просчитать бюджет. Промежуточные показы могут привести к изменениям и дополнительным требованиям, из-за чего появляется риск выйти за рамки бюджета.
Желание скрыть внутреннюю кухню. Команда может не хотеть показывать оптимизации или упрощения, которые, по их мнению, не повлияют на финальный результат, но могут быть восприняты заказчиком негативно.
Из всего перечисленного видно, что причин может быть множество. Такой подход имеет как минусы, так и определённые плюсы, но в большинстве случаев он увеличивает риски.
Риски и негативные последствия
Отсутствие прозрачности и вовлеченности заказчика значительно повышает риски провала проекта и потери клиента. Возникают опасения за судьбу проекта и сомнения в его успехе. Можно выделить как минимум три болевые точки такого подхода:
Риск “чёрного ящика” — заказчик не видит продукт, теряет доверие и контроль, а в итоге — деньги.
Разрыв в восприятии продукта — ожидания заказчика формируются без сопоставления с реальностью, и в финале возникает эффект неожиданности.
Уход от ответственности — руководитель проекта действует по принципу “или пан, или пропал”, надеясь на чудо в конце.
В своей практике я видел и конкретные последствия такого подхода:
Заказчик остановил финансирование, не дождавшись результата.
После финального показа клиент остался недоволен работой, закрыл проект и выставил неустойку.
Заказчик предъявил дополнительные претензии после финального показа и потребовал их устранения за счёт поставщика.
Клиент принял проект, но прекратил дальнейшее сотрудничество с компанией.
Что может сделать руководитель команды разработки
На нежелание или отсутствие возможности демонстрировать промежуточные результаты руководитель команды разработки не всегда может повлиять. В некоторых случаях это выходит за рамки его компетенций. Однако, чтобы изменить такой подход или хотя бы минимизировать его последствия, можно сделать следующее:
Регулярно проводить внутри команды показы промежуточных результатов и записывать их на видео.
Вести дневник разработки: короткие видео с демонстрацией изменений после каждой итерации, сопровождаемые текстовым описанием.
По возможности предоставить доступ к этому дневнику представителю заказчика, чтобы он мог видеть текущее состояние проекта — если это не противоречит политике компании. Если же противоречит, важно иметь дневник под рукой, чтобы документально подтвердить объём и ход выполненных работ.
При обсуждении новых задач или изменений прикладывать к переписке скриншоты работающего приложения, на которых виден прогресс и внешний вид продукта.
Чётко фиксировать итоги встреч и переговоров с заказчиком — по электронной почте с рассылкой всем заинтересованным участникам.
Стремиться к расширению прямого контакта с заказчиком.
Искать поводы для показа промежуточных результатов: предлагать контрольные точки, на которых можно демонстрировать, что у нас получается, чтобы лучше удовлетворить ожидания заказчика.
Попробовать изменить точку зрения руководителя проекта: обсудить с ним причины его опасений в отношении демонстрации промежуточных результатов.
Что говорят практики и теоретики управления проектами
Данная проблема не нова и в современном мире подробно изучена. Во многих руководствах по управлению проектами подчёркивается важность максимальной прозрачности при взаимодействии с заказчиком. Ниже я собрал подходы и решения этой проблемы с точки зрения различных изданий, институтов и авторов:
Project Management Institute. PMBOK Guide, 7th Edition
Принцип Stakeholder Engagement — управление ожиданиями заинтересованных сторон требует регулярной коммуникации и демонстрации прогресса.
Решение: создание плана коммуникаций с указанием частоты и формата демонстрации результатов.Sutherland, J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time
Подход: Scrum предполагает демонстрацию инкремента продукта в конце каждого спринта. Демо — обязательный инструмент получения обратной связи.
Решение: внедрение базовых Agile-практик (даже без полной трансформации) позволяет заказчику видеть промежуточный результат и влиять на продукт в процессе.Brooks, F. P. (1995). The Mythical Man-Month
Подход: информационный вакуум и ложный оптимизм — частые ошибки в проектах. Сокрытие прогресса почти всегда приводит к катастрофе.
Решение: создание прозрачной системы отчётности и промежуточных контрольных точек.Argyris, C. (1990). Overcoming Organizational Defenses: Facilitating Organizational Learning
Подход: руководитель проекта может избегать показа результатов из страха критики — это форма защитного поведения. Такие рутины мешают обучению и создают культуру, в которой нельзя показать недоработку.
Решение: беседы в стиле double-loop learning, где обсуждаются не только действия, но и скрытые установки ("почему ты считаешь, что не стоит показывать промежуточный результат?").Lencioni, P. (2002). The Five Dysfunctions of a Team
Подход: одна из ключевых дисфункций команды — отсутствие доверия и страх конфликта.
Решение: регулярные ретроспективы и открытые обсуждения внутри команды. Нормализация "здоровых" конфликтов как способ предотвращения кризисов.
Вывод
Несмотря на то, что принцип открытости и доверия вроде бы всем понятен, на деле ему следуют далеко не всегда. Причины бывают разные — страх, неопределённость, желание подстраховаться. Но итог почти всегда один: срыв сроков, недовольство заказчика и потери для компании. В каждом из описанных случаев всё могло пойти иначе, если бы промежуточные результаты стали частью рабочего процесса, а не чем-то опасным. Иногда даже один простой показ может изменить весь ход проекта.
P.S.
Понравилось? Поддержите лайком!