Ingeniería del software

Cómo evitar que el estrés te queme.

2007-11-19T07:00:00.000+01:00

Ciertos acontecimientos muy cercanos en el tiempo, me han hecho recordar la entrada que Naomi Dunford publicó hace cerca de un mes en su serie dedicada a la gestión del tiempo (Time Management for Entrepreneurs): How to Avoid Burnout.

Dichos acontecimientos me han hecho soltar algunas lágrimas, muchas menos que las derramadas por las personas directamente afectadas.

Desde aquí, un abrazo a los dos, y todo mi apoyo. Son momentos difíciles, lo sé, pero debe ser no más que un pequeño obstáculo que os haga abrazar al futuro con toda vuestra nueva energía, fuerza y pasión. Ánimo.

Sin llegar a extremos como el vivido por Naomi o por el que ha motivado este post, todos hemos vivido en algún momento de nuestra historia, situaciones en las que el tiempo corre en nuestra contra, que no nos da tiempo a hacer lo que teníamos previsto. Momentos en los que los acontecimientos se nos echan encima sin darnos un respiro. Momentos en los que los esfuerzos realizados se convierten en manos que nos ahogan. Si estas situaciones se prolongan en el tiempo, llegamos a quemarnos.

Citando a Naomi, de nuevo, pensemos en el término "quemarse":

Imaginemos una vela recién encendida. Su luz es brillante, fuerte. Nos proporciona calor y nos alumbra el camino. Es una ayuda.

Al pasar el tiempo, después de haber dado lo mejor de si, empieza a apagarse en sus propia cera derretida, no sin antes estremecerse y luchar por mantenerse encendida, terminando por quedar sólo la punta incandescente, hasta que finalmente, se apaga, soltando un hilo de humo que se pierde en la habitación antes iluminada.

No podemos lucir siempre

El proceso de la vela es extensible a nosotros mismos: no podemos dar lo mejor de nosotros constantemente. No podemos lucir siempre. Lección: cuando no podamos lucir lo suficiente, alto. Parémonos. Recarguemos nuestras energías lo suficiente, y vuelta a lucir.

Descanso necesario

Los momentos de desconexión son tan imprescindibles como las reuniones de seguimiento, la toma de especificaciones o las pruebas de usuario. Pero deben ser desconexiones reales, tan largas cómo sean necesarias, sean cinco minutos, un día, un fin de semana o un mes.

Cada grado de "falta de iluminación", cada momento y cada persona, deberá indicarnos cuál es el período necesario, sin necesidad de tener que ser siempre el mismo.

Tumbarse en la cama puede ser suficiente si con ello desconectas, pero lo recomendable es realizar acciones que ocupen nuestra mente con otras tareas diferentes a las que nos han llevado a quemarnos.
En nuestra profesión, lo más recomendable es ejercicio físico, que nos agote físicamente y nos haga dormir bien.
Reuniones con amigos que no tengan nada que ver con nuestro trabajo y de conversación amena, que nos evite caer en pensamientos laborales. En fin, cada uno debe encontrar y mantener su "vía de escape".
En mi caso, el mar: la simple contemplación del mar me evade, me relaja, descanso. Cuando me sumerjo o navego, mi mente se libra de golpe y porrazo de todo lo relacionado con mi mundo laboral.

Programa tus descansos

Se firme e inquebrantable con tus horarios. Lo que un día es una reunión imprevista de última hora que te ha hecho llamar a tu pareja diciendo que no va a poder ser lo de ir al cine, terminará siendo escusa porque no sabes vivir ese tiempo fuera de la oficina o sin estar trabajando. Debes tener en la recámara cosas por hacer en tu tiempo libre.

Si no se te ocurre ninguna, recuerda cómo imaginabas tu vida cuando tenías 15 o 20 años menos: las cosas que planeabas hacer, las aventuras que querías correr, los sitios donde querías ir. Pon en marcha algunos de esos proyectos perdidos, esos deseos, y cada vez que no cumplas con tus horarios, piensa que acabas de dar un paso más alejándote de ellos.

Recuerda por qué trabajas

¿Por qué estás trabajando? Para ganar dinero, evidentemente, ¿no? ¿Y para morir de estrés? No, ¿verdad?

¿Quizás porque cuando comenzaste era la forma de financiar esos deseos que tenías por cumplir? ¿Y qué ha cambiado? Supongo que en lo más básico, nada. Simplemente, el trabajo nos absorbe.

Debemos aprender a decir basta.

L. y J., de nuevo, mi más cariñoso saludo.

Un beso a todos.

El ventanal de Rosa o de cómo vender productos Microsoft

2007-11-15T20:55:00.000+01:00

Esta entrada no la consideré... lo que se dice muy al tema de este blog, así que la moví a "Íntimo y personal", por si alguien quiere echarle un ojo (es mi blog super-hiper íntimo, vamos, sin temática concreta)

En resumen, es un comentario en referencia al blog de Rosa García, Presidente de Microsoft Ibérica, con respecto a su post "¡Viva la señorita Pepis!"

Motivación. ¿Tan dificil es motivar?

2007-10-17T13:48:00.000+01:00

En contestación o continuación al post de Sergio "¿Qué pasa con nosotros?":

Aquí en tierras "ibéricas" yo creo que las cosas van cambiando, eso sí, a la velocidad de la luz que entra en un cuarto de revelado...

Obviamente yo sólo puedo hablar de los sectores que conozco personalmente, y aquellos en los que mis allegados me mantienen informado.

Se deba al estado del mercado de trabajo o al cambio de cultura empresarial, el caso es que se van viendo cambios en las políticas de motivación e incentivos de personal. No nos equivoquemos, motivación de un empleado no es darle dinero o subirle el sueldo (que también), son muchas otras cosas y detalles (pequeños en la mayoría de las ocasiones).

