Análisis de la asignación y fijación de precios del desarrollo de proyectos de software

Es habitual que un cliente potencial que pregunta me envíe un documento y espere que yo haga una estimación del precio basándome en él. He visto, en empresas, que algunos vendedores probablemente tiren los dados y digan al preguntón alguna cantidad para contentar al cliente potencial. Sin embargo, yo sólo hago presupuestos cualificados y para esos hay que tener suficientes antecedentes y pensar en otras cosas... En ningún sitio he encontrado un procedimiento claramente descrito para hacer un buen análisis y no poner precio a un proyecto. Así que en este artículo compartiré información sobre cómo hago yo el análisis y la estimación de precios.

En primer lugar, debemos tener claro de qué estamos hablando. Se trata de cómo estimar competentemente un proyecto de software que está siendo desarrollado a medida. No vender una cosa terminada/software como vender orugas/teléfonos/claves de licencia.

Precios

Las valoraciones de los edificios, por ejemplo, son muy buenas. Suponiendo, claro está, que el mercado no cambie y, por tanto, el precio de los materiales y la mano de obra. Por ejemplo, si se encarga un sistema de calefacción central, se puede calcular con mucha precisión después de inspeccionar y medir la casa para determinar la cantidad de material (esto es el análisis del material necesario) y una persona experimentada, basándose en su experiencia previa en la realización de un proyecto similar, estimará el precio, que se basa principalmente en las listas de precios de los materiales y el tiempo necesario. Dicha estimación toma algo de riesgo y beneficio y lo añade y como resultado hace un presupuesto al solicitante.

Desarrollo a medida

Sin embargo, en el caso del desarrollo de software a medida, cada proyecto es diferente si se se puede utilizar una solución off-the-shelf o una base preconstruida. Un ejemplo típico son las tiendas virtuales. Se toma una solución preconstruida, se modifica la configuración, se cambia el aspecto y se reprograman funciones menores.

O puedes alquilar una eshop como servicio, donde tienes las mismas funciones que los demás. Sin embargo, no se puede personalizar nada.

Hoy en día, la personalización es la forma óptima de gestionar el desarrollo de proyectos: Desarrollo ágil, donde puede que ni siquiera sea necesario abordar la estimación de costes o sean orientativas.

Sin embargo, en el caso de una solicitud de precio fijo, hay que dar alguna estimación. Las estimaciones, ya sean de precio, tiempo o complejidad, pueden ser útiles en el desarrollo ágil. Normalmente, si estás desarrollando un gran proyecto del que depende el funcionamiento futuro de la empresa o una estimación orientativa para implementar alguna funcionalidad crítica importante en la aplicación.

Pasos de una estimación aproximada

Es probable que alguien esté haciendo estimaciones de costes desde una bola de cristal. Sin embargo, una estimación de precios cualificada se puede hacer mejor, sólo requiere trabajo. Basta con seguir algunos pasos. Al mismo tiempo, estos pasos garantizan que el producto final satisfaga las necesidades del cliente.

Cuanto mayor sea el proyecto, más complejo será y mayor será la probabilidad y la magnitud del riesgo de que algo algo se juzgue mal, algo se haga mal o incluso algo se olvide. Y entonces, con un proyecto más grande son mayores los ajustes que hay que hacer para llevarlo a cabo o para hacerlo bien. Por lo tanto, con un proyecto más grande, la necesidad de hacer un análisis inicial aumenta fundamentalmente y también hay que hacerlo con más detalle y con más cuidado.

Una lista de pasos a seguir para proporcionar información que especifique claramente el encargo:

1. Recopilación y análisis de requisitos
.
2. Redacción y documentación de los requisitos
3. Creación de la especificación técnica
4. Revisión y aprobación

Recopilación y análisis de requisitos

