sábado, 28 de marzo de 2015

Abaratar el coste de los desarrollos nativos móviles yo querer

El miércoles 25 asistí a una charla en la Universidad de Cantabria que me pareció muy interesante y me ha inspirado para escribir este post.
El título de esta charla es “Introducción a la programación móvil multiplataforma con Xamarin” impartida por Rafael Serna y que forma parte del ciclo de charlas divulgativas “Informática en acción”.
La charla comenzaba con una introducción dedicada a las aplicaciones nativas y como encarece el precio del desarrollo por la necesidad de tener que programar para cada plataforma móvil. Hasta que no me metí en este mundillo móvil gestionando proyectos para aplicativos móviles, no era consciente de este requisito.
Como las webs se pueden desarrollar para que sean “responsive”, es decir que se adapten a los terminales móviles,  la mayoría de las empresas no ven la diferencia entre un aplicativo nativo y no nativo. Transmitir las ventajas del primero ha sido una de mis tareas más tediosas estos años y “una batalla sin cuartel” ya que los precios hacen del desarrollo nativo un producto de lujo.
Las ventajas y desventajas de desarrollo nativo frente a uno web adaptativo (respondive) son muy conocidos y ya hay mucho escrito, por ello no me extiendo. Tan sólo añado un breve resumen comparando tres tipos de desarrollos: Nativos, Web Adaptativos e Híbridos.
La elección entre una u otra tecnología debe estar en función de las “Prioridades de la empresa” y lo que busca con este nuevo aplicativo.
La charla sobre Xamarin (http://xamarin.com) nos introducía a esta solución multiplataforma con Visual Studio y C# que permite desarrollos nativos para las apps iOS, Android, Mac y Windows solucionando el problema de “múltiples expertos” para cada plataforma y facilitando la reutilización del código y por ello reduciendo los costes y tiempo de los desarrollos. Esta solución también unifica los diseños y tiene módulos para los testing y estadísticas de visitas.
Me gustó mucho la idea y animo a Xamarin a que amplíe a otras plataformas móviles y, porque no, opensource!

miércoles, 11 de marzo de 2015

Stakeholder, “El concepto es el concepto”*

Hoy dedico el blog a analizar el significado de la palabra inglesa “Stakeholders” en el contexto de la “Gestión de Proyectos”.
Si buscamos en la wikipedia la definición es **: “Stakeholder es un término inglés utilizado por primera vez por R. E. Freeman en su obra: “Strategic Management: A Stakeholder Approach” (Pitman, 1984), para referirse a «quienes pueden afectar o son afectados por las actividades de una empresa».”
Parece sencillo pero no lo es. Será la experiencia la que te indique quienes son estos “afectados/das” por las actividades del proyecto. 

Cuando cae en mis manos un proyecto totalmente nuevo siempre le dedico un tiempo a pensar quienes son los Stakeholders. La lista la almaceno en un Excel que conservo hasta el final de mi proyecto y la voy mejorando a lo largo de este, sobre todo en proyectos largos donde la visión inicial se va perdiendo y es cuando llega el día de cerrar el proyecto y aparece ese stakeholder que vino tan solo a la reunión de arranque, kick-off, pero que firma del certificado de aceptación. OMG!.

En esta tabla añado Nombre, Posición, % de “Son Afectados” por el proyecto y % de “Pueden Afectar” en el éxito del proyecto. Esto me ayuda para gestionar más tranquila la parte más “humana” de un proyecto técnico y saber a quién dirigirme en función de que problemas existan.

Almacenar esta lista te sirve tanto para el proyecto actual como futuro, por ejemplo, el contrato de mantenimiento posterior donde, habitualmente, se repiten estos stakeholder aunque con un peso de influencia diferente que habrá que reestablecer.

En este listado se encuentran, así a voz de pronto, por parte del cliente el gestor del proyecto, los usuarios finales (of course!), el equipo de sistemas, redes y el gestor de calidad. Y no debemos olvidar a nadie de nuestro entorno de trabajo como el propio equipo de trabajo, nuestro equipo de sistemas, redes, nuestro jefe, diseñadores, equipo de calidad. En muchos proyectos la administración pública: Ley de protección de datos, Ley de residuos, alcalde del pueblo… y como no: la competencia que no perderán oportunidad de recordarle a tu cliente que ellos lo harían de otra forma y mejor!
En caso de duda, siempre añado a ese “quizás” en la lista y al final se suele acertar, ¿intuición? ¿experiencia?

Veamos un ejemplo sencillo en clave de humor. Mi proyecto: "Voy a plantar un árbol en mi jardín".

Tabla de Stakeholders
Persona/perfil            "% son afectados"          "% pueden afectar"      "Como actúo"                            
Mi pareja 100 100 Consenso
Mis hijos 100 80 Consulto
Mi suegra 5 100 Yes Ma'am!
El vecino 75 25 Informamos
El jefe de la urbanización 30 90 Informamos e 
                                                                                                             invitamos a una copa
Ley de Montes/
guardia forestal/
guardia civil                         10                                    100                       Cumplimos con la 
                                                                                                                  normativa

Como conclusión: al castellano parlante la palabra “Stakeholder” no le aporta nada, sin embargo su concepto es importante para conseguir el éxito del proyecto ayudando en cómo abordar las relaciones humanas que rodean el proyecto. Olvidar este aspecto pone en riesgo el proyecto y nuestra carrera como gestores.


*Como nos dicen en la peli de Airbag: “El conceto es el conceto”