¿Cómo convencer a la gerencia de tirar un prototipo?

Me encanta la creación de prototipos como una forma rápida y efectiva de poner una interfaz de usuario frente a un usuario.

Muchas veces, sin embargo, la administración se pone en el camino, y el prototipo es arrastrado pateando y gritando al desarrollo de la corriente principal.

¿Cómo manejas a la gerencia para que no haga esto?

Use una herramienta como Microsoft SketchFlow , o haga su prototipo en algún otro idioma o plataforma, haciendo que sea casi imposible integrarse en el desarrollo principal.

También hay un ensayo de Joelonsoftware sobre mostrar capturas de pantalla y prototipos, donde hace que los aspectos no implementados y no trabajados aparezcan evidentemente rotos / no implementados, dejando en claro dónde aún queda trabajo por hacer.

Corolario importante dos. Si le muestra a un no programador una pantalla que tiene una interfaz de usuario que es 100% hermosa, pensarán que el programa está casi listo.

...

¿Qué puedes hacer al respecto? Una vez que comprenda el secreto de Iceberg, es fácil trabajar con él. Comprenda que cualquier demostración que haga en una habitación oscura con un proyector tendrá que ver con píxeles. Si puede, cree su interfaz de usuario de tal manera que las partes sin terminar se vean sin terminar. Por ejemplo, use garabatos para los iconos en la barra de herramientas hasta que la funcionalidad esté allí. A medida que crea su servicio web, es posible que desee considerar excluir las funciones de la página de inicio hasta que se creen esas funciones. De esa manera, la gente puede ver la página de inicio pasar de 3 comandos a 20 comandos a medida que se crean más cosas.

Por lo tanto, intente hacer sus prototipos en Photoshop en lugar de Visual Studio, o algo por el estilo.

No prototipos con código de trabajo. Prototipo con lápiz y papel, o un equivalente de software .

El uso de Mockups se siente como un dibujo, pero como es digital, puedes modificarlo y reorganizarlo fácilmente. Los equipos pueden idear un diseño e iterar sobre él en tiempo real en el transcurso de una reunión.

El uso del papel tiene el beneficio de que los miembros del equipo pueden participar fácilmente, y todos entienden que es solo una hoja de papel en blanco. Esto hace que parezca menos precioso.

Nunca comprometa la calidad de su código.

Escribir código basura es una economía falsa.

Como otros carteles han sugerido, puede lograr esto utilizando herramientas específicas para maquetas.

Sin embargo, hay diferentes razones para construir prototipos. A veces puede mostrar lo que necesita sin escribir código, pero a menudo este no es el caso. Una parte interesada puede querer que demuestre la viabilidad técnica de una característica.

Desarrolle lo más delgado posible para demostrar la característica / demostrar el concepto. Deja de lado cualquier otra cosa.

Para una función de IU, asegúrese de no desarrollar nada en el servidor; no lo toque en absoluto. Desarrollar de nuevo simulacros / falsificaciones incorporadas.

Si necesita hacer un esfuerzo para hacer que la interfaz de usuario se ajuste al estilo del resto de la aplicación, no se moleste. Si se ve lo suficientemente bien sin ningún esfuerzo, cambie los colores para que se destaque, o tal vez incluso una marca de agua para mostrar que es un prototipo.

He descubierto que los delincuentes más probables para hacer que los prototipos se conviertan en código de producción son los vendedores. Venderán su producto a un nuevo cliente; sin esta nueva característica, el cliente no habría firmado. No se les puede culpar, tienen objetivos. Ten cuidado con ellos; asegúrate de que no te hagan sacar las cosas que indican que es un prototipo. Tienes que mantenerte firme: probablemente no deberían confundir a los clientes de todos modos.

Su gerencia puede comenzar a forzarlo a convertir un prototipo en código de producción pieza por pieza, si siguió mi primer consejo para nunca escribir código malo, no debería haber ningún problema. Gradualmente, construye el software, sin compromiso.

Luego, si la gerencia comienza a forzarlo a reducir la calidad, debe preguntarse por qué. ¿Son pasivos? ¿débiles? ¿desesperado? Ninguna de esas cosas son buenas razones para quedarse en una empresa.

Bastante simple en realidad. Dígales que terminarían perdiendo a su cliente favorito si terminan poniendo este desastre con errores para mostrar.

Y sí, pídales que se arriesguen si realmente lo saben mejor.

Finalmente: no digas que el prototipo tiene errores específicos A, B y C. Luego, deberías corregir ese error, y la gerencia alegará que canalizaron la energía para preparar la producción de software.

