Por qué sus ingenieros nos odian (pero aman nuestros resultados)

Muchos equipos de ingeniería llegan a un punto en el que la capacidad interna ya no es suficiente. Es posible que un producto necesite una revisión de seguridad. Un sistema heredado puede requerir alguien con experiencia poco común en plataformas. Un lanzamiento puede depender de una tarea breve que no justifica una contratación permanente. Aquí es donde los ingenieros externos pueden ayudar. No son un reemplazo para el equipo central. El especialista externo adecuado brinda a sus ingenieros acceso a habilidades, tiempo y experiencia que quizás aún no existan dentro de la empresa. ## Por qué los equipos internos llegan al exterior A menudo veo los mismos puntos de presión: - Un equipo pequeño debe admitir tanto funciones nuevas como sistemas antiguos. - Un proyecto necesita una habilidad que la empresa utiliza sólo una o dos veces. - Los ingenieros superiores dedican demasiado tiempo a solucionar problemas de producción rutinarios. - Un problema de seguridad, nube o datos requiere una revisión independiente. - Contratar a un especialista a tiempo completo crearía un costo a largo plazo para una necesidad a corto plazo. Una empresa puede tener ingenieros de producto sólidos, pero nadie que haya gestionado una gran migración a la nube. Otro equipo puede comprender bien a sus clientes pero carecer de experiencia en seguridad de pagos, rendimiento móvil o canales de datos. La brecha no siempre significa que el equipo sea débil. Puede significar simplemente que el negocio ha alcanzado una nueva etapa. ## Los especialistas externos que su equipo puede necesitar ### 1. Ingenieros de plataforma y nube Los costos de la nube pueden crecer sin una razón clara. Las implementaciones lentas, los recursos no utilizados y el monitoreo deficiente a menudo generan trabajo adicional para el equipo interno. Un ingeniero de plataforma externo puede revisar: - Uso y gasto de la nube - Flujos de trabajo de implementación - Reglas de monitoreo y alerta - Planes de respaldo y recuperación - Permisos de acceso - Confiabilidad del servicio El objetivo no es mover cada sistema a una nueva plataforma. Un útil especialista explica qué debe quedar, qué necesita atención y qué puede esperar. ### 2. Especialistas en seguridad El trabajo de seguridad suele aparecer después de que un producto ya ha crecido. Es posible que el equipo original se haya centrado en las funciones de envío, mientras que los controles de acceso, el registro y los procesos de revisión siguieron siendo básicos. Un ingeniero de seguridad externo puede probar el sistema desde un nuevo ángulo. Esto puede incluir: - Revisar los permisos de la cuenta - Verificar los servicios expuestos - Probar rutas de ataque comunes con aprobación por escrito - Inspeccionar la gestión de dependencias - Crear un plan de respuesta para eventos de seguridad Este trabajo debe definirse cuidadosamente. Una empresa debe saber qué sistemas están incluidos, qué pruebas están permitidas y cómo se manejarán los hallazgos. ### 3. Expertos en sistemas heredados Los sistemas antiguos pueden contener años de reglas comerciales. Reemplazarlos demasiado rápido puede generar más riesgos que conservarlos. Un especialista que comprenda el lenguaje, el marco o la base de datos utilizados por el sistema heredado puede ayudar al equipo a: - Documentar procesos clave - Identificar áreas frágiles - Agregar pruebas en torno a funciones críticas - Planificar pequeños pasos de reemplazo - Capacitar a ingenieros internos Prefiero este enfoque a una reescritura repentina. Un sistema estable con documentación clara suele ser más útil que un sistema nuevo que el equipo aún no comprende. ### 4. Ingenieros de datos y aprendizaje automático Muchas empresas recopilan más datos de los que pueden utilizar. Puede que el problema no sea la falta de datos. Puede ser una estructura deficiente, una propiedad poco clara o informes poco confiables. Un ingeniero de datos externo puede ayudar a crear: - Canalizaciones de datos - Tablas de informes - Controles de calidad - Reglas de acceso - Modelos de pronóstico - Paneles de control internos La cuestión empresarial debe anteponerse a la herramienta. Un modelo no resuelve un problema cuando el equipo no se ha puesto de acuerdo sobre qué medir. ### 5. Especialistas en experiencia de usuario y rendimiento. Los ingenieros pueden saber que un producto parece lento, pero es posible que no sepan qué problema afecta más a los usuarios. Un especialista puede examinar: - Tiempo de carga de la página - Comportamiento móvil - Tasas de error - Flujo de pago - Accesibilidad - Navegación del producto Se puede ver un ejemplo público en grandes proyectos de código abierto como Kubernetes. El proyecto ha recibido trabajo de ingenieros de muchas empresas, no sólo de la organización que lo inició. Los contribuyentes externos aportan habilidades y tiempo que amplían la capacidad del equipo central para mantener el proyecto. El mismo patrón puede funcionar dentro de una empresa cuando las responsabilidades están claras. ## Cómo decido si tiene sentido la ayuda externa. Hago cuatro preguntas antes de buscar un contratista o un equipo de consultoría. ### ¿El problema es específico? “Mejorar el producto” no es una tarea externa adecuada. “Revisar nuestro proceso de implementación y reducir los pasos de liberación manual” le da al ingeniero una dirección clara. ### ¿Se necesita la habilidad por un período limitado? La ayuda externa se adapta a proyectos cortos, revisiones de especialistas y brechas temporales de capacidad. Una responsabilidad permanente sobre el producto puede necesitar un propietario interno. ### ¿Puede el equipo explicar el sistema actual? Un ingeniero externo no puede trabajar bien si falta acceso, documentación poco clara o tomadores de decisiones desconocidos. El equipo interno debe preparar: - Diagramas del sistema - Acceso al repositorio - Problemas técnicos actuales - Objetivos comerciales - Límites conocidos - Una persona que pueda responder preguntas ### ¿Cómo se medirá el éxito? Las buenas medidas dependen de la tarea. Para una revisión de la nube, la medida puede ser una lista clara de acciones de costo y confiabilidad. Para una revisión de seguridad, puede ser un informe de riesgos clasificado con propietarios y fechas objetivo. Para el trabajo de rendimiento, puede ser un tiempo de respuesta más rápido en los viajes de usuario acordados. Evite medir el éxito sólo por las horas trabajadas. El resultado útil es una mejor comprensión, menos riesgos o un sistema que el equipo interno puede mantener. ## Cómo trabajar con ingenieros externos La relación suele funcionar mejor cuando el ingeniero externo se une a un proceso definido en lugar de recibir una lista suelta de tareas. Recomiendo esta estructura: 1. Escriba un breve resumen del proyecto. Describa el problema comercial, el sistema actual, el resultado esperado, la fecha límite y los límites. 2. Nombre un propietario interno. Esta persona responde preguntas, revisa decisiones y mantiene el trabajo conectado con los objetivos de la empresa. 3. Otorgue acceso por etapas. Comience con la información necesaria para el descubrimiento. Amplíe el acceso una vez que el alcance esté claro. 4. Establezca puntos de revisión periódicos. Una breve reunión semanal puede exponer la confusión antes de que se convierta en una reelaboración. 5. Requiere documentación. Solicita decisiones, pasos de configuración, riesgos y elementos sin terminar en una ubicación compartida. 6. Planifique la transferencia con anticipación. Los ingenieros internos deben comprender los cambios antes de que finalice la participación externa. Este proceso también protege a la empresa. Limita el acceso, mantiene el conocimiento dentro de la empresa y reduce la dependencia de una sola persona. ## Errores comunes Algunos equipos contratan a un ingeniero externo y esperan que esa persona resuelva todos los problemas técnicos. Eso crea confusión. Otros equipos no dan contexto al especialista. Luego, el ingeniero mejora una parte del sistema sin tener en cuenta una restricción comercial. Un tercer error es elegir basándose únicamente en una tarifa horaria baja. Una contratación más económica puede llevar más tiempo cuando el especialista necesita aprender el sistema desde cero o corregir trabajos poco claros. Busco evidencia de experiencia relevante, comunicación clara, documentación práctica y voluntad de explicar las compensaciones. Un ingeniero externo fuerte debería sentirse cómodo diciendo: "Este cambio aún no es necesario". ## El objetivo es un equipo interno más fuerte. El mejor soporte externo hace más que completar una tarea. Ayuda a los ingenieros internos a ver el sistema desde otro ángulo. Deja documentación, pruebas, decisiones y habilidades que la empresa puede utilizar una vez finalizado el compromiso. Antes de contratar ayuda externa, define el hueco. Decida qué debe retener el equipo interno. Ofrezca al especialista un problema específico, un acceso adecuado y un plan de transferencia claro. El outsider adecuado no quita la propiedad a sus ingenieros. Ayudan a sus ingenieros a dedicar más tiempo al trabajo que sólo ellos pueden realizar.

