Текст книги "Сделано"
Автор книги: Скотт Беркун
Жанр: Управление и подбор персонала, Бизнес-Книги
Возрастные ограничения: +16
сообщить о неприемлемом содержимом
Текущая страница: 11 (всего у книги 36 страниц) [доступный отрывок для чтения: 12 страниц]
Технологические визионеры никак не поймут разницы между осуществимым и желаемым.
Эдвард Мендельсон
Лучшая в мире архитектура, основанная на лучших объектных моделях, блестящих алгоритмах и самом быстром и при этом надежном коде, будет бесполезной, если клиенты не поймут, как пользоваться этим продуктом. Алгоритмы и человеко-часы инженерных затрат окажутся ненужными, поскольку никто не сможет оценить качество проделанной работы.
Единственная страховка против такого разворота событий – начать проектирование сверху вниз, то есть с того, что клиент увидит на экране, затем спуститься к высокоуровневым компонентам, а затем и к отдельным рабочим элементам. После готовности чернового варианта UX-концепции следует обдумать, насколько технические идеи вписываются в эти концепции. Могут ли проектировщики воплотить это? Какие компромиссы понадобятся? Какие ограничения следует рассмотреть? Работа продолжается, обсуждения между экспертами команды переходят с одного этапа проектирования на другой, чтобы убедиться, что по ходу работы сохраняется интегральность пользовательского опыта без противоречий с тем, что возможно (и вероятно) со стороны разработчиков. Мысль проектировщика движется в двух направлениях: от желаемого клиентского опыта вниз к технологии и от практической технологии снова вверх – к клиентскому опыту (рис. 5.5).
Рис. 5.5. В идеальном варианте проектирования сочетается сфокусированность на клиенте с практическими соображениями относительно имеющихся технологий. Если изолировать один компонент, пострадает и другой
Мозговой штурм поможет понять, как и с чего начать проектирование. Многие первые идеи, вероятно, будут описывать, как спроектировать систему для решения проблемы. Каждая из идей имеет как минимум одно визуальное представление того, как приложение или сайт будут выглядеть для пользователей. Это можно сделать схематически или обсудить, не написав ни одной строчки кода. (Если проект представляет собой встроенную систему или ядро ОС – системы без реального пользовательского интерфейса, – следует обдумать, какие условия не приемлемы ни при каком раскладе.)
Визуализация, скетчи, рисунки, а в некоторых случаях прототипы – первый шаг к пониманию идеи. Если ее нельзя изобразить, то уж точно нельзя построить. UML-диаграммы и Visio – не то же самое, что наброски и чертежи. Диаграммы абстрактны. Они не показывают того, что увидит пользователь, и, следовательно, могут скрывать самые разные проблемы и детали, которые необходимо обдумать.
Вспомним одну из формулировок проблем из главы 3: «С домашней страницы сложно найти часто используемые элементы». Предположим, что после мозгового штурма команда выделила три достойные идеи:
• динамически выстраивать страницы по приоритетам, опираясь на то, что используют клиенты;
• избавиться от того, на что клиенты никогда не кликают;
• упорядочить материал на домашней странице по группам, значимым для клиентов.
Прежде чем разработчик задумается над реализацией этих задач, кто-то должен определить, насколько эти идеи соотносятся с клиентским опытом. Возможно, несмотря на всю их гениальность в теории, никто в компании не сможет придумать качественное проектное решение[56]56
Рекомендую Don’t Make Me Think, Steve Krug (New Riders Press, 2005) (Круг С. Не заставляйте меня думать. М.: Эксмо, 2017) по общим принципам дизайна; GUI Bloopers, Jeff Johnson (Morgan Kaufmann, 2000) (Джонсон Д. Web-дизайн: типичные ляпы и как их избежать. М.: Кудиц-образ, 2005) по частым ошибкам пользовательского интерфейса. Зайдите также на http://www.upassoc.org/people_pages/consultants_directory/index.html, если нужно нанять консультанта по простоте использования или дизайну, либо свяжитесь с автором: www.scottberkun.com/services.
[Закрыть], благодаря которому клиентам было бы легче ориентироваться. Поэтому в интересах команды начать именно с клиентского опыта: это простейший способ исключить ненужную работу, выяснить, какое проектное решение следует выбрать и почему, а также сократить необходимость серьезных изменений на более поздних этапах. Управлять этим процессом нелегко, однако посредственный результат лучше, чем полное его отсутствие.
С несколькими набросками пользовательских интерфейсов можно приступать к проектированию. Неформальная проработка набросков с разработчиками, тестировщиками и маркетологами становится отправной точкой важных обсуждений. Разработчик может дать проектировщику рекомендации по работе; или предложить изменения, которые ее облегчат; или ознакомить проектировщика с технически возможными вариантами. Чем раньше начнутся обсуждения, тем больше идей можно придумать, проанализировать и доработать.
Важно, чтобы все воспринимали процесс объективно: как цепочку проб, дискуссий, вопросов и исследований, которые повторяются, пока не будут сформулированы удовлетворяющие всем требованиям предложения (которые нужно задокументировать в спецификациях). Если кто-то не хочет участвовать в подобном диалоге, им следует передать хотя быть часть своих полномочий по принятию решений тем, кто готов к этому. Хотя участие разработчиков в проектировании повышает его качество, следует помнить: проектирование – это не разработка; лучше исключить людей из процесса, чем пытаться изменить процесс им в угоду.
Если цели, задачи и проблемы ясны, проектные обсуждения будут протекать в положительном русле. Конечно, разногласий не избежать, но они будут незначительными, если все участники решают одну и ту же проблему. Подобные столкновения лишь позволят людям расширить свой кругозор. Как гласят правила импровизации, идея одного человека может стать отправной точкой для другого, с иным опытом работы или иным мнением; для более неожиданного и более удачного варианта, чем первоначальный.
Мне нравится работать с хорошими людьми, потому что, если я предложу идею, они предложат идею получше, потом я предложу что-то еще лучше и так далее: похоже на чехарду, и результат оказывается намного удачнее, чем если бы я делал только то, что я хочу.
Сотрудничество, о котором говорит Гиллиам, возможно, только когда члены команды доверяют друг другу. Именно менеджеры и лидеры обязаны создавать доверительную атмосферу и должны быть открыты хорошим идеям независимо от их источника. Подробнее об этом мы поговорим в главе 12.
Резюме• Многие команды не умеют грамотно использовать время между требованиями и спецификациями.
• Качественные требования и проектные обсуждения – лучшие занятия в этот период.
• Идеи хороши или плохи только в сравнении с задачами и другими идеями.
• Ограничения полезны для поиска идей, а нестандартное мышление не всегда приносит нужный ответ. Иногда оптимальное решение – найти способ работать в рамках указанных ограничений.
• Вопросы, перспективы и импровизированные игры – инструменты поиска новых идей.
• Лучшая отправная точка для проектных идей – клиентский опыт.
• Идеи превращаются в проектные решения в ходе обсуждений между разными людьми с разным опытом работы.
УпражненияА. Найдите человека, которого вы считаете более креативным, чем вы сами. Спросите, откуда он черпает свои идеи и какие привычки помогают ему культивировать креатив. Позаимствуйте одну из его привычек и практикуйте ее в течение недели. (Если не получается, берите пример с Пикассо, Эйнштейна или любого другого человека, который славится креативным мышлением в вашей области.)
Б. На ваш взгляд, требования помогают или мешают креативу? Как сформулировать требования, чтобы они способствовали поиску креативных идей?
В. Какую самую безумную идею вы когда-либо предлагали? Можете сейчас придумать способ сделать эту идею еще более безумной?
Г. Какую самую безумную из своих идей вы никогда никому не рассказывали? Почему? Чего вы боялись? Насколько этот страх связан с вашим умением быть креативным на работе?
Д. Проектные работы означают, что итог непредсказуем. Иногда самые удачные идеи не приносят ожидаемых результатов. Как лидер проекта может укрепить уверенность команды, когда ее любимая идея оказывается неудачной или когда лучший прототип отвергнут?
Е. Какую проблему вы пытаетесь решить, читая эту книгу? Делая эти упражнения? Может, вы находитесь в ситуации, при которой полезно задать этот вопрос.
Ж. Допустим, вы занимаетесь перепланировкой дома или квартиры. Составьте список 10 фокусирующих вопросов для стимуляции креативного мышления. Затем составьте список 10 креативных вопросов.
З. На следующем мозговом штурме или креативной сессии запишите на доске правила. Предложите провести эксперимент всего на 10 минут, во время которого каждый присутствующий должен следовать этим правилам. Какие результаты вы получите? Захотелось ли вам изменить эти правила или дополнить их?
И. Если проектирование – цепочка обсуждений, то как оно влияет на необходимость развивать навыки общения? Может ли человек быть блестящим проектировщиком, если с ним невозможно разговаривать? Может ли блестящий проектировщик быть при этом отвратительным командным игроком?
К. Можно ли спрогнозировать, сколько идей вам нужно, чтобы выбрать достойную? Есть ли взаимосвязь со сложностью задачи, которую вы пытаетесь решить? Или другие факторы? Или прогнозировать слишком сложно?
Глава шестая. Что делать с найденными идеями
Хотя найти достойные идеи нелегко, еще сложнее применить их на деле. Работа идет полным ходом, видение есть, в офисе бурлит мощная креативная энергия. Пора обдумать, как воплотить идеи проектировщиков в конкретные решения. Даже если появились хорошие идеи, и люди увлечены работой, как преобразовать эти идеи в спецификации? Если в нужное время не сформулировать однозначные проектные решения и не организовать этот процесс должным образом, вас ждет катастрофа. По многим причинам она начинается именно с этого.
Если команда все еще не приняла основных решений, а программисты уже требуют спецификаций, проект отстает от графика, все недоделано, и люди не могут трудиться в полную силу. Более того, если качество проектных идей оставляет желать лучшего, временные рамки уже ничего не решают. В зависимости от целей проекта качество идей так же важно (или даже больше), как сроки.
По этим причинам время между завершением раннего планирования и написанием спецификаций (на любом этапе) всегда сопряжено с трудностями. Команды напрягаются, когда первый важный дедлайн вырисовывается на горизонте. Даже если об этом не говорят вслух, многие понимают, что выживут далеко не все идеи, которые находятся в обсуждении. Не хватит времени, денег или специалистов, чтобы воплотить все замыслы. Люди начинают искать способ уклониться от некоторых обязательств или «срезать углы». Хуже того, некоторые идеи конфликтуют друг с другом. В автомобиле может быть только один двигатель, у дома только одна крыша, и если до сих пор в работе три разных варианта, очевидно, что с двумя придется расстаться.
Бесконтрольные идеиВ этот период вокруг витает множество удачных идей, но им просто некуда приземлиться. Думаю, худший момент в моей карьере был во время работы над Internet Explorer 4.0. (Если вас не интересует очередная история с поля боя, переходите к следующему разделу.) Помню, я сидел в своем офисе, уставившись на доску. Вместе с другим менеджером мы составили диаграмму по многочисленной проектной команде и по всем рабочим характеристикам. Каждый раз, когда нам казалось, что она готова, мы вспоминали новое требование, которое добавляли или изменяли. В конце концов она заняла всю доску. Мой коллега отправился на собрание, и я остался один на один с этой жуткой диаграммой.
Мне предстояла масса работы, но я сидел и тупо смотрел на доску. Не мог представить себе, как такое могло произойти. Масштаб каждой задачи, которую мы пытались решить, был настолько велик и так сильно зависел от других задач, что я был не в состоянии удержать это все в голове. Я любил свою команду и свою работу, но эта любовь не уберегла меня от отчаяния. Я не понимал, как мы сможем закончить то, что начали. Хотя в этом хаосе были интересный потенциал и множество гениальных решений, он все равно оставался хаосом. Коллега заглянул ко мне в офис, увидел выражение моего лица, диаграмму, на которую я уставился, – и сразу все понял. Он сказал: «Эй, почувствуй любовь!» – и эта фраза превратилась в наш саркастический лозунг для всего проекта.
В первые месяцы проекта IE 4.0 у нас был полнейший бедлам. Мы одновременно пытались перейти от маленьких команд и релизов (к примеру, версий 2.0 и 3.0) к выпуску главного продукта. Мы находились под давлением из-за конкуренции Microsoft и Netscape, которую пресса представляла как битву не на жизнь, а на смерть. Еще была внутренняя политика революционного и в то же время стратегического продукта. Любому было бы сложно удержать корабль на плаву. И как в большинстве проектов, именно на этапе перехода от планирования к проектированию происходит столкновение эго и мнений. Людям впервые нужно принять окончательные решения, и они оказываются под прессом обязательств. Сомнения рождают стресс, и лишь одно остается неизменным – дедлайны. Очередная дата маячит на горизонте и приближается с каждым днем[58]58
Это чувство лучше всего отражает песня Older группы They Might Be Giants: «День подходит к концу, время на исходе, время на исходе. Времени почти не осталось».
[Закрыть].
Решение, которое я предлагаю в этой главе, позволит аккуратно пройти минное поле возможных проектных вариантов. Кто-то должен планировать и вести команду от одной вехи к другой – от исследования к спецификации. Если в команде нет опытного лидера по проектированию, который мог бы взять на себя эту задачу (а это был бы идеальный вариант, как я отметил в предыдущей главе), бремя ложится на МП. Мы обсудим, как благополучно преодолеть процесс генерации идей и перейти к написанию спецификации.
Управление идеями требует твердой рукиСамая распространенная ошибка – относиться к проектированию как к большому выключателю: думать, что можно включить или выключить его, когда вздумается. Эта иллюзия выглядит примерно так: вы приходите в офис и видите, что сроки уже поджимают, слишком много идей (и недостаточно решений), и говорите своей команде: «Хватит предлагать идеи! Выберите одно и начнем писать код! Вперед!» Даже если представить на минутку, что действительно существует проектный замысел, готовый к работе (хотя на практике его нет), такое непредсказуемое поведение дезориентирует всю команду. Доработка проектных замыслов требует времени. Поскольку разработчикам не предоставили конкретной даты, они, возможно, думали, что время есть до 23:59 вечера накануне формулировки спецификаций.
Грамотное управление идеями должно быть решительным и прогнозируемым. Никаких сюрпризов (если, конечно, у вас не кризисная ситуация) насчет смены сути работы или необходимости направить усилия в другую сторону, поскольку проект переходит на новый этап. Делать это можно только постепенно. Как с регулятором яркости света – нужен поэтапный перенос фокуса. Задача МП – управлять этим регулятором, причем твердой рукой. Настает момент, когда кто-то должен сказать: «Слушайте, время вышло. Что мы выбираем, А или Б?» – но команда обязана знать об этом моменте за несколько дней или недель. Темпы работы иногда приходится ускорять или сбавлять, но делать это нужно плавно и аккуратно.
Рисунок 6.1 демонстрирует идеализированный взгляд на креативный этап проекта, когда проблемы и задачи определены (видение и / или требования), и конкретный момент, когда спецификации готовы. Между этими двумя точками расположена масса обсуждений, чертежей, набросков, замыслов, прототипов и самых разных интересных занятий, о которых мы говорили в главе 5. Примерно первую половину этого времени все заняты тем, что придумывают идеи и возможные проектные решения. Во вторую половину делается акцент на сужение поля деятельности и выбора, а также корректировку лучших дизайнов. В итоге вы достигаете момента, когда принято достаточно решений по дизайну, чтобы записать их в спецификации.
Рис. 6.1. Область решения проблемы необходимо сузить по мере приближения к контрольной точке проекта
Хороший пример и полезная диаграмма, и я горжусь их появлением на страницах этой книги. Однако в природе, в отличие от диаграмм, не существует таких прямых линий и аккуратных углов. Управление идеями, как и всеми остальными элементами проект-менеджмента, – это всегда расплывчатый и субъективный процесс (вспомните восемь парадоксов проектного менеджмента из главы 1). Есть несколько важных причин, по которым эта диаграмма неточна.
Во-первых, область проблемы постоянно меняется. Это не ярко-желтая зафиксированная линия. Область возможных альтернатив всегда растет или сужается. Требования корректируются. Область задач может расти больше, чем сужаться, или сужаться больше, чем расти, но никогда не бывает что-то одно. Этот процесс больше походит на расплывчатую кривую, а не аккуратную прямую.
Перечислим основные причины.
• Появляется новая информация. Жизнь не стоит на месте. Компании могут выйти из бизнеса. Технологии могут оказаться провальными. Бюджет может измениться. Исследование простоты использования или опросы клиентов могут дать новый взгляд на проблему («Люди распечатывают документы чаще, чем мы думали» или «Пользователи не могут решить даже простейшие задачи с таким дизайном домашней страницы»).
• Вырисовывается технический план, и меняются примерные оценки объема работы. Чем раньше вы задумываетесь над этими вопросами, тем проще будет потом. Иногда изменения идут на пользу проекту, а иногда нет. К примеру, программист нашел новую стратегию реализации: «Если построить это так, мне не придется заниматься пятью другими задачами, и будет больше времени на другую работу, или мы просто выполним задачу раньше (ура!)» или «Поскольку мы не можем построить это так, как я предполагал изначально, придется выполнить еще пять дополнительных задач, то есть будет меньше времени для работы либо мы сорвем дедлайн (ужас!)».
• Конфликты появляются между двумя решениями по двум разным проблемам, которые при интеграции работают друг против друга. Это может быть связано с простотой использования, бизнесом и инжинирингом. Джо придумал фантастический дизайн для автомобильного двигателя, а Салли предложила блестящий дизайн для трансмиссии, но элементы этих двух дизайнов конфликтуют друг с другом – например, трансмиссия не подходит к двигателю.
ИЗМЕНЕНИЯ ВЫЗЫВАЮТ ЦЕПНУЮ РЕАКЦИЮ
Еще одна причина, по которой меняется область задачи, заключается в том, что проектные решения взаимосвязаны: одно изменение может повлиять на множество других решений. Учитывая такую зависимость, невозможно в полной мере прогнозировать последствия. Я наблюдал это множество раз.
Одной из задач проекта IE 5.0 было предоставить пользователю более широкие возможности упорядочить список избранных сайтов. Мы рассматривали четыре разных варианта дизайна и простые прототипы интерфейса для каждого из них. Прототипы позволили сделать первичные конструкторские прогнозы, получить информацию о потребительских свойствах и сравнить прототипы. Спецификации требовались уже в ближайшее время, и мы решили сосредоточиться на варианте Б. Через несколько дней выяснилось, что из-за изменений в графике другого проекта компонент, от которого зависел вариант Б, мы не получим. Так что пришлось снова возвращаться на прежние позиции и искать другой вариант.
Вернувшись, мы обнаружили, что все другие проектные замыслы требуют тот же компонент (ничего себе!). Но когда мы пожертвовали функциональностью (то есть сократили требования), которую обеспечил бы этот злосчастный компонент, то оказалось, что работа других программистов зависит от нас – то есть именно от функциональности разработанного нами кода. Этот компонент для проекта был важнее, чем казалось изначально. Пришлось собираться всей командой и обдумывать, сможем ли мы обеспечить функциональность самостоятельно или придется смириться с последствиями ее отсутствия.
Важно отметить, что это не история провала. Если бы мы не приняли решение заняться вариантом Б, то никогда бы не выявили все существующие зависимости и факторы проектных замыслов. Я уверен, что умные команды выявляют требования и зависимости на раннем этапе, но если проект сложный, невозможно отыскать их все. Сомневаюсь, что время, потраченное на моделирование сложных систем с целью отметить все зависимости и взаимосвязи, всегда оправданно (если темп работы высокий, а проект сложный, эти модели обойдутся недешево). Все зависит от потребностей проекта. Мы сделали ставку на командную работу в проектировании, чтобы вычленить эти моменты, и у нас все получилось.
В любом случае эта беготня туда-обратно, когда новые пути открываются и закрываются, когда наши предположения оказываются ошибочными, когда поднимаются новые вопросы, – это и есть процесс проектирования. Обычно его называют итерацией, то есть детали дорабатываются постепенно, со временем (потому что проблема настолько сложная, что решения нужно несколько раз скорректировать, чтобы получить качественный результат).
Если говорить о проектировании, итерация предполагает два шага вперед и один шаг назад. Чем сложнее работа, тем выше соотношение (то есть по полтора шага вперед на каждый шаг назад). Но пока не сделаешь шаг вперед и не примешь какое-то решение («Давайте займемся вариантом Б!»), не разглядишь всех проблем и трудностей. Принимать эти решения во время проектирования, даже если они окажутся ошибочными, – единственный способ пролить свет на трудности и проблемы. Если правильно все спланировать, вы много раз ошибетесь, но значительно увеличите шансы на успех. Проектирование, дизайн и научные исследования имеют схожие черты, как показывает эта цитата:
Нам предстоит масса проб и ошибок… Мы мечемся между наблюдением и теорией. Без теории мы не знаем, что искать, а без анализа фактов невозможно проверить теорию… Уверен, что движение взад-вперед происходит тысячи, даже миллионы раз на протяжении одного-единственного исследования.
КРЕАТИВНАЯ РАБОТА ОБЛАДАЕТ СОБСТВЕННОЙ ИНЕРЦИЕЙ
Креативная инерция проекта всегда сильнее, чем ожидают неопытные лидеры и менеджеры. Сократить количество идей до одного-единственного (хорошего) варианта совсем непросто и требует совершенно не тех навыков, каких они ждали. Рисунок 6.1 предполагает, причем совершенно обоснованно, что времени для сужения области проблемы требуется ровно столько, сколько понадобилось бы на ее расширение. Однако чем инновационнее или креативнее проект, тем сложнее рассчитать это время. Сложность возникает из-за инерции креативной работы.
Причина этой инерции заключается в том, что скорость появления новых вопросов и задач, которые возникают по ходу работы, превосходит скорость решения старых задач. Каждый участник процесса чувствует эту тенденцию. Даже если до утверждения спецификаций еще несколько недель, многие считают, что график сорвется (или еще хуже: что с этим ничего не поделаешь, потому что менеджеры ничего не замечают). Это зачастую первая серьезная причина, по которой проект начинает буксовать. Задержки происходят постепенно, причем опасность ситуации постоянно недооценивается, пока проблема не разрастается до таких масштабов, что ее трудно исправить. (Как корректировать график проекта, мы обсудим в главе 14 и главе 15.)
Итак, на рисунке 6.2 (он заметно уродливее рисунка 6.1, но, к сожалению, более реалистичный) видно, что команда трудится, засучив рукава, однако по-прежнему маловероятно, что спецификации удастся написать вовремя. Темпы решения задач довольно приличные, и процесс идет в нужном направлении, однако его траектория не соответствует дедлайну спецификаций.
Рис. 6.2. Область проблемы растет и сужается на протяжении обсуждения проектного замысла из-за неожиданной инерции креативной работы
Зачастую у МП это первый повод для паники. До этого момента все было абстрактным: слова, цели, списки и презентации. Но когда проектных решений еще нет, а дедлайн спецификаций неумолимо приближается, людям становится страшно. Некоторые стараются спрятаться от реальности и винят во всем других, навязывают неудачные решения или напрочь отрицают возможность провала. В главе 7 мы обсудим один из методов решения проблемы запоздавших спецификаций; в главе 11 поговорим, что делать, когда все из рук вон плохо. А в этой главе я хотел бы предложить эффективный способ управлять идеями и избежать подобных трудностей.
Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?
