Algunos de mis amigos y yo solíamos bromear sobre las analogías entre las dos disciplinas, así que lo llevé más allá y se me ocurrieron estos términos y conceptos:
Gerencia de Ingeniería de Software
- Deuda técnica: una acumulación de errores y características previamente reparadas.
- Quiebra de errores : después de que se acumula una cantidad insuperable de errores, el equipo ejecuta un script para cerrar automáticamente todos los errores antiguos de baja prioridad.
- Rescate de la deuda tecnológica: hay una gran acumulación de errores que aplasta el alma, la quiebra de errores no es una opción porque los errores son demasiado importantes, ¡pero no temas! Una fuerza más élite u organizacionalmente poderosa ha decidido reescribir el producto o simplemente cancelarlo por completo (y los ingenieros actuales son reasignados).
- Obligación de deuda tecnológica garantizada ( CDO ): es donde toma sus errores y los empaqueta con algunas características atractivas relacionadas. Luego toma ese CDO de deuda tecnológica y se lo entrega a otro equipo para que lo arregle e implemente. Están contentos porque obtienen nuevas funciones, usted está contento porque redujo la deuda tecnológica de su equipo.
- Tech-Debt / Equity Swap: tienes un gran conjunto de errores, también tienes algunos ingenieros que muestran signos de deslealtad (probablemente sean millennials aburridos). Te acercas a otro equipo y les dices: “Te daré algunos ingenieros si también quitas estos errores de mi equipo”. El gerente receptor luego distribuye los errores entre su equipo, y los ingenieros entrantes obtienen algo nuevo para trabajar.
- Impuestos de características atractivas: decirle a un ingeniero, “seguro, puedes trabajar en esta característica genial en la que todos y su madre quieren trabajar, pero también debes corregir estos errores desagradables”.
- Deflación de la deuda tecnológica: además de las quiebras de errores y los rescates, que son extremos, también tenemos otras herramientas: Bootcamp, pasantes, nuevos empleados y posibles candidatos de transferencia interna pueden ser vehículos para la deflación de la deuda tecnológica, ya que están más dispuestos tomar abuso debido a sus vulnerabilidades situacionales. Esto es complicado porque también estás tratando de atraer a dichos ingenieros para que se unan a tu equipo.
- Reducción cuantitativa de errores: Esto es similar a jugar con las tasas de interés: cree fricciones innecesarias en la herramienta de registro de errores a través de reglas y condiciones de validación adicionales. Por ejemplo, deben incluir pasos de repro, registros de fallos y un video de demostración de errores para poder enviar el error. Esto disminuirá artificialmente la velocidad a la que entran los errores, y lo ideal es filtrar los errores más graves que ingresan al sistema. Por supuesto, también filtrará algunos “errores buenos” que causan la degradación del producto, pero eso está bien porque se ve bien en el papel.
Navegando una carrera de ingeniería de software en una gran empresa tecnológica
- ¿Cuál es la validación empírica de la opinión de que scrum funciona mejor que la gestión de proyectos tradicional para el desarrollo de software?
- ¿Cuál es la pila tecnológica de SurveyMonkey?
- ¿Es posible con una gran cantidad de trabajo hacer un programa de traducción perfecto?
- Tengo 25 años, una mujer trabaja en una empresa de software. Ya no deseo continuar en este campo. ¿Cómo paso mi tiempo de calidad en casa una vez que renuncio?
- ¿Cómo es trabajar en un equipo técnico que abarca varios países?
Estas son algunas herramientas que se pueden usar para evaluar si es una buena idea invertir su tiempo en una empresa, equipo y producto en particular.
- Índice de deuda tecnológica a capital: si el capital es una medida de trabajo atractivo en este escenario, cuanto menor sea esta relación, mejor. Es una métrica interesante a tener en cuenta al cambiar de equipo. Los bancos usan esta proporción cuando deciden financiar una empresa, y de manera similar el tiempo de un ingeniero es su inversión.
- Relación impacto por empleado (I / E): similar a P / E, I / E mide el impacto promedio por empleado en un equipo en particular. La fórmula para el impacto es similar al impulso en física. Momentum = masa * velocidad e Impacto = número de usuarios * (aproximadamente) el número de kLOC que apagas.
- Relación Impacto por empleado sobre crecimiento (IEG): similar a PEG (P / E sobre tasa de crecimiento), existe IEG, que es cuando se tiene en cuenta la tasa de crecimiento de ese equipo y producto. Un IEG alto es como volar a través de una corriente en chorro o “subirse a un tren en movimiento”.
- Dividendos de productos: cuando estás en un equipo en particular que está creando algo nuevo y brillante, es similar a un “stock de crecimiento”, donde tu lado positivo se basa en gran medida en el crecimiento. Por el contrario, si está en un producto maduro de “vaca de efectivo” (como Hooli Search Ads, etc.), obtiene pequeños beneficios adicionales: más sitios lujosos, bonificaciones más grandes, más promociones, más seguridad laboral en una recesión, etc. , los reclutadores y la gerencia te jurarán que los dividendos de productos no existen, pero seamos honestos aquí …
Gestion de producto
- Stagflation del producto: no hay ajuste del mercado de productos, muy poco crecimiento de los usuarios, pero los ingenieros siguen trabajando en nuevas características e infraestructura “emocionantes”, que finalmente no tienen un impacto significativo. Sin impacto significa estancamiento en los niveles de carrera y el personal asignado del equipo.
- Portafolio de inversiones de productos: para un PM, cada característica es una inversión y el objetivo es lograr el máximo impacto. Similar a la “Caja de estilo” de Morningstar, una característica también se puede poner en una matriz, donde el eje x es el potencial de riesgo / recompensa, y el eje y es el recurso de ingeniería requerido para completar esa característica. Los recursos de ingeniería se cuantifican en función de la antigüedad de esos ingenieros y la cantidad de tiempo que llevará terminar. Una característica de bajo riesgo / baja inversión podría ser cambiar el título o el color de un elemento de menú en un experimento. Por otro lado, una característica de alto riesgo / alta inversión podría estar implementando algún tipo de característica de sugerencia de invitación, impulsada por una infraestructura de ML profunda, junto con todas las inversiones de canalización de datos que la acompañan. Puede dar grandes frutos, pero también podría ser un desperdicio colosal de recursos de ingeniería.