El Blog de Pablo Fernando Sanchez

Esta es mi bitácora personal, en la cual trato, sin limitarme a ello, sobre ingeniería de software, ingeniería de sistemas, gestión estratégica, modelado de procesos, metodología, aseguramiento de la calidad, gestión del conocimiento y todos esos asuntos que hacen, desde la gerencia y la técnica, a las empresas que asesoro.

Acerca de mí...

Mi foto

Experto en Gestión de Sistemas y Procesos de TI

Herramientas

KPI Dashboard

Blogs Amigos

En Otros Blogs

Estas son algunas entradas en otros blogs inscriptos en Bitacoras.com en las cuales me citan:

Leo en la Wikipedia que un oxímoron es «una figura literaria que armoniza dos conceptos opuestos en una sola expresión, formando así un tercer concepto que dependerá de la interpretación del lector. Dado que el sentido literal de un oxímoron —por ejemplo, un instante eterno— es absurdo, se fuerza al lector a buscar un sentido metafórico —en este caso, un instante que, por la intensidad de lo vivido durante el mismo, hace perder el sentido del tiempo». Pues bien, soy de la opinión que, aunque parezca un oxímoron en función de lo que nos tiene acostumbrado el mercado, no tenemos que oponer a los métodos ágiles y al Capability Maturity Model Integration (CMMI) —en su rol de representante de los métodos tradicionales— en una expresión como la del título. Ese aparente oxímoron diría: «¡métodos ágiles y CMMI!». Y digo aparente, porque en realidad no lo es.

Explico. Creo que...

  • la industria está plagada de tecnócratas desorientados, quienes en lugar de hacer ingeniería están más pendientes de apoyar hasta el fin ciertos inexplicables fanatismos personales, lo cual nubla la visión abierta que DEBE tener un ingeniero, y...
  • CMMI puede convivir perfectamente con métodos ágiles —al contrario de cómo se esfuerzan en demostrar, no son para nada opuestos.
Está bien, tal vez fui duro con la afirmación del primero de los puntos, pero la verdad es que ocurre... Veamos... Yo me casé una sola vez, con mi esposa y para toda la vida. Este es el único marco en el que acepto esto de casarse. Hay gente que, literalmente, se «casa» con una tecnología —sin siquiera cobrar por ello— exhibiendo una intolerancia general hacia las ideas de los otros. En todas sus formas, esta actitud de adversarios además de no ser razonable, es contraproducente para la tarea que se tiene entre manos: desarrollar software de la más alta calidad en el menor tiempo posible.

Que software libre, que software propietario, que métodos ágiles, que métodos tradicionales, que enfoque estructurado, que enfoque orientado a objetos, que tecnología de objetos, que Microsoft Visual Basic, que Java, etcétera. Vergonzoso... Las tecnologías están para que nosotros, los seres humanos que incurrimos en la ingeniería —seamos o no ingenieros—, las aprovechemos como mejor nos convenga... Nada más... Cada una de ellas puede convivir perfectamente con otra, si el proyecto lo justifica. No podemos ser fanáticos inquisidores en este marco. El fanatismo está para otras áreas en las cuales la lógica es distinta: fútbol, política, religión, etcétera. Pero no nos podemos permitir fanatismos en términos profesionales e ingenieriles.

Ahora bien, dejo de «hacer amigos» —aunque conozco muchos profesionales que me inspiran el más profundo de los respetos y que concuerdan con lo expresado— para focalizarme en la segunda de las afirmaciones, eso de que «CMMI puede convivir perfectamente con métodos ágiles».

En primer lugar, el Software Engineering Institute (SEI) de la Carnegie Mellon University, que es la entidad titular de los derechos de evaluación del modelo CMMI, no dice que tenemos que hacer todo lo que plantea dicho modelo. A pesar que CMMI puede aplicarse tanto en organizaciones grandes como en pequeñas, estas últimas suelen carecer, en gran medida, de los recursos y el conocimiento requerido para iniciar un proceso de mejora basado en CMMI.

Como CMMI es un modelo, por definición no es perfecto. Las prácticas del modelo necesitan ser interpretadas a la luz del trabajo a realizar y ser escaladas para proveer valor, no sobrecarga. Tenemos que ser lo suficientemente coherentes en nuestras labores de ingenieros para detectar aquellos puntos que nuestra organización no necesita o que en función de sus procesos no le conviene cubrir. Si hacemos esto y lo podemos justificar —cosa que no es negociable—, la evaluación arrojaría que es válido. Por lo tanto, podemos y debemos ajustar el modelo a nuestras necesidades particulares.

Por otro lado, al tiempo que CMMI da ejemplos de procesos y prácticas a nivel organizacional, no provee detalles específicos para los desarrolladores de software y los equipos que integran. Allí es donde entran en juego modelos de un nivel más bajo que ayuden a implementar las prácticas identificadas en CMMI. Ejemplos de ellos serían el Personal Software Process (PSP) y el Team Software Process (TSP), los cuales fueron desarrollados también dentro del SEI allá por 1998 por Watts Humphrey para complementar el «qué hacer» del CMMICMM en ese entonces— y acelerar la adopción proveyendo el «cómo hacerlo». Eso mismo se puede lograr mediante muchos y distintos modelos existentes, o nuevos o híbridos por modelar para el caso.

Además, también conviene complementar o extender CMMI con otras iniciativas de mejor práctica como las prácticas de línea de producto, la gestión del valor ganado —o «Earned Value Management» (EVM)—, sistemas basados en COTS, adquisición, mercadeo, Six Sigma, ISO 9001 y un amplio etcétera.

Más allá de su reputación, CMMI, PSP y TSP cubren el optimismo infundado, la irresolución de cronogramas y las metas no cumplidas en una forma ágil. Esta conclusión surge si comparamos los enunciados del «Manifiesto Ágil» con TSP, por ejemplo. Las relaciones son claras, pero por supuesto: tenemos que saber un poco de CMMI, PSP, TSP y agilidad para notarlo. En próximos artículos detallaré este asunto. Por ahora, lo dejo para que quien lo desee investigue un poco.

Tomar nota explícita de cosas malas que pueden ocurrir (riesgos) y planear de acuerdo a ellas es un indicador de madurez. Pero esa no es la forma en que tendemos a usar la palabra madurez en la industria de tecnologías de la información. Nosotros, la gente de software, tendemos a igualar madurez con competencia técnica. Incluso tenemos un esquema de cinco niveles para medir tal madurez, el Capability Maturity Model (CMM). (Todo lo que necesitamos ahora es un programa de doce pasos para ayudarnos a destetarnos de medir la madurez en un esquema de cinco niveles.) Pero la palabra madurez en castellano estándar no tiene nada que ver con la competencia técnica. Es, en cambio, una cualidad de crecimiento, un indicador de que una persona u organismo ha alcanzado el estado adulto.

—Tom DeMarco y Timothy Lister,
«Waltzing With Bears: Managing Risk on Software Projects»
(Dorset House, 2003)

Nota: Original en inglés.

Tal como lo reportó el Software Engineering Institute (SEI) de la Carnegie Mellon University y oportunamente reseñó Juan Palacio en Navegapolis, ha sido liberada la versión 1.2 del Capability Maturity Model® Integration (CMMI). CMMI 1.2 incluye mejoras significativas a todas las porciones del CMMI Product Suite dando así respuesta a asuntos que fueron surgiendo en la práctica con la versión anterior. Los cambios hacen foco en mejorar la calidad de los productos CMMI y la consistencia con que son aplicados.

