Ganar respeto y dinero con Joomla

Este es un capítulo especial escrito por Henk van Cann


La implementación de CMS's es difícil, pero algo genial en lo que estar involucrado. Ni lo bueno que seas técnicamente, ni lo socialmente conectado que estés, ni tan siquiera lo honesto o trabajador que seas - nada de eso suma un ápice a la hora de determinar el respeto y el dinero que recibirás.

Este capítulo trata acerca de lo que deberías y no deberías hacer para ganarte la vida implementado y dando soporte Joomla!.

Las cosas que sí cuentan a la hora de ganar respeto y dinero:

  1. Sé firme, pero comprensivo;
  2. Prioriza los plazos de entrega, flexibiliza el alcance del proyecto;
  3. Vende y negocia continuamente;
  4. ¡Define roles y desempéñalos!

¿Por qué yo?

¿Alguna vez has:

  • tenido clientes que no pagan sus facturas?
  • trabajado el doble de lo que has cobrado?
  • tenido un gran malentendido con tu cliente acerca de los entregables del proyecto?
  • recibido un trato poco respetuoso por parte de algún cliente?
  • fruncido el ceño frente a las elecciones que los clientes hacen en el campo en el que eres experto?
  • recibido poco o ningún reconocimiento por lo que has entregado?
  • necesitado pelearte para no caer en el "síndrome del lavadero"?
  • tardado mucho más en entregar, pero al cliente no le ha preocupado?
  • discutido con tu pareja, esposa o marido acerca de si es una buena idea seguir adelante con tu negocio?
  • pensado en volver a un trabajo fácil y normal?

No estás solo.

Si las respuestas a todas las preguntas anteriores fueron 'no', tienes un talento natural para ganar respeto y dinero con tus habilidades con un CMS de código abierto.

¿O es que acaso ya habías puesto en práctica los contenidos de este capítulo antes?

Negación

Tras años de largos días y duro trabajo, sólo nos encontramos con almas gemelas en reuniones y congresos sobre software libre, en los que compartimos nuestras experiencias. O a través de canales IRC, en los que nos gusta quejarnos acerca de nuestros clientes: son estúpidos, no quieren pagar, creen que lo saben todo, esperan que te pongas a trabajar sin que ellos hayan puesto siquiera el lápiz sobre el papel, y tantas otras cosas.

Lo que ocurre aquí es que estamos en un estado de negación. El cliente no es el problema. Somos nosotros mismos los que debemos cambiar de actitud.

"No soy bueno vendiendo, lo que me gusta es construir sistemas."

Muy bien pero, ¿pusiste en marcha tu propio negocio para hacer obras benéficas? Aquellos que trabajan de forma altruísta consiguen respeto, y "venden" su ayuda gratuita.
Si has decidido poner en marcha tu propio negocio, no vender no es una opción. Tienes que bajarte del tren equivocado rápidamente.

"No soy lo que se llama un vendedor - Soy demasiado blando. Para ser honesto: odio vender."

Necesitas un cambio en la forma en la que percibes el mundo. Vender es una profesión que debería ser descrita como "ayudar a comprar". ¡Deja a un lado tus prejuicios! Empieza a ayudar a tus clientes a comprar las cosas adecuadas (en lugar de vender), y enséñales cómo dispensarte el respeto y el trato que te mereces, además de pagarte.

"Las grandes organizaciones no contratan a pequeñas empresas para sus grandes proyectos."

Juega su juego, juégalo bien, y te contratarán.

"Mis clientes no trabajarán de esta manera."

Bueno, entonces búscate otro tipo de cliente, o enseña a los actuales "cómo funciona".

"No se gana mucho dinero con el software libre"

Justo al contrario: La integración de software libre tiene al menos cinco efectos principales de innovación que el software de fuentes cerradas no puede batir. Esto es algo probado e indiscutible. Por esa razón, la proposiciones a corto o largo plazo de sustitución de software cerrado por software abierto "son" un buen negocio. Simplemente porque el software cerrado requiere mucho dinero. El software cerrado puede llegar a adaptarse a la innovación del software abierto. Pero eso llevará tiempo. Mientras eso ocurre, tu pericia vale dinero y respeto. Si aún no te has convencido, haz clic en el enlace que hay un poco más atrás acerca de los mencionados efectos innovadores de la tecnología abierta porque necesitas desprenderte de tu orgullo.

¿Aún estás en estado de negación?

¡Lamento haberte molestado! Por favor, sigue adelante con tu buen hacer y pon tu mente a descansar con el resto de capítulos que encontrarás en este libro. Una última petición: ¿podrías hacer el favor de desvanecerte lentamente, pobre y sólo? :-)

El resto de capítulos del libro merecen mucho la pena. No me malinterpretes. Sin embargo, no te duermas en los laureles consiguiendo más conocimiento técnico simplemente como una distracción de un asunto completamente diferente: ganar respeto y dinero. Porque esto no tiene nada que ver con Joomla, Drupal, TYPO3 o cualquier otro CMS de código abierto, ni con tu nivel de pericia en su manejo.

¿Despierto? Perfecto, necesitamos una mente clara para aprender y precticar cómo ganar respeto y dinero con nuestra pericia.

Tres cosas que hay que tener en cuenta a lo largo de todo el camino

  1. Tu reputación
  2. Tu(s) rol(es)
  3. Tu(s) tarea(s)

1. Tu reputación

En general, la reputación de los trabajadores TIC puede encontrarse en la zona baja del espectro de los trabajos respetados. ¿No estás seguro de estar de acuerdo con esta afirmación? ¡Compruébalo tú mismo!

  1. Ponte un traje y empieza a hablarle de una proposición de negocio a alguien. Sobre la marcha, cambia el discurso y empieza a hablar de los detalles técnicos de una posible implementación de esa proposición concreta. Tu credibilidad disminuye inmediatamente.
  2. Menciona tu profesión tecnológica en una fiesta a (mujeres) profesionales urbanos (urbanas) jóvenes. Fíjate en sus caras.

2&3. Tus roles y tareas

En las organizaciones, nuestro trabajo como técnicos es persistir en una constante gestión de expectativas, en la venta infinita y en ceñirnos a lo planificado.

Las buenas noticias son que existe mucho material detallando el proceso de implementación de un sistema web. Las malas noticias: ¡Ayuda, hay humanos involucrados!

Los problemas son esas cosas sin sentido que aparecen cuando no tienes la vista fija en el verdadero objetivo: ganar dinero y respeto.

Para empezar, algunas definiciones

Recurso

Un recurso es una aportación que depende de un cliente o de terceras personas. Si no obtienes el recurso, no puedes completar tu trabajo. P. ej, fotos digitales de un fotógrafo, una lista de nombres de elementos de menú en un idioma diferente, una firmita en el contrato en el que se detallan tus emolumentos (¡ups...! ¿nunca pides eso?), etc...

Planificación de recursos

Consiste en asegurarse de que las aportaciones de los clientes y terceras personas están disponibles para ser usadas en un proyecto o soporte.

Alcance

La dimensión de una solución. El tamaño y magnitud de un esfuerzo, pericia, maquinaria, funcionalidad que será requerida/planificada para ofrecer esa solución.<la entrada "Alcance (gestión de proyectos)" de Wikipedia puede aclararte un poco este concepto, y si no siempre está Google para completar>

Bloques funcionales

Un grupo lógico de funcionalidades bajo un título común. Expresado en el lenguaje habitual del "homo sapiens". Por ejemplo, foro, diseño, interfaz, búsqueda avanzada. (un homo digitalis inventaría títulos como Jom-Social, psd más html/css y una plantilla basada en un boceto, esquema de base de datos para contenido indexado).

Plan de lanzamiento

El plan de lanzamiento especifica qué bloques funcionales serán implementados para cada fase de desarrollo del sistema, así como las fechas de lanzamiento para cada fase. El plan de lanzamiento especifica quién (en qué rol) completará cada tarea concreta.

Iteración (Sprint)

Los esfuerzos a desarrollar durante una fase concreta en un proyecto (tal y como se acordó en el plan de lanzamiento). La palabra "sprint" sugiere correr hasta la meta, sin perder tiempo. Tenemos que llegar al avión a tiempo. Porque el avión despegará, y mejor que sea con nosotros dentro. Y por tanto no deberíamos perder tiempo en empacar nuestro equipaje tan concienzudamente, no importa si nos olvidamos de algo, podemos ir a trancas y barrancas... ¡pero debemos llegar a tiempo! Procediendo de esta manera, estaremos mucho mejor que con nuestro equipaje impecablemente preparado: todo lo que podríamos necesitar está perfectamente colocado en la maleta, pero nos hemos quedado en el aeropuerto.

SprintX

El sprint virtual tras el último de los sprints consignados en el plan de lanzamiento. Es un contenedor para trabajo extra (ya sea por el síndrome del lavadero o acordado fuera del alcance) o zona de espera para bloques funcionales que no pudieron ser implementados en los sprints planificados hasta ese momento.

Gestión del contrato

La gestión de los contratos firmados con clientes, proveedores, socios o empleados. La gestión de contratos incluye negociar los términos y condiciones del contrato y asegurarse de su cumplimiento, así como documentar y acordar cualquier cambio que pueda surgir durante la implementación de lo acordado. El propósito: maximizar el rendimiento financiero y operativo y minimizar el riesgo.nimizing risk.

Gestión de proyectos

Es la disciplina que se encarga de planificar, organizar, asegurar y gestionar recursos para llevar a término los objetivos y fines de un proyecto. Dicho de otra manera: llegar de A a B sin quedarse por el camino, y llegar a tiempo, pase lo que pase.

Evaluación de prioridades

Cómo percibe la gente el mundo, y en particular en una implementación de sistema web abierto/Joomla: cómo ve la gente los resultados en el contexto de qué fue lo que se acordó. Necesitamos elaborar un poco más acerca de la evaluación de prioridades, porque la sincronización de dichas prioridades es la clave para una buena gestión de contratos.

Evaluación de prioridades

La evaluación de prioridades es compleja. Podemos encontrarnos intereses contrapuestos, asuntos personales frente a los roles que desempeñamos. Diferentes niveles de pericia y experiencia. Cómo de bien fueron percibidas las negociaciones. ¿Y qué hay acerca del respeto? ¿Recibieron suficiente respeto las partes implicadas que anotaron por escrito su evaluación de prioridades? ¿Respetaron a otros durante el proceso? Todos estos factores influyen en la manera en la que percibimos las cosas.

Ejemplo: una disputa emocional con tu vecino difícilmente tendrá algo que ver con el tema u objeto que inicialmente motivó dicha disputa. Lo más probable es que fuera alguna otra cosa la que formó su opinión, expresada en cierto tipo de "orden de prioridades".

Psicología casera personalizada

Vamos a echar un vistazo rápido también a algunos importantes efectos psicológicos presentes mientras hacemos negocios. En el caso de la implementación de un sistema web de código abierto, con frecuencia nos ptropezamos con algunos efectos interesantes que tienen una incidencia importante.

Lo que el cliente realmente quiere

Cobertura y asesoramiento futuros garantizados. Así es, amigos. El cliente no está interesado en código abierto, Joomla, tú, tu producto, tus métricas, tu visión, etc. Así que deja de contarle historias estúpidas y empieza a formular preguntas inteligentes para hacerle sentir seguro en lo que realmente le importa.

El valor decreciente del servicio

Todo lo que ya ha sido hecho, vale menos cada día que pasa, y todo lo que aún está por hacer es muy importante y urgente. ¿Te suena de algo?

Siempre tiene la razón

