Las jornadas de trabajo largas son un indicador de que la ejecución del proyecto no es correcta.

Resumen: Las jornadas de trabajo largas son un indicador importante de la ejecución del proyecto y por lo tanto tu planificación no se está cumpliendo. En gestionar estas situaciones se encuentra la diferencia entre cumplir o incumplir tus objetivos.

De software y recursos.

Resumen: Si no dispones de los recursos necesarios para desarrollar tu proyecto te verás obligado a agudizar el ingenio.

5 consejos para motivar a tu equipo de desarrollo de sotware

Resumen: El desarrollo de software es una disciplina en la cual la motivación de las personas que lo crean es directamente proporcional al resultado de la creación del mismo, por lo tanto mantener motivado al equipo es una de las tareas más importantes que has de realizar.

Conocer a tu equipo de desarrollo es uno de los factores que aseguran la correcta ejecución de un proyecto.

Resumen: Todo el que alguna vez ha trabajo con Scrum, ha percibido esa sensación incomoda que se genera cuando al llegar a la daily scrum meeting tienes que decirle al equipo que tus tareas están en rojo.

La competitividad en el software tiene poco que ver con ajustar estimaciones o tarifas

Resumen: Una situación habitual en nuestro sector, es la que se presenta cuando los gerentes de cuentas nos piden que ajustemos estimaciones o tarifas de cara a tratar de ser más competitivos en los procesos de capacitación de proyectos y en definitiva ganar oportunidades.

Microsoft Excel como interfaz de usuario para soluciones software.

Resumen: En muchas ocasiones nos empeñamos en crear procesos muy complejos para resolver las problemáticas que se nos presentan que nunca terminan de funcionar bien y podrían haber sido resueltos de forma mucho más eficiente utilizando herramientas totalmente implantadas y aceptadas en el ámbito tanto empresarial como domestico como por ejemplo las proporcionadas por Microsoft Office (o Google Docs).

Tengo un equipo y se como usarlo: Como realizar propuestas de colaboración de forma eficiente

Una propuesta de colaboración es un documento que nace como respuesta a una RFP (Request For Proposal) por medio del cual, se trata de resolver una problemática concreta, para un cliente concreto en un contexto concreto. Mediante este documento, vas a dar tu visión de lo que sera el proyecto a futuro en cuanto a alcance, plan, costes etc.

La realización de propuestas de colaboración es un trabajo importante y totalmente necesario que vas a tener que hacer si quieres ganar proyectos. Hacer propuestas de colaboración es una tarea compleja y normalmente se realiza sin tener muy claro si el esfuerzo que vas a realizar tendrá un retorno de la inversión directo, es decir, si vas a ganar el proyecto.

Trata de ser lo más eficiente posible (haciendo siempre un buen trabajo) en este tipo de tareas, ya que implica reducción de costes si o si, ganes o pierdas el proyecto.

Define un modelo para tus propuestas.

Las propuestas, muestran la personalidad de la empresa que está detrás, por lo tanto, tipos de propuestas hay tantas como empresas. Hay propuestas que se realizan en formato Power Point listas para ser presentadas y propuestas mucho más densas pensadas y realizadas para ser leídas. Hay propuestas donde prácticamente no se ahonda en el trabajo a realizar y propuestas donde se pretenden atar todos los detalles.

Como digo cada empresa tiene su propuesta, por lo tanto, tenemos que definir un modelo de propuesta con el que nos sintamos cómodos en cuanto a imagen corporativa, formato, extensión, tono y contenidos.

¿Qué tiene que entrar si o si en una propuesta de colaboración?

Las propuestas, a no ser que el cliente que la solicita la pida con una extensión y contenidos específicos (lo cual sucede en RFPS para proyectos muy grandes) suelen ser muy diferentes unas de otras. Si se comparan dos propuestas realizadas por dos empresas para un mismo proyecto, seguro que son totalmente diferentes.

Con independencia de la longitud de la propuesta, del formato, del tono o de la personalidad que quieras imprimir en la misma hay una serie de puntos que tienes que meter si o si:

• Visión: Define cual es tu visión del proyecto y que es lo que te hace único. Dile a tu cliente cual es la mejor solución para su proyecto y cautívalo. Es aquí donde tienes que demostrar tu conocimiento del medio y negocio que se presenta.
• Alcance: Define que es lo que vas a hacer en base a la planificación y costes que posteriormente le presentas. Este apartado, tiene que estar totalmente alineado con la visión, solo que aquí es donde vas a atar todos los detalles.
  Si en el apartado de visión, dices que habrá un proceso de login, define aquí que significa y que implicaciones tiene (login en base a un único usuario / password, login contra tabla de usuairos, login contra directorio activo etc.).
• Fuera de alcance: Enumera todo lo que esta fuera del alcance de la oferta, es decir lo que no vas a hacer.
• Planificación: Tienes que presentar un plan de proyecto, este plan, puede ser desde una excel con un cronográma a un project con todos los detalles. Tu eres el que se tiene que sentir cómodo con la planificación y tienes que incluirla, el formato del plan o el nivel de detalle, dependen de muchos factores, desde la personalidad de la empresa al tamaño del proyecto, así que define que necesitas en función del proyecto y hazlo.
• Costes: Di cuanto cuesta lo que vas a hacer. El descuento que le aplicas si es que lo haces, IVA etc.
• Descripción de tu empresa: Describe tu empresa, lo bueno que eres y lo bien que trabajas. VENDETE.

Acota el esfuerzo necesario para realizar una propuesta.

De cara a realizar la propuesta, es muy importante definir el tiempo que le vas a dedicar. Ten en cuenta que una propuesta es un trabajo que solo en el caso de ganar el proyecto conlleva un retorno de la inversión, por lo tanto, es muy importante ser todo lo efectivo posible y hacerla en el menor tiempo necesario. Un buen ejercicio y es asignarle una temporalidad. 40 horas, 80, 160 las que sean necesarias pero asociaselas. Asociar esta temporalidad implica que en ese plazo vas a tenerla cerrada.

Planifica la ejecución la propuesta.

Además de asignarle una temporalidad, define las tareas que se tienen que realizar junto con la fecha de entrega de las mismas y asignaselas a las personas más adecuadas para realizarlas.

Por ejemplo, todo lo relativo al plan del proyecto encárgaselo a un jefe de proyecto, lo relativo a visión – alcance – fuera de alcance a un arquitecto. Es decir, que cada persona haga lo que mejor hace en el menor tiempo posible.

Divide la propuesta en tareas, asígnaselas a una persona y define una fecha de entrega.

Reutiliza. Trabaja hoy para ser más eficiente mañana.

En cada propuesta, hay una parte importante que puede ser reutilizada, así que hazlo, reutiliza.

Si es la primera vez que tu empresa tiene que hacer una propuesta, te veras obligado a crear una descripción de la empresa, explicar cual es tu metodología de desarrollo, definir un plan de comunicación… Hazlo, pero ya que lo haces crea un repositorio de información, mantenlo actualizado, organizado y tira de el para futuras propuestas, tanto para realizarlas como para actualizarlas. Además tienes que hacer participe de este repositorio de información a toda la empresa ya que el coste de mantenimiento sera menor si lo hacéis entre todos.

Este repositorio, puede ser todo lo complejo / concreto que quieras. Para empezar probablemente te sirva con una plantilla donde vas añadiendo apartados según vas haciendo propuestas. En el momento en que detectes que esto es insuficiente busca una alternativa con la que te sientas cómodo y ponte con ella. Eso si, siempre de menos a más y basándote en el principio de simplicidad (KISS – Keep It Short and Simple o mejor, Keep It Simple, Stupid).

Es inevitable ya que si no lo haces el coste de las propuestas sera altísimo…

Trabaja hoy para ser más eficiente mañana.

Y tu, ¿que opinas?, ¿como hacéis las propuestas en tu empresa? Espero comentarios…

Qué es experiencia de usuario y quienes tienen que velar porque esta sea buena

