Gestión de Ingeniería de Software en 2023
Mi nombre es Mirek Stanek. Pasé los últimos diez años desarrollando tecnología y liderando equipos detrás de ella. Realmente amé cada día de eso.
En una de mis publicaciones de blog anteriores , describí la situación de la industria tecnológica en 2022/2023. Debido a las duras condiciones del mercado, los despidos y los recortes presupuestarios, algunos líderes de ingeniería deberán redefinir sus roles en una organización. Comparé esa situación con ser un líder de ingeniería en una etapa inicial de inicio y destaqué algunos puntos que pueden ser críticos para su éxito:
- Forma un equipo de misioneros, no de mercenarios
- Concéntrese en las soluciones, no en los problemas: este artículo
- Haga crecer su equipo, construya su confianza
- Vuelva a codificar, líder de ingeniería
En este artículo, me centraré en el aspecto práctico del descubrimiento de productos: encontrar soluciones en lugar de posibles problemas y casos extremos.
Volvamos a la oración que destaqué en la publicación anterior del blog:
El papel de la tecnología en una empresa de productos es resolver los problemas de los clientes.
Siempre es fácil decir, «centrarse en los resultados». Pero si, después de leer este consejo, regresa a las tareas pendientes que esperan ser preparadas, estimadas e implementadas, ¿hay algo que realmente pueda hacer para concentrarse en los problemas en lugar de solo crear características ?
¿Trabajas con requisitos o hipótesis?
Estar “orientado a los resultados” es parte de la cultura de la organización. Esto es algo que debería venir de arriba hacia abajo. Para validar eso, intente comprender de qué es responsable su equipo: entregar características o entregar valor (lo cubrí en el párrafo » definir la responsabilidad por los resultados «).
Entregar valor es entregar funciones, pero no siempre funciona de la manera opuesta. Puede ofrecer características que no tienen ningún valor para los clientes. Si es así, no solo desperdicia el tiempo de su equipo, sino que también aumenta la complejidad del producto, la deuda tecnológica y el trabajo futuro de ejecución y mantenimiento.
Es por eso que trabajar solo con requisitos es arriesgado. Usted asume que quienquiera que haya venido con ellos (PM y partes interesadas, muy probablemente) sabe exactamente lo que se debe hacer, y sus ingenieros solo deben ejecutar eso.
Es mejor asumir que trabaja con una lista de hipótesis para probar en lugar de una lista de requisitos para construir. En empresas más maduras, las hipótesis estarán impulsadas por los resultados esperados (p. ej., aumentar la base de clientes en x, obtener y nuevos clientes en el nuevo mercado). En empresas menos maduras, puede ser la visión del fundador. De cualquier manera, su trabajo es probar hipótesis sobre cómo hacer realidad los resultados esperados o la visión.
En un nivel alto, hay dos tipos de hipótesis en las que puede centrarse:
- una hipótesis de valor (resuelve problemas reales que tienen los clientes), o
- una hipótesis de crecimiento (qué tan rápido puede adquirir más clientes y cómo disminuir el costo de adquisición de clientes).
El “Ajuste del problema/solución” (el valor) y el “Ajuste del producto/mercado” (el crecimiento) son ampliamente conocidos en el mundo de la economía de las empresas emergentes. Te animo a que los busques en Google.
Para usted y su equipo de ingeniería, significa que necesita crear una solución que resuelva los problemas de los clientes (el valor). Debe construirlo rápidamente, hacerlo fácil de mantener a lo largo del tiempo y fácil de escalar (el crecimiento).
O al revés. Si construye las cosas equivocadas, no aumenta el valor. La complejidad del producto crece, por lo que el mantenimiento. Si no construye las cosas correctas, ampliarlas no tiene sentido.
Centrarse en las soluciones, no en los problemas
Es parte de la cultura de una empresa estar «orientada a los resultados». A menos que venga de arriba, no es fácil implementarlo de abajo hacia arriba. Pero hay una cosa práctica que usted y su equipo pueden hacer como primer paso.
Concéntrese en brindar soluciones, no solo en señalar posibles problemas.
Durante la próxima sesión de refinamiento, vea cómo es la comunicación entre el Gerente de Producto y los ingenieros. ¿PM presenta funcionalidades y los ingenieros la bombardean con la lista de posibles casos extremos?
Si es así, necesitas luchar contra esta dinámica. La intención parece buena: señalar todos los posibles problemas para crear un producto que sirva a todos los clientes y esté libre de errores. Pero la lógica es incorrecta: los ingenieros no están allí para encontrar lagunas en la lista de requisitos. Los ingenieros están ahí para asociarse con el Gerente de Producto y el Diseñador de Producto para encontrar la mejor solución y luego entregarla.
Veamos el ejemplo del trabajo diario de los ingenieros.
Supongamos que crea la función de vista previa de archivos para la aplicación móvil. Los requisitos dicen que debe tener la funcionalidad para obtener una vista previa de archivos PDF, PNG, JPG y otros formatos de imagen. Hay dos formas de abordarlo.
Escenario 1: enumerar todas las lagunas en los requisitos
Si su equipo se enfoca en los requisitos durante la sesión de refinamiento, escuchará algo como:
- «Te olvidaste del formato HEIF del iPhone». , o
- «¿Cuál es el tamaño máximo de la imagen que podemos manejar?» , o
- “¿Qué pasa con todos los estándares de PDF? ¿Qué sucede si los archivos PDF están protegidos?” , o
- “Necesitamos tener TODO escrito en los requisitos por adelantado porque si nos olvidamos de algo, tendremos que obligar a nuestros clientes a actualizar la aplicación para obtener soporte para el nuevo formato de datos”.
Los ingenieros probablemente saldrán de la reunión satisfechos con los resultados. Al final, enumeraron la mayoría, si no todas, las cosas que pueden salir mal. Protegieron un producto de fallas y mejoraron la previsibilidad de las estimaciones. 🦸♂️
Mientras tanto, el Gerente de Producto toma todos los comentarios, trata de responder tantas preguntas como sea posible, discute el resto con el líder del equipo o las partes interesadas del proyecto, y presenta boletos como este:
- Formatos admitidos: PNG, JPG, PDF, HEIC, HEIF, WEBP
- Cree un estado de vista previa vacío y un botón de descarga para todos los archivos de más de 20 MB
- Mensaje de error de compilación «Este archivo no es compatible» para todos los demás formatos
- Cree un mensaje de error personalizado para archivos PDF con contraseña
¿Qué pasa aquí? En lugar de discutir soluciones con todo el equipo, usamos sus mentes solo para señalar posibles fallas en la idea. La idea que no es necesariamente la mejor disponible en este momento.
¿Cómo podría haber sido esta sesión?
Escenario 2: encontrar soluciones
La tarea dice: el producto debe tener la funcionalidad para obtener una vista previa de archivos PDF, PNG, JPG y otros formatos de imagen (en aras de la simplicidad, délo por sentado).
Alguien de su equipo empoderado, en lugar de señalar posibles problemas, puede decir:
- “Hay muchos formatos de archivo que tendremos dificultades para admitir: archivos PDF bloqueados con contraseña, formatos de archivo de imagen específicos del sistema, etc.” — este es nuestro problema a resolver
- “¿Qué pasa si construimos la función Lambda de AWS, que genera una vista previa en JPG para cada formato admitido? Y luego, una aplicación móvil solo presenta un archivo JPG. Luego, cada vez que aparezca un nuevo formato de archivo, haremos mejoras en el backend, por lo que unos días después, los clientes lo verán funcionando en sus dispositivos móviles sin actualizar la aplicación”. — esta es la solución propuesta.
Por supuesto, esta conversación no termina aquí. Puede haber algunas limitaciones (como la falta de habilidades dentro de un equipo o la falta de infraestructura), u otras ideas que vale la pena considerar. O tal vez necesite entregar PoC rápidamente solo para comenzar a validar una hipótesis.
Pero lo importante es esto: su equipo debe estar facultado para traer soluciones a la mesa en lugar de centrarse en posibles problemas y casos extremos. Ya lo he compartido en el artículo anterior . 👇
Sus equipos saben mejor cómo se puede resolver este problema. Sabes qué es lo último en tecnología. Asistes a conferencias tecnológicas. Juegas con API y proyectos de código abierto.
Tú y tu equipo saben qué es posible y qué no.
Mantengámonos en contacto
Espero que este artículo sea valioso para usted. Mi misión es ayudar a los líderes de ingeniería a hacer realidad grandes ideas.
Estaré agradecido por cualquier comentario que pueda mejorar la Gestión Práctica de Ingeniería. Avíseme si hay algún tema en particular que le interese leer. Si desea conversar sobre otras formas en que podemos cooperar, envíeme un correo electrónico a mirek@practicalengineering.management .
Puede encontrarme en Twitter , LinkedIn o registrarse para recibir notificaciones por correo electrónico para obtener más consejos prácticos sobre la gestión de ingeniería. 👇
