Cómo escribir una propuesta de desarrollo de software

Cómo redactar una propuesta de desarrollo de software exitosa.

Kevin Languedoc

El propósito de una propuesta de desarrollo de software es transmitir una solución que será leída por la gente de negocios, así que manténgala simple y al grano; manténgase alejado de los términos técnicos tanto como sea posible. El siguiente esquema se puede utilizar tal cual para preparar una propuesta de desarrollo de software exitosa. Es importante tener en cuenta que las personas a las que vas a presentar la propuesta no tienen mucho tiempo para leer un documento extenso. Puede tomarlo de mí, he escrito cientos de propuestas durante mis más de 20 años en tecnología de la información: la gente de negocios solo quiere la información suficiente que les permita tomar una decisión informada.

Si está respondiendo a una Solicitud de propuesta (RFP) y debe respetar un cierto rango de páginas, porque las páginas están preimpresas o los requisitos de contenido lo obligan a tener una propuesta excesivamente larga, considere usar un Resumen ejecutivo. He agregado una sección que describe cómo preparar uno a continuación.

Duración de la propuesta

He visto plantillas y debates que abogan por propuestas que se ejecutan en 50 páginas o más. Créame, perderá el interés del ejecutivo comercial después de la quinta página. Una vez aceptada la propuesta, los documentos de diseño serán naturalmente más detallados, ya que estarán destinados al equipo del proyecto y serán los planos de trabajo del sistema. Esto se aplicará a la mayoría de los clientes, pero (sí, siempre hay un pero) si la propuesta responde a una Solicitud de propuesta (RFP), entonces debe cumplir con la RFP. Además, una agencia gubernamental o militar probablemente tendrá directrices estrictas sobre cómo preparar una propuesta de desarrollo de software y puede incluir varias páginas (10, 20, 30, 50 o más) según la complejidad del sistema.Esta regla sigue siendo válida para las grandes organizaciones que pueden tener un proceso de propuesta formal, especialmente si son una corporación pública y deben adherirse a las regulaciones o estándares de Sarbannes-Oxley o ISO.

Resumen ejecutivo

Si la propuesta tiene más de 20 páginas, entonces puede considerar proporcionar un Resumen ejecutivo que es una página de las secciones de la propuesta. Incluso puede proporcionar un resumen ejecutivo en formato PowerPoint. Si planea utilizar un resumen ejecutivo en la presentación de la propuesta de desarrollo de software, presente la propuesta utilizando el resumen ejecutivo y el ejecutivo podrá leer la propuesta en un momento posterior, como durante un vuelo de negocios.

La plantilla

El siguiente esquema es en realidad una buena plantilla que puede utilizar para preparar su propia propuesta de desarrollo de software. Siempre tengo en mente la regla de Elevator Pitch cuando preparo una propuesta, y usted también debería hacerlo. Básicamente, el Elevator Pitch estipula que su propuesta no debe ser mucho más larga que el tiempo que toma tomar un ascensor desde la planta baja hasta el último piso de un edificio en su camino para presentar una propuesta.

Título del Proyecto

Con un subtítulo o información resumida sobre la propuesta

La propuesta debe tener un título y una subsección que resuma el contexto de la propuesta de software. También incluye el nombre de la división, servicio, departamento u organización a la que está destinado el proyecto.

Si está respondiendo a una RFP (Solicitud de propuesta), incluya cualquier información que se requiera o se indique como obligatoria en la RFP. También he visto RFP que solicitan que coloque las firmas de aprobación además del título en la primera página, pero en este ejemplo, coloco las firmas en la página con la sección Cambios.

Tabla de contenido

En la página siguiente, debe incluir una tabla de contenido que enumere las secciones principales de la propuesta. Opcionalmente, puede incluir los números de página si la propuesta supera las cinco páginas o si lo requiere la RFP.

Aprobaciones

Esta sección es crucial para el proceso, ya sea que sea una respuesta a una RFP o de esta plantilla o de alguna otra fuente. Esta sección documenta las confirmaciones de que el proyecto está en marcha y proporciona un acuerdo vinculante entre los diversos miembros del proyecto. Nunca debe comenzar un proyecto hasta que haya obtenido todas las firmas necesarias y tenga el compromiso del campeón del proyecto y las partes interesadas para comenzar el proyecto. De lo contrario, podría encontrarse en un aprieto si el proyecto se cancela o si el alcance del proyecto cambia o los entregables.

Con las Aprobaciones vigentes, los cambios en el alcance y los entregables son mucho más difíciles de realizar y, si hay disputas, tener aprobaciones firmadas proporcionará una comprensión (más) clara de lo que se acordó. Por supuesto, siempre hay una cuestión de interpretación.

Las Aprobaciones deben incluir el nombre de la persona, su cargo, seguido de su firma y finalmente la fecha en que se firmó el documento.