Un cliente siempre tiene la razón. Si no, sencillamente tenemos una opinión diferente del tema... Este es un buen ejemplo sobre lo que hablábamos antes de la sincronización de las prioridades.

La fecha de entrega es sagrada. Flexibiliza el alcance

Los proyectos tienden a extenderse más allá de la fecha de entrega. ¿Por qué? ¿Tan malo eres planificando, te gusta disgustar a la gente? Por supuesto que no. ¿Acabas con un resultado defectuoso que debe ser depurado, aceptas nuevos requisitos y recursos que cambian mientras estás desarrollando? Sabes que sí. ¿Tienes algún problema para detener los esfuerzos de desarrollo y comenzar un testeo concienzudo? ¿Entregas sistemas a medio hacer simplemente para "mantener al cliente contento"? Probablemente lo hagas. Y deberías detener esa conducta en este preciso momento.

"La fecha de entrega es sagrada" significa: no importa qué es lo que ocurra, entregaremos el proyecto a tiempo. Lee la frase de nuevo: entregaremos el pryecto a tiempo.

40 años de TIC no nos han hecho ningún bien desde algunos puntos de vista. Está perfectamente aceptado que no entreguemos a tiempo. Incluso peor: está aceptado que más del 50% de los mayores proyectos TIC a lo largo y ancho del mundo sean un fracaso total. Y aceptamos que tienen a ser el doble de caros al final de lo que se estimó inicialmente.

Imagina que tu tienda de comestibles dijera "no hay leche hoy" después de que la hubieras encargado por teléfono ayer. Imagina que tu panadería subiera sus precios un 100% o 200% de un día para otro. ¿Qué dirías si el constructor de tu casa que acaba de derrumbarse te enviara la última factura por "trabajos hechos en tu vivienda"?

Los clientes TIC simplemente se largan mascullando su desdén. Se van y empiezan un nuevo proyecto TIC. ¿Y qué pasa con nosotros, los proveedores? ¡Nos quitamos de en medio con nuestro incumplimiento! No entregamos a tiempo, no nos ceñimos a las promesas y entregamos sistemas que no serán usados (por mucho tiempo). A veces, un cliente nos demanda. Pero qué importa: no puedes sacar sangre de una piedra. En muchos casos, clientes enfadados no pagan la última factura o la factura más cuantiosa (depende de cómo de estúpidos hayamos sido). Pero es de lo que se trata. Nos lo tomamos como un juego de niños. Pasamos página y vamos al siguiente proyecto, en el que actuaremos más o menos igual...

¡BASTA!

¡Entrega a tiempo, no importa qué es lo que ocurra, sin excusas, entrega!

Cómo entregar a tiempo

Ahora entraré en detalle acerca de cómo se hace y los efectos positivos de esta conducta para todas las partes implicada, incluyendo tus clientes.

¿Cómo puedes conseguir entregar a tiempo?
Fundamentalmente, flexibilizando el alcance.

La compañía 37signals escribe en su visionario manual Getting Real: los sitemas de código abierto (y también Joomla) están muy bien equipados para ceñirse a esta regla (lee el libro entero para conocer otras reglas igual de buenas)

  1. El código abierto tiene buenas capacidades para el prototipado y las pruebas de concepto, el alcance queda más claro "después" de crear un prototipo, y por tanto se pueden evaluar mejor los cambios necesarios.
  2. Un sistema web de código abierto lleva incorporadas muchas y muy útiles funcionalidades; hay una gran cantidad de cosas por cambiar al alcance (ver también 'Negocia continuamente')
  3. El alcance debería ser flexible porque los clientes cambian de idea acerca de lo que quieren una vez que han experimentado con los primeros resultados y posibilidades. Los clientes aprenden a medida que trabajan con la herramienta. Y cambian de idea en consecuencia. El síndrome del lavadero es el efecto negativo; "flexibilizar el alcance" es la solución positiva.

