Jummp’s Blog

El planteamiento de un marco común de trabajo, se articule de la manera que se quiera (framework único, libros blancos de desarrollo, metodologías de calidad, guías de buenas prácticas, consensos entre los miembros de un departamento, etc…), desde mi punto de vista resulta de mucho interés para conseguir productos finales que a la larga sean más fácilmente mantenibles.

Todo lo anterior además debe ser compatible con el objetivo final de cualquier proceso de desarrollo de software que es la entrega de un producto que sirva al usuario y funcione, sin esta premisa, como ya he comentado en otros artículos, de nada valen que se cumplan todas o la mayoría de las iniciativas de calidad del software que acompañen al proceso de desarrollo, ya que el primer mandamiento que debe cumplir toda aplicación informática es la verificación de los requisitos del usuario (además de otros importantes como la usabilidad, seguridad, etc…) y por tanto que satisfagan sus necesidades.

No deben ser aspectos contrapuestos o incompatibles conseguir productos software que sirvan y funcionen y que sean acordes con un marco común de desarrollo, es más, resulta más que razonable que si tiene que haber excepciones sobre ese marco, las haya, siempre y cuando estén justificadas por el propio proyecto en sí. No aplicar esa flexibilidad, sería ir en contra de lo que es el propio proceso de desarrollo de software en sí, donde no todo es previsible o planificable y donde una solución concreta puede requerir una estrategia, una técnica o unos recursos no contemplados dentro de una metodología de calidad o de desarrollo y que no por ello se deberían impedir su utilización si permiten resolver el problema de manera eficiente.

Para responder a esta pregunta me voy a basar en que por regla general existen dos niveles de calidad, uno el que marca el proveedor del servicio y otro el que marca el cliente.

En el caso de que alguno de los dos o los dos (cliente y proveedor) tengan un nivel de calidad, el nivel de calidad que debe tener el proyecto es aquel que tenga un umbral más alto. Una empresa de desarrollo de software podría aprovechar que el cliente tenga un listón por debajo del suyo para entregar un producto con menos calidad que la media que pretende alcanzar, pero esto aunque permite ganar algunos euros más, al final resulta contraproducente, ya que la calidad es un factor diferencial en el proceso de desarrollo de software (empresas de desarrollo hay muchas, pero que normalmente desarrollen productos con calidad, no tantas) y si se quiere tener la calidad como llave para mantener o incrementar el nivel de negocio, es necesario por un lado que la calidad sea siempre mayor o igual que la que espera el cliente y mayor o igual que el nivel de calidad establecido en la empresa y por otro crear un hábito en los procesos de desarrollo, ya que el establecimiento, seguimiento y exigencia de una calidad determinada en los mismos, hace más sencillo el cumplimiento de la misma en la mayoría de los proyectos. Sin la existencia de ese hábito, el esfuerzo por alcanzar el objetivo en cuanto a calidad se incrementa de manera considerable.

¿Qué permite que se llegue antes a tu sitio web la calidad o los contactos?. Sin lugar a duda los contactos, después la falta de calidad de tu sitio web, blog, etc… puede hacer que no se consiga retener a la audiencia, pero la calidad tarda bastante más en hacer que tu web llegue a un colectivo amplio ya que aunque se genere atención la propagación de la misma hacia una audiencia mayor requiere de bastante tiempo (y esfuerzo).

De todo esto tiene mucha culpa Google y su PageRank que si bien tiene medio millón de variables no todas parecen pesar lo mismo y entre las que tiene más peso está el número de enlaces a un sitio web y que a su vez esos sitios que te enlazan tengan peso.

No quiero que se entienda como una crítica a Google, de alguna manera su algoritmo tiene que elegir los sitios web más relevantes y desde luego el éxito que ha tenido el buscador de Google no hace más que corroborar que no se han equivocado.

Pero no sólo Google tiene que ver, es decir, si tu sitio web es enlazado o referenciado en otros sitios web (además con tiempo de permanencia en la red y con sitios web con un PageRank bueno o aceptable) se generará de forma indirecta atención, eso sí, como comenté antes, los contactos solo sirven para que se llegue al sitio web, la permanencia es otra historia, requiere otros ingredientes, ya que la atención directa no se regala, se gana.

