Программист-прагматик. Путь от подмастерья к мастеру

      Это весьма тонкое различие, но именно оно окажет серьезное воздействие на разработчиков. Если требование сформулировано как "Доступ к личному делу сотрудника ограничен персоналом фирмы", то разработчик может прекратить составление программы проверки на том месте, где приложение обращается к этим файлам. Однако если эта формулировка звучит как "Доступ к личному делу сотрудника ограничен уполномоченными на то пользователями", то разработчик, по всей вероятности, спроектирует и реализует нечто вроде системы управления доступом. При изменении политики (а оно обязательно произойдет) потребуется лишь обновление метаданных системы. На самом деле подобный метод сбора требований приведет к созданию системы, четко структурированной для поддержки метаданных.
      Различия между требованиями, политикой и реализацией могут быть весьма размытыми, если речь идет о пользовательских интерфейсах. Слова "Система должна давать возможность выбора срока предоставления ссуды" представляют собой формулировку требования. Выражение "Для выбора срока предоставления ссуды необходимо окно списка" может являться формулировкой, а может таковой и не являться. Если пользователям позарез нужно окно списка, то в этом случае речь идет о требовании. Если же вместо этого они описывают свою способность выбирать, используя окно списка лишь в качестве примера, то здесь говорится не о требовании. Врезка ниже "Когда интерфейс становится системой" описывает проект, который пошел совсем не в ту сторону, поскольку потребности пользователей в интерфейсе были проигнорированы.
      Важно обнаружить основополагающую причину того, почему пользователи поступают определенным образом, а не так, как они привыкли это делать. В конечном итоге разрабатываемой программе придется решать проблемы их бизнеса, а не просто отвечать их заявленным требованиям. Документируя причины, по которым были выдвинуты требования, команда разработчиков получит бесценную информацию, необходимую для принятия ежедневных решений, связанных с реализацией.
      Существует простая методика: чтобы взглянуть изнутри на требования (которые часто являются весьма недостаточными) ваших пользователей, нужно самому стать пользователем. Пишете систему для службы поддержки? Посидите пару дней на телефоне вместе с опытным сотрудником этой службы. Занимаетесь автоматизацией ручной системы управления складскими запасами? Поработайте на складе с неделю . Вы получите представление о реальном использовании системы и вдобавок будете просто поражены тем, насколько просьба "Можно я посижу рядом с вами недельку и посмотрю, как вы работаете?" способствует доверию и закладывает основы ваших взаимоотношений с пользователями. Но не путайтесь у них под ногами!
 

      Подсказка 52: Работайте с пользователем, чтобы мыслить категориями пользователя

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

Документация требований

      Итак, вы садитесь за стол с пользователями и начинаете выпытывать у них, что же им нужно на самом деле. Вы столкнетесь с несколькими вероятными сценариями, описывающими, что должно делать ваше приложение. Поскольку вы остаетесь профессионалом во всем, то вам хочется опубликовать такой документ, которым все смогут пользоваться в качестве основы при обсуждении, – разработчики, конечные пользователи и спонсоры проекта. Это весьма широкая аудитория.
      Ивар Джекобсон [Jac94] предложил концепцию "сценариев использования системы" для фиксирования требований. Они позволяют описывать частные случаи использования системы не с точки зрения пользовательского интерфейса, а в более абстрактном виде. К сожалению, книга И. Джекобсона несколько расплывчата в деталях, поэтому в настоящее время не существует единого мнения о том, что же считать "сценарием использования системы". Что это – формальный или неформальный термин, прозаический или структурированный документ (подобный канцелярской форме)? Каким должен быть уровень детализации (помните, что у нас весьма широкая аудитория)?

