Как мы работаем

Итак, вы решили заказать нам работу. Или решили заказать вообще, но не уверены кому. Или раздумываете — делать своими силами ли, заказывать ли. Скорее всего, этот текст поможет вам определиться.

Мы можем работать с заказчиком в трех различных вариантах. Самый простой вариант — «Завод». Вы приносите чертежи, мы по ним считаем смету и по ним же производим продукт. Бюджет определяется до начала работ с достаточной точностью и выдаётся заказчику вместе с планом работ.

Более сложный вариант — «Конструкторское бюро». Вы приходите с идеей, мы, в процессе общения с вами, готовим чертежи. Как только, по обоюдному согласию, чертежи будут готовы, мы можем отдать их в производство. На наш завод или на указанный вами — как угодно. Опять же, по желанию заказчика, если изделие по нашим чертежам делает другой завод, мы можем осуществить авторский надзор, провести тестирование результирующего продукта и т. п. Стоимость такой работы традиционно оценивается примерно в 20% стоимости разработки — и ее мы называем перед началом.

Наконец, самый сложный вариант — «Консультации». Если ваши мысли настолько абстрактны, что их нельзя облекать в форму документа, мы готовы работать с вами в режиме консультаций. При этом результатом нашей работы может быть просто более глубокое понимание вами предметной области, какие-либо конкретные документы, демонстрационные программы или даже законченный программный комплекс, на который затрачено 100 человеко-лет нашей работы. Всё, что захотите. Отличие этого варианта от других — в том, что на старте никто не в состоянии точно описать задачу и определить объемы работ. Поэтому оплачивается такая работа почасово.

Рассмотрим варианты подробнее.

Завод

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

Предупредим сразу — секретарша, бывший программист на C++ и начальник отдела АСУ, как правило, не в состоянии написать подобный документ достаточно хорошо. Поэтому мы почти всегда рекомендуем заказать эту работу профессионалам — нам или другой компании, не важно. Конечно, можно сделать требования и силами заказчика и мы, конечно, постараемся перед началом работы внимательно проверить их и указать на возможные проблемы, но по опыту основная беда требований — это их неполнота. А здесь, не потратив существенного времени и сил, мы не будем в состоянии найти все проблемы документа.

Мировая практика же показывает, что успех разработки программного продукта крайне сильно зависит от качества проектной документации. Действительно, если вы ещё проектируя автомобиль, забыли указать, что эксплуатироваться он будет на скорости 200 км/час, изготовитель вряд ли поставит специальные энергоёмкие вентилируемые тормоза. В результате возможен отказ тормозов и авария. Угадать же, что именно из требований забыто, практически невозможно.

Иногда ошибки, допущенные при подготовке требований, легко исправимы. Чаще же их исправление требует существенных денег, заметно превышающих стоимость работы по подготовке документа силами специалистов.

Поэтому мы рекомендуем заказчику считать, что мы — не завод, а…

Конструкторское бюро

Наиболее типичный вариант работы с нами как с исполнителем. В этом варианте заказчик приходит с чем угодно: с идеей, которую он готов описать лишь на словах; с бизнес-планом, в котором продукт описан в трех строках, из которых одна — «в остальном как у Google»; с бумажкой, на которой что-то начеркали вчера за пивом; и даже (изредка) с подробным документом, который описывает требуемый продукт с точностью до кнопочки на экране.

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

Мы (да и почти весь мир) называем этот документ «требования», а не «ТЗ». Отчасти потому, что, зачастую, ничего технического в нём нет. Задача документа — описать буквально то, что требуется от создаваемого продукта. А не то, как он будет устроен внутри. Хотя, если, например, продукт будет взаимодействовать с другими программами, в требованиях могут появиться технические детали. А иногда — если заказчик ограничен в выборе программной платформы или языка реализации — и совсем уж специфические подробности.

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

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

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

Когда требования необязательны

Есть ещё один вариант работы, широко практикуемый на западе в случае стабильных отношений заказчик-исполнитель. Они называются Time & Material. В этом случае заказчик поставляет нам задачи, описанные в произвольной форме, а мы решаем их по принципу best effort. При этом заказчик оплачивает время работы над его задачами и другие косвенные затраты, которые были понесены в процессе работы — закупки специальной техники и программного обеспечения и т. п. (такие затраты, естественно, согласовываются с заказчиком). В режиме Time & Material на старте работ оговаривается стоимость часа работы (обычно мы называем 40 евро в час) и примерные объёмы работы на месяц, которые мы обязуемся предоставить, а заказчик — выкупить.

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

Консультации

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