IA en la Gestión de Proyectos: los supuestos implícitos [parte 2]

 Autor: Beñat Descalzo Alcuaz (equipo Ada Byron)

(Nota: Esta L.A. es parte de una serie de artículos. Si no lo has hecho, accede al artículo general aquí)

Como bien resume el refranero de la lengua cervantina, "el diablo se esconde en los detalles". Con LLMs, esto es especialmente cierto. Los humanos, a partir de nuestra experiencia, trabajamos bajo varios supuestos tan evidentes (a nuestra percepción) que no quedan escritos en ningún lado. Los LLMs no cuentan con esa intuición interna. Por tanto, la mejor heurística defensiva aquí es sencilla: da por hecho que, para todo aquello que no hagas explícito, el modelo va a hacer la interpretación menos caritativa posible.

IA en la Gestión de Proyectos: el riesgo del contexto [parte 1]

Autor: Beñat Descalzo Alcuaz (equipo Ada Byron)

(Nota: Esta L.A. es parte de una serie de artículos. Si no lo has hecho, accede al artículo general aquí)

Definimos la "ventana de contexto" de un modelo de lenguaje como la cantidad de contexto que puede mantener razonablemente, sin empezar a olvidar o a inventarse detalles. Las ventanas de contexto útiles son limitadas (a día de esta redacción, ~256K tokens llevándolo al límite, aunque se anuncien 1M tokens) y, a partir de cierta cantidad de texto, es mucho más probable que el modelo alucine o pierda rigor en la tarea original[1]. Además, en cuanto comete un error, está estudiado uno de sus mayores problemas: tiende a redoblar la apuesta, reafirmándose implícitamente en sus propios fallos[2].

IA en la Gestión de Proyectos: ¿un caballo de Troya? [general]

Autor: Beñat Descalzo Alcuaz (equipo Ada Byron)

Pocas tecnologías han sido tan disruptivas en los últimos años como la IA generativa. Está afectando, ya sea bienvenida o por la fuerza, a todo trabajo que pueda realizarse en un ordenador (desde la generación de código hasta la -polémica- generación de ilustraciones). Por supuesto, la barbarie burocrática asociada a la gestión de un proyecto no iba a ser menos.

El director afronta la tarea de armonizar documentos sueltos, densos y potencialmente contradictorios: especificaciones formales del cliente, comunicaciones con el mismo, especificaciones internas de la organización, regulaciones pertinentes, y un largo etcétera. A la hora de planificar un proyecto es fácil mezclar mentalmente requisitos (especialmente cuando el tiempo para revisar la planificación es limitado), olvidar alguno de los puntos relevantes, o pasar por alto contradicciones sin resolver entre la organización y el cliente. Por supuesto, una de las primeras líneas de fuego debería ser siempre la revisión de calidad sobre la propia planificación, pero la idea se mantiene: en muchos casos, es altamente propensa a errores.

WordPress gratuito… pero, ¿a qué coste? Un manual de Supervivencia

 Autor: Mikel Bilbao Martins

Podrá resultar llamativo el título de esta entrada, pero nada alejado de la realidad, vamos a explicar las siguientes 3 posibilidades, en las cuales usted, el lector, se puede encontrar:

  • Ha utilizado un hosting gratuito de WordPress, sin tener en cuenta las consecuencias, y no ha ocurrido ninguna incidencia actualmente.
  • Se encuentra lidiando con las consecuencias, con o sin copias de seguridad o un plan sólido para salvar la situación.
  • Quieres tener hosting para WordPress gratuito de confianza.

Una referencia adicional útil para esta situación es la siguiente, en la cual ocurre el mismo suceso con un proveedor diferente, pero con el mismo concepto de “WordPress gratis”: Lo barato sale caro (Hosting).

Cómo aprovechar al máximo las herramientas

 Autor: Andoni De la iglesia Rodriguez

En la gestión de proyectos es muy importante decidir que herramientas van a usar los diferentes miembros del equipo. No es solamente escoger la herramienta más completa, sino la de mayor eficiencia de entre resultados y facilidad de uso. Muchas veces una mala selección provoca una gran pérdida de tiempo. Lo más importante, es adapta las herramientas al proyecto y no al revés.

Uno de los errores más comunes al seleccionar una herramienta, es coger una sin haberla probado antes. Es complicado saber si una herramienta encaja en el proyecto, por eso es conveniente usar un periodo de prueba, que nos permita comprobar los siguientes aspectos:

  • Con la herramienta puedo cumplir todos los requisitos.
  • Los miembros del equipo la pueden aprender a usar en un tiempo razonable
  • Si la herramienta produce problemas nuevos, como incompatibilidades, dependencias de pagos, limitaciones...
  • El resultado que se puede obtener justifica el tiempo invertido y los problemas generados.

Más vale prevenir que currar

 Autores: Jorge Arévalo y Laura Rodríguez

Cuando arranca un proyecto, lo primero que se nos pasa por la cabeza es: cuanto antes empecemos a producir, mejor. Hay plazos, hay entregas, hay nervios. Pero esa urgencia por meterse en faena, aunque nace de buena intención, puede acabar jugando una mala pasada.

Entre que se publica el proyecto y el momento en que empezamos a redactar documentos, grabar vídeos o diseñar páginas web, hay tiempo que solemos comprimir demasiado. En Gestión de Proyectos a esta etapa la llaman etapa preconstitucional, y se le asigna una dedicación estimada de unas tres horas de trabajo fuera de clase.

Parece mucho, pero nuestra experiencia y la de otros equipos, apunta a que esas tres horas mal aprovechadas pueden costarte mucho más tiempo después.

Quien calla otorga: El problema de los roles al principio del proyecto.

 Autor: Rubén Gallego

Cuando un equipo empieza sin conocerse, los roles en base a el conocimiento que tenemos del equipo en muchos casos limitado. Esto lo he vivido en primera persona: quien más habla termina dirigiendo, quien tiene más tiempo libre carga con más trabajo, y quien calla recibe menos tareas, no porque no valga, sino porque nadie sabe todavía qué sabe hacer. El problema no aparece el primer día. Aparece semanas después, cuando alguien está al límite y otro lleva tiempo sin hacer casi nada. Y para entonces, ya es tarde para cambiar las tareas sin retrasar el proyecto.