1. Dios, dame valor para cambiar lo que puede cambiarse; dame serenidad para aceptar lo que no puede cambiarse y dame sabiduría para distinguir lo uno de lo otro. Proverbio hindú.

2. Si no estás cometiendo errores, es probable que no estés haciendo nada. 3m la empresa que inventó el post-it cometiendo errores.

3. Si la velocidad de cambio en tu organización es menor que el ritmo de cambio de tu entorno, entonces tu fin está a la vista. Jack Welch

4. La ley del 80-15-5: De todo lo que sucede en nuestras vidas el 80% está fuera de nuesto control, el 15% está parcialmente en nuestro control, el 5% está totalmente en nuestro control. Cuando uno entienda esto será feliz el restante de su vida. Filosofía callejera oído en un restaurante de sushi.

De la British Computer Science, encontrado en el libro: “Project Management for Modern Information Systems“, de Dan Brandon:

1. Nuestros clientes realmente nos quieren, por lo que no les importa si nuestros productos se atrasan y no funcionan.

2. Sé que es un marco de administración de proyectos bien hecho, pero no lo puedo encontrar en medio del desorden en mi escritorio.

3. Todos nuestros proyectos son fáciles, y no tienen costos, programa de trabajo o riesgos técnicos.

4. La gestión de proyectos no es compatible con nuestra cultura, y la última cosa que necesitamos en este lugar es algún cambio.

5. No somos lo suficientemente inteligentes como para poner en práctica la gestión de proyectos, sin ahogar la creatividad y ofender a nuestros genios técnicos.

6. Tendríamos que entender los requerimientos de nuestros clientes y documentar una gran cantidad de cosas, lo que es una molestia.

7. La gestión de proyectos requiere integridad y valor, por lo que tendrían que pagarme más.

8. Nuestros jefes no proporcionarán el apoyo necesario para la gestión de proyectos; quieren que obtengamos mejores resultados por magia.

9. Tendríamos que aplicar ciegamente la gestión de proyecto a todos los proyectos independientemente de su tamaño y complejidad, lo que sería estúpido.

10. Pensamos que es más rentable tener un sobrecosto del 50% que pasar 10% del proyecto en resolverlo.

1. Alegría
2. Confusión
3. Desilusión
4. Búsqueda de los culpables
5. Castigo de los inocentes
6. Condecoración de los que no han participado

Les suena familiar?

Dicen que no hay nada peor que un pendejo con iniciativa?

Tal vez un pendejo que no le teme a nada. Este sí que es capaz de todo.

También dicen que el que no estorba ayuda.

En defensa de los pendejos con iniciativa diré que el que no ayuda es el que más estorba.

Consideren el siguiente escenario ficticio: en un proyecto grande de implementación de sistemas, tenemos de un lado un equipo completo de pendejos con iniciativa - al menos así parecen ser - y del otro, un equipo de usuarios con una fuerte resistencia al cambio.

El equipo de usuarios teme al cambio y a los nuevos sistemas más que a cualquier otra cosa. Han tenido en el pasado la experiencia de una implementación fallida, en la cual se tuvo que dedicar esfuerzo y tiempo a la implementación de un nuevo sistema, que nunca se utilizó realmente. Fue un desperdicio que terminó causando el despido y la salida de varios responsables.

Hoy ven esta nueva implementación como una imposición, una pérdida de tiempo, una distracción que pone en riesgo el mantener y llevar eficientemente su operación. También lo identifican como algo inútil que no va ni puede funcionar.

No quieren descuidar su operación que es su principal responsabilidad. Y no quieren involucrarse en un proyecto en el cual el que toma la iniciativa se quedará públicamente como uno de los responsables del fracaso del mismo.

El temor y la experiencia los llevan a la siguiente conclusión: “Mejor no participemos”.

Tienen una justificación para todo: Si se atrasan es porque el equipo de implementación no supo explicar bien la tarea, o que alguna otra área debe una información sin la cual no pueden avanzar. Si no se involucran es la culpa de la alta dirección de la compañía que no da al proyecto su correcta prioridad. El líder de proyecto es deficiente, no sabe comunicar correctamente, no sabe administrar el proyecto.

Sobre todo si cometieron algún error, este error fue inducido por la mala conducta del proyecto o por cualquier causa ajena a su trabajo. Es un sistema de defensa extremadamente elaborado y sin fallas.

