100 тыс руб это на составление ТЗ?

Да, согласен, требования меняются. Но наверное можно дать какой-то ориентир на основании имеющейся информации. Затем, если условия подходят, то сделать ТЗ с учетом особенностей Оду. Или далее разбить работу по блокам/спринтам, оценивая каждый блок работ. Но вначале должен быть какой-то ориентир по затратам. Для примера: если понимаем, что на php весь проект будет стоить 500 тыс руб, а на Оду 2 млн руб., на 1С -10 млн.руб., то логично выбрать реализацию проекта на php. А не так, что запустили проект, потратили 500 тыс. руб, а потом оказывается еще нужно 5 млн. руб. Суммы совершенно условные.

часто хитро>|<опые заказчики приходят с требованием сделать машину, просят дать оценку, ты даешь, начинаешь делать, а в процессе заказчик тебе накидывает требований типа: вместо руля должен быть штурвал, колеса должны убираться под капот по кнопке, кузов должен быть оптекаемый, разгоняться она должна до 800км\ч за 20секунд, и желательно чтобы с боков, по нажатию кнопки, выезжали крылья с мааааааленькими турбинами, а антикрыло трансформироваться в вертикальный хвост,... Вопрос: какой толк от предварительной оценки стоимости разработки автомобиля? Ответ: Чтобы ты не запросил за доп.требования еще денег. Ведь ты ж сам назвал цену за весь проект! Бюджет уже зафиксирован. "Фикс.прайс" это про то, как заказчику бесплатно получить функционал. Если разраб хочет работать бесплатно - то ему нужно обязательно использовать именно "фикс.прайс". Мораль: фикс.прайс "работает" по честному, только если проект изначально, четко прописан, а доп.требования, возникающие по ходу проекта, реализовываются за отдельные деньги. _________________ Я просто обожаю, когда на этапе сдачи работ, заказик начинает задавать вопросы: - а где юнит, тесты? Какое покрытие юнит-тестами, разработанного функционала? - а где документация? Какая-то документация не понятная. Вы можете добавить картинок, со стрелочками, а лучше записать видео. Сделать обучающий видео-курс ведь вам не сложно? Вам ведь всего-то нужно записать экран с демонстрацией функционала и проговорить голосом что происходит на экране. - что-то интерфейс, какой-то неудобный? Добавьте JS-виджетов и вэбсайт-сниппетов, чтобы уменьшить количество нажатий. - чтобы принять работу, вы должны ее поставить нам на наш odoo-сервер под управлением CentOS, в докере, на гугл-клауде. Ставить нужно через гит. Только у нас собственный гитлаб сервер, со встроенные автотестами, собственными настройками flask8, js-linter, styly-linter, bandit, pylint. Если наши автотесты не пройдут, то работу не примем. И обратите внимание, что мы используем python3.4, тому что мы используем один сложный модуль, разработчик которого его забросил, а он работает только под версией 3.4. - а почему вы сделали в этих справочниках связь m2o? А если нам нужно будет несколько элементов сразу выбрать? Нужно поменять на m2m. ... Фиксированная цена, в таких случаях играет против разраба\внедренца.

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

я сам с таким сталкивался как внедренец систем. поэтому сейчас сторонник следующего подхода: 1. описание бизнес-процессов 2. составление технических требований 3. примерная оценка стоимости на разных платформах/у разных внедренцев 4. выбор платформы/внедренца 5. составление ТЗ совместно с внедренцем с учетом особенностей выбранной платформы. 6. составление программы и методики испытаний/критериев оценки удовлетворения требования 7. уточненная оценка стоимости работ 8. договор 9. разработка/внедрение этапами/спринтами работы, не указанные в ТЗ оцениваются отдельно. а внедренец может подстраховать себя в т.ч. участием в разработке программы приемо-сдаточных испытаний, каких-то критериев оценки результата. Я выступал и со стороны внедренца и со стороны заказчика, понимаю опасения обеих сторон. По примеру. Если я хочу купить авто, то я должен понимать какой суммой нужно обладать чтобы прийти и выехать из автосалона, доехать до другого города, а не так, что сначала оплатил 1 млн, потом выясняется, что еще нужны допы на такую же сумму. Чтобы было честно, думаю, что двигаться нужно по пунктам, указанным выше. Только как всех обезопасить, если в процессе внедрения выяснится необходимость изменения? Думаю, что только правильной совместной разработкой ТЗ (что в случае наличия описанных процессов компании можно сделать)

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

> Только как всех обезопасить Вот! Я об этом и говорю 😊 Именно! Стороны боятся друг друга, и поэтому тратят время и деньги. Но только раньше это еще как-то работало, так как скорость жизни было более медленной, и можно было позволить себе каскадную модель. Сейчас все слишком быстро меняется. ТЗ уже мертво в момент рождения 😋