¿Esos otros ingredientes tienen que ver con la calidad? La calidad desde mi punto de vista es importante, pero para llegar a un colectivo amplio no es condición suficiente (e incluso necesaria) la calidad. Por ejemplo, yo puedo tener un sitio web que hable sobre un equipo de fútbol de segunda regional con una calidad exquisita, pero que no interese a nadie y sin embargo puedo tener otro que hable de prensa rosa en el que me limite a indicar titulares de lo que se comenta en la tele y tener éxito. Por tanto, que los contenidos puedan interesar resulta también un factor importante (un aspecto que quiero puntualizar es que en este artículo mis reflexiones están dirigidas en qué factores pueden influir en que se genere atención o no en un sitio web y que esa atención sea relevante para el colectivo de usuarios de la red (una visión generalista de los mismos) que hablen tu mismo idioma o tengan intereses o inquietudes similares a los tuyos, pero eso no quiere decir que no pueda ser igualmente válido un sitio web dirigido a un público muy concreto y que genere atención dentro de ese grupo).

Otro factor puede ser el marketing que se haga de tu sitio web (antes de alguna manera ya me referí a eso cuando hablé de los contactos), ya que si se habla bastante de él va a generar espectación e incluso en atención (aunque sea transitiva o se limite a una sección concreta del sitio web o a unos artículos concretos del blog). Internet nos proporciona medios (bastante económicos, en comparación con otros medios tradicionales) para dar a conocer nuestro sitio web y poder competir contra otros que tienen mejor posicionamiento en los buscadores.

También pesa mucho la competencia, cuanto más sitios web traten de lo mismo que tú, más obligará a intentar que tenga la mayor calidad posible y desarrollar contenidos de interés. Para generar atención, se tiene que llegar primero a tu sitio web, eso hace que en este caso los contactos y el PageRank puedan hacerte la vida más fácil.

Seguro que hay más factores, pero entiendo que estos cuatro son muy importantes: calidad, contenido de interés, marketing y competencia para generar y mantener la atención.

Ya nos pasó a todos cuando estudiábamos. Cuando más conseguíamos rendir era en los días previos a los exámenes. Muchas veces ese sprint final permitía que llegásemos al aprobado o consiguiéramos mejores notas, pero si se dejaba todo en manos de ese último impulso podría ocurrir que no diera tiempo de estudiarnos todo el temario con la suficiente profundidad y suspender (o no sacar la nota que nos habíamos marcado como objetivo).

Los seres humanos somos así, la cercanía del momento decisivo hace que nos pongamos las pilas y empecemos a rendir con el nivel que hubiéramos deseado desde el principio.

En el proceso de desarrollo de software se repite, como no podría ser de otra forma, esta máxima, normalmente la proximidad de una fecha de entrega mejora el rendimiento y productividad del equipo (por regla general, también la cantidad de tiempo que se dedica al proyecto, empujado por la necesidad de querer cumplir los plazos). También es cierto que la mala evaluación de las fechas de entrega, siendo demasiado exigentes en muchos casos, obliga en gran cantidad de ocasiones a hacer este sprint final por mucho que se apriete o se mantenga un nivel alto de rendimiento en todo el proyecto.

Por tanto, el sprint final va a ser necesario en la mayoría de los proyectos de desarrollo de software (esos famosos picos de trabajo), que va a durar más cuanto peor esté estimado el proyecto en tiempo y/o recursos (picos de trabajo continuos (y que darán lugar además de tener quemado al equipo del proyecto a una merma en la calidad del producto y a un más que probable retraso en la entrega)) pero que en cualquier caso es necesario mantener un ritmo constante para terminar el proyecto en fecha, ya que si no se ha avanzado lo suficiente antes del sprint final será muy complicado que se puedan cumplir los plazos con un nivel de calidad aceptable.

Este término lo podréis encontrar en muchísimos libros.

La diferencia muchas veces entre un trabajo correcto y un trabajo excelente está en dedicarle esa porción de tiempo de más (la milla extra) para cuidar los detalles y minimizar el número de errores.

