¿Cómo lidian los ingenieros de software con los requisitos que se arrastran los gerentes que desean solo una característica más nuevamente?

Hay algunas cosas buenas a continuación, pero como esto es algo que me apasiona y me han preguntado, responderé de todos modos … Trataré de ser breve, ya que se han escrito muchos libros sobre este tema.

En primer lugar, los requisitos cambiantes son parte integrante de la entrega de software útil. No puede evitarlos, por lo que debe administrarlos.

Para administrarlos, necesita un proceso en el que todas las partes (gerente, desarrolladores, clientes) acuerden. Estas son las reglas que todos ustedes juegan.

Los procesos más comunes son, muy aproximadamente.

• Modelo de cascada: Wikipedia, que actualmente está fuera de moda en la actualidad, es burocrático con mucho equipaje y no maneja el cambio lo suficientemente rápido para la mayoría de los clientes en el mundo actual en rápida evolución. Todavía se usa en lugares donde los requisitos se pueden arreglar de manera realista por adelantado o necesitan una gran cantidad de revisión. Sin embargo, incluso los gobiernos se están alejando en estos días.
• Scrum (desarrollo de software): Wikipedia o variantes del mismo para ampliarlo. Estos agregan requisitos en iteraciones fijas (digamos 2 semanas o 6 semanas) llamadas “sprints”. Los nuevos requisitos se agregan al comienzo de este período. Todos están de acuerdo en que si se agregan requisitos en el medio de un sprint, todas las estimaciones previas para ese sprint son nulas, y se debe volver a planificar, por lo que es un último recurso que desalienta el síndrome de “una cosa más”. Scrum es ideal para proyectos que consisten en entregar un solo producto o conjunto de productos.
• Kanban (desarrollo) – Wikipedia – que es, como Scrum, una metodología llamada “Ágil” diseñada para manejar el cambio rápido de manera práctica. Con Kanban, hay un límite de trabajo en progreso. Si comienzas demasiadas cosas, no puedes iniciar otra. Esto hace que el gerente / cliente piense cuidadosamente sobre cancelar una tarea para hacer otra. Cada elemento se estima por separado, por lo que cada “una característica más” se estima, se agrega a una cartera de pedidos y se prioriza (y si hay demasiado trabajo en progreso no se puede iniciar hasta que se termine otro elemento). Kanban es genial cuando surgen muchas cosas nuevas y urgentes, por lo que es difícil incluso planificar con 2 semanas de anticipación, como en un equipo de soporte o de corrección de errores de producción.

Si no tiene uno de estos en su lugar, y su “proceso” es la microgestión por parte de su “gerente” cada vez que algo entra en su cabeza o en la de los clientes, le aconsejaría

• Lea sobre estos procesos, explíquele al gerente que ustedes necesitan un proceso de este tipo para que funcione de manera efectiva, y tomen la iniciativa de reunir uno junto con sus colegas desarrolladores.
• O, si cree que su gerente no será receptivo, o si no ve esto como viable, mejore su CV y ​​vea qué otros trabajos hay en el mercado. Cualquier buen administrador de software debería estar en todas estas cosas.

Como ingeniero, puede ayudar diseñando su software para manejar el cambio y anticipándolo. Pregúntele a su cliente / BA / gerente / quien sea que obtenga sus requisitos de qué aspectos es probable que cambien en el futuro, e intente diseñar el software para que tenga el poder de ser flexible en estas áreas. Cuando calcule, brinde opciones para diferentes niveles de flexibilidad en diferentes áreas, generalmente más flexibilidad = mayor costo. Sea transparente y honesto sobre las compensaciones hechas en términos de flexibilidad y costo para su administración.

Uso de SOLID (diseño orientado a objetos): los principios de Wikipedia ayudan a garantizar que el código sea fácil de refactorizar ante el cambio. Pequeños componentes / clases, funciones individuales, interfaces, acoplamiento flexible, buenas pruebas, todo ayuda a facilitar la creación de flexibilidad y hacer que su base de código sea resistente a los cambios rápidos.

Cuando se le pregunta “¿Puede hacer tal y tal” y puede decir “es solo un cambio de configuración” o “sí, solo debería ser un par de horas más o menos” porque diseñó y escribió el código por adelantado, todos ganan .

