Проектное решение: игра по твоим правилам

Не секрет, что чем крупнее программный проект, тем больше его успех зависит от результатов работы аналитиков, в частности, от выбора правильной стратегии составления и согласования проектных решений. Однако как организовать работу этих творческих сотрудников? И как сделать так, чтобы результаты их деятельности были одинаково понятны как представителям заказчика, так и программистам? Как оценить возможные сроки выполнения и значимость этой работы для проекта? В этой статье я попытался сформулировать свои рецепты оптимизации управления аналитической работой на проектах по созданию программного обеспечения для государственных заказчиков. Приветствуется любая критика.

Рамки исследования

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на проектирование программы.

Поскольку на текущий момент на рынке труда в IT фигурирует более двух десятков разновидностей вакансий “аналитик” , сразу оговорюсь, что я буду говорить об аналитической работе по созданию заказного программного обеспечения в интересах крупных корпоративных заказчиков. Как показывает мой опыт, бизнес-аналитик, не разбирающийся в механизмах автоматизации бизнес-процессов, не может подготовить адекватную постановку задачи. Как не может быть адекватным системный аналитик, не понимающий бизнес-целей автоматизации. Поэтому, с моей точки зрения, аналитик, работающий на заказных программных проектах, должен совмещать в себе компетенции бизнес-аналитика, системного аналитика и UX-дизайнера. Кроме этого, как правило, ведущий аналитик на таком проекте должен выполнять функции Product Owner (если заказчик вам позволит). Именно об организации деятельности таких «универсальных солдат» пойдет речь далее.

При создании программного обеспечения в интересах государственных организаций основная деятельность аналитиков связана с решением таких задач, как:

• управление требованиями;

• формирование постановок задач для программистов, планирование реализации и контроль выполнения этих задач;

• подготовка проектной документации.

Детали управления требованиями к заказному программному обеспечению, порядок их первичного уточнения и ключевая роль аналитика, ответственного за их реализацию, были подробно рассмотрены в предыдущей статье.

Однако конкретность желаний заказчика не является гарантией того, что ему понравится конечный результат. В ходе моих проектов была «выявлена» следующая закономерность: все функциональные замечания заказчика, зафиксированные в ходе всех видов испытаний (не путать с выявленными ошибками!), касались требований, по которым превентивно не было согласовано с заказчиком проектное решение. В этом отношении показательна статистика, которую приводит Наталья Руколь, когда при анализе результатов одного из проектов выяснилось, что почти 70% выявляемых на стадии сдачи «ошибок» вызваны непониманием исходных требований со стороны разработчиков.

Казалось бы, после того, как уточнены требования к программному продукту, нужно сформировать пакет проектной документации в соответствии с ГОСТ РД 50-34.698, согласовать ее с заказчиком и потом разработать ПО в полном соответствии с утвержденным проектом. Зачастую именно о такой последовательности действий приходится слышать от вчерашних студентов-отличников (троечники, как правило, вообще не знают о существовании таких документов) и многих «опытных» топ-чиновников, которые никогда не несли персональной ответственности за конечный результат разработки программного обеспечения.

Однако, как подсказывает мой опыт, формирование проектной документации - это только финальная часть работы аналитика. В качестве аналогии можно привести научно-исследовательскую работу, в результате которой должен быть сформирован отчет в соответствии с ГОСТ 7.32 или написана диссертация. Однако эти документы являются всего лишь формой оформления полученных научных результатов. Проведение бесплодных экспериментов, статистическая обработка «белого шума», поиски крупиц требуемой информации в тоннах псевдонаучной макулатуры - все эти неотъемлемые составные части научной работы всегда остаются «за кадром». Точно так же в случае с проектной документацией. С одной стороны, она является неотъемлемой частью программного продукта. С другой - в ней оформлены только конечные результаты аналитической работы.

На мой взгляд, этот аспект является одной из ряда причин, почему согласно требованиям государственных контрактов на программных проектах, «глупые» заказчики планируют согласование проектной документации на этап проведения предварительных испытаний, т.е. на момент фактического завершения разработки программного обеспечения.

Именно поэтому в наших программных проектах в JIRA формируется два разных типа задач, позволяющих разделить непосредственно аналитическую работу и деятельность по подготовке документации проекта. И что отрадно, не один я пришел к таким выводам. Так чем собственно должны заниматься аналитики на программном проекте после уточнения требований и до оформления проектной документации?

Проектные решения VS проектной документации?

Как всё прекрасно на бумаге,

Как легко следовать словам.

Как просто сделать так, что ты непогрешим.

Несмотря на то, что определение понятия «проектное решение» дано в ГОСТ 34.003-90, в моем случае значение этого понятия было «открыто» в ходе мучительных и безрезультатных попыток согласования с представителями заказчика нескольких взаимосвязанных, но неоднозначных требований, когда клиенты просто игнорировали предлагаемые нами описания постановки задач (ОПЗ), сформированных в строгом соответствии с РД 50-34.698-90. После осознания того, что решение со стороны заказчика не будет принято вплоть до начала испытаний, был предпринят следующий манёвр: в адрес заказчика было отправлено наше проектное решение (т.е. решение, которое формально он был не обязан согласовывать).

В проектном решении были сохранены ритуальные атрибуты, но по сравнению с гостированным ОПЗ в этот документ были внесены существенные корректировки. В проектное решение были добавлены схема автоматизируемого бизнес-процесса с кратким описанием, макеты пользовательского интерфейса, формы получаемых отчетов на печать, предложения по распределению доступа, а также краткий сценарий сдачи этого проектного решения. В части неоднозначных и противоречивых требований было сделано однозначное и подробное описание. Однако остальной текст всячески минимизировался. Тривиальные алгоритмы не были описаны вовсе, как и не были описаны поля экранных форм, предназначение и правила валидации которых были понятны и так из приведенных макетов UI.

Получившийся коктейль одновременно по форме был похож на документ, оформленный в соответствии с требованиями РД 50-34.698-90, однако по факту он не соответствовал ни одному из форматов, приведенных в этом ГОСТ. При этом, то, что было в нем написано, понимал обычный, неподготовленный представитель заказчика. Требования, уточненные в этом документе, были совершенно понятны как для заказчика так и для исполнителя. Были определены границы требований, необходимый объем планируемых работ и чем собственно эти работы должны были завершиться.

В сопроводительном письме присутствовала примерно такая фраза:

«Представляем вариант проектного решения по выполнению перечисленных требований. Информируем Вас о начале работ по реализации представленного варианта. В случае Вашего несогласия с предложенным проектным решением просим проинформировать нас об этом».

Отсутствие ответа на такое письмо интерпретировалось как формальное согласие заказчика с предложенным проектным решением. Если же заказчик присылал возражения, в этом случае он информировался, что работы по реализации данного проектного решения приостанавливаются не могут быть продолжены до его согласования. В этом случае, как правило, дальнейшее согласование шло значительно быстрее.

Что забавно, сначала в ответных письмах в случае, если заказчик не присылал необходимые уточнения, мы использовали фразу «работы приостанавливаются». После нескольких таких писем один из представителей заказчика устроил форменный скандал в связи с тем, что мы «согласно подписанному контракту не можем приостанавливать работы и отсутствие разъяснений в отношении требований не является основанием для прекращения разработки». Однако на формулировку о том, что «работы не могут быть продолжены» у него не нашлось возражений.

Как оказалось впоследствии, несмотря на то, что сформированная структура проектного решения не соответствовала требованиям ГОСТ, предложенный подход значительно облегчил ритуальные телодвижения по формированию и утверждению проектной документации. Содержание проектной документации, которая требовалась для сдачи проекта, формировалось методом выборочного копирования соответствующих разделов проектных решений. При этом в отношении разделов документации, которые были сформированы на основании превентивно «согласованных» проектных решений, в ходе приемки со стороны заказчика не было заявлено замечаний.

Описание слона не по ГОСТ

Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумывались над задачей настолько детально, как это нужно указать в спецификации.

Фредерик Брукс

На мой взгляд, основным критерием хорошего описания постановки задачи (проектного решения) является не выполнение формальных требований ГОСТ, а однозначное описание условий успешного завершения работ по выполнению требований заказчика. С этой точки зрения, фактически неотъемлемой частью любого проектного решения является описание тестовых заданий по проверке требований.

