Y ahí viene un problema: facturar las horas. Sucede que cuando se contrata a un freelance se hace sobre la base del ahorro, se contrata un recurso con menos compromiso fiscal y cero beneficios cosa que a la larga representa un ahorro significativo para la empresa. Pero este no es el único ahorro que se pretende obtener en muchos de los casos ya que si uno se descuida te hacen peticiones como que “a que hora vienes a instalar el app en la oficina de jurumucú?” o “para cuando coordinamos un entrenamiento on site que no puede hacerse remoto”. Esto, regularmente, sin ser acompañado de un “se que no estaba en el presupuesto, pero recuerda ponerlo a la ultima factura”.

Costo de oportunidad

Donde esta el problema con estas peticiones “inocentes”? Sencillo, cuando tienes que dedicar 6 hrs de un día a hacer un deployment (que pretenden que no factures) on site quien te contrató no solo esta devaluando tu trabajo al no pagarte por el sino que esta efectivamente evitando que puedas trabajar esas 6 horas con alguien que si esta dispuesto a pagarlas. La solución no es tan sencilla como facturar las horas y ya pues en esos casos lo más que sucede es que se tranque el juego por un par de semanas hasta que por presión deciden pagarte si, y solo si, entregas todo al día siguiente.

Estas son las mismas empresas que luego dicen “trabajar con freelancers es un lío, son muy irresponsables o son unos mercenarios”, pero creo que esa frase se debe reescribir a “trabajar con quien sea con la pretensión de no pagarle todas las horas que me trabaje es un lío”. Y si, somos unos mercenario y nuestras horas serán dedicadas a quien este dispuesto a pagar por ellas ya que como dice aquella frase enseñada por mi hermano Wilbur: “Eto no e por fama montro, eto e pa come”.

No es una calle de doble vía

Pero veamos el caso inverso, imaginemos por un momento que tengamos la osadía de incluir 12 o 18 horas en una factura que no fueron trabajadas ni acordadas. Claro, el cargo tendría una descripción ambigua para no hacerlo tan obvio como te lo hacen las empresas … Algo como que “horas dedicadas a la buena voluntad”. Entonces viene la pregunta: te pagarían esas horas? Lo mas probable es que te manden al carajo con un nivel de diplomacia que va desde “por favor arregla esta factura” a “pero es loco que tu te estas volviendo?”.

Entonces, si no es una calle de doble vía por que de manera consistente se trata de obtener horas que no fueron acordadas ni se pretenden pagar? Sencillo: no hay respeto por el tiempo del freelancer. Y creo que en gran parte esta falta de respeto viene de dos vías:

1. La línea de pensamiento que llevo a la empresa a contratar al freelancer es el ahorro, y mientras mas mejor.
2. El freelancer promedio regularmente cede ante el secuestro del (o los) pago restante para saldar las horas acordadas.

Mi solución regularmente es cortar por lo sano, prefiero dejar caer un proyecto ante la falta de respeto de mi tiempo y enfocarme en otro proyecto. Por suerte a medida que he ido saliendo del mercado local (República Dominicana) me ha tocado vivir esta mala experiencia cada vez con menos frecuencia.

De repente hay dos pizarras que los empleados no pueden ver en el mismo dia sin pasar de una oficina a otra, las conversaciones que se tenian por email ahora involucran 45 personas todas haciendo “reply to all” y convirtiendo tu inbox en una delicia … aún más cuando tienes que buscar urgente un documento que te enviaron la semana pasada.

Ante esta situación lo mas inteligente es buscar la forma de centralizar la información y facilitar el acceso a esta. Dependiendo del presupuesto para la solución de este problema las opciones van desde muy complejas/completas a bien simples y de bien simples a Google Apps.

Lamentablemente Google Apps es la primera opcion del consultor/vendedor mediocre y holgazán sin importar el presupuesto o las necesidades reales de la firma que lo contata pues con par de clicks aqui y alli le hace creer a su cliente que ya le ha solucionado el problema de la colaboración.

Soy un usuario fiel y feliz de Google Apps, pero esto no quita que entienda y acepte sus limitaciones. Lo simple de Google Apps lo hace exitoso para necesidades, bueno, simples … cuando la cosa empieza a complicarse vemos como esta solución empieza a quedar cada vez más corta.

Contexto

Una de las mejores practicas más importantes es la definición clara de un contexto orientado a las tareas y las necesidades especificas del equipo. Cuando le das a tu cliente una cuenta de Google Apps por un intranet lo mas que puedes hacer es poner el logo de tu cliente arriba a la izquierda en el listado de Google Docs y uno que otro Google Site estático. Quieres que toda la experiencia tenga la misma apariencia? Que bueno, la esperanza es lo último que se pierde.

El flujo de la navegacion y la experiencia del usuario en general no las determinarán las necesidades del usuario, sino la visión generalizadade Google.

Funcionalidad especifica

Tu cliente de repente necesita que al subir un documento PDF la metadata sea extraida y guardada  en una base de datos para ser indexada? Si le vendiste una cuenta de Google Apps ve preparando el cuento que le vas a vender … aunque si lograste venderle una cuenta de Google Apps cuando realmente necesitaba un intranet ya tienes suficiente experiencia en el fino arte de vender cuentos.

Estructura de la información

Más allá de organizar tus Google Docs en folders no puedes hacer mucho más de ahi, bueno realmente hasta ahí es donde puedes llegar con una cuenta de Google Apps. Sutilezas como una taxonomía basada en categorías o tags a la fecha no son soportadas y estas cosas que son básicas para poder organizar la cantidad de info que tiende a manejar una organización de más de 10 empleados.

Variedad de formatos

Actualmente Google Docs solo soporta cinco formatos: Drawing, Document, Presentation, Form y Spreadsheet … si tu cliente trabaja intensamente con un formato que Google Docs todavia no soporta para crear entonces ya tienes otro cuento para ir preparando.

Ya estas alturas y despues de tantos cuentos: no es mejor ponerte seriesito y venderle lo que realmente necesita?

El primer cv presenta una trayectoria de antaño, el dueño ha trabajado en cuantas empresas de tecnologia han exisitido y fracasado en el pais y se la pasa de charla en charla con su ppt diciendo cuantos usuarios de internet y Facebook hay en RD. Cuando le pones tema solo te responde con “aristas convergentes”, “creación de marca” y “efectivo social”. Si le insistes sobre su trabajo (no su trayectoria) te invitara a la proxima charla donde regurgitará el mismo ppt o te pasará un link a su perfil en LinkedIn.

El segundo cv no tiene una trayectoria tan larga pero si tiene un portfolio repleto de aplicaciones que ha desarrollado o en las que ha colaborado, te habla de patrones de diseño y arquitectura de software con pasión y cuando le mencionas social media solo se rie. Cuando le preguntas a este sobre su trabajo te contará historias de horror como aquella de cuando tenia que consumir un webservice que devolvia las propiedades de fecha como un string.

La pregunta es, a cual de estos dos contratarías? Y una pregunta de bono: a cual de los dos nominarías como desarrollador de aplicaciones para un premio en esa categoría?

Extrañamente hay un tipo de proyectos que viola esta santísima trinidad, ese proyecto que el primer día quien te contrata te mira a los ojos y con cara de pena te dice: “mira, este es un proyecto de bajo presupuesto” cuando todavía no se ha mencionado el primer requerimiento. Por el patrón anterior el desarrollador de una vez asume un tiempo de entrega razonable y una cantidad mínima de requerimientos pues deberían estar ajustados a ese bajo presupuesto.

Por que digo que ese tipo de proyecto viola la trinidad del presupuesto, tiempo de entrega y requerimientos? Sencillo, una vez el desarrollador arranca con el listado inicial de requerimientos (palabra clave: inicial) ya se ha comprometido con el proyecto y sin darse cuenta quien lo contrata se olvida de que es un proyecto de “bajo presupuesto” y los requerimientos empiezan a llover. Lo que empezó como como una consulta de días disponibles en una base de datos se va convirtiendo de entrega en entrega en un booking engine que mata de envidia a Expedia o a Travelocity. Claro, todo esto con la presión de que ya que el tiempo de entrega acordado no crece al mismo ritmo que la lista de requerimientos el proyecto esta retrasado y, obviamente, el responsable de esto es el desarrollador.

Eventualmente se entra en el ciclo de entregar un requerimiento y recibir tres más, ya que estos proyectos de “bajo presupuesto” tienen una lista de requerimientos gigantesca que se le va pasando en dosis pequeñas al desarrollador para que este no se de cuenta que aquella trifecta del presupuesto como que no existe en el mundo de este que lo ha contratado … lo que no sabe es que si existe y por eso quien lo contrata dosifica los requerimientos en vez de hacer un plan de proyecto y enseñarlo desde el inicio.

Regularmente este tipo de proyectos pasa por varias manos a medida que cada uno de los desarrolladores se va dando cuenta del asalto a mano armada del que esta siendo victima y simplemente abandona el proyecto para que otro desarrollado inocente se trague el cuento del “bajo presupuesto” y repita el ciclo.

Pero saben que es lo peor? Estos proyectos de “bajo presupuesto” empiezan con un presupuesto tan holgado que cae perfectamente en la ecuacion de Presupuesto = F(Requrimientos, Tiempos de Entrega) … lo cual es otra particularidad de los proyectos de “bajo presupuesto”: a su cliente quien te contrata no le envió una factura de “bajo presupuesto”. Entonces como es que se convierten en proyectos de “bajo presupuesto”? Ni idea, pero le agradezco a quien me lo explique en los comments.

Ahora, esta idea la estan llevando muy lejos y sin entender bien el concepto de “el contenido es rey” se esta tratando de aplicar la misma estrategia de copy writing de un periodico a cuanto proyecto les cae en la mano. Recientemente vi una propuesta para el website relacionado a la industria farmaceutica y mi primera reaccion fue preguntar si alguien tenia dramamina a mano para el mareo … parrafos y parrafos de contenido apiñados en el menor espacio posible y todos con titulos gigantes. Si todos somos importantes, entonces nadie lo es.

Hay que saber distinguir el objetivo de un usuario al visitar un website, si entiendes que el usuario entra con la idea de leer un periodico cuando en realidad el usuario simplemente necesita informacion puntual sobre algo entonces entras en la paradoja la opcion: le das tantas opciones que lo abrumas y al final opta por no elegir ninguna y salir del website. Quizás por esto es que vemos websites con “muchísimo” contenido y un bounce rate superior al 50% en la mayoría de sus páginas.

Un usuario promedio de esos que utilizan gmail o facebook ya ha sido expuesto al flujo de trabajo de un cms básico: saben llenar un par de campos en un formulario, subir una foto y han formado una expectativa de lo que sucede al darle a ese botón mágico de “publicar”. Lo que si está fuera de su alcance es el manejo de una taxonomía, el diseño de una navegación principal o la optimización de la estructura general para ser indexada por un buscador. Ahí es donde entra en la película ese que se gana el pan trabajando con esas artes místicas y arcanas.

El individuo que trabaja con la arquitectura de la información es quien debe trazar estrategia del manejo de del contenido; definiendo la estructura del website, su propensidad al cambio y el proceso que debería seguir un administrador (persona) de contenido para realizar un cambio en esa estructura. Esto garantiza que dos meses luego de entregar el proyecto no recibiremos una llamada a las 8 am de un nervioso gritando: “he agregado una opción más al menú y se dañó el diseño”.

Luego de definida esta estrategia un experto (de verdad, no un Experto) en el desarrollo de experiencia del usuario debe definir como va a interactuar la persona que administrará el contenido con el software que se elija orientando su diseño a las tareas recurrentes del usuario. Es un error del 99.99% de las tiendas de desarrollo soltar a su cliente una interfaz default/genérica de Joomla! o Drupal, por mencionar algunos de los más populares, para actuar sorprendido cuando el proceso no llene las expectativas de los usuarios.

Entonces si, la administración del contenido de un website si es una tarea que puede ser asignada al usuario promedio siempre y cuando un grupo de profesionales haga su trabajo antes de llegar a ese punto.

Hace unos años trabajé para una institución educativa ocupando una de esas posiciones híbridas entre diseñador y desarrollador web: el mítico Gran Maestro de la Web (Webmaster según RRHH). Regularmente mi día a día se parecía mucho al ejemplo del primer párrafo lo único que en vez de carpinteros, peluqueros o herreros las vocaciones eran títulos: Gerente de IT, Subdirectora Académica y Gerente de Relaciones Publicas … ninguno con un la mínima experiencia o preparación en diseño de interfaces o desarrollo de experiencia del usuario.

Si no opino, siento que no trabajo … todos debemos ser protagonistas

El problema no se limitaba a la falta de preparacion en el area de UI y UX de estas personas, sino que obviando este hecho ellos sentían que si no opinaban o “sugerían” varios (nunca uno) cambios ellos no sentían que tenian el protagonismo suficiente en el proyecto. De ahí que los trabajos que despliego en mi portfolio durante el año que estuve con ellos es la primera versión presentada antes de que el comité empezara con las “revisiones” que hacían que un producto funcional conceptualizado sobre la base de principios de diseño y usabilidad terminara haciendo sentir a los usuarios como si un grupo de mandriles salvajes los raptaron y violaron las cavidades de sus ojos con todo tipo de objetos sin filo.

Pero por que pasaba esto? Por que si se contrato a un profesional con experiencia demostrada en el área había que abandonar el criterio de este profesional para tomar en cuenta las aberraciones visuales que salían de las cabezas de esos gerentes y aquella subdirectora? Sencillo, el diseño por comite. Regularmente cuando se contrata fijo a un diseñador o desarrollador web se hace sobre la base de que este ocupara una posición por debajo de una estructura establecida y, obviando su dominio muy superior del área, se le reduce a un simple conductor de Photoshop cuyo único proposito es materializar las ideas brillantes de ese comité que tiene cero criterio y cero experiencia en el area.