Nombre	Título del rol	Firma	Fecha

Cambios

La sección Cambios proporciona un registro de todos los cambios que se realizaron o se realizarán en el documento Propuesta de desarrollo de software. No documenta ningún cambio en el alcance del proyecto en sí ni en ningún otro aspecto del proyecto. La sección Cambios debe incluir como mínimo el nombre de la persona que realiza el cambio, la fecha del cambio y un comentario o descripción del cambio.



Autor	Fecha de cambio	Descripción o comentario

Glosario y acrónimos

Enumere cualquier término o acrónimo y sus definiciones. No asuma que todos conocen el significado de los términos o siglas, especialmente si planea utilizar consultores externos y los términos son internos, integrados en su cultura y jerga corporativa. Cada organización tiene su propia jerga y acrónimos. Está bien utilizarlos en la propuesta siempre que estén debidamente documentados.

Además, si se utilizan acrónimos específicos de la industria, también deben documentarse para que todos tengan una comprensión clara del significado de los términos y acrónimos y formulen mejores interpretaciones.

Los siguientes acrónimos son de la plantilla actual. Se proporcionan como ejemplo.

RFP: Solicitud de propuesta
ROI: retorno de la inversión
CAGR: Tasa de crecimiento anual compuesta
TI: Tecnología de la información
CAPEX: Gastos de capital
Unidad de medida: Unidad de medida

Alcance

El alcance de la propuesta debe describir a un alto nivel los detalles generales del proyecto, lo que se incluye y excluye. El alcance debe proporcionar una descripción general, la duración del proyecto y los principales objetivos. ¿Qué está tratando de lograr con esta inversión en el proyecto de desarrollo de software propuesto?

Cronología

Esta sección incluirá las fechas de inicio y finalización (estimadas). Asegúrese de crear un colchón y planificar las contingencias. Una buena regla general es agregar un búfer del 75% a su línea de tiempo.

Miembros del proyecto

Los miembros del proyecto deben incluir al campeón del proyecto y las partes interesadas. El campeón suele ser un ejecutivo que dirige el proyecto y el presupuesto generales. El interesado suele ser un promotor o patrocinador interno. También pueden ser los campeones dependiendo del alcance del proyecto o del tipo de organización que solicita la propuesta de desarrollo de software. La lista restante contiene los roles típicos que las personas realizan en un proyecto.

Lo siguiente se proporciona solo como un ejemplo del tipo de roles que pueden tener los participantes del proyecto. Algunas personas pueden tener más de un rol. Dependiendo del alcance del proyecto, la lista de miembros del proyecto puede ser muy extensa o la misma persona puede asumir diferentes roles.

La lista debe contener cualquier información que identifique adecuadamente a la persona, su rol dentro del proyecto, cómo llegar a ellos y cuáles son sus responsabilidades. Puede incluir otra información según la RFP o el tipo de organización con la que trabajará y sus políticas internas.



Miembro del equipo	Papel	Información del contacto	Responsabilidades
	Campeón
	Interesado
	Gerente de proyecto
	Arquitecto
	Analista
	Desarrollador

Oportunidad de negocio

La mayoría de las plantillas disponibles definen esta sección como “Problema empresarial” o “Declaración del problema”, sin embargo, a menudo me he encontrado con líderes empresariales que se ofenden por el hecho de que tienen un problema en su unidad de negocio o proceso. Recuerdo que una directora me echó literalmente de su oficina porque había dicho que estábamos arreglando un proceso y ella me dijo que no iba a ser alguien de TI (Tecnología de la Información) quien dictara si tenía un problema. con sus procesos o no.

Así que ten cuidado con la redacción. Siempre uso el término "Oportunidad de negocio" porque al final, la propuesta es en respuesta a una oportunidad de negocio para mejorar un proceso, apoyar un proceso o automatizar un proceso.



Declaración comercial	Cómo el sistema satisfará el requisito
Proceso de negocio afectado, situación, problema	¿Cómo mejorará la solución propuesta el área de negocio objetivo?
¿Qué necesidad se está abordando?	¿Cómo lo abordará el proyecto actual?

Resumen de la solución

En la sección Descripción general de la solución, puede proporcionar una descripción general de alto nivel del sistema. Esta descripción general puede incluir un mapa de navegación si la propuesta es para un sitio web o una aplicación web. También puede incluir un diagrama de flujo del proceso. Además, puede incluir un diagrama de los componentes principales del sistema.

El objetivo aquí es dar a la persona que está tomando la decisión suficiente información para que comprenda cuál es el sistema, cómo funcionará y cuáles son los componentes principales. Por supuesto, esto es solo una guía, ya que una organización puede tener un formato formal que defina lo que necesitará proporcionar en la propuesta, especialmente si está tratando con una agencia gubernamental o el departamento de defensa.

Características y entregables

