Algunas de las razones por las que fallan los proyectos de adquisiciones y desarrollo de Sw. Y cómo superarlas.

POR QUÉ ESTOY LEYENDO ESTO

Para comenzar el Doctorado, aquí un punto de inicio recomendado por mi tutor, José Arturo Mora es un trabajo realizado por el Linda Levine, investigadora del SEI en Carnegie Mellon.Un buen resumen de cada patrón puede encontrarse a continuación: http://www.sei.cmu.edu/acquisition/research/archetypes.cfm. El objetivo de este proyecto puede reflejarse en su slogan: “cambiar comportamientos anti productivos en adquisiciones bien hechas (una traducción literal)”.

Linda Levine utiliza el análisis sistémico y utiliza arquetipos. Los arquetipos sistémicos son patrones de comportamiento que se repiten en diferentes ámbitos (según Zenge, en la Quinta Disciplina). A continuación hago un resumen de cada uno de los arquetipos identificados por Linda y algunas reflexiones de a donde me puede llevar este trabajo y que necesito para poder determinar si me es útil en mi tesis de Doctorado o no. Por cierto, esto deberían leerlo en TODAS las áreas de adquisiciones de los Gobiernos.

ARQUETIPOS DE ADQUISICIONES

Arquetipo 1: Todo para todos. 

Una solución o plataforma general no funciona. “Las plataformas tratan de ser muchas cosas para mucha gente”. Estos proyectos generalmente fallan. Cuando se trata de quedar bien con todos la complejidad aumenta, las agendas se extienden, los costos crecen y nadie es feliz. Como dice el viejo dicho “el que sirve a dos amos con uno queda mal”. Lo mismo aplica para más de dos amos. Para romper el patrón no aceptar desarrollo de plataformas en periodos cortos, proveer incentivos para el uso de la plataforma, hacer un análisis costo beneficio y ser transparentes en los costos y beneficios del uso de la plataforma. http://resources.sei.cmu.edu/asset_files/WhitePaper/2009_019_001_29086.pdf 

Arquetipo 2: Alimentando a la vaca sagrada. 

Los proyectos de una vaca sagrada se sobre protegen independientemente de su éxito. Las decisiones en proyectos grandes y visibles se convierten de técnicas a políticamente defensivas con forme pasa el tiempo. Para romper este patrón se recomienda: promover la autocrítica con un proceso establecido y evaluar si se están cumpliendo las teas establecidas de manera periódica. http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=29215

Arquetipo 3: Apagafuegos. 

Cuando hay una cantidad impredecible de factores y variables para estimar exactamente el esfuerzo requerido. Para romper el patrón se recomienda no invertir en nuevas herramientas o procesos si ya se cuenta con una restricción, revisar la planeación es crítico sobre todo en fases tardías del desarrollo y no premiar a los desarrolladores por ser apagafuegos.

http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=29207

Arquetipo 4: Testear el sistema sin testearlo. 

En lugar de probar en un ambiente real, se prueba la aplicación en un ambiente controlado. Este problema surge cuando el sistema se utiliza en el mundo real. Para romper este patrón es necesario que existan los recursos para hacer un pruebas de ambiente real en la presencia de problemas reales además de probar el sistema en escenarios operacionales reales en lugar de hacerlo de manera funcional. http://acquisitions.sel.inf.uc3m.es/@api/deki/files/95/=happy.pdf

Arquetipo 5: Rotación de personal y stafff burnout. 

Este patrón puede identificarse por que la presión para cumplir las fechas obliga al personal a dedicar más horas y al final estar cansados y ser menos productivos. Si se mantiene de manera permanente este es causa de rotación de personal lo cual hace aún menos productivo al equipo de trabajo. Para romper este patrón es recomendable reducir el alcance del proyecto, ajustar la planeación o agregar persona. Sin embargo este puede ser contraproducente según la ley de Brooks. Para prevenir es mejor, buscando alternativas para que la presión no exista e invirtiendo en un ambiente de calidad para el equipo. http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=29129

Arquetipo 5: La ley de Brooks: “Agregar personal a un proyecto retrasado lo retrasa más”. 

Y básicamente lo retrasa por la distracción del equipo para capacitar o entrenar al nuevo personal y la necesidad de mayor esfuerzo para comunicarse con un número mayor de miembros del equipo. La contratación de más personal se realiza siguiendo la falacia de que se tendrá la misma productividad de inmediato. Entre más tarde se incorpora personal al proyecto es más probable que los efectos de la contratación sean negativos. Para romper el patrón, SÍ se puede añadir más personal pero lo más pronto posible, añadir poco personal, se puede añadir personal altamente calificado y finalmente cargar el personal al proyecto hasta que sea 100% productivo, lo cual no es posible frecuentemente. http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=28994

