¿Qué tan importante es el conocimiento del dominio vs. el conocimiento técnico?

Estoy trabajando en una aplicación de Trading y Gestión de Riesgos y, aunque soy de C #, me han pedido que trabaje en paquetes SSIS. Ahora puedo vivir con eso. El punto de dolor es que hay demasiado énfasis en la comprensión empresarial. El comercio (comercio de energía para ser exactos) es un área ENORME y comprender cada poquito es abrumador. Pero durante los últimos dos meses he estado trabajando para comprender los términos comerciales: Mark To Market, Risk Metrics, Positions, PnL, Griegos, Instrumentos, Estructura del libro ... cada pequeño detalle (entiendes el punto). Ahora en mi humilde opinión, este es el trabajo de un BA. Claro que es muy importante que los desarrolladores entiendan el negocio, pero ¿dónde trazan la línea?

Cuando hablé con mi gerente sobre esto, casi se burló de mí diciendo que cualquiera puede aprender una tecnología en una semana. Es el negocio lo que es más difícil. Mi aspiración a largo plazo es permanecer en el aspecto técnico, probablemente convertirme en arquitecto (si es posible). Si hubiera querido centrarme tanto en los negocios, ¡habría seguido un MBA!

Quiero saber si estoy equivocado o soy demasiado ingenuo para comprender la importancia del negocio o si se justifica mi frustración.

El trabajo de un programador es traducir los requisitos de lenguaje natural en implementaciones de lenguaje de máquina. No puede hacerlo de manera efectiva si solo habla con fluidez de un lado o del otro. A menos que esté escribiendo compiladores o software de control de versiones, casi todos los trabajos de programación requerirán una cantidad significativa de conocimientos de no programación.

Benjol y su gerente tienen razón, pero déjenme explicar:

aprender el dominio del negocio es cómo agregar valor al proceso y aumentar su valor para el negocio

Esta es la diferencia entre un programador de Code Monkey y un desarrollador

Hay un dicho que vino del Departamento de Informática de mi universidad:

Si desea crear software para geólogos, primero debe comprender la geología. Si desea crear software para físicos, primero debe incursionar en física. Si desea comprender los negocios, primero debe aprender a hablar de negocios.

Escucho gente aquí todo el tiempo que dice que el desarrollo de software es un campo creativo. Creo que esto es cierto hasta cierto punto. Involucra creatividad en que uno debe poder ver fuera de la caja para resolver una serie de problemas.

Lo que no significa es que puedes sentarte y, por lo tanto, crear creativamente lo que quieras. Esta no es una clase de arte, es ingeniería, y sus clientes y partes interesadas esperarán que cree algo que resuelva sus problemas, no algo que sea simplemente "genial".

Para resolver un problema, primero debe comprender el problema. Debes meterte en la cabeza de tus usuarios y comprender cómo piensan.

Ya sea que esté creando software para finanzas, marketing, ventas, geología, física o cualquier campo que admita el software, debe formar parte de ese campo.

Es por esta misma razón que, además de mi título en Informática, también obtuve un título en Negocios; Ha tenido un gran impacto en mi capacidad para comunicar posibles soluciones y ofrecer productos exitosos.

Si desea obtener más información sobre lo que buscaría al contratar a un ingeniero de software comercial, consulte esta Muestra de anuncio de trabajo de Ingeniero comercial que escribí como respuesta a otra pregunta.

Puede sobrevivir sin mucho conocimiento de dominio o contacto con el cliente como un codificador de bajo nivel, pero un arquitecto de software es alguien que está muy familiarizado con el dominio y se comunica activamente con todas las partes interesadas.

En mi opinión, estás equivocado y eres demasiado ingenuo.

Como dijo su gerente (ligeramente frívola), cualquiera puede aprender una tecnología en una semana. Lo único que lo marcará y lo hará útil para su empresa es su conocimiento comercial. Y cuanto más difícil sea, más valdrá la pena.

Obviamente, si encuentra que este negocio en particular es aburrido, puede buscar algo diferente. Pero si su idea del paraíso es piratear pequeños sitios web de php, tenga cuidado: habrá miles de niños de script que también lo están haciendo.

En serio, "Solo soy un programador, no me confundas con los hechos" simplemente no es suficiente.

También trabajo en Energy Trading. El conocimiento empresarial es el 90% del trabajo. No se puede evitar eso, es un negocio complicado.

Si al menos no comprende los conceptos básicos del comercio y los mercados en los que está trabajando, tendrá dificultades, sin importar cuán buen programador sea.

