2 presentaciones sobre turismo

Ponencia Raúl Hernández de la Jornada Nuevas Experiencias Turísticas: Oportunidades y modelos de negocio, en Foro CajaCanarias-27 Noviembre 2012 from Fundación FYDE-CajaCanarias

Ponencia Sergio Moreno Gil de la Jornada Nuevas Experiencias Turísticas: Oportunidades y modelos de negocio, en Foro CajaCanarias-27 Noviembre 2012 from Fundación FYDE-CajaCanarias

Libro sobre programación

Todavía no lo he leído, pero se ve que van al grano.

http://cloud.github.com/downloads/emanchado/camino-mejor-programador/camino_2012-11-09_3bee1fb.pdf

Gran video sobre Gobierno Abierto

Como he abierto un gobierno: Nagore de los Rios at TEDxMadrid

Esta es la plataforma

http://www.irekia.euskadi.net/

Ssh desde un navegador web con HTML5... Increible.

Ssh desde un navegador web con HTML5... Increible.


http://liftoffsoftware.com/Products/GateOne

Infografía PI-Model Driven Development

Platform-Independent Model-Driven Development Infographic

Executive Summary Platform-Independent Model Drive Development (PI-MDD) is an integrated agile, test-driven and model-driven approach to architecting, developing, testing and deploying complex, high-performance systems software. Two decades of constant refinement by hundreds of development teams and dozens of technology and expertise vendors spanning a range of challenging industries have optimized this method and its supporting automation to deliver the highest performance and best quality systems while boosting key business results. Real-world project metrics show the PI-MDD at its current level of refinement yields repeatable results including substantial productivity gains and 10 times quality gains within 14 months of adoption.

Model driven engineering is not cool

New programming languages are cool. Agile is cool. Cloud is cool. MDE / modeling is clearly not cool. Every time I mention the word model I get the immediate question: where is the proof that MDE improves productivity / quality /… ty. Instead if I talk about the latest programming language (new Agile method, new cloud platform,…) everybody gets excited and nobody asks if somebody has done any research on whether the new language is better than existing ones. They always give it at least the benefit of the doubt.

I wonder why this is not the case with MDE. Maybe the memories of the UML fever still hurt. Maybe there is something intrinsic in MDE that repels people. Maybe we should stop doing research on new MDE technologies and instead try to understand how we could change people’s perception and make MDE cool. That would probably the biggest advancement in the field of the last 10 years!

Two last things:

• We do have some proof about the benefits of modeling (see an example) but this is not the topic of this post
• I’m not saying that cool technologies do not bring any benefit (nor that right now we don’t have proof of that). I’m highlighting they were massively adopted before that proof exsisted.

http://modeling-languages.com/mde-is-not-cool/ (via Jordi Cabot)

[...] Meinte Boerma
One of the reasons that MDE is not cool is precisely that it has an uncool history (in the form of MDA, UML, 4GL, CASE tools, etc.) 

[...] Gleen

I’m going to have to disagree with Frank. MDE is not cool with programmers precisely because they want to spend their time coding. With MDE, you spend most of your time modeling and not coding.

As a programmer, I think MDE is cool because you do spend time meta-programming which I find to be very geeky and intellectually challenging in a oddly relaxing way. Most programmers aren’t into that at all. They are quite uncomfortable with modeling because they think it is for wannabees and posers who want to pretend that they can code but really cannot.

Plantillas Lean Startup Canvas y Business Model Canvas

Google drive es una buena opción para crear y compartir tus modelos de negocio. Podemos para ello podemos usar las plantillas que ya están creadas de manera pública.

https://drive.google.com/previewtemplate?id=1X27K9Z_6mPI7Q_YTBWT7llWdPp0JGre2AB7cueft5pg&mode=public

https://drive.google.com/previewtemplate?id=16uOd158UzJM9oqGWgJOtbppzGNPmZ4fWMSV6_xBz3Z8&mode=public

https://drive.google.com/previewtemplate?id=1UaiazQ2v97VlekS8iFtLYafWSQzKB9Waq2ivDI-F4cU&mode=public

Reflexiones sobre Oficinas Técnica

Reflexiones sobre Oficinas Técnica ( vía Rafa Feliciano)
http://rafafelicianor.wordpress.com/2011/09/26/oficina-tecnica-de-proyectos-un-aliado-estrategico/

