Guía de cómo encontrar el partner ideal para desarrollo de apps. Encuentra a tu dragón.


Introducción

Encontrar una empresa de desarrollo de aplicaciones móviles es muy fácil, lo difícil como siempre es encontrar la mejor para tu proyecto. Por eso tan a menudo se compara esta búsqueda con la de un dragón. Un animal mítico del que todo el mundo habla mil maravillas pero que parece imposible de encontrar. (Realmente se habla más a menudo de un unicornio pero quien quiere un unicornio cuando se puede tener un dragón?)

¡Pues no! Es posible encontrarlo, pero es duro, largo y arduo. Este artículo te va a ayudar a encontrar a este partner, conociendo cuáles son los parámetros y criterios que tienes que tener en cuenta a la hora de elegir al mejor aliado para tu proyecto.

No es una guía definitiva, ni exhaustiva, para eso haría falta un libro y re-escribirlo cada semana, pero sí que puede suponer “un kit busca tu dragón” para el responsable del laborioso trabajo de elegir el partner idóneo de desarrollo de aplicaciones móviles.

En definitiva, hoy vas a dar el primer paso hacia el éxito de tu proyecto y todo comienza por encontrar el mejor partner para este largo viaje.


1. PORTAFOLIO

Empezaré con las obviedades: Pedir al partner sus casos de éxito, su portafolio. No es cuestión de saber si han desarrollado 500 apps o solo 10. En primer lugar, porque no buscas un supermercado de Apps, sino el mejor partner para tu proyecto. Y en segundo, porque la cantidad y la calidad son conceptos muy diferenciados.

Lo que realmente nos interesa dentro de este portafolio son los siguientes criterios:

B2C (Business 2 Customer) y/o B2B (Business 2 Business)

Tienes que elegir una empresa que te pueda garantizar que conoce el público que se corresponde con tu App. Desarrollar para una empresa (B2B) o un usuario final (B2C) no es lo mismo. Está claro que a nivel técnico no hay diferencia, sin embargo, la experiencia que pueda tener tu partner con uno o otro público te permitirá no cometer errores que él ya conoce y ha resuelto en el pasado.Por ejemplo, los métodos de alta de registros o de autentificación cuando hablamos de B2C o B2B son completamente distintos (login social vs login empresarial), el despliegue en los markets, la petición de datos (cuidado con los formularios), etc… Así que si tu app es B2B asegúrate de que el partner tiene experiencia con apps B2B e igualmente para las aplicaciones B2C.

Experiencia Startup o/y Fortune 100

Lo que necesitas saber es si el partner tiene experiencia con empresas del tamaño de la tuya. Desarrollar una app para una startup o una gran corporación del Fortune 500 no es lo mismo.

Trabajar con una startup requiere (mucha) rapidez, agilidad, a veces saltarse procedimientos o buenas prácticas para alcanzar un objetivo de mayor importancia como comprobar la validez de un key feature antes de desarrollarla adecuadamente. Llegar a todas las plataformas (iOS, Android, etc.) no es una prioridad, más bien, lo que se busca es llegar pronto a una y validar el concepto/producto. Aquí una experiencia del tipo lean-startup es más que recomendable. Lo que buscas es el partner hermano mayor que te vaya guiando en esta larga travesía.

En el caso de las grandes corporaciones, aunque la agilidad y la rapidez también son importantes, en muchas ocasiones existe un legacy importante, una burocracia con la que lidiar, una carga de trabajo de gestión y comunicación mucho más densa y muy necesaria, unas reglas que no se pueden y no se deben saltar, etc. Tener un partner que ya conoce las reglas del juego representa un activo de mucho valor a la hora de anticiparse a estas limitaciones y riesgos corporativos internos, que más de una vez pueden hacer peligrar las fechas de entregas y/o los costes del producto hasta su existencia.

Kit dragón:

  • No busques el que haya hecho muchas apps sino buenas apps.
  • Busca quien tenga experiencia en tu público de aplicaciones (B2B o B2C).
  • Busca quien tenga experiencia con empresas de tamaño similar a la tuya (startup, pymes o Fortune 500)

2. RECOMENDACIONES.

No hay nada como pedir referencias a los clientes del posible partner una vez visto el portafolio. El portafolio no es suficiente y sé que llamar para pedir referencias puede parecer una tarea poca apetecible pero imagínate haberte tomado la molestia de buscar los datos de contactos de los clientes (pídeselos al partner) para llamar a un cliente cuya app está en el portafolio y haber recibido una de estas respuestas:

  1. “Ha sido un verdadero placer trabajar con ellos. Son muy profesionales, proactivos. Todo ha sido entregado a tiempo y cuando ha ocurrido un problema han sabido gestionarlo con transparencia, honestidad y profesionalidad. Os los recomiendo sin ninguna duda.”
  2. “Ha sido un desarrollo muy complicado. Desde el primer momento hemos tenido problemas de comunicación y el resultado final no nos gustó del todo. La verdad es que no creo que volvamos a trabajar con ellos.”

