Veré un resumen del proceso de desarrollo de productos que solía usar cuando estaba a cargo de los proyectos existentes . (Las cosas salen mucho por la puerta, y yo uso un proceso un poco diferente, para productos de software completamente nuevos ).
Invariablemente, el propietario del producto (lo llamaremos el CPO o Director de Producto) está atrapado en el medio entre los desarrolladores de software (a los que intenta apurar pero también a quién intenta proteger), los equipos de ventas que tienen sobreventa, equipos de operaciones que claman por más eficiencia o corrección de errores, y CEOs que están visualizando la próxima gran cosa.
Debido a todo esto, a veces hay una tendencia a que se desarrollen listas . Largas listas. De características a desarrollar y “errores” a corregir. De Verdad. Largo. Liza.
- Quiero hacer una nueva compañía en línea. Soy un programador de sofware; Quiero hacer una empresa y vender software y aplicaciones. ¿Cual es tu consejo?
- ¿Cuáles son algunos consejos para un probador manual con poco interés en la codificación que ha estado atrapado en este trabajo durante los últimos 3 años?
- ¿Qué tan difícil es cambiar a gigantes de software como Amazon o Microsoft después de 2-3 años de experiencia en una empresa de redes como Arista Networks?
- ¿Cuáles son algunos patrones de diseño de software que aún no están en el vocabulario común?
- Quiero dejar mi trabajo (en el que lo único que obtengo es el salario) por 2 a 3 meses de estudio a tiempo completo para actualizar mis habilidades de ingeniería de software. Actualizar mi conjunto de habilidades me ayudará a asegurar un mejor trabajo que me apasione. ¿Realmente vale la pena?
Mi principio central: negarse a albergar listas.
Para mí, el proceso para un lanzamiento comienza con la Reunión de Visión de Lanzamiento. . .
Reunión de visión de lanzamiento. A la mitad de un ciclo de desarrollo (quizás dos semanas en un lanzamiento de un mes), programe una “Reunión de Visión de Lanzamiento” para el próximo lanzamiento (que no comenzará a desarrollarse durante varias semanas).
Pizarra blanca: La gran lista. Comience con una pizarra en blanco y las 4-5 personas a las que ha empoderado para darle instrucciones sobre cómo planificar el producto. Vaya por la sala y haga que la gente empiece a gritar cosas que les gustaría ver en el próximo lanzamiento (o bien, pronto). Por lo general, en empresas pequeñas o medianas, ninguna de estas ideas será realmente “nueva”. . . en cambio, las personas los han socializado informalmente entre otras personas durante las últimas semanas o meses, por lo que bastará una referencia rápida a ellos por su nombre. Escriba esto en la pizarra.
Recordatorio: no hay listas antiguas. Alguien le preguntará: “¿De qué temas hablamos el mes pasado?” Esto es cuando usted dice: “Si es importante, lo recordará y aparecerá ahora. Si no es importante ahora, no lo vamos a construir ahora, porque solo podemos construir lo que debe ser construido ahora “. Lo que era “importante” hace un mes o dos a menudo no es tan importante ahora. Los equipos de productos desperdician montañas de energía manteniéndose al día con listas de mierda que ya no es importante. (Quizás un nuevo acrónimo: “STIIA” pronunciado como una dama británica haría su orgulloso caballo … “steeah”)
Pizarra blanca: la lista corta. . . Todos tienen voz . Al dar la vuelta en un círculo, cada persona tiene UNA opción para algo en la Gran lista que desea mover a la Lista corta. Marque un punto por cada elemento. No se necesitan múltiples votos, se desperdician. Cada persona elige un artículo diferente. Luego, en orden inverso al anterior, cada persona ahora obtiene una SEGUNDA opción única de The Big List.
El borrado estresante (o de alivio del estrés). Una vez que cada persona ha tenido dos selecciones, ahora borra cada elemento que no ha sido marcado. Alguien (tal vez el CEO) protestará (en cada reunión), “¡¿Pero quién va a salvar esas cosas?!?!” Aproveche este momento para recordarles a todos que no alberga listas, porque desperdicia mucho tiempo. Es solo STIIA (el caballo se vuelve loco ). Recuerde con cuidado a todos que si desean guardar la lista, pueden tomarle una foto antes de que la borre, y si desean volver a mostrar esos elementos en la próxima Reunión de lanzamiento de la visión. Pero es su responsabilidad, no la tuya. Estás lo suficientemente ocupado y ya estás demasiado en el centro de mucha presión de diferentes personas para mantenerte al día con STIIA. (En la práctica, nadie vuelve a la lista anterior de una reunión anterior, porque, independientemente de la emoción, pragmáticamente todos se dan cuenta de que todo es STIAA. Ocasionalmente, el CEO le pedirá que lo revise desde el teléfono de alguien, pero las cosas que fallaron hacer la última versión de The Short List tiende a fallar nuevamente si nadie la ha sacado de la memoria a la Big List).
Pizarra blanca: Ven a Jesús Momento. Con la lista corta restante, marque cada elemento (ya sea una pequeña mejora, característica principal o de otro modo) con una estrella para indicar el nivel de esfuerzo que estima que tomarán. No es necesario consultar con los desarrolladores de software. . . solo usa tus mejores conjeturas. Aquí está mi conjunto de anotaciones:
- Sin estrellas = Menos de un día de trabajo, incluido el control de calidad
- 1 estrella = 1-2 días de trabajo
- 1 estrella con un círculo = más de 3 días de trabajo
- 1 estrella con 2 círculos = Proyecto de eyección de masa coronal supermasivo. Épica de épicas que consumirán todo el lanzamiento.
De ellos, generalmente aceptaré de inmediato cualquier cosa sin estrellas, asignándoles P1 o P2 (ver más abajo). Luego, utilizando mi criterio sobre lo que posiblemente encajará, aconsejaré a la gente cuántos de los diferentes tipos de elementos podrían encajar, y todos priorizaremos en colaboración lo que queda:
- P0: error absurdamente urgente. Estos normalmente no aparecen en las reuniones de lanzamiento de visión, porque ya se está trabajando, porque el negocio está en riesgo inminente de colapso debido a eso.
- P1: Definitivamente entrará en esta versión. Trabaja primero.
- P2: salvo que la priorización inusual cambie a mediados del ciclo de lanzamiento, probablemente lo logre.
- P3: Puede o no entrar. Lo siento.
- P4-P5: no lo logrará. (Sí, a veces un P4 puede ascender en las filas, pero simplemente no va a suceder, así que no le dé a la gente falsas esperanzas).
Por lo general, solo uno o dos elementos lo convertirán en P1, algunos como P2, algunos como P3 y la mitad o más quedarán atrapados en P4-P5. . . así que no sucede este lanzamiento. A veces simplemente borro descaradamente los elementos P4 / P5, dependiendo de la poca atención recibida y del esfuerzo que requerirán los elementos restantes. Borro las protestas del grupo.
Un recordatorio más: no hay listas en curso. Al final de la reunión, tomaré una foto de la pizarra y agregaré tickets al sistema de seguimiento del proyecto a partir de los elementos que quedan en la Lista corta y asignaré los códigos de prioridad en consecuencia. En ningún momento un no-P0 (error de crisis urgente) entrará en el sistema de seguimiento del proyecto a menos que haya pasado todo el proceso de la Reunión de Visión de Lanzamiento. De esa manera, evito albergar listas.
Estimaciones formales y requisitos. Una vez que agregue los tickets para los artículos de The Short List con algunos requisitos iniciales basados en párrafos y prioridades provisionales, conseguiré que los líderes del equipo de desarrollo de software (CTO, Arquitecto de software, etc.) proporcionen sus estimaciones más reales. Ajustaré las prioridades en consecuencia, en consulta con el CEO y otros, si las estimaciones vuelven a desaparecer de mis puñaladas iniciales, lo cual es algo raro. Luego, los requisitos detallados, las maquetas de diseño, etc., vienen a continuación, asegurándose de que el equipo de software los tenga a tiempo.
Desarrollo de software + QA. Durante y durante el desarrollo de los elementos en el orden en que los prioricé, el equipo de software realiza algunas rondas de pruebas de Garantía de calidad, donde los desarrolladores comprueban el trabajo de otros desarrolladores contra los requisitos del ticket. Luego, el PM del lado del software realiza una “verificación de cordura” del artículo. Finalmente, el dinero se detiene conmigo cuando hago una verificación final de control de calidad del artículo y lo marco como completado.
Lanzamiento. Si todo ha ido bien, eventualmente daré la palabra a los desarrolladores para que realicen un lanzamiento de Producción.
* * *
Mezclado con todo esto, por supuesto, surgen incendios, y el CEO podría exigir alguna nueva característica. Si eso sucede, lo obligaré a decirme qué otra característica o conjunto de características (que se sumaría a una cantidad similar de trabajo) de proyectos aún no comenzados que le gustaría posponer hasta un lanzamiento posterior a cambio de El nuevo proyecto. A los CEO (y a otros en la compañía) les gusta pensar que si “presionan” lo suficiente, puede fabricar 30 horas a partir de un día de 24 horas, pero sabemos que eso no es posible. Si se necesita agregar algo, se debe descartar algo más (o de lo contrario, se deberá retrasar la fecha de lanzamiento), y depende de usted ser firme al respecto y asegurarse de que nadie se sorprenda.