Вы знаете, а ведь я с вами согласен. Я вот считаю что в стране недооценены инженеры, высококвалифицирвоанные рабочие, толковые военные и много других специальностей. Но, политику поддержки населения и работников определяю не я. Могу только руками развести.
Вы столько усилий потратили на фичу, без которой можно было бы обойтись. Она полезная, приятная, более удобная в обслуживании. Но прибавку доходности бизнесу она не даёт. А у IBS есть потенциально более выгодные точки приложения для внутренних проектов развития… Например, перестроить внутреннюю базу управления проектами так, чтобы она могла более точно рассчитывать прогнозируемые сроки исполнения проектов для заказчиков.
Вот и интересно как те кто описывал процессы их описывал и на каком инструменте фиксировал. СППР помогла бы зафиксировать и выявить слабость методологов и аналитиков на проекте и провести работу над ошибками, если конечно заказчик поганой метлой не вынес уже такую команду.
Ваш пример говорит лишь о том, что в данной компании не умеют планировать. Но процесс планирования у них есть. И изменились у них цифры — результат процесса планирования. Но ничего не говорит, что сам процесс изменился. Вобщем путаете процесс и результат процесса.
Мы о разных видах разработки говорим. Я работаю в той отрасли, где старт идёт не от идеи, а от чаще потребности реализовать давно ожидаемый функционал. И там другие темпы, расклады и требования, отсюда и подходы другие.
И где тут повышение маржи с проекта за счёт манипуляции оценкой?
Независимо от того есть ли манипуляция перед заказчиком или нету её, самому исполнителю важно для себя знать реальные затраты времени на проект и его потенциальную себестоимость.
У заказчика есть возможность ограничить манипуляции. Крупный заказчик обычно работает через тендер и может запросить оценку от нескольких исполнителей. Поэтому манипуляция исполнителя с занижением оценки ради контракта чревата работой в убыток, а манипуляция с завышением оценки чревата потерей контракта из-за лучших предложений конкурентов.
С пруфами всё сложно. Внедрение СППР идёт тяжко. Многие понимают, что инструменты типа СППР надо применять. НАДО. Но в большинстве случаев, где СППР используют её валят на разработчиков, а это неправильно (см. отдельную мою статью про это).
Использование СППР предполагает, что перед кодингом должно быть выполнено проектирование архитектуры системы, а ещё перед этим описание системы (анализ и фиксация бизнес-процессов и алгоритмов). Т.е. если ваш проект маленький и вам проще сесть и нахрапом (эджайлом) одолеть проблему («завалить врага кодом»), тогда проще обойтись без СППР и дополнительных членов команды. Если же проект крупный, создаёт или развивает систему с длительным жизненным циклом, то хватит уже многократно и однообразно повторившейся ситуации на проектах — ситуационным кодингом многочисленных «талантливых» программистских команд приводить любую систему в нереаботоспособное состояние. Путём победы тактики над стратегией (ща костылей понаставим — будет работать) очень большие деньги зарываются в песок. Денег в стране стало меньше и компании, после многократных бегов по кругу со многочисленными внедренцами, стали искать способы гарантированно продлить жизненный цикл сложных систем с меньшими затратами.
А для этого надо работать по определённой технологии. А СППР — это всего лишь инструмент для реализации такой технологии. Сказанное, повторяю, разумно для крупных проектов. В маленьких — проще кодить и кодить. В конце-концов СППР — проблема не разраба.
Что-то не спешат интеграторы COCOMO использовать и выводить оценку сроков и стоимости по ней. Хотя инструмент, предложенный в статье, кто превзойти может по простоте и предполагаемой весьма высокой точности…
За то как использует СППР сама 1С мы не в ответе. Но и большие проекты автоматизации уже нельзя делать в эксельчиках, а надо на надлежащем инструменте. Кроме 1С СППР ничего и толком то нет. Поэтому со всеми своими грехами и недоделками — он лучший на сегодня.
Телеграмм канал для оперативного общения по теме 1С СППР (Система Проектирования Прикладных Решений) для системных архитекторов, руководителей проектов, аналитиков, методологов, разработчиков, программистов 1С t.me/SPPR1c
Есть. Но вы точно уверены, что стоит так делать? На втором заводе «продукция-полуфабрикат» подвергается доработке. Выходит серьёно меняются её физические/потребительские свойства, неужели это не стоит отдельной номенклатурной карточки.
Вы знаете, а ведь я с вами согласен. Я вот считаю что в стране недооценены инженеры, высококвалифицирвоанные рабочие, толковые военные и много других специальностей. Но, политику поддержки населения и работников определяю не я. Могу только руками развести.
Вы столько усилий потратили на фичу, без которой можно было бы обойтись. Она полезная, приятная, более удобная в обслуживании. Но прибавку доходности бизнесу она не даёт. А у IBS есть потенциально более выгодные точки приложения для внутренних проектов развития… Например, перестроить внутреннюю базу управления проектами так, чтобы она могла более точно рассчитывать прогнозируемые сроки исполнения проектов для заказчиков.
Независимо от того есть ли манипуляция перед заказчиком или нету её, самому исполнителю важно для себя знать реальные затраты времени на проект и его потенциальную себестоимость.
У заказчика есть возможность ограничить манипуляции. Крупный заказчик обычно работает через тендер и может запросить оценку от нескольких исполнителей. Поэтому манипуляция исполнителя с занижением оценки ради контракта чревата работой в убыток, а манипуляция с завышением оценки чревата потерей контракта из-за лучших предложений конкурентов.
Использование СППР предполагает, что перед кодингом должно быть выполнено проектирование архитектуры системы, а ещё перед этим описание системы (анализ и фиксация бизнес-процессов и алгоритмов). Т.е. если ваш проект маленький и вам проще сесть и нахрапом (эджайлом) одолеть проблему («завалить врага кодом»), тогда проще обойтись без СППР и дополнительных членов команды. Если же проект крупный, создаёт или развивает систему с длительным жизненным циклом, то хватит уже многократно и однообразно повторившейся ситуации на проектах — ситуационным кодингом многочисленных «талантливых» программистских команд приводить любую систему в нереаботоспособное состояние. Путём победы тактики над стратегией (ща костылей понаставим — будет работать) очень большие деньги зарываются в песок. Денег в стране стало меньше и компании, после многократных бегов по кругу со многочисленными внедренцами, стали искать способы гарантированно продлить жизненный цикл сложных систем с меньшими затратами.
А для этого надо работать по определённой технологии. А СППР — это всего лишь инструмент для реализации такой технологии. Сказанное, повторяю, разумно для крупных проектов. В маленьких — проще кодить и кодить. В конце-концов СППР — проблема не разраба.
t.me/SPPR1c