Як обробити запити клієнтів типу "чи можна додати лише кілька полів"?

Дуже часто у нас є запити на функції для полів, які хоче лише один клієнт. Це, в кращому випадку, захаращує код програми. Часто, коли ми заглядаємо в їх базу даних через кілька місяців після додавання полів, ми можемо побачити, що вони насправді навіть не використовують зайві поля. Крім того, це досить стара програма, тому для додавання одного поля потрібні багаторазові зміни коду, зміна звітів та переконайтеся, що це не впливає на інших клієнтів, яким не потрібно бачити це поле.

• Як ми можемо переконатися, що клієнт справді потребує цих запитів на функції?

• Як ми ввічливо говоримо "вам це не дуже потрібно"?

Наразі ми починаємо стягувати плату за певні запити на функції. (Раніше запити на функції зазвичай були безкоштовними) Чи є ще щось, що ми можемо зробити?

Платять за додаткові функції? Якщо так, то справді це не ваша справа, чи вони ними користуються, чи ні. Дайте їм те, за що вони платять. Якщо це не так, то ваше керівництво вирішить, чи готові вони продовжувати додавати функції без додаткового доходу.

У нас схожа ситуація. Те, як ми працюємо, вибудовує стосунки, засновані на довірі, що дає нам свободу говорити "вам цього не потрібно". Це потребує часу, тихості, і ти повинен бути готовим багато говорити, обідати та інші нудні завдання. Ці нудні зустрічі окупляться в довгостроковій перспективі, де ви можете зосередитися на створенні дійсно важливих особливостей.

Якщо говорити, ви також змусите переконатися, що те, що вони запитують, насправді таке важливе.

Я не думаю, що ти можеш потрапити в "чи справді це потрібно?" сварка із замовниками. Особисто я хотів би запитати: "Як це зробить вашу компанію більше грошей?" але справа в тому, що якийсь менеджер чомусь хоче відстежити це, і вони використовують, щоб пройти свій шлях. Якщо ви не хочете цього робити, скажіть "ні" або стягуйте такі великі гроші, щоб відмовити в запиті.

Почніть розглядати способи, як полегшити програму обробці більшої кількості полів клієнтів.

1. Дозволити клієнту встановлювати мітки у звітах та формах для використання наявних полів.
2. Додайте загальні поля (String12) до існуючих або додаткових спеціальних таблиць.
3. Створіть визначену користувачем полеву систему, де це все обробляється шляхом введення даних, і не потрібно створювати нові стовпці в таблицях (я не можу пригадати, як це називається-довідка.).

Ви можете виявити, що існуючі клієнти переростають у вашу систему. Галузь може змінюватися, тому нові вимоги спливають.

Вибачте, але якщо ви не можете запропонувати своїм клієнтам те, що вони хочуть, лише з технічних причин, а не з метою отримання прибутку, вам потрібно скористатися темпом. Новому комерсанту не складе труднощів вийти на ваш ринок із більшою кількістю полів, тому не допускайте цього.

На мить, дивлячись з іншої сторони вікна, на останньому моєму роботі я потрапив у систему ERP, яка дозволила кінцевому користувачеві додавати "власні" стовпці до будь-якої сутності / таблиці. З моїх коротких взаємодій з ним виглядало так, що вони динамічно додавали стовпчики до другої таблиці з відображенням один на один. Наприклад:

Таблиця WIDGET зі статичними стовпцями:

• WIDGET_ID
• WIDGET_NAME
• WIDGET_COST
• тощо.

Таблиця WIDGETCUSTOM із стовпцями, визначеними користувачем:

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• тощо.

Стовпчик WIDGET_ID може зв'язати їх між собою. Він автоматично показував ваші додаткові поля, коли ви редагували віджет, і ви могли включати їх у динамічні звіти або навіть шукати за ними. Це було досить ефективно, оскільки база даних все ще могла їх відслідковувати та індексувати ці стовпчики, якщо потрібно

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

Функція "запити" - це саме те, запити. Якщо вони пред'являють вимоги, то вам потрібно вирішити, скільки варто компанії «захаращувати» кодову базу цим. Якщо це стає ендемічною проблемою, тоді ви можете притиснутись до цього, але якщо вони готові заплатити те, що ви просите, або щось близьке до нього, і це лише декілька можливостей тут і там, я кажу, йдіть з грошима.

