5to Debate ISSADIO 21/10

Los invitamos a la edición número 5 de ISSADIO. Debates y exposiciones sobre temas actuales relacionados con el desarrollo de software.
Estos son los temas y expositores de la próxima reunión, como siempre en UNTREF / SADIO el 21/10 en Galerías Pacifico de 9.30 (café) a 12.30 (estrictos).


¿Es posible certificar ISO 9001 en serio usando agilidad?

La vigencia de la llamada Ley de Software trajo como consecuencia un boom de certificaciones de calidad, y es de esperar que su renovación por otros 10 años, continuará el auge de las certificaciones. 

En este marco ISO 9001 aparece como la certificación más requerida. El atractivo de los beneficios puede hacer que la tentación de "prefabricar" la certificación sea muy grande.

Es totalmente factible hacer una implementación de un sistema de gestión de la calidad, con principios y métodos ágiles, que sea sencilla minimalista y compatible con las normas ISO y los principios ágiles. 

Alvaro Ruiz de Mendarozqueta

Alvaro Ruiz de Mendarozqueta se desempeña como consultor independiente en temas de gestión, calidad, desarrollo, estrategia, planificación, capacitación e ingeniería del software. También es consultor en la Fundación Sadosky. Es Consultor Ejecutivo en Liveware IS y Consultor Principal en Taller Technologies en temas de gestión, calidad e ingeniería del software. Tiene más de 34 años de experiencia en desarrollo de software en áreas tales como telecomunicaciones, finanzas, seguridad pública, sistemas embebidos y transporte. Docente de posgrado en UTN FRC y UTN FRSF.v

Entendamos a la TI de hoy

Dado el crecimiento y la relevancia que han adquirido en la actualidad las Tecnologías de la Información, los responsables de áreas de TI tienen el desafío de alinearse con el negocio, generar valor y demostrarlo. Para poder hacerlo, es necesario evolucionar en el gobierno y la gestión de TI. Pero, como siempre, primero hay que saber de qué se trata.

¿Gobierno y gestión, es lo mismo? ¿En qué se diferencian? ¿Qué comprende cada uno? ¿Existe algún marco de referencia que los abarque? ¿Por dónde se empieza?

Guillermo Angelani

Profesional de nivel gerencial de Tecnología Informática, con más de treinta y cinco años de trayectoria. Ha conducido diferentes áreas de TI responsables de planificar, implementar y dar soporte a servicios de misión crítica. Además de la conducción, ha llevado a cabo profundas reorganizaciones de estas áreas, fijando no sólo el marco de gestión sino también su rumbo estratégico, siempre sobre la base de metodologías, estándares y buenas prácticas de la industria. También ha liderado múltiples proyectos de TI de gran envergadura y exposición

¿Son compatibles los productos de software actuales con la norma ISO 25000?

Dada la velocidad con que se producen hoy los cambios en la tecnología, y consecuentemente en el software que las maneja, los tiempos de proyectos cada vez más cortos, la complejidad de determinar en forma precisa sus requerimientos y resultados, surge una pregunta: 

¿Puede ayudar un estándar de calidad de producto como ISO 25000 a una mejor comprensión del problema y a resolverlo teniendo en cuenta el contexto antes mencionado?

¿Son compatibles los productos de software actuales con la norma ISO 25000? from Raúl Martínez

Saludos,
Raúl
@RaulMartinez582

La Persona detrás de El Usuario

Al tratar de entender un problema a resolver o la solución a proponer, hablamos habitualmente de El Usuario. Eso es correcto según toda la literatura y es quien en última instancia utilizará nuestro producto/servicio.  

Bastante tiempo atrás nos preocupaba que este usuario recibiera un producto funcionalmente correcto, luego en la medida que la tecnología lo permitió sumamos cada vez más la idea de usabilidad y finalmente hoy debemos sumar algo más abstracto de definir que es la persona que está detrás de ese usuario.

