Как обосновать быстрый (быстрый!) экономический эффект от внедрения СППР в организациях двух типов 1) использующих сппр для внутренних проектов и сопровождения собственными силами 2) системных интеграторов, используюших сппр на внешних проектах. Как вы обосновывали экономическую эффективность СППР и убеждали начать её использовать?
17 comments
Log in to comment
СППР имеет смысл на чем то уникальном и мега масштабном.
И то не ради экономической эффективности, а что бы было можно потом найти концы.
Для масштабов меньше есть куда как более подходящие инструменты.
Когда на разработку на 40 часов надо бумагомараки на 200. Схему нарисуй, все согласуй 100 раз утверди и так далее.
Оно нужно конечно, но таких мест единицы в стране.
ну я даже не знаю что ещё рассказать, оно работало)
Есть процесс, есть по нему дока. Учёт до гвоздя так чтоб уж нужен?
По доке то поиск есть и всегда можно найти в рамках каких задач этот реквизит упоминается.
Отдельной абстракции вынесенной в интерфейс или куда либо еще не было, это было на уровне требования оформления документации.
В принципе я никаких неудобств или каких либо затруднений не заметил, впилился в процесс сразу.
В youtrack - описание задач, в гитлабе можно посмотреть изменения по задаче.
Что-то выходящее за описание - присоединенные файлы.
Проблемы такого подхода - нельзя сделать верификацию задачи, нет удобного стандарта описания.
Если система более менее крупная и проектируется с нуля, то без этого очень тяжело, большой риск возникновения ошибок: не учел вариант использования, в одной функции что-то учтено, в другой нет.
СППР на мой это прежде всего методология проектирования, а не способ организации работы в команде.
И если есть проблемы именно в проектировании и передачей контекста, тогда СППР очень даже основе
Единственное, порог входа очень высок