Как разрабатывать командные термины. Часть 2. Типы задач / Hubr по сбору информации для описания требований к учетной системе и бизнес-процессов, и с чего начать описание процессов.

Как разработать техническое задание. Часть 2. Типы задач при сборе информации для описания требований к учетной системе и бизнес-процессам. Первая часть статьи "Создание технического задания "Что это такое, зачем оно нужно, с чего начать, как оно должно выглядеть?") вызвала большой интерес. Помимо рассылки, еще больший интерес вызвал известный сайт разработчика Infostart. Как и было обещано, я пишу продолжение. После тщательного обдумывания я решил, что уместить все содержание планируемой второй части в одну статью невозможно, иначе это будут пики и теория, о которых уже написано во многих руководствах. Однако мы не делаем дальнейших прогнозов относительно того, сколько еще выпусков потребуется для завершения работы, поскольку стремимся к тому, чтобы конечный результат был практичным. На это будет влиять обратная связь с читателями, поэтому не стесняйтесь писать. Пользуясь случаем, хочу задать Вам вопрос: насколько интересно было бы организовать практический семинар-тренинг по разработке условий ввода в эксплуатацию в Санкт-Петербурге? Мы могли бы встретиться и обменяться опытом. Если будет хоть один такой интерес, мы обещаем его организовать. Среди наших читателей есть не только специалисты по разработке программного обеспечения, но и бизнес-аналитики, и руководители различного уровня, поэтому мы постараемся писать так, чтобы было интересно всем. В этой части описывается, как построить этап сбора требований, что представляет собой этап сбора требований и какие инструменты можно использовать. Опять же, этапы выполнения этих задач очень похожи на бизнес-исследование с целью описания бизнес-процессов. Как это часто бывает в жизни, Как это происходит в большинстве проектов Шаги Как это происходит Решение принято, и проект должен двигаться вперед. Нет ничего плохого в том, чтобы радоваться, особенно если проект крупный. Главное - не затягивать с радостью начало реальных работ. С этого момента течение времени меняется. Вы провели встречу с руководителем, чтобы собрать информацию о своем видении результата. Как правило, этот процесс ограничивается несколькими встречами с руководством, а затем с руководителями отделов. Вы задаете ряд "подсказок" на стороне клиента, и они задаются в виде общих формулировок. Иногда добавляется имеющаяся документация (например, кто пытался провести исследование, документация по существующим нормативным документам, форма используемого отчета и т.д.) Удивительно, но большинство внедрителей автоматизированных систем потом радостно восклицают: "Я так рад, что вы здесь". Только подправьте, и все будет хорошо". На вопрос, нужно ли им обсуждать с конечными пользователями, как все работает (или как выполняется тот или иной процесс), ответ обычно отрицательный. Высказывается мнение, что руководители знают о своих подчиненных все. И нет никакого смысла ... В этом скрывается множество подводных камней и препятствий, которые могут превратить выполнение задачи в марафон по полосе препятствий. Как известно, марафоны обычно проводятся по ровным дорогам, а гонки с препятствиями можно проводить (а можно и не проводить) только на коротких дистанциях. Документирование результатов выполнения задачи В первом случае такие документы оказываются удивительно похожими на командные пункты, во втором - акцент часто делается не на соответствие действительности, а на "точность описания", т.е. формальное соблюдение правил описания. К сожалению, ни тот, ни другой вариант не является лучшей практикой, поскольку оба они формальны и малосодержательны. Почему имеет место описанная выше практика? На самом деле, мы не знаем. Никто не знает. Несмотря на постоянные дискуссии, обмен опытом и книги на эту тему, ситуация меняется не очень быстро. Одной из причин этого, как мне кажется, является низкое качество соответствующего образования. Возможно, дело в том, что многие специалисты приходят из других компаний и учатся всему на практике - их опыт формируется средой, в которой они выросли. Не секрет, что отношение вузов и их нежелание приближаться к реальности меня иногда удивляет. Например, был случай, когда талантливая выпускница хотела написать диссертацию по платформе "1С" (отличная отраслевая разработка), но на кафедре ей сказали, что на "отлично" рассчитывать нельзя, независимо от темы. Это объясняется тем, что "1С" не является полноценной системой. Здесь важна не серьезность или объективность подобных мнений, а то, что примитивная работа на классическом языке программирования сразу была признана достойной признания. Давайте более системно подойдем к описанному выше процессу. Как бы он тогда выглядел? Как видите, процесс заканчивается вопросом, поскольку работа еще не закончена. Далее начинается самая сложная и практическая часть - определение возможности применения полученных результатов в реальной жизни. От этого будет зависеть судьба предыдущей работы. Она либо окажется в шкафу (на полке или в другом месте), либо станет ценным источником информации. А если она станет моделью для будущих проектов, то еще лучше. Хотелось бы подчеркнуть, что до последнего шага на схеме (где задается вопрос) общий принцип сбора информации о деятельности предприятия одинаков, независимо от того, что планируется дальше. Описание бизнес-процедур или внедрение автоматизированных систем. Да, сами процедуры одинаковы, но инструменты, используемые на некоторых этапах, могут отличаться. Это всегда следует учитывать при рассмотрении методов и инструментов для отдельных этапов. Более подробно об этом будет рассказано в другой статье, а здесь рассмотрим только самые важные из них. Последующие шаги будут зависеть от того, что требуется от проекта, например описание бизнес-процессов или внедрение учетной системы. Прежде всего, это зависит от того, как вы подготовили проектную команду заказчика. Они должны четко понимать процесс анкетирования и уметь донести информацию до всех участников. От формата самой анкеты. Анкета должна быть легкой для понимания. Должны быть инструкции по заполнению анкеты. Еще лучше, если есть примеры заполнения анкеты. Состав участников. Важно выбрать соответствующий состав участников. Если в опросе будет участвовать только руководство, то собрать достоверную информацию не удастся. Рекомендуется включать всех будущих пользователей конечных результатов. Например, если вы внедряете автоматизированную систему, то стоит включить всех, кто будет ее пользователем. Из 10 сотрудников, занимающих какую-либо должность, может быть один человек, выполняющий специальные обязанности, о которых остальные девять сотрудников не знают (например, пишущий специальные отчеты для руководителей). То же самое следует сделать, если требуется дальнейшее перераспределение обязанностей или разработка должностных инструкций. Здесь возникает вопрос: "Что делать дальше?". Вопрос возникает. Далее отдельно рассматриваются задачи описания бизнес-процессов и разработки технического задания. Я не случайно рассматриваю эти задачи параллельно. Они действительно имеют много общего, что я и хотел бы продемонстрировать. Во-первых, рассмотрим порядок задач при описании бизнес-процесса. Шаги Что и как делать Выберите бизнес-процесс Из общего списка бизнес-процессов, сформированного на предыдущем шаге, выберите один (приоритетный) для детальной обработки. Затем то же самое проделать с остальными. Детальное исследование бизнес-процессов Выбранный бизнес-процесс подлежит детальному исследованию. Полученные первичные документы, их отчеты и структура, используемое в процессе программное обеспечение, различные файлы (например, Excel) анализируются и обсуждаются с конечным исполнителем. . Сбор различных идей по улучшению процесса. Очень полезно, если мы можем наблюдать процесс в тех условиях, в которых он выполняется (многие не любят наблюдать за процессами, но что поделать?) Начните с графического и/или текстового описания бизнес-процесса (основного). Поясните полученную подробную информацию. Прежде чем описывать процесс, необходимо решить, нужно ли графическое описание. Если процесс прост и понятен, имеет мало особенностей и графическое представление не улучшает понимание или осведомленность, то нет необходимости тратить время. В этом случае достаточно объяснения в табличном текстовом формате. Если же процесс сложный и имеет различные логические условия, то целесообразно представить его в графической форме. Диаграммы всегда легче воспринимаются. Если вы решили описать процесс в графическом виде, это не означает, что он не должен быть описан в текстовом. Это означает, что во всех случаях необходимо текстовое описание процесса, которое должно быть выполнено по одной и той же схеме. Уд. Необходимо рассмотреть показатели, с помощью которых можно измерить качество или скорость процесса. Это нелегко, но необходимо. Показатель должен быть измеримым. Это означает, что должен существовать простой способ получения этой величины, чтобы выразить ее численно. Если измеримый показатель не может быть выделен, то существует риск, что операционный процесс не удался. Кроме того, нет возможности понять (и в конечном итоге измерить), улучшат ли изменения в процессе. Окончательное оформление операционного процесса может быть включено в документацию, поскольку вы уверены, что хорошо понимаете, как процесс реализован (или должен быть реализован). В зависимости от целей проекта дальнейшие действия (или их отсутствие) могут быть дополнительными вариантами. Эти действия анализируются и оптимизируются, разрабатываются должностные инструкции, определяется необходимость автоматизации отдельных процессов и т.д. Это может быть отдельный проект: описание бизнес-процессов. Рассмотрим, как представляется, дальнейший отпечаток подхода к исследованию требований к информационным системам в условиях командования А что делать, если планируется разработка новой системы, а моделировать нечего? А если демонстрация не обладает достаточной функциональностью и система нуждается в доработке?