Если вы не знаете, в каком направлении развивать проект, то он вряд ли выберет нужный путь самостоятельно.
Стив Макконнелл

Введение

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

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

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

Для достижения поставленных целей заказчику и исполнителю совместно нужно решить ряд вполне определённых задач:

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

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

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

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

Рисунок 1. Деятельность участников проекта на предварительном этапе.

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

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

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

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

Формулирование цели и задач будущего проекта

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

При формулировании цели и задач проекта должен быть создан документ, дающий ответы на следующие вопросы:

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

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

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

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

Почему изложенные выше вопросы важно решить в самом начале?

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

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

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

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

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

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

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

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

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

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

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

Плановая дата даёт ориентир для разработчиков. При этом нужно помнить о неопределённости проекта, которая может как сократить время работы над проектом, так и значительно увеличить его, причём второе гораздо более вероятно, чем первое. Плановая дата должна уточняться по мере развития проекта.

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

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

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

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

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

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

Разработка концепции проекта

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

Года два назад одна из команд департамента, где я работал в то время, должна была подготовиться к тендеру на разработку очень большой и сложной системы для одной из ведущих транспортных компаний России. Я в то время работал над другими проектами. Однако спустя некоторое достаточно продолжительное время после начала работ руководитель проекта обратился ко мне за помощью. Проблема проекта была в том, что никто из участников не понимал, как должна работать система. Возможно, в этом виноват масштаб системы и отсутствие опыта у команды для работы со столь сложными проектами. Но первое, что я нашёл, начав погружаться в тему, — полное отсутствие у команды уверенности в успехе. И второе – отсутствие понимания, как вообще взяться за проект. Несмотря на то, что прошло уже более месяца, главным вопросом оставался один: что спросить у заказчика, чтобы хотя бы начать работу?

Смешного тут ничего нет. Каждый специалист чаще всего является специалистом в своей области. Здесь же требовался человек, который мог бы впитать в себя весь гигантский объём ожиданий заказчика и при этом имел достаточно опыта разработки сложных информационных систем, чтобы выразить идею заказчика в виде реалистичного решения. Чем больше объём будущей системы, тем больше требуется навыков и знаний от разработчика концепции. Если в команде не оказывается такого специалиста, проект буксует. В наших проектах за разработку и дальнейшее сопровождение концепции отвечает системный архитектор. Он же отвечает за то, чтобы продукт реализовывался в точном соответствии с концепцией. И я не советую привлекать на эту позицию разработчиков, пусть даже опытных: очень редко талант написания качественного кода сочетается с умением вести диалог с заказчиком, и ещё реже программист желает подчиняться концепции.

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

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

И был день, когда мы всей командой собрались в переговорной. И я рассказал, каким я вижу разрабатываемую систему. Своё видение мне пришлось отстаивать, отвечая на большое количество вопросов. Но чем больше вопросов получало ответы, тем больше уверенности становилось у команды. Они поверили, что эту огромную систему они смогут сделать. Они снова были свободными и могли творчески решать свои сложные задачи.

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

Концепция – это магия. Если архитектура – это скелет проекта, то концепция – это его дух. Нет концепции, и от проекта остаётся бездыханное тело, от которого в скором времени начинает смердеть. Но когда она есть, проект развивается, и чем качественнее выполнена концепция, тем более здоровым будет проект, и тем более уверенными и успешными будут участники проектной команды.

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

Помните: если нет концепции – проект мёртв. Если какая-то часть проекта не поддерживается концепцией, эта часть проекта или отмирает, или заражает другие части проекта, и тогда умирает весь проект. Если концепция есть, но не соблюдается в полной мере, то проект будет то и дело буксовать и в конечном итоге выйдет за пределы приемлемых сроков и бюджета. Если концепция команды отличается от того видения, которое было согласовано с заказчиком, то вы делаете не ту систему, которую вас просили делать. Компромиссов в этих утверждениях я ни разу не видел.

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

Вдохните дух концепции в ваш проект, заботьтесь о его здоровье и никогда его не теряйте.

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

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

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

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

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

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

