оригінал був опублікований 2021.08.23
З особистого спілкування:
Антон, добрий день!
Перепрошую, що відволікаю Вас, хотілося б проконсультуватися з Вами як з досвідченим інженером в галузі моделювання.
На даний момент займаюся моделюванням.
Зорієнтуйте, будь ласка, скільки грошей коштує ця робота та остаточні результати?
Anton Vasiliev:
Два варіанти: якщо робота виконана (і треба зрозуміти скільки за неї взяти), та як оцінити роботу (за яку тільки плануєте взятися, а може за результатом і не візьметесь)
1. Якщо ви вже виконали роботу
Просто прикиньте скільки ви витратили часу на неї. і прикиньте вартість вашої години (зарплата за місяць/170, якщо грубо), а вже від цього танцюйте.
“Танцювати” ж від того скільки можна “зрубати” із замовника – вважаю некоректним і недоцільним. Це може бути вигідно в короткій перспективі… але на довгій дистанції результат дає не той, якого часто очікуєш. ІМХО.
Також слід пам’ятати про те, чи це додаткове завдання яке Вам особисто нічого не коштувало і йшло в паралель з основним, чи це основний спосіб заробітку. Бо якщо це другий варіант, то по перше треба оцінити не тільки скільки часу зайняв цей проект, але і те наскільки часто бувають проекти. Тобто якщо в Вас, наприклад, лише три проекти на рік, кожен довжиною в один місяць… то вони повинні годувати Вас весь рік, а не тільки три місяці. І Тут або підіймати ціну, або збільшувати кількість проекту.
По друге, якщо це основний заробіток, то не можна оцінювати тільки після виконання. Потрібно планувати ціну наперед. Наприкінці її можна (а іноді і треба) зкоригувати в меньшу сторону, якщо ціна була з запасом. В більшу сторону можна коригувати тільки якщо була попередня домовленість з замовником. І про це його треба повідомити при перших ознаках такої можливості/потреби. Тож переходимо до планування.

2. Якщо бажаєте оцінити роботу, що тільки очікується.
2.1 Частина перша. Основи
стандартний спосіб оцінки вартості це (для задач з обчислювальної механіки, гідродинаміки, тощо):
“базова вартість за годину”*”коефіцієнт складності самої задачі”*”к-т терміновості”…
але, зазвичай, фінальна ціна повинна бути не більше х2 від базової вартості за підсумком.
і далі помножуєте ціну на кількість годин, що потрібні, щоб все зробити.
Іноді на великих проектах, окремі етапи, наприклад, оформлення звіту, і час розрахунку (якщо він довгий і в цей час не виконується інших робіт) йде за меншою ставкою.
“Базова ставка” (для задач механіки) це лінійна статика без складних контактів.
Загальну тривалість я, зазвичай, прикидаю (розраховую в першому наближенні) наступним чином – дивлюся за скільки часу можна зробити один-два розрахунки такої конструкції в лінійній статиці,
або, якщо задача значно складніша, вирішую щось наближене до необхідної задачі з динаміки/нелінійки, але без контролю за точністю тощо.
А далі 1 година перетворюється приблизно 1 робочий день. (Це для моїх задач, для Ваших це може бути по іншому)
Попередня фраза виглядає як спроба розтягнути проект і зрубати бабла на пустомі місці, але це тільки якщо не в темі.
Від мене, та моїх колег, частіш за все, хочуть отримати не кольорові картинки, які потім нікуди не підуть, а результати які потім можна будьде використовувати. В тому числі в суді, в страхових товариствах, верифікаційних товариствах, тощо. І тут потрубно не просто отримати швиденько картинки, а зробити все правильно, все проконтрольювати, а іноді ще й не тільки зробити але й довести що все вірно. Наприкінці треба зробити повноцінний звіт де буде відображено все, що було зроблено.
Тож швидка робота потрібна тільки для розуміння скільки це займе часу при нормальній роботі з повним контролем за якістю. Бо, коли потім робитимеш все правильно, і стежити за сіткою, перезадавати вручну контакти, налаштування і інше – воно десь так час і з’їсть.
Причому це вірно для невеликих проектів із відносно невеликою кількістю об’єктів.

Якщо ж деталей занадто багато…. то треба розуміти, що від кількості об’єктів у збірці, які потрібні для розрахунку залежить час на контроль усіх контактів та ін.

