¿Resistencia a las pruebas de rendimiento para una reescritura del Big Bang?

Question

He estado trabajando en una reescritura de "Big Bang" para, literalmente, más de dos años. La gerencia ha ignorado de manera sistemática e implacable y menospreciado mis llamadas para asignar tiempo/recursos para la medición del rendimiento, la planificación de la capacidad y la optimización antes de que la aplicación reemplace a la aplicación web emblemática de millones de millones de dólares.

Finalmente, han aceptado hacerlo (y hemos evitado que se convierta en un problema al presentar un servidor beta paralelo que está en producción ahora y será el objetivo de las pruebas). No me gusta que esperaran hasta el final para priorizar esto, pero es mejor tarde que nunca.

¿Qué sugerencias tienen todos para tratar situaciones como estas en el futuro? ¿Cuál es la mejor manera de educar a los gerentes/clientes sobre la necesidad de este tipo de pruebas?

Les he mostrado la guía de rendimiento de Microsoft en CodePlex, con sus severas advertencias de los profesionales experimentados en las páginas iniciales. También les mostré el libro "¡Libérenlo!" y la orientación que da su autor sobre "la llamada a las 3 am". Eso finalmente los ha convencido de mala gana, pero la verdad es que esto debería haberse priorizado en el desarrollo y medido parcialmente durante el desarrollo antes de la prueba final completa del sistema.

Muchos gerentes e ingenieros de la vieja escuela que escribieron solo ASP, pero nunca .NET, están acostumbrados a codificar todo ellos mismos y no entienden todas las opciones de almacenamiento en caché, ajuste y monitoreo de estado en las aplicaciones .NET más nuevas.

Gracias

Answer 1

Tome notas detalladas sobre este proyecto de desarrollo, incluyendo lo que el rendimiento problemas surgen después del despliegue. La gente se lamentará de los problemas, y puedes sugerir con tacto que prioricen ese tipo de problema más temprano. Algunas personas solo aceptarán evidencia directa en primera persona.

Answer 2

Haz que acuerden números sólidos para lo que esperan que el sistema sea capaz de soportar (cantidad de usuarios/tareas simultáneas/etc.), luego se convierte en una parte obvia del trabajo de desarrollo para asegurarse de que el sistema pueda cumplir los requisitos.

Answer 3

Lo que no se dio cuenta (y muchos ingenieros no) es que se trataba de una "situación de ventas", no de una de ingeniería. No importa si el cliente es interno o no, el proceso es básicamente el mismo.

Las ventas se trata de descubrir qué tipo de problemas conducen a sus clientes y luego mostrar cómo su producto resuelve uno o más de sus problemas. Si no creen tener un problema de rendimiento, entonces no es así de simple. Aunque es posible que pueda educarlos hasta el punto en que vean las cosas a su manera, la "venta educativa" es costosa en tiempo y dinero, y muchos clientes no quieren que les digan "algo que ya saben". Parece que tienes que educar a este grupo golpeándolos en la cabeza con el libro, pero puede haber formas más fáciles de lograr tu objetivo.

¿Qué hubiera sido? No lo sé, pero lo hacen, así que pregúnteles. Pregunte qué fue lo que finalmente los empujó a tomar la decisión. Podría haber sido una repentina comprensión de que tenías razón, pero es más probable que fuera algo más básico, como un miedo creciente a ser humillado en la sala de juntas o en el mercado. Es poco probable que lo digan directamente, pero si realmente escuchas sus respuestas, es posible que puedas leer entre líneas. En ventas, hacer una autopsia en una llamada de ventas (exitosa o no) es fundamental para comprender qué motiva a su cliente y cómo puede ajustar sus propias habilidades para presentar ideas.

Y, la próxima vez, sabrá hacer preguntas abiertas sobre lo que quiere lograr su cliente y cuáles son sus problemas ahora y en el largo plazo. ¿Siempre funcionará? Por supuesto que no, pero aprender a lidiar con el aspecto social de los problemas de ingeniería es una habilidad valiosa para adquirir.

Answer 4

No hable de esto como un proceso abierto de puesta a punto del rendimiento y evaluación comparativa, ya que hará que los gerentes de más edad estén preocupados de que esté en una expedición de pesca o dorado el sistema.

En su lugar, discuta como un ejercicio de certificación. Identifique sus niveles actuales de tráfico, agregue un margen de seguridad y explique que sus pruebas pretenden certificar que el sistema resistirá a la vida real.

Aún puede hacer el trabajo del punto de acceso de rendimiento; solo tienes que darles a los jefes puntiagudos la confianza de que todo tu trabajo va a objetivos comerciales tangibles.

Answer 5

Hay todo tipo de formas de convencer a la gente; los ejemplos que menciona son "invocar una autoridad superior". La mayoría de los gerentes, sin embargo, no necesariamente serían persuadidos por la orientación técnica.

Para situaciones como esta, he utilizado un enfoque basado en el riesgo. Para cada proyecto, llevo un registro de riesgos, identificando los mayores riesgos para el proyecto, su probabilidad, impacto y opciones de mitigación. A menudo, puede cuantificar esos elementos, y eso les permite a los gerentes tomar una buena decisión.

En el comienzo de la re-escritura, el registro de riesgos podrían haber tenido la siguiente entrada:

Riesgo: El rendimiento del sistema no cumple con las expectativas del usuario

Probabilidad: desconocido

Impacto: los usuarios finales abandonan el sitio web debido a tiempos de carga excesivos. Proyecto falla

Coste del impacto: $$$ sea cual sea el costo de su proyecto.

Mitigación: pruebas quincenales de rendimiento.

costo de mitigación: $$$ lo que usted piensa que costaría en el tiempo y el dinero

Recomendación: prueba de rendimiento de la carrera de cuantificar el riesgo.

La mayoría de los gerentes se sentirían muy incómodos con un riesgo cuya probabilidad es desconocida, pero cuyo costo es la falla del proyecto. Por otro lado, no está pidiendo un gran compromiso, solo lo suficiente para cuantificar el riesgo.

Me gusta revisar el registro de riesgos regularmente con las partes interesadas del proyecto, al menos mensualmente. Siempre comienzo con los riesgos de "alto impacto/alta probabilidad", pero luego paso a los riesgos de "alto impacto/probabilidad desconocida". También es una buena idea distribuir notas de reuniones, registrando las decisiones de los interesados ​​sobre cada riesgo. De nuevo, un gerente que ve su nombre apegado a la decisión de ignorar un riesgo de alto impacto, en un registro escrito, pensará detenidamente acerca de la decisión.

Una vez que puede cuantificar el riesgo (ejecutando algunas pruebas de rendimiento), puede tomar más decisiones basadas en el riesgo, basadas en el costo y la probabilidad de problemas de rendimiento. Esta es también una buena forma de administrar los otros problemas clásicos no funcionales, como seguridad, accesibilidad y escalabilidad.

Al cuantificar el problema, lo convierte en una decisión comercial, no en una decisión de ingeniería.