Необходимо отметить, что при работе с корпоративным заказчиком все неоднозначности и недоговоренности в ваших проектных решениях всегда будут истолкованы в пользу заказчика. Чтобы избежать таких «белых пятен», в результате проб и ошибок протоколирования требований, был разработан контрольный лист оценки качества проектных решений, в котором были перечислены основные разделы, которые по мере необходимости, должны были отражаться в проектном решении. Таким образом, любое проектное решение должно проверяться со следующих позиций.

1. Перечень требований заказчика (которые будут реализованы в рамках проектного решения).

2. Список определений и сокращений.

3. Перечень нормативных документов, регламентирующих автоматизируемый процесс.

4. Описание порядка применения программного обеспечения (use case), которое может включать:

- описание автоматизируемого процесса (как правило, в формате BPMN – не забывайте отмечать, как выполняется то или иное действие: автоматически, автоматизировано или вообще без компьютера) и предполагаемого результата;

- перечень ролей и их полномочий;

- определение необходимости ведения истории изменения объектов учета (необходимость хранения и последующего анализа предыдущих значений атрибутов объекта) - пренебрежение данным пунктом может увеличить время разработки в разы;

- определение необходимости протоколирования действий пользователей (определение таких действий, связь с историей изменения объекта).

5. Описание доработки:

- описание новых классификаторов и требования по доработке имеющихся, определение порядка их сопровождения;

- описание пользовательского интерфейса ( UI ) и правил его отображения (в случае, если в рамках проектного решения определяются схемы процессов, все экранные формы должны быть связаны с действиями на этих схемах);

- описание печатных отчетов и правил (алгоритмов) их формирования.

6. Электронный обмен данными:

- описание форматов и регламента взаимодействия через API;

- описание форматов и регламента (последовательности) загрузки внешних данных в "ручном" режиме (в виде файлов);

- описание форматов и регламента (последовательности) выгрузки данных в "ручном" режиме в виде файлов.

В качестве примеров проектного решения по электронному обмену данными может здорово пригодиться пакет стандартов, разработанный некоммерческим партнерством «Стандарты некоммерческого обмена информацией» (партнерство распалось в 2011 г., в настоящее время эти стандарты продолжает сопровождать компания 1С). Также могут помочь нормативно-эксплуатационные документы, размещенные на техническом портале Системы межведомственного электронного взаимодействия ( СМЭВ ).

7. Определение полномочий доступа:

- определение атомарных действий, по которым должно (может) производиться ограничение доступа, определение иерархии этих действий;

- определение перечня атрибутов объекта, по которым должно (может) производиться ограничение доступа.

8. Сценарий ( синопсис ) проведения тестирования, который включает последовательность выполнения и названия отдельных тестовых заданий, а также ожидаемый результат выполнения этих тестовых заданий. При наличии времени на проектирование в этот раздел могут включаться описание тестовых заданий (по шагам) и краткое описание тестовых данных. Именно в этом разделе должны находить отражение пользовательские истории (собранные и запротоколированные во время проведения информационных обследований), начальные условия выполнения программы, условия (ограничений) успешного завершения, альтернативные варианты завершения процесса. Сценарий проведения тестирования в обязательном порядке должен быть «узнаваем» со стороны заказчика.

9. Пусковое решение - перечень мероприятий, необходимых для внедрения проектного решения в промышленную эксплуатацию (подготовка скриптов по первичному заполнению справочников и распределению доступа, проведение занятий с эксплутационным персоналом и т.п.).

10. Расчет трудоемкости предлагаемых к выполнению работ. Для детализации работ на проекте и уточнения их объемов рекомендуется применять калькуляторы оценки трудоемкости .

Повторюсь – это не фиксированная структура для проектного решения, это формальный перечень вопросов ( checklist ), ответы на которые должны быть при необходимости отражены в том или ином виде в проектном решении. Как показывает практика, если разработка в отношении одного из описанных выше элементов не предполагается – будет лучше, если вы укажете это в проектном решении явно. Или почти явно (не надо пугать заказчика). Главный критерий – однозначная трактовка. Важно не переборщить, чтобы вместо решения заявленного требования в результате его согласования не родилось пять новых. Например, фраза «Справочник типов объектов должен содержать только актуальные значения» и фраза «В справочнике типов не предусматривается хранение истории изменений» означают одно и то же, но вторая фраза с высокой долей вероятности приведет к тому, что вам придется описывать и реализовывать механизмы версионности этого самого справочника. При формировании проектных решений важно понимать, что его назначение – зафиксировать правила, по которым вы гарантированно сдадите связанные с этими решениями требования.