Arquetipo 6: Falta de confianza entre el contratista y el proveedor. 

En este caso el representante de gobierno presiona al proveedor porque no lo cree capaz y empieza a ponerle requisitos adicionales para sufragar la falta de confianza. Mientras que el proveedor siente que el gobierno no lo deja trabajar y cumple los requisitos pero protegiendo contra las demandas del proveedor sobreestimando los entregables. Al final el gobierno se da por vencido y acepta las fechas propuestas por el proveedor. Algunos de los disparadores de este patrón es que el proveedor no cumple con fechas de los entregables y por otra parte no acepta pequeñas modificaciones porque no son parte del contrato. Ala reacción es la retención de pagos por incumplimiento al proveedor de manera subjetiva. Para romper el patrón se debe de restablecer la confianza lo más pronto posible estableciendo los beneficios de tenerla y dejando claros los perjuicios y consecuencias de no hacerlo. Una manera de prevenirlo es lograr acuerdos pre matrimoniales y líneas claras de comunicación. http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=29211

Arquetipo 7: Sub costear el proyecto para ganarlo. 

Algunos proveedores que tienen acceso a información privilegiada ofrecer un precio para la subcontratación menor al costo del proyecto para ganarlo. Ya contratados buscan la manera con una revaluación de los entregables de que el precio se incremente. En México esto sería apelar al 30% de incremento del proyecto o buscar en el presente proyecto no salir tan mal pero establecer una buena relación con el cliente. Para romper el patrón, la oficina de contrataciones debería dejar en segundo lugar el criterio del precio, además de proveer una requerimiento de propuestas lo más claro posible y verificar con mucho detalle la propuesta del os proveedores, además de ser suspicaces durante la selección del proveedor independientemente de los estimados propuestos. Si ya se contrató un proyecto sub estimado lo mejor es rehacer el contrato inmediatamente o terminarlo. http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=29133

Arquetipo 8: Entre más largo más grande. 

Un proyecto largo requiere de mucho esfuerzo y mucho esfuerzo conduce a un tiempo mayor. Las condiciones van cambiando en el tiempo, la tecnología se vuelve obsoleta y los requerimientos pueden cambiar. Al ser proyectos tan largos, se tiende a sobre dimensional los entregables para protegerse. Para romper este patrón no se pueden ignorar las necesidades de los usuarios lo cual genera mayor esfuerzo y costo. La única manera sugerida es la prevención, dividir el proyecto en mini proyectos y finalmente el uso de prototipos puede aminorar el impacto de un proyecto fallido de este tipo. http://resources.sei.cmu.edu/asset_files/WhitePaper/2009_019_001_29060.pdf

Arquetipo 9: Quitarle a Pedro para darle a Juan. 

Cuando un proyecto no ejerce los recursos correspondientes, otros administradores que tengan la habilidad de gestionar recursos pueden obtener estos recursos para su proyectos en perjuicio del proyecto que sub ejercicio su presupuesto. Al momento de pagar lo ya presupuestado queda un boquete causado por el uso de fondos del proyecto para otro proyecto que generalmente estaba subestimado. Pero en lugar de castigar al que gasto de más, generalmente el programa que gasto de menos tiene menos presupuesto al año siguiente. http://resources.sei.cmu.edu/asset_files/WhitePaper/2009_019_001_29057.pdf

Preguntas después de leer los patrones de adquisiciones

• Aseveración: Muchas de estos patrones se rompen utilizando métodos ágiles. ¿Es cierto o estoy viciado por que me gustan?
• ¿Se puede evaluar con estos patrones los 21 casos que se han desarrollado y establecer una única causa-patrón para cada uno de ellos?
• ¿Está es la herramienta adecuada para comenzar a desarrollar la tesis?
• Aseveración: En general entiendo los diagramas causales, sin embargo es probable que si tengo que hacer uno sin ver no lo pueda hacer. Por tanto, habrá cursos o material adicional para profundizar en el tema.
• De la misma manera que la tesis de Agus, Linda Levine, después de hacer este trabajo que dejó en trabajo futuro? Buscar algún artículo escrito por ella al respecto. Esto que propone fue una tesis de Doctorado?

¿Qué artículos o estudios puedo escribir? 

Después de comentar los hallazgos de esta lectura.

• Validación del modelo de patrones de falla en adquisiciones en proyectos de software para PYMES en MEXICO.
• Propuesta de ley de adquisiciones basada en patrones de falla del SEI.
• Como los métodos ágiles contrarrestan los anti patrones de Linda Levine del SEI.
• CARACTERISTICAS DEL OBSERVATORIO DE PROYECTOS FALLIDOS DE SOFTWARE
• Un clasificador de problemas o de casos. No como una ontología de causas, efectos y soluciones, sino para saber cuando llega un caso saber donde clasificarlo.

¿Cómo hackear tu lectura? Imita a los que tienen buenos hábitos...

Cómo no obtener un buen libro.

Sacar libros de la biblioteca o ir a comprar a un librería es una mala idea. En la economía del conocimiento existe una mega oferta de libros y temas. Reitero, casi siempre es mala idea, al menos en mi caso, el tratar de seleccionar algún libro del estante de Walmart o de alguna librería. Aunque en ocasiones uno encuentra tesoros o buenas ofertas. En mi caso, después de 38 años he encontrado una manera de incrementar los libros que leo, siguiendo los consejos de los que saben.

Entonces, ¿cómo selecciono los libros que abonan más a mi formación?

He ido acumulando consejos de un lector profesional, y este en resumen de los tesoros que encontrado por seguir estas recomendaciones:

1. Primero que todo, contratar el servicio de Audible.com. Este servicio de Amazon, los primeros tres meses, meses de prueba, cuesta 7 dólares. Si el servicio te gusta hay varios esquemas, yo tengo contratado un crédito o un libro por mes. Para mí es suficiente. Escuchar un libro por mes me asegura por lo menos 12 libros al año! Y además prácticas tu Inglés.
2. Derek Sivers. Derek Sivers es un emprendedor nato y tiene un par de conferencias deTED que me agradan mucho. Derek tiene una relación de los libros que ha leído, que por cierto son más de 100. Esos libros tienen un ranking, de lo que más les gusto a lo que menos les gustó. Yo ya leí casi todos los de cinco estrellas y prácticamente ya forman parte de mis libros favoritos. De aquí saqué: "The five elementos of efective thinking". 
3. Recomendaciones de tus amigos. El Viejo me ha recomendado varios libros, ejemplo de ello son "The paradox of choice", "How education Works", The Toyota Way to Lean Leadership, por mencionar algunos.
4. Otra figura a seguir, Bill Gates. Gates tiene una costumbre muy padre. Durante sus vacaciones de verano, lleva una pila de libros y los lee todos en dos semanas. No se cuantos lee, pero los dos años más recientes ha publicado una lista de libros interesantes que también están en mi lista de recursos para seleccionar mi próximo libro para leer.
5. Otro gran consejo del Viejo. “Estudia al maestro, no a los alumnos”. Nuevamente, existen figuras que son referencias para el tema particular de estudio que nos llama la atención. Por ejemplo, en Ingeniería de Sofware el libro de “The Mythical Man Month” es obligatorio. Si Brooks, escribe otro libro, como es el caso, los Ingenieros de Software debemos leerlo. En el caso de Teoría de Restricciones, los libros o personas recomendados por Goldratt son referencias seguras de expertos en el tema.
6. Otro consejo del Viejo es, “si te gusta mucho una conferencia de TED. consigue el libro”. Ejemplo de libros leídos de conferencias o pláticas de TED son “The paradox of choice” y “Brain rules for kids”.
7. Una buena pregunta sería: ¿Cuál es el mejor libro que un programador debe leer? Aquí la respuesta: Code Complete. Pero además, una lista de los 100 libros que todo programador debe leer. http://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read. De la misma manera, habría que hacerse la pregunta para la profesión y el tema que estamos buscando. Claro, haciendole caso a los que tienen prestigio. 
8. Un consejo final, tomado de la filosofía de Gates, y que el Viejo aplica es. No leo literatura, porque quiero comprender al mundo. La literatura si vela en las películas. Aunque casi siempre un libro es mejor que una película, este lleva de 5 a 10 veces más en tiempo.

Impreso, contra digital en Kindle o de audio de Audible.

Esto depende del libro, o de la velocidad con que quiera terminar el libro. Si lo quiero terminar muy, muy rápido lo compro en los dos o tres formatos. Esto me ayuda a leerlo prácticamente donde esté. Esperando a alguien, yendo de camino en la camioneta o como lectura nocturna. Si quiero llevarlo despacio y tiene una narrativa ágil, con el audio es suficiente. Pero si el libro es muy bueno, vale la pena tenerlo también en físico. Si el libro lo quiero leer y no está en audio, lo compro en formato digital.

Los maestros inspiradores y las nuevas metas del Tec Campus Zacatecas.

El día de hoy se realizó una reunión de Planeación en el Tec de Monterrey. Me agradó mucho el conocer la misión del Tec de Monterrey. Estar dentro de las 100 mejores universidades del mundo para 2014 (LA VISION). Me gustó el interés demostrado en que el evento tuviera algo que ofrecer y aportar. El crédito lo tiene el nuevo ambiente promovido por el nuevo director del Tec, pero en especial creo que Gerardo Galaviz es una persona que desea que las cosas mejoren en el Tec.

En resumen, tuvimos varias pláticas, comenzando por nuestro Director, que nos dejó claro la misión del Tec en el mediano plazo: ser una de las mejores universidades del mundo, más concretamente, estar dentro de las primeras 100 para 2024. De la misma manera la secundaria Tec se propone ser la mejor del sistema Tec para dentro de tres años. En cuanto a profesional solo cuenta con la carrera de Licenciado en Desarrollo de Negocios, antes Licenciado en Administración de Empresas, pero con un enfoque más al emprendimiento.

Una de las dinámicas que me gustó, fue que tuvimos la oportunidad de platicar con alumnos sobre cómo es un maestro inspirador. Qué características tiene. En particular me sorprendió mucho el que los alumnos quieren que los profesores sean estrictos. La frase de Don Bosco de “Exigencia con amabilidad” no puede ser más adecuada.

Otra de las cosas buenas que el Tec está implementando es la retro continua para padres a través de un nuevo sistema. Don cada semana los padres podrán dar seguimiento respecto a las actividades realizadas por su hijo o hija, o no realizadas. En el kinder de mi hijo, en maternal, la maestra tenía una práctica parecida. Todos los días ponía en un papelito un mensaje para los padres sobre el comportamiento de cada niño. Estuvo alegre, participó, o estuvo triste, o se portó mal. Pero está pequeña retro es una herramienta para que los padres hablen con sus hijos a tiempo y detecten áreas de oportunidad.

Reitero el gusto por la creación de metas retadoras. Esto nos ayudará a crecer.

Y por cierto, mis maestros inspiradores son el Profesor Godoy y el Sr. Kasuga de Yakult.

¿Cómo mejorar la industria del Sw de manera sencilla?

De acuerdo al CHAOS Report 2012 el 43% de los proyectos son “Challenged” (fuera de tiempo, presupuesto, o alcance) y el 18% son cancelados. Y casi ninguno de estos fracasos es analizado. El no analizar estos errores impide que aprendamos, para no volver a cometerlos.

El transporte aéreo tiene una tasa de 0.05 muertes por cada mil millones de kilómetros recorridos. Es una industria que ha mejorado continuamente en la seguridad. El día de hoy es más segura que hace 20 años. Y la razón principal es que el 100% de los accidentes o averías importantes son analizados y convertidos a estándares de seguridad obligatorios. No sucede así en la industria del software. 

En su blog, Bertrand Meyer hace reflexiones contundentes sobre la diferencia entre las dos industrias. A pesar de que existen foros y sitios web que recopilan errores existen muy pocos analizados a profundidad, ejemplo de estos son: el caso de estudio de  Nancy Leveson sobre la Therac-25 y el análisis de Gilles Kahn sobre el accidente del Arian 5. Estos análisis son la excepción. Ambos casos han contribuido a un mejor entendimiento de la industria del software.

No existe una receta única para el éxito en los proyectos de software, generalizando, no existe una receta única para el éxito, como menciona Kough (2011),  “después de una vida en los negocios no puedo dar una receta del éxito, Lo que puedo hacer es hablar acerca de cómo perder. Y garantizo que cualquiera que siga esta fórmula será un perdedor seguro“. El detectar las causas de los fallos y evitarlas asegura en consecuencia mejores resultados. 

Patrick Eha (2012)  hace referencia a la pérdida de 440 millones de dólares por un error en un sistema automático de trading en Nueva York. Pero en ningún lugar se menciona cuales fueron las causas. El análisis sistemático de estos errores podría detectar causas clave: capacidad de los desarrolladores, métodos de calidad poco estrictos, procesos de seguridad deficientes. 