Este paquete, el CMMI v1.2 Product Suite, está compuesto por los siguientes elementos:

  • Modelo CMMI para Desarrollo —o «CMMI for Development (CMMI-DEV)», como se llama ahora—, versión 1.2.
  • La versión 1.2 de sendos productos para la evaluación CMMI —la famosa «Appraisal»—: requerimientos para la evaluación CMMI —o «Appraisal Requirements for CMMI (ARC)»— y el documento de defición del método de evaluación SCAMPI A —o «SCAMPI A Method Definition Document».
  • Curso introductorio a CMMI versión 1.2 —o «Introduction to CMMI V1.2 course».

Básicamente y para quienes ya conocen la versión anterior de CMMI, entre las mejoras al modelo se desatacan:
  • Ambas representaciones, escalonada y continua, ahora están juntas.
  • Fueron eliminados los conceptos de «práctica avanzada» y «característica común».
  • El objetivo genérico y las descripciones de las prácticas fueron movidas a la parte dos.
  • Fueron agregadas ampliaciones con respecto a hardware y ejemplos.
  • Todas las definiciones fueron consolidades en el glosario.
  • Las prácticas de Integrated Product and Process Development (IPPD) fueron consolidadas y simplificadas. No hay más áreas de proceso separadas para IPPD.
  • Se han consolidado Supplier Agreement Management (SAM) e Integrated Supplier Management (ISM), y se ha eliminado el anexo de Supplier Sourcing.
  • Fueron agregadas elaboraciones de prácticas genéricas a las prácticas genéricas de nivel 3.
  • Se agregó una explicación sobre cómo las áreas de proceso apoyan la implementación de prácticas genéricas.
  • Fue agregado material para asegurar que los procesos estándar sean desplegados en los proyectos desde su inicio.

Puede descargarse una presentación con un detalle de estos cambios al modelo desde el sitio web del SEI. También hay mejoras sustanciales para el método de evaluación SCAMPI y para las cuestiones relacionadas con los entrenamientos, que tendremos que actualizar quienes hemos tomado cursos sobre la versión anterior.

Como bien mencioné, esta liberación corresponde a CMMI para Desarrollo; lo que queda pendiente para 2007 es CMMI para Servicios. A esto podemos sumarle el módulo adicional para adquisiciones. Más detalles al respecto en la página de modelos y módulos de CMMI en el sitio web del SEI.

Siguiendo el planteo iniciado hace un par de semanas, presento a continuación una serie de enlaces a artículos de distintas fuentes de información que me han resultado interesantes y que están relacionados con la temática del mío. Les comparto mi índice:

  • Aunque fue publicado hace cerca de dos semanas, creo que este es uno de esos artículos imprescindibles y merece que lo reseñe en este espacio. El reportero Charlie Babcock lo escribió en Information Week y da un listado justificado con los doce (12) mejores productos software jamás escritos. Bajo el título «What's The Greatest Software Ever Written?», Babcock toma la responsabilidad por lo correcto o equivocado que pueda estar el listado, aunque reconoce las opiniones y la asistencia de un alto número de personas, destacándose James Rumbaugh, Stuart Feldman, Ann Winblad, Zeev Suraski y Andi Gutmans, entre otros. Resumo en forma escueta este listado, que incluye: UNIX, System-R de IBM —producto de bases de datos predecesor de las bases de datos relacionales—, el software de secuenciamiento genético que desarrollaron en el Institute for Genomic Research, el sistema operativo IBM System 360 —el primero de propósito general de la historia—, el lenguaje Java —significativo, pues es el único lenguaje de programación en el listado—, el navegador web Mosaic, el sistema de reservas de vuelos Sabre de American Airlines, el sistema operativo Macintosh, Excel —catalogada como una implementación robusta y de potencia industrial de Visicalc—, el sistema de guía de las naves espaciales Apollo, el software de calificación para búsquedas de Google y el gusano Morris. Por supuesto, podemos diferir con este planteo —yo difiero en algunos ítems, como la no inclusión de Colossus, que fue empleado por los Aliados para romper el código nazi de Enigma durante la Segunda Guerra Mundial, por ejemplo—, pero insisto en que el reportero justifica muy bien la selección y es válida en este marco.
  • Tim Bryce escribió en Management Visions, su blog, un planteo sobre la importancia del diseño lógico en el análisis de sistemas de información. El artículo, que está en inglés, trata cuestiones definitorias y nos da un paseo por temas como la reingeniería apuntada a la implementación de Service Oriented Architecture (SOA), los recursos de información en términos de componentes —negocio, sistema y datos— y la lógica de negocio, se titula «Logical vs. Physical Design: Do You Know the Difference?».
  • Sherman E. DeForest publicó en Lockergnome un muy buen artículo —en inglés— titulado «Inductive Reasoning and Why we Must be Careful of Success», en el que hace un interesante análisis sobre el razonamiento inductivo, su combinación con el deductivo y su aplicación al proceso de toma de decisiones.

Desde que comencé con este blog me han venido preguntando sobre las comunidades virtuales que menciono en la barra lateral de este sitio o menciono cuando aplica en mis artículos. Es por ello que se me ocurrió publicar el siguiente listado de comunidades virtuales alineadas a la temática de este espacio y con las que, de alguna forma, tuve y/o tengo algo que ver:

Gestión y Gerencia (Management)

Ingeniería

Desarrollo

Bases de Datos

Aplicaciones

Espero que estas referencias les sean útiles. Cuentas con múltiples funcionalidades, como publicación de mensajes tipo foro, espacio para almacenamiento de archivos —en los que suele haber documentación relacionada con el tema que se trata—, álbumes de fotos, enlaces, encuestas, etcétera.
Si quieren recomendar alguna otra comunidad virtual, pueden hacerlo mediante comentarios a este artículo.

Estas fotografías son viejas ya, pero estuve revisando mi álbum y noté que no había tenido la oportunidad de publicarlas con anterioridad, por lo cual decidí aprovechar este espacio. Las mismas corresponden a la «Reunión Regional 2005» de la Región 9 del IEEE, América Latina y el Caribe, de la que tengo el orgullo de haber participado del 17 al 19 de marzo del año pasado en la ciudad de Santiago de Chile.

En la primera me encuentro junto a Luiz Alberto da Silva Pilotto (Brasil), en ese entonces Director Electo y actualmente Director de IEEE Región 9, y a Marc Apter (Estados Unidos de América), el Vicepresidente a cargo del Regional Activities Board (RAB) del IEEE.

En la siguiente, estoy en conversación con Gustavo Giannattasio, el entonces Presidente de IEEE Sección Uruguay.

En la tercera, estoy al micrófono en la reunión, participando como Editor en Jefe y Presidente del Comité Editorial del NoticIEEEro, el centro de noticias de la Región 9.

En la cuarta fuimos fotografiados durante una charla con Cleon Anderson (Estados Unidos de América), el entonces Presidente del IEEE —sí, a nivel mundial— y hoy Pasado Presidente de la institución. La figura del Pasado Presidente es muy interesante, pues en la práctica desempeña funciones de apoyo con su experiencia al Presidente actual.

Luego, una foto que no es muy buena pues fue tomada desde una PDA por un amigo participante de la reunión quien desde Argentina me la pasó. En la misma estamos, durante el almuerzo de la segunda jornada, charlando con Francisco Martínez (México), el entonces Director Regional y hoy Pasado Director.

