Аутсорс-разработка сама по себе продукт, который сложно продавать. Взаимодействие с клиентами, включение в чужие бизнес-процессы требует определенных бизнесовых и технических навыков. Но куда важнее правильно построить процессы внутри и собрать такую команду, которая сможет вылезти из любого кризиса.
Расскажу, на какие грабли как руководитель я попадал, и что нужно делать, чтобы избежать подобного.
Кто должен быть в команде на старте работы
— Предыстория
— Структура команды на старте бизнеса
Процессы, которые нужно контролировать
— Финансы
— Сотрудники
— Коммуникация и управление
Выводы
Кто должен быть в команде на старте работы
Предыстория
С 2013 по 2016 год дела в компании шли отлично — у нас был ежегодный прирост в прибыли 50%. Финансы я контролировал в таблице, руками вбивая все доходы, расходы и так далее.
В 2016 году стало много разных проектов, нужно было систематизировать работу с финансами. Но я, наоборот, перестал следить сам и начал искать человека, который будет контролировать финансы за меня, но не довел до конца. (В конечном итоге я не только систематизировал финансовую сферу, но автоматизировал множество процессов.)
При этом разработчиков становилось все больше и больше, дошло до 20 человек, а контролировал их работу только один. Совершенно естественно, что постепенно он перестал эффективно отслеживать результаты работы ведущих разработчиков на проектах. Как оказалось, их кандидатуры были выбраны неверно. Мы стали терять в продуктивности и зафакапили несколько проектов по сдаче.
Когда я стал выяснять, что происходит, оказалось, что часть сотрудников откровенно не работала столько, сколько нужно, а зарплату получала. И из-за этого тогда было ощущение, что в компании мало денег, хотя их было много. На самом деле мы просто кормили дармоедов.
Если вы делаете сложные проекты, то должен быть человек, который сможет проверить знания сотрудников и не позволит делать неделями то, на что должны уходить дни.
Я пришел к выводу, что в команде должно быть два человека, которые смогут контролировать процесс.
Один отвечает за коммуникацию с клиентом и разруливает сложные вопросы внутри команды. Другой — контролирует работу этой команды. Коммуникация и понимание между двумя этими главными людьми позволяет решить любой вопрос: даже если все программисты отвалились (такого у нас не было, но подхватывать приходилось), то этот человек может доделать, а второй договорится с клиентом так, чтобы в день ИКС сдать необходимый минимум, чтобы не подвести клиента.
Причем главное условие — в команде не должно быть больше 15 человек разработчиков (лучше — 10). Иначе придется искать еще одного тимлида. Либо терять в деньгах и отношениях с клиентами при неэффективной работе кучи людей и иллюзии контроля.
Есть понятие «плеча», которое применяется в проектном бизнесе услуг: оптимально контролировать можно 5-7 человек.
Структура команды на старте бизнеса
Когда вы только начинаете бизнес, сосредоточьтесь на минимуме людей в команде, но максимальной их результативности. В идеале команда должна состоять из пары нужных вам разработчиков и тимлида. Если нет возможности нанять тимлида, разработчики на одинаковых языках смогут проверять друг друга — так будет лучше выглядеть и работать код, а сотрудники, взаимодействуя, улучшат свои навыки.
Аутсорс-разработка как бизнес выгодна и эффективна, когда работу делают разработчики, которые находятся на этапе между средним и очень опытным. На этом уровне разработчик быстро впитывает знания, понимает, что происходит, ему легко объяснять, как исправить, не требуется много контроля. При этом он еще дешевый, но уже опытный. Выгода для него — быстро набраться еще больше полезного опыта, для бизнеса — не тратить много денег на зарплату.
Процессы, которые нужно контролировать
Финансы
Главная ошибка, которую я допустил в кризис 2016 года — перестал следить за финансами компании. С одной стороны, я по памяти знал, кому нужно заплатить и когда, сколько денег компания получит, но с другой — информация не фиксировалась, я не сводил финансовые отчеты, не видел реальную картину. В итоге мы ушли в минус, из которого болезненно выбирались.
Я допустил одну ошибку, которую нельзя допускать — считал, что если каждый месяц у компании операционный плюс, то все нормально. Но это не так.
В один прекрасный момент заказчик может не заплатить или случится какой-нибудь форс-мажор, и от плюса не останется и следа.
Еще одну ошибку часто совершают новички в проектном бизнесе — берут и тратят предоплату. Я, к счастью, так не делал. Когда вы берете предоплату за работу, эти деньги еще не ваши. Вы взяли на себя обязательство что-то сделать, поэтому предоплата от заказчика фактически должна быть «заморожена», пока вы не сделаете работу. Если что-то идет не так — предоплата возвращается. На практике аутсорсеры часто делают предыдущий проект на предоплату со следующего. Такой бизнес нестабилен и может легко разрушиться, если команда не выдержит сроки или сделает ошибку.
Сотрудники
Контроль работы сотрудников и соблюдение субординации не менее важны при работе над проектами.
У молодых компаний аутсорс-разработки может быть желание делать индивидуально под каждый проект — от начала и до конца. Мы на это тоже попались, поэтому говорю — не надо так. Лучше иметь базу маленьких готовых наборов действий, которые ускоряют работу над проектом и не обесценивают опыт, полученный на других проектах. Я бы сравнил это с тем, что мы делали макбук, каждый раз собирая все детали с нуля самостоятельно, вместо того, чтобы использовать чертежи предыдущего.
И здесь важно контролировать работу программистов. Когда они говорят, что баг, который появляется из проекта в проект, нужно исправлять, а стандартизировать процесс, предотвращающий его заранее, не надо — не слушайте их. Разработчики живут в своем мире, им далеки финансовые расчеты, бизнес-процессы и общение с клиентами. Им важно писать код — за это вы их нанимаете. Если можете ускорить или улучшить работу — говорите и контролируйте, чтобы это было исполнено.
Когда вы переносите часть ответственности на сотрудника, глупо полагать, что он вообще понимает, что такое риск и ответственность.
Здесь должен работать принцип «Моя компания — мои решения». Но в адекватных пределах, конечно. Быть самодуром, который дает советы писать на Джанго или на Фласке, не надо.
Коммуникация и управление
Однако контролируя сотрудников, не стоит вникать в их ежедневные задачи — иначе погрязнете не в тех делах.
Но если вы заметили, что программист теряет продуктивность регулярно или делает ошибки в работе — решать эти проблемы вам. Если нужно — звонить и спрашивать, почему так вышло, что выработка не соответствует норме? Что случилось? Болеет любимая кошка или что?
Если вы наблюдаете, что у программиста число задач, которые возвращаются ему с тестирования или с code review не падает — это плохо, нужно понять, почему так происходит. Если число падает, значит, сотрудник развивается и все хорошо. Кроме этого, важны сроки сдачи задач, нормы выработки, сколько времени он залогировал в CRM (или любом другом менеджере задач) и прочее.
Отношения в команде должны быть построены на двух очень простых принципах: вежливость и уважение. Тот, кто находится на другой стороне экрана, — человек, и он, как и все мы, ошибается.
Ни в коем случае не должно быть оценок работы, кроме как позитивных, только просьбы исправить и только по факту. Даже если ваш сотрудник уронил базу на продакшн сервере — нельзя наказывать его. Это ваши процессы позволили этому случиться.
Вопрос — ответ. Не понял — задай вопрос еще раз. И с другой стороны: вопрос — это вопрос, но не больше. Ничего не надо додумывать за автора вопроса. Поэтому вопрос надо строить без ответа в нем.
Например:
— Вы делаете ошибки по утрам или вечерам? — неправильно.
— Сколько ошибок вы делаете утром, а сколько вечером? — правильно.
Да, вопрос неудобный, но этого не избежать, если ошибка допущена.
Первый вопрос ставит человека в тупик и обвиняет. А второй — открытый, на него можно дать ответ «я не делаю ошибок». Или «утром я сорвался и сделал парочку, извините». И дальше идет выяснение, как так вышло, и найти решение, чтобы ошибки больше не возникало.
В любой ситуации общайтесь с сотрудниками вежливо и по делу — это поможет определить, готов ли человек решать проблемы и принимать свои ошибки. Те, кто косячат — не выносят вежливых вопросов и уважительного отношения.
Выводы
Как делать аутсорс-разработку, чтобы не оказаться в кризисе:
- Не набирайте в команду сильно больше 10 разработчиков. Больше разработчиков — меньше контроля.
- Найдите человека, который будет вести ваши финансы. Если пока нет такой возможности — автоматизируйте ведение отчетов так, чтобы это было удобно и нельзя было прекратить.
- Перестанете следить за финансами — провалитесь.
- Перестанете следить за людьми — провалитесь.
- Операционный плюс на счету — еще не показатель отсутствия проблем.
- Не тратьте предоплату. Она не ваша.
- Если есть проблемы с проектами — общайтесь с программистами вежливо.
- Если есть вопросы — отвечайте и не позволяйте трактовать ваши вопросы как декларации, не лишайте себя права на вопрос — требуйте ответ. Неготовность сотрудника давать ответ — увольняйте.
- Уважайте ваших людей, но не забывайте, что ответственность вся на вас.
- Ваша компания — ваши правила.
Если хотите обсудить ваш проект, напишите нам. За 10 лет мы запустили 40 сложных программных продуктов для частных инвесторов, крупных бизнесов и государственных организаций. Поможем и вам 🙂