Es probable que con esos bonos de rendimiento y futuras concesiones de acciones en estos días, lo escuchen.

Evite el problema en primer lugar. NO LO ACABES. Con eso quiero decir que no lo hagas lucir bonito o que encaje con los estilos existentes en el sitio. El objetivo es simplemente obtener la versión de trabajo más cruda posible para que pueda ver que el flujo de interfaz de usuario muy básico funciona. Si agrega el estilo del sitio existente o lo pule demasiado, van a suponer que simplemente puede "enchufarlo". La administración es como Pakleds de Star Trek. Solo quieren que "lo hagas funcionar". Cuanto más listo lo hagas parecer, más listos van a pensar que es.

Si eso no resuelve su problema, consiga un trabajo en al menos una empresa con una marca conocida por un año. Ponga su correo electrónico y número en un currículum en línea y luchará contra los reclutadores con un palo, lo que le permitirá decirles "absolutamente no" con la confianza de un desarrollador que sabe lo que está haciendo y puede conseguir un nuevo trabajo. mañana donde esperamos que su experiencia en el asunto se tome más en serio.

Actualmente estoy trabajando en una base de código que no tiene dos, sino un triple stack de Rails, .NET y Java. La razón por la que añadimos los Rails fue porque se realizó un prototipo en Rails y el mejor perro de la compañía dijo "hazlo funcionar". Necesitamos decir que no a veces. Mientras no lo hagamos todo el tiempo, deberían tomarnos en serio.

Pero sí, hagas lo que hagas con un prototipo, asegúrate de que comience realmente feo.

No te preocupes por eso.

Si te sientas y arrojas los controles de la interfaz de usuario para un "prototipo", hay exactamente cero razones por las que deberías tirar ese diseño automáticamente. Si fue lo suficientemente bueno para mostrar la gestión, entonces es un buen lugar para comenzar a codificar el programa "real".

Pasar de un prototipo a una interfaz de usuario más "pulida" no debería ser más que una serie de pasos completamente justificables. Tenías que agregar un segundo botón. Recibió comentarios de los usuarios de que encontraron el orden confuso. El grupo de estándares de su organización dicta un cambio menor. Debes cambiar el tamaño de un cuadro de texto para la internacionalización.

Ninguna de esas razones es "bueno, solo fue un prototipo". En el diseño de la interfaz de usuario o en el código o por escrito, CUALQUIER COSA puede terminar viviendo para siempre. Y aquellos que no todos deberían tener muy buenas razones para matarlos.

Y a la administración probablemente no le importa.

Siendo realistas, si la razón por la que no simplemente dejó caer su interfaz de usuario al código existente fue "tuve que volver a escribirlo en nuestro marco correcto", esa debería ser una razón suficiente. Y si no fuera así, probablemente debería tener una discusión sobre el marco de la interfaz de usuario en sí, pero esa es otra pregunta.

Solía ​​tener este problema, hasta que me di cuenta de que no era un problema, sino una forma de liberarme de los estándares de desarrollo bastante obsoletos impuestos a la mayoría de las tiendas.

Entonces le dice a su gerencia que está escribiendo un prototipo, elige las tecnologías que funcionan mejor para usted, para esta área problemática, y luego escribe el software con el pleno conocimiento de que entrará en producción.

Usted escapa del tedio de "las aplicaciones deben estar en Java 1.6 usando Web (inserte el costoso motor J2EE de elección de gestión)" y estándares de nombres inútiles, etc.

Mis lenguajes de prototipo actuales son "php" (que escala totalmente a entornos de producción de servicio pesado, solo pregunte a Facebook) y la combinación muy elegante de Groovy / Java con Tomcat o Jetty.

La combinación maravillosa / java es ideal para un desarrollo rápido. Groovy es agradable de usar, se desarrolla rápidamente pero funciona como un caracol geriátrico, sin embargo, es trivialmente fácil re-factorizar secciones críticas de rendimiento en Java puro. Casar la aplicación con Tomcat o Jetty significa no tener que lidiar nunca más con EJB y otros horrores J2EE.

La principal ventaja de tener un prototipo funcional en lugar de un boceto propuesto por varios carteles es la opinión de los usuarios. Los prototipos son una excelente manera de involucrar realmente a la empresa en el diseño. Una vez que se dan cuenta de que pueden decir cosas como "¿no debería estar ese campo en la pantalla principal" y oye, listo! allí está en la pantalla principal en la próxima demostración que abren y se involucran en el diseño aportando años de valiosa experiencia empresarial al proyecto.