¿Cómo abordar el viejo "esto será solo una pequeña aplicación"? ¿Sí claro?

Ok, me he encontrado con esto muchas veces, pero este es el peor de los casos, un poco exagerado.

Un cliente dice "oye, ¿puedes hacernos este pequeño módulo para hacer esta pequeña tarea"?
Yo: "Claro que no hay problema".

Por lo tanto, en función de los presupuestos y las limitaciones, etc., me salteo parte de la arquitectura y me sumerjo y hago que no sude.

Luego piden otro módulo. Y otro. Y algunas mejoras. Y todo esto sucede muy lentamente, fíjate, durante años. Y antes de que te des cuenta, tienes esta aplicación monstruosa que está terriblemente diseñada.

¿Qué haces cuando te piden que hagas algo pequeño? No sabe si seguirá creciendo ... si el cliente seguirá pidiendo adiciones (y tampoco lo hacen).

No puedes sobre-diseñar la cosa, porque después de todo es solo una pequeña aplicación, y se irán a otro lado si dices (en eso sé toda la voz) "Bueno, por si acaso, vamos a diseñar esta cosa en capas con la parte superior -o-the-line seguridad y separación de preocupaciones. De hecho, vamos con una herramienta de inyección de dependencia que realmente hará que esto sea fantástico, bla, bla, bla ".

Dirán "sí, claro" e irán a otra persona.

El presupuesto, el tiempo y la percepción son tan importantes como la arquitectura de la aplicación misma.

¿Cómo debe abordarse esto?

Supongo que la pregunta realmente se reduce a "Cuando no tienes toda la información para el resultado final de lo que parece ser una pequeña aplicación, cómo evitar (o mitigar) la toma de decisiones arquitectónicas y de diseño desde el principio será completamente ¿Inapropiado después?

Me he encontrado con algunos de estos y lo que normalmente hago es exactamente lo que hiciste, sumergirte y hacerlo.

Cuando regresan por más, significa que su modelo de negocio está funcionando y que deberían estar dispuestos a invertir un poco más. Ahí es cuando los siento (generalmente el tercer módulo según la complejidad) y les cuento las malas noticias.

Pondré todo sobre la mesa, ofreceré rehacer todo, incluido el último módulo, y le diré cuánto costará. Por lo general, tendrán un poco de impacto al comienzo, pero si tienes una buena relación de trabajo y tus cosas funcionan, no debería ser un gran problema.

Sin embargo, asegúrese de que entiendan tres cosas:

1. Si realmente no quieren molestarse con una reescritura completa, igual harás el tercer módulo. Puede llevarle unas horas más y se lo facturará. Recuérdeles que realmente deberían pensar en hacer una reescritura en el futuro, porque cuanto más esperen, más les costará.

2. Realmente les costará más conseguir que alguien más lo haga. La nueva persona tiene que rediseñar todo con una comprensión mínima de sus necesidades y peculiaridades, lo que significa un tiempo de reescritura adicional y el riesgo de que no haga un trabajo tan bueno.

3. Que no estás tratando de ganar dinero rápido. La cosa necesita un rediseño.

Por cierto, si su hábito de facturación es algo así como la mitad ahora, la mitad cuando está hecho, podría considerar ofrecerles condiciones de pago extendidas. Cámbielo a la mitad ahora y divida el saldo durante el período en que trabajará en él. Eso podría disminuir la pizca si tienen problemas de presupuesto.

Simplemente hazle una pequeña aplicación y que te paguen por ella.

En mi experiencia, es convincente invertir más tiempo al principio de lo que realmente se necesita, en caso de que el cliente quiera más. Pero tiene que sopesar el esfuerzo al hacerlo (se le paga por ello) frente a la posibilidad de que realmente ocurran todos estos cambios adicionales. Toda la aplicación podría ser reemplazada completamente después de un año.

Y al invertir tiempo en la arquitectura inicial, puede sentir que se hace un favor. Pero realmente, solo le haces un favor al cliente haciendo que los otros módulos sean más baratos para él.

Simplemente facture a su cliente un poco más por cada módulo sucesivo y refactorice el proyecto inicial paso a paso, pero siempre solo para satisfacer las necesidades del cliente.

Las respuestas anteriores son buenas y, si soy honesto, lo que probablemente haría. Dicho esto, estoy un poco incómodo con este enfoque, ya que está tomando decisiones que pertenecen adecuadamente al cliente, basándose en la suposición de lo que quiere (y el deseo de conseguir el trabajo)

No puedo evitar sentir uno debe hacer es ser ser honesto con el cliente y darle a la opción: 1. Puedo hacer esto de manera rápida y (relativamente) barato ahora. Será genial, funcionará, pero las mejoras futuras costarán un poco más incrementalmente 2. Puedo pasar más tiempo por adelantado, lo que costará un poco más y no agregará ningún beneficio real para los usuarios, PERO le ahorrará dinero a largo plazo si necesita agregar nuevas funciones.

Idealmente, podrá darles algunas cifras aproximadas de tiempo / costos, de lo contrario, la conversación podría ser demasiado académica, pero aprecio que llegar a estos números también puede requerir un esfuerzo. Al menos, enmarcar la discusión en términos de proyectos anteriores facilitaría la vida del cliente (y hacer que la vida del cliente sea más fácil debería ser una prioridad :-))

Los comentarios que otros han hecho sobre tener una buena relación de trabajo son acertados, pero usted puede comenzar ese proceso siendo honesto. Si el cliente es del tipo con el que ni siquiera puede tener esa conversación, ahora podría ser el momento de preguntarse cuánto necesita este trabajo ...

Trataría cada una de estas "iteraciones" como un proyecto separado. Debería cerrar estos proyectos cuando se complete cada pequeño módulo o adición. Luego, cuando quieran algo más, redactan el papeleo. Y a medida que pasa el tiempo, el software se vuelve más caro ... lo que significa que está cobrando más por cada pequeño proyecto.

Es una forma de verlo, en lugar de uno ... Proyecto LONGGGGGG.

¿Cómo evita (o mitiga) la toma de decisiones arquitectónicas y de diseño desde el principio que serán completamente inapropiadas más adelante?

No se puede . Los programadores no son psíquicos. Si bien podemos predecir cosas simples o ver mejoras en la interfaz de usuario, realmente no podemos codificar más allá de lo que no sabemos que el cliente podría desear más tarde (¿ves la locura allí?).

Su pregunta mencionó que tenía procesos comerciales, pero no estoy seguro de si son buenos procesos. Aquí hay algunos consejos:

• Requerir todos los cambios y adiciones firmados por escrito y con un presupuesto.
  • Porque tienes facturas que pagar
  • La parte escrita y firmada se asegura de que sea lo que realmente quieren y reduce el 90% de las cosas privilegiadas en las que los clientes cambian de opinión a mitad de camino durante el proyecto

Su producto cubierto

Nos pasa a todos. Reconstruir desde cero suele ser una idea terrible, especialmente teniendo en cuenta que se volverá a hacer en el futuro.

En cambio, contrataría los cambios que solicitó el usuario. Agregue tiempo adicional para cada función, utilizando el tiempo original para trabajar en la función y el tiempo adicional para mejorar la arquitectura general, una pequeña mejora a la vez. El objetivo no es "arreglar" por completo la arquitectura en un solo contrato, sino más bien astillarla lentamente con el tiempo.

Mejore lentamente la iteración del código por iteración, centrándose en las partes que realmente importan.