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

В первую очередь необходимо определиться с терминами. Если мы говорим о физическом расположении сотрудников и степени их вовлеченности в проект, возникают две основные дихотомии: «Договор-Штат» и «Офис-Удаленная работа».

remote-dichotomy

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

 

Remote

Мы проанализировали известную книгу Remote об опыте компании 37signals (сейчас Basecamp). А кроме того, предупреждая закономерный вопрос,  мы в курсе как разрабатывался Linux и другие большие и известные open-source системы. Кстати, наши сотрудники участвуют в нескольких таких проектах.  Нам также известно, что капитализация компании Automattic, разработавшей платформу WordPress, на которой ведется и данный блог, превышает 1 млрд долларов. Что касается опыта 37signals, то книга производит неоднозначное впечатление. На наш взгляд это прежде всего инструмент само-пиара. Если же говорить по сути, то философия удаленной работы в 37signals  скорее заточена на удовлетворенность персонала, чем на прямой экономический эффект (например, подчеркивается, что речь не идет об экономии на зарплатах), хотя разумеется это – связанные вещи. Что касается организации процесса тотальной удаленной разработки в компании, то да, он возможен титаническими целенаправленными усилиями менеджмента компании, ее HR отдела, и других служб. Это может себе позволить только большая организация. Для небольшой компании накладные расходы на организацию четкого процесса удаленной разработки включая тренинги, тим-билдинги, регулярные «слеты», поддержание корпоративной культуры на наш взгляд съедят ту экономию, которая будет (?) достигнута.

Что касается open-source проектов, то там практикуется совершенно другое отношение к планам и срокам, по сравнению с коммерческими проектами. Но это – предмет отдельного разговора.

 

ИТ — Бизнес: От простого к сложному

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

1. Схема первая: монолитный офис. Это классическая схема, при которой штатные разработчики работают в офисе компании full-time. Пример: брокерная фирма и ее штатные  разработчики, обеспечивающие внутренние нужды компании. IT-отдел часто находится на том же этаже, что и трейдеры или сэйлз. Соответственно, коммуникация между отделами происходит на всех уровнях, в т.ч. персональном, за кружкой пива в ближайшем баре.

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

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

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

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

Принципиальный момент состоит в том, что работа технологических команд (разработка, тестирование, техническая поддержка) поддерживается на уровне организационной структуры. У каждого разработчика есть руководитель, к которому можно обратиться со своими проблемами, есть поддерживаемая технологическая культура и дисциплина разработки. Есть набор используемых методологий, есть архитектурный процесс. Есть постоянное освоение новых технологий, тренинги, обмен технологическими знаниями: как управляемый, так и – что более важно – спонтанный.

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

Вот перечень основных причин для привлечения внешних специалистов, в том числе фрилансеров:

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

 

Компактность команды

Мы сейчас начинаем говорить не просто о фрилансерах всех мастей, а конкретно о фрилансерах-разработчиках. Взаимодействие с ними может быть организовано несколькими способами. Разработчиками на фрилансе может управлять PM из бизнесового отдела, они могут дополнять штатных айтишников и управляться из ИТ отдела, в некоторых случаях даже менеджеры проекта могут работать удаленно на условиях фриланса, трудно представить, но бывает и такое!

%d1%83%d0%b4%d0%b0%d0%bb%d0%b5%d0%bd%d0%bd%d0%b0%d1%8f_%d1%80%d0%b0%d0%b7%d1%80%d0%b0%d0%b1%d0%be%d0%ba%d0%b0-p5

Ни одна из этих схем по нашему опыту не работает. Главная проблема состоит в том, что коллектив или — в армейской терминологии — боевая единица, работающая над одним проектом – рассеяна, а не сосредоточена компактно. Это отрицательно сказывается на всём: качестве продукта, мотивации разработчиков, конечной эффективности работы.  Тут важно, что речь идет именно о работе над одним проектом и именно о работе нескольких специалистов одного профиля над одним проектом, особенно — сложным проектом. Когда команда разнородная (один разработчик — один дизайнер — один аналитик — один тестировщик), пожалуйста, работайте распределенно без особого ущерба для эффективности.

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

 

Мотивация

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

Что же касается основного ядра наших сотрудников, то многие работают вместе уже 10-12 лет. И в значительной степени это связано именно с тем, что люди мотивированы работать в команде, причем именно в этой команде, каждый день встречаться с умными коллегами и совместно решать сложные задачи. А также подтрунивать друг над другом, спорить до хрипоты, вместе жарить шашлыки, а иногда и «снимать стресс» самым популярным народным способом.

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

Кстати, откуда вообще берутся программисты?

Говорят, что раньше их находили в перфокартах и залежах распечаток. А сейчас, в безбумажную эпоху?

ВУЗ? Нет. Понятно, что образование — это хорошо, особенно — хорошее образование. Но в университетах, по крайней мере в наших — не учат профессии программиста, в лучшем случае — учат языку Си или С++. Хотя там часто дают большее — навыки думать и решать сложные задачи, особенно если речь идет о математических факультетах.

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

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

 

Размер важен

Речь в данном случае идет о размере проекта. Существуют два основных критерия, по которым мы определяем, подходит ли та или иная схема работы для проекта:

  1. Сложность проекта
  2. Значимость проекта для бизнеса (сроки, риски, ответственность и т.д.)

project-complexity

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

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

Другая ситуация. Пусть это — даже огромный проект, но если  нет жестких сроков, бюджета, то разработка может вестись на энтузиазме разбросанных по миру open-source разработчиков. Заметим – это никакие не фрилансеры. Это, во-первых, и прежде всего – энтузиасты, т.е. люди обладающие высочайшим уровнем мотивации, причем нематериальной, в отличии от  фрилансеров. Во-вторых, это — высококлассные специалисты, многие из которых работают в штате крупных коммерческих компаний, а свое свободное время посвящают open-source.  Соответственно популярный аргумент, что «Линукс был написан фрилансерами» не совсем соответствует действительности.

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

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

 

Как же все-таки сэкономить?

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

 

remote_devel-4

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

 

HipChat вам в помощь?

Часто приходится слышать, что при наличии современных средств коммуникации, таких как видеоконференции, чаты, корпоративные базы знаний (wiki), баг-трекеры и т.п. уже нет особой разницы находятся ли сотрудники в одном помещении или в разных уголках Земли. Надо признать, что в настоящее время невозможно представить себе работу над проектом, локальную или распределенную, которая бы не использовала все эти инструменты. Собственно, сейчас все жители мегаполисов – друзья, родственники, знакомые —  постоянно находятся «на связи» в чатах, мессенджерах, социальных сетях, безотносительно к служебным отношениям. Может ли это заменить общение лицом-к-лицу? Работая под одной крышей люди общаются гораздо теснее и менее формально. Обмен информацией идет широким потоком. Часто возникают спонтанные обсуждения, или даже яростные технические споры при выходе на ланч, праздновании дня рождения или выходе в ближайший паб в пятницу вечером.  Просто находясь рядом люди мотивируют друг друга на плодотворную работу.

 

В сухом остатке…

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

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

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

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

remote_devel-8

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

  • Sharing

    Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather