REFLEXIONES sobre Ingeniería del Sofware e Informática

Algunas propuestas de soluciones organizativas:

• Para mí, la prioridad fundamental sería la de SEPARAR DEFINITIVAMENTE LA INFORMATICA DOMESTICA DE LA PROFESIONAL. Ambas tienen requisitos totalmente contrapuestos: el usuario doméstico suele demandar productos divertidos y fáciles de usar; mientras que el usuario profesional demanda productos robustos y fiables.
  Y, sobre todo, la gran diferencia estriba en que el PC doméstico debe permitir al propio usuario control total sobre su funcionalidad; (instalarse lo que quiera, autoactualizarse los programas, usarlo para oir música, jugar o ver vídeos,etc).
  Mientras que el control del PC empresarial ha de residir en el departamento de TI de la empresa; (software limitado justo al necesario para el trabajo del usuario, actualización según se programe desde TI, control de accesos, etc).
  
• El segundo punto sería reconocer de una vez por todas la EXISTENCIA DE VARIAS COLAS DE TRABAJO en el departamento de TI:
• Incidencias: errores sobre lo que ya está funcionando; se han de resolver lo antes posible.
• PequeñasMejoras: desarrollables en 1 ó 2 días
• GrandesMejoras: desarrollables en varios días o semana/s
• Proyectos: "mejoras" que necesitan de un amplio estudio/análisis/planificación/seguimiento, con varios meses de trabajo y/o la particicipación de equipos multidisciplinares

Y reconocer las muy distintas necesidades para atenderlas:
• Las Incidencias y PequeñasMejoras: requieren de personal multifuncional con disponibilidad permanente e inmediata, capaz de resolverlas con la celeridad demandada por el usuario.
• Las GrandesMejoras y los Proyectos: requieren de personal especializado con la tranquilidad suficiente, para poder concentrarse en su trabajo.


• Este segundo punto nos lleva a la cuestión accesoria de que, normalmente, el trabajo del informático es bastante solitario. Es decir, únicamente una persona (o unas pocas), suele conocer en profundidad un determinado sistema (-solamente quien ha estado directamente implicada en su desarrollo-). ¿Qué pasa si esa/s persona/s, por las causas que sean, deja/n de estar disponible/s?. Y, por otro lado, cada cual conoce únicamente su parcela; perdiendose importantes oportunidades de sinérgia entre distintos sistemas.
  Esto viene al hilo de que normalmente todas las personas del dpto TI suelen tener que atender simultáneamente a todas las colas de trabajo relacionadas con su "área de conocimiento". Dándose importantes colisiones entre la urgencia de unos trabajos y la concentración necesaria para otros.
  DIVIDIENDO el departamento de TI en DOS "FRENTES DE BATALLA", y ROTANDO AL PERSONAL ENTRE ELLOS, (por ejemplo, un año atendiendo urgencias --frente al usuario-- y otro año desarrollando --en la retaguardia--).
  Se solucionarían ambas cuestiones conjuntamente: damos a cada cola de trabajo el modo de respuesta necesario, y conseguimos que todo el departamento TI esté familiarizado con todos los sistemas implantados.
  
  Nota 1: en este sistema de trabajo, para ser efectivo, ambos frentes deberían estar físicamente separados uno de otro y con un estricto filtro de llamadas entre ellos; (para garantizar la necesaria tranquilidad en la "retaguardia").
  
  Nota 2: también es necesario, aunque esto ya es obvio, que las aplicaciones y los sistemas han de quedar perfectamente documentados tras su implantación; teniendo lugar ademas la adecuada formación para usarlos, (los usuarios), y para mantenerlos, (el personal TI "de primera linea" en ese momento).
  Es decir, nos obligaría a hacer las cosas bien y no chapuzas provisionales.
  
  Nota 3: llevando esta separación un poco más allá, nos podría solucionar incluso los planes de contingencia y continuidad de negocio. Me explico: dos equipos separados de TI nos llevarían a dos sedes separadas de TI. Cada una con su equipamiento, (de producción en un caso y de desarrollo/pruebas en el otro). Pues bien, sobredimensionandolo un poco, el CPD de desarrollo/pruebas se podría contemplar como un CPD "backup" . En caso de desastre, se pararía la actividad de desarrollo, pero el negocio podría continuar funcionando desde ese segundo CPD.
  

Una propuesta radical para mejorar la calidad del software:

Visto que muchas veces hemos de abordar los proyectos de software sin unas especificaciones claras por parte del cliente, trabajando con herramientas nuevas o que no dominamos totalmente, etc, etc. Y visto que habitualmente "vamos corrigiendo/aprendiendo sobre la marcha". Igual no estaría de más que, una vez terminado el proyecto, ya con las ideas más o menos claras, volvamos a "recomenzarlo".

Me explico: Una vez "terminado" el proyecto, con el software realizado ya operativo. Nos dedicamos a terminar de documentarlo, como solemos hacer habitualmente. Nos tomamos unos días de descanso, (para "desconectar" un poco). Y, con esa documentación, (más toda la experiencia adquirida durante el trabajo), volvemos a programar el software partiendo completamente de cero. Es decir, hacemos una "REFACTORIZACIÓN TOTAL".

De esta manera, tendríamos un código bastante más lógico y mejor organizado internamente.

Nota: una alternativa a esto serían algunas de las recomendaciones de las Metodologías Ágiles. Tales como: trabajar en ciclos iterativos, replanteandonos el proyecto en cada ciclo; refactorizar frecuentemente lo ya realizado; etc. Pero la ventaja de la Refactorización Total estriba en que no hemos de cambiar nuestro método de trabajo habitual. Tan solo hemos de "prolongarlo".....

20080605