En mi propia empresa, antes del verano, y a petición personal del "dire", se organizó un grupo de trabajo representativo de todo el capital humano de la misma para estudiar "nosotros mismos" qué echamos en falta, qué haríamos, cómo mejoraríamos nuestro entorno laboral, etc.

Unos meses después, parece que se van viendo resultados. Enhorabuena.

Por desgracia, mi empresa es un tanto particular, y aun así, un hecho tan simple como "dar las gracias" por un trabajo bien hecho, por unos minutos de más (ya no hablamos de horas), etc. sigue siendo, para determinadas personas, la representación psicológica de "rebajarse" a alguien "por debajo en la escala".

No quiero ni hablar del hecho de pedir opinión, a pesar de que "el chavalito" te da mil vueltas sobre el tema que se discute.

También se de este tipo de reuniones en otras empresas (que yo recuerde ahora de memoria 3 diferentes) en tiempo y forma bastante parecidas.

Pero ojo, no disparemos tan alto. Sergio comenta en su post:

Hace poco mi jefe me preguntaba que podíamos hacer para mejorar el rendimiento del equipo de trabajo en España, me preguntó si no se les podía motivar regalándoles entradas para un partido del Real Madrid, un concierto, o para ir al cine. No fue fácil explicar por qué eso en España no se hace y me dio bastante vergüenza. Sentí como si viniera del tercer mundo, ese al que decimos no pertenecer.

A lo cual, lo único que cabe decir es: sí, somos así.
Probablemente, si regalas un par de entradas de cine en mi empresa, o entradas para el basket (para el Estudiantes, claro), o algo así... seguro que se oiría:

"Prefiero que me de el dinero y ya elegiré yo donde me lo gasto", ó "seguro que eran para él pero no puede ir y no sabe lo que hacer con las entradas" ó "se las habrán regalado".

Como alguno de vosotros sabe, ahora mismo estoy de "externo" en un cliente, el cual, hace unos días, mandó un correo a mis jefes y a mí, agradeciendo y felicitando mi trabajo. Unos días después, el "dire" de mi empresa me mandó un mail felicitándome de nuevo y haciendo sabedores de esta felicitación a los jefes de proyecto. ESTO ES MOTIVACIÓN. Tanto por parte del cliente como por parte de mi propia empresa.

Me llamó de forma inmediata un compañero y amigo por teléfono y me dijo "bueno, no es pasta, pero no está mal ¿no?". efectivamente, no está nada mal.

Sergio, de veras, creo que las cosas están cambiando, pero no vuelvas hasta dentro de unos 20 años o estarás corriendo el riesgo de sufrir un shock.

Un abrazo !!!!.

Google incluirá en Docs diccionario, enciclopedia y sinónimos

2007-07-02T19:57:00.001+01:00

Google estudia, de momento, incluir las referencias de La Enciclopedia Británica, y el diccionario y sinónimos de Merriam-Webster.

Está aun en fase Alfa, no publicada y bastante escondidito, pero accesible y activable.

Según indica Tony Ruscoe en Google Blogoscoped, donde podeis ver varias capturas de pantalla adicionales, el sistema anda un poco de puntillas aun, las definiciones y correciones no son del todo acertadas, y es lógico que el sistema ande todavía "escondido".

Eso sí, funcionar, funciona. Probado:

Pasos para hacerlo funcionar:

Abre un documento de Google D&S.
En la barra de direcciones, sustituye la dirección con esto, y pulsa "Enter":

javascript:void(INCLUDE_BRITANNICA_INTEGRATION=true);

Ahora, haz click con el botón derecho encima de cualquier palabra y deben aparecer tres entradas nuevas en el menú contextual:
- Definición del diccionario para "xxxxxxxxxx"
- Artículo de la anciclopedia para "xxxxxxxxxxxxxx"
- Llave del tesauro para "xxxxxxxxxxx"

Al contrario que en otras ocasiones, en las que estas pruebas sólo las hacen en la versión .com, también funcionan con la versión en castellano.

No estaría mal, como dice algún comentario de la noticia de Google Operating System, que incluyeran la Wikipedia, ¿no?.

Y si dejasen escojer entre algunas otras fuentes, mejor. Pero bueno, esttos chicos de Google están empezando, démosles tiempo a ver como lo hacen... por cierto.... ¿para la versión española usaran la RAE?

Etiquetas de Technorati: Google, Herramientas, OpenSource, Web

Mi primera aplicación comercial

2007-07-01T20:26:00.001+01:00

Sí, por fin DiveGestión ha visto la luz.... ha sido un embarazo largo (más de 2 años) y con un parto dificil (48 horas de tensión...)

Hoy dia 2 de Julio sale a la venta y ya tenemos casi agotado nuestro stock de licencias.

Esta ha sido realmente la causa de la baja frecuencia de contenidos en los últimos tiempos, pero os aseguro que intentaré remediarlo marcándome como objetivo un artículo semanal con lo más interesante que tenga.

En estos más de dos años de trabajo he aprendido en carne propia lo que Aitor enumera perfectamente en PlanetaCódigo:

Uno de los grandes problemas con mayúsculas cuando formas parte de una miniempresa-ISV-startup es la cantidad de trabajo brutal que es canalizado a través de cada uno de sus miembros. Sacar la primera version de cualquier aplicación como cita Rands: “no te va a matar, pero lo intentará”.

