¿Cómo manejar el tipo de solicitudes de los clientes de “puede agregar solo unos pocos campos más”?

Muy comúnmente tenemos solicitudes de funciones para campos que solo un cliente desea. Esto, en el mejor de los casos, satura el código de la aplicación. A menudo, cuando miramos en su base de datos unos meses después de agregar los campos, podemos ver que en realidad ni siquiera están usando los campos adicionales. Además, es una aplicación bastante antigua, por lo que agregar un solo campo requiere múltiples cambios de código, cambiar informes y asegurarse de que no afecte a otros clientes que no necesitan ver el campo.

• ¿Cómo podemos asegurarnos de que un cliente realmente necesite estas solicitudes de funciones?

• ¿Cómo decimos cortésmente "realmente no necesitas eso"?

Actualmente estamos comenzando a cobrar por ciertas solicitudes de funciones. (Anteriormente, las solicitudes de funciones solían ser gratuitas) ¿Hay algo más que podamos hacer?

¿Están pagando por las características adicionales? Si es así, realmente no es asunto suyo 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 "usted no necesita esto". Se necesita tiempo, paciencia y hay que estar preparado para hablar mucho y tener almuerzos y otras tareas aburridas. Estas reuniones aburridas se pagarán por sí mismas a largo plazo, donde puede concentrarse en crear características realmente importantes.

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

No creo que puedas entrar en el "¿realmente lo necesitas?" discusión con los clientes. Personalmente, me gustaría preguntar: "¿Cómo hará que su empresa gane más dinero?" pero el hecho es que algunos gerentes, por alguna razón, quieren 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 de facilitar que su aplicación maneje un mayor número de campos de clientes.

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

Es posible que los clientes existentes estén superando su sistema. La industria puede estar cambiando, por lo que están surgiendo nuevos requisitos.

Lo sentimos, pero si no puede ofrecer a sus clientes lo que quieren 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 estuve expuesto a un sistema ERP que permitía que el usuario final agregara columnas "personalizadas" a cualquier entidad / tabla. De 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
• NOMBRE DEL WIDGET
• 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 buscarlos. Fue bastante eficiente porque la base de datos aún podí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 cuerdo. Cada cliente puede tener sus propias columnas personalizadas, pero esas columnas personalizadas no interfieren con su lógica central.

Las "solicitudes" de funciones son solo eso, solicitudes. Si están haciendo demandas, entonces debes decidir cuánto vale para la empresa "abarrotar" la base de código con eso. Si se convierte en un problema endémico, puede tomar medidas drásticas, pero si están dispuestos a pagar lo que está pidiendo o algo similar y son solo algunas características aquí y allá, le digo que vaya con el dinero.

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

Debería especificar exactamente lo que va a hacer en dicha función y aplicar un tiempo estimado para construirla. Si el cliente desea campos adicionales que estén bien, facture por ellos. Les digo a mis clientes que si desea agregar funciones después de haberla creado, está bien, pero en algunos casos costará un poco más trabajar en ellas.

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

Código de desorden base? 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, incluida la adición de "solo unos pocos 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 en qué dirección desea ir con su aplicación.

Si un cliente insiste en que los pocos campos adicionales son realmente que importante y que todavía no se deciden sobre la adición de ellos, es de esperar que el cliente todavía puede ver el beneficio de las características que están llevando a cabo en su lugar.

Parece que podría beneficiarse de algún tipo de sistema de extracción. Deje que el usuario elija qué característica se implementará a continuación, pero limite el número que puede estar en desarrollo en un momento dado. Un tablero Kanban es excelente para esto. Puede otorgarle al usuario la propiedad del proceso de priortización (es decir, menos responsabilidad y estrés para usted). Confía en mí, si el usuario se ve obligado a decidir qué característica se pone en desarrollo a continuación, sabiendo que las otras solicitudes se dejarán de lado, invertirán mucho más en decidir realmente lo que necesitan tener.

Creo que debería pedirle a su cliente que pase uno o más de ustedes durante un "día en la oficina" para ver cómo realmente usan el software ... Espere ... Contrateme por $ 250 / hora y lo averiguaré. Además, por favor, por favor no dores. Haz que funcione. A la mayoría de las empresas no les importa que se vea feo cuando funciona bien.

Rastrea las solicitudes. A medida que diseña / desarrolla las grandes características, elija un puñado de solicitudes priorizadas para incluir en esa versión.

Cree un sistema de negociación estándar para las solicitudes. Tal vez algo basado en un sistema de informes de errores o solicitud de funciones, como fogbugz. Permita que sus clientes realicen una solicitud y priorícela en función de:

• la factibilidad técnica / costo de la característica
• ¿Es la función solicitar un "pago"? Si está en un contrato y / o lo han pagado, póngalo en
• ¿Tiene sentido la función "tiene sentido"? Esto es un poco un arte, pero, en general, si suficientes clientes solicitan una función, entonces impleméntela 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 disponibles ciclos de pago no utilizados? 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 acostumbrando, comience a utilizarlos para hacer este tipo de cambios

Si el cliente tiene la propiedad total de la aplicación, haga lo que le pida. Deja que gasten su dinero; es de ellos.

Sin embargo, si no lo hace, entonces quiere 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 volver a fusionar los campos adicionales para este cliente en particular. (Hay algunas formas de hacer el almacenamiento 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 primaria que algunos PK en su tabla principal, pero eso es ineficiente cuando se usa del campo es muy escaso. Solo es realmente un problema cuando quieren características del campo que requieren cosas como la indexación).

También puede posponer las solicitudes de los clientes diciendo que no tiene suficientes recursos para implementarlos en esta etapa. Realmente ayuda si en ese momento apuntas a tu hoja de ruta que dice (tu mejor estimación en) cuándo será posible implementar lo que quieren a bajo precio. Y debe priorizar que la aplicación llegue a un estado en el que sea posible admitir las funciones de forma económica, ya que esa meta-característica se convierte en una característica principal de venta de su aplicación principal.