Вадим Митякин - Метод параноика. Как взять под контроль неопределённость в проектах при создании цифровых продуктов для бизнеса
- Название:Метод параноика. Как взять под контроль неопределённость в проектах при создании цифровых продуктов для бизнеса
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:2022
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Вадим Митякин - Метод параноика. Как взять под контроль неопределённость в проектах при создании цифровых продуктов для бизнеса краткое содержание
Эта книга – результат нескольких лет экспериментов и исследований, в основе которых лежит практический опыт использования описанного метода в стартапах и действующих компаниях. Для деловой аудитории она даёт понимание, чем на самом деле являются цифровые продукты в бизнесе и как устроена индустрия, их создающая. В свою очередь, профессионалы получают модель работы над проектами, позволяющую пройти полный путь от создания концепции продукта до его запуска. Автор книги – практик из мира бизнеса и ИТ.
Метод параноика. Как взять под контроль неопределённость в проектах при создании цифровых продуктов для бизнеса - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Доказательством верности такого подхода оказалось то, что, работая над «Красной» книгой я много раз делал для себя серьёзные открытия, которые шли вразрез с тем, что считается статус-кво. Казалось бы, столько всего было обсуждено с коллегами, столько выполнено проектов, но последовательная логика подводила к совсем другим выводам. И что интересно, эти выводы в дальнейшем подтверждались на практике.
В литературе есть такое выражение: «герой книги начал жить своей жизнью». Что-то похожее произошло и с описываемым методом. Обозначив аксиономические отправные точки, приложив базу знаний в виде систематизированного опыта, а дальше начав двигаться по логическому дереву, модель проектной работы предстала в несколько ином виде, чем мне представлялось изначально. В результате получилась системная, концептуально целостная конструкция, которая подобно фундаменту способна выдержать и интерпретационный и инструментальный уровни метода.
Помимо трёх частей книги, мы с коллегами задумались и уже начали работу над учебными материалами как в живом формате с личным общением, так и в виде записанных лекций. Это тем более интересно, т.к. каждый из нас имеет практику преподавания. Вся информация о «Методе параноика» собрана на ресурсе https://paranoidmethod.org, включая книги, материалы и т.д. Кстати, «Красная» книга доступна в открытом виде на этом же ресурсе. Там же можно найти ссылки на все внешние источники и каналы.
История вопроса
Индустрия создания цифровых продуктов – это экосистема. Как будет показано дальше, большинство проектов реализуется несколькими компаниями, командами и даже отдельными специалистами в симбиозе друг с другом. Клиенты обращаются в одну компанию, например дизайн-бюро, эти ребята нанимают себе в помощь продакшен для разработки и т.п. Часто нельзя точно определить полный состав проектной команды и где географически находятся все её участники.
Компания «ГАЛС СОФТ», которую я создал в 2002 году, тоже не была исключением. За 15 лет существования компании, вплоть до момента, когда я придумал новый формат – продюсирование ИТ-проектов, мы выполнили больше тысячи проектов и для большинства из них привлекали внешних участников. Очень быстро мы поняли, что недостаточно передать подрядчику простую постановку задачи в виде требований к продукту. Количество возможных интерпретаций и способов реализации могло быть каким угодно, но самое главное, что результат работы мог быть непредсказуемым. Постепенно все больше ключевых проектных решений мы начали принимать на своей стороне и уделять проектированию много внимания. Нашим языком общения с другими членами команд стала проектная документация. Это был единственный способ локализовать неопределённость, от которой зависела успешность проектов, которые мы выполняли для наших клиентов.
С помощью проектирования появлялась возможность управлять качеством будущего продукта, ведь у проектировщика есть возможность смотреть на всю картину в целом, избегать локальной оптимизации в угоду общих целей проекта, при этом обеспечивать целостность всей архитектуры продукта. А самое главное – выявлять возможные риски в технической реализации ещё до начала разработки.
Анализируя полученный опыт, я думаю, нам в некотором смысле повезло. Мы практически сразу начали работать с крупными клиентами (системный интегратор КРОК, компания Майкрософт), поэтому, в отличие от других команд, не могли работать в формате «все в одной комнате». Нам нужно было расширять состав проектных команд, одновременно вести пару десятков проектов. При этом мы занимались работой на результат, когда клиент ждал от нас готовый продукт, а не просто покупал часы разработчиков. Иными словами, мы не могли оставаться с иллюзией, что можно делать сложные продукты без проектирования и документации. Как показала практика, даже в проектах, где дизайнеры и разработчики сидят рядом друг с другом, устного общения оказывается недостаточно.
Чтобы мои слова не показались необоснованными, я приведу в качестве примера проекты, над которыми нам повезло поработать. История «ГАЛС СОФТ» началась с того, что я в возрасте 23 лет, будучи начинающим разработчиком с 5-летним стажем, при этом начитавшимся книг про проекты создания операционных систем, задумал сделать систему управления предприятием. На тот момент я уже участвовал в похожем проекте, и мои старшие коллеги показали, как системный взгляд на задачи позволяет находить нетривиальные решения. Например, мы спроектировали распределённую модель хранения данных о движениях товаров для нескольких офисов, не имеющих постоянного сетевого соединения. Все это было сделано ещё до появления чего-то похожего на блокчейн.
В работе над своим продуктом я хотел пойти дальше. Вместе с командой «ГАЛС СОФТ» мы разработали систему, имевшую встроенный редактор бизнес-процессов с внутренним скриптовым языком, распределённую сетевую архитектуру, базу данных с динамической структурой, возможность интеграции с внешними системами. На создание продукта ушло два года. Первым клиентом стал крупнейший на тот момент в России системный интегратор КРОК, в 2004 году внедривший нашу систему на полторы сотни рабочих мест. Мы сделали интеграцию с внутренним порталом для ведения документооборота по регламенту и со складской системой для отслеживания движений оборудования при поставках клиентам.
В дальнейшем мы много работали над созданием корпоративных систем и порталов, например, мы развивали корпоративные порталы Майкрософта и ТНК-BP, разрабатывали системы для анализа продаж в Хонде и Логитеке, делали внутренний сервис для Лаборатории Касперского. С каждым следующим проектом появлялся новый опыт, мы многому научились в том числе и у своих клиентов. При этом попытки создания сложных систем без предварительной глубокой проработки и проектирования всегда приводили к серьёзным проблемам в проектах.
Самые интересные проекты начались, когда мы занялись мобильными приложениями. Нашим первым проектом было создание мобильного приложения для livejournal.com. В тот момент в 2009 году «Живой Журнал» был жив как никогда и нам повезло создать приложения для Android и Windows Phone. Безусловно, это были непростые проекты, не в последнюю очередь по нашей вине. Тогда мы только искали оптимальный процесс, который бы объединял работу проектировщиков, дизайнеров и разработчиков. В дальнейшем мы создали приложения для Ведомостей и Афиши. А спроектированное и разработанное нами мобильное приложение издательского дома Коммерсантъ стало одним из лучших приложений в мире для СМИ по версии Google в 2014 году. На тот момент мы ещё не до конца отладили проектный процесс, но важность предварительного проектирования поняли в полной степени, и это давало свои результаты.
Читать дальшеИнтервал:
Закладка: