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

Capítulo 8

Tu próximo trabajo: director de proyectos.

En este capítulo es una introducción a la dirección de proyecto, y en él te contaré…

  1. Cuáles son las tareas del director de proyectos
  2. Lo difícil que es contratar desarrolladores web
  3. Qué herramientas usa un director de proyectos
  4. Qué es la documentación de un software
  5. Qué es el control de versiones
  6. Que existen tecnologías para automatizar el testeo de un software
  7. Cómo controlar la calidad del código fuente
  8. Metodologías de trabajo como el desarrollo ágil y por qué ninguna funciona
  9. Por qué subcontratar desarrolladores puede ser el peor de los errores
  10. Por qué si la tecnología con la que se construirá tu proyecto te preocupa, lo estás haciendo mal
  11. Por qué no debes pedir consejo a tus amigos informáticos
  12. Cómo valorar la calidad de un proveedor de desarrollo aunque no tengas conocimientos técnicos
  13. 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, 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. Analizar y definir – consiste en interpretar cada necesidad del promotor del proyecto y definir la manera óptima, a nivel técnico y de negocio, 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 por el que fracasa 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 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. He visto demasiada ocasiones en que los programadores son 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 desilusionarte, pero la incompetencia profesional media de tus amigos es la misma que la de aquellos que no conoces, y sólo puedes 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 al proyecto 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, creador 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, para lo que 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 medio de contacto que el sitio web corporativo de una gran empresa, una red social o el sistema operativo de 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 derivan 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 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 cliente se enfadó conmigo porque los resultados no fueron de su agrado.

Una start-up o startup es una empresa joven 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), lanzaron una moneda al aire para decidir cuál 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 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 más complicado de lo que cree. 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.

Los clientes no quieren entregables o ideas ejecutadas a medias. Bien pensado, los clientes ni siquiera quieren los proyectos. Lo que los clientes quieren es estar tomando piña colada en una isla paradisíaca 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 el primer paso de todo proyecto: la labor comercial.

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 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 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 mera 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 en un buen violinista, un desarrollador sin un buen gestor de proyectos resultará 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. —”Cuando un usuario tome una foto la aplicación debe comprobar si está en un parque natural…”
—”Claro, una conuslta a un sistema de información geográfica. Dame unas pocas horas.”
—”…y comprobar si en la foto aparece un pájaro.”
—”Necesitaré un equipo de investigación y cinco años.” En informática, es difícil explicar la diferencia entre lo fácil y lo prácticamente imposible.
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 los lenguajes de programación más usados 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 debe 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, otro carpintero hará un desastre con las mismas herramientas y otros serán dignos competidores usando herramientas 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 son citas 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

Incluso si has asentido mientras leías este capítulo es probable que en el momento de la verdad  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 también sé que para justificarlo usarás algunas 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 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. 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 elaborar 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 el de la consultoría tecnológica.

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 preguntas que ni siquiera te habías planteado? Si un posible proveedor no tiene 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 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. Formación del equipo en distintas áreas. Es imposible ejecutar un proyecto de calidad sin profesionales en programación, dirección, diseño, redacción… o lo que sea que necesite tu proyecto.
  4. Visión de negocio y discurso tecnológico: ¿tu potencial proveedor aporta algo en la visión de negocio?, ¿habla mucho de tecnología?, ¿cómo de defensor es de ciertas tecnologías?, ¿es riguroso en el uso de vocabulario técnico? (después de leer este libro esta última pregunta la puedes juzgar a la perfección). Si “No”, “Sí”, “Mucho” y “Poco” son las respuestas a las estas preguntas, sal corriendo.
  5. ¿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.
  6. Calidad del diseño: no busques en sus clientes lo que tú quieres, eso no tiene ningún sentido en una empresa que hace proyectos a medida. Juzga su calidad estética, pero si el diseño nunca te ha llamado la atención, ignora este punto, o también puedes iniciarte en el diseño con los documentales de Gary Hustwit Helvetica (2007), Objetified (2009) y Urbanized (2011).

    “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.

  7. ¿Te parece barato? 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!

La forma adecuada de contratar desarrollo

  1. Decide qué quieres y cuánto puedes invertir en ello.
  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 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 una página. Diles cuánto deseas invertir y elige al proveedor que proponga el planteamiento más convincente.
  7. Valora el mensaje de tus proveedores, si son formales, su interés. No valores chorradas como si viven en tu ciudad o si han trabajado en tu sector.
  8. Si ninguno te genera suficiente confianza, entrevístate con más proveedores. Tantos como necesites hasta encontrar uno en el que confíes.
  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. Aporta tu conocimiento del mercado u colabora ágilmente cuando tu proveedor te pida algo durante el desarrollo del proyecto.

Si ejecutas estos pasos 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 las habilidades que necesita un buen programador, como rigurosidad o atención al detalle.


Resumen

La dirección de proyectos no sólo no es trivial sino que es la responsable de la calidad del proyecto resultante, un buen proyecto empieza con una buena contratación, una buena contratación empieza con una conversación y una mala contratación es irreparable. Pero este sólo es el primer paso hacia la gloria. El éxito de un proyecto empieza, pero no acaba, en su contratación. Tú eres una parte clave del equipo de dirección de proyectos y por eso debes conocer las Más de 100 ideas para mejorar tu proyecto.