Project Planning PictureEsta es la realidad: la mayoría de los desarrolladores y gestores trabajamos en proyectos para un cliente específico final. Es decir, hay un cliente que genera unas especificaciones y un equipo que las desarrolla (en el mejor caso esos requisitos están claros al principio aunque lo habitual es que no lo estén).

¿Pero es que puede haber otra cosa? Claro que sí, no tiene absolutamente nada que ver la dinámica de trabajo en un proyecto que la dinámica de desarrollo de un producto software.

Ya he hablado en alguna ocasión sobre esta cuestión, pero ahora quiero enfatizar qué aspectos en el desarrollo de proyectos se deben cuidar mucho para evitar que tanto los equipos de trabajo como la misma compañía caigan abrumados bajo el peso de multitud de proyectos mal gestionados y mal cotizados.

El desarrollo de un proyecto está lleno de detalles y todos cuentan: el resultado final es un conjunto de aspectos que se han ido haciendo suficientemente bien, como en cualquier otra actividad profesional. Si descuidamos algunos, se notará en el resultado final. Sencillo de entender, ¿no?

Recientemente he visitado una empresa en la que he visto que se dan algunas de estas circunstancias: gente con ganas de hacer las cosas mejor pero agotadas de las guerras del día a día en que no hay tiempo de pararse un momento y ver qué no funciona o qué se puede mejorar. No hay que ser muy listo para evidenciar qué se está haciendo mal o qué impide que las cosas avancen mejor, el problema es que tú puedes pensar algo pero tiene que ser el gestor del equipo, sus jefes o el responsable de la compañía el que ponga los medios para que la gente trabaje correctamente y decida también cambiar cómo se hacen las cosas. Esto también es algo típico: la incapacidad de ver que los resultados dependen de eso...

Y no sólo se trata de disponer de la infraestructura mínima necesaria, también de mantener una disciplina metodológica en la forma en que se decidan hacer las cosas. Yo creo que no hay más, lo difícil realmente es seguir esa disciplina y los procedimientos establecidos.

Surver Monkey Logo

He creado esta pequeña encuesta sobre los puntos que vamos a ver a continuación.

Si te sientes identificado con algo de lo siguiente, enhorabuena, perteneces a una cultura de trabajo muy extendida en nuestro sector (con poca productividad y resultados pobres que se pueden mejorar). Todo lo que indico a continuación es demasiado obvio y a muchos les sonará a principios básicos, no obstante, ¿se cumplen en la mayoría de compañias de software?

#1 Un proyecto bien estimado en tiempo nos permite trabajar mejor

Cosa obvia aunque lo habitual es que los proyectos se consigan reduciendo los tiempos al máximo y cotizando las horas por lo bajo..., ¿resultado?, proyectos que tienen que salir sí o sí con poco tiempo y, por tanto, en su desarrollo deberemos ir abandonando las buenas prácticas de trabajo (las conozcamos o no, que esa es otra).

Básicamente, los proyectos se cotizan por horas y éstas por los perfiles de la gente que va a participar en ellos (dentro de la misma compañía suele haber perfiles más caros que otros).

Por tanto, si ese trabajo de estimación de horas no se hace bien, habrá dos posibles consecuencias: o vamos a reventar al equipo con mucha presión (cosa no mala sino malísima) o bien la compañía va a perder dinero (que tampoco es nada bueno, vaya).

¿La solución? La estimación se debe hacer por lo alto y contando con la opinión de las personas más relevantes que van a participar en el proyecto, añadiendo también alguna desviación. Esto es fácil de decir y difícil de llevar a la práctica, de ahí que las habilidades comerciales permitan conseguir esto. Seguramente de este modo va a salir un precio mayor que el cliente va a intentar regatear, que ese es otro tema, no menos importante.

Comercialmente no se puede disparar a todo lo que se mueve sin darnos cuenta de que igual que hay compañías que trabajan mal, también hay clientes que conviene no tener. Difícil decisión en épocas de crisis, claro.

#2 La especificación tiene que ser lo más completa posible

Este es el gran caballo de batalla de nuestra profesión en la que lo normal es que los clientes no tengan claro al 100% lo que realmente quieren o necesitan. No obstante, un buen comercial debe ser capaz de ayudar al cliente y extraer de él lo que quiere.

Lo importante de esto es que se debe adquirir el compromiso de que una vez establecida la especificación, ésta no debe cambiar (al menos demasiado) a lo largo de la ejecución del proyecto, y, si cambia, si nos obligan a cambiarla, entonces tenemos que repercutir en el cliente los excesos de tiempo que supongan. Claro, esto tampoco será sencillo, pero el cliente debe entender que no trabajamos por amor al arte y si los números no salen, pues no salen.

Para ello es necesario un trabajo comercial que sea capaz de llevar al cliente al terreno que nos interesa.

#3 Evitar la dispersión de tecnologías

A menos que la compañía cuente con muchísimas personas con perfiles muy distintos, lo normal es que sólo se dominen algunas tecnologías y se sepa algo de otras.

Al cotizar un proyecto hay que tener en cuenta el grado de conocimiento que tiene el equipo en las tecnologías que se van a usar. Si el equipo no conoce bien, por poner un ejemplo, JSF, entonces estamos obviando la curva de aprendizaje (igual a tiempo) en que se va a incurrir durante la ejecución del proyecto. Es, digamos, un coste oculto que hay que tener en cuenta.

No nos engañemos: si bien hay gente que en sus horas no laborales pasan gran parte del tiempo empapándose de manuales o haciendo proyectos por su cuenta, mucha gente no toca esos temas fuera de la oficina.

¿La solución? Intentar contratar proyectos en cuya ejecución se utilicen las tecnologías que mejor se conocen: esto es garantía de productividad (y rentabilidad).

En mi opinión nada peor que un equipo que le da a muchos palos (para mis lectores latinos, "darle a muchos palos" = hacer cosas muy distintas). Sólo podemos ser expertos en pocas cosas y, por tanto, la rentabilidad y productividad va a venir de la mano de esas tecnologías que conocemos mejor. Estamos hablando de hacer un proyecto rentable, no de querer jugar con MongoDB porque mola y voy a forzar a usarlo en el proyecto X sencillamente porque me gusta, no porque realmente encaje en él.

#4 Hay que usar algún tipo de gestión de la configuración

El día a día en el trabajo está lleno de pequeños momentos y detalles que podemos hacer bien, ejecutar en segundos o hacerlos rematadamente mal. Todo detalle cuenta, de modo que la falta de fluidez en el trabajo se debe a ejecutar mal parte o todos esos detalles del día a día.

No hay nada que afecte más a la productividad de un desarrollador que una mala gestión de la configuración: aunque sea simple, se debe establecer. 

¿Cuánto tiempo hemos perdido a veces porque se ha roto la compilación o porque hemos querido volver atrás en el código y esto ha sido imposible?

No es sólo usar un repositorio de código (me da vergüenza hasta escribir esto, pero es que hay quien trabaja sin usar ninguno), también establecer unos mínimos procedimientos sobre cómo usarlo para un equipo de varias personas.

En cuanto a la gestión de la configuración está todo inventado, no hay que innovar, sólo céntrate en las buenas prácticas buceando mínimamente en Internet.

#5 Hay que crear cierta documentación

Vale, sí, esto es obvio pero ¿hay alguien en la organización que exija que se cierre el proyecto con una mínima documentación? No estoy hablando sólo de la guía de usuario para el cliente final (si es que este la exige), sino de todo aquello que debamos documentar mínimamente para poder retomar el proyecto de manera rápida en el futuro. 

Yo siempre insisto en hacer una guía de diseño con todos aquellos aspectos sobre el diseño y la arquitectura que se deban explicar y que no sean evidentes; también una guía de despliegue exhaustiva que nos garantice que podemos instalar y hacer funcionar el proyecto en un nuevo entorno. Esto es tremendamente productivo y generalmente consume sólo unas pocas horas (muy pocas en comparación con cualquier proyecto). Ese tiempo meses más tarde, a la hora de asumir el proyecto de nuevo, pueden ahorrar mucho más y la frustración de hacer ingeniería inversa para ver cómo se han hecho las cosas.

No se puede dar por cerrado un proyecto si no se crea la documentación exigida; es más, se debe ver si ésta se puede realizar a lo largo de la ejecución del proyecto.

Al cotizar el proyecto se deben incluir unas horas dedicadas a la documentación. No es exagerado incluir un 5% de tiempo dedicado a este trabajo.

#6 En lo posible, hay que practicar el enfoque ágil en los proyectos

