archivo

Archivo de la etiqueta: departamento TIC

Si no se acota la cantidad de trabajo que se puede asumir a la capacidad real existente, quiere decir que el ritmo del proceso de desarrollo no lo marca la cantidad de trabajo que podemos sacar sino la cantidad de trabajo que entra y eso a corto, medio y largo plazo resulta perjudicial porque resulta muy complicado volver a encontrar el equilibrio.

¿Qué pasa cuando se satura un servidor o un PC? Que el rendimiento de los procesos abiertos cae en picado, pues exactamente lo mismo pasa cuando saturamos la línea de trabajo.

Por ese motivo insisto que un departamento TIC no debe decir a todo que sí, sino que debe ajustar su servicio a lo que realmente puede admitir y lo que no entre ahí tendrá que esperar. El problema es que como los departamentos TIC no pintan nada, aunque digan que no, habrá alguien más arriba que dirá que sí y empiece a saturar con ese tipo de decisiones a la capacidad de trabajo existente.

El problema no es solo ese, sino que además los departamentos TIC, como consecuencia de la crisis económica, cuentan con menos presupuesto, por lo que con cada recorte se desborda la capacidad, ya que con menos personal se deben seguir prestando los servicios básicos a la organización que además, crecen con el tiempo, al existir un mayor número de sistemas en la organización y ser cada vez más críticos en sus procesos internos y de negocio. Si a esto le sumas esa carga adicional de trabajo, por mucha voluntad que se ponga, la calidad del servicio caerá en picado.

El ritmo lo debe marcar lo que sale, porque las tareas que conseguimos terminar son las que determinan nuestra capacidad real y las que permiten dejar un hueco para que se pueda trabajar sobre otra.

En los proyectos de desarrollo de software pasa lo mismo, si trabajamos sobre demasiadas tareas de forma simultánea el esfuerzo y tiempo necesario para la realización de las mismas será mayor (incluso mucho mayor) que si las mismas estuvieran ajustadas a la capacidad del equipo, además, se corre el riesgo de que muchas de ellas queden abiertas indefinidamente si su prioridad no es muy alta, ya que seguirán entrando nuevas tareas y la presión y la carga de trabajo tiende a hacer que se centre el esfuerzo en ir cerrando todas las tareas que se puedan, que generalmente serán aquellas más simples y/o con mayor prioridad.

Una de las grandes aportaciones de la orientación a sprint (se siga Scrum o no) o de la aplicación de Kanban la tenemos en que se trata de limitar la cantidad de trabajo absorbible a la capacidad real de trabajo que puede admitir el equipo (limitación del WIP: Work in progress).

Es un caso específico del antipatrón “desfactorización“.

Puestos a priorizar, los usuarios querrán que se desarrolle primero las funcionalidades principales del sistema, dejando al desarrollo de las pantallas de administración (algunas simples, otras más complejas) para más adelante porque siempre existe la posibilidad de precargar los valores en base de datos y porque no se prevé que el grado de actualización sea elevado.

Por otro lado, los usuarios querrán flexibilidad y autonomía, de manera que no tengan que acudir a un desarrollador para modificar ciertos aspectos de funcionamiento e incluso comportamiento del sistema. Esta situación hace que proliferen más funciones de administración.

Tenemos una paradoja: los usuarios quieren ser autosuficientes y sin embargo no priorizan el desarrollo de pantallas que les permitan esta posibilidad.

Como siempre existirán funcionalidades que evolucionar u otras que implementar, estas pantallas siempre serán candidatas a quedarse fuera en cada sprint. Llegado el momento el presupuesto se agotará y la mayoría de ellas seguirán sin implementarse y se tendrá que recurrir al departamento TIC para que gestione la administración de esas aplicaciones trabajando directamente contra la base de datos, responsabilidad ésta que no debería recaer sobre ese departamento sino en el área usuaria, la cual a su vez se quejará de los tiempos de respuesta por parte de informática y por no poder ser ellos mismos quienes lo gestionen.

