Лайфхаки при аутсорсе. Как не попасть впросак
Прежде всего необходимо понять, какие цели и задачи преследует аутсорс такого рода услуг. Обычно первоочередные задачи это:
- 1.Разгрузить своих сотрудников для более важных задач
- 2.Выполнить работу, на которую не хватает знаний и в то же время нет времени наращивать экспертизу внутри компании.
- 3.Минимизировать расходы, в случае если при внутренней оценке работы она оказалась очень дорогой.
Определите, на какой стадии развития вы находитесь сейчас.
Начальная точка — это когда вы работаете по методологии Code&Fix, крайняя точка — означает высокий уровень зрелости процессов.
Представим, что вы находитесь на стадии развития, когда вы пишете код на коленке и затем его правите. Какой вам нужен подрядчик в данном случае и зачем? Вам нужны прозрачные открытые отношения и будущий партнер. Вам нужен подрядчик, с максимальным уровнем зрелости, который уже знают, как правильно, и вы сможете этому у него научиться.
Лайфхаки для проектов на ранней стадии развития
Лайфхак №1 Как распознать своего подрядчика?
В первую очередь, компании необходимо представить вам подробный workflow. Каждый процесс здесь должен быть абсолютно прозрачен, а из него у вас сложится понимание, как проходит цикл от зарождения идеи до продакшна.
Дальше следует убедиться в эффективной инфраструктуре разработки. Под эффективностью понимается единая система коммуникаций – это и управление проектом, и база знаний, и место для переписок/обсуждений. Все должно обсуждаться в одном месте, чтобы вы в любой момент могли зайти посмотреть какие за кем задачи и получить доступ к объективной реальности. Вам предстоит жить в мире подрядчиков.
Лайфхак №2 Определите свою роль
Подрядчик должен детально описать вашу роль на всех этапах совместной работы, чтобы вы имели представление в какой момент и на сколько активно вы будете вовлечены.
Когда вы начинаете работу, вам уже необходимо понимать свою роль, знать, что вам нужно сделать, на каком этапе что согласовывать, и когда есть необходимость в личной встрече.
Лайфхак №3 Как с таким подрядчиком работать?
Во-первых, участвовать во всех коммуникациях внутри команды разработчика. Это опять же относится к вопросу о прозрачности структуры процессов. Если вы просто получите от подрядчика кусок кода, это вам не даст ничего. Вам нужно с ним работать дальше, поддерживать и дорабатывать.
Во-вторых, вести живую документацию. Этим часто пренебрегают, считая, что документацию можно не писать, мы все обсудим, доделаем, но вы еще слишком незрелы, чтобы отказываться от этого. Вам нужно описывать бизнес-логику, описывать спецификацию API.
В-третьих, все проектные артефакты, знания и наработки должны остаться у вас. На данном этапе вам нужно будет узнать, что использует подрядчик, купить и развернуть у себя, чтобы запустить подрядчика уже в вашу структуру.
В-четвертых, все задачи следует описать и они должны быть связаны с комитами (термин git, означающий применение внесённых изменений в код )— это нужно вашим будущим разработчикам, которые потом придут в команду и будут разбираться с кодом, написанным вашим подрядчиком. Когда разработчик увидит задачу и посмотрит, какие комиты к ней были сделаны, ему будет проще разобраться с чужим кодом. Всегда фиксируйте все в общении с подрядчиками. Ваша цель – собрать информацию и знания.
Лайфхаки для проектов высокого уровня зрелости
Лайфхак №1 . Какого подрядчика искать и зачем он нужен?
Основной страх тут заключается в мысли мы все построили, у нас всё работает, и нужно кого-то пускать в свой процесс. Нужно искать того, кто будет не хуже вас, но будет: а) достаточно гибким б) идеально отыгрывать роль ведомого.
Как видно, область поиска здесь максимально узкая. Характеристики такого подрядчика могут быть следующими:
Работал по time&material и/или поддерживал написанный не им проект. Компания точно должна иметь успешно-признанный клиентами опыт.
У команды есть менеджер/ тим лидер — человек, который все внутренние проблемы подрядчика, всю кухню будет решать самостоятельно.
Оценку проводят осторожно, задавая много вопросов, переписывая ваш бриф как надо. Это значит, что люди сами пытаются вникнуть и понять, как это делать правильно, потому что привыкли работать по такой модели.
Вас познакомят с конкретными разработчиками. Это не обязательно, но хорошо, если все-таки это произойдет, потому что вам с ними работать и быть одной командой. Хорошо находиться на одной волне, чтобы было комфортно, так как вы общаетесь с ними напрямую.
Анализирует, советует, внедряет. То есть вы чувствуете, что подрядчик является частью команды.
Лайфхак №2. Как с таким подрядчиком работать
Во-первых, узнавать статус проекта вы должны без помощи подрядчика, то есть снова единая система коммуникации. Вы должны видеть в общем потоке задачи ваших сотрудников/задачи подрядчика, видеть комиты ваших сотрудников/подрядчика, все должно быть едино.
Во-вторых, избегайте прямых комитов для сильно связанного кода. Это достаточно рискованная затея и справиться с ней без проблем тяжело. Один из способов снизить вероятность проблем - избегание прямых комитов в общую ветку. Используйте pull request, проверяйте сами код и только после этого заливайте его в общую ветку.
В-третьих, общайтесь с подрядчиком в одном таск-менеджере/канале и ставьте там задачи, то есть вы должны полностью интегрироваться в процесс и управлять командой подрядчика как своими сотрудниками.
В-четвертых, возьмите за правило общее владение документами – допустим, спецификацию API для мобильного приложения разрабатывали вы, но подрядчик имеет право на запрос изменений в этой документации. Не должно быть настойчивого желания полностью владеть этим документом и распоряжаться им самостоятельно.
В-пятых, вводите подрядчика в проект, даже если он этого не просит. Давайте ему документацию и каждую новую задачу обсуждайте лично. Да, на первых порах вы потратите большое количество времени, но вы будете уверены, что они все поняли и сделают задачу правильно, а у вас будет меньше поводов волноваться, что они не подходят вам (команда просто адаптируется к проекту).
Лайфхак №3. На что стоит обращать внимание
Общие рекомендации, которые стоит иметь в виду:
Высокая/низкая оценка стоимости по сравнению с другими предложениями. Решить это просто: просите часы. Так вы сможете сравнить: возможно, у одних ставка 5 тысяч рублей за час, а у других 500 рублей за час. Но оценка может различаться просто из-за того, что в нее включено все: одни насчитали на миллион, но у них есть автотесты, автоматическая раскладка кода, группа тестировщиков. И в таком случае цена вполне обоснована.
Подрядчик запрашивает размер бюджета на проект. Это нужно для того, чтобы понять какие решения предлагать. От бюджета зависит много мелочей, в том числе сам функционал и используемые подходы и инструментарий.
От подрядчика часто можно услышать: Мы никогда этого не делали, но не видим проблемы, чтобы это сделать. То, что касается простых библиотек, элементарных технологий — да. Но если речь идет об инфраструктуре разработки — это годы постоянного отстраивания процессов, проб, ошибок, поэтому верить этому не стоит. Смотрите кейсы подрядчика.
Есть сильные неразвеянные сомнения. Скажите об этом подрядчику, и если подрядчик их не развеял - не начинайте, не рискуйте.
Определяйте для себя непоколебимые принципы. Посмотрите, насколько четко команда подрядчика будет выполнять правила работы, принципиальные для вас. При систематическом нарушении — расставайтесь. Если вы все сделали правильно, то хорошо будете разбираться в коде, который написал ваш подрядчик, и расставание с подрядчиком не станет для вас катастрофой.
Мантра для проекта на любой стадии развития
Подводя черту: помните, вы заказчик. Не забывайте об этом. Да, вы хорошо общаетесь с командой подрядчика, выстроили партнерские отношения, но вы не должны нести ответственность за их локальные сложности.