Volver
Diario del CEO

¿Cuál fue mi primera experiencia como gerente de proyecto? ¿Qué aprendí de mis primeros clientes?

Entre 2014 y 2016, PrestaRock consistió de tres desarrolladores, incluyéndome a mí. Mi jornada laboral ahora estaba estructurada de manera diferente: alrededor del 30% de mi tiempo se dedicaba a la gestión de proyectos y comunicación con los clientes, otro 30% a la coordinación de tareas, descripciones y preparación de especificaciones, y el tiempo restante se dedicaba a programar.

¿Cómo eran mis primeros clientes? ¿Qué aprendí de ellos y qué errores cometí? ¿Por qué cada uno de mis correos electrónicos o solicitudes mejoraban con el tiempo?

Como freelancer, noté que pasaba casi la mitad de mi tiempo de programación en llamadas telefónicas y correos electrónicos. Eso naturalmente me llevó a iniciar mi propia empresa. Organicé mi transición de desarrollador a gestor de proyectos, y mi conocimiento en este rol fue principalmente moldeado por observar cómo otros gestores de proyectos habían trabajado conmigo a lo largo de mi carrera.

También escribí sobre cómo, cuando era un programador trabajando en una agencia de publicidad, me molestaba que el gestor de proyectos no tuviera conocimiento técnico. Como resultado, la gestión de proyectos era simplemente transmitir mensajes y actuar como un intermediario de “copiar/pegar” entre yo y el cliente.

Me imaginaba como un tipo completamente diferente de gestor de proyectos que pudiera resolver este problema. Quería poder responder cualquier pregunta técnica en tiempo real durante las reuniones, proporcionar recomendaciones sobre cómo implementar soluciones de manera más eficiente (desempeñando el papel de un analista) y estimar tareas sobre la marcha. Este enfoque sentó las bases de lo que PrestaRock representa hoy en día: Soluciones de Comercio Electrónico Robustas.

ÁGIL en lugar de Cascada

Introdujimos el principio de ventanilla única, asegurando que los gestores de proyectos no tuvieran que decir: “No sé, necesito consultar con el desarrollador para ver si es posible, cuánto cuesta, etc.” Tener un canal de comunicación por correo electrónico único se convirtió en nuestra garantía de velocidad y calidad.

Basándome en lo que había escuchado en la universidad, gestioné proyectos de la mejor manera que sabía. Implementé un método de gestión de proyectos ÁGIL SCRUM en la empresa, introduje SPRINTS semanales, documenté procesos e instrucciones, y me alejé de un estilo de trabajo ad hoc donde las tareas se asignaban al azar. En su lugar, planificamos todo y estructuramos las tareas adecuadamente.

Esto me permitió distribuir el trabajo de manera más eficiente. Al principio de cada semana, documentaba y asignaba tareas a los desarrolladores, asegurándome de que no necesitaran interrumpirme durante la semana. Esto me liberaba para enfocarme en programar o trabajar con los clientes.

Adquirí conocimientos no solo de mis experiencias anteriores, sino también aprendiendo de mis clientes. Cada correo electrónico mejoraba con el tiempo: iteraba en mi estilo de escritura, respuestas y enfoque de comunicación con cada interacción. Me esforzaba por lo que Brian Tracy llama “excelencia”.

Como freelancer, tuve la oportunidad de trabajar con algunas de las mayores empresas de comercio electrónico en ese momento, y tuve la suerte de que mis primeros clientes fueran más experimentados que yo. Algunos me enviaron solicitudes bien estructuradas, y me di cuenta de que su formato sería útil para otros. Así que comencé a usar una estructura similar para mis otros clientes. A través de ensayo y error, siempre teníamos más trabajo del que podíamos manejar.

Desafíos y Primeros Errores

Sin embargo, pronto vinieron los desafíos. A medida que crecíamos, cometimos nuestros primeros errores y experimentamos nuestros fracasos. Durante esos años, nos encontramos con clientes exigentes, y, honestamente, al igual que trabajar con empleados poco talentosos, también fue más difícil trabajar con clientes inexpertos.

Querer ser un buen proveedor de servicios = Incumplir plazos

Hace diez años, uno de nuestros primeros fracasos fue que nuestro equipo aún era pequeño. A veces calculábamos mal las duraciones de las tareas, lo que llevaba a retrasos porque las tareas las completaba otra persona en lugar de yo. Además, a menudo surgían trabajos extra inesperados, que los clientes asumían se entregarían dentro del mismo plazo, incluso cuando el alcance se ampliaba.

Como gestor de proyectos, no sabía cómo manejar las expectativas, lo que dificultaba convencer a los clientes de que algunas tareas debían dividirse en fases separadas o planificarse como una nueva etapa.

