La diferencia entre el QUE y el COMO

Este es un tema de conversación muy recurrente cuando nos reunimos y hablamos de la importacia de tomar requerimientos.

A veces, cuando converso con algunos amigos, ellos comentan lo aburrido que notaron al usuario que estaban entrevistando. 
Ante esto siempre surge mi duda: 
“Qué tal la primera vez que se reunieron, de qué tipo eran tus preguntas, qué tanto ahondaste?
Quizá demasiado, no?”

 
Generalmente, lo que sucede es que posiblemente hayamos pecado de entusiastas, y de esa forma, a pesar que sabemos que no cubriremos lo necesario en una entrevista, queremos seguir preguntando al usuario detalles que de primera mano no vienen al asunto.

Debemos recordar siempre, que para el usuario es mas importante que uno comprenda y comparta las necesidades básicas que deben cumplirse.
Es cierto, estas necesidades son lo que conocemos los requerimientos principales, funcionales del sistema.

Algunos recomiendan tener menos detalle, llamándoles "Requerimientos Macro" o simplemente "Características" (algo asi como matricular, vender, comprar, grabar). Pero la verdad es que, en ocasiones (por no decir, todas) esto logra que confundamos los verdaderos objetivos de cada requerimiento.
Asi que personalmente hablando lo recomendable es comenzar a comprender, o al menos tomar en cuenta aquello QUE debe cumplir el proyecto, es decir el QUE del proyecto.
 
En este punto, el problema que surge es que mientras mas vamos comprendiendo aquellas cosas QUE deben hacerse en nuestro proyecto, nacen interrogantes algo tentadoras, que posiblemente, logren desviarnos del objetivo.
Asi es, mientras vamos avanzando vemos como van naciendo las dudas, cómo es que vamos hacer esas cosas?. Y que tal si preguntamos un poco mas, funcionalmente cómo se haría?

ERROR! eso nos desenfocaría demasiado del problema, en estos casos, el COMO cambia la dirección del problema, y mientras mas vamos ahondado en como cubrir tal interrogante, mas vamos perdiendo la hilación y el objetivo de las primeras reuniones.

 
En otras ocasiones he notado problemas y estancamientos entre equipos que quieren definir sus contratos (programáticamente hablando, cómo se comunicarán y usaran sus librerias), ya que ademas de pensar en los parámetros a intercambiar, hay integrantes del equipo que comienzan a hurgar en COMO hacer el método del otro, cuando el objetivo de algunas tareas es tan solo, la definición del objeto!!, el QUE del objeto, no el COMO cumplir con ciertas actividades.

Es gracioso, pero, la frase clave siempre termina siendo "No Desenfoques, estamos averiguando el QUE, luego veremos el COMO", o simplemente "NO Desenfoques!!!"

Ahora, como es que vamos convirtiendo el QUE en muchos COMOs? pues iterando. o no?

Saludos
@Jersson
PD: Esta es una versión editada y mejorada de un post mío publicado hace mucho tiempo. Esto a raíz de un nuevo tema de conversación que será comentado mas adelante.

Estándares y el why del asunto.

Como habrán podido notar, los últimos posts tratan de temas similares y muy relacionados a conceptos de estándares en general.

Pero lo que no se ha tocado de manera explicita, al menos, no de mi parte, es el por qué del asunto.
Porque, la verdad de las cosas es así de simple: muchas veces hemos caído en el lema de crear, proponer, reutilizar, publicar e incluso querer imponer el uso de estándares.

Antes de continuar, mi postura sigue siendo firme, con esto se soluciona poco o nada, mas que agregar un nuevo conjunto de reglas a los trabajadores del código fuente, mis amigos los constructores y programadores, con los cuales, me siento identificado.

Pero bueno, iniciemos con el why del asunto y opiniones/consideraciones al respecto.

Estándares, que buscan?
Eliminar barreras y alinear
De por si, lo que uno cree solucionar con ello es el desorden natural a consecuencia de un trabajo en equipo.
Con esto no pretendo decir que los equipos son desordenados, pero está demostrado que cada equipo nace con un nivel de entropía elevado, esto a consecuencia de factores como:
- Diversidad cultural
- Creencias
- Niveles de conocimiento
- Años de experiencia
- Personalidad
- Barrera idiomática
- Jerga Profesional (de por si, la jerga es algo profesional, no?)

Con esto, es que a veces se llega a creer que la solución parte con que todos hablen “el mismo idioma”, o lo que muchas veces llamo Lenguaje Común-del cual podríamos hablar en otra ocasión-.

 
Lo ideal sería conseguir que todos se encuentren alineados y sin ningún tipo de barrera. Pero lamentablemente se necesita considerar entre otros, como mínimo dos factores de riesgo:
- Capacidad: ya que muchos no podrían comprender el nuevo lenguaje a usar.
- Visión compartida: la cual mucho tiene que ver con el valor agregado que le encuentren los involucrados.

Orden
Es obvio que se busca orden, pero de qué manera y por qué?
Pues inicialmente, lo ideal es tratar de eliminar lo mencionado líneas arriba, esto bajo la creación de reglas que:
- No deberían ser complejas
- Repito, deberían ser de rápido entendimiento.
- Sea de lo que hablemos, código, sentencias, instrucciones, comentarios, pantallas, colores, SIEMPRE debe contarse con un ejemplo.
- Debe buscarse siempre, la manera mas gráfica de demostrar una regla.
- Agrupe la información de manera que se pueda resolver alguna interrogante sin necesidad de recorrer varias páginas.
- Y para intentar ser lo menos extenso posible, debe buscarse la manera de no entregar un documento de estándares de 100, 50 o 20 hojas.
- Busque siempre demostrar que el valor agregado de su estándar es inversamente proporcional con la cantidad de hojas que este tiene (a menos hojas, mejor)
- Resumen: Sea lo mas directo posible o entregue dos documentos, el detalle y el resumen que lee un público mas concreto.

 
Curva de Aprendizaje
El término Curva de Aprendizaje ha sido muchas veces uno de mis caballos de batalla cuando he intentado explicar la consideración de un adicional en tiempos de respuesta de personas que fueron integradas al equipo de trabajo.
De por si, trabajar en equipo muchas veces se torna complicado, y mas complicado aun si se trata de ser el nuevo de equipo, no? Ya que uno no solo tiene que preocuparse por su trabajo, sino por:
- Conocer políticas de trabajo
- Reglas de compilación y control de código fuente
- Módulos, responsables y responsabilidades
- Qué tan atrasados vamos?
- A qué hora almuerzan y acostumbran salir?

Estos aspectos, entre otros son aquellos que se deben buscar eliminar con el paso del tiempo.
Lo de horarios de trabajo, no es broma, pues he participado en mas de un proyecto con personas que tienen unas costumbres alimenticias por no decir, extrañas y estoy seguro que más de uno ha pasado por eso y que de alguna manera, esto afectaba al trabajo en conjunto.

Cambio de Contexto
El cambio de contexto, es un concepto que salió conversando entre muchos amigos en tiempos y proyectos diferentes. No he encontrado una referencia al respecto, pero la idea en este caso va cuando por ejemplo te cambian de proyecto y te encuentras con una realidad completamente diferente a la que ya andabas acostumbrado.
Si bien es cierto, no eres el nuevo en la empresa, pero básicamente, eres el nuevo en el proyecto!
Entonces, posiblemente no solo se trate de responder a las dudas mencionadas en el párrafo arriba descrito.
Se trata de sobrevivir a aspectos cómo:
- Por qué en este proyecto usan estos módulos?
- Vale usar otras librerías?
- Aquí no usamos el acceso a datos convencional?
- Aquí usamos otro controlador de código fuente, por qué?

De por si estamos hablando de un cambio de realidad que puede ser muchas veces doloroso y puedo agregar, que va desde deprimente hasta frustrante.

 
Entonces, lo que debe considerarse al trabajar sobre un estándar, es buscar que cada vez que una persona cambie de proyecto, tenga el menor número de preocupaciones, para que esto no sea una limitante para iniciar su trabajo y además lo desarrolle de una manera efectiva.

Entonces, cual es el WHY del asunto?
Podríamos resumirlo de la siguiente manera
Los estándares buscan:
- Eliminar barreras de trabajo
- Alinear formas de trabajo.
- Cumplir con la idealidad del Lenguaje Común.
- Disminuir tiempos en curvas de aprendizaje.
- Eliminar riesgos y problemas por cambios de contexto.

Cómo deberían ser?
- Simples.
- Rápidos.
- Con ejemplos y de ser posible, gráficos.
- De requerir sustentos técnicos, debería manejarse en apartados de uso y revisión opcional.
- De uso, conocimiento y aceptación general.
- Avalados por la empresa y a la vez, por sus trabajadores.
- Abiertos a nuevas posibilidades.

Qué es lo que nunca te asegurarán?
- Disminución de tiempos de entrega.
- Riesgo cero a problemas de trabajo en equipo.
- Orden y cumplimiento de reglas.
- Calidad funcional de los entregables.

Es un hecho que posiblemente se me estén escapando algunos aspectos clave, pero estoy seguro que con esto podremos resolver algunas interrogantes cuando se trate de avalar la necesidad de un set de estándares, y ojo, que no hablamos solo de codificación.

Los invito a compartir sus experiencias al respecto y el feedback que consideren necesario.

Saludos
@Jersson

Publicado en JersSoft on the Block!

Orden y Estándares

Mientras converso con mis amigos, compañeros del trabajo, ya sea almorzando o mientras vamos a casa, casi siempre sale a flote uno de los temas mas espinosos en lo que respecta a implementación o uso de alguna metodología en particular.

Lamentablemente tengo una posición que hasta el momento ha valido mas de una discusión, malentendido o molestia. Debido a que el punto de visto que mantengo, indica que no hay respuesta cien por cierto buena, ni solución que aplique a todos los casos.

En realidad ni siquiera puedo decir que “depende de…” ya que no hay manera de determinar si todo lo que haremos aplicará correctamente, puesto que hay demasiados factores que no se resuelven por usar tal o cual metodología.

Pero bajemos un poco mas al llano, hablemos de algo mas tangible en proyectos reales. Pues, es cierto, no todos usamos alguna metodología, framework o práctica extrema.
La verdad es que como mínimo debemos contar con orden y estándares.

 
El problema?
Pero cuál es el problema? pues simple y a la vez, doloroso.
Ninguno puede asegurar la veracidad o cumplimiento del otro.

Por qué?
La verdad, además de triste y complicada, es que no puedes vender siquiera el uso de un estándar, si es que las personas con las que se tiene que trabajar, no cuentan con un orden en particular.

Y si fueran todos ordenados?
Tenemos el siguiente caso:
Eres ordenado pero estas contento con tu manera de trabajar, sabes como hacer tu trabajo, estas de acuerdo con mejorar, pero sientes que lo que haces, está bien hecho.
Entonces, necesitas estándares?
Posiblemente… pero veamos que presto al cambio sea el equipo. 


Entonces cómo debería ser o hacerse?
Personalmente hablando, considero que:
1. Debe analizarse la apertura del equipo hacia “nuevas” tendencias. En este caso, favor notar las comillas. Puesto que por lo general muchas de las novedades a proponer, son en gran parte aceptada por el mercado pero posiblemente, no nos estamos dando cuenta.
2. Debe confirmarse la Existencia de Orden, sea el caso que sea… orden debe existir! Programación, tiempos de entrega, pruebas, pruebas unitarias! La idea es que haya orden y este sea tangible o al menos, identificable no solo de palabra.
3. Estandarización, el cual puede ser malinterpretado como parte fundamental del software de calidad. Pero la verdad es que el cumplimiento de un estándar, tiene mucho que ver con la apertura de los involucrados y el orden que tengan estas personas. De eso, nada mas.
4. Interiorización, Aquí solo podré decirles, por mas apertura que haya, por mas orden o estandarización que se tenga establecido. No se puede hablar de un cumplimiento real, si no es que no se tiene interiorizado el concepto. Nada tiene sentido.

Si hablamos de una característica que tomaría como punto fundamental para el inicio correcto, créanme, sigo pensando que sin interiorización, no habría por que preguntarnos por el resto de cosas. Sin eso, nada tiene sentido.

Saludos.
@jersson

El Mecánico

Hace unos meses, mientras visitaba un local de pintado y mecánica automotriz, me di con una sorpresa muy interesante en una de las paredes.
Había una sección que tenía un mensaje tipo “por favor, las herramientas deben estar ordenadas!”, en letras muy grandes.
En ese momento me dije, será complicado seguir una norma básica? si es así, porque las letras tan grandes?

Luego había una pared con muchos ganchos numerados de manera artesanal, pero numerados al fin y al cabo. Cada uno de estos contenía mas de una llave de tuercas, estando estas agrupadas por el número que indicaba cada gancho.
Esto sinceramente me pareció una buena idea! ya que he ido a lugares donde solo tienen cajas de herramientas y cuando alguien dice “pásame la de 3/4!” pues comienzas a escuchar como suenan las llaves mientras van buscando el número deseado. Que pérdida de tiempo, no?

En otra ocasión, mientras veía como revisaban un llanta en el agua (esto para ver si tenia agujeros), noté que antes de comenzar, la marcaron con una tiza, al encontrar los huecos, hicieron lo mismo en cada lugar con problemas, y al terminar la revisión antes de sacar la llanta para reparar, marcaron de nuevo la llanta!

