Sergio Gago

Después de pasar por cientos de blogs, miles de páginas y publicaciones, hay una gran cantidad de ellas que pecan de lo mismo.

¡Los artículos no tienen fecha!

Esto no quiere decir que absolutamente todos los contenidos de la página tengan una fecha asociada, solamente los que cuyo contenido sea volátil, o simplemente tenga carácter periódico. No logro entender cómo algunas plantillas de blogs omiten algo tan importante.

Por lo tanto, si su información es de carácter temporal, o son artículos de publicación, sigan los siguientes consejos:

• Pongan fecha a todos sus artículos, y si hay que elegir, la de última modificación / actualización.
• Aunque se escriban varios artículos en un día, cada uno debe llevar su propia fecha.
• La hora, no siempre es tan importante, pero si lo es, recuerden que hay visitas de distintas zonas horarias. Y aunque el A.M.  / P.M. es un estándar de facto, todo el mundo entiende el formato 24h.
• Sobre el formato de fechas no existe un estándar: dd/mm/aaaa ó mm/dd/aaaa; por lo que lo mejor es utilizar el nombre o la abreviatura del mes.
• Y si la fecha es algo crítico, como podría ser en un diario, o en un blog de actualidad, que ésta tenga suficiente importancia visual, y no esté simplemente oculta en alguna parte del texto.

Hoy he visto el artículo de Jorge Ringenbach en Maestros del Web, sobre el contrato para el desarrollo de sitios Web, y me ha parecido muy interesante, sobre todo por el texto que enlaza en leyenlinea, donde podemos descargar un documento escrito por el mismo Jorge, y bajo CC No comercial, que ojalá hubiera tenido cuando empecé a hacer desarrollo Web.

Hace tiempo también escribí sobre la intensa relación con el cliente a la hora de elicitar para diseño web, y cómo posicionarte en un mercad cada día más complicado. La conclusión es, como bien dice Jorge, hacer una elicitación lo más completa posible, detallando las funcionalidades que va a tener el sitio, los entregables en cada fase y cómo se van a decidir las versiones finales (intercambio de versiones, firma de documentos, etc…). De esta forma, en teoría, nos quitamos problemas.

Pero no os penséis que ahí acaban los problemas. Incluso con el contrato más sencillo, del proyecto más corto, con un contrato firmado por ambas partes tanto en funcionalidades como en precio, puede haber problemas entre cliente y desarrollador.

Cosas comunes que pueden ocurrir:

• El cliente no dió importancia al contrato, pensó que solo era una formalidad.
• El cliente no entendió alguno de los requisitos, y siempre pensó como obvia una funcionalidad que tu no tenías en cuenta, y por supuesto ahora quiere incluir con el mismo presupuesto.
• Al especificar los plazos, incluso aunque dejes claro que el proyecto se puede retrasar si el cliente no entrega su material a tiempo (fotografía, vídeo, imágen corporativa existente…), siempre entenderá que la culpa es tuya.
• Exigirá que cualquier cambio o modificación se hagan instantáneamente, aunque en ningún sitio ponga que hay un contrato de mantenimiento.
• Oirá campanas de gente que poco o nada sabe, y una vez el proyecto está terminado, te sorprenderá con frases como “¿Y por qué no está hecho en flash y tiene animaciones?” o “He pensado que el diseño que te aprobé hace dos meses ya no me gusta y quiero cambiarlo”, o mejor aun “Es que aunque me hayas dicho que es la  única forma con el presupuesto que tenemos, no quiero que en mis videos salga la marca de agua de youtube”.

En el peor de los casos, el hecho de tener un contrato te simplifica las cosas a la hora de poder auditar el proyecto, pero si se tiene que llegar a este punto, ya estamos perdiendo muchas cosas: Fuerza, energía e imágen. El cliente nunca se quitará la idea de que el malo eres tu.

Así que lo único que puedo hacer es poner algunos consejos para evitar llegar a comprobar qué es lo que se firmó.

