El arte es la destreza

Analfabetismo injustificable

Marco Dorantes — Wed, 01 May 2013 13:06:00 GMT

¿Por qué más información no es igual a más educación y más conciencia? Quizá por las mismas razones que practicar el chismorreo no es igual a un mayor entendimiento de la realidad. Tal vez la distinción entre lectura para información y lectura para entendimiento pueda arrojar algo de luz ante dicha pregunta. Distinguir, entre otras cosas, la cantidad de esfuerzo implicado puede aclarar la situación. En la lectura para información nuestro esquema actual de opiniones y prejuicios queda intacto, mientras que en la lectura para entendimiento se debe ejercer la facultad autocrítica para alterar dicho esquema. Con la lectura para información sigo siendo el mismo antes y después, con la lectura para entendimiento no es posible regresar al estado de conciencia anterior pues ya no soy el mismo.

Mucha información pero sin entendimiento produce el grave problema de ocultar o disimular mi analfabetismo, o incluso hacerlo pasar como sabiduría. Así, habría casos en los que pronuncio y vocifero mis opiniones sin tener conciencia de que estoy diciendo tonterías.

Creo saber una, o quizá más bien media, cosa sobre software y computación, y casi nada de campos como la filosofía, la ciencia, la historia o la teología, por lo que anticipo que mis opiniones y prejuicios actuales al respecto quedarán en breve derogados. Lo sorprendente para mí es escuchar una y otra vez, por años, las mismas razones por las que supuestamente no es posible cambiar en áreas como la política social o corporativa, o el proceso de creación de soluciones basadas en software. En esas áreas hay niveles de analfabetismo comparables a conservar nociones ya caducas en ciencia natural; por ejemplo, comparables a decir que el fenómeno de la gravedad es una fuerza de atracción o que el Sol es una bola de fuego. Señores, no digo que sea necesaria la erudición sino que el analfabetismo entre nosotros es inaceptable. No sería justificable condenar por su analfabetismo a quien debe partirse la espalda trabajando cada día para apenas sobrevivir, pero ¿cómo podría justificarse tal analfabetismo en quienes tenemos recursos y oportunidades, con acceso a la tecnología y a los libros?

La calidad del software y el público usuario

Marco Dorantes — Sun, 10 Mar 2013 23:46:03 GMT

La calidad del software que se desarrolla para propósitos empresariales o gubernamentales puede mejorar. Como a mí me gusta la programación de computadoras, he pensado en qué puedo hacer para que los problemas de calidad en software disminuyan. Hay muchas cosas, claro, empezando por mejorar mi propio profesionalismo. También imagino que si el público usuario conoce un poco más de software —así como yo igualmente necesito conocer más— entonces podrá recibir soluciones y productos de mayor calidad.

Además, como sospecho que cada vez más personas en el mundo hispanoparlante utilizarán software para sus negocios, y pocos de ellos saben mucho de software —yo tampoco sé mucho—, me pregunté qué le diré al siguiente pariente cercano que me pregunte qué debe hacer para mejorar su negocio por medio del software. Remito una página con mi posible respuesta. ¿Qué opinan?

Toda retroalimentación será muy apreciada. En especial si consideran que alguna sección es demasiado oscura para la posible audiencia: Carta a la tía Margarita o del software para mejorar tu negocio.

Carta a la tía Margarita o del software para mejorar tu negocio

Marco Dorantes — Sun, 10 Mar 2013 20:21:00 GMT

Querida tía Margarita* —o estimado emprendedor que quieres utilizar aplicaciones de software para tu negocio y apenas sabes cómo encender una computadora:

*La tía Margarita es un apelativo utilizado por algunos profesionales de la computación para referir a quienes son legos en las ciencias del cómputo electrónico-digital.

