Thursday, May 02, 2019

Grado de conciencia

Me llama mucho la atención el aprendizaje, en general. Es decir, el aprendizaje humano. No me interesa la enseñanza, sino el aprendizaje. No me interesa enseñar, sino aprender. ¿Me interesa aprender a enseñar? Si el gremio magisterial tradicional pretende monopolizar la enseñanza, entonces no me interesa aprender a enseñar. Me interesa enseñarme a aprender: me interesa darme lecciones a mí mismo sobre el aprendizaje y sobre la metacognición. Intento ser un perenne aprendiz.

No me interesa la educación entendida como certificación porque –precisamente– no certifica la destreza, sino participa en simulaciones.

Por el contrario, si por educación se entiende enseñar a pensar y aprender a pensar, entonces sí estoy interesado en la educación entendida como los esfuerzos en una comunidad cooperativa de indagación.

Entre los primeros hallazgos básicos sobre la acción de pensar está la distinción entre tres elementos con estructuras cognitivas diferentes entre sí: dato, información y conocimiento. El año pasado mencioné más sobre esa distinción en la publicación: Re-Educación versus Rezagos.

Quizá el grado de conciencia sobre esa distinción marque drásticamente la diferencia en resultados entre diferentes iniciativas de «cambio cultural» para lograr esa deseada «transformación digital» en muchas organizaciones.

Tuesday, May 29, 2018

¿Qué es pensar arquitecturalmente?

Con base en lo que me dicta mi conciencia crítica profesional, tengo la responsabilidad de intentar traer a su atención algunos puntos para su consideración, amable colega en la industria de las tecnologías de información (TI), con respecto al nivel de servicio que ofrecemos a nuestros usuarios y clientes. Esto no es relevante para un solo proyecto, sino para la proyección de nuestro nivel profesional en creación de soluciones de negocio basadas en software. A la fecha, observo algunos intentos nuevos por mejorar en la categoría de Proceso (en algunos casos, Scrum u otros entre los métodos ágiles), pero en la categoría de Diseño/Arquitectura aún observo hábitos que para mí no son convincentes pues no tienen base sobre la cual apoyar mi confianza. Mi punto concreto es que también es necesario intentar mejoras en el nivel de destreza y madurez en la práctica de la arquitectura de soluciones de negocio basadas en software; es decir, desde la definición del problema, pasando por la elaboración iterativa e incremental de una posible solución, hasta el retiro total de la misma. Un ejemplo es que cualquier propuesta de solución debe ser sometida a un estricto escrutinio crítico para ver si realmente representa una solución sólida, estable y sostenible ante el problema de negocio en cuestión. Tal evaluación crítica requiere pensar arquitecturalmente desde múltiples perspectivas. Por ejemplo, el manejo de excepciones: ¿cómo se va a monitorear cada tipo de excepción por parte del personal a cargo de las operaciones en el ambiente de producción, o cualquier otro ambiente operativo?, ¿qué datos tendrá ese grupo para diagnosticar con tino? ¿Son suficientes dichos datos para determinar, con reloj en mano, la remediación adecuada? ¿Se tienen respuestas claras y son satisfactorias para los responsables de monitorear un ambiente productivo? ¿No? Entonces sugiero que se demanden respuestas claras y oportunas para evitar descalabros e insatisfacciones por parte de usuarios y clientes.

Mi punto principal, en general, es que cada uno dentro de los grupos técnicos de cada proyecto (e.g., Scrum Development Team) necesita mejorar en su práctica de pensar arquitecturalmente desde su área de competencia. De esa manera lograremos aproximarnos a mejores soluciones ante los problemas de cada proyecto.

Mi intención no es pretender una respuesta que cierre la pregunta inicial, sino nutrir posibles conversaciones y discusiones sobre pensar arquitecturalmente con cualquiera interesado en el tema. La clave es no sólo incluir miembros de los grupos técnicos (e.g., Scrum Development Team), sino también incluir miembros del negocio en cuestión (e.g., Scrum Product Owner). Es decir, pensar arquitecturalmente no sólo es relevante para grupos técnicos de TI, sino principalmente es relevante para el diseño técnico —i.e., detallado— de las estrategias comerciales de los negocios hacia sus propios clientes (lo cual sería parte de la carnita rescatable de la así llamada “arquitectura empresarial”).