En mi opinión la diferencia no está solo en el talento, sino en las personas y organizaciones que son capaces de aplicar esta milla extra, ese factor diferencial que permite llegar más allá en el trabajo (en volumen y calidad) y/o en la evolución personal (autoformación).

La milla extra supone un esfuerzo, supone ir más allá del trabajo convencional. Esto implica un sacrificio, ya que estás cambiando tiempo libre por tiempo que estás dedicando a una ocupación. No obstante, esa milla extra es la que marca la diferencia, la que te permite subir escalones más deprisa y la que sin duda te devolverá con creces todo ese esfuerzo y sacrificio de más que has invertido.

El concepto de Inshore, es un concepto que ha venido de la mano de los dos modelos de centros de desarrollo de software tradicionales: Nearshore y Offshore, los cuales como ya he comentado en diferentes posts, se diferencian por motivos geográficos (para unas personas son unos motivos, para otras otros, en mi caso, el criterio es la distancia).

El Inshore maneja también criterios geográficos para diferencias del Nearshore, ya que hace referencia al establecimiento del centro de desarrollo de software en la misma localización geográfica (mismo municipio o misma provincia) que el centro destinatario del producto resultante.

La regla general que se aplica a estos modelos (no siempre se cumple) es que la distancia reduce la calidad del producto final y también los costes de desarrollo. Supuestamente, atendiendo a esta regla, un centro Inshore produciría resultados de gran calidad, pero también a unos costes de producción altos (o por lo menos similares a la competencia).

La calidad del resultado final depende de muchos factores, pero no necesariamente la distancia debería ser un factor decisivo, si se tiene un buen framework, una buena gestión y organización, una buena metodología y un buen equipo de técnicos. Como en todos los casos, no se puede decir qué una solución es óptima para todos los casos, ya que hay proyectos de desarrollo de software para los que puede resultar interesante el empleo de Offshore, otros Nearshore, otros Inshore y otros una combinación de los anteriores.

El Inshore sólo o combinado con el Nearshore o el Offshore, resulta muy adecuado para proyectos que requieren mucho contacto y feedback con el cliente, por lo que no resulta recomendable (entre otra cosa por los costes) estar desplazando continuamente técnicos y tampoco un umbral de latencia en la respuesta al cliente demasiado alto.

Hasta ahora sólo he trabajado con modelos Inshore puros o con el modelo combinado Inshore-Nearshore, con mejores resultados en los primeros casos que en los segundos, aunque también es cierto que se están mejorando las prestaciones en los últimos trabajos entregados utilizando el modelo Inshore-Nearshore.

Se habla muchas veces de la mala fama de determinadas empresas en cuanto a la excesiva duración de las jornadas de trabajo.

Mi visión sobre este asunto es la siguiente:

1) Para tener picos de trabajo importantes durante grandes períodos de tiempo, resulta más decisivo las características del proyecto que la empresa en cuestión, es decir, habrá casos en los que en esas empresas tan criticadas se esté estupendamente y casos donde en empresas con mejor prensa se esté fatal.

2) ¿Qué la empresa influye? Evidentemente, pero provocada por sus proyectos. ¿Cómo influyen las empresas en los proyectos? Pues generalmente por aplicar políticas agresivas, ya sea para ganar proyectos (infravalorándolos) o para ganar el máximo dinero posible en los mismos (disponiendo menos recursos en el proyecto de los que se necesitan para ejecutarlo), en cualquiera de los dos casos el resultado es exáctamente el mismo, mucho trabajo, pocos recursos. Si se aplican políticas agresivas en un número considerable de contrataciones quiere decir que existirá un número considerable de proyectos donde el personal que trabaja en los mismos se deberá esforzar un porcentaje por encima de su jornada laboral para que alcance unos ratios de beneficios aceptables para la compañía. Como consecuencia de lo anterior, al existir un elevado número de proyectos donde no está proporcionado el trabajo con los recursos, existirán un elevado número de trabajadores descontentos y por regla general los trabajadores descontentos suelen hablar, ya sea en público o en privado y esto es lo que provoca la mala prensa.

