¿Deben los desarrolladores comprender el dominio comercial o la especificación debería ser suficiente?

Trabajo para una empresa para la que el dominio es realmente difícil de entender porque es de alta tecnología en electrónica, pero esto es aplicable a cualquier desarrollo de software en un dominio complejo.

La aplicación en la que trabajo muestra mucha información, gráficos y métricas que son difíciles de comprender sin experiencia en el dominio. El desarrollador utiliza una especificación para describir lo que debe hacer el software, como especificar que un gráfico particular debe mostrar este tipo de métricas y esta métrica es la siguiente fórmula aritmética.

De esta manera, el desarrollador no comprende realmente el negocio y qué / por qué está haciendo esta tarea. Esto puede estar bien si la especificación es realmente detallada, pero cuando no lo es o cuando el autor ha olvidado un caso de uso, es bastante difícil para el desarrollador encontrar una solución.

Por otro lado, capacitar a cada desarrollador en todos los aspectos comerciales puede ser muy largo y difícil.

¿Deberíamos darle más importancia a la especificación detallada (pero como sabemos, no existe una especificación perfecta) o deberíamos capacitar a todos los desarrolladores para que comprendan el dominio comercial?

EDITAR: tenga en cuenta en su respuesta que la empresa podría usar desarrolladores externos y que una formación para todo el dominio puede demorar aproximadamente 2 semanas

La especificación prácticamente nunca es suficiente. Los desarrolladores que no tienen conocimiento de dominio no pueden señalar cuándo la especificación está en error (una ocurrencia frecuente en la mayoría de los lugares) y toman malas decisiones de diseño.

En mi experiencia, habiendo trabajado en 3 industrias muy diferentes ahora, puede comenzar sin saber mucho sobre el dominio, pero eventualmente tendrá que aprenderlo y alguien tendrá que entenderlo en un grado detallado.

El problema esencial se debe a la impedancia cliente-desarrollador: quieren algo pero solo lo sabrán cuando lo vean y usted quiere resolver su problema, pero no siempre puede tener una idea clara de cuál es ese problema. Cuanto más conocimiento de dominio de su industria (el cliente) pueda brindar (el desarrollador), más fácil será traducir los "deseos" vagos en "problemas" concretos y resolverlos.

Como ejemplo anecdótico, mi trabajo anterior fue en la industria química con software de gestión de plantas. Comencé con un conocimiento efectivo del dominio, pero pude implementar el código que necesitaba para resolver los subproblemas que me presentaron el desarrollador principal y los clientes. Con el tiempo, hice el esfuerzo de aprender la industria, para poder comunicarme más fácilmente a nivel del cliente. Cuando entendí su industria, comencé a entender cuáles eran los problemas reales. Cuando dicen cosas como "necesitamos rastrear todos los valores de datos en este módulo", puedo traducir eso a lo que realmente significan, que es "necesitamos mantener un registro histórico de cada valor que genera este sensor, almacenado durante X días de retención, pero siempre evaluado en función de la lectura más reciente de ese sensor ".

Entonces, sí, alguien necesita conocimiento de dominio, y preferiblemente un desarrollador porque los problemas de dominio no son problemas de código y la traducción entre los dos no es trivial. Eventualmente, cualquier desarrollador que valga la pena mantener en su equipo debería elegir el dominio, para que puedan tomar decisiones más informadas sobre los matices de su código.

ALGUIEN en el proyecto necesita tener un conocimiento de dominio bastante completo. Esa persona puede o no ser el desarrollador.

En los proyectos ágiles, el propietario del proyecto del cliente es esa persona, y están trabajando en colaboración y estrechamente con el equipo. En proyectos no ágiles, alguien en el equipo necesita adquirir ese conocimiento, pero generalmente no lo hacen, lo cual es una de las razones por las que los proyectos no ágiles son tan propensos a fallas.

Hay muchas respuestas excelentes. Agregué el mío porque después de leerlos y buscar descubrí que nadie menciona un problema clave: los errores .

