Читать книгу "Искусство управления IT-проектами - Скотт Беркун"

Рис. 5.1. Проектирование зачастую выглядит как некий таинственный переход от первичного планирования к выработке технических условий

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

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

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

Качественные требования и ошибки

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

Требования имеют решающее значение. Они являются отправной точкой для зарождения идей и потенциальных решений. Если в требованиях определено, что «это будет сарай зеленого цвета», то все задействованные в проектировании специалисты будут думать о всем разнообразии зеленых сараев. Из этого можно извлечь двоякую пользу. Во-первых, из рассмотрения исключается масса ненужных идей (можно будет с легкостью поставить на место тех, кто уже заготовил эскизы голубых космических кораблей). Во-вторых, проектировщики получают возможность задавать вопросы, ведущие к дополнительным исследованиям требований. Эти вопросы могут быть вполне конкретными, например: «Подойдут ли светлые оттенки зеленого или нужен только темно-зеленый цвет? Какова должна быть площадь сарая?», или более общими, например: «Для чего будет использоваться сарай? Предусматривается ли чердак? Он и обойдется недорого, и в хозяйстве пригодится». В зависимости от того, кто несет ответственность за выработку требований и проектирование (см. главу 3), принимать решения, какими должны быть ответы на эти вопросы или предлагать их измененные варианты, будут разные люди, наделенные соответствующими полномочиями. Но стремление задавать вопросы, уточняющие требования и повышающие их качество, должно поощряться.

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

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

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

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