Me has dicho del éxito en tu negocio y me da mucho gusto pues has dedicado, junto con tu familia, muchos años para lograrlo. Me platicas de tus ahorros y de tu intención de invertirlos en un proyecto para mejorar tu negocio e integrarlo al mundo de las posibilidades ofrecidas por los llamados teléfonos inteligentes, las nuevas computadoras tablets, los televisores de señal digital y otros dispositivos electrónicos; tecnologías que tienden a funcionar en una interconexión cada vez más ubicua a través de Internet. Dices que es un proyecto inevitable si no quieres perder el éxito obtenido. Además, estás decidida a extender tu éxito por medio de ese proyecto. Deseo con sinceridad que logres tus propósitos y te diré algo que yo pensaría si estuviera en tus zapatos.

Nicholas Carr publicó (IT Doesn't Matter, mayo 2003, Harvard Business Review) algunas observaciones sobre por qué las tecnologías de información se han convertido en materia prima para los negocios y ya no representan un criterio determinante de diferenciación con respecto a su competencia. Desde entonces se ha visto que no le falta razón. Así que un objetivo modesto para tu proyecto sería colocarte a la par de otros negocios con proyectos similares, y para lograrlo quizá no se requiera crear nada sino tan sólo adquirir una solución tecnológica ya existente. Si tal adquisición está en el alcance de tus ahorros, y tienes evidencia de que satisface tus necesidades prioritarias, entonces esa podría ser una opción viable. De otro modo, si adquirir es inasequible o eliges un objetivo más ambicioso para diferenciar tu negocio, entonces deberás pensar en crear una solución a la medida de lo que necesitas.

No digo que sea fácil adquirir e integrar algo existente sino que, en definitiva, la creación de una solución basada en software para problemas o retos de negocio representa palabras mayores en términos de complejidad (software es el conjunto de reglas e instrucciones que una computadora puede realizar). La organización Standish Group investiga cada año las estadísticas para este tipo de proyecto y publica los resultados de su sondeo en el ya tradicional Chaos Report. En la categoría de resultado general los proyectos se agrupan en exitosos, deficientes y fallidos. Un proyecto exitoso, como mínimo, logra sus objetivos de manera completa, lo hace a tiempo y dentro de su planeación financiera. Un proyecto deficiente fracasa en cualquiera de esos criterios y un proyecto fallido no alcanza ninguno. Todos los proyectos iniciaron con las mejores intenciones pero no todos fueron exitosos. La fracción de proyectos que cada año logran los tres criterios de éxito, según dicho reporte, gira alrededor de un tercio.

Año tras año el reporte contiene una relación de los factores que contribuyeron a los resultados, en esos factores deberás concentrar tu atención. Suelo agruparlos en las siguientes categorías: el perfil del personal involucrado, el proceso de creación, la estrategia de diseño y la tecnología utilizada. Al considerar su impacto sobre el resultado, los factores en cada categoría tienen un impacto superior comparado con el de los factores de la categoría sucesiva. Es decir, por ejemplo, si la estrategia de diseño es impecable pero no se cuenta con un proceso adecuado para realizarla entonces su impacto es marginal; lo mismo ocurre si el proceso es muy bueno pero no se tiene al personal que sepa cómo adecuarlo sobre la marcha ante el dinamismo de los negocios.

Las personas y su capacidad para enfocar tanto ideas generales como detalles específicos, y comunicarlos efectivamente, representan el factor más determinante para el éxito de tu proyecto; empezando por ti misma. Te sorprenderá el nivel de detalle al que es necesario especificar los requisitos para que puedas en efecto verlos realizados en una aplicación tecnológica. Si no estás dispuesta a enfrentarte a este tipo de exigencias, y mantienes tu decisión de llevar a cabo tu proyecto, entonces quizá debas reservar no poco dinero para financiar los procesos legales por litigios comerciales. Procesos basados en un sinfín de cláusulas relacionadas al incumplimiento de contratos. Sin embargo, sospecho que no es para eso que quieres usar tus ahorros.

Si el caso fuese una cirugía a cerebro abierto entonces buscarías al mejor neurocirujano que puedas conseguir. El caso de tu proyecto no es tan distinto si consideramos el tipo de esfuerzo intelectual y el nivel de esmero requeridos para el éxito (te advierto que es común usar analogías con otras industrias para explicar aspectos de la industria del software, pero debes interpretarlas con mucho cuidado pues, como verás en el siguiente párrafo, cualquier analogía tomada a la ligera puede ser causa de proyectos deficientes y fallidos). Lo propio del caso es asegurarte que tratas no sólo con administradores sino directamente con quienes tienen la capacidad para crear, con su mente y manos, las piedras angulares del proyecto; desde contribuciones al diseño de un modelo extendido de negocio, pasando por el diseño de la nueva interacción con tus clientes y proveedores, hasta los componentes técnicos de alta calidad que harán funcionar tu solución tecnológica.

Todavía hoy es frecuente encontrar consultorías en tecnología cuya organización se basa en un taylorismo posindustrial; es decir, un modelo orientado en analogía con la producción al estilo de la revolución industrial ocurrida a partir de la segunda mitad del siglo XVIII (Frederick Winslow Taylor, entre otros) y aplicado a la producción en la revolución de las nuevas tecnologías de la información (el periodo posterior al industrial). Como sabes, para que aquel modelo pudiese funcionar, los trabajadores debían ser baratos y de muy bajo perfil intelectual, realizar trabajo mecánico repetitivo en una línea de producción —cuales partes de la máquina fabril— y saber obedecer los estrictos dictados del grupo de administradores de la fábrica. Quizá te sorprenda saber que el esquema actual en creación de soluciones basadas en software, en muchos casos, no está radicalmente alejado, en los hechos, de tal régimen. Por lo cual no me sorprenden las razones de fondo atrás de esa banal excusa, ya proverbial, que recita algo como “no le podemos dar el servicio pues se cayó el sistema”.

Los factores para el éxito, cuyas categorías ya mencioné, son claves para entender qué tipo de actividad es crear software y cómo realizarla en proyectos comerciales privados o proyectos gubernamentales del dominio público. Componer software es una actividad reciente que inició hace unos sesenta años. Durante esta naciente etapa la industria del software ha adoptado opiniones ya caducas de la industria de manufactura de siglos pasados. Por ejemplo, la idea de división de trabajo; esta idea está detrás de puestos de trabajo como ‘analista’, ‘arquitecto’, ‘diseñador’, ‘programador’, o ‘tester’ (que realiza pruebas). Estos puestos coinciden con las etapas del modelo en cascada (secuencia lineal de etapas sucesivas) para el ciclo de vida del software: análisis, arquitectura, diseño, programación y pruebas. Quizá te sorprenda saber que Winston W. Royce, el supuesto inventor del modelo en cascada, jamás dijo que ese modelo funcionaría. De hecho, en su publicación original advierte en contra de intentar una secuencia lineal de etapas sucesivas. En años subsiguientes afirmó que su trabajo fue gravemente malinterpretado.

Como verás, la actividad de creación de soluciones de negocio basadas en software tiene mucho por madurar como profesión y como industria. Su actual imagen de glamour se debe más al buen trabajo de publicistas y comerciantes oportunistas que a una ética profesional interna y madura. Por supuesto, esta industria debe financiar su proceso de madurez de sus propios bolsillos y no a costa de los ahorros de personas como tú; es decir, no permitas que malformadas opiniones sobre los factores críticos de éxito afecten el potencial resultado de tu proyecto.

Necesitarás una estrategia para que tú misma te formes buenas opiniones de los factores críticos de éxito; una estrategia para distinguir entre conocimiento confiable y mera opinión. Pues en un tema de moda, como lo son las computadoras e Internet, con mucha frecuencia las meras opiniones son las más vociferadas. Por eso, para pensar tu proyecto, no digo que logres la erudición en el tema sino que salgas del analfabetismo computacional. De otro modo tú misma serías un factor de riesgo para tu proyecto pues, con mayor facilidad, fomentarías interpretaciones erróneas de lo que significa el avance y los hitos que cimentan el éxito final; por ejemplo, si al inicio del proyecto exiges una calendarización de todo el proyecto y luego usas tal proyección para juzgar avances y retrasos entonces estarás midiendo cantidad de actividad pero no cantidad de progreso. Para no tropezar con preconcepciones y meras opiniones debes practicar tres hábitos del conocimiento confiable: la duda, la razón y la experiencia. Entre más destreza tengas ejerciendo esos hábitos más oportunidades tendrás de lograr cada vez mejores opiniones en el tema. Tal estrategia no es otra que la usada por ti misma para salir del analfabetismo en otras áreas de la vida.

Lograr una mera opinión es algo muy fácil, basta con dejarse llevar por la corriente actual de la cultura popular, y esa facilidad revela, en parte, por qué son tan frecuentes. Los problemas inician por mantener y propagar una opinión obtenida de esa manera y, para agravarlos, por afirmar que tal opinión es propia y que debe defenderse —cuando ni es propia ni debe defenderse sino evaluarse. La mera opinión será para tu proyecto como la comida chatarra es para tu salud: dañina. Por otro lado, lograr conocimiento confiable implica un trabajo muy duro. En tu caso no hay motivo para amedrentarse pues ya estás acostumbrada a ese tipo de trabajo; asimismo, ¿cómo podrías justificar el apego a una mera opinión si tú no eres un caso desesperado sin recursos ni salud?

No quiero dejar de mencionar otros aspectos importantes del proyecto. Aspectos como un modelo extendido de negocio, que añada posibilidades distintas a tu modelo actual para interactuar con clientes y proveedores; el relevante papel del software como medio para conservar entendimiento; un modelo financiero para la solución tecnológica acorde al dinamismo de tu negocio y a las cambiantes condiciones en su entorno; y otros aspectos decisivos. En todos podrán entremezclarse las meras opiniones y el conocimiento confiable, por ejemplo: “un proyecto para crear una solución de negocio basada en software es igual a uno para hacer un edificio o un puente, y ambos se administran igual: al inicio hay un conjunto fijo de requerimientos, un costo total fijo, y un plan para todo el proyecto.” Si bien es cierto que los requerimientos, el costo y la frecuente planeación son muy importantes, también es cierto que, precisamente por dicha importancia, podemos lograr una mejor aproximación a esos aspectos por medio de procesos empíricamente controlados, y no sólo por medio de racionalizaciones prematuras.

¿Qué significa un proceso empíricamente controlado? Bueno, para comenzar, significa que un proceso no es controlado sólo por racionalizaciones «a priori», es decir por imaginar el futuro con independencia de la corroboración de la experiencia —lo cual sigue siendo una tendencia mayoritaria en la industria de hoy, con grandilocuentes arquitecturas por anticipado, gráficas de Gantt expresadas en meses o años, y estrategias y tácticas para la gestión del riesgo basadas en el miedo. Por otro lado, un proceso empíricamente controlado surge de estrategias y tácticas «a posteriori» ejecutadas continuamente y en lotes pequeños. Un ejemplo de tales estrategias y tácticas se puede encontrar en ejecuciones musicales y representaciones teatrales. Si te interesa aumentar la medida de confianza en el éxito de tu proyecto, entonces «¡ensayar, ensayar, ensayar!» es un hábito esencial para lograr excelentes resultados tanto en representaciones teatrales como en la creación de soluciones empresariales basadas en software. Por ejemplo, la publicación de la solución tecnológica a tus clientes y proveedores es una parte crucial que necesitarás que resulte muy bien; por lo que ensayos realistas de ese procedimiento deben ser ejecutados, temprano y a menudo, antes de tocar al usuario final.

Hay mucho, mucho más, que debes considerar para no ser parte de las estadísticas de proyectos fallidos o deficientes, donde los inversionistas obtienen muy poco o nada a cambio de su inversión. Con mucho gusto continuaré en la siguiente oportunidad.

Saludos.

Buenos estilos para la programación de computadoras

Marco Dorantes — Sun, 17 Feb 2013 16:00:00 GMT

Una presentación por Bjarne Stroustrup, creador de C++, sobre buenos estilos de programación. Esta presentación estuvo dedicada a Dennis Ritchie, creador of C.

Nota of relevancia: El lenguaje de programación C, de una manera o de otra, está en el cimiento de toda la computación existente.

Day 1 Keynote - Bjarne Stroustrup: C++11 Style

¿Controlado empíricamente?

Marco Dorantes — Fri, 08 Feb 2013 23:06:00 GMT

La creación de soluciones de negocio basadas en software, conocida también como desarrollo de aplicaciones, podría beneficiarse mucho de tipos específicos de procesos de desarrollo; en particular aquellos controlados empíricamente, como los que tienen un núcleo iterativo e incremental en el interior, por ejemplo Adaptive, Crystal Clear, DSDM, Scrum, FDD, Lean, XP y otros.

¿Qué es lo que podría significar ser empíricamente controlado? Bueno, para comenzar, debe significar que un proceso no es controlado sólo por racionalizaciones «a priori» —lo cual sigue siendo una tendencia mayoritaria en la industria de hoy, con grandilocuentes arquitecturas por anticipado, gráficas de Gantt expresadas en meses o años, y estrategias y tácticas para la gestión del riesgo basadas en el miedo. En cambio, por otro lado, un proceso empíricamente controlado surge de estrategias y tácticas «a posteriori» ejecutadas continuamente y en lotes pequeños.

Un ejemplo de tales estrategias y tácticas se puede encontrar en ejecuciones musicales y representaciones teatrales. Si te interesa aumentar el nivel de ejecución en proyectos donde el desarrollo aplicativo es una pieza clave, entonces «¡ensayar, ensayar, ensayar!» es un principio básico para ejecuciones excelentes tanto en ejecuciones musicales como en la ejecución creativa de soluciones empresariales basadas en software. Por ejemplo, como ya sabemos, la instalación o el despliegue (deployment) es una parte crucial de la cadena de valor en la entrega de software, ejecutemos entonces, temprano y a menudo, ensayos realistas de tal procedimiento antes de tocar el usuario final.

Hay mucho, mucho más, sobre esto por venir...¿interesado?

Avances en las bases teóricas para el desarrollo de software

Marco Dorantes — Thu, 31 Jan 2013 23:57:00 GMT

Hace tiempo publiqué algo acerca de la obsolescencia de algunas teorías de gestión de proyectos (The underlying Theory of Project Management is Obsolete) y, por lo tanto, sobre la necesidad de mejores teorías no sólo para la administración. En mi recorrido como profesional en software, En la medida en que fui tomando conciencia de cuán importante es el esfuerzo teorético para mejorar la práctica —y viceversa—, en esa medida he buscado teorías que cimentan científicamente nuestra actividad. Fue, entonces, muy grato saber que otros profesionales estaban realizando esfuerzos teoréticos (Working on software theory) en nuestro campo.

Hoy en día es muy enriquecedor aprender más sobre el progreso actual de la obra teórica de gente como Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, y Svante Lidman:

The Essence of Software Engineering: Applying the SEMAT Kernel

«The kernel in this book represents a software development effort as a continuously operating abstract mechanism composed of components and relationships. The project does not move from position to position within this mechanism as in the assembly line metaphor. Rather, there is a continuous flow through the mechanism as opportunities are transformed into requirements, and then into code and tests, and then into deployments.» —from the foreword by Robert C. Martin

«Software projects everywhere look for methodology and are not finding it. They do, fortunately, find individual practices that suit them; but when it comes to identifying a coherent set of practices that can guide a project from start to finish, they are too often confronted with dogmatic compendiums that are too rigid for their needs. A method should be adaptable to every project’s special circumstances: it should be backed by strong, objective arguments; and it should make it possible to track the benefits.» —from the foreword by Bertrand Meyer

Medida de confianza

Marco Dorantes — Sat, 12 Jan 2013 14:14:20 GMT

Al pensar en general sobre la creación de soluciones de negocio basadas en software, y al pensar en particular en el desarrollo adaptativo de dichas soluciones, busco maneras para construir confianza en clientes y usuarios; confianza en que la solución tecnológica entregará valor de negocio.

Al estar inmersos en una sociedad cuyo funcionamiento depende, en cada vez mayor medida, del software, es decir al nosotros mismos ser creadores y consumidores de software, necesitamos mejores niveles de confianza en dicho software. Y requerimos tal confianza en muchos niveles y ámbitos de influencia. Por ejemplo, los directores de la Agencia Espacial Europea seguramente quisieron un mayor grado de confianza en su software después de la explosión del Ariane 5 (causada por un error de diseño de software). De la misma manera, yo quiero un mayor grado de confianza en el servicio WCF que ahora estoy diseñando y programando, el cual será desplegado a escala empresarial y será invocado por docenas de aplicaciones empresariales.

¿Cómo sé que no estoy engañándome, y a mi equipo de proyecto, al creer que mi estimación de esfuerzo es correcta?

¿Cómo sé que no estoy engañándome, y a mi equipo de proyecto, al creer que mi servicio WCF está listo para ser desplegado?

Para obtener mejores grados de confianza, por supuesto, el primer paso es, como dijo Richard P. Feynman en lo que se refiere a un rasgo del pensamiento científico, no te engañes, ni a tu equipo, ni a tu cliente. Los métodos de las ciencias conllevan mecanismos para no engañarnos a nosotros mismos; dichos mecanismos provienen de mezclas adecuadas y útiles de las diferentes escuelas de pensamiento conocidas como racionalismo, empirismo y escepticismo.

Justo ahora, por ejemplo, un número cada vez mayor de exitosas pruebas automatizadas ejecutadas por demanda o en cada registro de código (check-in) de mi servicio WCF abona para un grado incremental de confianza. Pero esas pruebas sólo son un ejemplo. También ocurren por demanda varios ciclos de retroalimentación a partir del consumo del servicio WCF por parte de varias aplicaciones cliente. Además, la retroalimentación de los usuarios de dichas aplicaciones nos ayuda a no engañarnos a nosotros mismos al decir “creemos que estamos en la dirección correcta” o “queremos creer...”. Si tenemos o no tal creencia no es lo importante, lo que sí es relevante lo que podemos comprobar con base en una variedad de tipos de evidencia. Tipos de evidencia que sean diversos, amplios y no triviales.

¿Debo confiar que mi hija adolescente hará sus deberes? ¿Hay alguna prueba o patrón de comportamiento para justificar tal confianza? Las palabras en sí mismas no son evidencia. Por lo que no es una cuestión de confianza sino, en última instancia, una cuestión de evidencia.

Una evidencia plausible para justificar la confianza es el registro histórico de la entrega de buen software, a tiempo y dentro del presupuesto, por parte de algún grupo de proyecto en particular. Los planes y las buenas intenciones no son una evidencia en sí mismos.

Por tanto, una medida de confianza en X estará basada en medidas de evidencia real de X —para cualquier valor relevante de X.

Si sólo hay palabras, planes y buenas intenciones sin un registro histórico que respalden dichas palabras, planes y buenas intenciones entonces hay poca confianza por medir. En ese caso, una acción plausible es empezar a construir ese registro histórico para el grupo de proyecto en particular.

El lado oscuro del Manifiesto Ágil

Marco Dorantes — Wed, 14 Nov 2012 01:31:03 GMT

Para aquellos interesados en contestar un cuestionario de Giancarlo Succi (autor de Extreme Programming Examined) y Andrea Janes: http://darkagilemanifesto.org

Publiqué a continuación dos conjuntos de mis comentarios; para mayor discusión:

Dark Manifesto for Agile Software Development

Dark Manifesto for Agile Software Development. Take 2

Las preconcepciones

Marco Dorantes — Thu, 11 Oct 2012 08:19:00 GMT

¿Cuál puede ser un grave problema con mi versión actual del mundo? Pues uno grave sería, quizá, vivir siempre encadenado a unas preconcepciones que no me orienten en el sentido de la realidad, y ser inconsciente de ello. ¿Cuál es el problema con eso? Pues, tal vez, que mis preconcepciones actuales sean un estorbo para seguir aprendiendo, para mejorar o cambiar mi opinión sobre la realidad de algún asunto relevante. Por ejemplo, si estoy muy convencido de haber entendido la idea de diseño conducido por aserciones (test-driven design) como una actividad únicamente de pruebas entonces entre más fuerza tenga esa convicción menos estaré dispuesto a aprender algo nuevo o mejorado sobre dicha idea, precisamente la fuerza de esa convicción es lo que me impide mejorar la idea. Por lo que la siguiente vez que me encuentre muy seguro de mis opiniones quizá deba recordar que alguien sin escrúpulos es lo mismo que alguien sin dudas.

El conocer al estilo científico no es “la cúspide de la perfección humana” —lo cual es un disparate— sino uno de los esfuerzos más confiables para conocer justificadamente el mundo, no como quisiéramos que fuese sino como realmente es. Si bien es cierto que ese estilo de aprender no es perfecto, aún podemos apoyarnos en sus estrategias para tomar conciencia de nuestras preconcepciones y para no quedar encadenados a ellas por siempre.

Las preconcepciones están presentes todo el tiempo, es un efecto residual del consumo de la cultura a nuestro alrededor. Nosotros mismos hacemos ese consumo, nadie lo puede hacer por nosotros, y ocurre al realizar el acto de interpretación de los datos sensibles que percibimos o de las imágenes mentales en nuestra memoria. Por lo que las preconcepciones son residuos directamente relacionados con nuestra destreza para interpretar la realidad. Si no tenemos el hábito de mejorar nuestra capacidad interpretativa es posible entonces que nuestra destreza para interpretar no incluya tomar conciencia de nuestras preconcepciones, provocando que estemos por completo convencidos de haber entendido un concepto cuando en realidad nos mantenemos ignorantes de dicho concepto de manera inconsciente. Es decir, lo que nos impide aprender un concepto nuevo es el preconcepto que usurpa su lugar.

Nuestro actuar concreto en la vida práctica está dado en el contexto de un esquema teórico-conceptual, por lo que es evidente que el problema de las preconcepciones no es un problema práctico, sino teórico. Para mejorar substancialmente la práctica, y al mundo concreto del momento presente, es requerido mejorar la teoría. Una teoría es una mirada hacia la realidad desde determinada perspectiva, hay teorías de todo tipo y alcance, y las que explican más hechos, es decir las más amplias, tienden a ser las mejores. Las teorías moldean, como anteojos de color, nuestras interpretaciones y pueden convertirse en herramientas para el ejercicio interpretativo si uno es consciente de dichas teorías. Por tanto, ampliar y profundizar nuestro conocimiento teórico es parte del proceso para adquirir destreza interpretativa. No podemos ver la realidad de manera directa, al parecer siempre necesitamos una teoría para guiar cada interpretación. Como nos dice Guy Claxton:

«La observación está continuamente dirigida por el interés y el pensamiento humanos, y cuanto menos evidente sea la mano controladora de nuestras preconcepciones, más importante será recordar que está ahí y reflexionar constantemente sobre de qué nos puede estar apartando o a qué nos puede estar acercando de una manera tácita. El hecho de que los datos estén “contaminados” con las creencias y las presuposiciones de los científicos es algo de lo que éstos deben tratar de ser conscientes y, en ocasiones, de lo que se deben guardar. Por ejemplo, uno de los grandes problemas experimentados por los antropólogos es cómo dejar a un lado sus propios hábitos culturales de pensamiento mientras tratan de comprender cómo ven el mundo personas muy distintas a ellos. Y no es que juzguemos a otras personas en función de nuestra propia visión del mundo; las teorías que suscribimos en un momento dado moldean —tanto si lo sabemos como si no— todas nuestras observaciones.»

Cuando no podemos interferir en el curso de un proceso y así experimentar para indagar qué es lo que pasa, «...todo lo que podemos hacer es utilizar teorías para dirigir nuestra atención a determinados tipos y localizaciones de sucesos, y para guiar nuestra interpretación de lo que vemos.» —Guy Claxton. Educar mentes curiosas. El reto de la ciencia en la escuela.

Las estrategias científico-filosóficas que contrarrestan los efectos de las preconcepciones pueden ayudarnos para mejorar la interpretación que hacemos de la realidad. Algunas son, entre otras, y como nos recuerda Derek Alexander Muller, el auto-cuestionamiento, el diálogo y la discusión: Khan Academy and the Effectiveness of Science Videos.

Un enfoque participativo

Marco Dorantes — Tue, 09 Oct 2012 01:04:00 GMT

Recientemente he tenido el gusto de quedar maravillado por la inteligencia de personas como Mary Lynn Manns, Linda Rising, Esther Derby, Diana Larsen, Mary Poppendieck, entre muchas otras personas en el campo del pensamiento creativo y de la innovación en general, y en el campo de la creación de soluciones de negocio basadas en software en particular.

Ante los graves problemas en la sociedad, desde problemas políticos hasta problemas de calidad en software, hay quien opina que la solución depende de los políticos o de los líderes corporativos y que la mayoría nada significativo puede hacer. También hay quien opina que las soluciones dependen exclusivamente de la voluntad de la gran mayoría, y que los políticos y líderes mundiales, al ser una minoría, resultan irrelevantes.

Me gusta pensar en la diversidad de perspectivas, y disfruto tratando de lograr la síntesis de los opuestos, o aprender cómo otros alcanzan tal síntesis. Por ejemplo, la que Mary Lynn Manns y Linda Rising proponen en su obra Fearless Change: Patterns for Introducing New Ideas:

En español:

«Con el cambio de arriba hacia abajo, el énfasis está en hacer los cambios rápidamente y abordar los problemas sólo si es necesario. El cambio de abajo hacia arriba es más gradual, pero aborda la resistencia más eficazmente. El énfasis en el cambio de abajo hacia arriba está en la participación y en mantener a la gente informada sobre lo que está pasando, por lo que se reducen al mínimo la incertidumbre y la resistencia. Con base en nuestra experiencia, creemos que el cambio es mejor abordarlo de abajo hacia arriba con apoyo de los niveles administrativos en puntos adecuados—de manera local y a un nivel jerárquico superior. Peter Senge, autor de La Quinta Disciplina, parece estar de acuerdo:

“Durante los últimos años, ha surgido una nueva comprensión del proceso de cambio organizacional. No es descendente ni ascendente, sino participativo a todos los niveles — alineado a través de un entendimiento común del sistema.”

Como puede verse, creemos en un enfoque participativo.»

En inglés:

«With top-down change, the emphasis is on making the changes quickly and dealing with the problems only if necessary. Bottom-up change is more gradual, but it addresses resistance more effectively. The emphasis in bottom-up change is on participation and on keeping people informed about what is going on, so uncertainty and resistance are minimized. Based on our experience, we believe that change is best introduced bottom-up with support at appropriate points from management—both local and at a higher level. Peter Senge, author of The Fifth Discipline, appears to agree:

“During the last few years, a new understanding of the process of organizational change has emerged. It is not top-down or bottom-up, but participative at all levels—aligned through a common understanding of a system.”

As you can see, we believe in a participatory approach.»