Si el equipo no cuenta con suficientes personas con suficiente autoridad y experiencia en el dominio, tarde o temprano se introducirán inevitablemente errores. Dado el conocimiento del dominio, existen valores / resultados / relaciones imposibles o no sensoriales. Uno podría esperar que una especificación los señale explícitamente, pero en realidad lo mejor que puede alcanzar es evitar los más obvios (avíseme si las tasas de interés se vuelven negativas o cosas por el estilo; esto podría ser o no un error, pero es lo suficientemente extraño como para ser notable).

Esto está fuertemente relacionado con la comprensión de los motivos de las elecciones y, en el mejor de los casos, también conduce a un mejor software (porque si uno realmente conoce el motivo detrás de una solicitud, es capaz de pensar en ello, en lugar de tener que aceptarlo como algo dado) )

Recuerde que Einstein dijo: "Pero el pensamiento y las ideas, no las fórmulas, son el comienzo de toda teoría física" , es decir, no se piensa en términos de fórmulas abstractas sino de ideas ...

Si coloca a una persona que solo sabe inglés y una persona que solo sabe japonés en una habitación, no podría traducir del japonés al inglés, a pesar de ser expertos en sus respectivos idiomas. Por la misma razón, incluso los programadores expertos sin conocimiento de dominio son incapaces de descubrir lo que necesitan construir, incluso cuando tienen acceso 24x7 al mejor experto en dominio que no es también un experto en desarrollo de software.

Una especificación es un intento de traducir "japonés" de los requisitos del dominio al "inglés" de los requisitos de programación. Cuando obtienes una calidad de traducción comparable a la del traductor de Google, es tu día de suerte; la mayoría de las veces, la calidad simplemente no existe, por lo que no tiene forma de adquirir al menos algo de conocimiento de dominio. Con cierta persistencia, lo convierte en un "traductor" decente al final del proyecto, por lo que su valor para su empresa aumenta significativamente. La mayoría de las veces, también te diviertes mucho en el proceso, por lo que es una situación en la que todos ganan.

Sin algún aspecto del conocimiento del negocio, terminas con desarrolladores que no hacen preguntas y codifican sin pensar lo que dicen las especificaciones. Creo que se necesitan "Pensadores" para hacer un buen software, no solo personas que pueden golpear un teclado. Comprender no solo "qué" estás haciendo sino "por qué" y cómo encaja en el panorama general ayuda a proporcionar una mayor satisfacción al equipo de desarrollo.

Creo que deberías intentar obtener el conocimiento del dominio. Las especificaciones son una lista de verificación que indica qué debe hacer el producto final y es necesario para la validación de su producto. Como desarrollador, siempre debe tratar de comprender cuál es el verdadero problema que está tratando de resolver. Obtener el conocimiento del dominio lo ayudará a comprender eso.

Le ayudará a diseñar y codificar fácilmente, ya que comprenderá qué están cambiando las partes (digamos conjunto de reglas) y las colocará por separado. No es necesario ser un maestro en eso, pero podría hablar con un usuario final en su idioma .

Puede conducir un automóvil con conocimientos básicos del mismo; pero en caso de que quiera disfrutar del viaje, necesita aprender más sobre cómo usarlo exactamente. Al igual que con otras operaciones, no es obligatorio entender el dominio, pero es divertido cuando lo haces .

Creo que un desarrollador que sabe que el negocio vale su peso en oro.

En un escenario "tradicional" donde la empresa tiene algunos requisitos y algunos analistas de negocios los traducen en requisitos técnicos, entonces el desarrollador trabaja con aquellos en los que inevitablemente tiene dos cosas que pueden suceder:

1. Tienes múltiples puntos de falla. Es posible que el analista de negocios no haya conseguido que todos los requisitos comerciales se traduzcan perfectamente y / o que el desarrollador no los traduzca perfectamente a una especificación técnica. Una variante del escenario "secreto en la sala". Solo las exigencias de la comunicación.

2. Uno o todos los propietarios de negocios, analistas de negocios o desarrolladores son lo suficientemente nuevos para la organización como para perder elementos clave en los que normalmente no pensarían. El desarrollador experimentado que conoce bien el negocio puede ayudar a educar a las personas en esos otros roles para que el producto sea más completo.

Casi siempre se deben realizar compensaciones entre el valor de cada característica en la especificación, cuán estrechamente se debe implementar la especificación a valiosa y el costo de cumplir con cualquier combinación de características de especificación. A menudo, las buenas compensaciones solo se pueden hacer cuando el conocimiento para hacer todo lo anterior existe en una persona o en un equipo de trabajo cercano, incluido el arquitecto y / o codificador de software real.