Лучше один раз увидеть

Когда дело доходит до конечного результата, то, как ни ценны точные данные и реальные факты, гораздо большее значение имеет тот или иной способ их изображения.

Многое (если не все) на проекте зависит от того, как представители заказчика представляют себе конечный результат. Поэтому уже на начальных этапах проектирование макетов пользовательского интерфейса имеет ключевое значение для успешности проекта. Уточняйте и конкретизируйте требования заказчика в понятных ему терминах внешнего описания программного продукта. Диалог с представителями заказчика, основанный на обсуждении макетов экранных форм, показал себя гораздо более эффективным, чем диалог по обсуждению форматов входных и выходных данных и алгоритмов их преобразования (основные разделы в ОПЗ, созданном в соответствии с ГОСТ).

Отработка в рамках проектных заданий всех элементов пользовательского интерфейса, кроме прозрачности понимания границ реализации, также обеспечивает решение целого ряда проблем.

1. Прототипирование пользовательских интерфейсов позволяет более точно определить сроки реализации функционала. Согласно статистике, точность экспертной оценки сроков программного проекта, выполненной на основе утвержденных макетов UI, в несколько раз выше, чем точность оценки на основе концептуальных требований технического задания.

Источник : Стив Макконел. Сколько стоит программный проект. ISBN: 978-5-91180-090-1

2. Грамотный UX-дизайн позволяет обеспечить формирование проектной и эксплуатационной документации еще до завершения кодирования. Сразу после согласования проектного решения, параллельно с разработкой, становится возможным формировать руководство пользователя (замена макетов интерфейса на скриншоты осуществляется во время выполнения задач тестирования).

3. Фиксация макетов пользовательского интерфейса облегчает нахождение решения спорных вопросов при определении «новизны» требований. Если на согласованном макете UI не было поля, значит, его добавление – это новое требование, выходящее за рамки согласованного проектного решения (следующий пример раскроет последствия добавления «всего лишь» одного поля на форму).

4. Как показывает опыт, форма «внезапно» может оказать существенное влияние на содержание. Описанный далее случай произошел на четвертой неделе активного UX-проектирования и регулярного обсуждения с заказчиком макетов пользовательского интерфейса одной из подсистем АСУ. Заказчик охотно шел на общение, были уже предварительно согласованы схемы основных процессов и более 80% экранных форм. Мало того, чтобы ускорить разработку была уже создана база данных и по отдельным задачам в полную силу работали программисты. На одном из рабочих совещаний вдруг заместитель начальника управления (для которого собственно и создавалась подсистема) спросил: «А где у вас тут поле даты?». Как выяснилось, он имел в виду, что программа должна иметь возможность отразить состояние дел (или сформировать отчет) на любую произвольную дату, и это при том, что ведение истории изменений ранее не обсуждалось. Все представители заказчика подразумевали, что «это было совершенно очевидно и не требовало дополнительных пояснений». В результате «небольшое» замечание увеличило время разработки подсистемы почти в два раза. Надо отметить, что макеты форм практически не изменились, просто на некоторых добавилось поле «По состоянию на дату Х».

Хотелось бы сказать несколько слов о принципах проектирования пользовательских интерфейсов для автоматизированных систем управления. Несмотря на лавинообразный рост использования мобильных устройств, для автоматизированных систем управления, применяемых в государственных учреждениях, настольные компьютеры и ноутбуки остаются вне конкуренции (так же, как и для решения задач программирования и системного администрирования). В настоящее время для прототипирования интерфейсов появилось множество разнообразных средств . Однако за разъяснением особенностей применения Figma или Axure в интересах мобильных устройств теряются 10% примитивных способов, которые позволяют проектировать 90% пользовательских интерфейсов АСУ .

Моя практика показала, что для значительного сокращения проблем при разработке ПО надо придерживаться нескольких простых правил при проектировании пользовательских интерфейсов.

