В этой книге я не ставил цель рассказать обо всех технологиях, которые можно использовать в бизнесе. Это и невозможно. Приведенные примеры нужны, чтобы показать, под каким углом стоит на них смотреть. При этом важно помнить о принципе, который поможет подбирать технологии, способные влиять на бизнес.
Независимо от продукта или технологии, которую предполагается использовать, всегда стоит задаваться вопросами: «Как этот инструмент изменит модель работы? Какие возможности он создаст? Как повлияет на финансовые или организационные аспекты?» Если никак, то использование продукта – просто эмоциональный выбор, как смена одежды или покупка новой машины при наличии исправной. В этом тоже есть смысл, но важно понимать, в чем именно, например, в создании новой рабочей атмосферы или изменении образа компании в глазах потребителей.
Выше я описал идею постоянного изучения возможных путей развития бизнеса с помощью цифровых технологий. Если смотреть на эту задачу с точки зрения предпринимателей, то есть смысл концентрировать свое внимание в большей степени на соседних отраслях, нежели на своей. Таким образом можно обнаружить неочевидные решения.
С другой стороны, если вы профессионально занимаетесь проектированием и созданием цифровых продуктов, то ваша ценность заключается в знании технологий и способов их применения. Представьте двухмерную таблицу, где по одной оси находятся отрасли, а по другой – цифровые технологии. На их пересечении и находятся области поиска решений. В шестой главе под названием «Кодекс проектировщика» я рассказываю о подходе создания отраслевых концептов как методе проведения собственных исследований. Забегая вперед, скажу, что работа над концептами для разных отраслей – одна из важных составляющих в деятельности проджект-раннера, если он хочет создавать продукты вместе с бизнесом.
Дилемма бизнеса и IT-специалистов
Компании, занимающиеся внедрением систем автоматизации компаний, и разработчики цифровых продуктов часто обосновывают необходимость внедрения подобных продуктов требованием соответствовать современному уровню. К сожалению, при этом не звучит объяснения, что именно под этим подразумевается и как отразится на результатах работы компании. Их можно понять, ведь их бизнес заключается в создании технических решений. В таком случае честный ответ на вопрос «зачем» может помешать продажам.
Здесь возникает дилемма: требования бизнеса не отменяют того, что проект должен быть интересен специалистам, создающим продукт. Для классных и увлеченных специалистов деньги не являются единственной мотивацией. Им нужна интересная задача, ради которой они готовы на многое. Поэтому успешные проекты – это всегда история взаимного интереса, когда обе стороны дают друг другу то, что нужно. Это правило позволяет создавать сложные цифровые продукты, которые полезны бизнесу и конечным пользователям.
В следующей главе я подробно расскажу, как устроена индустрия создания цифровых продуктов. Понимая типы проектов и компаний, работающих над ними, у каждой из сторон появляется больше шансов получить нужный результат.
Глава 2Как устроена индустрия создания цифровых продуктов
Содержание главы:
• Зачем нужно знать устройство IT-индустрии
• Типы проектов
• Форматы работы
• Экономика проектов
• Экосистема IT-индустрии и продюсирование проектов
Зачем нужно знать устройство IT-индустрии
Начну с утверждения, что в индустрии разработки цифровых продуктов накопилось много противоречий, связанных с форматами работы и бизнес-моделями, которые используют агентства, продакшены, студии дизайна и внутренние продуктовые подразделения. Что интересно, большинство ее участников – владельцев, менеджеров проектов, дизайнеров продуктов и всех тех, кто так или иначе занимается организацией проектов, – не видят общей картины. Часто единожды сложившуюся схему работы на одном проекте они используют во всех остальных, не беря в расчет ни особенностей клиента, ни его действительных потребностей.
Аналогично и бизнес зачастую не различает специализации подрядчиков, и называют всех просто «разработчиками», независимо от того, идет ли речь про дизайнеров мобильных интерфейсов или про инфраструктурных серверных инженеров. Очевидно, что, если рассматривать цифровые продукты в качестве ключевых инструментов современного бизнеса, такой подход дает все что угодно, кроме хорошего результата. Ведь если вы хотите получить продукт, который решит ваши задачи, необходимо четко их сформулировать и найти тех, кто лучше всего подойдет для их реаизации.
Здесь кроется основное противоречие. Чтобы перейти от задач бизнеса к их решению на уровне конкретных цифровых продуктов, нужно находиться на стыке обеих сфер деятельности. Но специалисты часто не понимают язык бизнеса, а бизнес не разбирается в том, как устроена индустрия создания цифровых продуктов. Поэтому одни настаивают на четкой постановке задач на техническом уровне, а другие ждут, что от них требуется только заплатить и ждать результат. Возможно, такой подход бы сработал, но только когда бизнес знает, кто именно решит его задачу.
Продюсерский подход как основа «Метод параноика» позволяет устранить описанное противоречие. Он объясняет, как выстроить отношения между бизнесом и специалистами, кто должен находиться между ними на пересечении разных компетенций и как перейти от замысла к конкретному воплощению. В конечном счете успех проекта зависит не только от подходящей конфигурации команды, но и от организации работы таким образом, чтобы могли проявиться лучшие качества участников.
Для этого нужно понимать, кто основные игроки IT-экосистемы и по каким правилам идет игра. Если вы в индустрии, это описание поможет вам системно посмотреть на профессиональный мир вокруг вас. Если вы ищете помощь в создании мобильного приложения или цифрового сервиса для бизнеса, эта глава даст понимание, как классифицировать задачу и к кому обратиться.
Первое, что нужно знать об отрасли разработки программных продуктов – все зависит от конкретных людей. В рамках одной задачи и одного проектного процесса у двух, казалось бы, схожих по квалификации специалистов будет совершенно разный результат. Понятие типовой производительности в час – иллюзия, корни которой уходят в индустриальные времена, когда рабочий должен был выдавать норму выработки в рамках налаженного технологического процесса, например, на конвейере по производству машин или гамбургеров. Это означает, что точная предварительная оценка проекта невозможна в принципе. Связано это не только с индивидуальной скоростью работы, но и с тем, что разные специалисты по-разному решат одну и ту же задачу. На этом сложности только начинаются.
Помню, как впервые прочитал книгу Дэвида Майстера «Управление фирмой, оказывающей профессиональные услуги». На тот момент компании «ГАЛС СОФТ» было уже 10 лет, и, к своему удивлению и восторгу, я нашел в этой книге ответы на большинство накопившихся вопросов. Я был поражен, как все просто складывалось. Майстер писал про юридические и консалтинговые компании, я же адаптировал описанную модель под реалии IT-индустрии. В итоге после анализа нашей деятельности мы кардинально изменили формат работы с клиентами, а с некоторыми из них даже завершили проекты, чтобы сфокусироваться на приоритетных задачах. Всем, кто занимается проектной деятельностью, настоятельно рекомендую прочесть как минимум две книги – «Управление фирмой, оказывающей профессиональные услуги» и «Истинный профессионализм».
Типы проектов
По мнению Дэвида Майстера, существует три обобщенных типа проектов – «Мозги», «Седина» и «Процедуры» (Brains, Grey Hair, Procedures).
«Мозги» – это решение новых задач, например, создание сервиса для новой банковской бизнес-модели. Такие проекты похожи на исследовательскую работу, и специалисты, работающие над ними, должны быть опытными профессионалами с навыками поиска нестандартных решений.
Второй тип, «Седина», ориентирован на проекты, где клиент заинтересован в отраслевых или технологических наработках подрядчика. Примером может служить обращение розничной сети к компании, которая имеет опыт внедрения программ лояльности. Такая компания уже выработала подходящие решения, на реальных проектах выявила сильные и слабые стороны технологии, сформировала процесс внедрения и создала команду, способную данное решение внедрять, запускать и поддерживать.
Третий тип – это предоставление клиенту того, что я называю комодити-услугами, аналогично комодити-товарам – нефти, электричеству или транспортным услугам. Это типовые задачи, которые могут решать квалифицированные специалисты, например, разработка программных компонентов по детальной спецификации в определенной технологической среде или дизайн интерфейса системы с известными функциональными требованиями в соответствии с фирменным брендбуком. Главная ценность здесь – не уникальные компетенции, а способность подрядчика сделать эту услугу более дешевой или более организованной. Поэтому этот тип проектов называется «Процедуры», поскольку клиенту проще и дешевле «покупать часы разработчиков», чем нанимать собственных специалистов.
Описанная модель структурирования проектов по типам помогает диагностировать и выбирать проекты на раннем этапе. Ошибочное определение типа проекта или игнорирование этого аспекта приводит к проблемам. Каждый, кто проработал в нашей отрасли хотя бы несколько лет, наверняка увидит что-то знакомое в том, что описано дальше.
Например, уникальный проект типа «Мозги» вряд ли смогут одолеть недостаточно опытные специалисты, независимо от их количества. Но даже если такой проект делает квалифицированная команда, это не избавляет от проблем с оценкой, которая здесь невозможна. Так как это исследовательский тип работ, нельзя заранее сказать, будет ли найдено решение. Есть просто разумные пределы бюджета и сроков, после которых для клиента решение поставленной задачи становится нецелесообразным.