Sin ese conocimiento extremadamente localizado y posiblemente incluso sensaciones viscerales, el resultado puede terminar fácilmente como un producto muy costoso y casi inútil que cumple con las especificaciones escritas.

El costo de crear una especificación que no tiene los problemas anteriores a menudo puede ser mayor que capacitar al arquitecto y / o codificadores para que tengan suficiente conocimiento de dominio para trabajar con una especificación menos inescrutablemente detallada (suponiendo que las legalidades y los contratos comerciales lo permitan).

Sí, los desarrolladores necesitan conocer el negocio hasta cierto punto. No tienen que conocer cada detalle minucioso, pero deben tener una comprensión básica de para qué se usa el informe X y cómo se usa en el proceso comercial. Cuanto más entiendan sus desarrolladores sobre el negocio, mejor será la solución que pueden ofrecer.

Según mi experiencia *, es más probable que una sola persona con un buen conocimiento del dominio del problema y un buen conocimiento del desarrollo de software encuentre la solución óptima a un problema que dos personas, una con un excelente conocimiento del dominio del problema y otra con un excelente conocimiento de desarrollo de software, trabajando juntos.

Creo que todo se reduce al simple hecho de que la comunicación que ocurre en el cerebro de un solo individuo es muchas veces más rápida y mejor que la comunicación entre individuos.

* La experiencia principal a la que recurro para responder esta pregunta es más de 10 años dedicados al desarrollo de un paquete de software de contabilidad (desde el inicio hasta el 'modo de mantenimiento'). Aunque mi conocimiento del desarrollo de software era bastante bueno, en comparación con mis colegas, a menudo me sentía discapacitado por la falta de comprensión del dominio del problema.

Me gustaría responder que alguien que viene del lado comercial, que trabaja con desarrolladores que muestran poco interés en aprender los conceptos básicos del comercio, a veces incluso parece estar orgulloso de no tener que saber sobre esos conceptos básicos: el problema es que el los desarrolladores no podrán ver errores en el resultado a primera vista (resultados no plausibles, signos incorrectos, etc.), lo que requiere casos de prueba detallados (que no desarrollamos hasta hace poco) o supervisión constante de los resultados. En la medida en que estoy dispuesto a aprender los conceptos básicos del desarrollo de software para facilitar la comunicación, me gustaría instar a los desarrolladores a hacer lo mismo.

No tienes que hacerlo, pero ¿por qué no quieres hacerlo?

Me preocuparía cualquier programador que fuera reacio y especialmente incapaz de aprender el dominio hasta cierto punto. Es importante salir de la "torre de código de marfil" de vez en cuando.

Escribir código sin tener idea de cómo se usa y con qué propósito suena como un trabajo terrible. ¿Quién quiere romper ladrillos cuando podrías estar construyendo catedrales?

Cuanto más se involucre un desarrollador y más senior en el negocio, más importante será tener al menos un dominio de nivel medio o las áreas más matizadas de esa industria que pueden ser críticas no serán entendidas por el equipo de desarrolladores.

Sin embargo, una especificación debería ser suficiente para tareas de nivel inferior. En resumen, es mejor capacitar a su fuerza laboral a un nivel inferior. Puede que sean el mejor programador políglota del mundo, pero si no pueden entender el problema con bastante profundidad, siempre están condenados al fracaso o la programación de la marcha de la muerte.

Siempre debe haber alguna especificación: no puede esperar que todos los desarrolladores se conviertan en expertos en dominios. Al mismo tiempo, si los desarrolladores siguen ciegamente una especificación sin comprender realmente para qué sirve, el resultado puede no ser realmente lo que desean los clientes. A menudo sucede que cuando un desarrollador tiene un nivel de comprensión incluso decente (pero no experto), puede detectar errores y omisiones en las especificaciones. También pueden contribuir y dar retroalimentación al proceso que puede hacer que el producto final sea mucho mejor.

Podría valer la pena contratar a algunos expertos en dominios cuyo trabajo es establecer un enlace entre los clientes y los desarrolladores para ayudar a que los desarrolladores comprendan mejor y también para ayudar a escribir la especificación.

