---

El día finalmente ha llegado. ¿Es su primer día de trabajo o lo ha estado haciendo durante diez años? No importa. Finalmente, nos encontramos con una tarea de programacdión que simplemente no entendemos.

Entonces, ¿qué debería hacer? ¿Debería comenzar y esperar que funcione? ¿Debería decirle inmediatamente a su jefe que no puede hacer esto porque no comprende? Yo asumo que usted sabe que la respuesta es ¡ninguna!

En programación, como en cualquier otra profesión, he descubierto que es casi imposible pasar una semana (y a veces ni siquiera un día) sin encontrar algún problema que no se puede entender. Pero no se preocupe porque le tengo buenas noticias: No solo puede solucionar este problema, sino que también puede ser algo bueno.

Significa que de alguna manera está expandiendo sus habilidades y conocimientos más allá de lo que ha hecho y conocido antes.

En los próximos párrafos, detallaré cómo puede cerrar la brecha entre los requisitos que se le han entregado y el conocimiento que necesita para completar la tarea que se le ha asignado.

 

Acerca de los “requisitos”

Es posible que haya notado que utilicé la palabra “requisitos”. Esa palabra puede tener ciertas connotaciones según el lugar donde trabaje.

En mi experiencia, a las grandes empresas les encantan los requisitos y las pequeñas empresas a veces “no cumplen con los requisitos”. Creo que esto está perfectamente bien para nuestros propósitos aquí.

Eso se debe a que, al final, todo lo que hacemos como ingenieros de software es resolver problemas.

Podría recibir un informe extenso de cien páginas sobre cómo resolver ese problema (por ejemplo, una reunión de una hora para discutir sobre el texto de un botón). O tal vez su director ejecutivo se acerque a su escritorio y le pregunte si puede resolver el problema en los próximos días.

De cualquier manera, se le han asignado tareas de programación y debe asegurarse de comprender completamente los problemas para poder abordarlos correctamente.

 

Sobre los pasos

No todos los pasos que se indican a continuación son necesarios para cada problema. Solo los problemas más difíciles de comprender pueden requerir que proceda con cuidado a través de todos los pasos que se discutirán en este artículo.

Es posible que muchas de las preguntas no se puedan responder a través de los requisitos que se le han dado o solo a través de su experiencia personal.

Es posible que deba preguntarle a otros desarrolladores, al líder de su equipo, al propietario del producto, al analista de negocios… ¡Quizás tenga que preguntarle a todos antes de que haya terminado!

Aunque eso está bien. Significa que tomará conocimiento disperso y lo condensará para residir en un solo lugar. ¡Ese lugar está en usted y ahora podrá producir el mejor resultado posible!

Una advertencia final antes de aprender los pasos: no formalice demasiado este proceso. El objetivo aquí es ayudarlo a comprender rápidamente un problema. No debería crear barreras ni trámites burocráticos. En su lugar, debe proporcionarle un plan sistemático para abordar un problema que no comprende.

 

El primer paso: analizar las tareas de programación

En este paso, buscará comprender lo que se le ha pedido que haga, pero todavía no está tratando de averiguar cómo hacerlo.

La distinción aquí es importante. Puede ser peligroso pasar directamente a la implementación sin pensar en todas las consecuencias, o peor aún, sin identificar exactamente qué es lo que se le pidió que hiciera.

Clasifique la tarea

Clasificar sus tareas de programación significa determinar qué tipo de trabajo realizará para resolver este problema. A continuación, se muestran algunos ejemplos de tipos de tareas:

• Arreglo del fallo
• Nueva caracteristica
• Nueva aplicación
• Asignación de investigación
• Mejora del rendimiento

Recuerde que estas no son todas las opciones posibles.

El objetivo aquí es determinar qué tipo de trabajo se espera que realice. Esto es importante porque tiene un efecto directo sobre el trabajo que realiza.

Este paso es particularmente importante para los requisitos vagos. Un ejemplo de un requisito vago es: “Necesitamos una forma de purgar las cachés de nuestros clientes después de una actualización del sitio web”.

Puede haber algunas posibles interpretaciones.

1. Debe implementar de inmediato algún mecanismo de purga de caché para que los clientes siempre vean las últimas actualizaciones.
2. Debe investigar todas las formas en que se almacenan las cachés de los clientes y determinar la mejor forma o formas de destruir esas cachés después de cada actualización del sitio web.
3. Los cachés de los clientes ya deberían estar borrados y necesita encontrar y corregir el error que les impide borrar.

