Авторы: Алексей Киселев, Екатерина Душечкина

В компаниях, занимающихся разработкой ПО, зачастую отсутствует хотя бы какая-то практика хранения и систематизации своих наработок.

Это приводит к тому, что аналитик, получив задачу, сразу же начинает исследовать проблему с нуля, изучать предметную область, собирать требования, анализировать их, выявлять зависимости и т.д. Это большой объем трудозатрат, которых можно было бы избежать (или хотя бы сократить) при рациональном хранении артефактов (можно сказать – опыта), накопленных на предыдущих проектах.

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

Последствия

Каковы же последствия для компании?

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

Во-вторых, и это наиболее важно, – потенциальная экономическая выгода накопления и использования опыта.

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

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

Для наглядной демонстрации получаемой выгоды представим, что компания последовательно ведет несколько проектов разработки различных систем, каждая из которых предполагает одну и ту же функциональную возможность. Теперь возьмем такой показатель, как X чел./часов аналитики на реализацию этой функциональной возможности и Y руб. – стоимость 1 чел./часа работы аналитика.

Заново описывая данную функциональность в каждом проекте, мы получим (Y*X*количество идентичных систем) затрат компании на анализ требований и подготовку документации.

Предположим, что одну и ту же (уже написанную) постановку можно использовать в других проектах компании. Тогда затраты компании снижаются до (Y*X), а возможная экономия составляет:

Y*X*(количество идентичных систем-1)

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

Причины отсутствия типовой документации в компании

Основные факторы, мешающие созданию “типовой” документации и использованию накопленного опыта:

1. Отсутствие хорошо систематизированного и общедоступного ресурса для хранения документации с развитым инструментом поиска.
   • Зачастую в компании нет единого ресурса, где аналитик сможет посмотреть, вела ли компания похожие проекты и документацию по ним.
   • Аналитик не всегда может найти документ при помощи стандартных средств поиска, если нет единых требований к именованию документов и т.д. А просматривать все постановки по схожим проектам, в поисках аналогичной функциональности, требует изрядной доли терпения (проблема поиска нужной документации подробно рассмотрена ниже) – быстрее и интереснее продумать и написать заново.
   • Аналитик может не иметь доступ ко всем проектам компании.
2. Отсутствие стандартов разработки и работы с документацией. Допустим аналитик все-таки нашел нужную постановку, но возникает другая проблема – проще заново проработать постановку, чем пытаться разбираться в чужой, т.к.:
   • Отсутствует связь между предлагаемым решением и бизнес-потребностью.
   • Постановка явно не актуализирована.
   • Стили автора и текущего аналитика существенно различаются.
   • Постановка вызывает ряд вопросов у аналитика, которые требуют повторной проработки задачи.
3. Руководство и участники проектной группы инертны в вопросах, касающихся изменений в подходах ведения проектов / документации.

Ниже мы попробуем предложить наше видение методов преодоления обозначенных проблем.

Предлагаемый вариант решения

Основополагающими идеями предлагаемого подхода к решению первых двух проблем являются:

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

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

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

Ведение единого репозитория

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

Здесь стоит отдельно обсудить наличие эффективного инструмента поиска, т.к. это является, пожалуй, наиболее критичным и проблемным условием. Поясним почему: при большом объеме артефактов в хранилище, да еще и разного рода (документы различного формата, модели, видео-, веб-, аудио-контент и т.д.),  аналитику может понадобиться значительное количество времени на поиск нужных постановок и не факт, что:

1. Ему хватит на это терпения и мотивации.
2. Ему дадут это сделать, ибо зачастую “постановка нужна была ещё вчера” и менеджер и слышать не хочет о том, что постановки – это большие документы, в которые вкладывается довольно много человекочасов, потому лучше затратить время на поиски, чем создавать все заново.

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

Исходя из вышеописанных тезисов, можно сразу отмести такие простые инструменты контроля версий, как SVN и VSS (они не обеспечивают наших требований к поиску). Если удастся доказать руководству и менеджерам, что лучше потратить время на поиски документации по схожей функциональности, чем второпях писать постановку, которая будет иметь большое количество пробелов (со всеми вытекающими из этого последствиями), то нас могут устроить решения Microsoft SharePoint или IBM Lotus. Однако идеальным вариантом была бы разработка нового решения.

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