Para cualquier atraso del proyecto existe una razón perfectamente lógica y sólida, que permite descartar su responsabilidad. Hasta cierto punto son argumentos difíciles de contradecir: el que nunca hace nada, nunca comete errores.

No hacer nada también brinda tiempo para observar e reportar los errores de los demás.

Les suena algo familiar? Cualquier semejanza con proyectos o personas de la vida real es una mera coincidencia.

En frente se encuentra nuestro equipo de pendejos con iniciativa. Delante los atrasos del proyecto toman acciones. Cuando falta alguna información, corren atrás. Empiezan a tomar responsabilidades del usuario, porque tienen compromiso hacia el proyecto y no quieren estar a expensas de los tiempos y excusas de los demás.

En este camino cometen errores y cuando alguna tarea se atrasa aparecen como los responsables, ya que efectivamente tomaran la responsabilidad de realizar estas tareas.

Quién finalmente va hacer que el proyecto se implemente exitosamente? Quién más aporta? El que critica inteligentemente a los demás pero se rehúsa a tomar cualquier responsabilidad o acción constructiva en el proyecto? O el que se arremanga, toma responsabilidades y acciones, y se abstiene de lanzar la primer piedra?

No tengo duda al respecto.

Es por esta misma razón que siempre es más importante una persona con la actitud correcta que una persona muy competente con una mala disposición. Contra la mala disposición no hay nada que se pueda hacer. Contra los errores se puede aprender de ellos, se puede brindar capacitación adonde hace falta, se puede implementar procesos con conllevan a mejores prácticas y mayor control de los proyectos. Adonde hay disposición, tenemos la mitad del camino recorrido.

Como está escrito en la biblia: “Afortunados los pobres de espíritu, que el reino de los cielos será de ellos”, no temo en afirmar: Afortunados los pendejos con iniciativa porque el reino de los proyectos exitosos será de ellos.

Google está ofreciendo trabajos en la luna. La broma no es nueva.

Encontré comentarios en la blogosfera con fecha del 2004 al 2006.

Lo malo es que solo contratan personas que residen en la tierra: “Applicants must be at least 18 years of age by April 1, 2007 and have proof of earth residency.”

Mucha gente que vive en la luna estaría interesado por este trabajo.

Acortaría sus tiempos diarios de traslado de la casa a la oficina.

Creo que si voy a postularme.

Aquí un increíble compendio de peores prácticas en administración de proyectos para desarrollo de software.

Pero analizándolo bien suena más como un conjunto de reglas universales para sobrevivir en la jungla:

Asshole Driven Development (ASD): Desarrollo Conducido por Penitente. Es cuando el mayor penitente toma las decisiones más importantes, y todos le siguen la corriente.

Cover Your Ass Engineering (CYAE): Consiste en enfocar todos sus esfuerzos en demostrar que los demás tienen la culpa. Cuando algo sale mal, busquen culpables en lugar de soluciones. Se recomienda utilizar esta metodología cuando nadie le va agradecer, o recompensar por resolver un problema (”es normal solo está haciendo su trabajo, para esto le pagamos”), pero que le harán responsable de cualquier error cometido en el intento de resolverlo (”que imbécil, como se le ocurre hacer esto”).

Not My Problem Approach (NMPA): Mejor conocido en México como el: “No es mi pedo”. Particularmente eficiente cuando se utiliza conjuntamente con CYAE. Además de trasladar la responsabilidad a otra persona, permite aumentar su eficiencia, eliminando tareas que pueden mermar su tiempo, y generar problemas innecesarios.

Ass Licking Management (ALM): Es la excepción a las dos reglas anteriores. Nunca emplear el CYAE o NMYA en contra de su superior. El jefe siempre tiene la razón, nunca comete errores. Se recomienda siempre halagar su jefe, sin importar que tantas tonterías haga. Cualquier iniciativa suya exitosa fue en realidad idea de su jefe. La excelencia en esta práctica se alcanza cuando su jefe realmente cree que las iniciativas exitosas son ideas de el. A partir de este momento el apoyará todas sus iniciativas. En caso de algún fracaso es importante recurrir a las reglas anteriores del CYAE o NMYA para no perder la confianza tan dura y justamente ganada.

YBG IBG: “You´ll be gone, I´ll be gone. So who cares”, aplica en condiciones extremas, en donde el tiempo promedio de sobrevivencia de los empleados no supera los 6 meses.