Son dos ejemplos extremos, lo reconozco. Tendrás respuestas que te ayudarán a resolver dudas sobre quién escoger y quién no. Con sólo unas pocas llamadas puedes tener un filtro increíblemente potente sobre la calidad del trabajo y del servicio.

Kit dragón:

  • Si el partner te entrega los datos de contactos de sus clientes es buena señal.
  • Llámales o escríbeles. Esta comunicación te puede ahorrar mucho sufrimiento, molestias, pérdida de tiempo y sobre todo dinero.

3. APP NATIVAS, HÍBRIDAS O FRAMEWORK-MADE.

Aunque tú tengas muy claro lo que necesitas y por qué, te invito a preguntar a tu posible partner que te diga qué recomienda él. El objetivo aquí no es saber si tu decisión es o no correcta (aunque nunca sobra tener una opinión experta y externa), sino conocer su experiencia en este tipo de desarrollo completamente distinto y su opinión en cuanto a aplicar uno u otro en función de los objetivos y/o requisitos del proyecto.

Aquí no se trata de lanzar el debate de si es mejor una app nativa, híbrida o generada sino averiguar cuál es la experiencia real del partner con cada una de estas soluciones y ver por qué nos podría estar recomendando hacerlo de una forma o otra.

Un partner que puede enseñar ejemplos de cada uno de los tipos y justificar el por qué ha elegido dicho tipo de desarrollo denota una proactividad en cuanto a mejora continua de sus procedimientos y sus herramientas, y eso siempre es buena señal.

De la misma manera, una empresa que te vaya a recomendar solo un tipo de desarrollo, sobre todo si es usando un framework de desarrollo tipo PhoneGap, suele ser mala señal. Es verdad que estos frameworks existen porque responden a una problemática real y en ciertas ocasiones son la mejor solución, pero muchas empresas los usan porque realmente el desarrollo nativo es más complicado y no tener equipos altamente cualificados supone asumir un gran riesgo en cuanto a la rentabilidad de los proyectos y, por consiguiente, prefieren proponer frameworks que usan lenguajes más antiguos y más conocidos, donde los riesgos son mucho menos elevados, además de ser válidos para varias plataformas, con la consiguiente reducción del coste.

Las apps nativas cuestan mucho más dinero. Requieren más tiempo de desarrollo y tienen tantos puntos negativos como positivos, frente a sus equivalentes híbridos o apps nativas generadas por frameworks de desarrollo de apps. En función del tipo de mercado, de usuario final, del objetivo buscado, se podrá elegir un tipo u otro. En caso de optar por un desarrollo basado en un framework, es importante poder probar una app del portafolio del partner generada con este framework. El principal problema de estos desarrollos es que no suelen tener el acabado de los desarrollos nativos y seguramente cumplen perfectamente con las principales funcionalidades, pero pecan a nivel de detalles y en el caso de una app de producción (no hablo de pilotos o pruebas de concepto) los detalles son lo que marcan la diferencia.

Kit dragón:

  • Siempre preguntar si es mejor una solución nativa, híbrida o generada por un framework y la justificación de esta elección.
  • Mirar en el portafolio del partner si hay ejemplos de cada tipo.
  • En caso de elegir una app generada, siempre probar los ejemplos de app generada del portafolio para averiguar el “acabado” de dichas apps.

4. UI/UX

Es una parte fundamental de la app. El usuario final es muy exigente y si la usabilidad no es mínimamente aceptable, el usuario no tardará ni un segundo en desinstalar la app y en algunos casos en poner una reseña negativa en los markets. Así que es importante poder comprobar que las apps de referencia tengan una gran calidad a nivel de UX. El trabajo de UX, no es un one shot, sino un trabajo progresivo, donde se va mejorando la interfaz a base de error, pruebas y correcciones. Por lo tanto, no dudes en pedir un ejemplo del trabajo de UX no sólo con el resultado final sino la evolución desde los primeros sketches (hechos a mano seguramente) hasta los diseños finales. Será una muestra clara y transparente del trabajo realizado. Además podrás comprobar el cuidado por los detalles, así como saber qué tipo de entregables recibirás si eliges dicho partner.

