Как создать хорошие отношения между работниками отделов продакт-менеджмента, разработки и дизайна: опыт LinkedIN

Почему разработчики, продакты и дизайнеры говорят на разных языках?

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

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

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

Но что же на самом деле происходит в команде? Это командный путь, и я почти уверена, что в данном случае он прост и лёгок. Но в эмоциональном плане мы будто катаемся на американских горках всякий раз, когда начинаем процесс или проект, подобный этому. Причина в том, что мы не принимаем во внимание, что иногда ситуация может стать действительно напряженной, и мы не знаем, как говорить об этих проблемах или об этих конкретных вопросах, которые у нас есть, и мы тянем на себе этот груз с начальной точки проекта до самого конца. И все просто измучены этими сумасшедшими изменениями эмоций. Это всего лишь пример, все может меняться на протяжении всего проекта. У нас есть пара дизайнеров, в середине разработки они могут сказать что-то вроде: «эй, подождите, я должен улучшить этот проект, так как пиксели еще не идеальны»; или у нас есть продакт-менеджер, который говорит: «мы должны что-то переделать, так как мы не учли новые условия»; а затем инженер говорит что-то вроде: «ну, вы знаете, у этого проекта отсутствуют некоторые положения» или «у нас недостаточно технических характеристик или документации»; и в конце концов ваш руководитель или владелец продукта может сказать: «ну, вы знаете, конечно, я не хотел бы так делать, но мы изменяем рамки проекта, потому что на самом деле я так захотел».

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

Партнерство прежде всего

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

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

Общее видение результата

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

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

Говорите больше!

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

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

Зона прений: правила поведения

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

Но знаете ли вы, что на самом деле происходит на каждой из этих фаз? Всякий раз, когда у вас есть новая тема для разговора о новом условии или чем-то еще более конкретном, что включает в себя все возможности проекта и весь его контекст, вы входите в так называемую «зону прений» (англ. Groan zone). Это не новый термин, Сэм Кэнер придумал его давным-давно. Я уверена, что вы сталкивались с ней, хотя и не знали, что она так называется. Это «зона прений», и это – то неприятное состояние и ну лучшее время в командной динамике, это те фазы вашего проекта, когда становится трудно, все идет наперекосяк. Может быть, вы не учли некоторые условия, может быть, вы провели недостаточно исследований, и вы пытаетесь прийти к каким-либо компромиссам на ходу, а все не согласны. Это то состояние, которое все ненавидят, но очень важно убедиться, что вы успешно разрешаете эти конфликты. И вы делаете это, не осознавая, что вы это делаете. Действительно легко запутаться во всех безграничных возможностях тем или требований. Особенно, как продакт-дизайнерам нам просто нравится превосходить ожидания относительно функциональных возможностей нашего продукта, и я уверена, что продакт-менеджеры и разработчики также очень хотят создать что-то по-настоящему стоящее. Каждый хочет сделать свою работу на высшем уровне. Но очень сложно просто следовать этим конкретным бесконечным возможностям всякий раз, когда вы ищете решение.

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

Упреждающее решение проблем

Также очень важно учитывать, что мир постоянно меняется. Мы все это хорошо знаем. Также, как и условия проекта. Ничто не вечно, все может сильно поменяться на конкретном этапе проекта или на протяжении всего проекта. И это означает, что вы, как профессионал, независимо от вашей области знаний, должны уметь самостоятельно управлять тем, что находится под вашим контролем. Как дизайнер, я могу сказать, что если я увижу что-то, что может принести пользу моему конечному пользователю, я этого достигну. Скорее всего, я проведу какое-то время с большим количеством пользователей, или постараюсь поговорить с заинтересованными сторонами, чтобы убедиться, что мы проводим дополнительные исследования в самом начале и в самом конце проекта.

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

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

Важные уроки, которым меня научила работа в команде

В заключение можно сказать, что то, о чем я только что говорила сводится командной динамике. Мне повезло, что я попробовала себя во всех трех областях, и мне они по-настоящему нравятся, они многому меня научили, а также позволили мне больше сопереживать своим коллегам с позиции дизайнера. Каждый старается сделать все, что в его силах; я имею в виду, что все стараются нести ответственность друг перед другом. Действительно здорово чувствовать поддержку и одновременно поддерживать других, это здорово, учитывая, что все являются вашими пользователями. На самом деле, с точки зрения дизайнеров, именно так мы думаем о решении проблемы. Мы думаем о пользователе, о том, что было бы лучше для него, но мы не всегда думаем о членах нашей команды как о пользователях, их проблемах, разочарованиях и желаниях. Так что действительно полезно проводить беседы и получать обратную связь друг от друга просто для того, чтобы узнать, что мы можем улучшить в нашем общении или в командной динамике. Если вашу работу оценили не очень хорошо, обязательно об этом поговорите и не принимайте близко к сердцу. Я почти уверена, что все будут рады помочь вам стать лучше. Поэтому действительно важно относиться ко всем одинаково.

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

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

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

Сотрудничество – это принцип, а не тактика. Я научилась этому не в школе и не на курсах. Конечно, существуют ресурсы, такие как дизайн-конференции, где многие люди делятся своим опытом, но сотрудничество – это больше о создании своего личного бренда с остальной командой очень изящным способом. Не думайте об этом как о чем-то, чему вам следует научиться (например, способам общения и способам быть более напористым, ведь для этого существует много ресурсов), и тогда вы сможете научиться чему-то большему. Подумайте о своих ценностях и принципах, которые будут определять конкретную коммуникацию и командную динамику всего проекта.

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

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

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

Ежедневная практика для установления хороших отношений в команде

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

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