Velneo va a tu ciudad. Próximas citas. ¿Quedamos?

Visita presencial

Los que sigáis nuestro blog y estéis atentos a nuestras acciones ya sabréis que este año Velneo está de gira por España, y cada mes nos presentamos en una o varias ciudades para reunirnos con todos aquellos programadores que están pensando en pasarse a Velneo y por supuesto con nuestros Suscriptores.

Ya hemos estado en Madrid, Gijón, Valencia, Alicante y Murcia. Y seguimos con muchas ganas de continuar la ruta.

Nos quedamos con esas buenas impresiones que nos transmitieron nuestras citas. Desde tratar la estrategia de Velneo, hasta resolver cualquier duda técnica o comercial, o hasta ¿por qué no decirlo? pasar un buen rato charlando sobre todos esos temas que nos interesan a los programadores.

Así que si te animas a quedar con nuestros expertos, éstos son nuestros siguientes destinos:

Barcelona: Semana del 24 de abril

Sevilla: Semana del 22 de mayo

Vigo: Junio. Estamos pendientes de marcar la semana.

Solicita tu cita y te llamaremos para organizarlo.

Solicita tu cita

Este artículo Velneo va a tu ciudad. Próximas citas. ¿Quedamos? es original de Velneo.

Desarrolla aplicaciones a medida con éxito

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

The post Desarrolla aplicaciones a medida con éxito appeared first on Lógica mente Velneo V7.

Estrategia y Empresas

El pasado noviembre celebramos Life is Soft 2011, un evento que quería compartir la filosofia de hacer negocios de manera sencilla y rentable. La intención de Velneo con este tipo de eventos es ayudar a las empresas de la comunidad a ser rentables y definir sus estrategias de negocio. El éxito de Velneo está basado en el éxito de las empresas de la comunidad.

Para ello hemos creado un conjunto de 12 vídeos de 12 minutos en las que expertos en diferentes áreas de empresas de software nos cuentan su experiencia.

Si queréis acceder a todos los vídeos los podéis ver en la lista que hemos creado para Life is soft en el canal de Velneo en YouTube

Life is soft 2011, un evento que no te puedes perder

El 11/11/11 es una fecha muy especial.

En Velneo hemos elegido esta fecha para llevar a cabo un evento muy especial. Life is soft se va a convertir en el evento anual más importante para la comunidad de desarrolladores de Velneo.

En esta primera edición de 2011, Life is soft tendrá una duración de 3 días:

  • El miércoles y jueves se celebrarán unos interesantísimos seminarios donde podrás obtener la mejor y más actualizada información sobre tecnologías, técnicas de programación y software Velneo, directamente de personal de Velneo y de los mejores ponentes en cada área.
  • La tercera jornada del viernes será el colofón final de estas jornadas  y tendremos un gran evento en un marco incomparable como es el teatro de la Universidad Laboral de Gijón. En este evento contaremos con unos magníficos ponentes que nos darán una visión motivadora de diferentes áreas relacionadas con el sector empresarial del software.

¡No te lo puedes perder!

Hay un grupo de miembros de la comunidad que ya han confirmado su asistencia a las tres jornadas, teniendo en cuenta que las 2 primeras de seminarios y certificación cuentan con plazas limitadas y están más orientadas a desarrolladores.

Si no puedes asistir a las jornadas del miércoles o el jueves no te puedes perder el evento del viernes.

Será el primer gran evento organizado por Velneo desde la recordada Velneo Conference de 2006 y del éxito de la Jornada Velneo 2010. En Life is soft 2011 contaremos con múltiples ponencias que nos hablarán del negocio del software desde múltiples ámbitos de una empresa de software y, que te darán respuesta a preguntas como estas:

  • ¿Se puede ser rentable en una empresa de software?
  • ¿Cómo conseguir que las personas demos lo mejor de nosotros en el trabajo?
  • ¿Cómo elegir las tecnologías que debo utilizar en mi empresa?
  • ¿Cómo puedo incorporar el diseño en el corazón de mi empresa?
  • ¿Cómo debo vender mi software?
  • ¿Qué errores debo evitar en mi empresa a la hora de vender?
  • ¿Qué me pueden aportar las redes sociales en el marketing de mi empresa?
  • ¿Qué me puede aportar la formación online a mi empresa?
  • ¿Qué puertas me puede abrir el SaaS a mi negocio?
  • ¿Qué es el PaaS y como puede beneficiarme?
  • Y, por supuesto, ¿En qué novedades para 2012 está trabajando Velneo?

Tendremos la suerte de poder escuchar a magníficos ponentes que nos ayudarán a ver la luz sobre estas cuestiones y a obtener respuestas a cada una de estas preguntas.

Regístrate ahora.

Nos vemos el 11/11/11.

Estrategia para empresas de software

Desde mi punto de vista Geoffrey Moore es el mejor estratega que existe sobre el negocio del Software. Su libro Crossing the Chasm es sin duda el mejor libro que he leído nunca. Si quieres tener una visión general de este negocio y como son las fases desde la creación hasta la madurez no dejes de leer sus libros. En el siguiente vídeo nos hace una recorrido de una hora sobre el concepto de innovación, muy recomendable.

.


Cambiando de herramienta de desarrollo

Cambiando de herramienta de desarrollo

Qu fcil resulta olvidarse del pasado!

Esta se la conclusin a la que llego tras la experiencia vivida en casi 3 dcadas dedicado al desarrollo de software.

La primera vez

La primera vez que aprendes a usar un lenguaje de programacin o una herramienta de desarrollo, todo es nuevo, apenas existen barreras de aprendizaje, ni barreras de entrada. Tampoco tienes lastres del pasado. Todo es sumar, sumar y sumar…