Que el que nunca empleó o pensó emplear ninguna de estas prácticas lance la primer pedrada.

Dos grandes actores en Internet, Google y Adobe, respectivamente con GEARS y AIR, sacaron una plataforma de desarrollo que permite hacer trabajar aplicaciones WEB localmente.

Google utilizará su plataforma GEARS para hacer que sus principales aplicaciones: google Docs & Spreadsheets, gmail, etc… estén accesibles fuera de línea.

Segundo David Girouard, Vicepresidente y Gerente General para Google’s enterprise business, citado por CIO magazine, este es el requerimiento más solicitado por potenciales clientes.

GEARS es una parte central en la estrategia de Google para penetrar el mundo corporativo, y en su competencia contra MICROSOFT, para proponer una alternativa a la suite OFFICE.

Bien para Google, pero que beneficios reales para los usuarios? David (otro David, no el de Google) se pregunta quien necesita tener Gmail en su desktop? El considera que estamos conectados en Internet el 90% del tiempo. Y que pronto estaremos en un mundo 100% conectado.

Nicholas Carr explica porque es tan importante hoy contar con estas plataformas.

Nos cuenta la historia del nacimiento de REUTERS, cuando la red telegráfica contenía áreas no cubiertas. Para cubrir tal espacio entre Bruxelas y Aachem (Alemaña), Reuters empezó su operación en los años 1830, como una empresa de palomas mensajeras, antes de transformarse una de las empresas telegráficas lideres a nivel mundial.

Para los usuarios y las empresas la adopción de estas plataformas significa no depender de su conexión Internet, o del servicio del proveedor, para poder estar trabajando sin interrupciones.

Reducir así los riesgos de indisponibilidad de cualquier aplicación crítica tiene un gran valor para cualquier negocio.

Se eliminaría la última barrera para la adopción masiva de aplicaciones Web dentro de las empresas, así como del uso de software-as-a-service (SaaS) en las mismas.

Hace mucho sentido ver Google ofrecer esta plataforma. Pero también corresponde a una tendencia de fondo del mercado de software.

Se habla mucho de virtualización. Estuve buscando definiciones y aplicaciones en Internet para entender mejor el concepto.

La definición más genérica es una tecnología que permite que varios recursos de TI aparezcan como 1 solo, o al contrario que 1 solo recurso actúe como varios.

La virtualización aplica para cualquier tipo de recurso: aplicativo (sistemas operativos, aplicaciones de negocio), estaciones de trabajo, centro de cómputo, etc…

Muy bien, pero de que sirve que un solo recurso de TI pueda actuar como varios, o que varios puedan operar como 1 solo?

Ahí les va algunas aplicaciones prácticas de uso de la virtualización:

Para estaciones de trabajo:

• Emuladores de software / sistemas operativos: Con emuladores de sistemas operativos podemos jugar a la Playstation 2 en un PC, podemos manejar tanto el Sisteme Operativo de Windows como el de Apple en los equipos MAC, o utilizar a la vez el SO Linux y el de WINDOWS en una misma estación de trabajo.

• Emuladores de hardware: Actualmente empresas pueden reemplazar sus estaciones de trabajo por terminales tontas. Las aplicaciones tipo Office, e-mail, ERP, están instalados en servidores centrales que contienen la capacidad de cómputo y de almacenamiento.

Viene con ciertas ventajas y desventajas:

• Mayor dependencia hacía las redes
• Mayor exigencia en disponibilidad de los servicios del centro de cómputo
• Menor costo de hardware
• Simplificación de la administración de la configuración y del mantenimiento de los equipos de usuarios
• Mejor seguridad, porque las terminales tontas están menos expuestas a virus - no tienen disco duro

En ambiente de centro de cómputo:

Este articulo del Diario TI contiene una explicación muy clara de los usos de la virtualización en el ámbito empresarial.

Para ambientes de desarrollo y pruebas: La virtualización permite tener en 1 solo equipo varios entornos de desarrollo o pruebas. En 2 o 3 equipos una empresa puede mantener 10 o 15 ambientes de desarrollo, aún que trabajen con diferentes sistemas operativos, bases de datos o lenguajes de programación.