Hace ya algunos días que no pasaba por aquí, no obstante, esta semana por fin he sacado un poquito de tiempo para escribir un post que me ronda por la cabeza desde hace mucho tiempo. El post lo he publicado en el blog de Kabel Sistemas de Información y habla sobre que es la experiencia de usuario, que no es y sobre todo quienes son las personas que han de velar porque esta, sea siempre buena.

El susodicho post podéis leerlo a continuación:

¿Que es la Experiencia de Usuario?

De un tiempo a esta parte, por todos lados se esta hablando de experiencia de usuario (ux), no obstante, continuamente nos encontramos con situaciones que ponen de manifiesto que en el sector todavía no está muy claro que es eso de la experiencia de usuario y quienes son los responsables de conseguir una buena experiencia de usuario.

Wikipedia, define la experiencia de usuario como:

Conjunto de factores y elementos relativos a la interacción del usuario, con un entorno o dispositivo concretos, cuyo resultado es la generación de una percepción positiva o negativa de dicho servicio, producto o dispositivo.

Normalmente cuando en el ámbito del desarrollo de software se habla de experiencia de usuario, nos encontramos con que de lo que se habla realmente es de usabilidad y diseño gráfico y según la definición anteriormente citada, podemos deducir que la experiencia de usuario  desde luego tiene que ver con aspectos como usabilidad y diseño gráfico, pero realmente con lo que tiene que ver es con la percepción.

Por lo tanto:

Experiencia de usuario, no es usabilidad.
Experiencia de usuario no es diseño gráfico.

Experiencia de usuario es más que todo esto, experiencia de usuario es percepción.

La percepción es el acto de recibir, interpretar y comprender a través de la psiquis las señales sensoriales que provienen de los cinco sentidos orgánicos.

Según Wikipedia:

La percepción obedece a los estímulos cerebrales logrados a través de los 5 sentidos, vista, olfato, tacto, auditivo, gusto, los cuales dan una realidad física del medio ambiente.

Por lo tanto, podemos afirmar que la experiencia de usuario cuando interactuamos con un producto concreto, sera buena o mala en base a los estímulos recibidos y la manifestación del producto en una realidad física. En desarrollo de software, los estímulos que vamos a recibir, van a ser los relativos a eficiencia, sencillez, visibilidad y calidad de la información, navegabilidad, encontrabilidad, consistencia, estándares, performance o gestión de los errores por citar algunos.

No obstante, de todos estos factores enumerados, encontramos que varios de ellos, si que están totalmente relacionados con el desarrollo de interfaces de usuario, pero también encontramos otros, que tienen más que ver con negocio y arquitectura del producto.

¿Quienes son los responsables de trabajar la experiencia de usuario?

Por lo general, se identifican a los arquitectos de información, diseñadores de interacción o diseñadores gráficos como los responsables de definir, trabajar y conseguir una experiencia de usuario buena, pero esto es un error.

El responsable de conseguir una buena experiencia de usuario es el equipo.

El equipo de desarrollo es el responsable de la experiencia de usuario, ya que es muy difícil encontrar una única figura que pueda ejecutar las acciones necesarias para garantizar que la experiencia de usuario es buena, principalmente porque para conseguir una buena experiencia de usuario, tenemos que trabajar aspectos de disciplinas muy diferentes.

Por un lado, tenemos que tener un responsable de producto (Product Owner) que además de velar por los aspectos relativos al negocio, sea consciente de que una buena experiencia de usuario es directamente proporcional a la calidad del producto y en muchos casos, también al éxito del mismo.

Por otro lado, el líder tecnológico del proyecto, además de velar por el diseño, arquitectura y calidad del software, también tiene que velar por la experiencia de usuario que en su ámbito de actuación, se traduce en performance.

Las aplicaciones han de ser rápidas y ágiles, y este objetivo, lo perseguirán tanto el arquitecto como los desarrolladores.

Y por supuesto, arquitectos de información, diseñadores de interacción y diseñadores gráficos, concibiendo una interfaz de usuario usable, accesible y amigable, con buena navegabilidad, con una acceso a la información sencillo, haciendo uso del diseño gráfico como medio no como un fin en si mismo.

