archivo

Archivos diarios: octubre 25, 2010

Es difícil encontrar organizaciones en las que existe departamento de desarrollo y departamento de sistemas en las que no haya habido o haya conflictos y eso es debido al diferente enfoque que cada cual da a su trabajo, cosa comprensible ya que se trata de tareas diferentes, a la falta de comprensión mutua y a la pérdida de visión de los objetivos del servicio que el departamento de informática debe dar, pasándose a una serie de objetivos personales que por muy buena voluntad que se tenga, en la mayoría de los casos, ponen freno, precisamente, a la consecución de dichos objetivos globales.

Como sabéis, yo pertenezco al área de desarrollo y podía ponerme la camiseta de los de mi equipo y empezar a repartir estopa, pero no sería justo porque de igual forma que conozco muchas de las debilidades de los departamentos de sistemas, conozco todavía más debilidades de los departamentos de desarrollo, algo lógico porque es donde centro mi actividad laboral. Creo que no sería constructivo un artículo ombliguista en el que todos lo que hacemos los desarrolladores sea bueno y todo lo que hacen los de sistemas sea malo, tampoco sería constructivo si no especificase los comportamientos de cada mundo que acertados o erróneos no son comprendidos por la otra parte.

Los desarrolladores tenemos que responder ante el usuario por los problemas relacionados con los sistemas de información, tanto los que se encuentran en producción como los que están en desarrollo y puedo asegurar que los usuarios no se caracterizan especialmente por su paciencia. Además sea cual sea la causa del problema siempre echarán la culpa al programa o programas que utilizan, aunque éste sea debido por circunstancias que nada tienen que ver con él. Si falla la red, si se cae el servidor o pasa cualquier otra cosa es la aplicación el origen de todo mal. Esto aunque injusto, es razonable, ya que los usuarios no tienen por qué conocer toda la infraestructura que tiene un sistema de información para que funcione y ellos lo que notan es que el sistema no funciona, que va lento o cualquier otra contingencia.

Cada vez que sucede una incidencia de esas características se traduce, en función del tiempo que se tarde en resolver, el momento en el que se haya producido y el número de usuarios implicados, en trabajo, ya que habrá que volver hacia atrás tareas que no se han ejecutado correctamente y lo que es más importante, falta de confianza de los usuarios en la aplicación y en el equipo de personas que está detrás. Cuesta mucho ganarse el respeto y la confianza de los usuarios y sin embargo, perderlo, es mucho más sencillo.

También es cierto que la mayoría de los problemas que tienen las aplicaciones no son consecuencia del departamento de sistemas, sino porque las mismas tienen problemas funcionales y/o no funcionales que han llegado hasta la puesta en producción y esto es responsabilidad del departamento de desarrollo y/o de los usuarios si estos no han definido bien los requisitos o no han colaborado lo debido en todo el proceso.

Si la mayoría de los problemas que tienen las aplicaciones son resultado del proceso de desarrollo, ¿por qué nos fastidia/altera/mosquea tanto que de vez en cuando haya pérdidas de disponibilidad total o parcial de las mismas? Pues porque cuesta menos dar la cara cuando el problema es de tu responsabilidad que cuando es de otro y la cosa es que en la mayoría de los casos, independientemente de la naturaleza de la incidencia es el departamento de desarrollo el que recibe las “caricias” de los usuarios.

Otro problema que nos encontramos los desarrolladores con respecto al departamento de sistemas (o viceversa) es la existencia de prioridades distintas (en realidad son compatibles, pero nosotros mismos hacemos que cada una siga su propio camino) y esta circunstancia es la que favorece la creación del fenómeno de los dos mundos.

La prioridad de los desarrolladores es que los sistemas de información permitan el trabajo de los usuarios de la manera más eficientemente posible y, además, que el tiempo de respuesta ante las incidencias de las aplicaciones sea el menor posible. La prioridad de los departamentos de sistemas está en mantener la disponibilidad de los sistemas físicos, servidores y comunicaciones, así como establecer las medidas de seguridad apropiadas para evitar intrusiones o acciones no permitidas sobre cualquiera de los elementos anteriores.

