Время от времени ко мне обращаются знакомые предприниматели или топ-менеджеры с одним и тем же запросом — помочь разобраться с «окончательно распоясавшимся» inhouse-отделом разработки. Ситуация, как правило, описывается примерно одинаково: «мы на них тратим каждый год груду денег, а они все время срывают сроки, месяцами не могут зарелизить элементарную фичу, и постоянно разводят руками, говоря, что нужно нанять еще больше программистов». Меня, соответственно, просят прийти, провести аудит, и навести порядок.
Но для того, чтобы навести порядок, нужно понимать, чем порядок отличается от беспорядка. Меня удивило, что бизнесу оказалось очень непросто ответить на этот вопрос.Поясню на собственном примере. Наша компания — веб-инженеры. Проще говоря, мы занимаемся веб-разработкой. Еще проще — заказным программированием, то есть производим для заказчика программный продукт, тратим на это ресурсы, и, в случае успеха, получаем вознаграждение. Наша экономика сходится в том случае, если стоимость вознаграждения больше стоимости затраченных ресурсов. Поэтому, в нашем случае, «порядок» на производстве означает ситуацию, при которой продукт произведен с заданными (или меньшими) показателями затраченных на это ресурсов. По сути такой «порядок» в нашем случае можно назвать производственным планом или планом выпуска продукции.
Цели производственного подразделения обязательно должны коррелировать с целями всего бизнеса. Повышать эффективность, не зная таких метрик и требований, невозможно. Поэтому, начать разговор о наведении порядка в inhouse-подразделении стоит с определения целей собственного бизнеса, а также тех требований, которые должны выполнять различные подразделения для достижения этой цели. Фактически, на этом этапе вам предстоит ответить на вопрос о том, какую роль в вашем бизнесе выполняет inhouse-разработка? В результате станут понятными и метрики, с помощью которых можно будет измерять эффективность такого подразделения.
Так, если основная роль inhouse-подразделения — производственная, то чаще всего под эффективностью здесь будет пониматься объем продукта, реализованного в единицу времени. В этом случае следят за следующими показателями:
Производительность. Как правило, измеряется в человекочасах. Для этого можно внедрить любой таск менеджер (Jira, Redmine, Wrike, и т.д.) и практику измерения часов, затраченных специалистом на решение конкретного поручения. Общая сумма часов всех специалистов в единицу времени (например за месяц) будет являться показателем производительности.
% выполненных задач. Предыдущая метрика не всегда удобна в случае, если inhouse-подразделение работает над единственным продуктом. В этом случае удобнее использовать показатель процента выполненных задач. Или, иными, словами, скорость (ритм) производства. Для этого весь план проекта разбивается на небольшие календарные отрезки — спринты (чаще всего используются двухнедельные спринты), и измеряется процент задач, которые были выполнены вовремя в рамках конкретного спринта. Логика понятна — 100% мелких задач, выполненных внутри спринта приведет к 100% завершению всего проекта в срок.
В том случае, если inhouse-подразделение выполняет сервисную функцию — помогает другим подразделениям в выполнении их задач, производя продукт или проекты по их поручению, то есть является своеобразным внутренним исполнителем для внутреннего же заказчика, разумно использовать метрики эффективности, традиционные для сферы услуг:
NPS (Net Promoter Score). Вы легко нагуглите массу материалов об этом показателе. Он сейчас очень популярен. Суть проста — после выполнения каждой задачи или один раз в заданный период времени внутренние заказчики оценивают работу inhouse-подразделения, выставляя оценку от 0 до 10. Оценки от 0 до 6 считаются негативными оценками, 7 и 8 — нейтральные оценки, а 9 и 10 — это заказчики, оставшиеся в восторге от оказанной услуги.
% негативных оценок. С этим способом мы часто сталкиваемся в отделениях Сбербанка. Пресловутые кнопочки с позитивным и негативным смайликом рядом с каждым окном операциониста и есть способ сбора такой метрики.
Мы часто сталкиваемся с e-commerce проектами, когда inhouse-подразделение, по своей сути, является бэк-офисом крупного интернет-магазина. В принципе, в такой ситуации применим любой из перечисленных выше подходов, но иногда используются и довольно непривычные для программистов метрики, непосредственно связанные с продажами. Как правило, это вызывает сопротивление со стороны разработчиков.
Традиционно принято считать, что разработка не влияет на объем продаж напрямую, но в случае с интернет-магазином, это все-таки не совсем так — скорость загрузки страниц, а также удобство и логичность интерфейсов напрямую влияют на показатель конверсии. Поэтому, если то, каким будет ваш интернет-магазин, определяет не департамент маркетинга и не коммерческий директор, а руководитель inhouse-подразделения, разумно будет использовать одну из метрик, привычных для сферы продаж:
Выполнение плана по выручке. Тут, наверное, все очевидно, и дополнительные комментарии не требуются — работа inhouse-подразделения считается успешной, в случае выполнения плана бизнеса по выручке. Но программисты могут начать бунтовать, т.к., как я уже упоминал, они зачастую не полностью контролируют показатели, влияющие на выручку интернет-магазина. И в этом случае, нам на помощь приходит следующая метрика ...
Выполнение плана по показателю конверсии. В случаях, когда inhouse-подразделение занимается только развитием собственного сайта, а за привлечение трафика отвечает внешнее агентство, удобнее использовать этот показатель. Конверсия — это процент посетителей, совершивших нужное нам целевое действие, например, завершивших заказ.
Поведенческие факторы. Эта метрика — частный случай предыдущей метрики, используемый в ситуациях, когда отдельные поведенческие факторы сильно коррелируют с коммерческими факторами. Например, посещаемость и глубина просмотра для интернет-СМИ или сайтов ТВ-каналов напрямую влияют на привлечение рекламодателей. А значит и inhouse можно сфокусировать на достижение необходимых метрик.
Часто приходится слышать от не слишком опытных заказчиков ворчание о том, что расходы на IT-агентство становятся такими высокими, что «пора нанимать собственных программистов». Найм отдельных специалистов и создание слаженно действующего и выполняющего задачи бизнеса inhouse-подразделения — это очень разные задачи. Для решения последней задачи вам, как минимум, потребуется понимание роли такого подразделения в вашей организации и умелый руководитель такого подразделения. Без такого руководителя, вы будете вынуждены лично погрузиться во все реалии нашего ремесла — производства программного продукта и управления коллективом инженеров. На освоение премудростей этой профессии могут уйти годы.
Если у вас возникнет желание обсудить эффективность работы вашей inhouse-разработки — напишите нам. Постараемся помочь.