En la mayoría de proyectos podemos poner en práctica todas aquellas características del desarrollo ágil que nos permite avanzar con productividad. Puesto que un proyecto será rentable si está bien cotizado y si se realiza en tiempo, entonces hay que cuidar mucho todo aquello que suponga ahorrar horas de trabajo.

A lo largo de esta web así como de El Libro Negro del Programador, se insiste mucho acerca de la necesidad de que una solución software sea mantenible. Es más, si no es mantenible fácilmente, el proyecto puede ser todo un fracaso y traerá consigo un cliente muy cabreado y enojado (que seguramente nunca volverá a confiar en ti) o una compañía que tiene un agujero económico que cubrir.

No se hace software para que funcione ahora, sino para que pueda ser evolucionado y matenido fácilmente con el tiempo. Esto para mí es un mantra que repito y un principio irrenunciable.

Mantener un proyecto software en producción es en definitiva conocer cómo se comporta, tener identificadas claramente las actividades de mantenimiento, poder detectar con sencillez dónde ocurren los problemas pero, sobre todo, tener la capacidad de hacer todo eso de manera eficiente y en poco tiempo.

Administrar, por su parte, está relacionado con lo anterior y es igualmente importante: si la administración de cualquier producto software es ineficiente, estaremos poniendo en peligro su viabilidad en producción.

Por muy bien que funcione aparentemente nuestro proyecto, si este no se puede ni mantener ni administrar correcta y eficientemente, habremos realizado en realidad un proyecto más bien pobre. Para que un software sea mantenible y administrable tiene que desarrollarse desde el principio pensando en su sencillez de mantenimiento y administración.

Realizando recientemente algunas actividades de mantenimiento de la web de la compañía en la que dirijo proyectos software, volví a tener presente este carácter intrínseco tan importante del desarrollo. La web está montada en Drupal y se tenían que actualizar algunos módulos desde hacía algún tiempo. A los que me conocen no les extraña en absoluto que dirija la realización de proyectos software al mismo tiempo que me meto de lleno es aspectos de desarrollo de bajo nivel, ¿acaso se puede dirigir algo sin conocerlo suficientemente?

Existe un proyecto que el mundo drupalero conoce muy bien y que permite realizar las actividades de mantenimiento, supervisión y administración de una web basada en Drupal muy fácilmente y, sobre todo, de manera muy eficaz; se trata, claro está, de drush.

Por poner un ejemplo, si tenemos que actualizar el Core de Drupal de un 7.xx a la última versión (en el momento de escribir esto la 7.32) podríamos implementar los pasos oficiales sobre una instancia stage, que, más o menos, son estos:

  • Realizar un backup de nuestro sistema (ficheros y base de datos).
  • Descargar la última versión de Drupal.
  • Copiarla correctamente manteniendo nuestra carpeta "/sites".
  • Ejecutar el script "/update.php".
  • Por último comprobar que todo ha ido bien...

Esto es algo habitual y, en mi opinión, que existan tantas revisiones de Drupal 7 para mí es bueno, puesto que cada revisión mejora aspectos del Core o realiza actualizaciones de seguridad.

No obstante, lo anterior puede ser tedioso incluso si se tiene que realizar cada dos o tres meses. En cambio con drush todo lo anterior se puede hacer con:

$ drush up drupal

En una simple línea de comandos realizamos todos los pasos anteriores, por lo que de ser una actividad pesada se convierte con drush en la ejecución de una única orden.

Del mismo modo, con:

$ drush status

, obtenemos una visión general de la instancia de Drupal.

Comento esto como un maravilloso ejemplo de facilidad de manteniemiento: con el primer enfoque podemos tardar 10/30 minutos, con el segundo menos de un minuto. ¿No es esto productividad? Me pregunto si no llenamos nuestro día con actividades similares que podríamos optimizar.

Salvo que estemos haciendo proyectos de prueba o de evaluación y no profesionales que en ningún momento se pasarán a producción, personalmente me preocupo mucho de que lo que se haga ofrezca suficientes posbilidades, información y herramientas para un fácil y ágil mantenimiento y administración. En este punto está la clave del éxito de muchos proyectos software.

