BRD sin sistemas/sin TI

¿Se requieren documentos BRD y FRD para proyectos que no son de sistemas ni de TI? Estamos involucrados en un proyecto de migración de servicios que mueve los servicios de alojamiento de sitios web administrados de un proveedor externo completamente administrado a uno interno para que podamos administrarlos nosotros mismos. Debido a que este es un proyecto de transición que no requiere el desarrollo o la construcción de ningún sistema o infraestructura de TI (ya tenemos los servidores para respaldar el sitio web), se puede comparar con un proyecto de construcción o ingeniería donde los documentos BRD y FRD no suele existir.

Por lo general, los requisitos se basan en los objetivos comerciales y luego los requisitos funcionales y no funcionales se basan en los requisitos. Si este es un proyecto de transición que está moviendo un servicio del Proveedor A (externo) al Proveedor B (interno), ¿realmente se requiere un BRD?

El principal objetivo empresarial es hacer la transición de los servicios gestionados de forma externa a interna. Si observamos las tareas reales y las piezas de trabajo involucradas en el proyecto para lograr con éxito el objetivo comercial, algunas de ellas a un nivel muy alto incluyen:

  • Documentación: Identificación y traslado de la documentación soporte.
  • Recursos humanos: Emplear personal nuevo o contratar personal de proveedores existentes para administrar el servicio de alojamiento internamente.
  • Procesos: Obtención del proveedor e introducción de nuevos procesos para brindar el mismo servicio administrado.

Las restricciones principales, o requisitos no funcionales si se tratara de un proyecto de sistemas/TI, serían:

  • Sin pérdida en la prestación de servicios durante la transición.
  • Cumplir con los procesos y SLA de la empresa.

¿Se requieren documentos BRD y FRD, o sería suficiente una serie de planes (plan de implementación, plan de transición, plan de continuidad, SLA, etc.)?

Actualización: muchas gracias por las respuestas y comentarios hasta ahora. Solicito más puntos de vista y comentarios que puedan contribuir, ya que tales proyectos no son poco comunes, pero hay poca información en línea para consultar.

Respuestas (3)

El objetivo de estos documentos no es cumplir con un requisito del proceso (aunque es posible que su proceso le exija hacerlo), sino aclarar lo que se debe hacer y lograr que todos estén en sintonía.

Los documentos que mencionó en la conclusión de su pregunta (plan de implementación, plan de transición, plan de continuidad, SLA, etc.) son útiles, pero los documentos que le permiten declarar "hecho" son sus documentos de requisitos. Los animo a que los hagan, independientemente de que sus partes interesadas insistan o no.

Gracias Scott. Si vamos con un BRD, ¿puede dar algunos ejemplos de cuáles serían/podrían ser los requisitos comerciales reales, los requisitos funcionales y los requisitos no funcionales? A partir de este proyecto, esperamos desarrollar y/o adquirir cientos de documentos sobre cómo proporcionar el mismo servicio de alojamiento web. ¿Tendríamos cientos de requisitos comerciales para abordar cada documento?
Por ejemplo, si el objetivo comercial es hacer la transición de los servicios de hospedaje de sitios web administrados de forma externa a interna y, para hacerlo con éxito, no debemos tener ningún tiempo de inactividad ni afectar las operaciones comerciales, ¿en qué documentos ubicaríamos el trabajo de: • identificar y transferir la documentación de soporte • emplear personal nuevo o personal del proveedor existente para administrar internamente el servicio de hospedaje • obtener del proveedor e introducir nuevos procesos para brindar el mismo servicio administrado, etc.

Sugiero que sin algún tipo de documento de requisitos, no tiene una declaración clara de expectativas, por lo que tiene mucho sentido desarrollar incluso un documento de alto nivel que diga lo que hará dentro de este proyecto y defina algunos criterios. por el cual se medirá el proyecto: condiciones de satisfacción, si lo desea. Según el tipo de proyecto que describa, tendrá expectativas sobre el rendimiento, el costo, la confiabilidad y la funcionalidad. Incluso afirmar explícitamente que el rendimiento, el costo y la confiabilidad serán iguales o mejores que el servicio subcontratado actual, y que la funcionalidad será idéntica, es un buen comienzo. De lo contrario, es posible que sus equipos técnicos comiencen a realizar cambios dentro del alcance del proyecto, solo porque pueden y porque no hay nada que les diga que no lo hagan.

Básicamente, necesitas alguna estructura para definir qué está dentro y qué está fuera del proyecto, y luego trabajas dentro de eso o lo modificas consciente y deliberadamente. De cualquier manera, tiene un punto de partida desde el cual puede mantener el proyecto enfocado en entregar el valor comercial que se anticipa.

gracias Todavía no tengo claro qué dirección específica tomar. Hay un alcance del proyecto definido que define lo que está dentro y fuera del alcance, y las tareas y actividades se definen en la EDT en función del alcance. Si creamos un BRD, contendrá algunos requisitos que se enumeran anteriormente. ¿Hay alguna manera de que podamos incluir todos los documentos que necesitamos crear como requisitos comerciales? Si necesitamos crear un plan de continuidad, múltiples SLA, procedimientos operativos, etc., para respaldar el alojamiento de sitios web internos, ¿cómo podrían convertirse en requisitos funcionales utilizados para verificar los requisitos?
Debido a que el documento Alcance del proyecto puede ser suficiente, siempre que haya abordado el riesgo de que su visión de los entregables y la visión comercial de los entregables estén en línea. Considere comenzar con el riesgo, luego trabaje hacia atrás hasta que esté seguro de que todos están en la misma página en términos de comprensión, luego deténgase. No hagas más de lo que tienes que hacer. Además, no se obsesione con los nombres de los documentos: lo que cuenta es el contenido y el valor de los documentos, no cómo los llame. Si su documento de alcance cumple con los requisitos, ¡entonces no vaya a producir algo más que realmente no necesita!
gracias ¿Dónde especificaríamos los cientos de documentos individuales reales que se entregarán, como: documentación de soporte, SLA, etc.? Estos respaldan la transición en sí misma para que podamos administrarla internamente. ¿La dificultad será comunicar con las partes interesadas y el PM que solo tenemos un Documento de Alcance y no requisitos reales? La expectativa es crear de alguna manera cientos de "entregables" de todos estos documentos para que cada uno pueda verificarse para garantizar que la transición sea exitosa y que nada se haya pasado por alto o perdido. El proyecto es de naturaleza crítica.
No hay una respuesta correcta o incorrecta para definir los documentos individuales, pero un documento de requisitos comerciales puede ser el lugar correcto. Mi duda es que puede terminar produciendo docenas o cientos de documentos que no agregan valor a la organización, pero si los define todos desde el principio y los entrega contra esa lista, podría estar entregando material que nunca se lee y termina acumulando polvo. . Permítanme hacer una pregunta, y no necesito una respuesta: ¿La documentación define el éxito, o un sistema de trabajo confiable, seguro y robusto define el éxito? ¡Solo tú puedes responder eso!
Gracias Iain y algo de buena comida para el pensamiento. Aunque los entregables pueden estar en un nivel superior, la documentación de respaldo y otros recursos están ahí para respaldar y garantizar que el servicio sea confiable, seguro, sólido y funcional. Es positivo si estos documentos rara vez se recuperan y utilizan.

Creo que cada proyecto/característica/tarea, sin importar cuán pequeños sean, debe planificarse.

¿Qué pasa si uno de los sitios que está a punto de migrar depende de un tercero del que no está al tanto? Si tiene sus requisitos en un documento, puede distribuirlo a las personas relevantes y obtener su aprobación (firma). Esto no solo cubrirá su espalda, sino que también podría brindarle una mejor comprensión de un problema.

¿Cómo sabe cuándo el proyecto está completo si no ha dicho en ninguna parte qué cuenta para "completo"?

Los documentos que ha mencionado son a lo que me referiría como documento de análisis. El documento de análisis debe proporcionar suficiente información a alguien nuevo para que se haga cargo de la tarea en caso de que decidas dejar la empresa. Si es un documento de unas pocas páginas, simplemente lo llamaría un documento de análisis. Si fuera un documento de cuarenta páginas, consideraría dividirlo en documentos más pequeños.

Gracias CodeWorks y sus comentarios nos dan una buena visión del problema. Parece que una combinación de documentos de análisis, requisitos comerciales y algunas otras cosas será el camino a seguir.
BRD sin sistemas/sin TI
RespuestasAquíPolítica de privacidad1y, 0v