Vocabulario

common terms used by Project Managers and other people within a project

Cortesía

"Porque, cada vez más, la mala educación, la ausencia total del respeto a las mínimas normas de cortesía, la carencia de formas y la desaparición de una etiqueta en las relaciones laborales se están imponiendo.

Da lo mismo que nos citen a las diez. Aparecemos a las once, ya que lo elegante es llegar tarde y que el otro espere. Si escriben solicitándote alguna información, o invitándote a un acto comercial o social, ¿para qué contestar agradeciendo la invitación y excusando nuestra imposible asistencia?, ¿para qué confirmar por mucho que lo diga la invitación? Si voy, voy; y si no lo hago, más pierde el que invita. Si llaman por teléfono, cuanto más difícil sea dar con uno, más importante parece, y más tratan de localizarle. "

Artículo La mala educación en Expansionyempleo

Añado a esta lista otra: Mañana sin falta te envío por mail esa información. Y ese mañana ya puede ser dentro de una semana o nunca en el caso que no se reclame por activa y pasiva esos documentos.

Se nota la diferencia a la hora de trabajar cuando existen las mínimas normas de cortesía, al fin y al cabo indican un respeto hacia los demás y en el fondo hacia uno mismo.

Estimaciones optimistas

El artículo Symptoms & Sources (registro free) trata sobre los síntomas y el origen más frecuente de los problemas y los riesgos que pueden surgir durante el desarrollo de un proyecto. Cualquier persona que haya leído sobre este tema - gestión de proyectos y temas relacionados - está cansada de leer lo mismo. Este artículo tampoco nos aporta nada que no conozcamos; otra cosa es que seamos conscientes de estas cuestiones en el día a día. Así que hoy, a modo de recordatorio me quedo con el siguiente párrafo:

"Planning for the best case.This can be an example of misplaced optimism. Project planning assumes that everything will go according to plan. No contingency is left for things to go wrong. Tasks are estimated with best-case scenarios. This is an example of team members believing that they always do things right the first time because they are the best but they don't realize that mistakes do occur and new factors do emerge. Good management is the ability to respond to these factors."

Soluciones

Una solución buena no vale de nada, sino conduce a resolver el verdadero problema.

Puede parecer una obviedad pero en muchos proyectos está situación es bastante frecuente.

Identificar correctamente el problema no es tarea sencilla. En la mayoría de las situaciones a las que nos enfrentamos existen otros elementos que nos distraen y nos impide determinar el verdadero problema.

Gestión proyectos & weblogs

Considero que un blog es una herramienta que nos permite llevar una registro de un proyecto de forma poco costosa tanto en tiempo, esfuerzo y dinero. Por supuesto que existen otras herramientas con muchísimas funcionalidades, sin embargo debemos ser realistas aparte de la inversión económica, muchas veces son excesivamente complejas. En algunas ocasiones el tener demasiadas funcionalidades las convierte en poco prácticas y al final sólo se utilizan si es obligatorio pero siempre tarde y mal.

La utilización de un blog presenta una curva de aprendizaje cero y escaso coste. Es una forma de comunicarse entre todos los miembros del equipo, aunque sólo el blog lo utilicé el gestor (coordinador, responsable) del proyecto, permite que todo el equipo tenga una visión del proyecto. Mediante hipervínculos se puede hacer referencia a los documentos que se van generando. La creación de diferente categorías - por ejemplo: administración, requerimientos, análisis, modificación, incidencia, pruebas - nos permite tener todo registrado (fecha, hora, autor) y clasificado siendo mucho más sencillo el seguimiento. Por otra parte el historial del proyecto se genera automáticamente y permite generar fácilmente las conclusiones de cierre de proyecto.

Personalmente me parece muy útil principalmente porque el esfuerzo por mantenerlo es poco en comparación con las ventajas que aporta al proyecto.

Reconozco que muchas personas consideran los blog como muy simples y les parecerá ridículo, infantil emplear esta herramienta. Si lo sé, decir que utilizas un blog para gestionar los proyectos o parte de estos no vende.

El motivo de esta reflexión Using weblogs to manage project change

La tiranía del correo electrónico

"Email is one of the greatest things the computer revolution has done for personal productivity. Used improperly, it can also hurt your productivity."

En el artículo se dan una serie de normas para evitar la tirania del correo electrónico.

+ Turn your email client off. Pick the moment at which you'll be interrupted.

Fundamental. Tengo la opción automática de recibir correo, del Outlook, desactivada. Es un elemento de distracción innecesario. Es casi inevitable consultar la bandeja de entrada, cuando se muestra el icono de aviso de recepción de mensajes en la esquina derecha inferior de la pantalla (ni contar si lo tienes con sonido, insufrible).