Desde mi punto de vista, nunca experimento un alcance espeluznante, aunque no todos sienten lo mismo que yo.

Personalmente, no me gusta el término alcance del arrastramiento. Fomenta una relación poco saludable demasiado común entre negocios e ingeniería. Las empresas deben solicitar todas las funciones que deseen cuando lo deseen.

La ingeniería debe hacerles saber qué opciones tienen para obtener lo que desean lo antes posible.

Eso no significa marchas de la muerte. Significa comunicación y colaboración.

Para gestionar la comunicación y la colaboración, hay un millón de cosas diferentes que podemos hacer. De esto se tratan las metodologías de software y gestión de productos.

Prefiero metodologías que permitan a los ingenieros trabajar con la cabeza en cosas de valor tanto como sea posible sin interrupciones. Obviamente, esto es clave para mantener una alta velocidad. También aliento un modelo de producto reflexivo que fomente la comprensión de los requisitos y la visión. Esto debería garantizar que las empresas obtengan lo que desean, independientemente de lo que pidieron.

Desde una perspectiva de ingeniería, me gusta tener ventanas de tiempo pequeñas para entregar cosas. Generalmente de 1 a 2 semanas. Me gusta planificar porciones de trabajo más pequeñas en estas ventanas de tiempo y usar una herramienta para que cualquiera pueda ver el estado del trabajo. Esto permite a las empresas confiar en que entregaré aproximadamente la misma cantidad de trabajo cada vez.

El producto garantiza que las cosas que estoy haciendo tengan valor, por lo que las empresas nunca deberían sentir que la ingeniería es una caja negra.

Al planificar estos fragmentos de trabajo, es importante ser honesto sobre la capacidad y reflexivo sobre las estimaciones. La planificación de aproximadamente el 80% de la capacidad suele ser una buena idea para permitir flexibilidad.

El hecho de que las prioridades del modelo de producto cambien durante un período de tiempo no me causa ansiedad, ya que entregaré aproximadamente la misma cantidad de trabajo independientemente.

Desde una perspectiva de gestión de cartera, puede que no sea ideal ver cambios en las prioridades todo el tiempo. Eso generalmente representa una mala gestión del producto y las relaciones comerciales son menos que ideales.

Establecer estos patrones es importante para todos. Hay todo tipo de palancas para ajustar para aumentar la capacidad. La mayoría de ellos tienen poco que ver con agregar mano de obra. Aquí es donde contar con experiencia en liderazgo de ingeniería es importante.

• ¿Tenemos una buena cobertura del Código?
• ¿Están automatizadas todas las tuberías de entrega?
• ¿Cuán maduro es nuestro modelo de producto?
• ¿Cuán maduro es nuestro monitoreo?
• Código maduro de calidad?
• ¿Todo está en control de la fuente?
• ¿La colaboración en equipo está funcionando?

Agregar mano de obra antes de comprender lo anterior generalmente no ayuda mucho. La mayor parte de lo anterior debe estar dentro de un control de ingenieros capacitados para autogestionarse.

Este comportamiento puede ser una técnica de negación abusiva conocida como “trinquete” y es injusto porque aprovecha específicamente la tendencia natural de las personas a dar más de lo que reciben.

Irónicamente, el trinquete también es una práctica administrativa aceptada, de la cual no sé el nombre, que esencialmente se reduce a significar “pedir más, obtener más” de sus empleados.

Los nuevos gerentes, o los mal entrenados, a menudo usan en exceso esta técnica que está destinada para uso a corto plazo, y agotan a sus equipos al mismo tiempo que aumentan sus números de rendimiento. Cuanto mejor sea el equipo, más puede salirse con la suya un gerente nuevo o incompetente.

¿Pero por qué trinquete?

1. En realidad, eres crítico para el equipo de tu gerente, y tu gerente espera mucho de ti porque haces que parezca fácil y aún no has dicho “no más”.
2. Su gerente no conoce sus límites.
3. Su gerente está tratando de presionarlo para que sea mejor.
4. Su gerente está tratando de expulsarlo.

¿Como lidiar con?

No hay una respuesta única, pero mi sugerencia es simplemente programar un tiempo con su gerente, al mismo tiempo que tenga la amabilidad de conocer las agendas individuales y grupales en juego, y sabiamente de las personalidades involucradas.