• Procurar trabajar siempre con al menos dos personas de la empresa, sobre todo la aceptación del diseño, presupuesto y algunas funcionalidades.
• Todas las funcionalidades extra que se soliciten, que se haga por mail, y se guarde. No se confirman ni desmienten funcionalidades por teléfono ni en persona.
• Asegurales 5 veces si esas son realmente las funcionalidades que quieren, y repiteles hasta la saciedad que no habrá más salvo que se amplíe el contrato.
• Y sobre todo: Di NO. Si empiezas a decir SI, a peticiones de funcionalidades, aunque sean pequeñas y no cuesten nada, aunque pienses que eso aumentará la satisfacción del cliente, en realidad estás abriendo la veda para que te pida más cosas. Es mejor decir NO la primera vez que la quinta.

¡Suerte con vuestros clientes!

Hace un par de días Jeremiah Owyang publicaba una lista de sus 10 mejores posts a leer. Sin duda un recurso imprescindible, que no he podido pasar por alto.

Para mi, tres de los mejores y más inspiradores son, las tres esferas de la estrategia Web, cómo mejorar un sitio web corporativo irrelevante (con ideas geniales!), y por supuesto, las muchas formas de monetizar un sitio Web.

Que por cierto, al leer los posts de Jeremiah, se puede notar una pasión por la Web poco usual, pero cuando se le conoce en persona, ¡esa pasión se puede tocar!

Bueno, pues por culpa del compañero Francesc, que me ha metido el mono en el cuerpo, voy a empezar a trabajar con Ruby.

He estado investigando un poco, y a estas alturas ya hay una comunidad bastante grande, de forma que resulta fácil encontrar introducciones, manuales y recursos. Aunque yo quería una introducción rápida, que me pusiera en contexto y que me explicara las diferencias esenciales, así como los pros y contras de PHP vs Ruby.

Primero quise ver de qué es capaz el interprete. Esto se lo han montado muy bien con los screencasts y ejemplos que tienen en la web oficial.

Lo más destacado fué el interprete - manual online, que en unos 20 minutos vas siguiendo un paso a paso que te pone en siutación. Ves lo básico del interprete, del lenguaje de objetos y referencias, librerías, etc…

Luego descubrí el famoso manual “Rolling on Ruby on Rails“, y vi que había una magnífica traducción en sobrerailes. En marcha con Ruby 1 y 2. (Ahora que RoR está entre mis intereses, sobrerailes ha pasado a mi lista de feeds).

Y claro, no podía faltar una buena referencia del API de Rails.

Por último, una buena biblioteca. Ya está en el wishlist de amazon, pero mientras tanto, emule los quema para ir abriendo boca:

Powered by ScribeFire.

Mientras intento preparar el resumen de lo que ha sido el FOWA en Londres, en la Web del EuroIA, la conferencia a la que asistí hace unas semanas, ya ha publicado las presentaciones de la mayoría de los ponentes. Una gozada poder revisarlas tranquilamente y mejorar las notas que tomé, ya que algunas de ellas fueron excelentes.

Lo primero que han lanzado ha sido la documentación oficial, donde además de los programas, un resúmen de los ponentes, y los patrocinadores, están casi todas las presentaciones con explicaciones en la mayoría de ellas, por lo que es la mejor herramienta para ir al EuroIA sin haber estado ahí.

Programa EuroIA 2007, 2006 y 2005

Recomiendo la descarga de la Keynote de Ricardo Baeza (PDF), en el que vemos un ejemplo de lo que ya comenté del Mindset. Haciendo una búsqueda de “Canon EOS”, en shopping salen en primera posición Amazon, la web oficial de canon en US y tiendas de fotografía y lentes. Sin embargo si busco por “researching”, los primeros resultados son FAQs de canon, wikipedia y webs de información sobre fotografía.

Esto puede ser muy útil aplicado a los algoritmos de búsqueda, ya que, según Broder, resume las necesidades de navegación del usuariol en tres grandes grupos:

• Búsqueda de información: Quieren aprender algo sobre algún tema. Alrededor del 40% (historia griega, diabetes)
• Necesidades de navegación: Quieren ir a esa página en concreto. Aprox. 35% (Aeropuerto de Luton, Ministerio de economía).
• Intención transaccional: Quieren acabar haciendo una acción en la web. Como un 35%.
  • Acceso a un servicio. (Metro de Barcelona, Clima en Londres)
  • Descargas (Imágenes de ordenadores en creative commons, elinks p2p)
  • Tiendas (comprar chips para la wii, cds sin canon… )

En general, que recomiendo encarecidamente la lectura de la presentación.