Reúnete con el cliente y analiza sus necesidades. Averigua qué problemas quiere resolver, cuáles son sus objetivos y expectativas. En esta fase, es importante hacer muchas preguntas para entender el contexto y las razones para crear la aplicación.

Si el proyecto es de mayor envergadura e implica a varias partes, puede ser conveniente celebrar una reunión de grupo en la que todas las partes interesadas puedan expresar sus necesidades e ideas. Además de los directivos, debería asistir un empleado de base de la empresa que conozca personalmente la actividad, y que, por tanto, suele ser la persona que utilizará la funcionalidad de la aplicación.

Analice las soluciones existentes en la empresa y en el mercado. Si ya existe un sistema al que la nueva aplicación va a sustituir o complementar, analice su funcionalidad e identifique problemas o áreas de mejora.
Explore si existen aplicaciones similares en el mercado y qué funcionalidades o características podrían beneficiar a su proyecto.
Puede que incluso descubra que ya existe una aplicación con la funcionalidad deseada y no hay necesidad de malgastar recursos (gastar dinero, invertir tiempo) en implementar una nueva solución desde cero, pero será posible tomar una solución existente y modificarla para sus necesidades específicas. Esto supondrá un ahorro significativo de dinero, reducirá el tiempo de puesta en marcha y reducirá los riesgos asociados al desarrollo de software a medida.

El análisis es un método científico basado en la descomposición de un todo en partes elementales, un método de examinar hechos más complejos mediante su disolución en unidades más simples y básicas. El objetivo del análisis es identificar las propiedades esenciales y necesarias de las partes elementales del todo, conocer su esencia y sus regularidades. El análisis es también un método de interpretación cuando separamos los fenómenos fenómenos individuales y los examinamos aisladamente. (El procedimiento opuesto al análisis se denomina síntesis. La síntesis da lugar a la creación de nuevos enteros).

El resultado del análisis en los sistemas de información es principalmente la comprensión de la lógica. Y así obtener los supuestos iniciales para la implementación de un sistema o la optimización de un sistema existente.

¡Encontrar los puntos críticos!
Los puntos críticos de un proyecto son momentos clave en los que pueden surgir problemas graves o en los que es crucial decidir cómo se desarrollará el proyecto. Identificarlos y gestionarlos aumenta el éxito del proyecto. Trace el calendario del proyecto e identifique los plazos más importantes (por ejemplo, la finalización de una fase o la aprobación del cliente).

Analice las dependencias entre tareas. Cada tarea puede depender de otras. Si una tarea se retrasa, puede afectar a todo el proyecto. Utilice un Gráfico de Gantt o un Método del Camino Crítico (CPM), que son herramientas para visualizar cómo están conectadas las distintas actividades y cuáles tienen una flexibilidad mínima en los plazos.

Desarrollo de requisitos y documentación

Requisitos Funcionales

Definir lo que la aplicación debe hacer - es decir, sus funciones. Estas pueden incluir operaciones específicas que los usuarios pueden realizar, por ejemplo, "el usuario puede iniciar sesión con correo electrónico y contraseña", "el sistema notifica automáticamente los próximos eventos" etc.

CONSEJO: Escriba también las funciones que no estarán en la aplicación, para que quede claro lo que la aplicación no hará. Escriba las características que planea añadir en el futuro, ya que podemos utilizar esto para guiar el desarrollo y preparar la aplicación para facilitar la adición de estas características más adelante. características.

Requisitos funcionales

Determine los requisitos de rendimiento, seguridad, usabilidad, escalabilidad, mantenimiento, etc. Estos requisitos no se centran en características específicas, sino en cómo debe funcionar la aplicación.

Priorizar requisitos

En colaboración con el cliente, priorice cada requisito. Esto le ayudará a determinar qué características deben realizarse en la primera fase y cuáles pueden esperar a la hora de planificar el desarrollo.

