Cómo contratar diseño web sin hacer el ridículo

Capítulo 8

Tu próximo trabajo: director de proyectos.

Este capítulo es una introducción a la dirección de proyectos. En él leerás acerca de:

  1. Cuáles son las tareas del director de proyectos
  2. Lo difícil que resulta contratar desarrolladores web
  3. Qué herramientas usa un director de proyectos
  4. Qué es un PMS
  5. Qué es la documentación de un software
  6. Qué es y para qué sirve el control de versiones
  7. Que existen tecnologías para automatizar el testeo y publicación de un software
  8. Cómo controlar la calidad del código fuente
  9. Herramientas que ayudan a detectar y resolver bugs
  10. Metodologías de trabajo como el desarrollo ágil y por qué ninguna funciona
  11. Por qué subcontratar desarrolladores puede ser el peor de los errores
  12. Por qué si la tecnología con la que se construirá tu proyecto te preocupa, lo estás haciendo mal
  13. Por qué debes huir de tus amigos informáticos para pedir asesoría
  14. Cómo valorar la calidad de un proveedor de desarrollo, aunque no tengas conocimientos técnicos
  15. Un método infalible para fracasar en la contratación de un proyecto de desarrollo de software
  16. Un método para acertar en la contratación de un proyecto de desarrollo de software

En qué consiste la dirección de proyectos

A menos que existan los hombres orquesta (en el momento en el que escribo esto todavía no he conocido a ninguno), la ejecución de un proyecto de desarrollo de software requerirá reclutar, formar, organizar, orientar y evaluar a varios profesionales de distintas disciplinas: programadores y maquetadores, diseñadores, arquitectos de redes, expertos en analítica web, redactores, information designers o diseñadores de la información (los que diseñan la arquitectura de la información) …

Fotografía de la Orquesta Sinfónica Nacional de la RAI. El director de orquesta es una estupenda metáfora para explicar lo que hace un director de proyectos.

Imagen 8.1. La función del director de proyectos es equivalente a la del director de una orquesta.
(Imagen bajo licencia CC BY 2.0 cortesía de MITO SettembreMusica.)

En mi manual, la dirección de proyectos debe encargarse de, o asistir en, las siguientes tareas:

  1. Reclutar – participar en la selección de los miembros del equipo de desarrollo.
  2. Formar – un programador sin formación continua es un programador muerto. El director de proyectos debe formar y plantear un plan de formación para los miembros de su equipo. En equipos grandes puede existir un rol dedicado parcialmente a esta labor, el desarrollador líder o lead developer.
  3. Definir – consiste en interpretar cada necesidad del promotor del proyecto y definir la manera óptima, a nivel técnico, de satisfacerla (como ya hemos visto, en programación cada problema tiene numerosas soluciones). En algunos equipos existe la figura del analista, planner o ingeniero pre-venta para desempeñar o ayudar con esta labor.
  4. Asignar y coordinar tareas – quién debe hacer qué y cuándo para que el proyecto se ejecute con el consumo óptimo de recursos (ej.: tiempo), con la mayor calidad y manteniendo al equipo de desarrollo motivado.
  5. Orientar – alguien debe saber cómo empujar a los programadores cuando se atascan con un problema. Esta labor puede ser responsabilidad del lead developer.
  6. Evaluar – juzgar el rendimiento, capacidad de mejora, y puntos fuertes de cada miembro del equipo es parte del proceso de optimización y mejora continua en el que cualquier empresa debe tomar parte.

Lo difícil que es contratar

Desde que fundé Clever Consulting he trabajado en más de 500 proyectos cuyos promotores no eran desarrolladores. Algunos han tenido éxito empresarial en su aventura y otros no, pero ni uno solo ha tenido éxito en su primera contratación de un perfil técnico, y los que han acabado teniéndolo no ha sido con nada más sofisticado que aplicando el método de prueba y error.

Para acertar en la contratación de un informático algunos han necesitado dos intentos, otros cuatro, y otros lo han dado por imposible.

El libro y la película del mismo título, Los Blandings ya tienen casa, son la mejor explicación de por qué un proyecto sólo puede ser exitoso si cuenta con una buena dirección.

Además, porque estas empresas tampoco supieron valorar objetivamente el trabajo de su equipo de desarrollo, han necesitado meses o años en darse cuenta de su error. Imagina el dinero desperdiciado que eso supone (incluso puedo mencionar a algunas empresas que todavía hoy no son conscientes de que su(s) desarrollador(es) les están tomando el pelo).

El motivo más frecuente de error en la contratación de desarrolladores es que ante la incapacidad de evaluar los conocimientos técnicos de los candidatos, el proceso de selección se reduce a elegir a un conocido, a un recomendado por un conocido, o a la persona que más simpática ha caído de entre varias que decían saber programar.

Feria abarrotada con cientos de personas en traje que llenan pasillos, y salas donde se hacen presentaciones.

Imagen 7.2. Por motivos que no alcanzo a comprender, en España, lo más común es que los programadores sean seleccionados por personas sin conocimientos técnicos (lo siento por el topicazo, pero en otros países es diferente, y esta labor es desempeñada por expertos en contratación de perfiles técnicos).
En la imagen superior, feria de trabajo en Japón, un concepto habitual en muchos países. En mi caso, por cada programador que he contratado he tenido que analizar a unos 300 candidatos.
(Imagen bajo licencia CC-BY-2.0 cortesía de Dick Thomas Johnson.)

Tendemos a pensar que nuestros conocidos, familiares, personas cercanas o personas que nos caen bien cuentan con una competencia profesional por encima de la media. Siento desilusionar a muchos, pero la incompetencia profesional de aquellos que nos rodean –por muy amigos que sean– se sitúa en el mismo ratio que la de aquellos que no conocemos, y sólo podemos juzgarla a través de un método científico y riguroso.

Si la mayoría de la gente es mediocre en su trabajo, estadísticamente, la mayoría de nuestros amigos, vecinos, familiares y gente que nos cae súper simpática, serán mediocres en su trabajo.

