Читать «Руководитель проектов. Все навыки, необходимые для работы» онлайн - страница 194

Один из первых таких случаев произошел, когда я работал на крупную технологическую компанию в 90-х годах. Моя руководительница, которая одновременно была клиенткой проекта разработки программного обеспечения, потребовала, чтобы систему подготовили и запустили в течение трех месяцев. Поскольку мы только что начали и у меня даже не было требований к проекту, я мог бы сказать: «Хорошо, мы все сделаем», — а потом спрятаться на рабочем месте, надеясь, что как-нибудь справлюсь, но прекрасно понимая, что это маловероятно. Вместо этого я сказал: «Хорошо, только из этого ничего не выйдет. На самую простую систему ушло бы три месяца. Эта система не проста, и мы до сих пор не знаем, что должны сделать». Очевидно, она хотела бы услышать не это, но я стоял на своем.

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

Позже я столкнулся с тем, что мой проект отложили в долгий ящик вместе с другими, не обозначив, когда нам разрешат начать работу. Мой клиент, внутренняя группа разработки продукта, готовился запустить новый продукт, и ему требовались те инструменты, которые я должен был создать. Я не стал обманывать клиента. Вместо этого сказал, что, хотя надеюсь, что скоро мне позволят начать работать, ему на всякий случай лучше поискать альтернативные варианты. Несколько недель спустя нам разрешили начать работу, и у нас было достаточно времени, чтобы поддержать клиента. Тем не менее на совещании по поводу планирования, когда клиент заговорил о своих ожиданиях относительно нашего проекта, я сказал: «Спасибо, что поделились вашими ожиданиями. Давайте посмотрим, что мы можем сделать», — и объяснил, что запланировала моя команда. Оказалось, что ожидания клиента неисполнимы. Поскольку он присутствовал на совещании вместе с нами, то смог понять, какой объем работы нам предстоит проделать. Он принял этот план (перед его группой тоже возникли определенные затруднения). В итоге мы смогли выполнить наши обязательства вовремя.

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