Подход к работе с документами, структура хранилища

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

Если говорить о стандартах разработки и именования документации, то здесь каждой компании необходимо отталкиваться от специфики своей проектной деятельности. Единственным требованием является обязательное соблюдение принятых стандартов всеми аналитиками компании и регулярный аудит (о наличии такой отдельной службы мы уже упоминали выше). Отдельно стоит оговорить важность выполнения требований к именованию документов, размещенных в хранилище, т.к. это во многом определяет успешность дальнейшего поиска нужной информации. Ведь если структура именования постановок – <Проект>_<Номер требования> (например, “PROJECT1-REQ12”), то по названию мы не сможем понять, что это за требование. Другое дело, если мы именуем постановки следующим образом:

<Тип документа>_<Проект или заказчик>_<Предметная область>_<Бизнес-требование или название экранной формы>

Например: ПОСТ_Заказчик_Финансы_ДополнительнаяЭмиссия.doc.

Видим, что уже по названию можно понять о чем речь в постановке.

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

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

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

В упрощенном виде процесс работы с документами раздела “типовая” предлагается организовать следующим образом:

1. Первым шагом является принятие решения о добавлении постановки в данный раздел. Т.к. раздел предназначен для типовой документации, то основными критериями включения постановок в него являются прогнозируемая потребность в реализации аналогичных функциональных возможностей в последующих проектах. Здесь сложно дать какие-либо точные метрики, так что назовем это неким “искусством менеджера и аналитика” в принятии решения.
2. После того, как решение о добавлении в хранилище принято, постановка проходит верификацию на:
   • Соответствие принятым в компании стандартам ведения документации (нормоконтроль). В случае выявления отклонений от стандартов постановка отправляется на доработку автору и затем проходит повторную верификацию. Задача существенно упрощается при наличии чек-листа, в котором указаны требуемые формулировки, требования к оформлению и т.п. Исходя из опыта, эту задачу зачастую берет на себя руководитель аналитического отдела, ведь именно он располагает достаточным административным ресурсом, чтобы “продвигать” единое для всех аналитиков группы видение “идеальной постановки” В противном случае есть риск, что аналитики потратят множество своего времени дабы прийти к общему знаменателю в споре за образец такой постановки.
   • Качество содержания постановки. Проблема проверки качества содержания постановки весьма глубока. Конечно, можно предложить проводить специализированную экспертизу, анализировать потребность внесения изменений и т.д., но какого-то общего универсального подхода у нас еще не сложилось. Поэтому оставим этот вопрос пока в стороне и, возможно, вернемся к нему в следующей статье.
3. Как только процесс верификации пройден с положительным результатом, постановка добавляется в хранилище, при этом автор постановки должен указать поисковые атрибуты и уникальный идентификатор. На данном шаге можно применить специализированные средства, в том числе бесплатные, индексирующие документ по тем или иным принципам и составляющие “Поисковый образ документа”.
4. Далее следует этап хранения постановки, на котором все аналитики компании могут свободно повторно использовать постановку в своей деятельности. Для анализа востребованности документации на этом этапе можно ввести такие полезные метрики, как “Частота обращений”, “Потребность внесения изменений”, “Частота повторного использования”.

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

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

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

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

Преимущества и недостатки использования предложенного подхода

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

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

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

Y*X*(количество идентичных систем-1) - (K + M + L),

где K - дополнительные затраты на универсализацию требования (описание параметров, например).

L - общие затраты на адаптацию постановки под каждую новую ситуацию / проект и т.д. Тут есть зависимость от параметра K - чем качественнее (а, соответственно — дольше) универсализировали и параметризировали постановку, тем меньше времени будет тратиться ка каждую адаптацию.

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

Учитывая, что L одного проекта всегда будет меньше, чем X*Y (в противном случае — это просто совершенно разные постановки), получается, что чем больше типовых проектов — тем больше средств было сэкономлено компании.

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

            6*X*(4-1) - (3*X + 5*X (на данном этапе это раздел в Конфлюенс) + 3) -> 4X при 4 проектах

Заключение

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

В завершение, мы хотели бы выразить благодарность Эдуарду  Галиаскарову за конструктивную критику и плодотворные идеи, многие из которых существенно повлияли на описанную нами концепцию.