En un mundo ideal, es preferible cumplir el plazo con menos errores. Pero según su experiencia, que es más preferible / aceptable:

1. Cumplir con la fecha límite pero tiene varios errores porque el desarrollador se apresura
2. Menos errores pero no cumple con la fecha límite porque el desarrollador es muy riguroso al escribir el código

La respuesta a esta pregunta depende en gran medida de los objetivos comerciales, así como del cliente.

Empresa :

Si está haciendo negocios con un cliente de nivel empresarial que está bien establecido en el mercado, son menos flexibles y no pueden adaptarse a los cambios tan rápido. Por lo tanto, la estabilidad es un requisito absoluto en la mayoría de los casos. Hay excepciones para la investigación y el desarrollo y para entrar en nuevas verticales. Los acabados más rápidos primero en algunos casos.

En general, este tipo de clientes comprende que un buen software requiere tiempo para desarrollarse y trabajará con usted para tratar de alcanzar los objetivos.

Startups :

Para una nueva startup, las reglas son radicalmente diferentes. Como startup, debe saber de inmediato si el producto que está construyendo realmente satisfará una necesidad como lo predijo su investigación de mercado. Para una startup, sacar un prototipo al mercado lo más rápido posible puede generar muchos comentarios valiosos sobre la dirección que debe seguir el producto.

También puede establecerlo como el líder del mercado, ayudándole a ganar una valiosa participación de mercado en una nueva vertical antes de que se sature de competencia.

Dado que las startups son pequeñas, flexibles y pueden adaptarse rápidamente al cambio, este modelo funciona mejor para ellas.

En resumen, hay otros factores a considerar, pero la idea principal es que cada proyecto es diferente y tendrá diferentes objetivos de calidad y tiempo para comercializar. Depende del liderazgo ejecutivo determinar una estrategia comercial efectiva que incluya un análisis exhaustivo de los costos de oportunidad de elegir un método sobre otro.

o ... 3. Cortar la funcionalidad no esencial

A veces, debido a los dulces técnicos o las características de dulces solicitados por el cliente, los plazos son difíciles de cumplir e inherentemente surge una gran cantidad de errores. Son los principios de KISS y YAGNI aplicados.

Citando este libro , "Retrabajo", lo esencial / núcleo / epicentro de su software es lo que la empresa necesita para funcionar, así como un puesto de perritos calientes puede ser un puesto de perritos calientes sin coberturas, lo que no puede recortar son los hot dogs

Renegociar

Una de las cosas más difíciles de aprender es cómo mantener felices a los clientes y, en mi experiencia, esto se puede lograr más fácilmente con iteraciones de productos más pequeñas.

A veces, los plazos exigen que el software funcione a un nivel de producción pesado desde el primer día. Los gerentes / clientes no siempre saben (que es la mayoría de las veces) lo que realmente necesitan para el software. Por lo tanto, intente reducir la funcionalidad no esencial y mantener la calidad. Al final, depende de cuán crítico será el entorno de producción, pero trate de eliminar características adicionales y ofrecer calidad. Citando nuevamente de "Rework":

Hacerlo más tarde también significa hacerlo mejor

... y también cumplir plazos con menos errores

Bueno, puedes enmarcarlo de esta manera: ¿quieres pagar por la calidad ahora o más tarde? En primer lugar, tómese el tiempo para hacerlo bien o luego dedique tiempo a solucionar todos los problemas. Yo diría que esta fase de corrección de errores posterior al desarrollo de características puede ser más costosa porque también puede ser más arriesgada y más propensa a soluciones extravagantes, ya que el código existente ya está en su lugar y probablemente no tenga la calidad suficiente.

Cumpla el plazo y presente una lista de problemas conocidos .

La gente ODIA encontrar errores, pero si se les ha dicho por adelantado, tienden a ser mucho más indulgentes.

Esto depende completamente de la situación ...

Hay muchos factores a considerar:

1. ¿Qué tan fácil es implementar parches?
2. ¿Es posible lanzar una versión básica y simplificada y luego parchear una nueva funcionalidad (caso límite) con el tiempo?
3. ¿Cuál es la cultura general de la industria del cliente para tal producto? ¿Esperan lanzamientos perfectos únicos o están acostumbrados a la idea de un sistema en evolución que puede tener errores cuando se lanza por primera vez?
4. ¿Cuánto riesgo para el negocio representa una versión inicial con errores, en lugar de cumplir con la fecha límite?

