La implementación de un calendario de lanzamiento

Question

La empresa donde trabajo está tratando de poner en práctica un programa de lanzamiento y quiero conseguir un poco de retroalimentación constructiva de las personas que trabajan en ambientes mejor estructurado que la que estoy.

Tenemos un producto que es terminado y utilizado por varios clientes, pero tenemos 4 productos adicionales en proceso, y se comercializan activamente como si estuvieran terminados. (¡Imagínese eso!)

Somos una empresa muy pequeña que trabaja muy rápidamente (y sí, a veces descuidada) y con plazos ajustados y presupuestos ajustados, por lo que no tenemos el lujo de requisitos escritos, proceso sistemático de control de calidad, etc. Básicamente, los propietarios de la empresa acuden a los desarrolladores (3 de nosotros) con ideas y las implementamos. Luego, los expertos en la materia prueban las características para asegurarse de que la aplicación haga lo que se supone que debe hacer.

Sé que el último párrafo me abre a todo tipo de comentarios sobre "no se puede hacer de esta manera", pero no los necesito. Entiendo lo equivocado que es este enfoque. En un momento pude convencer a los propietarios para contratar a un gerente de proyecto y una persona de control de calidad, pero después de un corto tiempo ambos fueron despedidos debido a la pérdida de ingresos. Estamos donde estamos y no hay cambios en la cultura en este punto.

Lo que trato de hacer es gestionar las expectativas. Tenemos una lista de características solicitadas de una milla de largo y esto es lo que he propuesto.

Haremos lanzamientos trimestrales a la producción de nuestros productos terminados. El primer lanzamiento será en octubre. En lugar de tratar de gestionar lo que se hará de ahora en adelante según las prioridades Alta/Media/Baja, administraremos las funciones en función de lo que se puede y no se puede finalizar de aquí a septiembre. En ese momento, detendremos todo el desarrollo de funciones y nos centraremos en probar y corregir defectos para que el producto esté listo para su lanzamiento el mes siguiente. Repetiremos este proceso cada trimestre. Básicamente, los pasos serán los siguientes:

1) Coloque todas las funciones pendientes en una versión futura en función de su importancia. 2) Trabajar en estas características durante el trimestre. 3) A medida que se solicitan nuevas funciones, colóquelas en una "cola" para un ciclo de lanzamiento en particular. 4) Si la característica tiene que ir a la versión actual, luego mueva otras características a la próxima versión. 5) En ciertos puntos del ciclo, evalúe qué características pueden no entrar en la versión actual y ajústelas según corresponda. 6) Finalice el desarrollo de funciones al menos 30 días antes del envío programado a producción y concéntrese en las pruebas y la corrección de errores. 7) Empujar algo a la producción en la fecha programada y luego tomar el control por no haber terminado todo lo que acordamos al principio (hey, estoy siendo realista ... las personas para las que trabajo no lo son)

Ah, también, si planeas decirme "conseguir un nuevo trabajo", no te molestes en responder. Esa no es una opción en este momento.

Si tiene algún consejo con respecto a este enfoque propuesto, o cualquier enlace a recursos que puedan ayudarme a entender mejor cómo estructurar este proceso, lo agradecería enormemente.

Gracias de antemano por su ayuda.

Darvis

Answer 1

En pocas palabras, dada la falta de un proceso definido, no hay muchas posibilidades de implementar con éxito un calendario de lanzamiento sólido. Esto no es solo pesimismo, aunque lo admitiré fácilmente.

Al igual que el éxito se basa principalmente en el trabajo duro y un poco de suerte, los cronogramas de liberación sólidos y repetibles se basan en el proceso; tener cosas como especificaciones funcionales y especificaciones de diseño es realmente crítico para poder publicar en un horario consistente y sólido. (Usted sabe que hay una razón por la cual las personas tienen tales especificaciones, ¿no?) Y eso no quiere decir que no pueda alcanzar su agenda y liberar expectativas sin tales cosas; muy posiblemente puedas. Pero lo que tiene dicho proceso en su lugar aumenta masivamente sus posibilidades de ser capaz de cumplir con las expectativas, al menos parcialmente, porque asegura que las expectativas no se desvíen hacia un territorio "irrazonable" mientras usted todavía está implementando.

