sql - software - Explicar por qué "Solo agregar otra columna al DB" es una mala idea, para los no programadores
lucidchart generate sql (15)
Tengo vendedores y contadores de frijoles que intentan vender personalizaciones a los clientes, lo cual está bien. Pero cuando aparece una solicitud de cambio compleja en la que les envío una gran estimación, se confunden. A menudo vuelven con "¿Por qué no puedes agregar otra columna?" que por otro, significan una docena de columnas personalizadas PER por cliente.
Hasta ahora, todo lo que puedo volver es "Estamos tratando de mantener la base de datos bien normalizada", lo que no significa nada para ellos. Les digo que puedo crear un sistema de tablas que permita a cada cliente definir su propio conjunto de campos personalizados, pero, por supuesto, eso lleva más tiempo y dinero que "simplemente agregar unas pocas columnas". Y, por supuesto, quieren tener su pastel y comérselo también.
Entonces, ¿cómo puedo hacer que entiendan?
Les digo que puedo crear un sistema de tablas que permita a cada cliente definir su propio conjunto de campos personalizados, pero, por supuesto, eso lleva más tiempo y dinero que "simplemente agregar unas pocas columnas".
Creo que deberías impulsar esta opción para tus jefes ya que la personalización es obviamente una característica muy solicitada. Haga hincapié en que un sistema personalizado individualmente (en lugar de generalizado, de personalización limitada) para cada cliente significa que se deberán crear parches y actualizaciones para cada cliente individual (lo que lleva a tiempos de despliegue más largos y costos más altos); que las instalaciones no estandarizadas significan que los tickets de HelpDesk tardarán mucho más en cerrarse (lo que lleva a clientes insatisfechos y mayores costos); etc.
En otras palabras, venda el dolor a corto plazo para obtener ganancias a largo plazo al mostrar que el costo de su solución supera con creces el costo de su solución.
Los vendedores se enfocan en hacer la venta. Eso es lo que les da su comisión. No les importa lo que viene después. Los jefes, sin embargo, se centran en el costo. Vende a tus jefes y tus jefes pueden venderle a los vendedores.
Ah ... un poco de conocimiento es algo peligroso.
Prueba este:
Usted: ¿ A qué compañías no le hemos vendido?
Ventas: Acme Industries, OCP Corp, bla, bla, bla
Tú: Bueno ... ¿por qué no puedes hacer un par de llamadas más?
La respuesta, por supuesto, es que las ventas no son tan simples. Tampoco lo es el desarrollo de software. A menos que realmente quieran horas de explicación con respecto a la arquitectura y el mantenimiento, les sugiero que confíen en su juicio como desarrollador de software.
Este es el problema aquí, confianza. Debería explicarles que muestran una falta de confianza en sus habilidades al hacer estas afirmaciones.
Dígales que cuando las personas hacen un automóvil y luego quieren un modelo que va más rápido y hace más que el anterior, generalmente no agregan otro motor.
El problema es que "estamos tratando de mantener la base de datos bien normalizada" es casi seguro que la respuesta es incorrecta : reproduce la pelota en la corte de la desconfianza y los propósitos cruzados.
Debe volver a enfocarse en el objetivo final, la mejor manera de alcanzar ese objetivo final (tal vez en varios lanzamientos) y lo que costará a corto y largo plazo. He visto mencionar la deuda técnica en las respuestas y las estimaciones de costos deben tener en cuenta esos factores.
Puede que no sea una mala idea "solo agregar otra columna". Realmente no has dado todo el caso de negocios. Por otro lado, han desafiado tu respuesta negativa con una pregunta técnica ignorante. Eso no llega al corazón de ayudarlo a entender el requisito porque no les gustó escuchar "no". (Me gustaría saber cuál fue la declaración original del problema).
Hacer que la base de datos se normalice es un problema técnico y no tiene que ver con los requisitos que el sistema debe cumplir: es un principio de diseño del sistema que se utiliza para entregar sistemas con ciertas propiedades, como la capacidad de mantenimiento. Pero los sistemas mantenibles que no satisfacen las necesidades del usuario tienen valor cero, mientras que los sistemas no mantenibles que satisfacen las necesidades del usuario tienen un valor distinto de cero (que puede ser excedido por el costo de mantenimiento, que es un problema comercial). Si el EAV o algún otro mecanismo es requerido tampoco es realmente el punto, eso solo causa que la complejidad del sistema o el costo aumenten.
Si los requisitos son demasiado caros para implementarlos alguna vez, eso es parte del caso comercial. No nos ha contado lo suficiente sobre la arquitectura o el tipo de entidades que estas tablas modelan. Digamos que tienes 100 clientes. Puede haber superposición en columnas en una entidad particular. Tan solo el 95% de los clientes nunca usarán la columna de facturación o dirección de facturación opcional, eso no significa que esas columnas se omitan, ¡no solo eso, a menudo tienen un diseño original! Alternativamente, si esta es una tabla de Productos y cada cliente quiere muchas columnas especiales y no hay solapamiento, es posible que necesite un sistema de campo definido por el usuario (EAV / XML / tag - el diseño tendrá que coincidir con los requisitos) en su lugar para mantener un diseño de sistema cohesivo.
Raramente he encontrado negocios para ignorar un argumento de deuda técnica, particularmente si se puede demostrar que una solución propuesta satisface las necesidades del usuario y la flexibilidad puede convertirse en un punto de venta. Lo que he encontrado es que las empresas a menudo preferirán si presenta las opciones de solución de la manera más rápida y exhaustiva posible sin perder más tiempo explicando por qué no se puede hacer algo o cuánto costará de lo que se necesitaría para abrocharlo. tardes y realmente hacer el trabajo.
Google "deuda técnica"; Muéstrales los resultados.
Haga que entiendan cuánto cuesta eso en tiempo de desarrollo, ¿este cambio requerirá tiempo de 1 o dos desarrolladores? ¿Qué hay de las pruebas? si las solicitudes complejas cuestan más, la empresa en su conjunto está ganando menos en el trabajo. El gerente de cuenta / proyecto debe ser el intermediario cuyo trabajo es proteger este tipo de solicitudes.
La mejor forma que he encontrado es mostrarle cómo puede crear una nueva característica de lo que está pidiendo y que no puede agregar con solo un par de columnas personalizadas. Las características son mejores que las personalizaciones, especialmente cuando puede cobrarle a alguien por ello.
Intenta hacer un buen caso de negocios para tu lado antes de entrar en el tema técnico.
No llegarás a ninguna parte explicándoles en términos técnicos. Necesitas una metáfora Ajústalo a la persona con la que estás hablando, si puedes. Si él / ella es un fanático del automóvil, pídales que piensen en términos de modificaciones del motor. ¿Cuánto le costaría a Ford ofrecer tres motores diferentes en el Taurus, o modificaciones personalizadas a pedido?
Una vez que aceptan esa comparación, incluso si no la entienden completamente, pueden comenzar a entender por qué se aplica la metáfora.
Hay otra gran manera de ayudarlos a verlo a su manera; tómense un tiempo para verlo a su manera también. Cuando su cheque de pago depende de darle al cliente lo que quiere, no le importa lo que el propulsor en Ingeniería le indique. Si recibe muchas solicitudes de personalización, debe considerar los enfoques arquitectónicos y estratégicos para entregar esas personalizaciones, siempre que sea posible.
Nunca lo intenté yo mismo, pero lo he pensado: trazar una analogía con el sistema legal. Lagunas legales existen porque los legisladores intentan parchear el sistema con kludges perezosos. El software equivalente son errores, agujeros de seguridad, etc. La única forma de evitar estos problemas es una planificación cuidadosa y un trabajo arduo.
Para ampliar la sugerencia de tuinstoel (evitar estructuras genéricas de atributo-valor de la entidad): si bien generalmente me gusta esta estructura para el uso ligero, el uso excesivo (lo que eso signifique) degradará el rendimiento como se indica. Tales estructuras no pueden ser bien indexadas. Escribí y apoyé uno de esos sistemas. En el momento en que teníamos 50,000 "entidades" cada una con 10-100 teclas, era LENTO incluso en hardware de rango medio).
Sin embargo, son muy útiles y bastante fáciles de implementar. Por lo tanto, si existe la necesidad de agregar muchos "campos adicionales" arbitrarios por cliente, puede tener más sentido.
Otra opción posible podría ser agregar una cantidad de columna genérica no utilizada en las tablas apropiadas para ser utilizada por los clientes para sus propios fines. Algunas aplicaciones emprendedoras hacen justamente esto. Una tabla Ventas puede tener diez o veinte columnas CUSTCODE01 a CUSTCODE10 que cada implementación de la aplicación puede usar de forma diferente, totalmente personalizada.
Esto puede parecer horrible al principio, también puede ser un medio feliz. Existe una buena cantidad de espacio para personalizar por cliente sin a) "solo agregar una columna" y alterar la aplicación o el proceso de desarrollo, ob) implementar un sistema genérico potencialmente lento. Sin embargo, solo obtiene una cantidad limitada de felxablity, y hay una falta de nombres de columna auto-documentados (pero las descripciones de las columnas se pueden personalizar según sea necesario).
Puede decirles que una base de datos mal diseñada significa que a largo plazo:
les llevará más tiempo recuperar sus datos: ¿realmente quieren esperar y esperar?
Será más difícil y tomará más tiempo diseñar consultas para generar informes. De nuevo, si necesitan esa consulta mañana, ¿quieren que se les diga que aún se está trabajando?
será una pesadilla para mantener, con las consultas propensas a errores que es más probable que se escriban.
Puede explicar este problema haciendo una comparación con una biblioteca. Hay muchos libros. Uno pequeño y uno grande, delgados y gruesos, todos pueden imaginar eso. Ahora bien, si desea almacenar más información en alguna parte, sería más simple agregar algunas páginas nuevas a un libro que agrandar algunas páginas individuales; si hay varias páginas de un libro más grandes que las demás, esto no es muy sólido y ¿cómo podría uno encontrarlo? esta información si no tiene entrada en el índice de contens? Tal vez sea mejor almacenar la nueva información adicional en un libro adicional, uno nuevo con una estructura específica. Imagine cómo se puede obtener una información si todo el contenido de una biblioteca se escribe en un gran libro grueso. Nadie más podría encontrar nada hasta que encuentre lo que quiere y vuelva a colocar el libro en su lugar ... si puede llevar este enorme libro. ¿Por qué recuperar todo el Livestory si solo quieres saber la fecha de nacimiento de una persona?
Las personas mencionadas no tienen que entender la arquitectura de una base de datos, pero deben confiar en usted. Y lo organizas para que puedan arrojar su información en este gran agujero de la base de datos y recuperarla cuando lo deseen, rápido y confiable.
Si está en el negocio de vender un producto junto con personalizaciones, el producto debe admitir personalizaciones sin tener que bifurcar la construcción cada vez que la vendan.
Parece que has intentado explicar eso, fue en vano. En lugar de eso, intente estimar el costo de agregar su "personalización de la manera correcta" para una tabla con el mantenimiento, digamos, de media docena de versiones del producto con personalizaciones diferentes, y corrigiendo un error fuera de ellas. Mi apuesta es que verán que pronto obtendrán dinero con una base de códigos y un esquema unificados. Y un desarrollador que no se vuelve loco.
Si son vendedores y contadores de frijoles, entonces definitivamente entenderán el todopoderoso dólar (libra, euro, etc.). ¿Puede demostrar que el tiempo dedicado a mantener estas columnas adicionales no justifica las ventas adicionales?
Tenga mucho cuidado aquí y asegúrese de que su argumento tenga sentido. Me he sentido resistente en el pasado a hacer más personalizaciones porque no quería poner en tela de juicio mi pequeño y bonito modelo de dominio que porque realmente sería tan difícil de mantener. Un análisis decente lo ayudará a determinar por qué se resiste a la personalización.
Recuerde: la conclusión es que necesita mantener contentos a los clientes para poder mantener el negocio. Los desarrolladores reflexivos a veces pueden perderlo de vista en nuestra búsqueda para hacer que las cosas sean fáciles de mantener.
... Les digo que puedo crear un sistema de tablas que permita a cada cliente definir su propio conjunto de campos personalizados, pero eso lleva más tiempo y dinero ...
Parece que quiere construir algún tipo de modelo de datos genérico? Entidad-atributo-valor ...?
Esos modelos genéricos a menudo son muy lentos, no se pueden indexar correctamente y pueden confundir al optimizador de consultas. A menudo es mejor agregar algunas columnas.
Haga una evaluación comparativa muy completa antes de seguir el camino genérico.
Tal vez sea dependiente del proveedor de db, pero si usa Oracle, preferiría el camino ''solo agregar algunas columnas'' por encima de la entidad-atributo-valor-camino.