Если у вас нет партнера, но вы думаете о комплексной реализации, можете объяснять свои идеи вслух воображаемому наблюдателю. В сфере ПО это называется отладкой по методу утенка : программист действительно объясняет свои действия игрушечной резиновой утке [105]. И представьте, этот забавный прием работает!
Третий метод — слабосвязанная архитектура . Как мы обсуждали в предыдущей главе, между различными компонентами в области маркетинга существует много связей. Однако проблема появляется тогда, когда изменение одного компонента приводит к волновому эффекту в других. Хотя мы не можем полностью устранить эту сложность, так как компоненты должны взаимодействовать, нам по силам уменьшить степень их связанности, сознательно минимизируя зависимость между ними. Если какие-то зависимости нам нужны, мы стремимся сделать их явными, превращая скрытые допущения в четкие протоколы взаимодействия. Иными словами, разрабатываем, чтобы потом корректировать. При внедрении в маркетинг нового компонента подразумевается, что его или любой другой в какой-то момент придется поменять. Следует избегать ошибок, которые могут осложнить такие замены.
Четвертый метод — управление в условиях неожиданности , или «пуленепробиваемость» . Начинающие разработчики ПО часто ошибочно обдумывают только то, что происходит в случае нормальной работы программ, и не думают о возможных сбоях. Более опытные разработчики прибегают к защите при реализации кода, поэтому их программы могут корректно восстановиться, когда происходит нечто неожиданное. Мы можем сделать маркетинговые операции более стабильными, рассматривая нестандартные варианты и внося поправки в разработку и реализацию, принимая разумные меры для защиты от сбоев и максимального сохранения качества обслуживания клиентов.
И пятый метод — встроенные средства тестирования и контроля . При подготовке новых релизов маркетинговых кампаний следует их протестировать, чтобы проверить, будут ли они работать, как ожидается. Например, один раз попробовать поработать самому — это лучше, чем ничего. Но такого тестирования недостаточно. Более надежный способ — проверка различных сценариев на тестовом экземпляре. Стоит посмотреть, как целевая страница выглядит на смартфоне, на большом экране компьютера и систематически проверять все страницы. В разработке ПО это часто называют модульным тестированием [106]. Для большей эффективности используйте маркетинговые программы, которые помогут полностью или частично автоматизировать выполнение тестов. Кроме того, полезно сделать автоматизированный мониторинг программ и взаимодействия: если что-то перестает работать, вы сразу получите предупреждение. К маркетинговым программам типа «настроил и забыл» лучше применять принцип «доверяй, но проверяй».
Конечно, есть еще много способов борьбы со случайными сложностями в области маркетинга и разработки ПО, но внедрение перечисленных пяти заложит хорошую основу. Обменивайтесь новыми идеями с коллегами, регулярно общайтесь с разработчиками программного обеспечения, чтобы знать, какие новые приемы и технологии появились в этой области.
Сложность — серьезнейшая операционная проблема современного маркетинга. Справившись с ней, вы получите огромное конкурентное преимущество.
Глава 25. В погоне за мифом о «десятикратных» маркетологах
Принято считать, что лучшие разработчики программного обеспечения в десять и более раз продуктивнее середнячков. Однако это сомнительное утверждение, и в сообществе разработчиков ПО есть разногласия по этому поводу. Во-первых, разницу трудно измерить. Может, не в десять, а в два, три или пять раз? И во-вторых, при внедрении гибкого управления подчеркивается продуктивность команды, а значимость одного, пусть даже суперпрограммиста снижается.
Однако можно считать, что точность и популярность второстепенны. Лучшие разработчики программного обеспечения имеют огромное влияние на свои компании.
Интересно отметить, что начало этому мифу положил Фред Брукс (упомянутый в предыдущей главе) в эссе «“Серебряной пули” нет». Хотя Брукс не считал, что какой-нибудь метод управления или технологическая инновация способны десятикратно повлиять на разработку программного обеспечения, он верил, что таланту под силу многое: «Разница отнюдь не мала, вспомните Сальери и Моцарта. По данным исследований, проекты лучших разработчиков быстрее, меньше, проще, чище и создаются ценой меньших усилий. Разница между великим и средним составляет приблизительно один порядок величины [107]» [108].
Читать дальше
Конец ознакомительного отрывка
Купить книгу