Déjame hacerte una pregunta: Como gestor de producto o maestro de scrum, ¿crees que hay un punto de inflexión en el que la consistencia se convierte en tiranía?
Presenté esta pregunta a algunos pobres incautos en algunos Meetups recientes de producto y Agile aquí en el área de Raleigh. Mi recompensa fueron numerosas afirmaciones de que tales duendes tontos existen.
Más recientemente, después de publicar mi pregunta en una variedad de canales de medios sociales, estoy convencido de que nosotros en el negocio de la entrega de software a veces sí nos esclavizamos en nombre de la consistencia.
Así que vamos a desempacar esto un poco y ver si no podemos estar de acuerdo en lo que tal punto de inflexión podría parecer …. examinando primero lo que no es.
Consistencia sabia
Un ejemplo de consistencia beneficiosa para los gerentes de producto es en cómo elaboramos nuestras historias de usuario. Por ejemplo, a mí me gusta seguir el principio de INVERSIÓN -NO como una receta calderilla- sino más bien como guía para asegurarme de que no estoy pidiendo a mis equipos que se coman el elefante entero en una sola historia de usuario.
Otro ejemplo de buena consistencia viene del mundo de la UX, concretamente del capítulo 6 del seminal «The Design of Everyday Things» de Don Norman. Allí, Norman afirma que aquellos que tenemos experiencia en la conducción podemos manejar una marca y un modelo que nunca hemos manejado antes gracias a la colocación coherente de características como el pedal del acelerador y los espejos retrovisores laterales.
Steve Krug corre con este ejemplo en el capítulo ‘Billboards Design 101’ de su delicioso libro «Don’t Make Me Think». Krug hace argumentos efectivos en nombre del reconocimiento sobre el recuerdo, especialmente cuando se trata de tratamientos de jerarquías visuales, hipervínculos y disposición de contenidos.
Sin embargo, Krug también argumenta que lo que queremos en última instancia es esforzarnos por la claridad, con el uso sabio de la consistencia como un medio eficaz para conseguirlo. También ofrece esta advertencia en el mismo capítulo:
Y por último, unas palabras sobre la consistencia.
A menudo se oye citar la consistencia como un bien absoluto. La gente gana muchos argumentos de diseño simplemente diciendo «No podemos hacer eso. No sería consistente»
La consistencia es siempre una cosa buena para esforzarse dentro de su sitio o aplicación. Si tu navegación está siempre en el mismo lugar, por ejemplo, no tengo que pensar en ello ni perder tiempo buscándolo. Pero habrá casos en los que las cosas serán más claras si las haces ligeramente incoherentes.
Consistencia tiránica
Mi cita inicial proviene de «Self-Confianza» de Emerson,»un ensayo que hace un argumento convincente para que la gente piense por sí misma, en lugar de aceptar un destino a menudo asociado con acantilados y lemmings.
Como mencioné anteriormente, hice mi pregunta inicial en una variedad de canales sociales y Meetups. A continuación se presentan ejemplos que coseché y que creo que demuestran una coherencia tonta, si no tiránica:
- Un maestro de scrum lanzando un ataque si un desarrollador no crea una historia de JIRA para arreglar un error tipográfico en un artefacto README.md.
- Un editor de una organización de noticias que insiste en que la aplicación móvil nativa soporte exactamente las mismas 150 secciones que su solución de escritorio basada en el navegador para no confundir a los usuarios.
- Un gestor de proyectos que mantiene que la planificación de la capacidad como la única y verdadera manera de asegurar que un cliente está recibiendo lo que pagó porque los enfoques más modernos para la entrega de software tienen demasiada incertidumbre involucrados.
- Alguien del campo pregunta «¿No hay una manera de conseguir que todos los equipos de desarrollo se alineen en la forma de dimensionar las historias?»
- Un arquitecto que defiende el Gran Diseño por Adelantado de todo para cada escenario porque insiste en que es la única manera de saber qué construir para soportar un conjunto de características.
- Un cliente que exige que los resultados proporcionados por una nueva infraestructura de búsqueda de texto completo basada en Lucene sean 100% idénticos a los devueltos por la implementación de la base de datos NoSQL saliente.
- Un gestor de productos que se niega a aceptar historias de usuario de otros a menos que estén impecablemente formateadas y exhaustivamente completadas utilizando un boilerplate de TPS y su hoja de presentación adjunta.
El resultado de tales escenarios es la frustración de molienda que nuestros equipos de desarrollo soportan como una devoción servil a la consistencia … una priorización bien intencionada pero equivocada que impide en gran medida su capacidad para descubrir y entregar rápidamente y continuamente de las características correctas de valor.
Sabiduría adicional
Otros más inteligentes que yo también han advertido acerca de un tonto servilismo a la consistencia; a continuación hay algunas URLs útiles que visité en la preparación de este post.