Щоб піти далі, якщо це проблема з вашим продуктом, і багато клієнтів шукають подібних налаштувань, можливо, саме час переосмислити ці частини вашого додатка та зробити їх гнучкими, щоб клієнти отримали повноваження робити це. самі, будь то спеціальна звітність, гнучкість збору даних тощо. Спробуйте перетворити ці роздратування на точку продажу. "Наша модель даних про запаси недостатньо хороша для вас? Ознайомтеся з нашими параметрами налаштування! Ви можете це зробити самостійно!"

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

Мені важко зрозуміти, чому ти хвилюєшся, користуються вони чи ні. Це просто, ви будуєте те, що хочуть, і вам за це платять.

Кодове безладдя? Якщо вам потрібно перефактурувати код під час роботи в новій функції, стягуйте їх за це.

Створіть список кількох функцій, які ви хочете додати, включаючи додавання "лише декількох додаткових полів". Покажіть список своїм клієнтам і попросіть їх отримати відгук про те, які саме вони сподобаються першими. Поясніть, що ваші ресурси обмежені і що ви не можете зробити це все відразу. Використовуйте зворотний зв'язок, щоб визначити, в якому напрямку ви хочете подати заявку.

Якщо клієнт наполягає на тому, що кілька додаткових полів на насправді , що важливо , і ви все - таки вирішили на не складаючи їх, ми сподіваємося , клієнт ще може бачити вигоду з особливостей ви впроваджують замість цього.

Здається, ви можете отримати користь від якоїсь системи тягнення. Дозвольте користувачеві вибрати, яка функція буде реалізована далі, але обмежте кількість, яка може бути в розробці в будь-який момент часу. Рада Канбана для цього приголомшлива. Це може надати користувачеві право власності на процес пріоритетності (він же менший, ніж відповідальність та стрес для вас). Повірте мені, якщо користувач змушений вирішити, яка функція буде надана в розробку далі, знаючи, що інші запити будуть відкладені, вони вкладуть набагато більше коштів у вирішення того, що їм потрібно мати.

Я думаю, ви повинні попросити свого клієнта поставити одного або декількох із вас через "день в офісі", щоб побачити, як вони насправді використовують програмне забезпечення ... Зачекайте ... Найміть мене за $ 250 / годину, і я піду дізнатися. Також, будь ласка, не будьте золоті. Змусьте це просто працювати. Більшість підприємств не байдуже, що це виглядає некрасиво, коли він працює добре.

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

Побудувати стандартну систему переговорів для запитів. Можливо, щось базується на системі звітування про помилки чи запит на функції, наприклад fogbugz. Дозвольте своїм клієнтам надіслати запит та визначити його пріоритетним на основі:

• технічна доцільність / вартість функції
• це запит на функцію "на оплату"? Якщо це укладено в контракті та / або вони заплатили за нього, тоді покладіть його
• чи має особливість "сенс"? Це трохи мистецтво, але, як правило, якщо достатньо клієнтів запитують якусь функцію, то реалізуйте її безкоштовно. Це можливість покращити свій товар і зробити продаж наступному клієнту простішим
• Чи є у вас невикористані, оплачені цикли? Якщо ви включаєте набір щомісячних годин на технічне обслуговування / підтримку як частину своїх контрактів (настійно рекомендую це зробити, навіть якщо кількість дуже низька), і вони не звикають, почніть кидати їх, вносячи такі зміни

Якщо замовник має повну власність на додаток, то робіть те, що він просить. Нехай вони дують свої гроші; це їхнє.

Однак якщо ви цього не зробите, ви хочете перейти до рішення для цих допоміжних полів, що передбачає їх зберігання поза основної моделі даних. Потім ви можете використовувати щось на зразок виду бази даних для об'єднання додаткових полів для цього конкретного клієнта. (Існує кілька способів зробити допоміжний сховище, залежно від природи даних, що зберігаються; найпростіший - це просто таблиця, яка має той самий первинний ключ, що і деякі ПК у вашій головній таблиці, але це неефективно при використанні поля дуже рідкісне. Це справді проблема лише тоді, коли вони хочуть функції поля, які вимагають таких речей, як індексація.)

Ви також можете відкласти запити клієнтів, сказавши, що у вас недостатньо ресурсів для їх виконання на цьому етапі. Це дійсно допомагає, якщо в цей момент ви вкажете на свою дорожню карту, яка говорить (найкраща оцінка), коли стане можливим дешево реалізувати те, що вони хочуть. І вам слід розставити пріоритет щодо отримання програми в стані, коли стає можливим дешево підтримувати функції, оскільки ця мета-особливість стає основною функцією продажу вашого основного додатка.