Cómo instalar Salesforce Commerce Cloud

Si lees este artículo puede ser que tengas intención de instalar Salesforce Commerce Cloud como tu plataforma de eCommerce. ¡Bien!

Instalar Salesforce Commerce Cloud

Aunque hoy (oct/19) todavía no hay muchas instalaciones de Salesforce Commerce Cloud en España, lo cierto es que hay algunos casos de éxito muy interesantes. Son varios los retos que han perturbado mi sueño durante esta aventura, y espero con este artículo que no tengas que pasar por lo mismo. Te animo a leerlo y, sobretodo, que hagas tu comentario al final.

Voy a focalizar en dos puntos: 1) la instalación y desarrollo del software según el tipo de cliente que seas, y 2) el análisis de lo que vas a facturar con la herramienta. Al final pasaré muy de puntillas por un tema que ampliaré en otro artículo: los marketers, piezas fundamentales en este gran puzzle. Mi objetivo es que tengas material suficiente para ayudarte a tomar esta decisión tan importante.

Para empezar, Salesforce recomienda que te pongas en manos de un partner. Estoy bastante de acuerdo con Salesforce, aunque como todo, esto es matizable. En breve lo aclaro.

Lo primero y más importante para decidir esto: ¿qué tipo de cliente eres?

Commerce Cloud según cliente

Para instalar Salesforce Commerce Cloud de la mejor manera, y también para usarlo, es muy importante que seas consciente del tipo de cliente que eres. En esta categoría distingo con claridad 3 perfiles:

  • No tienes equipo de desarrollo
  • Tienes un equipo de desarrollo reducido
  • Tu equipo de desarrollo es muy importante (15+ personas)

Voy a repasar los tres tipos un poco más en detalle, dado que para cada uno de ellos la relación con Salesforce y con el partner será diferente.

Instalar Salesforce Commerce Cloud sin equipo de desarrollo

Este es el caso más habitual. Hay cientos de clientes sin equipo de desarrollo. En esta situación no hay más remedio que seleccionar al mejor partner posible, y confiar en él.

¿Y cómo seleccionar al mejor partner? «Esa» es la cuestión en tu situación. Esta es una lista de los elementos que tienes que poder identificar «sí o sí» en la propuesta de tu partner:

  • Realiza tests en sus desarrollos. Este punto es motivo de exclusión directa. Si no realiza tests, ni lo valores. Directamente descartado. Ah, y no vale con escribirlo en la propuesta. Que lo demuestre.
  • Tiene un equipo de desarrollo con experiencia. Exige los currículums de los programadores. Aunque esto es ‘falseable’, si no lo ponen, huye.
  • Tiene un experto gestor/jefe de proyecto. Créeme, este punto es clave. Tiene que usar las mejores prácticas en el desarrollo de software. Busca en la propuestas algunas palabras clave como desacoplamiento, react, o algo que se parezca mucho a esto. Indican que lo están haciendo bien. Y queda con él. Hazle una entrevista para saber cómo gestiona proyectos.
  • Utiliza integración continua. Aunque esto no es vital, sí considero que es muy importante. Dice mucho del partner.
  • Tiene personal especializado en «front-end». No vale con sacar una web bonita: tiene que estar bien hecha, y para eso necesitas un «frontender» en condiciones.

La mayoría de cosas de esta lista tienen que ver con los puntos que describía en un artículo que escribí hace poco, y que se titulaba 8 cosas que he aprendido sobre los equipos de desarrollo. De este artículo quiero hacer especial hincapié en los puntos 4, 3 y 1, en ese orden.

Como puedes comprobar, en esta situación estás en manos del partner. De ahí la necesidad de seleccionar al mejor con tanta objetividad como sea posible.

Instalar Salesforce Commerce Cloud teniendo un equipo de desarrollo reducido

Esta situación, bien llevada, es deliciosa. 🙂 Eso sí, si tienes dudas sobre su capacidad como programadores, si no practican el clean code o no saben qué significa testear en javascript… para y toma algunas decisiones previas. Luego las vemos…

