Как составить смету на программное обеспечение

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

Смета затрат – общий свод плановых затрат предприятия в денежном выражении на выполнение работ.

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

_{Производственная
себестоимость – затраты, непосредственно
связанные с выполнением данного вида
работ.}

_{Полная
себестоимость – включает производственную
себестоимость, административные и
управленческие расходы и затраты на
реализацию продукции.}

Расчет затрат
по статье «Покупные и комплектующие
изделия».

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

Таблица 6 Расчет
затрат на покупные и комплектующие
изделия

Наименование изделия	Количество, шт	Цена за единицу, тенге	Сумма, тенге
Дискета	1	70	70
Итого	1	70	70

Расчет затрат
по статье «Отчисления от заработной
платы» (социальный налог).

Размер отчислений
определяется в процентах от суммы
основной и дополнительной заработной
платы специалистов (исходные данные в
таблице 3) в размере 11%.

Расчет
затрат по статье «Расходы на подготовку
производства».
Включаются расходы на приобретение
специальной научно-технической информации
необходимой для создания программного
обеспечения. Принимаются равными 5% от
суммы основной и дополнительной
заработной платы.

Расчет
затрат по статье «Общие и административные
расходы».
Включаются расходы на управление и
хозяйственное обслуживание: заработная
плата аппарата управления и общехозяйственных
служб, затраты на содержание и текущий
ремонт зданий, сооружений и инвентаря,
за использование средств телефонной и
радио связи и другие расходы. Принимаются
равными 60% от суммы основной и дополнительной
заработной платы.

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

Результаты
расчетов статей затрат сведены в таблицу
7.

Таблица
7 – Смета затрат на разработку программного
продукта.

Наименование статей	Сумма, тенге	Обоснование
1)Материальные затраты: покупные и комплектующие изделия	70,00
2)Основная заработная плата	114 748,53
3)Дополнительная заработная плата	11 474,85
4)Отчисления от заработной платы специалиста	4 874,10
5)Расходы на подготовку производства	6 311,17
6)Эксплуатационные расходы	17 111,50
Производственная себестоимость	132 604,55
7)Общие и административные расходы	75 734,03
8)Расходы на реализацию	15 146,81
Итого полная себестоимость	230 324,18

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Оценка стоимости разработки программного продукта, информационной системы, сервиса или задачи

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

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

1. Базовая теория

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

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

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

2. Метод оценки – Декомпозиция

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

Конечно, на начальных этапах проекта данный метод будет менее точным, чем на последующих.

Ниже приведён пример таблицы для декомпозиции задач:

В неё можно добавить дополнительные аналитики, например:

• грейд сотрудника (junior, middle, senior – т.к. от грейда будет зависеть ставка).

• Локация сотрудника (Москва, СПБ, Екатеринбург и т.д.)

• Подразделение сотрудника

• Риски (описание возможных рисков)

• Сложность задачи

• Важность задачи

• и т.д.

Приведённая выше таблица не является исчерпывающей. Вы можете добавлять в неё любое количество аналитик, которое потребуется. Я специально не использую термин ИСР (Иерархическая структура работ) или WBS (Work Breakdown Structure) т.к. для большинства специалистов он ассоциируется с планированием работ, хотя на самом деле инструмент многоуровневой декомпозиции нужен именно для оценки. Он не включает в себя календарное планирование (календарные сроки выполнения работ). Для календарного планирования правильно использовать другой инструмент – план-график проекта. К тому же, если мы говорим про гибкие подходы к разработке, то детальных план-графиков может не быть, планирование происходит по другому (спринты, канбан и т.д., другие словами итеративное планирование и выполнение задач), при этом метод декомпозиции всегда будет актуален.

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

Упрощённый список основных видов затрат для ИТ-проектов (для примера):

