Пользовательские истории. Искусство гибкой разработки ПО - [2]

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

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

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

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

Метод построения карт историй, созданный Джеффом, находят полезным разработчики, и точно так же его оценивают дизайнеры. Карты историй – Розеттский камень нашего цифрового века.

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

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

Современный мир бизнеса доказал, что команде из 200–300 человек почти невозможно создать продукт, который понравится пользователям. В то же время сообществу стартапов известно, что команда из четырех-пяти человек способна создать небольшой продукт, который люди полюбят, но даже эти маленькие продукты со временем растут и теряют свой блеск. Большие программы используются большой аудиторией и решают сложные коммерчески успешные задачи. Ждать, что вы легко их изучите и в процессе работы станете получать удовольствие, сложно да и просто смешно.

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

Алан Купер, 17 июня 2014 года

Предисловие Марти Когана

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

Кроме этого, мне часто приходилось помогать компаниям, у которых дела идут не так здорово. Это были стартапы, пытающиеся запустить хоть что-то работающее, прежде чем кончатся деньги. Компании покрупнее, выбивающиеся из сил в попытке воплотить в жизнь свои последние разработки. Команды, безуспешно пытающиеся повысить эффективность бизнеса. Лидеры, раздраженные тем, как много времени занимает переход от идеи к воплощению. Инженеры, конфликтующие с владельцами своих продуктов.

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

Эта книга называется «Пользовательские истории. Искусство гибкой разработки ПО», но очень скоро вы заметите, что она повествует о чем-то большем, чем такая простая, но мощная техника, как построение пользовательских карт историй. С помощью книги можно проникнуть в самую суть того, как команды сотрудничают, общаются и в конце концов приходят к созданию великолепных продуктов.

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