Este Viernes 9 estaré exponiendo en la UTP!

En coordinación con la Universidad Tecnologíca del Perú: José, Roberto y quien les escribe, estaremos dando una serie de ponencias el día Viernes 9 de Abril desde las 7 de la noche.
Esto en las instalaciones de la UTP, especificamente en el auditorio Madre de Dios.

Desde aquí brindar mis agradecimientos a la Facultad de Ingeniería Industrial y de Sistemas de la UTP y especialmente al Decano de la Facultad por habernos invitado a compartir nuestras experiencias.

Las ponencias estarán orientadas a las Tecnologías de Información en el Mercado Peruano, pero para darles mayor detalle, un poster del evento!
Charla.UTP.Viernes.09.Abril.2010
Aquí una breve descripción de las sesiones:

1.- Tecnologías Estratégicas: ¿Qué debemos conocer?
Ponente: Roberto Camacho S.
Resumen: Marco practico-conceptual de las tecnologías que que todo estudiante debe considerar como estratégicas dentro del plan académico/profesional que desee desarrollar.

2.- Virtualización, La Nube y sus servicios Ponente: José Ponce A.
Resumen: Revisión practico-conceptual de las alternativas y fundamentos de Virtualización y servicios relacionados a Cloud Computing.

3.- Tecnologías de Información: Marcos, Metodologías y Herramientas que buscan Valor Agregado Ponente: Jersson Dongo P.
Resumen: Fundamentos, experiencias y lecciones aprendidas sobre el uso de herramientas, marcos de trabajo y metodologías de gestión, desarrollo de software e infraestructura tecnológica.

Este evento está dirigido especialmente a estudiantes de la Universidad, pero que sucede si deseas asistir? En este caso hemos conseguido acceso para 20 personas externas, si estas interesado, te comento que el requisito principal es ser miembro de la Comunidad Alphab-IT y luego de esto enviar un correo con Nombres y DNI al correo comunidad@alphab-it.com

Este Jueves estaremos enviándoles una confirmación e invitación de ingreso al evento.

Saludos
@Jersson

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?

Entrevista 
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.

requerimiento 
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.

Ese no es mi problema!

Honestamente, quién no ha pasado por una escena que tenga esa frase?
Desde ambos lados del partido, es posible, quizá por inexperiencia o simplemente ganas de salir “facilmente” del malentendido, uno puede llegar a decir, al menos una vez, tal comentario.

Pero basta de pensar en posibles explicaciones, lo único que nunca deberiamos olvidar, es una frase memorable como “necesito una solución no dos problemas”.

Asi es que, si estan en posición de solucionar un problema y el contexto se los permite, no se hagan de los oidos sordos, a resolver!

Aquí un video que deberiamos ver y recomendar cada cierto tiempo.

Fuente: Navegapolis.net

Saludos
@Jersson

Primer video publicado

Gracias a las recomendaciones y ánimos de muchos amigos es que he decidido, si el tiempo lo permite, realizar una serie de publicaciones en video, sean webcasts o screencasts… la idea es compartir un poco de lo aprendido y de paso aprender, no?

Bueno, aqui la primera prueba, sin editar ni nada, a la espera de sus comentarios =)

http://content.screencast.com/users/Jersson/folders/Default/media/5ea3c33b-3304-4ad3-a934-f9300065b404/mp4h264player.swf

Muchas Gracias a @grubhart por el dato del html que estaba fallando, sino, nunca publicaba el embed con el video!! (aunque el dice que la culpa no es del html, iluso!)

Saludos
@Jersson

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-.

dialogo 
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.

papeles 
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.

caja 
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!