Existen muchas maneras de contribuir a la mejora de la industria del software, la investigación sobre temas de avanzada es una de ellas; Meyer(2009) enfatiza que la manera práctica, de baja tecnología es “ aprobar una ley que obligue a analizar de manera profesional cualquier fallo en un proyecto de software”. 

De inicio hay varias restricciones que deben ser consideradas: la iniciativa privada es renuente a hacer públicas sus fallas, por cuidar el prestigio de su empresa. La hipótesis es que una ley general a nivel nacional o estatal que requiera que analicen los proyectos de software implica cabildeo legislativo y una gran cantidad de recursos. Pero de inicio, los proyectos finalizados que tengan como fuente de financiamiento en México son públicos por la propia Ley Federal de Transparencia o sus equivalentes en los estados de la República. Estos proyectos pueden ser un inicio. Este sería el enfoque top down.

Planeamos hacerlo de otra manera. El desarrollo de casos de negocio basado en proyectos reales de software, así como la recopilación de artículos y bibliografía existentes sobre proyectos fallidos de software y la construcción de un observatorio de estos proyectos fallidos pueden contribuir para el conocimiento real. 

Casi cuarenta años después de la publicación del Mythical Man Month de Frederick Brooks seguimos fallando de la misma manera. Existen varias fuentes de información relacionadas con proyectos fallidos de software: libros, artículos, algunos análisis profundos de fallos en la industria del software en proyectos costosos o críticos a nivel mundial. Pero está información no está disponible para la industria del software de manera directa. Ello hace necesaria un mecanismo para la promoción de los aprendizajes obtenidos del análisis de proyectos fallidos. 

Un mecanismo para ello, puede ser la Gestión del Conocimiento puede proveer la base para que está información esté consolidada en un solo lugar y la creación de un Observatorio de Proyectos de Software Fallidos. Siendo una buena idea en el contexto Mundial, el propio contexto de México y Latino América, donde existe una gran cantidad de PYMES que desarrollan software y que cometen errores en su propio contexto requiere un análisis profundo de fallos de software en este nivel. Así pues el alcance se reduce y es más real. 

Referencias:

• Meyer, Bertrand (2009, Agosto). The one sure way to advance software engineering. Blog post consultado el 30 de julio de 2014 de http://bertrandmeyer.com/2009/08/21/the-one-sure-way-to-advance-software-engineering/
• Meyer, Bertand (2010, Mayo).  Analyzing Software Failure. Blog post consultado el 30 de julio de 2014 de http://bertrandmeyer.com/2010/05/24/analyzing-a-software-failur
• Patrick Eha, Bryan (2012, Agosto). Los errores informáticos más costosos. Artículo electrónico consultado el 30 de julio de 2014 de http://www.cnnexpansion.com/economia/2012/08/10/los-errores-informaticos-mas-costosos

Estrategia para crear credibilidad en un nicho de mercado. Convertirte el experto en ese nicho...

Este es el plan que debemos de seguir para promover los servicios de un producto en un nicho especializado y crear credibilidad. No hay que pegarle a todo. (De los clásicos de El Viejo).

1. Desarrollo de presencia Web. Hasta aquí la idea va bien....

2. Crear catálogo de productos y servicios. Pero es página debe tener un catálogo de producto y servicios...

3. Escribir artículos y prensa relacionada con el servicio...

4. Dar conferencias en reuniones de tecnología... 

5. Ofrecer un boletín mensual. Ir recopilando una lista de correos e interesados...

6. Construir un sistema proactivo de referencias para el mercado meta...

7. Crear una base de datos de prospectos. ..

8. Recopilar casos de éxito y opiniones del líderes en el nicho de mercado elegido...

9. Competir en licitaciones, pero solamente las del nicho de mercado...

Neithlich (Octuber, 2003). Word Domination for Small Web Businesses. Artículo electrónico consultado

el 15 de febrero de 2013 de http://www.sitepoint.com/small-web-businesses/

Conversaciones con el viejo: Sistemas distribuidos y maximizadores vs satisfacidores

1) Cómo debería ser la clase de Artefactos de Software. 

El objetivo de esta clase en la Maestría en Ingeniería de Sofware es hacer Sistemas Distribuidos. En la clase en video se hace con CORBA, un curso que tiene más de 10 años. Ahora se hacen con Erlang. Sin embargo existen otras alternativas como Google Go.

Como introducción del curso

