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