Hasta ahí, todo bien, el problema está cuando los desarrolladores damos cabida a soluciones que no son compatibles con las políticas del departamento de sistemas o que requieren soluciones que muchas veces no están en su mano (los medios, memoria, procesador, etc… no son infinitos), de manera que pedimos la instalación de servidores nuevos, más memoria, más procesador, nuevas soluciones de bases de datos, etc… además de otros aspectos relacionados con las políticas de seguridad (apertura de determinados puertos, más capacidad de acceso a bases de datos, servidores, etc…,) generalmente, además, sin dar excesivo margen de maniobra en cuanto a buscar otras alternativas, ya que avisamos cuando ya se está trabajando en la solución o está terminada.

Como es lógico estas situaciones causan desgaste ya que por un lado los desarrolladores demandamos que se pongan a disposición de las aplicaciones las infraestructuras que creemos que se necesitan y pensamos, al no existir el tiempo de respuesta que nos gustaría, que los de sistemas viven en otro mundo, ajenos de los problemas del día a día de las aplicaciones y de los usuarios, y por otro los de sistemas piensan que no actuamos con perspectiva, que somos un desastre y que pretendemos resolver a base de fuerza bruta lo que no hemos sabido solucionar en el proceso de desarrollo.

En relación a este asunto, tengo que dar la razón a los de sistemas, ya que se suelen enterar demasiado tarde y eso es debido a que no se les consulta si una determina solución les parece adecuada con sus políticas e infraestructura. En el caso de que sea estrictamente necesario hacer una modificación en las mismas, además hay que darles tiempo para que puedan pensar en otras alternativas o a formarse o familiarizarse con lo que les hemos pedido que instalen y/o administren.

Otro problema que también ocurre con bastante frecuencia es el exceso de celo que a veces los del departamento de sistemas ponen respecto a determinadas políticas de seguridad, muchas veces desproporcionadas respecto a la realidad existente y basadas generalmente en apreciaciones personales más que en decisiones del propio colectivo del departamento.

Es necesario que desde sistemas establezcan las políticas, sería un error que desde desarrollo se impulsasen las mismas, pero es necesario que las mismas sean generales y conocidas y no se deje al criterio del personal su endurecimiento o reblandecimiento. Además es necesario que las normas que se dicten sean racionales con la realidad de la organización y sus capacidades, ya que a veces las mismas provocan un incremento de complejidad en el proceso de desarrollo o de gestión de los proyectos totalmente innecesario.

Muchos de estos problemas quedarían resueltos o, al menos, paliados si existiesen unas normas por escrito que rigiese el funcionamiento de los departamentos de desarrollo y de sistemas y si, además, los responsables de los mismos, siempre dentro de la profesionalidad y pensando en el interés general de la organización, llegasen a soluciones de consenso en aquellas excepciones, que seguro se producirán, que haya que estudiar por no cumplir parcial o totalmente las normas.

Además de todo lo anterior es necesario el respeto. Los desarrolladores tenemos que entender que los de sistemas conocen mejor la problemática del mantenimiento de las infraestructuras que nosotros y ellos deben entender que nosotros conocemos mejor la problemática del desarrollo y mantenimiento de los sistemas y las apreciaciones de los usuarios. También es necesario entender que ambos trabajos no son fáciles y que en muchas ocasiones, actuamos desde situaciones exigentes y con presión. Todos nos vamos a terminar equivocando, no una, sino cientos de veces y tenemos que intentar ser comprensivos.

Es difícil alcanzar la situación ideal en que los departamentos de sistemas y de desarrollo no sean dos mundos con objetivos dispares, sino uno solo que verifique el objetivo final de cualquier departamento de informática y que no es otro que dar el mejor servicio posible y eso solo se puede conseguir si todas las partes involucradas reman en la misma dirección.