2010-08-13 12 views
21

Estoy tratando de explicar la proporción de costos de desarrollo versus mantenimiento a nuestro departamento de ventas, y actualmente tengo la sensación de que pasamos aproximadamente el 60% del tiempo con el mantenimiento.Costo de desarrollo versus costo de mantenimiento

Tenemos algunas personas en el equipo que tiende a vender soluciones personalizadas, que tenemos que construir, y si los vendedores no entienden el costo total del desarrollo, entonces no podrán vender a precios realistas .

Otro "problema" es que estamos ampliando nuestro servicio, y tenemos la necesidad de refacturar parte de la infraestructura subyacente para reducir el tiempo de comercialización y otros puntos de medición.

¿Tiene alguna buena sugerencia sobre a qué me refiero para construir un argumento sólido? ¿Y qué puntos debo mencionar para poder comprender bien el problema?

tal vez hay algún gran texto en alguna parte que pueda señalar a.

Respuesta

18

En "Hechos Fundamentales Frecuentemente Olvidados sobre Ingeniería de Software" por Robert L. Glass, (un artículo en IEEE Software mayo/junio 2001), habla de softwares "60/60" regla, es decir que el mantenimiento típicamente consume 40 al 80% (60% promedio) de los costos de software, y luego que la mejora es responsable de aproximadamente el 60% de los costes de mantenimiento de software, mientras que la corrección de errores es de aproximadamente 17%.

+0

gracias por el enlace, voy a leer un poco. –

+0

Vi esta referencia en una publicación de slideshare en microservicios (http://www.slideshare.net/INPAY/the-why-what-and-how-of-microservices). La cosa es: ¿ha subido o bajado el costo 16 años en el futuro? – Irwin

3

intentar conseguir que piensen de software como un coche. Puede tomar solo un par de semanas o un mes para construirlo, pero mientras está en uso en las siguientes semanas, meses y años, se requiere mantenimiento. Tal vez solo sea un mantenimiento de rutina para que las cosas funcionen sin problemas; pero también podría ser el mantenimiento de emergencia cuando hace algo inesperado y necesita ser reparado.

Del mismo modo, puede que todo esté bien la primera vez que lo obtenga, pero después de un poco de uso, necesitará pulir hasta hacerlo como esperaba que fuera todo el tiempo.

+1

El uso de una analogía cotidiana es una excelente manera de tratar temas como este. –

+3

Para ser sincero, no creo que sea una buena analogía. El costo de mantenimiento de un automóvil es insignificante en comparación con el precio de compra. Entonces, ¿por qué el mantenimiento de su proyecto de software cuesta más de la mitad del presupuesto total de desarrollo? Ese es exactamente el tipo de razonamiento que a veces necesitas contrarrestar. –

+0

@BartGijssens, estoy de acuerdo. El costo de mantener un automóvil es preservar su funcionalidad actual. La analogía de eso en el software consistiría en corregir errores menores para reparar fugas de memoria, realizar limpieza de datos, borrar archivos de registro antiguos, y más. El costo real del "mantenimiento" en el software suele ser la readaptación y la mejora, o corregir fallas conceptuales fundamentales, y una vez que la máquina está en uso constante y ha acumulado estado, el costo es más análogo al ajuste o reemplazo de un motor de avión en vuelo. – Steve

4

estudiar el concepto de la deuda técnica. Además, trate de pasar el rato con vendedores. Lo más probable es que no sean malvados o que no les importe; simplemente han sido expuestos a cosas diferentes, tienen diferentes habilidades e intereses que tú. Las habilidades blandas importan mucho. Los mayores errores serían hacerles saber que "no entienden las computadoras". El tipo de vendedor más fácil con el que he trabajado era ex-QA, así que consiguió un montón de cosas. Por cierto, el trabajo de los vendedores es doblegar la verdad y mantener esos dólares por venir. Es un equilibrio delicado entre no incurrir en demasiada deuda técnica y no perder oportunidades de negocios.

+0

Gracias, leeré un poco sobre la deuda técnica. –

8

Después de 29 años en la industria puedo decir que el mantenimiento es 60-80% del costo total. El desarrollo es como máximo del 20%. Pero la mayoría de las empresas de hoy no parecen reconocer que ponen el mayor énfasis en el desarrollo rápido y establecen las fechas de vencimiento sin una estimación adecuada. Esto obliga a los desarrolladores a volcar e ir, lo que solo hace que el mantenimiento sea más difícil. Entonces, ¿qué hacen los ejecutivos como resultado? Tiran todo el software interno y compran cosas de terceros. A continuación, la pesadilla de la integración de sistemas sucede y quizás 4 o 5 años más tarde se va a clase de, clase-de ponerlo todo en marcha, pero el costo de hacerlo es exponencialmente mayor que el gasto de tiempo en la delantera y hacerlo bien la primera vez. Mientras tanto todos los veteranos experimentados cuelgan sus sombreros y una nueva generación de jóvenes machos vuelan con la actitud de "podemos arreglar cualquier cosa". Y eso, mi amigo es lo que harán durante mucho tiempo.

Es por esto que Agile finalmente me convenció porque la cascada simplemente no funciona en el software. Nunca lo ha hecho y nunca lo hará. Se trata de pequeñas iteraciones de trabajo y desarrollo de piezas. Al igual que Henry Ford nos mostró en 1900 ...

+0

La cuestión es, ¿cuándo diseñó el motor de un automóvil de forma incremental? En la arena mecánica, en realidad no diseñan las partes principales del automóvil (o sus relaciones) desde cero por métodos ágiles: simplemente han establecido patrones de diseño (que han surgido de más de un siglo de uso del motor de combustión), que podría refinarse usando principios ágiles, pero no redefinir fundamentalmente. En el software, la redefinición fundamental es común, razón por la cual los proyectos de TI más grandes (que a menudo están diseñados para integrar soluciones fragmentarias más pequeñas pero funcionales) son propensos al fracaso. – Steve

1

Lo que he experimentado es que aproximadamente el 35% del costo de desarrollo se gastará durante el primer año de mantenimiento, el 30% en el segundo año, el 25% en el 3er año. Entonces, si gasto $ 1 MM para desarrollo, estaría gastando 350K durante el primer año y así sucesivamente. Después de 3 años, el costo aumenta de 5 a 10% cada año. Por lo tanto, puede ser necesaria una reingeniería total de la aplicación después de 5 o 6 años.

Cuestiones relacionadas