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

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

• Buen programador: optimizo el código. Mejor programador: estructuro 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 "único punto de entrada / único punto de salida". Es un parche sobre el problema real, que es que salir temprano podría dejar un desastre. La regla correcta es "limpiar su desorden". Una regla aún mejor es usar construcciones de datos que se limpien después de sí mismos para que el programador no tenga que preocuparse por limpiar su desorden.

• Y ahora, Dígale siempre a su cliente / usuario "sí", incluso si no está seguro. El 90% de las veces, encontrarás una manera de hacerlo.
  Esto 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 costará mucho más de lo que el cliente está dispuesto a gastar o que no tiene la menor 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á fuera de problemas.

Los clientes se convierten rápidamente en ex clientes si no puede cumplir sus promesas. Una tasa de fracaso del 10% puede parecer pequeña, pero es en el que el 10% se enfocarán sus clientes. A veces demandan cuando usted no cumple con lo que prometió. Realmente no quieres eso. En otras ocasiones, asegurarse de cumplir una promesa puede hacer que usted se declare en bancarrota, se vuelva loco o pierda a su cónyuge porque está trabajando 18 horas al día. Tú tampoco quieres eso.

Piénsalo de esta manera: ¿Qué crees que pasaría con la industria aérea si el 90% de todos los aterrizajes de aviones tuvieran éxito? ¿Crees que volver y disculparse por el 10% que se estrelló arreglaría algo?

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

El cliente te respetará si eres honesto. En el consejo de la pregunta, la persona está equivocada el 10% del tiempo. Si trabajo con alguien que se equivoca habitualmente uno de cada diez veces, no voy a confiar en él / ella en absoluto. Es un historial horrible.

Prometer a la luna y entregar una roca es una especie de enfoque de vendedor que no debe ser tolerado. Si no sabes si es posible, investiga. O bien, déles una cotización sobre la cantidad de tiempo que tendrá que tomar para estudiarlo. De esta manera, no prometes nada que no puedas cumplir, sin embargo, se te está pagando por el tiempo que te lleva investigarlo.     

Esta pregunta se ha estudiado formalmente y se aborda mediante el IEEE Computer Society / ACM Código de ética .

2.01. Brindar servicio en sus áreas de competencia, siendo honesto y franco 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 se propongan trabajar con una combinación adecuada de educación, capacitación y experiencia.

3.09. Garantice estimaciones cuantitativas realistas del costo, la programación, el personal, la calidad y los resultados de cualquier proyecto en el que trabajen o se propongan trabajar y proporcionen una evaluación de incertidumbre de estas estimaciones.

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

Ciertamente hay implicaciones comerciales y legales sobre prometer 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 compañía. Si está en sociedad con otros, pueden demandar por daños si su parte no se entrega. Los juicios pueden incluso venir de competidores.

Hay una historia desde 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 compañía de computadoras muy grande les dijo a sus clientes que también estaba cerca de ser lanzada. La mentira le costó muchos negocios a los CDC y se convirtió en una demanda en la que la gran compañía no pudo mostrar ninguna evidencia creíble de sus reclamos. El resultado fue lo que en ese momento era un gran acuerdo por $ 80 millones de dólares en 1970 (alrededor de $ 223 millones en 2012, ajustado a la inflación). Puedes leer sobre esto aquí:

enlace

Con suficiente tiempo, recursos y flexibilidad en torno a la definición de éxito, todo es posible. El ejemplo de la masa x blanca es fácil si solo quiere 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 impresionante, si requiere un largo período de desarrollo o la adquisición de un hardware más exótico, sería mejor para el cliente saberlo desde el principio y luego dirigir la conversación hacia objetivos más razonables. la mayoría de los casos.

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

Por otra parte, cuando se trata de clientes razonables con recursos razonables, a veces no hay nada peor que decirle al cliente que se debe eliminar alguna característica después de haberlo aceptado porque es posible que ya hayan huido y hayan gastado tiempo / dinero / recursos para promocionarlo o documentarlo, y ese 10% podría haber sido lo que consiguió que el proyecto se iluminara en primer lugar. Caiga en esas situaciones y acaba de perder un cliente, y lo más probable es que haya ganado una mala referencia verbal en todo un mercado.

Haciendo partidario del diablo

Siendo de una mentalidad analítica, la gente técnica puede tender a asumir que su desempeño se juzgará principalmente en base a un cuadro de calificaciones de solicitudes completadas frente a las comprometidas, pero en la práctica no es tan simple.

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 voluntad de compromiso.

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

Como no hay 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 le está dando un 100% de esfuerzo, en lugar de cumplir el 90% o el 100% de las solicitudes.

Supongamos que el cliente tiene que elegir entre dos escenarios:

Contratista A :

• Confiados en que pueden entregar todas las solicitudes
• Resultado: 90% de las solicitudes entregadas
• El cliente está satisfecho de que el contratista haya realizado un esfuerzo del 100%
• 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 confiamos en 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% incompleto de las solicitudes se debió a una 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 "sobrecomprometido" del Contratista A estaba haciendo un esfuerzo del 100% y usó esto para validar que las solicitudes restantes realmente eran difíciles, para el crédito del Contratista A.

Por otro lado, el cliente sintió que el Contratista B no estaba haciendo un esfuerzo del 100% 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 un 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.

Debes decirles que te den tiempo para crear una "solución de picos" .

Una solución de picos es un pequeño programa que, al codificarlo, le permite descubrir cómo hacerlo, 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 pico sería hacer un pequeño programa que envíe un SMS. De esa manera ya no es una incertidumbre y puede hacer más estimaciones sobre la viabilidad.

Esto es lo que documentación de Programación eXtreme dice: p>

  

Cree soluciones de picos para descubrir respuestas a problemas técnicos o   problemas de diseño Una solución de picos es un programa muy simple para explorar   posibles soluciones. Construye el pico para que solo resuelva el problema.   bajo examen e ignorar todas las demás preocupaciones. La mayoría de los picos no son   Lo suficientemente bueno para mantener, así que espera tirarlo. El objetivo es reducir.   El riesgo de un problema técnico o aumentar la fiabilidad de un usuario.   estimación de la historia. Cuando una dificultad técnica amenaza con sostener el   el desarrollo del sistema puso un par de desarrolladores en el problema para una   semana o dos y reducir 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.