В первую очередь необходимо определиться с общей навигационной схемой, на которую как на новогоднюю елку можно безболезненно навешивать все новые и новые элементы интерфейса. В этом плане для автоматизированных систем управления в моей практике наиболее эффективной показала себя схема, которая повсеместно применяется в различных IDE .

Я не буду приводить здесь пример интерфейсаIntelliJ IDEA или PhpStorm, однако попробую препарировать на составные части основные составляющие такого UI, с точки зрения аналитика автоматизированной системы управления.

Интерфейс, построенный по этой схеме, содержит в правой части сворачиваемую вертикальную панель, с помощью которой обеспечивается навигация по всей системе. Наличие именно вертикальной панели с разделами, содержащими иерархические меню, фактически обеспечивает реализацию правила « трех кликов ».

Каждая из опций меню главной навигационной панели открывает доступ к формам-спискам объектов. Списки объектов (каталогов) и форм (карточек) отображения этих объектов формируют львиную долю пользовательского интерфейса. Унификация этих двух типов форм в рамках проекта и формирование на их основе навигационной структуры позволяют на порядок сократить количество запросов пользователей, связанных с недоработками пользовательской документации.

В рамках описания любой списковой формы при проектировании должны быть определены:

• перечень выводимых полей-атрибутов;

• требования к режимам просмотра списка (отображение по умолчанию, группировка, сортировка);

• требования к подчиненной форме, связанной с элементом списка (карточка (таблица) оперативного просмотра);

• требования к панели фильтров (выборка записей по заданному перечню атрибутов);

• описание групповых операций (одновременные действия над несколькими элементами списка, например: сравнение элементов списка, изменение атрибутов для нескольких элементов списка, изменение прав доступа для нескольких элементов списка);

• описание форм (панелей) оперативных статистических отчетов (мониторинга) по результатам выборки списка;

• описание требований к отчетам для вывода на печать и алгоритм их формирования;

• требования по оповещению пользователей (внешних систем) при изменении объектов.

При проектировании списковых форм хорошо зарекомендовали себя следующие правила.

1. Все элементы управления формой должны располагаться в верхней части в форме панели инструментов - при этом вероятность того, что пользователь «потеряет» их, сводится практически к нулю. При этом практика показала целесообразность отказа от строки иерархического меню в пользу ленточного интерфейса ( ribbon ).

2. Для всех списков, как правило, на ленте должны присутствовать четыре группы элементов управления:

• действия с одной записью из списка - как правило, эти действия сводятся к аббревиатуре CRUD: добавление, просмотр, редактирование, удаление;

• режимы просмотра (как правило, здесь располагаются элементы управления группировкой и фильтрацией списка);

• групповые операции;

• сервисные функции (вызов справки, пользовательская настройка списка, сбор предложений по доработке).

3. При формировании статистических отчетов (в т.ч. и для вывода на печать) желательно не создавать специализированные формы для предварительной настройки этих отчетов. Сама списковая форма с ее возможностями выборки, сортировки и отображения объектов должна обеспечивать предварительную настройку требуемых отчетов. Другими словами по возможности отчеты должны формироваться на основе выбранных критериев при формировании списков.

4. В рамках описания карточки объекта при проектировании должны быть определены:

• макет карточки просмотра;

• перечень действий, которые можно произвести с объектом учета (CRUD, изменение статуса, согласование и т.п.) и требуемые для этих действий полномочия доступа;

• описание правил валидации атрибутов при добавлении/редактировании;

• перечень возможных информационных сообщений;

• способы просмотра истории изменений объекта.

Пару слов об инструментарии. В результате проб и ошибок в ходе выполнения различных проектов по госзаказу наиболее эффективными оказались следующие три подхода к проектированию интерфейсов.

1. В случае, если в ходе разработки требуются изменения уже существующих интерфейсов, не стоит изобретать велосипед. Здесь лучше всего себя проявил Paint.NET (с помощью которого, кстати, подготовлены картинки к этой статье). Не имеет смысла заново перерисовывать формы, проще изменить готовый скриншот.

2. Если вы разрабатываете новый интерфейс пользователя, а ваш заказчик - «бумажная крыса», в таких случаях лучше всего себя зарекомендовал MS Visio со стандартным набором элементов управления. Не раз видел, как заказчик, который наотрез отказывался посмотреть разработанный интерактивный прототип, увлеченно обсуждал предлагаемые проектные решения, выполненные с использованием MS Visio, и рисовал очень интересные каракули на макетах, распечатанных на бумаге в цвете, выполненных в стиле привычного ему Windows.

