¿Cómo explicarle a una persona no técnica por qué la tarea llevará mucho más tiempo de lo que piensan? [cerrado]

Casi todos los desarrolladores tienen que responder preguntas del lado comercial como:
¿Por qué tomará 2 días agregar este sencillo formulario de contacto?

Cuando un desarrollador estima esta tarea, puede dividirla en pasos:

• hacer algunos cambios a la base de datos
• optimizar los cambios de DB para la velocidad
• agregar HTML frontal
• escribir código del lado del servidor
• agregar validación
• agregar javascript del lado del cliente
• usar pruebas unitarias
• asegúrese de que la configuración de SEO esté funcionando
• implementar confirmación por correo electrónico
• refactorizar y optimizar el código para la velocidad
• ...

Esto puede ser difícil de explicar a una persona no técnica, que básicamente ve toda la tarea como reunir HTML y crear una tabla para almacenar los datos. Para ellos podrían ser 2 horas como máximo.

Entonces, ¿hay una mejor manera de explicar por qué la estimación es alta para un no desarrollador?

Lo acabas de hacer en tu pregunta.

Divida la tarea en pasos individuales y proporcione estimaciones para cada uno. Esto mostrará que ha considerado todas las opciones y (con suerte) ha cubierto todas las eventualidades.

Si las escalas de tiempo son demasiado grandes, puede discutir qué partes (por ejemplo, confirmación por correo electrónico) no son necesarias en este caso con datos concretos en lugar de simplemente tratar de meter un cuarto de galón en una olla de cerveza.

Haga esto con la suficiente frecuencia y con suerte les enseñará que, por lo general, hay más en un desarrollo que a simple vista.

Enumerar las tareas es casi perfecto, pero tenga en cuenta que las tareas que tienen mucho sentido para un ingeniero tienen muy poco sentido para una persona no técnica. Por ejemplo, en la lista anterior, sé que "optimizar los cambios de la base de datos para la velocidad" puede ser una o varias tareas que consumen mucho tiempo que incluyen la creación de perfiles del código, ejecutarlo y buscar puntos lentos, revisarlo con expertos o lanzarlo a través de un conjunto de pruebas predefinidas específicas para el producto. Y luego probablemente tenga varias horas, si no días, de golpear su cabeza sobre su escritorio mientras intenta encontrar una manera de arreglar las áreas que son demasiado lentas.

Pero es posible que haya perdido la gestión de su proyecto en la palabra "DB" si no es la palabra "optimizar".

En general, expreso estas cosas a la gerencia del proyecto en términos de GRANDES pasos con palabras que describen el riesgo en términos del negocio. Tomando su lista, la resumiría de esta manera si estuviera hablando con la administración de mi proyecto:

1. Primero, hay dos partes en esto: la página web que ve el usuario y el servidor que hace el trabajo pesado. Ambas partes deben estar allí para que esta característica funcione.
2. La primera parte será crear una página web que tenga sentido para el usuario (agregue HTML front-end, agregue javascript del lado del cliente). La clave aquí es que la página web debe verse como parte de este producto, debe funcionar en todos los navegadores que admitimos y debe ser ingeniosa. Esto es lo que ve el usuario, por lo que si se ve mal, el usuario pensará que nuestro producto es malo. Desarrollar esto y luego probarlo llevará X días.
3. A continuación, debe haber cosas debajo de la página web que hagan el trabajo. En este caso, eso significa insertar una descripción de la característica aquí (se asigna a - realizar algunos cambios en la Base de datos, escribir el código del lado del servidor, implementar la confirmación por correo electrónico, agregar validación, usar pruebas unitarias). No puedo simplemente lanzar esto juntos. Si el código se desarrolla y luego se prueba, corremos el riesgo de causar daños a los datos de TODOS los usuarios. Eso significa que una cosa nueva y simple podría dañar la reputación del producto en todos los ámbitos, incluso para los usuarios que no usan esta característica en particular. Nuestras prácticas de desarrollo cubren esto: hacemos muchas pruebas para asegurarnos de que eso no suceda, pero eso significa que tengo que planificar a tiempo para probarlo correctamente. Eso me llevará días.
4. La velocidad es un gran problema en nuestro producto. Si las cosas no suceden rápido, los usuarios pensarán que el producto no es bueno. Entonces, después de escribir todo esto, necesito revisar el trabajo y asegurarme de que esté a la par en términos de rendimiento. Esto es un gran problema en la web: si las personas ven que un sitio se vuelve lento, rápidamente recurrirán a un producto diferente para satisfacer la misma necesidad, porque es realmente difícil ver la diferencia entre lento y roto. Ese tipo de trabajo generalmente toma Z días (optimice los cambios de DB para la velocidad, refactorice y optimice el código para la velocidad)

Evitaría cualquier estimación que sea menos de medio día. Tendrán que confiar, en algún nivel, en que sabes de lo que estás hablando. Y si realmente piensan que solo serán 2 horas, invítelos a sentarse con usted durante 2 horas mientras los explica exactamente cómo se ven las 2 horas en la vida de un desarrollador de SW, luego realice una clase de codificación 101 para aproximadamente 2 horas, para mostrar exactamente lo que se debe tener en cuenta para comenzar a resolver el problema.

Lo más importante es lo siguiente:

• Compre hablando más sobre la percepción del cliente y el uso del producto, está llegando a hablar su idioma, el idioma de $$, el punto es que si el código se piratea de una manera mala, eventualmente perderá negocios, si no en esta característica, luego en alguna característica posterior cuando las malas prácticas de desarrollo han hecho imposible extender el código.
• Establece una secuencia de eventos. La siguiente pregunta no técnica será "si tenemos más desarrolladores que usted, ¿ocurriría esto más rápido? Si es así, si tomará 40 horas para lograrlo, ¿pueden hacerlo 40 personas esta tarde?" La respuesta, por supuesto, es "¡NO! ¿ESTÁS FUERA DE TU MENTE?". Pero esa no es la mejor. La mejor es que hay una secuencia lógica de pasos aquí. La cosa B no se puede hacer hasta que la cosa A esté en su lugar (si no ha escrito ningún código, realmente no puede optimizarlo o probarlo ...). Sin embargo, las cosas A y A 'podrían hacerse juntas, por lo que si pudieran ahorrarle a ese tipo inteligente de allí, podrían reducir el tiempo de una semana a 4 días, y si pueden garantizar el increíble apoyo de la prueba, entonces probablemente podrían llegar a 3 días. Ahí'
• Concéntrese en el riesgo y esté preparado para que le digan que algunos riesgos valen la pena en este momento. Para eso se paga mucho dinero a los hombres de negocios: averiguar qué riesgos vale la pena correr. Por ejemplo, si la velocidad de comercialización pesa poco rendimiento porque su empresa tiene suficiente efectivo en la mano para organizar una cantidad ridícula de servidores a corto plazo, entonces se le puede pedir que omita todo eso en el paso 4 (la optimización del código / base de datos ) Ese es su derecho: es solo su trabajo explicar los riesgos inherentes a esa decisión.
• Sin embargo, si no confía en estas personas, obtenga una confirmación por escrito: no tiene que ser confrontacional, solo un correo electrónico rápido que diga "esto es lo que creo que discutimos, esto es lo que no estoy haciendo, aquí está el riesgo. Voy a hacerlo ahora, así que avíseme si no está de acuerdo ... si no tengo noticias suyas, asumiré que esta es la forma correcta de proceder ". Dado que la gestión del producto puede ser el centro de la pérdida de memoria a corto plazo, esto es bastante útil para todos.

Hay un dicho, "No puedes meter diez libras de (basura) en una bolsa de cinco libras". Su trabajo es demostrar que la tarea es diez libras y están pidiendo tenerla en un plazo de cinco libras.

Lo único que falta son las estimaciones de tiempo. Ponga una estimación de tiempo en cada tarea y muestre cómo todas estas cosas se suman a la estimación que proporciona. No permita que ningún cálculo sea superior a 4 horas. Si tiene alguna tarea en la que dice "un día" o "10 horas", divídala en subtareas más pequeñas.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

Ahora tiene una factura detallada de los costos. En total, eso suma hasta 27 horas de trabajo.

Ahora puede mostrar esto a su cliente y decir "Estas son las cosas que deben hacerse, con el costo de cada una". Use la palabra "costo", porque el tiempo ES un costo, y la gerencia entiende los costos. Explique que posiblemente podría eliminar las dos tareas de optimización al final, pero que tendrán un efecto negativo en el futuro, y son solo el 15% de la estimación total.

También asegúrese de explicar de manera realista cuáles son sus horas / día. Por ejemplo, si se le pide que brinde soporte técnico, o mantenga bases de datos, o lo que sea, calcule eso en su estimación. No diga "Bueno, puedo hacer 7,5 horas al día de buena codificación" porque probablemente no pueda. Probablemente sea más como 5 o 6.

Luego, lo más importante, rastrea tu progreso. Digamos que puedes hacer 5 horas por día de codificación. Entonces deberías poder eliminar las dos primeras tareas (en mi ejemplo) el lunes, terminar la tercera y comenzar la cuarta el martes, y así sucesivamente. Haga una lista de verificación que muestre esto, para que pueda mostrárselos el miércoles cuando vengan y diga "¿Cómo va todo para el final del viernes?"

Vea mis diapositivas para mi charla Prevención de crisis: estimación de proyectos y seguimiento que funciona que di en OSCON hace unos años. Mire la diapositiva 21, "Planificación de la semana". También hay un gráfico de velocidad de muestra .

Pregúntales:

¿Como lo harias? ¿Qué módulos cambiarías? ¿Cuántas líneas de código? ¿Cuáles son las implicaciones de seguridad? ¿Algún cambio en el esquema de la base de datos? Si realiza algún cambio en la base de datos, ¿cuántos archivos están afectados? ¿Cuánto tiempo llevó agregar el último formulario? ¿Cuál es el promedio (media aritmética) para agregar un formulario? ¿Cuál fue el más largo? Calculo que tomará un minuto menos que el más largo. Si no sabe cuánto tiempo tomó agregar las últimas N formas, entonces esta estimación solo se garantiza que sea precisa en un orden de magnitud.

Podría decirle que les explique que su software es como una máquina de 100 toneladas con 10,000 partes diferentes, muchas de las cuales están conectadas de manera complicada. Instalar una pieza de 1 pulgada en esta máquina requiere algo de ingeniería, para que no se rompa la máquina, PERO la mejor respuesta es:

Si tuviera una mejor arquitectura de código, ¿facilitaría tareas como esta? Y la respuesta es que la mayoría de los equipos de software no son buenos arquitectos (porque simplemente no han acumulado toneladas de plantillas genéricas y arquitectónicas o no son maestros del dominio del problema lo suficiente como para anticipar cada problema) y no siempre son buenos ingenieros , por lo que no se sienten seguros al hacer estimaciones o hacer promesas.

Al igual que le tomó al siglo XX acumular una buena arquitectura y la ingeniería para construir grandes edificios, las herramientas para la ingeniería de software simplemente no han llegado a la corriente principal. Se están desarrollando: se necesita una nueva mentalidad. Vea el Código Zen en wiki.hackerspaces.org/Hacking_with_the_Tao.