domingo, 28 de enero de 2007

Requerimientos y especificaciones: gestión de expectativas.

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.

lunes, 22 de enero de 2007

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

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.

lunes, 8 de enero de 2007

Adobe crea un plugin de Eclipse para JavaScript


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

miércoles, 13 de diciembre de 2006

Formación interna en empresas de software

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.

martes, 12 de diciembre de 2006

Reglas para el buen desarrollo de un producto

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:

  1. 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.
  2. Trabaja solo en los puntos necesarios para lanzar la versión 1.0
    • Sin olvidar lo mencionado en el punto anterior, claro...
  3. 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...
  4. 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...
  5. 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....
  6. 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...
  7. 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.
  8. 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?
  9. 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
  10. 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...