Если вы начинаете свою карьеру в области управления проектами, возглавляя agile-инициативы, то клиент всегда находится в центре всего, что происходит. Каждая итерация решения рассматривается пользователями, и отзывы напрямую влияют на будущие итерации. Но в традиционной реализации проекта все немного иначе.
У каждого подхода есть свои преимущества и недостатки, и организациям необходимо иметь возможность выполнять работу как можно большим количеством различных способов.
Тем не менее, нельзя отрицать, что традиционная реализация проектов, когда многие новые продакт-менеджеры получают свой первый опыт управления проектами, часто требует небольшого участия пользователей и клиентов после начала работы, по крайней мере, до этапа тестирования.
В результате проектные группы могут легко упустить из виду тот факт, что их работа в конечном итоге будет использоваться реальными людьми — сотрудниками, применяющими процессы или взаимодействующими с разрабатываемыми системами; клиенты, покупающие продукт или услугу; и так далее. Каждый член команды понимает это с концептуальной точки зрения, но последствия могут быть утеряны.
Влияние решений
Вот пример из проектов, которым я руководил несколько лет назад. Мы строили новую систему для сотрудников, и одна из функций требовала ввода большого количества полей. Нас попросили хранить все эти входные данные на одном экране, потому что процесс сохранения данных на полпути был медленным из-за ограничений компьютера в то время.
Нам это удалось, но в макете было мало логики — поля располагались там, где они подходят, а не там, где они естественным образом появляются в зависимости от заполнения информации. Мы достигли поставленных целей, и пользователям это не понравилось. Нам пришлось исправить это менее чем через две недели после запуска.
В то время я был неопытным руководителем проекта и, хотя я осознавал, что разрабатываемое нами решение не было идеальным, я считал важным реализовать проект, отвечающий задокументированным требованиям. Я хотел, чтобы данные для этой функции не распространялись по двум экранам, как это было предусмотрено.
Я был совершенно неправ. Это то, о чем сегодня должны помнить новые продакт-менеджеры: хотя детали будут другими, продакт-менеджеры — и, соответственно, возглавляемые ими команды — никогда не должны упускать из виду тот факт, что их выбор влияет на реальных людей.
Это может показаться очевидным утверждением, но поверьте мне — будут времена, когда делать правильные вещи для этих пользователей будет означать компрометацию того, к чему явно призывают требования. Я не предлагаю, чтобы PM автоматически игнорировал эти требования, но я предлагаю, чтобы они облегчили обсуждение со спонсором и представителем клиента, чтобы договориться о наилучшем плане действий.
Это относится ко всем проектам и всем менеджерам проектов, но для новых менеджеров проектов это может быть сложнее. Без собственного опыта существует тенденция придавать слишком большое значение формальным требованиям, взглядам заинтересованных сторон и т. д.
Однако эти требования и перспективы были разработаны с неполной информацией. По мере продвижения проекта появляется лучшее понимание того, что можно и что нужно сделать. Менеджер проекта лучше всего это понимает, и он должен сообщать о любых потенциальных отклонениях или проблемах ключевым заинтересованным сторонам.
Это не вызовет разочарования в связи с тем, что менеджер по проектам не просто следует документированным требованиям; это приведет к удовлетворению того, что даже новый менеджер проекта готов отметить потенциальные скрытые проблемы и сотрудничать, чтобы попытаться найти лучшее решение.
Помните, что проект может быть одноразовым, но он создаст решение, которое будет использоваться многими людьми в течение длительного периода времени. И во многих случаях это решение будет ориентировано на клиентов, которым необходимо получать доход, прибыль и удовлетворение клиентов. Это не может быть скомпрометировано просто из-за плохо продуманного маркера в документе с требованиями.
Проактивность лучше всего.
Гибкие методы реализации проектов сознательно вовлекают пользователей в процесс разработки. Нет правила, которое говорит, что это не может произойти в более традиционных подходах к реализации проектов.
Возьмем мой пример плохого потока информации на экране. Когда нам пришлось это изменить, мы сделали это в виде исправления. Но детали того, как спроектировать это исправление, были взяты не из другого документа с требованиями, а из обсуждений с пользователями, получения их коллективного мнения о том, что необходимо, и получения их одобрения проекта перед реализацией.
Более активное взаимодействие с пользователями, фокус-группами и т. д. в процессе разработки может помочь выявить потенциальные проблемы раньше, когда их будет проще, быстрее и дешевле решить. Новые менеджеры проектов не должны бояться предлагать такое взаимодействие своим заинтересованным сторонам, независимо от того, как выполняется работа.
Практический результат.
Проекты не утверждены для достижения определенного объема. Они одобрены для предоставления решений, которые помогают бизнесу. Руководители проектов должны постоянно помнить об этом, ставя себя на место пользователей, когда это возможно, и напрямую взаимодействуя с этими пользователями, если это возможно. Затраты минимальны, а польза может быть значительной. И более прочные отношения, которые получатся в результате, принесут пользу всем в текущем проекте и в будущем.
Перевод СПМРК
Энди Джордан президентом Roffensian Consulting SA.
Источник: https://www.projectmanagement.com/