Дискуссия: ожидания и реальность разработки за фикс, аутстаффа и готовых решений

Сегодня я хочу сравнить разработку под ключ, аутстаффинг и запуск на готовых решениях. Говорить буду о приложениях и сложных веб-сервисах, поскольку моя команда Bright Mobile специализируется на них. Поговорить хочу в режиме дискуссии — я накидаю тезисов и очень жду ваше мнение в комментариях.

Простые сайты можно заказать в типовой веб-студии или, если не позволяет бюджет, сделать на фрилансе и/или конструкторе. При заказе более сложных решений, совмещающих в себе к тому же и веб-часть, и мобильное приложение, возникает диссонанс. Во-первых, их можно точно так же заказать под ключ в студии (правда, придётся найти с релевантным опытом). Можно нанять человека в штат или арендовать разработчика, можно подсмотреть уже коробочные решения и попробовать реализовать свой на их основе.

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

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

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

Давайте начнём с преимуществ для основателя, в т. ч. вымышленных.

Стоимость прописана в договоре

Чаще всего процесс начинается с разработки технического задания – как самостоятельного, так и с разработчиком, особенно если проект сложный. Далее это ТЗ оценивается: что-то урезается для снижения стоимости, иногда, наоборот, добавляется что-то пропущенное. В итоге вы приходите к фиксированным срокам и стоимости, которая чётко будет прописана в договоре. Если в ходе разработки вы никакими новыми идеями проект не дополняете, цена, как правило, не меняется.

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

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

Примерно такая же история со средним и крупным бизнесом. Отличия от малого здесь в том, что когда бизнес вырос, то у него уже есть определённые бизнес-процессы начиная с юридических, заканчивая процессами согласований. Исполнителю-разработчику приходится под это подстраиваться и детально просчитать все административные трудозатраты и доптребования невозможно. Поэтому, либо разработчик перезакладывает риски х1,5-2 к оценке, либо предлагает риски разделить по тайм материал.

Я сторонник второго варианта.

Чёткие сроки

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

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

Организация работы

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

Если вы заказали разработку под ключ, голова болеть будет у руководителя проекта или у команды разработки. К вам будут обращаться в тех ситуациях, когда от вас нужны, например, комментарии по ТЗ или иным важным моментам. Беспокоить самим рабочим процессом вас не будут.

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

Отличия от почасовой оплаты

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

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

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

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

Реальная экономия

Второй момент – когда человек запускает не первый проект и примерно знает, как работают программисты, и видит в аутстаффинге возможность сэкономить. Он понимает, что, к примеру, на разработку нужно ~200 часов, перемножает их на ставку программиста (к примеру, 2000 рублей, как у нас) и получает примерно 400к. А студия называют ему 700к, и он понимает, что может сэкономить 300к. Пусть даже он ошибётся, и вместо 400к придётся отдать 450к или 500к, он всё равно останется в плюсе по сравнению с разработкой под ключ.

Нужно понимать, что сроки не фиксированы: вы берёте программиста в аренду. Что вы будете ему говорить, то он и будет делать – с той долей эффективности, которая этому программисту присуща. Поэтому касательно сроков и качества кода нужно иметь в виду некое собеседование конечного программиста перед тем, как вы возьмёте его в работу.

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

Экономия, которую я упомянул чуть выше, заключается как раз на организации процесса. Студия не берёт оплату за труд ПМа и тимлида в рамках вашего проекта: предполагается, что раз вы берёте программиста в аренду, вы можете обеспечить их функции самостоятельно или с привлечением своих специалистов.

Большой ошибкой при аутстаффинге для одного большого проекта брать одного программиста: в один прекрасный момент вы можете прийти к тому, что какие-то задачи окажутся ему не под силу. К примеру, он специализируется на бекэнде, а вы от него требуете вёрстку дизайна.

Хитрёж с доработками

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

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

У нас обычно аренда от 3-х мес и от 50ч в мес без торга. Какие-то уступки готовы давать при договорах от 6-и мес и 75ч в мес загрузки.

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

Мы за 13 лет пробовали запускать примерно 20 разных идей, то коробочного решения со стабильными продажами дошло две:

В обоих продуктах сайт, админка, приложения под обе ОС и настройка под идею клиента.

Быстрый запуск и низкая цена

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

Второе преимущество — это быстрые сроки. MVP на коробке можно запустить за 1 мес, против 3-4 мес при создании с нуля.

Доработки

Созданный на базе готового решения сервис можно использовать в базовом виде. Клиентов, которых удовлетворяет коробочный вариант, у нас около 20%: они уже привлекают в него первых пользователей, формируют беклог следующих задач и ставят в работу. Вторую часть составляют клиенты, которые видят, что ~70% функционала соответствуют требуемому, но какие-либо доработки всё-таки добавить надо. Отрасли и идеи у всех разные, поэтому дообработки индивидуальны для каждой.

Идеология использования готовых решений

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

Так вы сразу услышите общую сумму разработки, на которую можете рассчитывать. Основываясь на собственном опыте, могу сказать, что чаще всего разработка на базе ядра дешевле разработки с нуля дешевле в 2-2,5 раза – даже с максимальным числом внедряемых доработок. Если вам оценили разработку с нуля в миллион рублей, на готовом решении вы вполне сможете уложиться в 400-500 тысяч. Это явный плюс

MVP без переплат

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

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

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

Минусы готовых решений

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

Если у вас внутренний корпоративный продукт, и у вас в принципе не может быть онлайн больше этого объёма, в рамках MVP публичного стартапа — тоже. В случае разработки мирового проекта готовое решение, скорее всего, нужно вам только для тестирования идеи на первые 1-2 года. Дальше вы плавно подойдёте к тому, что нужно либо проводить глубокий рефакторинг этого готового решения, либо делать этот проект с нуля – с таки же функционалом, но с учётом той нагрузки, которую вы предполагаете получить после масштабирования.

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

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

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

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