Señale la reunión inicial para hablar sobre la función más nueva y mencione que, mientras ambos trabajaron juntos en una lista de funciones (para ese sprint o lo que sea), notaron que se agregó una solicitud de función adicional y estaban un poco sorprendido y confundido por este comportamiento, y pregunte si él / ella puede aclarar lo que acaba de pasar … luego simplemente escuche, mientras da afirmaciones positivas. (Como “oh, ¿en serio? :)” y “¿puedes hablar más sobre eso?” O “eso es realmente interesante”).

Si se le pregunta por qué lo menciona, sea ​​honesto y dígale a su gerente que usted y el equipo están en sus límites, si ese es el caso, y pregunte si las características se pueden reorganizar en el cronograma si la nueva característica es crítica , o empujado al siguiente sprint si no.

(Esto supone que su lugar de trabajo es un lugar bastante seguro donde puede compartir tales cosas, y su gerente no es psicótico).

El punto es no discutir con su gerente, sino ganárselos, reafirmando su confianza en el gerente y unirse como un equipo. Hacer esto eventualmente permitirá que su gerente también vea su perspectiva y, con suerte, reduzca la cantidad de veces que se agregan nuevas funciones al azar. Haga alguna variación sobre esto cada vez que piense que una nueva característica se está integrando innecesariamente, y también para eventos positivos, como elogiar rápidamente a otros compañeros de trabajo o agradecer al gerente por vigilar la espalda de los equipos, con el mismo nivel de camaradería abierta y entender que eres un equipo.

Esto puede no detener cada vez más solicitudes de funciones, pero al menos puede reducir el estrés y la frecuencia de las mismas y establecer expectativas más realistas al tiempo que se crea un clima de trabajo positivo.

El aumento de alcance y el aumento de requisitos son problemas endémicos en cualquier industria que proporciona bienes y servicios al gobierno. También es un problema para las pequeñas empresas en una gran cadena de suministro. La razón es que el cliente más grande (gobierno o compañía Fortune 500) a menudo pide más, ya sea requisitos, cantidad, fuentes de calidad, etc.

Los libros están escritos sobre cómo lidiar con los requisitos de arrastre. Mi respuesta es una respuesta básica que parece abordar e incluir la mayoría de las otras ideas.

En pocas palabras: gestión de requisitos y gestión de la configuración.

La gestión de requisitos generalmente puede caracterizarse como el proceso mediante el cual los requisitos se reciben, leen, comprenden, negocian e incluyen en una línea de base. Esto es importante: haga referencia a sus requisitos al comienzo del proceso. En ese momento, los requisitos se administran como se manejaría un dibujo de ingeniería, configuración de herramientas, calidad del producto y aceptación del producto por parte del cliente. Este es otro aspecto de la gestión eficaz de programas y proyectos.

La gestión de la configuración es tu mejor amigo en esta situación. Una vez que haya establecido los requisitos (contractuales, reglamentarios, de ingeniería, etc.), cualquier cambio requerirá una carta de contrato formal, una estimación del cambio en el trabajo y un acuerdo formal entre las partes.

Sí, esto implica gastos generales. Para un proyecto pequeño, la gestión de requisitos puede considerarse simplemente como una práctica de gestión de proyecto personal. Sin embargo, a medida que crece un proyecto, una o más personas pueden dedicarse a leer y analizar solicitudes adicionales de cambios. Y es entonces cuando presentaría un proceso formal de cambio de tabla, tal vez incluso invitando al cliente a sentarse, dependiendo de su relación con su cliente.

Depende del gerente y del ingeniero de software. Los cómics de Dilbert te dan una idea general. Pero hay un método básico: debe mostrarle al gerente la relación entre los cambios en los requisitos y los retrasos en el cronograma y los excesos de costos para que el gerente pueda tomar una decisión informada.

Aquí hay una historia real sobre esto. Una vez estuve involucrado en un importante proyecto de software para el Ejército de los EE. UU. El proyecto había existido durante mucho tiempo y en el que había actualizaciones frecuentes del producto de forma regular. Cada actualización desde que comenzó el proyecto había sido tardía y excedía el presupuesto. Todos lo atribuyeron a los retrasos en el software. Entonces, el general a cargo del proyecto convocó a una gran reunión e hizo que el gerente de software (una mujer inteligente que luego pasó a puestos de autoridad más altos) explicara por qué el proyecto siempre llegaba tarde y sobrepasaba el presupuesto. Ella le dijo que había una manera simple de solucionar este problema.