Когда интерфейс становится системой

      В своей статье (журнал «Wired», январь 1999, с. 176) продюсер и музыкант Брайан Иноу описал чудо техники – новейший микшерный пульт. Этот пульт заставляет звучать все, что в принципе может звучать. И все же, вместо того, чтобы помочь музыкантам в создании лучших произведений или ускорить (или удешевить) процесс записи, он "путается под ногами", нарушая творческий процесс.
      Чтобы понять, почему это происходит, необходимо взглянуть на работу инженеров студии звукозаписи. Они сводят звук интуитивно. За годы работы в студии у них вырабатывается врожденный цикл обратной связи между ушами и кончиками пальцев, управляющих плавно движущимися регуляторами, вращающимися ручками и т. д. Однако компьютерный интерфейс нового микшерного пульта не усиливал их способностей. Вместо этого он заставлял пользователей набирать текст на клавиатуре и/или щелкать мышью. Функции, обеспечиваемые этим интерфейсом, были универсальными, но они были скомпонованы неизвестными и экзотическими способами. Функции, необходимые инженерам в их работе, иногда скрывались за невразумительными названиями или же достигались за счет неестественных сочетаний базовых средств.
      Эта среда характеризовалась требованием – усилить существующие навыки работы. Вместо того, чтобы раболепно дублировать то, что уже существует, нужно было обеспечить переход на новую ступень развития.
      Например, хорошим подспорьем в работе инженеров звукозаписи мог бы оказаться сенсорный интерфейс, смонтированный в виде классического микшерного пульта, но при этом позволяющий программам выходить за границы, определенные фиксированными ручками и переключателями. Единственным способом завоевать рынок является обеспечение удобства во время перехода на новую ступень за счет уже известных метафор.
      Этот пример также иллюстрирует нашу уверенность в том, что удачные инструменты всегда привыкают к рукам, их держащим. В данном случае речь идет о привыкании инструментов, которые создаются вами для других людей.
 
      При рассмотрении сценариев использования системы стоит отметить их целенаправленную природу. Алистер Кокбэрн опубликовал статью, в которой описывается этот подход, а также шаблоны, используемые (строго или нестрого) при этом в качестве отправной точки ([Сос97а]; имеется Интернет-версия этой статьи [URL 46]). На рисунке 7.1. показан (в сокращении) пример подобного шаблона, на рис. 7.2 представлен пример сценария его использования.
 
      Рис. 7.1. Шаблон сценария использования системы по А. Кокбэрну
      A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ
      – Цель в контексте
      – Область действия
      – Уровень
      – Предусловия
      – Условие успешного завершения
      – Условие неудачного завершения
      – Первичный действующий субъект
      – Условие начала действия
      B. ОСНОВНОЙ СЦЕНАРИЙ ПРИ УСПЕШНОМ ЗАВЕРШЕНИИ
      C. РАСШИРЕНИЯ
      D. ВАРИАНТЫ
      E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
      – Приоритет
      – Рабочая характеристика
      – Частота
      – Превосходящий прецедент использования
      – Подчиненный прецедент использования
      – Канал связи с первичным действующим субъектом
      – Вторичные действующие субъекты
      – Канал связи со вторичными действующими субъектами
      F. РАСПИСАНИЕ
      G. ОТКРЫТЫЕ ПРОБЛЕМЫ
 
      Используя формальный шаблон в качестве шпаргалки, вы можете быть уверены в том, что включили всю необходимую информацию в сценарий использования системы: характеристики производительности, другие стороны-участники, приоритет, частоту использования и разнообразные ошибки и исключения, которые могут появляться неожиданно ("нефункциональные требования"). Шаблон удобен для записи комментариев пользователей, наподобие "если мы получим условие ххх, тогда нам придется сделать ууу". Шаблон может послужить в качестве готовой повестки дня при встрече с пользователями ваших программ.
 
      Рис. 7.2. Пример сценария использования системы
       ПРЕЦЕДЕНТ ИСПОЛЬЗОВАНИЯ № 5: ПРИОБРЕТЕНИЕ ТОВАРА
       A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ
      • Цель в контексте: Покупатель напрямую направляет коммерческий запрос в нашу фирму и ожидает отгрузки товаров и выставления счета за указанные товары.
      • Область действия: Фирма
      • Уровень: Итоговая информация
      • Предусловия: Нам известен покупатель, его адрес, и т. д.
      • Условие успешного завершения: Покупатель получает товары, мы получаем оплату.
      • Условие неуспешного завершения: Мы не производим отгрузку товаров, покупатель не производит оплату.
      • Первичный действующий субъект: Покупатель, любой агент (или компьютер), действующий от имени заказчика
      • Условие начала действия: Получение запроса на приобретение товара.
       B. ОСНОВНОЙ СЦЕНАРИЙ С УСПЕШНЫМ ЗАВЕРШЕНИЕМ
      1. Покупатель обращается в фирму с запросом на приобретение товара.
      2. Фирма фиксирует имя покупателя. его адрес, требуемые товары. и т. д.
      3. Фирма предоставляет покупателю информацию о товарах, ценах, сроках поставки, и т. д.
      4. Покупатель подтверждает заказ.
      5. Фирма компонует заказ, отправляет заказ покупателю.
      6. Фирма высылает покупателю счет-фактуру.
      7. Покупатель оплачивает счет-фактуру.
      C. РАСШИРЕНИЯ
      3а. Один из пунктов заказа отсутствует у данной фирмы: Заказ переоформляется.
      4а. Покупатель производит оплату непосредственно кредитной картой: Прием оплаты кредитной картой (прецедент использования № 44).
      7а. Покупатель возвращает товар: Оформление возвращенного товара (прецедент использования № 105).
       D. ВАРИАНТЫ
      1. Покупатель может осуществить заказ по телефону, факсу, при помощи Интернет-формы (на странице), по другим сетям электронного обмена информацией.
      7. Покупатель может оплатить заказ наличными денежным переводом, чеком, или кредитной картой.
       E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
      • Приоритет: Высший
      • Производительность: 5 минут на оформление заказа, оплата в течение 45 дней
      • Частота: 200 заказов в день
      • Превосходящий прецедент использования: Управление взаимоотношением с заказчиком (прецедент использования № 2).
      • Подчиненные прецеденты использования: Компоновка заказа (прецедент использования № 15)
      • Прием оплаты кредитной картой (прецедент использования № 44). Возврат товара покупателем (прецедент использования № 105).
      • Канал общения с первичным действующим субъектом: по телефону, факсу или компьютерной сети.
      • Вторичные действующие субъекты: компания – оператор платежной системы, банк, экспедиторская фирма.
       F. РАСПИСАНИЕ
      • Должная дата: Выпуск 1.0
       G. ПРОБЛЕМЫ, ЯВЛЯЮЩИЕСЯ ОТКРЫТЫМИ
      • Что происходит, если имеется лишь часть заказа?
      • Что происходит, если кредитная карта похищена?
 
      Подобного рода организация поддерживает иерархическое структурирование сценариев использования системы – вложение более подробных сценариев в сценарии более высокого уровня. Например, сценарии post debit и post credit дополняют друг друга в сценарии post transaction.