En resumen, no hay una respuesta en blanco y negro a esto. Por ejemplo: para algo como un sistema integrado que es difícil y costoso de implementar en dispositivos en el campo, puede ser mejor intentar esperar (renegociar los plazos si es posible) y sacarlo lo más libre de errores posible. Por otro lado, para algo como un gran sistema de portal web (escrito como una aplicación web) que se puede actualizar fácilmente en cualquier momento mediante la implementación de correcciones a medida que salen, puede tener más sentido lanzar una versión inicialmente dudosa, y luego parchee los problemas (y la funcionalidad del caso límite) a medida que llegue a él.

Pero al final del día, en mi experiencia, esto ha sido más una decisión comercial que una decisión tecnológica. Si se encuentra en una situación en la que perder el plazo es un gran problema, mientras que tener una versión inicial con errores no lo es (o viceversa), querrá sopesar estas cosas al tomar la decisión.

NOTA: Como programador, por supuesto, prefiero la idea de pulir un producto tanto como sea posible antes de desatarlo (diablos, prefiero no tener plazos, nunca;)). Pero de manera realista, esto no es posible en la vida real. A menudo, una versión inicial simplificada es una buena solución intermedia.

He visto a muchos PMs con miedo de decirle al cliente que no podemos cumplir con el cronograma e insistir en que enviemos con errores conocidos. Puedo decirle que cada vez que le dicen al cliente, generalmente está mucho más interesado en menos errores y una fecha límite cambiada. Le garantizo que recordarán los errores más que la fecha límite perdida a menos que la fecha límite sea absolutamente inamovible (como el inicio de la temporada de presentación de impuestos cuando esté haciendo software de impuestos) o afectará algunas otras cosas que serán muy costosas de mover (en mi humilde opinión 98% de todos los plazos no cumplen con estos criterios).

Creo que depende del error. ¿Desea retrasar un lanzamiento para corregir un error en el que la aplicación se bloquea en el momento en que se inicia en cualquier computadora? Sí definitivamente. ¿Necesita corregir un error que ocurre solo en Windows ME mientras hay luna llena? Eso probablemente puede esperar.

Si es un error crítico, es preferible hacer el número 2 sin dudas. La razón es que su reparación cuesta exponencialmente más si tiene que eliminar esa solución en una actualización.

Para actualizaciones menos críticas, puede lanzar una actualización incluida que reduzca ese costo hasta cierto punto.

En caso de duda, le digo que vaya con el n. ° 2, pero no me sorprendería recibir el rechazo de la gerencia con ese enfoque. Sospecho que los gerentes tienden a ser juzgados más por cuán buenos son para cumplir con los plazos que para no causar actualizaciones críticas innecesarias.

Ninguno. ¿Por qué no hornear calidad con su código? ¿Ser capaz de cumplir los plazos con un código de calidad? Puede eliminar menos funciones, pero si la calidad se incorpora al proceso, puede lograr ambas.

Lo que sucede ahora es que necesitará un líder de equipo o un administrador de desarrollo capacitado que pueda dar un empujón al negocio y tener una conversación sobre 2 cosas:

1. Calidad integrada en el código = 2 características menos por compilación
2. Priorizar las características más necesarias del interesado en cuanto a lo que REALMENTE necesitan.

Entonces puede concentrarse en las características de mayor valor y sacarlas con excelencia.

Bueno, en lo que respecta a las pruebas, nunca termina. se acabó pero nunca se terminó.

Vaya al lanzamiento con errores con severidad y más prioridad eliminada.

Cumplir la fecha límite con muchos errores lo hace pobre en la industria, y el cliente no volverá a visitarlo. Puede hablar con el cliente para obtener el retraso por dos o tres días.

Si miras esto de un usuario final, estaría bastante distraído si alguien prometiera hacer algo para el lunes y cuando traté de usarlo no funciona, o todo tiene errores.

Pero si nos fijamos en el lado "procesal", significa que la aplicación necesita más pruebas y es parte de la vida natural del software.

Mi mejor enfoque es tratar de hacer que las cosas funcionen de la manera en que deberían funcionar (si es un módulo importante, no preste atención a los detalles, inicie sesión en el formulario debe iniciar sesión, pero cualquiera se molestará si no muestra notificaciones después).

Esta es una pregunta que solo tú puedes responder. Depende del tipo de producto, quién es el cliente, qué exige el cliente, etc. No hay forma de que podamos dar una respuesta simple 'aob'. Es completamente dependiente de la situación.

Pero le recordaré que el costo de corregir un error después del lanzamiento es mucho mayor que repararlo antes del lanzamiento. Así que tenga en cuenta al decidir si esperar o no hasta la publicación posterior para corregir un error, ya que gastará más tiempo / esfuerzo / dinero en ello.