Share via


Conciencia en nuestra preparación técnica

¿Qué es el desarrollo de la conciencia en nuestra preparación técnica como miembros de la industria del software?

Buscamos mejorar en cómo crear soluciones basadas en software que entreguen valor de negocio para nuestros clientes y para nosotros. Sin embargo, el cómo lograr dicha mejora no cuenta con una respuesta mágica o una receta fácil y simplista, por ejemplo “todo el conocimiento requerido se adquiere logrando certificaciones”. Por el contrario, existe una pluralidad de perspectivas y directrices para mejorar en destreza técnica tan sólo dentro de Custom Application Development. Lo que resulta muy valioso en el contexto de un proyecto puede no serlo fuera de ese contexto. Para que el individuo logre distinguir los buenos principios y prácticas —que apliquen en el contexto dinámico del entorno— requiere formarse una vista de conjunto de tal pluralidad de perspectivas. Además, el individuo requiere guiar su conducta por medio de juicios balanceados sobre tales perspectivas, juicios basados en hechos y no en mitos o mensajes de mercadeo.

Formarse una vista de conjunto, integrarse un juicio balanceado basado en hechos, son habilidades nada triviales que requieren entrenamiento y preparación (readiness). Asumir que tenemos tales habilidades o que ya las tenemos debidamente desarrolladas, o que no tenemos más por aprender al respecto, es tropezarse seriamente en el camino del desarrollo intelectual. Por tanto, esas y otras habilidades que suelen darse por sentado en realidad forman parte del fundamento sobre el cual desarrollar no sólo un Technical Readiness for Custom Application Development sino la preparación continua para la vida en general.

Lo más importante de un plan para Technical Readiness es estimular a las personas para que piensen por sí mismas:

“La meta principal de la educación es ayudar a los individuos a ser capaces de realizar cosas nuevas, no simplemente repetir lo que han hecho otras generaciones; sino individuos que sean creativos, inventivos y descubridores, que puedan ser críticos y verificar, y no aceptar, todo lo que se les ofrece” —Jean Piaget, autor ampliamente reconocido en pedagogía y epistemología.

Los medios dentro de un plan personal para Technical Readiness que sea concienzudo y de no poca monta, por tanto, incluye la práctica y la aplicación de los patrones intelectuales de la investigación científica, del pensamiento crítico, de la argumentación, del debate, del pensamiento creativo y del pensamiento filosófico. Puede no ser esto una respuesta fácil sobre la cual sostener una esperanza barata de que ya estamos del todo desarrollados como profesionales y que tan sólo nos hace falta un poco por aquí y por allá. Puede no ser lo que queremos oír, pero con un poco de reflexión sobre el estado de las cosas a nuestro alrededor, podríamos aceptar que sí es lo que necesitamos oír.

Para estar a la altura del papel que juega la industra de software en el mundo, un plan serio de Technical Readiness necesita enfatizar el desarrollo de la conciencia a nivel individual, incluyendo individuos en posiciones de autoridad. La importancia de esto se puede constatar, por ejemplo, al reflexionar sobre las creencias de quien ha quedado inerme ante la propaganda de una sola perspectiva como “la mejor”. Al no tener manera para identificar las implicaciones, costos y beneficios de una manera proporcionada terminan por incurrir en excesos que eclipsan la supuesta buena intención original de tal perspectiva. Las posiciones religiosas y dogmáticas acerca de iniciativas que prometen resultados mágicos, acerca de la supuesta ingeniería de software y del mito de su predictibilidad, o acerca del desarrollo ágil presentado como panacea, o acerca de la completitud de la presente iniciativa, son ejemplos de lo que se debe evitar. Es decir, las ideas recién mencionadas tienen aspectos positivos, pero percibirlas dogmática y religiosamente es el efecto problemático al no contar con una conciencia desarrollada.

Por ejemplo, la creación de soluciones de negocio basadas en software es una actividad cuyos rasgos esenciales no la colocan por completo como una disciplina de ingeniería que provea los medios para la industrialización y la manufactura automatizable. Sin embargo, al creer que la actividad se trata de una ingeniería, entonces se espera la predictibilidad correspondiente. Este ha resultado ser el caso de un exceso que ha llevado a malbaratar el esfuerzo en proyectos al tratar de formalizar procesos donde no tiene sentido formalizarlos. Por ejemplo, al tratar de establecer una línea fija entre las actividades de análisis y diseño como si fuesen etapas distinguibles y separables. Sin mencionar la enorme cantidad de esfuerzo que se dedica en crear documentación que nadie termina leyendo en lugar de enfocar dicho esfuerzo en producir valor de negocio en forma de working software. En retrospectiva, la perspectiva de ingeniería ha sido un intento para obtener predictibilidad a costa de efectividad. Mientras que lo que necesitamos buscar son procesos confiables, con los cuales se pueda contar con la calidad de lo producido. Un pilar de tales procesos confiables es la adaptabilidad con la que se responde a las condiciones cambiantes del entorno. Se recomienda considerar la exposición que hace Jim Highsmith en su obra: Agile Project Management: Creating Innovative Products, Second Edition.