viernes, 24 de octubre de 2014

Dia 1. Taller de Enfoque Estratégico de Innovación y Gestión de de la Innovación.

¿Qué me gusto del curso?


  • La experiencia del expositor. Platico muchos casos del sector de innovación en México durante 30 o 40 años como consultor de InfoTec en empresas tradicionales mexicanas. 
  • Ha viajado a muchos lugares del mundo por lo que también comenta anécdotas y experiencias.
  • Hay algunos casos que podré utilizar para mis cursos de innovación.
  • Una empresa expreso la necesidad que tienen para que alguien los ayude a realizar proyectos de estímulos a la innovación y que pagan 40,000 pesos por la elaboración del proyecto.

¿Qué no me gusto?


  • Demasiado teórico.
  • Creo que no les va a servir mucho a las empresas asistentes.Las empresas esperan herramientas que les sirvan para realizar proyectos de innovación. 
  • El curso es una charla general de innovación y planeación estratégica. El profesor conoce muchas, pero no está especializado.
  • Ha sido consultor durante mucho tiempo pero no se ha especializado.
  • Menciona muchas metodologías pero no se aterriza en ejercicios concretos.
  • Solo el profesor habla.

Algunas ideas que considerar


  • Innovar comienza por como vemos a nuestra empresa u organización. Es diferente considerarte un productor de muebles para oficina que un habilitador de espacios para incrementar la productividad y el ambiente.
  • La innovación es diferente de la invención.
  • La innovación es un mundo de fracasos.
  • Si alguien no está encargado de innovación está se diluye. 
  • Irrelevancia de los estados contables.
  • El Balanced Scorecard tiene la perspectiva de los dueños (financiera), de los clientes, de la operación (procesos) y de la innovación y crecimiento. Esto yo no lo habia pensado así.
  • El problema no es fracasas. Debemos de fracasar rápido. Todas las tecnologías son conocimientos de tecnologías acumuladas.
  • La innovación es una cuestión de comunicación al interior.
  • Liderazgo es la capacidad de lograr cambios.
  • Si un profesional no dedica una hora a ver lo que esta pasando en el mundo en su tema, esta fuera.
  • Las oficinas de patentes son un lugar para donde buscar proyectos de innovación. De ahí se pueden buscar innovar basado en lo último que se ha registrado.
  • La sociedad se beneficia más de una innovación que la misma empresa. Un orden promedio de 100% contra 15%. Interesante. Mansfield. Social return of innovation.

Casos de innovacion interesantes

  • Curvas S. Tapa roscas y PET. La curva negra vs la curva roja. Camaras kodak vs camaras digitales. Esto sería buenos casos para el taller de innovación.
  • En PEMEX no innovamos, somos seguidores. Ellos adoptaron una estrategia de bajo riesgo. En los últimos tres o cuatro años la estrategia de PEMEX ha cambiado.
  • El caso de Parral Chihuahua. "Yo nos soy maquilador". Había 300 empresas mineras proveedores de la industria minera. Se crea el campus de economía internacional de la UACH. Crea el CIDEIT quien recibió 2 millones de dolares del BID para reinventar Parral. En la mañana los chavos iban a clases y en la tarde daban consultoria en el CIDEIT. 20 chavos aprendieron a hacer proyectos desde el primer semestre de sus carrera y este equipo comenzó a transformar Parral. Manuel Parga murió. Pero estos 20 chavos formados fueron muy peleados en muchas instituciones. Al hacer un plan estratégico Parga... Primero invitaba a un historiador. De donde venimos, que tenemos y hacia a donde queremos ir. ¿Qué paso con los planes 20/20?La Universidad de lavall de Quebec tenia varios contratos de 20, 30 y 50 millones de pesos. Las Universidades si deben de ayudar a generar nuevos proyectos.
  • La Universidad de lavall de Quebec tenia varios contratos de 20, 30 y 50 millones de pesos. Las Universidades si deben de ayudar a generar nuevos proyectos.

    Como medimos la innovación

    • De entrada: inversión, patentes, personas que tenemos en innovación, maestros doctores, vinculados con quien, convenios de innovación.
    • De operación: proyectos vinculados, nuevas areas.
    • De salida: ingresos por nuevos proudctos, patentes. 

    Áreas de oportunidad / nuevos proyectos.

    • La número uno. Creo que el taller de TRIZ les sería mucho más útil a los empresarios que un taller de innovación general. También uno de kanban. Y por supuesto otro de Teoría de Restricciones.
    • Elodi dice que tienen que asesorarse para bajar recursos con empresas de Chihuahua. Y es muy complicado hacerlo por correo. La Oficina de Transferencia Tecnologica es una necesidad.
    • Crear un grupo que pueda desarollar proyectos para bajar fondos para convocatorias de innovación.
    • Hay muchas patentes que no están registradas en México. 
    • En Brasil, existe una empresa que compra patentes y su negocio es difundir esta información. Para aprovechar estas necesidades.

    ¿Quiénes asisten al taller?

    Elodi, productor de remolques para el sector minero, almazan productor de muebles, cementos cruz azul, periodico la jornada, Hasit, Acerca, Rodrigo Castañeda, Empresa total (consultores para la implantacion de Sistemas de Gestion de Calidad en PYMES), Monitoreo de Medios Electrónicos.
    Los intereses son variados, desde conseguir un consultor, fortalecer con el area de gestion de la innovacion sus sistemas de gestion de la calidad, implementarlo a areas agricolas.

    Algunas preguntas

    • ¿Cómo logro que los investigadores salgan a la calle a resolver problemas y que tengan un mayor impacto y trascendencia?
    • ¿Para innovar en una empresa cuantas personas o roles son necesarios?Hay un hacker, un operativo, un encargado de negocio y un diseñador. Un responsable de difundir informacion técnica. Muy interesante ejemplo de agencia rusa que clasificaba revistas y enviaba a todos los negocios del pais una lista de lo que les podia servir y luego ellos les enviaban la informacion. Según Arturo, un Godfather (defiendie a la innovacion de los contadores) o patrocinador, un investigador, un implementador, ingeniero creativo (doer). El administrador del proyecto. El que une la tecnología con la estrategia. El bridge person (reune capacidades de multiples disciplinas).

    Dinámicas 

    1¿Cuáles son los obstáculos par la innovación? En equipo definirlos. Y luego proponer soluciones a los problemas encontrados.
    • Ante directivas temerosas es bueno tener confianza con proyectos pequeños donde se invirtió, que se llaman quick hits. Los quick hits van aflojando las decisiones. Esos proyectos por su naturaleza no son espectaculares. Arriesgar poco para ganar poco. Formación de cuadros directivos. Los directivos deben de educarse para innovar.
    • Como conseguir dinero para proyectos de innovación. Debería apartarse un 3% de las ventas de la empresa. Elaborar proyectos de una buena manera.
    • Los inversionistas cuando aportan es por que se presenta un buen proyecto y además se tiene know how en el tema que se presenta. 
    • Como gestionar los riesgos de innovación. Inversión contra probabilidad de éxitos. No se trata de asumir riesgos a lo tonto. 
    • Falta de capacidad técnica. Una inversión constante sobre capacitación. Dominio especifico del tema por parte del personal. Podemos conseguir al experto mas experto en 2.5 llamadas. Capital humano existe en el país.

    Bibliografía

    • El profesor hace referencia los libros de Clayton Christensen. 
    • Difussion of innovations de Rogers. Como llevar la innovacion a la sociedad más pobre.

    miércoles, 15 de octubre de 2014

    Lo que aprendí hoy en proyecto con la industria. Claro en CIMAT.

    Alejandro, Arturo y su servidor, con chavos de la 8va generacion, estamos trabajando en varios proyectos. Esto es lo que aprendi hoy de la reunión del 15 de octubre del 2014.

    HERRAMIENTAS PARA HACER MOCKUPS
    1) Wirify es un software que sirve para obtener un template que permite obtener templates de una página. Crea un wireframe.
    2) http://pencil.evolus.vn/ es una herramienta utilizada por Janik, de Chamilo, para hacer templates. La idea de Luis y de Juanis es usar ambos para hacer los muckups.

    USO DE SCRUM
    En el tablero del equipo de badges, se juntaron muchísimas actividades en revisión, lo que le corresponde a Arturo. Entonces, hay que

    ¿QUÉ APRENDER?
    Leer sobre el check list manifesto, en un artículo de New Yorker. http://www.newyorker.com/magazine/2007/12/10/the-checklist

    COMO ESCRIBIR MEJOR. Asistiendo a talleres de escritura como...
    Hay un curso de Gramatica de la fantasia en el Museo de Zoquite para hacer cuentos. Es necesario desarrollar la habilidad de desarrollo.


    lunes, 13 de octubre de 2014

    ¿Cómo debería ser mi tesis de Doctorado de patrones de falla en proyectos de software?

    Bertran Meyer menciona que hay muchos material de proyectos fallidos de software y a pesar de ello la industria no ha mejorado. El Viejo me mando con una simple búsqueda de Amazon, que es cierto loa existencia de varios libros que hablan acerca de fracasos en la industria del Software. 

    Basado en esta idea realicé tres experimentos sencillos:


    1. Buscar en Google. Lo primero que encontré es esta presentación de Yourdon. Yourdon, padre del análisis estructurado, que luego evolucionó a un análisis orientado a objetos realizó una presentación en el JaSST de Japón en 2007, conferencia especializada en software testing. El nombre de sus presentación hace alusión a su libro “La marcha de la muerte (The death march)”. Dentro de su presentación habla de varios libros que tratan el tema de proyectos de software fallidos. A continuación una breve relación solamente de los que se refieren a proyectos fallidos de software: 1) “La marcha de la muerte” de Yourdon, 2) Software Sytems Falilure an Succes y Assessment and Control of Software risks, 3) Software Project Dynamics de Abdel-Hamid y Madrick, 4) Critical Chain de Goldratt and Demystifying the Black Art de McConell, 5) The Mythical Man Month the Brooks, 6) Software Project Survival Guide también de McConell.
    1. Buscar en Amazon.Lo primero que encontré fue: 1) In search of stupidity: over twenty years of high tech marketing disasters de Chapman, 2) Software runaways: monumental software disasters, 3) Why software gets in trouble (quality software book 2) de Weinberg.Lo que no existe son proyectos de software documentado en detalle, que permitan un análisis de causa raíz que se convierta en un estándar de la industria. Meyer, señala dos casos conocidos. En Amazon, me encontre algo fabuloso: “The Technical and Social History of Software Engineering”, donde en el índice, donde vienen 21 casos documentados, probablemente los únicos existentes, que permitirían identificar el porque de los proyectos fallidos de software. http://www.amazon.com/Technical-Social-History-Software-Engineering/dp/0321903420/ref=pd_ybh_1?tag=donations09-20(insertar imagen).
    1. Al final, busque en Google Scholar. Encontré estos libros: 1) http://mitpress.mit.edu/books/software-development-failures y este artículo muy interesante: Why software fails en la IEEE. Y eso solo buscando, y preguntando a profesionales de la industria.


    Persiste entonces la pregunta de Linda Levine y de Bertrand Meyer, “¿Por qué persisten los problemas en desarrollo de software y adquisiciones a pesar del hecho de que han existido desde hace mucho tiempo soluciones a estos problemas?”.

    “Einsteing dijo, “locura es siempre hacer lo mismo buscando resultados diferentes”. Lo que propone este anteproyecto de Doctorado puede ser resumido en dos sectores, con una plataforma común. PYMES a través del desarrollo de casos de negocio y su publicación en un observatorio de software, promoción de los materiales y prácticas que han hecho mejorar la industria, en el observatorio y una iniciativa de ley para que los proyectos que tengan que ver con TI y Sw sean públicos y analizados con el objeto de promover mejores prácticas. Si logramos esto contribuiremos a una mejor industria de software, con una solución baja en tecnología. Más social, más humana.

    Próximo post:
    1. Ver tres programas de MayDay de Nationa Geographic sobre accidentes en la industria aérea, documentar el patrón de análisis y establecerle como base.

    martes, 7 de octubre de 2014

    El Chaos Report. Hacia los lotes pequeños... y los métodos ágiles.

    Lesser fiery copper Lycaena thersamon (female).jpg
    "Lesser fiery copper Lycaena thersamon (female)" by Charlesjsharp - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

    Antecedentes del reporte

    Leí el reporte recomendado por Alejandro García el Viejo hace un par de semanas. Tal vez estoy demasiado influenciado por los métodos ágiles, pero creo que si mapeamos cada uno de los reportes tanto en los errores comúnmente cometidos, como en las mejores prácticas es muy probable que el uso de estos métodos este muy relacionado con la mayor parte de las razones de la mejora de la tasa de éxito en proyectos. Lo cual es una buena noticia.

    • El Chaos Report tien una base de datos casi de 50,000 proyectos. 60% de estos proyectos provienen de USA, 25% de Europa y el 15% de proyectos del resto del mundo.Un poco más del 50% de estos proyectos son de las top 1000, 30 por ciento de medianas empresas y 20% de PYMES. 39% de los proyectos tuvieron éxito, 43% no cumplieron con la meta inicial y 18% fallaron. Sin embargo la tasa es mayor que en 2009, ya que este año 29% de los proyectos fueron exitosos.
    • El incremento en la tasa de éxito se debe a varios factores, pero el principal es “el incremento en número de proyectos ágiles y pequeños”. Varias buenas prácticas están siendo utilizadas, como el hacer un análisis postmorten, más de 90% de organizaciones realizan esta práctica.
    • El punto de apalancamiento más importante para la mejora de la tasa de éxito es el “incremento de la competencia· del patrocinador ejecutivo o product owner, haciendo referencia a Scrum. Este rol se convierte en el “Chief enabling officer”. Siendo el principal catalizador del proyecto dentro de la compañía.
    • Más compañías enfocan en actividades que generan más valor, en lugar de enfocarse en la totalidad de los requerimientos.
    • El análisis del presente año sugiero que existe funcionalidad que no se utiliza que va desde el 20% del proyecto hasta el 50%!!!!! Aquí aplica la ley de Paretto. El 20% de la funcionalidad aporta el 80% del valor de producto. Reducir el alcance pues, según el reporte, no solo es una estrategia valida, sino “LA MÁS PRUDENTE”. Menos es más dirían nuestros amigos finlandeses.
    • Los proyectos ENORMES no son necesarios. La premisa es romper estos proyectos en mini proyectos. La propia portada del Chaos Manifest es una mafiosa, haciendo referencia al “efecto mariposa” que tiene un impacto...
    • PIENSA EN GRANDE, ACTUA EN PEQUEÑO.
    • La recomendación del Standish Group es “limitar el tamaño y la complejidad de un proyecto”, lo más que se pueda. La solución rápida podría ser no aceptar proyectos grandes, pero una más sensata es adoptar una serie de proyectos pequeños que contribuyan a una meta grande. Los proyectos frecuentemente son demasiados grandes para tener éxito.

    Factores de éxito y su ponderación para proyectos pequeños

    A continuación un análisis a detalle de cada uno de los factores que influyen en el éxito de los proyectos pequeños.
    1. Soporte ejecutivo (20 puntos). En proyectos pequeños el patrocinador puede ser un administrador de nivel medio o un producto owner haciendo referencia a SSCRUM. NO SE REQUIERE UN PLAN DETALLADO por ser un proyecto pequeño. La negociación es mínima. Un VISION STATEMENT de una o dos páginas es suficiente para que un proyecto sea aprobado o rechazado rápidamente. La habilidad que más impacta y que debe ser altamente dominada es IDENTIFICAR que motiva al equipo. FACTOR CRÍTICO: El 78% de los proyectos pequeños que están alineados con la estrategia de negocio, TIENEN ÉXITO.
    2. Participación del cliente (15 puntos). Los proyectos tienen el fin de construir un proceso, producto o servicio que la gente utilizará. Una pregunta importante sería, se ha identificado el valor que aportará este producto o servicio para ellos? El patrocinador debería ser un usuario primario que comprendiera perfectamente lo que el usuario final necesitará o sea un product owner. Los proyectos pequeños no rehuyeren un alto expertise por parte de los product owners debido al alcance y tamaño del proyecto. La falta de comunicación en un proyecto grande es mayor, un proyecto pequeño permite manejar esto de una manera más cómoda. FACTOR CRÍTICO: el identificar el expertise real en un usuario.
    3. Optimización (15 puntos). "Less is more". La esencia de un proyecto pequeño es un alcance pequeño, el tamaño hace realmente una diferencia en la tasa del éxito del proyecto. Como dice la ley de Paretto el 20% de la funcionalidad aporta el 80% del valor, por tal razón esta debe ser construida así. FACTOR CRÍTICO: contar con una lista de entregables determinados por el propio alcance del proyecto.
    4. Mano de obra calificada (13 puntos). Tener mano de obra calificada no solo permite una mayor probabilidad de éxito, sino que conduce a mejores costos. Cuando se agrega personal a un proyecto este tiende a retrasarse, descrito por la Ley de Brooks. FACTOR CRÍTICO: la mayor parte de los miembros del equipo de los proyectos analizados tienen un nivel que va de competente a talentoso o virtuoso. Solo un 10% de los participantes fueron evaluados como no competentes.
    5. Experiencia en gestión de proyectos (12 puntos). Debido a que los proyectos son pequeños, un administrador de proyectos puede administrar varios proyectos a la vez. FACTOR CRÍTICO: simplificar el procesos de gestión del proyecto para que pueda ejecutarse.
    6. Métodos ágiles (10 puntos). La solución universal para el fallo en proyectos de desarrollo de sw son los métodos ágiles que manejan naturalmente proyectos pequeños. Y que utilizan el desarrollo iterativo. LOS PROYECTOS QUE SON RIGIDOS TIENEN UNA ALTA PROBABILIDAD DE CANCELARSE. FACTOR CRITICO: El Product Owner es el rol responsable de la ejecución del proyecto.
    7. Objetivos claros (6 puntos). La claridad y el enfoque son esenciales para proyectos exitosos. Las standup meetings actúan como una junta de status del proyecto. Un enfoque ligero se centra en artículos de alto valor que mantienen la innovación sin sobrecargar administrativamente a la organización. FACTOR CRITICO: La comprensión de la visión de los stakeholders.
    8. Madurez emocional (5 puntos). La madurez emocional se relaciona con el autoconocimiento tanto personal como social, la auto administración y el manejo de relaciones. “Confía en tu equipo, pero revisa los resultados. -Ronald Reagan”. FACTOR CRITICO: En su mayoría, la gente percibe como no sinceras a las personas. Solo el 4% las considera sinceras.
    9. Ejecución (3 puntos). La ejecución es el arte de completar las actividades en función de un plan. Los proyectos pequeños dan la oportunidad al equipo de salirse de su zona de confort y tomar más riesgos. Los proyectos pequeños te permiten. Aun los proyectos pequeños tienen que terminarse en tiempo y medirse de manera adecuada.
    10. Herramientas e infraestructura (1 punto). Cuando se trata de infraestructura menos es más. Menos herramientas ayudan a los pequeños proyectos a terminarse más rápido. La cuestión más critica de este aspecto es la infraestructura y procesos estándar para proyectos pequeños. La filosofía de buscar siempre tener menos herramientas y utilizar servicios de nube. NOTA . El pasar de pocos proyectos de muchos millones a pocos proyectos puede incrementar el número de proyectos de manera exponencial. Hay un límite en la capacidad de gestión de proyectos de los equipos,

    En resumen

    En resumen, muy pocos proyectos grandes son exitosos. En cambio los proyectos pequeños tienen más del 70% de probabilidades de terminar en tiempo, con el presupuesto establecido y que cuentan con los requerimientos de más valor implementados. No es fácil pasar de macro proyectos a pequeños proyectos, de soluciones complejas a soluciones sencillas.

    Porque es útil este reporte para el anteproyecto de tesis

    • Existe una gran cantidad de información sobre buenas prácticas y sobre proyectos fallidos. El Chaos Report es una de las fuentes más citadas en cuanto al éxito y fracaso de proyectos de software se refiere. Es un reporte fundamental que debe ser considerado en este tipo de proyectos.
    • SCRUM mapa una buena parte de los 10 factores de éxito de una manera sencilla.
    • Si lo analizáramos con PSP es probable que también manejara ciertos aspectos.
    • Less is more, pero solo para los demás. En ocasiones reiteradas en el reporte se menciona el principio de “Less is more”. Sin embargo, cada uno de los factores de éxito mencionados en el reporte tiene otros 10 puntos críticos para el manejo de ese aspecto en particular. Al contrario que técnicas como Kanban con tres principios solamente, al final terminan siendo 100 principios que deben “gestionares” para incrementar la tasa de éxito de proyectos pequeños.
    • El Standish Group tiene una serie de herramientas y software para gestionar los factores de éxito detectados. Por lo cual dentro de varios de los puntos se menciona y se dan ejemplos de la interfaz del software sugerido para festinar el factor.

    Referencias