¿Cómo pensó el grupo de albañiles, arquitectos e ingenieros de, por ejemplo, la Torre Latinoamericana –en la Ciudad de México– para que se mantuviera en pie todos estos años? ¿Cuáles valores, principios, prácticas y hábitos fueron parte de su ambiente profesional como para funcionar como grupo de trabajo con tales resultados? El resultado de su modo de pensar y actuar ha permitido que muchos habiten tal edificio por muchos años sin preocuparse de si hoy permanecería en pie. Con su ambiente profesional no sólo edificaron un inmueble material, sino que edificaron bases sobre las cuales se apoyó la confianza de todos en lo que hacían.

Antes pensaba que crear software era una disciplina de ingeniería y que todo proyecto debería tan sólo seguir prescripciones ya establecidas y probadas. Pero después de indagar comprobé que no debe, ni puede, ser así para cada proyecto. Por lo cual, el ejemplo anterior me sirve para pensar más en cómo un ambiente profesional (i.e., conjunto de valores, principios, prácticas, hábitos, etc.) puede ser un caldo de cultivo para ese tipo de resultados.

Una inferencia obvia es que un ambiente profesional debe enfocarse en edificar confianza en lo que se plantea y se hace ahí. Una base sólida sobre la cual apoyar la confianza es la evidencia material verificable, no sólo las palabras y las buenas intenciones. Si de confianza se trata: Lo importante no es quererlo, creerlo o decirlo —eso cualquiera lo hace—, sino demostrarlo. Así se está en mejor posición para cimentar una confianza duradera.

Las profesiones confiables hoy en día se derivan de la confianza que aportan los procesos de las ciencias. Por lo que regresar a los básicos del pensamiento científico es parte de mejorar una profesión hoy en día y de mejorar los ambientes en donde se ejerce cualquiera de las profesiones contemporáneas. Pero, por favor, debe quedar claro, aquí no me refiero al adefesio de “el método científico” que se expone en los sistemas escolarizados tradicionales. Eso sólo existe en las [j]aulas de dichas escolarizaciones. Aquí me refiero a cada perspectiva adulta, amplia, profunda y compleja que del pensamiento científico se ha evaluado desde la filosofía de la ciencia, i.e., epistemología.

Para no extenderme más aquí, intentaré provocarle la curiosidad, amable lector, diciendo que la confianza en las ciencias inicia con la destreza para distinguir entre conocimiento y meras opiniones.

Además, para ser explícito, propongo que pensar arquitecturalmente está ligado de manera directa con el autocultivo necesario para realizar estrictos escrutinios críticos. Pero esa relación no agota los modos de pensamiento relacionados. Los modos de pensar en la categoría del orden superior, i.e., la metacognición, cooperan entre sí necesariamente: el pensar creativo, el pensar crítico, el pensar solidario –por mencionar algunos– interactúan por demanda en un pensar arquitectónico.

Tuesday, November 14, 2017

Categorías de la realidad

Por favor, amable lector, tome conciencia de que la creación de soluciones de negocio basadas en software no es ni ingeniería civil ni es arquitectura. Por lo que las analogías con esas otras disciplinas son tan sólo eso: analogías, las cuales deben evaluarse y no transferirse como conclusiones aplicables directamente a nuestra profesión.

Una de las palabras de moda, entre otras, parece ser “ágil”. No pocos publicistas abusan de esa palabra al adherirla sobre aquello que quieren vender. Si su objetivo ahora fuese vender espejos, entonces a los mismos espejos de siempre, los mismos que vendían, por ejemplo, con la etiqueta de “orientados a objetos”, ahora los anuncian como “espejos ágiles”. Algo similar puede ocurrir con otras palabras de moda, como “microservicios”.

Por ejemplo, recién inicié una lectura crítica del libro a continuación: Agile People: A Radical Approach for HR & Managers (That Leads to Motivated Employees). Mi evaluación preliminar del mismo es favorable. Aunque, como la palabra “agile” está en el título, evaluaré más a fondo si se trata del artilugio de marras para vender más libros o sí discurre sobre algo substancial. Además, un riesgo muy peligroso es que su título sea malinterpretado y termine por alentar prejuicios y etiquetas sobre las personas: “esta persona es ‘ágil’ o aquella otra persona no es ‘ágil’” —¿ve usted las peligrosas implicaciones de que alguien incompetente tome decisiones con base en tales prejuicios?

