Открыть список
Как стать автором
Обновить

Удаленная работа: тим-лиду и программистам

GTD
Достоинства удаленной работы очевидны — меньше ограничений в поиске специалистов с нужной квалификацией, возможность нанимать людей за пределами МКАД, меньше расходов на ведение бизнеса. С другой стороны, есть и проблемы: наиболее значительные — со стороны организации работы. Последние 4 года я работаю тим лидом распределенной группы программистов (3-15 человек в разное время) для зарубежного заказчика, и хочу поделиться с хабрадевелоперами опытом такой работы :-)

Здесь и далее имеется ввиду следующая организация труда:
  1. Заказчик (+on-site команда опционально) в офисе где-нибуть в Европе/США.
  2. Тим лид распределенной команды — где-то на бескрайних просторах exUSSR.
  3. Члены распределенной команды — также где-то на бескрайних просторах exUSSR.
Подразумевается, что при желании заказчик может общаться со всеми членами команды. Оплата работы — почасовая.


Программистам


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

Вам следует обратить внимание на следующее:
  1. Ваш тим лид должен быть адекватным :-) Это самое главное: если это не так, то как бы не были хороши разработчики, ничего у вас не получиться :-) Должен уйти либо он либо вы. Не стоит ждать логической развязки — краха проекта и рвущего все заказчика, напишите о проблемах как можно раньше (нервы жалеть надо).
  2. И тим лид и заказчик всегда дожен иметь адекватное представление о том, какие есть проблемы на проекте, поэтому вы должны всегда их держать в курсе: над чем конкретно работаете, какие есть проблемы. Если вы видите что вероятно не сможите уложиться в срок — об этом надо писать как можно раньше вашему Тимлиду. Если тимлид никак не отреагирует на ситуацию, это будет уже его проблема, а не ваша.
  3. Если вы работаете удаленно — это не значит что можно работать 1-2 часа в день :-) Это очень быстро заметят :-) Безусловно, если вы знаете что действительно работаете на 40% быстрее среднего программиста с вашей зарплатой (т.е. вы недооценены), вы конечно можете делать дневную работу за 5 часов, и 3 отдыхать (но не наоборот — 3 отдыхать, а потом судорожно работать :-) ). Безусловно, для вашего будущего будет лучше если вы будете сдавать задачи раньше срока :-)
  4. Не стоит никого обманывать ни при каких условиях, и не стоит скрываться если что-то идет не так. Плохая правда всегда лучше неизвестности. Этот пункт пожалуй самый главный. Нужно находить в себе силы говорить плохие новости, и делать это нужно как можно раньше, чтобы оставалось больше времени на реакцию.

Тим лидеру


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

Следующие элементы помогут сделать работу более эффективной:
  1. Все члены команды должны высылать ежедневный отчет о потраченном времени по часам, не менее двух задач в день. Следует установить крайнее время отправки отчета (например 2 ночи мск). За опаздание с отчетом — выговор, если часто повторяется — придется искать замену.
  2. Кнуты и пряники: выговор, лишение премии, увольнение — придется прибегать гораздо чаще чем в офисе, т.к. многие программисты не могут эффективно работать удаленно, с этим ничего другого сделать нельзя. На этапе собеседования это так же не выяснить. Будет неплохо договорится о ежемесячном премиальном бюджете для премирования наиболее старательных сотрудников. Вы лично также должны иметь хорошую мотивацию, но за этим придется следить лично вам.
  3. Все члены команды должны иметь должные средства коммуникации: Skype+микрофон, софт для шаринга экрана (например YuuGuu), доступ к багтрекеру(например trac или bugzilla — без этого задачи быстро забываются если их больше 5-10),wiki для важной информации и внутренней документации. У всех почта должна проверятся с интервалом 1 минута (впрочем, если вы сторонник невмешательства в работу, можно всю срочную коммуникацию перенести в IM, и установить интервал проверки 30-60 минут).
  4. Во всех письмах время должно указываться в одном часовом поясе. Это может быть например мск, или локальное время заказчика. (Локальное время заказчика удобно смотреть в Skype — в информации о контакте)
  5. Члены команды должны хорошо знать svn, обновлять локальную копию как минимум каждое утро и по возможности комитить изменения к концу дня. Вы должны просматривать то что они закомитили, и спрашивать прямо если нужно: «Ты действительно потратил 8 часов на эти вот 10 строчек?» (конечно есть строчки на которые действительно можно потратить 8 часов). Программисты должны знать, что несмотря на то, что у них за спиной физически никто не стоит, результаты их работы учитываются постоянно.
  6. Необходима политика по тестовым и продакшн серверам: это может быть как 1 тестовый сервер с автообновлением из svn, так и по тестовому серверу на каждого программиста. Продакшн сервер должен обновлять только один человек (например вы).
  7. Желательно иметь почтовые аккаунты всех людей на одном сервере. Это исключает проблемы с фильтрацией спамфильтром, скоростью доставки писем и максимальным размером аттачментов. Хорошо если есть место куда можно заливать большие файлы, которые в почту уже не лезут по хорошему (50Мб и более)
  8. Как и в случае с программистами, вы не должны утаивать плохую инфрмацию и скрываться от заказчика если все совсем плохо. Всегда лучше сказать плохие новости как можно раньше, и выработать реакцию. Если кто-то из программистов сообщает вам что не укладывается в срок — вы обязаны прореагировать: либо сами помочь, или кто-то из команды поможет, или овертайм, или сообщить заказчику о сдвиге сроков. Думаю, даже если вы не сможете сдать проект, но будете всегда «в контакте» с заказчиком (без завтраков и несбыточных обещаний), то не до конца испортите его мнение о русских разработчиках :-)

Заключение


Надеюсь эта информация поможет кому-то успешно завершить проект с распределенной командой, и вырвать кусок рынка у злобных индусов :-)
Теги:удаленная работаdistributed teamменеджментменеджмент проектовпроблемыкритические ситуациизаказчикoutsourcing
Хабы: GTD
Всего голосов 80: ↑74 и ↓6 +68
Просмотры14.2K

Похожие публикации

Лучшие публикации за сутки