Главное Свежее Вакансии   Проекты
Комментируемое:
80 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Агентство аутсорс-разработки: какая должна быть команда, чтобы дела шли хорошо

Аутсорс-разработка как бизнес требует определённых технических и управленческих навыков. Но куда важнее правильно построить процессы в компании и собрать такую команду, которая сможет вылезти из любого кризиса. Рассказал, на какие грабли я попадал и какие выводы сделал.

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


Предыстория


С 2013 по 2016 год дела в компании шли отлично — у нас был ежегодный прирост прибыли в 50%. Финансы я контролировал в таблице, руками вбивая все доходы, расходы и так далее.

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

При этом разработчиков становилось всё больше и больше, дошло до 20 человек, а контролировал их работу только один. Совершенно естественно, что постепенно он перестал эффективно отслеживать результаты работы ведущих разработчиков на проектах. Как оказалось, их кандидатуры были выбраны неверно. Мы стали терять в продуктивности и зафакапили несколько проектов по сдаче.

Когда я стал выяснять, что происходит, оказалось, что часть сотрудников откровенно не работала столько, сколько нужно, а зарплату получала. И из-за этого тогда было ощущение, что в компании мало денег, хотя их было много. На самом деле мы просто кормили дармоедов.

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

Я пришёл к выводу, что в команде должно быть два человека, которые смогут контролировать процесс.

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

Причём главное условие — в команде не должно быть больше 15 человек разработчиков (лучше — 10). Иначе придётся искать ещё одного тимлида. Либо терять в деньгах и отношениях с клиентами при неэффективной работе кучи людей и иллюзии контроля.

Есть понятие «плеча», которое применяется в проектном бизнесе услуг: оптимально контролировать можно 5-7 человек.

Структура команды на старте бизнеса


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

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

Процессы, которые нужно контролировать


Финансы


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

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

В один прекрасный момент заказчик может не заплатить или случится какой-нибудь форс-мажор, и от плюса не останется и следа.

Ещё одну ошибку часто совершают новички в проектном бизнесе — берут и тратят предоплату. Я, к счастью, так не делал. Когда вы берёте предоплату за работу, эти деньги ещё не ваши. Вы взяли на себя обязательство что-то сделать, поэтому предоплата от заказчика фактически должна быть «заморожена», пока вы не сделаете работу. Если что-то идёт не так — предоплата возвращается. На практике аутсорсеры часто делают предыдущий проект на предоплату со следующего. Такой бизнес нестабилен и может легко разрушиться, если команда не выдержит сроки или сделает ошибку.

Сотрудники


Контроль работы сотрудников и соблюдение субординации не менее важны при работе над проектами.

У молодых компаний аутсорс-разработки может быть желание делать индивидуально под каждый проект — от начала и до конца. Мы на это тоже попались, поэтому говорю — не надо так. Лучше иметь базу маленьких готовых наборов действий, которые ускоряют работу над проектом и не обесценивают опыт, полученный на других проектах.

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

Когда вы переносите часть ответственности на сотрудника, глупо полагать, что он вообще понимает, что такое риск и ответственность.

Здесь должен работать принцип «Моя компания — мои решения». Но в адекватных пределах, конечно. Быть самодуром, который даёт советы писать на Джанго или на Фласке, не надо.

Коммуникация и управление


Контролируя сотрудников, не стоит вникать в их ежедневные задачи — иначе погрязнете не в тех делах.

Но если вы заметили, что программист теряет продуктивность регулярно или делает ошибки в работе — решать эти проблемы вам. Если нужно — звонить и спрашивать, почему так вышло, что выработка не соответствует норме? Что случилось? Болеет любимая кошка или что?

Если вы наблюдаете, что у программиста число задач, которые возвращаются ему с тестирования или с code review не падает — это плохо, нужно понять, почему так происходит. Если число падает, значит, сотрудник развивается и всё хорошо. Кроме этого, важны сроки сдачи задач, нормы выработки, сколько времени он залогинил в Jira и прочее.

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

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

Вопрос — ответ. Не понял — задай вопрос ещё раз. И с другой стороны: вопрос — это вопрос, но не больше. Ничего не надо додумывать за автора вопроса. Поэтому вопрос надо строить без ответа в нём.

Например:
— Вы делаете ошибки по утрам или вечерам? — неправильно.
— Сколько ошибок вы делаете утром, а сколько вечером? — правильно.
Да, вопрос неудобный, но этого не избежать, если ошибка допущена.

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

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

Выводы


Как делать аутсорс-разработку, чтобы не оказаться в кризисе:

  1. Не набирайте в команду сильно больше 10 разработчиков. Больше разработчиков — меньше контроля.
  2. Найдите человека, который будет вести ваши финансы. Если пока нет такой возможности — автоматизируйте ведение отчётов так, чтобы это было удобно и нельзя было прекратить.
  3. Перестанете следить за финансами — провалитесь.
  4. Перестанете следить за людьми — провалитесь.
  5. Операционный плюс на счету — ещё не показатель отсутствия проблем.
  6. Не тратьте предоплату. Она не ваша.
  7. Если есть проблемы с проектами — общайтесь с программистами вежливо.
  8. Если есть вопросы — отвечайте и не позволяйте трактовать ваши вопросы как декларации, не лишайте себя права на вопрос — требуйте ответ. Неготовность сотрудника давать ответ — увольняйте.
  9. Уважайте ваших людей, но не забывайте, что ответственность вся на вас.
  10. Ваша компания — ваши правила.

P.S. Чтобы убедиться, что вы всё делаете правильно, напишите нам. За 10 лет мы запустили 40 сложных программных продуктов для частных инвесторов, крупных бизнесов и государственных организаций. Поможем и вам: WB—Tech Consulting.

+1
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Первые Новые Популярные
Комментариев еще не оставлено
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.