Ella está dura sin ir al gym! Y así es, el hardware es la parte “dura” de nuestros proyectos electrónicos (traducido tal cual del inglés).

Si miramos los desarrollos tecnológicos en los que hay una parte de hardware, los tiempos se disparan. Así como con el software los cambios son rápidos, el hardware es lento y tedioso.

Esto hace de que hablemos que en los coches los diseños tarden 5 años y los desarrollos de 10 a 25 años. La industria es lenta. ¿Pueden startups y makers ser más rápidos obteniendo mismos resultados? ¿Qué diferencia a la gran industria a los pequeños talleres de prototipado del mundo?

Pues vamos a verlo, que el tiempo volando, se va…

Taylor en el mundo del hardware

Lo primero de todo, ¿Es posible competir con la industria? Con dinero sí. Pero también necesitaremos metodología. Y es que con impresoras 3D, talleres y la globalización, lo que pasa es que una empresa pequeña puede acceder a la misma tecnología que las empresas grandes.

Un ejemplo que he encontrado de ello es WikiSpeed. Una empresa que ha creado un coche con una eficiencia de fuel muy alta. Y para ello utiliza a voluntarios y metodologías ágiles. Aquí un vídeo dónde su fundador lo explica todo todito todo:

Scrum, trabajo en parejas, trabajo modular, Test Driven Development… Todo son técnicas utilizadas en el mundo del software para crear un desarrollo más rápido y que sea útil para el cliente.

Lo que realmente está haciendo WikiSpeed es atacar a lo que parece ya ser una vulnerabilidad de las empresas grandes: El taylorismo.

Taylorismo, no eres mío pero te soy fiel

El taylorismo es un método desarrollado por Taylor en 1911. Dicho método sigue siendo utilizado en la mayoría de empresas a pesar de que ya han pasado algunos añicos…

Según Taylor hay 4 fases en el desarrollo de un proyecto:

• Requisitos: Mi cliente me dice lo que quiere punto por punto y es a lo que yo le daré un precio y un tiempo y juntos llegaremos a un acuerdo de qué se entrega, cuando y por cuánto.
• Desarrollo: Realizo las tareas de diseño (mecánico, electrónico, de software,..) del nuevo producto que quiere mi cliente.
• Construcción: Fabrico este nuevo producto.
• Test: Compruebo que el nuevo producto funciona y se lo entrego a mi cliente.

Visto así parece totalmente lógico. De hecho seguro que alguna vez has visto un diagrama de Gantt representando todas las fases de un proyecto. ¡Pero si hasta me lo enseñaron en la carrera!

Pero hay algunas cosas por las que este modelo puede empezar a estar caduco… De hecho en el mundo software ya experimentan con otras cosas…

Cuando Taylor cae no hay vuelta atrás

Este proceso que hemos visto es en cascada, se planifica una cosa y van sucediendo las siguientes. Si alguna vez te ha tocado estar en la parte de “Requisitos” de un proyecto, seguramente ya hayas visto que no somos adivinos.

Siempre o nos faltará más tiempo del presupuestado y nos tocará hacer horas extra para llegar a la fecha de entrega o terminaremos antes de lo previsto por mucho.

Además, si te fijas, dejamos el test para el final. Es decir, suponemos que lo que hacemos va a ir perfecto y que al llegar al final será probarlo y entregar… Así en general, ¿Cuál puede ser la probabilidad de que algo funcione a la primera? O peor, ¿Podemos ir con tantas prisas que nos saltemos esta parte de test para poder entregar a tiempo tal y como habíamos prometido?

Si miramos al inicio, creamos una serie de requisitos que serán fijos durante todo el proyecto. Entonces nuestro cliente no los puede cambiar.

Si empezamos el proyecto de dos años y al pasar un año el cliente se da cuenta que su producto no puede ser de color azul porque no venderá nada de nada… Pues se siente, se lo entregaremos en azul tal y como firmó en los requisitos al inicio del proyecto. Y nos da igual que no vaya a vender nada… Aunque a él sí que le importara y es el que paga…

(Nota: Si le quitamos un poco de drama a esto, lo que pasará es que retrasaremos el proyecto aludiendo este cambio, pero seguro que nos viene de perlas porque ya íbamos tarde. Eso sí, al final entregaremos justo eso y seguramente cobraremos algo más al cliente por “su manía” de querer vender más.)

¿Clases de personas? No lo supimos ver…

Otra cosa curiosa del modelo es que hay dos clases: Los pensadores y los hacedores. Los que se encuentran en las dos primeras fases son gente que se les paga por pensar. Diseñan y negocian los requisitos.

Los del segundo bloque simplemente construyen lo que se les pide y lo testean antes de que llegue al cliente. Esto en una fábrica puede funcionar pero en una empresa pequeña tal vez suene un poco raro…

De hecho, si hilamos fino, podemos encontrar que hay muchas empresas divididas en departamentos. Justo los departamentos se estructuran igual que las fases de desarrollo de Taylor: Están los que gestionan lo que quiere el cliente, los que piensan cómo hacerlo, los que lo hacen y los que lo testean. Vaya… Si que nos ha llegado hondo esta forma de trabajo…

De hecho estos departamentos son estancos y se suelen contactar entre ellos mediante correos electrónicos, cosa que suele relentecer las cosas. Pero, ¿Es eso lo que quiere el cliente?

      He leído y acepto la política de privacidad

 

Información básica sobre Proteción de datos

Responsable ➥ Sergio Luján Cuenca
Finalidad ➥ Gestionar el envío de correos electrónicos con artículos, noticias y publicidad. Todo relacionado con los temas de rufianenlared.com
Legitimación ➥ Consentimiento del interesado
Destinatarios ➥ Estos datos se comunicarán a MailRelay para gestionar el envío de los correos electrónicos
Derechos ➥ Acceder, rectificar y suprimir los datos, así como otros derechos, como se explica en la política de privacidad
Plazo de conservación de los datos ➥ Hasta que se solicite la supresión por parte del interesado
Información adicional ➥ Puedes encontrarla en la política de privacidad y el aviso legal

Agile, nadie lo sabe hacer como tú lo sabes hacer

El cliente lo que quiere es que le enviemos su producto lo más rápido posible y con la mejor calidad posible. Y si puede hacer cambios, pues mejor. Es aquí dónde entra la agilidad, que como ves, se centra en el cliente de lleno.

Este término engloba algunas metodologías (En realidad ahora se les llama frameworks pero lo dejo como metodología para que lo entiendas mejor. Perdóname si eres un agilista hecho y derecho y este término te puede llegar a sangrar tus bellos ojos.) que lo que buscan es romper este ciclo en partes más pequeñas. En iteraciones.

¿Qué pasaría si en el caso de nuestro cliente anterior, tuviésemos dos reuniones de requisitos: Una al inicio y otra al primer año? Pues que nuestro cliente podría cambiar su producto de azul a verde sin problemas y ya no perdería dinero con su nuevo producto.

Pues imaginemos esto de una manera cíclica cada dos semanas. Aquí ya parece que somos más ágiles porque somos capaces de adaptarnos a los cambios que nuestro cliente necesita para vender más. Además, testearíamos más veces y eso nos daría una mejor calidad de manera que no nos saltaríamos este paso por falta de tiempo.

El tiempo volando, se va. Pero eso ya lo sabías…

Tiempo… Claro, ya no podemos basarnos en fechas tan fijas e inamovibles, pero yo creo que si a nuestro cliente le estamos entregando partes de su proyecto cada poco tiempo, seguramente no tenga la mirada tanto en la fecha de entrega como en lo bien que se adapta el producto a sus necesidades.

Además, vamos a estar más pendientes del producto ya que no hay fechas muy lejanas, sino que tenemos entregas tempranas de una funcionalidad que se pueda utilizar. Esto nos hará más rápidos y buscando siempre ofrecer valor a nuestro cliente por lo que poco a poco eliminaremos actividades que no ofrecen valor (reuniones eternas, papeles que pueden llegar a ser innecesarios, hilos eternos de mensajes, etc..).

Un ejemplo de esto son las comunicaciones. En una gran empresa en la que se envían correos electrónicos, si hay algo muy muy urgente, se terminan los correos y se pasa a las llamadas telefónicas y a las reuniones cortas que atacan directamente al problema. Esto es una acción ágil ya que el problema se resuelve al momento (Y esto a nuestro cliente, le gusta. Y si a él le gusta a mí me encanta…).

Y también quedaría ver que, tal vez, hacer pequeñas iteraciones utilizando las cuatros fases de Taylor cada dos semanas no sea lo mejor y hay otros métodos como el del Test Driven Development del que habla el vídeo. En este método primero se testea la funcionalidad, si no está incluida ya se crea y se vuelve a testear. Se piensa primero en cómo comprobaremos que funciona el requisito que se nos pide y luego se hace.

¿Cómo se siente? ¿Cómo se siente?

Y no me enrollo más. Creo que las empresas pequeñas pueden ganar mucho terreno a las grandes porque ya por definición, tienen menos burocracia y eso las hace más ágiles.

Lo que puede llevar a que empresas grandes quieran ser ágiles también, ya que en definitiva el cliente quiere que lo suyo le llegue pronto y bien, nada más.

Y hasta aquí el post, que es un simple experimento. Todo lo explicado aquí es la base y sirve tanto para hardware como para software, Si quieres que nos sigamos adentrando para buscar ideas específicas para el desarrollo de hardware, escríbeme un comentario.

Si conoces algo sobre el tema, escríbeme también. Y si te ha gustado, comparte en redes sociales a jierrooooooooo!