Mi espacio

Es el primer título que se me ha venido a la mente para compartir con quienes siguen este espacio las preocupaciones que tengo como emprendedor. Desde muchos puntos se anima a la gente a emprender, pero sinceramente el emprendedor emprenderá sin que nadie lo anime, sin embargo, si no se le advierte puede incurrir en errores que son evitables. Por lo tanto, veo positivo compartir la parte menos positiva de emprender.

A nosotros (@klicap) no nos va mal, de hecho considero que partimos desde una posición privilegiada porque:

1. Nos conocíamos como equipo, y eso ayudó a estar relativamente bien organizados.
2. Teníamos claro que lo más importante para nosotros era el bienestar del equipo y disfrutar de nuestra profesión.
3. Sabíamos qué tipo de cosas no queríamos volver a hacer y que las evitaríamos mientras pudiéramos.
4. Teníamos algunas iniciativas en mente con las que teníamos ganas de jugar.
5. Y además, teníamos algunos proyectos que nos ofrecieron y que económicamente están haciendo que todo esto exista.

Aunque algunos trámites se pusieron en marcha en el 2009, para nosotros klicap (como empresa) nace en enero de 2010. Han pasado ya tres meses y parece que fuera ayer cuando estábamos buscando oficina. Y es ahí donde está una de mis preocupaciones, el tiempo, o mejor dicho, la sensación de que el tiempo pasa muy deprisa. Para nosotros es muy pronto para hablar de resultados pero sí tenemos marcados algunos hitos en nuestra hoja de ruta con resultados parciales. Consideramos que es importante tener algo tangible para:

1. Por una lado comenzar a recibir comentarios y críticas cuando antes. Queremos una integración continúa entre el cliente potencial, el producto y nosotros.
2. Y por otro, comenzar con las tareas de marketing que todo producto requiere. En nuestro caso más aun porque comenzamos de cero y tenemos que dar a conocer klicap como marca y luego sus productos.

¿Qué pasa con esas oportunidades que se presentan durante el tiempo que has definido para desarrollar esos resultados parciales? Lo sensato es dejarlas pasar y pensar que ya vendrán otras oportunidades. Sin embargo, lo sensato puede ir acompañado de:

• ¿Y si luego no llegan las oportunidades?
• ¿Y si el producto no funciona como esperamos?
• Si no entra dinero no podremos seguir financiando los productos

El tiempo es para mi algo que no lo mide un reloj sino un cronómetro. Y junto al miedo está la desilusión que puede provocar que los resultados parciales no sean los esperados. No todo el mundo es capaz de caerse y volverse a levar, quizás se necesite tiempo, tesoro divino que corre en nuestra contra.

El tiempo y la desilusión están acompañados de la soledad. Cualquier ayuda que un emprendedor pueda recibir del estado español tiene letra pequeña. Menos mal que en esta soledad hay un montón de gente. Pese a estas líneas, sólo puedo decir que sigo muy ilusionado, pero también quiero mi dosis de realidad.

Supongo que será difícil que coincidamos en la respuesta, pero de eso se trata, de conocer distintas opiniones. Cuando digo con experiencia no me estoy refiriendo a que hayan participado en varios proyectos a lo largo de 2, 3 o 4 años escribiendo código Java, PHP o C. Me estoy refiriendo a que profesionales desarrollen su carrera profesional como desarrolladores de software.

Desconozco la organización en roles/perfiles que existen, pero en mi anterior puesto de trabajo como responsable de departamento de desarrollo, puse en marcha la siguiente propuesta:

Obviamente, por el tamaño del departamento y otros factores, tuve que prescindir de algunos roles, pero de haber continuado y crecido en número, hubiéramos tendido a esta propuesta. Recomiendo la lectura de Cracking the Code: Breaking Down the Software Development Roles. Detrás de esta iniciativa había varios objetivos pero los principales eran:

1. Especialización. Dar la oportunidad de que cada uno pudiera desarrollar su carrera profesional desempeñando una actividad con responsabilidades claramente definidas y conociendo el papel que juega dentro del equipo.
2. Facilitar la ejecución de procesos internos del departamento. En muchos de los procesos internos intervienen varios roles y saber quién tiene que hacer qué no es una tarea sencilla.

