Archivo de Etiquetas de 'proyectos'

FIXME: Empezar muchas cosas, terminar algunas menos.

No es un secreto para nadie que parecemos hiperactivos. Nos metemos en más asuntos de los que deberíamos, y eso que aquí no contamos ni la mitad de la cosas que nos pasan por la cabeza y empezamos. Pero con este post queremos también empezar una serie sobre cosas que hacemos mal, o mejor dicho, que deberíamos arreglar/mejorar, los FIXME de Linking Paths. Lo normal es que todo el mundo cuente sus cosas buenas, o las malas del contrario, pero raramente las empresas cuentan sus miserias en su blog corporativo.

Nuestro mayor aspecto a mejorar es sin duda la cantidad de cosas que empezamos y no acabamos. Distintos niveles de empezar, pero emprezar al fin y al cabo. Así un repaso rápido de nombres… apuestoque, Linquos, handicap36, las40horas, continuar con Vivir del software, “el otro ágora”, Ostraka, una mejor selección de personal informático, Vivir de la música, cajas azules, oboloi. No sé, una buena colección, ¿verdad?, incluso estoy seguro de que me dejo algunas ideas más. Proyectos que hemos empezado que se han quedado en un estado de letargo en su mayoría en espera de tiempos mejores.

Nota: No meto en esta categoría a Stage y Tabula porque esos siguen ahí, simplemente más lentos de los esperado (dejo este tema para otro post).

Razones para este resultado hay muchas, aunque supongo que la razón principal es que hemos estado haciendo muchas cosas tambíen. Repaso rápido a los últimos meses: tog, certificacionpm, upsiteme, MyFamilypedia, Tú y el salmón, una asesoría para la Junta de Andalucía, el linking internship con su flatee y por supuesto hemos trabajado en Stage y Tabula. Pero como esto no se trata de reunir enlaces, ni de llorar, ni de ponernos medallas sino de buscar soluciones, vamos a enumerar problemas y buscar soluciones.

  1. Problema: El día tiene 24 horas.

    Posible solución: Hemos mandado una instancia al ser supremo (que cada uno escoja el que quiera, yo opto por el pastafarismo ) para ampliar el día a 32 horas, pero de momento no hemos conseguido el visto bueno, así que mientras lo recibimos buscamos otras soluciones.

  2. Problema: Realmente empezamos muchas cosas.

    Posible solución: Deberíamos empezar menos cosas. Dejar de ser tan entusiastas, si eso es posible, y escoger un poco más las aventuras. Lo malo es que es difícil luchas contra nuestra propia naturaleza (personal y como ser humano). Hemos hablado varias veces de como solucionarlo, pero puesto que la mayoría son aventuras personales, que empezamos en una noche de desvelo, me cuesta ver como articularlo de mejor forma.

  3. Problema: Nos falta un diseñador.

    Posible solución: la programación de la mayoría de los proyectos que he enumerado es sencilla (relativamente). Pero tenemos un problema grande, y es que aunque Aitor no lo hace mal (lo existente en flatee, Stage y Tabula son obra suya), si tuvieramos a alguién que pusiera bonito y especial muchas de las cosas que hacemos el resultado sería otro. Programamos bien, tenemos un maquetador excelente, podemos ocuparnos del marketing y el copywriting, pero un diseñador en nómina sería una bendición. Lo malo es que no tenemos trabajo al 100% para cubrir su coste, y perfíles raros como el de mi amigo Vitxo que lo mismo diseña, que corta, que programa en Java, Rails o Lisp con una calidad superior son una mutación difícil de encontrar. Yo diría que es nuestro mayor problema.

  4. Problema: Trabajar para otros y no sólo para nuestros productos e ideas.

    Posible solución: Esto tiene que ver con el comentario anterior del retaso de Stage y Tabula. Como su explicación y discusión es demasiado grande, lo dejo para otro post.

¿Tiene sentido destecnificar los desarrollos IT?

Desde que el mundo es mundo existe la discusión sobre si la informática es una ingeniería o no, sobre si el ciclo de vida de un proyecto debe ser así o asá, incluso desde hace un tiempo se habla (y se discute) sobre si el código fuente es el diseño o no. Incluso aquí hemos discutido sobre puentes que se prueban con camiones. Me llama mucho la atención la tendencia de muchas empresas a industrializar el mundo del desarrollo en base a factorías de software y herramientas varias, basadas en analogías incompletas.

Y no es que el objetivo no sea completamente legítimo teniendo en cuenta nuestro porcentaje de éxitos en los proyectos informáticos, simplemente parece que demasiadas veces no se entiende esta profesión. El 80% (apreciación personal, si el lector quiere cambiar el número, que lo cambie) de los documentos que se escriben en un proyecto no se leen jamás en detalle y, lo que es peor, los que se leen normalmente no se actualizan a lo largo de la vida del proyecto. Yo no voy a pedir que no se escriba documentación, pero quizás no lo estemos haciendo de la forma adecuada, o quizás el ámbito de actuación de ese deseo de industrialización sea escaso, limitándose a la parte de construcción/programación.

No quiero decir que el cliente tenga que aprender a programar, pero decidme si no tendría sentido un escenario dónde las “pruebas” se escribieran directamente de una forma técnica (es decir, que se puedan instrumentalizar directamente). ¿No debería un analista funcional escribir un test de integración en la herramienta de pruebas definida para tal uso, de la misma manera en la que en los proyectos de ingeniería se utiliza directamente el Autocad desde el diseño hasta probar cosas?. ¿No ganaríamos todos con ello?. Por una parte se estaría haciendo un diseño de interfaces (interfaces de programación/apis) con sentido para el negocio (notar la palabra “diseño” de “diseño de interfaces”), por otra el analista tendría claro que lo que él ha escrito es lo que se está probando, y lo que es más, podría automatizar esa prueba (una vez se haya desarrollado).

Esto tampoco es nuevo, es lo que siempre se ha llamado Test Driven Development y que ha recibido recientemente nuevas vueltas de tuerca como el Behaviour Driven Development, pero es algo fundamental en el mundo de factorías y subcontratación que tenemos (o quieren que tengamos) hoy en dia, dónde cada vez hay más niveles y más problemas para transmitir la información entre ellos (¿hace falta el experimento de pasar un mensaje al oído del compañero y ver como acaba?).

Sin embargo lo que vivimos es lo contrario. Herramientas milagrosas cuyo resultado siempre hay que retocar y toneladas (bueno, entre 0 y N) de documentación que nadie lee ni actualiza. ¿Por qué?. Porque programar lo puede hacer un mono o porque, como he oído últimamente, se trata de describir todo para que al programador no le quede lugar a la interpretación. Es discutible si somos capaces de describir todo -o incluso algo- de una forma coherente, pero aún así estaríamos queriendo traducir el lenguaje natural, impreciso y arbitrario, en un lenguaje técnico (el código fuente), teniendo ademas en cuenta que esto se produce en situaciones que habitualmente conllevan una importante carga de estrés (con poco tiempo para nada, y menos para leer y escribir con detalle ni hacer pruebas).

En una ingeniería cada nivel es capaz de entender el material técnico al detalle que se les pide. Tanto el cliente, como los ingenieros que lo diseñan, como la gente que está al pie de la máquina son capaces de mantener el flujo de la información técnica, por mucho que acaben cargando el puente con camiones. Sin embargo parece que los informáticos queremos ser más listos, llegando incluso a pasarnos de listos a la luz del pírrico porcentaje de éxito de nuestros proyectos.

Y este ejemplo aplicado a las pruebas es aplicable a muchas más cosas. Interface de usuario, listado de funcionalidad, etc. Ya hemos tratado este tema en el pasado también de una forma u otra (por ejemplo: la interface es lo primero). Renunciamos al prototipo (esqueleto vacío) como herramienta de discusión porque preferimos copia y pegar de una oferta que gastar unas horas en entendernos realmente con el cliente.

