Comunicación en el desarrollo software

Miguel Llopis Lledó

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 :-)

Comments

[Publicado por: Vero]

Hola!! La verdad es que oirte hablar me da mucha envidia (sana eso sí ;). A mí me ha tocado dirigir un proyecto en una empresa dónde no existe el trabajo en equipo y el poco trabajo que había que hacer de forma conjunta normalmente daba muchos problemas debido a la falta de comunicación. La empresa de la que hablo es pequeña y por lo tanto todos los roles de los que hablas en tu post los desempeñaba yo (desde arquitecto a tester en el desarrollo, después implantador y administrador de la BD durante la implantación) y toda esta falta de coordinación y apoyo por parte de la empresa sólo se traduce en malos resultados que radican en pérdidas de dinero (al final es para eso para lo que uno trabaja). Yo creo que uno de los problemas más extendidos es que la premisa de que "casi siempre es casi tan bueno como siempre" se aplica a muchas fases del desarrollo sobre todo por la falta de capital en las empresas que lo único que quieren es que se pique código para que se pueda mostrar algo aunque ese algo no sirva para nada.
Todo esto de lo que hablo es desde una perspectiva pesimista y espero que esto no esté tan extendido en España como yo creo.
Saludos!

[Publicado por: Eugenio Estrada Csaky]

Buenas crack ;)

Creo que estamos totalmente de acuerdo Miguel, pero yo le daría un enfoque más tras leer el comentario de Vero. El principal problema de no existir un equipo, el trabajo individual, es la completa ceguera que hay a la hora de Testear o valorar tus proyectos y esto lo puedo resumir en una frase "lo que es evidente para ti para los demás no tiene porque serlo", ahí también se puede ver que la calidad del producto de un equipo probablemente será mejor ya que en el desarrollo son muchas cabezas que han trabajado CONJUNTAMENTE para que ese producto sea compresible y usable por el usuario final.

Me alegro mucho de que trabajes en un EQUIPO :)

Sigue así crack ;)

[Publicado por: Vero]

Cierto, es un punto que me he dejado por nombrar, se pierde usabilidad (que es uno de los puntos más importantes de una aplicación) porque no se es capaz de ponerse en la piel de un usuario ya que al desarrollar la aplicación todo te parece lógico y coherente aunque no lo sea.

[Publicado por: José Carlos]

Miguel, creo que incides en un punto muy interesante en el desarrollo del software: la ingeniería del software, frente a los "teóricos" de la artesanía (el arte del caos, en definitiva).

Respecto a las reuniones, creo que los americanos en general pecan por exceso de "reunionitis" (igual nosotros pecamos por defecto).

Se realizan muchas reuniones y en ocasiones la reunión parece más un fin que un medio. Además, en muchas ocasiones se invita a multitud de personas cuya presencia no tiene mucho sentido (ni siquiera para ellas).

Una pregunta a la que tú, como "tester" o ingeniero de pruebas (lo de "probador" también me suena mal a mí...), seguramente podrás responder con mayor conocimiento: ¿cómo se conjuga en Microsoft la presión comercial para finalizar un proyecto con la necesaria cadencia que exige la compleción del ciclo de desarrollo del producto y muy en particular la fase final de pruebas?

[Publicado por: Mario Ruiz]

Miguel,

Efectivamente los proyectos informáticos son complejos de llevarlos, aunque la esperanza de unión es una utopía. Los distintos participantes tienen en la naturaleza de su trabajo direntes intereses.

Además un buen manejo de proyectos informaticos tiene diferentes capítulos que no se pueden resumir en el espíritu de la unión. En efecto comunicacion es uno de ellos, el buen manejo de los recursos humanos, el manejo financiero, las especificaciones, la calidad, y el tiempo.

Mario Ruiz
http://www.oursheet.com

[Publicado por: Assad Malik]

Miguel,
Sería interesante averiguar la experiencia de los "interns" (si se ofrecen prácticas en España) y los empleados en Microsoft España. Si el espíritu y la cultura de Microsoft es una de unión y trabajar en equipo supongo que sería lo mismo en cualquier sucursal de Microsoft.

[Publicado por: José Luis]

Veo que teneis un muñequito de Channel 9 :-)

[Publicado por: Miguel]

Asi es Jose Luis, jeje.

Se podria decir que estoy haciendo dos internships paralelas, una como SDET (Software Development Engineer in Test), y otra en la que colaboro con el Channel 9 y el nuevo Channel 8 (igual que el Channel 9 pero hecho por estudiantes para estudiantes)

Un saludo!

[Publicado por: Miguel Egea]

El problema del desarrollo está en mi opinión en dos puntos
1.- somos demasiado jóvenes (a pesar de mis 38 "tacos" y de más de 15 de experiencia, es cierto que la ingeniería nuestra es demasiado nueva aún)
2.- No nos lo creemos ni nosotros mismos. Cuando dices que en un proyecto hay que hacer testing, o hay que hacer diseño, todo el mundo asiente con la cabeza, pero luego sigue la metodología A.S.M (A Salto de Mata), vamos como pollos sin cabeza, de héroes apaga fuegos y muchas veces por eso así nos va.

De todas formas yo no soy pesimista, he estado trabajando en proyectos que han sido un absoluto fracaso, y también en otros que han sido un rotundo éxito, y creo que haciendo las cosas como sabemos que se hacen y no como los pollos sin cabeza seremos capaces de cambiar la percepción (totalmente real) de vero.

Saldos
Miguel Egea

[Publicado por: Miguel]

Ha hablado el Maestro, este último comentario habría que escribirlo en papel, llevarlo en la cartera y consultarlo 20 veces al día...

No sé si habrás reparado en ello, D. Miguel, pero este fragmento de mi post son palabras tuyas:

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

De cierto viaje al Developer Day en Madrid...

Gracias al resto por vuestros comentarios, son muy acertados. Respecto al pesimismo que comenta Vero, decir que está en lo cierto, salvo en 5-6-7-10 ó 12 empresas en España, la situación es la que ella comenta. El dpto de desarrollo software en una empresa no dedicada al software (sino que se desarrolla sus propios sistemas de gestión) es un dpto que no genera en sí mismo beneficios sino que a lo que aspira es a dotar de un valor añadido al resto de procesos de negocio. Esto muchos "jefes" no lo ven tan claro y por ello lo consideran un departamento cuyo coste para la empresa se ha de minimizar. Lo cual, obviamente, también minimiza la calidad del proceso de desarrollo y, en consecuencia, del producto software final (si es que se le puede llamar "final", que ese es otro tema el de las versiones finales, parciales, parches y remiendos que merecería capítulo aparte)...

Y en empresas específicamente de desarrollo, la situación no es muy diferente. Se apuesta mucho por la "artesanía" del software, como decía uno de los comentarios, frente a la "ingeniería". Yo apuesto por la ingeniería como base sólida de un proyecto, como cimientos... y por la artesanía como ornamentación, extra, valor añadido, o como lo queramos llamar, de un proyecto ya edificado y sin peligro de venirse abajo. En el equilibrio de ambos factores (como en casi todo en esta vida) suele estar la clave del éxito.

Un saludo!