Работа программистом удалённо: как я перевёл свою команду на дом

Денис Гордиенко, генеральный директор Bright Mobile, об опыте закрытия офиса и перевода компании в формат удалённой работы.

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

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

Год назад у меня было два менеджера проектов, которые работали с клиентами. Проходило всё по классике: сначала мы договаривались о проекте, я передавал его менеджеру, а он вёл его, общаясь с программистом, клиентом и т.д. как в большинстве студий.

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

Мои функции сводятся к:

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

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

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

Самые большие изменения произошли именно в команде: раньше основной костяк сидел в офисе на 60 м2, также было несколько фрилансеров, которых мы время от времени привлекали при пиковой загрузке.

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

Было выгодно сузить производство, сохранив только тех людей, которые гарантированно могут довести проект до конца. Вместо уволенных мы начали набирать новую команду в начале лета – причём, не только из нашего города.

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

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

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

Микроотвлечения, которые всегда раздражали, исчезли. К слову, с большинством из 80% мы попрощались по следующим причинам:

Ранее это всё скрывалось в офисе — команда сидит, работает, что-то производит. Сейчас стал каждый человек, как на ладони.

Надо сказать, что это довольно сильно увеличило производительность оставшихся программистов примерно на 20-30% – только из-за того, что они не отвлекаются на задачи, общение и офисные шуточки. Идеальная работа для социофобов: те, кто приходит к нам в команду дружить и тусить, долго у нас не засиживаются. Работа идёт, как на конвейере: задача ставится, выполняется, сдаётся – и затем берётся следующая.

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

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

По факту, если вам нужно набрать 5 человек, следует рассматривать 50 целевых откликов (спам и тех кто не читает задание я не считаю). Половина отсеется по всяким организационным причинам, ещё 25% не справится с тестовым заданием, а из тех, кто справился, будут такие, которые не подойдут либо потому, что им постоянно нужно общение или те, у кого часто болеет бабушка. Вот и остаётся лишь 10%, которые вас устроят.

Я бы порекомендовал выбирать тех программистов, которые находятся в каталоге: топовые ребята уже наработали пул клиентов, и вам нужно заинтересовать их своей работой, показать, что у вас постоянная деятельность, и вы – адекватный заказчик, предоставить примеры ТЗ. Если вы его заинтересуете, вы можете остаться их единственным клиентом и будут работать на вас как офисные сотрудники, но с сохранением статуса фрилансера.

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

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

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

Нам удалось выстроить команду из фрилансеров, по факту являющихся и не фрилансерами вовсе, а удалёнными сотрудниками, заинтересованными в постоянной работе со мной. Отмечу, что бывает два типа фрилансеров: одни бегают от одного заказчика к другому, набирают предоплату, а как дело доходит до сдачи проекта, начинают морозиться. Другие – те, которые не любят продажи, объясняться с клиентами: им важно, чтобы им ставили чёткие, конкретные задачи, а они их выполняли. Вам нужны именно те, что не продают свои услуги разным клиентам, а ищут одного постоянного заказчика, с которым могут постоянно работать.

Кроме тех, что работают с нами фул-тайм, есть ещё те программисты, что работают только по вечерам. У них есть основная работа, но по несколько часов в день он работают на меня. Многие из совершенно разных часовых поясов: от Калининграда до Харабовска. Поэтому в экстренных ситуациях, когда нужны активные действия (например, недавно один клиент просто похоронил сервер, забыв оплатить хостинг), работу начинал программист Хабаровска, а когда его рабочий день подходил к концу, передавал её программисту из Калининграда, и проект клиента по факту был в работе 14 часов в сутки, а не 8.

В принципе, взвешивая все за и против и сравнивая текущую ситуацию с тем, что было у нас год назад, я вижу как плюсы, так и минусы. С одной стороны, держать команду стало сложнее – трудно поругать сотрудника, которого даже не видишь. Однако если контролировать процессы грамотно, открываются новые возможности. Самая главная – возможность рассматривать сотрудников по всей России и даже СНГ.

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

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

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

На своём YouTube я рассказываю о том, как развиваю команду и разбираю как запускать первые версии стартапов.