En la sexta foto estamos la delegación colombiana a pleno: Renato Céspedes (Colombia), Presidente 2005 del Consejo Andino de la Región 9; Michael Lightner (Estados Unidos de América), Presidente Electo 2005 del IEEE a nivel mundial; Luis Alberto Arenas, Presidente de IEEE Sección Colombia; y yo.

Por supuesto, si bien estoy viviendo en Colombia, también integré la delegación argentina: como muchos saben —en particular cuando me escuchan hablar—, soy argentino. En esta última fotografía estamos Ricardo Veiga (Argentina), entonces Presidente del Comité de Graduados de la Última Década (GOLD) de la Región 9, Norberto Lerendegui, Presidente de IEEE Sección Argentina, nuevamente Michael Lightner y yo.

A continuación, el álbum completo:



Para terminar, aclaro para quienes no estén al tanto. The Institute of Electrical and Electronics Engineers (IEEE) es la asociación técnico-profesional sin fines de lucro más grande del mundo, integrada por cerca de 400.000 miembros profesionales y estudiantes en 175 países. Su creación se remonta al año 1884, contando entre sus fundadores a personalidades de la talla de Thomas Alva Edison, Alexander Graham Bell y Franklin Leonard Pope. En 1963 adoptó el nombre de IEEE al fusionarse asociaciones como el American Institute of Electrical Engineers (AIEE) y el Institute of Radio Engineers (IRE). A través de sus miembros, el IEEE es una autoridad líder y de máximo prestigio en las áreas técnicas derivadas de la eléctrica original: desde ingeniería computacional —incluyendo las disciplinas específicas de las cuales ya hablé antes en este espacio—, tecnologías biomédica y aeroespacial, hasta las áreas de energía eléctrica, telecomunicaciones y electrónica de consumo, entre otras.

Esta semana, revisando la lista de productos sugeridos por una de las grandes librerías en línea de acuerdo a mis preferencias y las cosas que compré anteriormente, descubro «Dirigir las TI Como un Negocio», la edición en castellano del excelente «Managing IT as a Business: A Survival Guide for CEOs» de Mark Lutchen —el cual tengo y leí hace un tiempo, además de recomendarlo para aquellos que dominen la lengua de Shakespeare, pues se puede conseguir en oferta la versión en inglés, a buen precio. Esto me recordó algunos temas más que interesantes que hacen a esto de estar en el negocio de las tecnologías de la información y de la comunicación (TICs), pero que muchas veces no suele ser visto por quienes están del lado más tecnológico del asunto.

Primero que nada, ¿qué debería buscarse desde el lado de las empresas de TICs para sus clientes? Las respuestas a esta pregunta pueden ser muchas, aunque todas se podrían resumir en una: minimizar los riesgos clave del negocio. Lo importante en esto es no centrarnos exclusivamente en cuestiones de desempeño —típica visión tecnológica— y de costos —típica visión administrativo-financiera(-y-retrógrada-si-se-me-permite). En términos exclusivamente financieros, sabemos que es más importante tener un retorno aceptable de la inversión —el famoso «ROI»— que ver la cuestión como un simple costo o, según aplique, un simple gasto.

Más allá de esto, debemos ser lo suficientemente amplios al analizar el punto, pues es poco probable que algo como las TICs sean «exclusivamente algo». Entonces, si buscamos analizar la cuestión como un negocio, debemos involucrar en nuestro enfoque a disciplinas como las relacionadas con los negocios en sí, fiscales, presupuestarias, organizacionales, de mercadeo, de gestión, de inversión y de rendimiento en el amplio entorno de TI en la empresa, y cómo todas ellas aportan a la minimización de los riesgos mencionados.

Como suelo mencionar, muchas veces a la gente que está del lado técnico y académico de las TICs, les cuesta visualizar el negocio. En particular, qué es lo que buscan los clientes en las TICs. Nosotros podemos argumentar que, por ejemplo, un producto software que hemos desarrollado funciona bien, que fue modelado y programado correctamente, o que su desempeño es excelente, cosas con las que nuestros usuarios técnicos también se verán complacidos. Pero lo cierto es que quienes pagan por nuestro producto, por las TICs que proveemos, ven otras cosas, las cuales nosotros deberíamos manejar, mejorar y poder demostrar. Hay muchas encuestas que reflejan opiniones de empresarios sobre la forma en que miden el éxito de TI, pero siempre se destacan, entre otros, asuntos como:

  • Mi computadora y mi correo electrónico están funcionando.
  • No hay fallas catastróficas.
  • No hay llamados a medianoche.
  • El ROI u otras métricas financieras.
  • Que se complete el proyecto.
  • La contribución de TI al éxito del negocio.

Por supuesto, el eje central para poder dar un buen servicio en TICs es la gente, por lo cual debemos enfocar nuestros esfuerzos de gestión en nuestro equipo. Lo ideal es olvidarnos de etiquetas conceptuales como la de «Recursos Humanos» para alejar de la mente directiva su consideración en términos de recursos y apoyarse en técnicas como el «empoderamiento» —o «empowerment»—, aplanar un poco la estructura organizacional apostando a los equipos de trabajo interdisciplinarios como motores operativos, crear buenos modelos de incentivos, capacitación y mentorías dentro del plan estratégico, hacer evaluaciones periódicas y emplearlas como base para la mejora continua, entre otras cosas.

Por otro lado, puntualmente en el marco de las empresas de TICs, se hace fundamental estar a la vanguardia tecnológica. He visto empresas dedicadas al desarrollo de software que, por ejemplo, tienen infraestructura dedicada al desarrollo con características muy inferiores que la dedicada a tareas administrativas. Esto parece un despropósito, pero es la realidad en muchos ambientes —en los cuales, además, se suele culpar al personal operativo por ineficiencias que provienen más que nada de una pésima planificación estratégica. Si una empresa ofrece TICs, ¿no debería tomarlas en serio?

El tema es largo y da mucho para discutir; por supuesto, en futuros artículos seguiré tratándolo. Recomiendo nuevamente el libro de Lutchen que menciono al principio de este artículo y sugiero a aquellos interesados en estos asuntos participar de comunidades virtuales como Gestión de Departamentos de Cómputo, Sistemas, Tecnología y Automatización y Toma de Decisiones en el Ámbito de la Dirección Empresarial.

Hace unos días les contaba sobre la próxima realización de la «Segunda Jornada Técnica IEEE del Oriente Colombiano», organizada por IEEE Sección Colombia y la Rama Estudiantil del IEEE en la Universidad Francisco de Paula Santander (IEEE-UFPS), evento que se desarrollará el día viernes 1° de septiembre de 2006 en la ciudad de Cúcuta, Departamento de Norte de Santander, y del cual participaré como conferencista.

Disertaré en una conferencia dentro de las áreas de incumbencia de IEEE Computer Society, de título «Desarrollando Software de Clase Mundial: ¿Cuál es la Clave?», en la cual compartiré experiencias propias y de terceros al respecto. Hablaré sobre aseguramiento de la calidad, cuestiones a tener en cuenta relacionadas con el producto software, software propietario y libre, metodología, equipos de trabajo y usabilidad, entre otras cosas.

Para obtener más información e inscribirse en el evento, pueden acceder al sitio web de la Rama IEEE-UFPS o enviarle un mensaje de correo electrónico a Samuel Villamizar Berdugo, el Coordinador Local del evento.