Verificar que el equipo de UX entiende y respeta las guías de estilo oficiales de iOS y android. Obviamente, son recomendaciones que se pueden saltar en función de las necesidades de cada app. Sin embargo, antes de saltarse las normas, hay que haberlas dominado. Así que la empresa deberá poder enseñar sin problemas algunos ejemplos de apps, respetando material design para android o los guidelines de iOS.

Averigua si la empresa tiene una metodología de trabajo entre el equipo UX/UI y el equipo de desarrollo front. Si tienes experiencia en el desarrollo software sabrás que existe una vieja lucha entre los desarrolladores y los diseñadores, y por haberlo vivido en el pasado, es algo que perjudica al ambiente, la comunicación, las fechas de entrega y, en general perjudica al producto. Esto es algo que se puede evitar fácilmente si existe una metodología clara de trabajo. Si se ha definido desde el inicio un marco de trabajo, un sistema de comunicación, unas herramientas validadas por ambos lados, etc. Esta metodología ayudará a disminuirá cualquier riesgo inherente a la integración de trabajos de áreas distintas, permitirá una relación de colaboración para el bien del producto. Y el último y no menos importante, ayudará al cliente a centrarse en el producto y no en la gestión de los egos.

Otra buena manera de validar la experiencia que puede tener la empresa en cuanto a UI / UX es conocer las herramientas que usan y por qué. Es verdad que existe una gran variedad de herramientas y cada una tendrá sus ventajas y sus inconvenientes, por lo que una empresa capaz de proponer una herramienta y justificar su uso y no otra, es una buena señal de experiencia, de haberse pegado con dichas herramientas con antelación y conocer sus puntos débiles y sus puntos fuertes. También el uso de nuevas herramientas (menos conocidas) es una señal de proactividad en cuanto a la búsqueda de mejoras de sus procesos hacia la excelencia.

En caso de contratar el desarrollo y el UI/UX por separado, no olvidéis que el equipo de desarrollo y el de UI /UX, así como el product owner, tienen que trabajar conjuntamente desde el principio. Si se hace el trabajo de UI / UX por separado y se entrega luego al equipo de desarrollo es un error que se acabará pagando con cambios, fricciones personales y labores extras. El equipo tiene que colaborar desde el primer momento para eliminar cualquier riesgo de pérdida de tiempo, costes adicionales y aprovechar al máximo los conocimientos de cada uno, la inteligencia colaborativa.

Kit dragón:

  • Conocer la metodología de trabajo.
  • Buenas referencias de UI / UX en trabajos anteriores.
  • Ejemplos siguiendo las guías de estilo oficiales.
  • Herramientas de trabajo justificadas y validadas por ambos lados.
  • En caso de no encargarse del UI/UX, la empresa de desarrollo debería pedir intervenir desde el inicio.

Pregunta frecuente:

P: La gran mayoría de las apps del portafolio de una empresa tienen un UI / UX muy bueno pero algunas otras parecen de nivel inferior ¿Es mala señal?
R: Ni mala ni buena señal. En algunas ocasiones, el cliente final puede imponer el equipo de diseño para el proyecto. El equipo puede no tener la experiencia suficiente como para entregar la mejor interfaz posible. En estos casos es importante preguntar cuáles son los UI/UX que han venido impuestos por el cliente, y si es tu caso, mejor elegir un equipo de desarrollo que ya haya tenido la experiencia de colaborar con un equipo de diseño externo, porque estará acostumbrado a una comunicación seguramente más fluida y, sobre todo, sabrá manejar y anticiparse a los riesgos que conlleva trabajar con un tercero que puede que no tenga toda la experiencia necesaria o simplemente que no esté completamente integrado dentro del equipo de desarrollo.

5. METODOLOGÍA

Tener definida una metodología (la que sea) y saber aplicarla es clave. Asegura que existe la voluntad de hacer que los éxitos sean repetibles en el tiempo y que no se vuelvan a cometer los mismos errores. Como cliente es indispensable asegurarse de elegir un partner que tenga esta preocupación, que tenga definida una metodología, que pueda justificar de cada uno de sus pasos, informar sobre las herramientas utilizadas, las tareas a realizar por cada participante (cliente incluido) y obviamente pueda mostrar pruebas de ello. Esto es muy sencillo, puesto que seguir una metodología es una fuente de datos, informes, puntos de control (evaluación) y localización de posibles optimizaciones que no dejan dudas de si se debe utilizar o no.

Aplicar una metodología efectiva conlleva un aumento significativo del volumen de horas de gestión pero es un coste necesario. Acaso subirías en un avión donde te dicen que te vas a ahorrar el 10% del precio del billete porque se van a saltar las metodologías o normas de seguridad que se aplican para asegurar que el vuelo despega y aterriza sin problemas.