Considero que hay tres características principales que convierten a unaOficina Técnica de Proyectos en un socio tecnológico necesario para implantar las medidas derivadas de la estrategia de la organización. Como detallaré seguidamente, estas cualidades son inherentes a un equipo técnico-funcional dedicado a la gestión de proyectos de tecnologías de la información.

Transversalidad

Los sistemas de información alcanzan, de manera horizontal, a toda la organización y a todos sus niveles. La promoción e implantación de aplicaciones y herramientas es, por lo tanto, una función de la oficina técnica que implica un impacto global. Por este motivo, alinear a la OTP con la estrategia corporativa se convierte en un factor facilitador clave para llevar a cabo el despliegue de las actuaciones y políticas que se desea adoptar.

Conocimiento de negocio

Siguiendo el punto anterior y dado el carácter global de los sistemas de información, el asesoramiento y gestión de proyectos que desempeña una oficina técnica en la organización hace que concentre, en un reducido equipo de consultores, un amplio conocimiento del negocio. Esta capacidad ofrece a la organización un valor que, en muchas no tiene cubierto con perfiles correspondientes a técnicos de gestión.

Conocimiento tecnológico

El perfil de los consultores de una OTP cuenta con una sólida base en conocimiento de las infraestructuras informáticas y de telecomunicaciones. Estas capacidades convierten a una oficina técnica en referente en el ámbito tecnológico de la organización, ya que puede abarcar desde el conocimiento técnico hasta la planificación estratégica de los sistemas.

Como conclusión, la combinación de estos tres factores es un valor añadido adicional, ya que se concentra en un único equipo de trabajo tanto el conocimiento horizontal (negocio) como el especializado o vertical (tecnología)

http://rafafelicianor.wordpress.com/2011/06/08/dos-donts-de-una-oficina-de-proyectos/

[...]

Cuando me pregunto qué debe hacer una OTP me surgen múltiples respuestas, todas ellas con tres conceptos comunes: coordinación, conocimiento, asesoramiento. De estas tres ideas generales se desprende la relación de acciones identificadas: anticipar los problemas y proponer soluciones; orientar la evolución de los sistemas de información proponiendo las líneas tecnológicas a seguir; gestionar los proyectos y controlar su ejecución, tanto en lo referido al seguimiento de plazos como a garantizar la calidad de las soluciones implementadas; identificar las necesidades de la organización; participar en el diseño de las soluciones para que se ajusten a las necesidades identificadas; canalizar las peticiones provenientes de la capa de negocio concretando los requerimientos de partida para facilitar la obtención de un análisis inicial; ofrecer información de soporte al nivel directivo para la toma de decisiones estratégicas.

A pesar de que desarrolle todas estas actividades, una OTP no podrá ofrecer todo su valor potencial si la organización no tiene a este equipo como referencia en el desarrollo del negocio y, consecuentemente, de los sistemas de información.

Por otra parte, desde mi punto de vista hay un tipo de tareas que no debe hacer una OTP, y que podría resumir como ejecutar los proyectos encomendados por la organización a terceros. Dentro de esta categoría incluyo, principalmente, cuestiones como la realización de tareas de mantenimiento y evolución de los sistemas de información, implementación de las soluciones evolutivas o correctivas de las aplicaciones de soporte al negocio, etc. La realización de tareas de este tipo supondría una pérdida de eficiencia al duplicar esfuerzos que deben ser asumidos por la empresa que ejecuta los proyectos en cuestión. En este sentido, la OTP no estaría aportando el valor añadido esperado por la organización.

Como resumen me ha parecido interesante representar sobre el diagrama del Ciclo de Deming (Plan-Do-Check-Act) las responsabilidades de una Oficina Técnica de Proyectos, ya que encajan prefectamente con los pasos Plan y Check.

En este punto se podría ampliar la discusión con la siguiente pregunta: ¿quién es el responsable de planificar las tareas a realizar en el proyecto? Si atendemos a la propuesta de roles de Scrum, la planificación de cada iteración es responsabilidad del Product Owner (persona que toma las decisiones del cliente) pero, ¿puede ser la OTP el Product Owner? En el caso de mi organización la respuesta es no.

