¿Debería prometer entregar una característica que no está seguro si es implementable?

En un artículo de HN , me encontré con el siguiente consejo:

Siempre diga "sí" a su cliente / usuario, incluso si no está seguro. El 90% del tiempo, encontrarás una manera de hacerlo. El 10% del tiempo, volverás y te disculparás. Pequeño precio a pagar por un importante crecimiento personal

Pero siempre he pensado que uno debería hacer un análisis de factibilidad antes de hacer cualquier tipo de promesa a un cliente / usuario, para que no se confundan en ningún momento. ¿En qué circunstancias, entonces, deberían aplicarse los consejos anteriores?

Esta es la segunda pregunta en breve sucesión activada por ese artículo.

• Buen programador: optimizo el código. Mejor programador: estructurar datos. Mejor programador: ¿cuál es la diferencia?
  Hay otro nombre para esto: optimización prematura.

• Nunca use salidas tempranas.
  Esa es la regla del "punto de entrada único / punto de salida único". Es un parche sobre el problema real, que es que salir temprano podría dejar un desastre. La regla correcta es "limpia tu desorden". Una regla aún mejor es usar construcciones de datos que se limpien después de sí mismas para que el programador no tenga que preocuparse por limpiar su desorden.

• Y ahora, siempre diga "sí" a su cliente / usuario, incluso si no está seguro. El 90% del tiempo, encontrarás una manera de hacerlo.
  Este también es un consejo increíblemente malo.

A veces, a su cliente se le debe decir que no, o "¿en qué milenio quiere esto?" No prometa algo que destruirá su arquitectura, que le costará mucho más de lo que el cliente está dispuesto a gastar, o que no tiene idea de cómo lograrlo. Conoces la tecnología, no el cliente. Si no sabes cómo hacerlo, no digas que puedes hacerlo. Si no está seguro, diga que necesita tiempo para investigar si es posible. Es mejor ser honesto y te mantendrá alejado de los problemas.

Los clientes se convierten rápidamente en ex clientes si no puede cumplir sus promesas. Una tasa de falla del 10% puede sonar pequeña, pero es en lo que se centrará el 10% de sus clientes. A veces demandan cuando no cumple lo que prometió. Realmente no quieres eso. Otras veces, asegurarse de cumplir una promesa puede llevarlo a la bancarrota, volverse loco o perder a su cónyuge porque trabaja 18 horas al día. Tú tampoco quieres eso.

Piénselo de esta manera: ¿Qué cree que le sucedería a la industria de las aerolíneas si el 90% de todos los aterrizajes de aviones fueran exitosos? ¿Crees que regresar y disculparte por el 10% que se bloqueó solucionaría algo?

Sería mejor decir "Creo que se puede hacer". o "Lo comprobaré y te responderé". He tenido momentos en los que he dicho que no o he propuesto algo en contra. Si el cliente quiere "una aplicación basada en un navegador que funcione sin estar conectado a Internet y use retroalimentación táctil", probablemente sea posible. Pero es costoso y sería más útil discutir cuáles son las necesidades reales.

El cliente lo respetará si es honesto. En el consejo de la pregunta, la persona está equivocada el 10% del tiempo. Si trabajo con alguien que habitualmente se equivoca una de cada diez veces, no voy a confiar en él en absoluto. Esa es una trayectoria horrible.

Prometer la luna y entregar una roca es una especie de enfoque de vendedor que no debe tolerarse. Si no sabe si es posible, investigue. O bien, deles una cotización sobre la cantidad de tiempo que tendrá que tomar para investigarlo. De esta manera, no promete nada que no pueda entregar, pero se le paga por el tiempo que le lleva investigarlo.

Esta pregunta ha sido estudiada formalmente y es abordada por el Código de Ética de la IEEE Computer Society / ACM producido conjuntamente .

2.01. Brinde servicio en sus áreas de competencia, siendo honesto y directo sobre cualquier limitación de su experiencia y educación.

3.04. Asegúrese de que estén calificados para cualquier proyecto en el que trabajen o propongan trabajar mediante una combinación adecuada de educación, capacitación y experiencia.

3.09. Asegure estimaciones cuantitativas realistas de costo, programación, personal, calidad y resultados en cualquier proyecto en el que trabajen o propongan trabajar y proporcione una evaluación de incertidumbre de estas estimaciones.

5.05. Asegure estimaciones cuantitativas realistas de costo, programación, personal, calidad y resultados en cualquier proyecto en el que trabajen o propongan trabajar, y proporcione una evaluación de la incertidumbre de estas estimaciones.

Ciertamente, existen implicaciones comerciales y legales sobre la promesa de algo que no puede cumplir. Por lo general, estos provienen de que el cliente se va a otro lado, se niega a pagar o demanda a su empresa. Si está asociado con otros, pueden demandar por daños y perjuicios si su parte no se entrega. Las demandas pueden incluso provenir de competidores.

Hay una historia de los primeros días de las supercomputadoras en las que Seymour Cray y un equipo de Control Data Corporation estaban cerca de lanzar un producto, y otra gran empresa de computadoras le dijo a sus clientes que también estaba cerca del lanzamiento. La mentira le costó a CDC muchos negocios y se convirtió en una demanda en la que la gran empresa no pudo mostrar ninguna evidencia creíble de sus reclamos. El resultado fue lo que en ese momento era un gran acuerdo por un valor de $ 80 millones de dólares en 1970 (alrededor de $ 223 millones en 2012, ajustado por la inflación). Usted puede leer sobre ello aquí:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