Aunque no lo parezca tu organización interna se puede ver condicionada o afectada por tu cliente. Desde que comencé mi actividad profesional en el 2001 he tenido la oportunidad de conocer a muchas empresas del sector, lo cual se traduce en conocer a muchos profesionales. He de añadir que salvo en contadas ocasiones (esto ya está cambiando) las empresas eran andaluzas o con sede en Andalucía. Hoy por hoy me sigue resultando extraño comprobar que parece existir una evolución profesional:

1. Desarrollador. Compañeros de universidad, conocidos y amigos coinciden con que su primer trabajo fue participar en un desarrollo, comenzar algún pequeño proyecto desde cero o simplemente instalar una aplicación, probarla y hacer sus manuales.
2. Analistas. Estos mismos pasan a participar en reuniones con los clientes, redactar actas de reuniones, atienden peticiones de cambio, redactan documentos de análisis, pero también siguen desarrollando de puertas hacia dentro en su empresa.
3. Jefe de proyecto. Básicamente todo lo anterior pero se añaden otras responsabilidades, algunas impuestas por la cultura interna de la empresa y otras por el cliente. Obviamente participas en la preparación de ofertas.
4. Consultor. Aquí ya pueden entrar muchas otras cosas, pero la idea es transmitir experiencia, de puertas hacia fuera eres “experto en“.

¿Quién origina o alimenta esta evolución?

• Los profesionales. ¿Somos nosotros lo que queremos pasar por todos esos perfiles? ¿Lo hacemos porque para ser consultor hay que haber sido desarrollador?
• Las empresas. Desde los departamentos de recursos humanos se fomenta esta evolución porque se cree que debe ser así.
• Los clientes. Sí, sí, los clientes. ¿Cuántos clientes conocéis que son ellos mismos los que imponen la estructura del equipo y describen las funciones a desempeñar de cada rol/perfil? Y si lo pensamos un poco, incluso estipulan el precio / hora de cada rol/perfil.

No afirmo, simplemente reflexiono en voz alta:

Si los clientes pagan más ciertos perfiles, lo lógico y normal es que las empresas vean ahí margen económico. Las empresas intentarán que alguien con 5 años de vida laboral pase a ser jefe de proyecto de cara al cliente. Internamente cobrará lo que tenga que cobrar. A todos nos gusta evolucionar profesionalmente y que nuestro trabajo se valore, y una prueba de ello son (o deberían) nuestras retribuciones económicas. Si me gusta desarrollar nunca podré cobrar 35K anuales porque los clientes no pagan por las tareas de desarrollo ese precio.

Ahora sí afirmo:

Sólo hay que ver los portales de empleo especializados en el extranjero para comprobar que sí es posible que haya desarrolladores de software con experiencia.

Una vez más una situación particular que en pocas otras profesiones sucede.

Desde luego me siento más crítico que nunca, pero no puedo evitarlo. Está claro que este gobierno no sabe hacer las cosas de otra forma y ha recurrido a una subida de los impuestos. La cuota de la seguridad social para trabajadores autónomos ha vuelto a subir.

El mes anterior:

No si va a ser verdad que es mejor estar en el paro, especialmente para aquellos que tenemos 9 años cotizados. Desde luego así no hay quien ponga en marcha un proyecto.

Hoy me ha comentado el gerente y dueño de una empresa algo que me gustaría compartir con los que siguen este pequeño espacio. Resulta que hoy iban a entrevistar a candidatos para varios puestos de trabajo. El número y los puestos no son relevantes. Obviamente las entrevistas estaban concertadas previamente. Viendo que uno de los candidatos no se presentaba, lo llaman por teléfono para conocer qué había pasado. Resultado de la conversación:

Es que lo que me ofreceis no me compensa, prefiero seguir cobrando el paro