«El hábito no hace al monje» —dicen por ahí. Digámoslo así: una es la apariencia y otra es la realidad subyacente. Una es la forma y otra es la materia de dicha forma. Ambas categorías son partes de un todo y ambas son relevantes, en tanto no se tome lo uno por lo otro. Una cosa es el semblante superficial, contingente; y otra cosa es la substancia necesaria, la que hace emerger aquel semblante. Si se enfoca en lo substancial, entonces puede usted planear que el semblante emergerá por sí sólo. Si se enfoca sólo en lo superficial, e.g., sólo en el uso de las palabras “correctas” sin el comportamiento correspondiente, entonces podría usted estar construyendo sobre arena y entonces no se sorprenda de que lo substancial nunca ocurra en los hechos de la realidad objetiva.

Le invito a iniciar conversaciones sobre los rasgos profesionales de la creación de soluciones de negocio basadas en software y –aún más importante– le invito a mantener esas conversaciones abiertas, sin intentar cerrarlas y sin considerar las cuestiones clausuradas por completo.

Saturday, October 14, 2017

Profesionalización

Quizá un camino que se aproxima más a la profesionalización, en el sentido de ejercer a cabalidad una ciencia o un arte, sea precisamente no buscar la profesionalización entendida como recorrer grados académicos y ascender estructuras jerárquicas, sino mantenerse como un devoto aficionado a la curiosidad propia y al aprendizaje; especialmente si ese aprendizaje es cooperativo, en conversación y en discusión con otros, sin ortodoxias académicas ensimismadas y desapegadas del resto del mundo.

Por fortuna yo no perdí tiempo estudiando filosofía en ninguna institución. Me hubiera sucedido lo que a Jonathon Keats, lo cual es lo mismo que ya he hecho en varias ocasiones: abandonar instituciones que pretenden tener el monopolio de la verdad ya sea en política, historia, ciencia, religión o en otras áreas de mucho interés para mí; como la creación de soluciones de negocio basadas en software.

What the World Needs is More Curious Amateurs.

Saturday, October 07, 2017

Hermenéutica en software

El otro día fui a esta conferencia sobre la vida y, principalmente, la obra literaria de Antoine de Saint Exupêry.

¿Será descabellado decir que para mí ese tipo de material representa parte de mi “capacitación” profesional en creación de soluciones de negocio basadas en software?

Dicho así, sin justificación, no es claro y cabe la duda sobre cómo estarían relacionados esos dos temas, lectoescritura y creación de software, tan dispares en apariencia.

Por un lado, he visto lo que la lectoescritura le puede hacer a una persona en términos de transformarle la mentalidad —para bien o para mal, pues el resultado no siempre sería miel sobre hojuelas—. Aquí opera la destreza básica para interpretar un texto: entre mayor destreza, más jugo se le saca al texto. Por lo que una interpretación a la ligera no es lo mismo que una interpretación más pensada.

La obra «El principito» de de Saint Exupêry es un caso de excesiva mercantilización y de muchas interpretaciones a la ligera. No es una obra escrita para infantes, sino una catarsis melancólico-existencial repleta de añoranza. Por lo que me ha interesado tomarla, entre otras obras, para ejercitar mis capacidades interpretativas o hermenéuticas e intentar sacarle más jugo. Por ejemplo, ¿quién o qué simboliza la rosa? ¿Qué o quién es el zorro? ¿Y el cordero? Etc. Hay variedad de posibles respuestas en función del sistema de interpretación utilizado. Nuestra destreza interpretativa, por tanto, depende de cuántos sistemas de interpretación conozcamos y seamos capaces de aplicar a textos concretos.

Por el otro lado, creación de software como profesión tiene textos fundacionales que son muy importantes y que debemos interpretar cada vez más y mejor. De eso, en parte, depende un mejor entendimiento de nuestra profesión y del jugo que le sacamos a la aplicación práctica de las ideas en esos textos. Tan sólo por mencionar unos ejemplos de esos textos:

(1) The Art of Computer Programming (TAOCP)

(2) Structure and Interpretation of Computer Programs, Second Edition

Editorial

Curso

