Количественная оценка цены на исходный код и программный продукт

Я собираюсь предпринять проект. Это требует, чтобы я написал код, и тонны этого. Требование клиента - передать весь исходный код в конце проекта.

Мой вопрос: как мне определить цену за исходный код и программный продукт? Есть ли метрика, которой следует следовать для определения цены? Как бы определить количество программного продукта?

Дополнительная информация: приложение должно запускаться где угодно, в любой ОС, включая планшеты (iPad, Galaxy Tab и т. Д.), Смартфоны (iPhone, телефоны Android и т. Д.), А также в Интернете. (Теперь представьте, сколько это будет кода) .

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

Тематическое исследование

Вы получили запрос на небольшой сайт на базе WordPress. Единственное, что вам нужно сделать: работать с вашим дизайнером, чтобы создать привлекательную графику, затем создать сам веб-сайт (ничего особенного, просто набор плагинов для добавления в WordPress), а затем развернуть его. Работа очень проста, вы указали 600 долларов.

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

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

Сюрприз: вы обнаружили, что плагин A несовместим с плагином B, что плагин C не работает должным образом, и что плагин D не может быть установлен в новейшей версии WordPress, тогда как плагин A может быть установлен только на этой новейшей версии. Теперь вам придется много писать PHP-кода вручную, и, поскольку вы являетесь разработчиком Python и никогда не писали ни одной строки кода на PHP, это не самая простая задача.

Тем временем заказчик начинает отправлять вам страшные электронные письма, спрашивая, почему работа еще не выполнена, тогда как срок был неделю назад. Вы наконец-то завершили PHP-кодирование, и все отлично работает на вашем компьютере. Клиент счастлив.

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

Наконец, потратив более 3000 долларов на этот проект, вы открыли и запустили веб-сайт. Заказчик злится из-за сроков и из-за того, что «с вами ничего не работает». Вы бы попросили 600 долларов? $ 3000?

Почему это происходит?

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

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

Можно решить эти проблемы с помощью конкретных подходов:

• Четкие и точные функциональные и нефункциональные требования,
• Управление сценарием «Удачи на автобусе» (то есть, дизайнер должен был поделиться с вами каждым документом, чтобы он мог умереть в любой момент, не ставя под угрозу проект),
• Предварительное знание инструментов и языков, которые вы должны использовать (что требует большой работы),
• Постановка, интенсивное тестирование и т. Д.

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

Так что тут нечего делать?

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

У вас есть два способа сделать это:

1. Вольно путь

Если вы работаете над проектами, которые соответствуют Waterfall / V-Model, это может сработать:

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

2. После того, как вы получили этот документ, у вас уже есть:

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

   • Ясное, точное и полное понимание продукта, который вы просили сделать.

3. Идите с вашей командой шаг за шагом, анализируя каждое требование и оценивая:

   • Средняя цена этой части проекта,

   • Максимальная цена без учета риска,

   • Индекс риска.

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

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

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

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

2. Проворный путь

Если вы работаете над проектами, которые подходят для Scrum или других гибких моделей:

• либо не указывать общую цену проекта, а цены каждого компонента,
• или вы можете указать очень приблизительную общую цену в начале, а затем дать более точную.

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

• в первом случае человек поверит, что вы просто крадете ее деньги, прося маленькие суммы снова и снова, и это никогда не закончится,

• во втором случае человек не поймет, почему вы все время меняете цену, особенно если цена растет большую часть времени.

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

Минусы Agile подхода: цена слишком неточная или даже не указана. Большинство клиентов не захотят иметь с вами дело, если вы не скажете им, сколько им придется заплатить.

Не принимайте проект, когда неясно как результат, так и деньги, которые клиент должен заплатить. Я просто делаю следующее:

• Придумайте шаги и платежи, которые клиент должен сделать.
• Когда предыдущий шаг будет выполнен и полностью оплачен, и клиент с удовольствием перейдет к следующему.

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

Платить на основе строк кода (LOC) - глупость. Потому что LOC ничего не значит! Будь умным, напиши хороший код и взимай плату в зависимости от функции!

Удачи,

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