Para concluir me gustaría retomar el comentario sobre el denominador común que hacía al principio. En este caso propongo tomar como referencia la guía PMBOK, que aborda la PMO (Project Management Office) desde una perspectiva abierta indicando que tiene “responsabilidades asignadas con relación a la dirección centralizada y coordinada de proyectos”, señalando posteriormente funciones como el apoyo administrativo al establecimiento de políticas, metodologías y plantillas; la capacitación y asesoría a los directores de proyectos; la identificación de recursos necesarios en el proyecto; y la centralización de la comunicación entre directores de proyecto, patrocinadores, nivel directivo y otros interesados.

Seguramente con vuestra experiencia y aportaciones se podrá ampliar y mejorar esta primera aproximación. ¿Se animan a participar?

¿Qué es una OTP?

http://www.ambiser.es/servicios/ContenidoExtendido/ContenidoExtendido_0006.html_49272422.html

Una Oficina Técnica de Proyectos (OTP) es un centro de competencia dentro de cualquier organización, normalmente externalizado, que permite la coordinación entre las diferentes áreas de la organización y los departamentos de tecnología, sirviendo de referencia para la recogida y canalización de todas las necesidades en materia tecnológica.

Funciones de una OTP Establecer las bases tecnológicas de los diferentes proyectos a ejecutar Definir los pliegos técnicos de las contrataciones a realizar Dar soporte a la evaluación de las propuestas técnicas presentadas por los diferentes ofertantes Realizar el seguimiento de los proyectos en ejecución Dar soporte a las certificaciones de las entregas correspondientes a los proyectos ejecutados Realización de informes de seguimiento y cuadro de mando de indicadores de seguimiento del proyecto Analizar las nuevas necesidades planteadas desde los diferentes departamentos de la Organización Apoyo a las reuniones de seguimiento Apoyo a la colaboración con otras Administraciones Públicas Búsqueda activa y continua de financiación alternativa disponible Difundir los resultados del proyecto a Ciudadanos, Empresas y otras Administraciones Coordinar los diferentes canales de comunicación de la organización para difundir el proyecto

¿Qué beneficios obtiene el cliente? Recibe el asesoramiento adecuado y alineado a los objetivos del proyecto, sin tener que realizar contrataciones de personal especializado. Coordina los diferentes actores del proyecto adecuadamente Establece un equipo de referencia para cualquier consulta o acción a emprender dentro de la organización Unifica los criterios para seleccionar y atender a proveedores Obtiene un ahorro de costes en la gestión de cualquier proyecto Dispone de los medios humanos adecuados a las necesidades del proyecto en todo momento Oficina técnica de proyectos from Isidro Parga PMO (vía PMBOK) A project management office (PMO) is an organizational body or entity assigned various responsibilities related to the centralized and coordinated management of those projects under its domain. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of a project. The projects supported or administered by the PMO may not be related, other than by being managed together. The specifi c form, function, and structure of a PMO is dependent upon the needs of the organization that it supports. A PMO may be delegated the authority to act as an integral stakeholder and a key decision maker during the beginning of each project, to make recommendations, or to terminate projects or take other actions as required to keep business objectives consistent. In addition, the PMO may be involved in the selection, management, and deployment of shared or dedicated project resources. A primary function of a PMO is to support project managers in a variety of ways which may include, but are not limited to: Managing shared resources across all projects administered by the PMO; Identifying and developing project management methodology, best practices, and standards; Coaching, mentoring, training, and oversight; Monitoring compliance with project management standards, policies, procedures, and templates via project audits; Developing and managing project policies, procedures, templates, and other shared documentation(organizational process assets); and Coordinating communication across projects. Project managers and PMOs pursue different objectives and, as such, are driven by different requirements. All of these efforts, however, are aligned with the strategic needs of the organization. Differences between the role of project managers and a PMO may include the following: T he project manager focuses on the specifi ed project objectives, while the PMO manages majorprogram scope changes which may be seen as potential opportunities to better achieve business objectives. The project manager controls the assigned project resources to best meet project objectives while the PMO optimizes the use of shared organizational resources across all projects. The project manager manages the constraints (scope, schedule, cost, and quality, etc.) of the individual projects while the PMO manages the methodologies, standards, overall risk/opportunity, and interdependencies among projects at the enterprise level.