Es obvio, marcan los errores para parcharlos. pero por qué al inicio? por qué al final?
- Lo que sucede joven, es que tengo que dejar una marca donde estoy comenzando a revisar la llanta, sino termino dándole vueltas por gusto, o no termino de revisarla por completo.
- Y bueno, le hago una marca al final para saber por donde comenzar cuando tenga que colocar nuevamente la llanta en el aro.

La verdad es que quedé sorprendido por la necesidad de exactitud que tenia el señor trabajador. Honestamente, en otras ocasiones no había encontrado eso.

Lo cual me hizo pensar y a la vez encontrar mucha analogía con el trabajo que realizamos los desarrolladores, ya que, no importando la tecnología:
- Requerimos de orden, aunque sabemos que no basta con solo poner un anuncio o mensaje de búsqueda de calidad, establecemos estándares de trabajo y ponemos de alguna manera, carteles pidiendo el cumplimiento del mismo.
- Realizamos pruebas, revisamos si es que hay huecos en nuestros programas, y si somos un poco mas meticulosos, establecemos técnicas de identificación, mejor aun, si es que las tenemos automatizadas.
- Marcamos los errores que identificamos, estando esto muy relacionado con la analogía anterior.
- Establecemos bases y marcas al iniciar o culminar un trabajo, y si utilizamos herramientas controladoras de código fuente como mínimo, pues mucho mejor, no?
- Salvo conocidas excepciones, no tenemos problemas en compartir explicaciones sobre las prácticas que realizamos. Aunque claro, a veces hay momentos en los que pensamos que las cosas son obvias, suponemos y caemos en el error, pues no debemos suponer!!

Creo que si es que tuviera algo de tiempo y mas llantas con hueco, podría seguir visitando talleres mecánicos y sorprendiéndome con el orden y otras veces, desorden que se pueda encontrar.
Y eso que no he mencionado los niveles y maneras de integración que hay en estos equipos.
Con decirles por ejemplo, que aquí en casa están refaccionando el cuarto de al lado, y he visto el trabajo en equipo que realizan las dos personas involucradas, sin contar las diferencias que uno puede identificar en cualquier equipo de trabajo, me pareció muy interesante el nivel de coordinación que manejaban, algunas prácticas y técnicas que utilizaban.

Pero a lo que quiero llegar mi estimado lector, esperando no haberlo aburrido, es que nuestro trabajo por mas técnico/informático/artístico que pueda llegar a ser, puede ser visto de manera similar cuando se compara con otras actividades, como el trabajo en de un mecánico automotriz, un albañil, gasfitero y así.

Entonces, la recomendación que podríamos rescatar de todo esto, es:
Que nos tomemos un tiempo y mientras este bajo nuestro alcance, busquemos y encontremos analogías entre lo que sucede en lo cotidiano del mundo real (por así llamarlo) y el trabajo que realizamos.
O mejor aun, si pueden pregunten a su mecánico sobre los procedimientos que usa, claro sin ser muy molestosos que digamos eh!
Lo del mecánico puede ser tomado como un ejemplo, ya que en realidad, lo recomendable es que veamos y comprendamos las cotidianidades de los profesionales de otras carreras u oficios.

De ser mejor aun, lo ideal seria que conversemos con ellos, compartamos experiencias, veamos y permitamos ver nuestros puntos de vista desde otras perspectivas.

De ser así, que otras soluciones descubriríamos? pues aun no lo se, pero créanme, estoy seguro que mientras mas llantas tenga que reparar, mas cerca estaré.

 
Un Saludo.
@jersson

Asegurando la Calidad… estás seguro?

Hace un tiempo, mientras revisaba/corregía las observaciones que el equipo de control de calidad hacia, una de las personas del equipo “contrario” (por así decirlo) fue parte de uno de los diálogos mas interesantes por esos días.
Líneas abajo, un resumen:
- QA: Si, está bien, ahora está todo mas rápido.
- Yo: Y cómo lo determinas?
- QA: Bueno, es lo que parece, no?
- Yo: …
- Yo: Estás seguro?
- QA: (sonrisa) ya bueno, con mi reloj.

Por esas fechas una de las observaciones mas importantes tenían que ver con la performance de la aplicación, a lo cual procedimos a ejecutar diversas pruebas, muchas de estas bajo automatización realizada con programas que habíamos construido, mientras que por otro lado, usábamos herramientas que en base a reportes, nos aseguraba, o al menos nos daba una idea del consumo de recursos, administración de memoria, tiempos de respuesta, etc.

Mientras transcurría el proyecto, se resolvían las observaciones y éramos testigos de como el producto comenzaba a integrarse con cada aplicación, por mi parte confirmaba (y lamentaba) una vez más la pobre percepción que tienen muchos profesionales sobre el Aseguramiento de Calidad.
El problema se hace mayor si es que nos damos cuenta de que esta falencia también está sentada en las empresas, no solo en algunos trabajadores, sino en los jefes! 

