DTE y la figura del bibliotecario

Hola a todos.

He decidido rescatar un par de artículos que publiqué hace varios años en Club Delphi y Programadores Delphi de México, y unirlos en uno solo, dada la relación tan estrecha que guardan entre sí y la importancia que considero podría tener este material en el mundo del desarrollo de software.

---

Distribución del Trabajo

por Especialidades (DTE)

La Distribución del Trabajo por Especialidades es un paradigma de organización laboral aplicable a todas las profesiones que alcanzan cierto nivel de complejidad. Consiste en clasificar todas las tareas involucradas en un ámbito laboral por tipo de actividad o, más formalmente, por especialidades, y respetando esa clasificación durante los procesos de estimación, repartición y ejecución del trabajo. La idea fundamental de la DTE es tener claramente identificadas las diferentes áreas de una profesión y promover el surgimiento de especialistas y el trabajo en equipo, para lograr resultados de mayor calidad, dignificar la labor de los profesionistas y elevar su nivel de vida. Por dar un ejemplo donde la DTE ha tenido éxito, podemos mencionar la profesión médica, la cual lleva muchos años fomentando la especialización con resultados realmente admirables.

Debemos aceptar el hecho de que, en cualquier profesión, la especialización siempre será una ventaja competitiva tanto para los trabajadores como para las empresas que los emplean. El resultado directo de la especialización es un mejor desempeño y una mayor calidad en los productos y servicios obtenidos. Una persona especializada tiende a realizar mejor su trabajo que una no especializada. Al unir los esfuerzos de diferentes especialistas en un mismo equipo de trabajo, logramos un entorno de alta productividad.

Quizá el lector empresario se plantea en este momento el siguiente cuestionamiento: «De acuerdo, lo ideal sería que mi empresa contara con varios especialistas, pero sería imposible sostener esa nómina. La cantidad de trabajo y los ingresos por ventas son insuficientes».

Ese es un punto de vista típico del empresariado del siglo XX. En la mayoría de los casos, esa perspectiva derrotista pierde validez y se vuelve anacrónica cuando en contraparte se exponen estos sólidos argumentos del siglo XXI:

1. Un especialista no necesariamente debe percibir un salario mucho mayor que el de un trabajador no especializado, aunque es deseable y económicamente sano que si tenga un nivel de ingresos superior. Un especialista es un profesional, y por lo tanto entiende que el valor económico de su trabajo está determinado por el mercado; siempre habrá un punto de equilibrio aceptable entre lo que las empresas quieran pagarle al especialista y lo que éste quiera cobrar.
2. Un trabajador puede cubrir dos o más especialidades. La especialización no significa que la empresa deba contar forzosamente con un trabajador por cada especialidad. La meta laboral es cubrir todas las especialidades, independientemente de cuántas personas se ocupen para ello. Lo importante es que cada especialidad esté cubierta por alguien que desempeñé eficazmente su labor en esa área. Hay muchos profesionales que destacan en más de una.
3. La empresa puede recurrir a la contratación de servicios externos (outsourcing) y al pago por hora, dos prácticas altamente efectivas y cada vez más difundidas alrededor del mundo. Una excelente forma de contar con el trabajo de diversos especialistas es contratando los servicios de profesionales independientes o de compañías consultoras, además de instaurar el pago por hora en lugar de abultados sueldos que, en muchos casos, no equivalen a la cantidad real de tiempo efectivo trabajado. De esta manera, la empresa decide cuándo, a quién, por cuánto tiempo y para qué actividades contratar a cada especialista. Por su parte, los especialistas gozan de una mayor autonomía laboral, permitiéndose cotizar sus servicios en el mercado con toda libertad.
4. Cuando una empresa desarrolla sus actividades más importantes empleando a especialistas, lógicamente incrementa sus ingresos por ventas. Esto es porque al mejorar la calidad de sus productos y servicios —gracias a la especialización— eleva su competitividad, logra una mayor aceptación de los mismos en el mercado y, opcionalmente, puede cotizarlos a un precio más alto.

DTE en el desarrollo de software

