Столкновение мнений: как разработать эффективное ПО для бизнеса, когда отделы выдвигают спорные требования?

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

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

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

Беда в том, что классический подход к проектированию предлагает либо собрать все хотелки в одну кучу и утрамбовать их в техническое задание, либо выбрать чью-то одну правду за главную и под неё всё подстроить.

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

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

Раскладываем конфликт на составляющие

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

Продажи и маркетинг

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

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

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

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

Склад и логистика

Тыл живёт в реальности, где ошибка стоит дорого и заметна сразу. Если продавец может позволить себе сказать «простите, задержка, сейчас всё поправим», то кладовщик, отгрузивший не тот артикул, получает возврат, двойную работу и недовольного клиента, которого уже успокаивают на другом конце компании.

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

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

Бухгалтерия и юристы

Финансовый и юридический блоки работают в системе координат, где главная валюта – последствия. Ошибка в интерфейсе может расстроить клиента, а ошибка в учёте – привести к штрафу, блокировке счёта или проблемам с налоговой через год после сделки.

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

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

Поддержка

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

Им нужно не просто «быстро отвечать», а иметь доступ к таким сценариям, которые не предусматривал никто из проектировщиков: клиент ошибся с адресом, курьер не дозвонился, товар повредили при доставке, оплата зависла. Чем меньше таких сценариев заложено в систему на старте, тем больше операторам приходится импровизировать вручную. Запросы поддержки часто звучат хаотично и избыточно, потому что операторы приносят с собой весь груз нестандартных случаев за последние полгода.

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

Почему нельзя угодить всем и сразу?

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

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

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

Программа, созданная для всех, на деле оказывается не нужна никому. Деньги потрачены, процессы не изменились, а к старым проблемам добавилась ещё одна – новая система, которую теперь надо поддерживать и как-то оправдывать перед руководством.

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

Но за «зелёной кнопкой» стоит рост конверсии на полтора процента, а за «серой таблицей» – снижение ошибок комплектации на треть. Это несопоставимые величины, и относиться к ним как к голосам на собрании жильцов просто некорректно. У каждого требования есть цена и есть последствия, и задача проектировщиков – эти цены и последствия сопоставить, а не просто пересчитать голоса.

Более того, некоторые запросы при ближайшем рассмотрении оказываются не требованиями, а эмоциями. Уравнивать такие сигналы с выверенными функциональными потребностями – значит закладывать в продукт решения для проблем, которых по большому счёту уже нет.

Голосование на совещании – ещё более опасный инструмент. Восемь начальников отделов поднимают руки, и большинством решается, каким быть интерфейсу, перевес в один-два голоса определяет судьбу продукта на годы вперёд. Но проблема в том, что за столом сидят люди с совершенно разной мерой ответственности за конечный результат.

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

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

Практический инструмент для поиска истины

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

Шаг первый. Добраться до настоящей потребности

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

Самый простой инструмент тут – задать вопрос «зачем» несколько раз подряд. Выглядит это примерно так:

• «Нам нужно поле для ввода причины возврата в карточке заказа».
• Зачем?
• «Чтобы поддержка фиксировала, почему клиент отказался».
• Зачем это фиксировать?
• «Чтобы в конце месяца понимать, какой товар чаще возвращают».
• Зачем вам эта статистика?
• «Чтобы передавать снабженцам и менять ассортимент».

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

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

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

Шаг второй. Пройти по цепочке создания ценности

У каждого продукта есть сквозной путь – от первого контакта с клиентом до денег на расчётном счёте и закрытых отчётных документов. Этот путь проходит через все отделы, и именно на нём становятся видны настоящие стыки и конфликты.

Удобнее всего взять одну типовую операцию и пройти её от начала до конца, фиксируя, кто на каком шаге подключается:

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

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

Конфликт не во всей системе, а на одном шаге, и решать его можно точечно – например, разрешить смену адреса, но с автоматическим уведомлением склада и пересчётом времени доставки.

Шаг третий. Отделить правила от привычек

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

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

Здоровый подход – пройтись по каждому требованию с вопросом: «Это требование закона, физики процесса или внутренней договорённости?» Первое принимаем как данность, второе уточняем, можно ли его обойти перестройкой самого процесса, третье выносим на обсуждение: сохраняем, если оно до сих пор полезно, и безжалостно убираем, если оно превратилось в ритуал.

Шаг четвёртый. Назначить хранителя целого

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

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

• Как это повлияет на соседние отделы?
• Упростит ли это жизнь конечному клиенту или только одному подразделению внутри компании?
• Не сломает ли это уже согласованную цепочку?
• Есть ли у нас подтверждение, что проблема реальна, или это тревога одного человека?

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

Как выглядит грамотный баланс?

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

• Бухгалтерия перестала вести параллельный учёт. Если финансисты по-прежнему выгружают данные в свои таблицы и перепроверяют каждую цифру вручную, значит, доверия к системе нет.
• Продавец не изобретает обходные пути. В нездоровой системе менеджеры по продажам быстро учатся обходить её ограничения. Звонят на склад в обход заявок, договариваются с логистами устно, записывают договорённости в личных заметках.
• Склад работает без всплесков ошибок. Если после внедрения новой системы количество пересортов и недогрузов заметно выросло – продукт не помогает, а мешает.
• Поддержка решает вопросы, а не тушит пожары. В перекошенной системе операторы работают как пожарная бригада: клиент злится, оператор извиняется и ищет обходные пути, потому что штатные средства не дают нужного действия.
• Руководитель видит картину целиком. Это не значит, что директору нужна панель со всеми мыслимыми показателями. Скорее наоборот: несколько ключевых цифр, которые не расходятся с реальностью. Выручка за сегодня, количество заказов в работе, процент возвратов, среднее время доставки.

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

Над фундаментом – надёжность операционных процессов. Склад должен отгружать то, что заказано, поддержка должна иметь доступ к истории клиента. Логистика должна видеть реальные сроки. Верхний слой – клиентский опыт. Быстрая загрузка страниц, понятная корзина, удобная форма оплаты, человеческая коммуникация. Это то, ради чего всё и затевается, но надстраивается оно поверх первых двух слоёв, а не вместо них.

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

Попытка построить эту пирамиду с вершины – частая ошибка. Руководитель хочет видеть цифры, под цифры проектируют отчёты, а процессы внизу остаются неразобранными, и отчёты врут.

Разработка ПО от 66 Бит

Всего за 10 минут мы вместе нашли баланс между хотелками разных отделов, самое время вооружиться полученными знаниями и разработать продукт, который не оставит равнодушным ни бухгалтеров, ни маркетологов, а чтобы процесс пошел легче и производительнее советуем обратиться в 66 Бит!

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