Упражнение «Волшебный компьютер»

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

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

Терминология

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

Если для выражения какой-либо идеи нет подходящих слов, передать ее становится практически невозможно. Как следствие, невозможно произвести анализ и декомпозицию этой идеи на таком уровне технической детализации, чтобы можно было описать ее на языке C# или Java.

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

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

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

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

Коммуникационный прорыв

Первая задача надежной терминологии – сделать коммуникации в команде более эффективными. Тем не менее нередко у нее бывает и еще одна немаловажная задача. Время от времени мы замечаем, что в корпоративной культуре компаний наших клиентов уже прижились отдельные термины. Хорошим примером здесь будет фраза Microsoft «Embrace the Internet» («Охвати весь интернет»). Такие фразы порой обретают почти религиозный смысл, их произносят с благоговением. Из-за этого благоговейного трепета добраться до первоначальной сути фразы и рассмотреть ее в свете новых императивов проектирования бывает очень нелегко. Следует ли из фразы, что под охватом интернета подразумеваются браузеры, или имеется в виду HTML, или же только протокол ТСР/IР? Подобные «священные слова» похожи на ограждение вокруг храма. Однако попирать священную веру клиента мы тоже не можем, поскольку это не продвинет наш процесс проектирования вперед. Поэтому мы обычно разбиваем процессы, задачи и программы на понятные отдельные фрагменты и называем их по-новому, названиями, которые не несут прежнего смысла. Новые названия, как правило, также носят некий юмористический оттенок, и с помощью такого легкомысленного подхода нам удается прорваться сквозь серьезный настрой участников.