¿Cómo se determina qué características son suficientes para el inicio? ¿Deberíamos lanzar con la "funcionalidad básica" sin extras? ¿O deberíamos agregar "campanas y silbatos"?Determinar qué características son suficientes para iniciar
¿Cómo decides? ¿Es cierto que podemos "quemarnos" de la exposición repentina, o la exposición repentina es más bien un mito, y la exposición es lenta y gradual.
Sus sugerencias son bienvenidas.
Si tiene la suerte de poder elegir, libérelo tan pronto como tenga una rutina de instalación y una sola característica útil que funcione.
Suelte temprano, suelte con frecuencia, deje que sus usuarios le digan lo que quieran, mire 37Signals el poster boys of small is beautiful.
Estoy de acuerdo, ¡solo asegúrese de que esté PROBADO! Mejor pequeño con promesas que grande con errores, y no cumpliendo con su parte del trato.
Agregar BETA a su logotipo no hace que los errores sean más fáciles de aceptar.
tiene razón, las pruebas son importantes, pero solo para los errores de código, ya que los desarrolladores a menudo no tenemos idea de lo que los usuarios quieren, como lo que necesitan. – MrTelly
En mi experiencia, generalmente es mejor lanzar tan pronto como haya pulido la funcionalidad principal. Y si una característica es muy importante para un cliente o para el público objetivo, ya no pertenece a los botones & y debería considerarse una característica central, sin importar cuán fácil sea de implementar o qué tan poco agregue al producto.
Como la mayoría de las cosas, mi respuesta es 'depende' ...
¿Cuál es el propósito de su software? Si se trata de una aplicación dirigida a un conjunto específico de usuarios con necesidades específicas, entonces debe asegurarse de cumplir con esas necesidades para que las personas puedan usar su sistema (recuerde que la mayoría de las personas cree que una vez mordido, dos veces tímido) no tendrá una segunda oportunidad). ¿Comprarías un auto que no girara a la izquierda?
Si su aplicación es más general, y está apuntando a una porción determinada de usuarios de una base más amplia (generalmente usuarios expertos) para ayudar a evolucionar su aplicación a lo largo de líneas ágiles, luego libérese temprano y con frecuencia. Muchos de estos tipos de sistema no planifican lanzamientos en función del tiempo, sino de las características, es decir, la versión 2.1 se lanzará cuando todos los tickets asignados a 2.1 estén marcados como completos o descartados.
También diría que depende del mercado. No lanzaría un producto sin una característica asesina (incluso simple). Incluso en los primeros lanzamientos, tienes que construir cierta reputación.
Hay dos dogmas de mantenerse alejado de:
no lo suelte hasta que haya terminado.
y
lanzamiento tan pronto como se tiene nada, no importa cuán pequeño.
Me gusta este último enfoque, pero debe tomarse con un poco de sentido común. Hay una sobrecarga para cualquier versión, dependiendo de su organización y producto.
No me malinterpreten: se publica temprano y a menudo tiene un gran rendimiento ventajas, sobre todo porque nunca cumplimos con los requisitos del negocio, pero debe ponderar esos beneficios con los costos reales de un lanzamiento. Esta es una de las razones por las que me gustan las entregas internas intercaladas entre las versiones "reales": tienen costos más bajos (si no son cero), pero mantienen el proceso de desarrollo avanzando honestamente.
Al final, supongo que termino con la respuesta clásica del consultor: "¡Depende!"
¿Es cierto que podemos "quemarnos" de la exposición súbita, o es una exposición repentina en lugar de un mito?
¿Has visto las noticias en la prensa sobre el lanzamiento de Cuil.com? Sus comunicados de prensa lo promocionaban como un motor de búsqueda que mataría a Google, aunque las búsquedas simples produjeron resultados asombrosamente malos. (Por ejemplo, la búsqueda de "COBOL" le indicó que no había resultados para COBOL.) El repentino estallido de tráfico de los anuncios también abrumaba a sus servidores. Diría que se quemaron por la exposición repentina que experimentaron en el lanzamiento.
Algunas personas lo llaman lanzamiento de "Estilo de Hollywood" porque es similar a la forma en que se lanzan las películas. Este estilo de lanzamiento ofrece algunos beneficios que no siempre obtiene de una acumulación gradual de usuarios. Sin embargo, la mayoría de estos beneficios se ven compensados por el hecho de que las primeras impresiones son muy importantes y la complejidad habitual de un producto hace que sea muy fácil tener un error y dar a la mayoría de los posibles usuarios una mala primera impresión.
La pregunta es, inicie ¿qué?
Si está haciendo un software interno, quiere involucrar a los usuarios lo antes posible, por lo que darles algo rápido es una buena idea.
Si está haciendo código abierto, libérelo temprano y con frecuencia, con una hoja de ruta para el desarrollo futuro.
Si está haciendo el software shrinkwrap, necesita dar a los usuarios algo bueno por su dinero. No cuente con cobrarles por la actualización que realmente hace que el software sea útil, a menos que sea una empresa grande y establecida que ya lo haga. A menos que seas conocido como la fuente principal de ese tipo de software, nadie se molestará en pagarte dos veces después de haber sido quemado una vez.
Si está haciendo servicios web, necesita tener algo útil cuando lo libere. Puede ser pequeño, pero debe darle al usuario un motivo para regresar. De lo contrario, es "Foo.com no tiene nada bueno, no vayas allí", incluso después de haber implementado los elefantes bailarines o lo que sea. Debe dejar al usuario sintiéndose bien con respecto a su sitio, e idealmente curioso para ver qué está haciendo a continuación. Si vas a lanzar con un toque especial, asegúrate de que un montón de cosas funcionen.
Si está haciendo incrustado, se libera cuando el software está lo suficientemente cerca de perfecto, y todos han cerrado sesión, y no un momento antes.
Habría sido una mejor pregunta para http://programmers.stackexchange.com en estos días. –