Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Тег: подрядчик

Выбор подрядчика для разработки приложения

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

У вас четыре варианта подхода к найму исполнителей. 

  1. Инхаус-команда.
  2. Один или несколько фрилансеров. 
  3. Аутстаф команда под полным вашим контролем. 
  4. Подрядчик, которому вы поручаете работу под ключ. 

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

Инхаус команда

Создаём штатные единицы исполнителей, поручаем рекрутеру найти кандидатов в штат. Вносим им записи в трудовые книжки, платим зарплату. 

Вариант хорош, когда приложение планируется очень сложным и дорабатывать его предполагается длительный период (в нынешних условиях «длительно» — это 2-3 года). По деньгам вариант получается чуть ли не самым дешёвым, дешевле только фрилансеры. 

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

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

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

Один или несколько фрилансеров

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

Чаще всего, фрилансеры не требуют договор. Есть пространство для бухгалтерских манёвров с расходами на них. Нет официального оформления отношений — в ваших руках большая свобода в формировании команд и их переформатировании. 

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

Ранее практиковался найм разработчиков-фрилансеров из Украины, они стоили ещё дешевле, относительно российских. Но теперь этому мешает СВО и препятствия для трансграничных переводов. 

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

Аутстаф команда под вашим контроем

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

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

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

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

Подрядчик для работы под ключ

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

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

Возникает вопрос, как потом поддерживать получившееся приложение. Тут возможны варианты, всё зависит от изменчивости среды и потока изменений. Можно заключить отдельный договор на сопровождение с этим же или другим подрядчиком. 

Также возникает вопрос, как в этом случае проконтролировать качество кода с точки зрения последующего обслуживания, развития и доработок.

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

Гибкие методологии

be flexible

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

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

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

Я бы организовал работы так.

Входные условия:

  1. Большое задание — нарисовать шесть альбомов рисунков.
  2. Ограниченный бюджет, не позволяющий обратиться к более ответственному художнику.
  3. Ограниченные сроки — в эти шесть альбомов упирается важный этап съёмок фильма.

 
 
Риски:

  1. Художник имеет особенность периодически проваливать сроки.
  2. Провал данной задачи означает провал важного этапа съёмок фильма.

 
 
Основной план:

  1. Разбил задание на шесть небольших задач — нарисовать первый альбом, второй, третий, так дальше.
  2. Для удобства визуализировал задачу в виде доски trello или экселевского роадмапа.
  3. Поручил художнику исполнить первый альбом. Срок неделя, риски минимальные.
  4. Предложил инструмент, позволяющий оценить качество исполнения без необходимости встречаться лично. Например — Яндекс Диск. Нет ничего сложного в том, чтобы отсканировать рисунок и выложить в облако.
  5. Установил срок для каждого рисунка с контрольной точкой — просрочка на x дней означает автоматическое прекращение сотрудничества.
  6. Установил правило: художник нарисовал рисунок — немедленно выложил в Яндекс Диск.
  7. Никакой предоплаты. Художник заканчивает первый альбом — встречаемся лично, художник передаёт бумажную версию альбома, получает деньги.
  8. Установил дедлайн для сдачи первого альбома (вторая контрольная точка).
  9. После сдачи первого альбома поручил реализацию второго альбома по тем же правилам.

Можно добавить дополнительные мотивирующие фишки. Например, за пять альбомов художник получает лишь 40 % от полной суммы, а за шестой — оставшиеся 60 %.

Вот такой роадмап может получиться:

 
 
Резервный план:

  1. Нашёл второго художника, пусть и более дорогого и достиг с ним предварительной договорённости.
  2. Если первый художник нарушает правила на любом этапе (автоматически теряя время и гонорар), заказ переходит ко второму.
  3. Заложил риск в бюджет. Либо изыскал дополнительные средства (это лучше, чем полностью провалить съёмки фильма), либо «пофлексил» задачу — реализовать не шесть, а, предположим, четыре альбома за исходную сумму.

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

Искренне жаль, что люди искусства пренебрегают методами, давно апробированными профессиональными менеджерами.