¿De qué sirve un producto que ha costado desarrollar X € si el mantenimiento del mismo cuesta el triple? ¿Tiene sentido proyectos en los que existen hasta varias personas dedicadas íntegramente al mantenimiento del mismo? ¿No es esto una evidencia de que las cosas no se han hecho del todo bien durante su desarrollo? Recuerdo hace algunos años cuando dedicaba parte de mi jornada laboral a mantener un sistema de telegestión en un cliente y se me iban las horas buceando en la base de datos con consultas muy tediosas para descubrir y resolver ciertos problemas.

Me pregunto cuántas veces en este tipo de situaciones no tiene efecto esa frase tan española y castiza de "preocuparse por la peseta pero no por el duro" (un duro equivalía en la era pre-euro a cinco pesetas), expresión que en versión tecnológica vendría a ser algo así como "intentar que el desarrollo a corto plazo sea muy barato y no ver que su mantenimiento será muy caro".

En cualquier producto software, se desarrolla una vez pero se mantiene continuamente (al menos hasta que nos quedemos sin clientes).

Del mismo modo, cualquier cliente en su sano juicio antes de comprar algo debería preocuparse por lo que le va a costar el mantenerlo y si su administración es eficiente y ágil.

Es más, podríamos convertir esta misma capacidad en un atractivo más de valor para nuestro producto: su sencillez (y poco costoso) mantenimiento.

Idea Concetp Development ProductDurante mis primeros años como desarrollador de software tuve la enorme suerte de participar en un equipo que estaba dedicado íntegramente al desarrollo de un producto. Incluso teníamos quienes se dedicaban exclusivamente a escribir pruebas (lo que era un auténtico lujo). Hace tiempo de eso y aunque usábamos tecnologías ahora obsoletas o de menos uso (Visual C++, ActiveX, COM, DCOM, etc), la dinámica para la creación de un producto software no ha cambiado en absoluto, aunque desde entonces he abrazado el desarrollo ágil como mejor forma de realizar software.

Estos dos últimos años, sin ir más lejos, me he dedicado íntegramente a dirigir un equipo de desarrollo para la creación de un producto software muy específico para compañías del sector eléctrico. Han sido dos años muy duros en los que hemos escrito muchísimo código, hemos sacado unas cuatro versiones comerciales del producto con éxito (con clientes consolidados) y hemos tenido siempre presente la necesidad de refactorizar, de esforzarnos por mejorar y ampliar las pruebas, de escribir una documentación de despliegue correcta y mantener una gestión de la configuración eficiente. Nada es perfecto, pero el resultado, en mi opinión, me indica que hemos hecho las cosas aceptablemente bien.

Programar algo que funcione es relativamente fácil, crear un proyecto muy particular para un cliente requiere de algunas habilidades más, hacer un proyecto similar pero de mayor tamaño con un equipo de varias personas añade un nuevo nivel de dificultad pero, sobre todo, realizar un producto software que sea válido no para uno sino para cientos de clientes distintos, es otro nivel completamente distinto que requiere de una dinámica muy diferente a la del trabajo en un proyecto particular.

Hay muchas diferencias técnicas y de gestión entre uno y otro escenario y no siempre se distinguen claramente.

¿En qué consiste la diferencia?

La dinámica es tan diferente hasta el punto de que en ocasiones se intenta afrontar el desarrollo de un producto con la presión al mismo tiempo de entregar proyectos con ese mismo producto (haciéndolo todo el mismo equipo). Lo he visto, lo he vivido y es un absoluto desastre.

Aunque cada producto y cada proyecto tienen su propia idiosincrasia, en mi opinión es mucho más fácil entregar un proyecto para un cliente que te indica lo mejor posible qué necesita. Otra cosa distinta es saber productivizar algo a partir de las necesidades de un conjunto de clientes: esto es ni más ni menos que el desarrollo de un producto software.