3. Если вы разрабатываете новую подсистему, а ваш заказчик - продвинутый пользователь, то интерактивные прототипы вне конкуренции. При этом с наилучшей стороны показал себя подход, когда эти прототипы строятся на основании того же самого фреймворка, который используется для создания интерфейса пользователя. В случае одного из моих успешных проектов прототип программного обеспечения строился на основе инструментов DHTMLX. Вместо базы данных для имитации работоспособности использовались статичные XML-файлы, сформированные на основе примеров таблиц, которые предоставил заказчик. Представления ( view ), созданные аналитиками в ходе прототипирования, использовались как заготовки для работы программистов. За счет низкого порога вхождения по использованию данного фреймворка, трудозатраты аналитиков на создание прототипов пользовательского интерфейса были соизмеримы с трудозатратами, если бы те же макеты экранных форм создавались в MS Visio. Правда, при этом некоторые представители заказчика не понимали, что еще надо программировать после того, как им продемонстрировали «рабочую программу».

Неоднократно, приводя все эти доводы продвинутым разработчикам, далеким от проблем заказчика, я видел их тускнеющий взгляд и выслушивал их экспертную оценку убогости и перегруженности предлагаемого UI. Однако со временем, проанализировав опыт нескольких проектов, я подметил удивительную закономерность: если программист рьяно критикует отсталость и сложность разрабатываемых пользовательских интерфейсов, это верный признак того, что заказчик примет такой интерфейс на «ура».

Строительные леса и опалубка

Обычно люди очень много думают. Но беда в том, что они думают о проблемах, а не о решениях этих проблем.

При возведении домов применяется множество вспомогательных конструкций, которые после завершения строительства оказывается совершенно ненужными. Это строительные леса и опалубка . Что примечательно, даже непрофессионалы не пытаются оспорить необходимость затрат на закупку и обслуживание этих конструкций. В IT-индустрии, напротив, чаще видишь, как «опытный» аналитик изо всех сил стремится сразу создать проектную документацию, соответствующую всем требованиям.

Однако, на мой взгляд, без превентивного оформления и согласования проектных решений, созданная проектная документация годится только для формального закрытия договора и в дальнейшем больше вредит эксплуатации, чем помогает. Вместе с тем, описанные выше проектные решения и прототипы не являются единственными «вспомогательными конструкциями» в аналитической работе.

Источник

На первый взгляд, кажется, что все зависит от опыта аналитика, и регламентировать применение этих вспомогательных работ невозможно. Например, как учесть и регламентировать работу аналитика, который целый день провел в гостях у заказчика и на следующий день притащил три гигабайта всяческих документов? Или то, что аналитик потратил неделю на изучение этих документов? Это хорошо или плохо? И на самом деле вы не сможете ответить на этот вопрос, если не будете знать результаты, которые имеют смысл в свете реализации проекта.

Именно поэтому в рамках нашего проекта была проведена классификация выполняемых аналитических работ с позиции достигаемых результатов. Кроме проектного решения, большинство программных проектов, в реализации которых мне пришлось поучаствовать, требовали со стороны аналитика разработки аналитических материалов следующих типов.

• Анализ документов - отчет по результатам анализа нормативных документов заказчика или проектной документации.

• Аналитический обзор - отчет по результатам анализа путей решения возникшей проблемы (как правило, сравнительный анализ новых технологий или тенденций рынка).

• Информационное обследование - отчет по результатам проведенного исследования существующих бизнес-процессов заказчика (формирование модели as is - « как есть »).

• Системный анализ - материалы, описывающие в терминах разработчиков способ реализации требований заказчика одного из вариантов использования программного обеспечения ( use case ). Этот же тип аналитической работы организуется в случае необходимости реинжиниринга legacy-кода.

• Анализ данных - отчет по результатам исследования качества данных, загруженных в систему (выявление ошибок и противоречий).

• Учебные материалы - материалы, подготовленные для проведения обучения сотрудников заказчика или членов проектной группы.

