• Думать на ход вперед

    Posted on February 20th, 2009 Александр Орлов 4 comments

    Не так давно я решил сделать тренинг по работе в распределенном проекте. По всяким психологическим аспектам, коммуникациям, инструментам и пр. Собственно, программа уже практически готова. Думаю, ближе к концу марта мы его запустим. Тренинг, естественно, будет распределенным. :)

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

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

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

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

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

    Поэтому, начиная распределенный проект:

    • Обратите внимание на то, насколько зрелые люди в нем участвуют. Зрелые – в плане думать на ход вперед.
    • Приготовьтесь к задержкам и непониманию. Это нормально. Но каждый такой случай – это комбинация, которая должна быть зафиксирована в памяти людей. Чтобы в следующий раз они про нее вспоминали.

    Хорошая новость: играть на уровне 4-го разряда могут все. :) Если захотят. А почему могут не захотеть – думается, тема отдельного поста. :)

     

    4 responses to “Думать на ход вперед”

    1. Хочется добавить следующее
      1) Из изложенного в посте ясно, что сильно возрастает потребность в чёткости коммуникаций. Продумайте и зафиксируете, как вы будете общатся с удалённой командой. Общая рекомендация такая:
      а) для знакомства рекомендуется 1 Vidoconference (подумайте о ресурсах – тех. средствах), крайне желательно все _критичные_ проблемы также разбирать на Video status meeting еженедельно. Смысл тут такой – проще решать конфликты и недопонимания, когда есть невербальная обратная связь (не забываем, что мы не native-speakers, и, скорее всего навыки общения (и fluent язык) развиты только у менеджера, что прискорбно, но обычно).
      b) для обсуждения текущих проблем – ежедневные (регулярные, зависит от итераций или project tracking points) phone conf. Состав участников – минимальный. (Важно, чтобы кол-во часов проводимых в конференциях, не перебивало кол-во часов для работы, не более 1 конференции в день. Для переговорщиков – не более 2-х)
      c) основные коммуникации – письменные. Обсудитье и согласитесь с общими положениями реагирования на mails (приоритеты) и следуйте им, чётко обсудите обязательные для заполнения поля в bug tracking system. Возможно, (в начале) делайте ревью багов перед assign (это касается как Dev так и QA) на удалённую команду.

      2) Все решения тактического порядка (не говоря уж о стратегических) должны быть доведены до удалённых команд. (Документирование процесса, однако тут важно не переборщить).

      3) С каждой стороны должен быть 1 переговорщик с публично и жёстко закреплённым графиком availability. Опять же – если вам дан моб.телефон, не стоит беспокоить человека в 2 часа ночи по его времени. Имейте совесть.
      Основной смысл переговорщика – не “козёл отпущения”, а наделённый опред. полномочиями коллега, который _помогает_ _ВАМ_ добиваться результата. Основная его обязанность – довести информацию до ответственного человека. Проблему решаете вы с этим человеком. Переговорщик вас с ним свёл – всё. Это необходимое, но не достаточное условие. Переговорщик должен быть в курсе проекта и участвовать в нём. (Это моё мнение, я считаю, что внешний человек тут не эффективен).

      4) Всегда занимайте позицию “Он прав”, когда вы не понимаете, в чём проблема. Ишите смысл, может быть даже и в не очень корректных формулировках.

      как-то так. Понятно, это не всё.
      Извините за менторский тон, я не нарочно.

    2. Данила, все в тему, спасибо. Половину постов теперь могу не писать. :)

    3. Григорий Кнеллер

      Я два года работал в такой распределенной команде. Очень помогает системы issue tracking. Делаешь чего-то и параллельно ведешь дневник того что сделал в такой системе – копи-пастом команд, кода, чатов, комментариями. Потом товарищи легко могут подхватить. Обычно достаточно было номер тикета бросить в чат.

      Самая удобная и гибкая система и из тех что я пробовал – JIRA, очень рекомендую. Я ее использую для личных проектов и домашних дел (персональная лицензия у них бесплатная сейчас)

      А переговоры… Раз в неделю – обязательно кто-то – тимлид или каждый по очереди – должен собирать на телеконфу всю команду . Чаще раза в неделю – только при острой необходимости.

    4. Частота телеконференций, наверное, от специфики проекта зависит.

      А по поводу issue tracker’ов – это, конечно, маст. При этом должна еще быть выработана культура того, что туда писать, чтобы JIRA или Bugzilla не становилась кладбищем кода. :)

    Leave a reply

    You must be logged in to post a comment.