El mantenimiento de Software siempre ha de orientarse al servicio.

Resumen: Realizar mantenimiento de software en la modalidad de cesión de recursos es perjudicial para desarrolladores, clientes y empresas proveedoras de servicios. El camino está en entender el servicio de mantenimiento de software como servicio y no como cesión de recursos.

El principio de simplicidad define como será la fase de mantenimiento de software.

Resumen: El principio y final de un proyecto, son dos puntos más cercanos de lo que se piensa ya que en el momento que un equipo de desarrollo finaliza un proyecto, otro equipo, el de mantenimiento, lo empieza y esta fase, probablemente tenga más perdurabilidad en el tiempo. El principio de simplicidad (KISS) es directamente proporcional a la calidad del servicio de mantenimiento evolutivo.

Buenas prácticas cuando se mantienen soluciones de software.

Resumen: Mantener soluciones de software es un trabajo muy crítico que a menudo se menosprecia  y se realiza con una ausencia total de procedimientos, roles, herramientas y gestión.

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…

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?

6 consejos a tener en cuanta cuando lideramos equipos que crean software.

A continuación os dejo con un post que escribí en su momento en el blog de Kabel Sistemas de Información compañía en la que trabajo y desempeño mi carrera profesional.

Siguiendo la estela del post 6 consejos a tener en cuenta cuando escribimos software, hoy vamos  a ver algunos aspectos que se dan en los equipos encargados de generar software que tenemos que tratar de evitar.

El código no es ni tuyo ni mío, es nuestro.

Una frase típica en los equipos de software es “mi código funciona”. El código no es tuyo, es del equipo, es nuestro. Siente el código que ha desarrollado otra persona del equipo como tuyo, esto, te va a obligar a involucrarte más en el desarrollo y ser más crítico con nuestro trabajo.

En mi equipo funciona.

El software que desarrollamos no funciona hasta que está desplegado en los entornos de producción y vemos que funciona. Eso de “en mi equipo funciona” es un error. Tenemos que asumir que nuestro código falla, y una vez refactorizado y muy probado, podemos tener la seguridad de que funcionara ok, pero no te lo creas hasta que no lo veas.

Cuantas veces te has encontrado con este caso. Muchas. Aprende de los errores y asume que el entorno de desarrollo no es el mismo que el de producción, que los servidores no van a estar siempre configurados de la misma forma y que aunque no lo queramos, pueden aparecen sorpresas a última hora.

Despliega el software que estas creando de forma asidua en un entorno exactamente igual que el de producción y no te encontraras con estas sorpresas de última hora, que implica cambios a fuego en ficheros de configuración o trabajos a deshoras de la noche.

Los equipos grandes son inversamente proporcionales a la productividad.

Cuanto más grande es un equipo menos productividad tiene el mismo.

Cuanto más grande es un equipo más obligado te vas a ver a realizar tareas de documentación, revisión de código, gestión de tareas, gestión del equipo, etc.

Evítalo.

Si el proyecto es muy grande, crea equipos más pequeños con tareas concretas. Delega funciones. Verás cómo la gente está deseando involucrarse en tareas que de otra forma tendría que realizar el jefe de proyecto / arquitecto y cuanta más gente, más trabajo y sobrecarga para esta persona.

5 equipos de 4 – 5 personas y un jefe de equipo van a ser mucho más productivos y eficientes que 1 equipo de 30 personas.

Interfaces de usuario y perfiles muy “juniors”.

Es un clásico, a menudo se desprecian las interfaces de usuario y se ponen a las personas con menos experiencia a implementarlas.

ERROR GRAVÍSIMO.

La pieza más compleja de toda aplicación, es la que le permite la comunicación hombre-máquina.

Pon ahí a gente con experiencia, profesionales que entiendan que están haciendo, que tengan gusto por el detalle y las cosas bien hechas y sobre todo que le den la importancia que tiene.

La tecnología es un medio no un fin.

La tecnología es el medio que nos va a permitir desarrollar ideas o resolver problemas y tenemos que usarla para eso.

En muchas ocasiones, cuando estas desarrollando software nos olvidamos de esto perdiendo el foco de las tareas que tenemos que realizar, para crear plataformas tecnológicas que se apartan la “idea” inicial que pretenden resolver.

Los mejores han de estar en tu equipo.

Rodéate de los mejores. Busca buenos profesionales. Gente que haya puesto aplicaciones en producción. Es complicado, pero existen muy buenos profesionales con gusto por lo que hacen, búscalos e incorpóralos al equipo de desarrollo.

6 consejos a tener en cuenta cuando escribimos software

A continuación os dejo un post que escribí en su momento en el blog de Kabel Sistemas de Información.

Principio de simplicidad.