CONSEJO: Cree un grupo de requisitos que sean imprescindibles para la primera versión significativa de la aplicación. Pase esta versión de la aplicación a la fase de a producción para su uso. A continuación, añadir características adicionales de forma incremental.
Este es el final de la aplicación tav. producto de valor mínimo (MVP), que tiene la ventaja de darle una respuesta rápida a su aplicación y puedes adquirir tus primeros clientes.

Crear un resumen técnico

Dado que el lenguaje del usuario y del cliente es diferente del lenguaje del desarrollador del sistema de información, es una buena idea crear glosario de términos y anotar todos los términos desconocidos. Normalmente palabras del ámbito de la programación o del argot corporativo.

Introducción y descripción del proyecto

Inicie el documento con un resumen sencillo de lo que se pretende hacer con la aplicación y qué problemas se pretenden resolver.

Introducción del proyecto

Especificación de la funcionalidad

Describa cada requisito funcional en detalle, incluyendo escenarios de uso (casos de uso), diagramas de flujo, historias de usuario, etc.

Arquitectura del sistema

Diseñe cómo se estructurará el sistema. Esto puede incluir diseño de la base de datos, API interfaz, módulos de aplicación, y cómo los diversos componentes trabajarán juntos.

Para escribir (trazar) clases, estructuras de BD, y usecase, lo ideal es utilizar el UML. De esta forma podrás crear, editar y leer los documentos de desarrollo de la aplicación de forma más eficiente.

Pila de tecnologías

Seleccione las tecnologías y herramientas que se utilizarán - lenguajes de programación, frameworks, bases de datos, servidores, etc. Al seleccionar las tecnologías, considere su idoneidad para la tarea en cuestión. A menudo, la cantidad disponible de desarrolladores que estén familiarizados con la tecnología.

Prueba las tecnologías y API que vas a utilizar por primera vez, para que sepas qué esperar y si son incluso utilizables. De esta forma, no te adentrarás en lo desconocido ni harás conjeturas a partir de lo desconocido. Esto también te preparará para el entorno de desarrollo/pruebas.

Requisitos de seguridad

Especifique cómo se manejarán los temas de seguridad, incluyendo autenticación, autorización, encriptación, etc. Si no los especifica no espere que sean considerados significativamente.

Pruebas

Defina cómo se probará la aplicación: qué tipos de pruebas se realizarán (unitarias, de integración, usuario), quién las realizará y cuáles son los criterios de aceptación. Quién aprobará por parte del cliente que la funcionalidad se ha entregado correctamente.

Plan de desarrollo

Por último, cree un cronograma de desarrollo con hitos que se irán alcanzando de forma incremental. Incluya también un plan para abordar gestión de riesgos y cambios.

Revisión y aprobación

Proporcione al cliente un encargo técnico para su revisión. Repase todos los puntos clave con ellos y asegúrese de que lo entienden todo y esté de acuerdo con todo. Obtenga comentarios y haga ajustes si es necesario. Es importante que el cliente esté totalmente de acuerdo con los TdR antes de comenzar el desarrollo. Una vez que todo esté acordado, haga que el cliente apruebe formalmente los TdR. Esto garantizará que ambas partes expectativas claramente definidas.

¿Por qué hacer un análisis y un informe técnico?

Este enfoque sistemático y estructurado ayudará a minimizar los malentendidos y garantizará que el desarrollo de la aplicación sea planificado y conforme a los requisitos del cliente. Tanto el proveedor como el cliente tienen mayor confianza en que todo será como esperan.

¿Pago por análisis?

A menudo ocurre que el consultante espera que el análisis y el presupuesto sean gratuitos. Y alguien acepta tal petición, pero luego recibe una oferta que no está respaldada por nada. Posteriormente, una vez que el solicitante se ha convertido en cliente, éste se sorprende cuando obtiene el resultado más tarde a un precio más alto y a veces recibe algo que no se ajusta a sus expectativas. Un buen análisis y una buena especificación técnica también garantizan el control de todo el proceso de desarrollo y contribuyen así al éxito del proyecto.

