El reality check del Big Data

Tenemos un proyecto que genera un volumen de datos tremendo sobre las transacciones y los clientes. Datos en tiempo real de todo tipo, desde montos por transacción como geo localizaciones de dichas compras amén de los tiempos que se tardan en pulsar los botones para que todo suceda correctamente. Estos datos, que almacenamos tanto en bruto como procesados (importantísimo procesar datos en tiempo real y agregarlos), están generando información que nosotros pensamos pueden ser de muchísima utilidad para los diferentes departamentos de la empresa con la que estamos trabajando. Desde el departamento más obvio, Marketing, hasta el departamento menos obvio, Operaciones. Tenemos la capacidad de definir en tiempo real cosas como por ejemplo, qué localización y qué turno de empleados exactamente está dando el mejor servicio, y por lo mismo, el peor servicio y por tanto, deteriorando su marca y la experiencia de sus clientes. También podemos ayudar a la marca a redireccionar clientes a otras localizaciones que probablemente tenga el stock optimizado para ellos en vez de tener que modificar el stock de las localizaciones que es muchísimo más lento y costoso -y probablemente llegue tarde a la demanda.

Como puedes ver, tenemos un set de datos que cualquier marca querría tener en sus manos y poder analizar en tiempo real. Además, una marca como la que menciono, que tiene miles de empleados y que ha apostado por las nuevas tecnologías como pagos móviles en sus localizaciones de venta directa a clientes, debería de estar tremendamente interesada en poder acceder a esa información.

Pues nada más lejos de la realidad. Llevamos más de un año trabajando con ellos, y lo que nos encontramos es precisamente todo lo contrario.

Tienen una buena justificación, no es que la empresa no quiera los datos o no tenga interés en ellos. Es que tiene un problema mucho mayor que le impide si quiera poner interés en esos datos: es una empresa de miles de empleados, con miles de jefes, procesos internos, burocracia y responsabilidades. Es una empresa que tiene una organización tradicional (como toda gran empresa) que tiene una rigidez que le impide moverse con suficiente velocidad.

Pongamos el siguiente ejemplo: podemos analizar y ofrecer los turnos de trabajo de cada una de las localizaciones y discernir cuáles están dando un mejor o peor servicio. Este dato, por muy sencillo que parezca, no es nada trivial. En esta organización en concreto, los empleados de las localizaciones son gestionados desde Operaciones y tienen un índice de rotación muy alto. Desde el momento que el director de operaciones recibe el dato, hasta que este queda digerido por su equipo y se llega a los nombres y apellidos de dichos empleados, lo más probable es que esos empleados ya no se encuentren en plantilla, y por tanto, no se pueda saber qué es lo que les ha motivado a dar tan mal servicio. Peor aún, implementar un proceso interno que tenga esta información y pueda reaccionar a tiempo puede costar incluso más que la rotación natural de los propios empleados, y por tanto, no se justifica el gasto.

La realidad del Real Time Data es que las grandes corporaciones, pese a que generan tremendos volúmenes de información, no son capaces -y no lo van a ser en el corto plazo- de analizar y digerir dicha información de tal manera que les produzca un valor añadido y en consecuencia un retorno de inversión por usar dicha información. Existen excepciones, y es que dentro de estos grandes conglomerados hay equipos que sí son tremendamente ágiles. Estos departamentos suelen ser Marketing y Customer Support. Justo los dos departamentos que tocan directamente el mercado y los clientes, por lo que resulta obvio que tienen que ser lo suficientemente ágiles. Por eso vemos que la demanda más grande en consumo y análisis de datos internos es en estos departamentos.

Ninguna empresa grande no relacionada con la tecnología actualmente está preparada para reaccionar en tiempo real. De hecho, no está preparada si quiera para analizar y digerir la información en tiempo real. Pese a que puedas procesar la información de tal manera que queda ya lista para la toma de decisiones, lo más probable es que no hayas tenido en cuenta (sobretodo si no has tenido mucha exposición a las grandes corporaciones) todo lo que implica tu información en esa toma de decisiones. La definición de los destinatarios adecuados puede aliviar la fricción, pero sigue siendo el mismo problema, hay que cambiar un proceso interno en una corporación de miles de personas.

La realidad del Big Data es que por ahora solamente los departamentos más ágiles como Marketing van a ser los que lo consuman. Pero lo que más me choca es que una gran empresa no reconozca que el valor de ahorrar en los procesos, en mejorar la atención al cliente y en reducir su tiempo de respuesta, pueden significar mejores números al final del año y se incline por el camino de menos fricción, que es usar los datos para su departamento de Marketing y de Atención a Clientes.

Random Though – He aquí un negocio redondo para las grandes consultoras que quieren atacar este problema… ¡cuando ellas mismas sufren del mismo dolor!

De cero a treinta

La verdad es que no muchos podemos decir que hemos visto crecer la empresa en la que trabajamos desde los cero empleados hasta los treinta empleados. De hecho, todavía menos podemos decir que lo hemos visto varias veces. Y la verdad es que algunos podemos decir que también hemos visto ver decrecer de treinta a cero. Y ver todos estos casos es lo que hace que aprendamos algunas cosas muy importantes sobre las personas que incorporamos a la empresa.

Un buen producto sólo puede salir de un buen equipo. Pero el mejor producto solamente sale del mejor equipo. Por eso es muy importante que prestes atención a todos y cada uno de los candidatos que vas a contratar, porque un sólo candidato con malas cualidades puede arruinar el proyecto por completo.

Lo primero que tienes que tener claro cuando empiezas un proyecto, ya seas el fundador o uno de los primeros es entrar, es que cuando eres una empresa del tamaño de una Startup, la responsabilidad se reparte entre todos de manera equivalente -y si no lo es, entonces no estás empezando bien tu empresa. Por lo que aquella persona que contrates al principio tienes que tener en cuenta que es una persona en la que vais a poner mucha responsabilidad y además en la parte más crítica del proyecto. Por eso es recomendable que cuando vayas a contratar a alguien, si es de las primeras personas, te lo pienses muy bien. No solamente tiene que encajar en el perfil profesional, que es tremendamente importante, sino en el perfil personal. Una persona que encaje muy bien en el perfil profesional no vale lo mismo que una que también lo haga en el perfil personal. Son personas que van a pasar muchas horas encerrados contigo, y por tanto, la convivencia con ellas va a ser mucho más intensa que con empleados normales.

Cuando hablo del perfil personal, hablo de todos los aspectos del perfil personal. Tanto su carácter, como su sociabilidad así como su vida personal. Si, vida personal, eso es lo que he escrito. Aunque parezca agresivo, la vida personal de una persona que contratas al principio de tu proyecto va a ser tu vida personal también. Debido a la cantidad de esfuerzo tanto profesional como personal que dedicáis, vuestras vidas personales van a tener hilos en común, donde sufrirás los problemas de tus compañeros de trabajo al igual que ellos sufrirán los tuyos. Y es que no es nada desacertado cuando la gente habla no solamente de Startup sino de ser como una familia.

La edad no debería de ser una baza para seleccionar a una persona. De hecho, la experiencia siempre es un buen punto a tener en cuenta cuando contratas a alguien en una etapa tan crucial del proyecto. Pero también tienes que tener en cuenta que la edad también es una distancia entre las personas. Las horas que pasas junto a tus compañeros de trabajo genera un entorno de bromas, actividades sociales e incluso de confianzas que a veces la edad puede interrumpir o incluso minar. Ten en cuenta que la persona que entre al principio debe estar 100% alineado con el resto de tu equipo tanto profesionalmente como personalmente.

En segundo lugar, hay que mirar muy bien la actitud que tiene la persona con respecto al proyecto. Un candidato que vea el puesto de trabajo como algo temporal, o un sueldo que va a obtener al final del mes es un candidato perdido. Aquellos que miren tu proyecto como uno más no merecen ni que los mires. Son personas que no vas a conseguir enamorarles de tu proyecto, y si lo consigues, es tiempo que has perdido en vez de haber contratado a otro candidato.

Es preferible que contrates a alguien que tenga menos aptitudes profesionales pero que tenga un entusiasmo feroz por tu proyecto. Esta persona va a dejarse la piel por aprender todo lo que le falta hasta llegar al nivel que necesitas de él, e incluso más. El amor por un proyecto es importantísimo en un candidato. Es lo que hace que esa persona venga a la oficina a las siete de la mañana y que se quede durante quince horas contigo programando o organizando diseños o limpiando bases de datos. Esa diferencia puede ser determinante, así que analiza muy bien el interés de tus candidatos por el proyecto.

Aquí es igual de importante cómo sepas explicar tu proyecto. Y cómo lo vendas. La energía que pongas, las ganas que dediques y la manera en la que lo expliques va a dar más o menos oportunidades al candidato a entender lo que estáis haciendo en tu Startup. Ten en cuenta que no eres una empresa famosa y no hay artículos de prensa ni revisiones de tu producto por ahí que puedan leer. Simplemente una descripción del trabajo y probablemente un par de conversaciones con quien le haya organizado la entrevista. Si no lo vendes bien, no vas a enamorar a los candidatos, y menos a tus empleados o compañeros de trabajo.

Finalmente, lo que voy a decirte es una frase que tengo grabada a fuego en mi cabeza: los veinte primeros empleados son los que determinan el ADN de una empresa.

Así que cuando vayas a contratar a alguien para tu proyecto, y sea una de las veinte primeras personas que contratas, mira con mucha atención los puntos que he puesto, porque pueden ser claves para que tu producto sea el mejor.

Ahora bien, igual de importante que contratar a las personas adecuadas es el despedir a las personas inadecuadas. Suena mal, pero una persona inadecuada puede llevarse por medio a toda una empresa, que son muchos más que un solo empleado. En un estado tan crítico como una Startup no hay espacio para error. Es decir, tienes que ser capaz de reaccionar lo más rápido posible para que el proyecto siga adelante y no se quede por el camino. No puede haber gris, sólo blanco o negro. No hay tiempo para analizar o para evaluar, solo hay tiempo para ejecutar. Y el despido es tan importante como la contratación. Y si los despidos son complicados, como pasa por ejemplo en España, lo más aconsejable es hacer un acuerdo con el empleado que vas a echar, de manera que los dos estéis contentos. No hay nada peor para una Startup que un ex empleado no contento, que tanto aquí en Estados Unidos como en España te pueden poner el proyecto en la calle.

En una Startup la mejor situación es cuando no se tiene que ir nadie, porque significa que la contratación que estás haciendo es la adecuada. Ese es el escenario al que todos debemos luchar, donde debemos ser muy diligentes con las personas que incorporamos a nuestro equipo y muy exigentes con las pruebas y entrevistas que hacemos para que no se incorpore alguien que a la postre no será compatible con la forma de trabajar del equipo.

Por fin salimos a la luz

Hace ya un año y medio, en Noviembre de 2010, me puse en contacto con los tres amigos tanto de la carrera, como del paintball -esto merece otro post- y les comenté la idea de hacer un sistema de pago por móviles. Sin dudarlo, Fernando Ávila, Virginia Masa, Catalina Mayorga y Sebastián Vidal se pusieron en marcha y se vinieron a Santa Mónica para empezar un nuevo proyecto que ahora se llama Kuapay.

La historia en realidad es mucho más larga. Allá por el 2005, finalizada la carrera y llevando ya varios meses trabajando en Accenture, Fernando, compañero de carrera, se puso en contacto conmigo y me dijo que quería que viera una cosa que un amigo había visto en Estados Unidos. Dicho y hecho, nos fuimos a casa de Adeyemi y me pusieron delante de la pantalla donde estaba Facebook. Su pregunta: ¿Es posible hacer esto en España? y mi respuesta: «Dame un día y te lo enseño.». Así que me puse la manta a la cabeza, y con la ayuda de Fernando y Virginia, hicimos el primer prototipo, que tenía ya etiquetas en las fotos. Toda esta historia, con todos los detalles irán en otro post, porque hay muchas cosas que no se han dicho y que merece la pena escribirlas -sólo por lo graciosas que son.

Por esta historia común, decidimos volver a empezar otro proyecto, que es Kuapay. La idea fue ponernos delante de una pizarra blanca y pensar ¿cómo podemos hacer que los pagos sean mejor, y más seguros?. El proceso de pensamientos fue muy simple. Fuimos uno a uno poniendo todos los puntos que un pago, sea del tipo que sea, tienen que cumplir. Al final conseguimos una lista que es la que mantenemos a día de hoy:

1. El pago tiene que ser sencillo

2. Tienes que poder pagar con lo que tienes ya en tu mano

3. Tiene poder pasar sin tener que imprimir papeles

Con estos puntos en la cabeza nos pusimos manos a la obra. Para poder resolver estos problemas, lo primero que hicimos es ponernos una sola prioridad, la experiencia del usuario en el pago. A día de hoy la experiencia del usuario del pago es horrible. Tienes que introducir la tarjeta, introducir un PIN y luego recibir el papel con tu confirmación. En otros países incluso tienes que esperar a que el papel salga, y en vez de introducir el PIN tienes que firmar y posteriormente entregar tu papel firmado. Si estás en un restaurante, tienes que esperar a que te traigan un punto de venta para poder hacer este mismo proceso o dejar que se lleven tu tarjeta. Esto a nosotros nos pareció un buen punto de partida. Es decir, ¿por qué sucede esto? ¿por qué es tan mala esta experiencia? ¿cómo hemos llegado hasta este punto?. Y nos dimos cuenta de que actualmente estamos usando una plataforma de pagos que fue diseñada hace más de 40 años ya. Donde todavía la tecnología que tenemos a día de hoy era impensable. El simple hecho de que tengamos que llevar una tarjeta de plástico con nosotros ya nos da la idea de lo retrasado que está el mundo de los pagos.

Visa y Master Card están al corriente de esto y por esto están obsesionados con lanzar nuevas maneras de pagar que mejoren esta experiencia. Por eso han salido con productos como el NFC en el plástico o como Visa Paywave y Master Card Paypass. La innovación en realidad la lleva Master Card, que es el creador original del estándar mundial de NFC en tarjetas Paypass, que luego compartió con Visa y con American Express para promover la tecnología. Pero siguen teniendo el mismo problema de base, y es que lo que quieren hacer en transformar la capa más superficial de su plataforma de pagos, dejando las capas restantes como están. Es decir, cambiar la capa del plástico y el deslizado de las tarjetas en las tiendas, pero no quieren cambiar cómo funciona el resto de los componentes por detrás, como los procesadores de las tarjetas, los emisores, los agentes, etc.

Esto es lo que nos dio la clave de cómo debíamos atacar el problema. En Kuapay lo que tenemos que hacer es cambiar todas las capas del medio de pago. Es decir, no podemos hacer una solución que añada una capa más -como hace el NFC- o simplemente cambiar una sola capa -como hace SquareUp. Tenemos que cambiar el medio de pago por completo, y tenemos que ofrecer una solución que cambie radicalmente cómo se hacen los pagos. Una experiencia que sea legítima y de la percepción de un pago hecho y terminado. Una experiencia tanto para el usuario como para el comercio.

Así pues, nació Kuapay. Hemos trabajado muy duro para llegar hasta esta posición. Estamos en la segunda revisión de nuestro producto. Hemos hecho pilotos en más de 6 países, incluídos Estados Unidos y Chile. Somos un equipo de más de 30 personas trabajando en dos oficinas diferentes y tenemos la confianza de nuestros inversores detrás del proyecto aprobando todas y cada una de las decisiones que tomamos. Como por ejemplo, la decisión de no salir en ningún medio general hasta el congreso de Barcelona. O que los empleados de la empresa tengan más porcentaje que los inversores. O que todas las pruebas qu

e estuviéramos haciendo por le mundo fueran secretas.

Ahora tenemos la oportunidad de enseñar al mundo el fruto de nuestro trabajo durante los últimos 12 meses. ¡Bienvenido a la nueva forma de pagar!

Conectarse a varios esclavos de MySQL con Ruby

Vamos a ver como nos conectamos a varios esclavos de MySQL que replican de un maestro. Como comentamos en el capitulo anterior, la replicación  de MySQL nos permite aumentar la capacidad de lecturas de nuestra base de datos.

Ahora vamos a estudiar la manera en la que podemos conectar nuestro programa de Ruby a todos esos esclavos. La mayoría de las gemas que nos encontramos soportan múltiples esclavos. Pero la manera en la que se conectan es muy simple, y si nos encontramos en una situación de mucha carga, podemos llegar a tumbar toda la base de datos. Veamos el ejemplo de la gema Sequel.

Para configurar múltiples esclavos, tenemos que configurarla de la siguiente manera (codigo ejemplo de su documentación):

DB=Sequel.connect('mysql://master_server/database', \
    :servers=>{:read_only=>proc{|db| {:host=>db.get_slave_host}}})
  def DB.get_slave_host
    @current_host ||= -1
    "slave_server#{(@current_host+=1)%4}"
  end

Siendo master_server nuestro servidor maestro y slave_server#{(@current_host+=1)%4} nuestros esclavos.

Vamos a hacerlo más aleatorio:

DB=Sequel.connect('mysql://maestro/my_db', \
    :servers=>{:read_only=>proc{|db| {:host=>db.get_slave_host}}})

  def DB.get_slave_host
    slaves = [
      "esclavo_1",
      "esclavo_2",
      "esclavo_3",
      "esclavo_4",
      "esclavo_5",
      "esclavo_6"
    ]
    return slaves[rand(slaves.length - 1)]
  end

Ahora bien, viendo este código, podemos ver ya que la distribución de las conexiones va a ser equitativa, es decir, si tenemos 4 esclavos, cada uno de ellos va a recibir el mismo número de conexiones. Esto en un mundo ideal nos viene bien, pero no nos viene tan bien cuando tengamos alguno de los esclavos con más carga que los demás…

Vamos a darle una vuelta de tuerca. Vamos a tratar de comprobar el estado de los servidores antes de conectarnos, para saber si realmente queremos conectarnos a dicho servidor, o no…

DB=Sequel.connect("mysql://maestro/#{db_name}", \
    :servers=>{:read_only=>proc{|db| {:host=>db.get_slave_host}}})

  def DB.slaves_array
    slaves = [
      "esclavo_1",
      "esclavo_2",
      "esclavo_3",
      "esclavo_4",
      "esclavo_5",
      "esclavo_6"
    ]
    return slaves
  end

  def DB.get_slave_host
    tries = 0
    while tries <= DB.slaves_array.length
      slave = DB.get_slaves_array[rand(DB.get_slaves_array.length - 1)]
      return slave if DB.get_slave_delay <= 1
      tries += 1
    end
  end

  def DB.get_slave_delay(slave, db_name)
    begin
      DBSlave=Sequel.connect("mysql://#{slave}/#{db_name}")
      delay = DBSlave["SHOW SLAVE STATUS"]
      return delay[32].to_i
    rescue
      return 1000
    end
  end

Parte por parte.

Lo que este código hace es simplemente  comprobar si el esclavo al que nos vamos a conectar esta sin retrasos con respecto al maestro y ademas si nos podemos conectar. Para ello, cuando Sequel llame a db.get_slave_host lo que vamos a hacer es lo siguiente:

def DB.get_slave_host
    tries = 0
    while tries <= DB.slaves_array.length
      slave = DB.get_slaves_array[rand(DB.get_slaves_array.length - 1)]
      return slave if DB.get_slave_delay <= 1
      tries += 1
    end
  end

Vamos a sacar un esclavo de la lista de manera aleatoria:

slave = DB.get_slaves_array[rand(DB.get_slaves_array.length - 1)]

Y posteriormente vamos a tratar de conectarnos al esclavo y mirar su estado:

return slave if DB.get_slave_delay <= 1

Esto llama a la función que hemos definido:

def DB.get_slave_delay(slave, db_name)
    begin
      DBSlave=Sequel.connect("mysql://#{slave}/#{db_name}")
      delay = DBSlave["SHOW SLAVE STATUS"]
      return delay[32].to_i
    rescue
      return 1000
    end
  end

Esta función va a comprobar el estado del servidor. Si el esclavo tuviera algún problema, devolvería un retraso elevado (cuando los esclavos tienen mucha carga, suelen retrasarse con respecto a su maestro) o si no podemos conectar, entonces devolverá 1000, dando así un retraso muy elevado indicando que el servidor no esta disponible.

Nota: para que nuestro código pueda preguntar por el estado de los esclavos («SHOW SLAVE STATUS») necesitamos dar privilegios SUPER, REPLICATION CLIENT al usuario que hemos designado a nuestro programa para conectarse a los esclavos:

mysql> GRANT SUPER, REPLICATION CLIENT ON *.* TO 'user'@'domain' IDENTIFIED BY 'password'

En conclusión, si queremos que nuestro código soporte varios servidores esclavos y que compruebe la carga antes de cada conexión, debemos complicar la lógica de conexión a la hora de conectarnos a la base de datos. Las gemas como Sequel nos pueden ayudar a ello con abstracciones de conexión. Es muy sencillo hacer esta comprobación cada vez que nos conectamos. Pero como en todo, este método de comprobación no es escalable a grandes sistemas dado que cada vez que vamos a realizar una lectura, primero hacemos una conexión al esclavo para mirar su estado. Esto hace que la cantidad de conexiones se multiplique por dos.
Mi recomendación es que se trate de hacer un método híbrido donde en paralelo a este código, se compruebe el estado de los esclavos cada vez, y se modifiquen los pesos de cada esclavo dependiendo de dichas comprobaciones. Pero esto corresponde al siguiente post…

La escalabilidad, una asignatura pendiente

Desde hace varios meses, la escalabilidad está siendo mi única materia de estudio y aplicación. No paro de investigar, hacer y deshacer. Y digo deshacer porque una de las cosas más importantes que he aprendido de esta materia es que no se pueden leer blogs aleatoriamente y hacer lo que dicen.

Una vez estuve leyendo un blog de un americano que aseguraba que haciendo una configuración específica a MySQL se podría aumentar su eficencia en la concurrencia. Como no teníamos otra cosa que hacer, lo probamos. Claro, esto de probar las cosas está bien hasta que te pegas el castañazo. Más bien el trompazo. Porque cuando activamos esta nueva configuración, los esclavos de la base de datos empezaron a caer uno detrás de otro como moscas. Menos mal que sólo cambiamos esta configuración en unos cuantos por lo que el portal no sufrió consecuencias y seguía funcionando.

Pero aprendí desde ese momento que cuando alguien en internet habla de escalabilidad o de posibles ideas para solventar este problema tienes que tener claro o seguro que en realidad ha tenido experiencia en ese campo.

Otra anécdota que puedo contar es que en los inicios de tuenti, estábamos otro compañero y yo por la noche haciendo cambios varios sobre la estructura de datos. Hasta que nos topamos con la duda de si aplicar estos cambios a las tablas en el portal. Leyendo la documentación de MySQL 5.0, aseguraba que en un entorno maestro-esclavo hacer cambios en las tablas con ALTER no debiera afectar en absoluto al rendimiento del sistema puesto que el ALTER se realiza sobre una copia temporal de la tabla, por lo que las lecturas podrían seguir sucediendo en la misma tabla durante la operación. Por lo que tanto Kenny como yo decidimos que podríamos hacerlo sin problemas.

Ya podréis saber el resultado de esta acción por cómo estoy empezando esta frase. Si, casi desastre. El maestro comenzó a retener las escrituras sobre la tabla y de esta manera reteniendo las conexiones desde el PHP. Esto hizo que se sobrepasara el límite de conexiones que el servidor tenía previsto -y eso que lo aumentamos en mucho sabiendo que podría pasar… Esto formó una espiral de acontecimientos que nos obligó a cancelar la operación para que el portal no se cayera.

A lo largo de este tiempo, esta son las cosas que creo claves para tener una buena escalabilidad -que es imposible sin experiencia y conocimiento del sector donde te metes , por supuesto:

• Las cosas tienen que ser muy simples: todo lo complicado no es escalable, y menos aquellas cosas que precisamente hacemos complicadas para que escalen. Puesto que la complejidad es el peor enemigo de la escalabilidad.
• Investigación: A la hora de econtrarte con un problema de escalabilidad, probablemente, si no eres uno de los portales más grandes del mundo o con una cierta peculiaridad que no tiene nadie, alguien ha pasado ya por lo mismo que tú. Consulta los blogs, listas de desarrolladores y demás frecuentadas por las personas de otros sitios iguales al tuyo (pero más grandes).
• Priorización: Es muy importante determinar qué cosas son las más importantes para centrarte en la escalabilidad de ellas. Perder demasiado el tiempo en algo que no es importante en tu portal podría mermar otra prioridad que sin embargo necesita ese tiempo.
• Iteración constante en los cuellos de botella: Esta tiene su base en la Administración de Sistemas. Pero en realidad se puede aplicar a todo tipo de disciplina que necesita una escalabilidad. En producto nos econtramos contínuamente con cuellos de botella en el código que no pueden ser resueltos con más servidores…
• Éxito como equipo: Tener en cuenta tus responsabilidades, asumirlas y ejecutarlas es vital para que otros miembros de tu equipo puedan hacer las suyas confiando que tu parte estará hecha. Esto hace que el equipo pueda afrontar los problemas de manera más efectiva.
• Conocer tu plataforma: Tener una buena plataforma y conocerla son claves para poder escalarla. Si estás usando un framework que no conoces por dentro (ruby on rails) puedes encontrarte en una situación donde las propias librerías pueden no ser escalables.

Algunos de estos puntos vienen de leer este comentario en los blogs relacionados con Youtube.