Kit dragón:

  • Averiguar la metodología de trabajo que emplea el partner.
  • Pedir muestras de trabajos anteriores fruto de esta metodología.
  • Preguntar por los hitos, los entregables (informes o dashboards) y las herramientas inherentes a dicha metodología.

6. AUTOMATIZACIÓN Y TESTING

La automatización de los proceso es clave en cuanto a desarrollo de apps. Las personas que ya han vivido un desarrollo con un partner que no tenía automatizados sus procesos os podría contar cómo cada versión subida arreglaba errores visibles pero generaba otros nuevos problemas. Y así hasta perder totalmente la confianza en cualquier subida de nueva versión, con lo que esto conlleva de cara al usuario final y las tasas de desinstalación.

A día de hoy, no tener implementado dentro de la metodología de desarrollo una automatización de los tests, sean estos tests unitarios de integración, funcionales, de sistemas o de aceptación), es asumir un nivel alto de riesgo. El partner no va a entregar un producto 100% sin error, es imposible. Y los que lo venden así, mienten. No lo consigue ni la NASA con todos sus medios… y perdón por comparar mandar gente al espacio con hacer una App pero la realidad es que siempre aparecen errores y detalles que pulir. No existe el producto perfecto. Por eso hay que reservar los días previos a la entrega a producción para resolver estos detalles. Para que efectivamente sea un trabajo de pulido es indispensable tener todos los tests automatizados con el fin de asegurarse que cada versión entregada no sólo resuelve los errores detectados sino que además no haya dañado nada de lo anterior. Esto no es posible si el testing es manual o parcialmente manual.

Así que si vuestro partner no os presenta su metodología de desarrollo y despliegue con un sistema automatizado, el riesgo de asumir cualquier imprevisto en coste y/o tiempo será muy alto.

Del mismo modo, deben existir unos procedimientos de integración y despliegue continuos. En las fases finales del desarrollo es muy normal tener varias entregas de versiones que permitan validar rápidamente la implementación de una funcionalidad nueva, una modificación o la corrección de un bug. Así que no dudéis en averiguar cuáles son los procesos automatizados, cuáles son las herramientas utilizadas y preguntar para poder examinar un caso real. Es la mejor manera de asegurarse de que tu partner no deja nada al azar.

Una buena señal para conocer el grado de automatización de los procesos es saber si dentro del equipo existe la figura del DevOps. En los proyectos de cierto tamaño las tareas de automatización requieren un trabajo importante de automatización en cuanto a despliegue, integración y testing que recaen en la figura del DevOps.

Kit dragón:

  • Averiguar los procesos automatizados existentes dentro de la metodología.
  • Validar las fases de testings y los distintos tests que se vayan a realizar.
  • Pedir información sobre las herramientas utilizadas para la automatización.
  • Pedir ver un ciclo completo de un desarrollo anterior con el fin de observar cómo trabaja y evalúa su propio trabajo el partner.

7. TRANSPARENCIA Y HONESTIDAD

Todos compramos en el supermercado. Es muy cómodo y más barato. Sin embargo, cuando a uno le toca preparar una cena importante, le gusta ir a comprar el pan a la mejor panadería o ir a ver a su sommelier para que le recomienda la botella perfecta para dicha cena.Lo mismo ocurre con tu proyecto. No haces apps cada semana. Este debe ser un proyecto importante y por eso debes confiar esta tarea a los mejores profesionales. Necesitas un equipo experto, que cuida su trabajo porque lo ama y que hace del desarrollo un estilo de vida.

Si tu posible partner tiene un equipo experto y experimentado para el desarrollo, es un punto más que positivo porque significa que entiende y se dedica este negocio. No hay de nada malo en subcontratar a gente experta.Al fin y al cabo, lo que importa realmente es que sean los mejores profesionales para conseguir el mejor producto y cada persona o grupo aporta su valor al conjunto del proyecto. Es un trabajo en equipo. Desde mi punto de vista la relación con todas las personas tiene que ser transparente desde el primer momento como base de una buena relación de trabajo. Yo aporto valor aquí y tengo una red de profesionales que aportan valor allí, y conjuntamente vamos a hacer el mejor producto del mundo. Cualquier intento de ocultar un hecho como este debería de ser visto como una señal del apocalipsis.

La honestidad y la transparencia son la base de toda relación sana y no puedes pedir menos a tu partner de tecnología.

