Исследователь из Стэндфордского университета Клиффорд Насс (Clifford Nass) предполагал, что те люди, которые делают много дел одновременно, в любом случае развивают какие-то другие удивительные способности. Ему казалось, что они должны быть великолепны в сортировке информации и быстром переключении между задачами, а также обязаны обладать хорошей кратковременной памятью.
Как ни печально, но в результате своих исследований профессор Насс открыл, что все его предположения оказались ошибочными – ни одно из трех не подтвердилось:
«Мы были просто шокированы. Мы все ошибались. Оказалось, что те, кто делает несколько дел одновременно, просто ужасны во всех аспектах многозадачности».
Проблема многозадачности особенно остро стоит среди молодого поколения. Современные дети вырастают в условиях многозадачности, так что в юности для них является естественным смотреть ТВ во время работы, печатать текст во время разговора по телефону, вообще никогда не вынимать из ушей плеер и т.д. Им кажется, что производительность труда совсем не страдает, а все разговоры на данную тему — придирки людей старшего поколения, чьи мозги не способны на такое.
Однако, на самом деле человеческий мозг демонстрирует самые плачевные результаты, когда его периодически отвлекают или заставляют выполнять несколько задач одновременно. Без разницы, о каких задачах идет речь: вождение автомобиля и разговор по мобильнику, программирование и чтение почты или даже простое нажатие кнопки во время разговора.
Результаты научных исследований показывают, что в среднем каждый человек тратит примерно 28 процентов своего рабочего дня на прерывания и неэффективные действия. И главная причина этого, пожалуй, в многозадачности (или переключении между задачами).
Игорь Полонский, руководитель и основатель event-агентства «Режиссерская версия», размышляя о работе в режиме многозадачности, говорит: «Если ты строишь систему, в которой за каждую функцию отвечает отдельный человек, многозадачному сотруднику не находится в ней места. Какое-то время он еще может поработать, но в итоге будет проигрывать узкоспециализированным коллегам, которые с каждой отдельной задачей справляются эффективнее и быстрее». Результаты работы агентства подтверждают эти слова: за первый год реализовано около 12 проектов, за второй – более 40 проектов.
Не будем скрывать – нам нравится гордо считать себя человеком многозадачным. Доказано, что люди, склонные к мультитаскингу, менее результативны, но зато чувствуют более сильную эмоциональную удовлетворенность от иллюзии продуктивной работы.
Продукт как можно раньше начинает работать, выполнять своё полезное действие, зарабатывать деньги, расширять аудиторию.
Чем больше функций, тем больше их пересечений, а значит мест для ошибки. Поэтому отказ от функции помогает уменьшить количество узких мест и повысить качество первой версии.
Открытый вовремя продукт помогает быстрее узнать правду о продукте: изучить мнение пользователей и проверить гипотезы. Возможно, убранная функция никогда и не понадобится, и силы будет лучше потратить на другую.
Новый продукт с небольшим числом функций легче объяснить пользователям. Только мы знаем о том, что часть идей не реализовали. Пользователям они бы только добавили сложностей.
Когда отложенная функция добавится во второй версии, будет кого ей порадовать. Кроме того, новая функция — это информационный повод, лишняя причина рассказать о продукте.
Самая большая ошибка — предполагать, что проект пойдёт, как задумано.
Проект — это путешествие из точки А в точку Б, полное неожиданностей и приключений.
Начиная движение, проект сталкивается с сопротивлением окружающей среды. Дизайнер забывает учесть сложный случай. Клиенту не нравится дизайн. Программистов тормозит проблема в реализации. Кто-то заболевает. У кого-то ломается компьютер. Можно перечислять возможные сюрпризы, но в каждом проекте будут свои.
Проект движется и колеблется вокруг идеальной линии, и, возможно, придёт в совсем другую точку Б’:
Закон о потерях: нельзя реализовать задуманный проект за 100% времени, 100% денег, со 100%-й функциональностью и без потери качества. При отклонении от курса придётся чем-то пожертвовать. Чем именно — жизненный выбор.
Репутация зарабатывается годами, а теряется за один день. Поэтому жертвовать качеством — не вариант.
Фиксируем срок. Если команда не успевает доделать проект вовремя, обычное решение — сдвинуть срок запуска. Но время — невосполнимый ресурс, недаром deadline происходит от слова «смерть». За отпущенное нам время мы успеем только то, что успеем. Чтобы не уходить в мрачные аналогии, мы сравниваем запуск проекта с наступлением Нового года. Отодвинуть его нельзя, даже если ты не успел купить подарки. Мы не сдвигаем срок.
Фиксируем бюджет. Когда проблемы в проекте решают деньгами, это означает одно из двух: либо оплачивают дополнительное время, либо расширяют команду. Первое не подходит. А увеличение команды нередко снижает управляемость проекта и только усугубляет его проблемы.
Флексим. Когда жертвовать сроком, бюджетом и качеством нельзя, методом исключения приходим к одному: жертвуем функциями, «флексим». Отрезаем то, что не успеваем сделать.
Этот вариант — большая удача:
Аббревиатура ФФФ означает fix time, fix budget, flex scope. Мы работаем с фиксированными сроками и бюджетом, а функциональность оставляем гибкой
Продукт как можно раньше начинает работать, выполнять своё полезное действие, зарабатывать деньги, расширять аудиторию.
Чем больше функций, тем больше их пересечений, а значит мест для ошибки. Поэтому отказ от функции помогает уменьшить количество узких мест и повысить качество первой версии.
Открытый вовремя продукт помогает быстрее узнать правду о продукте: изучить мнение пользователей и проверить гипотезы. Возможно, убранная функция никогда и не понадобится, и силы будет лучше потратить на другую.
Новый продукт с небольшим числом функций легче объяснить пользователям. Только мы знаем о том, что часть идей не реализовали. Пользователям они бы только добавили сложностей.
Когда отложенная функция добавится во второй версии, будет кого ей порадовать. Кроме того, новая функция — это информационный повод, лишняя причина рассказать о продукте.
Часть клиентов соглашаются с этим подходом, часть — нет. Но даже если клиент согласен, это не значит, что проблем не возникнет. Мы честно предупреждаем о подводных камнях.
Флексить страшно
Несмотря на плюсы, звучит устрашающе: в запущенном с нами продукте оказывается меньше функций, чем изначально планировалось. Мы понимаем, что наш подход к ведению проектов может выглядеть как шарлатанство в глазах некоторых клиентов.
Любой человек, если заказывает ящик апельсинов, а потом точно в срок получает отличные апельсины, но только пол-ящика, почувствует себя обманутым. Но доставка апельсинов — стандартизованная процедура с отлаженной логистикой. Риски предсказуемы и сразу заложены в цену.
С проектами иначе. У Колумба в экспедиции были бунты, болезни, поломки и штормы. И в результате он открыл вовсе не ту страну, на путешествие в которую собирал деньги.
Проект гораздо больше похож на экспедицию, чем на доставку апельсинов.
Флексить больно
В продукте будет меньше функций, чем изначально планировалось
Одно дело решить делать зарядку по утрам, другое дело — делать её. Когда приходит время отказаться от какой-то задумки, больно всем. Дизайнерам больно, потому что они придумали классную фишку, но её не будет в продукте. Разработчикам обидно, потому что они потратили силы на отладку функции, а её пришлось убрать. Но больнее всех клиенту, который придумал проект и имел от него свои ожидания.
Не все готовы к этой боли.
Клиент — предприниматель
Больнее всех — клиенту
Мы работаем напрямую с предпринимателем — человеком, который затеял проект и принимает в нём все решения. Обычно это директор компании. Мы привлекаем его с самой первой встречи, ведь самое главное говорится в начале.
Чтобы сделать проект без директора или с минимальным его участием, нужно либо лишить его права голоса (что звучит неправдоподобно), либо попросить его делегировать задачу человеку, которому он полностью доверяет.
Опыт показывает, что если мы будем пытаться угодить нескольким «клиентам» одновременно, проект получится болезненным, а продукт — беззубым и компромиссным. Мы не сможем взяться за проект, в котором больше одного командира.
Результат — это пуск
Работаем с тем, кто принимает решения
Обычно дизайнеры отдают клиенту картинки.
Но большинство дизайнерских решений принимается на этапе разработки. Что произойдёт, если пользователь нажмёт на эту кнопочку при незаполненной форме? Что делать, если в реальной базе данных на странице оказывается в три раза больше текста, чем предусмотрено дизайном? Как выглядит 404-я ошибка при ширине экрана 2000 пикселей? Поскольку дизайнер не позаботился об организации этого этапа, а клиент не подозревает о проблемах, все решения достаются бесконтрольным программистам:
Дизайнер кладёт скриншоты в портфолио, а на реальный продукт без боли не взглянешь.
Раньше бюро пыталось осуществлять авторский контроль над разработкой через клиента:
Дизайн не заканчивается на картинках
Дизайнеры спамят клиента замечаниями о том, что продукт не похож на картинку. Клиент передаёт программистам. Программисты кладут в баг-трекер. Список проблем растёт быстрее, чем его успевают разгребать. Дизайнеры паникуют, запуск несколько раз откладывается, в конце концов клиент вынужден открыть сырой продукт.
Чтобы повысить эффективность коммуникации в проекте, нужно оставить клиенту принятие ключевых решений, а общение о поведении кнопки на форме обратной связи вести напрямую с программистами:
Авторский контроль через клиента не работает
Решения в любом проекте принимаются постоянно. Ни подписание ТЗ, ни утверждение чертежа не способны зафиксировать конструкцию будущего самолёта. Если вы создаёте пользовательский интерфейс, большая часть решений во время его разработки будут дизайнерскими — кто бы их ни принимал. Лучше, чтобы решения принимали дизайнеры совместно с клиентом, а затем напрямую, через технического директора, транслировали их в разработку.
Дизайнерское управление разработкой гарантирует, что программисты будут работать не на ТЗ и баг-трекер, а на проект. Перед началом проекта мы тестируем разработчиков. В проекте — руководим ими. Это может не подойти вашему техническому директору.
Регулярные пуски
Руководим вашей командой разработки. Перед началом тестируем её. Вашему техническому директору это может не подойти
Предположим, в продукте задумано четыре функции, а разработка оценена в четыре месяца. Тогда, теоретически, через четыре месяца откроются эти четыре функции:
Но это теоретически. В жизни длинные проекты не идут по плану. Сначала дедлайн кажется бесконечно далёким и все расслабляются. К концу все устают от труда без видимого результата и опускают руки. Работа требует длительных вложений без информации о том, правильно ли приложена сила.
Мы разбиваем большой проект на короткие итерации. Результат каждой — пуск полезной функциональности:
Так каждая отдельная функция начнёт приносить аудиторию и доход гораздо раньше, а если в процессе работы мы поймём, что первоначальный набор функций и план были неверными, сможем скорректировать работу.
Ритмичные пуски держат команду в тонусе: во-первых, пуск всегда вот-вот, и расслабляться некогда; во-вторых, ничто так не вдохновляет команду, как объявление «Мы открылись».
Никаких сюрпризов
Разбиваем большой проект на короткие итерации с регулярными пусками
Как идёт проект по ФФФ? В самом начале мы пишем понедельный план от начала работы до пуска. Для каждой недели известна работа и результат.
За пуск проекта отвечает ведущий дизайнер: он понимает задачу, руководит работой дизайнеров, проводит презентации, согласовывает замечания с клиентом, передаёт задачи разработчикам и проверяет, чтобы всё было сделано вовремя. Если на очередной неделе что-то пошло не так и есть угроза сроку, вероятно, придётся флексить.
Самый страшный грех ведущего дизайнера — принести клиенту в последний день половину проекта и спокойно сказать «мы успели только это». Сколько бы ни обсуждался флекс перед началом проекта, любой клиент будет возмущён, если его просто поставят перед фактом, что чего-то не будет.
Когда возникает угроза сроку, приходится принимать решение об упрощении дизайна или ограничении функциональности. Ведущий дизайнер предлагает решение, клиент принимает его или предлагает своё. Достижение договорённости о «флексе» — наша взаимная ответственность с клиентом.
Вопросы
Решение о конкретном способе флекса принимаем вместе с клиентом
Часто ли реально приходится жертвовать функциональностью в проектах?
Всегда. Флекс — это не особый инструмент на случай редких исключительных ситуаций. Это часть любого проекта. Всегда что-то приходится корректировать по ходу: где-то упрощаем дизайн, где-то заменяем одно решение на другое, а где-то отрезаем функцию целиком.
Нельзя ли заложить достаточно времени, чтобы точно всё успеть?
При планировании мы берём небольшой запас, руководствуясь принципом «не впритык». Но жизнь преподносит сюрпризы. Сколько времени ни закладывай, гарантии «точно всё успеть» это не даст.
Если продукт открылся в срок, но без части функций, будут ли доделаны отложенные функции после пуска?
Возможно, по итогам пуска будет принято решение делать совсем не то, что планировалось изначально — сила подхода в том, что он позволяет своевременно скорректировать курс. Мы будем рады, если вы решите продолжить с нами работу над продуктом в новой итерации. Эта работа оценивается дополнительно.
Разве выпустить продукт без половины задуманных функций — это не «жертвовать качеством»?
В первом Айфоне не было диктофона, видео и буфера обмена (которые уже были даже в обычных Нокиях). Но то, что было, было сделано на отлично. Мы за такое.
Почему бы не реализовать ещё одну полезную функцию, вместо того чтобы отлаживать плавность анимации?
Мы сами за пользу. Но когда мы вместе с клиентом выбрали, какую функцию реализовать, надо сделать это хорошо. Тормоза, глюки и опечатки создают впечатление ненадёжного продукта. Поэтому мы считаем, что лучше отладить одну функцию, чем выпустить две сырые. И всегда закладываем в план существенное время на полировку.
Неужели в продуктах, выпущенных с вашим участием, не бывает проблем с качеством?
У нас случаются проколы. Это самая большая боль. Куда большая, чем недостаток фич.
Выходит, вы как американские юристы — тупо берёте деньги за время?
Нет. Мы отвечаем за выход продукта в срок и за то, что он будет решать поставленную задачу, даже если конкретное решение будет отличаться от задуманного изначально.
Правильно ли мы поняли, что по вашим принципам вы обещаете больше, а делаете меньше?
Нет, ровно наоборот. Мы сразу говорим, что всё сделать не получится и чем-то придётся пожертвовать. Если вдруг получится успеть всё, что задумали, пусть это станет приятным сюрпризом. Лучше недообещать.
Вот буквально пара примеров из реальных документов, по которым надо было как-то оценивать объём работ и подписываться:
«Система должна обладать интуитивно-понятным графическим пользовательским интерфейсом», — в переводе на русский, это, скорее всего, означает что-то вроде: «Кроме консоли нужен GUI на русском и с большим количеством пояснений, потому что комплексом будет управлять секретарша». Скорее всего. Потому что может оказаться, что у заказчика есть свои представления об интуиции, и он будет настаивать именно на них. Но чаще всего эта фраза типовая для документации и, в целом, не очень опасная.
«Система должна обеспечивать простую и гибкую настройку прав доступа пользователя системы», — это уже на порядок хуже. Здесь не описано, какие бывают права, а разница в деталях сетевых ролей может повлиять на архитектуру. И, соответственно, на оборудование, которое нужно в проект.
Один раз встретилось после детального описания системы документооборота такое: «Срок хранения информации должен быть настраиваемым по периоду», — попробуйте угадать, что заказчик имел в виду. Вас интересует для начала, о какой именно информации речь и где она будет храниться. С равным успехом это может оказаться как обычная фраза о том, что должен быть доступен архив записей (что очень просто), так и то, что это должно быть резервное копирование на отдельную площадку.
Уточняю формулировку
При написании программ на языках с динамической типизацией сложнее выявить ошибки.
То, что в языках со статической типизацией выявляет компилятор еще до первого запуска программы, в языках с динамической типизацией может вылезти боком даже через полгода после запуска в эксплуатацию.