Negocios tratando de tomar decisiones técnicas

A menudo nos encontramos con escenarios en los que la empresa le promete a un cliente una nueva característica. La empresa promete que la función se implementará de manera específica. Estos detalles técnicos prometidos por la empresa suelen ser deficientes. Desafortunadamente, el cliente ahora está configurado y desea que esta característica se implemente de la manera descrita por la empresa.

Al final, el negocio solo quiere que esta característica se complete sin tener en cuenta la calidad y la facilidad de mantenimiento. ¿Hay una buena manera de retroceder? ¿Cómo podemos explicarle a la empresa que es una mala idea proporcionar detalles técnicos antes de que se hayan reunido los requisitos?

Ese es un problema de organización. Si los superiores no entienden esto, no hay mucho que puedas hacer. Intenta explicar el problema a tus jefes no técnicos, pero no te sorprendas cuando no llegues a ningún lado.

Es un problema común para los desarrolladores que trabajan en empresas que no son de desarrollo que, por cualquier razón, venden software.

No es una táctica agradable, pero puedes golpearlos con evidencia. Al comienzo de un proyecto, escriba exactamente por qué fallará (porque los detalles técnicos eran deficientes) y envíelo por correo electrónico a las personas relevantes. Siga enviándolos por correo electrónico en todo momento y cuando el proyecto finalmente termine en un desastre con clientes enojados, cite esos correos electrónicos que envió en cada oportunidad. Puede generar una mala voluntad, pero realmente no hay una buena manera de tratar de solucionar un problema sistémico como ese.

Desde la perspectiva del desarrollador, este es uno de los dos sabores de falla, cuando se trata de escribir especificaciones. La otra cosa que puede suceder es cuando las ventas hacen grandes promesas y luego recurren a TI para especificar el proyecto y entregar un informe que se puede convertir en una cotización.

El problema es que, a menudo, esa es la mayor parte del trabajo. Es muy probable que el código real solo esté implementando los detalles del enfoque establecido en una especificación bien diseñada.

Al mismo tiempo, las ventas tienen dificultades para facturar preliminares como el desarrollo de especificaciones. Todavía no estamos en la cama con el cliente, y es extraño buscar dinero para averiguar cuánto dinero ganar.

Es por eso que la mayoría de los proyectos "por primera vez" con nuevos clientes terminan siendo líderes de pérdidas. Si tiene SUERTE, usa ese primer proyecto para capacitar al cliente sobre cómo ser un cliente, y puede comenzar a ganar su trasero en el segundo proyecto, o el acuerdo de mantenimiento en el primero.