+ Never criticize anyone in email, and avoid technical debates. Use face-to-face meetings or 'phone calls instead.

La primera parte es obvia, no es el medio más adecuado para realizar críticas o señalar algún aspecto negativo. En la segunda parte – evitar detabes - tengo mis dudas, en el artículo se referiere a debates largos y considera que se puede llegar a polarizar el debate con diferentes frentes. Me imagino que depende del tema a tratar, de las personas implicadas, de si hay o no moderador.

+ Be judicious in who you send email to, and who you copy on emails.

Cierto, a veces enviamos (o recibimos) demasiadas copias de emails (opción CC) a personas que el asunto les cae de manera tangencial. Muchas veces creo que se hace con el objetivo de protegernos, pero la consecuencia son buzones hasta arriba e incluso un cruce de correos innecesarios. Es mejor enviar copias (CC) cuando se solicitan de manera explícita. Las copias ocultas, personalmente no me parecen correctas; quizá existan casos en los que este justificada enviar copias ocultas pero no lo contemplo.

+ Observing some formality is important.

Importante, no sólo con revisar la ortográfica y sintaxis sino la estética y organización del mensaje.

Se observa como empresas gastan mucho dinero en su imagen corporativa, y después se olvidan que la mayoría de los empleados se relacionen con clientes, proveedores, colaboradores a través del correo electrónico. Entonces se suele dar el caso que mientras recibes correos estándar todo perfecto, en el momento que existe una intereracción personalizada se acabo la magia. Y es que hay muchas más personas en una empresa que se relacionan vía correo electrónico con el exterior de lo que a priori se puede pensar como para no tener manual, normas de estilo y controlar la calidad de los correos.

+ Don't hesitate to review and revise important emails.

Esto me parece de una obviedad.

+ Remember that email is a public and permanent record.

Este punto enlaza con el número de copias a quién se envía el correo si en un futuro existe algún problema siempre puedes consultar tu registro de emails y enviarlo.


Para mí faltaría apuntar que es necesario que tengamos en cuenta que el correo electrónico es un medio de comunicación asíncrono y en muchas ocasiones parece que se quiere emplear como síncrono cuando para eso tenemos otros medios.

Si empleo el correo electrónico como medio para comunicarme no pretendo tener una respuesta inmediata porque para eso tengo el teléfono o utilizo una aplicación de mensajería instantánea o el encuentro personal.

Observo que en algunos estudios de mercado en el que se realizan valoraciones del servicio de una empresa, se le da demasiada importancia (con esto no quiero decir que no la tenga) al tiempo de respuesta al correo electrónico enviado. Y dentro de un intervalo de tiempo en este caso es más importante la calidad de la respuesta.

Si escribo para solicitar información sobre un producto / servicio o cualquier cuestión (reclamación, queja) me parece que la respuesta debería ser en menos de 24 horas. Pero no me puedo quejar si no me han contestado a los 10 minutos porque para eso llamo por teléfono. A menor tiempo la probabilidad de recibir una respuesta estándar es mucho mayor, vamos que copian y pegan lo que hay en su web. Con un poco mas de tiempo creo que pueden darme una respuesta más personalizada, yo entiendo que si envío un correo es porque la información que tienen disponible públicamente no me ha servido y necesito algo más específico, personalizado.

Parece que se olvida la diferencia entre inmediato y unas horas.

Estrategias oblicuas

Las estrategias oblicuas es una técnica que mediante la utilización de una baraja de cartas diseñadas con unas instrucciones permiten introducir elementos al azar en el proceso de creativo. Sus creadores Brian Eno (músico) y Peter Schmidt (pintor).

Supongamos que estamos buscando una solución, una idea y en un momento dado nos quedamos atascados entonces seleccionamos una carta y seguimos sus instrucciones; es una forma de liberar nuestra mente. Algunas de las propuestas de estas cartas hay que interpretarlas [digo yo] dependiendo de lo que se esta haciendo sin embargo es una solución para despejar la mete.

Ahora tenemos estas cartas en flash

Enlaces en donde se explica todo esto con bastante mas detalle.

Lista de las instrucciones || Site ObliqueStrategies

Modas