En la página del programa de la edición del 2007 tienen enlaces a muchas de las presentaciones, algunas de ellas en slideshare, por lo que desde ahí podréis ver las que más os interesen.

Algunas de las que más me gustaron fueron:

Core and Paths: Designing from the inside and out. Are Halland, Netlife research

Processes + Patterns, best practices on steroids: Peter Boersma.
Muy Buena por los modelos que presenta y los enlaces de la presentación, como welie.com donde podemos ver una gran cantidad de patrones de diseño de interacción.

No suelo hablar mucho del tema SEO por aquí, como mucho cuando lo juntamos con la parte de usabilidad y accesibilidad, y la repercusión que tiene.

Personalmente me parece una ciencia inexacta. Basada, eso si, en axiomas bastante claros, pero que en la mayoría de los casos, se trabaja con rumores o pruebas y error. Algun googler se le escapa un pequeño comentario en una fiesta, y acaba dando la vuelta al mundo convirtiéndose en un must-have de tu web.

El caso es que dado que yo no soy (ni seré) ningún experto SEO, así que no voy a evangelizar ni dar consejos magistrales. Lo que sí que me gusta es saber lo que piensan los que saben mucho más que yo de esto, asi que para vuestras indagaciones y preguntas, os dejo con los que pueblan el tag SEO de mi reader:

Adseok

Davilac

Seoblog

WebSeo

SeoMoz (en inglés)

Y por supuesto, el último que se han incorporado a la blogosfera, que seguro que tiene cosas muy importantes que contar, porque el tío es un verdadero crack, y cuyo último post ha inspirado a este y su título: “cómo ser el primero en google“. Aquí está:

El blog de Enric Ramos.

Como ya he puesto por aquí en otros posts anteriores, tuve el placer de asistir a la EuroIA conference de este año en Barcelona, y la experiencia ha sido más que satisfactoria. En cuanto a la calidad de las ponencias, a los asistentes y ponentes, que han dado una calidad de networking excepcional, y a la organización en si misma. Hay que reconocer que encontrar salas y un hotel en plena Mercé no es tarea fácil.

Un breve resumen de algunas de las ponencias a las que asistí y lo que me parecieron.

Opening Keynote: Ricardo Baeza-Yates

Desde su posición nos pudo explicar la importancia de las métricas absolutas a la hora de mejorar los resultados en las búsquedas. Qué se tiene en cuenta y qué no, y hasta qué punto, la minería de datos eficiente nos puede ayudar a conocer mucho más en profundidad a nuestro usuario.
Algo que me sorprendió y que no conocía fue la barra de filtrado de resultados en función de lo que el usuario quiere, buscar información, comprar un producto etc…

Y esto me llevó a una conversación con Vanesa Barrero sobre, ¿por qué cuando Google saca una nueva aplicación o funcionalidad, todos los blogs se hacen eco, pero Yahoo lanza funcionalidades excelentes y nadie se entera? (por cierto, pásame alguna invitación para mash!)

How to really localize and Information Architecture: Peter Van Dijck

Una ponencia más que interesante sobre cómo internacionalizar los sitios, tratando de ir más allá de la pura traducción. Las taxonomías son distintas en cada cultura y en algunos países no tendrán sentido las mismas que en otros.

Una nota curiosa y que dará que investigar. En emagister podemos tropicalizar nuestros países muy bien. Se creó México por y para mexicanos, así como Francia, Italia o Alemania. Pero, ¿qué ocurre cuando un mexicano busca formación en España, Alemania, o viceversa? Es decir, ¿Cómo se podría lograr una tropicalización inversa? ¿Cómo podemos explicar a un español que quiere estudiar en Inglaterra qué es un high school, o un institute… que no tiene nada que ver con lo que hay aquí.

Su presentación no tiene desperdicio, la podéis encontrar en su blog.

Playful IA: Kars Alfrink

Cómo lograr que la arquitectura de la información juegue un papel divertido, añadiendo retos y premios a la interacción. Muy útil para según que proyectos. La conclusión: ¿Cómo conseguir enganchar a nuestros usuarios y asombrarlos?

Muchas veces pensamos en la usabilidad como la forma de hacer que el usuario consiga nuestro objetivo, pero en realidad también incluye en hacer todo lo placentero posible, el camino hasta él y engancharle.

Persuadability in e-Commerce: Ariel Guersenzvaig