Así como la propuesta Ágil nos muestra, entre varias otras cosas, la Persona que está detrás del Recurso en el Equipo de Trabajo y lo útil que es considerarla, deberíamos examinar cómo nuestro modelo de análisis de los problemas contemplan a la persona detrás del usuario y no sólo la funcionalidad que utilizará en la operación del producto.

Hay varios factores además del funcional, como el social o el emocional, que pueden finalmente transformarse en requerimientos tal como cualquier otro requerimiento funcional que conocemos.

En mi opinión este tipo de análisis es un movimiento imparable debido a la presión y difusión de las tecnologías que hoy ya están totalmente incorporadas al plano social y personal.

Sobre el tema, hay literatura interesante que si bien pertenece a lo que llamaríamos habitualmente libros de negocios, creo que son necesarios para el analista de negocios, el product manager , el arquitecto / desarrollador senior y por supuesto el emprendedor.

Los libros son estos:

--Business Model Generation, Osterwalder, Pigneur, 2009

--Value Proposition Design, Osterwalder, Pigneur , Bernarda, 2014

--The four steps to epiphany. Steve Blank, 2013

--The Startup Owner’s Manual. Blank , Dorf, 2012

Ninguno trae ideas revolucionarias, excepto el formato gráfico de los dos primeros utilizado para plantear temas áridos de negocios. Hay ideas de Christensen, Kim, Ries, etc. Bien condensadas y presentadas.

Conviene empezar por el primero Business Model.

Hay que tomarse un tiempo para leerlos, desprenderse del preconcepto de “eso es un  tema del negocio, no mío” y recordar siempre la frase de Steve Blank  -- get “outside of the building” -- que las cosas ocurren fuera de nuestro lugar de trabajo. Con la lectura no basta.

Hasta la próxima.

Raúl Martínez

rmartinez@rmya.com.ar

www.rmya.com.ar / Ideas sobre el software / Twitter: @RaulMartinez582

Sobre la importancia de la camiseta

En estos días en que el mundial de fútbol está al tope de las noticias y es tema de conversación aún entre los no futboleros, solemos darnos cuenta del valor de los buenos equipos. No sólo de las figuras o estrellas con que se cuente, o de los buenos entrenadores. Y de cómo en equipo se logran victorias, que individualmente no es tan fácil o posible lograr.

Trasladando esto a los equipos de trabajo, es claro que si cada integrante “corre” hacia distinto lugar sin un objetivo común, lo que se logre será sumamente pobre.

Y esto es lamentablemente así y puede tener resultados a veces catastróficos, en los proyectos relacionados con TI, y en particular con la construcción de software. Seguramente cada uno lo habrá podido apreciar en diferentes contextos, proyectos, posiciones dentro de los equipos, posiciones dentro de las organizaciones para las que se llevan a cabo.

Si bien no siempre se requiere un equipo compacto y súper motivado, ya que hay tareas para las cuales se requiere un grupo de trabajo, por ejemplo en mantenimientos repetitivos y otras tareas más rutinarias (que no implica que sean sencillas), en un proyecto no ocurre lo mismo.

Cuando se lo requiere, hay varios aspectos de la gestión de proyectos relacionados con la gestión del equipo de proyecto, como por ejemplo:

•          Roles necesarios
•          Momentos en que debe involucrarse cada rol
•          Capacitaciones / habilidades requeridas
•          Mecanismos de incorporación y desafectación / proveedores
•          Dependencias
•          Responsabilidad / autoridad
•          Motivación
•          Incompatibilidades
•         Localización
•          Restricciones
•          Aspectos culturales y de idioma
•          …

Habitualmente nos preocupa tener a la gente adecuada y capacitada, y disponible cuando se la requiere en las diversas actividades.

Lo que no siempre miramos con igual cuidado, es lo relativo a aspectos motivacionales, buena relación y sinergia entre los miembros de todo el equipo, voluntad de cada persona para colaborar con otros y compartir sus conocimientos, ganas de “poner garra” para triunfar y llegar entre todos a lograr los objetivos del proyecto. Gente que esté “orgullosa de la camiseta”.

