¿Cómo manejar el tipo de solicitudes de los clientes? ¿Puede agregar solo algunos campos más?

¿Están pagando por las funciones adicionales? Si es así, entonces realmente no es tu negocio si los están utilizando o no. Dales lo que pagan. Sin embargo, si ese no es el caso, entonces depende de su liderazgo decidir si están dispuestos a seguir agregando funciones sin ingresos adicionales.

Tenemos una situación similar. La forma en que manejamos es construir una relación basada en la confianza que nos da la libertad de decir "no necesitas esto". Lleva tiempo, paciencia y tiene que estar preparado para hablar mucho y almorzar y realizar otras tareas aburridas. Estas reuniones aburridas se pagarán por sí mismas a largo plazo, donde podrá concentrarse en crear características realmente importantes.

Hablar también te hará ver si lo que están preguntando es realmente tan importante.

No creo que puedas entrar en el "¿realmente lo necesitas?" Argumento con los clientes. Personalmente, me gustaría preguntar: "¿Cómo hará esto más dinero para su compañía?" Pero el hecho es que, algún gerente, por alguna razón, quiere rastrearlo y están acostumbrados a salirse con la suya. Si no quiere hacerlo, diga no o cargue una cantidad tan grande de dinero para desalentar la solicitud.

Comience a considerar formas para facilitar que su aplicación maneje una mayor cantidad de campos de clientes.

1. Permitir que el cliente establezca etiquetas en los informes y formularios para utilizar los campos existentes.
2. Agregue campos genéricos (String12) a tablas de campos personalizados existentes o adicionales.
3. Tener un sistema de campo definido por el usuario donde todo esto se maneje mediante la entrada de datos y no tener que crear nuevas columnas en las tablas (no puedo recordar cómo se llama esto -la ayuda).

Es posible que los clientes existentes estén superando su sistema. La industria puede estar cambiando para que surjan nuevos requisitos.

Lo siento, pero si no puede ofrecer a sus clientes lo que quieren únicamente por razones técnicas y sin fines de lucro, debe acelerar el ritmo. No sería difícil para un recién llegado ingresar a su mercado con más campos, así que no permita que eso suceda.

Mirando desde el otro lado de la ventana por un momento, en mi último trabajo, fui expuesto a un sistema ERP que permitía que el usuario final agregara columnas "personalizadas" a cualquier entidad / tabla. Desde mis breves interacciones con él, parecía que estaban agregando dinámicamente las columnas a una segunda tabla con un mapeo uno a uno. Por ejemplo:

Tabla WIDGET con columnas estáticas:

• WIDGET_ID
• WIDGET_NAME
• WIDGET_COST
• etc.

Tabla WIDGETCUSTOM con columnas definibles por el usuario:

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• etc.

La columna WIDGET_ID podría unirlos. Mostró automáticamente sus campos adicionales cuando estaba editando un widget, y podría incluirlos en informes dinámicos, o incluso buscar por ellos. Fue bastante eficiente porque la base de datos aún podría seguirlos e indexar esas columnas si fuera necesario, etc.

Desde el punto de vista de la programación, veo cómo eso lo mantendría sano. Cada cliente puede tener sus propias columnas personalizadas, pero esas columnas personalizadas no interfieren con su lógica central.

Las "solicitudes" de características son solo eso, solicitudes. Si están haciendo demandas, entonces necesitas decidir cuánto vale para la compañía "saturar" el código base con eso. Si se convierte en un problema endémico, entonces puedes reprimirlo, pero si están dispuestos a pagar lo que estás pidiendo o algo parecido y son solo algunas características aquí y allá, digo que con el dinero.

Para ir aún más lejos, si este es un problema constante con su producto y varios clientes buscan este tipo de personalizaciones, tal vez sea el momento de repensar estas partes de su aplicación y hacerlas flexibles de manera que los clientes tengan el poder. para hacerlo ellos mismos, ya sea en informes ad-hoc, recolección flexible de datos, etc. Trate de convertir estas molestias en un punto de venta. "¿Nuestro modelo de datos de stock no es lo suficientemente bueno para usted? ¡Vea nuestras opciones de personalización! ¡Puede hacerlo usted mismo!"