Finalmente, a veces prometía plazos poco realistas de manera involuntaria, que no siempre podíamos cumplir. Mirando hacia atrás, sin embargo, toda la industria del comercio electrónico era como el Salvaje Oeste, y ningún proyecto de TI en Lituania se completaba a tiempo durante esos años.

Trabajo Adicional: ¿Siempre Pagado?

Uno de mis mayores fracasos fue el intento de un cliente de construir un “centro comercial en línea”.

Incluso entonces, sabía que la idea fracasaría, pero no pude convencer al cliente de lo contrario. Así que seguimos adelante. Todo estaba bien hasta que el cliente importó 500,000 productos en PrestaShop 1.6. ¿Y qué sucedió? Por supuesto, PrestaShop no pudo manejarlo.

Una vez más, se hizo evidente la falta de conocimientos en gestión de proyectos. Nuestro equipo comenzó a optimizar el proyecto de forma gratuita, a pesar de ser un trabajo adicional. No pude convencer al cliente de que necesitaban pagar casi tanto como costaba el proyecto para que funcionara.

Pero no éramos el tipo de empresa que dejaba un proyecto incompleto, así que seguimos trabajando de forma gratuita.

Clientes Inexpertos solo se Preocupan por el Resultado Final

Ocurrió una situación similar con una tienda de joyas de ámbar en línea en la costa. El cliente no sabía nada sobre computadoras, internet o tiendas en línea, pero quería construir una.

Ayudamos con todo hasta que nos encontramos con un problema: las fotos de los productos del cliente tenían mala calidad y estaban mal tomadas. Sin embargo, se nos culpó porque, desde la perspectiva del cliente, el resultado final debería haber funcionado sin problemas.

No entendían, incluso después de tres o cuatro reuniones, cuando explicábamos que la plataforma de comercio electrónico generaba miniaturas a partir de lo que el cliente subía; intentamos resolver la mala calidad de las fotos de forma programática.

La situación se agravó cuando tuvimos que integrar un nuevo módulo de tarjeta de crédito PayPal que acababa de ser lanzado. El cliente exigía: “¡Haz que funcione como eBay!” Sin embargo, PrestaShop no tenía un módulo de terceros para esto, y la tecnología de PayPal no lo permitía. Aun así, el cliente no lo aceptaba.

Clientes que Aseguran que “No Tienen Dinero”

Recuerdo visitar una de las empresas más grandes de Kaunas para discutir el desarrollo de una tienda de electrónica en línea.

El CEO seguía quejándose de que nuestros precios eran demasiado altos e insistía en que todo debería ser más barato. Dado que este era un cliente grande y prestigioso, ofrecí descuentos.

Más tarde, descubrí que esta empresa tenía una facturación anual de 30 millones de euros y millones en beneficios.

En ese momento, era joven e inexperto, así que ofrecí descuentos a casi todos. Eso me convirtió en un contratista ideal: barato, rápido y de alta calidad.

Errores de Desarrollador Dañaron las Relaciones con los Clientes

Finalmente, uno de nuestros mayores desafíos fueron los errores de los desarrolladores.

No teníamos probadores en ese momento. Después de mis primeros proyectos, me di cuenta de que debía revisar todas las tareas, así que me convertí tanto en gestor de proyectos como en probador.

Fue impactante que si cometía 10 errores mientras codificaba para clientes de EE. UU., mis desarrolladores cometían la misma cantidad en cada tarea de 5 horas.

Para clientes orientados a resultados, los errores al principio del proyecto destruían la confianza. Se volvió imposible cobrar por trabajos adicionales porque los clientes culpaban nuestros errores y exigían correcciones gratuitas. Y como queríamos ser los mejores, “redimíamos nuestros errores”, a menudo a costa nuestra.

Resumen

Los primeros años trabajando con clientes fueron principalmente exitosos, hasta que comenzamos a crecer rápidamente. El rápido crecimiento significó que pasamos de solo yo a tres desarrolladores. Se sintió como un gran salto, considerando que inicialmente compartíamos una oficina con un diseñador y ahora los desarrolladores ocupaban completamente nuestro espacio.

A medida que crecimos, asumimos todos los clientes y proyectos posibles, lo que llevó a nuestros primeros fracasos: algunos clientes debían ser despedidos y algunos proyectos nunca debieron comenzar. Errores, corregirlos de forma gratuita y nuestra incapacidad para defendernos contra trabajos adicionales no remunerados nos impidieron alcanzar una rentabilidad adecuada: estábamos trabajando para cubrir nuestros salarios.

Sin embargo, estas lecciones sentaron las bases para nuestros proyectos más significativos, que se describirán en publicaciones próximas. Lo más importante es que no repetimos nuestros errores, y para 2015-2016, ya nos habíamos convertido en la agencia líder en soluciones de PrestaShop. Los clientes reconocieron a PrestaRock como una de las pocas empresas que sabía cómo codificar correctamente y ofrecer servicios de alta calidad.