Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
23.07.2015, 18:28
|
|||
---|---|---|---|
|
|||
Нужен совет по организации процесса |
|||
#18+
Добрый вечер! Пишу не совсем по профильной теме, но более подходящей ветки не нашел. Сейчас столкнулся с одной проблемой и нужен совет. У нас в департаменте ИТ есть департамент бизнес-анализа, в котором я сейчас собственно говоря и работаю. У нас 2 основные задачи: 1) От бизнес-заказчиков через нас проходят ТЗ на разработчиков и обратно от разработчиков к бизнесу возвращается результат. 2) Описываются текущие процессы компании, которые требуют описания. Процессы описываются в разных нотациях, т.к. унифицировать все в одной нотации пока не получилось. Так же пока нет единой нумерации для процессов. Сейчас есть следующая процессная проблема. Суть в том, что не до конца понятно, как связать процесс внесения изменений в информационные системы с обновлением (поддержанием актуальности) описания бизнес-процессов. Какие есть проблемы: 1) Может быть связь один ко многим, т.е. одно изменение может потребовать изменения документации по ряду бизнес-процессов. 2) Разработчики сами никак не могут выстроить связь между их изменениями и описаниями БП, 3) До фактических изменений, несмотря на формализацию ТЗ. нельзя точно сказать, в какие описания БП потребуется вносить изменения, т.к. все зависит от конкретной реализации в системе разработчиком. Вариант, который напрашивается - после внесения изменений разработчиками, внести обязательную стадию внесения изменений в описание БП аналитиком. Но тут возникнут очень большие издержки, на анализ всех существующих БП. Возможно, что нужно, как-то увязать описания БП с областями информационных систем. Короче, красивого решения пока нет. Буду рад любым комментариям: личный опыт, лучшие практики, ссылки на литературу и т.д. Всем спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.07.2015, 20:35
|
|||
---|---|---|---|
Нужен совет по организации процесса |
|||
#18+
Кирилл80ссылки на литературу Разработка требований к программному обеспечению ... |
|||
:
Нравится:
Не нравится:
|
|||
|
24.07.2015, 17:49
|
|||
---|---|---|---|
|
|||
Нужен совет по организации процесса |
|||
#18+
egorych, Спасибо. Данную книжку видел, теперь видимо придется купить. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.07.2015, 22:46
|
|||
---|---|---|---|
Нужен совет по организации процесса |
|||
#18+
Кирилл80, система управления требованиями, интегрированная с ИС? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.07.2015, 10:49
|
|||
---|---|---|---|
|
|||
Нужен совет по организации процесса |
|||
#18+
Алекссс, не совсем понял ваше сообщение. Отдельной системы управления требованиями у нас нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.08.2015, 13:26
|
|||
---|---|---|---|
Нужен совет по организации процесса |
|||
#18+
Кирилл802) Разработчики сами никак не могут выстроить связь между их изменениями и описаниями БП Весьма показательно. Личное признание работника отдела по возне с бизнес-процессами в неубиваемом желании свалить собственную работу на смежников. Вывод - вам зачем-то хочется "сделать красиво", но как это сделать вы не знаете. Если это ваш личный внутренний позыв, то совет простой - много читайте и так же много применяйте прочитанное на практике, после дцатой итерации начнёт вырисовываться понимание. Ну а если же начальство домогается, то все гораздо проще, ведь ваш ответ Чемберлену уже дан - "Короче, красивого решения пока нет". Вот так и заявляйте начальству. Естественно, в целях самосохранения к заявлению нужно прилагать кучу наукообразного текста, из которого начальство прочтёт лишь часть первой страницы и содержание, так что скопируйте на первую страницу кусок вашего сообщения под фразой "Какие есть проблемы:", а остальное забейте копипастой из чего угодно близкого по смыслу. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
10.08.2015, 10:47
|
|||
---|---|---|---|
|
|||
Нужен совет по организации процесса |
|||
#18+
alex55555Кирилл802) Разработчики сами никак не могут выстроить связь между их изменениями и описаниями БП Весьма показательно. Личное признание работника отдела по возне с бизнес-процессами в неубиваемом желании свалить собственную работу на смежников. Вывод - вам зачем-то хочется "сделать красиво", но как это сделать вы не знаете. Если это ваш личный внутренний позыв, то совет простой - много читайте и так же много применяйте прочитанное на практике, после дцатой итерации начнёт вырисовываться понимание. Ну а если же начальство домогается, то все гораздо проще, ведь ваш ответ Чемберлену уже дан - "Короче, красивого решения пока нет". Вот так и заявляйте начальству. Естественно, в целях самосохранения к заявлению нужно прилагать кучу наукообразного текста, из которого начальство прочтёт лишь часть первой страницы и содержание, так что скопируйте на первую страницу кусок вашего сообщения под фразой "Какие есть проблемы:", а остальное забейте копипастой из чего угодно близкого по смыслу. Ну тут вопрос и сводится к желанию этот красивый процесс построить. То, что красивого решения нет, вышестоящее руководство понимает. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
10.08.2015, 16:36
|
|||
---|---|---|---|
Нужен совет по организации процесса |
|||
#18+
Кирилл80Ну тут вопрос и сводится к желанию этот красивый процесс построить. Понимаете, когда начальство ожидает от вас выполнения его собственных функций, результат всегда будет некрасивым. Или даже хуже - вы ожидаете, что начальство чего-то вообще ожидает, но на самом деле начальство смотрит лениво на ваши потуги и в лучшем случае ожидает чего-то из серии "удиви меня". Вы начальника вряд ли удивите, тем более при ваших минимальных знаниях. И красиво не сделаете без опыта. Поэтому, если вам самому это дело интересно, то есть один только путь - копите опыт и читайте знания в умных книжках. В книжках, в общем-то, всё есть. Но вот скомбинировать эти знания с учётом реальности в вашей конкретной конторе - для этого и нужен опыт, которого у вас нет. Значит просто занимайтесь не торопясь своими исследованиями, у начальства минимальный интерес поддерживайте и постепенно чего-то да получится. И да, если даже за мега-деньги вам сделают реально красиво, то это скорее всего потребует смены вашего начальства, что совершенно не в интересах вашего начальства. Ну и тратить мега-деньги ни разу не в интересах ваших хозяев. Так что - копите личный опыт, а с красотой пока не стоит торопиться. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
11.08.2015, 17:22
|
|||
---|---|---|---|
|
|||
Нужен совет по организации процесса |
|||
#18+
Кирилл80... 3) До фактических изменений, несмотря на формализацию ТЗ. нельзя точно сказать, в какие описания БП потребуется вносить изменения, т.к. все зависит от конкретной реализации в системе разработчиком.... Это как? Что же это за ТЗ такое и что делает архитектор (или человек утверждающий ТЗ)? То-есть, что-то изменив в коде программист может самостоятельно и существенным образом изменить какие либо БП? Нафиг тогда вообще отдел аналитиков, пусть программисты дальше БП и меняют. Ну и мне не понятно, а что менять в БП? Обычно картинка-БП - это одно, а документация на программу (user guide) - другое. IMHO Программист может поменять какие-то экраны, может поменять какую-то логику (локально) и/или проверки. Тогда нужно менять соответствующую часть документации по программе (user guede). БП на нее могут только ссылаться. Соответственно, если мы знаем, что программист "копался" в форме оформления заказа - нужно ПРОВЕРИТЬ все БП где данная форма/экран задействована. Прописать в "квадратиках" картинок-БП названия программных модулей и/или форм/экранов - в общем, на мой взгляд, задача не сложная. IMHO & AFAIK ... |
|||
:
Нравится:
Не нравится:
|
|||
|
11.08.2015, 17:31
|
|||
---|---|---|---|
|
|||
Нужен совет по организации процесса |
|||
#18+
По пред. опыту, было только 2-е точки требующие возврата информации обратно от программиста к аналитику: 1. При реализации, иногда, реализовано оказывает НЕ совсем так как было описано в ТЗ. Т.ч. продвинутые аналитики, после реализации, обычно подходят и спрашивают: а теперь расскажите как оно работает на самом деле и если нужно, то меняют ТЗ, что бы оно было актуальным. 2. Сообщения об ошибках. Хотя, вроде, это нужно описывать в документах на код (AIM MD.70), было решено, что это должно описывать в документах аналитика (AIM MD.50). Т.к. это важный раздел, который должен попасть в user guide. Разумеется, аналитики, при написании user guide документы на код не читают. Т.ч. в случае наличия блока "сообщения об ошибках" данная информация после завершения разработки копировалась в документы аналитика. А анализ, какие БП затронет реализация очередной "хотелки" должна выполнять ДО написания ТЗ. Т.к. возможно, что если затронет соседние отделы и те не хотят ничего менять, то и требования можно похоронить на корню. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=37&mobile=1&tid=1555333]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 151ms |
0 / 0 |