Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах ITSM 365 Пользователи Компании Лента заказов Курс по ITSM

Какая адекватная цена на разработку корпоративного ПО?

Какая адекватная цена на разработку корпоративного ПО?
Знаете чем мне нравится биржа? Там всегда понятна текущая цена на товар!
Увы, услуги по разработке программного обеспечения на бирже не торгуются. Все попытки сделать площадку, на которой можно было бы быстро получить оценку стоимости проекта, проваливаются.
 
В подавляющем числе случаев цены на услуги по разработке ПО не публикуются. Рамочную оценку проекта озвучивают после обсуждения ТЗ.
Насколько эта оценка адекватна и на сколько соответствует рынку?
 

Как оценивают стоимость проекта

Все способы оценки стоимости сводятся к трем базовым:
  1. От финансовых возможностей заказчика. Определить сколько готов заплатить заказчик и под это подгонять стоимость работ. 
  2. По опыту прошлых проектов. Берем фактические затраты на похожий проект. Меняем название и накидываем процент на инфляцию. 
  3. От себестоимости. Составляется задач по проекту (структурная декомпозиция работ). Для каждой определяется требуемое время, которое умножается на ставку сотрудника.
 
Комбинируя эти способы хороший менеджер/продавец может в довольно широких диапазонах варьировать стоимость проекта и подстраиваться под заказчика. Но даже очень хороший менеджер/продавец не всесилен и почти всегда сталкивается с настойчивым требованием об оптимизации (уменьшении) стоимости работ.
 

Способы оптимизации стоимости

 
Шел 2012 год. На одной из встреч Заказчик спросил: "А вы работает над оптимизацией стоимости разработки и снижением кол-ва ошибок?". Хотелось ответить: "Нет, а зачем?", но ответили: "Конечно!" и перевели разговор на другую тему.
Конечно же мы не снижали ни себестоимость, ни пытались радикально снизить количество ошибок. Это не имело для нас смысла, заказчик платил исправно и только изредка жаловался на цену.
 
Но времена меняются и в 2014 году мы задумались над оптимизацией стоимости разработки и последующей эксплуатации разработанного нами программного обеспечения. Надеюсь, не только мы.
 
Итак, со стороны заказчика только один способ оптимизировать стоимость: снижать требования.
Требования к функциональности, качеству, документации, производительности и так далее.
 
Со стороны исполнителя способов значительно больше. Вот основные способы снижения затрат на разработку:
  1. Оптимизация затрат на персонал
  2. Финансирование одних проектов за счет других
  3. Внедрение методологии разработки
  4. Использование готовых решений/компонентов
 
Оптимизация затрат на персонал
Самый популярный способ уменьшения цены проекта. Обычно, приводит к печальным последствиям. Как для проекта. Так и для компании. 
 
Финансирование одних проектов за счет других
Второй по популярности "трюк". В надежде на получение более крупного проекта, компания-разработчик соглашается на изначально убыточный для себя проект. Обычная пирамида. Главное, что бы пирамида не закончилась на вашем проекте.
 
Внедрение методологии разработки.
Упорядочивает процесс работы. Производительность труда увеличивается не всегда, снижается кол-во ошибок. Внедрить эффективную методологию получается не у всех.
 
Использование готовых решений/компонентов. Самый сложный и эффективный способ снижения стоимости проекта. Требует значительный инвестиций в инструменты разработки - покупка сторонних или разработка собственных.
 
Первые два способа могут дать преимущество в краткосрочной перспективе, но от сотрудничества с компаниями, которые злоупотребляют ими, стоит воздержаться.
Наиболее "здоровый и правильный" это инвестиции в использовании готовых решений/компонентов и собственных разработок, которые повышают производительность труда и снижают количество ошибок.

Подведем итоги

 
Каждая компания разработчик программного обеспечения имеет свой уровнь цен, который складывается из множества факторов, таких как уровень профессионализма сотрудников, используемые технологии, наработки, подход к работе, выстроенные бизнес-процессы и т.д.
 
Хотя цены на бирже в конкретный момент времени t и предельно ясны, но чтобы торговать успешно и с прибылью – вы всегда должны угадывать направление изменения цены. Так и в разработке ПО - важно понимать в бюджете вы или нет, когда ветер вдруг меняется. А он меняется.
 
Только сравнивая предложения от разных компаний можно понять адекватную ли цену предлагает ваш исполнитель. Сравнивать предложения лучше на тендере, но для получения рамочной оценки можно воспользоваться одним из on-line калькуляторов.  Это будет полезно, даже если вас, в целом, устраивает текущее предложение вашего подрядчика, просто откройте калькулятор и посчитайте бюджет.
 
Оригинал статьи здесь.
 