Вторым шагом к предсказуемому проектированию стало определение конкретных требований к предполагаемым результатам аналитической работы. На основе этих требований для каждого типа разрабатываемых аналитических материалов был определен свой шаблон описания задачи JIRA.

Постановка задачи на разработку аналитических материалов предполагает краткое описание требуемых результатов, а не описание процессов анализа. Так, например, рекомендуется избегать формулировок типа «провести анализ предметной области...» или «изучить документ».

План для маэстро

Всё должно быть изложено так просто, как только возможно, но не проще.

Зачастую, когда речь заходит о планировании работ по анализу и программированию, возникает множество споров о том, как можно оценить сроки получения результатов в этом случае. Однако проведенный выше анализ этой творческой деятельности позволяет сделать предположение о том, что в рамках программного проекта это все-таки возможно. Первым шагом к этому становится разбиение работ по проектированию системы на части, которые можно проконтролировать с периодичностью не менее раза в неделю. Необходимо стремится к тому, чтобы трудозатраты аналитика на формирование одного проектного решения не превышали 5 рабочих дней (в терминах объема такое проектное решение должно состоять примерно из 20-30 страниц – согласно ГОСТ Р ИСО/МЭК 15910-2002 ). Соответственно по тем же нормативам на рецензирование того же проектного решения у программиста должно уходить максимум 3 часа.

Важно понимать, что не надо делать из проектного решения технический проект . Проектное решение должно охватывать только небольшую группу взаимосвязанных требований, результат выполнения которых можно предъявить заказчику.

При формировании проектного решения также важно не попасться в ловушку, о которой предупреждают Мэри и Toм Поппендик , а именно - не стать заложником мифа, что созданная заранее подробная спецификация гарантированно сокращает потери. Как правило, при согласовании проектного решения заказчик пытается впихнуть в этот документ все, что только может вспомнить. Поэтому при его согласовании важно обеспечить тот необходимый минимум который обеспечит успешное прохождение предварительных испытаний. При этом залог успеха - это не только сочетание качества, сроков и стоимости, но и удовлетворенность участников проекта его результатами.

Как правило, для получения сроков выполнения задач на анализ, достаточно экспертной оценки самого исполнителя, но в случае возникновения споров можно применить прагматичный подход . Для повышения объективности оценки трудоемкости задач на анализ может быть использован online-калькулятор, который позволяет спланировать и оценить трудозатраты на проведение аналитической работы. С использованием данного инструмента можно сформировать перечень запланированных работ, уточнить их формулировки в зависимости от специфики проекта. Для каждой из планируемых работ учитывается минимальная, максимальная и наиболее вероятная оценка трудозатрат. В результате расчета формируется ожидаемая трудоемкость выполнения задачи и рассчитывается оптимальный резерв времени, который необходимо оставить для страховки. Сформированное описание постановки задачи на анализ можно скопировать прямо в поле описания задачи JIRA.

Кроме общих атрибутов, для каждой задачи типа «анализ» в JIRA опытным путем был определен следующий набор дополнительных (пользовательских) атрибутов.

С учетом вышеизложенного, уточним ранее приведенную последовательность действий аналитика по реализации задач типа «анализ» в интересах разработки программного обеспечения.

1. В случае необходимости ответственный аналитик должен запланировать в JIRA задачи на проведение информационных обследований с представителями заказчика (эти задачи связываются с соответствующими требованиями).

Желательно до встречи в первом приближении сформировать макеты пользовательского интерфейса , которые можно будет обсудить с заказчиком. При проведении информационного обследования необходимо обсудить с заказчиком основной бизнес-процесс, с его точки зрения (пользовательскую историю - user story ), альтернативные пути, в каком виде заказчик видит конечный результат.

Неоднократно встречался с мнением, что основой информационного обследования является интервьюирование компетентного сотрудника, который подробно расскажет об особенностях автоматизируемого процесса. Однако что хорошо для разработки в интересах коммерческого заказчика, для государственного может иметь самые неожиданные последствия. Неоднократно сталкивался с ситуацией, когда оказывалось, что описание процесса, сформированное на основе рассказов седых ветеранов, противоречит ключевым требованиям действующих нормативных документов. И это объяснялось не тем, что аналитик чего-то недопонял, а тем, что ветеран «всю жизнь так делал».

