All streams
Search
Write a publication
Pull to refresh
0
0

User

Send message
Мы о разных видах разработки говорим. Я работаю в той отрасли, где старт идёт не от идеи, а от чаще потребности реализовать давно ожидаемый функционал. И там другие темпы, расклады и требования, отсюда и подходы другие.
В крупных компаниях так просто процессы, по крайней мере их канва, не меняются. На грошовых и чепушильных проектиках — только так и бывает.
И где тут повышение маржи с проекта за счёт манипуляции оценкой?
Независимо от того есть ли манипуляция перед заказчиком или нету её, самому исполнителю важно для себя знать реальные затраты времени на проект и его потенциальную себестоимость.
У заказчика есть возможность ограничить манипуляции. Крупный заказчик обычно работает через тендер и может запросить оценку от нескольких исполнителей. Поэтому манипуляция исполнителя с занижением оценки ради контракта чревата работой в убыток, а манипуляция с завышением оценки чревата потерей контракта из-за лучших предложений конкурентов.
С пруфами всё сложно. Внедрение СППР идёт тяжко. Многие понимают, что инструменты типа СППР надо применять. НАДО. Но в большинстве случаев, где СППР используют её валят на разработчиков, а это неправильно (см. отдельную мою статью про это).

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

Information

Rating
Does not participate
Registered
Activity

Specialization

Project Director, Software Architect
Lead
People management
Organization of business processes
Strategic planning
Development of tech specifications
Development management
Building a team
Project planning
Project management
Business process management