Herramientas de trabajo

Antes de empezar con un desarrollo, el director de proyectos debe elegir las herramientas, tecnologías y metodología de trabajo que mejor le permitan llevar a cabo todas las tareas mencionadas hasta ahora, lo que incluirá decidir cosas como:

  • Con qué herramienta se controlará la evolución del proyecto, asignación de tareas, y consumo de recursos, es decir, la elección y uso de un PMS, siglas de “Project Management Software“, lo que se traduce como “Software de Gestión de Proyectos“. Teamwork o Basecamp son dos populares PMSs, éste último desarrollado por David Heinemeier Hansson, el creador del Rails, el framework para el lenguaje de programación Ruby.
  • Cómo se documentará el código. En el Capítulo 3. ¿Qué es el HTML y el CSS? contaba que el código fuente se puede (y debe) comentar (no sólo el código HTML se puede comentar, también se puede comentar el código CSS o el de cualquier lenguaje de programación). Los comentarios en el código (y opcionalmente otra documentación adicional) deben contener explicaciones para facilitar el trabajo en el futuro o de otros desarrolladores. No soy partidario de generar documentación adicional a los comentarios de código, pues ésta nunca se actualiza conforme se va modificando el software, lo que produce más problemas de los que soluciona.
  • La elección de un sistema de control de versiones, lo que entre otras cosas permitirá que varios desarrolladores trabajen en paralelo sin riesgo de perjudicar el trabajo de sus compañeros, facilitará la detección de errores, permitirá medir el aporte de cada desarrollador o recuperar versiones antiguas de un software. El sistema de control de versiones más popular es git, co-desarrollado por Linus Torvalds, el padre de Linux.

    A la izquierda, el logotipo de Github, que consiste en la ilustración de un gato negro de ocho patas sobre un charco de agua azul, y a la derecha la captura de pantalla de la sección "Quiénes somos" del sitio web de Clever Consulting en la que se muestra como un programador, Víctor Falcón, incluye como parte de su descripción un icono de Github que enlaza a su perfil en dicha plataforma.

    Imagen 8.3. Github es tan popular entre programadores que algunos publican un enlace a su perfil en ésta plataforma junto a los enlaces de sus perfiles en redes sociales.

Gráfica que indica el número de modificaciones o añadidos en una proyecto desde el 7 de agosto de 2011 al 10 de julio de 2015. Debajo otros dos gráficos con gráficas del mismo tipo pero únicamente de los dos programadores que más han contribuido al proyecto.

Imagen 8.4. Captura de pantalla de GitHub donde se ven las contribuciones de distintos programadores al software libre WooCommerce.

GitHub es una aplicación web de control de versiones basada en Git. Servicios como el ofrecido por GitHub o Bitbucket permiten que varios programadores trabajen a la vez en un mismo proyecto, tener control sobre la evolución de un código fuente, o compartir códigos fuente entre una comunidad mundial de programadores.