Поэтому перед встречей с экспертами предметной области, необходимо проанализировать нормативные документы, с точки зрения регламентации процесса, предполагаемого к автоматизации. При этом важно понимать, что нормативные документы - это тоже не истина в последней инстанции Зачастую, в нормативных документах при беспристрастном анализе всегда находятся неоднозначности и противоречия (исключением, как правило, являются документы «написанные кровью»). Отмечу наиболее распространенные разногласия, на наличие которых следует обратить внимание:

• нарушение базовых принципов классификации , например, когда в рамках одной группы смешиваются разные признаки (красное, зеленое, теплое);

• построение отчетных документов на основе атрибутов, учет которых не предусмотрен;

• неопределенность или недостаточность нормативных атрибутов для однозначной идентификации объектов учета;

• отсутствие описания требуемых действий при типовых форс-мажорных обстоятельствах;

• юридические коллизии - наличие расхождений или противоречий в содержании отдельных нормативно-правовых актов, которые регулируют одинаковые или смежные процессы.

Решение этих нормативных конфликтов является одним из ключевых вопросов при встречах с представителями заказчика. Для того, чтобы зафиксировать это решение, в результате проведения информационного обследования в обязательном порядке должен быть сформирован протокол с указанием участников, места и времени проведения. Протокол представляется заказчику на уточнение (e-mail прикрепляется к соответствующей задаче). После этого задание на информационное обследование можно переводить в статус «выполнено». В статус «закрыто» эта задача JIRA переводится после получения от заказчика подтверждения о согласовании протокола.

2. На основании уточненных требований и результатов информационных обследований формируется проектное решение. Ответственный аналитик должен согласовывать его с руководителем проекта и программистами (для каждого из них создаются соответствующие подзадачи). В случае, если проектное решение не прошло внутреннего согласования в течение рабочего дня, задача переводится в статус «ожидание» (сигнал для руководителя проекта). Пройдя внутреннее согласование, проектное решение отправляется заказчику для ознакомления (при необходимости – согласования). Все реквизиты отправки фиксируются в комментариях к задаче. На время нахождения проектного решения на стороне заказчика задача переводится в статус «ожидание».

3. Если проектное решение согласовано (или если понятно, что согласование затягивается, а сроки поджимают), то на его основании ответственным аналитиком формируются задачи на разработку, тестирование и документирование. При этом необходимо осуществить предварительную оценку трудозатрат на реализацию проектного решения (как сумму трудозатрат задач разработки, связанных с этим проектным решением). На основании этой оценки необходимо уточнить сроки реализации связанных требований.

4. После согласования с заказчиком (письмо, подтверждающее этот факт, сохраняется в JIRA), задачу по подготовке проектного решения можно переводить в статус «выполнено».

Продолжение следует

В настоящее время проектирование программного обеспечения для государственных заказчиков чаще всего организуется в соответствии с требованиями ГОСТ 34 серии. При этом, ратуя за точное соответствие итоговой проектной документации этому ГОСТ, зачастую большинство представителей заказчика «забывают» о том, что кроме документации, которая предоставляется на испытания разработанного ПО, со стороны заказчика в рамках согласования эскизного и технического проектов должны быть утверждены проектные решения. И даже в том случае, когда согласовываются эскизный и технические проекты, не редкость, когда в угоду нереальным срокам при полном соблюдении формы игнорируется содержание. Особенно это характерно для проектирования систем, напрямую не связанных с безопасностью жизнедеятельности. Так на одном из проектов один заместитель руководителя «учил жизни», рассказывая о том, как он сформировал с помощью Википедии 500-страничный технический проект за одну ночь. Расхлебывать результаты таких «проектных решений» приходится, как правило, совсем другим людям.

В этих непростых условиях описанные здесь подходы позволяют организовать итеративное наращивание функциональности программного обеспечения с сохранением системности внедряемых решений, что соответствует принципам бережливой разработки ПО . С другой стороны, целевые установки описанных проектных решений позволяют с минимальными затратами скомпилировать на их основе документы, соответствующие «прокрустовым» требованиям заказчика.

Разбиение аналитической работы на элементарные действия также позволило координировать действия нескольких сотрудников с разным уровнем подготовки и, как следствие, естественным образом сформировать матрицу компетенций для аналитиков нашего проекта, которую я планирую обсудить в следующей статье.