¿Deben los desarrolladores entender el dominio empresarial o la especificación debe ser suficiente?

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

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

El problema esencial se debe a la impedancia entre el cliente y el 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. Cuantos más conocimientos de dominio de la industria (del cliente) que usted (el desarrollador) pueda aportar, más fácil pueda 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. Como 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 quieren decir, que es "necesitamos mantener un registro histórico de cada valor que genere este sensor, almacenado por X días de retención, pero siempre se evalúa según la lectura más reciente de ese sensor ". Una gran cantidad de problemas de dominio tienen reglas ocultas (como los períodos de retención en los datos) que los clientes han internalizado, pero usted debe explicitar.

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 debe recoger el dominio, para que puedan tomar decisiones más informadas sobre los matices de su código.

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

En los proyectos Agile, el propietario del proyecto cliente es esa persona, y están trabajando en colaboración y estrechamente con el equipo. En los 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 fallar.

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

Si al equipo no se le proporciona suficiente gente con suficiente autoridad y experiencia en el dominio, los errores tarde o temprano inevitablemente aparecerán. Dado un conocimiento del dominio, existen valores / resultados / valores no sensitivos. Uno podría esperar que una especificación los señale explícitamente, pero en realidad lo mejor que puede alcanzar es evitar las más obvias (adviértame si las tasas de interés se vuelven negativas, o cosas así, esto podría ser o podría no ser 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 opciones, y en los mejores casos también conduce a un mejor software (porque si uno realmente conoce el motivo de una solicitud, puede pensar en ello, en lugar de tener que aceptarlo). como dado).

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

Si coloca a una persona que sabe solo inglés y a una persona que sabe solo japonés en una sala, no podrá 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 que no conocen el dominio son incapaces de descubrir qué necesitan construir, incluso cuando tienen un acceso 24x7 al mejor experto en dominios que no es 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 de Google Translate, es tu día de suerte; la mayoría de las veces, la calidad simplemente no existe, por lo que no tiene forma de obtener por lo menos algunos conocimientos de dominio. Con cierta persistencia, te convierte en un "traductor" decente al final del proyecto, por lo que tu valor para tu empresa aumenta significativamente. La mayoría de las veces, también se divierte mucho en el proceso, por lo que es una situación en la que todos ganan.

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

Creo que deberías intentar obtener el conocimiento del dominio. Las especificaciones son una lista de verificación que indica lo que debe hacer el producto final y se requiere para la validación de su producto. Como desarrollador, siempre debes tratar de entender cuál es el problema real que estás tratando de resolver. El conocimiento del dominio te ayudará a entender eso.

Le ayudará a diseñar y codificar fácilmente, ya que entenderá qué son las partes cambiantes (por ejemplo, el conjunto de reglas) y las colocará por separado. No es necesario que sea un maestro, pero podría hablar con un usuario final en su idioma .

Puedes conducir un auto con un conocimiento básico de él; 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, luego El desarrollador trabaja fuera de los que inevitablemente tiene dos cosas que pueden suceder:

1. Tienes varios puntos de falla. Es posible que el analista de negocios no haya traducido a la perfección todos los requisitos comerciales y / o el desarrollador Puede que no se traduzcan perfectamente en una especificación técnica. Una variante en el escenario "secreto alrededor de la habitación". Solo las exigencias de comunicación.

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

Casi siempre hay que hacer concesiones entre el valor de cada función en la especificación, la precisión con la que se debe implementar la especificación y el costo de cumplir con cualquier combinación de características específicas. A menudo, solo se pueden hacer buenas compensaciones cuando existe el conocimiento para hacer todo lo anterior en una persona o en un equipo que trabaje estrechamente, incluido el arquitecto y / o el programador de software.

Sin ese conocimiento extremadamente localizado y posiblemente incluso con sensaciones viscerales, el resultado puede terminar fácilmente como un producto casi inútil muy costoso que cumple muy de cerca la especificación escrita.

El costo de crear una especificación que no tiene los problemas anteriores a menudo puede ser mayor que la capacitación del arquitecto y / o los programadores para tener suficiente conocimiento del dominio para trabajar con una especificación menos detallada e inescrutable (suponiendo que la legalidad y los contratos comerciales lo permitan ).

Cuanto más involucrado esté un desarrollador y más avanzado en el negocio, más importante será tener al menos un conocimiento de dominio de nivel medio o las áreas más matizadas de esa industria que pueden ser críticas no serán comprendidas por el equipo de desarrolladores.

Sin embargo, una especificación debe ser suficiente para las 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 a la programación de la marcha de la muerte.

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

Siempre debe haber una especificación de alguna ; no se puede esperar que todos los desarrolladores se conviertan en expertos en dominios. Al mismo tiempo, si los desarrolladores siguen ciegamente una especificación sin entender realmente para qué sirve, es posible que el resultado no sea lo que los clientes desean. A menudo sucede que cuando un desarrollador tiene un nivel de comprensión un tanto 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 los desarrolladores a comprender 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 entender 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 modelo de negocio que entender realmente el negocio en sí.

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

En las PYMES con desarrolladores solitarios, es importante que el desarrollador tenga discusiones frecuentes con los propietarios / gerentes para evitar evitar implementaciones incorrectas.

Así que hay muchas formas posibles de pensar acerca de esto, pero la clave es la misma en todos los casos: 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 un conocimiento básico de la profesión en la que está trabajando. Es importante tener suficiente comprensión del dominio para comunicarse Con clientes y otros desarrolladores en el idioma del cliente. Como desarrollador, no siempre puedes confiar en otros para que te entrenen. A veces, tiene que aumentar por su cuenta con la investigación personal, a menudo fuera del horario habitual de trabajo.

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 una con un excelente conocimiento del 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 en la que me baso para responder a esta pregunta es la dedicación de más de 10 años 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 incapacitado por la falta de comprensión del dominio del problema.

Me gustaría responder como alguien que viene del lado de los negocios, que trabaja con desarrolladores que muestran poco interés en aprender los conceptos básicos del oficio, a veces incluso parece estar orgulloso de no tener que saber sobre esos conceptos básicos: el problema es que los desarrolladores no podrán ver los 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 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 tiene que hacerlo, pero ¿por qué no querría hacerlo?

Me preocuparía cualquier programador que se mostrara 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 construir catedrales?

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

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

Entonces, este movimiento dio muchos malos resultados a largo plazo. Luego, dimos un gran paso adelante y empecé a centrarme solo en el desarrollo en lugar de en la parte empresarial 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 una 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, tome el camino difícil y capacite a su personal sobre los aspectos 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 empresas reconocen y ofrecen 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 podría fallar un sistema si no cumple con lo esperado 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 quedan obsoletos rápidamente.

La experiencia del dominio empresarial puede ser obligatoria para algunas empresas. Buscan desarrolladores con experiencia en el dominio a la hora de contratar. Algunas compañías incluso ponen esto por encima de las habilidades tecnológicas reales. (No hay experiencia financiera, ninguna entrevista es muy común, ciertamente aquí en el Reino Unido).

Por experiencia personal, la especificación es suficiente siempre y cuando tengas a alguien en el equipo que trabaje contigo y que tenga conocimiento del dominio.

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