Ayer, en la primera parte de este artículo, hice una introducción a esta filosofía práctica de gerencia llamada Balanced Scorecard en la cual, entre otras cosas, hablé sobre sus beneficios. Hoy continuo la introducción con los errores típicos, la definicón de objetivos financieros, los primeros pasos a dar y la aplicación de esta técnica a la gerencia de tecnologías de la información y la comunicación (TICs).

Comencemos, entonces, con los errores más comunes que cometen las empresas al implantar un sistema de Balanced Scorecard, los cuales suelen ser:

  • No tener una visión y misión clara.
  • No alinear los objetivos de la empresa con los de las áreas.
  • No alinear los objetivos de las áreas con los del personal.
  • Contar con objetivos subjetivos —sin indicadores numéricos.
  • Tener objetivos inalcanzables o poco realistas.
  • Tener objetivos subvaluados.
  • Poco apoyo y compromiso de la dirección y del personal.
  • No educar/capacitar al personal.
  • No alinear los resultados del Balanced Scorecard al estado de resultados.
  • No tener los procesos clave documentados con evidencias estadísticas.
  • Asignarle mayor importancia al software que a la técnica.
Los errores anteriores harán que el sistema del Balanced Scorecard implantado fracase de una manera rotunda.

Normalmente, en la mayoría de las organizaciones la implantación de un sistema de Balanced Scorecard lleva de 12 a 18 meses; no es un proceso sencillo ni rápido y requiere de atención, compromiso y mantenimiento, hasta generar una cultura de la medición en el personal.

Para ayudar al éxito del sistema de Balanced Scorecard, el personal debe estar capacitado y entrenado en:
  • Herramientas básicas de calidad.
  • Mapeo de procesos —diagrama de flujo de los mismos.
  • Auditorías de calidad —procesos.
  • Trabajo en equipo.
  • Comunicación.
Entre los principales problemas de la implementación de un modelo de Balanced Scorecard, se encuentran:
  • Alinear la misión, visión y objetivos organizacionales a objetivos individuales.
  • Traducir las actividades, funciones y competencias a objetivos numéricos.
  • Evaluar los objetivos numéricos y definir la contribución individual —evaluación de desempeño— a los objetivos organizacionales.
  • Definir el impacto financiero del nivel de logro de cada objetivo.
Es vital tener referencias del mercado o de la competencia con respecto a los objetivos que se van a definir, ya que si no se tiene esta información se puede caer en la definición de objetivos inalcanzables o demasiado benévolos que no reflejan la realidad, que pueden hacer que el proceso de implementación del Balanced Scorecard fracase.

Todos los objetivos deben estar reflejados o traducidos a resultados financieros. La siguiente fórmula nos permite determinar el nivel de valor de una actividad, tarea, proceso, producto o servicio en términos financieros desde la perspectiva del cliente:

siendo para el caso:
  • V = Valor. Es la efectividad y/o productividad en términos de rentabilidad o utilidad de un objetivo.
  • Q = Calidad. Grado en el cual el producto o servicio cumple con las expectativas.
  • s = Servicio. Nivel de satisfacción del cliente por la calidad, precio y oportunidad del producto o servicio recibido.
  • c = Costo. Insumos requeridos para generar el producto o servicio.
  • t = Tiempo. El grado de oportunidad en que se recibe el producto o servicio.
Antes de comenzar el proceso de construcción de un Balanced Scorecard, se necesita relevar información estratégica que servirá como entradas para los primeros pasos de la construcción del tablero. Se sugiere preparar una checklist de fuentes de información estratégica, incluyendo cosas como planes estratégicos, planes financieros, planes de mercadotecnia, planes operativos, reportes anuales, programas de mejora de la calidad, análisis de los consumidores, entrevistas con la gerencia ejecutiva, otros documentos de planeamiento, análisis competitivos, análisis de tendencias de la industria, análisis de tendencias tecnológicas, análisis de tendencias en mercadotecnia y otros análisis de la industria.

Y hasta aquí van las cuestiones introductorias que quería mencionar para entrar en el planteo inicial del Balanced Scorecard para el área de Tecnología Informática. Yo diferenciaría las cosas en función del tipo de organización. Si se trata de una empresa que no es específicamente de base tecnológica pero posee un área en tal sentido, pensaría en un Balanced Scorecard transversal a toda la organización, tratando las cuestiones de tecnología como objetivos dentro del mapa completo. Ahora, si la empresa fuera de base tecnológica, me orientaría hacia alguno de los modelos específicos, como por ejemplo:
  • El Balanced IT Scorecard (BITS), propuesto por el European Software Institute (ESI) que provee una nueva versión de las cuatro perspectivas originales agregando una quinta en relación con la gente —«People».
  • El Balanced Scorecard de Advanced Information Services Inc. (AIS), que considera a los empleados —«Employee»— como una perspectiva distintiva, expandiendo así el análisis a cinco elementos.
Como vemos, ambos modelos —que no son los únicos— se preocupan en forma diferencial por las cuestiones relacionadas con el que en la actualidad se considera el componente básico y más importante en una organización: su gente.

Por supuesto, seguiré tratando estos temas en futuros artículos. Les recomiendo las comunidades virtuales «Toma de Decisiones en el Ámbito de la Dirección Empresarial» para tratar aspectos relacionados con el Balanced Scorecard y «Gestión de Departamentos de Cómputo, Sistemas, Tecnología y Automatización» para su aplicación a la gerencia de TICs.

Por estos días, un amigo me preguntó sobre el Balanced Scorecard (BSC) para el área de Tecnología Informática. Es un tema interesante, por lo cual decidí plantearlo en mi blog.

Comencemos desde el principio. Balanced Scorecard —también llamado en nuestro idioma castellano como «Cuadro de Mando Integral» o «Tablero de Comando»— es una filosofía práctica de gerencia y fue desarrollada en la Escuela de Negocios de la Universidad de Harvard por los profesores Robert Kaplan y David Norton allá por 1992. Remarco especialmente lo de «filosofía práctica de gerencia» porque se suele confundir con las herramientas de software que la implementan o incluso con otras herramientas informáticas que sólo muestran valores de indicadores, lo cual dista mucho de lo que es un Balanced Scorecard.

El Balanced Scorecard se suele presentar basado en una combinación de mapa causal —un clásico diagrama de causa-efecto adaptado— y un cuadro categorizado según las perspectivas. Su principal característica es que mide no sólo los factores financieros del estado de resultados de la organización, algo típico de la vieja escuela administrativa, sino también los no financieros, separándolos en distintas perspectivas. En el modelo inicial, estas perspectivas eran cuatro y fijas, pero en las versiones posteriores del modelo se abrió la posibilidad de adaptar estas perspectivas para incluir elementos que sean necesarios para alinear el Balanced Scorecard a los objetivos de las organizaciones. Por ejemplo, no contemplar el impacto social como perspectiva en una organización de proyección social nos daría una visión parcializada de su realidad estratégica.

En definitiva, se trata de un poderoso instrumento para medir el desempeño corporativo y se ha demostrado que es la herramienta más efectiva para enlazar la visión y la estrategia a ciertas medidas de desempeño, como por ejemplo:

  • Resultados financieros —generalmente medido en términos de «Return on Investment» (ROI), «Return on Capital Employed» (ROCE) y «Economic Value Added» (EVA).
  • Satisfacción de clientes —internos y externos.
  • Operación Interna —procesos.
  • Creatividad, innovación y satisfacción de los empleados.
  • Desarrollo de los empleados —competencias.
  • Otras medidas relevantes, como la proyección social, el impacto ambiental, etcétera, que podrían ser de distinto peso en función del tipo de organización y su misión.