Крім того, слід розуміти, що нелінійні розрахунки, динаміка вимагають часу на порядки більше, ніж лінійна статика. Навіть чисто комп’ютерного часу на розрахунок.
тобто.
якщо лінійний розрахунок, наприклад, “йде” не більше 5 хвилин (за тривалістю всього розрахунку) – то динаміка чи нелінійний розрахунок – це вже 2-10 годин лише для розрахунку (бо там будуть сотні та тисячі кроків по 5 хвилин)
відповідно змінюється час очікування, а також потрібно більше часу на вичитування результатів, анімацію, їх аналіз.
Ну а крім того, загалом, – змінюється ціна помилки (у тому числі і своєї)

Частина 2. розрахунок, Розрахунок, дослідження, проектування
Ми (наш колектив) не займаємося суто розрахунками. Ми займаємося перевіркою, вирішенням проблем і підписуємося під результатами 😉
А це, повірте, не завжди одне й те саме (мова про “розрахунок” та “підпис”).
Чим відрізняються пункти, думаю, буде зрозуміло з назви та опису. Тож поговоримо про етапи.
Почнемо з проектування
якщо крім розрахунків потрібно займатися проектуванням (не важливо Вам, чи замовнику) то потрібно врахувати, що ітерацій (великих) буде мінімум 3-5. а всякої дрібниці – 20-100, які вкладуться в ті 3-5
і якщо вам треба від замовника отримувати дані, їх треба постійно чекати, узгоджувати та ін.
А значить потрібні паузи на очікування реакції від кількох годин до кількох днів.
А це впливає на тривалість проекту. Впливає на те, чи можна буде паралельно щось інше робити, чи затягнеться проект понад обговореного, тощо… Це, за підсумком, впливає як на рівень заробітку так і на реальну вартість проекту. А, як результат, і на підсумкову вартість Вашої години в середньому за рік. Також все це впливає і на Вашу репутацію та можливі проблеми з іншими проектами, замовниками та ін.
Це все залежить не тільки від Вас, але й від замовника та низки інших факторів (але для Вас це буде бити по Вашому заробітку, часу та репутації).
В ідеалі, роботу бажано робити так, щоб поки замовник думає – можна було робити щось так, що потрібно для проекту, що можна робити без реакції замовника і від чого проект не постраждає… Проте це дозволить заощадити загальну тривалість проекту. Мова тут не про паралельні проекти, а про роботу по даному проекту – якісь дрібні дослідження та перевірки. Роботу, яку можна виконувати навіть якщо немає інформації.
Короткі приклади: поки затверджуються дані за матеріалами, навантаженням, – будуємо сітку. Поки надсилається геометрія, на схожому об’єкті відпрацьовуємо методику розрахунку, чи шукаємо стандарти та ін.
Якщо треба розписати докладніше – пишіть, спробую розписати). А поки – якось так.
Решта буде зрозуміла з розгляду “результатів”
Що є остаточним результатом – залежить від постановки початкового завдання та цілей.
як приклад, завдання (обрати один з “шляхів”):
- є конструкція, є стандарт, наприклад на розрахунок чи проведення експерименту, – треба повторити
- є конструкція. є стандарт. але в стандарті швидше добрі побажання
- стандарту немає…
- фіг з ним зі стандартом, ніхто і близько сказати не може як воно працює
цілі:
- прикинути можливість (виконання розрахунку, можливість зміцнення та ін.)
- виконати розрахунок
- перевірити працездатність
- перевірити працездатність та видати рекомендації
- зробити працездатну конструкцію (тобто: виконати купу розрахунків, перевірити працездатність декількох ітерацій проекту, обговорити з замовником шляхи покращення та довести конструкцію до робочого варіанту)
- зробити працездатну з урахуванням купи факторів (тобто пункт 5+ замовник буде крутити носом і видавати вимоги, що протирічать один з одним… купу таких вимог)
- Виконати оптимізацію (“європейську”/”совЕтську” якщо цікаво чим відрізняються – пишіть коментарі та лайкайте. Наберемо два десятки коментарів/лайків – розпишу)
Anton Vasiliev, [20.08.21 15:14]
Тепер приклади “проектів” (тобто суміщення двох списків) трохи докладніше:
- 1. робимо все за стандартом і радіємо. Якщо стандарт не передбачає СЕ розрахунків. адаптуємо та погоджуємо умови під розрахунок іноді робимо кілька тестових розрахунків, щоб обрати раціональні підходи після – вибрали підходи і все згідно зі списком зі стандарту

