Desarrollo de software en Equipo (Parte 1)


He decidido escribir este post con el fin de proveer una pequeña guía que exponga las mejores practicas que he encontrado en mis años de experiencia desarrollando software de clase empresarial.Si estas a punto de empezar un desarrollo o te encuentras dirigiendo un proyecto de desarrollo maduro, estas recomendaciones pueden ser de gran ayuda.

Para desarrollar software en equipo de manera exitosa es necesario tener en cuenta un sin numero de aspectos que dan cuenta de lo complejo que puede ser esta actividad, aquí me enfocare en tres rubros fundamentales: Metodología, Tecnología y Arquitectura.

Metodología

Adopta una metodología, abrázala fuerte y se fiel a esta. scrum-kanban-scrumban-intland-softwareSi desarrollas software comercial que no es de misión critica (donde fallas en el sistema nunca pondrían en riesgo el integridad de una persona) mi recomendación casi inmediata es Scrum y Agile, tambien llamadas metodologías ágiles. Esta metodologías te dirán con exactitud que hacer para sacar adelante un proyecto de desarrollo de software. Ademas utiliza las herramientas  visuales de gestión de equipos que adoptan estas metodologías, por ejemplo puedes usar Team Foundation Server (TFS) or JIRA para apalancar tu equipo si usas Scrum.

tfs_IC810589
TFS screenshot – Miembros del equipo asignados a alguna tarea

Una vez adoptas una metodología, cualquiera que sea, es casi un hecho que el concepto de REQUERIMIENTO llegará a tu vida. La mayoría de metodologías de desarrollo de software concuerdan en ahondar en las necesidades del usuario final y extraer de este las funcionalidades que son un requisito para que se sienta a gusto con el software que al final le entreguemos.

Desarrollar software es un proceso de ingeniería a menudo llevado a cabo por personas de muy variadas profesiones, sin embargo suelen ser ingenieros quienes mayoritariamente toman las riendas de los proyectos de desarrollo y a menudo su formación característica los lleva a cometer un error grave. Es muy común que los ingenieros tengan un visión que intenta “asegurar” el éxito del desarrollo desde la plena confianza en una metodología.

“En la practica satisfacer requerimientos no siempre es sinónimo de satisfacer al cliente”

Pero ten mucho cuidado, ya que en la practica satisfacer requerimientos no siempre es sinónimo de satisfacer al cliente. En un mundo ideal, tu le preguntarías al cliente que desea y el te dirá sus requerimientos, al cabo de un tiempo satisfaces esos requerimientos y el cliente no tendría razón para sentir frustración alguna. En la realidad, la amplia mayoría de oportunidades encontraras que tu cliente realmente no sabe lo quiere a pesar de que responda tus preguntas asertivamente. Es mas, puedes apostar a que cambiará de opinión en varias ocasiones. Esto es completamente natural ya que toda organización esta en ultimas formada por seres humanos a lo cual debe sumarse que tu cliente contrata tu equipo para realizar el desarrollo precisamente porque no tiene la habilidad o el conocimiento para desarrollar el software por si mismo, así que es apenas evidente que no tendrá claras una gran cantidad de cosas. Seguramente te preguntarás, entonces cómo es posible satisfacer al cliente? Esta respuesta vale oro y te la diré sin rodeos:

“Acércate a tu cliente, … busca entender qué lo hace o qué lo haría exitoso en su propio juego”

Primero: Acércate al cliente, conoce tanto como puedas de su actividad, entiende su negocio y busca entender que aspectos lo hacen o lo harían exitoso en su propio juego. suena fácil, verdad? pues no lo es. Cuando digo que entiendas qué lo hace exitoso, me refiero a que genuinamente comprendas por qué sus propios clientes lo buscarían y por qué ellos se quedarían con el, en caso de ser posible entiende de donde proviene su mayor beneficio financiero. No seas tímido, si lo deseas puedes ser transparente en todos estos objetivos. Asume a tu cliente como tu socio, solo entonces entenderás que necesita tu cliente.

“Pregúntale a tu cliente lo que quiere pero no esperes su respuesta”

Segundo: Pregúntale a tu cliente lo que quiere pero no esperes su respuesta. Invierte por adelantado parte de tu tiempo en formular desde tu propio equipo varias soluciones de software adecuadas, deja que el arquitecto y tus mejores hombres realicen prototipos de la tecnología que usarían y selecciona la mejor opción. Deja que sus mentes vuelen, permítete ser creativo. Pero finalmente deja a tu arquitecto seleccionar la mejor solución posible. Y en esto no seas transparente con tu cliente.

Tercero: Cuando su cliente le comunique sus requerimientos, escúchelo pero con su solución ya en mano, arrójese a persuadirlo y guiarlo hacia el camino que ya de antemano decidió de manera que para el sea natural y casi de su propia invención. Pero no le cuentes tu plan en forma completa. Aquí puedes cometer fácilmente un error: NO le presente varias opciones. NO le presente una visión donde empiezas desarrollando un proyecto pero que requiere el desarrollo de varios módulos de un gran software. En lugar de eso, déjalo asumir que existen pocos requerimientos a la vez. Siempre intenta guiarlo y no dejes que se salga del sendero que tu estas trazando para el, sin embargo, siempre como primera medida dale la experiencia de sentir que esta descubriendo el camino por si solo.

“No hay nada mas apaciguador que ver que se hizo solamente lo que estaba planeado”

Cuarto: Siempre debes parecer dar mas de lo esperado, planea un feature o un aspecto del desarrollo con el que puedas sorprender a tu cliente el día de la entrega. Recuerda que la satisfacción de tu cliente no necesariamente esta dada por la satisfacción de los requerimientos, asume el hecho de que esa organización tiene naturaleza humana y en ese sentido dale experiencias enriquecedoras, dale la oportunidad de decir WOW en la reunión de entrega de iteración o release. No hay nada mas apaciguador que ver que se hizo solamente lo que estaba planeado, por eso contribuya a mantener una relación dinámica en el buen sentido de la palabra generando expectativas positivas e instruya a su equipo para que en todo contacto con su cliente se comporte como un profesional exitoso y dinámico.

expectationSi aplicas estos consejos verás como en cada fase del desarrollo tanto tu equipo trabajará en lo que cree es la mejor solución, como tu cliente se mantendrá convencido de que dicho es desarrollo es el mas pertinente posible. Sin embargo debo advertirte que algunos de estos consejos pueden ir en contravía de lo que tu metodología puede decirte, por ejemplo, algunas veces Agile puede decirte que seas transparente con tu stakeholder (cliente) pero si lo haces no podrás entregar nada fuera de lo planeado como indico en el punto 4. Como este pueden existir otras diferencias. Analízalas con calma y verifica que existan formas de armonizarlas.