Ejemplo de Kanbanpad

El desarrollo de software a medida tiene características específicas que lo diferencian del desarrollo de aplicaciones estándar, sin embargo la metodología a seguir en ambos casos es muy similar. En este artículo quiero comentarte 7 aspectos que considero fundamental cuidar desde el principio, para tener éxito en un proyecto de desarrollo de una aplicación a medida.

1. Gestiona tus expectativas y las del cliente

No pienses que te vas a hacer rico con un proyecto a medida. Los clientes no son PaPá Noel, no regalan nada, y tampoco tienen por qué hacerlo, de la misma forma que tú debes hacer valorar tu trabajo. Si consigues un proyecto importante vete pensando que si vas a ganar mucho dinero es porque vas a tener que trabajar mucho. Esfuerzo y facturación suelen ser proporcionales.

El éxito profesional y económico en este tipo de proyectos se consigue a través de una larga relación con tu cliente, basada en la confianza que deberás obtener en base a hacer un buen trabajo cumpliendo plazos y calidad.

2. Sin jefe de proyecto no hay organización

En cualquier proyecto siempre hay como mínimo 2 personas, tu cliente y tú. A medida que el tamaño del proyecto crece también lo hacen las personas que están implicadas en el proyecto. Gestionar un equipo de personas no es fácil, por ese motivo la figura del jefe de proyecto es fundamental.

Sin un jefe de proyecto que haga bien su trabajo el equipo estará inmerso en el caos y la desorganización, te encontrarás con graves problemas de comunicación que derivarán en serios problemas con el cliente, entre los programadores. El trabajo se vuelve complicado, se pierde mucho tiempo en tomar decisiones, los programadores se sentirán perdidos y se buscarán la vida por su cuenta, nadie sabe lo que están haciendo los demás, nadie sabe cuanto llevamos hecho y cuando falta, etc.

No lo dudes si no hay un jefe de proyecto haciendo bien su trabajo, solicita la parada del proyecto hasta que se nombré a uno, y si es preciso coge tú el toro por los cuernos.

3. El responsable de producto debe ser el cliente

Nadie deberia saber más de su negocio que el propio cliente. Nosotros estamos para ayudar al cliente a poner en marcha una herramienta de software que le suponga mejoras en su empresa o negocio y que deberán tener una repercusión económica positiva.

Por este motivo es fundamental que la figura de responsable de producto corra a cargo de un empleado de nuestro cliente. Esta persona debe tener una importante dedicación en horas al proyecto, si no es así el jefe de proyecto debería pararlo inmediatamente hasta que se encuentre la persona que lo pueda llevar a cabo.

Esta persona debe estar en permanente contacto tanto con el jefe de proyecto como con los usuarios finales de la aplicación. Un grave error que debemos evitar es tratar directamente con los usuarios finales sin que esté presente el responsable de producto, lo más probable es que saques conclusiones incorrectas, tu análisis no sirva y haya que deshechar mucho código, tiempo y dinero.

Un buen responsable de producto también debe saber medir los tiempos, las necesidades de la empresa y saber decir no tanto a los usuarios finales como a los programadores cuando tratan de llegar más lejos de lo previsto inicialmente. Si tienes un buen jefe de proyecto y un buen responsable de producto, que aplican bien el criterio de menos es más hay más de un 75% de posibilidades de tener éxito.

4. Utiliza una herramienta online para la gestión de las tareas

Cada vez es más fácil encontrar proyectos donde el equipo está disperso geográficamente, además hay que tener en cuenta a los miembros del equipo que no son de tu empresa. Necesitamos trabajar como un único equipo y para eso es fundamental disponer de una herramienta que nos facilite la gestión de las tareas y la comunicación.

Están de moda las metodologías ágiles, y de esta moda una de las herramientas que mejor me ha funcionado y aportado grandes beneficios son los tableros kanban. Hay cientos de herramientas en el mercado para el uso de tableros kanban, yo te puedo comentar que tengo una magnífica experiencia de uso con dos de ellas:

  • kanbanpad que funciona perfectamente tanto en navegadores de escritorio como en móviles.
  • Trello, una aplicación web que cuenta también con versión para navegador y aplicaciones nativas para iOS y Android.

En otro artículos escribiré más en profundidad las experiencias con cada una de ellas y sus pros y contras.

Gracias a estas herramientas los equipos conocen las tareas pendientes, planificadas, en curso, en fase de pruebas o finalizadas. Todos, incluido el cliente, saben lo que están haciendo los demás, es fácil gestionar los errores encontrados durante las pruebas.

Mi recomendación es que dividas las tareas hasta que puedan ser realizadas en un día como mucho, el objetivo es doble, conseguir que pasen a pruebas tareas todos los días y que el programador se sienta más productivo. Por otro lado el equipo de desarrollo debe tener una comunicación constante, nosotros usamos un chat grupal, como el que nos ofrece por ejemplo Skype.

4. Iteraciones cortas

Si el proyecto lo permite es bueno tener contacto físico con el cliente. Nosotros intentamos tener una reunión presencial en el inicio de cada iteración, en esa reunión se definen y planifican las tareas a desarrollar en las siguientes 2 ó 3 semanas.

2 ó 3 semanas es tiempo suficiente para obtener avances visibles y a la vez es lo suficientemente corto como para reducir el coste de corregir errores en la gestión de las tareas del proyecto. Un mes es mucho tiempo, mejor si las iteraciones pueden ser de 2 semanas.

Las ventajas de realizar iteraciones cortas son múltiples, por un lado simplifica el control de la evolución del proyecto, algo crítico desde el punto de vista económico y del cumplimiento de plazos, por otro lado para los miembros del equipo es más positivo tener 3 tareas pendientes de hacer que ver una lista desde el inicio del proyecto con 100 tareas. Además, los proyectos evolucionan por lo que las tareas deben definirse a corto plazo para que sean efectivas.