Ключевой вопрос при декомпозиции – как сильно надо детализировать? т.е. на насколько мелкие задачи необходимо разбивать? На старте проекта важно учесть все задачи, которые влияют на scope (содержание) проекта, при этом понимая, что со временем требования будут детализироваться и оценку потребуется уточнять, сверять с бизнес-целями.

На картинке ниже продемонстрировано, как снижается неопределённость по мере детализации требований.

3. Метод оценки – Расчёт по метрикам и сравнение исторических данных

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

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

Примеры метрик, которые могут быть использованы для оценки объёма работ и стоимости разработки:

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

При использовании метода расчёта по метрикам очень важно понимать какие проекты сравнивать. Многое зависит от языка разработки и стека технологий. Например, надо очень осторожно сравнивать показатели из проекта на Платформе 1С и проектов на open source технологиях, даже если бизнес задача идентичная (что маловероятно, но для простоты примера). А вот если сравнивать проекты на базе 1С с другими проектами на 1С (при условии схожести задачи), тогда точность оценки на базе метрик будет высокой.

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

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

3.1. Определение размера программного продукта

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

Системные метрики, например:

1. Модули системы (если они системно разделены)

2. Веб-страницы, пользовательские окна (интерфейс)

3. Классы

4. Компоненты системы

5. Таблицы базы данных

6. Строки кода (LOC)

Функциональные метрики, например:

1. Функции системы

2. Систематизированные требования к системе (если у требований есть чёткая классификация)

3. Сценарии использования (Use Case)

4. Пользовательские истории (user story)

5. Количество запросов от пользователей

6. Количество запросов по API

Функциональные метрики (функционально-ориентированные метрики) позволяют измерять программный продукт, процесс его разработки с помощью классификации и разделения функционала.

Системные метрики (размерно-ориентированные метрики) позволяют достаточно точно измерить программный продукт и процесс его разработки с помощью системных артефактов. Самый популярный и всем известный пример размерно-ориентированной метрики это – LOC (Lines Of Code) количество строк кода в программном продукте.

Для разных программных продуктов будет правильно использовать разные системные и функциональные метрики, например для относительно простых сайтов подойдут – веб страницы. Для систем, которые чётко разделены на разные функции – функции системы. При этом стоит использовать несколько метрик сразу (например, таблицы БД, строчки кода и функции).

Ниже приведён достаточно простой пример определения средней стоимости, качества и производительности на основании количества строк кода.

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

Производительность = Длина тысяч LOC / затраты чел.мес

Качество = Кол-во ошибок / Длина тысяч LOC

Средняя стоимость = Стоимость (млн. руб.) / Длина тысяч LOC

Документированность = Кол-во страниц документации / Длина тысяч LOC

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

3.2. Использование поправочных коэффициентов

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

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

4. Метод оценки – Экспертный

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

Есть несколько основных правил использования данного метода:

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

2. Существенную пользу принесёт подготовка чек листов для всех участников. Это поможет не упустить важные моменты и повысить точность. Чек листы будут очень сильно отличаться в зависимости от типа задачи, поэтому следует попросить экспертов самостоятельно составить их.

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

В экспертной оценке часто используют метод PERT (Program Evaluation Review Technique). Идея PERT заключается в определение ожидаемой оценки на основании оптимистичного, среднего и пессимистичного сроков выполнения задачи. Вот, как это выглядит:

Формула для расчёта:

PERT = (Оптимистично + (4 * Наиболее вероятно) + Пессимистично)/6

5. Другие модели и подходы к оценке

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

5.1. Косвенные оценки

Данный метод предполагает использование связанных показателей для оценки задачи. Например, у вас есть информация, что один тестовый сценарий на аналогичном проекте выполняется за 2 часа, но нет понимания, сколько этих тестовых сценариев будет. Самый простой способ, это посчитать их относительно количества сформулированных требований (например, user story) или количества запросов на изменение.

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

5.2. Специальные системы для проведения оценок

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

5.3. Покер планирование (или Scrum Poker)

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