En esta situación vamos a hacer algo genial. Vamos a separar por completo el back-end del front-end. Vamos a «desacoplar» la web de la gestión del Business Manager (así se llama el back-end de Salesforce Commerce Cloud). Esto nos dará dos ventajas fundamentales: 1) nos permitirá gestionar la web de forma completamente independiente, y 2) podremos utilizar tecnologías modernas. Esto último, que puede parecer fútil, no lo es tanto. El antiguo javascript no atrae a nadie, pero si tienes React, Redux, etc… hmm, las cosas cambian. 😉

Obviamente, también necesitaremos que los programadores sepan de estas tecnologías. Si no fuera el caso, ya sabes… formación. Dales un curso intensivo de React, de test en javascript (con Mocha, Ghost Inspector o Jasmine), y también de integración continua (Jenkins está bien). Además, la formación en temas novedosos es pura gasolina para los developers.

Si tu equipo de desarrollo tiene capacidad para programar en javascript, está al día de las mejores prácticas del software, y está motivado para instalar esta «bestia», adelante. Te divertirás, se divertirán, y sacarán un producto bueno.

¿Y el partner? Aquí el partner pasa a tener un rol diferente. Si antes era el responsable de tu instalación, ahora es tu adjunto, tu complemento. Es tu aliado para todo, pero tú marcas el ritmo. En esta tesitura te ayudará de diferentes maneras; con uno o más programadores destinados a tu equipo, realizando tareas de revisión, haciendo de consultor en ciertas tareas, etc.

Y por supuesto, el requerimiento de seleccionar al mejor partner posible no ha cambiado.

Instalar Commerce Cloud teniendo un gran equipo de desarrollo

Esta, si te lo puedes permitir, es la mejor situación. Cuando «tienes músculo» como para hacerlo tú sólo, … wow, es un proyecto increíble. ¿Me llamas y lo hablamos?

En esta situación podrás tomar dos caminos: 1) tener a un partner como soporte o 2) prescindir de él. Por eso dije al principio que lo que recomendaba Salesforce era, cuanto menos, matizable. En esta situación incluso te puedes plantear recurrir directamente a los servicios profesionales de Salesforce. Es carísimo, sí, pero tienes contacto con los que más saben del software. Y otra cosa: un partner seguramente no estará preparado para esto. 🙂

Si esta situación es genial, obviamente también implica algunos riesgos. Vas a tener que reescribir prácticamente todo el código. ¿Difícil? No, mucho más que eso, pero tenemos un gran equipo de desarrollo que rehará todo el Back End «sin problema» (¿verdad?). 😉

Repasa la siguiente lista, con la que pretendo ayudarte a la hora de tomar la decisión:

  • Deberás tener un gran jefe de proyecto. Es la piedra angular sobre la que pivotará todo. Escoge a una persona que sepa «apartar» a los desarrolladores de negocio, sin perderlos de vista. Va a ser el director de orquesta.
  • Es posible que tu empresa sea muy grande, y que pretenda hacer cosas a las que está acostumbrada. Por favor, no caigas en la tentación de hacer proyectos tipo waterfall. Scrum es tu metodología.
  • Intenta crear equipos de desarrollo más pequeños para simultanear partes del desarrollo. Con toda seguridad, tu jefe de proyecto ya lo habrá tenido en cuenta.
  • Muy importante: tus marketers (me refiero a esos genios que «conducen» la web hacia la meta que has marcado) intentarán que los demás vivan en su mundo de caos y prisas. Sabrán sacarle todo el partido a la plataforma, pero sepáralos de los desarrolladores.

Bonus thought

Antes de publicar tu flamante eCommerce, tendrás que pasar por un proceso llamado SRA (Site Readiness Assessment). Hasta eso tiene que estar planificado. Piensa en esto como en un examen: hay que aprobarlo (y tal vez puedas saber las preguntas de antemano) 😉

Si estás en este tercer punto, sinceramente amigo, te envidio.

Hasta aquí he analizado las tipologías de cliente y su relación con el partner. Ahora toca hablar de las previsiones de facturación de tu web.

Previsión de tu facturación online