Pasado un tiempo, que depende de la dedicacin y de cada programador adquieres un nivel que te permite abordar proyectos cada vez ms complejos. Finalmente, terminas convirtindote en un experto de esa herramienta y, durante aos desarrollas software e implantas aplicaciones en nuevos clientes.

La hora del cambio

El software no es diferente al resto de tecnologas, con el paso de los aos se cumple un ciclo tecnolgico y comienza otro. Cada ciclo suele obligar a un cambio de lenguaje, herramienta o plataforma de desarrollo.

A diferencia de lo que ocurri la primera vez, ahora existen multitud de barreras que dificultan el cambio:

Los hbitos de programacin

Has adquirido hbitos de programacin, cambiar se convierte en un trauma.

Inevitablemente comparas la nueva herramienta, desconocida, con la antigua que dominas a la perfeccin, otro trauma.

El desconocimiento de la nueva plataforma, durante el tiempo de aprendizaje, produce sensaciones frustrantes. Lo que ahora con la nueva herramienta tardas en hacer 2 horas con la antigua lo haces en 10 minutos. Esta prdida de rendimiento se subsana con formacin y dedicacin al aprendizaje, es decir, programar, programar y programar.

Mi experiencia es que cada vez que tratas de dominar una herramienta de forma autodidacta, las horas que empleas y que podras emplear en tareas productivas acaban resultando ms caras que hacer formacin.

La base instalada

Tienes clientes con instalaciones a los que debes seguir prestando servicios, lo que te obliga a trabajar en paralelo con las dos herramientas de programacin. Lo que se convierte en dos traumas, uno mientras te cuesta ms trabajar con la nueva herramienta que con la vieja y el segundo cuando ya dominas la nueva y te cuesta ponerte con la vieja.

Si el cliente acepta -paga- el cambio hay que migrar sus aplicaciones, lo que produce tambin la necesidad de migrar sus datos y volver a formar a los usuarios.

La evolucin

Con el paso del tiempo evolucionamos y, como sucede con los idiomas, dejas de comparar y comienzas a pensar directamente en como se hacen las cosas con la nueva plataforma.

Finalmente dominas mejor la nueva herramienta y te da pereza ponerte con la vieja.

Si tienes aplicaciones estndar y dispones de financiacin basada en suscripciones o pagos de actualizacin terminas creando una nueva versin. En el desarrollo de las nuevas versiones aprovechas para realizar las modificaciones que llevas deseando hacer desde hace tiempo, mejoras el diseo, interfaz y usabilidad de la aplicacin.

Si tienes aplicaciones a medida, aprovechas las necesidades de los clientes para producir el cambio. Lo importante es que se produzca un beneficio mutuo, el cliente desea una nueva aplicacin mejorada y tu consigues la financiacin del desarrollo.

Mencin aparte requieren las llamadas herramientas de migracin. Mi experiencia se resume en en dos palabras “no funcionan”. Migrar suele suponer un ahorro de tiempo al principio pero que termina siendo una prdida de tiempo y calidad al final. Una vez ms, podemos afirmar que con la migracin lo rpido es lento, y desarrollar el programa desde cero aprovechando los recursos que ofrecen las nuevas plataformas significa que lo lento es al final lo ms rpido.

La historia vuelve a empezar

Con el paso de los aos, la plataforma va quedando obsoleta y el mercado se encarga de generar nuevas necesidades que te obligan a buscar un nuevo lenguaje, herramienta o plataforma.

La situacin nunca vuelve a ser la de tus inicios, al contrario, se vuelve a repetir lo comentado en el cambio anterior, aunque probablemente con barreras cada vez ms altas. Sin embargo, si quieres vivir en este mundo no te queda ms remedio que renovarte o morir de obsolescencia.

Conclusiones

Combina formacin y auto-estudio con el fin de reducir al mximo el tiempo de aprendizaje. Recuerda que tu tiempo vale dinero.

No realices formacin si posteriormente no tienes una planificacin para practicar lo aprendido. Organiza tu agenda para que tras realizar los cursos tengas un tiempo asignado a programar con la nueva herramienta y practicar lo aprendido, de no ser as olvidars lo aprendido y habrs tirado el dinero.

Aprende primero lo sencillo, vete quemando etapas. Comienza con desarrollos sencillos pero completos, es decir, realiza el ciclo completo desde el anlisis hasta la puesta en marcha de la aplicacin. Esto te permitir conocer y dominar la herramienta en su totalidad y no partes aisladas que luego te cueste combinar.

A medida que vayas aprendiendo plantate desarrollar aplicaciones ms complejas, para uso interno, pequeos mdulos de aplicaciones o pequeas aplicaciones.

No abordes proyectos grandes o importantes hasta que tengas perfectamente dominada la nueva plataforma de desarrollo. Si an no ests preparado en la nueva plataforma aborda el proyecto con la antigua si consideras que conseguirs satisfacer las necesidades del cliente. Deshecha el proyecto, si es importante, en caso de que no puedas abordarlo con la herramienta antigua y no dominas an la nueva. Recuerda que es preferible perder un cliente antes de abordar su proyecto que invertir tiempo en un proyecto condenado al fracaso.

Preprate para convivir con las 2 herramientas de desarrollo un mnimo de 2 aos. La duracin de este perodo vara en funcin de la tipologa de tu negocio y puede alargarse mucho ms. Recuerda que mientras tengas un cliente que mantener en la antigua plataforma no podrs olvidarte de ella.

Fija tu estrategia y se fiel a ella. La estrategia es la que marca cundo y hacia donde debes dar el salto tecnolgico.

Recuerda, no tengas prisa, cualquier cambio de herramienta de desarrollo lleva tiempo y debes pensar que lo haces para la prxima dcada no para la prxima aplicacin que tienes que desarrollar.