Esta es la guía paso a paso:

  1. Acuerda desde el principio que para ti lo primero es la fecha de entrega, y que el alcance será flexible para ajustarse a dicha fecha. Explica honestamente lo que "flexibilizar el alcance" significa. Llamemos "ellos" a los clientes. Sé muy abierto: lo que ellos quieren en este momento, no lo querrán al final. ¿Por qué no? ¿Por qué no? ¡Avanzar a base de intuiciones puede llevar a diferentes sistemas! Sin embargo, ellos conseguirán siempre lo que quieren en cada iteración hacie el resultado final.
  2. Asegúrate de que estás a cargo de flexibilizar el alcance (sin discusión, tienes que cumplir con la fecha de entrega, de modo que tú eres el que toma las decisiones).
  3. Planifica un "tiempo de amortiguación" en tu trabajo hacia la fecha de entrega. Usa este tiempo para flexibilizar el alcance y poder crear nuevas versiones de tu plan de lanzamiento. Puedes hacer esto disminuyendo el número de bloques funcionales en el sprint actual, o "adelgazando" algún bloque funcional.

Gestiona con los clientes posibles frustraciones

  1. Nunca escribas tú mismo las especificaciones de un bloque funcional. Colócalo en el siguiente srpint o en el SprintX.
  2. Comunica la acción de flexibilización del alcance con un nuevo plan de lanzamiento
  3. Cíñete a las prioridades establecidas en la evaluación de prioridades, y toma nota de cada indicación (que no se duplique ninguna) o petición explícitamente.

Sé firme pero amable

Mantener una postura firme significa principalmente:

  1. No vuelvas a aceptar un contrato con un presupuesto cerrado nunca más. De lo contrario, obtendrás un margen ridículo sobre lo presupuestado inicialmente. El desarrollo e implementación de sistemas web de código abierto sencillamente no es apto para ofrecer servicios a un precio cerrado. Explora el sistema de alerta de 2Value como una alternativa a medio camino entre un precio cerrado y un sistema de "carta blanca".
  2. Cíñete a las reglas del compromiso: ¿los pagos se retrasan? Deja de trabajar inmediatamente, sin excepciones.
  3. Profesionalidad: empieza a ofrecerla demandándola.

Comportamiento amable acompañado de una postura firme

  • A: Siempre escribe o di: "no podemos" en lo lugar de "no queremos" o "no haremos".
    Ejemplo: Lo siento, señor, me temo que no puedo continuar trabajando en su sitio web. No hemos recibido el pago de la última factura en nuestra cuenta bacaria. La política de la compañía es la de comenzar el trabajo únicamente cuando los pagos pendientes acordados hayan llegado a nuestra cuenta.
  • B: Di que no puedes empezar con ese análisis en busca de virus hasta que el dinero haya llegado al banco, pero al mismo tiempo deja que el cliente "sienta" que "extraoficialmente" ya se han tomado medidas, y que se está trabajando a pleno rendimiento en solucionar el problema.
  • C: Un contrato de soporte difícilmente puede asegurar resultados. El soporte de los gestores de contenidos web, especialmente de los basados en código abierto, sólo puede asegurar esfuerzo guiado. ¿Qué significa esto? Pues que como mucho podemos prometer tiempos de reacción, respuesta y resolución, así como la capacidad y habilidades necesarias para ello.

No pongas el peso de la responsabilidad de garantizar resultados sobre los hombros de tu negocio. No podrán soportarlo. La carga de varios millones de líneas de código... del código de otra persona. Código ejecutándose en un sistema en constante cambio que es atacado por sinvergüenzas todos los días (hackers).

Recuerda. Antes de que el cliente llamara por primera vez a tu puerta, su sitio nunca había sido un problema. Ten eso en mente y recuérdaselo a tu cliente. Algunos de esos clientes piensan que pueden comprar tu compromiso y devoción contratándote como un mero maquetador por unas cuantas horas... Y algunos actuáis como pecadores tan pronto como un cliente se angustia y apunta su dedo acusador hacia vosotros porque su sistema web no funciona. Repito: compórtate como un profesional y ellos te respetarán como un profesional. Compórtate como un asistente de bajo rango, y te tratarán como a un felpudo.

