Комментарии 42
А потом, после названия окончательной суммы, люди начинают работать, делать ПО, и как оно заведено в России и во всём цивилизованном мире, смета начинает расти. Исследование, конечно, полезное, НО, как показывает практика, картина может полностью измениться после того как фирмы уже сделали ПО :)
> Задание было довольно несложное: разработать простую систему расчета зарплаты
это задание несложное? — Вы оптимист, всё что в России связано с законодательством — очень сложно так как законы громоздки и запутаны… расчет зарплаты тянет за собой, больничные, отпускные, алименты, налоги, отчетные формы и прочие выплаты… исправления для той же конфигурации 1С выходят регулярно…
за 100.000 нельзя написать такой софт, и тем более поддерживать его (100.000 уйдет только на ЗП аналитикам), а без поддержки и обновлений он никому не нужен…
за 100.000 можно написать скромненький и очень индивидуальный «учет товаров на складе» например…
это задание несложное? — Вы оптимист, всё что в России связано с законодательством — очень сложно так как законы громоздки и запутаны… расчет зарплаты тянет за собой, больничные, отпускные, алименты, налоги, отчетные формы и прочие выплаты… исправления для той же конфигурации 1С выходят регулярно…
за 100.000 нельзя написать такой софт, и тем более поддерживать его (100.000 уйдет только на ЗП аналитикам), а без поддержки и обновлений он никому не нужен…
за 100.000 можно написать скромненький и очень индивидуальный «учет товаров на складе» например…
Там же ссылка есть, по ссылке видно, что человек просит не расчет зарплаты, а что-то среднее между планом-графиком и стоимостью
rar-архив качать не стал…
наверно я не о тех масштабах и подходе говорю, я о бизнесе по автоматизации предприятий(именно так я понимаю разработку на ПО заказ), а автор наверно о халтурке сделанной на коленке 1-2 программистами, без анализа и обследования предприятия…
наверно я не о тех масштабах и подходе говорю, я о бизнесе по автоматизации предприятий(именно так я понимаю разработку на ПО заказ), а автор наверно о халтурке сделанной на коленке 1-2 программистами, без анализа и обследования предприятия…
Ну этот несложный вывод можно сделать просто увидев график. За 12 000 $ на нормальном предприятии можно сделать первичное обследование.
Александр, а что для вас «нормальное предприятие»? :)
И как вы оцениваете «нормальность»? (я понимаю, что речь идёт о величине и сложности бизнес-процессов, а не адекватности :) )
В моей практике была компания (гордо именующая себя корпорацией) со штатом в 25 человек и оборотом в несколько десятков миллионов рублей. А вот сложные или простые там бизнес-процессы я не могу наверняка сказать даже сейчас :) Простые в целом, но очень запутанные в мелких частностях.
И как вы оцениваете «нормальность»? (я понимаю, что речь идёт о величине и сложности бизнес-процессов, а не адекватности :) )
В моей практике была компания (гордо именующая себя корпорацией) со штатом в 25 человек и оборотом в несколько десятков миллионов рублей. А вот сложные или простые там бизнес-процессы я не могу наверняка сказать даже сейчас :) Простые в целом, но очень запутанные в мелких частностях.
Простите великодушно, за неточность формулировок. «Нормальность», в данном случае, означала как раз, что в ТЗ автора, которое предлагалось скачать, явно не содержится описания множества бизнес-процессов, которые потребуют предварительного обследования, написания и согласования технического задания, схемы «to be», графика внедрения и переподготовки персонала и других важных этапов разработки ПО, которые явно не укладываются в 12 000$ независимо от размера предприятия.
я вас вовсе не обвиняю ни в чём :)
«в ТЗ автора»
Дык не ТЗ это, а то, что обычно высылают заказчики — поток мыслей, родившийся в голове директора и изложенный секретаршей (качество зависит от того, умеет ли секретарша слушать :) )
«не укладываются в 12 000$ независимо от размера предприятия»
Александр, можно я к вам уборщицей устроюсь, у вас зарплаты явно хорошие :) На мой взгляд 12 000$ это многовато для мелкой компании, типа ЧОП. Хотя… ЧОПы бывают разные.
«в ТЗ автора»
Дык не ТЗ это, а то, что обычно высылают заказчики — поток мыслей, родившийся в голове директора и изложенный секретаршей (качество зависит от того, умеет ли секретарша слушать :) )
«не укладываются в 12 000$ независимо от размера предприятия»
Александр, можно я к вам уборщицей устроюсь, у вас зарплаты явно хорошие :) На мой взгляд 12 000$ это многовато для мелкой компании, типа ЧОП. Хотя… ЧОПы бывают разные.
Я и не оправдываюсь. :) Я честно делаю вид, что Вы не стебетесь, а меня не понимаете. Так интереснее.
Автор называет это ТЗ. Говорить заказчику, что это не ТЗ — непедагогично и нерентабельно
Уборщицей нельзя, к сожалению, мы это дело аутсорсим. А так — приходите, конечно, поговорить с умным человеком всегда приятно.
У меня, к сожалению, а может и к счастью, нет опыта работы с ЧОПами.
Сумма, как мне кажется, зависит не от размера предприятия. Если нужно ставить высокоорганизованный процесс, то и самой работы должно быть не мало, иначе будет рентабельнее и проще сделать где-нибудь и как-нибудь.
Автор называет это ТЗ. Говорить заказчику, что это не ТЗ — непедагогично и нерентабельно
Уборщицей нельзя, к сожалению, мы это дело аутсорсим. А так — приходите, конечно, поговорить с умным человеком всегда приятно.
У меня, к сожалению, а может и к счастью, нет опыта работы с ЧОПами.
Сумма, как мне кажется, зависит не от размера предприятия. Если нужно ставить высокоорганизованный процесс, то и самой работы должно быть не мало, иначе будет рентабельнее и проще сделать где-нибудь и как-нибудь.
Кстати для внутренней автоматизации (той где автоматизируется бизнес процессы не затрагивающие законы, налоги, зарплату) малого бизнеса частенько достаточно excel/access (или любого другого табличного процессора и СУБД) и специалист, с мозгами, вовлеченный в бизнес-процесс сам автоматизирует свою деятельность…
да, и еще раз уж вы индивидуальное ПО для автоматизации бизнеса собираетесь разрабатывать, то названная Вами сумма в 100.000 — это очень скромная стоимость обследования предприятия очень малого бизнеса (уровня ЧОП или КА, РА, АН), описания его бизнес процессов с целью дальней автоматизации, для производства цена буедт в 10-100 раз больше…
Это все понятно :) Вы все-таки посмотрите приложенное ТЗ. Там все расписано довольно подробно — по сути, даже исследовать ничего не надо, там прямо конкретно указано, что и как нужно сделать (вплоть до схематических скриншотов). Никаких налогов не надо, это просто программа для облегчения расчета суммы з/п. Внутренняя, для себя.
Тогда возможно, как я написал чуть выше, достаточно заинтересовать расчетчика в повышении эффективности его труда, и он сам все в «excel» сделает…
ps: если вы предложение тоже в rar рассылали, то неудивительно что некоторые Вам просто не ответили…
ps: если вы предложение тоже в rar рассылали, то неудивительно что некоторые Вам просто не ответили…
А что, типа rar — некошерно? :) Лень распаковать, от клиентов нет отбоя и можно выбирать?
при ведении бизнеса не стоит создавать партнерам искусственные сложности, например, использованием форматов файлов которые Вы не уверены, что он сможет открыть (из-за технических сложностей или из-за необходимости использования платного ПО), не стоит использовать rar, лучше предпочесть zip, а конкретно в этом случае, когда упаковано всего 2 файла и размер ~150 килобайт вообще стоило обойтись без архивирования, так же не стоит использовать, без предварительной договоренности с потенциальным партнером закрытые форматы типа doc, лучше использовать простой текст, если подозреваете, что могут возникнуть проблемы с кодировкой, а текста немного стоит его поместить прямо в письмо…
Стоит всегда помнить, что партнер может не являться информационно-грамотным, и что он может использовать совсем другое программное окружение нежели Вы…
Стоит всегда помнить, что партнер может не являться информационно-грамотным, и что он может использовать совсем другое программное окружение нежели Вы…
Вообще согласен, и именно ПАРТНЕРАМ я всегда шлю в zip (он встроен в винду и проблем не должно быть с открытием). Но в данной конкретной ситуации — это не партнеры, а те, кто на мне могут заработать. Кто платит, тот и заказывает музыку. Это раз.
А во-вторых — если IT-компания не может открыть rar… Сами понимаете :)
А во-вторых — если IT-компания не может открыть rar… Сами понимаете :)
nix(mac/linux/bsd) пользователи не очень любят rar — это факт
4ого января я бы выставил цену не постеснявшись.
А по абсциссе — количество фирм? Мне не очень понятен приведенный график :-)
А по абсциссе — количество фирм? Мне не очень понятен приведенный график :-)
Александр, я, по-началу, тоже оценивал предлагаемые мне на разработку проекты, основываясь на предложениях рынка.
Но потом отказался раз и навсегда от этой порочной практики.
Есть множество методик, для оценки стоимости ПО. Очень рекомендую.
Да, конечно, не стоит забывать о здравом смысле и жлобить. :)
Но потом отказался раз и навсегда от этой порочной практики.
Есть множество методик, для оценки стоимости ПО. Очень рекомендую.
Да, конечно, не стоит забывать о здравом смысле и жлобить. :)
>Есть множество методик, для оценки стоимости ПО. Очень рекомендую.
Подскажите пожалуйста парочку лучших, исходя из вашего опыта.
Подскажите пожалуйста парочку лучших, исходя из вашего опыта.
Спасибо за вопрос.
Вообще, существует множество методологий оценки стоимости (и не только стоимости разработки ПО, а любого проекта).
И чем больше вы работаете в некоторой области, тем точнее ваши оценки. Я постараюсь вкратце изложить самые простейшие методики:
1. Оценка строчек кода — как ни банально это звучит. KLOC (исходно: en.wikipedia.org/wiki/Source_lines_of_code, но принято считать тысячами — kilo ). По ссылке же найдёте описание диллемы: что считать за строчку: физическую строку кода или логическую (яркий пример: цикл for).
Суть метода: имея декомпозицию задач, и, исходя из опыта, вы даёте оценку будущего кода: на задачу а надо написать 15000 строк, на задачу b — 7500 строк, и так далее. Затем учитываете сколько затрат на написание 1 строки, на её поддержку, сопровождение, тестирование и т.д. и — у вас есть оценка стоимости по строкам кода
2. Оценка сверху вниз — эта оценка даётся для проекта, когда он разбирается по косточкам начиная с верхнего уровня архитектуры. Чем дальше движемся от вершины — тем точнее оценка
3. Оценка снизу вверх — ка и в п.2, но проект как бы «собирается» из самых мелких модулей (файлов, функций — кому как)
Обычно 2 и 3 — делают вместе, точнее на разных этапах оценки стоимости (влияет наличие ТЗ и другой документации)
Я не рассказал о более сложных методиках (если найду время и… — напишу отдельный топик по этой теме).
В любом случае: любой менеджер проектов обязан (на мой скромный взгляд) собирать метрики проектов. Сколько времени занимает решение задачи, сколько строк кода уходит на разный функционал, сколько ошибок на каждые 1000 строк кода и прочие. Только в этом случае ваши оценки будут уточняться с каждым проектом. Кстати самому ПМ это поможет делать реальные прогнозы.
завтра постараюсь найти какую-нибудь адекватную литературу по этому вопросу и выложу название сюда.
если есть вопросы — с удовольствием отвечу.
Да, и совсем забыл: не надо выбирать — надо комбинировать, искать «срединный путь» :)
Вообще, существует множество методологий оценки стоимости (и не только стоимости разработки ПО, а любого проекта).
И чем больше вы работаете в некоторой области, тем точнее ваши оценки. Я постараюсь вкратце изложить самые простейшие методики:
1. Оценка строчек кода — как ни банально это звучит. KLOC (исходно: en.wikipedia.org/wiki/Source_lines_of_code, но принято считать тысячами — kilo ). По ссылке же найдёте описание диллемы: что считать за строчку: физическую строку кода или логическую (яркий пример: цикл for).
Суть метода: имея декомпозицию задач, и, исходя из опыта, вы даёте оценку будущего кода: на задачу а надо написать 15000 строк, на задачу b — 7500 строк, и так далее. Затем учитываете сколько затрат на написание 1 строки, на её поддержку, сопровождение, тестирование и т.д. и — у вас есть оценка стоимости по строкам кода
2. Оценка сверху вниз — эта оценка даётся для проекта, когда он разбирается по косточкам начиная с верхнего уровня архитектуры. Чем дальше движемся от вершины — тем точнее оценка
3. Оценка снизу вверх — ка и в п.2, но проект как бы «собирается» из самых мелких модулей (файлов, функций — кому как)
Обычно 2 и 3 — делают вместе, точнее на разных этапах оценки стоимости (влияет наличие ТЗ и другой документации)
Я не рассказал о более сложных методиках (если найду время и… — напишу отдельный топик по этой теме).
В любом случае: любой менеджер проектов обязан (на мой скромный взгляд) собирать метрики проектов. Сколько времени занимает решение задачи, сколько строк кода уходит на разный функционал, сколько ошибок на каждые 1000 строк кода и прочие. Только в этом случае ваши оценки будут уточняться с каждым проектом. Кстати самому ПМ это поможет делать реальные прогнозы.
завтра постараюсь найти какую-нибудь адекватную литературу по этому вопросу и выложу название сюда.
если есть вопросы — с удовольствием отвечу.
Да, и совсем забыл: не надо выбирать — надо комбинировать, искать «срединный путь» :)
Не надо считать строчки кода — вы идете по граблям, которые остальное человечество прошло лет 30 назад. Основные недостатки использования этой метрики в качестве основы для планирования разбирал еще Ф.Брукс в своей классической книге The Mythical Man-Month вышедшей в 1975-м году. Эти недостатки также перечислены и на упомянутой странице из википедии.
Самый главный недостаток — это неточность данной метрики. Например, запись оценки в виде «7500 строк для задачи b» предполагает, что точность составляет ±100 строк, тогда как в реальности точность этой оценки примерно ±3500, т.е. итоговый результат может отличаться в два-три раза минимум, а в крайних случаях — на порядок. Производительность разных программистов (или одного программиста на разных задачах) в строках кода также отличается в среднем в 2-3 раза и до 10 раз в крайних случаях и зависит в том числе и от объема кода и от количества других программистов участвующих в проекте.
Не думаю что нужно перечислять остальные недостатки — этого уже достаточно чтобы понять, что данную метрику имеет смысл использовать только для оценки порядка объема некоего проекта, например — «проект в 15000 строк является средним по объему и средним программистом будет выполнен в срок от 3 до 9 месяцев».
Самый главный недостаток — это неточность данной метрики. Например, запись оценки в виде «7500 строк для задачи b» предполагает, что точность составляет ±100 строк, тогда как в реальности точность этой оценки примерно ±3500, т.е. итоговый результат может отличаться в два-три раза минимум, а в крайних случаях — на порядок. Производительность разных программистов (или одного программиста на разных задачах) в строках кода также отличается в среднем в 2-3 раза и до 10 раз в крайних случаях и зависит в том числе и от объема кода и от количества других программистов участвующих в проекте.
Не думаю что нужно перечислять остальные недостатки — этого уже достаточно чтобы понять, что данную метрику имеет смысл использовать только для оценки порядка объема некоего проекта, например — «проект в 15000 строк является средним по объему и средним программистом будет выполнен в срок от 3 до 9 месяцев».
совершенно с вами согласен. имспользовать лишь метод подсчёта строк кода — глупо. В конце моего комментария есть важное, на мой взгляд, замечание: нужно комбинировать.
Лично я всегда оцениваю кол-во строк кода. Да я не делаю это с точностью даже до сотни, но я всегда оцениваю порядок. Не знаю, может я так привык — но мне удобно этим пользоваться на самых ранних этапах оценки, так сказать: окинуть взглядом поле деятельности с точки зрения разработки.
и, как обещал: отлично написано об оценке в шикарной книге Эрик Дж. Брауде Технология разработки ПО. ISBN: 5-94723-663-X
Если нужно, выложу djvu
Лично я всегда оцениваю кол-во строк кода. Да я не делаю это с точностью даже до сотни, но я всегда оцениваю порядок. Не знаю, может я так привык — но мне удобно этим пользоваться на самых ранних этапах оценки, так сказать: окинуть взглядом поле деятельности с точки зрения разработки.
и, как обещал: отлично написано об оценке в шикарной книге Эрик Дж. Брауде Технология разработки ПО. ISBN: 5-94723-663-X
Если нужно, выложу djvu
Так я и не оцениваю на основе предложений рынка :) Это мини-исследование я провел для того, чтобы знать — как действуют конкуренты.
Для оценки стоимости я в основном пользуюсь своим опытом и методикой Джоэля Спольски (у него написано, правда, про составления плана работ, но можно прикинуть общий объем времени и рассчитать стоимость).
Для оценки стоимости я в основном пользуюсь своим опытом и методикой Джоэля Спольски (у него написано, правда, про составления плана работ, но можно прикинуть общий объем времени и рассчитать стоимость).
Подобная задача как раз для фрилансера, серьезная компания с правильным подходом к разработке никогда не выполнит такой проект с прибылью — слишком много накладных расходов.
> Многие из фирм на самом деле предлагали не разработку настольного приложения, а по сути веб-сайта. Т.е. в более сложном проекте, скорее всего, они сложат руки.
Можете пояснить как вы сделали такой вывод? В вашем ТЗ явно не сказано, что это должно быть настольное приложение.
Можете пояснить как вы сделали такой вывод? В вашем ТЗ явно не сказано, что это должно быть настольное приложение.
Не сказано намеренно. Но, на мой взгляд, видно, что такую задачу удобнее (для заказчика в первую очередь) решать с помощью настольной программы. Иначе, если это веб-сайт, то процедура установки будет заметно сложнее настольного приложения, да и работать будет медленнее (с точки зрения пользователя — пока загрузятся страницы и т.п.).
Ну и вообще, каждый раз, когда я вижу веб-решение, еще и на PHP, у меня создается стойкое впечатление, что это очередная веб-студия, коих у нас тысячи.
Ну и вообще, каждый раз, когда я вижу веб-решение, еще и на PHP, у меня создается стойкое впечатление, что это очередная веб-студия, коих у нас тысячи.
Сложный вопрос. Вот я, например, часто предлагаю вместо настольного решения веб. Обычно заказчики радуются, узнав, что а)можно будет смотреть инфу из дома б)при необходимости можно использовать разделение прав доступа.
Кроме того, в ряде веб-фреймворков есть встроенные решения для генерирования отчетов по БД и их заполнению, что снижает сроки и стоимость разработки.
PS: Очень понравилась стоимость разработки в 12 к$. Видимо, собираются использовать SQL Server Enterprise + полгода производить первичное обследование фирмы :)
Кроме того, в ряде веб-фреймворков есть встроенные решения для генерирования отчетов по БД и их заполнению, что снижает сроки и стоимость разработки.
PS: Очень понравилась стоимость разработки в 12 к$. Видимо, собираются использовать SQL Server Enterprise + полгода производить первичное обследование фирмы :)
Обычно заказчики радуются, узнав, что…
в) при появлении новой версии не придется тратиться на обход всех пользователей для обновления и разгребать последствия хождения в базу данных клиентами разных версий
г) работать можно будет в том же окошке, где и читать анекдоты
д) при смерти рабочего компьютера, данные не потеряются
в) при появлении новой версии не придется тратиться на обход всех пользователей для обновления и разгребать последствия хождения в базу данных клиентами разных версий
г) работать можно будет в том же окошке, где и читать анекдоты
д) при смерти рабочего компьютера, данные не потеряются
Сравнивать по ценам очень странно. Поскольку цена, в первую очередь, зависит от подхода, который использует разработчик. Я бы стал сравнивать по цене и качеству тех. задания, если цель понять «сколько у нас в среднем берут за это». То есть взял бы того, кто сделает это со сходным качеством и сходным процессом разработки.
Заказчик подобного ПО не будет, как мне кажется, ориентироваться на цену. Вообще, в наших реалиях найти заказчика, который знает, что ему нужна автоматизация, знает какая именно и готов за нее заплатить — несбыточное счастье.
Заказчик подобного ПО не будет, как мне кажется, ориентироваться на цену. Вообще, в наших реалиях найти заказчика, который знает, что ему нужна автоматизация, знает какая именно и готов за нее заплатить — несбыточное счастье.
Откуда налоги в 40%?
Ну в худшем случае:
Налог на прибыль — 24%
ЕСН — 26% (с ЗП сотрудников)
мож еще что забыл
А т.к. основные расходы IT-компаний — ЗП — так и получается ~40%
Налог на прибыль — 24%
ЕСН — 26% (с ЗП сотрудников)
мож еще что забыл
А т.к. основные расходы IT-компаний — ЗП — так и получается ~40%
> 1. Разослал я 23 письма. Ответов пришло всего 14! Т.е. грубо говоря половина вообще не откликнулась никак.
Ничего удивительного, таких как вы не любят. Половина вас просто вежливо послала, не став обижать.
Ничего удивительного, таких как вы не любят. Половина вас просто вежливо послала, не став обижать.
Да? И почему же не любят?
Не все компании способны работать с заказчиком, не разбирающемся в тонкостях разработки программ.
Я посмотрел краем глаза на ТЗ. Если:
— число охранников, объектов и постов измеряется десятками (а не тысячами)
— с «программой» будет работать только один человек
то подобную задачу можно решить в Excel. Если постараться, то даже без единого макроса.
Я посмотрел краем глаза на ТЗ. Если:
— число охранников, объектов и постов измеряется десятками (а не тысячами)
— с «программой» будет работать только один человек
то подобную задачу можно решить в Excel. Если постараться, то даже без единого макроса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Почем ныне разработка ПО на заказ?