En este punto, si no está absolutamente seguro de qué significado se está utilizando, debe solicitar una aclaración antes de continuar.

Indique cuál es la tarea en una o dos oraciones simples

Resuma los requisitos complicados como si le hubieran preguntado en qué está trabajando hoy. Tal vez no sea tan simple, pero debería poder resumirlo en una oración o dos.

Si no puede resumir sus tareas de programación, probablemente significa que tendrá que dividirla en varias tareas. Entonces, esencialmente, este paso se convierte en una prueba de fuego para determinar si ha organizado sus tareas en partes lo suficientemente pequeñas.

A continuación, se muestra un buen ejemplo de resumen: “Cuando actualizamos el sitio, agregamos un número único a los archivos para que el navegador sepa que debe usar el código más reciente”.

Esta podría ser una de sus tareas de programación que pasa la prueba de fuego de la simplicidad y probablemente no necesite crear varias tareas.

Un mal ejemplo podría verse así: “Cuando actualizamos el sitio, agregamos un número único a los archivos para que el navegador sepa que necesita usar el código más reciente. También tenemos que enviar un mensaje a nuestro CDN haciéndole saber que necesita actualizar los archivos. Además, las aplicaciones IOS y Android deberán tener una actualización enviada a la tienda de aplicaciones. También…”

Este claramente falla la prueba. Hay mucho trabajo por hacer y es posible que sea necesario identificarlo y realizar un seguimiento por separado.

Resume las partes principales

En la forma que sea más conveniente para usted, ahora debe hacer una lista de las cosas más importantes que deben hacerse.

Estos deberían ser resúmenes muy simples de cada paso importante.

Estos no deben ser una guía paso a paso o detallada de cómo solucionar el problema.

Recuerde que todavía está analizando la tarea que le asignaron. Recomendaría escribirlos de alguna manera. Yo personalmente los grabo en mi aplicación Notas.

Nuestras tareas de programación de almacenamiento en caché son muy simples y es posible que no necesiten un esquema. Para este ejemplo, consideraremos un problema más complejo.

Nuestras próximas tareas de programación son una nueva característica: “A cada usuario se le debe mostrar un anuncio específico para un producto interno. Este anuncio debe adaptarse a sus necesidades individuales en función de los datos que hemos recopilado “.

Para resumir las partes principales, deberá pensar claramente en lo que cada parte del requisito le hará hacer.

• Nuestros anuncios actuales deberán desglosarse de tal manera que puedan correlacionarse con alguna métrica de usuario específica.
• Será necesario que nuestro equipo de marketing tenga una forma de asignar nuevos anuncios a un fragmento o fragmentos de datos del usuario (¡sin codificación!).
• El sistema necesitará agregar métricas sobre un usuario que sean relevantes para nuestros anuncios.
• Finalmente, necesita crear algún tipo de sistema que reciba una identificación de usuario y emita un anuncio.

¡La belleza de una lista como esta es que puede usarse para verificar rápidamente con su equipo o jefe! Entonces, en este ejemplo, tal vez lo haya dirigido el líder de su equipo y él decidió que debe haber una pieza importante más:

• Los usuarios deberían poder decirnos cuándo ya no quieren ver determinados anuncios.

¡Porque después de todo, no queremos molestar a nuestros queridos usuarios! Al tomarnos el tiempo para pensar en nuestras tareas de programación por solo un par de minutos, nos ahorramos horas o días de dolor al identificar y planificar una tarea importante antes de comenzar con la codificación.

Antes de continuar, quiero abordar una posible crítica que pueda tener.

Es posible que esté pensando: “En un negocio adecuado, este es el tipo de trabajo que debe realizarse antes de que los requisitos lleguen al desarrollador”, ¡y definitivamente estoy de acuerdo con usted!

Sin embargo, lamentablemente no vivimos en un mundo perfecto. A veces, los requisitos no siempre se completan completamente antes de que lleguen al desarrollador. Esto significa que todos debemos hacer nuestro mejor esfuerzo para evaluar adecuadamente los requisitos antes de que comience el desarrollo.

Defina el problema o problemas que está intentando resolver

Responda la pregunta, “¿por qué alguien usará esto?”, O “¿qué problema real o percibido del mundo real estoy tratando de solucionar?”

Ojalá la respuesta sea obvia. Para nuestro ejemplo de caché, podría decir, “los usuarios siempre verán las últimas actualizaciones”. En el ejemplo del anuncio, “los usuarios verán anuncios relevantes en lugar de anuncios que no les interesan”.