Ayer en el periódico Expansión en su suplemento digital se hacía un resumen del IT Forum organizado por Accenture y contaba con la participación de responsables de tecnologías de la información de importantes empresas Españolas; en esta jornada también se presento el Estudio de costes de tecnologías de la información España 2003 ( me gustaría tenerlo, tengo que buscarlo). El periódico señala que los participantes coincidieron que la optimización de los costes y la rentabilización de los activos tecnológicos han sido una de las prioridades en sus empresas en el último año. Todas estas acciones deben conducir a aportar valor al negocio, y no sufrir un empacho de tecnología como ocurrió en el famoso boom y así apunta Julio Yepes del BBA "A la hora de plantearse la adopción de nuevas tecnologías, una actitud coherente es decir no a la tecnomoda" (el énfasis mío)

Desconozco los mecanismos de mi cerebro que me llevan a enlazar lo anterior con el comentario de hoy; que como todos los comentarios de este rincón son personales y no tienen más objetivo que obligarme a escribir para ordenar mis ideas y guarda aquellos enlaces que me parecen interesantes.

Al grano, considero que se deberían aplicar estos mismos planteamientos a los entornos de desarrollo de software. Desde hace años se vienen desarrollan muchas herramientas que ayudan a las tareas de desarrollo: aplicaciones para la fase de análisis, de diseño, frameworks, entornos de desarrollo, componentes y plugins para nuestros entornos ( de todos los tipos y colores), diferentes arquitecturas y diseños; es decir, “cositas” que nos permiten construir la aplicación que un cliente quiere. Haciendo un símil con la construcción de obra civil podríamos decir que son los andamios, grúas, maquinaria, ladrillos, tubos, cables...

El objetivo que tienen estas “cositas” es mejorar la productividad; generar menos código; desarrollos de mayor calidad, más robustos, que podrán evolucionar de manera más fácil, más segura y ... bla, bla, bla.

En la actualidad la velocidad de las nuevas versiones es alta, por lo tanto se reduce el tiempo entre una y otra versión. A esto le añadimos que un defecto que tenemos las personas que nos apasiona la tecnología es querer estar a la última: probar aquella última versión, incorporar a un proyecto aquel componente o framework o lo que sea que hemos leído que es lo "más de lo más". No discuto ni pongo en duda que las características de las siguientes versiones son casi siempre mejores y con mas potencial.

Pero, resulta que nuestros proyectos presentan el siguiente escenario:

+ Intereses del cliente: cumplir presupuesto y tiempo.
+ Cambios: esto es consustancial a cualquier proyecto de software, el que no lo tenga asumido, por favor que toque el timbre y se baje que este no es su vagón [de este tema en próximos comentarios]

Entonces si sumamos las nuevas “cositas” a los proyectos, acabamos desarrollando y aprendiendo a la vez. ¿Por qué creo que este no es el camino? Porque perdemos el foco que es construir una aplicación para el cliente. Es necesario centrarse en las características de esa aplicación en el tiempo, el presupuesto y la calidad determinada.

Si estamos continuamente incorporando nosotros mismos otros elementos que añaden más piedrecillas, lo único que conseguimos son retrasos y un aumento de presupuesto. Y poco valor para el cliente.

Además, existe otro efecto pernicioso es que al no tener tiempo para profundizar cada día se desarrolla peor. Parece que si no se desarrolla con una herramienta, con unos determinados componentes o con una determinada arquitectura es como si estuviésemos antiguados o haciendo un desarrollo de poca calidad. Y no, la calidad del desarrollo no tiene que ver el número, ni tipo de "cositas" que empleamos.

Por lo tanto, de la misma manera que cualquier empresa busca que su inversión en software aporte valor al negocio, deberíamos realizar el mismo análisis. ¿Qué valor nos aporta para el tipo de desarrollo que hacemos? ¿Concretamente que ganamos?¿Cuál es nuestro target de aplicaciones, de clientes? ¿Es una moda? ¿Es coherente con nuestra estrategia de desarrollo? ¿La podremos aplicar en varios proyectos? ¿Qué ocurre con las modificaciones de proyectos anteriores? ¿Qué riesgos corremos en introducirla en nuestros proyectos? ¿Y si no lo hacemos? ¿Qué capacidad de aprendizaje tienen nuestros desarrolladores? No me vale que dos gurus consideren que es lo último, si el resto de equipo no sabe de que va y no tengo tiempo para que tengan tiempo para aprender [recordatorio: trabajamos en equipo - esto es lo deseable- pero como mínimo en grupo]. No podemos introducir cositas y aún por encima pedir que se realicen en el tiempo determinado. Y muchas más variables que hay que analizar antes de ir de cabeza a descargase la ultima versión de estas cositas.

Ocurre que muchas personas de las que estamos en este sector hemos llegado por nuestras inquietudes bastante alejadas de nuestra formación universitaria; nuestro conocimiento ha venido de probar, cacharrear y en cierta forma jugar. Por eso en algunas ocasiones, nos confundimos o despistamos cuando toca una cosa y cuando toca la otra.

