Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.
Хорошо подумав, я решил, что вместить весь материал планируемой второй части в одну статью опять не получится, иначе это будет верхами и в теории, что и так написано во многих учебниках. Но ведь я ставлю задачу, чтобы это можно было применять на практике, поэтому не буду больше загадывать на будущее о том, сколько выпусков еще потребуется, чтобы закончить с темой. На это будет влиять и обратная связь с читателями, так что пишите, не стесняйтесь!
Пользуясь случаем, хочу задать вопрос: на сколько интересна была бы организация практического семинара-тренинга в Санкт-Петербурге на тему разработки Технического задания? Встретились бы, опытом обменялись. Если такой интерес будет не единичным, обещаю организовать.
Поскольку читателями являются не только специалисты в области разработки программного обеспечения, а также бизнес-аналитики и руководители различного уровня, постараюсь писать так, чтобы было интересно всем.
В этой части мы будет говорить о том, как организовать этап работ по сбору требований, из чего он должен состоять и какими инструментами можно пользоваться. Повторюсь, что данные работы с точки зрения этапов очень похожи на обследование предприятия с целью описания бизнес-процессов.
Как обычно происходит в жизни:
| Как это происходит в большинстве проектов | |
| Шаги | Как это происходит |
| Решение принято, проекту быть! | Понятное дело, что есть повод для радости, особенно, если проект большой, ничего плохого в этом нет! Главное, не радоваться слишком долго, оттягивая начало фактических работ, с этой минуты время будет идти по-другому. |
| Провели совещание с руководителями, собрали некоторую информацию об их видении результата. | Обычно этот процесс ограничивается несколькими встречами с руководством, затем с руководителями подразделений. Зафиксировав некие «позывы» со стороны Заказчика, они фиксируются в виде общих формулировок. Иногда к этому добавляют имеющуюся документацию (кто-то когда-то пытался уже поводить обследование, документы по существующим регламентам, формы используемых отчетов) Как ни удивительно, но после этого большинство внедренцев систем автоматизации радостно восклицает: «да в нашей системе все это есть! Ну немного поднастроить и все будет работать». На вопрос, надо ли обсуждать, как все должно работать (или как выполняется конкретный процесс) с конечными пользователями, ответ обычно отрицательный. Высказывается мнение, что руководитель все знает за своих подчиненных. А зря… За этим скрывается множество ловушек и препятствий, и сдача работ может превратиться в марафон по полосе с препятствиями. Как известно, марафон принято бегать по ровной дороге, а бег с препятствиями возможен только на коротких дистанциях (можно и не добежать). |
| Документирование результатов работы | После этого начинается документирование результатов в зависимости от целей работ: Если требуется разработать Техническое задание, консультант начинает рассовывать полученную информацию по заготовленному шаблону документа, чтобы и выглядело красиво, и основные требования были зафиксированы (те, что озвучены от руководства, а то ведь могут не утвердить). Понимая, что на практике такое Техническое задание особо не используется и приходится все выяснять «по ходу дела», главной целью Технического задания он ставит минимальное время согласования и утверждения. И, если получится, информация для примерной оценки стоимости будущих работ (кстати, тоже немаловажно). Если требуется описать бизнес-процессы. Как ни странно, но часто все предшествующие действия выглядят аналогично, как и в случае с разработкой Технического задания. Разница лишь в оформлении документации. Тут возможны варианты: консультанты описывают процесс произвольными словами или используют какие-либо правила описания бизнес-процессов (нотации). В первом случае такой документ получается удивительным образом похож на Техническое задание. Бывает даже такое, что если заменить титульный лист, никакой разницы не увидишь.В последнем случае часто делают акцент не на соответствии действительности, а на «правильности описания», т.е. формальное следование правилам описания.К сожалению, оба варианта являются не самой лучшей практикой, т.к. являются скорее формальностью, а пользы приносят не много. |
Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования. Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».
Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?
Как видим, процесс заканчивается вопросом, т.к. на этом работа далеко не закончена и дальше начнется самое сложное и самое практичное – именно то, что будет определять применимость полученного результата в реальной жизни. Именно то, что будет определять судьбу предыдущей работы: или она отправится в шкаф (на полку или еще куда-нибудь), либо будет представлять собой ценный источник информации. А еще лучше, если она станет образцом для последующих проектов.
Хочу особо отметить, что до последнего шага на схеме (там, где вопрос) общий принцип сбора информации о деятельности компании выглядит одинаково, независимо от того, что планируется делать в дальнейшем, описывать бизнес-процессы или внедрять автоматизированную систему. Да, сама последовательность шагов одинаковая, но инструменты, применяемые на некоторых из них, могут отличаться. Мы данный момент обязательно рассмотрим, когда будем изучать методики и инструменты отдельных этапов. Подробно будем это делать в отдельных статьях, а сейчас рассмотрим только самое главное. Дальнейшие шаги будут отличаться и определяться тем, что требуется от проекта: описать бизнес-процессы или внедрять систему учета.
Давайте посмотрим, как можно реорганизовать подход к сбору информации о деятельности компании.
| Как это может происходить при более грамотной организации работ | |
| Шаги | Как это происходит |
| Решение принято, проекту быть! | Тут ничего не меняется относительно первого варианта, эмоции никто не отменял |
| Провели совещание с руководителями, собрали некоторую информацию об их видении результата. | Этот шаг тоже остается, и он имеет большое значение. Но основное назначение первой встречи (или нескольких встреч) с руководителями и собственниками это знакомство. Знакомство в первую очередь с людьми и компанией. Сформулированные цели и пожелания на таких общих встречах могут быть самими различными, в том числе фантастическими. Все они будут, конечно же, выслушаны, но не факт, что будут реализованы. При более глубоком погружении в бизнес компании будут как появляться другие цели, так и отвергаться предыдущие. Я это к тому, что из предварительных встреч нельзя сформулировать четкие цели, все это потребует тщательной проработки.На таких встречах необходимо конспектировать все посылы от собственников и первых лиц, чтобы потом можно было к ним вернуться и обсудить, когда будет собрано достаточное количество информации. Даже простое на первый взгляд требование может оказаться нереализуемым либо очень трудоемким. |
| Формирование рабочей группы от Заказчика и Исполнителя, распределение ролей | Необходимо определиться, кто будет работать над проектом как со стороны Заказчика, так и со стороны Исполнителя. Несмотря на кажущуюся простоту данного этапа, он имеет очень большую роль. Если не зафиксировать четко, кто за что отвечает, в ходе реализации работ Вы рискуете столкнуться с неразберихой. Если со своей стороны Вы можете всегда конкретизировать роли в своей команде, то у Заказчика с этим могут возникнуть проблемы. На что следует обратить внимание: в состав рабочей группы Заказчика обязательно должны войти те люди, которые будут в дальнейшем хоть как-то влиять на принятие результата. Если допустить ситуацию, что при сдаче работ подключатся сотрудники Заказчика, которые не принимали участие в работах по формированию целей и выявлению требований, то проблемы гарантированы. Возможна даже такая абсурдная ситуация, что все, оказывается, сделано не так, как требовалось.В моей практике я сталкивался с такой ситуацией не раз.Поэтому, Вы себя можете обезопасить, если оговорите и зафиксируете документально, что никто, кроме рабочей группы Заказчика не может принимать участие в приемке-сдаче работ. А лучше всего, прописать такое в договорных условиях (В договоре или Уставе проекта). Помню, был такой случай: в одном крупном проекте учредитель решил подключиться к процессу (уж не знаю почему, скучно видать стало) и посетил одну из рабочих встреч, где обсуждался вопрос формирования счетов клиентам. Он с удивлением для себя узнал, что счет клиенту выставляет менеджер по продажам. В его представлении счет должен выставлять бухгалтер, и никак иначе. Но на самом деле бухгалтер вообще не представлял, о чем идет речь, а менеджер не мог себе представить, как так работать, если за каждым счетом бегать к бухгалтеру. В результате потеряли кучу времени, но ничего не поменялось, счет по-прежнему выставлял менеджер. А учредитель остался при своем мнении, но больше в процесс не вмешивался. На этом же этапе целесообразно разработать Устав проекта, в котором зафиксировать роли участников, порядок коммуникаций, регламент и состав отчетности, а также все остальное, что следует прописать в Уставе. Разработка Устава проекта это тема опять же отдельная. |
| Обучение проектной команды методикам и инструментам работы, согласование правил работы, видов и состава документации | Во-первых, необходимо разъяснить проектной команде все, что прописано в Уставе, как это будет применяться на практике. Во-вторых, проектную команду Заказчика необходимо обучить тем методам работы, которые Вы собираетесь использовать на всех последующих этапах. Имеет смысл обсудить форматы документов, которые будут использоваться, рассмотреть образцы. Если будут применяться какие-либо правила описания моделей или бизнес-процессов, то надо обсудить и эти правила, чтобы они были понятны. |
| Анкетирование | Этап анкетирования позволяет сравнительно быстрым способом получить достаточно достоверный срез информации о компании. Качество такой информации будет определяться тремя факторами:
Обращаю внимание, что методика анкетирования для последующей внедрения автоматизированной системы или описания бизнес-процессов в правильном случае различается. Конечно, структура анкет может быть и одинаковая, но это не самый лучший вариант. Когда мы описываем бизнес-процессы, то анкеты обычно носят более общий характер, т.к. неизвестно точно, с чем придется столкнуться. Если же речь идет о внедрении конкретной автоматизированной системы, то лучше иметь анкеты, учитывающие особенности этой системы. При таком подходе можно сразу выявить все узкие места системы, которые не подходят для данного предприятия. Как правило, методики внедрения готовых систем предусматривают наличие таких анкет. Такие анкеты могут разрабатываться либо по отдельным областям учета (например, учет заказов, продажи, ценообразование), либо для конкретных должностей (финансового директора, например). Состав вопросов примерно одинаковый. |
| Опросы | Опросом называется проведение устного собеседование со специалистами с целью выяснить особенности отдельных процессов. Необходимо организовать опрос так, чтобы он не выглядел как просто «встретились-поговорили», а более организовано. Для этого необходимо подготовить так называемый план опроса. В него можно включить те части анкеты, которые у Вас вызывают вопросы, противоречат сведениям других анкет или информация представлена поверхностно. Целесообразно добавить вопросы и просто из личного опыта.Ответы надо конспектировать в обязательном порядке. Идеально, если Вы договоритесь о ведении аудиозаписи. На этом же этапе следует проследить за полнотой предоставленной информации о документообороте (как форм первичных документов, так и различных отчетов) |
| Выделение ключевых бизнес- процессов или областей автоматизации | После анкетирования и опроса можно обосновано считать, что информации достаточно, чтобы делать выводы о выделении ключевых бизнес-процессов. На самом деле, уже можно выделить не только ключевые бизнес-процессы, но и практически все (если состав участников был выбран правильно). Вопрос выделения бизнес-процессов это тема совсем отдельная и не простая. Научиться тут сложно и вырабатывается в основном опытом. Из выделенных бизнес-процессов следует составить перечень (классификатор). Затем можно будет принимать решения, какие из них следует исследовать более глубоко, какие нет, а также выделять приоритеты. |
| Формулирование ключевых требований к системе, целей, критериев успешности проекта, процессов для детального изучения | К этому этапу должна быть собрана вся первичная информация о деятельности компании, составлен перечень бизнес-процессов. Теперь в самое время вернуться к целям, конкретизировать их, при необходимости обсудить с первыми лицами компании. При формулировке целей следует учесть конкретные показатели, при достижении которых будем считать проект успешным. Если речь идет о внедрении автоматизированной системы, то отдельным перечнем можно выделить требования к системе от ключевых пользователей. Я это делаю в виде отдельной таблицы, где все требования сгруппированы по подсистемам, для каждого требования указывается автор требования, формулировка и приоритет. Данную информацию можно будет использовать для составления плана развертывания системы (последовательности внедрения отдельных подсистем), а также для предложений по дальнейшему развитию системы (если отдельные подсистемы в текущем проекте внедрять не планируется). Если необходимо описать бизнес-процессы, принимаются решения о тех процессах, которые необходимо исследовать более детально. |
Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.
| Шаги | Что и как делать |
| Выделяем бизнес-процесс | Из общего перечня бизнес-процессов, полученного на предыдущих этапах, выделяем один (по приоритету) для детальной проработки. С остальными затем поступаем аналогично. |
| Детальное изучение бизнес- процесса | Выделенный бизнес-процесс подвергаем детальному изучению: анализируем полученные первичные документы, отчеты и их структуру, используемые в процессе программы, различные файлы (например, Excel), разговариваем с конечными исполнителями. Собираем различные идеи о том, как можно улучшить процесс. Очень полезно, если удастся понаблюдать за процессом именно в тех условиях, в которых он выполняется (не многие любят, когда за ними наблюдают, но что делать) |
| Графическое и/или текстовое описание бизнес-процесса (первичное) | Полученную подробную информацию начинаем описывать.Прежде чем описывать процесс, надо определиться, потребует ли он графического описания. Если процесс простой и понятный, функций в нем мало, и, графическое представление не улучшит его понимание или восприятие, то не надо тратить на это время. В этом случае достаточно описать его в текстовом виде в табличной форме. Если же процесс сложный, с различными логическими условиями, то лучше привести его графическую схему. Диаграммы всегда воспринимаются легче. Если Вы решили описать процесс в графическом виде, это вовсе не означает, что не надо приводить его текстовое описание. Т.е. текстовое описание процесса должно быть в любом случае, причем выполненное по одинаковой схеме. Удобно это делать в виде таблицы, в которой указать: исполнителей каждого шага, какую информацию они получают на входе, описание каждого шага, какую информацию формируют на выходе. Ниже мы посмотрим на примере, как это может выглядеть. |
| Согласование с исполнителями и владельцем бизнес-процесса | Лучший способ понять, насколько удачно вы выбрали стиль изложения информации, это показать результат пользователям (исполнителям) процесса.На самое главное в такой демонстрации это понимание того, насколько правильно Вы поняли, как процесс выполняется.Если обучение проектной команды прошло успешно, то можно ожидать от исполнителей вполне адекватной обратной связи. А если им станет интересно, то продвигаться все начнет гораздо быстрее.Выявленные уточнения и несоответствия необходимо отразить в описании (актуализировать), при необходимости операцию повторить. |
| Выделение показателей бизнес-процесса | После того, как выработано правильное понимание, как выполняется бизнес-процесс, надо подумать над показателями, которыми можно измерить качество или скорость выполнения процесса. Это не просто, но необходимо. Показатель должен быть измеряемым, т.е. выражен в числовом выражении и должен существовать простой способ эту величину получить. Если измеряемый показатель выделить невозможно, есть риск того, что бизнес-процесс выделен неудачно. Кроме того, не будет возможности понять (измерить ведь нельзя), приведут ли изменения процесса к его улучшению или нет. |
| Окончательное документирование бизнес-процесса | После того, как мы убедились в правильном понимании, как процесс выполняется (или должен выполняться), можно включать его в документацию. |
| Дальнейшие действия (или их отсутствие), в зависимости от целей проекта | Дальше возможны варианты: рассматриваемые процессы будут анализироваться и оптимизироваться, разрабатываться должностные инструкции, приниматься решения о необходимости автоматизации отдельных процессов и т.д.Это может быть и отдельный проект: описание бизнес-процессов. |
Теперь рассмотрим, как будет выглядеть подход к изучению требований к информационной системе с дальнейшим их отражением в Техническом задании
| Шаги | Что и как делать |
| Выделяем бизнес-требование/область автоматизации | Выделение в качестве требований целой области автоматизации (например, «Складские запасы») на практике используется, однако, это не самый эффективный способ детализации требований. Область автоматизации представляет собой группу требований, и рассматривать их лучше каждое в отдельности. Например, «Учет поступления материала на склад» |
| Детальное изучение бизнес-требования | Под детальным изучением бизнес-требования понимается то, как это хочет видеть и будет использовать конечный пользователь (разумеется, в соответствии с целями проекта). В технологиях разработки программного обеспечения это часто называют «вариант использования». Таким образом, детальное изучение бизнес-требования сводится к проработке вариантов использования. Пример такого варианта приведен в приложении 2 к статье. В простейших случаях варианты использования вовсе не обязательно рисовать в виде графических схем, можно ограничиться и текстовой формулировкой. Например, требование «При вводе номенклатуры цена должна рассчитаться как цена закупки +20%» рисовать не имеет смысла. В виде диаграммы имеет смысл представлять требования, объединенные до области автоматизации, как показано в примере в приложении 2. |
| Моделирование требований в информационной системе | Вот оно! Как Вы наверное помните, я уже обращал внимание на этот важнейший элемент в методике разработки Технических заданий. «Построй модель – получишь результат!» А что надо моделировать? Моделировать надо варианты использования, полученные на предыдущем этапе. Что должно быть на выходе моделирования? Должна получиться демонстрационная программа, в которую внесены пользовательские данные, причем желательно привычные его (пользователя) слуху, с учетом отраслевой специфики, актуальных проблем. И не просто так внесены, а должно быть понятно, откуда эти данные взялись, как рассчитались. В этом месте у читателя должны возникнуть вопросы:
Конечно, Вы должны столкнуться с такой ситуацией, и это нормально. Что делать? Если система совсем новая (как говорится «с нуля»), то моделировать придется по большей части на бумаге, тут Вам диаграммы вариантов использования очень помогут. Частично имеет смысл набросать некоторые экранные формы, которые предполагается разработать (прямо в той среде, в которой будет вестись разработка), т.к. рисовать их в каком–нибудь редакторе будет дольше и эта работа скучная. Если внедряется готовая система, и в ней не хватает функциональности, то ничего страшного нет, данные вносятся руками, а пользователю так и рассказывается, что после необходимых доработок должно рассчитаться так-то и так (и он это видит). Целесообразно сопроводить такую модель текстовым описанием, пусть даже кратким, чтобы пользователь мог самостоятельно попробовать поработать с моделью в свободное время. В этом же описании можно формулировать требования к доработкам. |
| Демонстрация информационной модели рабочей группе | Полученную модель показываем Заказчику и рассказываем, как все должно работать.Демонстрацию модели лучше проводить по подсистемам, т.е. по группам требований. В случае, если выяснится, что у клиента предлагаемая схема работать не будет, надо подумать о других вариантах использования, внести изменения в модель и показать еще раз. Только если есть уверенность, что планируемая модель у данного клиента «будет жить», можно считать модель удачной. |
| Разработка тестов | Зачем нужны тесты? То, как мы смогли реализовать требования, нужно будет проверять. Соответственно, на все ключевые участки, сложные алгоритмы и пр. тесты желательно сделать. В том числе эти тесты могут быть использованы при сдаче работ. Вовсе необязательно делать тесты на каждую функцию системы, везде должен быть здравый смысл. Если речь идет о готовой системе, то делать тест на «ввод нового элемента в справочник клиентов» будет выглядеть глупо и бесполезной тратой сил и времени. А вот если это совсем новая система, такое вполне возможно. Зачем делать тесты, если еще нет системы?Во-первых, разработчику будет понятнее, чего от него хотят добиться. Во-вторых, мы облегчаем жизнь тестировщику (кто-то ведь будет тестировать результат разработки). Вообще, тестирование это отдельная дисциплина, весьма не простая с множеством методик. На практике, как правило, все равно используются самые простые методы тестирования. |
| Документирование требований в виде Технического задания | Собранная информация на предыдущих этапах будет являться как раз тем, что и должно войти в основу документа «Техническое задание» в раздел с требованиями.Так что остается все это грамотно оформить. |
| Дальнейшие действия (или их отсутствие), в зависимости от целей проекта | Дольше может начаться процесс разработки, поиск партнеров для проекта, тендер и т.д., все зависит от ситуации. |
Да, разработка Технического задания процесс трудоемкий, а значит и затратный. Но если он сделан грамотно, то избавляет Заказчика от не сбывшихся ожиданий. Исполнителю приходится делать то, что требуется Заказчику и не переделывать сто раз одно и тоже. Да и вообще, придает всему проекту прозрачность.
Приложение 1. Описанный бизнес-процесс в нотации EPC.
Приложение 2. Вариант использования подсистемы « Заказы»
Автор: chavalah
