Блог компании Лидер·Айти

Стоимость разработки и вывода на рынок

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

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

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

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

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

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

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

Повременная схема работы: когда это выгодно и как не прогореть

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

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

Как строится работа на повременной схеме?
1. Обсуждается проект, подбирается исполнитель из сотрудников компании.
2. Если необходимо, проводятся предварительные исследования кода и первые оценки.
3. Заключается договор, вносится предоплата за оговоренный объем часов (от человеконедели до человекомесяца).
4. Работы вычитаются из предоплаты.

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

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

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

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

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

Работа над крупными проектами

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

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

После того, как проектная документация готова и оценена, начинаются работы над проектом. Мы используем в своей работе багтрекер Jira (http://www.atlassian.com/software/jira), для того чтобы разбивать задачи в ТЗ на еще более мелкие составляющие. После выполнения нескольких задач мы производим сначала внутреннюю приемку, а затем сдаем микроэтап заказчику. Таким образом клиент всегда в курсе куда и как движется его проект и может своевременно внести коррективы в ход работ.

Кроме багтрекера мы применяем репозиторий (bitbucket.org/). Он позволяет организовать групповую работу исполнителей над проектом. Слияние кода, отслеживание версий, откат назад в случае необходимости что-то исправить, сохранение исходного кода в облачном хранилище – все это позволяет нам нести ответственность за проект, находящийся в разработке и таким образом мы можем гарантировать непосредственно в договоре, что форсмажорные обстоятельства не позволят потерять важные данные.

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

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

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

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

Успешная реализация проекта.

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

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

Есть несколько советов, которые хотелось бы дать, исходя из нашего накопленного опыта и опыта наших клиентов.

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

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

Необходимо выбирать компании с четко отлаженными внутренними процессами по организации труда.

Исполнитель должен:

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

- Использовать в своей работе репозитории.

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

- Понимать важность разбивки проекта на этапы, а этапы на подэтапы и по каждому подэтапу организовывать итеративную разработку:

a. реализация функционала,

b. внутренняя приемка,

c. доработка функционала,

d. внутренняя приемка,

e. сдача заказчику,

f. доработка замечаний,

g. сдача.

- Иметь возможность оказания дальнейшей поддержки для проекта.

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

Ценовая политика

Проведенное нами независимое исследования рынка ИТ-разработки Москвы позволяет нам с уверенностью выставлять конкурентноспособные цены на наши услуги.

Так аналогичные компании на московском рынке, в которые мы отправляли наш запрос, предлагают рейты от 1000 до 2000 руб. в час.

Частные исполнители выставляют средние рейты от 600 до 1000 руб. в час. Читайте нашу статью почему стоит выбирать именно корпоративного исполнителя.

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

Плюсы и минусы фиксированной стоимости оплаты.

Существует два основных подхода в разработке программного обеспечения:

- Контракт с зафиксированной стоимостью оплаты (fixed price).

- Договор с почасовой оплатой труда (time & material).

Fixed price

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

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

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

Исполняя проект, по контракту с зафиксированной стоимостью, подрядчик полностью несет все риски, что отражается на конечной стоимости предложения. К оценке добавляется от 50% до 200% дополнительно заложенных трудозатрат в виде коэффициента неопределенности. Это ведет к дополнительным расходам со стороны заказчика.

Time & material

В случае применения подхода time&material оплата производится за затраченные над проектом часы. При этом нет необходимости разрабатывать детальные технические задания, поскольку разработка движется небольшими (например, недельными) итерациями. Эта схема очень хорошо сочетается с такими гибкими методологиями разработки, как Agile. Прозрачность данного подхода позволяет постоянно быть в курсе событий и непосредственно влиять на процесс разработки.

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

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

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

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

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