Los ingenieros no se resisten al cambio porque no les guste el progreso. Se resisten a afirmaciones poco claras, pruebas débiles, decisiones apresuradas y herramientas que crean más trabajo para el equipo. Cuando un nuevo sistema afecta la producción, las pruebas, el mantenimiento o la seguridad, el escepticismo es una respuesta práctica. Los ingenieros saben que un pequeño cambio en un proceso puede generar retrasos en otro lugar. He visto este patrón muchas veces. Un proyecto comienza con respuestas breves como "ahorrará tiempo" o "la configuración es fácil". El equipo de ingeniería solicita datos de prueba, detalles de integración, límites de fallas y planes de soporte. Si se ignoran esas preguntas, la confianza cae rápidamente. Esa reacción no es una barrera. Es una retroalimentación útil. Obtengo el apoyo de los ingenieros respetando la forma en que evalúan el riesgo. ### Empiezo con el problema que ya sienten. Los ingenieros rara vez necesitan otra promesa general. Necesitan ayuda con un problema específico: - Comprobaciones manuales repetidas - Ciclos de aprobación lentos - Datos de producción poco claros - Mantenimiento del sistema difícil - Demasiadas alertas falsas - Herramientas que no se ajustan al equipo existente - Informes que tardan horas en prepararse Pregunto dónde se pierde tiempo, qué errores aparecen con más frecuencia y qué tareas el equipo evitaría cambiar a menos que el beneficio fuera claro. Las respuestas dan forma a la discusión. Un equipo de mantenimiento puede preocuparse por tener menos interrupciones. A un grupo de diseño le puede interesar tener datos de prueba más limpios. Un gerente de planta puede centrarse en la producción y el tiempo de capacitación. Un mensaje no puede servir para todas las funciones. ### Muestro cómo la solución se adapta al proceso actual. La resistencia a menudo crece cuando un producto se presenta como un reemplazo completo de un flujo de trabajo existente. Los ingenieros quieren saber qué permanece, qué cambia y qué sucede si el nuevo proceso no funciona como se esperaba. Explico los puntos de conexión en lenguaje sencillo: - Qué datos recibe el sistema - Con qué equipo o software se conecta - Qué ve el operador - Qué se puede ajustar - Cómo se verifican los resultados - Cómo puede el equipo volver al proceso anterior Este nivel de detalle les brinda a las personas algo que pueden revisar. También revela los problemas antes de que se vuelvan costosos. Una demostración útil no oculta las partes difíciles. Muestra la configuración, el flujo de trabajo diario y los límites. Si la herramienta necesita datos de entrada limpios, lo digo. Si el entrenamiento lleva tiempo, lo incluyo en el plan. ### Dejé que el equipo probara la afirmación. Una presentación de diapositivas puede generar interés. Una prueba controlada genera confianza. Normalmente sugiero un pequeño piloto con un punto de partida claro. El equipo selecciona un proceso, un grupo de usuarios o un tipo de tarea. Registramos la condición actual antes de realizar cambios. Las mediciones pueden incluir: - Tiempo dedicado a la tarea - Número de pasos manuales - Correcciones de errores - Tiempo de inactividad vinculado a la tarea - Preguntas de los usuarios o solicitudes de soporte - Resultados de calidad después del cambio Luego, el equipo compara los resultados del piloto con el registro anterior. Este enfoque ofrece a los ingenieros una forma justa de juzgar el producto sin pedirles que acepten una promesa amplia. Por ejemplo, un equipo de producción puede dedicar dos horas cada semana a verificar el mismo conjunto de registros. Un piloto puede realizar un seguimiento de cuánto tiempo lleva la verificación con el nuevo flujo de trabajo, con qué frecuencia es necesario corregir el resultado y si el informe final sigue siendo preciso. El resultado puede mostrar una mejora clara, una pequeña mejora o ningún cambio útil. Cada resultado proporciona información. ### Respondo preguntas difíciles directamente Las preguntas sobre seguridad, mantenimiento, compatibilidad y condiciones de falla no son signos de rechazo. Muestran que el equipo está pensando más allá de la reunión de ventas. Evito respuestas que suenan pulidas pero que dicen poco. Si no tengo la respuesta digo que la verificaré. Una respuesta cuidadosa genera más confianza que una suposición rápida. Los ingenieros pueden preguntar: - ¿Qué sucede cuando falla la conexión? - ¿Puede el equipo exportar sus datos? - ¿Quién se encarga del soporte? - ¿Con qué frecuencia necesita mantenimiento el sistema? - ¿Se pueden cambiar los ajustes más tarde? - ¿El flujo de trabajo funciona durante los picos de demanda? - ¿Qué costes pueden aparecer tras el despliegue? Estas preguntas merecen respuestas específicas. También ayudan a los tomadores de decisiones a comprender el alcance real del proyecto. ### Involucro a las personas que utilizarán el sistema. Un gerente puede aprobar una herramienta, pero los operadores e ingenieros viven con el resultado todos los días. Sus aportes pueden identificar problemas que no aparecen en una revisión formal. Invito a los usuarios a probar el flujo de trabajo y describir lo que les parece lento, confuso o innecesario. Un pequeño detalle de la interfaz puede afectar a decenas de tareas cada día. Una opción de exportación faltante puede generar trabajo adicional para otro departamento. Cuando los usuarios ven sus comentarios reflejados en la configuración, el producto se siente menos como una instrucción externa y más como una parte viable del proceso. ### La celebración surge de la evidencia. La mejor reacción no ocurre cuando hago la promesa más grande. Ocurre cuando el equipo de ingeniería ve que la solución funciona como se describe, se ajusta al proceso existente y reduce un problema que les preocupa. A veces la reacción es tranquila. Un ingeniero experimentado puede decir: "Esto es más fácil de mantener de lo que esperaba". Un operador puede dejar de solicitar una solución alternativa manual. Un líder de proyecto puede utilizar el tiempo ahorrado para abordar otro problema de producción. Esos momentos importan más que una respuesta cortés a una reunión. Los ingenieros no necesitan ser persuadidos mediante presión. Necesitan un problema claro, información honesta, un plan comprobable y suficiente control para juzgar el resultado por sí mismos. Cuando proporciono esas condiciones, la resistencia a menudo se transforma en un soporte cuidadoso. El equipo no está celebrando un argumento de venta. Se celebra una solución que resultó útil en el trabajo que importa.