Si la respuesta no es obvia, entonces probablemente sea el momento de preguntarle a alguien por qué está haciendo esta tarea. Hacer esta pregunta lo llevará a tener una comprensión más clara de la tarea en cuestión, o lo llevará a repensar lo que se le pidió que hiciera.

¡Esperamos que vea los beneficios de cualquiera de esas respuestas! Una comprensión más profunda del problema y el propósito le permitirá tomar decisiones en su implementación que realmente sirvan a los objetivos comerciales. Identificar malas soluciones o problemas que no tienen sentido evitará un esfuerzo inútil en un trabajo que nunca resolvería un problema al final.

 

El segundo paso: interpretar y evaluar los requisitos

En este punto, debe comprender qué es lo que hará y por qué lo hará.

Su próximo paso será comprender los detalles de lo que está haciendo, cómo se espera que lo haga y por qué lo está haciendo de esa manera.

Aclare todos los términos importantes relacionados con su tarea

Puede encontrar que este paso es más importante si es un desarrollador nuevo en un equipo o si trabaja en una gran empresa. Ambas situaciones hacen que sea más probable que encuentre términos desconocidos en sus requisitos.

Los términos pueden ser términos comerciales, como los nombres de productos, clientes o procesos. También pueden ser términos de desarrollo como nombres de herramientas, aplicaciones, modelos, servicios o bibliotecas.

Debe estar seguro de comprender todos los términos importantes, sin ninguna vaguedad, para que pueda estar seguro de que está implementando su tarea correctamente.

Es posible que comprenda que necesita crear una forma de acceder a la información agregada del usuario, pero ¿comprende lo que significa agregarla al “DAO (Objetos de Acceso a Datos)“?

Es posible que comprenda que necesita formatear los datos del anuncio, pero ¿comprende qué es el “MADF” (alimentación de datos de anuncios de marcado)?

Yo tampoco.

Es por eso que debe identificar y definir todos los términos importantes. Tiene una mayor probabilidad de implementar la tarea de forma incorrecta si se equivoca en las definiciones.

Identificar cómo se deben realizar sus tareas de programación.

En este punto, ahora debería comenzar a ver cómo se debe realizar la tarea. Este paso puede variar ampliamente según el lugar donde trabaje y la tarea en particular que se le haya asignado.

En algunos equipos, no se le dirá cómo implementar los requisitos, solo se le indicará con qué funcionalidad debería terminar.

Otros detallarán cada paso que debe dar.

Lo más probable es que su experiencia se encuentre en algún punto intermedio.

Si su equipo no le ha dado instrucciones, no puede hacer mucho en este paso. Si le han dado instrucciones, en este punto querrá empezar a familiarizarse con los pasos que deberá seguir.

Este paso parece bastante obvio, pero el orden en el que aparece es algo a lo que debe prestar especial atención.

La inclinación natural puede ser sumergirse en todos los detalles de la tarea antes de asegurarse de que se comprenda el propósito de la tarea.

Como primero se tomó el tiempo para comprender su tarea, ahora tendrá un objetivo más claro en mente al evaluar los pasos que debe seguir.

Determinar si los problemas se resolvieron

Aquí es donde confluyen la etapa de análisis y la etapa de interpretación. En la etapa de análisis, se centró en los objetivos y resultados generales, el qué y el por qué.

En el paso de interpretación, se centró en los detalles, el cómo.

La razón por la que se llama interpretación y evaluación es que ahora comparará el cómo con el qué y el por qué. Interpreta los detalles considerando el panorama general. Evaluará los detalles y determinará si se resolvió el problema original.

Pregúntese: ¿Los pasos que me dieron darán como resultado el resultado que su tarea tenía la intención de crear? ¿Este resultado realmente resolverá el problema original?

Si está seguro de que todos los problemas están resueltos y todos los detalles tienen sentido, ¡está listo para comenzar su trabajo! De lo contrario, debe pasar a la tercera etapa para resolver cualquier conflicto.

 

El tercer paso: pensar críticamente

En esta etapa, debe poder afirmar con seguridad que comprende el problema y la solución. El último paso es asegurarse de tener la solución adecuada.

Para crear el mejor producto posible, todos debemos sentir que tenemos la responsabilidad de hablar cuando algo simplemente no tiene sentido.

Por otro lado, no queremos estar en desacuerdo fuera de turno. No debe decir que algo está mal porque “se siente mal” o porque “no me gusta”. Debes tener razones concretas y bien pensadas.

Así que establezcamos algunas reglas básicas sobre los desacuerdos.