Apache Subversion (abreviado como SVN), ya en desuso, es otro sistema de control de versiones.

  • Implantar una metodología de testeo del software que se va desarrollando, lo que incluirá la implementación de tests automatizados y manuales para detectar bugs, valorar y mejorar la compatibilidad entre navegadores, el rendimiento, la accesibilidad por personas con discapacidad, la seguridad, etc. Existen multitud tipos de pruebas automáticas que se pueden programar así como herramientas para hacerlo.

    Terminal de Mac OS X en la que aparece un listado de tareas en inglés, que debe permitir una aplicación web. Las tareas que se pueden completar están en verde y las que no en rojo.

    Imagen 8.5. Pantalla de los resultados de una batería de tests automáticos sobre una aplicación web. Los mensajes en verde indican las pruebas superadas sin incedencias y los rojos las pruebas que han acabado en error.

  • Establecer procedimientos para el control de la calidad del código fuente que se desarrolla. Uno peculiar –y poco práctico– es el pair programming o programación en pareja. Cuando se desarrolla software en pair programming un programador escribe código mientras otro le observa –supervisando su trabajo–, y cada cierto tiempo se turnan en sus roles. Otro método más eficiente para controlar la calidad del código fuente es que antes de publicar un cambio de código éste deba ser aprobado por un superior.

    Dos programadores trabajando en "pair programming". El de la izquierda escribe código mientras el de la derecha observa.

    Imagen 8.6. Un programador que escirbe código comenta algo con su compañero, que observa cómo el primero programa.(Imagen bajo licencia CC BY-SA 3.0 cortesía de Vajrapani666.

  • Cómo se hará el seguimiento de bugs, lo que se conoce como bugtracking. La detección, seguimiento y resolución de bugs puede resultar compleja en grandes desarrollos, y por eso existen herramientas como bugzilla, aunque también se pueden emplear métodos tan simples como compartir una hoja de cálculo.

    Página web que además de un buscador y botones de navegación como "Home", "New", "Browse", "Help", "Reports", "Product Dashboard", "New Account" o "Login", contine una tabla que lista 500 fallos, dónde se encuentran, a qué producto afectan, un número de referencia, una descripción de en qué consisten y su estado.

    Imagen 8.7. Captura de bugzilla, aplicación web creada por la fundación Mozilla (los autores del navegador Firefox), para registrar bugs. Además, existen libros que enseñan las mejores prácticas para encontrar bugs, gente que ofrece sus servicios de detección de bugs, debuggers profesionales de videojuegos, a quien le lleva cuatro meses localizar un retorcido bug o un bug que obliga a reiniciar el Boeing 787 cada 248 días para que siga funcionando.

  • Elegir las herramientas y plantear la metodología de trabajo que permitan publicar nuevas versiones de software de la manera más automatizada posible. Es lo que se conoce como Continuous Delivery o CD, lo que se traduce como “Entrega Continua”.
  • Por último, todo lo que ocurre alrededor del proyecto, desde cuántas reuniones se mantienen, hasta cuándo, quiénes, y cómo participan ellas, es algo que también repercute en los resultados del proyecto y forma parte de la metodología de trabajo.

Todas estas labores no tienen por qué recaer en una sola persona ni todos los proyectos requieren de una dirección de proyectos tan exhaustiva como la descrita en este apartado. No tiene la misma complejidad un sitio web que se limita a presentar un producto y un método de contacto que el sitio web corporativo de una gran empresa, la construcción de una red social, o la programación de un sistema operativo para un avión.

Metodologías de trabajo en el desarrollo de software

Existen tantas metodologías de trabajo y de gestión de proyectos de software como programadores alguna vez han existido; y tantas versiones de dichas metodologías como personas se hayan cruzado con estos programadores.

Una de las metodologías más populares, y de la que deriban muchas otras, es el “desarrollo ágil de software” (agile software development en inglés).

Desarrollo ágil

El desarrollo ágil defiende la creación de software de manera cíclica e incremental.

Cíclica porque defiende trabajar en iteraciones cortas (días o semanas), de un tiempo prefijado (por ejemplo dos semanas), que concluyen con la entrega de una nueva y mejorada versión del software.

Incremental porque considera (muy acertadamente) que es imposible conocer los requisitos del software al inicio de un proyecto y se entiende que los problemas y soluciones (y presupuesto) evolucionan durante la programación del mencionado software.

Scrum es una conocida variante del desarrollo ágil.

El Manifiesto por el Desarrollo Ágil de Software nació en 2001, aunque las primeras ideas del desarrollo incremental aparecieron en 1957. Algunos de los principios más importantes del manifiesto son:

  • Se valorará a las personas y sus relaciones por encima de los procesos y las herramientas.
  • Se valorará el software en funcionamiento por encima de la documentación, lo que quiere decir que la presentación de documentación al cliente no debe ser una forma de medir el avance del proyecto.
  • Se valorará la colaboración del cliente por encima de la negociación del contrato. Se asume que ni cliente ni programador tienen la capacidad de definir los requisitos al inicio del proyecto, por tanto, se requiere la involucración del cliente durante el proceso del desarrollo.
  • Se valorará la adaptación al cambio por encima del seguimiento de un plan. El cambio de requisitos será bienvenido.

Alabanzas al desarrollo ágil

En la teoría, la filosofía del desarrollo ágil es genial. Me creas o no, no existe humano capaz de prever cómo debe ser su software hasta que lo ve en funcionamiento y siendo utilizado por los usuarios finales. Incluso en el sitio web corporativo más sencillo del mundo.

Da igual cuánto tiempo hayas dedicado a pensar en ello, durante la marcha te das cuenta de cosas en las que no hubieras reparado aunque hubieras estado cien años pensando antes de empezar. Inviertes ingentes cantidades de tiempo en implementar funcionalidades que nadie usará, en prevenir problemas que nunca ocurrirán y, aun así, el día que publicas tu primera versión los usuarios te dan mil ideas geniales que nunca se te habían pasado por la cabeza.

Eso por no hablar de la cantidad de proyectos que nacen para solucionar un problema que ni siquiera existe (el libro El Método Lean Startup aborda en extensión cómo evitar este error).

He visto a emprendedores desperdiciar años de su vida por negarse a aceptar que el resto del mundo no desea sus “geniales” ideas. En una ocasión trabajé con una empresa que no vendió una sola unidad de su producto durante tres años. En otra ocasión un emprendedor me contrató para que le ayudara a valorar, a través de un estudio de mercado, si su producto tendría éxito. El cilente se enfadó conmigo porque los resultados no fueron de su agrado.

Una start-up o startup es una empresa joven y –habitualmente– de base tecnológica, de la que se espera un crecimiento exponencial. Hewlett-Packard, GoogleFacebook o twitter, todas fueron startups de éxito. En un sentido más amplio es habitual usar este término como sinónimo de “empresa emergente”.

Humilde construcción de madera con puertas en color verde oscuro.

Imagen 8.8. En este garaje se fundó, en 1939, la primera startup, hewlett-packard, con un capital de 538 $. Hoy es lugar de peregrinación en Silicon Valley.
Cuando crearon hewlett-packard, sus socios, Bill Hewlett (1913—2001) y Dave Packard (1912—1996), echaron a suertes, lanzando una moneda al aire, cual de sus apellidos iría primero en el nombre de la compañía.

Una muestra representativa es el conjunto con suficiente número de individuos como para que el resultado de un estudio estadístico resulte fiable. Tú y tu círculo de amistades y familiares no sois una muestra suficientemente representativa de ningún mercado.

Por todo esto el desarrollo ágil es tan estupendo, porque solventa un problema inherente al desarrollo de software. Sólo tiene un inconveniente.

Crítica al desarrollo ágil

El desarrollo ágil requiere que el promotor del proyecto se crea que no sabe lo que quiere, que cambiará de idea cada día que pase, y que sea consciente de que el desarrollo de tecnología es infinitamente más complicado de lo que él percibe. Por si esto fuera poco también tiene que aceptar que hasta que acabe el proyecto no sabrá cuánto va a invertir. Pero eso, amigo mío, no ocurre nunca. Y no me extraña.

El desarrollo ágil le soluciona todos los problemas al director del proyecto o al proveedor de desarrollo web, pero ninguno al cliente. Al menos ninguno percibido por el cliente, que son los únicos problemas que importan en la venta, también en la venta de proyectos de software.

Por contra, el desarrollo ágil introduce otros problemas al cliente. Problemas en forma de incógnitas, es decir, el peor tipo de problemas con los que un cliente se puede encontrar en un proceso de compra. Quién compra algo que no sabe cuánto le va a costar, quién quiere contratar un proyecto sin saber lo que va a incluir. El desarrollo ágil está diseñado por un departamento de desarrollo que no preguntó al departamento de ventas. Tal y cómo está planteado, sólo aquellos con experiencia en tecnología y conocimientos técnicos avanzados querrían contratar un proyecto con estas condiciones. El problema está en que las personas y empresas con ese perfil no constituyen la mayor parte del mercado.

Aunque trabajo para acercarme a ella cada día, todavía no sé cuál es la metodología de trabajo óptima, sólo sé que dicha metodología tendrá en cuenta que los clientes no quieren entregables o ideas ejecutadas a medias. Probablemente los clientes no quieren ni siquiera los proyectos. Lo que los clientes quieren es estar tomando piña colada en una isla paradisiaca gracias a que sus ideas se han convertido en una fábrica de billetes. La metodología ágil falla miserablemente en transmitir esa visión al cliente.

Las metodologías de gestión de proyectos ignoran la labor comercial, algo que sin embargo es el primer paso de todo proyecto.

Uno de los autores del manifiesto ágil reconoce el fracaso del desarrollo ágil en un artículo con ese título, pero es uno de los comentarios del artículo el que da en el clavo con el motivo:

“El único “proceso” que he visto que funciona es “tener a alguien bueno al cargo”. […] ni siquiera importa si [esa persona] tiene formación técnica.

El mejor director de proyectos con el que he trabajado en mis 16 años de experiencia era una mujer sin formación técnica, pero que estaba dispuesta a profundizar en el trasfondo técnico de las cosas. [Ella] aprendió SQL y a programar tests que le permitieran valorar la calidad del código que supervisaba. Cuando le conocí llevaba cuatro años y ya tenía una impresionante habilidad estimando cuánto tiempo requería ejecutar una tarea, y si [en un proyecto] las cosas iban bien o mal.

Si tienes a alguien bueno al cargo que llama a su sistema “ágil” parecerá que el desarrollo ágil funciona. Si tienes a alguien malo al cargo que llama a su sistema “ágil”, entonces parecerá que el desarrollo ágil apesta. Lo mismo ocurrirá si llaman a su sistema “XP” o “Deep Review” o lo que sea.”

Subcontratar programadores: nunca más

Con el objetivo de ahorrarse la dirección de proyecto o con la creencia de que bajo su supervisión física la dirección del proyecto es más óptima, más de un cliente me ha solicitado que uno o varios miembros de Clever Consulting se desplacen a sus instalaciones para trabajar desde allí. Otros creen que la presencia de un superior es sinónimo de dirección.

Las pocas veces que hemos aceptado nos hemos arrepentido al poco tiempo. El cliente quedó insatisfecho porque el proyecto no se ejecutó con los requisitos y costes que él había estimado y yo he perdido dinero porque he prestado un servicio deficiente con un consumo de recursos mayor al estimado y necesario.

De la misma forma que un stradivarius no convierte a alguien sin formación musical en un buen violinista, un desarrollador o un equipo de desarrollo sin un buen gestor de proyectos de software sólo acabará en un proyecto de baja calidad o inacabado.

Viñeta cómica en la que una persona de pie conversa con una programadora sentada a la mesa con un ordenador.

Imagen 8.9. En los sesenta, el científico estadounidense Marvin Minsky, encargó a dos de sus estudiantes que pasaran el verano escribiendo un programa que identificara objetos en una imagen. Pensó que habrían finalizado al final del verano. Medio siglo después todavía nadie lo ha conseguido.

¿Cuál es el mejor lenguaje de programación o la mejor tecnología? (Título alternativo: Si te preocupa la tecnología lo estás haciendo mal)

Captura de githut.into con listado de lenguajes de programación ordenados por número de proyectos activos en GitHub. El más popular es JavaScript, seguido de Java, Python, CSS (que no es un lenguaje de programación), PHP, Ruby, C++, C, Shell, C#, Objective-C, … y la lista continúa en la página web githut.info.

Imagen 8.10. El sitio GitHut mantiene un ranking de popularidad, según varios criterios, de lenguajes de programación más usados en proyectos publicados en GitHub.Como no puede ser de otra forma, el lenguaje más popular es JavaScript. Como ya sabes, esto se debe a que JavaScript es necesario en cualquier proyecto de desarrollo web independientemente de qué otro lenguaje de programación se use.

Si te estás haciendo esta pregunta lo estás haciendo mal.

Cuando contratas a alguien lo haces para que te acerque a unos objetivos o te solucione un problema. Que lo haga con el uso de una u otra tecnología –incluso que lo haga sin usar la tecnología en absoluto– es lo que menos te debería importar.

Quédate con esto: no existe una forma correcta de programar. A diferencia de lo que ocurre en otras áreas profesionales, en informática no existe una metodología de dirección y ejecución de proyectos claramente definida, universalmente aceptada e indiscutiblemente superior al resto. Sólo existen bandos que defienden una u otra tecnología o forma de trabajar basándose en aquello que han probado y donde han tenido una mejor experiencia.

Hay dos tipos de lenguajes de programación: aquellos que todo el mundo critica y aquellos que nadie usa.

La informática es una disciplina tan joven y cambiante que cada día nacen opciones que prometen acabar con las desventajas de sus predecesores, y con cada novedad aparece alguien dispuesto a convertirse en profeta de esa innovación. Al menos durante el tiempo que tarda en aparecer la siguiente.

Cuando alguien ve algo como perfecto pierde la capacidad de imaginar una alternativa mejor.

¿Recuerdas lo de “Se valorará a las personas y sus relaciones por encima de los procesos y las herramientas”? El éxito o fracaso de un proyecto depende de las personas que lo ejecutan, no de las tecnologías que emplean, porque si el equipo es bueno éste habrá elegido tecnologías suficientemente solventes.

De la misma forma que no juzgarías un armario a medida por las herramientas que usó el carpintero, no tiene sentido juzgar un software por las tecnologías con las que se programó.

Dibujo: Cerebro > Herramientas (llave inglesa)

Imagen 8.11. En la contratación de servicios de alta cualificación, lo importante no son las herramientas, sino la capacidad de quienes las usan.

Lo que aporta valor es el carpintero que construye el armario, no la marca de martillo que usa. Si el carpintero es bueno elegirá herramientas con las que sea capaz de producir el mejor armario posible. Mientras tanto, otro carpintero hará un desastre con las mismas herramientas, y otros serán dignos competidores del buen carpintero aunque usen herramientas ligeramente distintas.

En tecnología –y en cualquier aspecto de la vida–, los apóstoles de algo limitan sus posibilidades de mejora. Olvidan que la tecnología es el medio para conseguir tu fin, pero no son tu fin. Son los agnósticos tecnológicos, con visión de negocio y que se preocupan de rodearse de gente con talento, los que triunfan.

La tecnología no es lo importante. La tecnología es lo que usamos para conseguir lo que sí es importante. —Halt and Catch Fire.

Cuando la única herramienta que se tiene es un martillo todos los problemas tienen forma de clavo.

Busca un proveedor con el que te sientas a gusto, conviértelo en tu asesor de confianza y tú dedícate a vender tu idea al mundo. Cómo acertar en la elección del proveedor es otra pregunta, de más difícil respuesta, y el motivo por el que he escrito este libro.

“La mayoría de retos técnicos son triviales en comparación con cómo conseguir que la gente use tu producto.”

“La solución a muchos, pero que muchos, problemas, no es técnica. Eso no evitará que la gente siga intentando solucionarlos a través de aplicaciones móviles.”

“Cualquier programador puede pillar una nueva tecnología en unas pocas semanas.”

Las anteriores tres citas son del artículo del programador Ben Dixon titulado What I’d tell myself about startups if I could go back 5 years (Qué me diría acerca de las startups si pudiera volver 5 años atrás).

Excusas que usarás para intervenir en la elección de la tecnología

Sé que incluso si has asentido mientras leías este capítulo, en el momento de la verdad es probable que no puedas evitar hacer de la tecnología tu fin –no tu medio– y pretendas aportar tu granito de arena en su elección, y como en los últimos años he vendido cientos de proyectos de tecnología también sé que para justificarlo usarás una o varias de las siguientes excusas:

“En el pasado ya probé con esta tecnología/metodología y el proyecto salió mal.”

También probaste con programadores morenos (o rubios, o pelirrojos) y no por ello vas a prescindir de ellos en este intento. ¿Qué pruebas tienes de que tu anterior proyecto salió mal por la elección tecnológica y no por quienes la usaban?

“Mi amigo me ha recomendado otra tecnología/metodología.”

Dame una razón lógica por la que alguien al que no has contratado y que no va a ejecutar tu proyecto deba tener más poder de decisión en la elección de la tecnología que las personas a las que sí vas a pagar para usarla. ¿Acaso no contratas a alguien precisamente para que tome, entre otras, esta decisión? Además, como ya hemos visto, que alguien sea tu amigo no lo convierte en un buen técnico.

“Quiero que sea compatible con nuestros sistema actuales.”

Este motivo no necesariamente condiciona la elección de la tecnología y si es así será tu proveedor (si es bueno) el que te lo dirá antes de elaborarte una propuesta. De nuevo, con un buen compañero de viaje no habrá problema, y con uno malo estás condenado, use la tecnología que use.

“Quiero un proyecto que pueda crecer, seguro, que pueda gestionar yo mismo, …”

Nunca he conocido a alguien que quiera un proyecto que no cumpla con las características previas. Si no es este, ¿qué otro criterio crees que un buen proveedor tiene en cuenta para elegir una u otra tecnología?

La única forma de acertar con la elección de la tecnología es contar con un buen proveedor o equipo. Si no puedes confiar a ese nivel en tu proveedor o equipo, entonces el problema es otro y no deberías trabajar con ellos en primer lugar.

Contratar a un equipo de desarrollo y no morir en el intento

Dudo que exista un sector con una tasa de fracaso e insatisfacción mayor que la del sector de la consultoría tecnológica. Como no existen barreras de entrada cada día aparecen un nuevo puñado de empresas. Que en seis meses hayan desaparecido es lo de menos, entre tanto habrán disgustado a algún cliente, arruinado a algunos emprendedores y quemado un poquito más el mercado.

Anuncio pegado en una pared de la calle en dice: "Tu Página Web! Desde 125 euros Llámanos 657 581 413 TePublico.es"

Imagen 8.12. El del desarrollo web es un sector sin barreras de entrada, cualquiera puede decir que presta servicios. Ese es uno de los motivos por los que las probabilidades de fracasar en su contratación son tan altas.

He elaborado una lista de características que cualquiera puede juzgar sin necesidad de conocimientos técnicos avanzados, y que la experiencia me ha demostrado que tienen una alta correlación directa con la calidad de una consultora tecnológica:

  1. ¿Se interesan por tu negocio?, ¿te hacen muchas preguntas?, ¿te hacen preguntas que ni siquiera te habías planteado? Si la respuesta a estas preguntas no es un indiscutible “Sí”, ni siquiera tiene sentido que solicites una propuesta a este proveedor. Si un posible proveedor no tienen dudas de tu planteamiento lo más probable no es que tu planteamiento sea perfecto, lo más probable es que tu proveedor sepa lo mismo que tú, y ¿para qué ibas a contratar a alguien que supiera lo mismo que tú? Si eres de los que no les gusta que les pregunten y sólo buscas un presupuesto rápido no vas a tener éxito contratando tecnología.
  2. ¿Entiendes lo que te cuentan?, ¿tiene sentido lo que te proponen? En la respuesta a estas preguntas se encuentra la segunda característica más importante de un proveedor. Jamás contrates a alguien del que no entiendes todas y cada una de sus palabras: en su sitio web, en las reuniones, en la propuesta y en el contrato.
  3. Que te digan a todo que sí tampoco es una buena señal. Eso de que el cliente siempre tiene la razón no se cumple en el mercado de la consultoría (y probablemente en ningún mercado). Parte del trabajo de un proveedor es poner los pies en la tierra al cliente, formarle, explicarle, proponerle mejores opciones, trasmitirle su experiencia de proyectos anteriores …
  4. Formación del equipo en distintas áreas. Es imposible ejecutar un proyecto de calidad sin profesionales en distintas disciplinas (programación, dirección, diseño, redacción … o lo que sea que necesites en tu proyecto).
  5. Visión de negocio: ¿tu potencial proveedor se limita a establecer la definición técnica o aporta algo en la visión de negocio?
  6. Discurso tecnológico: ¿hablan mucho de tecnología?, ¿cómo de defensores son de ciertas tecnologías?, ¿son rigurosos en el uso de vocabulario técnico? (después de leer este libro esta última pregunta la puedes juzgar a la perfección). Si “Sí”, “Mucho” y “Poco” son las respuestas a estas preguntas, sal corriendo.
  7. ¿Ofrecen de todo? No me refiero a que la empresa de desarrollo web trabaje con todos los sectores, que es lo normal, sino a que además de diseño y desarrollo ofrezcan servicios que van desde la gestión de redes sociales a la asesoría legal, el alojamiento, la reparación de ordenadores o la imprenta. Si la respuesta es que sí, activa la alarma en tu detector de charlatanes.
  8. Calidad del diseño: juzga el diseño del propio proveedor, el de su sitio web y el de su material corporativo y, por último, juzga el diseño de sus clientes. Pero no busques en sus clientes lo que tú quieres, eso no tendría ningún sentido en una empresa que se dedica a hacer proyectos a medida. Juzga únicamente su calidad y si está de tendencia. Importante: si el arte y el diseño nunca te han llamado demasiado la atención, ignora este punto.

“La moda es lo que parece bonito hoy pero feo más tarde; el arte puede parecer feo al principio pero se hace bonito más tarde.” —Steve Jobs.

  • ¿Te parece barato? Asumo que a estas alturas no debo explicar por qué una propuesta barata es indicativo de baja calidad.

¿Crees que contratar profesionales es caro? ¡Prueba a contratar a aficionados!

Una vez un cliente potencial rechazó mi propuesta porque según me dijo había tenido una idea para hacer su proyecto de manera más económica: “contratar” becarios.

Un método infalible para fracasar en la contratación de un proyecto de desarrollo de software

Lo que el cliente quiere, lo que el cliente contrató la vez anterior, y lo que el cliente explica que quiere, son cosas distintas.

El proveedor entiende una cosa, el cliente no suele contar con suficiente presupuesto, y a veces cuenta con un asesor "experto" que cree que se puede hacer una solución maravillosa y casi gratis.

Acabado el proyecto el cliente contará a sus jefes y clientes que ahora tiene la solución definitiva, pero al final, acabará usando una pequeña fracción de sus posibilidades, y todo se hubiera solucionado con un proyecto más humilde.

Imágenes 8.13, 8.14, 8.15, y 8.16, respectivamente. Imagina hasta que extremo son habituales los problemas en la gestión de proyectos como para que existan tiras cómicas como la de arriba e incluso webs para hacerte la tuya propia.
(Imágenes bajo licencia CC BY 3.0 cortesía de Project Cartoon).

El procedimiento es sencillo. Ni siquiera hace falta que sigas todos los pasos que expongo a continuación, con que sólo apliques uno o dos será suficiente para contratar a una pésima empresa de desarrollo web:

  1. No aprendas nada de tecnología antes de iniciar el proceso. Ese no es tu problema. Para eso contratas a alguien. Además, aprender cosas nuevas y actuales es una pérdida de tiempo.
  2. Si tienes empleados delega la búsqueda de proveedores potenciales a alguien que no tenga poder en la decisión de compra, que no tenga conocimientos técnicos, ni experiencia en el proceso comercial de la empresa. Ideal si es un community manager.

    Lo siento por los afectados, pero alguien con un máster o con un cursillo en redes sociales, community management o marketing online, no es un director de proyectos.

  3. Localiza a todas las empresas de desarrollo web que puedas (a partir de cuatro ya es buen número).
  4. Escribe un email genérico a todas las empresas que hayas localizado en el que incluyas una vaga descripción de tu proyecto y, a ser posible, un documento adjunto. Cuanto más largo el documento y más tecnicismos uses, mejor. Que no cuentes con un desarrollador web para elaborar el documento es lo de menos, que lo hagan los de marketing.
  5. Cuando te pregunten cuánto deseas invertir, ¡no lo digas! Sólo te lo preguntan porque han visto que no tienes ni idea y quieren cobrarte lo máximo posible. Piensa que en programación existen soluciones paquetizadas con precios preestablecidos para cualquier necesidad.
  6. Hazte con tantos presupuestos como sea posible. Por supuesto, descarta a los que antes de elaborarte una propuesta te soliciten más información o a los que deseen una reunión. Piensa que si alguien no quiere hacerte una propuesta no es porque tenga mucho trabajo fruto de su buen hacer, o porque quiera elaborarte una propuesta personalizada que te aporte el máximo valor, o porque tu solicitud contenga fallos o dé lugar a dudas; el motivo es que no tienen suficiente interés en su trabajo o que quieren embaucarte con discursos comerciales.
  7. Pídeles que te hagan un diseño. Gratis, claro está. Diles que elegirás al que más te guste. Descarta a los que con su diseño no acierten con lo que tienes en mente. Que no hayan cobrado, y que por tanto no hayan dedicado tiempo a hablar contigo y estudiar tus gustos y tu mercado no debe ser un problema, ¡para eso se dedican a esto! Por supuesto, si alguien no quiere hacer un diseño gratis no se debe a que esa sea una importante parte de su trabajo que requiere un estudio previo, es que no tiene suficiente interés. Descártalo.
  8. Haz un filtro por precio. Elimina a los más baratos y a los más caros, quédate con los intermedios. Eso tiene sentido… ¿no? Ignora las diferencias entre las propuestas, tú ya has dejado claro lo que quieres, si el proveedor no se ha enterado es su problema.
  9. Haz un segundo filtrado. Calcula unos tiempos de entrega de manera arbitraria y descarta a todos los que no se ajusten a ellos.
  10. Si todavía tienes muchas opciones entre las que elegir descarta a todos los que no estén en tu ciudad. Por teléfono, correo electrónico o videoconferencia los desarrolladores no entienden bien las cosas.

    Imagen de un monitor sobre un escritorio en un puesto de trabajo, con una citna azul que cuelga y que contiene el texto "I survived another meeting that should have been an email".

    Imagen 8.17. Hay quien colecciona, a modo de trofeos, cintas como las de la imagen, que dicen “He sobrevivido a otra reunión que debería haber sido un email“.
    (Imagen propiedad y cortesía de BuyOlympia.)

  11. Durante los pasos anteriores ignora las condiciones de pago y los términos legales de las propuestas recibidas, pues seguro que podrás negociarlos más adelante. Es más, si la propuesta no tiene términos legales valóralo como una ventaja.
  12. Reúnete con los proveedores que hayan pasado el filtrado. Si es posible solicita una reunión de un día para otro. Descarta a los que no accedan. No lo tomes como un signo de organización y calidad, en lugar de eso supón que no te quieren. También puedes proponer reunirte en festivo o por la noche.
  13. En la reunión no olvides decir frases como “para nosotros este proyecto es súper importante” o “nos preocupa la calidad por encima de todo”. Si no lo haces lo más probable es que el proveedor te ofrezca mala calidad porque crea que tu proyecto no es importante.
  14. Si tienes la oportunidad di que en el pasado has tenido “muy mala experiencia” con otros proveedores, que ahora ya no te fías “ni de tu madre”. Es una frase muy elegante que no está nada manida.
  15. Da igual que ya tengas un precio encima de la mesa, pídele a tu potencial proveedor que en su presupuesto tenga en cuenta tu anterior metedura de pata (bueno, la tuya no, la de tu anterior proveedor).
  16. Deja claro constantemente que estás hablando con otras empresas de desarrollo. Incluso di qué precios te han ofertado. Por supuesto di precios por debajo de los reales, tu interlocutor no se dará cuenta y es una técnica de negociación muy astuta.
  17. Asegúrate de que no te toman por tonto. Que no te pase como la última vez que dejaste el coche en el taller y te cobraron 300 € por cambiar una bombilla. Di muchos tecnicismos (que los uses correctamente es lo de menos, esto de la informática no es para tanto).
    No descartes ir con un amigo informático a la reunión. La disciplina a la que se dedique tu amigo o su experiencia en desarrollo web es indiferente, nadie se atreverá a jugar con un ingeniero.
    ¿No tienes un amigo ingeniero? ¡No pasa nada! Dí que tú lo eres, y si alguna vez has hecho algo que remotamente tiene que ver con la tecnología, ¡di que en el pasado has hecho muchas webs!

    Cuidado con usar la última palabra de moda. A alguno le ha llevado a pedir algo distinto a lo que quería.
  18. Regatea el precio. Algunos argumentos convincentes son: “en el futuro os vamos a dar mucho trabajo”, “vas a crecer conmigo”, “este proyecto os interesa”, “queremos daros trabajo”, “hay quien lo haría por menos”, “las circunstancias son malas”, “no tengo mucho dinero” o “hoy en día todo el mundo necesita clientes, ¿no?”. Todas estas insinuaciones te proporcionarán una imagen muy atractiva como cliente.
  19. Propón ideas para reducir el precio, una buena es “¿y si un amigo me hace el diseño?”. También puedes poner en duda que el precio presupuestado sea adecuado o correcto. No descartes alarmarte e, incluso, enfadarte.
  20. Para aumentar un poco más tu sex appeal asegúrate de que no estás cogiendo a ningún loco. Para ello, durante la reunión, haz preguntas del tipo: “¿y cómo sé yo que no vais a desaparecer mañana?”.
  21. Dedica semanas a contestar a cualquier email que te envíe un potencial proveedor, pero que eso no te impida insistir en la mucha prisa que tienes, pues para ti los tiempos –a diferencia del resto de clientes– son fundamentales.
  22. No descartes proponer una penalización por retraso (para tu proveedor, ¡no para ti!, en ningún momento supongas que un retraso puede venir por tu parte). Incluso exige reducir los tiempos de entrega. Da por hecho que el tiempo de entrega no se calcula, que cualquier tiempo de entrega es posible.
  23. Ya casi te has decantado por un proveedor. Ha llegado el momento de ignorar los términos de pago que éste te haya propuesto y proponer pagar más tarde y en más plazos. ¿Qué te debería importar a ti que haya clientes en lista de espera que pagan según las condiciones pactadas?
  24. Decántate por el proveedor que te dé los términos de pago más cómodos. No hagas la reflexión de que si hubieras empezado por aquí te hubieras ahorrado –y hubieras ahorrado a otros– semanas de trabajo. Pensar con lógica a estas alturas del proceso no tiene sentido.
  25. Busca la pasta. No tiene nada de malo pedir multitud de propuestas antes de haber conseguido el dinero necesario para contratar el proyecto. Si se da la remotísima posibilidad de que la consigues, procede con el siguiente punto.
  26. Cuando ya tengas claro con quién quieres trabajar remata el acuerdo diciendo al elegido: “te paso con el departamento financiero/de compras para que habléis de los términos de pago”. No te debe preocupar que ya hayáis pactado otra cosa. Si funcionáis así con la empresa que os proporciona la tinta de la impresora, ¿por qué no ibais a hacerlo con la de desarrollo web?
  27. Que tu departamento de compras acuerde pagar las facturas a 30 días. Convencerás si dices: “somos muy buenos pagadores” y “somos una empresa muy solvente”. Si eres un alumno de sobresaliente, una vez que empieces el proyecto, aplica también los siguientes trucos:
    1. Asegúrate de que los de finanzas, en lugar de pagar a los 30 días pactados, pagan a 60 o 90 días.
    2. Si tu proveedor te pregunta por una factura impagada di que eso no es cosa tuya, que hable con “los de finanzas”.
    3. Da orden a “los de finanzas” de que le digan a tu proveedor que ha habido un error en el pago de facturas, en el software de contabilidad o que la persona que hace los pagos está de vacaciones. Hazlo así para todas las facturas. Pagar las facturas debe ser tu última prioridad. Dedícale tiempo a cualquier otra cosa antes que a eso.
    4. Recuerda que las facturas de agosto y diciembre son menos importantes y se pueden pagar más tarde de lo habitual.
    5. De vez en cuando “olvídate” de pagar una factura. Una de cada mil veces el proveedor no se da cuenta. Puede ser tu día de suerte.
    6. Si tu proveedor deja de trabajar por un impago amenaza con demandarle y aprovecha para recordarle que los únicos tiempos importantes son los de entrega.
    7. De vez en cuando puedes negarte a pagar una factura hasta que tu proveedor trabaje un poco más (puedes probar a hacerle lo mismo a tus empleados).
    8. Cuando el contrato ya esté acordado nunca envíes una copia firmada a tu proveedor. Si tu proveedor no te insiste en que lo hagas, mejor.
    9. Por descontado, no debes avisar jamás a los proveedores que has descartado de que ya has tomado una decisión. Si te llaman o te escriben no les contestes, eso es de malísima educación.
    10. No olvides que es mala costumbre pagar la última factura de un proyecto.

 

Tan hilarante como pueda sonar, todas son experiencias que me han pasado al menos una vez.

La forma adecuada de contratar desarrollo

  1. Decide qué quieres, asegúrate de que lo quieres ya y cuánto puedes invertir en ello. Si tienes dudas, contrata a un asesor que te ayude con este primer paso.
  2. Decide la cantidad que deseas invertir en base a lo que tienes ahorrado o al presupuesto asignado por tu empresa. No lo hagas en base a lo que crees que tendrás al mes que viene, ni al crédito que pedirás, ni en base a la subvención que estás seguro que te concederán, ni a lo que sin lugar a dudas te querrán dar cientos de inversores cuando escuchen tu idea. No. Nada de eso. Sólo en base al dinero que puedes tocar.
  3. A través de internet, ferias, revistas o conocidos localiza a 1, 10, 100 o 100 millones de empresas de desarrollo.
  4. Lee los sitios web de todos ellos.
  5. Entrevístate en persona o por videoconferencia con las dos o tres empresas de desarrollo cuyos mensajes más te convezan y mejor entiendas.
  6. Diles, con un lenguaje natural, qué deseas, no cómo; tu objetivo de negocio. Sé transparente y sincero. No les envíes ningún documento de más de media página. Diles cuánto deseas invertir y elige al proveedor que proponga el planteamiento más convincente.
  7. En caso de que ninguno te genere la suficiente confianza, entrevístate con más proveedores. Tantos como necesites hasta encontrar uno en el que confíes.

    Alguna vez he visto a un cliente perder la paciencia durante la programación de su proyecto. El motivo es que el cliente no percibe ningún avance puesto que no tiene conocimientos para entender código fuente, que es lo único sobre lo que puede observar una evolución en esta fase.

    Por motivos como éste es tan importante que el cliente tenga confianza incondicional en su proveedor, además de hacer lo posible por entender lo suficiente de tecnología y gestión de equipos como para mantenerse tranquilo en los periodos en los que no percibe avances.

  8. Valora la organización de los proveedores, su mensaje, su accesibilidad, su interés, su diseño. No valores chorradas como si viven en tu ciudad, si te hacen un diseño gratis, si han trabajado en tu sector o si acceden a reunirse de un día para otro. O más bien, valora negativamente cosas como las dos últimas. Si has leído hasta aquí, aunque no seas consciente de ello, ya sabes valorar las capacidades de un proveedor o perfil técnico bastante mejor que la mayoría de empresarios y directivos del mundo.
  9. Una vez hayas dado con un proveedor de confianza pídele que te elabore una propuesta formal. Sólo solicitarás una propuesta cuando ya hayas elegido proveedor. Lo que quieres comparar son personas e ideas, no documentos. Tampoco compares precios, esos los estableces tú.
  10. Pregúntale a tu proveedor todo lo que no entiendas acerca de la propuesta. Asegúrate de que todo es correcto y que no echas nada en falta. Si algo en la propuesta te hace desconfiar, vuelve a empezar; si no, continúa.
  11. Firma la propuesta.
  12. Colabora activamente durante el desarrollo del proyecto. Contesta ágilmente a los mensajes de tu proveedor y facilítale la información que te solicite.
  13. Trata a tu proveedor con amabilidad y valora su trabajo, eso le mantendrá motivado.
  14. Paga tus facturas a tiempo, sólo de esa forma podrás esperar la misma diligencia en el trabajo de tu proveedor.
  15. Aporta tu conocimiento del mercado y del negocio, escucha y acepta las recomendaciones de tu proveedor. Delega en tu equipo y delega en tu proveedor.

Si ejecutas todos los pasos explicados en este apartado lo único que puede ocurrir es que las cosas salgan bien.

Aline Lerner, experta en reclutación de perfiles técnicos, analizó los currículums que había procesado durante un año y concluyó que el mejor indicador de si un candidato va a ser elegido para un puesto de trabajo, por encima de sus estudios o experiencia, es el número de errores ortográficos en su currículum (a menos errores mayor probabilidad de ser contratado), lo cual tiene mucho sentido, porque es un reflejo de muchas de las habilidades que necesita un buen programador, como rigurosidad o atención al detalle.


Resumen

En este capítulo pretendo convencerte de que la dirección de proyectos no sólo no es trivial sino que es la responsable de la calidad del proyecto resultante, que un buen proyecto empieza con una buena contratación, que una buena contratación empieza con una conversación y que una mala contratación es irreparable.

Pero este es sólo el primer paso hacia la gloria. El éxito de un proyecto empieza, pero no acaba, en su contratación. Te guste o no, tú eres una parte importante del equipo de dirección de proyectos y por eso debes aprender las Más de 100 ideas para mejorar tu proyecto.