La transparencia durante el desarrollo, como digo,es una necesidad absoluta. Por eso es importante conocer la metodología de desarrollo del partner. Ciertas metodologías implican una gran transparencia porque se da cuenta y se muestra todo lo referente al desarrollo, el trabajo realizado, los problemas encontrados, las fechas de entregas, múltiples y regulares hitos con su correspondiente entrega de un versionado del producto final. Esto te permitirá saber en todo momento en que está trabajando el equipo, su velocidad y tener una visibilidad completa sobre el avance del proyecto. En caso de usar una metodología ágil (agile), dicha transparencia también se tiene que notar por la posibilidad por parte del cliente de participar en las reuniones diarias del equipo (daily stand-up) y obviamente en las reuniones de sprint review y sprint planning.

Kit dragón:

  • Averiguar si el posible partner será un gestor de equipos externos, y si es así, que sea transparente y honesto, de tal modo que sepas cual es el valor que aporta cada parte del equipo.
  • Averiguar si la metodología de desarrollo usada por el partner te da la visibilidad suficiente sobre el desarrollo.
  • Cualquier engaño deberá ser vista como una señal de mala praxis o la crónica de una muerte anunciada.

8. PROACTIVIDAD

Como habrás notado nunca he usado la palabra “proveedor” hasta ahora porque tengo claro que lo que buscas no es un proveedor sino un partner. Un partner se involucra en el proyecto, es alguien con quien puedes ir a la batalla con los ojos cerrados (coding is a war), es una relación de confianza y a largo plazo.

Involucrarse en un proyecto significa mostrar proactividad en todo momento. Significa que puede aportar valor a tu producto o servicio. A nivel técnico, en el mundo desarrollo de apps, tu partner sabe más que tú . Es normal ya que es su especialidad, con lo cual, es importante que en una posible respuesta a un RFP tenga un apartado específico sobre recomendaciones tecnológicas y otro dedicado a mejoras fuera del ámbito del proyecto que aportan valor. Como todo en la vida, si no te aporta valor, entonces no te sirve.

Un partner involucrado y proactivo será el que te propondrá ideas desde el principio porque desde el primer momento hará suyo el proyecto. Y eso es algo que agradecerás en el futuro, en cuanto surjan las dudas, los posibles evolutivos, etc. Entonces sabrás que podrás apoyarte sobre este partner y no te sentirás solo en el duro camino del desarrollo sino que estarás muy bien acompañado y recibirás ayuda en caso de que tengas que justificar cosas a nivel interno de tu empresa. Así es como se construyen los mejores productos: ¡juntos!

Kit dragón:

  • Averigua la proactividad de tu partner.
  • Pregúntale cómo son sus flujos de comunicación con sus clientes para verificar su actividad.

9. CONOCIMIENTO BACK

Lo más probable es que tu aplicación sea transaccional y que, por lo tanto, tu app necesite conectarse a un plataforma de backend para realizar procesos de compra (catálogos, pasarelas de pago o reservas, etc.) y/o almacenar datos. Como dije antes,la colaboración equipo desarrollo-equipo UX es importante. Debe existir esta misma colaboración entre equipo front (App, lo que ve el usuario) y back (la tecnología que opera y que no se ve). Aunque hoy en día una capa API-REST es el estándar de facto, para que su definición sea perfecta, los dos equipos tienen que trabajar conjuntamente.

No vale que el equipo back entregue unos servicios ya definidos porque lo más probable es que no estén perfectamente adaptados al front ni a la App. Probablemente se podrán aprovechar pero seguramente duplicando funcionalidades o añadiendo trabajo en la parte de la App. Si el desarrollo back se hace en paralelo al desarrollo de front, la capa API estará en cambios constantes y es importante que los dos equipos hayan definidos previamente no sólo un diccionario de servicios completos y documentos (o por lo menos documentado en tiempo real) sino que también existan unos servicios mocks para poder simular el back (qué no disponible todavía) y permitir al equipo de front trabajar de forma eficiente, además de otros sistemas de pruebas automatizadas que le permiten saber en todo modo en qué estado está la capa de comunicación y, de este modo, poder descartar fácilmente el origen de los problemas que surgen.

En un escenario perfecto, es recomendable que el back y el front se hagan con el mismo partner porque seguro que cuenta con equipos acostumbrados a trabajar juntos, con sus metodologías ya implantadas, conocidas y aceptadas por ambas partes. Una colaboración entre equipos externos es posible pero nunca será tan transparente y efectiva como dos equipos del mismo partner que siguen siempre un mismo protocolo, basado en la experiencia, que les asegura la calidad y la eficiencia.Con el fin de conocer dicha experiencia sobre la integración con sistemas de backend, es importante ver cuáles son las herramientas que propone en cuanto al consumo de la API (documentación, sandbox, mocks, analytics, seguimiento, etc..). Es una buena muestra de la madurez del partner en cuanto a la app transaccional y las problemáticas relacionadas con el intercambio de datos entre varios canales.