Pero cuidado, una gran mayoría de esos aspectos, no dependen sólo de cada persona, dependen de cómo gestionamos el equipo como responsables de hacerlo, de cómo escuchamos a la gente, atendemos sus dudas y problemas, colaboramos también al logro de sus expectativas personales, y al logro de un buen clima en el proyecto. También depende del contexto organizativo donde se desarrolla el proyecto y la cultura de cada organización participante.

Claramente, muchos podrán aducir que la mayoría de esos aspectos son muy difíciles o imposibles de manejar cuando los proyectos que actualmente se contratan se basan en menores costos, tercerización, distribución de pequeños paquetes de trabajo, desconociéndose el “todo” de los proyectos, etc.

Pero creo que cualquiera sea la forma de la contratación, es fundamental la formación del equipo, y lograr que se trabaje de la forma más satisfactoria para todos, cliente, proveedor, personas.
Y por favor, dejemos de llamar a nuestra gente recursos. Es el primer obstáculo que ponemos en el camino a construir un buen equipo de trabajo.

Hasta la próxima
Pilar

Equipos multidisciplinarios

En el post anterior  Una visita al supermercado mencioné el tema de los equipos que están compuestos por personas que dominan diferentes disciplinas.  Para no que no quede en un enunciado, detallo un poco el tema. 

Como lo que buscamos es la mejor experiencia de usuario posible que lleve al éxito del negocio, el equipo que se conforme debe estar compuesto por todas aquellas personas que puedan colaborar a lograrlo y verificar que realmente se logró. Esto significa que tiene que estar el que hace y el que ve en el campo el resultado de lo hecho. 


Entonces, el equipo multidisciplinario deberá, al menos idealmente:

• Encargarse de un flujo de valor. Esto es entenderlo, diseñarlo, implementarlo y medir su resultado en operación.  Para poder responder ¿qué le aporta/aportó al negocio esta operatoria?
• Ser responsable por ese flujo de valor, es decir tomarlo como propio, no descargando responsabilidades en uno u otro sector. Lo que se construye es de todos y todos en el equipo son responsables por su éxito o su fracaso.

Estos dos puntos nos llevan a que al equipo multidisciplinario lo deben componer entonces: 

• personas del negocio que entiendan qué se requiere y qué se espera del producto/servicio y del flujo de valor en particular, 

• personas técnicas que tenga capacidad para llevar adelante la ejecución 

• y personas de la primera línea de contacto con el usuario que informen el resultado del producto en operación de modo de adecuarlo donde se requiera.

No todos deben saber hacer de todo en el equipo. Si bien sería ideal, también sería poco óptimo y utópico. Pero sí todos deben saber qué se hace y por qué y para qué.  

Ventajas, muchas: sentido de pertenencia, objetivos definidos, indicadores de negocio relacionados a indicadores técnicos, etc.

Obstáculos, bastantes: organizaciones funcionales que no aceptan, por cultura o desconocimiento, otras alternativas de organización; pequeños “caciques” que no ceden su territorio; negocio e implementación separados por fronteras funcionales, etc.; “secretos” del negocio no accesibles a personas técnicas; vivir en urgencias continuas y no encontrar  proyecto ni tiempo para implementar la idea (que entonces nunca aparecerá). 

Resumiendo, como todo primer paso es complejo, no exento de caídas y vueltas a empezar.

Pero en muchas organizaciones que ofrecen productos exitosos, se trabaja en equipos multidisciplinarios.

Viene de Una visita al Supermercado

Sigue en  ¡Hoy volvemos al Super!

Saludos,

Raúl

TW: @RaulMartinez582

Nota: la imagen muestra un momento del rescate de los 33 mineros chilenos de la mina de cobre San José durante agosto 2010.