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

Более формально я называю эти явления и отношения между ними как «технологический продукт» и «бизнес-продукт». Первое – это инструмент, созданный с помощью технологий. Второе – вся совокупность бизнес-инфраструктуры, задействованной для выполнения решаемой бизнесом задачи, и представленной клиенту в виде услуги или сервиса. Бизнес-продукт включает в себя технологический продукт. В примере с транспортной компанией технологическим продуктом выступает автомобиль, бизнес-продуктом – услуга по перевозке груза из пункта А в пункт Б.

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

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

Проблема в том, что задача формулируется прежде всего в технологической плоскости, например, «нам нужен сайт и мобильные приложения для продажи билетов». Вместо того чтобы посмотреть на уровень бизнеса и понять, как будет выстроена работа в целом и какова в ней роль технологий. Чтобы убедиться, что вы на правильном пути, нужно рассмотреть бизнес-модель, убрав из неё технологический продукт. Например, вы занимаетесь организацией логистической компании и рассчитываете, что компьютерная система сможет учитывать движения транспорта, оптимизировать загрузку, динамически распределяя заказы, и взаимодействовать с клиентами. Попробуйте смоделировать работу без системы, переложив все функции на людей, использующих телефон и электронные таблицы. Если вы все ещё способны представить такой бизнес, пусть и крайне неэффективный, то, значит, вы думаете в нужном направлении. Нет смысла ожидать, что разработчики смогут реализовать бизнес-логику, если даже вы не способны её самостоятельно сформулировать.

Теперь, когда с базовыми понятиями «бизнес-продукт» и «технологический продукт» мы разобрались, давайте посмотрим на другие части смыслового поля. Я часто использую термин «цифровой продукт», и его тоже важно объяснить. Вообще понятие «цифровой» начало активно применяться относительно недавно и до этого чаще использовалось по отношению к форматам передачи данных в паре с термином «аналоговый», например, «разница между цифровым и аналоговым звуком». Но с некоторых пор вошло в обиход как термин, описывающий все, что связано с компьютерными системами. До этого подобные системы было принято называть компьютерными, информационными, автоматизированными. Что-то мне подсказывает, через какое-то время этот термин тоже будет заменён чем-то ещё, как это часто бывает.

Со словом «продукт» тоже не все просто. Понятие «продукт» – это термин, который очень любят маркетологи. Он позволяет «упаковать» услугу, например, по страхованию, в цельное предложение для клиента. Хотя как услугу ни назови, она все равно ею остаётся. В нашем же случае речь идёт о «цифровом продукте», как об обобщающем термине, который может относиться только к технологическому продукту, а может описывать и в целом бизнес-продукт. Во втором случае речь идёт о продукте, реализованном на цифровых технологиях.

Перейти на страницу:

Похожие книги

Управление рисками
Управление рисками

Harvard Business Review – ведущий деловой журнал с многолетней историей. В этот сборник вошли лучшие статьи авторов HBR на тему риск-менеджмента.Инсайдерские атаки, саботаж, нарушение цепочек поставок, техногенные катастрофы и политические кризисы влияют на устойчивость организаций. Пытаясь их предотвратить, большинство руководителей вводят все новые и новые правила и принуждают сотрудников их выполнять. Однако переоценка некоторых рисков и невозможность предусмотреть скрытые угрозы приводят к тому, что компании нерационально расходуют ресурсы, а это может нанести серьезный, а то и непоправимый ущерб бизнесу. Прочитав этот сборник, вы узнаете о категориях рисков и внедрении процессов по управлению ими, научитесь использовать неопределенность для прорывных инноваций и сможете избежать распространенных ошибок прогнозирования, чтобы получить конкурентное преимущество.Статьи Нассима Талеба, Кондолизы Райс, Роберта Каплана и других авторов HBR помогут вам выстроить эффективную стратегию управления рисками и подготовиться к будущим вызовам.Способность компании противостоять штормам во многом зависит от того, насколько серьезно лидеры воспринимают свою функцию управления рисками в то время, когда светит солнце и горизонт чист.Иногда попытки уклониться от риска в действительности его увеличивают, а готовность принять на себя больше риска позволяет более эффективно им управлять.Все организации стремятся учиться на ошибках. Немногие ищут возможность почерпнуть что-то из событий, которые могли бы закончиться плохо, но все обошлось благодаря удачному стечению обстоятельств. Руководители должны понимать и учитывать: если люди спаслись, будучи на волосок от гибели, они склонны приписывать это устойчивости системы, хотя столь же вероятно, что сама эта ситуация сложилась из-за уязвимости системы.Для когоДля руководителей, глав компаний, генеральных директоров и собственников бизнеса.

Harvard Business Review (HBR) , Сергей Каледин , Тулкин Нарметов

Карьера, кадры / Экономика / Менеджмент / Финансы и бизнес
Чистый Agile. Основы гибкости
Чистый Agile. Основы гибкости

Прошло почти двадцать лет с тех пор как появился Манифест Agile. Легендарный Роберт Мартин (Дядя Боб) понял, что пора стряхнуть пыль с принципов Agile, и заново рассказать о гибком подходе не только новому поколению программистов, но и специалистам из других отраслей. Автор полюбившихся айтишникам книг «Чистый код», «Идеальный программист», «Чистая архитектура» стоял у истоков Agile. «Чистый Agile» устраняет недопонимание и путаницу, которые за годы существования Agile усложнили его применение по сравнению с изначальным замыслом.По сути Agile — это всего лишь небольшая подборка методов и инструментов, помогающая небольшим командам программистов управлять небольшими проектами,… но приводящая к большим результатам, потому что каждый крупный проект состоит из огромного количества кирпичиков. Пять десятков лет работы с проектами всех мыслимых видов и размеров позволяют Дяде Бобу показать, как на самом деле должен работать Agile.Если вы хотите понять преимущества Agile, не ищите лёгких путей — нужно правильно применять Agile. «Чистый Agile» расскажет, как это делать разработчикам, тестировщикам, руководителям, менеджерам проектов и клиентам.

Роберт Сесил Мартин , Роберт С. Мартин

Программирование, программы, базы данных / Менеджмент / Финансы и бизнес