La lógica de esta técnica es obvia —si aceptamos como misión genérica para toda organización el transformar capital en productos y/o servicios que generen más capital—: todo lo que pasa en la compañía afecta los resultados financieros, por lo que es necesario medir esos elementos para dirigir el desempeño financiero. La satisfacción de los clientes involucra estar cerca de ellos, saber sus necesidades, evaluar el servicio y los productos, predecir sus necesidades futuras. La operación interna se refiere a los procesos de proveedor-cliente interno, que deben estar documentados y alineados a satisfacer a los clientes con indicadores de calidad, eficiencia, etcétera. Los empleados deben estar comprometidos y satisfechos con su trabajo, estar capacitados, generar ideas creativas y de innovación, desarrollar las competencias de acuerdo al puesto y tener expectativas de desarrollo dentro de la empresa.

Tal vez los beneficios más evidentes de implementar un Balanced Scorecard sean:
  • Comunicar la visión y estrategia a toda la organización.
  • Traducir objetivos estratégicos y tácticos de la organización en medidas individuales de rendimiento y productividad.
  • Ofrecer a cada empleado la visión de su contribución individual al logro de los objetivos de la empresa.
  • Enlazar los resultados con los procesos que se desarrollaron en el logro de los mismos.
  • Alinear las estrategias de la empresa con las competencias requeridas del personal.
  • Monitorear los recursos necesarios para el logro de objetivos.
  • Elevar los niveles de servicio a clientes internos y externos.
Una de las principales razones por la cual se utiliza el Balanced Scorecard es que ayuda a tener a la organización alineada con su estrategia. Esto permite tener conectados a los líderes y los empleados —comunicación— y ayuda a entender cómo y qué tanto los empleados impactan en el desempeño y resultados del negocio.

El Balanced Scorecard no es un reporte de resultados —como, lamentablemente, muchas empresas que lo han implementado lo emplean—; es un vehículo de comunicación de la estrategia y visión de la compañía. En ese sentido, para lograr el éxito en la implementación de la filosofía del Balanced Scorecard se requiere tener el apoyo de los líderes de la empresa, quienes deberían cumplir los pasos siguientes:
  1. Tener compromiso.
  2. Crear un modelo de Balanced Scorecard con sus objetivos estratégicos e indicadores clave de desempeño.
  3. Educar al personal, de manera que el Balanced Scorecard sea parte de la cultura organizacional. Siguiendo los planteos modernos de gerencia, algunos de los cuales ya mencioné en un artículo anterior, se sugiere involucrar a todo el personal y no cometer el error de restringirlo sólo a los líderes.
  4. Tener soporte tecnológico —para el caso, software.
Uno de los problemas a los que se enfrenta la organización al implementar un modelo de Balanced Scorecard es la dificultad para establecer indicadores de desempeño de las funciones administrativas. No obstante, se debe mantener presente un principio de calidad: «lo que no se puede medir, no se puede mejorar». Para poder apoyar lo anterior se sugiere redactar los objetivos en términos cuantificables de:
  • Calidad.
  • Tiempo.
  • Costo y gasto —manteniéndolos, como corresponde, bien diferenciados.
  • Ahorros.
  • Cantidad.
  • Grado de satisfacción.
  • Grado de cumplimiento.
En la fórmula de valor, que entre otras cosas trataré mañana, en la segunda parte de este artículo, podremos observar la interrelación entre los objetivos en términos cuantificables.

Esta semana ya he escrito en este blog sobre la condición de producto del software, en dicho caso incursionando en los terrenos de la usabilidad del mismo y nuestra responsabilidad al respecto. También hablé sobre la interacción del producto software con el usuario, lo cual nos hace pensar en las acciones que debemos encarar para interpretar al usuario, su ambiente y sus necesidades. Y esto desencadena este artículo.

Sabemos que debemos fabricar productos software de calidad, pero… ¿qué es la calidad? Y más puntualmente, ¿qué es la calidad del software? Hay dos definiciones que me gustan sobre esto, que son igualmente válidas aunque mantienen dos enfoques diferentes. Las mismas son:

  • Enfocándonos en el cliente, calidad del software es el grado en que un cliente y/o usuario percibe que el producto software satisface sus necesidades.
  • Enfocándonos en la condición industrial del producto, calidad del software es la habilidad de un producto software de satisfacer su especificación de requerimientos.
Ahora bien, hay ciertas cuestiones que se presentan como principios fundamentales para cualquier sistema de gestión de la calidad y que, como corresponde, no podemos eludir. Estos principios son:
  • Foco en el cliente.
  • Liderazgo.
  • Resultados basados en los procesos.
  • Gerencia de las interrelaciones entre procesos.
  • Implicación del personal.
  • Mejora continua.
  • Relación con los proveedores.
  • Decisiones basadas en el análisis de la información.
Fíjense que todos estos principios, en mayor o menor medida, dependen fuertemente de la calidad de los procesos. Esto me hace pensar... ¿el producto software puede ser de calidad si el proceso no tiene calidad? Opino que sí, aunque el problema serio es que no podríamos asegurarnos de ello... Entonces, es por esto que corresponde que hablemos del «aseguramiento de la calidad del software» y no simplemente de la «calidad del software», pues si creyéramos en la suerte esta última podría llegar a darse en un caso fortuito y único en ambientes no controlados.

Aseguramiento de la calidad del software... Es básico y sería falaz pensar siquiera en que la calidad podría llegar a «inyectarse» al producto software finalizando el proceso de desarrollo —el viejo enfoque del control de la calidad. El simple control no puede asegurarnos más que que estaremos muy concientes de los dolores de cabeza que tendremos y la cantidad de dinero que perderemos. La calidad del producto software depende de tareas realizadas durante todo el proceso: detectar errores en forma temprana ahorra esfuerzos, tiempo y recursos.

No hacer las cosas bien se manifiesta en muchas formas. Estos problemas, que listo a continuación, son los más generalizados en las empresas del sector cuyos procesos no tienen calidad y no tienen forma de asegurar la calidad del producto software:
  • Compromisos consistentemente incumplidos, expresados en términos de entregas tardías, afluencia constante de defectos de última hora —algo que aquí en Colombia llaman coloquialmente «chicharrones»— y costos espiralados.
  • Reducida visión gerencial en el progreso, con la ocurrencia de sorpresas constantes.
  • Problemas propios de la calidad, como demasiado «reproceso» o «retrabajo», que las funciones no operen correctamente y un elevado número de quejas de los clientes luego de la entrega —lo cual no es menor si pensamos en el impacto que esto puede tener sobre la imagen marca de la empresa al estar dejando gran parte de las detecciones de defectos en manos de los clientes.
  • Moral pobre, que se percibe en forma de gente frustrada y la sensación de que nadie está a cargo.
Para ir terminando, no sin antes decir que seguiré tratando el asunto en este espacio, les dejo la referencia de la comunidad virtual «Aseguramiento de la Calidad del Software», en la cual se tratan temas como este.

Se trata de la «Segunda Jornada Técnica IEEE del Oriente Colombiano», organizada por IEEE Sección Colombia y la Rama Estudiantil del IEEE en la Universidad Francisco de Paula Santander (IEEE-UFPS), evento que se desarrollará el día viernes 1° de septiembre de 2006 en la ciudad de Cúcuta, Departamento de Norte de Santander.