Evidentemente, cada profesión tiene sus rampas y sus muros que facilitan u obstaculizan la especialización. Y cada una requiere un tratamiento específico para establecer una logística DTE efectiva. El autor de este artículo es un desarrollador de software, especialista en programación de bibliotecas, a quien le interesa la puesta en práctica de un modelo DTE en las empresas de software y en las oficinas de los programadores independientes. Tanto él como otros colegas de diversas especialidades están convencidos de que la DTE dará grandes beneficios tanto a los profesionistas y empresas creadores de software como a los usuarios de tecnologías de información, empezando por una mayor calidad de los productos y servicios proporcionados y propiciando que los desarrolladores —usualmente llamados informáticos—, convivan en un entorno laboral más digno, respetado, satisfactorio y estable.

Clasificación de las especialidades

Cuando se pretende establecer un modelo DTE, lo primero es determinar cuál o cuáles son las clasificaciones más efectivas. En ocasiones leemos o escuchamos sobre desarrolladores especialistas en el manejo de herramientas o entornos de software específicos, como base de datos Oracle™, lenguaje Delphi™, programación Web, y muchísimos otros. Eso nos muestra que, de facto, ya existe una serie de especialidades que puede ser aprovechada al aplicar la DTE. Sin embargo, creo que la clasificación de especialidades por herramientas o entornos de software obedece más al gusto personal que a las habilidades reales del profesionista.

Supongamos que tenemos a un autodenominado experto en Java, un fanático del lenguaje que no programa nada si no es con algún entorno Java. Éste realiza un trabajo excelente programando rutinas de eventos, validando la lógica de negocios y creando clases de objetos para las aplicaciones que desarrolla, pero sus sentencias SQL de acceso a datos no son del todo óptimas y su diseño de interfaces de usuario carece de estilo gráfico y calidad gramatical. Entonces inferimos que realmente no se trata de un experto, más bien es un desarrollador que conoce el lenguaje lo suficiente como para crear aplicaciones funcionales y hasta cierto punto aceptables; se le reconocen importantes habilidades de programador operativo, de lógica de negocios y de bibliotecas, pero tiene escasa destreza en las áreas de administración de datos y diseño visual. Si una empresa le asigna cualquier actividad que tenga que ver con programación en Java, muchas de esas actividades serán mal ejecutadas (las que no son de su dominio).

El ejemplo anterior es tan claro como lamentablemente típico. La especialización a partir de herramientas o entornos de software por lo general termina siendo una especialización a medias, poco eficiente. Como promotor de la DTE creo que la clasificación de especialidades debe originarse en función de los diferentes tipos de labores, lo cual va más acorde con las habilidades reales de los desarrolladores y no tanto con sus gustos personales. Naturalmente, pienso que es válido crear subespecialidades por herramientas, entornos u otras clasificaciones que satisfagan el gusto personal de cada desarrollador, pero siempre partiendo de especialidades mayores clasificadas por tipo de actividad. Bajo esta tónica, la empresa del ejemplo anterior le encargará a nuestro reconocido especialista en programación operativa, de lógica de negocios y de bibliotecas en Java las tareas que son de su competencia profesional, mientras que el diseño de las interfaces de usuario y la construcción de sentencias SQL serán asignados al especialista respectivo.

Si el lector empresario está pensando de nuevo en la “imposibilidad” de contratar a «tantos» desarrolladores especialistas, le sugiero, de la manera más atenta, que vuelva a leer los cuatro sólidos argumentos del siglo XXI que expuse casi al comienzo de este artículo.

Principales especialidades

Algunos colegas y yo hemos detectado doce principales especialidades y cinco subespecialidades, en función de los diferentes tipos de tareas realizadas al desarrollar sistemas de software. A cada una le hemos asignado un acrónimo de dos letras mayúsculas para fines de simplificación. Se listan en seguida:

1. Análisis (AN)
2. Dirección (DI)
3. Administración de datos (AD)
   - Modelado de datos (MD)
   - Administración de bases de datos (AB)
4. Diseño visual (DV)
   - Diseño gráfico (DG)
   - Diseño operativo (DO)
   - Reporteo (RE)
5. Programación operativa (PO)
6. Programación de lógica de negocios (LN)
7. Programación de bibliotecas (PB)
8. Preparación de instaladores (PI)
9. Documentación (DC)
10. Control de calidad (CC)
11. Instrucción (IN)
12. Soporte técnico (ST)

Red Colaborativa DTE

Concientes de que no es muy viable ni estratégico para la mayoría de las empresas de software contratar a doce o más especialistas de tiempo completo, pero a la vez convencidos de las ventajas de una organización DTE, los promotores del modelo consideramos que deben aceptarse dos escenarios perfectamente combinables:

1. Cada uno de los desarrolladores en una empresa estará a cargo de la realización de tareas de una o más especialidades. El equipo de desarrolladores (que en algunos casos podrá ser de uno sólo) deberá identificar y tratar de cubrir todas las especialidades mayores propuestas en este modelo. La repartición de las tareas se hará en función de las especialidades y disponibilidad de tiempo —en ese orden— de cada desarrollador. Siempre toda tarea deberá estar enmarcada en alguna de las especialidades, desde el análisis hasta la implantación.
2. La empresa recurrirá a la contratación de especialistas DTE externos cuando lo considere estratégico. Esto puede suceder cuando la empresa no cuente con el especialista interno adecuado o cuando éste no disponga de tiempo por estar ejecutando otras actividades que le fueron asignadas previamente. El servicio de outsourcing contratado podrá ser ejecutado de forma presencial en las instalaciones de la empresa, o a distancia, con las facilidades que Internet ofrece para ello.

Para que esto sea factible y tenga aceptación general, los promotores del modelo proponemos crear una Red Colaborativa DTE; un directorio de desarrolladores especialistas, tanto independientes como de empresas consultoras, que ofrezcan servicio profesional externo de desarrollo de software. Cada desarrollador público, por llamarlo de alguna manera, deberá estar perfectamente registrado en ese directorio, con sus datos personales y fiscales básicos, direcciones y teléfonos donde se le puede localizar, especialidades DTE que domina, empresa a la cual pertenece, currículum, referencias comerciales, calificación o nivel de preferencia que le dan sus clientes, entre otra información importante. Y opcionalmente podrá publicar ahí algunas actividades de su agenda y su tarifa por hora. Un directorio formal y serio como ese le dará a las empresas la confianza necesaria para firmar contratos de trabajo con especialistas DTE externos, independientemente del lugar geográfico donde éstos se encuentren o de su esfera cultural.

Pero esta Red Colaborativa tiene bondades adicionales. Al instaurarse el modelo DTE en las oficinas de los desarrolladores independientes y en las pequeñas empresas de software, pueden crearse magníficos equipos de teletrabajo para desarrollar proyectos de sistemas de cualquier tamaño y para cualquier compañía u organización. Con el modelo DTE y la Red Colaborativa, todos los desarrolladores independientes y pequeñas empresas de software tendrán la capacidad de competir en el mercado, ofreciendo software de alta calidad y a la medida de cualquier empresa o institución. Así por ejemplo, un programador serio y formal que trabaja desde casa podrá fabricar una completa solución de software para una compañía local, echando mano de especialistas externos DTE de cualquier parte del mundo. Inclusive podrán ocurrir situaciones donde dos desarrolladores o empresas estén mutuamente contratados para la ejecución de varios proyectos. También podrán darse alianzas estratégicas entre los desarrolladores y las empresas de software, con el fin de garantizar su estabilidad a largo plazo, dando pie a la creación de nuevas y más sólidas compañías. Y más aún, entre los desarrolladores podrán surgir acuerdos de colaboración para la fabricación de paquetes de software comerciales, compartiendo riesgos (en este caso se sugiere emplear, en lugar de colaborativo, el término cooperativo, distinguiendo dos tipos de proyectos compartidos que propone el modelo DTE). También es posible que surjan nuevas empresas especialistas DTE. Que no nos extrañe ver el surgimiento de compañías especializadas en AN, CC, DC, etc., además de las de DG y PB (componentes), las cuales ya son algo comunes.