Los responsables técnicos del proyecto por parte del departamento TIC deben dejar claro al usuario que estas pantallas deben desarrollarse, que elijan el momento que consideren más adecuado, pero que finalmente tienen que construirse porque es su competencia y responsabilidad administrar la aplicación desde el punto de vista funcional y que la dependencia de informática en ese sentido solo debe y puede ser transitoria.

Pues lo pasamos mal pese a que el resto de la organización suele pensar que lo pasamos muy bien. No tenemos peso, no tenemos influencia a nivel directivo, lo importante es el negocio de la organización y nosotros somos solo un instrumento.

Se nos exige mucho y los recursos que nos suelen dar son muy limitados o por lo menos son inferiores a las necesidades reales. Si hay que recortar se recortará por la parte TIC ya que al fin y al cabo somos algo secundario.

Esa mentalidad no solo hace daño a los departamentos TIC sino que lo hace a la propia organización. ¿Puede la misma plantearse funcionar sin recursos TIC?, ¿sobreviviría a un apagón TIC? Seguro que no y sin embargo el tratamiento es similar a cuando todo funcionaba con papel y archivadores.

Es cierto que muchos departamentos TIC crecieron desmesuradamente (más en volumen de trabajo que en recursos) en la época de bonanza y eso se está pagando ahora pero también lo es que incluso quienes hicieron un esfuerzo en su día por ajustarse a la realidad están sufriendo actualmente.

Recortar sin medida en TIC es bajarle el octanaje al combustible, se piensa que el motor va a rendir igual. Eso no puede ser así porque las tareas siguen siendo X y los medios muchos menores que antes. No es cuestión exclusivamente de productividad (siempre es posible mejorar) se trata ya de una cuestión física.

Y no cabe duda que un Departamento TIC que funcione bien tiene influencia directa en el funcionamiento de la organización y por ese motivo debe cuidarse y tener un peso en la organización que no tiene. El responsable del Departamento TIC debería tener un puesto de nivel directivo y tener un trato de igual a igual con el resto de responsables de área.

Es absolutamente necesario en todo Departamento de Informática de una organización el conocimiento y comunicación de sus objetivos adecuados al contexto y circunstancias en las que se encuentra, de lo contrario, los distintos departamentos que la componen definirán sus propios objetivos o prioridades ajenos a una visión global del servicio que se tiene que ofrecer y dando la espalda a cualquier posibilidad de sinergia.

Y como decía sin olvidar contexto y circunstancias. Lo mismo las posibilidades actuales pasan exclusivamente por dar una buena atención orientada al puesto de trabajo de los usuarios e intentar dar supervivencia a los sistemas de información más críticos o prioritarios de la organización. Si no tenemos en cuenta donde nos encontramos probablemente no consigamos llegar a ningún sitio y enfoquemos los esfuerzos en aspectos secundarios que hagan que nos quedemos con la bolsa vacía.

Y no, no son tan obvios los objetivos de un departamento si no se definen o discuten. Los objetivos deben ser explícitos y recitados casi a modo de mantra por los que se tienen que encargar de alcanzarlos. Darlos por conocidos, sin reflejarlos en ningún sitio, sin hacer un seguimiento medianamente objetivo, es lo mismo que dejar las puertas abiertas al caos, a la definición de prioridades y objetivos singulares y a los reinos de taifas.

Algo que no termina nunca, dirán algunos.

Y no es así, más bien, no debería ser así. Vamos a analizarlo.

Un proyecto es un conjunto de actividades que se realizan en el tiempo (su realización, por tanto, es gradual) que tienen como objetivo producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó.

Definiciones, hay muchas, la anterior puede ser una de ellas.

¿Qué se realizan en el tiempo quiere decir planificadas? En algún momento, y eso es independiente de la metodología utilizada, hay que decidir cuándo se realiza la actividad. Personalmente me gusta más la expresión “se realizan en el tiempo” que “planificadas” porque lo segundo parece que se remonta a un horizonte temporal más amplio y no necesariamente tiene que ser así.

