Опыт работы с территориально распределенными командами

Есть такая нематериальная вещь — опыт. Он, как известно и «сын ошибок трудных», и иногда – «парадоксов друг» через посредничество с не менее известным понятием — «гений»... И кстати, опыт зачастую бывает выстраданный. «Потом и кровью», сквозь «огонь, воду и медные трубы»... В общем, рассказ пойдет о личном опыте работы с удаленными командами, выступающими на подряде, и удаленными сотрудниками — на подряде и в штате.

Так получилось, что на нескольких замечательных должностях я выступал в качестве руководителя проектов (или технического руководителя проектов) в территориально распределенных командах. Вообще, если сделать лирическое отступление, территориально распределенные команды — это не то чтобы тренд, это данность. Причин тому несколько.

Во-первых, нередко оказывается, что найти специалистов в другом регионе проще, чем в своем. К тому же специалистов узких. Например, разработчика на php отыскать можно практически везде. А вот прикладного java-программиста, имеющего опыт в дописывании некоего специфического enterprise-ПО, так просто не встретишь. Точнее (с гарантией в 90%), искать будешь долго, в итоге получишь за условные «большие деньги» (профессионалы, как правило, требуют оплаты, достойной их уровня, особенно в крупных городах). Таким образом, порой проще и дешевле найти нужного специалиста именно в регионах. Проще потому, что обычно там нет достаточных задач, соответствующих его квалификации. Дешевле потому, что чем больше мы удаляемся от мегаполисов, тем ниже стоимость привлеченного специалиста.

Во-вторых, нередко есть смысл привлекать специалиста не на постоянной основе, а для решения определенной задачи. Тот же фриланс — достаточно распространенное и эффективное решение. (Про эффективность будет отдельный разговор.) В силу тех или иных причин — высокая загрузка, уникальные компетенции и так далее — легче пригласить сотрудника по договору, на выполнение отдельных работ, чем реализовывать те же работы силами собственного штата. Между прочим, порой такие фрилансеры мигрируют в штат — и тогда получается удаленный сотрудник. (Честно скажу: не представляю себе, как они трудятся. Дом, который работа и дом. Одновременно. Но, к счастью, все люди разные — и в подобном режиме кто-то чувствует себя вполне комфортно.)

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

Как выстроить работу с удаленным сотрудником

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

Самое важное при работе с удаленными сотрудниками — определение правил взаимодействия и четкое следование им. Второе по степени значимости — тщательное планирование. Почему? Да потому что в отличие от сотрудников, находящихся «рядом» (можно подойти — поговорить, понять, что и в каком состоянии, да и вообще множество вопросов решить, что называется, на личном контакте), с удаленными сотрудниками приходится выстраивать систему чуть ли не ежедневного контроля. Понятное дело, не со всеми и не всегда. Но в 70–80% случаев надо готовиться к тому, что планирование будет ежедневным или периодическим, например раз в два-три дня, промежуточные результаты должны проверяться достаточно тщательно, а итоговый — с «особым пристратием», тем более если речь идет о фрилансере. (После завершения проекта контракт с исполнителем закрывается — и предъявить претензии, например, к качеству результата может оказаться довольно сложно.) Правда, в такой организации есть и свои плюсы: при частом контроле вероятность неудовлетворительного для вас итога снижается. Кстати, на заметку: в контракте с фрилансером или удаленным сотрудником следует указать условия выплат и приемки, напрямую связанные с качеством и сроками... А из этого вытекает еще один немаловажный пункт: рабочее задание должно быть максимально подробным, во всех положениях нужно исключать возможность двоякого толкования и четко устанавливать сроки исполнения.

Таким образом, сотрудничество с фрилансером поначалу достаточно специфично и требует от работодателя определенных ресурсов. Да и сам исполнитель должен быть заинтересован в подробном задании: для него это страховка, перекрывающая возможности работодателя «навесить» на него дополнительный объем. Хотя признаюсь: такое случается. Нечасто и не ситематично, но бывает — просто потому, что все предусмотреть невозможно. Для этой ситуации хорошо иметь предварительно оговоренный алгоритм действий. Однако чаще небольшие доработки делаются «за так», а крупные — проводятся отдельными договорами.

Еще момент — все эти рассуждения про «сверхобъем» применимы к внештатным специалистам-контрактникам. Если удаленный сотрудник находится в штате, то понятие «сверхобъем» к нему относится так же, как и к любому другому члену коллектива, работающему над проектом. (То есть для штатного специалиста нагрузку и весь спектр задач координирует руководитель; фрилансер же самостоятельно распределяет задание в рамках установленного периода. Кстати, такая «самобалансировка» почти всегда несет в себе риски срыва сроков или неполного выполнения обязательств: к сожалению, зачастую фрилансеры склонны работать в авральном режиме.)

Как принимать работу у удаленного сотрудника

За годы деятельности в ИТ я вывел для себя одно простое правило: сдача и прием работы — процесс, который следует готовить с самого начала. Нет, можно, конечно, подойти формально, и сделать по принципу «понял, что написано», но возникает риск натолкнуться на альтернативное трактование задания исполнителем. Это правило вообще универсальное: оно верно практически для любой ситуации, когда требуется организовать сдачу-приемку работ. Если же говорить о приемке работ у удаленного сотрудника, то обычно все аспекты определяют в контракте, в частности, указываются положения о порядке приемки и сдачи выполненного задания. Если совсем «по-правильному», то там должно быть описано, кто, как и в какие сроки передает результат работ; кто и в какие сроки рассматривает результат; кто выдает и передает замечания; как устраняются данные замечания. В «неидеале» — все те же самые процедуры придумываются «на лету», что могут грозить определенными финансовыми потерями каждой из договаривающихся сторон.

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

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

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

Особенности работы с удаленным коллективом

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

Впрочем, «на входе» понять, как работает команда «внутри себя», — достаточно сложно. Но, по косвенным признакам, вполне реально. Для начала имеет смысл поинтересоваться, что будет представлять собой результат работ и как планируется его обеспечить, что станет гарантией сроков и каковы пути решения поставленной задачи. Хорошо, если кроме непосредственно результата, например кодов приложения, в состав поставки будет включена документация. Не менее хорошо, если представлен предварительный план с указанием средств его обеспечения (скажем, ресурсов) и возможных рисков. Или выполнена аналитическая проработка поставленной задачи и предложено несколько альтернативных решений.

Разумеется, эти рекомендации далеко не исчерпывающие, но для организации «первичного фильтра» при выборе удаленного исполнителя вполне пригодны, да и как стартовые вводные при создании собственного подразделения тоже. Индикативным может быть ответ на вопрос об ответственности исполнителя за сроки и качество, а также его возможные метрики. Подобной теме следует уделить часа два и по итогам проведенной беседы составить мнение относительно команды. Также можно попросить предъявить портфолио или дать рефернес-контакты (если коллектив на подряде, для собственного подразделения это не имеет смысла). В случае с «одиночкой», кстати, метод «портфолио и референс» тоже работает — в отличие от всего остального.

И еще одна немаловажная особенность, которую нужно подчеркнуть. Обычно удаленный коллектив — это либо собственное подразделение, либо отдельное юридическое лицо. Соответственно, и работа с ним выстраивается иначе, чем с фрилансером или удаленным сотрудником.

Как принимать работу у удаленного коллектива

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

Отчетность и контроль

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