Прабахарана Гопалана

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

В McKinsey я работал над проектами Построение цифрового бизнеса (DBB). Именно здесь мы создаем стартапы внутри основного бизнеса предприятия или рядом с ним, в конечном итоге привлекая новые таланты и способы работы, создавая при этом культуру инноваций, которая распространяется по всей организации.

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

Интересно, что ни одно из моих наблюдений не имеет ничего общего с самими техническими инструментами - не имеет ничего общего с каким-либо языком программирования или фреймворком (хотя некоторые концепции действительно относятся к Agile). Настоящее обучение относится к людям.

Неопределенность и эволюция как образ жизни

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

Команды крупных предприятий, как правило, с трудом справляются с этой неопределенностью и итеративным способом работы в первые дни обучения, особенно инженеры, которые привыкли иметь четко определенный набор предварительных спецификаций. Это проявляется в разговорах типа «зачем мы проводим рефакторинг?» или «Я думал, что технические руководители решили все эти проблемы, и я просто реализую это» или «как я должен писать код, когда некоторые варианты использования все еще обсуждаются?» или «вы заставили меня написать все тестовые примеры, и теперь, если я проведу рефакторинг, мне придется изменить почти все из них - почему вы не сказали мне об этом раньше?». Хотя в некоторых случаях эти опасения могут быть очень обоснованными, в большинстве случаев это показатель дискомфорта внутри команды, когда что-то меняется / развивается. Научить команды понимать, что изменения - это хорошо, и научиться процветать в условиях неопределенности - одна из самых больших проблем, с которыми я столкнулся.

По моему опыту DBB, наиболее эффективные команды обычно придерживаются следующих руководящих принципов:

  • Итеративная разработка за счет частых обновлений вместо длительного развертывания
  • Расплывчатая и коллективная ответственность (продукт принадлежит каждому, а не «это работа PO / Designer / QA»).
  • Измерение важных вещей (технический долг, ошибки, прогресс вместо усилий, например, сквозное выполнение вместо готового пользовательского интерфейса).
  • Код для измерения, позволяющий отслеживать использование, производительность и удовлетворенность пользователей ключевых элементов - в совокупности и по конкретным сегментам клиентов.
  • Больше разговоров, меньше кода
  • Практики программирования, которые помогают быстро и безболезненно предоставлять новые функции и устранять проблемы
  • Улучшения процессов, которые поддерживают все вышеперечисленное, например, управление изменениями, управление, управление рисками, юридические вопросы и т. Д.

Инновации - это не создание нового продукта или процесса. Этого не бывает в одной "Эврике!" момент. Это происходит постепенно, по одному небольшому решению за раз. Небольшими улучшениями в процессах, технологиях и продуктах мы поощряем инновации на каждом этапе, каждый день. Может быть неудобно - даже как хаос - не знать, каково конечное состояние с первого дня. Вот почему в усилиях по построению цифрового бизнеса мы действительно сосредотачиваемся на расширении возможностей клиентов - но под этим мы не подразумеваем обучение новому языку программирования, или каркас. Речь идет о формировании культуры экспериментирования и способности наблюдать, размышлять, адаптировать, улучшать, предоставлять и повторять.

Фотография Danielle MacInnes на Unsplash