Supongo que hay gente que mira lo que percibe en su cuenta estando en el paro y si estando contratado ingresa 50 euros menos, prefiere seguir en el paro. ¿Puede ser esto verdad? Es cierto que cada persona es un mundo y tiene sus circunstancias, pero que un empresario esté intentando cubrir un puesto de trabajo y escuche algo así tiene que dejarte de piedra.

Tengo la sensación de que esta gente que está esperando a que llegue un día y abran los telediarios diciendo “la crisis ha pasado, ya no hay crisis”. Reconozco que nunca he creído en los políticos  (sí en la política) y tampoco tengo esperanza de que vayan implantar medidas inteligentes, pero si alguien puede hacerle frente a la crisis son los propios empresarios, los mismos que la provocaron.

Desde luego no es la primera vez que me lo planteo pero recientemente he vivido alguna situación que me ha hecho reaccionar. En Andalucía existe un conjunto de proyectos horizontales (@firma, Trew@, Solicit@, @ries, etc) que conforman el soporte de la administración electrónica.

Muchos de los proyectos que se desarrollan para la administración pública andaluza están condicionados por estos proyectos. Y digo condicionados por desde el propio pliego ya se indica qué componentes deben usarse.  En algunos casos su integración es muy positiva pero en otros es ganas de disparar los indicadores de riesgo de proyecto. Dejando a un lado opiniones no argumentadas, me hago la siguiente pregunta:

¿Por qué resulta tan complicado para los proveedores de software que NO hemos participado en esos proyectos horizontales acceder a esos servicios?

Sé que existe documentación publicada, la posibilidad de acceder a los binarios de algunos de estos servicios, que siempre circulan por ahí CD con contenido no oficial, etc. ¿Pero no sería más conveniente e inteligente acercar estos servicios a los proveedores de software para que todo resultase más sencillo? ¿Sabéis lo frustrante que resulta tener que descompilar una clase para solucionar una incidencia? Bueno, y depurar una odisea.

Tengo que reconocer que algunos de estos servicios (denominados normalmente plataformas), por su naturaleza no pueden estar accesibles de forma pública. Sin embargo, creo que existen alternativas sencillas que pueden facilitar el trabajo. Recientemente he realizado algunas propuestas:

1. Estos proyectos ofrecen en su mayoría interfaces basadas en servicios web para su integración. Sería de gran utilidad, si no se quieren/pueden distribuir, ofrecer simuladores para que los equipos de desarrollo puedan diseñar al menos sus pruebas de integración y funcionales.
2. ¿Por qué no distribuir máquinas virtuales con estos proyectos instalados y configurados? Son muchos los ecosistemas software que cuentan con entornos virtualizados donde resultaría trivial desplegar estas máquinas y así poder configurar entornos despliegue.

La propuesta ha sido realizada donde corresponde e incluso me he ofrecido a formalizarlas para conocer costes e impacto. ¿Alguna otra propuesta?

Esta mañana, leyendo mis sindicaciones me he encontrado con una demostración de que en política se miente. No penséis que soy tan inocente, simplemente que no había visto una demostración tan objetiva, elegante y con tacto desde hacía tiempo. El año pasado escribí una entrada titulada “El dinero es mío y hago lo que quiero” que está muy relacionada.

Verdaderamente no me molesta que se apueste o no por el software libre, o en general, por un conocimiento libre. Lo que me molesta es que se haga política con estas cuestiones. Y mirando la situación desde una perspectiva algo más amplía, el malestar pasa a indignación cuando el dinero público no se gestiona correctamente.

Esto va por etapas. Cada cierto tiempo vuelve la eterna discusión sobre si la informática es una ingeniería. Precisamente durante los últimos días he leído comentarios y blogs con excelentes opiniones. En esta ocasión no voy a compartir mi opinión porque creo que tengo poco que aportar al tema, pero sí voy a contar otra anécdota.

