Marketing-department Driven Development

Prometo...

Prometo...

En el mundo Agile se habla mucho del design-driven development. Es una aproximación práctica al desarrollo de software que parte de la base de que la magia de un diseño sucede cuando el mismo se concibe y que, por tanto, la clave es concentrarse al máximo en esta etapa de concepción y diseño, dado que determinará y condicionará el éxito o el fracaso de todo lo que le sigue.

Esto está muy bien y si se hace bien el resultado es fantástico, pero no es la panacea y si no se hace bien resulta en catástrofe y concluye peor que si hubieras tomado la «aproximación clásica» (dejar la fase inicial a los técnicos). El problema explota cuando el desarrollo no lo condiciona el diseño, sino las promesas del equipo de marketing.

(Casi) Todo proyecto nace del departamento de marketing, alguien tiene que venderlo antes de que exista necesidad y justificación para construirlo. El tema es que hay muchas formas de vender, de prometer, y de decidir cuándo se van a admitir aportes, o cuáles aportes van a ser admitidos en absoluto.

Una forma sensata de vender un proyecto consiste en contrastar antes con la realidad: preguntar a tu amigo techie o a tu CTO, si tal o cual sistema con tal o cual funcionalidad es vendible y/o programable dentro del presupuesto que el dpto. de ventas está pensando fijar para el mismo.

Una forma insensata de hacerlo es, por contra, que el proyecto tenga fecha de antemano, que la misma sea inamovible (porque el dpto. de marketing que condiciona el proyecto ya ha reservado sala para la launch party), y que los diseños se hagan a espaldas de quien tendrá que desarrollarlos. Un creativo haciendo diseños y un vendedor dándolos por buenos sin que nadie valide internamente que la estructura informacional es correcta, que sirve al objetivo del proyecto, que es usable, que se ciñe a unos bocetos ya consensuados. (Noten que todas estas labores son técnicas, requieren conocimiento especializado, y que no he hablado siquiera de programar; son otras tareas técnicas necesarias para un proyecto de software, aunque nadie hable de ellas.) El resultado se asemeja a las viejas pelis ochenteras, como aquella saga barata de de No me chilles que no te veo.

Como todo buen equipo falto de rigor (esto es un oxímoron, claro), no existirá tal cosa como un hito de validación, se continuarán haciendo cambios hasta el último día. No es grave, al fin y al cabo, el desarrollo es magia, todos hemos visto The Social Network y sabemos Facebook se construyó en un día. Zuck se chinchó con sus colegas de la uni después de la hora de la cena y a la mañana siguiente tenía Facebook terminado, con WhatsApp comprado e integrado, y todo eso. Éste es el concepto.

Y es un concepto catastrófico.

Combos que incrementan la gravedad de esto, y la probabilidad de que suceda: que el vendedor sea asiduo a blogs de tercera tipo PuroMarketing (tranquilos, no lleva nofollow porque no he puesto enlace) en los que se relata con presumido glamour las historias de empresas social media, faunders, CEOs, SEOs, Investors, y toda esa calaña. El vendedor (ahora conocido como CEO) terminará creyendo que él puede ser faunder de su propia startup tecnológica, y dirigir al equipo técnico. Imbuido de esa mística marketiniana irradiada por blogs como el anteriormente mencionado, se verá a si mismo como el próximo CEO de la próxima startup tecnológica, e instaurará para su proyecto, en lugar de un desarrollo condicionado por el diseño, el mucho más divertido diseño condicionado por el departamento de marketing.

Hay otros combos letales también comunes (el conocido síndrome del «este traje me viene un poco grande») que desembocan en la instauración de procesos de desarrollo dirigidos por el departamento de marketing. Otro día los comentaremos.

Jose Alcántara
Resolviendo problemas mediante ciencia, software y tecnología. Hice un doctorado especializado en desarrollo de hardware para análisis químico. Especialista en desarrollo agile de software. Más sobre Jose Alcántara.

5 comentarios

  1. Hay otra situación que suele empeorar las perspectivas de éxito: que desarrollo, diseño y márketing vengan de proveedores diferentes. He estado ahí, y el resultado no suele ser bonito.

    La situación que comentas (plazos inamovibles, ausencia de hitos de validación) no son exclusivos de los proyectos comprados por departamentos de mkt (sería injusto focalizarlo todo este colectivo) y en realidad se traduce en el viejo tópico del cliente tóxico.

    Por último, si el departamento de mkt se lee blogs, la única medicina que conozco para eso es ser tú más resabidillo que ellos.

    1. Me estás spoileando el próximo rant… jajaja.

      Yo he estado ahí y cada vez que lo hago me prometo a mí mismo «que es la última vez que paso por ahí». El resultado suele ser agotador (y demoledor) para todos los que tengan la mala suerte de tener que estar en el ajo.

  2. Quiero hacer preguntas:
    Si el reto de las empresas en la innovación (cuanto más disruptiva mejor), y la innovación viene de la mano de la tecnología… ¿como podemos unir una tecnología que aporte valor, innovación, agilidad, time to market…? ¿Como hacemos para que no se vea a los encargados de la tecnología como los «p*t*s freekies» o como los estirados con los que no va el negocio?. ¿Quién y como debe mover la innovación dentro de las compañías?

Los comentarios están cerrados.

Este blog usa cookies para su funcionamiento.    Más información
Privacidad