No hay ningún producto de calidad y éxito en el mercado que tenga una mala experiencia de usuario o dicho de otra forma, la totalidad de los productos que hay en el mercado que han tenido éxito, tienen una experiencia de usuario excelente.

Pensad en los iPods de hace 6 años.

¿Y vosotros qué opináis?

El concepto de terminado en el mundo del desarrollo de software

La semana pasada, en medio de la vorágine que esta suponiendo este mes de Agosto, escribí un post en el blog de Kabel Sistemas de Información donde hablaba sobre el concepto del trabajo terminado.

En el ámbito del desarrollo del software, vamos a encontrar que en función del rol que interectue con una tarea, normalmente el significado de terminado es diferente. Es muy importante, definir que se espera de una tarea y cual es el camino para conseguirlo. A continuación podéis leer el post, o podeís acceder al post que escribir originalmente en el blog de Kabel.

Acabado, cerrado o terminado, son palabras usadas comúnmente para referirnos a lo mismo: el momento en el que a una tarea no es necesario dedicarle más tiempo.

Probablemente el concepto de terminado, sea uno de los conceptos que más controversia levanta en el mundo del desarrollo de software, ya que es algo muy habitual que el concepto de terminado sea diferente para los diferentes roles que intervienen el ciclo de desarrollo y por lo tanto, cuando una persona del equipo de desarrollo dice esto esta terminado o cerrado, el jefe de proyecto, el arquitecto o el product owner esperan una resultado concreto que casi seguro es diferente al que espera alcanzar el desarrollador.

¿Que supone esto? tareas que se reabren / tareas que no se cierran, fricciones y en algunos casos frustración.

Evitar los problemas que surgen en relación al trabajo terminado es un propósito que tiene que perseguir la persona que esta liderando el desarrollo del proyecto y además, tenemos que entender la importancia que tiene ya este concepto esta directamente relacionado con otros de gran importancia, como la evolución del proyecto o el trabajo ideal.

Evitar los problemas que surgen en torno al trabajo terminado es algo asumible, simplemente, prueba lo siguiente:

Define cuando se encuentran las tareas terminadas.

Las tareas se encuentran terminadas cuando el responsable de hacer las pruebas dice que esta terminada.

Sencillo, contundente y sin dejar lugar a ningún tipo de duda. Una tarea estara acabada cuando la persona que prueba dice que esta acaba y que no es necesario dedicarle más tiempo.

Los hay que también defienden que una tarea esta acabada cuando una vez se ha desplegado la solución funciona en un entorno idéntico al que será el entorno de producción. Más o menos es lo mismo, ya que cuando decimos que el responsable de pruebas dice que esta acabada, esto implica que la solución ha tenido que desplegarse, que la solución ha de ser estable etc.

Una tarea estará terminada cuando el responsable de hacer las pruebas dice que esta terminada. En esta afirmación hay una parte muy importante que es “el responsable de hacer las pruebas”, es decir, damos por hecho que tendremos una persona implicada en el proyecto cuya labor sera probar y decir que es lo que esta y que no esta cerrado. Una persona que en definitiva se responsabiliza de lo que se va desarrollando y de que los  acabados y niveles de calidad del producto son suficientes.

Define que significa terminado y que niveles de calidad esperas cuando algo esta terminado.

Comparte con el equipo de desarrollo que esperamos cuando algo esta terminado. La comunicación dentro del equipo es directamente proporcional al resultado del ciclo de desarrollo. En relación a las tareas que se encuentran hechas y las que no lo están, también. Como hemos dicho en la introducción normalmente nos encontramos que el concepto de terminado es diferente en base al role que desempeña cada uno de los miembros del equipos, así pues, unifica el concepto de terminado, deja claro cuando esta terminada una tarea y que es lo que implica.

Un buen ejercicio, es describir que es lo que se espera de cada una de las tareas y dejarlo escrito. Evidentemente esto tiene un coste en la gestión / creación de tareas, pero este sobre coste sera siempre inferior al coste que tiene sentarse con cada miembro del equipo que participa en el desarrollo de una tarea y contarle que esperas de ella o por supuesto, del coste que tiene esperar un resultado sin especificar cual es el resultado.

