Помоги проекту - поделись книгой:
• Упростить:
• убрать дополнительные элементы управления, которыми никто не пользуется;
• улучшить формат страницы результатов поиска;
• сократить количество одновременно отображаемых результатов.
• Сориентировать на потребителя:
• позволить пользователям устанавливать индивидуальные предпочтения в отношении внешнего вида страницы;
• открывать результаты в новом окне.
• Реконструировать архитектуру:
• провести доводку системы обработки запросов (включить поддержку логического поиска);
• устранить ошибки, замедляющие работу поисковой машины;
• использовать улучшенную поисковую машину HyperX.
Представленная здесь группировка элементарно проста, и поскольку в ней всего восемь идей, она безупречна. Но если бы она состояла из 40 или 50 идей, не все пошло бы столь гладко. В списках отражаются предположения о линейных и иерархических зависимостях, поэтому с длинными списками справиться намного труднее. Позднее, в процессе разработки, списки придают процессу неплохое ускорение, но на ранних стадиях диаграммы сходства намного эффективнее. Они помогают людям рассматривать идеи в качестве подвижных и осязаемых объектов, способных к перемещениям и перегруппировкам. Эта подвижность позволяет людям подвергать сомнению их предположения, видеть новые перспективы и воспринимать мысли других. Для команд, не искушенных в творческом мышлении (особенно в составе группы), диаграмма сходства является великолепным выходом из положения. Позднее вы, как руководитель проекта, можете воспользоваться списками для своих собственных целей, но сначала дайте команде поработать над сходствами. Я убежден, что такая работа помогает людям втянуться в процесс и отыскать больше удачных идей.
Оптимизация и расстановка приоритетов
Не старайтесь добиться наилучшего варианта группировки, лучшее – враг хорошего. Существует немало вариантов группировки даже небольшого количества идей, и многие из них дают хорошие результаты. Целью должно быть создание четырех или пяти групп, охватывающих различные области или обозначающих различные направления. Некоторые идеи просто не укладываются ни в одну из групп, но вам все равно следует поработать над ними в полную силу.
Следует помнить, что если понадобится, позже можно будет вернуться к идеям и перегруппировать их заново. Как только вы найдете вполне приемлемый вариант, идите дальше. Вам же не нужно предоставлять диаграммы сходства или списки идей конечному пользователю, поэтому и не стоит перенапрягаться.
Последнее, что нужно обдумать, – примерную расстановку идей по приоритетам (вопросы формального деления по приоритетам рассматриваются в главе 12). Какие идеи являются наиболее многообещающими? Обратитесь к концепции проекта и к решаемым проблемам и добейтесь общего понимания реальных оценочных критериев, поскольку в идеи нетрудно влюбиться на основаниях, никак не связанных с целями проекта. Этим процессом должен управлять кто-то один, либо руководитель проекта, либо ведущий проектировщик. Чем неформальнее будет дискуссия, тем меньше времени на нее уйдет. Необязательно составлять сложный контрольный список критериев и оценочных процедур. Перед тем как перейти к разработке прототипа, вам понадобится всего лишь примерная прикидка, какое из направлений представляется более перспективным. Это позволит правильно распорядиться временем в условиях его дефицита.
Прототипы – ваши друзья
В главе 5 я объяснил, почему проектирование является исследовательским процессом. Чтобы понять, какие альтернативные варианты существуют, вам необходимо исследовать пространство проблем. Хороший проектный замысел зависит от знания альтернативных вариантов, поскольку чем больше информации о проблемах и решениях находится в вашем распоряжении, тем проще принимать правильные решения. Подготовка прототипов является следующим естественным шагом процесса проектирования. Они вбирают в себя все, что было изучено, и используют этот багаж для решения проблем, причем без рисков, свойственных полноценной реализации. Прототипы следуют плотницким принципам – семь раз отмерь, один раз отрежь, повышая продуманность проекта, перед тем как команда сверстает план. И, как я объясню чуть позже, прототипы не нуждаются в тщательной проработке или затрате существенных средств, как и не требуют много времени. Если вы скептически относитесь к ценности прототипов, прочтите сначала раздел «Прототипы – это опора программистов».
С чего начинаются прототипы?
Создание хороших прототипов возможно при наличии четырех-пяти групп идей. Наряду с тем, что люди с более развитыми творческими навыками могут заранее увидеть альтернативные направления, группировка идей поможет команде определить количество имеющихся вариантов. При наличии двадцати-тридцати идей существуют сотни способов их комбинирования, не считая вариантов интерпретации каждой отдельно взятой идеи.
У опытного проектировщика вырабатываются здоровые инстинкты относительно того, с чего начать работу. Он легко сможет отсортировать имеющиеся идеи и принять решение по поводу тех, на основе которых создавать первый прототип (абстрагируясь от того, как именно это делать). Но если проектирование ведется без участия опытного специалиста, для выбора основы для прототипа можно воспользоваться несколькими простыми приемами.
• Выберите наиболее многообещающую идею из каждой группы и попытайтесь скомбинировать эти идеи в единый замысел.
• Создайте небольшие прототипы для каждой группы и посмотрите, к чему это приведет. Можно ли решить все необходимые проблемы путем модернизации архитектуры или добавления средств настройки? Посмотрите, насколько каждое из направлений соответствует замыслу.
• Учтите мнение проектировщика: разрешите ему воспользоваться собственным опытом и интуицией для решения, что нужно использовать в первой попытке.
• Создайте перечень наиболее сложных или важных вопросов проектирования и создайте прототип или несколько прототипов, помогающих на них ответить.
Как правило, чем сложнее будет прототип, тем сложнее вопросы, на которые с его помощью можно будет ответить. Эскиз на обороте салфетки подойдет лишь для ответа на самые предварительные и приблизительные вопросы, а если вам требуется узнать кое-что специфическое и быть уверенным при ответе на заданный вопрос, нужно нечто более существенное.
При создании первых прототипов станет ясно, какими идеями можно воспользоваться дополнительно, не создавая проблем, а какие идеи в них больше не вписываются. Как и в мозаике, какие-то элементы подходят друг другу по смыслу больше, чем другие, но для поиска соответствий приходится действовать методом проб и ошибок. Поскольку мы имеем дело с массой деталей и точек зрения (пользовательских, деловых, технологических), предсказать, какие направления окажутся работоспособными, а какие нет, невозможно. Но именно для этого и предназначены прототипы: учиться на ошибках, исправлять их и двигаться дальше.
Прототипы для проектов с пользовательским интерфейсом
Прототипы должны создаваться последовательно, сверху вниз. Начните с того, что должны видеть пользователи, и в той последовательности, в которой они все это должны видеть. Для получения вполне обоснованных замыслов и предположений с самого начала привлеките к работе своих специалистов по потребительским свойствам и дизайну. Пока не будут созданы несколько экранов, нет смысла тратить дни на выработку структур баз данных и XML-схем – это все равно что возводить стены дома еще до того, как вы узнали его планировку. Если вы это сделаете, потеря качества конечного продукта вам гарантирована – именно от этого и призваны защищать прототипы.[38]
Лучше подождите появления обещанных эскизов или моделей пользовательского интерфейса (которые лучше всего определяются после изучения потребительских свойств или воспроизведения всех решений, которые должен будет принимать пользователь в процессе работы с каждым экраном). Затем разработчики должны исследовать вопрос, как все это может быть реализовано на практике. Если подобные дискуссии начались на ранней стадии проекта, то они будут легко и естественно продолжены.
Что касается самого создания прототипов, то тут не существует никакой волшебной тайны. Чтобы понять, какие составляющие могут быть сымитированы или приукрашены, а какие потребуют дополнительных осмысления и затрат,[39] требуется лишь некоторый опыт. На практике основной принцип заключается в том, чтобы добыть требуемую информацию с наименьшим показателем трудозатрат. Основой прототипа может послужить любое средство – Flash, HTML, VB и даже бумага. В этом деле важнее искусство дизайнера и(или) создателя прототипа, чем используемая для его создания технология или инструментарий.
Прототипы для проектов без пользовательского интерфейса
Даже если проект изначально не имеет пользовательского интерфейса или отношения к Интернету, он все равно нуждается в прототипе.[40] Вместо вопросов дизайна пользовательского интерфейса нужно взять наиболее трудные или сложные технические проблемы и создать прототипы их решения. Подтвердите действенность основных алгоритмов, соответствие основным тестовым показателям или набору критериев производительности. Цель создания прототипов не зависит от типа проекта – эта работа позволяет понять, можно ли в отведенное время реализовать рассматриваемый вами примерный подход (или подходы) и обеспечивает ли он фактическое решение обозначенных проблем. Это шанс оценить риски еще до начала создания самого продукта и узнать, что нужно сделать до перехода к его созданию.
Прототипы – это опора программистов
В ситуации, когда дизайнер или руководитель проекта ведет работу по созданию прототипов, программисты и инженеры часто жалуются на свою незанятость.[41] Они могут также говорить, что данный процесс – пустая трата времени (такие заявления часто касаются всего, что не связано с созданием программного кода). В противовес этому я думаю, что программисты получают больше пользы от создания прототипов, чем кто-либо из команды. Удачно созданные прототипы значительно повышают вероятность взвешенности и высокого качества продуктов, моделируемых с их помощью. Возможно, для руководителя проекта более важным является то обстоятельство, что в период разработки прототипов у программистов появляется время на исследование новых технических подходов, которые необходимо будет применить. Если они разумно распорядятся временем, отведенным на проектирование, качество произведенного ими программного кода значительно возрастет.
Вот краткий перечень вопросов, на которые программисты должны ответить в данный период:
• Как в целом мы будем реализовывать все представленное в дизайнерском прототипе (или прототипах)? Существует ли готовый код или технология, которую нужно или можно использовать в этих целях?
• Возможны ли разумные поправки дизайна, сокращающие инженерные затраты, о которых нужно уведомить проектировщика?
• Какие пять-шесть компонентов для всего этого понадобятся и как они будут сочетаться друг с другом? Во что, по большому счету, обойдется создание этих компонентов? (Здесь подойдет вариант высоких, средних, незначительных или не поддающихся оценке затрат. Последний вариант служит поводом для программистов для начала исследований.)
• В чем заключаются наибольшие технические риски? Какие компоненты труднее или сложнее всего реализовать?
• Какие элементы взаимодействия (и между какими компонентами) наиболее сложны или имеют наибольшую склонность к отказам? (На это лучше всего сможет ответить опытный специалист по тестированию или контролер качества продукции.)
Как для проектировщика создание проектного прототипа – единственный способ уверенно ответить на сложные вопросы проекта, так и для разработчика не существует способов ответить на сложные инженерные вопросы без создания технологического прототипа (вопреки тому, что он может сказать по этому поводу). Если когда-либо возникнет потребность в создании множества прототипов, их следует создавать скоординировано. Лучше если ведущий дизайнер и ведущий разработчик потратят время на переговоры друг с другом, на расспросы и помощь друг другу в принятии верных решений. Усилия этих двух специалистов по созданию прототипов должны направляться по пути, который их, в конечном счете, концептуально объединит: идеи разработчиков и дизайнеров должны соответствовать друг другу.
Альтернативные варианты повышают вероятность успеха
Применительно к пользовательскому интерфейсу и веб-дизайну, большинство прототипов, в которые я вносил свой вклад или разрабатывал самостоятельно, имели множество братьев и сестер. При большом запасе идей, высветившихся на ранней стадии творческого процесса, возникало множество альтернативных вариантов, в равной степени казавшихся подходящими. Испытание некоторых вариантов было единственным способом понять, какой из них лучше. Проектировщикам или разработчикам, имеющим опыт по созданию прототипов, предоставляется возможность вносить изменения в пользовательский интерфейс, внешний вид и другие детали в одной из многочисленных конфигураций (хорошим примером этому служат языки CSS и HTML, в которых разные уровни можно модифицировать независимо друг от друга). Легко модифицируемый прототип может сократить дискуссии и ускорить принятие решений, поскольку он избавляет людей от необходимости держать все в голове.
Я по собственному опыту знаю: независимо от того, насколько реально впечатление взаимного согласия, если все люди не смотрят на одно и то же изображение, ни о какой согласованности не может быть и речи. Каждый человек может иметь собственное, совершенно отличное от других представление, и когда он соглашается с другими, на самом деле он думает о чем-то своем. Позже в создавшейся неразберихе, скорее всего, будет обвинен проектировщик или руководитель проекта. Прототипы являются действенным средством избежать подобной ситуации, потому что они реально существуют и могут быть продемонстрированы, а впоследствии на них можно сослаться. «Вы видите это? Вы с этим были согласны, и все присутствовавшие в этой комнате видели, что вы согласились именно с этим дизайном». При этом вы должны конкретно указать на характерные особенности прототипа или на созданные дизайнером экранные копии.
Вопросы относительно последовательного приближения
С первым же прототипом возникнет масса новых идей и вопросов, включая предложения кое-что изменить, улучшить или попробовать новые задумки. Если вы имеете дело с ранним прототипом, то создание его следующего варианта может быть направлено на исследование существенных идей или значительных изменений. Если речь идет об одном из поздних прототипов, то его следующий образец может быть создан только для того, чтобы сузить пространство проектирования и помочь принять верные решения. Если собрать вместе все последовательно созданные образцы, появится возможность для новой дискуссии о прогрессе в проектировании. Лучшей основой для такой дискуссии станет набор вопросов, помогающих провести оценку проекта и направить обсуждение в конструктивное русло.
Вот часть вопросов, относящихся к ранним образцам прототипов:
• Каким требованиям отвечает данный образец? Можно ли в этом убедиться? (Исходя из его потребительских качеств, примеров использования и т. д.)
• Каковы сильные и слабые стороны данного образца в отношении проблем, предположительно решаемых с его помощью? (Все за и против со всех точек зрения: потребителя, бизнесмена, разработчика.)
• Какими данными мы должны располагать при оценке этого образца? (Возможно, полученными в результате изучения потребительских запросов, неформального анализа возможностей реализации, проведенного программистами, анализа рыночной ситуации, мнений специалистов и т. д.)
• Что поучительного, пригодного для следующей версии прототипа содержал данный образец? Можно ли его уничтожить?
• Что нужно попробовать сделать в следующем образце, чтобы добиться лучшего результата?
• Есть ли в этой же группе или в других прототипах какая-нибудь другая идея, которой мы можем воспользоваться?
А вот ряд вопросов для более поздних прототипов:
• Какое решение с его помощью мы можем принять?
• Какие спорные вопросы он поможет нам закрыть?
• Подтверждается ли данным образцом существование проблемы, подлежащей исследованию? Решается ли эта проблема с его созданием?
• Что следует попробовать сделать в следующем образце, чтобы приблизиться к составлению технических условий?
Ответив на эти вопросы, проектировщик получит достаточно сведений для создания следующей версии прототипа, возможно, путем объединения двух альтернативных вариантов или расчленения образца на два новых. Что бы вы ни делали, пока это, в конечном счете, приближает проект хотя бы на один шаг к завершению, не должно быть никаких ограничений на то, что разрешено, и на то, что нет.
Список открытых проблем
По мере сужения пространства возможных вариантов у руководителя проекта появляется еще одна обязанность: составление списка открытых проблем. Под открытой понимается проблема, которую нужно решить или очертить, но сделать это пока не представляется возможным. По существу, это список вопросов, в котором перечислено все, что нужно сделать, в порядке, соответствующем степени потенциального влияния на разработку. Не так важна форма этого перечня, как качество внесенных в него вопросов и старательность человека, ведущего команду к их решению. Для составления перечня я использовал выделенную часть классной доски или электронную таблицу Excel и не могу сказать, что выбор инструмента на что-либо существенно повлиял. Я не думаю, что за этим списком нужен особый контроль или им нужно управлять, как при создании исходного кода (если, конечно, политика или культура труда в вашей организации не принуждают к этому), чем проще инструмент создания списка, тем лучше.
Этот список можно начать с весьма приблизительного перечня вопросов, оставшихся без ответа, и дел, оставшихся не сделанными («Какую схему данных мы будем использовать,
Всю ответственность за технические вопросы и исследования должны нести программисты, но если есть особо сложные проблемы, за которые лучше взяться руководителю проекта, он так и должен поступить. Как правило, руководитель проекта курирует вопросы, не имеющие технической специфики, но способные воспрепятствовать разработке, такие как согласования со специалистами по маркетингу, учет интересов пользователя, разработка бренда и визуальное проектирование, поскольку эти вопросы влияют на технические условия больше, чем на саму разработку (в чем здесь разница, мы выясним в следующей главе).
Мудрый руководитель проекта делит список открытых проблем по срочности решения на две части: на то, что должно быть решено до выдачи технических условий, и на то, что может быть отложено на более поздний срок. Естественнее всего расположить по приоритетам те проблемы, которые потенциально могут помешать разработке и, возможно, всему проекту. Все проблемы, попавшие во вторую часть списка (относящуюся к периоду после выдачи технических условий), должны быть уточнены с участием разработчиков, потому что только они могут проверить, какие решения или сведения можно пока отложить. (Как и почему их можно отложить, пока не появятся технические условия, мы рассмотрим в следующей главе.)
Все неопределенности, к которым рано или поздно придется вернуться, должны быть отражены в списке. Ни у кого, кроме руководителя проекта, не возникнет потребности заглянуть в этот список, и разумеется, не сразу. Но по прошествии времени список может послужить поводом для сбора команды или проведения обсуждений «на ходу». Цель не в том, чтобы испортить людям настроение, просто им нужно иногда напомнить о том, что осталось нерешенным, и помочь понять, какие проблемы нужно решить специалистам команды. Поскольку работа руководителя проекта касается всех, вывешивание списка на видном месте позволит людям сотрудничать в решении проблем: «А этот пункт и меня касается. Кто им займется, ты или я?» По этой причине я держу список проблем на доске в своем офисе или коридоре. (Может сработать и wiki-технология, но никто, кроме составителя, туда не заглядывает. Обычные невиртуальные и неформальные места срабатывают куда лучше.)
Когда люди заходили в мой офис и спрашивали, как продвигаются наши дела, я указывал на список и говорил: «Вот так и продвигаются. Пока список не будет исчерпан, я не смогу закончить составление технических условий». Хотя этот список – не показатель производительности и не объект, подлежащий строгим измерениям в течение длительного времени, состояние списка проблем, находящегося у руководителя проекта, и круг вопросов, в него включенный, являются существенным показателем того, насколько хорошо идут дела. Если список достаточно длинный, но состоит из сугубо специфических и узкоспециальных проблем, все идет хорошо. А если он короткий, но его вопросы пугают своей основательностью, например: «Какую проблему мы пытаемся решить?» или «Какой язык программирования мы используем?», то проект, что называется, еще толком и не сдвинулся с места.
Выводы
• Идеи обладают собственной инерционностью. Доминирование идей в творческом процессе продлится дольше ваших ожиданий. Изменения влекут за собой цепную реакцию во всем проекте.
• Для отслеживания хода творческого процесса и управления им следует установить контрольные точки. В число обычных контрольных точек включаются: доказательство состоятельности концепции, группировка идей, три альтернативных варианта, два альтернативных варианта, единый замысел.
• Для объединения идей используйте диаграмму сходства.
• Прототипы позволяют проекту противостоять разногласиям на ранней стадии и учиться на ошибках без существенного риска.
• Для ответов на вопросы, оценки степени прогресса и принятия решения о том, что делать дальше, делайте новые версии прототипов или обновляйте существующие.
• Для отслеживания вопросов, требующих разрешения до составления технических условий, составьте список открытых проблем.
Упражнения
1. Как вы составляете свой список текущих дел, по личным задачам или по задачам работы? Можете ли вы применить такую же систему для приведения в порядок, отслеживания или управления своими идеями? Почему «да» или почему «нет»?
2. В каком режиме должно вестись управление идеями, в закрытом или открытом? Кто в вашей проектной команде должен иметь доступ к: а) просмотру; б) изменению; в) добавлению или удалению идей?
3. Представьте, что вы близки к завершению проекта и поняли, что есть великолепная идея, способная радикально улучшить то, что вы делаете. Каковы способы сохранить эту идею, чтобы при запуске планирования следующего выпуска работы ею можно было воспользоваться? Можете ли вы придумать способ сбора подобных идей для всей команды?
4. Проведите сутки, занимаясь записью любых, услышанных от кого-то или самостоятельно придуманных идей. Сколько идей вам удастся собрать? Больше или меньше ожидаемого количества?
5. Возьмите список из предыдущего упражнения. Сколько различных способов группировки идей по категориям можно придумать? (Если вы поленились выполнить предыдущее упражнение, воспользуйтесь любым списком – покупок, людей, которых вам хотелось бы увидеть в голом виде, всего, что угодно.)
6. Что является тревожным признаком работы над проектом, для которого сгенерировано слишком много идей? Есть ли какое-нибудь разумное соотношение количества идей к отведенному времени, количеству сотрудников или к сложности проекта?
7. Управление творческим процессом требует определенных навыков, которые могут быть невостребованы при других этапах управления проектом. Каковы преимущества или опасности привлечения разработчиков или проектировщиков к руководству творческой стадии проекта?
8. Представьте, что вы работаете над проектом в середине этапа планирования. Никто не представил никакого прототипа, и в вашем распоряжении только письменные документы. Вы понимаете, что на некоторые вопросы невозможно получить ответы, используя лишь эти документы. Что вам делать? Изготавливать прототип самостоятельно? Привлечь к этой работе какого-нибудь другого специалиста команды? Кому вы покажете прототип? Какую реакцию вы от него ожидаете?
9. Представим, что в предыдущем упражнении вы решили изготовить прототип. Вы показали его команде, и он ей понравился. То есть он ей настолько понравился, что команда согласилась прекратить всю другую проектировочную работу и оснащение ради того единственного созданного вами прототипа. Вы знаете, что прототип создает массу предположений, требующих проверки, но их это мало волнует. Как убедить их в необходимости другого прототипа? Что можно сделать до показа прототипа, чтобы свести к минимуму шансы подобного развития событий?
10. Как расценить действия руководителя проекта, если он требует, чтобы список открытых проблем был пуст? Кому вы больше станете доверять, тому руководителю, у которого пять, или тому, у которого пятьдесят записей в списке открытых проблем? Испытываете ли вы какие-нибудь опасения насчет слишком больших затрат времени на отслеживание хода сокращения открытых проблем?
Часть 2. Как подготовить хорошие технические условия
Глава 7. Практические навыки
Однажды у меня зашел спор с программистом, который полагал, что технические условия составлять незачем. Я вошел к нему в офис с объемистой спецификацией, которой требовалось следовать в соответствии с указанием нашего босса, а коллега над ней просто посмеялся (и, к сожалению, надо мной тоже). По его мнению, если то, что я хочу сделать, настолько сложно, что для объяснения этого программистам понадобилось 50 страниц, то создавать это в любом случае не стоит. Необходимость во всем этом процессе и в бумажной работе он рассматривал в качестве сигнала, что общение и координация усилий в команде нарушены и ей не доверяют принимать самостоятельные решения. Он сказал, что нам не нужна такая мощная опека и бюрократия, подразумевая, что в столь детальном планировании потребности никогда не возникало.
Я улыбнулся, поскольку сталкивался с подобной аргументацией уже не впервые, и спросил, готов ли он утверждать то же самое в отношении технической документации на многоэтажный жилой дом, в котором находилась его квартира, или на трехуровневую дорожную развязку, по которой он добирался на работу. Однако ранее он, видимо, уже слышал подобные вопросы, поэтому улыбнулся мне в ответ. Он сказал, что хотя он рад, что такие сооружения были спланированы весьма подробно, но он не думает, что работа над созданием программ сравнима с работой в той сфере, где царят законы физики и используются строительные материалы (и он приводил доводы в пользу методов с минимальным объемом письменных технических условий, таких как экстремальное программирование). Мы быстро пришли к согласию по двум пунктам. Сначала мы согласились с тем, что по сравнению с традиционным инженерным искусством разработка программных продуктов – процесс более гибкий, в него легче вносить изменения и от него вряд ли зависят жизни людей. Но при этом мы признали и то, что для уверенности в результате требуется нечто более осязаемое, чем просто воспоминания о содержимом кулуарных разговоров, тем более в условиях, когда перед нами стоят сложные технические проблемы, работа команды зависит от наших решений, нужно уложиться в бюджет и соблюсти заданные сроки.
Мы также согласились и с тем, что для проекта нужно что-нибудь подходящее для той работы, которую мы выполняли, и для того типа людей, к которому мы себя относили. Польза от какой-нибудь письменной документации была бы в том случае, если бы с ее помощью решались реальные проблемы, возникающие перед нашей командой, ускорялся производственный процесс и повышалась вероятность получения качественных результатов (и чтобы со временем эту документацию нужно было бы обновлять, не ущемляя чьих-либо интересов). Он сказал, что если мы в состоянии создать что-либо подобное, то он охотно этим воспользуется, независимо от того, как мы это назовем и в какой форме преподнесем. На том мы и порешили, обратив процесс создания технических условий в то, что по взаимному согласию отвечало бы интересам всей нашей маленькой команды. Я вернулся к боссу, пересказал ему наш разговор и подготовил компромиссный вариант. Громоздкий, похожий на налоговое законодательство вариант технических условий ушел в прошлое.
Самое поучительное в этой истории заключается в том, что при составлении технических условий или документировании работы, как и в любом другом виде человеческой деятельности, не существует единственно верного пути. Технические условия, как и многие другие задачи, стоящие перед командой, должны отвечать потребностям текущего проекта и интересам тех людей, которым предстоит их составлять и выполнять. Так же как веб-сайты и программные продукты для поиска лучших подходов должны пройти процесс проектирования, технические условия, чтобы из них вышло что-нибудь подходящее, требуют вдумчивой работы и многочисленных прикидок.
Но многие известные мне опытные специалисты попадались в ловушку, будучи уверены, что есть лишь один способ подготовки технических условий (как бы они их ни называли): использование ранее накопленного опыта. Иногда эта цепочка повторений уводила их к самым первым разработкам. Они считали, если эти проекты не были полным провалом, значит, способ составления технических условий (или игнорирование других способов) положительно повлиял на конечный результат. Данное утверждение без каких-либо исследований может быть в равной степени как верным, так и ошибочным (то есть проект, возможно, оказался успешным, хотя процесс составления технических условий был неправильным). Хуже того, если не были подняты резонные вопросы о том, как и зачем написаны эти технические условия, никто в команде так и не поймет, плох или хорош был процесс их подготовки или каков их вклад в работу команды. (Здесь прослеживается полная аналогия с тем, как отсутствие толковых вопросов относительно создания качественного программного кода не позволяет понять, насколько этот код хорош или плох на самом деле.)
Моей целью в данной главе является объяснение ряда ценных идей. Во-первых, что технические условия должны принести проекту тройную пользу: гарантировать, что создается именно то, что было задумано, предоставить график поэтапной работы, которым завершается стадия планирования проекта, и дать возможность основательно рассмотреть курс реализации проекта и получить о нем отзывы различных специалистов. Значение всех трех составляющих трудно переоценить, и вряд ли какой-нибудь другой процесс, кроме составления технических условий, обеспечит все это одновременно. Лишь поэтому я считаю себя ярым сторонником составления технических условий. Во-вторых, большинство претензий, предъявляемых к техническим условиям, легко устранимы при условии, что авторы разбираются в типовых просчетах, допускаемых при подготовке таких условий, и понимают, ради чего они создаются.
Что могут и чего не могут технические условия
Технические условия, как и концептуальные документы, являются формой организации взаимодействия. Если они составляются в целях реального использования, содержащаяся в них информация подается в простом и понятном виде. Если же должного значения им не придается, то они создаются и читаются с большим трудом и вызывают разочарование у всех, кто бы ни взял их в руки. Довольно часто команды, составившие слабые технические условия, реально ощущают недостаточную отдачу от этого документа (если волки сбиваются в стаи, технические условия становятся досадным недоразумением). Зачастую причиной появления слабых или неудачных технических условий является недопонимание того, что с их помощью можно сделать, а в чем они, наверняка, не помогут.
Технические условия могут принести существенную пользу проекту в следующих вопросах:
• Предоставить толковое описание характеристик создаваемого изделия.
• Заставить проектировщиков разъяснить их решения, поскольку эти решения впоследствии превращаются в технические условия.
• Предоставить возможность проведения различных обсуждений, опросов мнений и дискуссий в отношении детальных планов перед началом их активной реализации.
• Стать источником распространения информации от одного специалиста ко многим.
Поделиться книгой: