Una startup, llamada FakeEnterprise, necesita desarrollar una aplicación para ejecutar esa gran idea que tienen en mente. Dentro de su equipo no hay ningún integrante con un perfil informático, por lo que no tiene la capacidad para desarrollar por si mismo esa aplicación. Así, FakeEnterprise debe recurrir a una empresa externa para que concrete esa gran idea en la forma de una aplicación que sus clientes amen. Dada la condición de startup el presupuesto es limitado, por lo que la aplicación tiene que funcionar “a la primera”, ¿cómo elegir a la empresa adecuada para esta importante misión?

Este artículo ahondará en este escenario ficticio, pero muy habitual, con el objetivo de mostrar por qué FakeEnterprise debiese optar por una empresa que use metodologías ágiles como la encargada de desarrollar la aplicación que necesitan. Y, también, por qué cualquier empresa que quiera desarrollar un software con una empresa externa debiese optar por un proveedor que use metodologías ágiles.

‍

¿Qué tan definida está tu idea para transformarla en una aplicación?

Al hacer esta pregunta, los fundadores de FakeEnterprise se emocionarán explicando su idea y dando argumentos de por qué es la mejor idea de la historia. El clásico pitch, casi aprendido de memoria, apoyado por un prototipo de baja fidelidad diseñado con alguna herramienta en línea. Todo suena bien, la idea es clara y sencilla de comprender, aún más si se puede visualizar el flujo en el prototipo. Hasta ahí todo bien, hasta que algunas personas de las empresas externas con las que se está cotizando el desarrollo de la aplicación empiezan a hacer preguntas sobre el cómo debería funcionar la aplicación en términos más concretos. El qué y el por qué de la idea están claros, pero estas preguntas sacan a la luz escenarios no considerados con anterioridad. En definitiva, hacía falta definir el cómo de la idea en su nivel técnico, el cual sólo puede ser determinado con propiedad por alguien con conocimientos técnicos.

Luego de un par de reuniones, y de un análisis de alto nivel de la idea por parte de las empresas de desarrollo, FakeEnterprise recibe varias propuestas y/o cotizaciones, todas diferentes unas de otras. Así, surge entre el equipo la duda sobre qué tan definida está la idea y su propuesta de valor realmente. Si la idea era tan clara, ¿por qué todos entendieron cosas diferentes?

‍

La intangibilidad del software lo vuelve peligroso

Es muy difícil saber qué es lo que se necesita de un software antes de usarlo por primera vez. Y esto es así, porque mientras esa idea de aplicación viva sólo en la imaginación de sus “ideadores”, es posible que todo el resto se la imagine de una forma diferente. De hecho, es bastante probable que incluso cada una de las personas que ideó la aplicación se la imagine de una forma diferente.

¿Está mal que cada cual se imagine una misma aplicación de diferentes maneras? Para nada, así funcionan los intangibles. Si a 10 personas diferentes se les pidiera que imaginaran un sentimiento como el amor, ¿cuántas formas de amor habrían? Lo más seguro es que 10, por que cada persona lo imaginará a su manera.

La naturaleza intangible del software provoca que cada cual se lo imagine a su manera. De hecho, esto llega al extremo de que una misma idea de aplicación puede ser desarrollada de tantas formas como desarrolladores existan. Si bien la existencia de un prototipo concretiza (de cierto modo) lo que se quiere realizar, lo cierto es que sólo acerca las expectativas de los diferentes actores involucrados en relación a la interfaz de usuario de la aplicación, pero el resto sigue estando en el mundo de lo intangible en forma de unos y ceros.

‍

Haciendo que lo intangible se vuelva tangible

Siguiendo la idea anterior, para que un software se vuelva “tangible” (hasta cierto punto) es necesario usarlo en un ambiente real. A partir de ese punto, todas las versiones imaginadas del software colapsan hacia una única versión, desde la cual se puede seguir avanzando. Claramente, para lograr esto es necesario que el software exista y pueda ser utilizado.

El equipo de FakeEnterprise se encuentra en fase de idea y, más allá del prototipo de baja fidelidad, aún no tiene una versión funcional del software desde el cual pueda seguir avanzando. ¿Cuál es su mejor opción en este escenario?

‍

Metodologías ágiles al rescate

La mejor opción para FakeEnterprise es, sin duda, seleccionar a una empresa que desarrolle software utilizando metodologías ágiles. Esto dado, principalmente, por los cuatro principios que guían estas metodologías:

1. Individuos e interacciones sobre procesos y herramientas
2. Software funcionando sobre documentación extensiva
3. Colaboración con el cliente sobre negociación contractual
4. Respuesta ante el cambio sobre seguir un plan

Cada uno de estos principios supone una ventaja considerable para FakeEnterprise, dado que:

1. Es preferible la interacción directa con un equipo externo que sea capaz de concretizar la idea que tienen en mente a incorporarse a una maquinaria productiva que desconocen completamente
2. El software funcional entregado de manera continua y periódica permite que todos en FakeEnterprise hablen sobre lo mismo, olvidándose de la incómoda documentación técnica
3. La empresa proveedora estará más preocupada de alcanzar una aplicación que todos amen que de cumplir un contrato
4. Será posible realizar modificaciones al plan inicial si la aplicación, tal y como se la habían imaginado, no era tan buena idea como se pensaba

Si a estos cuatro puntos se agrega el uso de Scrum (un framework metodológico ágil) hay que sumar que:

1. La ritualización de las reuniones de trabajo mejorarán el rendimiento de todo el equipo (de FakeEnterprise y de la empresa desarrolladora)
2. El ajuste continuo y constante de las funciones del software permitirán siempre aportar el máximo valor posible a todos los involucrados
3. La incorporación de feedback continuo dentro de las diferentes iteraciones le permitirán al equipo funcionar cada vez de mejor manera

Con el apoyo de una metodología ágil, el equipo de FakeEnterprise puede bajar la incertidumbre que supone construir la aplicación con una empresa externa y mantener la preocupación sobre lo que es más importante: aportar valor a sus clientes. Además, si es que la empresa desarrolladora no fuese tan buena como se pensaba, la agilidad permitirá detectar esto a tiempo y detener el desarrollo lo antes posible, minimizando el impacto de costos que esto trae consigo.

‍

¿Tiene algún contra usar metodologías ágiles?

Depende. Usar metodologías ágiles exige una alta colaboración y disposición del cliente. En este caso, el equipo de FakeEnterprise es el que mejor conoce su negocio y su propuesta de valor, por lo que tendrá que estar disponible cada vez que la empresa desarrolladora lo necesite. Esto es un problema para algunas empresas, dado que tienen una exigencia de tiempo considerable. Pero si FakeEnterprise quiere que la aplicación sea tan genial como soñaron, debiesen estar felices de poder estar involucrados en todo momento dentro de los procesos que se están llevando a cabo y asegurarse de que siempre se está aportando el máximo valor posible. Si lo anterior no significa un problema, entonces las metodologías ágiles no presentan inconvenientes por si mismas.

Ante tanto beneficio, es muy probable que el equipo de FakeEnterprise (y cualquier otra empresa en su situación) haya optado por una empresa desarrolladora que hace uso de metodologías ágiles. Pero, ¿qué habría pasado si hubiese más de una empresa que ofrecía trabajar con este tipo de metodologías?, ¿en qué debiese fijarse el equipo de FakeEnterprise? Todos estos temas (y más) serán abordados en futuros artículos. Suscríbete a nuestro newsletter para no perderte de ninguno de ellos.