Sepa cuándo estar en desacuerdo

• No esté en desacuerdo hasta que lo comprenda completamente.

Nunca diga que algo anda mal hasta que esté absolutamente seguro de que comprende con qué no está de acuerdo.

Si no puede expresar con seguridad el problema y la solución prevista, no debe estar en desacuerdo. Si no ha verificado su comprensión, no debe estar en desacuerdo. Solo cuando sepa que tiene la comprensión más completa posible, debe comenzar a estar en desacuerdo.

Si descubre que no tiene toda la información que necesita, entonces podría ser el momento de detenerse y revisar cualquiera de los pasos anteriores antes de decirle a alguien que los requisitos son incorrectos.

• No esté en desacuerdo sobre asuntos subjetivos. Concéntrese en los problemas potenciales reales.

“No me gusta cómo se hace esto” es subjetivo. “Esto causará problemas de rendimiento debido a la cantidad de operaciones involucradas”. es una razón objetiva. Otros ejemplos de razones subjetivas pueden incluir, “No es así como lo hice en otros lugares” y “Hubiera diseñado esta solución de manera ligeramente diferente, pero solo por preferencias personales”.

• Tenga listas explicaciones bien razonadas de sus desacuerdos para ser presentadas.

Si no puede explicar por qué algo anda mal, ¿puede decir realmente que sabe que está mal? Sugeriría escribir las razones por las que algo está mal y qué se puede hacer para solucionarlo.

Alternativamente, si no tiene una solución, indique claramente al principio que no lo sabe.

Tenga cuidado cuando no esté de acuerdo con los demás. La mayor parte de su tiempo debe dedicarlo a comprender y escuchar antes de estar en desacuerdo.

Si siguió todos los pasos hasta este punto, es muy probable que lo entienda bien. ¡Pero tenga mucho cuidado de mantener la mente abierta de que es posible que se haya perdido algo!

Me gusta iniciar conversaciones diciendo: “No estoy en desacuerdo con usted, simplemente no entiendo”. Más tarde llega el desacuerdo si es necesario, pero ojalá nunca antes se entendiera.

Sepa cómo estar en desacuerdo

Para asegurarse de que no estamos de acuerdo objetivamente, aquí hay algunas medidas que lo ayudarán a determinar si su desacuerdo es válido.

Los desacuerdos objetivos hacen uno o más de los siguientes:

• Muestre que la solución está desinformada.
• Muestre que la solución está mal informada.
• Demuestre que el problema o la solución es ilógico.
• Demuestre que la solución está incompleta.

Estar desinformado no es un insulto, sino que significa que faltaba información cuando se creó una solución. Quizás no conocían un sistema que existe actualmente y que puede realizar las acciones necesarias.

Estar mal informado significa que la solución provino de información incorrecta.

En este caso, podrían pensar que un sistema existente hace algo que en realidad no hace. Por ejemplo, tal vez el equipo de SEO (optimización de motores de búsqueda) le solicitó que Google indexara una página registrada en su aplicación. Google no puede hacer eso. Estaban mal informados sobre lo que hace el rastreador de Google.

Un problema o solución ilógica es uno que simplemente no tiene sentido. Como desarrollador, creo que una solicitud ilógica común que puede ver es una característica que podría romper otra característica. Podría considerarse ilógico hacer eso porque haría daño, en lugar de ayudar.

En realidad, se puede pretender una solución incompleta. En el desarrollo de software, a menudo intentamos comenzar haciendo un MVP (producto mínimo viable). Esto significa que, al principio, podemos omitir intencionadamente funciones que no son absolutamente necesarias.

En su lugar, solo debe considerar que una solución está incompleta si no resuelve el problema inmediato que se le pidió que corrigiera, o si los pasos proporcionados no son suficientes para crear un producto o función que funcione.

 

Resumen

Recuerde, no formalice demasiado este proceso. Debería ser rápido y probablemente consistir en anotar algunos pensamientos en su aplicación de Notas. Luego, posiblemente podría conducir a algunas conversaciones con sus compañeros de trabajo para aclarar lo que se supone que debe hacer. ¡Eso es todo!

A continuación, se muestra una lista simplificada de los pasos:

Paso 1: analizar

• Clasificar
• Resumen
• Contorno
• Define el problema

Paso 2: interpretar y evaluar

• Aclarar términos
• Identificar las tareas de programación
• Determine si el problema se resolverá

Paso 3 – Piense críticamente

• Sepa cuándo estar en desacuerdo
• Sepa cómo estar en desacuerdo