Volver
Diario del CEO

Primer año en la universidad y cómo mi primer trabajo sentó las bases.

En la publicación anterior, hablé sobre cómo fui casi todo en mi primer trabajo (todavía bajo acuerdos de freelance): desde supervisor de una campaña de Google AdWords hasta programador. Trabajar en una agencia de publicidad fue un excelente comienzo para una carrera freelance porque probablemente me enseñó todos los errores posibles.

Además de crear sitios web, lo primero con lo que empecé a trabajar fue la publicidad de pago en Google AdWords, que en ese momento era bastante misteriosa. Recuerdo no saber nada al respecto, excepto que Google Analytics era una herramienta nueva y en crecimiento parcialmente relacionada con el servicio de publicidad de pago de Google AdWords.

Queriendo ser honesto y hacer bien el trabajo, descargué un montón de libros de Apress sobre SEO y Google AdWords a través de torrents. Los leí en inglés en lugar de blogs todos los días para entender de qué se trataban y cómo gestionarlos adecuadamente.

Estoy orgulloso, pero esos tres libros que leí fueron un excelente comienzo para entender de forma general el SEO y Google. Luego continué construyendo sobre esta comprensión leyendo blogs y manteniéndome al día con los últimos desarrollos. Leer esos libros formó la base de mis conocimientos, que todavía son útiles hoy en día.

El segundo problema que me di cuenta entonces fue que un diseñador de impresión no podía ser simultáneamente un diseñador web. En ese entonces, casi todos los diseñadores se consideraban a sí mismos diseñadores universales, y términos como UX o UI no se utilizaban. Y eso fue un problema significativo.

El problema era que los diseñadores creaban postales estáticas y hermosas que, en cierto sentido, se suponía que funcionaban como sitios web. Algunos ejemplos:

• Los elementos del menú se diseñaban sin estados y sin dejar claro que se podía hacer clic en ellos.
• Se usaban degradados (CSS3 no existía en ese entonces), y el fondo se convertía en una imagen enorme. Imagina qué diría Google PageSpeed Insights sobre eso ahora.
• El diseñador usaba fuentes en cursiva o incluso Comic Sans a veces. Sí, sucedía.

Para ayudar a mis colegas, leí el entonces popular blog de Smashing Magazine, que básicamente moldeó mi comprensión del diseño web: cómo debían estar dispuestos los elementos y las mejores prácticas, y en general sentó las bases de los estándares de UI/UX que se desarrollarían en el futuro.

Así, me convertí en la primera barrera antes de presentar diseños a los clientes, aquel que daría algunas notas al diseñador para hacer el diseño al menos un poco mejor. Recuerdo que esto fue un verdadero dolor para un experimentado diseñador de impresión: algún niño tratando de decirle cómo dibujar. Había mucha tensión, pero me sentía obligado a hacer las cosas bien y con calidad. Quería compartir mis conocimientos.

El tercer problema era que los sitios web no eran el negocio principal de las agencias de publicidad. No es un secreto que las agencias de publicidad suelen tratarse de contactos y relaciones, donde un “buen amigo” llega y encarga servicios porque saben que tú “haces las cosas bien”.

Debido a esto, noté que los clientes a menudo querían más funcionalidad o un tipo diferente después de que se entregaba el proyecto. Pensaban que cumplir todos sus deseos y expectativas por un precio fijo era lo esperado. Después de todo, si estás organizando un evento o ajustando un diseño de volante, puedes hacer tantos cambios como desees hasta que estés contento con el resultado final.

Inicialmente, no escribíamos ni definíamos ninguna especificación. Y, por supuesto, no podías decepcionar a un amigo, así que todas las solicitudes adicionales tenían que cumplirse de forma gratuita. Naturalmente, todo esto eventualmente se hacía a mi costa. Nadie entendía que agregar un nuevo tipo de página no era solo agregar un elemento de menú, sino que requería programar una nueva entidad, sistema de gestión e integración en el sistema general.

Apenas había escuchado vagamente sobre especificaciones y que incluso existían. Introduje el objetivo de escribir descripciones (en el mejor de los casos, estas podrían llamarse requisitos) antes de comenzar cualquier proyecto y cobrar extra por costos adicionales no especificados.