Esta sección proporciona un mecanismo para asignar una característica del sistema propuesto a un producto tangible. También he visto esta sección que contiene una estimación de tiempo para completar el entregable, pero no me gusta usar esto porque es demasiado restrictivo y crea un vínculo. Al trabajar en el proyecto, es posible que los entregables no se alineen exactamente como están escritos, por lo tanto, si se ha comprometido en papel a terminar un entregable en un cierto tiempo, elimina o disminuye cualquier elasticidad más adelante, cuando realmente está haciendo el proyecto.

Otra columna que se puede agregar es la versión a la que pertenece el entregable. Esto es útil si el proyecto se entregará durante un período de tiempo más largo y habrá varios lanzamientos. Esto también se puede aplicar a un proyecto basado en Agile o Lean donde cada característica o historia de usuario pertenece a una versión.

El concepto es simple; para cada característica del sistema, proporcione el nombre de la característica, una breve descripción y qué entregable satisfará el requisito de la característica.



Característica	Descripción	Entregables

Presupuesto y ROI

El presupuesto y el ROI es probablemente la parte más importante para algunos ejecutivos. Todos están ansiosos por saber cuánto les costará el sistema o cuánto impacto tendrá este proyecto en el presupuesto de su departamento. Esto es especialmente cierto si el proyecto no se incluyó en el Capex al comienzo del año fiscal.

A veces, incluso si el proyecto fue presupuestado, otro proyecto puede tener prioridad sobre la propuesta actual y los fondos se pueden desviar de su fuente prevista. A menudo hay un poco de disputas políticas a nivel ejecutivo y gerencial para que un proyecto despegue y, a menudo, hay circunstancias imprevistas que pueden tener prioridad sobre los proyectos planificados.

Por lo tanto, prepárese para trabajar con sus partes interesadas para ayudar con las negociaciones o sea flexible y proactivo para brindar una solución de trabajo si la situación presupuestaria va hacia los lados. Es mejor adaptar el proyecto a la realidad presupuestaria, incluso distribuir los entregables del sistema durante un período de tiempo más largo o incluso alejarse del proyecto. Es mucho mejor marcharse que haber trabajado en un proyecto y no recibir un pago y tener que recurrir a litigios en el futuro.

La siguiente tabla es solo para fines de demostración para darle una idea de cómo preparar un presupuesto. Naturalmente, deberá agregar sus propias líneas de pedido para que se ajusten a su proyecto. Luego, ingrese la cantidad, el precio unitario, la unidad de medida y el total del artículo de línea. Luego, cuente los totales de las líneas de pedido en la parte inferior.

Esto proporcionará una buena imagen de la inversión necesaria para realizar el proyecto de software. A la mayoría de los ejecutivos con los que he trabajado les gusta saber cuál será la tasa de retorno o cuánto costará este proyecto a lo largo del tiempo, por lo que también incluyo un valor de ROI simple y una CAGR, ya sea usando mis propias estimaciones y suposiciones (que deben ser explicado) en la propuesta o utilizando las estimaciones y supuestos proporcionados.



Elemento del proyecto	Cantidad	Precio unitario	UoM	Total
Licencia de software
Máquinas)
Licencia de servidor
Licencia de base de datos
Consultor de desarrollo
Gestión de proyectos
Capacitación (tiempo + materiales)

ROI

El cálculo del ROI es muy sencillo. Básicamente, la fórmula es ganancias: costo dividido por costo. La fórmula se proporciona a continuación:

El único inconveniente es que el cálculo no tiene en cuenta el tiempo, por lo que el ROI es bueno para proyectos a corto plazo, pero para proyectos a largo plazo generalmente incluyo una CAGR (tasa de crecimiento anual compuesta). El cálculo de la CAGR es una tasa de rendimiento anual durante un determinado momento.

CAGR

La fórmula CAGR es:

La primera parte es la división del valor final por el valor inicial. El resultado se eleva a la potencia de 1 sobre el número de años invertidos. El valor resultante se resta por 1.

Beneficios

En esta sección, enumera los beneficios comerciales que proporcionará el proyecto de software. Se pueden enumerar en formato de viñetas siempre que se correspondan con los objetivos generales. Deben demostrar cómo el software o el sistema mejorará el valor comercial.

En pocas palabras, ¿cómo va a ayudar la solución propuesta a que la empresa tenga más éxito y alcance los objetivos de su declaración? Use palabras y oraciones positivas.

Restricciones

La sección de restricciones debe enumerar cualquier restricción tangible e intangible que pueda prever. Esto puede relacionarse con equipos, algún factor de estacionalidad como el cierre de una planta de producción que la mayoría de las plantas hacen al menos una vez al año como ejemplo.

Intente minimizar las limitaciones o pintarlas como mínimas. No enumere ningún aspecto negativo del software o sistema o, si es necesario, proporcione soluciones alternativas.