Почему ничто никогда не бывает очевидным: искусство общения в разработке программного обеспечения

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

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

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

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

Почему это легче сказать, чем сделать? Давайте сначала проанализируем процесс общения.

Элементы связи

Более 50 лет назад Роман Якобсон представил коммуникационную модель, которая может быть очень полезна для анализа проблем с пониманием друг друга. Взгляните на схему:

Понятно, что общение — это больше, чем просто сообщение между отправителем и получателем. Контекст, канал и код влияют на сообщение и могут изменить восприятие слов. Даже если два фактора присутствуют, а один отсутствует, проблемы возникнут.

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

Всегда указывайте контекст

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

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

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

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

Используйте канал с умом

Канал — это часто забываемый коммуникационный фактор в управлении проектами. Сейчас, когда команды разработчиков очень часто работают из разных стран, когда бэкенд находится в Индии (сейчас 85% американских компаний отдают большую часть своих операций на аутсорсинг в Индию), фронтенд-разработка в Польше, а Product Owner — в США. , мы все используем множество различных инструментов для общения.

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

Мы не можем делать вид, что общение в чате — это то же самое, что общение в одной комнате с командой. Что мы можем сделать, так это помнить об ограничениях удаленного общения и пытаться их преодолеть.

Советы по эффективному удаленному общению

1. Включите камеру во время разговора по конференц-связи. В зависимости от ситуации невербальная коммуникация может составлять более 50% сообщения. Гораздо легче понять, если вы саркастичны, когда, например, другие могут вас видеть. Вы также можете видеть реакцию ваших собеседников в режиме реального времени. Вы можете заметить, путаются ли другие с вашими словами или нет.
   
2. Используйте отдельные комнаты в чате, чтобы классифицировать разговоры. Когда проект сложный, коммуникация в разработке программного обеспечения также имеет тенденцию усложняться, и постоянно появляются новые темы для обсуждения. Отдельные комнаты позволяют упорядочивать сообщения и доставлять их нужным получателям с меньшими трудностями.
   
3. Отмечайте получателей сообщений при написании через чат. Нелегко следить за каждым разговором. В ваших же интересах, чтобы человек, которому вы пишете, был уведомлен.
   
4. В письменном разговоре используйте смайлики, когда это уместно. Не используйте слишком много, но дайте аудитории понять, что вы шутите по поводу развертывания в пятницу во второй половине дня.

Проверка кода связи

В самом начале работы нужно установить общий код, чтобы одинаково понимать основные термины. Даже «очевидные». Например, у нас есть требование: «Я как пользователь могу сделать заказ только утром, чтобы выбранный товар был отправлен в тот же день». Выглядит ясно, не так ли?

Ну… Так что же именно означает утро в этой функции? Когда начинается утро? Когда восходит солнце или в точное время, т.е. в 7 утра? Если в 7:00, какой часовой пояс вы имеете в виду?

Коммуникация в управлении проектами, особенно в ИТ, должна быть кристально чистой. Здесь нет места для догадок. В нашем случае это может привести к ситуации, когда продукты нельзя заказать до 10.00 (когда главный разработчик просыпается, так что для него утро) и владелец приложения теряет деньги из-за отсутствия заказов от ранних пташек.

Лучшие практики общего коммуникационного кода

1. Создайте глоссарий с часто используемыми терминами. Это помогает в начале проекта, а новичкам очень полезно понимать язык, на котором говорит команда разработчиков.
   
2. Также хорошо спросить получателя, как он понимает требование или фразу. И я не говорю о бесполезном: «Все ли понятно?». Быть конкретной. Спросите о деталях. Убедитесь, что вас поняли. Сделайте обзор кода коммуникации.
   
   Давайте еще раз посмотрим на наш пример: чтобы прийти к общему пониманию термина «утро», попросите того, кто его употребил, перефразировать его.
   
3. Эмпирическое правило заключается в том, что при разработке программного обеспечения лучше повторяться, чем оставлять место для игр в догадки.

Вопрос экспертизы

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

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

Как избежать проблемы с экспертизой

1. Сделайте шаг назад к началу своего пути с продуктом и объясните команде разработчиков все решения, которые вы приняли. Когда они поймут, как все началось, они найдут лучшие технические решения или даже заполнят пробелы в вашем образе мышления.
   
2. Позвольте команде задать столько вопросов, сколько им нужно. В поговорке о том, что глупых вопросов не бывает, нет преувеличения.

Как эффективно общаться в команде разработчиков программного обеспечения

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

Превратите свою идею в выдающийся цифровой продукт

Давайте работать вместе

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

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

Просто поговорите с нашими специалистами Miquido и воплотите свои идеи в жизнь!