El principio de simplicidad ha de prevalecer siempre. Siempre que te encuentres ante una decisión toma la más sencilla. A menudo cuando creamos piezas sumamente complejas sufrimos un impacto la productividad del equipo ya que es mucho más difícil comprender, entender y usar el código.

Esto sumado a las tiempo que hay que emplear en pruebas regresión cada vez que nos vemos en la tesitura de modificarlo hace que estos códigos sean un lastre a la larga.

En aplicaciones en las que hay códigos sumamente complejos, el equipo de desarrollo pasa más tiempo leyendo y depurando el código que escribiendo código y esto hay que evitarlo toda costa.

Además gran parte de los proyectos de software son después mantenidos por equipos que no han desarrollado las aplicaciones, por lo tanto, la persona que ha creado un código sumamente complejo desaparece y esto suele derivar en códigos que nadie quiere tocar por miedo al impacto que pueda tener.

Nada es reutilizable hasta que se reutiliza.

A menudo, cuando diseñamos los diferentes componentes de la aplicación, pensamos en el futuro de la misma e intentamos crear códigos reutilizables “por si acaso”.

Error.

Nada es reutilizable hasta que se reutiliza. Esta es una gran verdad que tenemos que tener clara en todo momento. Crear un código para posteriormente reutilizarlo (por que sí) implica complicar ese código, cayendo en el punto anteriormente enumerado.

No a soluciones genéricas que se adaptan a todos los casos.

Cuidado con los casos “voy a diseñar un control que valide lo que introduce un usuario, ya sea un mail, un código postal o un DNI”.

Este tipo de acciones, deriva en códigos complejos y a los problemas anteriormente vistos. A menudo, estas piezas de software mágicas resuelven solo lo que contemplan y conforme tienes que ir añadiendo funcionalidad vas complicándolo más y más.

Soluciones concretas a problemas concretos.

Construir de menos a más. Haz refactoring.

Siempre que creemos piezas de software, tenemos que partir de código sencillo y conforme vayamos teniendo necesidades, crecer sobre lo creado anteriormente.

Hacer uso de refactoring (http://en.wikipedia.org/wiki/Code_refactoring) es una buena práctica, dado que, conforme vamos revisando nuestro software, podemos detectar carencias y subsanarlas, además de ir añadiendo funcionalidades necesarias. Por otro lado, el refactoring te va a dar una visión clara de las funciones de que cada una de las partes de la aplicación a lo largo de todo el proyecto.

No a tu framework, usa frameworks ya desarrollados.

Evita en todo momento crearte tu propio framework. Hay gente, equipos enteros que se están encargando de esto. Usa estos frameworks. Ten en cuenta que seguramente, están desarrollados por buenos profesionales, que están perfectamente testeados y que prácticamente en el 100% de los casos, estos frameworks, van a ser bastante mejores que el tuyo.

Usa JQuery, Modernizr, usa el .NET Framework, usa el framework que quieras, pero no te crees el tuyo.

Por ejemplo, no puedes estar desarrollando un framework de acceso a datos cada vez que desarrollas una aplicación. Esto tiene un gran impacto en la productividad del equipo y seguramente no te van a pagar por desarrollar esa pieza, sino por resolver una problemática concreta. Céntrate en tu negocio.

Haz Pruebas unitarias.

El trabajar con pruebas unitarias, puede parecer que tiene un impacto en los tiempos del proyecto, y bien es verdad que dado que tenemos que escribir más código inicialmente vamos a tardar algo más, pero a la larga, nos va a permitir reducir los tiempos.

Si un código no funciona, vamos a detectarlo en el momento en que ejecutamos la batería de pruebas y esto nos permite ser más eficaces dado que sabemos en qué punto concreto falla nuestro software.

Trabajar bajo el paradigma del TDD, nos va a obligar a diseñar el código de una forma concreta (desacoplado) para poder probarlo, obteniendo así un software diseñado de manera “uniforme” a lo largo de todo el desarrollo, lo cual hace más sencillo su posterior uso, reutilización y refactoring por todo el equipo.

 

Francisco de Goya, en el año 1799, publico una serie de grabados realizados por medio de aguafuerte, aguatinta y retoques de punta seca que llamo Los Caprichos. Mediante estos grabados busco satirizar y retratar la sociedad española de finales del XVIII.

El sueño de la razón produce monstruos, es el grabado 43 de los 80 que componían la serie. Y este, además de posiblemente ser el más famoso de todos, cuenta con un título totalmente inspirador con el que no años después, si no siglos después, nos encontramos que su mensaje sigue siendo totalmente vigente.

En nuestro sector seguro que todos hemos visto casos en los cuales podemos decir que la fantasía ha sido abandonada por la razón y esto se ha traducido en aplicaciones de software monstruosas.