refactoring - unitario - como hacer un presupuesto para un proyecto
¿Cómo hacer que los clientes independientes entiendan los costos de desarrollar y mantener productos maduros? (4)
Tengo un proyecto de aplicación web independiente en el que el cliente solicita nuevas características cada dos semanas aproximadamente. No puedo anticipar los requisitos de las próximas funciones. Entonces, cuando el cliente solicita una nueva característica, puede suceder una de varias cosas:
Implemento la característica con facilidad porque es compatible con la plataforma existente.
Implemento la función con dificultad porque tengo que volver a escribir una parte significativa de la base de la plataforma
El cliente retira la solicitud porque cuesta demasiado implementarla con la plataforma existente
Al inicio del proyecto, durante aproximadamente seis meses, todas las solicitudes de características se clasificaron en la categoría 1) porque el sistema era pequeño y ágil. Pero durante los últimos seis meses, la implementación de la mayoría de las funciones se incluyó en la categoría 2). El sistema está maduro, lo que me obliga a refactorizar y probar cada vez que quiero agregar nuevos módulos. Además, me encuentro rompiendo cosas que solían funcionar y solucionándolas (no me pagan por esto).
El cliente está empezando a expresar frustración en el momento y el costo para mí de implementar nuevas funciones. Para ellos, muchas de las solicitudes de funciones son de la misma escala que las que solicitaron hace seis meses. Por ejemplo, un cliente preguntaría: "Si le tomó 1 semana construir un sistema de tickets el año pasado, ¿por qué le lleva 1 mes construir un sistema de registro de eventos hoy? Un sistema de registro de eventos es mucho más simple que un sistema de tickets. ¡Solo debería llevarte 1 semana! " Debido a este escenario, me temo que las solicitudes de características pronto aterrizarán en la categoría 3). De hecho, ya me estoy costando mucho porque me ofrezco voluntariamente muchas horas para apoyar el proyecto.
El cliente a menudo se sorprende cuando le digo honestamente el tiempo que toma hacer algo. El cliente siempre compara mis estimaciones con los primeros meses de un proyecto. No creo que estén preparados para lo que realmente cuesta desarrollar, mantener y admitir una aplicación web madura.
Cuando trabajaba en un salario para una compañía de tiempo completo, los gerentes se mostraban más receptivos a mis estimaciones e incluso me alentaban a rellenar mis números para prepararme para lo inesperado. ¿Hay una manera de condicionar a mis clientes a pensar de la misma manera?
¿Alguien puede ofrecer consejos sobre cómo puedo continuar trabajando en este proyecto web sin pagar demasiado el costo?
Información adicional - Solo he estado trabajando de manera independiente a tiempo completo durante 1 año. Todavía no tengo los clientes de gama alta, pero poco a poco voy llegando. Estoy obteniendo clientes de mejor calidad a medida que pasa el tiempo.
¿Alguien puede ofrecer consejos sobre cómo puedo continuar trabajando en este proyecto web sin pagar demasiado el costo?
La transparencia y la comunicación son tus mejores herramientas. Si sus clientes no pueden entender por qué algo que una vez tomó una semana ahora toma tres semanas, necesita poder explicarlo mejor. Dependiendo del área de experiencia del cliente, puede encontrar una metáfora que resuene con ellos: tratar de construir un Prius en un marco de Modelo T, digamos, o intentar escribir Guerra y Paz con una máquina de escribir sin vocales. No se avergüence de sus estimaciones honestas, y no se deje intimidar. Y comparta con su cliente todo lo que pueda sobre su proceso y los obstáculos que enfrenta, incluso puede encontrar que tienen algunas sugerencias valiosas.
Con respecto al tema de la deuda técnica, y estoy de acuerdo en que este es el problema subyacente, TDD lo llevará lejos, al igual que la refactorización frecuente que permite la amplia cobertura de pruebas. Piense en qué diseño habría permitido todos sus cambios fácilmente, y trabaje hacia ese diseño, de manera incremental, con pruebas y refactorización. Tal vez tengas que pagar los costos de eso, porque la funcionalidad ya está pagada. Pero, mirando hacia el futuro, incluya los costos de refactorización en sus estimaciones, y no piense en ello como relleno. El relleno es (posiblemente) deshonesto; Mantener el diseño de su código para adaptarse a futuros cambios es un requisito honesto de su trabajo.
He estado haciendo lo mismo de manera independiente recientemente (aunque este campo es diferente), e incorporé al contrato dos cosas; a) Si se hicieran algunas adiciones / cambios importantes (en mi opinión) al marco, cada uno se contabilizó como un proyecto separado con requisitos de entrega y costos separados, b) que proporcionaría un nivel adecuado de documentación de modo que si no están contentos con mi ''estimación'', podrían probar con otra persona.
Tuve un cliente probando la opción b una vez; volvieron bastante rápido.
Me parece que tienes alguna deuda técnica en tu arquitectura; Es frágil con respecto al cambio. Además, no está claro que esté realizando las pruebas en el momento adecuado. El mejor momento para escribir sus pruebas es antes de escribir su código, permitiendo que sus pruebas funcionen como una especificación ejecutable para su código.
Una arquitectura robusta debería facilitar el cambio al fomentar el desacoplamiento entre clases. Esto debería limitar la propagación del cambio a medida que se agregan nuevas funciones. Suena como si tuvieras más acoplamiento de lo que es saludable, pero es casi imposible saberlo sin mirar el código. Sólo voy por su descripción de los síntomas.
Si este es el caso, podría valer la pena invertir algún tiempo en mejorar la arquitectura subyacente. Sea sincero con su cliente de que el sistema subyacente ya no cumple con sus requisitos y que necesita tomar algo de tiempo ahora para que los cambios futuros se puedan hacer de manera más rápida y económica. Es posible que parte de esto sea tu culpa, si es así, sé honesto al respecto. No creo que sea irrazonable esperar que el cliente seleccione la pestaña de los cambios en la arquitectura necesaria para admitir sus nuevas funciones. Sin embargo, si es parcialmente el resultado de la inexperiencia, es posible que desee comer parte del costo y atribuirlo a una experiencia de aprendizaje. Es posible que desee hacer esto de todos modos si de lo contrario perdería al cliente.