Hook

Their other posts in the index, biggest breakout first.
No desarrolles a tu cliente lo que te pide. Puede que este sea el consejo controversial del día, pero en software como servicio, cuando nos piden funcionalidades específicas y hacen sentido para nuestra plataforma de software, no las debemos desarrollar tal cual las pide el cliente. Debemos hacer metafuncionalidades para que sean configurables y que el cliente obtenga el resultado que nos solicitó después de una configuración. Voy a explicarlo con un ejemplo muy trivial. El cliente me pidió que se vea azul. Yo no puedo desarrollárselo para que se vea azul. Yo tengo que desarrollarle un color picker para que el tipo seleccione el color azul, tenga que parametrizarlo y obtenga su resultado. ¿Por qué? Porque eso convierte en el esfuerzo de desarrollo de esa funcionalidad en algo que se puede reutilizar en más clientes y, por lo tanto, se convierte en algo que agrega valor a una plataforma de software como servicio y no algo que resta valor a través de la generación de un Frankenstein. El cliente me va a preguntar, oye, ¿por qué no me lo hiciste azul si sencillamente te lo pedí azul? Y tú le vas a decir, porque el vecino me lo va a pedir verde. Entonces yo de una vez dejo el color picker acá. Obviamente este es un ejemplo muy trivial, pero todas las funcionalidades deben ser estudiadas por este medio y deben ser construidas abstractamente para que puedan ser parametrizadas, configuradas y aterrizadas dentro de una verdadera plataforma de software como servicio que le da posibilidades a un mercado de cubrir con variantes específicas los requerimientos de su proceso de negocio.