Cuando estamos en un proyecto debemos estar a lo que estamos; esto no significa que veamos para otro lado, en absoluto nuestra obligación es estar a la última, descargamos, experimentar y después una vez analizado incorporarlo a los proyectos, pero porque aporten valor a nuestros desarrollos no porque sea una moda y lo haga fulano y mengano.

Por cierto, para cuando empezamos con tapestry que ya toca, impresionante todo lo que va a suponer para nuestros desarrollos. La próxima moda, y sino al tiempo. No, nada de gurú es que es la historia de siempre.

Las ppt

Una de las aplicaciones ofimáticas que más se usan y a la que menos atención se le presta es Power Point. No me refiero al funcionamiento de la aplicación sino al producto que obtengo.

El Power Point es una herramienta mediante la cual genero un producto que tiene un objetivo que es presentar una información a una audiencia. Y creo que es ahí donde se falla, en no pensar el objetivo de ese producto.

Qué hay que dar seminario, conferencia, ponencia o presentación pues nada... copy & paste, modificamos colores, el nombre del cliente o del evento y ya tenemos un perfecto pastiche.

Mi opinión es que antes de realizar una presentación hay que reflexionar ¿Cuál es la razón que me lleva a realizar una ppt? ¿Qué quiero conseguir de la audiencia? A diferentes objetivos, diferentes formas de hacer la presentación.

Olvidamos que las presentaciones gráficas pueden convertirse en nuestro peor aliado y conducir al desastre la ponencia. Porque lo único que se consigue es introducir otro elemento más de distracción para quienes nos están escuchando.

Es frecuente observar al ponente que realiza una ppt para ayudarse así mismo y se olvida de la audiencia. En estos casos la presentación gráfica esta sobrecargada de información.

Si lo razonamos tiene toda la lógica: como el objetivo de su presentación es utilizarla a modo de recordatorio no se priva de escribir y escribir datos. Ante una ppt sobrecargada acabamos prestándole más atención a la diapositiva que a lo que esta diciendo la persona. El caso más sangrante es cuando directamente la lee y entonces me pregunto ¿Qué hago aquí? Porque si me van a leer las diapositivas, casi prefiero que me la envíes por mail.

La moda de las ppt esta originando que se produzca una alergia a la utilización de los procesadores de texto, entonces se reciben documentos en formato ppt cuando debido al contenido, al objeto del documento debería de ser en otro formato, por ejemplo Word.

Soy consciente que esto es una opinión muy personal y se podría establecer un debate interminable con aquellos que opinen que el Power Point se puede usar para todo.

Y todo este post por leer : The Cognitive Load of PowerPoint

" It is worthwhile to distinguish between two possible goals in making a PowerPoint presentation — information presentation, in which the goal is to present information to the audience, and cognitive guidance, in which the goal is to guide the audience in their processing of the presented information."

"When your goal is information presentation, PowerPoint slides can be full of information that may be extremely hard to process by the audience. However, since your goal is simply information presentation, you are not concerned with whether or not the audience can process the presented information.

"When your goal is cognitive guidance, you want to make sure that the audience members build appropriate knowledge in their memories. Your job is to communicate in a way that will have the desired impact on the audience, so you need to design your slides so they are consistent with how people learn."

7 Deadly Sins

7 Deadly Sins ... Here are the seven deadly sins of management ...

• Arrogance
• Indecisiveness
• Disorganization
• Stubbornness
• Negativism
• Cowardice
• Distrust

Considero la desorganización como el defecto más frecuente que observo en los proyectos. Cuando hay desorganización es altamente probable (por no decir que casi seguro) que se produzca un aumento del presupuesto, de la duración y la calidad disminuye muchisimo.

La falta de toma de decisiones es también bastante frecuente retrasando mucho los proyectos. Aunque este defecto no es tan evidente, en general no es percibido ya que se esconde detrás de la falsa actividad: muchas reuniones que en algunas ocasiones sólo generan más reuniones pero no se concreta nada.

Los otros defectos - arrogancia, intransigencia, negativismo, desconfianza y cobardía - no son deseables; sin embargo, creo que no condicionan tanto la evolución del proyecto. Su influencia será mayor o menor en función de su grado pero las desviaciones en el presupuesto, tiempo y calidad del proyecto pueden llegar a ser asumibles.

Mensajería instantánea en el móvil

ZeeWee es un servicio de mensajería instantánea móvil a móvil (los teléfonos deben soportar aplicaciones Java). Una alternativa a los mensajes SMS y que va a ser más barato que los mensajes de texto (hasta un 90%, dixit CEO de Echovox).

