Negocio tratando de tomar decisiones técnicas

13

A menudo nos encontramos con escenarios en los que la empresa le prometió a un cliente una nueva característica. El negocio prometerá que la característica se implementará de una manera específica. Estos detalles técnicos prometidos por el negocio son generalmente pobres. Desafortunadamente, el cliente ya está configurado y desea que esta función se implemente de la manera descrita por la empresa.

Al final, el negocio solo quiere que esta función se complete sin importar la calidad y la capacidad de mantenimiento. ¿Hay una buena manera de empujar hacia atrás? ¿Cómo podemos explicar a la empresa que proporcionar detalles técnicos antes de reunir los requisitos es una mala idea?

    
pregunta nivlam 01.09.2010 - 22:23

2 respuestas

5

Eso es un problema de organización. Si los superiores no entienden esto, no hay mucho que puedas hacer. Trate de explicar el problema a sus jefes no técnicos, pero no se sorprenda cuando llegue a ninguna parte.

Es un problema común para los desarrolladores que trabajan en compañías que no son de desarrollo y que, por cualquier motivo, venden software.

No es una táctica placentera, pero puedes simplemente pegarlos con evidencia. Al inicio de un proyecto, escriba exactamente por qué va a fallar (porque los detalles técnicos eran deficientes) y envíelo por correo electrónico a las personas relevantes. Continúe 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 algo de mala voluntad, pero en realidad no hay una forma buena de intentar solucionar un problema sistémico como ese.

    
respondido por el Fishtoaster 01.09.2010 - 22:46
3

Desde la perspectiva del desarrollador, este es uno de los dos tipos de fallas, cuando se trata de escritura de 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 es la mayor parte del trabajo. Es muy probable que el código real esté implementando los detalles del enfoque presentado en una especificación bien diseñada.

Al mismo tiempo, a las ventas les resulta difícil facturar los preliminares, como el desarrollo de especificaciones. Aún no estamos en la cama con el cliente, y es raro pegarle dinero por dinero para calcular la cantidad de dinero por el que golpearlo.

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

    
respondido por el Dan Ray 01.09.2010 - 22:54

Lea otras preguntas en las etiquetas