Me encuentro en pleno proceso de decoración de lo que espero sea la cocina de mi casa. Eligiendo materiales, distribución de espacios, sopesando entre lo que uno quiere y lo que uno puede, y todas esas cosas que a muchos ya les sonarán. Esta tarde me he acercado a informarme para conocer cómo trabajan en una gran superficie y me lo han explicado todo perfectamente. Te hacen un estudio previo a partir de un plano que les entregas, de los materiales y algunas características adicionales. Con ese estudio te dicen si estamos hablando de 10.000 o 30.000 euros. El siguiente paso es realizar un proyecto (vamos una oferta cerrada) donde sí se detallan los materiales, tamaños, formas, plazos, garantías, planos, perspectivas y todo aquello que ayuda a imaginarnos lo que estamos comprando. Si bien el estudio previo es sin compromiso y totalmente gratuito, este proyecto como ellos llaman sí tiene un coste. No me lo han fijado pero creo que estará entre 100 y 150 euros. Me parece algo totalmente lógico y comprensible que cobren por su trabajo.

Una vez que me he despedido y agradecido su amabilidad, las preguntas no se hicieron esperar. ¿Por qué en nuestra profesión esto no es así? ¿Cuántos concursos públicos se preparan sin recibir nada a cambio? Sólo te compensan si los ganas, obviamente. ¿Cuántas veces nos ha pedido opinión que bien pudiera haber sido el primer punto de una consultoría?

Ingeniería o no, en nuestra mano está dignificar una profesión que para muchos es su oficio y su pasión.

En mi profesión, la sobrecarga se asocia directamente a una prolongación del horario laboral. Esa prolongación equivale a un aumento del esfuerzo (horas), un indicador muy fácil de detectar. Sin embargo, no siempre se refleja de esta forma. Cuando un equipo ve aumentados sus objetivos, de forma casi natural, comienza a priorizar. Desde fuera puede llegar a dar la sensación de que los objetivos se alcanzan, pero si verdaderamente existe sobrecarga es porque hay otros objetivos que se están quedando por el camino.

Dos cualidades que  te pueden ayudar a diferenciarte de tu competencia son tu forma de trabajar (“el como”) y tu producto (“lo que entregas”). Cuando hay sobrecarga y esta no se manifiesta en ningún cuadro de mandos, quizás estés perdiendo lo que hasta la fecha te diferencia ligeramente de tu competencia. Evidentemente, eso es mucho más difícil de medir.

El otro día escribía en mi twitter “Dar soporte a software no tiene nada que ver con desarrollar software nuevo. Menudo puente con Struts 1.2.x“. La verdad es que sólo hay ver el timeline o las gráficas de STractistics para ver que en los últimos días le estoy dedicando bastante tiempo a uno de mis principales proyectos. Durante los últimos años los esfuerzos se han centrado -principalmente- en ofrecer soporte. Hay clientes que lo han contratado y otros usuarios del proyecto han pedido ayuda y en la medida de las posibilidades se les ha dado.

Desde hace bastante tiempo tengo en mente construir una nueva versión, con nuevo diseño y aprovechando toda la experiencia adquirida atendiendo a los usuarios y viendo las nuevos caminos que se presentan. Mi poca (o mucha) dedicación se ha centrado en la versión 2.x y cada incidencia que sucedía en la versión 1.x me provocaba la sensación de estar retrasándome en la construcción de esta nueva rama. La situación es complicada. Con el poco tiempo libre del que dispongo, cualquier interrupción supone retomar de nuevo el proyecto. Y eso para alguien como yo que es incapaz de decir “no” a nuevos retos, es lo peor.

Sin embargo, he decidido cambiar el enfoque. Para tener la sensación de que el proyecto no está anclado en el tiempo se necesita feedback, y que mejor forma que atendiendo a las peticiones de mejora que tengo anotadas en mi cuaderno, mails, herramientas como uservoice o simplemente ideas que se van ocurriendo . Esto tiene sus consecuencias y una de ellas es no caer en la tentación de refactorizar todo el proyecto porque haya cosas que harías de otra forma. Para eso ya tengo la versión 2.x, y esto significa, que esta nueva rama continuará y algún día verá la luz.

Tengo que reconocer que estoy enganchado a este proyecto. Para mi es un vicio, especialmente si nos referimos en su sexta acepción de la RAE. Verdaderamente he llegado a esta conclusión cuando durante estos días he disfrutado a muerte cerrando tickets y ansiaba el momento de publicar una nueva release. A veces me surge el deseo dejarlo, darle las gracias por todo lo que me ha hecho leer, investigar y luchar, y dar paso a nuevos proyectos.

