Исполнители разработчики — полная инструкция по эффективной работе

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

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

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

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

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

Необходимое зло

Заказчик, который появляется на рынке без ясного осознания собственной задачи, представляет собой настоящий приз для разработчиков. Это хрестоматийная ситуация асимметричного владения информацией. Разработчик, в силу своего опыта, сразу понимает, как именно нужно реализовать проект для заказчика, и какие именно дополнительные элементы помогут ему заработать на таком проекте.
Неудивительно, но первое, что нужно сделать заказчику когда он подходит к реализации проекта создания программного обеспечения — это подумать, что же именно заказчик хотел бы получить в качестве результата. Удивительно другое — как много заказчиков перекладывают “подумать” на исполнителей, призванных эти мысли реализовать в коде.

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

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

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

Как это нужно делать

Форма публичной процедуры для выбора исполнителя является результатом применения корпоративных практик заказчика и может проводится в виде конкурса, тендера или любой иной процедуры. Наилучшего эффекта в снижении стоимости предложений заказчик может добиться использованием в качества основы запроса на предложения модульных требований и сбором оценок различных исполнителей по каждому требованию. Модульные требования в определенном смысле можно сравнить с “Прокрустовым ложе”, в которое заказчик укладывает исполнителей-разработчиков.

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

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

Также интересна встречающаяся подмена принципов гибкой разработки. Это когда разработчик просит заказчика выписать вексель на то, чтобы он потратил произвольное количество часов на создание ПО без требований вообще, и называет это Agile. Нужно сказать, что принципы Agile были разработаны 25 лет назад, когда состав программистов был несколько иной, и за последние три десятилетия рынок претерпел значительные изменения. Мы не рекомендуем попадаться на подобные предложения, в противном случае — нужно иметь резерв в виде множителя на первоначальный бюджет разработки, поскольку одной из основных компетенций таких компаний является понимание максимального размера счета, который исполнитель может выставить заказчику.

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