- 2. якщо немає точного стандарту з конкретними вимогами – отже треба передбачити варіанти розвитку подій, межі допустимої поведінки, навантажень.
погодити це із замовником
погодити список розрахунків – виконати їх.
оцінювати у комплексі всі результати.

Наприклад замовник попросив виконати “дроп тест” (скинути щось з певної висоти) івважає, що для оцінки працезданості достатньо всього одного розрахунку.
- 3. ну як би все те саме що в 2, але кількість розрахунків, аналізу та узгоджень збільшується в рази. (Бо, при оцінці “дроптеста” – страшнішим може бути не прямий удар з великої висоти, а удар під кутом, коли все навантаження не “плашмя”, а на кут. І навіть менша висота не врятує. і це Ваша задача довести це замовнику.)
- від 3 – відрізняється тим самим чим 3 відрізняється від 2
тобто ще більше роботи, ще довше за узгодження (якщо воно може падати різними сторонами, якщо конструкція не працездатна за ітогом перевірок…)

за цілями, думаю пояснювати не треба – там очевидно, що робота зростає від пункту до пункту.
VT: ну так, у цьому начебто зрозуміло, все логічно)
Anton Vasiliev: єдине, що в цілях та завданнях не написано – це розробка методики проектування/перевірки (є такий тип завдання, коли в результаті всі розрахунки будете робити не Ви, а сам замовник)
Така ціль не написана через те, що, по-перше, вона набагато об’ємніша, ніж все перераховане раніше за обсягом (по суті треба зробити “свій” “стандарт”)
а ще …. Ще проблема в тому, що іноді треба не просто навчити замовника вирішувати завдання. А вбудувати це у процес проектування. І це означає, що окрім “просто” “методів розрахунку” треба знайти спрощені методи розрахунку та межі їх застосування
Бо ніхто не буде вбудовувати “розрахунок на дві доби” у процес проектування!
Розрахунок повинен тривати (бажано з аналізом) не більше півгодини (а краще меньше за хвилину)
Тому, спочатку відпрацьовуємо повний розрахунок… потім починаємо розробляти спрощені методики, і визначати межі в яких вони дають норм результат, а в яких – ні
VT: я думав робота зі спрощення паде на плечі конструктора.
Anton Vasiliev: та якби! (тобто, та фіг там)
це повинен робити той, хто розуміє, що робить…
без конструктора тут не обійтися – бо йому (в кінці кінців) це робити. але…
тож, якось так. В результаті, наприклад, складний динамічний розрахунок може бути замінений на статичний з силою х2, х3
так такі розрахунки не є точними. зате швидкі!
І лише наприкінці, – робимо одну велику перевірку на п’ять дво-годинних розрахунків… і радіємо життю 🙂
або переробляємо : (
що теж може бути
Через це для себе, особливо з розрахунками, з якими ми раніше не стикалися, – ми робимо не тільки те, що просить замовник, але ще певну роботу “навколо”
Наприклад, змінюємо деякі параметри і дивимося, що саме впливає і на що.
Зазвичай така робота не йде в залік часу та вартості. Це йде для розуміння і для того, щоб уникнути помилок.
Якщо, це виявилося непотрібним (тобто не показало навності можливих проблем) – це досвід. Якщо дає важливі результати, що впливають на проект – показуємо замовнику.
Замовник, якщо він адекватний, і ти йому показуєш те, що впливає на його конструкцію, зазвичай, тільки радий, навіть якщо при цьому він не просив за такі перевірки
І, в подальшому, при виборі заплатити менше комусь хто робить тільки те, що потрібно, або більше, але людині, яка точно перевірить все, що може вплинути – обирає друге.
А якщо неадекват – ну… теж дзвіночок. Це просто говорить про те, що від нього рано чи пізно прилетить таке, що потім не видихнеш, і скільки б це не коштувало – краще з ним справ не мати
Іноді все одно доводиться. Але краще не мати справ – дешевше, за підсумком, собі вийде.
За кадром залишилося питання, як це оформлювати (і в сенсі контрактів і в сенсі звітів). Але це тема для наступних “лонгрідів”. Тож, пишіть якщо комусь цікаво.
Також хотілося б дізнатися, що думаєте про написане, і які Ви використовуєте підходи для визначення вартості, фронту робіт.

Одна відповідь до “Як визначати вартість та тривалість розрахункових проектів”
CAE Розрахунки. Ціна питання — Очередной Блог О САПР