Ariel nos comenta cómo llegar a la persuasión en el comercio electrónico, a través de la credibilidad, la emoción y el contenido de calidad. Y lo hace presentando un estudio que han realizado desde Multiplica. Los resultados son bastante desalentadores, ya que en general hay muy pocos aprobados teniendo en cuenta todos los factores usados. Amazon a la cabeza con 83 puntos sobre 100 (como no), y lo más triste, El Corte Inglés, en noveno puesto, con un mísero 51 sobre 100.

En algunas falla la usabilidad, en otras el servicio telefónico, la sencillez del carrito, o simplemente la forma de pago. Las últimas tecnologías “2.0″ apenas han llegado. Seguimos anclados al oscommerce y no conocemos el mundo SEO, y a muy pocos se les han ocurrido cosas como usar tags, o incrustar videos.

UiaML: Universal Information Architecture Modelling language: Alex Jongman

Durante mucho tiempo, no había una forma universal de modelar y planificar los desarrollos de software. Entonces llegaron Booch, Rumbaugh y Jacobson y propusieron el UML, que dio todo un giro a lo que se conocía, y hoy por hoy es usado por miles de desarrolladores en todo el mundo. Pues bien, Alex Jongman nos presenta el UiaML, o Universal Information Architecture Modelling Language, con el que trata de buscar una forma universal de salir de los estáticos y a veces demasiado engorrosos wireframes y sitemaps.

Centra su núcleo en una vista de las distintas páginas del sitio y en otra del contenido, al que añade una especie de “casos de uso” e interacciones, en función de los eventos del usuario.

En general creo que puede ser una buena idea y está bien desarrollada. Pero no tiene ninguna validez si no se convierte en estándar, y no empiezan a surgir herramientas que simplifiquen el trabajo de los arquitectos de la información, tal y como Rational, o Poseidón simplifican el de los Ingenieros de Software.

Además, poder mezclar diagramas conceptuales, de interacción y casos de uso del UML tradicional, con este UiaML, podría ser una herramienta excelente para coordinar como nunca equipos de diseñadores gráficos, diseñadores de interacción y programadores.

Service Design: Claire Rowland

La arquitectura de la información es diferente en función de si estamos diseñando un producto o un servicio concreto. No es lo mismo crear un sistema para vender productos online, que un youtube, o un lector de feeds, por ejemplo.

Claire Rowland entró en este campo hablando de diseño en función de diseño de experiencias del usuario, como una parte de un todo en el que si algo falla, la imagen completa fracasa. Claire divide el diseño en cuatro partes fundamentales: Descubrir quién es nuestro usuario, qué busca, cómo se comporta, o qué hace al competencia si existe. Sintetizar los datos: Extraer de todo lo analizado los factores clave para los stakeholders, y crear modelos de usuarios.
Diseñar: Las personas, los escenarios y los momentos clave. Saber sobrellevar a nivel de diseño esos “Moments of Truth” puede ser la diferencia entre un servicio excelente o muy pobre. Y en general, prototipar, evaluar y refinar.

El resto de las ponencias, seguro que podéis encontrar más información en los blogs de los otros asistentes, como Jorge Marquez (Usandolo) y con David Rodriguez (Pozo de conocimiento online), del equipo de usabilidad de Everis. O Tomy Lorsch que ya ha escrito su review del evento, o Ariel Guersenzvaig.

Por último recomendar que nunca os ofrezcáis voluntarios para dar una vuelta por vuestra ciudad a todo un grupo de Europeos (y otros…). Siendo La Mercé, les ofrecí la posibilidad de salir a cenar y tomar algo, para disfrutar de estas fiestas, esperando 10 o 15 valientes. Pero cuando me encontré con 45 personas a las que coordinar, y buscar un restaurante, casi me da un patatús… aunque al menos, salió bien, tapearon un poco, y vieron algún concierto en catalán (algo de experiencia gané en organización de eventos, después de las fiestas de fin de año…)

Si bien la documentación del API de google es bastante completa y sencilla, comparado con otras cosas que hay por ahi, la creacion de un gadget para la google ig se puede simplificar bastante, de forma que con muy poco esfuerzo, podamos conseguir visitas para nuestros sites, sobre todo gracias al uso masivo que está teniendo desde Estados Unidos.