---

La figura del bibliotecario

En un equipo de desarrolladores debe existir por lo menos un programador bibliotecario, cuya definición que propongo es esta:

Desarrollador encargado de elaborar, adquirir, investigar, administrar y facilitar recursos técnicos a otros desarrolladores, principalmente a los que se encuentran dentro de su grupo o equipo de trabajo.

El bibliotecario debe programar y mantener una biblioteca de funciones, componentes y otros recursos de software prefabricados, cuyos elementos sean creados como soluciones a necesidades reales, reportadas por los demás programadores en sus respectivos proyectos. También debe encargarse de evaluar los requerimientos de los programadores, hacer investigaciones al respecto y en su caso solicitar y / o adquirir los recursos que sean necesarios para satisfacer tales requerimientos. Además el bibliotecario, en la medida de lo posible, debe ser intuitivo, analítico, suspicaz, metódico, imaginativo, perspicaz, persuasor, disuasivo y cuestionante respecto a las peticiones que le hacen sus compañeros, pero sobre todo debe apoyarlos, entenderlos, y ponerse en sus zapatos para determinar qué es lo mejor que se puede hacer en cada caso que le plantean.

Supongamos que Pascual es el programador bibliotecario, y Lorena y Roberto dos de los programadores finales (los que realizan la programación de alto nivel y ensamblado final del producto). En determinado proyecto, Lorena se ve en la necesidad de convertir un arreglo abierto de enteros Array Of Integer, en una cadena de caracteres String separada por comas. Por ejemplo, necesita convertir el arreglo de enteros [78, 27, 2, 19] a la cadena '78, 27, 2, 19' (considerando que el vector de enteros es variable). Lorena intuye que esta necesidad pudo haberse presentado antes en algún otro proyecto del equipo, así que lo primero que hace es plantearle su caso a Pascual, el bibliotecario:

—Mira. Este procedimiento de nuestro proyecto recibe un arreglo abierto de enteros. Se me facilitaría mucho poder convertir el arreglo recibido en una cadena tipo lista separada por comas, porque así podría darla como parámetro al llamar a este método que espera un String. Creo saber cómo realizar la conversión, pero quizá alguien más pudo haber necesitado algo así antes. ¿Tendrás algo para estos casos? Si no, te sugiero tomarlo en cuenta, porque eventualmente podría presentarse de nuevo esta necesidad.

—¡Este es tu día de suerte, Lorena! —le responde Pascual—. Sabes, hace algunas semanas Roberto me planteó un caso muy similar. Desde entonces tenemos en la unidad Convertidores.pas de nuestra biblioteca, una función llamada EnterosALista que hace precisamente la conversión que requieres de Array Of Integer a String. Se usa de esta manera...

—¡Órale, me impresionas Pascual! Me has ahorrado algunas horas de trabajo y medio dolor de cabeza, je-je-je. Muchas gracias, niño listo.

El anterior es un ejemplo de cómo interviene el bibliotecario en la solución de necesidades técnicas de los programadores finales. Se destaca la importancia que tiene en el manejo efectivo de los recursos del equipo, y se observa cómo los programadores finales no se desvían de su objetivo principal, ya que varias tareas adyacentes le son delegadas al bibliotecario.

---

Si les interesa conocer las opiniones de algunos colegas respecto a la DTE y la figura del bibliotecario, les recomiendo ampliamente echarle una mirada a estas sanas discusiones:

http://www.clubdelphi.com/foros/showthread.php?t=25463

http://www.clubdelphi.com/foros/showthread.php?t=6559

http://www.clubdelphi.com/foros/showthread.php?t=64236

El tercer enlace es un grato testimonio del éxito que ha tenido una pequeña empresa de software de la ciudad Córdoba, en México, respecto de la figura del bibliotecario.

Espero sus opiniones vertidas a través del enlace / recuadro de comentarios que ven debajo de estas líneas.

Un abrazo especializado.

Al González. :)