archivo

Archivos Mensuales: febrero 2009

Los usuarios en ocasiones desean magia, que se obtengan listados o se obtenga información a partir de datos inexistentes o grabados incorrectamente.

Sin una disciplina en la grabación de datos, los procedimientos de extracción de información y conocimiento son muy costosos y con escasa precisión.

Es importante por parte de los gestores de proyecto, informar a los directores usuarios de la importancia que tiene grabar datos con calidad. Es responsabilidad de los directores usuarios imponer una política entre el conjunto de usuarios orientada al uso correcto del sistema de información y a la grabación de datos precisos y con calidad.

Si la ejecutas a tiempo.

Si piensas, ya lo haré. Si piensas, no tenemos recursos para llevarla a cabo, vendrá mañana un competidor que también la tendrá y se llevará todo el negocio que podrías haber conseguido tú.

Tanto valen las ideas que incluso hay organizaciones en las que se convocan concursos entre sus empleados.

Los departamentos (y la filosofía) de I+D son esenciales para empresas tecnológicas, tanto para ejecutar ideas, como para mejorar la infraestructura de desarrollo. Estos departamentos son los que pueden marcar la diferencia con los competidores.

1) Ejecutar ideas: Las ideas en un papel no valen nada. Las ideas solo valen cuando compilan.
2) Mejora de la infraestructura de desarrollo: Es algo que estoy repitiendo muchísimo en mi blog. El framework debe ir mejorándose periódicamente y la construcción de componentes reutilizables (prefabricados) un objetivo.

Un Departamento de I+D, sirve para esas y para muchas más.

Si tienes un programador que ha salido de tu cantera y tiene talento y actitud, protégelo.

Le has formado, conoce tu política de empresa, conoce la tecnología de desarrollo, conoce el equipo humano, conoce el negocio. Esto vale mucho dinero. Si esta persona se va, traer a otro programador ya sea para la cantera o para ocupar su puesto, va a costar bastante dinero, ya que no todo es el sueldo, sino la capacidad de producción que se pierde hasta que se pone a la altura de quién se ha marchado.

A quien destaca, hay que impedir que se vaya, para ello debe sentirse bien en la empresa y reconocérsele su trabajo desde el punto de vista personal y económico.

No es lo mismo 1+1 que 1+2, no es lo mismo tablón que cab…

Pues eso, la toma de requisitos requiere precisión y por tanto que te enteres con exactitud qué quiere el usuario. ¿Qué tienes que preguntarle 1000 veces? Le preguntas 1000 veces.

El usuario quiere un producto final que le valga para algo, que le sirva para tener informatizado su proceso y si es posible además que le agilice el trabajo. Pues bien, para que le sirva para algo y para que le agilice el trabajo se requiere un análisis de requisitos que recoja con precisión lo que quiere y necesita.

¡Qué frase tan cierta!.

Desgraciadamente suele suceder que si no expresas que necesitas tal o cual recurso, que te mereces un ascenso, un aumento de sueldo, un descanso, nadie te hace caso.

Es muy injusto tener que llegar a la situación de quejarte para que te hagan caso, pero desgraciadamente suele ser así.

¿Por qué pasa esto? Pues porque quiénes toman decisiones se centran en problemas globales en lugar de en problemas locales. Eso en cierto modo es lógico, pero se puede solucionar delegando determinadas tareas en personas que sí tengan una visión más local de los problemática de la organización y por tanto puedan adelantarse de forma proactiva a la necesidad de la queja justificada para que te hagan caso.

Yo animo a que siguiendo los cauces adecuados y de buena forma, que todo aquel que tenga algo que reivindicar lo haga, sobre todo si entiende que se está cometiendo una injusticia.

Sí, lo reconozco.

Eso demuestra que tengo muchas cosas que aprender de la vida, de mi trabajo y de los demás.

Eso demuestra que además tengo deseos de aprender.

Eso demuestra humildad.

Reconocerse ignorante implica la conciencia de tener un largo camino que recorrer, camino que nunca termina, porque son prácticamente ilimitadas las áreas de conocimiento en las que uno puede aprender.

Reconocerse ignorante implica la necesidad de escuchar lo que los demás te dicen, ya que lo mismo aprendes algo.

Reconocerse ignorante es reconocer que eres una parte muy pequeña de un mundo muy grande y de un universo todavía mayor y que tienes potencial para brillar con luz propia dentro de ellos.

En mis posts, pasados y futuros, haré muchas menciones a la necesidad de tener frameworks de desarrollo que ahorren toda la codificación que sea posible y además que sean estables, de calidad (con el menor número de errores posibles) y basados en productos estándars y libres por un lado y componentes de más alto nivel desarrollados por tu propia empresa haciendo uso también de librerías primitivas estándars y libres. En la fortaleza de ese framework depende en gran medida la reducción de los costes de producción de software sin necesidad de perder calidad.