No quiero ni pensar lo que tiene que sentir un emprendedor todos los días mientras su sueño se desarrolla. Supongo que él también estará enganchado.

Hace unos días leía en el blog de kybele consulting una entrada muy interesante sobre métodos de estimación software. En la entrada se hace referencia a unas transparencias en las que hay información con la que estoy de acuerdo, sin embargo, y probablemente sea un problema particular mío, todo eso me suena a pura teoría más propia de una asignura de aquella carrera que tanto me aburrió.

Estoy convencido de que mucha gente pensará que estoy equivocado, y es probable, sin embargo, creo que en cualquier método de estimación de proyectos software (incluidos productos) en el que no tengamos en cuenta a los recursos (al equipo), la incertidumbre será abundante. Muchas veces me veo obligado a planificar proyectos incluyendos costes y la sensación que tengo es de levantar el dedo y ver para qué lado sopla el viento. ¿Cuántas veces no se ha preparando una oferta para un concurso público haciendo ingeniería inversa? El dinero que hay es X, pues a partir de ahí defino mi oferta (planificación, recursos, tecnología, etc).

Una de las líneas de trabajo en los ecosistemas software es la base histórica de proyectos. Realizar una estimación teniendo en cuenta tus recursos (conocimientos, habilidades, especialización, etc) y una base histórica, sigue siendo predecir, pero lo cierto es que cada vez acertamos más. A continuación un breve listado de situaciones que hacen que la estimación se parezca a la realidad con la misma probabilidad que un niño de 3 años escriba en un post-it los números del euromillón:

1. Optar por un marco tecnológico en el que no se tenga experiencia. Hace un “Hola mundo” no es tener experiencia.
2. Que en el equipo definido no haya un líder tecnológico. Un líder tecnológico no es un jefe de proyecto.
3. No disponer de un entorno de desarrollo flexible, cómodo y fácil de usar. Podemos llamarlo Ecosistema Software.
4. Ausencia de metodología. Si es un proyecto pequeño y un equipo pequeño, el correo electrónico puede ser su ecosistema, pero en el resto de casos, mal vamos.
5. Reacios a los cambios. Si no admites y pones trabas a que lo requisitos cambiarán, entonces tienes el riesgo de que el mal rollo aparezca.
6. El proyecto tiene un tamaño que no puedes controlar. Muy simple, pasas de ejecutar proyectos de 3-5 personas durante 3-8 meses a 6-15 personas durante 12-18 meses. Los proyectos que se prolongan en el tiempo tienen ciertos aspectos que no aparecen en proyectos pequeños.
7. Tu diseño está condicionado por el cliente y no te siente a gusto desde el comienzo. Mal empezamos porque tu crees que deberían de confiar en ti como proveedor de software y dejarte libertad.

Como en todas las listas que hago, siempre se podrían añadir más puntos. Lo dejo para quienes leen este espacio.

No es que ponga en duda los benecifios que un conocimiento libre aporta a la sociedad, pero ayer surgió algo que me hizo replantearme -una vez más- ciertas cuestiones en mi carrera profesional.

Anoche, salí de casa para ayudar a descargar unas maletas y le pregunté a mi hermana antes de cerrar la puerta: “¿Tienes las llaves de casa?“, ella me respondió que sí, y automáticamente tiré de la puerta. Justo al cerrar me vino a la mente que me había dejado las llaves puestas por dentro. Os lo estáis imaginando, ¿no? La puerta no se podía abrir desde fuera porque la llave estaba puesta por dentro.

Automáticamente salí a la puerta del residencial donde vivo para buscar el teléfono de un cerrajero. Había varios, elegí el que tenía la pegatina que más me llamó la atención. En menos de 20 minutos, el cerrajero estaba en la puerta de mi casa. Intenté estar atento para ver lo que hacía pero fue imposible. Lo único que escuché fue el ruido de una segueta. En menos de 5 minutos la puerta estaba abierta sin necesidad de estropear ninguna llave ni la cerradura. Me cobró por el servicio 70 euros que pagué con mucho gusto porque me veía en la calle un viernes a las 22:15.

