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

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

Тег: трудозатраты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учёт рабочего времени

Время циклично. Времени много.

В России ябедничать не принято. В отличие, например, от Европы или Америки, где даже детям в детском саду категорически запрещают выяснять отношения самостоятельно. Ни в коем случае — зовите взрослых, они разрулят проблему.

Поэтому управленец любого уровня, работающий в российской компании априори не имеет полной картины. Нормальный менеджер среднего звена знает примерно 10 % происходящего. Хороший — 15 %. Чем выше позиция в иерархии компании, тем меньше достоверной информации.

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

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

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

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

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

В kanbanize схема работает так:

Исполнитель открывает доску и нажимает «Log time», чтобы списать время на задачу.

Исполнитель открывает доску и нажимает «Log time», чтобы списать время на задачу.

 

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

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

 

Система отображает запись о трудозатратах с возможностью редактирования.

Система отображает запись о трудозатратах с возможностью редактирования.

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