Por eso, el solicitante debe pagar por el análisis. Pagar por el análisis tiene muchas otras ventajas...

Pagar por el análisis de un encargo es beneficioso para el cliente por estas muchas razones:

• Definición clara de objetivos y requisitos.
.
• Minimización de riesgos y costes.
• Estimación precisa de costes y plazos.
• Garantía de calidad
.
• Prevención de malentendidos
.
• Mejor toma de decisiones.
.
• Flexibilidad y adaptación.
.
• Base para el desarrollo futuro.

Definición clara de objetivos y requisitos

Analizar el brief ayuda al cliente a articular exactamente lo que espera de la aplicación. A menudo, los clientes tienen una idea general de lo que quieren, pero no una especificación detallada. El análisis ayuda a concretar esa idea, garantizando que el producto final satisfaga realmente sus necesidades.

Minimización de riesgos y costes

Invertir en un análisis exhaustivo al principio de un proyecto puede ahorrar dinero a largo plazo. Sin un análisis minucioso pueden surgir problemas inesperados durante el desarrollo o puede ser necesario realizar cambios importantes, lo que puede hacer que el proyecto sea costoso y retrasar el proyecto.

Estimaciones precisas de costes y plazos

A través de un análisis detallado, se pueden estimar los costes y plazos de desarrollo. Esto ayuda al cliente a planificar presupuesto y esperar fechas realistas de finalización del proyecto. Sin este análisis, las estimaciones son muy imprecisas, lo que provoca insatisfacción en ambas partes.

Aseguramiento de la calidad

Un informe técnico creado a partir de un análisis exhaustivo proporciona al equipo de desarrollo directrices y especificaciones claras, lo que conduce conduciendo a un producto final de mayor calidad. Cuando los desarrolladores disponen de información precisa y detallada, pueden centrarse mejor en la implementación, lo que reduce el número de errores y defectos.

Prevención de malentendidos

El análisis detallado y las posteriores especificaciones técnicas sirven de referencia para todo el proyecto. Esto garantiza que ambas partes - el cliente y el equipo de desarrollo- tengan una idea clara y coherente de lo que se va a crear. Esto reduce el riesgo de malentendidos y conflictos posteriores.

Mejor toma de decisiones

Durante el proceso de análisis, a menudo surgen preguntas e ideas que el cliente no tuvo en cuenta inicialmente. Esto conduce entonces a una mejor (oportuna) toma de decisiones y optimización de las funcionalidades de la aplicación. El cliente puede así obtener información valiosa sobre qué funcionalidades le convienen y qué enfoque tecnológico es el más adecuado.

Flexibilidad y adaptación

Si los requisitos cambian o se descubren nuevas necesidades durante el análisis, es más fácil hacer ajustes en esta fase que durante el propio desarrollo. El análisis permite reaccionar con mayor flexibilidad a los cambios, lo que es beneficioso para el cliente.

Base para el desarrollo futuro

Un análisis y una especificación técnica bien realizados sirven como documentación que puede utilizarse en el futuro. Si el cliente decide seguir desarrollando o ampliando la aplicación, tendrá una base sólida sobre la que sobre la que construir.

La especificación técnica puede y tomar con esta información completa puede solicitar la aplicación con otro proveedor.

Entrega y puesta en marcha del proyecto terminado

Si estás construyendo el proyecto sobre tecnologías que conoces y has probado, has pensado en las tecnologías desconocidas y API de antemano, has pensado en los puntos críticos del proyecto, has eliminado los grandes riesgos y tienes muchas posibilidades de que el proyecto salga bien.

Acuerde de antemano dónde se explotará la aplicación y si espera supervisar y mantener la aplicación después. de la aplicación.
Una vez puesto en marcha el proyecto, lo ideal es realizar un análisis posterior a la aplicación.


¡Complete y actualice la documentación!