Nuevamente, esto no significa que no pueda lograr lo que necesita para hacer lo que describió anteriormente; para ser sincero, si se encuentra en un entorno que es activamente hostil a tener tal proceso como se describe en su lugar, probablemente esté trabajando de la mejor manera para lograr lo que necesita. Y no quiero ser completamente pesimista; parece que tienes una buena idea de cómo intentar hacer esto; para lo que tienes que trabajar, parece que tienes un proceso razonable en su lugar. Pero puedo garantizar virtualmente que terminarás siendo mejor si solo puedes obtener dos cosas; 1) una especificación funcional de la administración que describe lo que quieren que haga el software, y 2) una especificación de diseño desde la ingeniería que describe hasta la administración cómo hará que el software haga lo que quiera en la especificación funcional.Pensaría que podrías incluso encajar esto en tu proceso; las especificaciones funcionales no necesitan ser complicadas; la clave de ellos es que son anotados, lo que evita disputas acerca de lo que la gerencia pidió; está justo ahí. Y las especificaciones de diseño tampoco requieren mucho tiempo; un rápido buscapersonas para que la gerencia sepa cómo (en un nivel alto) va a implementar lo que necesita, les brinda la seguridad de que los ha escuchado y puede ayudarlos a comprender la complejidad involucrada (pero no avance) demasiado profundo, de lo contrario corre el riesgo de aburrirlos y perder su atención).

Answer 2

Libere antes y con frecuencia.

A menudo encuentro que los usuarios no saben lo que quieren hasta que los mostramos. En nuestras instalaciones, tenemos un sistema QA/prueba liviano. Deje que los usuarios prueben cosas nuevas. A medida que los usuarios aprueban las ideas, las movemos hacia la producción.Esto nos permite estar siempre trabajando en cosas nuevas, probando interfaces, agregando tablas y columnas de bases de datos, sin romper el código de producción.

El único "truco" consiste en recordar constantemente al cliente que la plataforma de prueba no es la plataforma de producción.

Answer 3

Dada la falta de gestión de proyecto, organización, etc. Creo que se encontrará con problemas al tratar de introducirse en un ciclo trimestral (o en cualquier fecha fija). Esto será especialmente cierto si tiene características "grandes" que tardarán más de 2 meses en desarrollarse, lo que permite el tiempo de desarrollo.

Mi sugerencia sería hacer un ciclo de publicación basado en características. Simplemente haga su cola de funciones, decida cuáles cree que puede hacer razonablemente en un marco de tiempo específico. Implementa esas características, concédete un mes (o lo que sea) para probar, luego suelta. Pase al siguiente grupo de funciones. Si lleva 2 meses en lugar de 3, genial. Si lleva 4, está bien también.

Dicho esto, me centraría en tratar de hacer esto más corto, no más. Tener más lanzamientos más pequeños realmente lo ayudará en este caso, especialmente porque no cuenta con los procedimientos formales (y personal) para manejar el control de calidad, etc. Mantenerse flexible le ayudará a solucionar los problemas que se presentarán en sus lanzamientos ...

Answer 4

¿Qué está utilizando para controlar la fuente?

Utilizamos SVN y tenemos la flexibilidad para, si es necesario, crear una variedad de ramas diferentes según lo que se implementará a partir de la próxima versión. Si las versiones a1, a2 y a3 están configuradas para ser liberadas, podemos fusionar estos cambios en una rama fuera de producción. Si a2 se vuelve menos prioritario, podemos revertir solo los cambios de a2 o, si hay superposición, simplemente crear una nueva rama y fusionar solo a1 y a3, dejando a2 para alguna versión posterior.

¿Cuán probable es que los propietarios reescriban una especificación antes de una versión determinada? Donde trabajo esto sucede con frecuencia, lo que hace que la capacidad de cambiar de marcha y deshacer/volver a fusionar sea muy útil.

Answer 5

Mi empresa también se empantana con solicitudes de funciones.

Lo que hicimos fue pasar por todas las características y dar una estimación de la cantidad de tiempo que tomarán para implementar. Luego, dejamos en manos de nuestro "comité de cambio" (nuestro CEO, líderes de equipo, etc.) darnos las características que completaremos durante el próximo sprint.

De esta manera, no nos están dando cargas de trabajo irracionalmente grandes, y el usuario final tiene algo que decir sobre lo que se completa.