¿Cuáles son sus mayores consideraciones (o requisitos) al externalizar el desarrollo de su aplicación móvil?

Aquí está el mejor juego de herramientas sobre estrategia móvil. Piensa más grande que una sola aplicación móvil. Debe pensar en su estrategia: el kit de herramientas de estrategia móvil empresarial

1 de cada 4.

Así es como muchas empresas perderán su clasificación competitiva debido a la falta de competencia digital para 2017.
Las aplicaciones móviles ahora son necesarias para competir por los consumidores de hoy. Las empresas que ignoran este mensaje hacen un daño significativo a la percepción de su marca a los ojos de esos consumidores, que se han convertido en criaturas mucho más volubles en los últimos diez años. Según Accenture, el 56 por ciento de los consumidores encuestados dijo que la cantidad de marcas que consideran para una compra se ha expandido significativamente en la última década. Junto con la investigación que muestra que el 85 por ciento de los consumidores prefieren las aplicaciones móviles a los sitios web, está claro que abandonar a los consumidores en el espacio móvil garantiza que los consumidores abandonen su marca.

Para los empleados, las aplicaciones móviles no son menos importantes que las creadas para el público consumidor. Los avances en la reducción de los costos operativos a través del uso de la innovación digital han abierto las compuertas del retorno de la inversión en tecnología de información estratégica. Casi todas las industrias están aprovechando los avances de la computación en la nube y los grandes datos para ver el alivio final que puede aislarlos de los disruptores digitales que se apoderan de la industria.

En pocas palabras: el mundo ha cambiado para las aplicaciones móviles.

Los requisitos reales de las aplicaciones móviles de hoy

El problema es que la forma en que muchas empresas persiguen a los proveedores no ha cambiado: desempolvar una plantilla de RFP, completar algunos requisitos y hacer una convocatoria de propuestas. Priorice los envíos en función del costo y la capacidad estimada de entrega, y el proyecto está en camino.

Hay demasiado en juego para estos productos, junto con demasiado potencial para transformar su negocio y hacer una mala inversión. Los CEO que se han dado cuenta de esto destinarán una mayor parte del gasto al desarrollo de soluciones móviles, pero estas inversiones tienen un historial difícil: el 60 por ciento del desarrollo de software produce productos ineficaces o deficientes, con un 25 por ciento fallando directamente.

Las RFP tradicionales son especialmente propensas a producir productos en las categorías ineficaces y de falla. El autor de los requisitos es a menudo un líder de TI con poca comprensión de las necesidades comerciales o de los usuarios en las que operará el problema. Su única misión es a tiempo y dentro del presupuesto, sin tener en cuenta lo que significa el éxito más allá de estas dos métricas.

Para la mayoría de las empresas, la causa raíz de esta falla ocurre desde el principio. Al no investigar y diagnosticar adecuadamente si existe un problema, desarrollan una solución basada en suposiciones sobre el comportamiento de los usuarios y cuando se dan cuenta del error, es demasiado costoso solucionarlo.

Un estudio de la NASA reveló que en cada etapa del desarrollo del producto, cambiar los requisitos genera un aumento de diez veces en el costo. Cuanto más avanzan las empresas sin comentarios de los usuarios, más difícil es hacer los cambios que los usuarios necesitan. Muchas empresas suponen erróneamente que obligar a los empleados a utilizar la aplicación es la solución para las aplicaciones internas. Sin una investigación robusta de los usuarios para validar que la aplicación funciona bien para los usuarios, las empresas solo se están preparando para el fracaso cuando sus usuarios recurren a soluciones alternativas o, lo que es peor, experimentan frustración y complicaciones de la aplicación.