Un gestor de contenidos web es el problema del cliente, y podemos asistirle mejorándolo y ofreciendo ayuda cuando surjan problemas. No es tu problema. ¿Comprendido? Pequeña diferencia, enorme efecto. Simplemente cuida el tono de voz.

Dicho (y repetido) esto, te dejarás el culo para ayudar a que la tienda online de ese cliente esté operativa de nuevo justo antes de que llegue la fiebre compradora de las Navidades.

  • D: Entregamos exactamente lo que se acordó (sin descontar nada), pero también pondremos un pequeño esfuerzo extra en el proceso

Vende y negocia continumente

Es obvio que deebs vender un proyecto y negociar condiciones (entre ellas el precio). Lo que resulta novedoso para mucha gente es que en el desarrollo de un proyecto de un sistema web o del soporte que vendrá después, debes vender y negociar continuamente.

Varios ejemplos:

  1. ¿Está completado? ¿Puedo mandar mi factura ahora? ("No, aún hay un para de cosas que mejorar...")
  2. Petición de soporte: cambiar un logo en el sitio. ¿Cuánto tiempo necesitas? ("¡Oh, venga ya, no puedes hablar en serio...!")
  3. Tú piensas que es trabajo extra, tu cliente no opina lo mismo. ("Puede que no esté en el documento de condiciones, pero recuerdo muy bien haber discutido acerca de esa funcionalidad")

Recuerda que vender es un juego. El cliente debería tener la sensación general de que ha ganado ese juego. ¡Proporciónales esa sensación y consigue un acuerdo beneficioso al mismo tiempo!

Para poder jugar a las canicas, necesitarás canicas.

¿Cómo consigues las canicas? ¿Firmando el contrato? No. ¿Enviando facturas? No y no. Ocultando resultados. A veces...

Las principales fuentes de créditos para tu juego de ventas son la felicidad y el dinero. No las mezcles.

  • Reúne créditos en la cuenta del banco emocional de tus relaciones (ver Steven R. Covey). Soluciona cualquier frustración que puedas tener; ¡necesitas ser feliz también en tus relaciones laborales!
  • Si los pagos parciales han llegado a tiempo, tienes créditos para jugar más partidas.
  • Trata de evitar dejar demasiadas horas trabajadas sin pagar. Esto te hace vulnerable, y despeja el camino de tu cliente para ponerte bajo presión y/o volver a plantear negociaciones. Mientras más dinero te deban, más argumentos de mierda sacarán a relucir para no pagarte. Una presión que no debía estar ahí empieza a caer sobre ti, pero tú eres el causante de que haya aparecido (revisar de nuevo la sección "Sé firme, pero amable")

¡Define roles y desempéñalos!

Un cliente dispone de muchos roles ampliamente aceptados: el jefe, el usuario final, el administrador del sistema web, y lo que es más importante, él o ella es el juez.

Dado que literalmente eres el propietario único de tu negocio, eres el responsable único del sistema web que suministras a tu cliente. Es tu responsabilidad entregar un sistema que sea: bueno, adecuado, bien documentado, que esté a tiempo, dentro del presupuesto y confiable. ¿Te parece justo?

Bueno, lo cierto es que ¡no es justo en absoluto! Echemos un vistazo un poco más de cerca a lo que está ocurriendo aquí.

Imagina que rezumas esa actitud de "lo hago todo y me encanta". Te plantearán preguntas como:

'¿Nos recomiendas usar Joomla?'

y

'¿Puede PHP encargarse del ciclo de copias de seguridad por nosotros?'

y

'¿Es posible tener soporte multi-lenguaje a tiempo?''.

No hay nada malo en estas preguntas, ¿no? ¿Cuántas veces respondiste a esas preguntas?... sin darte cuenta de que al hacerlo estabas poniendo balas en la recámara de una escopeta que apuntaba directamente a tu cabeza.

