Кроличья нора автоматизации бизнес-процессов

[ChePeter]

Первым и обязательным шагом любой попытки применения автоматизации должна являться формализация процесса, который хотите автоматизировать.

Без этого шага начинается лирика и беллетристка на основе софтскилл. И классические душевные метания "что делать?" и "кто виноват?"

[m1v1ks]

Да, пожалуй, самая распространённая проблема из всех, это попытка автоматизации хаоса.

[avf48]

Если к Аджайлу добавить Формализацию процессов, то это уже ГОСТ какой-то получается)))

ГОСТ Р 56715.2-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель

ГОСТ Р 56716-2015 Проектный менеджмент. Техника сетевого планирования. Общие положения и терминология
ГОСТ Р 56715.5-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения
ГОСТ Р 56715.4-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 4. Данные и модель данных
ГОСТ Р 56715.3-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 3. Методы
ГОСТ Р 56715.2-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель
ГОСТ Р 56715.1-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения
ГОСТ Р МЭК 62198-2015 Проектный менеджмент. Руководство по применению менеджмента риска при проектировании
ГОСТ Р МЭК 61160-2015 Проектный менеджмент. Документальный анализ проекта
ГОСТ Р ИСО MEK_TO_16326-2002 РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ГОСТ Р ИСОМЭК 12207 ПРИ УПРАВЛЕНИИ ПРОЕКТОМ
ГОСТ Р ИСО 21500-2014 "Руководство по проектному менеджменту";
ГОСТ Р 54869-2011 "Проектный менеджмент. Требования к управлению проектом";
ГОСТ Р 54871-2011 "Проектный менеджмент. Требования к управлению программой";
ГОСТ Р 54870-2011 "Проектный менеджмент. Требования к управлению портфелем проектов".

[ChePeter]

Можно конечно и формализм довести до абсурда, но без формализма ничего не получится.

Предметная область должна быть изложена формально именно теми, кто в ней понимает. Иначе этот формализм проведут программисты в силу своих религий и тогда

"Беда, коль пироги начнет печи сапожник, а сапоги тачать пирожник"

Если аджайл вот так прям приглянулся, то всё равно - формализацию должен регулярно корректировать понимающий и без этого будет бардак.

[itwarwar]

да, уж не ожидал от Ланита столько воды, как будто статью из студопедии прочитал

[SatoVandal]

Вот тут соглашусь. Куча воды.
"Виды ERP, ECM и прочих систем мы расписывать не будем"
"Зато в деталях распишем методологии разработки ПО!"
¯\_(ツ)_/¯

[itwarwar]

Еще и 17 плюсов у статьи...
Статью стажер писал скорее всего, а плюсовали waterlovers или такие же стажеры после конфы LDM.DAY 2023, чтобы приз заработать.

[MilPavel]

И главное - разработчик должен иметь профильное образование, что бы понимать нюансы отрасли, коих огромное количество. Заказчик не сможет все описать в ТЗ/БТ.

[m1v1ks]

Это скорее задача аналитика раскопать все нюансы отрасли и задать заказчику правильные наводящие вопросы. А после того, как он в этом разберется, написать ТЗ разработчику так, чтобы разработчик мог выполнить задачу не имея профильного образования в отрасли. Всё-таки сфера ответственности разработчика это код, ему не обязательно знать бизнесовые нюансы отрасли.

Другой вопрос, конечно, когда проект маленький, и разработчик на проекте и чтец и жнец и на дуде игрец, но тут уже вопрос из другой плоскости.

[MilPavel]

Разработчик должен разбираться в предметной области. Аналитик не сможет все описать - слишком много нюансов.

[rombs]

При таком подходе очень сложно будет масштабировать команду разработки.

Поэтому как раз аналитики разбираются в предметной области, а разработчики пишут "идеальный код"

[uskovak]

О, да! Все это нужно рассказать внедрятелям САПа. Наверно много нового узнают.