1. Creamos en nuestro servidor un archivo XML con el siguiente contenido.
2. Creamos el script php (o asp, o coldfusion, o jps, o whatever), que a fin de cuentas, imprima una página por pantalla. También vale un html que tenga un javascript, un CGI, flash, o lo que queramos.
3. En caso de querer utilizar parámetros y opciones en el gadget, lo podemos configurar en el xml, y nos llegará a través de GET, con lo que será fácil capturarlos por php

Un ejemplo, muy burdo y rápido, de cómo hacer un gadget para google homepage que saque una foto aleatoria.

gadget.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
<ModulePrefs
title=”Nombre del gadget”
title_url=”http://www.urldelgadget.com/gadget.php”
height=”380″ width=”400″ scrolling=”true”
author=”Nombre de autor”
author_email=”tururu@tararara.com”
category=”funandgames”
description=” [...] ”
screenshot=”http://www.tudominio.com/screenshot.jpg”
thumbnail=”http://www.tudominio.com/thumbnail.jpg”>
</ModulePrefs>
<UserPref name=”nombre_userpref”
display_name=”Elige categoria”
datatype=”enum”
default_value=”0″>
<EnumValue value=”0″ display_value=”Cat 1″/>
<EnumValue value=”1″ display_value=”Cat 2″/>
<EnumValue value=”2″ display_value=”Cat 3″/>
<EnumValue value=”4″ display_value=”Cat 4″/>
</UserPref>
<Content type=”url” xhref=”http://www.tudominio.com/gadget.php”
mce_href=”http://www.tudominio.com/gadget.php”/>
</Module>

Básicamente llama a la url gadget.php en mi dominio, y pinta además un combo que permite elegir entre 4 opciones. La opción elegida, me la enviará por GET con el prefijo “up_”, por lo que para recogerlo en php sería $_GET['up_nombre_userpref'].

Y ya en dicho gadget.php, podemos hacer las consultas que quedamos a la base de datos, impimir aleatoriamente una foto, y enlazar a donde queramos. Ya sea la home de nuestra página, o la página concreta de la foto que estamos imprimiendo. Esto también es válido para nuestro feed, juegos javascript o lo que nos de la gana. Y podemos poner hasta adsense!!!

En Smashing Magazine celebran su aniversario, y para ello han cogido a algunos de los mejores diseñadores, y les han hecho algunas preguntas. Un post realmente bueno (para seguir la tónica de este blog), que recomiendo leer encarecidamente.

50 diseñadores x 5 preguntas

Y una de las frases que más me ha gustado, es la de Larissa Meek, hablando sobre uno de los mitos del diseño de Webs.
The biggest myth is that you can get a site fast, cheap AND good. You can’t have all three. You can get it fast and cheap (but it won’t be good), good and fast (but it won’t be cheap), or you can get it good and cheap (but it won’t be fast). That’s the designer’s triangle of truth.
[Larissa Meek]

Intento de traducción:

El mayor mito es que puedes conseguir un sitio web rápidamente, barato Y bueno. No puedes tener las tres cosas. Podrías conseguir uno rápidamente y barato (pero que no será bueno), bueno y en poco tiempo (pero no será barato), o puedes tenerlo bueno y barato (pero no será bonito en poco tiempo). Ese el el triángulo de la verdad del diseñador.

Es decir, se asemeja un poco al típico triángulo de la organización de proyectos (alcance, tiempo y coste), donde a la misma envergadura de proyecto, si modificamos uno de los factores, los otros cambiarán respectivamente. Vamos, que si reducimos el tiempo del proyecto, o aumentamos el coste o reducimos ámbito.

Al final, el triángulo de Larissa es el mismo, aplicado. Si el diseñador es mejor, quizá se reduzca el tiempo, pero el coste será mayor. Si queremos hacer un proyecto muy grande, nos puede salir muy caro o ser muy malo… aunque claro, aquí ya no entramos en esos proyectos que son baratos al principio pero caros al final…

Tanto en el mundo del diseño Web, como en tantos otros, ocurre en ocasiones que el cliente se cree más profesional que la persona a la que contrata, y exige ciertos cambios que no tienen ningún sentido, o directamente no se habían contratado.

El proceso que seguimos nosotros cuando nos contratan para realizar un diseño web, es el siguiente:

1. Análisis de cliente. ¿Realmente merece la pena? ¿Necesita una Web? ¿Para qué? ¿Tenía ya algo hecho?

