Рассказываю на примере, как без навыков программиста прикинуть примерную стоимость разработки мобильного приложения.
Цель статьи научить стартаперов правильной оценке стоимости приложения. Забегая вперёд, скажу, что в статье не будет указания на "честную стоимость часа" или подобные вещи, которые будут восприняты, как самопиар. В статье речь о том, как правильно составить структуру приложения, прикинуть её плюс-минус в часах и умножить на рейт часа понравившегося разработчика.
Небольшая инсайдерская информация – это механика, которой пользуется наш отдел продаж, чтобы сориентировать человека по стоимости. Делюсь с вами, возможно, поможет и кому-то из коллег-разработчиков. В данный момент мы занимаемся разработкой webview-приложений, поэтому такая оценка верна для них. Но, если будет запрос от аудитории найду время, чтобы высчитать для натива.
Теория
Для начала вам нужно понять, что вам необходимо. Технический дизайн или же красивый и отрисованный? Вся оценка сводится к трудозатратам разработчика, то есть сколько времени он потратит на экран. Есть два варианта развития: либо разрабатывать дизайн, верстать его, а затем собирать сервер и приложения, либо использовать более быстрый подход, собранный на Bootstrap. На Bootstrap не будет дизайна как у Лебедева, но его может собрать программист на основе шаблонов элементов интерфейса и не нужно будет тратить время и деньги на дизайнера. Оцениваем два подхода: с дизайном и без дизайна, при этом, предполагаем, что дизайн у вас уже отрисован. Экраны мы делим на три типа:
- Простой
- Средний
- Сложный
Важно правильно понять, к какому типу экран относится.
Простой экран – это тот экран, на котором есть только информация, и нет никакого взаимодействия. Например, просмотр новостной ленты, просмотр новостей, акции. Взаимодействий в таких экранах нет. Цель экрана – это информирование.
С дизайном: 6 часов разработки.
Без дизайна: 2 часа.
Средний экран – это экран, на котором присутствует только одна значимая функция. Например, экран регистрации/авторизации, экран отправки формы обратной связи, экран товара в магазине.
С дизайном: 8 часов на верстку и 8 часов на сборку. В общем – 16 часов.
Без дизайна: 1 час на верстку и 8 часов на сборку, всего 9 часов
Сложный экран – это экран, где есть переплетения различных процессов. В нем имеется много работающих кнопок и функционала. По сути – это такой экран, где программист вопрется и будет долго думать над его реализацией. Обычно, это лента товаров с множественной фильтрацией и сортировками, это экран навигатора в такси, в общем, на которые смотришь и понимаешь, что тут всё сложно :)
С дизайном: 40 часов на вёрстку и 40 на сборку, всего 80 часов.
Без дизайна: если делать на Bootstrap, то 5 часов верстка и 40 сборка, всего 45 часов.
Я рекомендую оценивать экраны по такой методике. Решать уже вам, что лучше – использовать разработку с дизайном или без.
Практика
Теперь рассмотрим, как оценить приложение по такой схеме на примере INCLAMER, о котором я писал ранее. Суть приложения перевести все билборды города в приложение, тем самым, избавляясь от большого количества рекламных баннеров и предоставляя людям экологичную рекламу (на которую подписывается сам пользователь).
По методике оцениваем приложение и сделаем структуру:
- Регистрация/авторизация. Это средний экран, потому что мы совершаем действия: в данном случае регистрируемся, и нам приходит SMS.
- Карта, геолокация. Это сложный экран, так как необходима карта со списком предложений. Так же нужно взять из базы список магазинов и внедрить их в приложение. Помимо этого нужно определить, где находится человек и когда ему отправлять push-уведомление.
- Список предложений. Простой экран, со списком полученных предложений
- Просмотр акции. Простой экран, только просмотр деталей предложения
В приложении есть ещё экраны, но для этой статьи решил оставить эти 4.
С дизайном: сначала рассчитываем время, получаем 16 + 80 + 6 + 6 = 108 часов.
Без дизайна: с версткой на Bootstrap получается 9 + 45 + 2 + 2 = 58.
Теперь мы умножаем на стоимость одного часа программистов, у нас это стоит 1800 рублей. Если делаем с дизайном, получается 194 400 рублей, без дизайна - 104 400 рублей. На Фрилансе можно спокойно найти людей, которые сделают вам дешевле, хорошего фрилансера на webview можно найти по 800-1000р. в час.
Итог
Это статья не является рекламной. Моя задача научить, как правильно оценивать стоимость приложения. Так же хочу протестировать идею, что я смогу составить для вас структуру и помочь при собеседовании фрилансера. Если есть задача дёшево сделать приложение, то напишите мне и я помогу не обмануться на фрилансе.
Так же пишите в комментариях, что в этой схеме оценки не понятно, какие детали не ясны, разберем в комментариях, либо в следующей статье.
Вот меня убивают эти трудочасы. У дизайнера уйдёт столько часов... у программиста столько... убейте меня не понимаю... вы делаете по заготовкам (шаблонам)??? У меня совершенно другой опыт в этой области. Работали как с фрилансерами так и студиями, разного уровня. В жизни не обращусь в студию если мне начнут считать трудочасы. Мне нужна цена за проект по тз!!!!! Программист для внедрения этой фичи потратит 3 часа, а дизайнер 4. Бред. По будильнику вдохновение дизайнера работает?
Нет другой схемы расчёта стоимости на рынке. По ТЗ если работать - то же самое будет: посчитают стоимость фичи в часах и возьмут за итог выше средней оценки времени для страховки, что ТЗ кривое было. В итоге будет то же самое.
Внутри компании пусть делят хоть на минуты. Это их внутренний менеджмент. Я хочу знать следующие показатели: срок выполнения n месяцев, стоимость n тугриков. А выкатывая часы - это называется - пыль в глаза. Мы такие важные! И вот почему возьмём много денег. Компания, рисовала некоторые сервисы google и другие крупные проекты - срок/цена + перед приговором обсуждались проблемы возможные и как из избежать... это не рынок диктует, а маркетинг!!!!!
Вы можете закрывать уши или глаза, когда понимаете что сейчас будет слово»Часы». И в итоге все будут довольны)
Останавливаю на этом чтение/общение. Я лишь высказал своё мнение, надеюсь оно поможет компаниям в выборе подхода к клиенту.
про часы говорят не для понтов, а для того что бы объяснить их чего складывается цена!
зачем тебе пытаться обьяснять из чего складывается цена?
Она такая, какая есть, какие с этим проблемы?
тебе же не обьясняют про цены на квартиры в Москве, или на немецкие машины.
Попытки чего-то там обосновывать и дичь по поводу часов втирать это видимо от неуверенности в себе.
Это вытекает из вопросов клиентов "А почему так дорого?" и "Если убрать вот этот функционал сколько сэкономим?"
В строительстве есть такой же подход, называется "Сметная документация" и там прописана стоимость на материалы и работы.
Ответ прост - продать проект за столько сколько он стоит и не давать при этом скидок на пустом месте.
Всё верно. Потому я и оставил за скобками рейт часа - каждый выбирает тот, который считает честным
Ну не будет в договоре / обсуждении слова "часы" - как это Вам поможет? А как аргументировать тогда логичный вопрос "А почему столько, а не в два раза меньше?" Впрочем, если это не волнует, то n месяцев на x фич - та же песня, просто стоимость будет не часа, а месяца ;)
В том то и дело читал договоры с раскладкой по часам!!! И их большинство. Трудочасы великолепно походят для штамповки «сайтиков на шаблонах», а разговаривая о жирных проектах - есть дедлайн. У вас есть глобальная задача и вы командой решаете процесс. А в ходе тестирования проекта, например, оказывается, что есть узкие места (иногда не все можно предусмотреть), и их нужно оптимизировать и что тогда???? У программиста исчерпан лимит по времени! И опа! Оставим так? Или идем к клиенту и объясняем ему мол так и так ты попал ещё на бабки. Это Мега непрофессионально. И если углубиться, то примеров очень много против схемы по часам. Я за дедлайн.
Это мне напоминает пример с такси , где клиент берет заказ не по счетчику, а фиксированная стоимость поездки. И когда таксист упирается в пробку он высаживает клиента, т.к. этот "окончательный фикс" может занять унего целый день.
Нечто подобное есть и в ремонте\отделке и в автосервисе.
Но проблема возникает в случае какой-то некалиброванной задачи, когда сложно сходу оценить ее сложность.
Если разработчик взялся за проект и оценил его в n -часов и по ходу станет понятно что потребуется в два три раза больше , клиент будет обречен оплатить эту сумму. Если проект простой или его бросили, то лишнее никто не вернет. также проблемы с исправлением недоработок.
Идеальный вариант лично мне видиться так:
Нужна гибкость и не сухое следование договру , а взаимоподстройка. Но это работает , когда обе стороны понимают, что действуют добросовестно.
Изначально берется некая первичная цифра и первичный дедлайн, затем по ходу работ если он выше, клиенту это объясняется, он это одобряет и договр дополняется.
Но опять же это наличии доверия. А мошенников сейчас очень много.
Поэтому приходим к необходимости независимого эксперта , которого изначально признают обе стороны.
Вообще даже в строительстве есть такое понятие как "внешний надзор"(хотя вроде и заказчик и исполнитель обладают немалой экспертностью). Когда привлекается сторонний профессиональный эксперт, который может оценить и стоимость и уровень исполнения, указать на ошибки, потребовать исправления.
И со всем что связано с "разработкой\стратапами\проектами" эта ниша сторонней экспертизы сейчас пуста. Эти эксперты привлекаются со стороны случайно и не всегда .
Дедлайн опосредовано связан с часами разработки. Сроки сдачи никогда не будут на 100% основанными на оценке в часах. Оценка в часах - это стоимость. Дедлайн - это дедлайн. Может кто-то это смешивает, но это такое себе. Я ж говорю просто о чем, допустим у нас стоит 6 месяцев на разработку (дедлайн), я за них даю Вам цену исходя, скажем, из 320 часов в месяц. Ну и выкачу сумму. Дедлайн 6 месяцев. Сумма за 1920 часов. Ну не будет там написано раскладки по часам, а будет помесячно или одна итоговая сумма. Это что меняет?
Вопрос в том, что я НЕ хочу платить за процесс (трудочасы). Я готов платить за результат. Поэтому от исполнителя требую определения даты/цены. А внутри он уже сам все решает.
Комментарий удален модератором
Т.е. вы не несёте ответственности за свой велосипед?
Комментарий удален модератором
Есть понятие: опыт! И если у Вас мало опыта, то соответственно вы сделаете больше ошибок. Это Ваша проблема, а не проблема заказчика. Как правило заказчик готов оплачивать компетентным специалистам, а ответ типа: ну я не знаю, может день... не устроит его. И не нужно лениться изучать тз. А то получается вы заявляете о том, что это риск связываться с вами. И о программировании наслышан не из комментариев
Комментарий удален модератором
И в каком месте Вы специалист если просчитались на 7 дней?
Это если есть ТЗ в классическом понимании, а не фото салфетки с квадратиками. Хорошая практика - это выставлять счёт за ТЗ в рамках отдельного этапа.
Позиция у Вас понятная. Но, как Вы и написали, узкие места не всегда можно предусмотреть зарание. Позиция - сам накосячил, исправляй бесплатно часто приводит к тому, что у программиста начинает болеть бабушка и прочие каламбуры. Иногда выгоднее понять и доплатить, чем идти на FL с проектом в стиле "осталось поправить пару багов"
Всегда внутренняя оценка проекта производится в часах, иначе просто никак не посчитать. Оценка производится на основании опыта разработчиков. Затем закладываются риски (запас по времени) и умножается на стоимость часа, с которой готова работать студия на этом проекте. Дополнительно ставится дедлайн по договору, как правило, значительно превышающий точную оценку в часах. Вы платите всегда за результат, а не процесс.
Проекты, где платят за процесс, единичны. Как правило, заказчик не имеет четкого видения и собирается руками исполнителя проверить концепции, оплачивая трудочасы. Такой заказчик понимает в разработке и участвует во всех стадиях проекта.
Дорогой Роман, желаю каждой студии такого заказчика как ВЫ, такого который не вникает в детали, не считая т деньги и готов переплачивать на пустом месте.
Детали и трудочасы - разные вещи. Я мыслю глобально в целом о проекте, вы как специалист работаете над деталями
Вполне возможно оценивать и так, как вы предлагаете. Это называется fixed price
В кп вы как заказчик их можете и не увидеть, но во внутреннем расчёте исполнителя они будут точно.