Как обрабатывать запросы типа «можете ли вы добавить еще несколько полей» от клиентов?

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

• Как мы можем быть уверены, что клиенту действительно нужны эти запросы функций?

• Как мы можем вежливо сказать: «Вам это не нужно»?

В настоящее время мы начинаем взимать плату за определенные запросы функций. (Раньше запросы на функции обычно были бесплатными). Есть ли что-нибудь еще, что мы можем сделать?

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

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

Разговор также заставит вас понять, действительно ли то, что они просят, так важно.

Я не думаю, что вы можете войти в "вам это действительно нужно?" спор с клиентами. Лично я хотел бы спросить: «Как это сделает вашу компанию больше денег?» но в том-то и дело, что какой-то менеджер по какой-то причине хочет отследить это, и они привыкли добиваться своего. Если вы не хотите этого делать, скажите «нет» или взимайте такую ​​большую сумму денег, чтобы отклонить запрос.

Начните искать способы упростить для вашего приложения обработку большего количества полей клиента.

1. Разрешить пользователю устанавливать метки в отчетах и ​​формах для использования существующих полей.
2. Добавьте общие поля (String12) в существующие или дополнительные таблицы пользовательских полей.
3. Имейте определяемую пользователем систему полей, где все это обрабатывается вводом данных и нет необходимости создавать новые столбцы в таблицах (я не могу вспомнить, как это называется-help.).

Вы можете обнаружить, что существующие клиенты опережают вашу систему. Отрасль может меняться, поэтому появляются новые требования.

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

Посмотрев на другую сторону окна, на моей последней работе я столкнулся с системой ERP, которая позволяла конечным пользователям добавлять «пользовательские» столбцы в любой объект / таблицу. Из моих кратких взаимодействий с ним выглядело, как будто они динамически добавляли столбцы во вторую таблицу с сопоставлением «один к одному». Например:

Таблица WIDGET со статическими столбцами:

• WIDGET_ID
• WIDGET_NAME
• WIDGET_COST
• и т.п.

Таблица WIDGETCUSTOM с определяемыми пользователем столбцами:

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• и т.п.

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

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

Особенность "запросов" - это просто запросы. Если они предъявляют требования, вам нужно решить, сколько стоит компании «загромождать» кодовую базу этим. Если это становится эндемической проблемой, то вы можете решить ее, но если они готовы заплатить то, что вы просите, или что-то близкое к этому, и это всего лишь несколько функций здесь и там, я говорю: иди с деньгами.

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

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

Мне трудно понять, почему тебя волнует, используют ли они это или нет. Все просто, вы строите то, что они хотят, и вам за это платят.

Кодовая база беспорядок? Если вам нужно реорганизовать свой код при работе с новой функцией, взимайте плату за нее.

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

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

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

Я думаю, вы должны попросить своего клиента провести одного или нескольких из вас через «день в офисе», чтобы увидеть, как они действительно используют программное обеспечение ... Подождите ... Наймите меня за 250 долларов в час, и я пойду узнаю. Кроме того, пожалуйста, пожалуйста, не позолота. Заставь это просто работать. Большинство предприятий не заботятся о том, что это выглядит ужасно, когда работает хорошо.

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

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

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

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

Однако, если вы этого не сделаете, вы захотите перейти к решению для этих вспомогательных полей, которое включает их хранение вне основной модели данных. Затем вы можете использовать что-то вроде представления базы данных, чтобы объединить дополнительные поля для этого конкретного клиента. (Есть несколько способов сделать вспомогательное хранилище, в зависимости от характера хранимых данных; самый простой - это просто таблица, которая имеет тот же первичный ключ, что и некоторые PK в вашей основной таблице, но это неэффективно при использовании поля очень редки. Это действительно проблема, когда им нужны особенности поля, которые требуют таких вещей, как индексация.)

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