Imagina que respondiste con un "sí" a esas preguntas, y que además te extendiste dando explicaciones. ¡Muy amable por tu parte! ¡Sabes un montón! El respeto que obtienes se origina en el hecho de que no sólo eres un buen desarrollador, sino también en que:

  • tienes una visión muy mordaz sobre cómo debe ser el proceso de selección;
  • te sientes familiarizado y seguro con la pila LAMP y el mecanismo de tareas cron, y eres capaz de arreglarlo (¡guau!)
  • la comunidad internacional del software libre, y especialmente la del CMS Joomla, es como tu propia acsa; conoces a un montón de gente dentro de ellas, en cualquier parte del mundo...

'¡Qué tipo, qué tipo, qué tipo tan talentoso!'

¿No tienes ni idea de hacia dónde nos dirigimos? Tranquilo, no te preocupes, esto no son más que ejemplos inofensivos para ayudarte a comprender los peligros de ser demasiado cándido con tus respuestas.

Apretemos el gatillo de esa escopeta que apunta a tu cabeza. Recuerda que fuiste tú el que cargó la munición:

  • Espera un minuto, tú recomendaste Joomla... ¡¿y ahora resulta que tenemos que programar una extensión a medida para resolver un problema que Drupal puede resolver con las opciones por defecto...!?
  • Nosotros esperábamos tener una copia segura de nuestro sitio todas las noches, porque tú dijiste que PHP era capaz de hacerlo. Te pagamos para configurar la tarea cron. Y ahora resulta que nos encontramos con una copia inservible...
  • Prometiste soporte multi-lenguaje... ¿y ahora tenemos que pagar por él?

¿Dónde ha ido a parar el respeto con el que contabas? ¿Por qué se comporta este cliente de esa manera? Es obvio que el cliente está enfadado, y puedo adivinar que... ¡tendrás que trabajar gratis para que vuelva a ser feliz de nuevo!

¿Qué es lo que fue mal? Varias cosas elementales que hay que tener en cuenta al hacer negocios profesionalmente. Y por favor, no eches balones fuera con frases como

oh, no, si yo no soy más que una pequeña marca, un emprendedor creativo, y mis clientes son pequeños. No necesito esto.

Hay varias cosas elementales y universales que deben tenerse en cuenta al hacer negocios profesionalmente que fueron mal:

  1. No separaste tus diferentes talentos en roles distintos. Representa cada uno de ellos con sombreros de diferentes colores. Así que, a partir de ahora: define roles.
  2. No te pusiste los sombreros adecuados al responder a las preguntas. Eso te hizo vulnerable: el cliente puede tomar tu respuesta desde cualquier punto de vista. ¡Desempeña tu rol

¿Cómo puedes definir roles?

No tienes que hacerlo. Ya existen, simplemente elige un conjunto de ellos que encajen con tu negocio y comunícalos. Ponlos por escrito y haz que tu cliente se familiarice con los distintos roles que desempañas profesionalmente. Por ejemplo: gestor de cuentas, consultor, gestor de contratos, responsable de proyecto, diseñador, desarrollador, probador, generador de contenido, alojador.

Un cliente o su representante sólo abusarán de ti obligándote a desempeñas 10 roles simultáneamente SI TÚ LES DEJAS.

Para permanecer sano y salvo: usa estos roles explícitamente en los momentos importantes, y desempéñalos

Estimado cliente, realmente lo siento, pero como su desarrollador yo nunca podría contestar a la pregunta "¿deberíamos usar Joomla?". El motivo es que es su organización la que debe elegir el gestor de contenidos web, y mi trabajo será conseguir lo mejor del gestor seleccionado. Por supuesto, puedo ponerle en contacto con el Sr. Colega_que_conoces; es consultor en nuestra empresa, y se especializa en procesos de selección. Su tarifa es muy razonable comparada con la cobertura de riesgos corporativos que su consejo puede garantizar.