5.4. Модели оценки (стандарты)

Есть несколько, если можно так выразится, стандартов по проведению оценки стоимости проектов по разработке ПО:

• Модель Oracle AIM для оценки трудоёмкости. Она основании на полном и точном знании процесса, а также крайне глубокой декомпозиции.

• Модель СОСОМО (и СОСОМО II) – сложная модель оценки разработанная ещё в 70-х года, которая устанавливает соответствие между размером системы в тысячах условных строк кода, типом проекта и трудоемкостью разработки системы.

  Немного более современные модели IFPUG FPA и FPA mkII, в них были введены понятия транзакции, а также репозитория кода.

• ГОСТы:

  ГОСТ Р 58302-2018 управление стоимостью жизненного цикла. Номенклатура показателей для оценивания стоимостижизненного цикла изделия.

  ГОСТ Р 56136-2014 управление жизненным циклом продукции военного назначения. Термины и определения

  ГОСТ Р ИСО/МЭК 25021-2014 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения(square).

6. Ключевые ошибки при проведении оценок

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

Оценки с запасом. Часто сотрудники берут немного времени “про запас” т.е. сверху и дают завышенную оценку.

Интуитивные оценки. Лучше потратить 10 минут на анализ задачи, её детализацию и уточнение, а потом уже давать оценку. Интуитивные оценки чаще всего ведут к нарушению сроков и увеличению стоимости.

Оценка ради бизнес-цели. Когда оценку даёт человек, который заинтересован в выполнении бизнес-цели. Желание выполнить поставленную цель не является плохим явлением, но очень важно давать объективные оценки (особенно, если это касается заказчика или вывода продукта на рынок).

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

Косвенные затраты и задачи. Не весь объём задач по разработке системы учитывается при оценке. Часто это бывает из за недостаточности проработанной бизнес модели, бизнес требований или отсутствие проектирования.

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

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

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

• Отсутствие стандартизированного процесса разработки (когда все понимают, какой порядок работы в JIRA, Confluence и как задача переходит из аналитики в проектирование, а из проектирования в разработку и т.д.).

• Упрощённый и недостаточный анализ требований.

• Отсутствие вовлечённости бизнес пользователей и заказчика.

• Упрощённое проектирование и отсутствие подходов к разработке, качеству написания кода.

• Отсутствие подходов к тестированию или тестирования в целом.

7. Итог

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

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

Буду благодарен конструктивной критике и буду рад, если поделитесь своими методами проведения оценок, которые не учтены в статье. Спасибо.

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

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

Сложности при составлении сметы на разработку программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

Это снова наш клиент — Денис. Он уже разобрался, от чего зависит стоимость мобильного приложения и почему она может измениться во время разработки. Теперь Денис попросил подробнее объяснить, что такое смета на разработку приложения и зачем ему этот документ.

Денису говорили, что ему необязательно понимать, как считается смета — важно смотреть на конечную цифру. Мы же думаем, что, чем понятнее для клиента процесс формирования сметы, тем очевиднее для него ценообразование на проекте. В статье разберём:

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

Что такое смета разработки приложения и зачем она нужна 

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

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

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

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

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

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

Как считается смета мобильного приложения: показываем в картинках

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

Есть только один способ понять, подходит вашему бизнесу мобильное приложение или нет — обсудить идею проекта с экспертами. Напишите или позвоните
нам +7 495 204-35-03 — услышим, поймём, расскажем, как мобильное приложение поможет бизнесу развиваться, и разработаем для ваших клиентов полезный сервис

Какие элементы включает смета на разработку мобильного приложения

1. Этапы и часы — это база всех подобных документов. В левом поле, которое будет отвечать за строки в таблице, мы прописываем этапы разработки: проектирование, дизайн, разработка бэкенда, мобильная разработка, тестирование и релиз.
В поле напротив — часы специалистов.