Un aspecto fundamental es la prioridad de las tareas, nosotros aplicamos el criterio de priorizar siempre la resolución de incidencias encontradas durante las pruebas a seguir avanzando con otras tareas nuevas. La experiencia nos demuestra que muchas veces la resolución de una incidencia encontrada durante las pruebas de una tarea implica cambios de estructura y de programación que cuanto antes se aplique menos costo en tiempo y dinero supondrá para el proyecto.

En realidad cuando el equipo funciona bien trabaja en lo que podriamos denominar una iteración continua a la que añaden nuevas tareas cada 2 ó 3 semanas.

5. Programa en cloud

Cada día crece el número de personas que hacen teletrabajo y gracias a herramientas de desarrollo de aplicaciones PaaS como Velneo, también crecen el número de desarrolladores que programan en cloud tanto individualmente como en equipo. Programar en la nube aporta numerosas ventajas:

  • Tu código está siempre disponible estés donde estés.
  • No dependes de un equipo, puedes programar desde cualquier ordenador
  • Puedes programar en equipo sin tener que abrir tu red a accesos externos
  • Pruebas tu aplicación en un entorno más real que programar en local
  • Si tu aplicación está optimizada y funciona bien en cloud será un cohete en una red local

Evidentemente, programar en cloud también tiene contras:

  • Grabar tus desarrollos es más lento
  • Las pruebas de importación de datos requieren más tiempo o más programación

Pese a los inconvenientes, te recomiendo que siempre programes en cloud, y que excepcionalmente lo hagas en local para hacer tareas muy puntuales, depurar procesos complejos o pesados o para evitar bloqueos de proyectos con otros desarrolladores del equipo.

En otro artículo, daré más información sobre nuestra experiencia a la hora de abordar el desarrollo en equipo de una aplicación usando el cloud y combinándolo con servidores para uso individual de cada desarrollador y el uso de la importación de componentes.

Desarrollar en cloud tiene además 2 ventajas fundamentales para abordar estos proyectos:

  • El cliente y el responsable de producto pueden ver en todo momento como se avanza en el desarrollo de la aplicación. Es cierto que ven si avanzamos o no, pero la transparencia es nuestra aliada si somos buenos profesionales.
  • El cliente, el responsable de producto y los usuarios finales, puedes hacer las pruebas en tiempo real, con los mismos datos y condiciones que el equipo de desarrollo. Esto ayuda a que sea más sencillo comprender las incidencias reportadas.

Todo esto no implica que en una fase avanzada del proyecto sea conveniente poner en marcha un servidor de desarrollo en el cliente para que puedan tener libertad a la hora de hacer pruebas sin bloquear al equipo de desarrollo que constantemente necesita reiniciar las instancias para probar sus desarrollos.

6. Informa periódicamente a tu cliente de la evolución del proyecto

Salvo que tu cliente sea un autónomo o una empresa pequeña, no es habitual que la dirección participe de forma activa en el proyecto, y aunque el responsable de producto podrá informar de primera mano, es lógico que los directivos deseen conocer el estado del proyecto desde el punto de vista de la empresa que los está programando.

Por ese motivo es importante informar periódicamente, cada iteración o una vez al mes, enviando un informe donde se detallen las acciones realizadas, los módulos o funcionalidad que ya están programadas y probadas, las que se están probando, las que se están programando y las pendientes. No hace falta entrar en profundidad con detalles muy técnicos, hay que tener en cuenta el perfil de quién leerá nuestro informe.

Es importante ser realista y sincero, indicar en todo momento si el proyecto evoluciona favorablemente o si se están produciendo retrasos. Cuanto antes informes, más posibilidades hay que de se puedan tomar medidas correctoras y de que los propios directivos puedan ayudar en la resolución del problema.

Las personas que dieron viabilidad económica al proyecto, están implicadas personalmente en el mismo, y por regla general tienen el mismo deseo que todos los miembros del equipo del proyecto en que sea un éxito, por ese motivo debemos siempre verlos como nuestros aliados, no como nuestros enemigos o evaluadores.

7. Probar, probar, probar y aprobar

Todos los arranques son complicados. Si quieres evitar que la implantación de la aplicación sea un infierno debes asegurarte de que todos los usuarios tienen conocimiento de como funciona la aplicación, la han probado y han dado su visto bueno. Aún así, los datos de pruebas no te van a proteger de que surjan complicaciones durante el arranque, pero al menos evitarás que los usuarios vean a la aplicación como su enemigo, pues ellos mismo han tenido la oportunidad de probarla y aprobarla antes de su puesto en producción.

Para conseguir que los usuarios prueben la aplicación es indispensable el trabajo del responsable de producto que se encargará de probarla personalmente y de validarla con cada uno de los usuarios de la aplicación, bien personalmente o a través los responsables de departamento o área que deberán encargarse de trasladar las tareas de pruebas y validación a toda la organización.

El éxito siempre será el fruto del esfuerzo y del trabajo en equipo

Aún gestionando bien un proyecto y realizando un gran esfuerzo para que todo salga bien, siempre aparecerán muchas dificultades e imprevistos, que deberán superarse en equipo, con respeto, evitando buscar culpables y centrándonos siempre en resolver las incidencias que surjan y las necesidades de nuestro cliente.

Cuando la implantación se estabiliza y el proyecto se convierte en un caso de éxito, no te olvides nunca de disfrutarlo personalmente, con todo el equipo, con el cliente y añadirlo en tu lista de casos de éxito, ya que siempre puede ser la puerta a nuevos clientes y proyectos.

 

Si te ha gustado este artículo, por favor compártelo con los tuyos en las redes sociales

[social_share/]

Share This