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

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

Как проводить обсуждение технических условий

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

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

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

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

Кто должен присутствовать и как все должно происходить

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

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

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

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

Список вопросов

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

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

Вот мой перечень вопросов, пересмотр и дополнение которого только приветствуется.