Trabajo con algunos BA que simplemente no pueden cumplir los requisitos correctamente. Necesito confiar en mis propias habilidades analíticas y comprensión del conocimiento del negocio para hacer el trabajo.

Creo que si está trabajando para una tienda que vende software Energy Trading, su experiencia puede diferir, pero en el comercio corporativo de energía de TI, el enfoque se centra directamente en comprender el mercado y cómo el software puede proporcionar soluciones a los problemas del negocio primero.

Las tecnologías reales utilizadas y la implementación ocupan un segundo lugar.

El hombre de arriba que hizo el comentario de Excel no sabe qué tan adecuado es su comentario. Los comerciantes a menudo construyen sus propias pequeñas aplicaciones de negociación en Excel / VBA (eso es todo lo que saben) y luego TI termina heredando estos problemas de programas.

Me encantaría reconstruir algunas de estas aplicaciones en un lenguaje "adecuado", pero eso no siempre es una prioridad.

Si se está desarrollando para un negocio, terminará teniendo una idea más clara y detallada de las reglas comerciales que cualquier otra persona en la empresa. Esto no es necesariamente porque eres más inteligente que todos, sino porque es la única forma en que puedes hacer el trabajo.

Su reacción podría ser "¿Pero qué hacen los analistas de negocios?"

Los analistas de negocios se sientan en largas reuniones con los clientes para tratar de obtener requisitos que sean lo suficientemente claros para que un desarrollador pueda trabajar con ellos. Miro la forma en que tienen que tratar con los clientes y me siento agradecida de no tener que hacer eso.

Me gusta dibujar analogías entre el desarrollo de software y la arquitectura. Ambas son artes aplicadas. Ambos requieren modelos elaborados dentro de la mente. El aspecto que se aplica a esta pregunta es que escribir software sin conocimiento comercial es como diseñar un edificio sin comprender el estilo de vida y las necesidades de los habitantes. Creo que muchos de nosotros hemos visto (o incluso vivido / trabajado en) edificios que pueden verse hermosos y modernos y, desde el exterior, simplemente no se pueden usar desde el interior. (En el peor de los casos, ni siquiera son agradables: - ((()

Actualizar

Comentario de Gaurav:

Lo que me interesa es hasta qué punto un desarrollador debe esforzarse por comprender el dominio empresarial. Debería ir hasta el final, o hay que trazar una línea.

No creo que puedas dibujar una línea en ningún lado en general. A menos que haya partes de la aplicación / dominio que no necesita tocar (así comprender) nunca. Lo cual es IMHO muy raro en la vida real, a largo plazo. Cualquier parte de una aplicación que esté en uso activo recibirá informes de errores y solicitudes de funciones. Los dominios también cambian, a medida que cambian la legislación, las normas fiscales, las políticas y los hábitos correspondientes, en resumen, el mundo real. Esto también debe seguirse en el software.

Pero incluso sin solicitudes externas de cambios, las pruebas unitarias y la refactorización del código heredado también requieren comprender las áreas de dominio relevantes. De lo contrario, simplemente "congela" el comportamiento actual de la aplicación, sin saber si es o no correcto.

Actualización2

¿Qué pasa si el desarrollador [...] cambia con frecuencia el dominio comercial en el que está trabajando?

Eso, por supuesto, significa que una gran parte de la inversión (de su tiempo y el dinero de su empleador) para obtener su conocimiento comercial se pierde :-( Si sabe que va a suceder, por supuesto, puede no valer la pena profundizar demasiado en un dominio específico. Sin embargo , tenga en cuenta que los dominios no son totalmente diferentes, hay aspectos fundamentales que pueden reutilizarse entre diferentes dominios. Y lo más importante, el enfoque de diseño impulsado por el dominio que obtiene es reutilizable.

He trabajado en el sector bancario durante más de diez años desarrollando aplicaciones comerciales y estoy de acuerdo en que es importante que los desarrolladores entiendan bien el negocio. Pero una y otra vez, durante los procesos de entrevista, si la persona no tiene un buen conocimiento del negocio, no atraviesan la puerta.

Esto ha llevado a que un número considerable de aplicaciones y sistemas críticos sean desarrollados por estas personas con un sólido conocimiento del negocio pero habilidades técnicas de nivel medio a débil. Estos sistemas siempre terminan mal diseñados, los cuales constantemente fallan, están plagados de errores, no se escalan, son casi imposibles de arreglar sin romper algo, y eso si el proyecto no termina siendo cancelado debido a la insuficiente habilidad técnica para conseguirlo. en producción