De la primera de estas jornadas, que se realizó hace aproximadamente un año en la ciudad de Bucaramanga, Departamento de Santander, también tuve el gusto de participar como conferencista con mi charla titulada «Ingeniería de Sistemas e Ingeniería de Software: Diferencia Curricular Aplicada a un Modelo de Negocios» —si no están al tanto de qué hablo cuando menciono la «diferencia curricular», sugiero referirse a este artículo que publiqué anteriormente en mi blog.

La fotografía que sigue es un recuerdo y corresponde a «instantes de trastienda» de la versión del evento realizada en 2005. En la misma me encuentro junto a Luis Alberto Arenas, Presidente de IEEE Sección Colombia, y algunos de los estudiantes miembros de la Rama Estudiantil del IEEE en la Universidad Industrial de Santander (IEEE-UIS), quienes organizaron la jornada en dicha ocasión.


En esta oportunidad disertaré en una conferencia nuevamente dentro de las áreas de incumbencia de IEEE Computer Society, de la cual ya daré más precisiones mediante este espacio.

Para obtener más información e inscribirse en el evento, pueden acceder al sitio web de la Rama IEEE-UFPS o enviarle un mensaje de correo electrónico a Samuel Villamizar Berdugo, el Coordinador Local del evento.

Como preámbulo, una aclaración. Si bien en mi título académico no dice «Ingeniero de Software», me permito considerarme uno por mis años de experiencia en esta disciplina. Por lo tanto, enfoco este artículo hablándonos a los que ejercemos esta profesión.

Ahora bien... Reconozcamos algo: el software es un producto. Esto, que a primera vista parece obvio y que queda claro incluso en material de referencia básico de Ingeniería de Software —como el libro «Software Engineering: A Practitioner's Approach» de Roger Pressman, por citar uno—, no resulta tan obvio para muchos si vemos algunas piezas de software que pululan por allí...

En general —si bien, como expresa el dicho, «toda generalización es mala, incluso ésta»—, los desarrolladores de software no suelen ver al software como producto... al menos no desde el principio. Tal vez, con la buena guía de personas experimentadas o con muchos años encima, puede ser que sí. Pero no desde el principio. La academia debería dar este enfoque, pues no todo es perderse en cuestiones estrictamente técnicas —al menos, en términos computacionales.

Para esto suelen ser buenos los Analistas de Sistemas —he sido uno de ellos hace unos cuantos años— o, mejor aún, los Diseñadores Industriales orientados a la Informática —he tenido el gusto de trabajar con algunos de ellos. Los primeros porque, si ejercen bien su profesión, ven al software como una herramienta que apoya al sistema. Los segundos, porque debido a su propia profesión ven al software como producto y los que tenemos experiencia en el asunto no tenemos que andar explicándoles esta obviedad. No digo que los Ingenieros de Software no podamos ser también buenos en esto, pero lo cierto es que vaya uno a saber por qué extraña razón, solemos estar más orientados a pensar en el software como software, ese conjunto de modelos, código y documentación varia, sin olvidar la metodología, dejando muchas veces en un segundo plano lo que más importa...

En ambos casos, Analistas de Sistemas y Diseñadores Industriales orientados a la Informática, suelen hacer estudios con distintos enfoques metodológicos para comprender el entorno en el cual el software operará y, lo que es más importante aún, quién lo va a usar. Sí señores, el famoso... ¡usuario!

Tal vez la característica más clara de quien diseña una pieza de software bien hecha, es que jamás pierde de vista a quien, en definitiva, operará —o sufrirá, depende del caso— el software. ¿Dónde lo operará? ¿Estará haciendo algo mientras vaya a operarlo? ¿Qué? ¿Podrá operarlo en una forma que consideramos tradicional o tendríamos que pensar en alternativas de interacción con el mismo? Y otra serie de preguntas que apuntan en el mismo sentido: lo que podríamos calificar como «diseño enfocado en el usuario».

Los Ingenieros de Software deberíamos tomar algunos buenos lineamientos del dominio de esta gente. Por ejemplo, podríamos dejar de pensar en algo etiquetado como «diseño de interfaz gráfica de usuario» y reemplazarlo por algo que llamaríamos «diseño de interacción». ¿Quién dijo que siempre la mejor solución es implementar una interfaz gráfica de usuario? Puedo mencionar un sinnúmero de ejemplos en los cuales esto no sería eficiente. Nosotros deberíamos detectar estas cuestiones, y no vale decir que «el usuario no me lo dijo».

Tenemos que salir de la caja y borrar el preconcepto de que la forma de interactuar con el software es una combinación de monitor, teclado y mouse. Se puede ir más allá. Se debe ir más allá. Hay muchas otras alternativas y, si no hay ninguna que satisfaga las necesidades de los usuarios, deberíamos ser lo suficientemente creativos como para idearla o colaborar en idearla —después de todo, somos «Ingenieros» y de eso se trata... Nuestra obligación profesional es trabajar para ayudar a los usuarios a que cumplan con su cometido en una mejor forma —eso es calidad—, y no complicarles la vida... Nuestro compromiso con el usuario debe manifestarse en términos de usabilidad.

Para ir terminando, los dejo con una recomendación casi obvia para el caso. Se trata del ya viejo libro «The Inmates are Running the Asylum» —que han traducido al castellano como «Presos de la Tecnología»— de Alan Cooper, excelente tanto para gente de Computación como para el conjunto de tomadores de decisiones de las empresas. Es, para mi gusto, un imprescindible para la biblioteca de todo Ingeniero de Software.

Estas imágenes corresponden a la Octava Reunión Nacional de Ramas Estudiantiles del IEEE de Colombia 2006 (RNR2006), evento del que participé en calidad de conferencista el pasado jueves 27 de julio de 2006. Organizado por los miembros de la Rama Estudiantil del IEEE en la Universidad Industrial de Santander (IEEE-UIS), con una concurrencia de 130 personas y una duración de cuatro días, el ciclo de conferencias tuvo lugar en la ciudad de Bucaramanga, Departamento de Santander.

En la primera fotografía, me encuentro disertando en mi conferencia: «El Reto de Ejercer la Ingeniería: Consejos y Experiencias» —las diapositivas se encuentran disponibles en las memorias del evento. La charla, brindada dentro del marco de las actividades del Capítulo Colombia de IEEE Engineering Management Society, partió de mi visión y la de otros como gerentes de tecnologías, y buscó plantear, desde este lado, elementos de guía y discusión para acompañar a los estudiantes en su transición a profesionales.



En la segunda fotografía, estamos reunidos miembros de Colombia y Venezuela (de izquierda a derecha):

  • Roberto Durán, en ese entonces Presidente de la Rama IEEE-UIS, Bucaramanga, Santander, Colombia;
  • Luis Alberto Arenas, Presidente de IEEE Sección Colombia;
  • Ángel Javier Ballestero, Vicepresidente de la Rama Estudiantil del IEEE en la Universidad Rafael Belloso Chacín (IEEE-URBE), Maracaibo, Zulia, Venezuela;
  • Juan Pablo Aguirre, Presidente de la Rama IEEE-URBE, Maracaibo, Zulia, Venezuela;
  • Camilo Londoño, Coordinador de Comunicaciones Electrónicas de IEEE Sección Colombia; y
  • Pablo Fernando Sanchez, Presidente del Comité de Comunicaciones Regionales de IEEE Región 9 y Coordinador de Actividades en la Región Oriental del Capítulo Colombia de IEEE Engineering Management Society.
El evento fue reseñado en varios periódicos locales, como es el caso de Vanguardia Liberal.

Asimismo, desde la página web de la Reunión pueden descargarse las memorias y ver muchas otras fotografías que no incluí en este espacio.

