¿Por qué hablar de profesionalismo?
Cuando la profesión principal de un negocio hace uso de otras profesiones a veces la interacción no resulta tan clara y ocurren desencuentros, malentendidos o expectativas insatisfechas. En la búsqueda por la claridad en la interacción entre profesiones en ocasiones puede ser útil una sana controversia que promueva valoraciones críticas balanceadas y justas. La siguiente conclusión preliminar tiene la intención de promover la discusión racional sobre el profesionalismo en desarrollo de software en un contexto de negocio.
Riesgos de negocio y rendición de cuentas
Cada vez más empresas suelen tener al menos un departamento o una área de «Tecnologías de información (TI)» pues han determinado que necesitan aplicar la computación electrónica para los fines de su negocio. Si la administración de un negocio sigue la regla básica de mantenerse en su giro comercial y no desenfocarse en esfuerzos dispersos, entonces una pregunta prudente que no debe olvidarse es: ¿representa mi área de TI sólo un centro de costos o es un activo que permite mejores resultados empresariales?
Algunas áreas de TI también son responsables de desarrollar software aplicativo; es decir, el software concreto que procesa la información empresarial con las reglas del negocio en particular. Para crear dicho software la empresa decidirá entre contratar servicios externos o agregar programadores a su nómina, o un esquema mixto.
La decisión de agregar programadores a la nómina implica que además de conocer el giro principal del negocio ahora se requiere conocimiento sobre cómo administrar la actividad de programación de computadoras. Cuánto conocimiento adicional se requiere está en función de cuánta responsabilidad tendrían los programadores internos. Si el esquema de tal decisión es mixto y deja la mayor parte de la responsabilidad de crear el software empresarial en manos de un grupo externo de profesionales, entonces la empresa requiere menos conocimiento que si la mayor parte de dicha responsabilidad quedase en las manos del grupo interno.
Un esquema atinado tiende a designar la mayor parte de la responsabilidad a quien demuestra la mayor parte del profesionalismo; o sea, que cada quien se dedique a lo que mejor sabe hacer y en lo que mejor pueda rendir cuentas. Lo cual coincide con una regla básica de empresas exitosas: conoce tu oficio.
Si un esquema designa la mayor parte de la responsabilidad al grupo interno, entonces se requiere de una estrategia para el crecimiento profesional y para la retención del talento interno; de otra manera la cantidad de riesgo de negocio aumenta debido a un conocimiento subdesarrollado en la materia. Programar computadoras en el contexto de un negocio puede llamarse «creación de soluciones de negocio basadas en software» y profesar tal actividad, como cualquier otra profesión, requiere desarrollo constante de conocimientos. En otras palabras, un negocio sin profesión pone sus resultados en mayor riesgo.
Datos, información y conocimiento
Aquí hay otro riesgo que debe ser debidamente administrado: el primer tropiezo que hay que evitar es confundir conocimiento con información o con datos. Los datos pueden transmitirse de persona a persona e incluso transmitirse de manera electrónica. La información es una interpretación subjetiva de dichos datos. Por otro lado, el conocimiento humano no es algo que pueda transmitirse sino sólo puede ocurrir al desarrollarse de manera personal; es decir, el conocimiento ocurre en la persona que logra un entendimiento de algún aspecto de la realidad objetiva, la cual es intersubjetiva y verificable con independencia de cómo nos gustaría o quisiéremos que fuese esa realidad.
El conocimiento humano es algo que requiere elaboración y desarrollo paulatino (como el caso de software complejo) y no algo que pueda generarse de manera instantánea (aunque hay casos de software simple que sí es generable instantáneamente por medio de software más complejo).
Arquitectura empresarial
Por supuesto, una empresa de mayor tamaño requiere la coordinación de un mayor número de profesiones. De ahí la necesidad de algo llamado ‘arquitectura empresarial’ o la acción de diseñar una empresa en su contexto de mercado, sus profesiones y sus procesos, sus modelos financieros, etc.
Si una empresa apuesta en serio por contar con su propia capacidad empresarial para crear software, entonces deberá también apostar por la profesionalización interna de tal actividad. Es decir, por el desarrollo interno de profesionales de la creación de soluciones de negocio basadas en software y no sólo contar con departamentos de IT que justifiquen el argumento de Nicholas Carr en su artículo «IT Doesn't Matter» de mayo 2003 en Harvard Business Review.
Profesionalismo en desarrollo de software
Hasta donde alcanzo a ver a la fecha, y por mucho que sea la sorpresa inicial, aún no está claro qué tipo de profesión es la creación de software; pero si revisamos su incipiente historia de apenas 60-70 años entonces la sorpresa disminuye. No es una disciplina de ingeniería, y no pocos autores demuestran porqué nunca lo será, pero sí requiere la constante aplicación de conceptos ya bien definidos a situaciones concretas. No es del todo una ciencia que entendamos ya por completo y con la que se pueda controlar y predecir con exactitud toda causa y efecto relacionado, pero sí requiere mucha abstracción y conlleva patrones de pensamiento lógico-matemático. No es del todo un arte que sólo pocos iniciados puedan realizar sino que hoy en día está al alcance de muchos. Crear soluciones de negocio basadas en software es quizá aún una artesanía en evolución en forma, por ahora, de un oficio cuasi-gremial.
Sin embargo, una empresa necesita aprender a identificar a los practicantes de ese gremio artesanal, ya sea para reclutarlos o para referirlos durante el desarrollo de su propio talento interno. Un rasgo a identificar es la coherencia entre lo que piensan y lo que hacen; lo importante es no sólo decirse profesional de la programación de computadoras, sino demostrarlo con la liberación y la evolución sostenida de software de calidad que resuelva problemas a un negocio o le habilite nuevas oportunidades.
Una empresa puede identificar a quienes están en el giro de la creación de soluciones de negocio basadas en software por la calidad del software que son capaces de entregar. Son profesionales cuyo giro de negocio depende de crear confianza en la calidad de su software y suelen carecer de una red corporativa de emergencia que les cobije en caso de mala calidad. Tales practicantes, por medio del ejemplo, suelen contribuir semillas de lo que llevaría a esta artesanía a ser una profesión conocida y respetable —no parece que esta industria esté en ese punto aún; por ejemplo, es muy difícil todavía relacionar lo que hace un programador con lo que hace un neurocirujano, a pesar de que ambos manipulan cerebros con sus propias manos, ya sea un cerebro basado en silicio o uno basado en carbono, respectivamente.
La dimensión de la complejidad que conlleva la creación sostenible de soluciones de negocio basadas en software es tal que le exige respeto a quien la contempla y le invita a la humildad. Por lo que otro rasgo de un practicante es que cultive activamente su propio nivel de conciencia sobre tal complejidad y en aprender cómo otros la abordan y la administran de manera sostenible. Por tanto, nadie que afirme altivamente dominar por completo esta profesión es realmente un practicante del gremio aludido aquí; por supuesto, puedo estar equivocado.
Además del cultivo personal, un practicante se enfoca también en el cultivo de otros practicantes a su alrededor a través de valores como el diálogo, la comunicación y la cooperación sobre aspectos de la profesión compartida. Cada voz cuenta y es preferible hablar cara a cara con regularidad en lugar de sólo a través de documentos. Someter las ideas y el trabajo propios a la crítica de otros y escucharles con atención es un hábito del profesional practicante; así como realimentar lo más atinadamente posible a los demás.
El desarrollo del profesionalismo implica muchas cosas que giran alrededor de los efectos y acciones derivadas del verbo «profesar», entre lo cual, en este caso, está la intersección entre ingeniería, ciencia y arte.
Referentes
Los practicantes del gremio aquí aludido suelen investigar con esmero y aprender de las obras de diversos autores profesionales en la materia. Algunos de esos autores a lo largo de la historia de esta profesión han sido: Edsger W. Dijkstra, Kristen Nygaard, Niklaus Wirth, Ole-Johan Dahl, Dennis M. Ritchie, Donald E. Knuth, C.A.R. Hoare, Bjarne Stroustrup, Larry L. Constantine, Alan Kay, Bertrand Meyer, Adele Goldberg, Frederick P. Brooks, Jr., David L. Parnas, Tom DeMarco, Gerald M. Weinberg, Tom Gilb, Barry Boehm, Winston W. Royce, Caper Jones, Jim Gray, David Harel, Barbara Liskov, Rebecca Wirfs-Brock, Peter Coad, Sally Shlaer, Stephen Mellor, Andrew Koenig, Ivar Jacobson, Grady Booch, Ward Cunningham, Robert C. Martin, Erich Gamma, Jeff Sutherland, Kent Beck, Dave Thomas, Ken Schwaber, Andrew Hunt, Steve McConnell, Alistair Cockburn, Jim Highsmith, etc.
Conclusión preliminar
En conclusión, si al arquitectar una empresa se contempla contar con la capacidad de crear soluciones de negocio basadas en software, entonces también se necesita profesionalizar tal función de manera interna. La profesión de crear soluciones de negocio basadas en software, como parte de una empresa o como negocio por sí mismo, suele emerger con pauta propia y sus practicantes pueden identificarse por la calidad de su software, por su auto-cultivo y por su trabajo cooperativo.