Otro punto muy importante a considerar antes de instalar Salesforce Commerce Cloud es la previsión de ventas online. Sé tan realista como sea posible, puesto que el contrato que cierres con Salesforce dependerá de este dato. Analiza en detalle varios aspectos, y genera reuniones con todos los equipos involucrados. A modo de ejemplo:

  • ¿Tus marketers tienen preparadas las campañas para el semestre posterior al Go Live!? No dejes este punto sin cubrir. Es vital que la nueva plataforma tenga mucha actividad. ¿Han previsto diferentes escenarios con diferentes resultados?
  • ¿Tu SEO/SEM tiene un plan para esta nueva web? ¿Tenías otra web y ahora cambias a Salesforce Commerce Cloud, o empiezas de cero? Conviene que esto esté preparado de antemano. Para mejorar el SEO seguramente tendrás que incorporar algunas cosas a tu página.
  • ¿Tienes claro cómo vas a medir lo que pasa en esta web? Es importante que sepas lo que ocurre en ella para tomar decisiones ágiles. Y testea, testea, testea. Los A/B están bien, pero también puedes hacer test multivariante y generar funnels diferentes.
  • ¿Tus redes sociales y las campañas que hagas en ellas están alineadas con la nueva web? ¿Tienes claro el estilo de brand awareness que harás a partir de ahora? Por cierto, si tienes equipos diferentes para estas tareas, alinea sus objetivos. 😉

Como ves, todas las opciones están orientadas a convertir mejor, y te van a ayudar a construir una imagen de lo que puedes llegar a vender con Salesforce Commerce Cloud.

Si estás construyendo tu primer eCommerce, entiendo que el cálculo de esta cifra te puede resultar muy difícil. Sin embargo, si ya tienes un eCommerce, no lo dudes mucho y plantea un escenario optimista.

Acabaré este punto insistiendo una vez más: intenta por todos los medios hacer una correcta previsión de ventas online.

¡Ah! ¡No olvides a los marketers!

Ya los he mencionado un par de veces, diciendo que son los que conducen tu web hasta la meta. Suelen ser expertos en marketing. Es super importante que se les dé la formación adecuada para que el uso que hagan de la plataforma sea óptimo. Este sistema no se aprende de la noche a la mañana; es necesario que un experto les guíe en sus primeros pasos.

Para ello, además, Salesforce te asigna un Customer Success Manager (el típico account manager con un nombre mucho más cool). Esta persona te puede resolver todas las dudas en cuanto a cursos y aceleradores que pueden formar correctamente a tus equipos. No obvies esto.

Prometo escribir algún artículo más sobre los marketers, dado que son un elemento clave en el éxito de las ventas. Hoy, sin embargo, me quería centrar más en los requisitos previos, la instalación, el desarrollo y el cálculo de la cifra de negocio.

¿Te ha gustado?

Instalar Salesforce Commerce Cloud no es «rocket science«. Hay que estar al día, aplicar buenas prácticas, ser tenaz, terco… y es necesario que tu equipo de desarrollo esté focalizado.

Pero amigo… cuando todas las piezas de este puzzle encajan, lo que tienes delante es una auténtica «máquina de vender«. Es brutal.

Espero que la lectura te haya resultado muy útil. Si lo necesitas, no dudes en contactar conmigo.

¡Hasta pronto!

3 cosas que nunca deberías hacer como Jefe de Desarrollo

Read this article in english

A lo largo de mi vida como programador he vivido momentos difíciles en el trabajo diario. A veces sólo puedes apretar y apretar, sea cual sea la razón. Esto pasará, sin duda, y cuando pase tienes que hacer el esfuerzo. El trabajo tiene que salir.

Pero, sea como sea, pase lo que pase, intenta evitar estas 3 cosas.

1. Establecer fechas límite poco realistas

Todos hemos tenido deadlines, y sabemos que tenemos que atenernos a ellas. Pero cuando hablamos de programación, estas fechas tienen que ser realistas. La mejor manera de tener fechas realistas es consultando con el equipo de desarrollo. Sabrán trocear el proyecto en tareas más pequeñas y estimar la fecha de finalización con bastante exactitud. Y si el equipo usa Scrum lo harán todavía mejor.

Establecer deadlines poco realistas te retornará de varias formas:

  • Equipo estresado. «Tensión» está bien, pero el estrés no.
  • Baja calidad del código. Tendrán que correr para cumplir con el deadline, sin importar demasiado si las decisiones de implementación son correctas o no.
  • Deuda técnica. Habiendo leído el punto anterior, ¿pensabas que me iba a dejar la deuda técnica?