El cerrajero hizo por donde para que yo no conociera lo que había hecho. Estoy convencido que lo que hizo fue algo muy simple, sin embargo, si todo el mundo conociese la forma de hacerlo, él y otros cerrajeros perderían la oportunidad de ganar esos 70 euros por menos de 30 minutos de trabajo (incluyendo desplazamiento).

¿Qué pasaría si en nuestro sector aplicásemos ese planteamiento? No me estoy refiriendo a que Opina deje de ser libre y de fuente abierta, sino a ese conocimiento que uno adquiere con la experiencia del día a día y que es el que nos da valor en mercado laboral.

El pasado domingo 26 de abril terminé con mis evaluaciones de los proyectos del Concurso de Software Libre. Evidentemente no voy a comentar nada sobre los resultados pero sí me gustaría compartir algunas opiniones sobre algo en lo que vengo pensando desde hace muchos años: la carrera de informática, en sus tres titulaciones universitarias, necesita refactorizar sus temarios. Evidentemente, evaluar unos proyectos realizados por alumnos universitarios (no todos pertenecientes a la carrera de informática) no es significativo para sacar conclusiones, ni mucho menos, pero mientras evaluaba los trabajos no pude evitar que me vinieran a la mente iniciativas que surgieron dentro la Escuela Técnica Superior de Ingeniería Informática de la Universidad de Sevilla para reforzar esos temarios con contenidos que considerábamos FUNDAMENTALES, especialmente si el fin era desarrollar software. Lo sé, la informática no sólo es software, pero desde luego prácticamente todo el mundo que conozco ha terminado vinculado al desarrollo de software. También es cierto que otros son comerciales o gerentes, en este caso siempre me pregunto, ¿Para qué estudiaron informática pudiendo elegir otras carreras más adecuadas a esos perfiles? Pero bueno, esto es otro tema.

Algunos puntos que deberían tenerse en cuenta en dicha refactorización:

1. Existen un conjunto de herramientas básicas que los alumnos deben conocer a lo largo de sus años de estudio:
   1. IDE: Eclipse, Netbeans, Visual Studio, etc.
   2. SCM: centralizados, distribuidos, características básicas, buenas prácticas, comparativas, etc.
   3. Construcción: Ant, Maven, GNU build tools, Scons, etc.
   4. Issue traking: ¿Qué son? ¿Para qué sirven? ¿Qué nos aportan?
   5. Wikis: ¿Qué son? ¿Para qué sirven? ¿Qué nos aportan?
2. Metodologías: ¿Qué metodologías están surgiendo? Casos de éxito, Principios básicos, ¿Por qué surgieron? ¿Quiénes fueron sus mentores? etc.
3. Aseguramiento de calidad: métricas, definición de pruebas, tipos de pruebas, herramientas, etc.
4. Gestión de proyectos

Supongo que vosotros añadiríais o eliminaríais cosas, ¿Qué cosas?

Antes hablaba de iniciativas y me gustaría recordar que hace ya algunos años tuve el placer de participar en una asignatura de libre configuración llamada “HGPS: Herramientas de Gestión de Proyectos Software”. Para mi fue una suerte y toda una experiencia preparar el temario de aquella asignatura con Manuel Resinas, alumno de la Escuela por aquella época y hoy Doctor en Informática. Y con Rafael Corchuelo, uno de los mejores docentes que he conocido.

Para los que no lo sepan, aquella asignatura de libre configuración era el preámbulo de lo que hoy es el grupo de trabajo sobre Ecosistemas Software.

Hace unos días leí en el blog de María Martínez que iwannagothere ha recibo inversión (capital) de tres empresas, una de ellas es The Cocktail. Este proyecto fue creado por María Martínez, Manuel Muñoz Solera y Fernando Blat, todos ellos pertenecientes al equipo de The Cocktail.

