Комментарии 22
Краткое содержание статьи: предлагается система которая может а) предсказывать будущее, б) убедить всех в том, что эти предсказания верны.
Примечание. Если реальность расходится с предсказанием, значит вы неправильно используете систему.
— — — Если по делу — очень плохо. Прям как будто реферат незаинтересованного ни в чем студента. Статья состоит даже не из воды, а из общих слов и фраз. Если она касается неких важных моментов которые понимают только специалисты по СППР, то это надо публиковать в каком-нибудь «Вестнике СППРщика». А здесь — все же популярный ресурс.
Как сделать чтоб было хорошо?
...
Я честно вчитывался и пытался написать что-то конструктивное, но упс… увольте/извините. Вопросы возникают просто по каждому предложению, я так просто утону в тексте.
Примечание. Если реальность расходится с предсказанием, значит вы неправильно используете систему.
— — — Если по делу — очень плохо. Прям как будто реферат незаинтересованного ни в чем студента. Статья состоит даже не из воды, а из общих слов и фраз. Если она касается неких важных моментов которые понимают только специалисты по СППР, то это надо публиковать в каком-нибудь «Вестнике СППРщика». А здесь — все же популярный ресурс.
Как сделать чтоб было хорошо?
...
Я честно вчитывался и пытался написать что-то конструктивное, но упс… увольте/извините. Вопросы возникают просто по каждому предложению, я так просто утону в тексте.
не знаю что там 1С СППР, у Макконнела есть хорошая книжка (и даже древняя софтинка) для расчётов по COCOMO (два или не два, не помню). "Сколько стоит программный проект" название вроде.
Идея отучить регрессию на данных по проектам хоть и не нова, но вполне себе имеет право на жизнь. Ревизию старья можно проводить даже автоматизированно, если есть gitlab локальный и (без или) что-то вроде ms project. во всяких галерных интеграторах даже ТЗ все по одному шаблону, можно даже тексты в регрессор подавать.
Беда что проектов часто не так уж и много для надёжной модели. Но для крупных галер можно навести анализ, у них и ОУП под это наверняка есть.
А 1С вообще тут не нужен.
Что-то не спешат интеграторы COCOMO использовать и выводить оценку сроков и стоимости по ней. Хотя инструмент, предложенный в статье, кто превзойти может по простоте и предполагаемой весьма высокой точности…
Ну так, как говорится: «Где пруфы, Билли?».
Нужны примеры — вот была команда которая срывала все сроки. Потом пришел новый менеджер, и сказал — а теперь всё будет по-новому. И внедрил магическую СППР не разогнав команду и не набрав новых сотрудников. И всё заработало и засияло!
По поводу сроков — мне надо сейчас написать программку считывающую данные из виртуального ком-порта (туда воткнут некий прибор, естьописание протокола на бумаге). Я никогда этого не делал раньше, рядом тоже никто не делал. Сколько времени я буду с этим разбираться? Может я прям сейчас используя гугл-стайл-программинг найду нужный кусок кода. А может две недели буду разбираться с протоколом, и т.п… Да это недостаток квалификации — но привлечение специалиста с нужной квалификацией это и время и траты… Как быть?
Нужны примеры — вот была команда которая срывала все сроки. Потом пришел новый менеджер, и сказал — а теперь всё будет по-новому. И внедрил магическую СППР не разогнав команду и не набрав новых сотрудников. И всё заработало и засияло!
По поводу сроков — мне надо сейчас написать программку считывающую данные из виртуального ком-порта (туда воткнут некий прибор, естьописание протокола на бумаге). Я никогда этого не делал раньше, рядом тоже никто не делал. Сколько времени я буду с этим разбираться? Может я прям сейчас используя гугл-стайл-программинг найду нужный кусок кода. А может две недели буду разбираться с протоколом, и т.п… Да это недостаток квалификации — но привлечение специалиста с нужной квалификацией это и время и траты… Как быть?
С пруфами всё сложно. Внедрение СППР идёт тяжко. Многие понимают, что инструменты типа СППР надо применять. НАДО. Но в большинстве случаев, где СППР используют её валят на разработчиков, а это неправильно (см. отдельную мою статью про это).
Использование СППР предполагает, что перед кодингом должно быть выполнено проектирование архитектуры системы, а ещё перед этим описание системы (анализ и фиксация бизнес-процессов и алгоритмов). Т.е. если ваш проект маленький и вам проще сесть и нахрапом (эджайлом) одолеть проблему («завалить врага кодом»), тогда проще обойтись без СППР и дополнительных членов команды. Если же проект крупный, создаёт или развивает систему с длительным жизненным циклом, то хватит уже многократно и однообразно повторившейся ситуации на проектах — ситуационным кодингом многочисленных «талантливых» программистских команд приводить любую систему в нереаботоспособное состояние. Путём победы тактики над стратегией (ща костылей понаставим — будет работать) очень большие деньги зарываются в песок. Денег в стране стало меньше и компании, после многократных бегов по кругу со многочисленными внедренцами, стали искать способы гарантированно продлить жизненный цикл сложных систем с меньшими затратами.
А для этого надо работать по определённой технологии. А СППР — это всего лишь инструмент для реализации такой технологии. Сказанное, повторяю, разумно для крупных проектов. В маленьких — проще кодить и кодить. В конце-концов СППР — проблема не разраба.
Использование СППР предполагает, что перед кодингом должно быть выполнено проектирование архитектуры системы, а ещё перед этим описание системы (анализ и фиксация бизнес-процессов и алгоритмов). Т.е. если ваш проект маленький и вам проще сесть и нахрапом (эджайлом) одолеть проблему («завалить врага кодом»), тогда проще обойтись без СППР и дополнительных членов команды. Если же проект крупный, создаёт или развивает систему с длительным жизненным циклом, то хватит уже многократно и однообразно повторившейся ситуации на проектах — ситуационным кодингом многочисленных «талантливых» программистских команд приводить любую систему в нереаботоспособное состояние. Путём победы тактики над стратегией (ща костылей понаставим — будет работать) очень большие деньги зарываются в песок. Денег в стране стало меньше и компании, после многократных бегов по кругу со многочисленными внедренцами, стали искать способы гарантированно продлить жизненный цикл сложных систем с меньшими затратами.
А для этого надо работать по определённой технологии. А СППР — это всего лишь инструмент для реализации такой технологии. Сказанное, повторяю, разумно для крупных проектов. В маленьких — проще кодить и кодить. В конце-концов СППР — проблема не разраба.
Ау. Релизный цикл 2 недели.
Вся эта фиксация алгоритмов уже давно на помойке истории. Никому не нужны зафиксированные на год бизнес-процессы и алгоритмы. Через год уже все 3 раза поменяется.
Вся эта фиксация алгоритмов уже давно на помойке истории. Никому не нужны зафиксированные на год бизнес-процессы и алгоритмы. Через год уже все 3 раза поменяется.
В крупных компаниях так просто процессы, по крайней мере их канва, не меняются. На грошовых и чепушильных проектиках — только так и бывает.
Канва нет. Канва — хотим заработать денег.
А вот все остальное меняется только так. Жизнь сейчас такая.
Средний цикл разрабтк чего-то нового примерно такой (исследовальские проекты не трогаем, берем что-то типовое):
И в какое месте вот это вот фиксирование алгоритмов вставить? И докуда оно доживет? Полгода это я взял с запасом, когда что-то действительно большое делается. Желательно на пользователях проверить пораньше.
А вот все остальное меняется только так. Жизнь сейчас такая.
Средний цикл разрабтк чего-то нового примерно такой (исследовальские проекты не трогаем, берем что-то типовое):
- Есть клевая идея, ресурсы на разработку выделены
- До полугода делается нулевая версия. Альфа какая-нибудь. Быстрее — лучше
- На живых пользователях проверяются что идея действительно клевая и может принести деньги
- До полугода эта альфа переделывается в нормальную версию. Быстрее опять же лучше. По итогам проверки на живых пользователях изменения нужны будут всегда
- Переходим на 2 недельный релизный цикл. Пилим фичи, правим баги
И в какое месте вот это вот фиксирование алгоритмов вставить? И докуда оно доживет? Полгода это я взял с запасом, когда что-то действительно большое делается. Желательно на пользователях проверить пораньше.
Мы о разных видах разработки говорим. Я работаю в той отрасли, где старт идёт не от идеи, а от чаще потребности реализовать давно ожидаемый функционал. И там другие темпы, расклады и требования, отсюда и подходы другие.
Звучит как добавить фичу в продакшен. Ну или множество связанных фич.
Это давно решено. Релизим под флагом, включаем для тестировщиков, потом для выбранных клиентов, потом для 1%, потом для всех.
Никаких разработок на год, с фиксированием алгоритмов (до сих пор не понимаю как в таком случае баги править). Все декомпозируем и релизим минимальными кусочками. Раз в две недели, с откатом по кнопке если что-то пошло не так. Заодно шанс разломать все без обратной совместимости понижается.
Это давно решено. Релизим под флагом, включаем для тестировщиков, потом для выбранных клиентов, потом для 1%, потом для всех.
Никаких разработок на год, с фиксированием алгоритмов (до сих пор не понимаю как в таком случае баги править). Все декомпозируем и релизим минимальными кусочками. Раз в две недели, с откатом по кнопке если что-то пошло не так. Заодно шанс разломать все без обратной совместимости понижается.
Не меняются процессы в крупных компаниях? Ну-ну. Как-то в крупной компании разослали предложение по отделам составить план своей деятельности, расходов и доходов на один год. Надо ли говорить, что уже через 3 месяца многие отделы превысили план по расходам? Но чудо-экономисты там все же продолжают страдать этой фигней каждый год недели за две перед новым годом.
Ваш пример говорит лишь о том, что в данной компании не умеют планировать. Но процесс планирования у них есть. И изменились у них цифры — результат процесса планирования. Но ничего не говорит, что сам процесс изменился. Вобщем путаете процесс и результат процесса.
Вобще-то меняются. Крупный бизнес хоть и более медленный, но меняется. Вот пример, умер региональный дистрибьютор и в результате дележа территории бизнес получил крупный контракт. Бизнес перестраивает свои процессы и ЭДО под изменившиеся условия, т. к. поставщик сказал что взаимодейтвовать нужно именно так. Получила Россия Крым и бизнес получил возможность работать там, но не совсем вбелую, чтобы не злить Запад вот еще один замысловатый процесс нарисовался. Случился крупный пожар и сгорел основной склад и бизнесу пришлось арендовать склады в разных местах и перестраивать логистику под все это. Ну и процессы следом. Выпустило государство новый закон…
И вы утверждаете, что все эти процессы автоматизировались без всякого описания, а сразу в код?
Сначала автоматизировались потом описывались, но описание как всегда осталось далеко от реального положения дел.
НЛО прилетело и опубликовало эту надпись здесь
Захотел как-то очень крупный заказчик сделать прозрачной процедуру оценки проектов в рамках своей большой программы. И выбрал он CocomoII. Проговорили, прописали и протестировали все параметры и метрики с поставщиком решений. Готовились к переходу около полугода. В итоге получили результат, устраивающий всех — заказчик начал думать, что понимает, как оцениваются его проекты, исполнитель повысил маржу. Очевидно же, что почти любой системой оценки можно манипулировать.
И где тут повышение маржи с проекта за счёт манипуляции оценкой?
Независимо от того есть ли манипуляция перед заказчиком или нету её, самому исполнителю важно для себя знать реальные затраты времени на проект и его потенциальную себестоимость.
У заказчика есть возможность ограничить манипуляции. Крупный заказчик обычно работает через тендер и может запросить оценку от нескольких исполнителей. Поэтому манипуляция исполнителя с занижением оценки ради контракта чревата работой в убыток, а манипуляция с завышением оценки чревата потерей контракта из-за лучших предложений конкурентов.
Независимо от того есть ли манипуляция перед заказчиком или нету её, самому исполнителю важно для себя знать реальные затраты времени на проект и его потенциальную себестоимость.
У заказчика есть возможность ограничить манипуляции. Крупный заказчик обычно работает через тендер и может запросить оценку от нескольких исполнителей. Поэтому манипуляция исполнителя с занижением оценки ради контракта чревата работой в убыток, а манипуляция с завышением оценки чревата потерей контракта из-за лучших предложений конкурентов.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
1С СППР и оценка сроков и стоимости проектов методом COCOMO II