Con suficiente tiempo, recursos y flexibilidad en torno a la definición de éxito, todo es posible El ejemplo de masa x blanca es fácil si solo desea una precisión superior al 50% y tiene la ubicación geográfica del usuario y un poco de datos estadísticos.

La primera pregunta real en la mayoría de los proyectos no es si algo es posible, sino si es razonable dado un cierto conjunto de circunstancias.

¿La característica agrega suficiente valor para justificar el gasto del intento?

Incluso si la idea fuera bastante sorprendente, si requiere un largo período de desarrollo o la adquisición de un hardware más exótico, sería mejor que el cliente lo supiera por adelantado y luego dirija la conversación hacia objetivos más razonables en la mayoría de los casos.

Si alguien está lo suficientemente loco como para darle un cheque en blanco y no hay fecha límite, entonces dígale que todo es posible, solo dígale que tiene que inventar y distribuir varias de las tecnologías involucradas para alcanzar el objetivo en el camino.

Por otro lado, cuando se trata de clientes razonables con recursos razonables, a veces no hay nada peor que decirle al cliente que se debe cortar alguna característica después de que haya aceptado, ya que es posible que ya se hayan escapado y hayan gastado tiempo / dinero / recursos promoviendo o documentarlo y ese 10% podría haber sido lo que hizo que el proyecto fuera aprobado en primer lugar. Entra en esas situaciones y acabas de perder un cliente, y lo más probable es que hayas obtenido una mala referencia verbal en todo un mercado.

Jugando abogado del diablo

Al tener una mentalidad analítica, la gente técnica puede asumir que su desempeño se juzgará principalmente en función de un cuadro de mandos de solicitudes completadas frente a las comprometidas, pero en la práctica, no es tan sencillo.

Incluso antes de que comience el desarrollo, los clientes comienzan a formarse opiniones sobre el rendimiento de un equipo en función de su nivel de confianza y disposición para comprometerse.

Parte de la razón de esto es que los clientes pueden tener dificultades para evaluar si la duda de un contratista para comprometerse se debe a la gran dificultad de la solicitud o la falta de capacidad del contratista.

Como no existen criterios absolutos para medir la dificultad de una solicitud, a menudo lo que es más importante para el cliente es confiar en que el contratista está dando el 100% de esfuerzo, en lugar de si se cumplen el 90% o el 100% de las solicitudes.

Supongamos que el cliente tiene que elegir entre dos escenarios:

Contratista A :

• Confiados en que pueden cumplir con todas las solicitudes
• Resultado: 90% de las solicitudes entregadas
• El cliente está satisfecho de que el contratista haya realizado el 100% del esfuerzo
• El cliente percibe que las solicitudes incompletas se debieron a problemas imprevistos, que probablemente están fuera del control de los contratistas.

Contratista B :

• Se compromete a entregar el 90% de las solicitudes. No estoy seguro de que puedan cumplir con el 10% restante
• Resultado: 90% de las solicitudes entregadas
• El cliente está decepcionado de que el contratista no haya intentado completar el otro 10% de sus solicitudes
• El cliente asume que el 10% de las solicitudes incompletas se debieron a la falta de esfuerzo o capacidad del contratista

En ambos escenarios, se entregó el mismo número de solicitudes; sin embargo, el cliente sintió que el Contratista "comprometido" estaba haciendo un esfuerzo del 100% y usó esto para validar que las solicitudes restantes eran realmente difíciles, para crédito del Contratista A.

Por otro lado, el cliente sintió que el Contratista B no estaba dando el 100% de esfuerzo y su incapacidad para completar todas las solicitudes se debió a la falta de esfuerzo o capacidad del Contratista B.

Descargo de responsabilidad: no estoy abogando por el compromiso excesivo como estrategia; esto es solo una observación de una posible situación del mundo real en la que el compromiso excesivo podría tener resultados positivos.

Debe decirles que le den tiempo para crear una "solución de espiga" .

Una solución puntual es un pequeño programa que, al codificarlo, le permite descubrir cómo hacer, o incluso si es posible, algo que está creando incertidumbre en un proyecto.

Por ejemplo, suponga que nunca ha enviado SMS mediante programación, pero de alguna manera sabe que es posible. Una solución de punta sería hacer un pequeño programa que envíe un SMS. De esta manera, ya no es una incertidumbre y puede hacer más estimaciones sobre la viabilidad.

Esto es lo que dice la documentación de programación de eXtreme :

Cree soluciones de punta para encontrar respuestas a problemas técnicos o de diseño difíciles. Una solución de pico es un programa muy simple para explorar posibles soluciones. Construya la espiga para abordar solo el problema bajo examen e ignore todas las demás preocupaciones. La mayoría de los picos no son lo suficientemente buenos como para mantenerlos, así que espera tirarlos. El objetivo es reducir el riesgo de un problema técnico o aumentar la fiabilidad de la estimación de una historia de usuario. Cuando una dificultad técnica amenaza con retrasar el desarrollo del sistema, ponga a un par de desarrolladores en el problema durante una semana o dos y reduzca el riesgo potencial.

Según mi experiencia, cuando un usuario solicita algo, debe pedirle una especificación detallada de lo que el usuario realmente quiere o necesita. La mayoría de las veces, nunca volverá a escuchar sobre la solicitud.