Quizás me equivoque pero sospecho que un día ellos se juntaron, definieron el modelo conceptual del proyecto y con mucho esfuerzo y dedicación se pusieron a construir. Verdaderamente alabo estas iniciativas porque compaginar tu trabajo dentro de una empresa y emprender proyectos personales supone privarse de muchas cosas.

El que tu propia empresa valore eso y se decida a potenciarlo (es este caso con capital) es fantástico. Por una lado la empresa invierte en una idea que el día de mañana le puede dar beneficios y por otro lado, está capacitando la creatividad e iniciativa de algunos de sus empleados. No hacerlo tiene muchos riesgos. Si la gente está convencida de la idea y comienza a funcionar quizás decidan abandonar la empresa y comenzar su propio camino.

Teniendo en cuenta la época económica que estamos viviendo, potenciar las iniciativas es algo muy necesario. ¿Te suena esta situación?

No, no voy a hablar de la Semana Santa. De hecho es una celebración en la que aprovecho sus días festivos para hacer una escapadita a Portugal para disfrutar de uno de los deportes que más me gusta, el surf. Sin embargo, tengo unos amigos que son devotos y disfrutan con esta tradición popular. Algunos son costaleros en sus hermandades y cuando están con sus conversaciones, yo siempre hago la misma pregunta, ¿Qué pasa si uno de los costaleros no hace bien su labor? Se nota mucho?. Todos responden al unísono, “es de lo peor que puede pasar, el trabajo de todos los costaleros se ve gravemente resentido“. Por ejemplo, en un equipo de fútbol no creo que este efecto sea tan notorio pero desde luego implica un sobre esfuerzo para el resto de sus compañeros. Y en un departamento de desarrollo, ¿Qué pasa? ¿Qué efecto tiene cuando un recurso no desempeña correctamente su labor o no rinde lo que se espera?

En este caso el efecto también es muy notorio, tanto que los resultados de ese recurso tienen que ser alcanzados por otros recursos. Esto se traduce que en departamentos pequeños haya recursos asumiendo un sobre esfuerzo constante.

¿Qué se hace en estas situaciones?

Muchos son los proyectos de gestión de contenidos que frecuentemente se ponen en marcha. En los últimos años he tenido la oportunidad de participar en este tipo de proyectos para Ministerios, Consejerías, Ayuntamientos y empresa privada. Me sigue sorprendiendo que lo que más preocupe sea la solución tecnológica. Hace unos años sí podía suponer un reto pero hoy por hoy no lo creo. El verdadero reto no está ahí. A continuación algunas impresiones que suelo compartir con quien me consulta:

1. Por regla general existen múltiples opciones, no hay una mejor solución, especialmente en cuanto a gestión de contenidos se refiere.
2. Elegir una solución tecnológica sin conocer qué tipo de información se va a tratar y cómo, condicionará el resultado final.
3. El como es tan importante que descarta inicialmente ciertas soluciones tecnológicas. Dependerá de nuestra estrategia a la hora de organizar los flujos de trabajo. ¿Centralizado, distribuido?
4. La flexibilidad es un requisito fundamental en la gestión de contenidos por lo que debemos tener presente las necesidades presentes y disponer de los medios para atender necesidades futuras. ¿Cuánto me constará el día de mañana incluir un nuevo contenido o que varios contenidos estén relacionados?
5. Aspectos clave a la hora de elegir una solución tecnológica de fuente abierta:
   1. Comunidad: foros, listas de distribución, comunidades locales, etc.
   2. Estabilidad: roadmap, versionado, etc.
   3. Facilidad: ¿Qué nos resultaría más sencillo de mantener y soportar?
   4. Modularidad: ¿Está especificada la forma de extender su funcionamiento?
6. Si el proyecto conlleva migración, aprovecha la migración para reorganizar y revisar tu información a la vez que validas las funcionalidades que estás construyendo.
7. La solución tecnológica define el punto de partida y la pendiente del camino.
8. Un proyecto de gestión de contenidos no consiste en instalar una solución software clasificada como CMS, personalizarla y cargar contenidos.

¿Qué relación existe entre las soluciones CMS y los gestores documentales?