Es posible que su equipo tenga objetivos claros y todavía tenga dificultades para avanzar en la misma dirección. Las reuniones se prolongan. Las tareas cambian sin previo aviso. Unas pocas personas realizan la mayor parte del trabajo, mientras que otras esperan una orientación más clara. El problema no siempre es el esfuerzo. Puede deberse a roles poco claros, retroalimentación débil o un proceso que ya no se adapta al trabajo. No desafío los objetivos que te has fijado. Desafío los hábitos, suposiciones y patrones de equipo que hacen que esos objetivos sean más difíciles de alcanzar. Cuando trabajo en equipo, empiezo escuchando. Quiero entender cómo el trabajo pasa de una idea a un resultado final, dónde aparecen los retrasos y qué necesitan los miembros del equipo unos de otros. Una revisión típica puede analizar: - Cómo se comparten las prioridades - Quién toma cada decisión - Dónde se vuelven confusas las tareas - Cómo se brinda la retroalimentación - Qué reuniones ayudan al trabajo - Qué reuniones crean trabajo extra - Cómo se rastrea el progreso - Qué impide que las personas planteen inquietudes Este proceso le da al equipo una visión compartida de la situación. También ayuda a separar un problema de personas de un problema de proceso. Un plazo incumplido, por ejemplo, puede no deberse a un compromiso deficiente. Es posible que un equipo haya recibido tres cambios de prioridad diferentes en una semana, haya esperado la aprobación de dos gerentes y haya trabajado a partir de un resumen de proyecto desactualizado. Pedirle al equipo que "trabaje más duro" no solucionaría la causa. Una mejor respuesta podría incluir: - Un propietario claro para cada decisión - Un resumen breve del proyecto escrito - Una forma sencilla de registrar los cambios - Puntos de revisión definidos - Un camino directo para aumentar los riesgos - Una verificación semanal de la carga de trabajo y las prioridades Estos cambios dan a las personas espacio para concentrarse en su trabajo en lugar de adivinar qué debería suceder a continuación. También desafío los hábitos del equipo con cuidado. Si una reunión no tiene un propósito claro, puedo preguntar si es necesario continuar. Si un gerente responde todas las preguntas, puedo preguntar cómo el equipo puede generar más confianza al tomar decisiones. Si los comentarios llegan sólo después de que se completa un proyecto, puedo sugerir puntos de revisión más breves durante el trabajo. El objetivo no es hacer que todos los equipos funcionen de la misma manera. Un equipo creativo, un grupo de atención al cliente y un departamento de ingeniería pueden necesitar ritmos diferentes. El proceso útil es el que coincide con el trabajo y ayuda a las personas a actuar con menos confusión. Un plan práctico de mejora del equipo suele seguir este camino: 1. Escuchar al equipo Recopilo opiniones de los gerentes y miembros del equipo. Las conversaciones privadas pueden ayudar a las personas a hablar más abiertamente sobre la presión, las expectativas poco claras y los obstáculos repetidos. 2. Asignar el flujo de trabajo actual Observamos cómo se asignan, revisan, modifican y completan las tareas. Esto a menudo revela pasos que ya no sirven al equipo. 3. Elija un pequeño conjunto de cambios Evito darle a los equipos una lista larga de reglas nuevas. Nos centramos en cambios que pueden mejorar el trabajo diario sin añadir una administración pesada. 4. Pruebe los cambios El equipo utiliza el nuevo enfoque durante un período determinado. Observamos qué mejora, qué se siente difícil y qué necesita ajustes. 5. Revise el efecto Utilizamos señales claras, como menos reuniones repetidas, decisiones más rápidas, mejor propiedad de las tareas y comentarios más útiles. Los números pueden ayudar, pero la experiencia del equipo también importa. 6. Conserve lo que funciona Un proceso debe seguir siendo útil una vez finalizado el trabajo de coaching o consultoría. El equipo necesita hábitos simples que pueda manejar sin apoyo externo constante. Creo que los desafíos saludables deberían generar mejores conversaciones, no miedo. Las personas deberían poder cuestionar un proceso sin ser tratadas como un problema. Los gerentes deberían poder recibir retroalimentación sin perder autoridad. Los miembros del equipo deben saber qué poseen, qué pueden decidir y cuándo necesitan ayuda. Tus objetivos le dan dirección al equipo. Mi función es ayudar a eliminar los patrones que ralentizan al equipo, exponer las brechas que son fáciles de pasar por alto y respaldar cambios que se ajusten a la forma en que trabaja su gente. El desafío está dirigido al sistema que rodea al equipo, no al valor del equipo en sí.