Pues bien, hay otro elemento importantísimo que eleva el nivel de todos los frameworks que tengas implantados en tu empresa: la comunicación.

La comunicación interna, entre el equipo de jefes de proyecto, analistas y programadores, para repartirse el trabajo coherentemente, para preguntar cualquier duda sobre el análisis, la arquitectura o la codificación y la comunicación con el cliente que es el que te tiene que suministrar las especificaciones funcionales y no funcionales del producto, el que te tiene que dar el visto bueno final y con el que tienes que pactar los plazos de entrega y otros plazos intermedios (para entregar documentación, ver prototipos, etc…). Tan importante es alimentar el framework de desarrollo como utilizar de base una buena política de comunicación.

Ya he hablado muchas veces de los frameworks de desarrollo, desde lo que son las piezas base del mismo, hasta llegar al nivel de componentes reutilizables (de alto y bajo nivel en función del proyecto), pasando por la selección de una arquitectura óptima para el proceso de desarrollo.

Todo lo anterior ahorra costes de desarrollo y si el framework es estable, pues también asegura un número de errores mínimo provocado por los mismos, por lo que también supone una buena base para la calidad de la entrega.

En este post, hablo de ir a más, de crear componentes software a nivel de aplicación, diseñado de tal forma que con una parametrización de la misma pueda ser implantada en diferentes organizaciones. Lo de la parametrización es lo óptimo, sé que no siempre se puede llegar a ese punto, pero por lo menos se debe lograr que esas piezas completas de software se puedan adaptar a una organización aplicando los menores cambios posibles sobre su código.

Diseñar software así no es sencillo, pero tener un catálogo de productos software disponibles para su instalación y parametrización supone unos beneficios en cada venta muy considerables, además de situarte frente a tus competidores en una situación privilegiada.

En este aspecto no puedes dejar para mañana lo que puedas hacer hoy.

Las cargas de trabajo importantes no deben provocar un descuido en el área de creación de negocio de tu empresa y empezar a buscar nuevos trabajos para realizar a corto, medio y largo plazo.

Ya lo he dicho en otros posts, es siempre mejor el peor overbooking (hay que saber gestionarlo para no morir de éxito) que el mejor período con personal sin trabajo que asignar.

No hay nada más cómodo que tener en tu disco duro o en una carpeta de tu red de área local las bases de datos Access, las hojas de cálculo, las capas de cartografía que necesitas para tu trabajo habitual.

Sin embargo, esta solución cómoda plantea un problema cuando la información con la que trabajas es un subconjunto de la información que se requiere para ejecutar o llevar a cabo un proceso de tu organización. ¿Por qué? Pues porque si tu tienes tu propio repositorio de información, en la sede central de tu organización otro, el compañero de la mesa de al lado otro y el del Departamento de enfrente otro y manejáis el mismo tipo de información, hay algo con lo que se vais a encontrar seguro y es la incoherencia y no homogeneización de la información. Y esto trae muchos problemas.

¿Cuáles son esos problemas? Si la información que tenéis no es coherente y tenéis que tomar decisiones basadas en esa información, lo más probable es que en muchos casos se tomen decisiones diferentes sobre un mismo hecho en función de la base de información que utilices.

¿Cómo se soluciona esto? Pues teniendo repositorios centralizados de información donde la misma sea igual para todos los que la utilicen, lo cual garantiza la coherencia de los datos y de las decisiones que se tomen que tengan como base la información.

El uso de repositorios centralizados requiere:

1) Disciplina, ya que la información no la guardas como quieres sino en base a unas especificaciones que son las mismas para todos los que manejen esa información.

2) Una correcta gestión del cambio. Una base de datos centralizada, por muy bien que estén las comunicaciones siempre va a tener un acceso más lento que a tu disco duro o a tu red de área local. Por tanto es importante que si se implanta un repositorio centralizado de información, se informe al personal de las ventajas que tiene el uso de esta estrategia.

3) Un buen ancho de banda. Una cosa es que te vaya más lento que en tu acceso local y otra cosa es que sea insufrible trabajar con ese repositorio centralizado. Si no se tiene un buen ancho de banda probablemente se pierda la disciplina de utilizar el repositorio central y se vuelvan a los repositorios locales.

4) Una tecnología que garantice la consistencia de los datos y las transacciones.

La creación de repositorios centralizados de información es una política que recomiendo a cualquier organización independientemente del tipo de información con la que se trabaje, alfanumérica (desde hace muchos años están consolidados los repositorios centralizados para este tipo de información), cartográfica y documental.