Общение несовершенно - умей управлять несовершенностью

Любой проект - это море общения.

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

  • Документация. Написание и чтение оной. Это общение, так как писатель “общается” с читателем посредством документации.
  • Дизайн архитектуры приложения или конкретных фич. Это общение, так как архитектура и фичи не возникают в голове у одного человека. И даже после того, как они возникли - их еще надо донести до окружающих.
  • Митинги, обсуждения, отчеты.
  • Планирование работы, постановка задачи. Бывают ли планирования без общения? Возможно, да, в клинических случаях. Но постановка задачи - это уж точно акт общения.
  • Занесение бага в баг трекер тестером, исправление бага программистом, проверка исправления тестером и т.д.
  • Обучение, тренинги, посещение конференций и т.п.

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

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


А как достичь совершенства в общении?

А никак! Общение между людьми несовершенно по своей природе. Все люди разные, с разными представлениями об обсуждаемой проблеме, с разным уровнем знания, с разным настроением, наконец. То, что одному человеку можно объяснить двуми словами, другому вы будете объяснять полчаса. Фраза, полная сокращений и аббревиатур будет значить очень много для опытного разработчика, знакомого с предметной областью, но для новичка это будет просто набор бессвязных слов.

Если вы смотрите доктора Хауза, то можете вспомнить, как его команда ставит диагноз - они не тратят времени на обсуждение деталей. Они говорят скупые, понятные только им, как профессионалам, слова, дают ссылки на специальные случаи и прошлый опыт и всё - диагноз поставлен. Всего 30-40 секунд и “подходит. вколите ему хрензнаетчтонин”.


Как и почему это работает?

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

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


Рассмотрим вкратце разные виды “общения” и как их можно улучшить:

  • Документация. Всегда надо точно представлять тех, кто будет читать документацию, которую вы пишете. Если вы пишете для специалистов, для Senior Developer, тогда вы можете использовать совсем другие слова и гораздо меньше текста, чем если вы пишете для начинающих. Документация для начинающих должна содержать гораздо больше информации и не должна содержать аббревиатур или общепринятых в компании терминов, которых начинающий может и не знать пока. Разберитесь вначале, кто  будет читать ту документацию, которую вы собираетесь написать и пишите в подходящем стиле. Не требуйте писать документацию “для начинающих”, если начинающие не будут ее читать. И не сажайте начинающего писать документацию для специалистов.
  • Дизайн архитектуры приложения или конкретных фич. Пригласите на обсуждение архитектуры половину Senior и половину Junior программистов и вы погубите проект. Обсуждение займет бесконечное число времени, так как вы будете тратить больше времени на объяснение понятий и теории, чем на, собственно, архитетуру. Собирайте только людей, находящихся на одном уровне понимания проблемы для обсуждения архитектуры. При этом под джуниорами я понимаю не только тех, кто только начинает работать, но и всех, кто Junior для этой конкретной обсуждаемой проблемы, кто не имеет опыта работы в этой сфере. Например, профессиональный программист с 10 годами опыта работы может быть Junior, если он попал на митинг в другой отдел и обсуждается то, о чем он понятия не имеет.
  • Митинги, обсуждения, отчеты. Тут совет такой же, как в предыдущем пункте - не пытайтесь совместить людей с разным уровнем понимания проблемы на одном митинге. Если вы хотите все же задействовать Junior-ов в обсуждениях, то соберите вместе 5 джуниоров и 1 senior - этого может быть достаточно.
  • Планирование работы, постановка задачи. Знайте уровень, на котором нужно планировать. Для Senior достаточно написать краткое описание задачи (User Story) и всё - дальше он все спланирует сам. А для Junior нужно написать детальный план. Но если вы будете тратить время на написание детального плана для Senior, то это как раз и есть неэффективность общения.
  • Занесение бага в баг трекер тестером, исправление бага программистом, проверка исправления тестером и т.д. Если программист и тестер работаю вместе не первый год, то у них свой язык общения. Они могут описать сложнейший баг одним простым предложением и ссылкой на похожий предыдущий баг. Исправление и инструкция по перепроверке может быть такой же короткой. Так что не разлучайте людей, давно работающих друг с другом.
  • Обучение, тренинги, посещение конференций и т.п. Не посылайте начинающих на конференции для профессионалов - им от этого не будет толку. И не посылайте Senior людей на тренинги про основы Python или т.п. Также сильно разочаровывает, когда на одном и том же тренинге собираются сотрудники с разным уровнем знаний - им очень сложно понять друг друга и это приводит больше к раздражению друг другом, чем к правильному результату.



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

7 комментариев к Общение несовершенно - умей управлять несовершенностью

  • Забавно читать статью, в которой сначала утверждается, что усовершенствовать общение невозможно, а потом даются советы о том, как же это сделать. Кстати, по этим советам у меня вопрос: вы их сами придумали и опробовали?

    • Забавно читать статью, в которой сначала утверждается, что усовершенствовать общение невозможно,

      Я этого не писал. Я писал, что СОВЕРШЕННОЕ общение невозможно. Но немного усовершенствовать несовершенное общение - это возможно.

      Кстати, по этим советам у меня вопрос: вы их сами придумали и опробовали?

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

      • Я писал, что СОВЕРШЕННОЕ общение невозможно. Но немного усовершенствовать несовершенное общение - это возможно.

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

        Маленький совет, если позволите: когда вы пишете в повелительном наклонении “не посылайте Senior людей на тренинги про основы Python”, то возникает вопрос: “А вы, собственно, кто такой? На основании каких данных вы пришли к таким рекомендациям? Что произойдет, если ваши рекомендации нарушить?” Если бы вы написали: “Я убедился, что бесполезно посылать Senior людей на тренинги про основы Python”, то лично я бы относился бы к вашим словам более внимательно.

        • то возникает вопрос: “А вы, собственно, кто такой? На основании каких данных вы пришли к таким рекомендациям? Что произойдет, если ваши рекомендации нарушить?”

          А этот вопрос должен возникать всегда, не только при чтении моих рекомендаций. Вы что, кому-то верите беспрекословно и выполняете все рекомендации, как написано?
          И потом, всё, что я пишу - это моё ИМХО. Как и всё, что пишут другие люди - это их ИМХО. И неважно, в повелительном наклонении это написано или нет.
          И ничего с этим не поделаешь.

  • bialix

    чудесный финал для такой статьи :-)

  • aussy

    Ну, это классика жанра. Люди мыслят “объектно” -образами, какими-то ассоциациямм и т.п. Общение словами влечет необходимость эти объекты преобразовать в поток символов, а потом выполнить обратное преобразование. Функции преобразования у каждого свои. Отсюда, собственно, все и идет.

    А вот знакомо ли вам состояние програмазма? Это когда сам себе заказчик, дизайнер, программист, тестер и т.п. Общение всех этих ипостасей внутри одних и тех же мозгов происходит без потерь на кодирование/декодирование, что ускоряет процесс в сотню раз; причем получаешь именно тот результат, какой хотел, без искажения на “не так понял” - что дает мощную обратную связь (причем положительную). “Еще чуть-чуть”, “еще немного” - продолжаешь “улучшать” и “улучшать” программу, в общем, впадаешь в програмазм ;)

    • >> А вот знакомо ли вам состояние програмазма? Это когда сам себе заказчик, дизайнер, программист, тестер и т.п.

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

Ответить

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>