Marketing-department Driven Development

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.