Cómo comprender cualquier tarea de programación

El día finalmente ha llegado. ¿Es su primer día de trabajo o lo ha estado haciendo durante diez años? No importa. Todos finalmente nos encontramos con una tarea 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?

¡Imagino que sabes que la respuesta no 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 entiendo.

¡Pero no te preocupes! 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 le han entregado y el conocimiento que necesita para completar la tarea que le han asignado.

Acerca de los 'requisitos'

Puede que hayas notado que utilicé la palabra "requisitos". Esa palabra puede tener ciertas connotaciones según el lugar donde trabajes.

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 es porque, al final, todo lo que hacemos como ingenieros de software es resolver problemas.

Podrías recibir un informe extenso de cien páginas sobre cómo resolver ese problema (una vez tuve una reunión de una hora 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 antes del viernes.

De cualquier manera, se le ha asignado una tarea y debe estar seguro de que comprende completamente ese problema para poder abordarlo 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 preguntar a otros desarrolladores, al líder de su equipo, al propietario del producto, al analista de negocios o incluso a su abuela. ¡Quizás tengas que preguntarles a todos cuando termines!

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

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

El primer paso: analizar la tarea

En este paso, buscará comprender lo que se le pidió que hiciera. ¡ Aún no estás tratando de averiguar cómo hacerlo!

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

Clasifica la tarea

Clasificar una tarea significa determinar qué tipo de trabajo hará 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

Recuerda que estas no son todas las opciones posibles.

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

Este paso es particularmente importante para 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 los cachés de los clientes y determinar la mejor forma o formas de destruir esos cachés después de cada actualización del sitio web.
  3. Las cachés de los clientes ya deberían estar borradas 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 reducirlo a una oración o dos.

Si no puede resumir la tarea, probablemente signifique que tendrá que dividirla en varias tareas. Básicamente, este paso se convierte en una prueba de fuego para determinar si ha organizado sus tareas en partes lo suficientemente pequeñas.

Este es un buen ejemplo de un resumen: "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".

Esta tarea 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 deba identificarse y seguirse por separado.

Resume las partes principales

En la forma que sea más conveniente para usted, ahora debe hacer una lista de las cosas principales 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.

Nuestra tarea de almacenamiento en caché es muy simple y es posible que no necesite un esquema. Para este ejemplo, consideraremos un tema más complejo.

Nuestra próxima tarea es 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 asigne nuevos anuncios a una o varias partes de los 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 se puede usar 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 más importante:

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

Porque después de todo, ¡no queremos molestar a nuestros queridos usuarios! Al tomarnos el tiempo para pensar en nuestra tarea 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 están completamente desarrollados 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, ¡probablemente sea hora 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 volver a pensar en 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 asegurarse 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"?

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 debe realizar la tarea.

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 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 podrá 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 ha tomado 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 se unen 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 disentir fuera de turno. No debes 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 cuando 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 discrepes 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 a mano explicaciones bien razonadas de sus desacuerdos.

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 para solucionarlo, 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 dedicarse a comprender y escuchar antes de estar en desacuerdo.

Si siguió todos los pasos hasta este punto, es muy probable que tenga una buena comprensión. ¡Pero tenga mucho cuidado de mantener la mente abierta de que puede haberse perdido algo!

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

Sepa como estar en desacuerdo

Para asegurarnos 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 podemos, al principio, omitir intencionalmente 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 llevar a algunas conversaciones con sus compañeros de trabajo para aclarar lo que se supone que debe hacer. ¡Eso es todo!

Aquí hay 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
  • Determine si el problema se resolverá

Paso 3 - Piense críticamente

  • Sepa cuando estar en desacuerdo
  • Sepa como estar en desacuerdo

Hola, soy Justin Fuller. ¡Estoy tan contento de que hayas leído mi publicación! Necesito hacerle saber que todo lo que he escrito aquí es mi propia opinión y no tiene la intención de representar a mi empleador de ninguna manera. Todos los ejemplos de código son míos y no tienen ninguna relación con el código de Bank Of America.

También me encantaría saber de ti, no dudes en conectarte conmigo en LinkedIn, Github o Medium. ¡Gracias de nuevo por leer!