Понимание заказчика: принципы CustDev для разработчиков

Содержание:

• Заказчики с другой планеты: причины непонимания при общении на одном языке

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

Я сталкивалась с аналогичными трудностями как со стороны бизнеса, так и со стороны разработчиков. С одной стороны, мы надеялись на глубокое понимание и активное участие со стороны подрядчика, но в итоге получали ответ: «это не было указано в техническом задании». С другой стороны, команда разработки постоянно переносила сроки выполнения, а функциональные требования дописывались по мере работы из-за неверно сформулированных задач.

Принципы Customer Development (CustDev) способствуют взаимопониманию и совместной разработке качественного продукта. Эта методология направлена на проверку жизнеспособности концепции или прототипа программного обеспечения.

Заказчики с другой планеты: причины непонимания при общении на одном языке

Я считаю, что CustDev следует рассматривать не только как метод проверки продуктовых предположений. В более широком смысле это представляет собой подход к мышлению и взаимодействию, который дает возможность понять, что именно ценит пользователь или, в данном случае, предприниматель, и за что он готов отдать свои деньги.

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

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

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

Это явление встречается не только в IT-секторе — часто одни и те же термины применяются для обозначения задач и решений, но при этом они могут иметь различные, а порой и противоположные значения для разных людей. В области проектного менеджмента подобные случаи обозначают понятием «мискоммуникация». Чтобы избежать недопонимания, необходимо переводить вводные данные с языка заказчика на язык исполнителя: начиная с определения задачи, далее переходя к выявлению проблемы, затем к выработке решения и, наконец, к конкретной функции.

Принцип №3

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

Как это бывает

Предположим, к вам обратился клиент с идеей приложения, которое позволит пользователям бронировать услуги, производить оплату и взаимодействовать с менеджерами. В ходе короткой встречи с заказчиком вы узнаете, что в данный момент эти функции представлены через бесплатный виджет на сайте. При этом отсутствует интеграция с системой управления взаимоотношениями с клиентами (CRM), и менеджерам приходится вручную проверять поступившие бронирования в личном кабинете. Чтобы обеспечить непрерывную обработку заказов, клиент был вынужден привлечь дополнительных сотрудников.

Из этого следует множество предположений относительно продуктов.

• Разработать скрипт для автоматической обработки заказов и интегрировать его с сайтом и CRM-системой. Это подход может оказаться быстрым и экономически выгодным, однако в долгосрочной перспективе он может уступить, поскольку многие конкуренты уже внедрили мобильные приложения для эффективной монетизации своей клиентской базы.

• Создание веб-приложения с интуитивно понятным интерфейсом и системой автоматизированной обработки заказов позволит заменить существующий сайт и минимизировать расходы на сотрудников. Это решение идеально подойдет для компании, стремящейся не к активному расширению, а к оптимизации своих бизнес-процессов.

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