En un proyecto en el que participé, nos encontramos que el día que nos hicieron una demo del proyecto con las tareas terminadas, no se había realizado ningún trabajo en relación a la interfaz de usuario. Cuando nos hicieron la demo del supuesto trabajo terminado y preguntamos que pasaba con la solución ya que no tenía una hoja de estilos que plasmara la imagen corporativa del cliente ni ayudara a comprender lo que se le estaba exponiendo al usuario final, la respuesta fue:

El trabajo esta hecho, los estilos son interfaz.

Poco que decir al respecto la verdad. No obstante, ¿Que es lo que ha pasado para que un proyecto se considere terminado cuando falta por desarrollar una de las piezas más importantes del mismo?

No utilices el termino terminado.

Terminado es un concepto demasiado absoluto, muchas veces lo utilizamos pero no siempre es el mejor. Es decir, dado que vamos a tener en el equipo una persona que va a ser el responsable de definir que esta terminado, trata de que el termino terminado solo lo utilice él.

Desde el punto de vista del desarrollador, puedes utilizar otros términos, términos no tan absolutos que te dan margen para interactuar con las tareas, por ejemplo, en scrum, es un formalismo comúnmente aceptado utilizar los términos rojo y verde.

• Rojo cuando la tarea se encuentra en progreso.
• Verde cuando ya se ha realizado el trabajo y podemos considerarlo hecho.

Como conclusión, evitar los problemas que surgen en relación al trabajo terminado, es tan sencillo como hacerle ver al equipo cuando se puede dar una tarea por cerrada, quien dice que esta abierto y qué está cerrado y sobre todo que todas las personas que intervienen en el ciclo de desarrollo, tengan el mismo concepto de lo que supone que algo este terminado.

Y a tí, ¿que te parece? Espero comentarios.

Equipos de desarrollo, productividad y software o como mejorar la productividad del equipo de forma sencilla

Anoche, escribi un post muy chulo sobre como mejorar la productividad de los equipos de software en el blog de Kabel, compañia para la que trabajo.

En este post, cuento experiencias propias que pongo en práctica en los proyectos que ejecuto con Kabel. En el hablaba de una serie de prácticas que van a promover que el equipo de desarrollo se encuentre coexionado y alineado con una forma de trabajar y los objetivos que hay que cumplir.

Si quieres leerlo, puedes hacerlo mediante el post escrito en el blog de Kabel, o a continuación:

Uno de los aspectos recurrentes al que nos enfrentamos cuando nos encontramos inmersos en el desarrollo de proyectos de software es la gestión del retraso en la ejecución de tareas planificadas por parte del equipo de desarrollo.

Normalmente, antes de iniciar cualquier proyecto, incluso antes de de haber ganado un proyecto, se realiza un ejercicio de definición de alcance del proyecto y estimación. Estimar es un proceso (normalmente) empírico por medio del cual tratamos de definir el coste en tiempo(por lo tanto también en dinero) del trabajo que vamos a realizar. ¿Qué sucede en la vida real? que en algunas ocasiones, nos encontramos con que el tiempo dedicado a la ejecución de las tareas es más alto del que hemos estimado / planificado.

Cuando estoy liderando un equipo que crea software y detecto que esto sucede, la primera aproximación que realizo es tratar de analizar como esta trabajando el equipo y ver si hay un estado mental de equipo y proyecto. Que quiero decir con esto, pues simplemente que el equipo tiene que avanzar en un dirección y todos los miembros del equipo tienen que tener en la cabeza cual es el próximo objetivo a alcanzar, cuando lo vamos a alcanzar y la calidad que tenemos que alcanzar para poder calificarlo de éxito.

Es muy importante que lleguemos a este estado mental de proyecto ya que esto nos va a permitir ser mucho más productivos y aumentar el velocity de forma significativa.

Como lo conseguimos:

El equipo ha de estar junto.

Que el equipo de desarrollo ha de estar junto parece evidente, pero es sorprendente ver como algo que debería ser habitual no siempre sucede y encuentras que en una misma sala, hay varios equipos de desarrollo y cada miembro de los equipos, en una punta de la misma.