El éxito que han tenido los mensajes de texto hace que este nuevo servicio tenga muchas posibilidades de triunfar, principalmente entre la gente joven.

Ahora dependerá si algún operador desea comercializarlo en España. Con los ingresos suculentos que obtienen los operadores con los mensajes SMS, ¿estarán interesados en proponer nuevas alternativas?

En realidad ya muchas personas emplean los mensajes cortos casi como mensajería instantánea (envían-reciben-envían) con este servicio ¿se dejarán de enviar SMS? o quizá se utilice más y les compense a las operadoras.

El tiempo dirá ...

Equilibrio

:-)

Ráfagas

• A Gantt chart is more a reflection of what happened last week, and what someone hopes will hapen next week


• Project managers can't predict the future, but accurately gauging the degree of uncertainty inherent in their projects can help them quickly adapt to it.

Managing Project Uncertainty From Variation to Chaos ( Meyer, H.Lonch, T Pinch).

¿Para quién desarrolla IT?

"The survey also found that when business and technology are not properly aligned there is a greater chance of IT projects failing" [ Business managers and IT managers: together at last ]

No se me ocurre una situación en la que cuando los proyectos en el área IT no se alineen con los intereses del negocio puedan funcionar. ¿ Qué criterios va a tener IT para desarrollar? Únicamente que la razón de ser de este departamento sea para que quede bonito en los organigramas. Curiosamente estas cosas que deberían ser de perogrullo, pues no lo son.

Hotelchatter

Hotelchatter es una publicación on-line colaborativa, esta a medio camino entre un blog y una revista diaria. Cada día es más complicado clasificar los sites en función de la herramienta de publicación en internet; a veces, se utiliza una herramienta: wikis, foros, blog, blogs colaborativos, o formato revista on-line pero se le da un uso funcional distinto al genérico (es una evolución lógica, por otra parte)

Al grano, que me pierdo. La idea que me interesa comentar de hotelchatter, es la propuesta que hacen para que se les envíe las experiencias y opiniones en los hoteles en los que se ha estado. Pretenden con esta información, conseguir que cualquier persona pueda tener una visión diferente a la que realiza el propio hotel con su publicidad. Esta publicación además ofrece información sobre hoteles de todo el mundo, por ejemplo: anuncian los artistas que actuarán o características de los hoteles.

El negocio de este site esta en la publicidad (que obviedad acabo de escribir). Esta claro que van a poder tener una audiencia muy definida y con unos intereses muy concretos. Por lo tanto, los hoteles estarán muy interesados en anunciarse y realizar alguna campaña de marketing. El éxito de este negocio viene dado por lo rigurosos que sean en sus post. Y en cuanto a las opiniones que los lectores les envíen tendrán que tener algún control de calidad y diferenciar entre un punto de vista argumentado y las típicas quejas o críticas que no están fundamentadas.

Si una iniciativa de este tipo, consigue atraer a un número suficiente de personas como para convertirse en referencia puede llegar hacer daño a algún hotel. Si voy a organizar un viaje y busco un hotel por la zona a visitar, podría consultar este site y en función de los comentarios puedo decantarme por uno o por otro. Por supuesto, que no me asegura que me vaya a gustar pero es más probable que ante un mal comentario prefiera no experimentar. Y si en ese momento hay alguna promoción interesante puede que compre.

Creo que en España no hay nada de esto que se mezcle noticias y opiniones de clientes, planteado con rigor en el que exista un control de calidad. Aunque me parece (esto es un apreciación mía, que puede que no sea real) que los Españoles somos menos participativos a la hora de enviar nuestras opiniones y si son positivas nada de nada. Quizá si se incentivase la participación - algún sorteo regalando alguna estancia de fin de semana - aumentaría esta participación.

Bueno, confesemos: hace un tiempo desarrollé (intente) algo parecido, no tan pretencioso. Consistía en que me enviasen historias para publicarlas en cierto blog; cierto que las historias pertenecían a un grupo de personas con unos intereses muy específicos y que tampoco lo hice bien, en cuanto a la comunicación y promoción. No tenía ningún interés económico y no perdía nada (sólo mi tiempo y tampoco fue mucho). El resultado es que recibí respuesta de personas que les gustaba la idea pero que hasta no ver más historias publicadas no enviarían su historia. Y no lo entiendo porque no era necesario firmar (nombre y apellidos) las historias, dejaba al autor que especificase como quería identificarse. Quizá si me lo hubiese propuesto como negocio lo hubiese planificado mejor. HotelChatter me ha recordado mucho al planteamiento que tenía en mente.