Ensayo de 4 hojas de arquitecturas de software open source. Libro open source por supuesto.
Curso de Google de Sistemas distribuidos. Falta link aquí:
Las ocho falacias de los sistemas distribuidos: http://aosabook.org/en/distsys.html

2) La diferencia entre cómputo distribuido y sistemas distribuidos.

El cómputo distribuido para buscar vida extraterrestre es un ejemplo de cómputo distribuido.
Los sistemas distribuidos para consultar la CURP, por ejemplo, son un ejemplo de sistemas distribuidos. El curso de Artefactos de Software está enfocado en el desarrollo de sistemas distribuidos.

3) Maximaicers vs satisficers

Los maximicers buscan la mejor en cada aspectos de su vida, los satisfacers establecen criterios y si una solución cumple con ello, se quedan con ella, aunque pueda haber otras mejores. The paradox of choice, no está tan bueno.
“… research shows that maximization is negatively related to happiness, optimism, self-esteem, and life satisfaction, and positively associated depression, perfectionism, and regret. This means picking the best option does not come with being happy or satified with the decision”… Aquí el link: http://www.setsailcoaching.com/maximizing-vs-satisficing-how-happy-are-you-with-your-decisions

Video de TED sobre lo importante de la retroalimentación en el trabajo. Link en Facebook: http://www.ted.com/talks/dan_ariely_what_makes_us_feel_good_about_our_work.html
Experimento de hacer sopas de letras y pago con 50 centavos.
Cuando se reconoce el trabajo es más probable que se logre mayor cantidad de ejercicios de sopa de letra realizados, contra pagados pero sin retroalimentación positiva.

4) Las metas del año.

En 43 things, un sitio Web para crear redes de apoyo en torno a metas particulares, el viejo tiene registradas algunas de las suyas. En particular este año no he hecho la reflexión sobre lo que quiero lograr. Pero primero Dios será:
1) La consolidación de la Maestría en Ingeniería de Software.
2) El ofrecer cursos particulares en cuestiones de capacitación de maestros y de micro y pequeños empresarios en métodos ágiles y teoría de restricciones.
3) El escribir 1000 palabras diarias durante 365 días.
4) El correr 2 veces a la semana y nadar 3. Para un total de 5 días haciendo ejercicio.
5) El entrenar a un equipo de voleibol o fútbol de niños.

5) Alternativas de tesis para maestría y doctorado. 

Alineados con el interés de desarrollo de ingenieros.Una maestría en matemáticas que tendría como tesis un curso en coursera con haskell por ejemplo. Un Doctorado en Educación que tendría como tesis el programa de preparatoria con sólo materias que incluyeran herramientas de software como recursos didácticos. Un programa así, podría ser una fuente valiosa con alternativas para materias en particular y como referencia de otros programas. Sin embargo, otra alternativa recortada, donde pudieran implementares estos cambios tal vez generaría valor y pudiera dar pie al programa completo.
Una materia para enseñar física, tiene un libro gratuito y un lenguaje de programación para enseñar mecánica (cuál es el link). Otra idea del viejo es utilizar videojuegos para las clases de historia, como el “Medal of honor”.

6) Como se podría motivar a empleados del conocimiento.

Cuando existe mucho control y falta de tiempo para realizar actividades importantes para trabajadores del conocimiento, como ingenieros de software es probable que exista desmotivación. Algunas alternativas para cambiar esto son el uso de tiempos flexibles, para que los ingenieros puedan realizar actividades personales y otra es desarrollo de personal. Así a través de expertos o de certificaciones en particular. El programa de la Maestría en Ingeniería de Sofware del CIMAT es una alternativa para desarrollar la “Maestría” requerida por los ingenieros de software. El “Control” se realizaría a través de la aportación de los Ingenieros a un tiempo personal. El propósito, el para qué, solo puede ser alcanzado cuando se persigue una meta valiosa. Pero el compartir la visión no es un asunto sencillo.
Agregar video de motivación de los trabajadores del conocimiento.

7) Planeación de la Maestría.

El año pasado intentamos llevar menos clases simultáneas. En un experimento Alejando llevó una clase en 2 meses y otra clase en otros 2 meses. A diferencia de llevar 2 clases los cuatro meses seguidos. Esto con el objeto de enfocarse en un solo tema durante 2 meses. El semestre que estamos llevando teníamos la intención de realizar lo mismo. Sin embargo, debido a restricciones de los horarios del los propios maestros no pudimos hacerlos.

