¿Cómo gestiona las solicitudes de funciones y los cambios de software? [cerrado]

Soy ingeniero de software y en los últimos años me he convertido en el gerente de proyectos de software de facto simplemente porque no hay ninguno. Entonces, para mantener nuestra cordura en el departamento de I + D / Ingeniería, los clientes se han acostumbrado a acudir a mí con sus solicitudes. No tengo experiencia en este ámbito, por lo que es la primera vez que actúo como gerente de proyectos de software. He manejado otras cosas pero no el software.

Entonces, ¿cómo gestiona proyectos de software y marca prioridades? Las solicitudes llegan a intervalos poco frecuentes, por lo que muy bien podríamos estar trabajando en algo para otra persona y luego otra persona entra con un trabajo "apresurado" que necesita trabajar. ¿Es más fácil decir Primero en llegar, primer servicio o es la persona con más dinero?

Descubrí que cuanto más se queja un cliente de cuán urgente es su solicitud, a menos que también sea un desarrollador por derecho propio, generalmente es una buena señal de que la solicitud no es urgente en absoluto. Uno de mis profesores en la universidad siempre nos decía que no dejáramos que lo urgente interrumpiera lo importante.

Normalmente clasifico las solicitudes en este orden (YMMV):

1. Problemas relacionados con una actualización o migración reciente (lo más importante).
2. Correcciones de seguridad.
3. Funcionalidad rota del sistema existente.
4. Funcionalidad rota en RC y características beta.
5. Solicitudes de funciones pagas.
6. Solicitudes de funciones de I + D de una gran parte de la base de usuarios.
7. Solicitudes de funciones de I + D de solo uno o dos usuarios.

Este último en realidad toma mucho más tiempo porque tienden a ser las solicitudes de "urgencia, lo necesito ayer". En realidad, el usuario rara vez ha pensado completamente en lo que realmente necesita o cómo respaldará su modelo de negocio. Muy a menudo, estas solicitudes urgentes, una vez entregadas, terminan siendo utilizadas una o dos veces y olvidadas. Y una vez olvidados, se convierten en un dolor de cabeza sin fin de agujeros de seguridad y consecuencias no deseadas.

Me gustan los principios:

1. QI: importante y urgente
2. QII - Importante pero no urgente
3. QIII - No es importante pero es urgente
4. QIV - No es importante ni urgente

1. Configure un sistema de seguimiento de características / errores / solicitudes y haga que sus clientes / compañeros de trabajo presenten las entradas. Si no lo presentan, no lo estás haciendo. Los tickets deben ser lo suficientemente detallados para ser accionables y deben especificar una "urgencia" ("Lo necesito ahora" frente a "bueno tener").
2. Ir a través de nuevos boletos y examinarlos cuidadosamente . Ingrese el costo en el boleto en dólares, desarrolladores, recursos y / o tiempo. Esto es esencial . Cuando sus clientes vean lo que realmente les costará, verán opciones muy diferentes en el campo "urgencia".
3. Diariamente, calcule su horario en función de los boletos archivados y su urgencia. Haga que el horario sea visible para otros para que sea obvio lo que está haciendo y su disponibilidad para futuras solicitudes.

He visto proyectos en los que los cambios de requisitos se gestionan mediante un sistema de control de cambios muy pesado. Esto es malo. Muchos cambios importantes no ocurren porque el cliente no quiere pasar por la molestia de presentar un control de cambio, por lo que el software no satisface sus necesidades. Algunos pequeños cambios se deslizan "por debajo del radar" para evitar el proceso, por lo que el software ni siquiera coincide con lo que crees que hace.

Por el contrario, también he visto proyectos en los que el gerente de proyecto piensa que "reactivo" significa hacer que los codificadores respondan a cada solicitud de los usuarios, lo que significa que nunca se realiza ningún desarrollo central y su código se convierte en un gran lío de pirateo. cortar. Esencialmente, ahora no tiene ningún desarrollador, tiene un equipo de ingenieros de ventas sobrecalificados.

Por lo tanto, uno podría esperar que haya una situación entre estos dos polos que funcione bien, y espero que lo que funcione mejor para usted sea tanto una elección personal como una ubicación. Definitivamente hay valor en capturar el costo de cada cambio. En un marco como Scrum, puede expresar el costo en puntos de historia, y el equipo puede intercambiar el trabajo que realizan en cada iteración versus el esfuerzo total disponible. Si tiene un gerente de producto, puede hacer que esa persona cuantifique el beneficio esperado de un cambio o solicitud de función. Esto generalmente se hace en términos de ingresos protegidos (cuántos clientes se irían si usted no hiciera esto) y los ingresos atraídos (cuántos clientes llegarán si lo hace). Eso puede ayudar con la priorización, pero también puede reflejar el sesgo o la preferencia personal del gerente de producto.

Aquí algunos pensamientos ...

Hay un montón de software en el mercado que le ayuda, http://www.fogcreek.com/ con Fogbugz, GeneXus USA con XPM http://www.genexususa.com/xpm , etc.

Es como un arte equilibrar las nuevas solicitudes de funciones con correcciones de errores y con sus propias ideas. Tienes que conseguir comida para el próximo invierno, pero también tienes que comer hoy.

Tiene tiempo, recursos y alcance, aproveche al máximo.

Henry Ford también dijo una vez: "Si hubiera escuchado a los clientes, les habría dado un caballo más rápido" ...

Personalmente: sé dinámico, no pongas reglas como las que dijiste ... y ten cuidado con las reglas de otras personas ... pueden funcionar bien en su contexto, pero no en el tuyo.

Lo que terminamos con fue que ahora tendríamos reuniones bimensuales de ventas / ingeniería para discutir proyectos actuales y solicitudes de características futuras o futuras. Los ingenieros de ventas se convertirán en gerentes de proyecto y al menos estarán en sintonía con las últimas ofertas de productos. En el pasado, era fácil pasarlo a Ingeniería y olvidarlo. Esto probablemente disminuirá la carga que tiene que hacer un ingeniero de software y le dará la responsabilidad a las ventas y la administración para usar nuestro tiempo sabiamente.

La compañía para la que trabajo utiliza dos aplicaciones principales, una herramienta basada en la web llamada JIRA para manejar los aspectos relacionados con el proyecto y nuestro sistema de mesa de ayuda para manejar la solicitud de cambio a través de su funcionalidad rfc

Las respuestas que veo hasta ahora son buenas. Una cosa que explicaré específicamente es que tendrá que ser bueno al decir "No" a algunas solicitudes.

Si permite que el cliente establezca la urgencia, casi siempre será "Alta" (o mayor).

Usted (usted mismo o un equipo, según su configuración) deberá evaluar estas solicitudes y priorizarlas según sus propios criterios.