Luego de leer un artículo que referencio en mi blog, me surgió la necesidad de releer el libro «Peopleware: Productive Projects and Teams», de Tom DeMarco y Timothy Lister. Es un gran libro, tal vez de los mejores que haya leído como gerente. Demás está decir que lo recomiendo, pues en sus páginas se puede leer lo que hace a la gerencia en empresas de clase mundial. Por supuesto, luego de meterme en este texto, la reacción lógica es hablar estos asuntos con amigos y colegas. Así pues, creo oportuno plantear los temas que discutimos, en esta ocasión a través de las líneas de este artículo.

A lo largo de mi carrera, he notado un problema recurrente y serio en muchas empresas de tecnología —principal, aunque no exclusivamente, en las pequeñas y medianas—: la no profesionalización de la gerencia. Una de las características que evidencian esta falencia, es cuando los gerentes suelen adoptar roles cercanos a un arcaico capatazgo, antes que alineados a lo que es la gerencia moderna...

Antes de seguir adelante, mi experiencia en distintos países me dice que corresponde hacer una aclaración: ¿qué entendemos por Gerente? En algunos lugares, un Gerente es sólo el que está al frente de la empresa. En otros, eso sería un Presidente o un Gerente General, dependiendo del tipo de empresa, pero hay gerentes de área —lo que se conoce como «gerencia intermedia». En este artículo y en general, cuando hablo de gerentes hablo de toda esa plana mayor, desde el que está al frente de todo, hasta el de menor nivel jerárquico que ejerza funciones de gerencia.

Otra mención que cabe tiene que ver con la empresa en sí. ¿Qué es una empresa? Una empresa es su gente. Se puede cambiar de edificio, muebles, computadoras, etcétera, y la empresa sigue siendo la misma. Pero se cambia la gente —renovando el personal, capacitándolos o empoderándolos— y la empresa es otra.

Ahora bien, continuando con el tema, surge una pregunta: ¿qué es lo más importante que puede hacer un gerente? Toda una pregunta... Considero que lo más importante que puede hacer un gerente como tal es trabajar para que su gente —y, estrechamente relacionado a ello, él mismo— sea feliz con su trabajo... Sino, la aventura no vale la pena...

Para reforzar mejor esta consideración, recurro a algo que he mencionado antes en este espacio: «si la gente no está feliz con su trabajo, la función de la gerencia no vale la pena y la empresa será menos rentable de lo que debería —incluso nada rentable». Lo cierto es que esta visión, que para algunos, lamentablemente, puede sonar revolucionaria y hasta ilógica, no es un invento mío, sino de la vida misma. Es decir, si un gerente no se encuentra feliz con lo que hace, ¿qué está haciendo? Si considera, como ocurre, que su gente es la culpable de todos los males y no hace más que demostrarles que eso cree, ¿quién los contrató? ¿Por qué no hacer algo productivo haciendo que la gente ame lo que hace y logrando que mejore —mejorando también la empresa—? Muchas preguntas más podrían hacerse, pero creo que estas son suficientes para expresar lo que quiero decir.

También mencioné que «es sólo en torno al lugar que este grupo humano sinérgico ocupa en la sociedad que esta visión común llamada empresa puede sostenerse: que todos crezcan». Es eso. Pónganle el nombre técnico que quieran, «empowerment» si quieren, pero lograr que la gente gerencie su propio espacio es óptimo. Claro, hay que confiar en la gente para ello... Y, por sobre todas las cosas, hay que confiar en uno mismo y no temer a formar gerentes en nuestro grupo. Esto es gerenciar el factor humano, no cubrirse las sentaderas por todos los medios posibles, no mirar sólo hasta donde llegan las propias narices...

Planificar a largo plazo, considerando la capacitación de nuestra gente en gerencia —o «management»—, formando personas que sepan tomar decisiones y permitirles hacerlo, felicitar y premiar cuando corresponda, darles su espacio y luchar por su bienestar, son algunas de las cosas que pueden articularse para lograr este cometido: que la gente ame lo que hace. Lograr que la gente sea gerente de su propio trabajo da buenos resultados, pero lleva inversión... Hay que enseñar a la gente a gerenciar... Fuera de que hay muchas empresas que no están interesadas en invertir en esto, están aquellos «gerentes», los que le temen mucho a este modelo y que oscilan dentro de los lamentables límites de una visión generalizada que los lleva a cuidar sus sentaderas en lugar de hacer planificaciones serias a largo plazo...

En conclusión, creo que el primer paso para hacer feliz a la gente se da no con grandes técnicas, sino con algo básico que muchos olvidan: ser gente. Luego, las técnicas, pero sin esta característica básica, la técnica no sirve... Eso se aprende desde la cuna, y es un tema ético y moral...

Permitiéndome copiar humildemente la costumbre de Mariano Amartino en el excelente Denker Über, uno de los blogs que leo, aunque sin pretender establecerlo como un hábito semanal —como en dicho caso— y tal vez siendo escueto, presento a continuación una serie de enlaces a artículos en blogs que me han resultado interesantes y que están relacionados con la temática del mío. Por lo general son blogs que tengo enlazados en mi agregador; entonces, les comparto mi índice:

El otro día, en un comentario que dejé a un análisis a una propuesta curricular de Bertrand Meyer hecho por Jorge Ubeda en su bitácora, Hacia la Cuarta Generación del Software, mencioné el modelo curricular conjunto de IEEE Computer Society (IEEE-CS) y Association on Computer Machinery (ACM), que tal vez sea el de mayor renombre y difusión. A raiz de dicho comentario, he sido consultado sobre el tema por varias personas, lo cual me impulsó a escribir este artículo.

En primer lugar, desmitifiquemos algo: en el título de este artículo escribí «Sistemas». Pues bien, tacho: está mal. Lo hice porque si hubiera titulado el presente como «Un Modelo Curricular Estándar para Computación» —por su adaptación desde la lengua de Shakespeare, «Computing»—, creo que lo leería... ¡nadie!

En general, he notado que en Iberoamérica solemos tener una visión un poco prejuiciosa de la palabra «computación», como si fuera adecuada sólo para titular los suplementos dominicales de periódicos o los cursos para niños. Pero no señores, Computación es una gran disciplina que podríamos definir como abarcativa de cualquier actividad orientada a lograr objetivos requiriendo computadoras, beneficiándose de computadoras o creando computadoras. De acuerdo al planteo del mencionado modelo curricular, se subdivide en las siguientes cinco disciplinas específicas:

  1. Ingeniería en Computación —aceptado por «Computer Engineering». La Ingeniería en Computación abarca el diseño y construcción de computadoras y sistemas basados en computadoras. Incluye el estudio del hardware, software, comunicaciones y la interacción entre ellos. Su curriculum se enfoca en las teorías, principios y prácticas de la Ingeniería Eléctrica tradicional y matemática, y las aplica a los problemas de diseñar computadoras y dispositivos basados en computadoras. Es decir, cosas que en general le dejamos en manos de la Ingeniería Electrónica.
  2. Ciencias de la Computación —aceptado por «Computer Science». Las Ciencias de la Computación expande un amplio rango de áreas, desde las bases teoréticas y algorítmicas hasta desarrollos de vanguardia en robótica, visión computacional, sistemas inteligentes y bioinformática, entre otras. Los científicos de la computación suelen ser adecuados para desafíos avanzados de programación, como los relacionados con encripción o compresión de datos, por ejemplo.
  3. Sistemas de Información«Information Systems». Los especialistas en esta disciplina específica se enfocan en la integración de soluciones de tecnología de información y los procesos de negocio para satisfacer las necesidades de información de las organizaciones, facilitándoles el logro de sus objetivos en una forma efectiva y eficiente. La perspectiva de esta disciplina específica en la tecnología de información enfatiza la información y ve a la tecnología como un instrumento para generar, procesar y distribuir información.
  4. Tecnología de la Información«Information Technology». Básicamente, trabaja en una línea similar a la de Sistemas de Información, sólo que hace énfasis en la tecnología y en mantener vivas en términos tecnológicos a las organizaciones.
  5. Ingeniería de Software«Software Engineering». La Ingeniería de Software abarca el desarrollo y mantenimiento de sistemas de software que sean fiables, se comporten eficientemente, sean desarrollables y mantenibles, y satisfagan todos los requisitos que los clientes le hayan definido.

