Reduzca la cantidad de revisiones requeridas sin conocimientos técnicos

Soy un desarrollador de software que sufre de las revisiones periódicas que se requieren para una aplicación que he desarrollado.

La aplicación que desarrollé no tenía muchos requisitos de infraestructura desde el principio, pero con el tiempo esos requisitos se hicieron cada vez más. Esta es solo una parte del problema porque cuando llega un nuevo requisito, se espera que haga una revisión fuera de otro trabajo planificado. Porque los gerentes de proyecto ya prometieron una aplicación funcional.

Quiero reducir la cantidad de revisiones que debo hacer, ya que esto me permitiría concentrarme en la tarea en la que estoy trabajando actualmente y los gerentes de proyecto no tendrán que disculparse cuando el producto no funcione desde el principio.

La mayoría de esos requisitos de infraestructura tienen que ver con la autenticación y la autorización (directorio activo, compatibilidad con dominios cruzados, suplantación de identidad, etc.).

Creo que ni el propietario del producto ni los gerentes de proyecto ni yo sabemos lo suficiente sobre los detalles técnicos para construir un catálogo de requisitos desde el principio.

El producto se desarrolla con Scrum como ideología de gestión de proyectos. (También soy parte de otros Equipos Scrum).

¿Cómo puede una pequeña empresa sin este conocimiento evitar tales revisiones?

Sé que no prometer una solución funcional y reservar tiempo para pruebas y correcciones resolvería esto. Pero, ¿hay alguna otra forma de evitar esto? ¿O debería tratar de hablar con los gerentes de proyecto y tratar de cambiar su forma de actuar?

Para mí, esto suena menos como revisiones (= corregir errores) y más como apresurarte a agregar funciones prometidas. ¿Eso encaja con tus impresiones?
@Kempeth ¡Sí! Eso suena como la situación. Y tal vez sea la prisa lo que impide que se realice un buen análisis técnico/prueba de integración... Pero tampoco sé si seríamos capaces de resolver este problema con el tiempo suficiente dado que nuestro conocimiento técnico es quizás demasiado pequeño.

Respuestas (2)

Si te he entendido correctamente, tu objetivo es tener una experiencia de desarrollo más estable. Menos "dejar todo y poner X a trabajar".

Tu problema se debe a varios factores:

  • A los clientes se les promete que su producto puede hacer algo que no puede
  • Usted (personalmente y la empresa) no sabe lo suficientemente bien qué requisitos se esperan
  • Usted, el personal de ventas o los gerentes, no están dispuestos a esperar por estas funciones.
  • No está protegido de estas deficiencias en un grado suficiente

¿Qué ayudaría?

  • Adquirir los conocimientos de dominio necesarios. Ya sea a través de un desarrollador, gerente de producto, usuarios avanzados o, si es necesario, consultores. Tener a alguien que sepa qué tipo de expectativas enfrentará su producto le permitiría trabajar en estas funciones de manera preventiva.
  • Evite que las ventas afirmen que su producto ya lo hace todo. Esto es muy difícil porque en este momento lo que están haciendo está funcionando bien desde su perspectiva. Tienes que convencerlos de que no hacerlo es mejor o que alguien con suficiente influencia política ponga su pie en el suelo por ti.
  • Consiga que el personal de ventas y su OP construyan una asociación más sólida con sus clientes y comprendan mejor sus necesidades. Transición a un enfoque más abierto en el que sea honesto acerca de lo que su producto puede hacer en este momento y cuánto tiempo llevará agregar cualquier adición determinada.
  • Haga que su PO, SC y usted mismo pongan su pie en contra de estos trabajos urgentes. Dijiste que estás haciendo Scrum. No haces trabajos urgentes en Scrum. Esto es arriesgado, ya que negarse a realizar estas tareas puede costarle el trabajo si su organización no se compromete a hacer Scrum. Y por todo lo que he leído, no parece que lo sean. Es posible que pueda negociar esta "libertad" ofreciendo sprints más cortos (es decir, menos tiempo de espera antes de que se retome una nueva tarea). Sin embargo, su capacidad para ofrecer sprints más cortos está limitada por el tiempo que aparentemente necesita un solo desarrollador para una función determinada. . Una alternativa sería abandonar Scrum y hacer Kanban en su lugar. Tienes UNA tarea activa en la que estás trabajando hasta que la termines. Luego haces lo que ellos creen que es la siguiente tarea más importante.
  • Salga o cambie a un producto diferente. Parece que eres un desarrollador único que trabaja solo una parte del tiempo en este producto. Esto indicaría que no hay mucha inversión en el producto y que la compañía lo trata con la actitud de "saca todo el dinero que puedas con el mínimo esfuerzo". Si es así, esa no es una posición en la que quieras estar a largo plazo.

Sé que dices que estás siguiendo Scrum, pero ¿lo haces siguiendo las reglas ?

  • ¿Está creando un producto potencialmente liberable al final de cada Sprint?
  • ¿Está revisando el producto con las partes interesadas al final de cada Sprint durante la reunión de Revisión de Sprint?
  • ¿Está incorporando los comentarios que recibe en la revisión en el producto?

Si no, ese sería, creo, un buen lugar para comenzar.

Gracias por tu respuesta. Diría que hacemos todo lo posible para seguir las reglas (sé que esta oración hace que se vea mal y probablemente lo sea). Tenemos un producto potencialmente liberable al final de cada sprint. Pero antes de lanzarlo, no programamos el producto durante un sprint para permitir que los probadores hagan su trabajo. Y luego corregimos errores si es necesario y liberamos. Estamos revisando el producto al final de cada sprint, pero los requisitos técnicos básicamente nunca se discuten. Y sí, incorporamos comentarios al final del sprint y, como resultado, creamos elementos de backlog para el siguiente sprint.
Reduzca la cantidad de revisiones requeridas sin conocimientos técnicos
RespuestasAquíPolítica de privacidad1y, 0v