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

12

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

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

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

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

Earlz
источник
С большим количеством ворчания и ругательства под моим дыханием>. <В конце концов, они платят мне…
Рэйчел

Ответы:

16

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

Джон Крафт
источник
2
Что ж, они платят, но нам бы очень хотелось сосредоточиться на более крупных запросах на функции, которые они в конечном итоге будут использовать (и это может привести к увеличению количества наших клиентов в будущем), а не на небольших простых запросах, которые просто загромождают код
Эрлз
8
@Earlz - «Нам бы очень хотелось сосредоточиться на ...» - я уверен, что вы бы не так работали с клиентами. Эти небольшие запросы (которые могут значительно повысить ценность для клиента) - это цена, которую вы платите за работу над более крупными материалами. Им нужен поставщик, который отвечает их потребностям, а не тот, кто выбирает и выбирает. Чтобы справиться с этим, нужно справедливо оценить их, но указать, что объединение их в более крупные выпуски является экономически эффективным (меньше регрессионного тестирования и т. Д.), И попытаться сделать его более привлекательным для таких действий, но вы не можете тщательно выбирать.
Джон Хопкинс
2
Если вы можете сократить расходы на 50%, потеряв 5% клиентов, это хорошая сделка, как принято считать. Действительно ли эти пользовательские поля сильно потеют за небольшую награду?
9000
5
В разработке программного обеспечения наблюдается плохая тенденция не желать делать то, что хочет клиент, потому что это не круто и не весело. Мы, разработчики, склонны ставить наше собственное счастье перед желаниями заказчика практически повсеместно. Однако речь идет не о нашем веселье и удовольствии. Это о клиенте. Клиент оплачивает счета, вам лучше сделать их счастливыми. Если вы занимаетесь написанием настраиваемого программного обеспечения, это часть работы.
Джон Крафт
3
@Wayne M спасибо за демонстрацию отношения, о котором я говорил. Клиенты могут не понимать технологии, но обычно они не идиоты. Обычно разработчик не понимает потребности бизнеса. Более того, если добавление функции нарушает целостность приложения, это признак плохого дизайна приложения.
Джон Крафт
3

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

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

Pedro
источник
3

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

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

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

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

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

JeffO
источник
3

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

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

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

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

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

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

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

Скотт Уитлок
источник
Это приложение слишком сложное, чтобы добавить такую ​​функциональность без капитального ремонта. Таким образом, это решение вышло (но планируется в основном обновлении версии, которое должно появиться через год)
Earlz
1
Если вы можете справиться с этим через год, в чем дело?
JeffO
@ Джефф год, если предположить, что мы не зацикливаемся на этих запросах на функции в то же время .. Год непрерывной разработки в основном
Эрлз
1

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

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

MattC
источник
2
Помните, что за каждой проблемой стоит возможность найти решение, а затем продать его кому-нибудь;)
MattC
0

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

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

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

Маффин Человек
источник
0

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

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

Buhb
источник
0

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

Морган Херлокер
источник
Методы канбана работают только тогда, когда вы можете добраться до Гембы: места, где возникает проблема. Будьте в физическом пространстве, говорите с людьми, которые делают работу, смотрите, как они показывают вам, как они это делают. Смотрите своими глазами, касайтесь пальцами. Тогда и только тогда попытайтесь выяснить, как его улучшить. И спросите их, как это улучшить.
Кристофер Махан
@Christopher - точка взята, но, безусловно, система может быть изменена до некоторой степени. Возможно, забудьте канбан, но постарайтесь сохранить идею системы тяги. Независимо от того, как это работает конкретно, у пользователя должен быть какой-то способ расставить приоритеты для задач и выбрать, какое из них будет выполнено следующим в среде, где разработка продолжается. Разработчик не может по-настоящему узнать, какую функцию необходимо выполнить самостоятельно.
Морган Херлокер
1
Железный код, ты прав. Я работаю в Bank of America, и наша команда позволяет бизнес-подразделению назначать приоритеты запросам функций через приоритет bugzilla. Они регистрируют ошибки, а затем расставляют приоритеты. Они могут изменить приоритет в любое время, и мы подстраиваемся. Да, иногда это требует затрат на переключение, но мы обнаружили, что это более эффективно для бизнеса. Обратите внимание, что это, вероятно, не сработает для оригинального плаката, так как у руководства могут быть цели для своих клиентов. (как ни крути, этот подход к управлению кажется ошибочным)
Кристофер Махан
0

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

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

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

IAbstract
источник
0

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

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

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

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

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

Donal Fellows
источник