Solía ​​pensar que un buen trabajo de ingeniería hablaría por sí solo. Si el diseño era limpio, el código estaba bien estructurado y la explicación técnica era sólida, esperaba que la gente reconociera su valor. Muchos ingenieros piensan de esta manera. Pasamos horas mejorando un sistema, probando casos extremos y resolviendo problemas que la mayoría de los usuarios nunca ven. Entonces llegan los resultados. Un servicio más rápido recibe más atención que un hermoso diagrama de arquitectura. Una herramienta que elimina tres pasos manuales obtiene más apoyo que un informe técnico extenso. Una característica que ayuda a los clientes a completar una tarea con menos errores a menudo importa más que la cantidad de ideas inteligentes detrás de ella. Esa lección puede resultar incómoda, pero es útil: la gente rara vez juzga la ingeniería sólo por el esfuerzo. Lo juzgan por los cambios después de que se publica el trabajo. ## La brecha entre el buen trabajo y el trabajo útil Una vez trabajé con un equipo que pasó semanas mejorando una herramienta de informes internos. El equipo limpió el código, agregó filtros flexibles y reconstruyó varias pantallas. El resultado parecía pulido. El uso apenas cambió. El principal problema no fue la interfaz. La mayoría de los empleados no necesitaban más filtros. Necesitaban que el informe se cargara más rápido y se exportara en un formato que sus gerentes pudieran leer. El equipo había mejorado el producto desde el punto de vista de ingeniería, pero no había resuelto el problema diario. Una actualización más pequeña cambió el resultado. Redujimos el tiempo de carga, agregamos una opción de exportación y eliminamos un paso del flujo de trabajo. Los empleados empezaron a utilizar la herramienta con más frecuencia porque se adaptaba a su rutina. La lección no fue que el código limpio careciera de valor. El código limpio ayudó al equipo a mantener el sistema. El error fue tratar la calidad interna como lo mismo que el valor para el usuario. Están relacionados, pero no son idénticos. ## Los resultados dan dirección al trabajo técnico Cuando comienzo un proyecto, intento definir el resultado antes de discutir la solución. Un objetivo vago suena así: "Mejorar la plataforma". Un objetivo útil suena así: "Ayudar al personal de soporte a encontrar el registro de un cliente en menos de un minuto". El segundo objetivo le da al equipo de ingeniería algo que probar. También ayuda al equipo a rechazar el trabajo que parece impresionante pero que no influye en el resultado. Este enfoque ayuda en tres áreas: - Da a las decisiones de diseño un propósito claro. - Hace que las compensaciones sean más fáciles de explicar. - Le da al equipo una forma de comprobar si el trabajo ayudó. No es necesario que el resultado sea una cifra de ingresos elevada. Podría ser un tiempo de respuesta más corto, menos pagos fallidos, menos tickets de soporte, menores costos operativos o un proceso más seguro para el personal. La medida debe coincidir con el problema. ## Paso 1: Encuentre los problemas antes de elegir la función. Los ingenieros suelen recibir solicitudes de funciones en forma de solución. "Agregar un panel". "Crear una API". "Cree una alerta automatizada". Estas solicitudes pueden resultar útiles, pero no constituyen el problema en sí. Pregunto qué está tratando de hacer la gente, dónde se interrumpe el proceso y qué sucede cuando se interrumpe. Un equipo puede solicitar un panel porque los gerentes no pueden ver los pedidos atrasados. La mejor solución podría ser un simple informe diario. Otro equipo puede solicitar la automatización porque la entrada de datos lleva demasiado tiempo. Un formulario con mejores valores predeterminados podría resolver el problema con menos mantenimiento. La solicitud es un punto de partida. La dificultad del usuario debe guiar el trabajo. Cuando hablo con los usuarios, prefiero preguntas como: - ¿Qué tarea lleva más tiempo? - ¿Dónde ocurren los errores? - ¿Qué haces cuando el sistema falla? - ¿Qué paso evitas? - ¿Qué haría que este proceso fuera más fácil de completar? Estas preguntas suelen revelar una solución más pequeña y útil. ## Paso 2: Conectar el trabajo técnico con un resultado visible Las tareas técnicas pueden parecer desconectadas de los resultados comerciales. Es posible que la refactorización, los cambios en la base de datos, la cobertura de pruebas, el registro y las actualizaciones de seguridad no creen una función inmediata para el usuario. Eso no los hace menos valiosos. Es necesario explicar la conexión. Un cambio en la base de datos puede reducir los errores de tiempo de espera durante los períodos de mayor actividad. Un mejor registro puede reducir el tiempo necesario para diagnosticar un incidente. Un conjunto de pruebas puede permitir al equipo publicar cambios con menos defectos. Una solución de seguridad puede proteger los datos de los clientes y reducir el riesgo operativo. Intento describir el trabajo en este formato: "Estamos cambiando X para que Y pueda mejorar". Por ejemplo: "Estamos mejorando el índice de búsqueda para que el personal de soporte pueda encontrar registros sin esperar una consulta lenta". "Estamos agregando pruebas automatizadas en torno a los reintentos de pago para que las transacciones fallidas puedan manejarse con menos comprobaciones manuales". Este lenguaje ayuda a los socios no técnicos a comprender por qué el trabajo es importante. También ayuda a los ingenieros a cuestionar tareas que no tienen un propósito claro. ## Paso 3: Elija una medida antes del lanzamiento Un equipo no puede aprender mucho de un proyecto si nadie sabe qué mirar. Antes de la liberación, elijo una o dos medidas útiles. Demasiados números pueden ocultar la señal real. Para una función de búsqueda, podría realizar un seguimiento de: - Tiempo de búsqueda promedio - Abandono de búsqueda - Recuperación exitosa de registros - Solicitudes de soporte relacionadas con registros faltantes Para un cambio de pago, podría realizar un seguimiento de: - Tasa de finalización de pagos - Frecuencia de errores - Tiempo necesario para completar el pago - Contactos de atención al cliente sobre pagos fallidos La medida debe ser fácil de recopilar y estar conectada con la tarea del usuario. Un recuento alto de páginas vistas puede parecer positivo, pero puede significar que las personas siguen regresando porque no pueden encontrar lo que necesitan. Los números necesitan contexto. Un resultado no es útil cuando el equipo no sabe qué comportamiento lo produjo. ## Paso 4: envíe una versión pequeña y escuche. Los proyectos grandes crean grandes brechas entre el esfuerzo y la retroalimentación. Durante esa brecha, las suposiciones pueden crecer. Prefiero un lanzamiento más pequeño cuando el riesgo es manejable. Una versión limitada permite al equipo observar el uso real, recopilar preguntas y ajustar el plan. Una empresa de logística probó una vez una alerta de entrega con un grupo de conductores en lugar de transmitirla a toda la operación. El equipo esperaba que los conductores quisieran más tipos de notificaciones. La prueba mostró una necesidad diferente: los conductores querían menos alertas, con instrucciones más claras. Esa retroalimentación cambió el producto antes del lanzamiento más amplio. Los lanzamientos pequeños no se tratan de bajar los estándares. Son una forma de aprender antes de dedicar más tiempo a detalles incorrectos. ## Paso 5: Trate los comentarios como información del producto Los comentarios negativos pueden parecer personales, especialmente cuando un ingeniero ha invertido mucho tiempo en una solución. Intento separar el trabajo de la persona. Si los usuarios ignoran una característica, eso no significa que el ingeniero fracasó como profesional. Significa que el equipo ha aprendido algo sobre el problema, el momento o el diseño. Un usuario que dice "No uso esto" puede estar dando comentarios incompletos. Un usuario que dice: "No puedo terminar mi tarea porque este botón aparece solo después de ingresar datos", le da al equipo un camino claro para investigar. Busco comportamientos, no sólo opiniones: - ¿Los usuarios completan la tarea? - ¿Crean soluciones alternativas? - ¿Piden ayuda? - ¿Vuelven al antiguo proceso? - ¿Utilizan la función de la forma que esperaba el equipo? El comportamiento real a menudo cuenta una historia diferente a la de una discusión en una reunión. ## Paso 6: Mantenga juntos la calidad y los resultados Los resultados no deben convertirse en una excusa para una ingeniería deficiente. Una solución apresurada puede mostrar una mejora a corto plazo y generar costos más altos en el futuro. Los tiempos de respuesta lentos, el código frágil, la propiedad poco clara y la seguridad deficiente pueden convertir una pequeña victoria en un problema mayor. Utilizo dos preguntas al mismo tiempo: "¿Esto ayuda al usuario?" "¿Podemos respaldarlo de manera segura y confiable?" Ambas preguntas importan. Una función rápida que pierde datos de los clientes no es un buen resultado. Un sistema estable que nadie puede utilizar no es un producto útil. La calidad de la ingeniería respalda resultados duraderos, mientras que los resultados de los usuarios ayudan al equipo a decidir dónde se debe prestar atención al trabajo de calidad. El equilibrio cambia con la situación. Un problema de seguridad necesita pruebas cuidadosas. Un experimento interno simple puede necesitar un proceso más ligero. El buen juicio surge de comprender el riesgo, no de aplicar una regla a cada proyecto. ## Por qué los ingenieros a veces se resisten a esta idea A algunos ingenieros les preocupa que centrarse en los resultados signifique que se ignorará el juicio técnico. Esa preocupación es razonable. La presión empresarial puede empujar a los equipos hacia cifras a corto plazo y soluciones rápidas. La respuesta no es rechazar la medición. La respuesta es elegir mejores medidas y explicar el costo de las malas decisiones. Si un equipo quiere reducir el costo del servidor, los ingenieros pueden mostrar cómo un presupuesto más bajo puede afectar el tiempo de respuesta o la confiabilidad. Si un equipo quiere realizar un lanzamiento rápido, los ingenieros pueden identificar qué comprobaciones protegen a los usuarios y qué pasos pueden esperar. Una cultura basada en resultados debería generar mejores conversaciones, no silenciar las preocupaciones técnicas. Mi papel como ingeniero no es sólo construir lo solicitado. Es para ayudar al equipo a comprender qué cambiará la solicitud, qué no cambiará y qué riesgos conlleva. ## El trabajo se vuelve más fácil de explicar Cuando los resultados guían el proyecto, las actualizaciones de estado se vuelven más útiles. En lugar de decir: "Completamos el nuevo servicio de búsqueda". Puedo decir: "El nuevo servicio de búsqueda redujo el tiempo promedio de búsqueda de 18 segundos a 6 segundos en el grupo piloto. Aún quedan tres casos de falla bajo revisión". Esa frase le da a la gente una imagen más clara. Muestra el progreso, la evidencia y la próxima área de trabajo. También protege al equipo de elogios vacíos. Una tarea completada no siempre es un resultado exitoso. La versión debe probarse según el motivo por el que se creó. ## Lo que no significan mejores resultados. Mejores resultados no significan perseguir todas las métricas. No significan tomar atajos. No se refieren a construir sólo lo que se puede medir en una semana. Algunos trabajos de ingeniería protegen la confiabilidad futura, respaldan la accesibilidad, mejoran la seguridad o reducen el riesgo. Su valor puede aparecer a través de problemas que nunca suceden. Ese valor aún necesita una explicación clara. El objetivo no es convertir cada decisión de ingeniería en un argumento de venta. El objetivo es conectar el esfuerzo con una necesidad real y hacer visible la compensación. He aprendido a respetar más el buen trabajo técnico cuando puedo ver a quién ayuda, qué problema reduce y cómo sabrá el equipo si funcionó. Un diseño limpio es útil. Un sistema bien probado es útil. Una idea técnica sólida se vuelve mucho más valiosa cuando mejora el trabajo de una persona, reduce la frustración de un cliente o ayuda a una empresa a operar con menos desperdicio. El código importa. El resultado nos dice si el código importó de la manera que pretendíamos. Para cualquier consulta sobre el contenido de este artículo, comuníquese con Hu Peng: 756759203@qq.com/WhatsApp +8613867775312.

Nicole Forsgren, Jez Humble y Gene Kim, 2018, Accelerate: The Science of Lean Software and DevOps Gene Kim, Kevin Behr y George Spafford, 2013, The Phoenix Project: una novela sobre TI, DevOps y cómo ayudar a su negocio a ganar Martin Fowler, 2018, Refactoring: Improving the Design of Existing Code Eric Ries, 2011, The Lean Startup: Cómo Los emprendedores de hoy utilizan la innovación continua para crear negocios radicalmente exitosos Google, 2023, Ingeniería de confiabilidad del sitio: cómo ejecuta Google los sistemas de producción NIST, 2018, Marco para mejorar la ciberseguridad de infraestructuras críticas versión 1.1