Evidentemente, no he estado sólo: Karlos Simón ha sido el precursor de la idea, el "beta tester" y documentador del proyecto, mientras que en la parte técnica, analítica y minera (por aquello de picar código), ha sido Ignacio Bello quien ha aportado su esfuerzo, tiempo y sabiduría.

Parece esto un "que guapos somos todos y que bien lo hemos hecho". Bueno, pues sí, que leches... sin la capacidad de trabajar en equipo y a larga distancia, mezclada con grandes dosis de autodisciplina, organización y capacidad de trabajo individual y en solitario, nunca hubiera sido posible este proyecto, realmente monstruoso. Si en realidad quereis saber de que se trata, os diré que es una aplicación orientada a la gestión TOTAL de un centro de buceo.

Como casi todos sabeis, soy buzo (DiveMaster para aquel que le interese, con un blog sobre el tema y todo...), y fue a raiz de la mezcla de "mis dos mundos", el de la ingeniería de software y el del buceo deportivo, cómo surgió el nacimineto del grupo de trabajo.

Por supuesto, contamos con sitio web, aunque estamos aun agregando contenido, las bases de diseño y estructura ya están creadas, pero seguimos mejorándolo. Está basado en Joomla y en diseño RedBridge de Wordpress. Aun queda trabajo en este aspecto...

Realmente, un grupo pequeño puede hacer grandes obras.

El secreto es rodearse de personas con los suficientes conocimientos, motivación y ganas. El resto: marcarse pequeños hitos sin perder nunca de vista el gran objetivo, y tener la capacidad de variar el orden o posición de los hitos, crear nuevos puntos intermedios si es necesario o desechar aquellos que se transforman en escollos infranqueables que nos hacen perder de vista el objetivo. Como siempre me ha dicho Ignacio a lo largo del proyecto:

Que lo urgente no te impida ver lo importante

Desde el punto de vista de la ingeniería del software, he aprendido algunas cosas:

La visión global del proyecto es sumamente importante, porque te hace ver los pequeños desarrollos dentro de su entorno y anticipar posibles necesidades hacia y desde el "todo".
La capacidad de cambios continuos en la fase de desarrollo sólo es posible si el proyecto ha sido planificado para absorverlos. Unos requerimientos estancos o un análisis petreos harían imposible un desarrollo "agil".
Dejar que el "experto" te diga cómo deben ser y hacerse las cosas, incluso en tu propio desarrollo. Por algo es el experto.
y otras muchas que poco a poco ire desgranando en forma de posts, palabra.

Por desgracia, la absorción que hace de tí un proyecto de este calibre deja huella: o cuentas con un respaldo familiar infinito, o despídete (o de la familia o del proyecto), y por eso, desde aquí, públicamente, mis más sentidas disculpas y agradecimiento a mi familia: Isa Mary, mi mujer; Celia, mi hija; y mi mamá, quien siempre me ha dicho que trabajo demasiado...

Por supuesto, a todos aquellos que de una forma u otra me habeis apoyado tanto con cariño, ideas, soporte y aliento: Sergio Bonachella, Rebeca Astasio, Estrella, Luis (aka Luigi), Elba, Juanma Cortés y Rosa (sí, sí, la mamá de Anabel). A todos, muchas gracias.

Ahora solo queda que se venda bien y el esfuerzo no sólo tenga recompensa personal si no también económica, que si no, a la siguiente, Isa me va a decir que sí...

Etiquetas de Technorati: Desarrollo, Gestión de proyectos, Requerimientos, DiveGestión

Adobe Flex será OpenSource

2007-04-26T13:01:00.000+01:00

Adobe acaba de anunciar (26 de Abril, 2007), sus planes estratégicos, según los cuales pasará a un modelo de código abierto su producto Flex.

Lo hará bajo la licencia Mozilla Public License (MPL).

Incluirá no solo los fuentes de los componentes de ActionScript del SDK de Flex, que son accesibles desde que fue lanzada la versión 2 de Flex, si no también el código Java de los compiladores de ActionScript y de MXML, las herramientas de depuración y las propias librerías del SDK de ActionScript.

Os recuerdo que la SDK de Flex incluye TODOS los componentes necesarios para crear aplicaciones Flex, las cuales corren bajo cualquier navegador, incluso, usando Apollo, ahora también como aplicaciones de escritorio, y en cualquier sistema operativo Windows, Linux y Mac OS X.

Podemos, por tanto, usar libremente el SDK de Flex para desarrollar y distribuir aplicaciones con el Adobe Flex Builder, o cualquier otro IDE de nuestra elección.

Para mucha más información:
- Nota de prense de Adobe.
- Anuncio en Adobe Labs.

- Todo sobre Flex ( y ahora también Apollo) en MadeInFlex.

Google Presentations, oficial.

2007-04-18T08:10:00.000+01:00

Google confirmó ayer, martes 17 de Abril, en el Web 2.0 Expo en San Francisco, en palabras de Eric Schmidt, CEO de la compañia, que Google Docs & Spreadsheets añadirá a partir de verano una aplicación para edición de presentaciones, del tipo de PowerPoint de Microsoft.

Eric Schmidt intentó dejar bastante claro que estas aplicaciones no son competencia directa de las aplicaciones de Microsoft, puesto que las suyas se basan en la colaboración vía web y el trabajo en equipo y las de Microsoft son aplicaciones de escritorio.

Desde mi punto de vista, más que un "traquilos chicos de Redmond, no somos vuestra competencia", me parece a mi un... "por más que lo intenten, nunca lograran llegar a nuestro nivel de aplicaciones colaborativas... vosotros sabreis".

Sin duda alguna, una buena noticia en un mundo donde el trabajo colaborativo cobra mayor importancia y las distancias físicas pueden dejar de ser un escoyo para formar parte de un grupo de trabajo. Sirva como ejemplo todos los proyectos "open source" que llevan años creciendo, mejorando y distribuyéndose a lo largo y ancho de todo el globo.