8) Los proyectos con la industria del semestre enero mayo 2014 de la Maestría en Ingeniería de Software.

• Traducir los libros de Monash Universitiy. 
• Herramienta para evaluar los requerimientos en base la dificultad y el valor que aportan con árboles AVL.
• Traducción de diseño de sitios web en photoshop a maqueado html en wordpress para vender en theme forrest.
• Traducción de libro de desarrollo de una herramienta de redes sociales de PHP. Haciendo ejercicio con NEO4J.

9) Otros proyectos para el presente semestre.

• Startup Weekend para Clúster Minero.
• Internado de los alumnos en empresas del extranjero con el objeto de quedarse a trabajar ahí.
• El seguimiento de la materia de inglés, para que todos tengan 500 puntos en el TOEFL. Pedir al centro de idiomas un examen de evaluación general para todos los alumnos de maestría.

El estar en gobierno es como estar becado. Algunos aprovechan la beca y otros no.

El trabajo en el sector público es una oportunidad para aprender y desarrollarte. Pero no todas las personas lo entienden. Cuando entré a trabajar en Oficialía Mayor en Gobierno del Estado de Zacatecas, por ahí a inicios de 2002. Mi entonces jefe Pedro Carrera, me dijo que "lo bueno de trabajar en gobierno, es que para donde quiera que volteas es un área de oportunidad". Eduardo Gómez me dijo una vez: "El estar en gobierno es como estar becado. Algunos aprovechan la beca y otros no". Una conocida me platicó que trabaja en una dependencia en la que se la pasan viendo películas todo el día. Ese es su trabajo. Mi recomendación fue, pues aprovecha para estudiar algo. Una maestría, una especialidad en línea, un Doctorado. Por eso recordé la frase de Gómez… Mi paso por gobierno fue una beca, que creo que aproveche.

Primera etapa: 
De 2002 a 2004. Administración de Ricardo Monreal. Oficial Mayor, Soledad Luévano. Sub oficial y mi jefe directo: Pedro Carrera.

Aproveche: seguir mi Maestría en TI, aprendí del sector público, desarrolle aplicaciones cliente servidore para facilitarle la vida a él área de Recursos Materiales y también de recursos humanos. 

Al entrar a Oficialía Mayor, que no sabía que era en un principio, me di a la tarea de conocer el 100% de las áreas y las visite físicamente. Fui el primer Ingeniero en Sistemas que trabajó en la Dependencia. Entre el 2001 con un alcance de toda la organización. La entonces área de recursos materiales en ese momento contaba con dos ingenieros en sistemas, encargados de administrar la información de compras y como apoyo del área. 

Aquí desarrolle algunas aplicaciones, un sistema cliente servidor para llevar el control de inventario de la organización. Un sistema cliente servidor para llevar el control de gastos de la organización. Y me empece a encargar de la "planeación operativa" de la organización. Fui enviado a capacitarme en indicadores y en Programas Operativos anuales. Ahí me di cuenta, por ejemplo, que la información se copiaba prácticamente igual en todas las áreas, pero no se cumplían las metas. En una buena parte, porque no había presupuesto para todas las buenas intenciones planteadas.

Al final de la administración, me corresponde integrar la información de activos de la organización. Ya que es una atribución de la dependencia. Además me toca colaborar con el equipo de entrega recepción. Al cuál apoyamos brindándoles la información necesaria para hacer una transición suave. 

En esta etapa, tengo la fortuna de contar con el apoyo de Luz del Carmen Navarro. Y el departamento de informática de 1 persona, se convirtió en dos personas. Aquí, Luz realiza el primer sistema para requisiciones Web. Y es cuando empiezo a colaborar con Juan Hernández. En ese entonces Jefe del Departamento de Redes de Oficialía Mayor. 

En esta etapa también, nos toca compartir oficina con la Señora Lupita Murillo, responsable de Recursos Humanos de la organización. Ella es invitada por Pedro Carrera. Y su tarea es hacer el Manual de Organización de la Dependencia. Gracias a la colaboración con ella, empiezo a trabajar también en el área de recursos humanos. Y empezamos a leer sobre el servicio profesional de carrera. Les comienzo a ayudar a revisar reglamentos para ello. Esta iniciativa se queda en papel. Pero me da entrada para una posterior colaboración en este tema posteriormente.

Desde que estuve en Cerveza Corona de Zacatecas, comencé a estudiar la Maestría en Administración de Tecnologías de Información. Y fui avanzando hasta terminarla en 2005.

