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