46
ПО Аналитика / Re: Помогите с выбором инструмента для описания БП
« : 27 Августа 2013, 13:56:15 »
3SL Cradle оказался дороговат для моего случая. Буду пились в ЕА пока.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
47
ПО Аналитика / Re: Помогите с выбором инструмента для описания БП
« : 26 Августа 2013, 17:40:58 »
попробую разные средства, и потом опишусь сюда что вышло.
48
ПО Аналитика / Re: Помогите с выбором инструмента для описания БП
« : 26 Августа 2013, 17:19:52 »Всё это можно сделать и в Excel – имитировать swimlane, раскрасить цветами, повесить тэги, сделать реестр проблем со ссылками на них из процесса – voila!
Да, но это же я могу сделать и в ЕА и делать выборки в бд для анализа.
Но ЕА немного тяжеловат и поэтому я спрашиваю что ещё есть.
49
ПО Аналитика / Re: Помогите с выбором инструмента для описания БП
« : 26 Августа 2013, 16:58:10 »Антон, а у вас уже бы опыт, когда описание процесса помогло верно оценить потенциал для оптимизации?
Как описание процессов помогает вам «увидеть реальные проблемы»?
Очень правильные вопросы вы мне задали. Пока я писал ответ, понял что ошибся в формулировке изначального поста.
Моя фраза "Я связываю это с тем, что мы изучаем БП, не в том масштабе, в котором нужно." не совсем верна или я под "масштабом" имел ввиду немного другое. Я попробую пояснить почему.
Рецепт правильной оценки реквестов действительно не в составлении описания всем БП.
Расскажу текущую ситуацию, только слово "реквест" заменю на слово "проблема".
Итак, мне дано:
1. Тонны проблем. О проблемах мне сигнализируют от всех компаний из всех отделов 24/7.
2. Метрики известных проблем в большинстве случаев заранее не сняты. Тонны проблем мне вообще не известны.
3. Проблема сидит на каком-либо БП, но роль этого БП для бизнеса мне заранее не известна. Представители бизнеса частенько эту роль преувеличивают, поэтому я не могу им 100% доверять. Всё приходится проверять.
4. Маленькая команда для решения проблем. Мне одним выстрелом нужно красиво завалить как можно больше сидящих рядом зайцев. Чем эффективнее моя команда стреляет, тем больше шансов, что мне её расширят и у меня появится больше ресурсов.
5. Отсутствует единая система хранения данных о проблемах и БП, поэтому я не могу проводить полноценный анализ.
Как я выбираю, какую проблему решать следующей?
1. Стараюсь понять для всех проблем на каком БП они сидят и какая роль у этих БП для бизнеса.
Это как раз пункт, который дает ошибки в оценке. Даже если я знаю, что для отдела "А" я могу высвободить 3 человеко-часа/день за 80 часов работы конамады, а для отдела
"Б" 1 человеко-час за 90 часов работы команды, то это не всегда значит, что для успешности бизнеса нужно делать автоматизацию для отдела "А".
Т.е. я хочу сказать, что для правильной оценки одних метрик проблем недостаточно.
2. Снимаю метрики со всех известных проблемы в реальных цифрах, если это можно сделать вообще.
3. Найти решение, в котором можно было бы хранить и анаизировать все данные.
4. Пытаюсь найти смежные проблемы и попробовать убить побольше зайцев за один выстрел, ну или чтобы не плодить сущности.
5. Выбираю лучшую проблему ( выгода от решения/ затраты на решение), которая сидит на самом важном для бизнеса БП и пытаюсь её решить.
Таким образом я отвечу на ваши вопросы:
1. "Как описание процесса помогло верно оценить потенциал для оптимизации ?" // тут я немного перефразировал
Голое описание БП не помогает в этом. В этом помогает осознание значения БП для бизнеса. Т.е. я должен знать каждый БП и понимать их значение до такой степени чтобы мог дать сортировку БП от наиболее важных к наименее важным для бизнеса. Это косвенно видно из диаграмм. В любом случае, оценивая БП, его описание не будет лишним.
Когда я говорил "мы изучаем БП, не в том масштабе, в котором нужно", я имел ввиду, чтобы мне нужно понимание роли БП для бизнеса в купе с четко снятыми метриками проблемы, чтобы не делать ошибок в выборе лучших проблем для решения. Роль описания тут второстепенна.
2. "Как описание процессов помогает вам «увидеть реальные проблемы»?"
Проблема реальная, если с неё можно снять реальные метрики и решение этой проблемы принесет реальную просчитываемую выгоду. Если с проблемы сложно снять метрики или просчитать выгоду, лучше отложить её, до тех пор пока не появится достаточно знаний в предметной области чтобы просчитать выгоду.
Наиболее реальные проблемы сидят на важнейших для бизнеса БП. Ваша правда, что описание процессов тут не помогает никак
В чем мне помогают описания БП сами по себе ?
Удобно осмыслить как построить сценарии GUI.
Был случай, когда описание БП дало понимание что метрики с проблемы сняты неверно. (Увидел что БП имеет сезонность, а выгода от решения была просчитана как если бы БП работал круглый год), тогда не стали писать решение для этой проблемы.
При изучении проблемы и сборе информации/требований, я смотрю на диаграммы БП, чтобы подумать в какие отделы зайти и на всякий случай спросить нет ли у них смежных проблем. Ну и вообще, изучение БП это как своеобразный этап подготовки перед интервью.
Помогают сформировать архитектуру решения с заделом на группу сидящих рядом зайцев.
Немного сумбурно и нагружено получилось и может я вообще гоню
50
ПО Аналитика / Помогите с выбором инструмента для описания БП
« : 20 Августа 2013, 14:04:55 »
Добрый день, уважаемые.
Сейчас я отыгрываю роль системного аналитика + ui дизайнера в команде разработчиков. Мы внутри холдинга(=группа компаний).
Есть необходимость поднять описание бизнес-процессов (далее БП), с последующим их анализом(выявление проблемных мест), изменением.
Мне нужно описывать как процессы внутри компаний, так и их взаимоотношения между компаниями внутри холдинга.
Зачем мне это нужно ?
Схема нашей работы сейчас след.:
К нам приходят бизнес, и просит: "Помогите нам автоматизировать то и то, помогите улучшить то и то, сделайте нам то и то."
Такое обращение мы называем "реквестом".
Мы оцениваем такой реквест, насколько он реален и какую пользу принесен (например в высвобожденных человеко-часах или других реальных единицах) и решаем брать в разработку или нет.
Стараемся брать лучшие реквесты из общей массы.
Реквест "лучше", если за меньшее количество ресурсов команды сможем высвободить большее количество Человеко-часов для какого-нибудь договорного отдела.
Всё же, мы ошибаемся в оценке реквестов, и берем не лучшие. А я хочу быть более эффективным и брать лучшие.
Я связываю это с тем, что мы изучаем БП, не в том масштабе, в котором нужно.
Хочу описывать БП для того, чтобы видеть в нужном масштабе. Кроме того, ряд реальных проблем мы просто не видим, потому что бизнес не догадается к нам обратиться с этим.
Что мне нужно от инструмента для описания БП:
- нужно видеть БП в виде диаграммы (всё равно какая нотация)
- нужно чтобы один процесс имел 2 варианта: текущий и исправленный.
- нужно, чтобы в процессе было обозначено узкое место, т.е. проблема.
- нужно чтобы я мог видеть какие БП в какой организации происходят
- нужно видеть БП между организациями с обозначением проблем в них, а ещё лучше чтобы было видно на стороне какой организации проблема в этом БП.
- желательно, чтобы проблемы имели теги, чтобы по ним можно было потом дергать БП со схожими проблемами.
- желательно, чтобы проблема была самостоятельной сущностью и имела поля, в которые я мог бы записывать разные стандартные данные.
Я работаю в ЕА над проектами по разработке смогу организовать всё что описал выше этим инструментом, однако мне интересно посмотреть, может есть что-нибудь специально для моего случая ?
Скорее всего видно, что я в этой теме плаваю, поэтому прошу помочь ссылками на правильные книги или советом.
С уважением, Морозов Антон.
Сейчас я отыгрываю роль системного аналитика + ui дизайнера в команде разработчиков. Мы внутри холдинга(=группа компаний).
Есть необходимость поднять описание бизнес-процессов (далее БП), с последующим их анализом(выявление проблемных мест), изменением.
Мне нужно описывать как процессы внутри компаний, так и их взаимоотношения между компаниями внутри холдинга.
Зачем мне это нужно ?
Схема нашей работы сейчас след.:
К нам приходят бизнес, и просит: "Помогите нам автоматизировать то и то, помогите улучшить то и то, сделайте нам то и то."
Такое обращение мы называем "реквестом".
Мы оцениваем такой реквест, насколько он реален и какую пользу принесен (например в высвобожденных человеко-часах или других реальных единицах) и решаем брать в разработку или нет.
Стараемся брать лучшие реквесты из общей массы.
Реквест "лучше", если за меньшее количество ресурсов команды сможем высвободить большее количество Человеко-часов для какого-нибудь договорного отдела.
Всё же, мы ошибаемся в оценке реквестов, и берем не лучшие. А я хочу быть более эффективным и брать лучшие.
Я связываю это с тем, что мы изучаем БП, не в том масштабе, в котором нужно.
Хочу описывать БП для того, чтобы видеть в нужном масштабе. Кроме того, ряд реальных проблем мы просто не видим, потому что бизнес не догадается к нам обратиться с этим.
Что мне нужно от инструмента для описания БП:
- нужно видеть БП в виде диаграммы (всё равно какая нотация)
- нужно чтобы один процесс имел 2 варианта: текущий и исправленный.
- нужно, чтобы в процессе было обозначено узкое место, т.е. проблема.
- нужно чтобы я мог видеть какие БП в какой организации происходят
- нужно видеть БП между организациями с обозначением проблем в них, а ещё лучше чтобы было видно на стороне какой организации проблема в этом БП.
- желательно, чтобы проблемы имели теги, чтобы по ним можно было потом дергать БП со схожими проблемами.
- желательно, чтобы проблема была самостоятельной сущностью и имела поля, в которые я мог бы записывать разные стандартные данные.
Я работаю в ЕА над проектами по разработке смогу организовать всё что описал выше этим инструментом, однако мне интересно посмотреть, может есть что-нибудь специально для моего случая ?
Скорее всего видно, что я в этой теме плаваю, поэтому прошу помочь ссылками на правильные книги или советом.
С уважением, Морозов Антон.
51
Примеры / Re: Пример описания поведения UI. Прошу мнений
« : 13 Мая 2013, 18:24:52 »
Поддерживаю IAFedorov в рекомендациях.
Вы в ДД ограничиваете ряд аспектов реализации заранее.
Например, в соответствии с ДД невозможна дополнительная проверка данных формы на
сервере непосредственно перед вставкой в БД, хотя такая проверка лишней не будет.
Если проверка первого поля не тяжелая, то её можно делать на лету и по другим событиям,
что вообще избавит пользователе от необходимости "куда то там переводить фокус".
Мораль тут в том, что вы беретесь определять детали реализации и поэтому
должны обладать компетенцией не меньшей, чем у вашего ведущего разработчика.
Иначе можете навязать разработчикам не совсем удачные решения.
Ещё смущает, что если данные в первом поле не валидны, то система
просто перекидывает пользователя на то же поле и никак не сообщает о причине своего поведения.
Не находите что это может быть воспринято пользователем как "система глючит" ?
Мне видится, что д. б. сообщение пользователю от системы что не так с данными, которые он ввел.
Сейчас логика формы определена в вашей activity.
Скорее всего, логика этой формы, хотя бы частично, уже описывается в классе, который отвечает за эту форму.
Т.е. в вашей документации есть как минимум два разных места, касающиеся поведение этой формы.
Вот вы захотите развить форму впоследствии. Тогда придется специально отслеживать чтобы
в этих двух местах не создавалось конфликтов логики. Impact analysis никто не отменял,
но усложнять задачу заранее тоже не стоит.
Попробуйте отобразить в ДД ту логику, которую увидит только пользователь этой формы.
Всё остальное можно перенести в описание класса, отвечающего за эту форму.
Вы в ДД ограничиваете ряд аспектов реализации заранее.
Например, в соответствии с ДД невозможна дополнительная проверка данных формы на
сервере непосредственно перед вставкой в БД, хотя такая проверка лишней не будет.
Если проверка первого поля не тяжелая, то её можно делать на лету и по другим событиям,
что вообще избавит пользователе от необходимости "куда то там переводить фокус".
Мораль тут в том, что вы беретесь определять детали реализации и поэтому
должны обладать компетенцией не меньшей, чем у вашего ведущего разработчика.
Иначе можете навязать разработчикам не совсем удачные решения.
Ещё смущает, что если данные в первом поле не валидны, то система
просто перекидывает пользователя на то же поле и никак не сообщает о причине своего поведения.
Не находите что это может быть воспринято пользователем как "система глючит" ?
Мне видится, что д. б. сообщение пользователю от системы что не так с данными, которые он ввел.
Сейчас логика формы определена в вашей activity.
Скорее всего, логика этой формы, хотя бы частично, уже описывается в классе, который отвечает за эту форму.
Т.е. в вашей документации есть как минимум два разных места, касающиеся поведение этой формы.
Вот вы захотите развить форму впоследствии. Тогда придется специально отслеживать чтобы
в этих двух местах не создавалось конфликтов логики. Impact analysis никто не отменял,
но усложнять задачу заранее тоже не стоит.
Попробуйте отобразить в ДД ту логику, которую увидит только пользователь этой формы.
Всё остальное можно перенести в описание класса, отвечающего за эту форму.