Obviamente en esta profesión hay sitio para todos y ni pretendo hacer un alegato para alzar a los geeks al poder ni menospreciar todo lo que no sea programación. Simplemente tenemos que encontrar un lenguaje común que minimice los problemas de interpretación. Y si en algo podemos estar de acuerdo es que el lenguaje natural y las toneladas de documentos escritos en él no pueden ser nuestra lingua franca.

El factor humano

Recientemente he tenido la oportunidad de vivir como espectador en primera fila una catrastrofe anunciada. Un proyecto que desde hace meses se veía que iba a acabar en fracaso, sin que sus gestores fueran capaces de encontrar posibilidades de salvarlo. No voy a entrar en detalles, pero me llama la atención que siga habiendo tanta gente que no ve lo obvio, y es que el 75% del resultado de un proyecto depende del factor humano. El % no lo voy a discutir, si alguno quiere cambiarlo le dejo hacerlo.

Y es que tenemos claro que las personas son importantes. Por supuesto. Nadie se atrevería a negarlo. Nadie niega que las personas hacen que los equipos funcionen, que las empresas tengan éxito, que el ambiente merezca la pena o que una idea se lleve a buen puerto o no. Pero ¿por qué eso que todo el mundo sabe nadie parece tener interés en aplicarlo en la vida real?. Las políticas de recursos humanos en la mayoría de las empresas son, cuanto menos, mejorables (demasiado café para todos), y demasiados gestores se escudan en “metodologías mágicas” para llevar a cabo sus proyectos. Así nos va. Y como nadie paga, pues lo mejor que les pasará es que les darán nuevos proyectos dónde poner esas metodologías en práctica.

No me entendais mal. Las metodologías ayudan, claro, lo mismo que la tecnología, pero no son la solución final en una profesión tan puramente mental como la informática. Existen decenas de metodologías, que a veces funcionan y otras no dentro de un mismo entorno. Existen multitud de tecnologías, y la mayoría de las veces, muchas de ellas pueden valernos para llegar al mismo resultado. Es decir, si ninguno de esos factores es determinante, ¿cúal nos queda?. El factor humano, claro. Y es que casi siempre el resultado depende de las personas (gestores, comerciales, programadores ¡e incluso clientes!). De lo que saben o de lo que no, de su situación personal, de su relación o de sus egos. De la mano izquierda del que dirige o de la capacidad del que ejecuta para buscar soluciones. De lo equilibrado que esté el factor humano en el proyecto en todos los roles necesarios.

Es como el fútbol. Por mucho que el entrenador piense como jugar, depende de los jugadores, de si son capaces o no de llevar la pelotita hasta la red (o de impedir que el contrario lo haga). Luego tener los mejores jugadores debería ser la receta para el éxito. Pero no es tán fácil, sólo hay que ver el ejemplo de los galácticos del Real Madrid. Sigue haciendo falta el entrenador, para que les coloque, pero también para que con mano izquierda consiga que hagan lo que quieran. Lo mismo que hace falta el Pavón de turno porque hay todo tipo de tareas en un proyecto. Y es que cada persona es un mundo, así que juntar a, digamos diez, personas para conseguir un objetivo, es cercano a poner en orden un universo (perdón por la exageración). Y para terminar de complicarlo, temporada a temporada, proyecto a proyecto, mes a mes, las personas cambian, y hay que volver a buscar ese equilibrio.

La solución no la tengo, claro que no. Lo que tengo claro que no funciona es la mentira, la intimidación, el abuso de poder, la autocomplacencia, la explotación (tomar este término con un poco de sal), no escuchar lo que el resto tiene que decir, menospreciar al prójimo ni cualquiera de estas técnicas demasiado habituales. Eso seguro que no funciona.



Close
E-mail It