Evaluaciones técnicas: 6 preguntas que debe hacerse

Al introducir una nueva herramienta, lenguaje de programación o dependencia en su entorno, ¿qué pasos toma para evaluarlo? En este artículo, analizaré un marco de seis preguntas que utilizo para tomar estas decisiones.

Índice

¿Qué problema estoy tratando de resolver?

Todos estamos atrapados en los detalles del problema inmediato en cuestión. La evaluación honesta y crítica ayuda a revelar causas raíz más amplias y evita las microoptimizaciones.

Supongamos que tiene problemas con su sistema de gestión de configuración. Las tareas operativas diarias tardan más de lo debido y es difícil trabajar con el idioma. Un nuevo sistema de administración de configuración podría aliviar estos problemas, pero asegúrese de analizar más ampliamente el contexto de este sistema. Quizás pasar de máquinas virtuales a contenedores inmutables alivie estos problemas y más en su entorno mientras representa una cantidad de trabajo equivalente. En este punto, también debe explorar la viabilidad de soluciones más integrales. Puede decidir que este no es un proyecto factible para la organización en este momento debido a la falta de conocimiento organizacional sobre los contenedores, pero aceptar conscientemente esta compensación le permite colocar los contenedores en una hoja de ruta para el próximo trimestre.

Este ejercicio intelectual lo ayuda a explorar las causas fundamentales y resolver los problemas básicos, no los síntomas de problemas mayores. Esto no siempre será posible, pero sea intencional al tomar esta decisión.

¿Esta herramienta soluciona este problema?

Ahora que hemos identificado el problema, es hora de evaluarnos críticamente a nosotros mismos y a la herramienta seleccionada.

Una tecnología en particular puede parecer atractiva porque es nueva porque lee una publicación de blog interesante al respecto o quiere ser el que dé una charla. Las campanas y los silbatos pueden ser geniales, pero la herramienta debería solucionar los problemas básicos que identificó en la primera pregunta.

¿A qué estoy renunciando?

La herramienta realmente solucionará el problema, y ​​sabemos que solucionamos el problema, pero ¿cuáles son las ventajas y desventajas?

Estas consideraciones pueden ser puramente técnicas. ¿La falta de herramientas de observabilidad impedirá una depuración efectiva en la producción? ¿La naturaleza cerrada de esta herramienta hace que sea más difícil encontrar errores sutiles? ¿Vale la pena administrar otra dependencia por los beneficios operativos de usar esta herramienta?

Además, incluya los contextos organizacionales, comerciales y legales más amplios en los que opera.

¿Está cediendo el control de un flujo de trabajo crítico a un proveedor externo? Si este proveedor duplica el costo de su API, ¿es algo que su organización puede pagar y está dispuesta a aceptar? ¿Se siente cómodo con las herramientas de código cerrado que se ocupan de una parte sensible de la información confidencial? ¿La licencia del software dificulta el uso comercial?

Si bien estas no son preguntas sencillas de responder, tomarse el tiempo para evaluar esto por adelantado le ahorrará mucho dolor en el futuro.

¿Está sano el proyecto o el proveedor?

Esta pregunta va acompañada del apéndice “para el equilibrio de sus necesidades”. Si solo necesita una herramienta para que su equipo pase de cuatro a seis meses hasta que termine, esta pregunta se vuelve menos importante. Si se trata de un compromiso de varios años y la herramienta impulsa el flujo de trabajo comercial crítico, entonces eso es una preocupación.

Durante este paso, utilice todos los recursos disponibles. Si la solución es de código abierto, explore el historial de confirmaciones, las listas de correo y los foros de discusión de ese software. ¿Parece que la comunidad se comunica de manera efectiva y trabaja bien en conjunto, o existen divisiones obvias entre los miembros de la comunidad? Si parte de lo que compra es un contrato de soporte, use ese soporte durante la fase de prueba de concepto. ¿Está a la altura de sus expectativas? ¿Vale la pena el costo de la calidad del soporte?

Asegúrese de ir más allá de las estrellas y las bifurcaciones de GitHub cuando evalúe las herramientas de código abierto. Algo puede ocupar la página principal de un agregador de noticias y llamar la atención durante unos días, pero un examen más detenido podría revelar que solo unos pocos desarrolladores principales están trabajando en un proyecto y lucharon por encontrar contribuciones. Tal vez una herramienta sea de código abierto, pero un equipo financiado por la empresa está liderando el desarrollo central y es probable que el soporte cese si esa organización abandona el proyecto. Tal vez la API ha cambiado cada seis meses causando mucho dolor a las personas que han adoptado versiones anteriores.

¿Cuáles son los riesgos?

Como tecnólogo, entiende que nada sale según lo planeado. Las redes se caen, los discos fallan, los servidores se reinician, las líneas del centro de datos pierden energía, regiones enteras de AWS se vuelven inaccesibles o los secuestros de BGP redirigen cientos de terabytes de tráfico de Internet.

Pregúntese cómo podría fallar esta herramienta y cuál sería el impacto. Si agrega un producto de proveedor de seguridad a su canalización de CI/CD, ¿qué sucede si el proveedor deja de funcionar?

Esto plantea consideraciones tanto técnicas como comerciales. ¿Se acaba el tiempo de espera de las canalizaciones de CI/CD porque no pueden comunicarse con el proveedor, o se "abre por error" y permite que la canalización finalice con una advertencia? Este es un problema técnico, pero en última instancia, una decisión comercial. ¿Está listo para entrar en producción con un cambio que omitió el análisis de seguridad en este escenario?

Obviamente, esta tarea se vuelve más difícil a medida que aumentamos la complejidad del sistema. Afortunadamente, sitios como k8s.af consolidar los ejemplos de escenarios de falla. Estas autopsias públicas son muy útiles para comprender cómo puede fallar el software y cómo planificar este escenario.

¿Cuáles son los costos?

Las principales consideraciones aquí son el tiempo de los empleados y, si corresponde, el costo del proveedor. ¿Es esta aplicación SaaS más barata que más personal? Si ahorra a cada desarrollador del equipo dos horas al día con esta nueva herramienta de CI/CD, ¿vale la pena en el próximo año fiscal?

Por supuesto, no todo tiene que ser una propuesta de reducción de costos. Tal vez no sea neutral en cuanto a costos si ahorra al equipo de desarrollo algunas horas al día, pero elimina un gran obstáculo en su flujo de trabajo diario y estarían mucho más felices por ello. Esta felicidad probablemente valga el costo financiero. La incorporación de nuevos desarrolladores es costosa, así que no subestimes el valor de una mayor retención al hacer estos cálculos.

Conclusión

Espero que haya encontrado este marco informativo y lo animo a que lo incorpore en sus propios procesos de toma de decisiones. No existe un marco único que funcione para todas las decisiones. Tenga en cuenta que a veces puede que tenga que dejarse llevar por sus instintos y ser crítico. Sin embargo, tener un proceso estandarizado como este ayudará a diferenciar cuándo puede analizar críticamente una decisión y cuándo necesita dar ese salto.

Artículos de interés

Subir