Kit dragón:

  • Elegir un solo partner que haga front y back, que cuente con ambos equipos.
  • Si solo se requiere un partner de desarrollo App, averiguar su experiencia con el trabajo con equipos externos (metodología, herramientas, flujos de comunicación, etc).
  • Pedir al equipo back que hable con el equipo del partner para validar el nivel técnico en cuanto a la parte back para que la comunicación sea completamente fluida.

Pregunta frecuente:

P: La mayoría de las empresas nos están ofreciendo para gestionar la API productos como MuleSoft o 3Scale. En cambio, otras no ¿Cómo lo tengo que interpretar?
R: — ¿Realmente necesitas estos productos? De las 20 features que puedan cubrir estos productos (con costes recurrentes) ¿cuántas necesitas para tu producto? A veces, algunas empresas ofrecen este tipo de productos por otro tipo de intereses mercantilistas. ¿Comprarías un avión para ir a comprar el pan?

10. SEGURIDAD

Podría empezar el párrafo recordando algún caso de app que tenía importantes fallos de seguridad. Fallos que fueron aprovechados por terceros y que tuvieron graves impactos en imagen, negocio, financiero, legal, etc. Esto sobraría porque, a día de hoy, todo el mundo sabe que la seguridad es un punto clave en cualquier desarrollo y más cuando se trata de productos distribuidos (descargado, instalado y donde las actualizaciones son mucho más complicadas de conseguir comparado con un servicio web).

El partner que no tiene una política estricta y una metodología completa de pen-testing así como una metodología de buenas prácticas en cuanto a la seguridad a nivel de desarrollo, asume un alto riesgo de tener un producto fácilmente explotable por terceros.

Mi recomendación es que el partner tenga un equipo dedicado a las tareas de pruebas de tipo pen-testing, distinto al de desarrollo. En función del tipo de aplicaciones que contrates, los servicios de una empresa especializada en seguridad informática para que haga hacking ético, variarán con el fin de verificar que no existen fallos de seguridad en tu producto.

Esto obviamente encarece el producto y como suele suceder, puede que no sea una necesidad absoluta y prefieras invertir el dinero en nuevas funcionalidades. Es una cuestión de estrategia de negocio y de gestión de riesgo.

El pen-testing no es un trabajo que se ejecuta una vez sino que se trata de un trabajo que se tiene que realizar con cierta frecuencia. Cada día aparecen nuevos agujeros, hacks, además de los distintos evolutivos de tu producto con su correspondiente riesgo. Con lo cual si contratas (y deberías hacerlo) el servicio de soporte a tu partner, verifica que este incluya tareas de pen-testing programadas.

Kit dragón:

  • Ver si el partner tiene una metodología de buenas prácticas para el desarrollo.
  • Ver si tiene una metodología de pen-testing que vaya a aplicar antes de la entrega final.
  • Ver si tiene informes de hacking ético de terceros sobre su portafolio.

11. EQUIPO

Vas a trabajar con un partner, sí, pero sobre todo con un grupo de personas. Vas a confiar en que estas personas sean las mejores para tu proyecto, que fluya la comunicación, que tengan la experiencia suficiente, que sean los expertos que estén deseando tener a tu lado. Por eso es importante que puedas pedir (lo normal es que te lo proporcione el partner) la lista de las personas que vayan a trabajar en tu proyecto. Esto no sólo ayuda a la transparencia sino que es un seguro más para poder averiguar que estas personas son los profesionales que esperas. Hoy en día, con servicios como LinkedIn o Github es muy fácil ver la “calidad” del equipo, su experiencia, hasta la calidad de su código en algunos casos.

Poder comprobarque algunas personas no acaban de entrar la semana pasada dentro de la compañía. Esto daría a entender que el partner las han contratado para tu proyecto, lo cual no significa que no sean las mejores, pero en todo caso, no tienen la misma integración dentro del equipo que otras personas con más antigüedad. Te recomiendo que prestes atención a este aspecto para tener una visión del equipo que vaya a desarrollar tu producto.

Kit dragón:

  • Verifica cada uno de los miembros del equipo que pondrá el partner. Es fácil hacerlo y no debes asumir un riesgo pasando por alto este punto.
  • Un partner que te proporciona la lista de las personas que van a trabajar en tu proyecto debes considerarlo positivamente.

12. SQA