Диаграммы сценариев использования

      Последовательность операций может быть зафиксирована при помощи диаграмм на языке UML, а схемы концептуального представления иногда могут быть полезны для оперативного моделирования бизнес-процессов. На самом деле сценарии использования представляют собой текстовые описания с иерархией и перекрестными ссылками. Сценарии использования могут содержать гиперссылки на другие сценарии и могут вкладываться друг в друга.
 
      Рис. 7.3. Сценарии использования, выраженные UML, понятны даже ребенку!

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

Чрезмерная спецификация

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

Видеть перспективу

      Вина за возникновение "проблемы 2000 года" часто возлагается на близоруких программистов, пытавшихся сэкономить несколько байтов в те дни, когда объем памяти мэйнфреймов был меньше, чем у современных пультов дистанционного управления телевизорами.
      Но это не зависело от программистов и не являлось вопросом использования памяти. Если уж быть честным до конца, вина за это лежит на системных аналитиках и проектировщиках. "Проблема 2000 года" возникла по двум основным причинам: нежелание выйти за пределы существующей бизнес-практики и нарушение принципа DRY.
      Двухразрядное обозначение года использовалось в деловой практике задолго до появления компьютеров. Это было обычной практикой. В то время приложения, предназначенные для обработки данных, в основном занимались автоматизацией существующих бизнес-процессов и просто повторили ошибку. Даже в том случае, когда архитектура требовала двухразрядного обозначения при вводе данных, создании отчетов и хранении данных, должна была бы появиться абстракция DATE, которая «знала» о том, что две цифры представляли собой усеченную форму реальной календарной даты.
 

      Подсказка 53: Абстракции живут дольше, чем подробности

 
      Требует ли от вас фраза "Видеть перспективу", чтобы вы занялись предсказанием будущего? Нет. Это означает создание формулировок типа:

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

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

