Руководители ИТ-проектов - переводчики делового мира.

Они говорят код, они говорят по-деловому, и они используют свои знания в обеих областях, чтобы заставить обе стороны организации общаться.

А иногда работа переводчика в вашей компании может быть самой неприятной частью работы менеджера проекта.

Эта проблема.

Джейсон Коэн предлагает фантастическую аналогию, когда речь идет о техническом общении с клиентами, не имеющими технического образования - это как врач, пытающийся объяснить осложнения болезни и риски, связанные с лечением, человеку, не имеющему медицинского образования. Он написал:

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

Вам придется доверять своему врачу.

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

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

Используйте существующие процессы управления проектами.

Есть причина, по которой так много технологического мира перешло на Agile. Хотя методология Waterfall предлагает простой для понимания подход к управлению проектами, она не учитывает проблемы со знаниями в начале любого проекта. Использование правильного метода может помочь улучшить общение между вами и вашим клиентом.

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

через Scrum Alliance

Используйте product owner-у, чтобы «владеть» коммуникацией между технической командой и заинтересованными сторонами. В этом конкретном случае Scrum предлагает формальный процесс для сужения коммуникации до одной точки - вы не хотите, чтобы вся ваша техническая команда пыталась переводить расплывчатые «что» исходят от ваших клиентов.

С учетом сказанного, стоит отметить, что придерживаться процесса на 100% иногда бывает обременительным. В Platforms мы на 80% полагаемся на Agile, но Agile требует гибкости даже в собственном процессе - если требуется, чтобы между нашей технической командой и нашей командой по развитию бизнеса было несколько человек, которые общаются друг с другом, мы не будем упорно держаться за них. процесс просто ради процесса.

Избегайте неопределенности задач.

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

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

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

Второй способ избежать неопределенности - использовать программное обеспечение для управления проектами . Например, существует программное обеспечение для управления проектами, специально предназначенное для улучшения взаимодействия с проектом (например, Asana ) или предназначенное для поддержки Scrum и Agile (например, Atlassian Jira ). В любом случае программное обеспечение для управления проектами - отличный ресурс, который поможет определить, что неизвестно, и создать путь к устранению этих переменных.

Стремитесь к полному общению.

В конце концов, личному общению нет замены.

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

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

Радж Чилакапати, ведущий менеджер проекта Platforms , подчеркивает, что для объяснения идей нужно использовать нечто большее, чем просто словесное общение. Например, он объясняет, что визуальные эффекты особенно хороши для представления концепций нетехническим клиентам.

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

Более?

Какие еще способы вы порекомендуете улучшить коммуникацию между техническими менеджерами проектов и нетехническими заказчиками? Эти методы работают на вас? Оставьте свои мысли ниже!