Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Венчурный фонд и стартап-акселератор
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
45
Битрикс24

Битрикс24

www.bitrix24.ru

15
GIFTD

GIFTD

giftd.tech

13
Aword

Aword

Приложение для изучения английских слов

12
Логомашина

Логомашина

logomachine.ru

12
Convead

Convead

convead.ru

11
Devicerra

Devicerra

devicerra.com

11
Eczo.bike

Eczo.bike

www.eczo.bike

11
Flowlu

Flowlu

flowlu.ru

10
Отследить-посылку

Отследить-посылку

отследить-посылку.рф

10
KEPLER LEADS

KEPLER LEADS

keplerleads.com

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк в Facebook

Лайфхаки при аутсорсе. Как не попасть впросак

3 272 0 В избранное Сохранено
Авторизуйтесь
Вход с паролем
Эдуард Христусь, сооснователь и руководитель производства компании Func, в рамках очередной встречи iDoMa, посвященной взаимодействию стартапов и digital агентств, поделился со слушателями советами и правилами по процессу аутсорса разработки существующего продукта.

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

  • 1.Разгрузить своих сотрудников для более важных задач
  • 2.Выполнить работу, на которую не хватает знаний и в то же время нет времени наращивать экспертизу внутри компании.
  • 3.Минимизировать расходы, в случае если при внутренней оценке работы она оказалась очень дорогой.

Определите, на какой стадии развития вы находитесь сейчас.

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

Представим, что вы находитесь на стадии развития, когда вы пишете код «на коленке» и затем его правите. Какой вам нужен подрядчик в данном случае и зачем? Вам нужны прозрачные открытые отношения и будущий партнер. Вам нужен подрядчик, с максимальным уровнем зрелости, который уже знают, как правильно, и вы сможете этому у него научиться.

b_565f2f9e0973f.jpg

Лайфхаки для проектов на ранней стадии развития

Лайфхак №1 Как распознать «своего» подрядчика?

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

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

Лайфхак №2 Определите свою роль

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

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

Лайфхак №3 Как с таким подрядчиком работать?

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

Во-вторых, вести «живую» документацию. Этим часто пренебрегают, считая, что «документацию можно не писать, мы все обсудим, доделаем», но вы еще слишком незрелы, чтобы отказываться от этого. Вам нужно описывать бизнес-логику, описывать спецификацию API.

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

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

b_565f304e5753f.jpg

Лайфхаки для проектов высокого уровня зрелости

Лайфхак №1 . Какого подрядчика искать и зачем он нужен?

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

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

Работал по time&material и/или поддерживал написанный не им проект. Компания точно должна иметь успешно-признанный клиентами опыт.

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

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

Вас познакомят с конкретными разработчиками. Это не обязательно, но хорошо, если все-таки это произойдет, потому что вам с ними работать и быть одной командой. Хорошо находиться «на одной волне», чтобы было комфортно, так как вы общаетесь с ними напрямую.

Анализирует, советует, внедряет. То есть вы чувствуете, что подрядчик является частью команды.

Лайфхак №2. Как с таким подрядчиком работать

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

Во-вторых, избегайте прямых комитов для сильно связанного кода. Это достаточно рискованная затея и справиться с ней без проблем тяжело. Один из способов снизить вероятность проблем - избегание прямых комитов в общую ветку. Используйте pull request, проверяйте сами код и только после этого заливайте его в общую ветку.

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

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

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

Лайфхак №3. На что стоит обращать внимание

Общие рекомендации, которые стоит иметь в виду:

Высокая/низкая оценка стоимости по сравнению с другими предложениями. Решить это просто: просите часы. Так вы сможете сравнить: возможно, у одних ставка 5 тысяч рублей за час, а у других 500 рублей за час. Но оценка может различаться просто из-за того, что в нее включено все: одни насчитали на миллион, но у них есть автотесты, автоматическая раскладка кода, группа тестировщиков. И в таком случае цена вполне обоснована.

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

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

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

Определяйте для себя непоколебимые принципы. Посмотрите, насколько четко команда подрядчика будет выполнять правила работы, принципиальные для вас. При систематическом нарушении — расставайтесь. Если вы все сделали правильно, то хорошо будете разбираться в коде, который написал ваш подрядчик, и расставание с подрядчиком не станет для вас катастрофой.

Мантра для проекта на любой стадии развития

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

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