Debería estar especificando exactamente lo que va a hacer en dicha función y aplicando un tiempo estimado para construirlo. Si el cliente desea campos adicionales que están bien, facturelos por ello. Les digo a mis clientes que si desea agregar funciones después de haber creado la función, está bien, pero en algunos casos costará un poco más trabajarlas.

Me cuesta entender por qué te importa si lo usan o no. Es simple, creas lo que quieren y te pagan por ello.

Código de base de desorden? Si necesita refactorizar su código cuando trabaje en la nueva función, cárguelos por él.

Cree una lista de varias características que considere agregar, incluyendo la adición de "solo algunos campos adicionales". Muestre la lista a sus clientes y pídales comentarios sobre cuáles les gustaría primero. Explique que sus recursos son limitados y que no puede hacerlo todo de una vez. Use los comentarios para decidir qué dirección quiere seguir con su aplicación.

Si un cliente insiste en que los pocos campos adicionales son realmente tan importantes y aún decide no agregarlos, es de esperar que el cliente aún pueda ver el beneficio de las funciones que está implementando en su lugar.

Parece que podría beneficiarse de algún tipo de sistema de extracción. Permita que el usuario elija qué función se implementa a continuación, pero limite el número que puede estar en desarrollo en un momento dado. Una tabla Kanban es genial para esto. Puede otorgarle al usuario la propiedad del proceso de priorización (también conocido como menos responsabilidad y estrés para usted). Confíe en mí, si el usuario se ve obligado a decidir qué función se pone en desarrollo a continuación, sabiendo que las otras solicitudes se dejarán de lado, invertirán mucho más para decidir realmente lo que necesitan tener.

Creo que debería pedirle a su cliente que ponga a uno o más de ustedes en un "día en la oficina" para ver cómo realmente usan el software ... Espere ... Contráteme por $ 250 / hora y me iré descubrir. También, por favor, por favor, no oro. Haz que funcione. A la mayoría de las empresas no les importa que se vea fea cuando funciona bien.

Seguimiento de las solicitudes. A medida que vaya diseñando / desarrollando las características grandes , elija un puñado de solicitudes priorizadas para incluir en esa versión.

Construir un sistema de negociación estándar para las solicitudes. Tal vez algo basado en un sistema de informe de errores o solicitud de funciones, como fogbugz. Permita que sus clientes realicen una solicitud y establezca prioridades según:

• la viabilidad técnica / costo de la función
• ¿la función de solicitud es "de pago"? Si está en un contrato y / o lo han pagado, entonces póngalo en
• ¿la característica "tiene sentido"? Esto es un poco artístico, pero, en general, si un número suficiente de clientes solicita una característica, implementarla de forma gratuita. Es una oportunidad para mejorar su producto y hacer que la venta al próximo cliente sea más fácil
• ¿Tiene ciclos pagados sin usar disponibles? Si incluye un conjunto de horas mensuales para mantenimiento / soporte como parte de sus contratos (le recomiendo que lo haga, incluso si el número es muy bajo), y no se están utilizando, comience a utilizarlos para realizar este tipo de cambios.

Si el cliente tiene la propiedad total de la aplicación, haga lo que le pidan. Dejen que les echen su dinero es de ellos.

Sin embargo, si no lo hace, entonces desea ir a una solución para estos campos auxiliares que implica almacenarlos fuera del modelo de datos central. Luego puede usar algo como una vista de base de datos para fusionar los campos adicionales de nuevo para este cliente en particular. (Hay algunas formas de hacer la tienda auxiliar, dependiendo de cuál sea la naturaleza de los datos que se almacenan; la más simple es solo una tabla que tiene la misma clave principal que alguna PK en su tabla principal, pero es ineficaz cuando se usa). El campo es muy escaso. Solo es realmente un problema cuando quieren características del campo que requieren elementos como la indexación.)

También puede posponer las solicitudes de los clientes diciendo que no tiene recursos suficientes para implementarlas en esta etapa. Realmente ayuda si en ese punto apunta a su hoja de ruta que dice (su mejor estimación en) cuándo será posible implementar lo que ellos quieren a bajo precio. Y usted debería priorizar el hecho de que la aplicación llegue a un estado en el que sea posible brindar soporte a las funciones a bajo costo, ya que esa meta-característica se convierte en una característica de venta principal de su aplicación principal.