Еще одна мелочь…

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

Поддержка глоссария

      Как только вы начинаете обсуждать требования, пользователи и специалисты в предметной области будут использовать определенные термины, имеющие для них специфическое значение. Например, они проводят различие между «клиентом» и «заказчиком». Было бы неуместно допустить небрежность, используя в системе то один, то другой термин.
      Создайте и поддерживайте "глоссарий проекта", где будут определены все специфические термины и словарь, используемый в проекте. Все участники проекта, от конечных пользователей до специалистов службы поддержки, обязаны использовать глоссарий для обеспечения согласованности. Это подразумевает доступность глоссария для широкого круга – хороший аргумент для размещения документации на web-сайтах (об этом буквально через минуту).
 

      Подсказка 54: Используйте глоссарий проекта

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

Прошу слова…

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

Другие разделы, относящиеся к данной теме:

      • Суп из камней и сварившиеся лягушки
      • Довольно приличные программы
      • Круги и стрелки
      • Все эти сочинения
      • Большие надежды

Вопросы для обсуждения

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

Упражнения

      42. Какие из нижеследующих примеров, по всей вероятности, являются требованиями? Переформулируйте те, которые таковыми не являются, для придания им большей пользы (если это возможно). (Ответ см. в Приложении В.)
      1. Время отклика не должно превышать 500 мс.
      2. Цвет фона диалогового окна будет серым.
      3. Приложение будет организовано в виде нескольких внешних процессов и внутреннего сервера.
      4. Если пользователь вводит нечисловые символы в числовое поле, система будет выдавать звуковой сигнал и не примет их.
      5. Приложение и данные должны умещаться в пределах 256 Кбайт.

37
Разгадка невероятных головоломок

      Однажды царь Фригии Гордий завязал узел, который никто не мог развязать. Было предсказано, что тот, кто сможет развязать его, станет властелином всей Азии. И вот пришел Александр Македонский, который разрубил узел своим мечом. Несколько иная интерпретация требований и все – он стал властителем всей Азии.
      Время от времени вы будете оказываться в ситуации, когда в самом разгаре проекта перед вами возникает сложнейшая головоломка: техническая проблема, с которой невозможно справиться, или фрагмент программы, составление которого оказалось намного сложнее, чем вы думали. Может быть, это выглядит просто невозможным. Но так ли это сложно на самом деле?
      Рассмотрим реальные головоломки – хитроумные детальки, выполненные из дерева, металла или пластмассы, которые появляются в магазинах в дни рождественских праздников и распродаж. Задача состоит в том, что бы снять кольцо или сложить Т-образные кусочки в одну картинку, или выполнить нечто подобное.
      Итак, вы пытаетесь сделать это и быстро приходите к выводу, что очевидные решения просто не срабатывают. Головоломка не может быть разгадана подобным способом. И хотя это очевидно, люди не прекращают делать одно и то же снова и снова, будучи уверенными, что это и есть нужный способ.
      Конечно же, нет. Разгадка находится в совершенно другом месте. Секрет разгадки головоломки состоит в идентификации реальных (а не воображаемых) ограничений и поиске решения, исходя из этих ограничений, некоторые из которых абсолютны, а другие являются лишь предвзятыми мнениями. Абсолютные ограничения обязаны соблюдаться, какими бы неприятными и нелепыми они ни казались. С другой стороны, некоторые очевидные ограничения в реальности могут таковыми и не являться. Например, существует старый фокус, который обычно демонстрируется в баре: вы берете закупоренную бутылку шампанского и спорите, что можете пить из нее пиво. Фокус заключается в том, что вы переворачиваете бутылку донышком вверх и наливаете немного пива в углубление на донышке. Многие проблемы в программировании можно разрешить подобным оригинальным способом.