Lo que pasa es que muchos piensan, creen o aseguran, que asegurar la calidad se determina por la menor cantidad de errores que salgan al probar la aplicación luego de programar un módulo, funcionalidad o peor aun… al terminar de programar todo!

Error!

Asegurar la calidad tiene que ver con:
- Asegurar
- la
- Calidad.

Nada mas que eso!
(no, no estoy bromeando)

Y cómo logras algo tan simple?
Pues primero, tenemos que detenernos un momento y determinar cuales son nuestros estándares mínimos para definir un producto de calidad.
Tranquilidad ante esto, ya que muchas veces estos aspectos ya están definidos por las gerencias de alto nivel.
Lo que se debe hacerse es conversar con el equipo (una vez mas, la comunicación saliendo a flote) sobre estos aspectos ya definidos y ver/encontrar/definir/decidir de que manera se hará un trabajo acorde a esto.

Pero decidir una forma de trabajo que vaya de acuerdo a la idea de los estándares de calidad de la compañía es mucho menos del 50% de lo que tienes que hacer para asegurar la calidad de tus desarrollos.

Debemos en primera instancia mantener un respeto al trabajo de las demás personas, por eso:
- Si alguien usará la librería que estas creando, pues, simula su uso antes de entregarla. Ante esto, la primera palabra clave es: pruebas unitarias, aunque claro, hay mas conceptos, pero al menos ese, no?
- Si ya vas a entregar tu módulo/funcionalidad, realiza algunas pruebas en base a lo especificado funcionalmente y acordado con tu Analista de Pruebas.
- No puedes aducir que no tienes tiempo y que esa ya no es tu tarea, pues tu tarea en realidad es entregar algo que funciona, recuerda, es prácticamente el valor de tu palabra y del compromiso que tienes con el proyecto.
- El Analista de Pruebas tiene como una de sus actividades principales, confirmar las funcionalidades especificadas, no tanto así, como verificar si es que algo está correctamente compilado, desplegado, escrito, diseñado visualmente.
- Escrito: es decir, ortográfica y gramaticalmente hablando, es que acaso ser ingenieros informáticos nos da opción a no saber escribir?
- Diseño Visual: esto es dependiendo del caso, pero si vienes con la mentalidad del “ya luego vemos como le arreglamos el diseño” pues, créeme, estas comenzando mal.
- Lo mencionaré en otros términos, el trabajo del Analista de Pruebas, no es ver si lo que has publicado está listo para probar. Su trabajo es confirmar si está listo para ser publicado.

Si bien es cierto, hasta este momento muchas de estas anotaciones parecen obvias o difíciles de considerar por la naturaleza de nuestro mercado, pero la verdad es que aun no hemos terminado de hablar al respecto.

Pues, queda determinar algo bien claro:
Asegurar la calidad una aplicación no es probar la aplicación.


Cómo es eso?
Independientemente del modelo de trabajo que se esté siguiendo, debemos tener en mente y aceptar que el aseguramiento es constante, que si hablamos de fases, microfases, iteraciones, etc. pues lo que se debe considerar siempre es que todo artefacto debe pasar por un proceso de certificación realizado por un tercero ajeno de manera directa a lo liberado, que asegure que lo se va a liberado:
- Que funcione, si es un módulo.
- Se entienda, si es un documento, procedimiento, proceso
- Sea claro, que no requiera explicación
- Responda a los flujos ideales y casos ideales.
- Soporte casos complejos, si es que ya es una versión superior.
- Que tenga sustento, sea técnico, funcional o ambos, lo realizado debe tener sustento! no solo se trata de un “así me pareció” o “es que lo otro no me gusta”.

Como podrán notar asegurar la calidad de un producto, desde el punto de vista de construcción de software (tema del cual espero hablar en alguna oportunidad), no tiene mucho que ver con pensar en el producto como un todo, sino en un esquema integral en el cual, cada componente está completamente ligado con la siguiente versión del mismo y del producto en si. 

No podemos olvidarnos de las personas involucradas en la construcción, liberación y certificación de cada artefacto, teniendo muy en cuenta que cada uno no puedo ser juez y parte del trabajo que viene haciendo, que además de nuestro trabajo, está en juego nuestra palabra y el respeto a las demás personas que usarán lo que vayamos liberando (dentro y fuera del proyecto).

Y lo mas importante, asegurar la calidad de un producto, no es probar el producto, y mucho menos a ultima hora!

Saludos
@Jersson