Independientemente de que piense que infravalorar proyectos informáticos sea pan hoy y hambre para mañana (además de ser muy negativo en general para el sector), es respetable que una empresa intente subsistir y/o conseguir los mayores beneficios posibles (en caso contrario no tendría sentido la existencia de la empresa), pero deben tener en cuenta que estas políticas agresivas se pueden volver en contra, ya sea por no conseguir proyectos con el nivel de calidad suficiente (muchas veces por muchas horas que se eche a un proyecto por los recursos que participan en él, si estos son demasiado pocos no podrán hacer milagros) o porque la rotación del personal sea tal que sea difícil consolidar equipos, lo que también afectará por un lado al acabado de los proyectos y al nivel de productividad.

Por regla general nos encontramos con que en muchas organizaciones existen procedimientos que se dictan como reglas generales y que después al no estar suficientemente detallados son interpretados de diferente forma en función de quien lo esté aplicando.

No tener homogeneizado un mismo procedimiento en toda la organización es tremendamente improductivo, además de no garantizar que ante una misma circunstancia todos actuén de la misma forma, lo cual provoca inseguridad jurídica si el procedimiento tiene repercusiones legales.

Si un procedimiento no está reglado en detalle y cada cual lo interpreta a su forma y además lleva mucho tiempo funcionando así, es tremendamente complicado plantear una solución homogénea si no es a través de una instrucción de la dirección de la organización. Por tanto, la homogeneización procedimental requiere sin duda el apoyo de la alta dirección de la organización, la cual debe ser consciente de que si quiere eficiencia debe tomar medidas para conseguirlo.

Además de la instrucción que describa con detalle cómo es el procedimiento y que obligue a hacerlo como se indica es necesario un proceso de gestión del cambio para que todos los implicados comprendan cómo se debe ejecutar el procedimiento y entiendan lo necesario e importante que era el proceso de homogeneización de procedimientos.

Otra de las máximas del fútbol es que quien perdona acaba perdiendo el partido.

En el mundo de las empresas de desarrollo de software pasa algo parecido, es decir, si tienes una killer-app y sin embargo no la sabes explotar en el momento preciso, lo más probable es que tarde o temprano salga un competidor con una solución, que incluso puede ser inferior a la tuya, pero que explotada comercialmente de forma correcta ha dejado a la tuya sin posibilidad de negocio.

Otra máxima es que si se juega bien al fútbol lo normal es que ganes y que si juegas mal al fútbol lo normal es que pierdas. Yo creo que en esto estamos todos de acuerdo, independientemente de que Capello o Rafa Benítez ganen ligas.

Si tu empresa hace proyectos de calidad, lo normal es que se imponga a empresas que no consigan ese nivel de desarrollo.

Una frase muy repetida por futbolistas y entrenadores es que hay que ir partido a partido o que el partido dura noventa minutos.

En el proceso de desarrollo de software sucede algo parecido, es decir, no podemos pensar desde el minuto uno en la entrega del producto, ya que el proceso de desarrollo es algo elaborado, metodológico y que debe pasar por tanto por una serie de etapas. La precipitación no es buena, por eso hay que ir partido a partido.

Si has conseguido que un cliente confíe en ti, has dado un auténtico paso de gigante para hacer que su relación con él se prolongue en el tiempo.

La confianza crea fidelización y la fidelización estabilidad.

La confianza no es sólo conseguir la entrega de productos con un nivel importante de calidad, sino haber estado ahí durante el proyecto y después de él, estando a disposición del cliente cuando ha sido necesario y manteniendo un diálogo constante y sin fisuras.

La confianza cuesta ganarla y esto sucede en todos los ámbitos de nuestra vida, no solo en el proceso de desarrollo de software y resulta muy fácil perderla, con cualquier paso en falso.

Imaginaros el siguiente caso, contratáis a una empresa para que os haga una reforma en la cocina y resulta que aunque la ejecución final ha sido muy buena, la obra ha durado un mes más de lo previsto, había días que los albañiles aparecían y otros que no, que cuando se llamaba para pedir una explicación no siempre se respondía y que para reparar unos pequeños desperfectos en la obra, has tenido que estar llamando todos los días, hasta que por fin dos meses después han aparecido y lo han arreglado. ¿Volverías a confiar la reforma de alguna otra habitación de tu casa a dicha empresa?.