Creo que es difícil dar una respuesta de cualquier manera.

Es difícil ver cómo, por ejemplo, un desarrollador independiente puede comprender el negocio (o la ciencia) detrás de cada aplicación que desarrollan. En esta situación, creo que es más importante que el desarrollador sepa hacer las preguntas correctas sobre la especificación o el modelo comercial que comprender realmente el negocio en sí.

Por otro lado, un desarrollador empresarial, suponiendo que han estado en el mismo negocio por un tiempo, realmente debería haber aprendido cómo funciona el negocio después de unos meses (o quizás años). En un equipo grande también puede tener un arquitecto que entienda el negocio más claramente que los desarrolladores.

En las PYME con desarrolladores solitarios, es importante que el desarrollador tenga conversaciones frecuentes con los propietarios / gerentes para evitar que se activen e implementen algo incorrecto.

Por lo tanto, hay muchas formas posibles de pensar sobre esto, pero la clave es la misma en todos los casos: la comunicación .

El desarrollo de software es la única profesión que conozco que requiere que usted no solo sea competente en su propia profesión, sino que tenga una comprensión básica de la profesión en la que está trabajando. Es importante tener suficiente comprensión del dominio para comunicarse con los clientes y otros desarrolladores en el idioma del cliente. Como desarrollador, no siempre puede confiar en que otros lo capaciten. A veces tiene que aumentar por su cuenta con una investigación personal, a menudo fuera del horario laboral habitual.

Realmente entiendo lo que quieres decir aquí porque nosotros, como compañía en una industria turística, enfrentamos el mismo problema. Cuando era un desarrollador junior, también estudiaba turismo en una universidad. Entonces, puedes adivinar que no vengo de un fondo de informática pero mi conocimiento del turismo es alto.

Estábamos creando productos en relación con otras compañías de software en aquel entonces, pero faltaba mucho conocimiento específico del dominio. Como describió, es realmente difícil hacerlo bien si está creando un producto en la industria del turismo, ya que existen muchas preocupaciones transversales, etc.

Entonces, este movimiento dio muchos malos resultados a largo plazo. Luego, dimos un gran paso adelante y comencé a enfocarme solo en el desarrollo en lugar de la parte comercial del proyecto. Como tengo el conocimiento industrial y el conocimiento de programación, el proyecto se vuelve más eficiente que nunca. Sin mencionar que podemos tomar decisiones más rápido ya que tengo la experiencia en ambos lados de la moneda.

Como respuesta concreta a su pregunta, ciertamente es sí en mi opinión personal. Si el proyecto en el que está trabajando su equipo es un proyecto a largo plazo, entonces tome el camino difícil y capacite a su personal sobre los fundamentos y detalles específicos del dominio.

Si un desarrollador permanece en una empresa / industria durante un largo período de tiempo, aprenderá "el negocio" de manera lenta pero segura.

Algunas compañías reconocen y brindan capacitación en "el negocio". Las compañías financieras son un buen ejemplo de esto.

Cuanto más aprenda el negocio, más fácil será hablar con sus usuarios. Sentirán más confianza en ti. Comprenderá más fácilmente las peculiaridades de dónde puede fallar un sistema si no funciona como se espera para el usuario.

Para responder a su pregunta, la especificación NUNCA es suficiente en mi experiencia. El problema común es que a menudo no contienen suficiente información y se desactualizan rápidamente.

La experiencia del dominio comercial puede ser obligatoria para algunas empresas. Buscan desarrolladores con experiencia en el dominio al contratar. Algunas compañías incluso ponen esto más alto que las habilidades tecnológicas reales. (Sin experiencia financiera, ninguna entrevista es muy común, ciertamente aquí en el Reino Unido).

Por experiencia personal, la especificación es suficiente siempre que tenga a alguien en el equipo trabajando con usted que tenga el conocimiento del dominio.

Trabajo en una industria muy especializada: creamos software para medios de difusión. Apenas sé algo sobre la transmisión, pero conozco el código y los datos, y tengo buenas personas en el equipo de gestión de proyectos que entienden la transmisión. Esa fórmula ha sido lo suficientemente buena durante los últimos años para que yo pueda encontrar una buena funcionalidad que les guste a los clientes.