Segunda etapa:

Cambio de Administración. La Lic. Amalia García Medina se vuelve gobernadora. Y es nombrado Oficial Mayor al Lic. Mario Espinoza. Realmente el Lic. Mario estaba enfocado en el trabajo. Muy trabajador el Señor. Pero dedicaba poco tiempo a la Dirección de la Dependencia. Cómo el ritmo de trabajo era bajo tuve oportunidad de hacer otras cosas.

Aproveche: Trabaje con los directores de informática más proactivos de las diferentes dependencias de gobierno, que hoy son buenos amigos: Juan Hernández, Heriberto Hernández, Roberto Navía, Gerardo López y Carlos Martell y trabajamos en algunos proyectos de modernización de la Contraloría Interna. Este trabajo en equipo redundó en varios proyectos exitosos como los cajeros electrónicos o kioscos, el proyecto de licencias y la red WAN de gobierno del estado o red gubernamental (en este contribuí poco). Y además…

Asistí a varios eventos relacionados con Informática e Innovación del Sector Público entre ellas a varias reuniones del CIAPEM (México D.F., Monterrey, Morelia, en el mismo Zacatecas, Colima). Para el proyecto de cajeros electrónicos visité Culiacán, mientras que otros directores fueron a Chiapas. Los estados con experiencia interesante en esos momentos en kioscos electrónicos. Coordine el proyecto en Zacatecas. Hicimos toda la gestión para que pudiera llevarse a cabo la subcontratación del procesos de negocio o BPO de expedición de licencia de manejo por un tercero. Además seguí trabajando en la elaboración de Programas Operativos Anuales de la Dependencia y asistiendo a estas reuniones. Cómo se mecanografía, fui el mecanógrafo de manuales, reglamentos de la dependencia y propuestas de ley para el servicio civil de carrera en Zacatecas junto a la Sra. Lupita Murillo. En el área de cómputo nos dedicamos a dar servicio y establecimos un proceso sencillo para llevar control de este servicio que se ofrecía no solo a la Oficialía Mayor, sino a diferentes dependencias de gobierno. Apoyamos en el desarrollo en conjunto con un despacho externo para el área de adquisiciones con una herramienta llamada adquisinet y la implementamos en para hacer requisiciones de manera centralizada en Oficialía Mayor. Inicie la Maestría en Ingeniería de Software, que por motivos personales tuve que dejar. El área de informática se convirtió en Unidad de Informática formalmente y pasó de 3 personas a más de 10, la mayoría en el proyecto de mantenimiento de equipo de cómputo.

Tercera etapa:

Cambio de Oficial Mayor. En la segunda parte de la Administración de la Lic. Amalia García Medina el Lic. Eduardo Ruiz Fierro es nombrado Oficial Mayor. El Lic. Ruiz, economista, con una visión completamente diferente de la Administración. Aquí soy ubicado por el Lic. Ruiz en una nueva dirección. La Dirección de Innovación y Competitividad Gubernamental. Aquí también se crea la Dirección de Informática.

Aproveche: Estudie una segunda Maestría en Innovación para el Desarrollo Empresarial, pues el gobierno apoyó con becas para mujeres y hombres en maestrías en línea del Tec de Monterrey. Establecí procesos del área de innovación. Colaboré en la implementación de Sistemas de Gestión de Calidad de la propia Oficialía Mayor, el Instituto Estatal de Migración y la Junta de Conciliación y Arbitraje. Además desarrollamos un método para priorización de proyectos, un modelo y propuesta de re ingeniería para las dependencias. Hicimos varios proyectos para echar a andar Ciudad Gobierno, ahora Ciudad Administrativa. Y me especialicé en modelos de Gestión del Sector Público. Seguí con mi capacitación y tomé dos cursos en CEPAL en Chile de Evaluación del Impacto en Sector Público y Gestión del Gasto Público.

Al fin es recomendable aprovechar la beca...

En fin, creo que fueron 10 años en los que conocí a mucha gente y participé en muchos proyectos que me hicieron comprender como funciona el Sector Público. Cuando me dicen que se la pasan viendo películas, no puedo más que pensar en todo lo que podría hacer yo con esa beca. Hay personas que podrían hacer más. Pero definitivamente no se puede tomar una actitud pasiva ante la vida. Debemos ser proactivos. Si te dan todo este tiempo, se puede utilizar en crear capital para el próximo proyecto que enfrentemos y no solamente “dormir el sueño de los justos”.