2. Конкретизация этапов — требования и пожелания клиента по работе мобильного приложения мы переводим на язык разработки: фиксируем их как те самые фичи и артефакты, о которых уже сказали выше. Декомпозируем эту функциональность
и подробно расписываем, что сделаем на каждом этапе. 

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

4. Стоимость проекта — после того, как функциональность оценена в часах, мы перемножаем часы на ставку специалистов и получаем ориентировочную стоимость проекта.  

Где найти шаблон сметы на разработку приложения

С готовой сметой идём к клиенту, чтобы сориентировать его по стоимости и срокам разработки. Документ показывает, как мы декомпозировали задачи и во сколько их оценили, — клиент видит, за что будет платить деньги.

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

Почему мобильные студии много внимания уделяют составлению сметы

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

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

Как смета используется на проекте во время разработки

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

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

Почему происходит переоценка проекта 

1. Новые требования 

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

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

Недавно к нам пришёл клиент, которому нужен был веб-сервис для оказания услуг клиентам в Москве. Мы сделали смету, подписали договор и приступили к разработке. Спустя два месяца клиент понял, что хочет масштабировать проект: 1) сделать его международным; 2) дать возможность другими компаниям продвигать услуги с помощью этого веб-сервиса. 

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

2. Изменение в способе реализации

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

Переоценка после аналитики и проектирования 

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

Пример 1

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

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

Пример 2

У нашего клиента сильный отдел маркетинга. Они хотят отслеживать эффективность приложения и считать метрики. Но во время пресейла их требования к аналитике ещё не сформированы, поэтому мы оцениваем базовый набор метрик. К этапу проектирования клиент даёт нам список из 20 показателей, которые нужно отслеживать. Реализовать это — сложнее и дольше. Мы потратим больше часов, чем планировали изначально, а следовательно — работы будут стоить дороже

Какие документы фиксируют конечную стоимость работ

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

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

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

Как помочь разработчикам сделать смету, которая будет совпадать с конечной стоимостью разработки

Чем лучше клиент знает свой проект в самом начале пути, тем больше шансов, что стоимость приложения будет такой же, как указано в смете. Если будет хоть одно неизвестное, то нужно готовиться к тому, что стоимость приложения изменится в большую или меньшую
сторону (но не больше, чем на 15-20%).

Чтобы смета была максимально близкой к финальной стоимости разработки, клиент может: 

• подготовить бриф или ТЗ — если есть документы, в которых описана вся функциональность мобильного приложения, все интеграции, то для нас это идеальный вариант — мы сразу увидим, как должно работать приложение, и скажем,
  сколько это будет стоить;
• активно пользоваться схожими приложениями по функциональности — запоминать свой опыт, выделять что нравится, а что не очень и делиться этим со студией разработки — тогда нам будет очевидно, чего ждет клиент; 
• закладывать риски — если на пресейле вы можете рассказать о проекте в общих чертах, то для нас надёжнее будет заложить в оценку риски: это предупредит всех участников процесса, что какие-то детали на проекте могут измениться,
  но меньше скажется на изменении цены; 
• развивать MVP — можно начинать разработку приложения, в котором будут только базовые функции — такой проект быстрее запускается и легче масштабируется — новые функции добавляются постепенно. 

Можно ли делать приложение без сметы

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

1. Как работать по договору аутстаффинга

Если у вас уже есть приложение с планом развития, с командой менеджеров, но не хватает технических специалистов, которые могут воплотить задумку в жизнь, вам нужны аутстафф-разработчики.
Это люди, которые устроены в штате одной компании, но по договору аутстаффинга имеют право временно работать в другой команде. Для этого им лишь нужно знать, какие задачи вы им ставите. Позвоните нам, чтобы нанять помощника для своего проекта +7-495-204-35-03. 

2. Что такое ретейнер-модель

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

Как начать разработку мобильного приложения, если есть только идея

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

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