Степени свободы

      Широко известное «умное» изречение о "размышлении вне пределов ящика" поощряет распознавание ограничений, которые могут быть неприменимы в данной ситуации, и игнорирование их впоследствии. Но эта фраза не вполне точна. Если «ящик» является границей ограничений и условий, то фокус заключается в нахождении этого «ящика», который может оказаться намного больше, чем выдумаете.
      Ключом к разгадке головоломки является распознавание факторов, сдерживающих вас, и степеней свободы, которые у вас есть, поскольку в них в них-то и находится разгадка. Вот почему многие головоломки столь эффективны: слишком легко вы отвергаете потенциальные разгадки.
      Например, можете ли вы соединить все четыре точки (см. рисунок ниже) тремя прямыми линиями и вернуться в исходную точку, не отрывая карандаша от бумаги и не проводя одной и той же линии дважды [Но178]?
 
      Вы обязаны бросить вызов любым предвзятым мнениям и оценить, являются ли они реальными, раз и навсегда установленными ограничениями.

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

      Подсказка 55: Не размышляйте вне ящика – найдите этот ящик

 
      Столкнувшись с серьезной проблемой, представьте все возможные направления, в которых вы можете двигаться. Не отвергайте никакие варианты, какими бы бесполезными или глупыми они ни казались. Теперь просмотрите весь список и объясните, почему нельзя идти по тому или иному пути. Вы уверены в этом? Можете ли это доказать?
      Рассмотрим историю с троянским конем – свежее решение непреодолимой проблемы. Как войско может попасть в укрепленный город, оставаясь незамеченным? Спорим, что вариант "через главные ворота" изначально был отвергнут как самоубийственный. Расположите ограничения по категориям и приоритетам. Столяры сначала вырезают самые крупные деревянные детали, а затем из оставшейся части – детали меньшего размера. Действуя подобным образом, мы хотим вначале идентифицировать самые жесткие ограничения и поместить оставшиеся внутрь.
      Между прочим, решение головоломки с четырьмя точками представлено в Приложении В.

Есть более простой способ!

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

Вопросы для обсуждения

      • Пристально взгляните на любую сложную проблему, которую вам приходится решать. Можете ли вы разрубить гордиев узел? Задайте себе ключевые вопросы, приведенные выше, особенно этот: "Стоит ли делать это именно таким образом?"
      • Когда вы получили проект, которым занимаетесь в настоящее время, то прилагался ли к нему набор ограничений?

38
Чувство готовности

      Тот, кто колеблется, иногда спасается
Джеймс Тэрбер, Стекло на поле

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

      Подсказка 56: Прислушайтесь к сомнениям – начинайте тогда, когда полностью готовы

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

Здравое суждение или промедление?

      Каждый испытывает страх перед чистым листом бумаги. Начало нового проекта (или даже новый модуль в существующем проекте) может лишить вас спокойствия. Многие из нас предпочли бы отложить момент связывания себя обязательствами. Но вы же не можете заявить, что вы просто оттягиваете начало работы?
      Создание прототипа – это методика, хорошо зарекомендовавшая себя в подобных обстоятельствах. Выберите область, которая, по вашему мнению, будет трудной, и начните создание некоего доказательства концепции. Вскоре вы можете ощутить, что тратите время понапрасну. Это признак того, что ваше изначальное сопротивление было просто желанием отложить момент связывания себя обязательствами. Откажитесь от прототипа и врубайтесь в реальную разработку.
      С другой стороны, в ходе разработки прототипа наступает момент истины, когда вы внезапно осознаете, что некая базовая предпосылка была неверной. Но вам станет ясно не только это, но и способ исправления этой предпосылки. Вы с легкостью откажетесь от прототипа и начнете проект надлежащим образом. Инстинкты не обманули, и вы сэкономили для себя и команды значительное количество усилий, которое могли потратить впустую.
      Когда вы принимаете решение о создании прототипа, в целях исследования причины своего беспокойства, не забывайте, зачем это делаете. Вспоминать о том, что вы начали создавать прототип, спустя несколько недель после начала серьезного проекта – последнее дело.
      Это звучит несколько цинично, но начало работ по созданию прототипа может быть более политкорректно, нежели примитивное высказывание типа "Я не настроен на начало работы" с последующим запуском игры "пасьянс".

Вопросы для обсуждения

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