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