Esta situación genera interrupciones (por ejemplo, cuando tenemos que preguntar algo y nos levantamos y te cruzas con otro de tus compañeros y se mantiene una charla), genera ruido(cuando dos personas hablan desde sus sitios en voz alta), genera problemas de comunicación (ya que es muy dificil realizarla de forma eficiente), no permite que se comparta el conocimiento correctamente (la distancia física fomenta que no todas las personas puedan acceder al mismo) etc.

Reduce el espacio físico y pon a todos los miembros del equipo juntos y si puedes separados / aislados del resto. Verás como de repente, el equipo estará más centrado, verás como hay menos interferencias en la realización de tareas, verás como la comunicación es más eficiente y fluida y verás como poco a poco se crea ese ambiente de proyecto, es decir de tensión debido precisamente a que evitamos todo lo anterior.

Reduce las interferencias al equipo.

Muy importante. Reduce interferencias. Si ves que alguno de los miembros del equipo constantemete es interrumpido, trata por todos los medios que esto no suceda.

Cual es la mejor forma, nombra a un miembro del equipo como el portavoz (o como lo quieras llamar) del mismo, canaliza todas estas interrupciones a través de el y que sea esa persona el que se encargue de gestionarlas. Si alguno de los miembros del equipo, se encuentra desarrollando a tiempo parcial, trata de cerrar ese tiempo en base a jornadas, es decir, es mejor que este de lunes a jueves al 100% y el viernes se dedique a otro proyecto a que cada día de la semana le dedique una horita a ese proyecto.

La concentración del equipo en las tareas que esta realizando es directamente proporcional a la calidad, velocidad y resultado de la ejecución de tareas, por lo tanto del proyecto.

Crea hábitos.

Crea habitos, trata de realizar la reunión de scrum SIEMPRE a la misma hora, trata de ir a comer a la misma hora, trata de tomar el cafe a la misma hora y además, trata de hacer todo esto con todo el equipo. Nos reunimos todos, tomamos el cafe todos y comemos todos juntos. Estas acciones simples, permiten crear esa conexión de la que hablaba anteriormente, permite crear ese estado mental y en la práctica, implica que cuando tomamos cafe, tratamos de resolver dudas respecto a tareas, comentamos problemas que hemos encontrado, le ayudamos a un compañero, así que, cuando  estamos en la reunión de scrum, hablamos del proyecto, cuando tomamos cafe, hablamos del proyecto, cuando comemos, hablamos del proyecto, cuando… hablamos del proyecto. PROYECTO, PROYECTO, PROYECTO.

El proyecto siempre ha de estar presente y todo el mundo tiene que estar a mil con el mismo. Desde luego para asuntos personales / sociales etc. también hay tiempo, pero trata de que sea menor que todo lo relativo al proyecto.

Comparte objetivos, fechas y plazos.

Comparte los objetivos, fechas y plazos, es más, haz participe al equipo en la planificación de estos objetivos, de las fechas y los plazos y trata de que todo mundo este involucrado y de acuerdo con estos aspectos.

Que los compromisos salgan del equipo, siempre te va a ayudar a compartir la responsabilidad y que cada uno de los miembros del equipo trate de conseguir este objetivo ya que son responsabilidad suya directamente.

Que todo el mundo tenga presente que hay que entregarle al cliente y cuando hay que entregárselo.

Fomenta las buenas relaciones del equipo.

Todos los miembros  del equipo han de tener con sus compañeros una relación de confianza basada en el respeto. Es muy importante que el equipo este a gusto con sus compañeros, que disfrute trabajando con ellos y que los conozca bien.

Como fomentar estas buenas relaciones, pues simplemente al crear hábitos ya estas haciendo algo importante, además también puedes tratar de realizar alguna actividad que vaya en esta linea.

Lo que esta claro es que el equipo tiene trabajar bien junto y las relaciones tienen que basarse en el respeto. Si alguien no cumple con esto, tendrá que salir del equipo.

Aquí acaba el post, y a tí ¿que te parece?