¿Estás dispuesto a pagar este precio?

2. Permitir deuda técnica

La programación implica deuda técnica. No tener deuda técnica es casi imposible y, con toda seguridad, demasiado caro. Así las cosas, lo que tenemos que conseguir es minimizar su impacto.

Profundizando en esto de la deuda técnica, ya hace algún tiempo, encontré un artículo muy interesante que además incluía un «Cuadrante de la Deuda Técnica» (de Martin Fowler). Te recomiendo encarecidamente la lectura de este artículo.

https://deviq.com/technical-debt/

Me encanta la definición de la primera frase del artículo:

Technical debt is a metaphor for all of the shortcuts, hacks, and poor design choices made for a given software system that compromised its quality, usually in an attempt to meet a deadline.

«La deuda técnica es una metáfora de todos los atajos, trucos y malas elecciones de diseño hechas para un sistema de software dado, que comprometió su calidad, generalmente en un intento de cumplir con una fecha límite.»

Como Jefe de Desarrollo, una de tus prioridades es entregar software, y entregarlo con buena calidad (minimizando, como decíamos antes, su deuda técnica). Por otro lado tenemos las fechas límite. Esto es siempre lo mismo: atenerte a las fechas límite y entregar buen software. ¿Todo? ¿¡Cómo!?

La mejor manera de «intentar» llegar a este objetivo es usando metodologías ágiles. Probablemente sabes que me encanta Scrum. Bueno, eso es porque te da a ti y al equipo de desarrollo una visión muy amplia de lo que se está desarrollando.

Y, por supuesto, las metodologías ágiles son el siguiente punto.

3. Evitar el uso de metodologías ágiles

Cuando tienes o formas parte de un equipo de desarrollo estable, deberías/deberían usar metodologías ágiles. Y a mi me encanta Scrum (¡Ah, que eso ya lo dije!). 🙂

Así que, si tienes un equipo de desarrollo, no asignes ‘n’ proyectos a ‘n’ individuos en un intento de paralelizar su trabajo. ¡Eso es un error terrible! Si haces eso, un proyecto pertenecerá a un programador, los demás no tendrán conocimiento sobre ese proyecto, y por ello el mantenimiento se verá seriamente afectado.

Usar Scrum le otorga al equipo algunas ventajas muy interesantes:

  • Todos participarán en la definición de la solución (sprint planning).
  • Todos hablarán cada mañana sobre sus logros y problemas del día anterior (daily meeting).
  • Todos sabrán qué se está haciendo.
  • Todos hablarán al final de cada sprint sobre lo que han aprendido en él (sprint retrospective).
  • Y mi favorita: aprenderán más y más sobre ellos mismos y serán capaces de estimar la duración de las tareas con mucha más exactitud.

Esta vez no he dicho nada sobre la calidad de código, pero estaba implícito en los tres puntos.  😉

8 cosas que he aprendido sobre los equipos de desarrollo

Read this article in english

Llevo muchos años programando en equipo y, a veces, liderándolos. Hay muchísimas cosas que aún aprenderé en el futuro, pero … mi años no han pasado en vano. 😉

1. La calidad es importante

Sí, la calidad del código es importante, tanto en cómo lo escribes y en cómo lo mantienes. No eres un buen programador hasta que no seas capaz de garantizar que tu código es bueno, y eso significa sin bugs, testeable y limpio (volveré sobre esto más tarde). Y cuando hablamos de calidad hay dos puntualizaciones a hacer: 1) el uso de patrones de diseño es prácticamente obligatorio, y 2) el código debe ser SOLID. No voy a profundizar en estos dos puntos en este artículo, pero lo haré en el futuro.

Consejo: si eres programador y no sabes qué es esto de patrones y SOLID… empieza hoy. Créeme.

2. Lenguaje ubicuo

No solamente entre los miembros del equipo, sino también con el Product Owner y el negocio. Es necesario que usemos las mismas palabras para referirnos a los mismos conceptos. Esto evitará malentendidos y, consecuentemente, costes añadidos. Empieza por tener un buen ‘DoD’ (Definition of Done, Definición de ‘Hecho’).