(3) Managing the development of large software systems: concepts and techniques

A este último texto se le atribuye establecer el inicio histórico del modelo en cascada para desarrollo de software; sin embargo, tal texto fue interpretado muy a la ligera y en realidad constituye —según el propio autor— una refutación en contra de dicho modelo.

Adivine usted qué, amable lector: lo mismo aplica para los textos que contienen ideas clave en temas como Agile, o Scrum, o Domain-driven design, o micro-servicios, o IT social sentiments, o Machine Learning, o Big Data, etc.

Le pregunto: ¿Logré explicar algo, en general, del porqué es relevante, profesionalmente, mejorar nuestras destrezas para interpretar textos?

Procesos de aprendizaje

¿Qué clase de cambios son pertinentes en una transformación cultural para la mejora en creación de soluciones de negocio basadas en software?

Dado el tipo de trabajo que está íntimamente involucrado en los procesos de dicha creación —es decir, el trabajo de tipo intelectual—, una clase pertinente de cambios, por ejemplo, serían cambios en los procesos de aprendizaje. Es decir, cambios en los procesos por los cuales las ideas se hacen parte de la mentalidad, y de la conducta, de las personas involucradas. Distinción relevante: aquí me refiero al aprendizaje, no me refiero a la enseñanza.

El aprendizaje está, principalmente, en manos del aprendiz. Por lo que el cambio particular que aquí propongo es intentar una mayor conciencia por parte del aprendiz sobre sus propios procesos de aprendizaje. Si el aprendiz logra una mayor conciencia de los tipos de pensamiento aplicables durante su recorrido en un tema dado, entonces esa mayor conciencia de sí mismo podría ayudarle a sopesar las oportunidades para aplicar adecuadamente, por ejemplo, el pensamiento dogmático, el pensamiento crítico y el pensamiento creativo. Ver referencia: El progreso de un aprendiz, más adelante.

Hay teorías del aprendizaje que distinguen entre datos, información y conocimiento pues, aunque están muy relacionados entre sí, en realidad son distintos en la estructura cognitiva del aprendiz. Los dos primeros se pudiesen transmitir por medio de los imperantes y cortoplacistas esquemas escolarizados, pero el tercero no es transmisible y lograrlo está por completo en manos del aprendiz.

El progreso de un aprendiz

—Edición 2015: http://agilidad.blogspot.mx/2015/01/el-progreso-de-un-aprendiz.html

—Edición 2009: https://blogs.msdn.microsoft.com/destreza/2009/10/30/el-progreso-de-un-aprendiz/

Saturday, September 30, 2017

Análisis preliminar retrospectivo de decisiones de diseño

Líderes en la industria del desarrollo de software:

Por favor solicito unos minutos de su tiempo para hacer juntos un análisis preliminar retrospectivo de la decisión arquitectónica X en el proyecto Y. Pero aún más importante, para intentar juntos un análisis crítico retrospectivo de la madurez a la fecha del tipo de proceso arquitectónico que derivó en tal decisión y su correspondiente nivel de calidad. Dado el potencial derroche de tiempo y recursos de negocio asociado a tal decisión es necesario sopesar la posibilidad de tal decisión como defectuosa y, por tanto, sea necesario hacer ajustes en el proceso que la generó. Dado el nivel de impacto que un ejercicio de arquitectura tiene sobre un proyecto, y dados otros antecedentes de decisiones similares en otros proyectos pasados, sugiero repensar el proceso de arquitectura actual y repensar el tipo de dependencias entre grupos de trabajo que existe actualmente en dicho proceso.

Para lograr una cadena de liberaciones productivas de valor de negocio con calidad por arriba del promedio se requiere considerar procesos y dependencias de un tipo por encima del promedio.

El punto prospectivo principal que propongo discutir es el análisis, diseño, ejecución de pruebas y evaluación de la correspondiente evidencia para confirmar la calidad tanto del requerimiento de negocio —e.g., exactitud en reglas de negocio, oportunidad del caso de negocio, etc.— como de las decisiones en un proceso arquitectónico con una madurez quizá por arriba de los procesos imperantes no sólo de manera local, sino en la infanta industria de la creación de soluciones de negocio basadas en software.

Saludos y gracias.

I make mistakes, and want a safety net.Continuing lessons from my mistakes