Para DRPs (Disaster Recovery Plan ): En caso de falla de un servidor de producción, se puede levantar el mismo servicio en otro equipo, copiando una imagen del servidor de producción, en lugar del proceso más común de respaldo y restauración del ambiente. Hace el proceso más rápido, y no se requiere más tener equipos redundantes con las mismas características (marca, modelo, capacidades de CPU y almacenamiento, y sistema operativo).

Para consolidación de centro de cómputo: Las empresas están empezando también a usar la virtualización para consolidar sus centros de cómputo, e instalar en un solo equipo varias aplicaciones de negocio. Sin embargo este uso de virtualización para ambientes de producción todavía no ha sido adoptado por la mayoría de las empresas debido a algunos inconvenientes:

• Todavía no se considera maduro para aplicaciones que consumen muchos recursos máquina. Ej: ERP, aplicaciones de Intranet.
• Existen preocupaciones sobre tener varias aplicaciones de negocio en un mismo equipo ya que aumenta el impacto para el negocio en caso de indisponibilidad del hardware.

En el blog de DELL encontrarán un articulo que trata exactamente de esto.

Otros ejemplos de virtualización:

• Almacenamiento de datos: Los arreglos de disco RAID5 hace que varios discos duros estén funcionando de forma redundante, como si fueran un solo dispositivo de almacenamiento.
• Clusters de servidores: La carga de trabajo de los CPU de varios equipos está balanceada entre ellos, produciendo una mayor capacidad de procesamiento, simulando ser una super computadora.

Estos ejemplos son contrarios a los primeros mencionados porque tenemos aqui varios recursos de TI que operan como si fueran lógicamente 1 solo dispositivo de almacenamiento, o 1 solo servidor.

Cuando uno está a cargo de una área de sistema y es empleado:

Si obtiene resultados es algo normal. Nadie realmente lo nota. El reconocimiento es mínimo porque se considera actualmente que los sistemas deben de funcionar 24 horas, 365 días del año. Además solo está cumpliendo con su trabajo.

Cuando comete un error o pasa algún accidente es inaceptable. Pero existe una ventaja: aún que sus errores pueden hacer perder dinero al negocio, si no es una pérdida notable, usted no sufre consecuencias económicas directas. No le van a reducir su sueldo, tampoco lo van a despedir, por un error que no sea garrafal. Ahí parece que existe un mayor espacio para cometer errores y aprender de los mismos.

Cuando uno tiene su propio negocio:Por ser una persona externa a la organización a la cual está brindando servicio, cuando su aportación es notable, cuando uno hace las cosas bien tiene un reconocimiento real por su trabajo. Además esto genera dinero directa o indirectamente: más proyectos, mejores recomendaciones.Cuando comete un error o sufre un accidente pierde dinero y su responsabilidad está de por medio. Si comete un error garrafal no solo pierde el cliente, puede en algunos casos perder su camisa.

Entonces cual es la mejor opción? Sin lugar a dudas, si usted es capaz de vivir de su propio negocio, esta es la mejor opción. Hay más reconocimiento, hay más que ganar, tanto en aprendizaje como en dinero. Y no es tan evidente que es un camino más riesgoso, ya que actualmente no existe trabajo seguro.Entonces no lo duden más, abren su empresa de servicios de TI.

Neta significa verdad en Mexicano. Creo que no es una palabra española. Se lo dice un francés.

El otro día estuve observando el trabajo del help desk de mi empresa.

Encontré algunas netas:

1. Es de suma importancia que el personal de heldesk tenga excelente memoria porque atender o no una petición depende exactamente de que tan buena memoria tenga.

2. Cuando una petición no se resolvió correctamente con un “comentario en el pasillo” (método mejor difundido en la población mundial de usuarios para levantar peticiones), se resolverá por seguro dando el “grito en mitad del pasillo” (mejor práctica conocida a la fecha de escalación de peticiones).

3. Si el usuario no vuelve a quejarse, no importa lo que haya hecho o dejado de hacer para atender su petición, es que esta petición está resuelta y cerrada. (Mejor práctica en control de calidad)

4. La prioridad para atender a las peticiones depende de que usuario solicita y de como solicita, no del impacto o de las prioridades reales del negocio.

5. El personal del helpdesk parece nunca entender el problema real, por consecuencia también se tarda en identificar su causa, e implementar la solución.

En un futuro post les explicaré como descubrir estas netas sobre el soporte al usuario.

Sphere: Related Content