Y esto no sólo es aplicable a nuestro lenguaje natural. Lee el siguiente punto.

3. Código limpio, limpio, limpio

«¿Código limpio? ¿Para qué? ¡Esto es la vida real!». No cometas este error. ¡El código limpio es prácticamente obligatorio! Di la verdad: ¿cuántas veces has tenido que releer tu código, escrito sólo unas semanas antes, porque no entendías nada? Esto se puede evitar si haces las cosas bien.

La mejor manera de escribir código limpio desde cero es adoptando algún standard. En PHP, sigue *al menos* lo que indica PSR-2 y ya estarás en el buen camino.

Y una cosa más… código limpio también significa darle nombres correctos a clases, métodos, variables, etc. Por ejemplo, no pongas el nombre ‘ClientBasket’ a una clase cuando claramente es ‘Order’. (sin bromas; esto lo he visto).

Y hazte esta pregunta: ¿Has tenido alguna vez un jefe que te diera tiempo para limpiar tu código? 😉

4. Testear es esencial

Obviamente no podía dejar de mencionar PHPUnit, Jasmine, Mocha, Ghost Inspector, Cucumber, … Cuando creas una aplicación, tener testeo automatizado es el pasaporte a la tranquilidad. Si quieres dormir por las noches (o ir a tomar algo, o lo que sea), testea tu código. Este punto es tan importante que incluso tenemos un acrónimo. Bueno, tenemos acrónimos para casi todo. En este caso, TDD – Test Driven Development. Por favor, créeme. Testear todos tus métodos [públicos] desde el principio mantendrá tu código perfecto. Créeme (a mí, no a tu código) y testea. 😉

5. La formación no es esencial, pero a nosotros, los programadores, nos encanta.

Nuestro sector evoluciona a un ritmo altísimo, y siempre queremos estar al día. En mi caso, me gustaría tener la certificación de AWS Solutions Architect. Otros querrán certificarse como Scrum Master o Product Owner. Otros querrán dominar Docker. Cualquiera que sea su objetivo, dales esa formación. Eso es motivación «de la buena» para ellos (para nosotros).

6. Escucha a los miembros del equipo

Tus compañeros de equipo tienen cosas que decir. Pueden tener inquietudes, otros puntos de vista y, aunque algunos de estos puntos no serán aplicables, otros seguro que sí. Pueden tener dificultades en explicar con exactitud cuáles son sus necesidades, pero escúchales igualmente, o lee entre líneas. Me han sorprendido (agradablemente) tantas veces que simplemente no podía dejar este tema sin mencionar.

7. Usa metodologías ágiles

Las metodologías ágiles me encantan, pero hay una que destaca sobre las demás: Scrum. Esta metodología le aporta diferentes beneficios al equipo de desarrollo: confiabilidad, reducido tiempo de deploy, mejor ROI, y mi favorito: calidad.

En el uso de Scrum, pide a tu equipo que además haga revisión cruzada de código. Esto les hará interactuar aún más. Me encanta Scrum.

8. Usa herramientas de colaboración/automatización

Nosotros, los programadores, tenemos un montón de buenas herramientas a nuestra disposición. Sólo por mencionar unos cuántos: git, Bitbucket/Github, PHPUnit, gulp, grunt, composer, Jira, Trello, Jenkins, Docker, Kubernetes, …

Como programador, no los uso todos en cada uno de mis proyectos, pero puedo asegurar algo: el uso de estas herramientas hace que mi vida sea mucho, mucho, mucho más fácil. Algunas de estas herramientas son gratis, y otras no. Cuando sea necesario, paga por ella. Punto.

Comentario extra: Desacoplamiento

¿Alguna vez has oído aquello de “El programador resolvió un problema, pero estropeó otra cosa”? Seguro.

Si quieres impresionar a alguien cuando hables de programación, usa la palabra «desacoplamiento«. Esto puede sonar muy «top», pero significa simplemente que una determinada funcionalidad de tu código está encapsulada en pequeños métodos, de manera que cuando necesites modificar o añadir algo, probablemente no vayas a romper nada más.

Y si a esto le añades testeo automatizado, patrones de diseño, SOLID y código limpio… ¡Boom!  ¡Súper código!