Ambos nos beneficiamos de esto: no tuve que trabajar de forma gratuita y cumplir con requisitos cambiantes, mientras que la agencia encontró una razón para cobrarle aún más al cliente. Aunque en algunos casos, yo fui el único que se benefició del mismo presupuesto.

A partir de entonces, aprendí a escribir especificaciones técnicas o descripciones de requisitos para cada proyecto. Constantemente mejoraba y aprendía a escribirlas más precisas y mejores, y con cada nuevo cliente, tenía menos disputas sobre qué se necesitaba hacer y por cuánto.

El cuarto problema que encontré fue la gestión de proyectos. Organizar un evento o manejar un trabajo de volante o tarjeta de presentación no es lo mismo que crear un sitio web funcional.

No puedes enojarte porque todavía es difícil encontrar buenos directores de proyectos de TI hoy en día. Para ser un buen director de proyectos de TI, debes entender lo que están haciendo tus colegas diseñadores y programadores y el proceso. Si no entiendes esto, seguirás siendo solo un mensajero entre el cliente y el programador. Ser un mensajero a menudo significa solo reenviar correos electrónicos, lo que no crea valor.

Me di cuenta de esta discrepancia ya en el duodécimo grado al observar cómo trabajaba el director de proyectos conmigo. Por ejemplo, antes de asignar una tarea a un programador, primero debe ser descrita adecuadamente, obtener las credenciales necesarias y preparar todo para que todo lo que reste sea ejecutarlo. Pero resultó que, como uno esperaría que ya no suceda en las empresas de TI, las respuestas eran: “No puedo responder a eso, necesito verificar,” o “Te responderé con una respuesta.” Tus respuestas se copian y pegan simplemente al cliente, y sus correos electrónicos se reenvían. Eventualmente, te conviertes en el director de proyectos, te guste o no.

En ese momento, abordamos este problema cuando yo, en mi primer año de universidad y sin automóvil, viajaba frecuentemente en tren de Kaunas a Vilnius para asistir a reuniones con los clientes.

Era encantador que, como estudiante de primer año, tomara el primer tren a las 6 a.m. a Vilnius, donde el director de proyectos ya estaría esperándome en la estación de tren a las 8, y nos dirigiríamos juntos a las reuniones.

Era genuinamente aterrador porque las empresas parecían bastante grandes y elegantes, al menos así me parecían a mí. Me ponía mi mejor suéter y me aseguraba de que no hubiera pelusas en mi abrigo. Quería que me vieran como profesional y no solo como un niño asustado.

Escuchaba y observaba cómo un director de proyectos realmente bueno (a pesar de todos los problemas relacionados con TI) se comunicaba amablemente, resolvía conflictos e incluso vendía servicios. Aprendí observando, y observar no es menos importante que hacerlo tú mismo. Cuando no entiendes el contexto o cómo se debe hacer, aprender de un ejemplo proporciona una gran cantidad de contexto que puedes aplicar más adelante. Estoy increíblemente agradecido por eso.

Por ejemplo, aprendí una regla aparentemente simple: para ser puntual, debes llegar exactamente a tiempo, ni antes ni después. Siempre solía llegar demasiado temprano, con miedo de llegar tarde.

Es gracioso que algunos de esos clientes de entonces ahora se hayan convertido en mis clientes en comercio electrónico a través de la agencia sin siquiera saberlo. Es un impulso al ego.

Así que, mi primer trabajo bajo un acuerdo de freelance con una agencia de publicidad sentó las bases para mi viaje freelance posterior. Desarrollé mis primeras habilidades de SEO, profundicé mis conocimientos de programación construyendo sistemas con WordPress y comencé a formar habilidades como analista y director de proyectos.

Finalmente, los proyectos evolucionaron de “hacer lo que funcione” a “hacer las cosas correctamente”: con especificaciones y descripciones de requisitos, evaluaciones preliminares y contratación de diseñadores web y desarrolladores front-end profesionales, mientras yo programaba todo y gestionaba el proceso. Incluso preparamos instrucciones para los clientes sobre cómo usar el sistema, y yo mismo conducía esas sesiones de capacitación, mostrando cómo funcionaba el sistema.