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

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

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

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

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

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

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