Разработчик концепции должен ответить на следующие вопросы:

Будет ли система распределённой географически? Если да, то на какие компоненты она будет разделена и где каждый компонент будет/может быть развёрнут? Какие каналы связи между распределёнными компонентами будут/могут использоваться? Имеются ли каналы связи в наличии у заказчика, или их предстоит создать? Будут ли каналы связи собственными, или они будут арендоваться? Кто будет ответственным за аренду каналов связи: заказчик или исполнитель?
Какие программные средства будут входить в каждый компонент системы? Как отдельные программные средства будут взаимодействовать между собой в составе компонента системы?
Какая аппаратная и программная платформа будет использоваться для развёртывания каждого программного средства системы? Будет ли исполнитель отвечать за закупку, развёртывание и сопровождение среды выполнения?
Какие из сформулированных заказчиком задач будет решать то или иное программное средство? Как оно будет решать поставленные задачи? Как будут обеспечиваться функциональные показатели качества системы?
Как будет осуществляться взаимодействие программных средств системы с пользователем и внешними информационными системами? Какие интерфейсы и сервисы система будет предоставлять наружу? Как будут обеспечиваться нефункциональные показатели качества?
В конечном счёте, главный вопрос: как система в целом будет решать поставленные заказчиком задачи с учётом установленных ограничений?

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

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

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

Если заказчик не боится UML-схем, покажите ему диаграммы последовательности: они очень наглядно демонстрируют, как взаимодействуют друг с другом разные компоненты системы. Можно привести диаграммы деятельности. Однако не переусердствуйте: диаграммы в концепции нужны только для иллюстрации принципа работы программы, не более того.

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

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

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

Анализ востребованности разрабатываемой системы

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

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

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

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

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

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

Предварительная оценка рисков и неопределённостей проекта

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

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

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

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

Подготовка предварительного технического решения

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

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

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

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

Предварительное техническое решение должно содержать указание на аппаратное и программное обеспечение, которое потребуется приобрести для обеспечения разработки или эксплуатации разрабатываемой системы. Например, для работы с криптографическими алгоритмами ГОСТ Р 34.10/34.11-2001, используемыми для создания и проверки электронной цифровой подписи, может понадобиться лицензия на криптопровайдер, который поддерживает эти алгоритмы. Если планируется использовать управляемый код, то в дополнение к криптопровайдеру может потребоваться дополнительное программное обеспечение. Другой пример – библиотеки визуальных компонентов для пользовательского интерфейса. В ряде случаев потребуется закупать аппаратное обеспечение для развёртывания системы. Расходы на подобные закупки могут быть весьма существенными и обязательно должны оцениваться при анализе реализуемости разрабатываемого ПО.

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

Выбор методологии разработки продукта

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

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

Подготовка предварительного плана работ

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

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

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

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

Разумно не только определить список задач, но и указать их примерную длительность, зависимости и исполнителей, а также требуемую инфраструктуру.

Длительность задачи должна учитывать время, реально затрачиваемое на её решение, а не «идеальные» часы. Хорошие результаты даёт использование фокус-фактора при получении реальных оценок. В данном случае фокус-фактор я заимствую из практик agile, где он определяется как количество «идеальных» часов, отводимых на решение комплекса задач, делёное на количество времени, реально затраченного на решение [3]. Так, если в идеале на реализацию некоторой задачи программист потратил бы 4 часа, то, используя фокус-фактор 0,55, получим реальную длительность работы над задачей почти 7,5 часов. Разница значительная, и её обязательно нужно учитывать.

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

Удобно выразить длительности и зависимости задач с помощью диаграммы Ганта [4]. Это даст представление о том, какие задачи могут или должны выполняться параллельно (и, соответственно, для них нужны разные исполнители), а какие – последовательно. Появится возможность выявить критические цепочки задач и попытаться их оптимизировать. Также такое представление даст сроки, к которым следует набирать персонал или развёртывать/обновлять/освобождать компоненты инфраструктуры проекта.

Ещё один значимый положительный эффект плана – возможность разбить весь объём работ на несколько небольших этапов поставки и тем самым сделать проект более гибким и предсказуемым. Выпуская на каждом этапе поставки готовый продукт с определённым набором функций, можно своевременно получить отзыв заказчика, что очень важно при работе в сложных предметных областях. Я обычно делаю этапы поставки длительностью 4-6 недель.

Предварительная оценка трудозатрат, требуемого персонала и ресурсов

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

Обычно, я даю оценки по этапам для каждого исполнителя и каждого ресурса с указанием процента их занятости, затем даю итоговую общую оценку. Например, для этапа реализации небольшого проекта может потребоваться участие архитектора (50% его времени), аналитика (25%), администратора, сопровождающего инфраструктуру (10%) и трёх разработчиков с полной занятостью. Этап длится 6 недель (30 рабочих дней), так что архитектор будет занят 15 дней, аналитик – 7, администратор – 3, а каждый из разработчиков – все 30 дней. На основе этих трудозатрат можно рассчитать расходы на персонал. На те же 30 дней команде нужны система трекинга задач, система контроля версий, пара виртуальных машин для тестирования, виртуальная машина с развёрнутой СУБД и что-то ещё, специфичное для проекта. Кроме того, нужна лицензия на использования криптопровайдера, сертификаты и контейнеры закрытых ключей для каждого стенда и персонально для каждого разработчика, чтобы можно было использовать цифровую подпись.

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

Всё вместе позволяет сделать общую оценку сроков и бюджета для реализации рассматриваемого решения. Но поскольку в проекте очень много неопределённостей, решить которые на подготовительном этапе невозможно, важно понимать, что реальная стоимость и длительность проекта, как и реальная длительность привлечения специалистов и ресурсов, могут значительно отличаться от полученных оценочных значений. Отклонения могут составлять до 100% в сторону превышения оценок и до 50% в сторону снижения [5].

Анализ реализуемости технического решения

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

Обычно для ответа на вопрос, реализуемо ли предлагаемое решение, нужно ответить на следующие вопросы:

Соответствует ли решение целям и задачам, сформулированным заказчиком?
Соответствует ли решение принятой концепции?
Реализуемо ли решение технологически?
Применима ли для решения выбранная методология?
Корректна ли оценка сроков и бюджета, сделанная исполнителем для данного решения?
Каковы могут быть отклонения реальных значений сроков и бюджета относительно оценок?
Укладывается ли решение в ограничения на срок и бюджет, указанные заказчиком?

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

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

Независимое рецензирование предварительного решения

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

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

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

Однако ответить на эти вопросы заказчику сложнее. Хорошо, если заказчик имеет собственное IT-подразделение, в котором работают достаточно компетентные специалисты. Чаще заказчик вынужден привлекать независимых аудиторов, которые проводят анализ реализуемости предложенного исполнителем решения. На основе экспертного заключения заказчик принимает или отвергает решение исполнителя.

Завершение подготовительного этапа – подписание договора

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

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

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

Итог

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

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

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

Будьте внимательны и ответственны при закладке краеугольного камня вашего проекта. Вы будете им гордиться!

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

Максим Кузнецов. Обзор процесса разработки программного обеспечения – habrahabr.ru, 2015 (http://habrahabr.ru/post/255991/).
Максим Кузнецов. Применение agile при разработке проекта для государственного заказчика – megamozg.ru, 2015 (http://megamozg.ru/post/14554/).
Vishal Prasad. Agile Forecasting with Focus Factor – scrumalliance.org, 2014 (https://www.scrumalliance.org/community/articles/2014/july/agile-forecasting-with-focus-factor).
Сергей Рогачёв. Планирование и отслеживание итеративной разработки с помощью Microsoft Project – agilerussia.ru, 2012 (http://agilerussia.ru/practices/planning-ms-project/).
Стив Макконнелл. Остаться в живых. Руководство для менеджеров программных проектов – СПб.: Питер, 2006.

Подготовительный этап разработки программного обеспечения