Метод параноика. Как взять под контроль неопределённость в проектах при создании цифровых продуктов для бизнеса

Метод параноика (часть 1): книга о создании цифровых продуктов, Вселенной и всем остальном
Вадим Митякин

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

Пролог

42

В один летний день я пришел на Стрелку. Вы должны догадаться, там студия Земфиры и где Ценципер открыл институт и КБ. Лекторий под открытым небом и много-много молодых людей. Все собрались, чтобы послушать лекцию девушки-дизайнера из Дании. Из анонса следовало, что она будет рассказывать про отражение реального мира в интерфейсе. Но у нее были свои планы. Она недавно написала книгу, и эта лекция была одной из многих, на которых она представляла результаты своей работы. Методично, страница за страницей, на которых были то отдельные пиксели левого верхнего угла кнопки, то список названий файлов в маковском файндере с указанием их размеров, то просто пустое белое пространство.

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

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

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

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

Чтобы всем было легче, прежде всего, конечно, мне самому, книга написана в формате серии эссе. Если вдруг кому-то покажется, что стиль слишком неформальный, знайте, я хотел сделать его еще более живым и личным, так что вы не ошиблись.

История вопроса

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

Компания «ГАЛС СОФТ», которую я создал в 2002 году, тоже не была исключением. За 15 лет существования компании, вплоть до момента, когда я придумал новый формат – продюсирование ИТ-проектов, мы выполнили больше тысячи проектов и для большинства из них привлекали внешних участников. Очень быстро мы поняли, что недостаточно передать подрядчику простую постановку задачи в виде требований к продукту. Количество возможных интерпретаций и способов реализации могло быть каким угодно, но самое главное, что результат работы мог быть непредсказуемым. Постепенно все больше ключевых проектных решений мы начали принимать на своей стороне и уделять проектированию много внимания. Нашим языком общения с другими членами команд стала проектная документация. Это был единственный способ локализовать неопределенность, от которой зависела успешность проектов, которые мы выполняли для наших клиентов.

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

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

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

В работе над своим продуктом я хотел пойти дальше. Вместе с командой «ГАЛС СОФТа» мы разработали систему, имевшую встроенный редактор бизнес-процессов с внутренним скриптовым языком, распределенную сетевую архитектуру, базу данных с динамической структурой, возможность интеграции с внешними системами. На создание продукта ушло два года. Первым клиентом стал крупнейший на тот момент в России системный интегратор КРОК, в 2004 году внедривший нашу систему на полторы сотни рабочих мест. Мы сделали интеграцию с внутренним порталом для ведения документооборота по регламенту и со складской системой для отслеживания движений оборудования при поставках клиентам.

В дальнейшем мы много работали над созданием корпоративных систем и порталов, например, мы развивали внутренние порталы Майкрософта и ТНК-BP, разрабатывали системы для анализа продаж в Хонде и Логитеке, делали внутренний сервис для Лаборатории Касперского. С каждым следующим проектом появлялся новый опыт, мы многому научились в том числе и у своих клиентов. При этом попытки создания сложных систем без предварительной глубокой проработки и проектирования всегда приводили к серьезным проблемам на проекте.

Самые интересные проекты начались, когда мы занялись мобильными приложениями. Нашим первым проектом было создание мобильного приложения для livejournal.com. В тот момент в 2009 году ЖЖ был жив как никогда и нам повезло создать приложения для Android и Windows Phone. Безусловно, это были непростые проекты, не в последнюю очередь по нашей вине. Тогда мы только искали оптимальный процесс, который бы объединял работу проектировщиков, дизайнеров и разработчиков. В дальнейшем мы создали приложения для Ведомостей и Афиши. А спроектированное и разработанное нами мобильное приложение издательского дома Коммерсантъ стало одним из лучших приложений в мире для СМИ по версии Google в 2014 году. На тот момент мы еще не до конца отладили проектный процесс, но важность предварительного проектирования поняли в полной степени, и это давало свои результаты.

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

В определенном смысле, благодаря такому подходу, мы достигли потолка в развитии компании. Дальнейший рост компании потребовал бы, как это ни странно, упрощения проектов, над которыми мы могли бы работать. Мне же хотелось двигаться дальше и пробовать свои силы в чем-то еще более интересном и сложном, кроме того, мне нравится непосредственно процесс проектирования и работать исключительно в административной роли мне не хотелось. Так, в результате я договорился об объединении «ГАЛС СОФТ» с одной из дружественных компаний и в 2016 году появился новый бренд на рынке заказной разработки мобильных приложений. Я же, после некоторого перерыва, запустил Цифровую артель Eleven, в которой выступаю как управляющий партнер и продюсер ИТ-проектов.

Поиск новой проектной модели

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

Так появилась роль продюсера ИТ-проектов и метод параноика.

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

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

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

Как устроена книга

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

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

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

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

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

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

Глава 1. Цифровые продукты

Doom

и новый мир

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

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

Сейчас набирают популярность системы с голосовым интерфейсом – колонки, приложения, чат-боты и виртуальные операторы. Тот факт, что устройство способно распознать речь и также ответить голосом, создает иллюзию, что с нами взаимодействует нечто, имеющее интеллект. А наш человеческий опыт говорит о том, что сам факт наличия интеллекта предполагает, что тот, кто им обладает, способен самостоятельно решать задачи. В результате у людей складывается впечатление, что устройства и приложения с голосовым интерфейсом могут решать любые поставленные им задачи. Даже если допустить такую возможность, остается открытым вопрос специализации подобной системы. Хотя каждый человек обладает интеллектом, не каждому можно поручить произвольную задачу.

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

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

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

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

Уже тогда я интуитивно начал понимать, в чем дело. У успеха продукта две стороны: одна – это решение задач пользователей, другая – быть первым, оказаться в нужное время в нужном месте и связать представление пользователей о задаче именно с этим продуктом, когда название продукта становится синонимом самой задачи. На мой взгляд, лучше всего об этом написал один из создателей Quake, Майкл Абраш в статье «Valve: как я здесь оказался, на что это похоже и чем я здесь занимаюсь»:

«Гэйб рассказывает об этом так. Когда он работал в Microsoft в начале 90-х, он провел опрос на тему того, какое ПО установлено на компьютерах работников. На втором месте по популярности оказалась Windows.

На первом был Doom.

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

Успех Doom'а наглядно показал, что этот подход больше не работал. Не было особого смысла в том, чтобы делать одну и ту же вещь даже дважды; практически вся ценность сосредотачивалась в воплощении творческого порыва в самый первый раз. После того как Doom был выпущен, тысячи программистов и художников могли сделать что-то подобное (и многие делали), но никто из них и близко не подошел к такому же эффекту. Проще говоря, если ты программист, возможно, ты вполне способен написать Facebook, или поисковый механизм как у Google, или Twitter, или браузер, и ты определенно можешь штамповать Tetris, или Angry Birds, или Words with Friends, или Farmville, или любую из сотен других чрезвычайно успешных программ. Однако прибыль от такой деятельности будет крайне мала, и в этом вся фишка – в эпоху Интернета софт имеет практически нулевую стоимость копирования и массивные сетевые эффекты, которые приводят к так называемой «спирали положительного фидбэка», а следовательно именно тот, кто первым сделает ход, будет доминировать».

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