Time to market VS Calidad de proyectos

Reconozco que hace días que tengo el blog algo abandonado.
No es que se me hayan acabado los temas ni las ganas de seguir con el blog, básicamente he cambiado de puesto de trabajo y, la verdad, la nueva posición me tiene algo desbordado y estresado.

Si me seguís en Twitter o habéis curioseado en el “Sobre mí” del blog, habréis visto que recientemente lo he actualizado ya que ahora estoy en el departamento de arquitectura de software. Es una buena posición, con mucha responsabilidad pero a la vez con mucha visibilidad y sobretodo que me permite frikear con un sistema tan grande como es la web de Privalia y todo el backoffice que hay por detrás. Lo malo es que mi volumen de mails diario se ha multiplicado y paralelamente a ello mi asistencia a reuniones con diferentes departamentos y product owners.

Y en estas reuniones aparecen constantemente las discusiones entre el Time to market y la calidad del software que desarrollamos. Y me apetece dar mi visión sobre esto, a ver si hay suerte, algún product owner lo lee y reflexiona un poco sobre las cosas que se dicen en las reuniones.

El Time to market, para el que no lo sepa, es la palabra de moda en el mundillo web. Especialmente en las tiendas online. La competencia es feroz, cada vez hay más gente dedicándose a estos temas y por tanto aparecen nuevas tiendas online como setas. Además, algunas de ellas han contratado a gente buena y consiguen resultados muy correctos, independientemente de que la plataforma sea PHP, Java, Perl, Python o Ruby. Incluso hemos visto alguna cosa hecha en .NET que no tiene mala pinta, aunque me sorprendería que un SQL Server aguante mucha carga.

Ahora ya no valen las medias tintas. Hay que innovar y actualizar constantemente la página o mueres. Y claro, hay que hacerlo rápido, especialmente si la competencia que tan pequeños eran han puesto ese botón tan molón que tú no tienes y te piden tus clientes.

Y aquí chocan los objetivos y deseos de la empresa y los managers con la voluntad de los desarrolladores de lanzar productos de calidad, especialmente si un mal desarrollo puede provocarnos vivir bastante peor al tener bugs y tener que arreglar en caliente y a horas intempestivas pedidos que han quedado mal en las bases de datos.

La inmensa mayoría de la gente no tiene ni idea de lo jodido que es a veces poner un botón que haga tal funcionalidad. Y ya no hablo solo de modificar el framework JS o nuestras vistas HTML. Hablo de la logística y contabilidad que puede ir ligada, hablo de que en webs muy grandes una query mal hecha te puede tumbar en momentos de muchos visitantes, y sobretodo de que muchas veces hemos arrastrado códigos mal hechos porque funcionan (y el time to market es lo más importante) y añadir nuevas funcionalidades es traumático, especialmente si no tenemos una suite de tests automáticos y entornos completos de integración continua.

Y es muy importante que la gente que gestiona los proyectos de IT sea consciente de estas dificultades que muchas veces tenemos los desarrolladores, tengan background técnico o no. Y probablemente también sea tarea nuestra hacer que nuestros managers lo entiendan.

Y en el mundillo web hay un problema aún más gordo. Están saliendo masters como setas en gestión de proyectos web, cursos de scrum master, profesiones nuevas como el SEO y User Experience y muchas veces se está contratando a gente que ha hecho estos masters pero que no conoce los entresijos de una web. Y eso es un riesgo bastante grande, ya que se pueden tomar desiciones erróneas debido a la inexperiencia en el sector.

Aprovecho para aclarar que igual que siempre he mostrado mi respeto más absoluto por los ingenieros de Front-End que casi nadie valora, respeto a los expertos en SEO y User Experience, pero aún no he conocido a ninguno que sepa mucho mucho más que yo de estos temas. Los debe haber, sin duda, y ahí están todas esas webs que dan en el clavo, pero no tengo el placer de conocerlos y haber podido charlar con ellos. En SEO, todo son teorías, cosas que funcionan, cosas que no, pero no está nada claro en muchos puntos qué es mejor y qué no. Y en User Experience, que es psicología inversa todavía es peor.

¿Y qué quiero decir con todo esto? Que con el Time to market la calidad de los proyectos disminuye y se entra en el riesgo de tener un fallo gordo que no detectas hasta producción y ahí es cuando hay problemas de verdad.

Cierto es que muchas veces nos obsesionamos con intentar hacer el código perfecto, super-óptimo, con clases tope molonas, dependencies injections por todas partes y quizás eso no es 100% necesario. Pero hay que mantener un equilibrio entre el código perfecto y hacer las cosas deprisa y corriendo solamente porque la competencia acaba de poner ese botón.

Por tanto, Time to market sí, pero escuchando al equipo de IT que es quien te asegurará unos mínimos de calidad en los proyectos.

Manager o estudiante de master que tal vez estés leyendo esto porque has llegado de rebote buscando Time to market en Google, recuerda estas palabras del gran Pau Garcia-Milà, creador de EyeOS: “No te rías de un friki, porque un día será tu jefe”.

Hecho este paréntesis de reflexión, el fin de semana nuevos artículos sobre PHP y la certificación.

You may also like...

5 Responses

  1. Albert Casademont says:

    No hase falta disir nada más! WEA! xD

  2. Te has quedado a gusto :mrgreen:

  3. JuanFra says:

    No veas tío, te has desahogado bien ee! 🙂

  4. Pedro says:

    Totalmente de acuerdo, felicidades por tu blog que es de los mas interesantes que he visto sobre PHP últimamente.