En una entrevista realizada tras la presentación a Jonathan Rochelle, product manager de Google Docs & Spreadsheets, apuntó que las características y funcionalidades finales de esta nueva herramienta no serán anunciadas aun, pero que sin duda alguna, será su capacidad de colaboración on-line uno de sus puntos fuertes, como el resto de aplicaciones lanzadas hasta ahora por la compañía. Anunció también que, este nuevo hijo de Google Docs and Spreadsheets formará parte, como no podía ser de otra manera, de Google Apps.

Vía: InfoWorld

Entrevista a la presidente de Microsoft Ibérica

2007-02-08T21:08:00.000+01:00

Me entero por navegápolis de una entrevista realizada en la TV3 a Rosa María García, presidente de Microsoft Ibérica, no sólo sobre Windows Vista, su lanzamiento y "virtudes".

La entrevista toca temas como el software libre, política de empresa de Microsoft, gestión de personal y de personas, cultura de empresa trabajo y vida privada... salvo lo tocante al software libre, en el que deja demasiadas frases lapidarias, injustas y en algunas ocasiones rozando la desinformación (por no decir mentiras), la entrevista es muy interesante.

Requerimientos y especificaciones: gestión de expectativas.

2007-01-28T21:42:00.000+01:00

Hace unos días Ángel publicaba en PresiónBlogosférica una entrada en la que me vi perfectamente dibujado, y de la que le he robado el título: La gestión de las expectativas.

Por resumirlo, nos cuenta su experiencia con un cliente al que le parecen pocos los beneficios y/o mejoras obtenidas con el proyecto terminado, aun superando este las expectativas iniciales de la fase inicial del mismo. O cómo cuando comentas las posibilidades de una tecnología determinada o un nuevo enfoque, el cliente multiplica sus expectativas exponencialmente para pasar de unas necesidades concretas, a montarse un universo paralelo donde el nuevo sistema será la solución a todos sus problemas presentes, pasados y futuros... la entrada es ideal, muy recomendable.

En el mundo de la consultoría y desarrollo informático, nos encontramos en estos casos con serios problemas: cuando estás en la fase de requerimientos junto al cliente (idealmente, claro), vas dibujando mentalmente pequeñas soluciones concretas. Cuando terminas esta primera fase y estudias el proyecto en su totalidad, planteas la posible solución global, cómo lo vas a hacer, con qué tecnología, etc... y es ahí donde hay que andar con pies de plomo...

Se puede dar el caso de que el cliente vea soluciones nuevas a viejos problemas que no entraban en los requerimientos iniciales... ¿qué haces? ¿Aumentas los requerimientos y por tanto la solución final y por tanto el precio del proyecto? ¿Haces encajar más requerimientos en los ya tomados al mismo precio? Uff... como diría un gallego... depende...

Depende de la venta, del cliente, de tus expectativas de futuro con el cliente, de las expectativas del cliente en torno al proyecto... son decisiones tan particulares y concretas de un momento dado con determinados actores, que no es posible dar una respuesta estándar; aunque sí hay que mantener una línea base:

Si los requerimientos iniciales han sido obtenidos siguiendo unas normas básicas (próximas entradas sobre requerimientos !! ), con la conformidad del cliente, son estos requerimientos los que deben marcar las expectativas y el marco del proyecto, y por tanto, todo aquello que se salga de estos requerimientos mutuamente acordados, deberán ser abordados en un nuevo proyecto o en una ampliación del mismo.

Web 2.0 - ¿Muerte de un término o de una filosofía?

2007-01-22T23:33:00.000+01:00

Desde los orígenes del invento que nos ocupa, esto es, internet, llevo oyendo y leyendo que si internet significará la muerte de esto, el ocaso de aquello, etc., etc. y con la misma intensidad, pero en círculos menos profanos (o más, no me atrevería a decidirme), llevo escuchando, leyendo y oyendo desde hace unos meses, que la "última revolución de internet", ha muerto: Web 2.0, descanse en paz.

¿Estamos todos de acuerdo? ¿Lo estás tú?

Yo no... hoy no... me he debido de levantar cobardón...
Y es que aunque me alimente de ello, yo lo alimente, y entre todos hayamos engordado a esa bestia, sigo sin tener claro que narices significa el tan traído y llevado término Web 2.0. Más llevado que tarído, sin duda... llevado a extremos como Periodismo 2.0 (1.250.000 entradas en Google) o Empresa 2.0 (¡¡ 1.650.000 entradas !!).

Mi humilde opinión:

Larga vida al Web 2.0. RIP a vendedores de humo

Entiendo por "Web 2.0" la red colaborativa (blogs y RSS, evolución de foros, etc), préstamo de servicios especializados o micro-servicios, un diseño cuidado y elaborado en internet, el uso de "viejas" herramientas con nuevos fines, o la mezcolanza de ellas para obtener un mejor interface de usuario (AJAX, nuevos host scriptings, etc)... por todo ello, un brindis, un deseo de larga vida, y mi más sincero esfuerzo para que así siga.

Si al carro de "Web 2.0" se suben empresas, empresarios, emprendedores y demás vendedores de humo que basan su filosofía de empresa, su plan de márketing y sus proyecciones de futuro en ser pasto de Google, Yahoo, o por qué no, Microsoft... lo siento por ellos (por el 90% como mínimo) y me alegro por el pequeño porcentaje restante que han conseguido dar el pelotazo (o los pelotazos)... no digo que haya sido cuestión de suerte: de suerte, vista, momento, sobrevaloración del servicio en muchos casos, y contactos...

Lamento que el término se asocie ahora más a esta estupidez que a la propia filosofía de la que nació y engordó hasta convertirse en un monstruo... lee la entrada "El Web 2.0 ha muerto" del blog "Buenos días, Sillicon Valley". Como siempre, buena entrada Rogelio.

Adobe crea un plugin de Eclipse para JavaScript

2007-01-08T23:34:00.000+01:00

Los laboratorios de Adobe están en fase de desarrollo de un plugin de Eclipse que nos ayudará con el JavaScript en nuestros proyectos.

Tal como indica la página web del proyecto, nos echará un cable con la sintaxis, funciones, control de errores, etc. Implementará también soporte para documentar el código con JavaDoc, así como capacidad para crear, modificar y usar "templates" de código.

Soportará de forma "transparente" el uso de librarías "populares" (según Adobe, claro): Dojo, Prototype, Yahoo UI Library, Qooxdoo

Actualmente, en fase pre-release, te la puedes descargar desde aquí.

Formación interna en empresas de software

2006-12-13T12:33:00.000+01:00

Ayer comenzó, para algunos compañeros en mi empresa, un curso básico de programación orientada a objetos.

Se que a estas alturas muchos de vosotros os preguntareis: "¿ De POO en el año 2006 (2007 casi...) ? ¡Pues a buenas horas!", o... "Je, je... una empresa de desarrollo de software... y un curso de esos a estas alturas, con el Web 2.0 por ahí, AJAX, etc, etc... díme que empresa es para no contar con ella..."

Pues bien, teneis razón, pero en el campo donde se mueve la empresa, realmente, no son necesarios esos conocimientos, ni siquiera hoy en día, en el 90% de los desarrollos; leí hace unos días en PresiónBlogosférica (gracias Angel por el link) titulado "Hacer bien una cosa".

La empresa para la que trabajo, es realmente, si no la mejor, casi, en lo que se refiere al conocimiento del negocio en el que se mueve, sus desarrolladores son especialistas o casi, en la materia, y los analistas no solo son reclamados por los clientes para desarrollos nuevos, si no como consultores que les ayuden en su propio negocio.

Con sólo un día de curso (presentación y esas cosas), ya hay alguno que se ha atrevido a cuestionar la validez del mismo, no solo poniendo en cuestión la calidad profesional de la persona que lo imparte, si no, y lo que me parece más llamativo, la utilidad de esos conocimientos que su empresa le pone al alcance de la mano.

Si bien es cierto que estas personas llevan "haciendo lo mismo" desde hace años, en el mismo entorno, con los mismos métodos, etc. etc., no es menos cierto, por tópico que sea, que el saber no ocupa lugar y más aun en este "mundillo". Frases tales como "si luego se me olvidará... total...", u otras del calibre de "si me valiera para algo...", no son la primera vez que las escucho en situaciones semejantes anteriores. Las mismas, no son más que la expresión hablada, a mi modo de ver, del cerrado entrecejo, limitado entendimiento del mundo informático y empresarial, de la persona que las dice.

La escasa amplitud de miras de estos compañeros, quiero pensar que se debe más a ganas de tocar las narices que a sus sentimientos reales, porque aun en el caso de ser ciertas dichas afirmaciones, ¿alguien les asegura que en un futuro (lejano o no) van a seguir "haciendo lo mismo"? ¿Tienen una bola de cristal en casa en la que han visto que su futuro profesional está asegurado, en puesto y funciones, en la empresa donde están ahora? ¿Realmente piensan que engordar su curriculum de conocimientos es una pérdida de tiempo?.

Si fuera yo, que evidentemente no es el caso, quien tubiera que financiar estos cursos, la siguiente vez me lo pensaría muy mucho, a pesar de poder encontrarme entonces en un círculo vicioso... "Mi empresa no me forma, haré siempre lo mismo, que aburrimiento"... lo que encima, aumentará la desilusión, la baja productividad, y mandará al garete cualquier intento de incentivación del personal.

Y lo peor de todo... es gente joven, muy joven, con una media de alrededor de 30/35 años de carrera profesional por delante... no quiero pensar que será de ellos dentro de 10 años...

Por favor, es un tema en el que necesito críticas y otros puntos de vista, porque se que lo miro con un filtro muy subjetivo. Deja tus comentarios. Gracias por servir de desahogo.

Reglas para el buen desarrollo de un producto

2006-12-12T20:20:00.000+01:00

En el blog Product Musing, hubo una entrada el pasado 5 de Noviembre sobre 20 reglas para conseguir el lanzamiento de un producto software con éxito (en inglés). No es que esté de acuerdo al 100% con todos los puntos, pero realmente, dan en que pensar, o al menos, para echarse unas risas.

Paso a comentar las que me han parecido más acertadas:

Asegúrate de saber qué estás desarrollando. Muchos de los retrasos en los proyectos se deben a que "el cliente", el/los analista/s, los programadores, etc. (inclúyete en el pack correspondiente), no saben realmente cuál es el objetivo final del proyecto. Reconoce, añade en una actualización del post, que lo que estás desarrollando ahora mismo, cambiará casi de forma irremediable en el futuro hasta completar el proyecto, así que asegúrate de que tus procesos, clases, sistemas o subsistemas, admitirán estos cambios preparándolos para ello desde el origen.
Trabaja solo en los puntos necesarios para lanzar la versión 1.0

Sin olvidar lo mencionado en el punto anterior, claro...

Asegúrate de mantener un prototipo siempre funcional

Si lo vas actualizando con las últimos desarrollos, y lo mantienes accesible a los usuarios finales, podrás ir corrigiendo o debatiendo con ellos desde la interfaz a posibles malentendidos en las funcionalidades de la aplicación, con lo que podrás, entonces, anticipar estos cambios en las partes que aun no has empezado o tienes entre manos...

No hagas del proyecto un escaparate para mostrar lo "guay" que eres
- Aquí... no es que discrepe, pero... si tu proyecto puedes aprovecharlo como escaparate del buen desarrollo y buen hacer de tu empresa o grupo de trabajo, es posible utilizarlo como un trampolín para futuros proyectos... o a la inversa, si la picias o el cliente no queda contento... una puerta abierta menos...
Lo breve, si bueno, dos veces bueno... osea, mejor las cosas pequeñas
- No seas mal pensado... estamos hablando de los métodos, ficheros, procesos, funciones....
Si alguien no está en sintonía con el resto del grupo...
- Habla con él/ella en privado
- Reasígnalo o cambia sus tareas o funciones
- Habla con él/ella en privado
- Y si eres tu mismo... recuerda lo del escaparate...
Diseña los módulos o clases construyendo interfaces, de forma que sea accesible facilmente por terceros módulos, reutilizable y facil de implementar cambios masivos.

Documenta estas interfaces a la perfección, pero no los módulos o clases que usa la interface, eso sí, mantén una escrupulosidad absoluta en la facilidad de lectura y mantenimiento del código de estos módulos.

Cuando estés en el proceso de debug de un problema, nunca digas ¡¡¡ Pero si en mi equipo funciona !!!
- ¿Quién no lo ha dicho alguna vez?
Si hay algún fallo de funcionalidad o algún bug grabe en la parte ya desarrollada, no continues con partes de código nueva hasta haber resuelto estos problemas
Si alguna parte del código es complicada de seguir el Lunes a primera hora, antes del primer café, rediséñalo.

Después de todos estos puntos, sería casi obligado hablar de algunos temas importantes, y debatir sobre ellos:

Tomas de especificaciones.
Reuniones de seguimiento con los clientes/usuarios y con el equipo de desarrollo.
Equipos multidisciplinares o equipos de especialistas
Prototipos, maquetas, beta releases...

Y prometo ir ocupándome poco a poco de estas cositas... por supuesto, necesito de tu colaboración, opiniones, críticas, experiencias... no te cortes...

Librerías básicas javaScript para sitios Web "so cool taste"...

2006-12-11T20:59:00.000+01:00

Recopilando las librerías de diseño que tengo en mi biblioteca, las que últimamente he utilizado más en algunos clientes y/o aquellas que sin utilizarlas por no serme necesarias hasta la fecha, he considerado como "must have", me he encontrado con estas:

Moo.fx - librería muy ligera para aplicar efectos, "hija" de prototype.js o de mootools, a elegir, provee mecanismos para controlar el ancho, alto y la opacidad de elementos impidiendo una re-escritura de estos por el usuario de forma accidental.
Rico - Soporte para AJAX, y gestión de Drag and Drop, efectos cinematic, y más...
script.aculo.us - Pues más de lo mismo... AJAX, efectos, Drag and Drop, Tablas a go-go, y los ejemplos integrados con Rails... (lo mejorcito hoy por hoy... ¿no?)
Mochikit - Yo uso la parte de logging, pero tiene muchas más cositas, como todos...
dojo - El uso principal que le ha dado ha sido con gráficos estadísticos y vectoriales en 2D. Implementa también ayuda a discapacitados visuales (alto contraste, readers, etc) junto con "gadgets" curiosos...

Y no siendo JavaScript, en último lugar pero no menos importante (me ha resultado muy util en ocasiones):

Dynamic Drive CSS Library - Ejemplos y algo de código CSS para construcción de menús.

¿Se te ocurre alguna más que yo no tenga en mente? ¿Usas tú alguna que crees que todo el mundo debería conocer? Este el momento de añadir elementos a esta lista...

Brainstorming (II)

2006-12-11T18:44:00.000+01:00

Posteado por Ángel en PresionBlogosferica el 11 de Diciembre de 2006

Tal como
prometí, la continuación del artículo sobre la realización de Brainstormings.

Nos quedamos al final de la fase de creación:

Las ideas han ido surgiendo y se han ido anotando… Es importante insistir en que, si bien debe establecerse un límite horario, es igualmente importante fijar un objetivo cuantitativo, y mi consejo es fijarlo en el orden de los cientos de ideas. A veces no será posible, sobre todo cuando el objetivo de la sesión esté muy delimitado o el campo sea muy específico, pero es bueno marcarse objetivos ambiciosos.

Otra cosa que se me olvidó comentar en el artículo anterior: Invitad a gente de fuera. Los miembros de un grupo, equipo o Departamento pueden estar muy retroalimentados entre ellos con la misma información. Traer a personas de fuera - incluso mejor si no tienen ningún conocimiento sobre la materia - estimulará el proceso creativo. Además, el cruce de experiencias y conocimientos durante la fase de destilación puede ser crucial si de lo que se trata es de innovar.

Pasemos pues a la destilación. Durante esta fase, procuraremos no solo identificar las buenas ideas, sino ver qué podemos aprovechar de las que se descarten e incluso generar nuevas ideas derivadas de las que ya existen.

Al igual que en la fase anterior, existen unas reglas de obligado cumplimiento:

ANOTAR LOS CRITERIOS DE VALORACIÓN: Usar frases comenzando con “Debería”, “Sería deseable”, “Es necesario que”. Esto nos servirá para evaluar las ideas de forma homogenea y no arbitraria.

IDENTIFICAR GRUPOS O CATEGORÍAS DE IDEAS: Para esto, los mapas mentales son fenomenales. Si además habéis seguido mi consejo de usar post-it, podréis ir moviendo las ideas hacia las zonas del mapa a las que pertenezcan.

REVISAR TODAS LAS IDEAS: Por extrañas, pequeñas o absurdas que parezcan, ninguna idea debería quedar si evaluar. Dedicadle al menos un minuto a cada una.Si, ya lo se, cien ideas a un minuto cada una son cien minutos…Nadie dijo que la creación de buenas ideas, de esas que marcan la diferencia, fuese rápida. Si queréis ideas rápidas y baratas, buscad algo en google… (*)

CLARIFICAR LAS IDEAS Y LO QUE SIGNIFICAN: Durante la fase de creación dijimos que no valía criticar ni hacer preguntas. Ahora es el momento. ¿Que ha querido decir la persona que ha propuesta esa idea? ¿En qué funcionamiento estaba pensando exáctamente? ¿Cómo piensa que se imlementaría?

USAR FRASES CONSTRUCTIVAS, NO DESTRUCTIVAS: Si os dedicáis a reiros de los que han propuesto las ideas más absurdas, solo lograréis coartar el proceso creativo. Por otra parte, si no sois constructivos con una idea podríais dejar pasar algún aspecto de la misma que os de la clave de lo que andais buscando… Algunas frase de estimulo podrían ser:

¿Qué se podría hacer con esto?

¿Cómo podría modificar esto para aplicarlo a un nuevo uso?

¿Qué pasaría si se cambiase esto de alguna manera?

¿Qué cambios podríamos introducir para provocar mayor atención?

¿Por qué no arriba en vez de abajo?

¿Qué podríamos eliminar?

¿Qué se conseguiría si alteramos el orden?

¿Cuáles son las cosas opuestas?

¿Por qué no podría tener menos partes?

¿Y si dijésemos esto al revés?

CLASIFICAR O PUNTUAR: Usar un baremo, bien con calificativos (excelente, interesante, no aprovechable) o con puntos (cero a cinco, cero a diez)…

ELIMINAR CONSENSUADAMENTE LAS IDEAS QUE NO SEAN UTILIZABLES: Cuando una idea no vale, no vale. Hay que intentar exprimirlas y luego pasar a la siguiente. Pero si alguien piensa que la idea no es tan mala, quizás tenga razón. Preservadla hasta el final, cuando hagáis una segunda o tercera criba. Solo deberían eliminarse las ideas a las que todos penséis que no se le puede sacar más partido.

Con toda esta información, es recomendable que el coordinador de la sesión realice un pequeño memorandum en el que explique el objetivo, los participantes, las áreas de ideas exploradas y las mejores que se han obtenido. Este tipo de documentos ayudan a demostrar a las organizaciones la utilidad del Brainstorming como técnica productiva.

(*) Esta frase me recuerda a una similar aparecida en una tira cómica protagonizada por

Dogbert: “Puedo darle buenos consejos por una tarifa de 60.000$…También puedo darle malos consejos al precio reducido de 40.000$”

IBM vota "no" al OpenXML de Microsoft en el ECMA

2006-12-07T21:41:00.000+01:00

Pues aunque todo el mundo esperaba un "si" por parte de todos las grandes empresas del mundillo del desarrollo, IBM se ha desmarcado con un rotundo "no" a la ratificación como estandar la propuesta "OpenXML" para la definición de documentos de oficina (léase MSOffice, OpenOffice, etc, etc.)

Bob Sutor, quien defendió la postura de IBM en el congreso celebrado hoy, llevaba tiempo anunciando su postura: la defensa a ultranza del estandar OpenDocument Format (ODF), sobre el que ha publicado varios trabajos...

Y me gustaría plantear la pregunta... ¿ IBM defiende sus intereses con este voto o el interes de los estándares, sean o no de facto ?, porque, al final, todos sabemos que terminará siendo aprovado el esquema de definicion OpenXML como estandar ISO y utilizado por todo el mundo (ya lo es con Open Office, etc... pero si tal como dicen al menos 7 de cada 10 ordenadores usan Windows con MS-Office o MS-Works en su defecto...) ¿Por qué el voto en contra de IBM?... no se....

En anteriores congresos, Microsoft jugó en el mismo equipo que IBM definiendo las bases de estos estándares e incluso los orígenes comunes (hoy ODF), fueron ratificados por Microsoft a petición de IBM....

ODF, cuenta a día de hoy con varias versiones y revisiones en las que se han ido añadiendo posibilidades a este formato, curiosamente, posibilidades que ya tiene el formato ofrecido por Microsoft.

Enlaces:
Blog de Bob Sutor
Is Open XML a one way specification for most people? (por Bob Sutor)

Brainstorming (I)

2006-12-07T21:34:00.000+01:00

Desde Presión Blogosférica por Ángel

Se abusa demasiado de este término. Cada vez que se juntan cuatro personas a discutir, pensar o darle vueltas a una idea, es que hemos estado de brainstorming. Pero si nos ponemos académicos, este término se refiere a una técnica concreta para estimular el proceso creativo y, como tal, tiene ciertas reglas y procedimientos. Voy a reflejar aquí las que a mi me constan y que he empleado, lamentablemente, en muy poquitas ocasiones (porque las empresas no suelen prestarse a estas frivolidades, fijate ellas que serias ) pero en todas ellas con resultados espectacularmente buenos - ya ves, lo que son las cosas .

Ante todo, es necesario que una persona dirija la sesión. Solo en grupos que ya están muy acostumbrados a la mecánica del brainstorming aconsejaría prescindir de esta figura. El siguiente principio básico de un brainstorming (tormenta de ideas, para los puristas del idioma) es dividir la sesión en dos partes. Tres si lo hacéis con calentamiento.

Un calentamiento consistiría en hacer unas cuantas listas de prueba que no tengan nada que ver con el objetivo de la sesión. Por ejemplo, empezar nombrando cincuenta marcas de comida. Luego seguir con cincuenta prendas de ropa, cincuenta marcas de coche…¿Os acordáis del un-dos-tres? . Da igual si se consigue llenar la lista o no, se trata solo de difuminar un poco la consciencia, comenzar a disociar las ideas y calentar un poco las neuronas.

A continuación hay que centrar el concepto de la sesión: ¿Por qué estamos aquí? ¿Qué queremos conseguir? Para no perder el foco, recomiendo reservar una pizarra o papelógrafo en el que ir realizando un

mapa mental de la sesión.

Pasaríamos entonces a la primera fase del brainstorming: La fase de creación. Durante esta fase, todo vale. La cantidad vale más que la calidad. Se trata de fijar un número determinado de ideas (100, 200, 300…) e ir nombrando todas las que se nos vayan ocurriendo, por absurdas o inconexas que nos parezcan. Hay una serie de reglas que es importante cumplir:

TODO VALE: Da igual lo absurdas que parezcan las ideas. Precisamente cuando se agotan las respuestas convencionales es cuando empieza el proceso creativo.

CANTIDAD ANTES QUE CALIDAD: Lo importante en esta fase es generar muchas ideas, agotar el saco de las preconcebidas, las lógicas y las evidentes

PROHIBIDO CRITICAR: Las ideas no se critican. Todas las ideas valen lo mismo. No se permiten comentarios negativos:

Eso no funcionaría
Seamos serios
Vaya tontería
Esto no sirve para nada
No tenemos personal / tiempo / recursos / presupuesto para eso

ESTIMULAR/VALORAR LO DIFERENTE Y EXTRAÑO: Frente al punto anterior (no criticar), el contrapunto es precisamente premiar e incentivar las ideas que más se salgan de la senda habitual de pensamiento

ROBAR IDEAS: No solo se permite, sino que se estimula y se premia el copiar las ideas de otros dándole otros matices

TRABAJO EN EQUIPO (NO HAY “PADRES”): El director de la sesión debe conducir la misma y procurar que todo se haga según las reglas, pero ahi acaba su autoridad. No es su labor reñir a los que se saltan las reglas oi los que menos participan. Es el equipo el que debe tomar esa labor.

ORGANIGRAMA PLANO (NO HAY “JEFES”): Si los integrantes del equipo están cohibidos porque hay Jefes en el mismo y no quieren discutir con ellos, contradecirles o temen parecer ridículos ante ellos, es preferible que los Jefes no participen. Lo ideal es que reine un clima de equipo y organigrama plano.

TODOS PARTICIPAN (100% ENERGÍA): El equipo debe procurar estimular a los que más les cueste arrancar. Típicamente, al principio habrá personas que contribuyan poco, pero si logran saltar la barrera mental, se convierten en colaboradores al cien por cien.

TRABAJO EN CÍRCULO: Si en un momento dado la sesión se atasca, repasar desde el principio las ideas generadas y tratar de generar nuevas ideas basadas en ellas o como combinación de varias.

TOMAR NOTA DE TODO: Es responsabilidad del director de la sesión ir tomando notas de todas las ideas. Tambien es recomendable ir identificando areas o grupos de afinidad, para lo cuál es muy util usar el mapa mental que mencionaba al principio. Una técnica muy buena para esto es lo que los americanos llaman COW: Cards On the Wall, o sea, usar post-its u otro tipo de medio para anotar las ideas e ir pegándolas en la pared, lo cuál permite ir moviéndolas de sitio para acercarlos a grupos o areas de similitud.

Seguimos en otro post con la siguiente fase: La destilación…

Technorati Tags:

brainstorming

Ruby on Rails 1.2 RC1

2006-12-07T21:29:00.000+01:00

Desde genbeta por Salva Castro

La primera versión candidata para la versión 1.2 de Ruby on Rails 1.2 ya puede usarse y descargarse desde hace un par de días. Parece ser que incorpora muchísimas novedades al framework de desarrollo de este potente lenguaje y que constituye una actualización bastante importante a todos los niveles, recomiendan que la comunidad de desarrolladores vaya viendo las novedades que se incorporan y ayuden a mejorar la plataforma para que pueda lanzarse una versión final con la mayor brevedad posible para que todos puedan disfrutar de las mejoras estructurales que trae esta nueva versión.

Vía digg

Más información Riding Rails: Rails 1.2 RC1

Bonus Track Libros online gratuitos sobre Ruby on Rails

InputDraw, usa la pantalla táctil en aplicaciones web

2006-12-07T21:11:00.000+01:00

desde genbeta por Sacha Fuentes

InputDraw es un componente diseñado en flash que permitirá a nuestras aplicaciones web aprovechar las características de los dispositivos con pantalla táctil. Los que seáis fieles lectores de Xataka sabréis que los UMPCs y los smartphones están a la orden del día. Pero los formularios web no pueden aprovechar todas las características de estos.

Con InputDraw solo tendremos que insertar un componente flash y el usuario podrá escribir y dibujar en ese control, obteniendo como resultado un fichero en formato SVG con los datos que se que hayan introducido.

Posibles aplicaciones de esto son, por ejemplo, un webchat donde los usuarios puedan enviarse dibujos ellos por hechos mismos. Su uso es gratuito para proyectos no comerciales, mientras que si es comercial habrá que pagar 15 euros de base más 2 euros por cada lugar en que se use.

Enlace InputDraw.