El desarrollo de proyectos software es un proceso muy complejo. Existen diferentes enfoques a la hora de planificar las fases del desarrollo, la duración de cada una de estas fases, el modo de dar mayor prioridad a una u otra fase, el número de personas que intervienen y el papel de cada una de estas.
Tanto es así que hace unas décadas surgió el concepto de "Ingeniería del Software". De manera similar a un arquitecto que diseña y planifica la construcción de edificios, un ingeniero de software debe diseñar y planificar el desarrollo de un producto software. De la experiencia y talento del arquitecto depende que un edificio no se desplome, y de éstas mismas virtudes de un ingeniero de software depende que un proyecto termine con el resultado deseado.
Mucho se puede hablar y debatir sobre la gran cantidad de corrientes en la Ingeniería del Software, pero puesto que ni esto es una clase universitaria ni yo profesor, lo que os voy a contar es mi experiencia en el día a día del desarrollo de productos de software en Microsoft.
En mi trabajo diario me he encontrado con una diversidad bastante grande de roles, de personas con especialidades diferentes en el ámbito de la ingeniería del software. El abanico va desde personas cuya virtud radica en unos profundos conocimientos que les hacen aptos para el diseño de proyectos (Arquitectos de software), otras cuyo punto fuerte radica en la planificación del proceso para construir lo que el arquitecto ha diseñado (manager), el "programador" que se encarga de convertir esas ideas en código para hacer realidad el software (lo que por aquí se conoce como Software Development Engineer, o de forma abreviada, SDE), el tester que se encarga de coger ese código desarrollado por el programador y someterlo a duras pruebas para asegurarse de la calidad del mismo, encontrar fallos y coordinarse con el programador para resolverlos...
Como muchos de vosotros ya sabréis, y los que no lo supiérais espero que lo hayáis entendido a través de mi explicación, el desarrollo del software es un proceso largo, complejo y que involucra a personas con perfiles muy diferentes. Ante esta dificultad sólo cabe una cosa: UNIÓN. Hoy más que nunca, y dicho sin el menor ánimo de prepotencia, sino llenándome de orgullo por los compañeros de trabajo que tengo, puedo decir que trabajo en un EQUIPO.
"Informático" es un término muy amplio, que engloba a profesionales de muy diversa índole, no sólo en lo referido al desarrollo software que os he contado antes, sino también en otro tipo de tareas: administradores de bases de datos (DBA's), diseñadores (de los que ya os he hablado en anteriores entradas), desarrolladores de aplicaciones web, administradores de sistemas...
A menudo, estas diferencias son tan acentuadas que cuesta incluso hacerse entender entre unos y otros, hablando sobre un proyecto. Y esta reflexión nos conduce al factor clave en el desarrollo de proyectos: LA COMUNICACIÓN. Escrita en mayúsculas y negrita, aún así debería ser enfatizada mucho más.
El proceso de desarrollo de software requiere de una comunicación clara, precisa y, una cosa muy importante, eficiente. Cada una de las "máquinas" de esta cadena de montaje que es el desarrollo de software debe saber claramente cuál es su función, qué va a encontrar como materia prima para su fase, y qué espera la siguiente fase como resultado de su trabajo. Y lo más importante, de una manera eficiente. El tiempo es algo muy valioso en el desarrollo de software. La informática, y por extensión la tecnología en general, es un campo en constante evolución, de modo que la mínima pérdida de tiempo o retraso no justificado en la creación de un producto, produce un desfase que, finalmente, se traduce en pérdidas económicas importantes...
Para fomentar esta comunicación existen muchos mecanismos, confidenciales o públicos, en Microsoft. Desde el popular correo electrónico, listas de distribución a las cuáles se suscribe todo el grupo de trabajo para recibir emails automáticamente, grandes entornos de desarrollo como por ejemplo Visual Studio, orientados al trabajo en equipo y la coordinación de tareas entre personas con distintos roles dentro del proyecto, herramientas para notificar fallos o bugs en el software... y, por supuesto, las reuniones de trabajo.
En Microsoft, cada edificio tiene unas 15-20 salas de reunión, ¿por qué será?... Efectivamente, hay muchas reuniones. Reuniones con gente con los mismos roles que tienes tú, para hablar sobre tus avances y escuchar los del resto, para resolver en grupo problemas difíciles para uno solo, sesiones de aprendizaje conjunto... Reuniones con gente que ocupa otros roles, para saber qué y cómo lo están haciendo, y aportar tu visión sobre cómo ese proceso o esos objetivos podrían mejorarse. Reuniones con tu manager, como ya comentó Marta en la entrada anterior, para analizar tu rendimiento...
En mi caso, que soy tester, mantengo semanalmente unas 4-5 reuniones con programadores para mejorar el producto que estamos desarrollando, un par de reuniones con gente de mi equipo (testers) para coordinar nuestras pruebas, varias reuniones con Product Managers, que son personas que se encargan de analizar qué características debería y no deberían tener las próximas versiones del producto, en base a estudios de mercado, viabilidad técnica, opiniones de desarrolladores y testers...
Algo que llama la atención en estas reuniones es la enorme capacidad de diálogo de toda esta gente, su facilidad para expresar argumentos de manera no ofensiva aún cuando las posturas son radicalmente opuestas, y la enorme predisposición a ayudar a los demás. Aquí todos se esfuerzan por dar lo mejor de sí mismos, y que cada día esa cota sea mayor, pero no con el afán de ser individualmente los mejores, sino de elevar la calidad de su trabajo para desarrollar muy buenos productos.
Para todas aquéllas personas que trabajen en equipo, ¿cómo es vuestro trabajo?
Espero y deseo que tengáis la suerte que he tenido yo de caer en un equipo :-)