Como programador, ¿cómo puedo acelerar mi adopción y comprensión de las reglas comerciales?

He sido desarrollador por un tiempo. Estoy lejos de ser el mejor que hay. (Mientras me siento solo en esta sala, me pregunto si soy el mejor aquí.) Sin embargo, he llegado a comprender mis herramientas y he llegado a confiar en mi capacidad para razonar y aprender.

Cuando comienzo un nuevo trabajo, siempre creo que puedo aprender la base de código si es un idioma que conozco. Si no conozco un lenguaje o marco, creo que puedo comprender los conceptos lo suficiente como para aprenderlo (y solo leer la documentación). Esta es una parte de nuestro conjunto de habilidades como programadores y estoy orgulloso de poder cumplir con este estándar.

Sin embargo, por todo esto, una de mis principales debilidades es aprender e internalizar las reglas comerciales para el cliente para el que estoy trabajando de manera rápida, ya sea que sea un empleado remunerado o un contratista. Estoy bien con las bases de código, pero las reglas y los procesos comerciales para un negocio específico siempre me llevan un tiempo comprenderlo completamente. (Como ejemplo, esto puede ser un error al reescribir aplicaciones empresariales).

Como desarrollador, ¿cuál es la mejor manera de asimilar las reglas y procesos comerciales de manera rápida y eficiente? ¿Es posible sin ser un experto en la materia o simplemente tener años de experiencia con el cliente, la empresa o el negocio?

Para mí, es leyendo y entendiendo las bases de código.

Lo digo por dos razones clave:

1. La gente apesta. Ah, no deliberadamente (por lo general), pero en los negocios he descubierto que las personas a menudo tienen una comprensión sutilmente diferente de las reglas de negocios. Y cada uno tiene su propio modelo mental que, a su vez, pierde fidelidad al tratar de comunicarse con usted. Pero el código no miente. Las personas pueden pensar lo que quieren sobre cómo se supone que funcionan las cosas , pero el código es correcto.

2. Construir una base primero. Entonces, si todos tienen su propio modelo mental de cuáles son estos términos y procesos específicos del negocio, ¿cómo construye el suyo? Para mí, y espero para muchos programadores, construyo mis modelos mentales mejor a partir del código. El código tiene patrones. El código tiene abstracciones. Tengo mucha experiencia tomando código y construyendo un modelo mental a partir de él. Una vez que tenga al menos una forma vaga de lo que las cosas existen y cómo se relacionan, a continuación, puedo hablar con la gente de negocios. Entonces puedo hacer las preguntas correctas y ajustar mejor sus respuestas al rompecabezas.

No seas demasiado duro contigo mismo. A veces me pregunto por qué incluso se molestan en llamarlas "reglas" comerciales, pero supongo que llamarlas "formas en que normalmente hacemos las cosas a menos que haya otras cosas que se apliquen y luego las hacemos de manera diferente" probablemente las insultaría. El negocio es desordenado. Hacen juegos malabares con las necesidades de clientes, agencias legales, contabilidad, regulaciones, vendedores, empleados, gerentes y gobiernos locales. No siempre tienen una razón.

Creo que la mejor manera es asegurarse de pasar tiempo con tanta gente de negocios como sea posible. Esto puede ser difícil para algunas personas en puestos técnicos.

1. Presupuesta tu tiempo y sé respetuoso con el de ellos, pero obtén todo lo que puedas.
2. Tendrás que hacer preguntas. No piensan como programadores y desglosan todo y tienen una comprensión completa de cómo se relaciona la información entre sí.
3. No finjas como lo entiendes. Si supieras tanto como las otras personas de negocios, te harían hacer ambos trabajos. Ver # 2.
4. No esperes documentación. Elogie mucho si alguna vez recibe alguno.
5. Espera las críticas. Los procesos y procedimientos pueden tener redundancias y otras posibles eficiencias, pero puede haber una razón para ello. Aprenda por qué, pero no se sorprenda cuando digan: "Siempre lo hemos hecho así".
6. Sea cortés, amable y comparta sus refrigerios. Estás tratando con personas. Di hola. Pregunta cómo les va. Pregunte por qué entraron en la industria, cuánto tiempo han estado con la compañía.

No eres un vacío llamado programador, eres una persona. Hágales saber que está allí para facilitar su trabajo. Desafortunadamente, puedes ser el héroe o la cabra. Es la naturaleza de nuestro negocio.

Recomendaría leer un libro titulado Los 5 elementos del pensamiento efectivo de Edward Burger y Michael P. Starbird. Está relacionado con la comprensión de nuevos conceptos en general, pero creo que se aplica a esta situación.

Aquí hay algunos puntos interesantes del libro:

Domina lo básico

Si no conoce los conceptos básicos, desarrollará su comprensión sobre una base inestable. Por lo tanto, debe hacer esas preguntas estúpidas que nadie más hace.

Deja que los errores sean tu guía

A veces es útil hacer preguntas que están claramente equivocadas para que puedas descubrir tu falta de comprensión. (Ej: ¿Quieres decir que los administradores tienen acceso a todos los documentos? Oh. ¿Por qué?)

Enseñar o explicarlo a otros

Cuando intentes enseñárselo a alguien más, comenzarás a descubrir dónde tienes problemas para entender.

¡Espero que ayude!

Como desarrollador, me di cuenta de que traduzco directamente el negocio en código, estructuras de datos, posibles clases, etc. Pasé de algo abstracto y, a menudo, indefinido a algo específico, algo con "forma". Empiezo a codificar de inmediato y, la falta de información , me lleva a refactores frecuentes. Cada refactorizador me hace pensar que hay demasiados vacíos en mi comprensión del negocio .

¿Cómo he comenzado a resolver esto?

Me obligo a leer todos los documentos realizados durante el análisis funcional y las fases anteriores. Intento hacerlo como si fuera el cliente o el usuario final . Necesito comprender qué busca el cliente con dicha aplicación y requisitos. Pero necesito alejarme del desarrollador que soy.

Nuestro trabajo nos proporciona una gran habilidad que los clientes no tienen. Pensamos en estructuras condicionales de una manera que otros no. Entonces empiezo a enfrentar los requisitos. Buscando contradicciones o incoherencias . Un poco de lluvia de ideas sobre lo que he entendido. Formulación de escenarios hipotéticos.

Me llevó a preguntas y dudas. Escribo todos y finalmente establezco una reunión con quien pueda resolver mis dudas.

Resumiendo, cambio mi punto de vista. Trato de ver el problema desde otra perspectiva. Pero puse algunas habilidades de desarrollo en el proceso. Lo que termina en un buen grupo de preguntas y dudas por resolver. Una vez resuelto, mi comprensión del negocio es más profunda.

Estudio> Dudas> Preguntas> Respuestas> Comprensión (y repita el ciclo una y otra vez)