01.
введение
Техническое задание – необходимый документ для любого, кто разрабатывает новую технологию.
Касается не только информационных технологий. Любая техническая область не может обойтись без документа, который подробно описывает изменения. В техническом задании должно быть указано: цели изменений, средства изменений, процедуры изменений.
Я коснусь двух базовых принципов составления технического задания. Первое, какая информация должна быть в техническом задании. Второе, как эта информация должна быть представлена.
В техническом задании должно быть отражено, достаточно подробно, какие уже есть средства и материалы. Это не значит, что аналитик должен будет отражать подробно общее состояние дел
Существующая модель описывается не полностью, в этом большая сложность, отделить процессы, подвергающиеся изменениям, от процессов, которые будут не затронуты этим процессом. Во-первых, все процессы взаимосвязаны, отделить один процесс от другого, не простая задача. Для этого аналитик строит процесс AS IS. В такой схеме, можно определить область изменений конкретного процесса. Наглядно показать область изменений.
Следующим этапом будет описание процесса AS IS. В описании существующего процесса нельзя вдаваться в подробности, максимально сжато. Существующие процессы должны быть описаны только в тех гранях, которые возможно, будут подвергаться изменениям.
Отделить процессы друг от друга, сложная задача. Ниже я скажу о формальной и неформальной схеме процессов.
Для описания процессов AS IS требуется неформальная схема. Формальная схема предусматривает точную иерархию, подкрепленную нормативными актами.
Неформальная схема предусматривает более практическое описание, например, участие отдела статистики в процессах, отдел анализа и статистики, Data Science в анализе баз данных, отдел нормирования, учета заработной платы и охраны труда в промышленных процессах.
Функции, которые несут эти подразделения, предполагают участие во всех процессах компании. Описывая процессы AS IS, аналитик должен учитывать, что, все структурные подразделения так или иначе связаны с новыми изменениями, но, часть подразделений обязательные участники любых изменений.
Дело аналитика, акцентировать свое внимание на описание процессов учета и контроля в особом порядке, или, оставить на усмотрение отделов. Это немаловажный вопрос, схема TO BE может быть перегружена процессами, или наоборот, не указаны процессы важные для проекта.
Техническое задание, подробно описывающее процессы AS IS, может потерять смысл схемы TO BE. Информация, собираемая аналитиком, для описания процесса AS IS должна быть максимально сжатой, смежные процессы, которых касается изменения, должны быть указаны и описаны в таком виде, что бы исполнитель технического задания был в курсе, какие изменения ему надо прорабатывать.
Для потребителей технического задания, есть сформированные стандарты представления информации. ГОСТ, RUP, BABOOK, и другие отраслевые стандарты. Представление информации в схемах: USER STORY, BPMN, IDEF0…4, и так далее. Данные стандарты предназначены для единого понимания представления информации.
Задача аналитика, не только представить изменения, но и, представить их в максимальном понятном виде.
Я в повседневной работе использую следующий порядок представления информации. Во-первых, строится схема TO BE, в понятной для большинства нотации. Во-вторых, делается краткое описание самой схемы. В-третьих, список изменяемых процессов.
02.
на этом всё
Документ представляемый должен быть максимально кратким. Я стараюсь не делать полного и подробного описания изменяемых процессов, не делать полного описания изменений.
На первом этапе, я, как аналитик, делаю максимально краткие требования и высокоуровневые схемы.
Масштаб изменений должен быть описан максимально кратко. Руководители, активные участники изменений, должны иметь максимальную возможность «маневра» в рамках общих изменений.
Детализация схемы TO BE, её доведение до практического исполнения, не должно быть неожиданностью для руководителей смежных подразделений.
На первых этапах подготовки и согласований информационных материалов, построении схемы AS IS, уже предполагается в каких частях процесса предполагаются изменения.
Высокоуровневая схема TO BE, дает возможность аналитику, в процессах детализации, изменить, уточнить мелкие процессы, привести в соответствие с общей схемой. Такой порядок действий, как правило, встречает меньшее сопротивление со стороны участников процесса.
Подведу итог: необходимо обеспечить сбор информации только от наиболее значимых участников процесса, ограничить представление информации в итоговом документе до максимума, идти в процессе разработки и согласования от крупных деталей к мелким, представлять информацию только в понятных нотациях.
03.
связаться с нами
Возникла идея?
Действуйте…
Удача благоволит смелым!
