Разработка на аустсорс: взгляд изнутри ч.1

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

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

Во второй части статьи мы уже подробно расскажем о нюансах внутренней кухни и непосредственно о вопросах производства.

Почему в целом используется модель человеко-часов?

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

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

Этапы работы над проектом.

Проект поступил на оценку:

Изначально проект поступает на оценку менеджеру. Почему именно менеджеру? Для чего вообще нужен менеджер?

Менеджер разговаривает на понятном языке с заказчиком и оперирует понятиями, доступными как заказчику, так и программистам.

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

Итого: менеджер упрощает и ускоряет работу программиста, четко ставя ему задачу и обеспечивая максимальную скорость, а также повышая КПД связи с заказчиком для получения оптимального результата, соблюдая баланс «скорость/качество».

Как происходит процесс оценки?

Этап 1:

Проект пришел на оценку, менеджер анализирует полученные исходные данные:

1) Достаточно ли начальных данных для оценки?

2) Какой вариант оценки хочет получить клиент?

а) Предварительный, в рамках которого клиент может получить вилку.

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

3) Есть ли запрос на специалистов конкретного уровня?

Специалист June/Middle и Senior реализуют поставленную задачу за разное время. Если клиент четко хочет специалиста определенного уровня, тогда будет учитываться, в какие сроки он хочет получить оценку и когда можно будет начать проект. В этом случае менеджер изначально смотрит календарь загрузки и принимает решение в принципе о возможности дать оценку.

Взаимодействие менеджера и программиста.

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

Вариант 1:

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

Вариант 2:

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

Итого:

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

В результате такой подход позволяет показать уровень экспертизы, которую может получить заказчик. В итоге, как правило, клиенты (студии) приходят к тому, что формировать ТЗ совместно с нами – это лучший вариант.

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

А-ля: согласовать критерии принятия задачи. Делаем, тестируем, правим, тестируем и сдаем.

Лирическое отступление:

Ага, джуны… Впихиваете криворуких джунов с тремя классами "образования"… В нашей компании аутсорс-продакшен построен на основе модели работы со студиями, от которых идет постоянный поток неких типовых задач, которые у нас стандартизированы и приведены к определенным шаблонным кодам.

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

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

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

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

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

99
12 комментариев

Ждём часть "два"

2
Ответить

Будет. В процессе :)

Ответить

Спасибо, жду вторую часть. 

1
Ответить

Будет. В процессе :)

Ответить

Иван, поддержу статью вопросами )

1. Вы только со студиями работаете? Напрямую с заказчиками - нет?

Потому что у заказчиков (не имеющих опыта) самый популярный вопрос начального уровня это "как это так, оценивать по часам..вдруг вы можете сделать за 50 часов, но специально будете делать 100?"

2. Упомянутые в статье менеджеры - это ПМ, аккаунты, сейлзы, или всё-в-одном?

Ответить

Заказчик без своего ПМ при оплате по часам может быстро расстроится.
Кто эти менеджеры мне тоже интересно. В аутсорсе по идее они и не нужны, там продажники. Нашли заказчика, продали ему человека или команду.
А тут вроде и почасовая оплата и оценки делают и менеджер клиенту решения презенует, как в разработке на заказ ..

Ответить

Андрей, спасибо за вопросы.

1. Мы работаем как со студиями, так и с прямыми заказчиками, в большинстве своем которым нужна именно сложная разработка и высокий уровень технической экспертизы, а дизайн у них есть либо не требуется (например, разного рода админки/CRM-ки).

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

2. Конкретно в статье по большей части речь шла про ПМ-ов, а если брать в целом, то общаются все: сейлы, и пмы, и аккаунты.

Ответить