Introducción
Basándose en el artículo de Joe Ackert "Herramientas para la caja de herramientas", uno de los puntos de los que habla es "Aportar valor". Aportar valor como ingeniero puede ayudarte a desarrollar tu carrera y ascender en el escalafón. Sin embargo, las descripciones de lo que hay que hacer para aportar ese valor pueden ser bastante confusas. Está la típica orientación críptica de "Apropiarse de la función" o "comunicar con eficacia".
Para ayudar a entender esta orientación, me gusta utilizar la frase "¿Qué aspecto tiene eso? Por ejemplo: ¿Qué aspecto tiene la propiedad? ¿O qué aspecto tiene comunicar eficazmente? Tomaré esta pregunta y te mostraré cómo es aportar valor al tiempo que te ayudo a entender las crípticas descripciones de la escala profesional.
En este ejemplo, tu jefe se te acerca después y te dice: "Necesito que te encargues de la nueva función de perfil de usuario". Como desarrollador web, tienes la tarea de crear una página en la que los usuarios puedan ver y editar su información personal. ¿Qué significa ser el propietario de esta función, dirigirla y comunicarla eficazmente?
Diseño de software
El paso inicial de la escritura de software una vez redactados los requisitos suele ser el diseño del software. Ser propietario de la solución no es sólo escribir el código, es asegurarse de que la función satisface las necesidades del cliente, tiene alta calidad y se entrega a tiempo. Podría decirse que ese es el trabajo del propietario del producto, o el trabajo de QA, o el trabajo del equipo de la base de datos. Sin embargo, al ser dueño de la solución, un desarrollador eficaz se asegura de que todo esto suceda de una manera que funcione bien con todo el mundo.
Aclare los requisitos: Es posible que ya haya revisado la historia de usuario con el equipo. A menudo, necesitarás alguna aclaración durante el sprint. En lugar de enviar un correo electrónico o un mensaje de Slack y esperar la respuesta, mantén una conversación con el propietario del producto para aclarar cualquier criterio de aceptación: Tal vez el equipo omitió campos obligatorios. ¿Cómo deben tratarse los errores? ¿Hay consideraciones de cumplimiento o seguridad para los datos de los usuarios?
Apropiarse es comprender la solución completa para poder completar un diseño minucioso con el equipo. Tampoco se trata de esperar aclaraciones que podrían causar retrasos, sino de ponerse en contacto directamente. La comunicación eficaz también es mejor en persona o por teléfono.
Implique a las personas adecuadas: Involucra a los miembros del equipo que trabajan en la función desde el principio para discutir cómo se obtendrán y actualizarán los datos en la base de datos. Concierte una cita con el diseñador de UX/UI para revisar los esquemas. No espere a que el scrum master organice estas conversaciones.
Te adueñas de la función al establecer tú mismo las conversaciones. Avanzas sin esperar. Y te comunicas de forma eficaz poniéndote en contacto con otros miembros del equipo o manteniéndolos al tanto de las novedades a través de Slack o en reuniones.
Colabora para identificar dependencias: Asegúrate de que todos los miembros de tu equipo y de otros equipos sepan qué piezas técnicas dependen unas de otras y sigan el progreso. Si la API de backend se retrasa, señálalo inmediatamente y sugiere alternativas al equipo de interfaz de usuario (como el stubbing de datos localmente). La propiedad está en la comunicación proactiva y eficaz de las dependencias y los detalles del diseño.
Como puede ver, la implicación, la comunicación eficaz y la aportación de valor van de la mano. La diferencia entre un ingeniero que aporta valor y un ingeniero que se limita a hacer lo mínimo es que no esperas a que el jefe de proyecto o el scrum master resuelvan los problemas, sino que te anticipas a ellos y los abordas. También te comunicas bien asegurándote de que los demás son conscientes de las posibles repercusiones en su trabajo. Trabajar directamente con otros miembros del equipo puede aportar valor y ser mucho más eficaz que pedir al gestor del proyecto que programe y documente las reuniones por ti.
Aplicación
Ahora que se han identificado todas las dependencias, se han creado todas las subtareas y se ha completado el diseño del software. Empiece a trabajar en el desarrollo simplemente tomando las tareas de alta prioridad del backlog. No espere a que el scrum master se las asigne.
Solicite ayuda: Si has estado trabajando en la conexión del frontend a la API del backend para actualizar los datos del usuario, pero estás atascado con un error extraño que sigue lanzando códigos de estado 500. Después de 45 minutos de depuración, no puedes resolverlo sin demora. Después de 45 minutos de depuración, no se puede averiguar, llegar sin demora. Pide ayuda al desarrollador del backend. No te limites a decir: "No funciona". Ven con el contexto: "Estoy viendo errores 500 cuando intento actualizar el campo de dirección. Lo he rastreado hasta el formato JSON, pero no estoy seguro de por qué se rechaza". Antes de pedir ayuda, inténtalo todo dentro de lo razonable y, cuando lo hagas, ven preparado con información específica, no sólo con el problema. He descubierto que el 99% de las veces alguien sabe cuál es el problema. O, si no lo saben, hablarlo con otra persona ayuda a identificarlo.
Seguimiento: A medida que avanza la implementación, haga un seguimiento con los otros miembros del equipo si es necesario enviando un mensaje rápido de Slack para confirmar que su API estará lista para la integración el viernes. Busque una respuesta de algún tipo, como los globos oculares o un pulgar hacia arriba. Hacer referencia a una persona directamente y buscar una respuesta ayuda con la comunicación porque entonces sabes que han recibido el mensaje.
Ofrezca soluciones: Si una tarea se está retrasando, responsabiliza a los demás miembros del equipo haciendo un seguimiento de los entregables con ayuda del gestor del proyecto. El gestor del proyecto hará un seguimiento del progreso o de los cambios en el plan, y tú puedes ofrecer recomendaciones sobre cómo avanzar. Envía un mensaje al responsable del backend: "Oye, me he dado cuenta de que la API aún no está lista. ¿Estás teniendo problemas? Puedo ajustar mis plazos, pero tenemos que elaborar un plan para no bloquear el lanzamiento de la función". Esto es buena comunicación y apropiación. Has identificado un problema y has trabajado con otros miembros del equipo para resolverlo directamente. Si se produce un retraso, puedes informar directamente al jefe de proyecto con actualizaciones, ahorrándole tiempo.
Ayude a los demás: Ser propietario de la implementación no significa necesariamente escribir el código uno mismo. También significa ayudar a otros miembros del equipo en su trabajo. Si puedes ayudar a otros tres miembros del equipo a mejorar sus esfuerzos en un 10 %, habrás aumentado la eficacia del equipo en un 30 % con respecto a si lo haces tú solo.
Informe sobre los progresos: A medida que avanza la implementación, la comunicación también aparece en pequeños elementos como la administración. A lo largo del desarrollo asegúrate de actualizar los tickets de JIRA para reflejar que el frontend y el backend están integrados, anota cualquier tarea pendiente como más pruebas o ajustes de accesibilidad.
Informa inmediatamente cuando hayas terminado una tarea. Si has terminado pronto una parte del código, no hace falta que esperes a la reunión de la mañana siguiente para comunicárselo a los demás. Publica una actualización en Slack: "La página de perfil de usuario está funcionalmente completa. Integración de la API terminada. Pruebas finales en curso, en camino para el lanzamiento de la próxima semana".
Por pequeño que parezca, mantener informados a sus tickets, partes de horas y partes interesadas sin necesidad de recordatorios aporta valor. Ninguna de estas tareas requiere mucho tiempo. Todas ayudan a la comunicación. Cuando un propietario o gerente de producto debe volver a ti para mantener los tickets actualizados o preguntar sobre detalles que podrías haber comunicado, lleva tiempo y esfuerzo adicionales que podrías haber ahorrado con un simple mensaje o actualización.
En este punto, la cantidad de esfuerzo que un ingeniero dedica a una función empieza a disminuir, pero la aportación de valor a través de la propiedad no se detiene. Pasamos a las pruebas y el despliegue.
Pruebas y despliegue
A medida que la función pasa por los siguientes pasos, desde las pruebas funcionales hasta las pruebas de integración y las pruebas de usuario, asegúrate de que los demás miembros del equipo tienen lo que necesitan para realizar las pruebas.
Seguimiento de las implantaciones: Ponte en contacto para asegurarte de que las implantaciones se realizan correctamente, de que los miembros del equipo de pruebas disponen de los datos que necesitan o responde a algunas preguntas rápidas para que las cosas avancen.
Haz tú mismo el seguimiento de las métricas: Tras la implantación, haga un seguimiento de las mejoras esperadas en las métricas. Quizá disminuya el tiempo de respuesta del servicio web o aumente la tasa de conversión de las compras.
"¿Cómo es poseer una solución?"
Responder a la pregunta "¿Qué aspecto tiene eso?" da lugar a la búsqueda de acciones que se pueden llevar a cabo para aportar valor. En este caso, se trata de poseer una solución y aportar valor. Pueden ser otras cosas.
Aportar valor a un proyecto no es sólo completar una tarea, sino también liderar el esfuerzo buscando acciones que ayuden a avanzar en el proyecto. La siguiente lista es un buen comienzo, pero en ningún caso es completa.
- Comunicación proactiva
- Proporcione información actualizada sin esperar a que se la pidan
- Haga usted mismo el seguimiento de las solicitudes sin esperar mucho tiempo
- Colabore con las personas que puedan verse afectadas por la nueva función
- Resuelve tus propios problemas.
- Presénteles opciones para resolver un problema junto con una recomendación sobre la solución.
- Ayudar a otros miembros del equipo en tareas difíciles.
- Póngase en contacto con otros equipos
- Garantizar el éxito de las implantaciones
Busca tus propias formas de hacer avanzar el proyecto actuando. Eso es aportar valor y liderazgo.