Aclaro, por si hiciera falta, que esta visión no es un simple capricho, sino el resultado del trabajo de un comité formado especialmente para este desarrollo por dos de las organizaciones técnico-profesionales de mayor prestigio a nivel mundial —muchas más que dos si sumamos a todas las que participaron de una u otra forma de los comités de expertos en las disciplinas específicas, como The Association for Information Systems (AIS). Al mismo tiempo, también prestigiosas universidades como Stanford, basan en este modelo la configuración curricular de sus programas en Computación.

Asimismo, cabe aclarar que no se limita exclusivamente a estas cinco disciplinas específicas, sino que el modelo está diseñado para que se vaya subdividiendo a medida que avance la Computación. Podrían, por ejemplo, surgir disciplinas específicas como «Ingeniería de Requisitos», «Inteligencia Computacional» o «Ingeniería en Pruebas de Software», de ser necesario.

Esta división disciplinar no es menor. Me ha tocado diseñar o ayudar a diseñar modelos de negocio aprovechando la misma. Por ejemplo, trabajar en frentes abocados a las incumbencias de disciplinas específicas: un Departamento de Consultoría trabajando con Sistemas y Tecnologías de la Información, un Departamento de Desarrollo trabajando con Ingeniería de Software y Ciencias de la Computación, o un Departamento Técnico trabajando con Ingeniería en Computación. En definitiva, si se domina esta división y se es lo suficientemente hábil en organización, se le puede sacar mucho provecho a este modelo.

Lamentablemente para mi gusto, en muchos programas en nuestra región se suele tomar el paquete completo —muchas veces con una visión cercana a la enciclopedista— y se lo engloba en la llamada «Ingeniería de Sistemas». O sea, en teoría un egresado de estos programas podría dedicarse a hacer cosas tan variadas como diseñar la arquitectura de una pieza de software, programar, hacer análisis de sistemas, instalar un sistema operativo, configurar una red, cambiar un módem que se quemó, armar los cables para conectar la red, crear un manual de organización y métodos, conducir estudios de mercado para proyectar el futuro tecnológico de la empresa y un amplio etcétera. Descabellado... En muchos casos, una titulación en «Todología Computacional» sería más representativo... Mi abuela decía que «quien mucho abarca, poco aprieta» y estoy convencido de que tenía razón.

Algunas veces me pregunto si no será un tema de mercado, pues contratar a una persona es más barato que contratar a cinco... ¿La eficiencia? Bien, gracias... Es que hay tantos «visionarios» en el mercado...

Quisiera que den opiniones y comenten experiencias en este asunto, pues creo que es un tema más que importante para debatir.

Luego de la insistencia de muchos conocidos, por fin decidí tomarme el tiempo para crear mi bitácora personal, la cual en un brote de originalidad llamé «El Blog de Pablo Fernando Sanchez». Bueno, tampoco es que será tan «personal» en términos estrictos, porque de lo último que escribiré en este espacio, exceptuando este artículo introductorio, será sobre mí. La idea es compartir experiencias con la sociedad, cosa que no es una simple ocurrencia, sino que va más allá: hay una cuestión ética detrás del asunto.

Explico. Sería petulante opinar que uno se hace solo. Uno no llega a donde está solo, sino por una lógica interacción social. Es la sociedad, a través de quienes nos preceden, que se encarga de formarnos. Uno, en consecuencia, tiene una cierta obligación ética de ayudar en la formación de otros y, de paso, también aprender en el proceso —sin lo cual, claro está, no tendría sentido.

Obligación ética, decía. ¿Hacia quién? Hacia uno mismo, hacia nuestros colegas, hacia la profesión, hacia la sociedad. Invito desde estas líneas a reflexionar sobre el particular.

Mencioné la insistencia de conocidos, quienes generalmente me conocen de algunas comunidades virtuales que coordino desde hace mucho tiempo en Yahoo! Grupos —Análisis y Diseño de Sistemas de Información, Ingeniería de Software, Aseguramiento de la Calidad del Software, Gestión de Departamentos de Cómputo, Sistemas, Tecnología y Automatización y Toma de Decisiones en el Ámbito de la Dirección Empresarial—, de la que co-coordino con mi esposa (quien también es consultora, aunque en otras áreas de incumbencia) —Gestión de la Calidad—, de mi participación como voluntario en las actividades de The Institute of Electrical and Electronics Engineers (IEEE), de alguna que otra conferencia de las que suelo conducir, de alguna de las empresas que asesoro o, en general, del resto de mi labor como profesional en Sistemas, tanto en Argentina como en Colombia. A todos ellos, así como a quienes han sido mi guía y/o mi apoyo, les agradezco. Y a todos, conocidos o no, espero poder aportarles algo desde este espacio, aunque más no sea alguna opinión con la cual no estén de acuerdo pero que sirva para pensar, movilizar ideas y debatir.

Como sea, no es mi primera experiencia con un blog, pues con mi equipo de voluntarios del Comité de Comunicaciones Regionales de IEEE Región 9, América Latina y el Caribe, reformamos una publicación típica tipo newsletter llamada NoticIEEEro, en lo que calificamos como «centro de noticias» —lo cual no es otra cosa que un weblog. Igual, este es mi primer blog de índole particular, por lo cual espero hacerlo como corresponde: bien.

Escribiré —o, espero, escribiremos—, como indico en la descripción para este espacio «sin limitarse a ello, sobre ingeniería de software, ingeniería de sistemas, gestión estratégica, modelado de procesos, metodología, aseguramiento de la calidad y todos esos asuntos que hacen, desde la gerencia y la técnica, a las empresas que asesoro». Por supuesto, es que también son los temas que me gustan y me impulsan a escribir, al menos desde lo profesional.

También deseo aportar a algo en lo que creo decididamente: la orientación humana y social de la gerencia. Estoy convencido que una empresa es su gente. Si la gente no está feliz con su trabajo, la función de la gerencia no vale la pena y la empresa será menos rentable de lo que debería —incluso nada rentable. Al mismo tiempo, es sólo en torno al lugar que este grupo humano sinérgico ocupa en la sociedad que esta visión común llamada empresa puede sostenerse: que todos crezcan.

Bienvenidos y muchas gracias por leer estas líneas. Espero que todos aprendamos con esta experiencia, que esto les sirva y que interactuemos hacia el crecimiento.

Blog Widget by LinkWithin

Seguime

Suscribite al feed de mi blog Suscribite para recibir las actualizaciones de mi blog por correo electrónico Seguime en twitter

Seguidores

Etiquetas

Últimos Artículos

Herramientas

IBSN