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”.

Muchas empresas de desarrollo de software han ganado dinero a espuertas gracias a esto, en ocasiones propiciado por ellas mismas y en la mayoría de los casos provocado por los mismos clientes. En cualquier caso no hecho la culpa de ello a quien es contratado, sino a quien contrata.

Esto suele suceder en organizaciones donde la gestión informática está descentralizada, fragmentada y sin la existencia de una política real de coordinación. En situaciones como esta cada departamento TIC suele hacer la guerra por su cuenta, en unos casos por ser autosuficiente, en otros por considerar que son capaces de hacer su trabajo mejor que el resto y en otras por un mero afán de ser dueño de un cortijo (la diferencia con la autosuficiencia es que en el primera caso el objetivo es no tener que depender de nadie más para garantizar el funcionamiento y disponibilidad de los sistemas, mientras que en el segundo el principal objetivo es mantener una parcela de poder).

Es cierto que las problemáticas en diferentes organizaciones puede ser distinta a la hora de enfocar un mismo proceso pero en muchos casos la solución no debe pasar por desarrollar un sistema específico para cada casuística sino en determinar qué aspectos son comunes, cuáles son divergentes y cuáles son los motivos que provocan esa diferencia para intentar reducirla, antes o durante el proceso del desarrollo del sistema único y si no fuera posible por lo menos reaprovechar toda la infraestructura que sea posible.

De esta forma tendríamos proyectos mejor dotados presupuestariamente y por tanto con una mayor margen para intentar, si el proyecto evoluciona racionalmente, que el resultado final salga de la mejor manera posible.

La bonanza económica de hace unos años constituyó un caldo de cultivo adecuado para el carácter independiente y autónomo de muchos departamentos TIC, yo tengo el dinero, yo me lo guiso y yo me lo como, la consecuencia de eso es que ahora tienen múltiples sistemas que mantener y sin dinero para poder hacer frente a los mismos. Si se hubiera sido más solidario en su momento ahora podría repercutirse los costes de mantenimiento entre diferentes departamentos y la cosa sería diferente.

Pero no solo hay que echar la culpa a los departamentos TIC (que la tienen) sino también a la falta de una coordinación desde la organización. Si no existen normas rígidas al respecto se abre vía libre a que cada cual haga la guerra por su cuenta. No es fácil establecer un marco de trabajo común, un roadmap general, pero si no se intenta, difícilmente se podrá llevar a cabo.

Esto pasa tanto en el marco de entidades privadas como públicas y es un aspecto en el que hay que tratar de mejorar, no ya por intentar hacer las cosas bien, sino porque en momentos de crisis económica como el actual porque no hay otra alternativa.,

Llevo unos cuantos artículos haciendo reflexiones sobre el hecho de que el desarrollo de software tiene un precio y que cuando se oferta (y se acepta) hacerlo por menos del mismo sin que exista una justificación para esa reducción del importe o que cuando se pone un presupuesto de ejecución inferior al que debería ser, el proyecto entra en una situación de alto riesgo para que se desarrolle con unos niveles de calidad aceptables o para que simplemente se ejecute. Hay que huir, por tanto, de ofertas imposibles y presupuestos insuficientes.

Esa situación ha hecho y está haciendo mucho daño a nuestra profesión porque al final todos pagamos justo por pecadores cuando un proyecto y otro también no alcanza unos niveles mínimos de calidad.

Sin embargo, por encima del Departamento TIC de una organización se encuentra la dirección de la misma que es la que hace el reparto de presupuesto entre los diferentes departamentos de la misma. Si al Departamento TIC se le asigna X y en realidad necesita 2*X o 3*X para poder ejecutar sus competencias, es necesario hacer ajustes y ese ajuste llega también a los presupuestos de los proyectos porque lo que suele suceder es que el recorte económico no suele ir acompañado por una rebaja de competencias, es más, en algunos casos va de la mano incluso con más tareas.

Ante esto, ¿qué se puede hacer?

1) Pelear hasta donde se pueda porque el presupuesto que te asignen sea el máximo posible acorde a las tareas que tienes que realizar. El éxito de esto dependerá muy mucho de la consideración y posición que tenga el Departamento TIC en la organización. Si no está bien posicionado, será complicado conseguir algo, pero por lo menos, hasta donde se pueda hay que intentarlo.