Esto es lo que ella le dijo: cada vez que alguien quiera hacer un cambio de requisitos, no lo apruebe hasta que tenga una declaración firmada de mí que explique las consecuencias de este cambio en el cronograma y el presupuesto. La aprobación del cambio de requisitos por su parte significa la aprobación del presupuesto y el cambio de horario.

El general aceptó el trato y las cosas funcionaron mucho mejor después de eso. Algunos requisitos se pospusieron para futuras actualizaciones para permitirles cumplir con el cronograma, otros se aprobaron con modificaciones adecuadas del cronograma y el presupuesto.

Esa es la forma correcta de manejar las cosas. Ese gerente demostró una de las habilidades que distingue a un verdadero ingeniero de software de un programador básico. Sabía lo suficiente sobre su proyecto como para poder informar con precisión los efectos de un cambio de requisitos en el cronograma y el presupuesto de su proyecto.

Hable sobre el impacto que tendrá en la línea de tiempo . ¿Quieren una versión posterior, o esta característica como está sin la complejidad adicional?

En última instancia, es su decisión, pero agregar más funciones agregará más tiempo, por lo que deben planificar en consecuencia . No es justo esperar que todos los ingenieros inviertan más horas porque quieren cumplir con más requisitos y aún quieren que se lance en una fecha específica. Eso es insostenible, conduce a un software mal diseñado y aumenta la rotación de empleados. Si quieren más y quieren una cadencia sostenible de desarrollo de software, les llevará más tiempo.

Por lo general, cuando consideran esto, acuerdan sacarlo tal cual y agregar las características adicionales en las próximas semanas. No siempre, sin embargo. A veces, la nueva funcionalidad es realmente necesaria. Cuando eso suceda, deberán acudir a los socios comerciales y hacerles saber que va a llegar tarde.

Recuerde esto: no le hace ningún favor a nadie al aceptar plazos poco realistas. Está perjudicando el negocio porque dependen de que las cosas se hagan en una fecha específica, pero no se harán antes de esa fecha. Está perjudicando a su equipo haciéndolos trabajar horas extra y tomar atajos, lo que lleva a malas prácticas de ingeniería y rotación de empleados.

Si es factible, entonces no debería ser un problema.

Si no, intenta razonar con ellos. Tenga una reunión y repase los posibles problemas que pueden surgir al tratar de agregar una nueva función, o la falta de tiempo para hacerlo, o el requisito de más tiempo para hacerlo. Si le dan más tiempo para agregarlo, entonces no debería ser un problema.

Si no es posible, explíquelas claramente. Aquí su comunicación y habilidades convincentes entran en juego. Si no tienes estas habilidades, trabaja en ellas. Las habilidades de ingeniería de software no son solo escribir código.

Si todavía insisten, deje en claro sin ser tímido que no será responsable de los problemas que surgirán debido a apresurar una nueva función y la falta de pruebas.

Añádalo en una nueva rama Git it SVN en este caso para que si tiene que volver a una versión que funcione, pueda hacerlo de inmediato.

“Podemos cambiar tres cosas: alcance, personal o escalas de tiempo. Si desea agregar esta función, perdemos una diferente para equilibrarla, agregamos más personas¹ o ampliamos la fecha de entrega. ¿Tiene alguna preferencia?”

La metodología ágil tiene esto en cuenta, gestionando continuamente estos tres factores, particularmente el alcance. No hace daño recordarle al gerente acerca de ellos de vez en cuando, para que comprendan que el deslizamiento afectará la entrega, pero al menos todos tienen una visibilidad constante y actualizada de los efectos. Con Waterfall, debes ser más firme sobre el arrastre de características.

En gran medida, se trata de administrar al gerente y de cuán razonables son. Si está ejecutando Waterfall, y el deslizamiento sigue ocurriendo, ¡ documente todo ! Cuando la entrega llegue tarde, necesitará ese registro para explicar a los Directores por qué la misión se siguió expandiendo sin tener en cuenta los tiempos de entrega, y qué esfuerzos hizo para tratar de controlarla: específicamente, cuántas veces dijo a quién rompería las entregas y por qué.