Un proyecto, por tanto y por definición, debe ser finito. Sin embargo, cuando hablamos de enfoques iterativos incrementales en el desarrollo parece que siempre lo hacemos pensando en una continuidad, como si el sistema siempre estuviera en continua evolución.

Ese enfoque es lógico y no solo sucede en ese tipo de ciclo de vida, también nos lo encontramos en el < href="clásico ya que un software siempre es susceptible de ser mantenido en sus diferentes vertientes (evolutivo, correctivo, adaptativo y perfectivo), lo cual no quita que planteemos horizontes temporales para conseguir determinados objetivos.

La vinculación que se tiene respecto a un sistema de información hace que, independientemente de que el proyecto sea el mismo para el cliente que para el proveedor, y por tanto, finalice a la vez, se tengan diferentes visiones, de cuándo realmente termina para uno y para otro.

Si tu rol es el de proveedor, el proyecto termina cuando se alcanzan los objetivos por lo que te han pagado y una vez finalizada la garantía establecida (esto puede ser más o menos tormentoso, llevar más o menos tiempo, pero los proyectos, terminan).

Si tu rol es el de responsable técnico del cliente no está tan claro cuándo terminas, si es que terminas, ya que existe una frontera poco definida entre lo que es la explotación y mantenimiento de un sistema de información (generalmente por una mala definición de las funciones y procesos de los departamentos TIC), por lo que no se termina de pasar página y esto sucede, tanto si se encadenan proyectos como si no. Eres responsable técnico del sistema y lo serás hasta que el ciclo de vida del mismo se cumpla.

El problema de que la vinculación al sistema de información sea esa es que, conforme vaya pasando el tiempo, cada vez serán más proyectos y sistemas con los que trabajes y la montaña se hace cada vez más grande, tanto que la gestión termina siendo insoportable porque habrá sistemas de información que durante un tiempo no den problemas, pero al final siempre aparecerá algo que origina un trabajo.

Cuando se gestionan muchos sistemas, la suma de elementos aislados forman una sucesión interminable de tareas, que afectan a los proyectos reales en los que estás trabajando en ese momento, mermando la calidad de las actividades que realizas en el mismo.

La respuesta la he obtenido en una cita anónima que dice que: “Cualquier programa que funciona correctamente está obsoleto”.

Es decir, la evolución del producto se puede extender a lo largo de todo su ciclo de vida porque en cualquier momento pueden aparecer nuevas funcionalidades que incorporar al sistema o la modificación de las ya existentes.

El desarrollo de software es así, evolutivo, cambiante y es importante que tengamos en cuenta ese aspecto a la hora de enfocar un proyecto, sobre todo si es complejo y/o de gran tamaño. También resulta fundamental la actitud pedagógica con la dirección de la organización y con otros departamentos para que tengan en cuenta este aspecto a la hora de designar los presupuestos para el Departamento TIC.

Si la finalidad última de un sistema de información es satisfacer las expectativas de los usuarios materializada en la informatización de un proceso o de una serie de procesos que permita realizar su trabajo con mayor eficiencia y productividad y/o la organización se beneficie mediante el almacenamiento y automatización de la información que se maneja, sin embargo ¿qué pasa cuando los usuarios no se sienten identificado con el problema o simplemente sienten que no existe un problema?.

Pues pasa que el proyecto para ellos pasa a ser algo secundario, cuando no algo sobre lo que poner todas las trabas posibles con el objeto de que no llegue a ningún sitio. ¿Acaso no conocemos todos proyectos que no han ido a ningún lado? Pues aquí una de las principales causas (junto a una mala ejecución de los mismos).

Por eso soy de la opinión de que no es misión de un departamento TIC de una organización crear necesidades ni en usuarios ni en directivos, sino que las necesidades deben ser expresadas por ellos y una vez hecho eso comprometerse e implicarse en el proyecto desde el principio hasta el final.

Sobre este tema Weinberg realiza una reflexión interesante cuando comenta (traducción libre): “Al final de todo, no hay mucha gente que quiera ver sus problemas resueltos”.