2. Análisis de necesidades. ¿Qué necesita? ¿Cuáles son sus objetivos con esta web? ¿Qué retorno espera tener? Porque si le voy a cobrar 2000 o 3000€, él querrá obtener unas ganancias de al menos el doble de esa cantidad (o mucho más!).

3. ¿Qué herramientas pueden cumplir con esos objetivos? ¿Un blog? ¿Unos foros? ¿Una web estática con animación flash?

Una vez estudiado todo eso, y teniendo en cuenta el presupuesto que tiene el cliente, se establece un plan de acción, con unos hitos, y unas especificaciones de producto muy claras, y firmadas por contrato.

Generalmente entregamos un solo boceto, porque nosotros, somos profesionales en saber lo que necesita, y no nos importa lo que le guste o le deje de gustar.

Entonces… ¿Qué ocurre cuando de repente, en medio de un proyecto, te dice…? Por cierto, es que también quiero eso de que la gente pueda dejar mensajes…. esto… foro! O, es que quiero que hay animación, mucho movimiento, y pueda poner los videos que crea mi sobrino en la empresa.

Evidentemente la respuesta es negativa, y esta puede ser por dos motivos:

a) No lo hago porque NO quiero. Para hacer un producto de calidad, es imposible que ponga esa cutrez. Si quieres que el sistema sea usable, no voy a incorporar esa funcionalidad

b) No me vas a pagar lo que cuesta hacer eso. si eso cuesta 15 horas de mi tiempo, te lo tengo que cobrar, y en el presupuesto actual está estrictamente lo que hemos acordado.

Estas situaciones se dan mucho, demasiado a menudo, y al final, vamos aprendiendo a paliarlas. Algunos consejos:

1. Establecete siempre como el profesional, el consultor, el que sabe lo que el cliente necesita. No eres un proveedor de herramientas, eres un proveedor de conocimiento, que luego se aplica a un código.
2. Deja claro al cliente que él no tiene ni idea, y que no le vas a permitir decirle cómo tienes que hacer tu trabajo. Igual que cuando un fontanero va a su casa, no le dice qué tipo de junta usar, tu vas a utilizar las tecnologías que considereres oportunas.
3. No eres diseñador Web. O al menos, esa solo es una pequeña parte de tu labor. Eres consultor en tecnologías de la información (esta afirmación me ha dado más clientes de los que nunca hubiera imaginado).
4. Analiza bien todas las necesidades, establece una planificación, y crea una hoja de requisitos y de funcionalidades. Esta hoja debe ser firmada por ambas partes.
5. Firma siempre un contrato que deje bien atadas todas las posibilidades. ¿Qué pasa cuando alguien se retrasa? ¿Y si el cliente tarda un mes más en pasarte algunos textos o fotografías? Establece que cualquier retraso por parte del cliente elimina parte de tus responsabilidades en fechas. Y por supuesto, deja siempre claras las fechas, o bien en función de jornadas laborables, o en días concretos de entrega de materiales, o finalización de hitos.
6. No pases por el aro a la primera. Aunque veas claro que tiene razón, no le digas que lo harás a la primera. Di al cliente que tienes que pensar bien todas las implicaciones de esa funcionalidad, y piénsatelo dos veces antes de decirle que si. Si aceptas sin pensarlo un pequeño cambio, mañana te puede venir con algo más grande.
7. Cobra siempre una parte entre el 30 y el 50% del proyecto antes de mover un dedo. Si no pagan nada, no se sienten con responsabilidad, y puede pasar cualquier cosa. Tener un contrato siempre es una garantía, pero es preferible no entrar en temas judiciales.
8. Si subcontratas partes del proyecto, o trabajas con gente freelance, cierra muy bien las fechas, y asegúrate que no puedan “saltarte” y conseguir al cliente. Cierra los requisitos y las especificaciones igual de bien que con el cliente. Ten en cuenta que si ellos la pifian, el que da la cara al cliente final eres tu.
9. Y por último… si es posible, que te subcontraten. Lo mejor que te puede pasar es que no trabajes con cliente final, y que la persona que te da los requisitos sea un profesional. ¡Te quitará más de un dolor de cabeza!

Por supuesto, estas casuísticas se dan solo con PYMEs, ya que cuando hablamos de empresas más grandes, y entramos al nivel de consultorías, la situación es muy distinta.