Esto solo debería convencer a los líderes de TI y de negocios de abandonar las plantillas tradicionales de RFP. Con tanto en juego, las empresas se están vinculando a una solución ineficaz o fallida; para cuando se dé cuenta de que el producto no cumplirá con las expectativas de KPI de la empresa, el presupuesto para arreglarlas se habrá agotado. Cada aplicación recibe comentarios de los usuarios; ya sea a través de una baja tasa de adopción o las voces de usuarios frustrados, el equipo de TI escuchará los cambios que deben realizarse. La diferencia con nuestro enfoque de las solicitudes de propuestas es que el equipo tendrá el presupuesto y el tiempo para corregir los supuestos de comportamiento del usuario que conducen a esos errores antes de que la aplicación entre en costosas fases de diseño y desarrollo.

Nuestro enfoque es un tipo diferente de RFP: uno que garantice el ROI del negocio y se adapte mejor a la forma en que se crean productos digitales verdaderamente innovadores.

La estrategia infalible para reunir los requisitos del usuario para aplicaciones móviles

Las ventas se habían estancado para un importante distribuidor de productos de servicio de alimentos. Se necesitaron 50 por ciento más de interacciones para que las nuevas contrataciones de ventas lograran los mismos resultados que sus contrapartes veteranas, debido a la inexperiencia, la gestión de las garantías de ventas y la incapacidad para responder las preguntas de los clientes.

El equipo de liderazgo hizo sonar la alarma para el equipo de TI, que envió una solicitud de propuesta para una solución personalizada de habilitación de ventas digitales.

El problema: nunca fue un problema colateral. Observar al equipo de ventas en acción arrojó la idea de que el estado de ánimo de los clientes era el culpable. Estaban en la oscuridad acerca de cuándo llegarían sus órdenes anteriores y ansiosos por cumplir sus propios objetivos de rendimiento para el día.

La solución de habilitación de ventas nunca habría mejorado las métricas de ventas. Desarrollar un sólido compromiso de investigación del usuario con la observación de campo en el proyecto descubrió esto a tiempo para invertir los dólares de TI en una aplicación orientada al cliente con información en tiempo real sobre sus pedidos.

Los procesos tradicionales de evaluación de agencias de desarrollo de aplicaciones pierden el compromiso de investigación del usuario con demasiada frecuencia. El líder de TI del proyecto analiza el problema a partir del caso de negocios, valida un poco su existencia y pasa a las soluciones.

En el campo de la medicina, el acto de prescribir una solución antes de verificar el problema se llama “mala práctica”. Sin embargo, en el campo de TI, esto es exactamente para lo que están diseñados los procesos de evaluación de la agencia sin un compromiso de investigación del usuario.

Las entrevistas a usuarios simplemente no son suficientes para proporcionar el nivel de diagnóstico detallado que requieren los productos digitales. A medida que el proceso se vuelve más arraigado y sin sentido para el empleado o cliente, menos pueden explicar cada paso con suficiente detalle. Los diagramas de proceso y los manuales de usuario son víctimas del mismo problema. La gerencia asume incorrectamente que las tareas suceden exactamente como se describen en estas publicaciones, aunque la realidad es a menudo muy diferente.

Antes de diseñar un solo wireframe, es necesario salir al campo para observar a los usuarios y luego crear un mapa de flujo de trabajo real para identificar dónde existen ineficiencias o frustraciones de los usuarios. Use esas observaciones para formular una hipótesis del impacto de un producto digital. Algunas empresas tienen un proceso existente como parte de la creación del caso de negocios. Esto aún puede no ser suficiente, dependiendo de qué tan bien se entiendan los objetivos del usuario y del negocio.

Diagnosticar si necesita investigación de experiencia de usuario:

¿Tiene personas detalladas para cada usuario que describan sus motivaciones, temores y frustraciones?
¿Se ha tomado el tiempo de investigar las condiciones ambientales de los usuarios?
¿Ha mapeado los flujos de trabajo de cada usuario con un alto grado de precisión?

Si esas preguntas pueden ser respondidas y validadas por los datos de la investigación contextual en el campo, es mejor extrapolar las necesidades claras y específicas de los usuarios y proporcionar un resumen de la investigación para la RFP. De lo contrario, cambie la sección tradicional “Resumen y alcance” por esto:

Resumen del problema comercial. Escriba las condiciones que conducen a esta RFP. Sea lo más específico posible.
Cronología y fecha de lanzamiento del objetivo.
¿Qué hará el proveedor para minimizar el riesgo de falla del producto antes de las fases de diseño y desarrollo? Descubra cómo el equipo aborda la investigación de riesgos y experiencia del usuario.
¿Cómo validará el proceso de desarrollo de su producto que este producto funcionará para los usuarios antes del desarrollo? El objetivo aquí es descubrir cómo se incorporan los comentarios de los usuarios en el proceso de desarrollo del producto.
¿Cómo y cuándo se medirá el impacto de la aplicación? Descubra cómo el equipo aborda los datos y las métricas.
¿Cómo se asegurará de que el producto maximice la adopción del usuario? Aclare cómo la agencia mide y define la adopción del usuario. Tenga cuidado con las respuestas que se centran en el “aspecto” de la aplicación; Muchas aplicaciones hermosas y elegantes no logran atraer a los usuarios.
¿Cuáles son los antecedentes de los usuarios investigadores del equipo? Con demasiada frecuencia, las agencias confían en los diseñadores para hacer esto, lo cual es problemático porque carecen de capacitación formal en investigación de campo.

KPI de negocios sólidos

A tiempo y por debajo del presupuesto.

En cuanto a la mayoría de las RFP tradicionales, estos dos son los principales KPI que deben cumplir los proveedores. Parte de esto proviene de pensar en las soluciones móviles como proyectos, no como productos. La “mentalidad de proyecto” crea productos sin los efectos medibles para los usuarios y con una misión que completar, en lugar de ROI.

Piénselo de esta manera: un chef en un restaurante Michelin de tres estrellas prepara un menú de precio fijo de cinco platos. Si bien es necesario que la creación se ajuste al presupuesto del restaurante y se cronometrará en consecuencia, ninguno de los dos importará si no satisface a los clientes.

Aquí hay algunos cálculos útiles para medir y justificar los KPI:

Errores: (# de errores) x (tiempo promedio de reparación) x (costo de empleado) x (# de empleados) = ahorro de costos
Costo de desarrollo: (# de cambios) x (promedio de horas / cambio) x (costo del desarrollador) x (4, si llega tarde) = ahorro de costos
Productividad: (tiempo ahorrado) x (costo de empleado) x (# de empleados) = ahorro de costos
Retención de más clientes: tasa de retención = (número de clientes al final del período – número de nuevos clientes adquiridos durante el período) / clientes al inicio del período (tasa de retención del objetivo x número actual de clientes – tasa actual de retención x número actual de clientes) x costo de adquisición del cliente = ahorro de costos
Nuevos clientes: (Costos de generación de demanda después del lanzamiento) / (Número de clientes después del lanzamiento) – (Costo total de actividades de marketing y ventas para la generación de demanda para el período anterior) / Número de clientes = Ahorro de costos
Mejora de la retención de empleados Tasa de retención = (número de empleados al final del período – número de nuevos empleados contratados durante el período) / empleados al inicio del período (Tasa de retención del objetivo x número actual de empleados – tasa actual de retención x número actual de empleados) x costo promedio de adquisición y capacitación de empleados = ahorro de costos

La clave es enraizar ambos en las necesidades de los usuarios. Todos estos cálculos deben aplicarse al nivel de usuario individual.

La RFP misma debe incluir una hipótesis de los KPI que la empresa quisiera cumplir con esta solución. Estos deben ser objetivos específicos, medibles y oportunos que la aplicación móvil debe cumplir. Evite objetivos vagos o “suaves”, como “mejorar la moral de los empleados”. En su lugar, escriba métricas claramente definidas, como “aumentar el puntaje neto del promotor de los empleados de 56 a 64 para el segundo trimestre”.

Para esta parte, es importante identificar claramente a todas las partes interesadas en el proyecto y realizar entrevistas para delinear las métricas para el éxito desde su perspectiva. Por ejemplo, el Gerente de Planta ha identificado la necesidad de una solución para movilizar y digitalizar los formularios de control de calidad, que están regulados y requeridos por una agencia de regulación gubernamental. El KPI del Gerente de Planta es una disminución de los retrasos en las entregas relacionadas con el control de calidad y una disminución en la cantidad de tiempo que le toma a un producto pasar por el proceso de control de calidad. El coordinador responsable de administrar el papeleo tendrá un KPI para disminuir los errores en los formularios de control de calidad y disminuir la cantidad de tiempo que lleva enviar el papeleo.

Preguntas para incluir en la RFP:

Descripción de los KPI. ¿Qué significa el éxito para el producto?
¿Cómo utilizará los datos en los procesos de diseño y desarrollo para garantizar que el producto esté en camino de cumplir con los objetivos de ROI? Descubra cómo ingresan los datos al proceso.
¿Cómo corregirá el curso si el proyecto no está en camino de cumplir con los KPI? La clave aquí es que el proveedor realiza una investigación sobre por qué el proyecto no cumplirá con los KPI, en lugar de simplemente hacer suposiciones a ciegas sobre la causa raíz.

Los requisitos no funcionales que son críticos para el éxito de las aplicaciones móviles

El diseño debe ser más que “bonito”. De hecho, los sentimientos estéticos que usted y sus superiores tienen sobre el portafolio de una empresa no deberían tener en cuenta su evaluación de los proveedores, a menos que eliminen a los proveedores cuyas aplicaciones son claramente poco profesionales o tienen errores.

Primero, es importante expandir su propia definición de experiencia del usuario más allá de su experiencia con el producto digital. La experiencia del usuario se centra en las personas, piensa más allá de las soluciones digitales y es cómo la tecnología crea una experiencia holística que vincula todos los puntos con los que un usuario entra en contacto para mejorar el rendimiento de los empleados. UX no es wireframes, una interfaz, experiencia de uso o tecnología por sí sola. El término ha evolucionado y ahora considera la experiencia holística en torno a un producto de software, así como la marca y el entorno. Además, el diseño de la experiencia del usuario y el diseño de la experiencia se fusionan, ya que los artefactos y sus entornos se integran cada vez más. La experiencia del usuario implica la experiencia fuera de línea y en línea y abarca interacciones digitales, físicas y basadas en servicios.

Estas interacciones deben ser impulsadas por los datos y centrarse en el usuario. Intente comprender cómo tomaron las decisiones de diseño que tomaron, en lugar de suponer que usaron la “mejor práctica”, lo cual es una vaga justificación para decisiones de diseño cruciales. Por ejemplo, la aplicación debe proporcionar operaciones remotas de monitoreo del desempeño para una fuerza laboral de campo. Cuando un activo tiene un rendimiento inferior, aparece un triángulo con un signo de exclamación junto a la etiqueta del activo. ¿Por qué esa forma? La respuesta clave que está buscando aquí es que la iconografía ya fue entendida y utilizada por los usuarios finales. Esto muestra que no solo el equipo de diseño está coordinando con un equipo de investigación, sino también que los diseñadores toman sus decisiones en función de las necesidades del usuario, en lugar de su propio juicio sobre lo que es estéticamente agradable.

Un factor clave en el proceso de diseño centrado en el usuario es la comprensión de las necesidades del usuario. Piense en el conjunto diverso de usuarios que confiarán en el producto que está considerando crear. ¿Cuáles serán los diferentes deseos y necesidades de esos usuarios? Por ejemplo, está creando un producto para desplegar todos sus materiales de ventas para canalizar representantes de ventas. El coordinador de marketing, responsable de actualizar los documentos, debe poder eliminar fácilmente las versiones anteriores y reemplazarlas con las versiones más recientes, así como ver el uso del documento por diferentes representantes de ventas para ajustar el mensaje. El representante de ventas del canal, por otro lado, quiere poder agrupar documentos en conjuntos y etiquetar sus propios documentos para una búsqueda fácil. El administrador de representantes de ventas del canal también quiere ver el análisis y la actividad de los representantes de ventas, junto con paneles de control de uso de los representantes de ventas de los documentos en función de la experiencia y la etapa en el embudo de ventas para garantizar que todos los representantes de ventas estén utilizando los materiales correctamente. Es importante pedirle al equipo de diseño que revise su cartera y vea qué tipo de personas están impulsando las interacciones. Encuentra un pequeño detalle en su aplicación y pídeles que te expliquen.

El siguiente paso es preguntar acerca de los datos y cómo eso influye en las decisiones de diseño. Piense nuevamente en la sección de KPI de negocios. ¿Cómo es el progreso en el cumplimiento de los factores en cada interacción? En cada etapa del diseño, ¿se mide adecuadamente el progreso hacia el cumplimiento de esos objetivos? Una práctica a tener en cuenta: diseñadores que son investigadores improvisados. La investigación y el diseño son prácticas muy distintas que, aunque trabajan en estrecha colaboración, requieren diferentes antecedentes y especialidades. Cuando solicite los antecedentes y deberes de cada miembro del equipo de diseño propuesto, asegúrese de que sus deberes sean independientes de los del equipo de investigación. Los diseñadores deben comunicarse con usted y sus partes interesadas, pero haciendo una investigación de campo, a menos que hayan recibido capacitación específica y antecedentes (al menos un título de posgrado en psicología), entonces no están calificados para realizar investigaciones.

Preguntas para incluir en la solicitud de propuesta para el diseño:

Proporcione un currículum, antecedentes y deberes del jefe de diseño y al menos tres miembros principales del equipo. ¿Cuánta experiencia tiene el equipo en su industria?
Proporcione un recorrido por el proceso de diseño de principio a fin para una aplicación móvil. Observe cuántos puntos de contacto tendrá el equipo con usted y con qué frecuencia se incorporan los comentarios de los usuarios en el proyecto.
Envía una cartera de tu trabajo.
Para un proyecto en el trabajo, envíe las personas de usuario que informaron la creación de las interacciones. Busque detalles en la persona que tradujo a la aplicación.
Explica cómo las personas necesitaban cambios específicos que se incorporaron al producto final. Descubra cómo el equipo itera sobre el concepto inicial e incluye a las personas en cada etapa del proceso.
¿Cómo influye el diseño en el ROI de sus proyectos? ¿Están pensando en el rendimiento general del proyecto? ¿O simplemente piensan “bonitas”?
¿Cómo diseña su equipo de manera diferente para una tableta frente a un teléfono frente a un reloj? ¿Cómo cambian las interacciones para cada medio? ¿Qué tan bien son capaces de comprender el diseño y las restricciones de usuario para cada medio? Las pantallas son más pequeñas, lo cual es obvio, pero las necesidades del usuario también deben cambiar.

Cómo obtener los requisitos de desarrollo de aplicaciones móviles correctamente: la primera vez

En 1961, Alan Shepard condujo la misión al espacio. Cuando los periodistas le preguntaron más tarde sobre qué pensaba mientras esperaba el despegue, él respondió: “Que cada parte del barco fue construida por el mejor postor”.

Este sentimiento se hace eco de las prácticas de muchas empresas en la evaluación de equipos de desarrollo con productos digitales de alto riesgo. Los equipos subcontratados con precios de desarrollo bajos parecen una solución fácil para facilitar el presupuesto, pero lo que muchos pierden en estructurar un equipo de esta manera es la creatividad que los equipos de desarrollo experimentados aportan al proceso de desarrollo. Los procesos de evaluación necesitan no solo evaluar qué tan equipado está el equipo para manejar el desarrollo de productos, sino también el elemento intangible de qué tan bien pueden aplicar soluciones creativas. Parte de eso proviene de trabajar codo a codo con los diseñadores en el desarrollo de un equipo de producto, donde ambos pueden beneficiarse de la lluvia de ideas.

Los equipos de productos dedicados son la configuración más efectiva, tanto para la creatividad como para la comprensión de su producto móvil. Su producto tendrá desarrolladores y diseñadores dedicados trabajando en él, y podrá utilizar su profundo conocimiento del contexto de su producto. Piense en los chefs que trabajan en la cocina: cada chef que prepara una comida para la mesa creará una mejor experiencia para el cliente que un equipo de chefs diferentes que entran y salen por cada paso, así es como algunas agencias se acercan a los equipos de desarrollo. Una lista maestra de tareas dicta qué tareas se realizarán para todos los productos, y los desarrolladores las recogen a medida que terminan otras. Es más fácil para la agencia, pero el producto pierde ese equipo cohesionado.

La seguridad es una preocupación importante para las empresas que buscan productos digitales. La posibilidad de pirateo de datos de clientes o empresas y el daño de un millón de dólares que conlleva es suficiente para disuadir a cualquier equipo de gestión de invertir en la transformación digital. Los equipos de desarrollo experimentados pueden ayudar a describir el cifrado de datos y otras medidas de precaución necesarias para un producto digital específico. Las soluciones de seguridad deben personalizarse según las necesidades del producto, y la experiencia para hacerlo debe incluirse en cualquier RFP.

Para identificar proveedores con la experiencia adecuada, debe describir las integraciones, plataformas y dispositivos back-end aplicables al producto. Incluso si esto no se establece porque está buscando orientación en el equipo de desarrollo, debe proporcionar el universo de posibilidades para que el proveedor pueda asegurarse de que los recursos estén disponibles.

Un problema común de recursos es el pastoreo de API. Con demasiada frecuencia, al escribir los requisitos para un producto móvil, el administrador del producto asume que las API están listas y funcionando. Sin embargo, cuando se inicia el desarrollo, el equipo se da cuenta de que este no es el caso y, por lo tanto, causa retrasos significativos y sobrecostos. Documentar las API también es absolutamente necesario para la experiencia del equipo de desarrollo y la capacidad de la API para desempeñarse. Existen numerosas herramientas para automatizar estas tareas. Swagger, Mashery I / O Docs y Apiary: construir hermosas API son algunas. Debe proporcionar un nivel mínimo de documentación para evaluar la capacidad de una API para cumplir con los requisitos de diseño y construir un servidor API falso necesario para el desarrollo si es necesario. Su documentación debe incluir un historial de versiones para observar los cambios en las API. También debe incluir una sección que describa las políticas y los requisitos de autenticación.

La parte final de su sección de desarrollo debe abordar la metodología que el equipo de desarrollo sigue para desarrollar aplicaciones móviles. No todas las metodologías son iguales; Algunas metodologías serán más efectivas para su producto y equipo. Considere la frecuencia con la que desea comunicarse y la cantidad de ajustes que desea realizar en función de los comentarios de los usuarios.

Desarrollo ágil vs. cascada para minimizar el riesgo

El desarrollo ágil de software se centra en compilaciones iterativas de porciones pequeñas aprobadas por el cliente que se entregan tan pronto como estén listas. Las variaciones incluyen scrum, XP y DSDM.

Lanzamientos regulares e iterativos para nuevas funciones
Comentarios continuos del usuario
Comunicación constante con los clientes.
Equipos de productos dedicados

El desarrollo de software en cascada es un proceso de diseño secuencial, donde cada paso se completa uno tras otro con documentación meticulosa. El proyecto se entrega todo de una vez.

Centrarse en el mantenimiento de registros
Reduce el impacto de la rotación de personal de desarrollo
Largo ciclo de desarrollo
Lanzamiento de todo el producto de una vez
Comentarios del usuario después del lanzamiento

Preguntas para incluir en la RFP:

¿Qué tipo de metodología de desarrollo sigue su equipo?
Explica los principales pasos de tu proceso de desarrollo de una aplicación de principio a fin. Tenga cuidado con los largos ciclos de desarrollo sin comentarios de los usuarios y la falta de incorporación del equipo de diseño.
¿Cómo minimizará su equipo el riesgo? Algunas empresas darán respuestas relativamente estándar aquí. Busque los que incluyen el caso de negocio en su desarrollo.
Proporcione tres ejemplos en los que el equipo de desarrollo aplicó creatividad a un problema de desarrollo.
[Si es necesario] ¿Tiene su equipo la capacidad de proporcionar pastoreo API como parte del proyecto?
¿Proporcionará un equipo de producto dedicado que maneje todas las tareas para la aplicación? ¿Cómo se configurará el equipo?
¿Con qué frecuencia y bien se comunica su equipo con los clientes?
Explica cómo abordarías la seguridad de esta aplicación.

Comprender sus necesidades de mantenimiento

Crear un producto digital, en lugar de completar un proyecto, también crea otra arruga para la creación tradicional de RFP. Los productos digitales nunca se terminan, pero los proyectos se completan. Esto refleja la realidad de las aplicaciones, que requieren un mantenimiento regular y lanzamientos de nuevas versiones para abordar los problemas. Ejemplo: a lo largo de 2014, Amazon, Walmart y Geico actualizaron sus aplicaciones respectivas entre 20 y 25 veces , y obtuvieron las calificaciones promedio más altas en la App Store.

Es importante que el proveedor pueda crear un plan para cada versión, con análisis y mediciones en curso después de la primera versión para mejorar las iteraciones posteriores. El análisis y la medición deben provenir de los KPI de negocios descritos, así como la usabilidad general y el rendimiento de la aplicación.

Apple lanza una nueva versión de su sistema operativo cada año y, como mínimo, la aplicación debe cumplir con las especificaciones de la versión para permanecer funcional. También hay nuevas características con los lanzamientos que pueden tener un impacto en la experiencia del usuario, como la mayor sensibilidad del toque 3D que permitió diferentes acciones en función de la cantidad de fuerza en el toque.

¿Cómo funcionará un compromiso continuo para el mantenimiento de la aplicación, en términos de precios y mano de obra? ¿Qué tipo de plan de mantenimiento puede proporcionar?
¿Cómo se medirá el rendimiento de la aplicación después del lanzamiento a través de análisis? ¿Alguien en la agencia supervisará y recopilará estos datos?
¿Qué análisis me recomiendan? ¿Qué herramientas usa su equipo para monitorear el desempeño?
Proporcione dos ejemplos de proyectos con mantenimiento y análisis continuos, describiendo específicamente cómo evoluciona la aplicación con cada lanzamiento y por qué se seleccionaron las herramientas de análisis específicas.

Elaboración de su estrategia de garantía de calidad

Mostrar la línea de tiempo al equipo de gestión se convierte inmediatamente en una discusión sobre dónde se pueden hacer los recortes. Con demasiada frecuencia, esta área es la garantía de calidad de la aplicación. Hershey’s cometió este error durante su modernización de ERP heredada y vio que los pedidos por valor de $ 100 millones no se cumplieron.

Cada RFP necesita evaluar las capacidades de QA de las agencias, que son culpables de la misma mentalidad cuando se trata de QA. Es más barato no probar en dispositivos reales mediante el uso de programas de simulador, pero estos fallan errores cruciales. Lo mismo se aplica para confiar únicamente en las pruebas automatizadas, en lugar de incluir también las pruebas manuales en el proceso. Las pruebas automatizadas son un gran predictor del comportamiento del software, no del comportamiento humano. Puede estar apostando por la calidad del producto y arriesgarse a estropear el lanzamiento.

Preguntas para incluir en la RFP:

Explica tu proceso de control de calidad. Asegúrese de que haya un proceso completo y riguroso en su lugar. ¿El equipo de control de calidad aprende sobre el proceso a través de su propia experiencia?
¿Su equipo de control de calidad y su equipo de desarrollo trabajan en estrecha colaboración?
¿Cuántos empleados a tiempo completo participan en el control de calidad? Si bien puede no ser completamente necesario usar solo FTE, depender de todos los subcontratistas plantea un riesgo.
¿Su equipo de control de calidad prueba manualmente, automatizado o ambos? ¿Utilizan algún programa simulador?