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

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

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

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

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

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

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

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

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

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

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

Этап 1:

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

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

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

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

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

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

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

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

Вариант 1:

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

Вариант 2:

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

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

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

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

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

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

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

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

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

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

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