(¹ Antes de considerar el cambio de personal como algo válido a corto plazo, le recomiendo encarecidamente que lea el libro seminal de Fred Brooks El mes del hombre mítico . Luego, vuelva al gerente y explique por qué agregar más personas aumentará su entrega escalas de tiempo también.)

Una buena manera de lidiar con eso es utilizar un enfoque de desarrollo ágil:

• Haga una lista de todas las funciones requeridas en orden descendente de prioridad (Producto acumulado)
• Si aparecen nuevas solicitudes de funciones, insértelas en la cartera de productos en orden descendente de prioridad
• Utilice un enfoque de desarrollo incremental para desarrollar las funciones que van desde las funciones de alta prioridad a las funciones de baja prioridad.

Si usa ese enfoque y revisa el progreso al final de cada iteración, será más evidente cuando llegue al punto de retorno decreciente donde el valor incremental de cada característica a desarrollar comienza a no exceder el costo incremental de desarrollarlo.

El trabajo de un ingeniero de software es crear el software o hacer las modificaciones solicitadas por la administración.

Cuando se realiza una solicitud, su entrada debe ser el tiempo requerido para realizar el cambio. Es decisión de la gerencia determinar si los beneficios de la nueva característica superan los costos de ese cambio.

Ahora, si se trata de un cambio adicional y la fecha límite para realizar todos los cambios planificados no refleja el tiempo requerido para el trabajo adicional, entonces es su responsabilidad informar a la gerencia que el cambio adicional pone en peligro el cumplimiento de la fecha límite.

Los requisitos y el alcance son parte del juego, amigo mío. Creo que nunca he trabajado en un proyecto serio donde los requisitos no cambiaron. De hecho, el método de desarrollo ágil (que en realidad es una metodología muy antigua) resurgió hace aproximadamente una década específicamente para abordar esta realidad.

Si se está ejecutando ágilmente, está intercambiando historias de usuarios. Pero eso ya lo sabrías.

Entonces, supongamos que es una cascada, o simplemente está trabajando en contra de una fecha límite financiera como consultor que tiene una oferta fija con el representante de ventas comprometiéndose demasiado para hacer feliz al cliente. La forma en que maneja esto es parte de las habilidades blandas de ser un líder, lo que considero parte de lo que hace que un ingeniero de software sea diferente de un programador.

Mi metodología personal favorita es sentarme con el cliente y mover colectivamente partes de otros requisitos a la “Fase 2.” Ah, Fase 2. Ese lugar de esperanza mítico y mágico. Ese grupo ilimitado de fondos que seguramente se materializará porque su causa es justa.

Lo que realmente está haciendo es reducir otros requisitos. A menos que esté en esa situación en la que un presupuesto de fase 2 realmente se materializa.

Se mudan a otras compañías con gerentes competentes. Pero en las organizaciones que desarrollan software como actividad principal, los gerentes como este son raros. Uno los ve principalmente en compañías que tienen alguna otra actividad primaria, y en las cuales el desarrollo de software es incidental y para uso interno.

Hago lo que dicen mientras advierto sobre los riesgos del cronograma.

Los desarrolladores son abejas obreras, especialmente contratistas. No tenemos mucho que decir sobre cómo se ejecuta el proyecto.

Siempre que agregar una función más no requiera noches de trabajo y fines de semana de manera regular, trato de hacer felices a mis dueños.

Uso la frase mágica “No sé cómo hacerlo (dentro del tiempo disponible)”. Por supuesto, esto supone que el gerente está tratando de obtener más funciones al mismo tiempo o por el mismo dinero. Si el gerente ofrece más tiempo o dinero a cambio de una función más, entonces no es un “arrastramiento”.

Solo lo agrego a la cartera como una nueva historia. Será priorizado en su debido momento.

Con desarrollo ágil. Tiene tickets predefinidos con criterios de aceptación establecidos que no se modifican.

Es inevitable. Simplemente diga cuánto más tardarán los nuevos requisitos. Si codifica de manera inteligente, no requiere mucho esfuerzo agregar nuevas funciones, solo tiempo y más paga 🙂

No hay una buena manera, solo diferentes.

Intento ser honesto al respecto.

“Si desea que agregue , esto afectará la fecha límite en ”