En uno de los primeros artículos que escribí comenté lo necesario que resulta que el responsable TIC de una organización ocupe un puesto directivo en la misma, de lo contrario está vendido. También he comentado que el presupuesto TIC debe ser gestionado integramente por el Departamento TIC ya que así se conseguirá un mejor rendimiento de la inversión económica y una mejor planificación.

2) Gastar mejor.

Esto empieza por priorizar ya que no todo es igual de importante ni todo es igual de urgente. La priorización implica prescindir de tareas que no son necesarias. Si nos ponemos a analizar hay muchas modificaciones en sistemas de información (generalmente evoluciones funcionales), alcances de muchos desarrollos u otras tareas dentro del Departamento TIC que son prescindibles. En todos estos casos, menos es más.

Si hay una solución que funciona, ¿para qué sustituirla por otra? (salvo que su coste total de propiedad sea superior al que tendría si se desarrollase de nuevo).

3) Mejorar la productividad de los propios equipos. Siempre es posible afrontar esta mejora y en estas situaciones donde el presupuesto y el trabajo es el que es es cuando hay que intentar mejorar la eficiencia del trabajo desarrollado. No se trata de trabajar más, sino de trabajar mejor.

4) Adaptar los procesos a la realidad presupuestaria.

5) Elegir el proveedor más adecuado para cada trabajo. No hay un proveedor universal que sea el mejor en todo, hay especialistas que hacen mejor una serie de tareas que otros. La elección de un proveedor que sea especialista en un área probablemente te pueda proporcionar mejores condiciones económicas con un nivel de calidad aceptable que otros. Como puede haber diversos especialistas sobre una materia, lo mejor es ir hacia una concurrencia competitiva y que gane el que mejor solución proponga, sin que el precio sea el factor principal para realizar la elección.

6) Tender al producto sobre el desarrollo a medida, cuando las condiciones sean mejores, que lo serán en la mayoría de los casos. Si además, la solución es libre, mejor (siempre y cuando el servicio que se te ofrezca sea competitivo frente a la alternativa propietaria).

7) Aplicación de estrategias ágiles en el desarrollo y mantenimiento de software.

Estas son algunas posibilidades que se pueden aplicar y permitirán optimizar tu presupuesto, sin embargo, no son los ingredientes de una receta que te permitan conseguir imposibles, si el desequilibrio entre lo que se puede gastar y los servicios a ofrecer son importantes, la calidad de los mismos se verá mermada.

Hace poco asistí a un curso de SGSI. Decidí asistir al mismo ya que al estar centrado en la gestión de proyectos de desarrollo de software, existen determinados aspectos como la seguridad de la información sobre los cuales no tengo excesivos conocimientos y además necesitaba una cierta actualización de los que ya tenía.

En el curso se planteaba la problemática de que costaba implantar medidas efectivas de gestión de la seguridad de la información ya que por mucho que se trabajase y por mucho que se invirtiese, siempre se rompía la cadena por el eslabón más débil que no es otro que las personas.

El problema es la falta de conciencia de la importancia que tienen la seguridad de los activos de una entidad, la cual llega hasta los niveles más altos de la organización que no terminan de priorizar adecuadamente estas tareas integrándolas como un proceso más.

A esto hay que sumarle el hecho de que exista una creencia generalizada de que la seguridad de la información se considera algo que es función del Departamento de Informática y como tal el resto de Departamentos suelen descargarse de responsabilidad.

El Departamento de Informática se encuentra con un problema ya que ahí sí que existe conciencia de la necesidad de aplicar una serie de medidas de seguridad que no es otro que tener que liderar las distintas acciones que se tomen al respecto, sin tener el apoyo del resto de departamentos y en muchos casos sin ser considerado algo prioritario desde arriba.

Al final, mucho esfuerzo que conseguirá determinados objetivos pero sin poder llegar a las personas y con la sensación de que se está luchando solo contra molinos de viento.

En los Departamentos de Desarrollo sucede algo parecido, ¿en cuántos proyectos los usuarios no han hecho adecuadamente su labor, teniendo que suplir el equipo de proyecto muchas de las funcionalidades que no han sido correctamente definidas?, ¿en cuántos proyectos los usuarios han cambiado, incluso radicalmente, los requisitos en etapas tardías de la construcción?, pero en los Departamentos de Seguridad es incluso peor, porque los sistemas y sus resultados se pueden ver, pero la seguridad no (solo se ve cuando hay un problema, que suele ser importante y del que por supuesto se hecha la culpa a Informática).