La gestión de la calidad es un proceso primordial en el mundo del desarrollo y, más todavía, en el de las apps móviles (por ser distribuidas). Muchos de los clientes están acostumbrados a los desarrollos web donde en caso de error en la mayoría de las ocasiones una modificación en un servidor permite resolver el problema para todos los usuarios de forma transparente (. En el mundo móvil es un lujo que no tenemos: hacer que un usuario se descargue nuestra App y que la use es un trabajo titánico, y el porcentaje de desinstalación por errores es alto, sin hablar de la dificultad de forzar un usuario a actualizar una app a la siguiente versión si no lo desea.

Por eso, es importante que elijas a un partner que tiene claramente definido una metodología de SQA (Software Quality Assurance). Un SQA, no es sólo validar que antes de la entrega el producto es perfecto y que cumple con la descripción funcional, sino también que hay un procedimiento de alto nivel que engloba todos los procesos, como la definición funcional, la arquitectura software, el coding, el control de versiones, el code review, el testing, la automatización de pruebas (Silicon Testing), la validación humana (Carbon Testing), la integración continua y el despliegue continuo.

Así que tienes que averiguar quién se encarga del testing dentro del equipo, si existe una metodología, cuáles son los distintos tests que se pasarán, su grado de automatización, las herramientas que se usarán, etc. Es una parte primordial para que tengas el mejor producto. Es tan importante que no debería hacerlo el equipo de desarrollo, dado el volumen de trabajo que representa, los skills necesarios a este tipo de trabajo y los objetivos, que también difieren entre los equipos que intervienen en el desarrollo.

Kit dragón:

  • Verifica si tu partner tiene un equipo de testing y SQA independiente.
  • Verifica que tengan una metodología de SQA,.Pregunta por las herramientas, la gestión y el reporte de los posibles errores, la manera de distribuir las distintas versiones antes de la subida a producción. Cuantas versiones al día (sí, al día) se publicarán, etc.

13. SOPORTE Y MANTENIMIENTO

Como estamos viendo, desarrollar una app no es un trabajo de one-shot. Las apps tienen que evolucionar, adaptarse a los usuarios, a los cambios del mercado y de los ecosistemas. Subir una app al market no es el final del proyecto, sino simplemente un hito importante, pero no deja de ser uno más, queda la captación de usuarios y ventas (por parte de marketing) y el mantenimiento (por parte del partner).

El partner tiene que poder mantener, evolucionar la app, realizar seguimiento de las analíticas, atender las incidencias de los usuarios, monitorear crashes (errores), detectar posibles problemas y solucionarlos, realizar test A/B, preparar la app para los cambios tecnológicos, monitorear la evolución de la calificación en el market y entregar informes de seguimiento de métricas bien justificados.

Para poder hacerse de forma profesional, este trabajo, totalmente distinto al del equipo de desarrollo de proyecto, tiene que ser asumido por un equipo dedicado en exclusiva al soporte y mantenimiento de aplicaciones. Sus miembros, igual de profesionales y capacitados que el equipo inicial, tendrán la responsabilidad de mantener tu producto a lo largo de su vida bajo un acuerdo de nivel de servicio que tendrás que definir con tu partner.

Como siempre, no dudes en pedir referencias de clientes de dicho departamento, cuáles son sus metodologías (distintas de los equipos de desarrollo de proyectos), su capacidad de respuesta, los procedimientos que se aplicarán al servicio, las herramientas usadas, etc.

Kit dragón:

  • Verifica que tu partner tiene un departamento de soporte y mantenimiento dedicado.
  • Verifica que dicho departamento tiene también una metodología orientada a servicio completa.
  • Pregunta por referencias, las herramientas usadas, los procesos, satisfacción de servicio, etc.

14. PRECIO

Si has llegado hasta aquí (gracias por hacerlo) entonces habrás visto que tener todo lo anterior obviamente supone un coste. Esnormal porque necesitas un gran producto, y no el más barato. Así que no dejes que el precio sea tu único guía. No se puede seleccionar un partner basándose sólo en una estimación económica.

Existe una ley empírica que circula por Internet que dice que el usuario final tiene tendencia a pagar en función del tamaño de la pantalla. Parece estúpido pero a nadie le parece raro pagar 49€ por una aplicación para mac y, sin embargo, le resulta una locura pagar más de 0,99 € por una app mobile. Esto pasa también con la idea de los desarrollos. Los desarrollos para apps o tablet son iguales de complejos que para pc, mac o web.Es más, comparado con un desarrollo web, el desarrollo de una app es más caro. Por varias razones:

1ª) Porque lo tienes que hacer en la gran mayoría de ocasiones para 2 plataformas (Android e iOS) y no, no se puede reaprovechar nada entre las 2 plataformas,en lo que se refiere a código nativo excepto si utilizas un framework.