PHP para el ciclo de respaldo. Como gestor de contratos, debería contestarle 'no', dado que el proceso de copia de seguridad está fuera del alcance. Como gestor del proyecto me temo que debo darle la misma respuesta, pero por un motivo diferente: estamos bastante ocupados en este sprint tratando de llegar a la fecha de entrega, no hemos planeado esta funcionalidad, y no tenemos la rutina de copias de seguridad entre las funcionalidades especificadas en el plan de lanzamiento que debemos completar. Como desarrollador podría decirle: sí, puede hacerse. Pero las señales de alarma se activan cuando hablo como alojador del proyecto web: antes de diseñar una estrategia de respaldo adecuada, hay que definir las características que deben ser restauradas en caso de necesitar aplicar un respaldo. Como ve, hay muchas y distintas perspectivas desde las que se puede mirar esta aparentemente sencilla pregunta.

¿Soporte multi-lenguaje a tiempo? Debe ser más específico para evitar disgustos en un futuro cercano. Podría responderle que 'Sí', ya que es sencillo instalar un módulo de traducción. Esto se lo digo con mi sombrero de desarrollador puesto. Pero alguien tendrá que hacer las traducciones. Y ese alguien podría ser yo desempeñando un rol distinto, con un sombrero distinto: el de traductor/configurador. Si espera que "soporte multi-lenguaje" signifique "contenido localizado" tendré que desempeñar una tarea de la que no soy capaz: no soy hablante nativo del idioma en el que quiere centrarse, ni tampoco vivo en una región en la que se hable dicho idioma. Si puedo o no puedo realizar las tareas a tiempo dependerá de la planificación. Le echaré un vistazo el próximo jueves, que es el día que dedico a mi gestión de proyectos.

Esto puede parecer un juego estúpido, pero lo cierto es que se trata de negocios serios.

Tácticas

Ejemplo: diseño de interacción

Tu sesión de diseño de la interacción de usuario de mañana con tu cliente sería mucho más fácil si un tercero (en tu nombre) mencionara la cascada de acciones legales que vas emprender contra él, dado que las facturas pendientes siguen sin pagarse. Podrías darle unos toquecitos en el brazo a tu cliente y decirle "por favor, no te enfades con él, simplemente está haciendo su trabajo. No podemos culparle, ¿verdad?" El cliente le respetará tanto por su profesionalidad como por la tuya. Imagina lo duro que es desempeñar todos esos roles tú solo.

  • Para evitar minar tu relación personal con tu cliente podrías "presentarle a tus auténticos colegas" (individuos). Los auténticos colegas (incluso si ni ellos mismos saben que lo son) son geniales para tenerlos alrededos, ya que puedes:
    • a. culparles
    • b. rogarles que te presten su ayuda experta en su rol
  • Posponer y desviar: contesta a la pregunta en uno o dos roles inmediatamente, pero a continuación introdúcelo como un elemento de agenda para un rol diferente en el camino crítico. Por ejemplo: "Sí, técnicamente no hay problema, pero tendré que mirarlo el próximo jueves, que es el día que dedico a la gestión del proyecto."
  • Inventa una distracción tú mismo. No es nada de lo que avergonzarse. Es algo que se hace en los negocios a diario. Pregúntate a ti mismo "¿Suena como una excusa?" No debería. Debería ser más bien "un rol bien desempeñado".

Resumiendo

Las 4 reglas interdependientes para ganar respeto y dinero como experto en software libre resumidas son:

  1. La fecha de entrega es sagrada, flexibiliza el alcance
  2. Sé firme, pero amable
  3. Vende y negocia continuamente
  4. Define roles y desempéñalos

¿Lo ves?: ¡Ganar respeto y dinero con Joomla no tiene nada que ver con Joomla!

(Gracias a Froukje Frijlink, que corrigió mi inglés para el artículo original).

Comentarios

Muy Bueno

Un libro bastante interesante ....

Sin duda que son una gran cantidad de consejos muy útiles al momento de querer emprender.
Gracias Isidro por llevar el conocimiento al español.