Комментарии (18)

  • Аватар

    Емец Станислав Валерьевич [CYFiVE], 19 апреля 2015, 10:49

    0
    У нас в городе, все более или менее адекватные разработчики пляшут от человекочасов * на ставку часа (не человека, а некая ставка в которую включены все затраты + маржа) и при первой беседе мне всегда называли цену +/- 100 тыс. руб. А еще все они применяют agile методологии в разработке ПО, что очень сильно уменьшает риски финансовых потерь на проекте.
    • Аватар

      Melnikov Dmitry [dmelnikov], 20 апреля 2015, 13:50

      0

      А если бюджет проекта 5 МЛН, то точность тоже +/- 100 тыс. руб? 

       

      >>очень сильно уменьшает риски финансовых потерь на проекте.

      Agile в своей основе предполагает разбиение проекта на частые итерации (как правило, 1-2 недели). Не более. При грамотном ведении проекта это позволяет на раннем этапе выявить проблемы. Но не более того.

      • Аватар

        Емец Станислав Валерьевич [CYFiVE], 21 апреля 2015, 06:43

        0

        у меня таких проектов не было :)

        но думаю, погрешность не сильно будет большая, по сравнению с бюджетом.

      • Аватар

        Емец Станислав Валерьевич [CYFiVE], 21 апреля 2015, 06:46

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

          Melnikov Dmitry [dmelnikov], 21 апреля 2015, 14:13

          0

          Тут не согласен.

          Между понятиями "рабочий продукт для разрабочика" и "рабочий продукт для заказчика" огромная пропасть.

          • Аватар

            Емец Станислав Валерьевич [CYFiVE], 21 апреля 2015, 15:16

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

              Melnikov Dmitry [dmelnikov], 21 апреля 2015, 15:26

              0
              Это применимо только в части работ по пользовательскому интерфейсу.
              • Аватар

                Емец Станислав Валерьевич [CYFiVE], 21 апреля 2015, 15:58

                0
                нет, тут вы не правы, понятно, что архитектура закладывается на самых ранних этапах, но и ее можно поменять, если требования поменялись...
                • Аватар

                  Melnikov Dmitry [dmelnikov], 21 апреля 2015, 16:20

                  0
                  Можно всё, вопрос только в бюджете проекта :)
                  • Аватар

                    Емец Станислав Валерьевич [CYFiVE], 21 апреля 2015, 19:21

                    0

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

                    • Аватар

                      Melnikov Dmitry [dmelnikov], 22 апреля 2015, 11:09

                      0

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

                      Ситуация, в которой заказчик принимает функционал по частям, очень опасна прежде всего для самого заказчика: части работают, а система в целом нет. И кто виноват в данной ситуации?

                      Правильный ответ: виноваты оба!

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

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

                    • Аватар

                      Мартикайнен Андрей [Wooster], 08 мая 2015, 14:54

                      0

                      > Я бы на месте 1С-ников вообще бы только по аджайлу и работал

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

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

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

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

                      • Аватар

                        Емец Станислав Валерьевич [CYFiVE], 08 мая 2015, 15:12

                        0
                        Так и я про тоже, что внедрение по итерациям это очень хорошо. А насчет споров, если исполнитель и заказчик работают впервые, то это почти всегда, иногда исполнитель наговорит о себе с три короба, а на практике выясняется, то он просто приукрасил себя очень сильно. Так-же как и заказчик, говоришь с ним, вроде все понятно, а потом выясняется, что тебе выдают не понятно, что за желаемое... Так, что часто виноваты обе стороны. Я могу привести одну историю, когда на одном делали переход с 7.7 на 8.0, я и представитель бизнеса убедили топов, что надо в 8-ке реализовать минимально необходимый функционал, внедрить и потом уже развивать, подрядчик все это принял. Но за пару месяцев до внедрения, представитель бизнеса ушла в декретный отпуск, а на ее место пришла другая дама, которая сказала, что надо реализовать кучу функционала, и его закончили за месяц перед внедрением (как взялся за это подрядчик, я не понимаю, но на дворе был кризис 2008 года), и соответственно внедрение неотттестированого функционала просто парализовало работу компании на 4 месяца. Вообщем виноваты оба были.
                        • Аватар

                          Мартикайнен Андрей [Wooster], 09 мая 2015, 11:40

                          0

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

                          PS То, что умная женщина вместо всей этой ерунды ушла размножаться, - это правильно.

  • Аватар

    Бондаренко Руслан [bruslyc], 21 апреля 2015, 21:19

    0

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

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

    Поддерживаю подход рассчёта на основе человеко-часов, но с жесткими рамками и штрафами за невыполнение сроков... но такого у нас видел

    • Аватар

      Melnikov Dmitry [dmelnikov], 22 апреля 2015, 11:40

      0

      Такой подход имеет место быть в некоторых компаниях. Данный подход недальновиден и ведет к большим проблемам.

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

      Расчет на основе человеко-часов наиболее понятен подавляющему числу заказчиков (даже которые в разработке ничего не понимают). Так сложился рынок.

      Про штрафы за срыв сроков

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

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

      • Аватар

        Бондаренко Руслан [bruslyc], 22 апреля 2015, 11:59

        1

        я и говорю - кустарные методы производства влекут за собой кустарное ценообразование

        потомучтояхочустолько и точка

        допилы и индивидуалка потом выливается в гемор при обновлении

        - аааааааа, после обновления пропала моя любимая формочка и половина отчётов.... и тут начинается

        поэтому тут или с запасом или на сопровождение по ставить