Muy resumidamente, en un proyecto:

  • Hay un trato directo con un cliente que puede ser más o menos difícil de llevar (especificaciones que cambian sobre la marcha, exigencia de tiempos de entrega, etc).
  • La funcionalidad a implementar está perfectamente acotada (sí, ya sé, al menos debería estarlo).
  • La gestión de la configuración, o sea, la definición de flujos de trabajo, la gestión de versiones de desarrollo y la de producción final, etc., es relativamente más sencilla. No digo que sea trivial, sino que es más sencilla que la gestión de configuración para un producto.
  • La gestión del grupo de trabajo se orienta a la entrega del proyecto al cliente en fechas determinadas.
  • Las reuniones con el cliente absorben mucho tiempo, sobre todo si se le van haciendo entregas tempranas para su evaluación y corrección.
  • El equipo de desarrollo o quien lo dirige no necesita conocer con todo detalle el universo en el que trabaja el cliente y su propio negocio.
  • No hay necesidad de hacer partes del sistema flexibles y adaptables a gustos y diferentes exigencias de posibles clientes, ya que sólo hay uno.
  • En cuanto al mantenimiento, nos podemos permitir que no sea lo más fácil de mantener (ya que va a haber un sólo cliente), aunque lo deseable es que sea extremadamente sencillo de mantener sin acumular deuda técnica que luego nos pase factura en el tiempo dedicado al cliente, tanto si éste paga ese mantenimiento como si no. Un proyecto difícil y costoso en tiempo de mantener en producción, es un fracaso.
  • No hay tantas restricciones en la elección de las tecnologías a usar, sobre todo el proyecto no va a evolucionar demasiado con el tiempo.
  • Puesto que existe un único cliente, se puede conocer con antelación el entorno en el que se va a desplegar el proyecto (sistema operativo, tipo de base de datos, hardware, etc.), al menos se puede acordar con el cliente.

En cambio, el desarrollo de un producto es otro nivel distinto y mucho más exigente en el desarrollo de software, porque:

  • Hay que conocer profundamente el universo de los clientes potenciales hacia los que te diriges. El producto tiene que resolver algo y aportar funcionalidad para el negocio de los clientes, por tanto, tienes que conocer ese negocio muy bien. No es necesario que todo equipo conozca esto, pero quien lo dirige o determina la funcionalidad sí.
  • De este conocimiento del negocio de los clientes potenciales hay que extraer la funcionalidad a implementar: especificar es algo muy pero que muy difícil, especificar bien para extraer historias de usuario o requerimientos técnicos lo es todavía más.
  • La gestión de la configuración tiene que ser más exhaustiva, sobre todo si con el tiempo terminas teniendo en el mercado distintas versiones del mismo producto.
  • Puesto que la vida del producto puede ser muy larga, hay que hacer mucho más énfasis en la testeabilidad del software y todo o casi todo tiene que estar cubierto por pruebas automáticas. De no ser así, el probar el sistema puede suponer tal agujero de tiempo que puede incluso poner en peligro la viabilidad económica del producto.
  • Es mucho más difícil elegir las tecnologías a usar más adecuadas, sobre todo si se estima que el producto software tenga una vida de muchos años, que es lo deseable para rentabilizar la inversión en su desarrollo, claro.
  • Hay que ponerse en el lugar de los posibles clientes y adivinar o averiguar cuáles pueden ser sus necesidades específicas y particulares para incorporarlas al producto en forma de capacidades de integración, funcionalidad de particularización, etc.
  • Hay que definir el entorno ideal de despliegue del producto, lo que puede ser muy delicado porque esto afectará al coste que tenga el mismo. Cuantos más entornos distintos que tengan que ser compatibles con el producto, mucho más esfuerzo por nuestra parte para probar y probar. Un error fundamental es ignorar el tipo de entorno de despliegue hasta el final.
  • Si queremos mejorar el producto para ganar cuota de mercado, es imprescindible recibir mucho, muchísimo feedback desde el momento en que tenemos un primer cliente usándolo. Es más, si podemos liberar un MVP (minimum viable product) cuanto antes, mejor, corregiremos así deficiencias lo antes posible y enfocaremos mejor el desarrollo del producto.

Aunque estas diferencias las debe considerar el responsable del desarrollo del proyecto o del producto, también afectan al día a día de los desarrolladores del equipo de trabajo.

Me pregunto por qué nunca he visto en un currículum una mención del tipo "Desarrollador de productos software" o "Desarrollador de proyectos para clientes finales"; para mí la diferencia es enorme. 

Sin duda, el desarrollar un producto software (o dirigir su desarrollo) requiere de mucha más experiencia y de controlar muchos más parámetros que el desarrollo de proyectos específicos, bastante más cómodos de gestionar (aunque el trato con el cliente siempre es difícil de llevar).

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

El libro negro del programador.com
Now available in english!

Archivo

Trabajo en...

Mis novelas...