2ª) Porque no hemos alcanzado la madurez que tiene actualmente el desarrollo web tanto en front como en back. Son años y años de mejora continua, de errores y correcciones. No podemos exigir todavía lo mismo a los equipos o las herramientas de desarrollo App. El hermano pequeño del desarrollo.

3ª) Porque hay pocos especialistas y mucha demanda de desarrollo App, con lo cual los salarios tampoco se pueden comparar. Puede parecer injusto o triste pero es así. La vieja regla de la oferta/demanda.

De cara a comparar tus posibles partners, tienes que pedir un desglose del precio por tareas así como el desglose del precio por perfiles. No sólo te permitirá verificar que se harán todas las tareas que hemos comentado anteriormente sino también comparar los precios con criterio.

Kit dragón:

  • No dejes que el precio sea tu guía. Necesitas un gran producto, no el más barato.
  • Pide el precio desglosado por perfiles y por tareas.

Preguntas frecuentes:

P: El partner me propone un calendario de pago donde al final le voy a tener que pagar una parte del desarrollo antes de la entrega definitiva. Y lo considero un riesgo y quiero pagar a la entrega final.
R: Si has seguido esta guía para seleccionar tu partner entonces sabrás que este no te va a entregar un producto al final, sino que te hará entregas parciales donde podrás comprobar la calidad del trabajo de forma regular. Así que el riesgo realmente no existe. Por otro lado, lo que todos buscamos es un partner involucrado en el proyecto, alguien con quien ir a la batalla (coding is a war), una relación a largo plazo y esto se basa en dar y recibir. Así que recibir este calendario de pago es también una buena señal de profesionalidad del partner y si éste cumple tus expectativas te encantará pagar por lo recibido.
P: Tengo un departamento de compras en mi compañía y se que van a pedir presupuesto a más empresas y el precio para ellos es lo más importante.
R: Las buenas mesas de compra comparan peras con peras, así que si has pasado todos los puntos anteriores como requisitos a la mesa de compra, pedirán presupuesto a empresas que podrán aportar estas mismas garantías. Asíque mejor para ti. Tendrá efectivamente el mejor partner al mejor precio. Si tienes una “mala mesa de compras(1)”, pues lo siento. La vida es injusta.
P: Tengo un presupuesto cerrado y no me da para hacer todo el proyecto con el partner que he elegido.
R: Entonces tendrás que asumir más riesgos con otro partner o tomar la decisión de hacer una primera versión de tu producto (si es posible) con funcionalidades recortadas respecto al producto final previsto y buscar más dinero para la segunda fase (sí es posible). De este modo puedes validar la calidad del trabajo en esta primera parte y el modelo de negocio o las funcionalidades y pivotar, si hiciera falta, para abordar la segunda fase.

(1): ¿No te has leído ‘Guía de cómo encontrar la mesa de compra ideal. Descubre a tu kraken.? ;)

POSTFACE

Esta guía no tiene como objetivo ser definitiva, ni la más completa sino ayudar a las personas que tienen la dura responsabilidad de elegir a un partner.

Por experiencia a lo largo de estos años como partner tecnológico, he visto a personas gastar mucho dinero con una mala selección de partner y tirarse proyectos a la basura para empezarse de nuevo desde cero. Y sobre todo, he visto cómo los equipos de intelygenz, año tras año, han mejorado sus metodologías, aprendiendo de sus errores y de sus éxitos, pensando siempre en una búsqueda de mejora continua. De esta experiencia he creado esta guía.

Guía que seguramente ya esté obsoleta en cuanto la publique (así de rápidos somos en intelygenz) pero espero que ayude a los tomadores de decisiones a encontrar este dragón.

Estaré agradecido eternamente a todos los que quieran aportar cualquier mejora a esta guía. No os cortéis con los comentarios. Estamos aquí para mejorar el contenido, no para caer bien a los demás ;)

AGRADECIMIENTOS

A todos los clientes que han confiado en intelygenz todos estos años y nos han permitido crecer en calidad y eficiencia.

A todas las personas de intelygenz, por su constante búsqueda de la excelencia, su compromiso, su pasión y su amor por el trabajo bien hecho.

A todos los correctores de este artículo por sus comentarios y aportaciones. Una especial dedicatoria a Manuel por los dragones y krakenes.


Me llamo Fred (Frédéric Alluin), https://about.me/frederic.alluin, Proud founding member of intelygenz (1/4), a (custom made) software development company based in Madrid (Spain) and SF (USA), specialized in solutions that live in the cloud and provide access to users through smartphones and powerful web interface. Our claim: “If you have a dream, we can write the code.”

Proud father, French Chef, intelygenz lover, innovation evangelist, coder, lean ninja, ideas generator and always human.