El resultado de esta experiencia? Decidí abandonar siete años de experiencia en el área de diseño de UI y enfocarme en el desarrollo de aplicaciones. Por que tan drástico? Sucede que mi en en ultima jornada de diseño por comite se tomó uno de los trabajos al cual le dediqué el mayor tiempo de preparación e investigación y sin importar los argumentos basados en la teoría del color, usabilidad y objetivos del website se procedió a reducirlo a una de las aberraciones visuales que todavia de vez en cuando hace que quisiera arrancarme los ojos y dárselos a comer a un dingo australiano para que no exista posibilidad alguna de que yo pueda volver a posar la mirada sobre resultado de ese aborto de diseño de UI.

Los que quieran ver el diseño original y el “resultado” me pueden mandar un mail y se los envío.

Aun con el código mas flexible un cambio drastico al final de un proyecto trae, junto con el enojo colectivo, una distorsión en los estimados iniciales tanto de costos y tiempos de entrega como la posibilidad de tener que sacar un feature sin la planificación debida mutando asi lo que antes era un codigo limpio y hermoso a una abominación sin nombre que nos hace sentir como un Victor Frankenstein.

En el libro The Pragmatic Programmer el autor Andrew Hunt nos habla de como podemos evitar aquella abominación si junto con el cliente construimos y revisamos prototipos antes de empezar a desarrollar la app, creando así una fase de aprendizaje donde tanto el cliente como los desarrolladores se van dando cuenta del alcance real de la app. En esta fase es donde los desarrolladores pueden fijarse en la prioridad que el cliente le da a ciertos features o como reacciona el usuario a diferentes formas de realizar la misma tarea.

Para fabricar un prototipo tenemos varias opciones, podemos hacerlo con código semi-funcional y bien crudo solo para mostrar la funcionalidad que queremos sin acceso ni manipulacion de data. El problema con este enfoque es que es muy facil confundirse y terminar usando codigo del prototipo en la version final de la app. Otra opción que tenemos es usar herramientas especificas para esta tarea como Axure, SmartDraw o Balsamiq. La ventaja de estas herramientas es que se enfocan en la productividad por lo que hacer un wireframe/prototipo es mucho más rápido que hacerlo a base de código … código que por su naturaleza no puede llegar al final del proyecto.

Para tu próximo proyecto si no has intentado dedicar las primeras dos semanas a una fase inicial de aprendizaje con prototipos te recomiendo que lo hagas y al final compares los resultados con el proceso del un proyecto anterior, específicamente compara tiempos de entrega, precisión de los estimados y satisfacción del cliente/usuarios.

Nuevo rol de las agencias

El rol de las agencias tradicionales se limitó por mucho tiempo a buscar la forma de decir cosas; básicamente trabajaban arduamente en la creación de un mensaje y como lo llevarían al mayor numero de personas posible … les interese o no.

Los nuevos medios traen nuevas oportunidades de negocios, y así el rol de la agencia cambia de “decir cosas” a la explotación de estas oportunidades y la creación de nuevas utilizando las tecnologías establecidas y las emergentes. En vez de invertir el presupuesto en buscar la forma de hacer que el consumidor se mueva hasta la marca ahora tienen que analizarlo y hacer que la marca llegue donde este para establecer una conversación donde la marca no es quien lleva el mensaje sino quien lo recibe, lo escucha y responde directamente.

Creación de nuevas oportunidades de negocios

Nuevos medios abren nuevos canales, un medio que te permite mantener una conversación directa con el usuario es el sueño de todo vendedor directo. En este sentido agencias como Razorfish y RMG Connect han dado ejemplos de como se puede desarrollar apps que exploten estos canales.

Un ejemplo genial es lo que hizo Royal Caribbean en su website para afiliados, según el rango de edad e historial de consumo el contenido y las ofertas que estaban disponibles para ese usuario registrado era a la medida de su perfil logrando así llevar al usuario el contenido mas relevante y aumentar la probabilidad de cerrar una venta.

Resultados medibles

Uno de los cambios mas dramáticos viene con la medicion de los resultados, tradicionalmente las opciones estaban limitadas a numero de suscripciones o estimaciones de televidentes que posiblemente (aunque poco probable) hacían caso a un anuncio o cuña. Medir sin preguntarle al cliente “como supo de nosotros?” cuantas personas compraron un producto a raíz de ver el anuncio que se presentó a las 8:00 p.m. aún hoy es bien difícil.

En este contexto los nuevos medios tienen una ventaja gigantesca, el contenido se consume requerido por el usuario por lo que estimar numero de impresiones es posible con mayor precisión. Al explotar el medio digital como canal de ventas se puede observar directamente el resultado de un esfuerzo con solo medir cuantas personas realizaron la acción deseada.

Estos son solo tres cambios, la lista de cambios drásticos al modelo tradicional se llevaría varios posts igual de largos que este … que ya de por si es bastante largo.