Объяснить или давать разбираться?

16 декабря 2010 г.

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

Я затрону тему возможности улучшения коммуникации.

Поступай с другими так, как хочешь, чтобы поступали с тобой?

Недавно в команде мы обратили особое внимание на следующие ситуации.

Ситуация №1

К вам подходит коллега и спрашивает, как работает компонент Х в системе формирования исходящего документа?

Ваши действия можно разделить на два варианта.

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

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

Вопрос №1: Как вы поступаете в ситуации, когда у вас просят помощи?

Ситуация №2

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

Вопрос №2: Какого отношения к себе вы ожидаете от коллеги, когда вам нужна помощь?

Наши варианты

Мы провели небольшой мозговой штурм на эту тему в своей команде. Каждый высказал свое мнение и вот несколько мыслей по каждому варианту.

Объяснять

  • Если к вам подошли с вопросом это должно подразумевать, что коллега уже попробовал разобраться сам. В другом случае у него просто не будет конкретных вопросов. Он рискует зря потратить ваше и свое время. Возможно, он сам может найти ответ за пару минут
  • Нужно объяснять, когда тема объемная и быстрее будет её объяснить самому (Каков критерий того, что тема объёмная?)
  • При объяснении важно показать общий подход к решению типичных проблем, а не просто дать коллеге готовый ответ на его проблему
  • Когда вы объясняете, вы начитаете ещё лучше разбираться в вопросе
  • Разработчики вокруг слышат ваше объяснение. Это хорошо влияет на распространение знаний в команде
  • Если вы просите помощи, то выбиваете коллегу из потока. Возможна ситуация, когда он потратит много времени на то, чтобы обратно вникнуть в свою задачу
  • После объяснения никто не мешает продолжить разбираться самостоятельно, главное дать направление для более детального изучения вопроса
  • При объяснении отнимается время сразу двух человек
  • Улучшается коммуникация в команде, т.к. минимум два человека общаются друг с другом, причем в целях личного роста
  • Тот, кому объясняют должен максимально углубиться в тему и не стесняться задавать вопросы
  • Плохо, если приходится объяснять одно и то же снова и снова

Разбирайся сам

  • Нужно отсылать на самостоятельное изучение, когда тема маленькая и простая (Как узнать, что тема не стоит объяснений? Может она простая для вас, но сложная для того, кто спрашивает?)
  • Вы хоть и ненадолго, но всё равно отвлечете коллегу от его текущего задания
  • Возможно, что самостоятельное изучение займет много времени
  • После самостоятельного изучения вам всё равно придется поговорить с коллегами, чтобы убедиться, что вы понимаете вопрос также, как они
  • Если человек разберется сам, то поймет тему лучше (Это ещё открытый вопрос, нет однозначного ответа)
  • Если вы отослали человека разбираться самостоятельно, то обязательно получите обратную связь. Убедитесь, что у него получилось разобраться. Иначе, если он не осилит вопрос, то ему будет сложнее подойти к вам второй раз. Он может бояться признаться, что так и не понял, как это работает

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

Ваши варианты

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

15 комментариев:

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

    ОтветитьУдалить
  2. Естественно, объяснить. Откуда вообще такие вопросы,,,

    ОтветитьУдалить
  3. По крайней мере для проектов с почасовой оплатой (а это, как ни крути, единственный вменяемый способ оплаты работы программиста) нашли отличное решение данной проблемы.
    Тот, кто спрашивает, за время консультации не только не получает денежку (логично, ибо иначе это поощрение "недопрофессионализма"), но ещё и берёт на себя оплату времени объясняющего (а вот профессионализм поощряется).
    Несмотря на кажущуюся жёсткость и "приземлённость" такого решения, действует отлично.

    ОтветитьУдалить
  4. @nPacker
    А какие при этом складываются отношения между участниками проекта? Есть ли проблемы?

    Возможно вы говорите про специфику именно почасовой работы на небольших проектах. Были ли у вас описанный опыт на постоянной работе?

    ОтветитьУдалить
  5. Как ни странно - отношения скорее улучшаются.
    Проекты совершенно разные и по составу команды и по сложности. Были и совсем меленькие и весьма большие.

    Единственное ограничение - принципиально стараюсь не работать в больших (более 5-ти) командах.

    А вот насчёт "постоянной работы", если речь о работе "на дядю", тут у меня опыта совершенно нет. Своя контора. :)

    ОтветитьУдалить
  6. @nPacker
    Т.е. у вас не постоянной команды?

    Как идет обмен опытом внутри команды?

    ОтветитьУдалить
  7. В команде как 2-3 постоянных участника.
    Иногда работаем с удёлнными "узкими" специалистами.

    Насчёт обмена опытом.
    Прежде всего рабочий день 4 оплачиваемых часа.
    Конечно, бывает и rush, но в основно держимся в этих границах.
    Остальное время - на своё усмотрение, так что если упёрся и нужно спросить, есть два варианта.
    1 - подождать "нерабочего времени".
    2 - отвлечь и "заплатить" за это.
    Что интересно, после введения этого правила мы не стали меньше общаться, скорее наоборот, но вот по мелочам никто друг-друга уже не отвлекает.

    Тут есть ещё один момент, когда тебя отвлекают "по мелочам", отношение к отвлекающему ухудшается.
    И тот, кто спрашивает, это чувствует, и в следующий раз, даже если проблема достаточно серьёзная, он постарается обойтись без консультаций.
    А это так же плохо (а то и хуже), как и "отвлечение по мелочам".

    ОтветитьУдалить
  8. Рекомендую книгу http://www.ajaxplanet.ru/deadline/
    http://depositfiles.com/ru/files/n7qz3s2r4

    ОтветитьУдалить
  9. @nPacker
    Спасибо!

    @Valery Moskalenko
    Книжка известная. Вы из нее какую мысль хотели донести?

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

    ОтветитьУдалить
  11. На это много факторов влияет. Как ни крути, спрашиваемый все равно сделает какую-то оценку, чтобы объяснять/не объяснять. Нельзя однозначно сказать, что нужно всегда объяснять или наоборот.
    Интересно узнать, почему вы предпочли первый вариант?

    ОтветитьУдалить
  12. @M
    > Интересно узнать, почему вы предпочли первый вариант?

    Потому что стоит один раз отказать, как вся коммуникация в команде сходит до минимума.

    ОтветитьУдалить
  13. тоже за первый вариант, но объяснять можно не во время работы, а во время перекуров или обеденного перерыва, что бы не отвлекаться от текущей задачи.

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

    ОтветитьУдалить
  15. Сергей Борисенко28 февраля 2012 г. в 00:40

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

    ОтветитьУдалить

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...