¿Es una buena práctica si un cliente se niega a escribir especificaciones y quiere que los ingenieros de software investiguen el área de negocios por sí mismo?

Depende de para qué lo contraten.

Si el cliente no está completamente involucrado en el proceso de escritura de especificaciones, huya tan rápido como pueda, porque no importa lo que se le ocurra, estará mal.

Tendrá que investigar el área comercial usted mismo de todos modos: la pregunta es en qué medida y qué sucede después de escribirlas. El problema con escribirlos de forma aislada es que es poco probable que pase la revisión del cliente la primera vez, lo que puede llevar a muchos cambios, lo que puede ser molesto.

Yo diría que es una receta para el desastre. Muchos de los mayores problemas de software en los que puedo pensar (que no fueron errores reales) fueron de personas de software que no entendían el negocio correctamente.

Lo que puede estar sucediendo aquí, lo que sería más saludable, es si el cliente dice que no quiere escribir las especificaciones por sí mismo, sino que quiere poner a los ingenieros de software directamente en contacto con los usuarios finales. Esto puede ser saludable, porque otro modo de falla es que la administración especifique el software de la forma en que piensan que funciona, no de la forma en que realmente lo hace.

Por lo tanto, es una buena idea poner a los ingenieros de software en contacto con los usuarios finales, para que, en cierta medida, los usuarios finales especifiquen el sistema. Pero el cliente debe estar en contacto con el proceso y, por así decirlo, “curarlo”.

Una buena ingeniería querría un flujo de información en todos los niveles: cliente a líder de equipo, usuarios finales a ingenieros y arriba y abajo dentro de los dos lados. No puede esperar lanzar una especificación sobre la pared, y obtener un paquete de software devuelto después de meses o años, y ser feliz.

No tengo ningún problema con los clientes que desean que traduzca sus declaraciones de lo que quieren en requisitos explícitos. Al final, sin embargo, los requisitos provienen de ellos y de su visión de lo que debe hacer el producto. Es mi trabajo expresarlos de una manera que los haga claros y comprobables. Si el cliente no está involucrado en el proceso, ¿qué estamos haciendo los dos?

No, esa no es una buena práctica. Significa que el cliente no está completamente comprometido. La coautoría de la especificación sería razonable. Hacer que los ingenieros investiguen y entiendan el área comercial es realmente bueno. Pero el cliente definitivamente debe involucrarse en decirle lo que quiere. En detalle.

Es perfectamente aceptable que un cliente solicite a los ingenieros de software que preparen las especificaciones para un trabajo además de programarlo.

Pero asegúrese de hacer que el cliente apruebe su especificación final y firme antes de comenzar a diseñar y codificar.

Y debe tener una cláusula en su contrato para cargos adicionales y extensiones de horario cuando y si el cliente cambia algo, y es una buena apuesta que lo haga.

No, en absoluto.

Si su cliente busca las mejores prácticas para una industria determinada, debe pagar por ellas. Lo más probable es que sea un producto comercial. O pagar por consultores con el conocimiento adecuado.

Nunca aceptes un trato como ese. Un cliente siempre debe firmar los requisitos; de lo contrario, su proyecto no tendrá fin. O no es un buen fin financiero para ti.

Estaría preocupado Podría funcionar si tuviera analistas muy buenos que estén acostumbrados a este tipo de actividad. Debería asegurarse de contar con el respaldo de quien lo contrata, ya que esto puede volverse político. Necesita que todo el equipo del proyecto de software, incluidas las áreas de negocios, sean todos igualmente responsables e invertidos en el éxito de un proyecto.