Estudiante de la carrera de Ingenieria en Computación.UABC
¿Alguno de ustedes ha leído «El Arte de la Guerra?». Este libro fue escrito hace más de 2000 años por el general chino Sun Tzu. Es un libro principalmente dedicado a enseñar estrategia militar y la importancia de ésta, pero si se lee cuidadosamente se podrá observar que sus aplicaciones van más allá de la ciencia militar.
Sun Tzu le estresaba la importancia de una planeación cuidadosa y detallada antes de ir al combate. En su libro él expresa que la mejor forma de asegurar la victoria es a través del combate indirecto, lo que él llamaba ganar sin luchar. Pero ¿qué relación tiene todo esto con el desarrollo del software?
Lo fascinante del libro es que está escrito con muchas analogías y metáforas. Aunque es obvio a primera vista que se está hablando de actividades bélicas, sus enseñanzas pueden ajustarse a casi cualquier ámbito competitivo, como los deportes, los negocios y la política. El desarrollo del software es un negocio y por lo tanto es fácil traducir estas analogías al lenguaje de los desarrolladores.
Aquí presento algunos de los pasajes que siento que son de mayor relevancia:
«El ejército victorioso busca la victoria primero y después lucha. El
ejército derrotado lucha primero y busca la victoria después»
«[…] Su victoria es infalible porque su victoria es inevitable.
Termina con un enemigo que ya fue derrotado.»
Uno no puede simplemente lanzarse directamente a codificar el software, por más tentador que esto pueda parecer. Se tiene que realizar todo un análisis previo al desarrollo. Los recursos y el tiempo son siempre limitados, por lo que no se pueden gastar ciegamente. Realizar el análisis de requerimiento y diseñar todo el plan de desarrollo antes de si quiera escribir una línea de código, servirá de guía para todo el equipo de desarrollo y la programación sería más sencilla de realizar, ya que se tendrá una idea clara de cómo debe ser el producto terminado.
Se debe diseñar el producto final antes de codificarlo, siempre, o la falta de coordinación del equipo causará problemas que afectarán directamente la calidad del software.
«Conoce a tu enemigo y conócete a ti mismo y ni en 100 batallas correrás peligro.»
En el desarrollo de software se pueden apreciar muchos problemas a lo largo del
proceso. Todos estos problemas pueden causar graves consecuencias, desde atrasos e incremento en los costos, hasta entregar un producto incompleto.
Casi todos estos problemas son causados por un pobre estudio en los requerimientos
del proyecto. Si no se conoce con precisión qué es lo que el usuario busca con el software que se está desarrollando, es decir, cuáles son las necesidades que nuestro software debe satisfacer, entonces estamos desarrollando un producto a ciegas. Estudiar bien cuáles son los requerimientos del software y planear de antemano el desarrollo nos evitará muchos dolores de cabeza después. Y no solamente se debe conocer las necesidades del usuario final, sino que también se debe tener una idea clara de cuál es la situación del equipo, cuáles son los recursos y el tiempo disponible y cuáles son las fortalezas y debilidades de cada miembro del equipo de desarrollo.
En conjunto, conocer estas dos cosas permitirá planear estrategias más realistas y efectivas, organizar mejores cronogramas, distribuir las responsabilidades a las personas adecuadas y gestionar los recursos de manera más efectiva. Llevando a cabo estas prácticas, se podrá tener un producto de mejor calidad.
Un último pasaje que en lo personal me parece importante mencionar y que casi
nadie lo hace es este:
«El rey puede traer desgracia a sus tropas en tres maneras: ordenarle a sus tropas avanzar o retirarse cuando no deberían, se llama maniatar el ejército; interferencia ignorante en las decisiones militares confunde a los oficiales y a sus hombres; intromisión ignorante en los nombramientos militares perpleja a los oficiales y a los hombres.»
Muchas veces, se puede tener un equipo de desarrollo habilidoso y bien coordinado, pero sin un buen liderazgo (sin una buena gerencia), éste no podrá realizar sus responsabilidades de forma efectiva. En el peor de los casos, los trabajadores se desmoralizarían o comenzaría a haber conflictos personales o emocionales entre ellos.
La gerencia no debe asignar tareas que contradigan el progreso actual de los desarrolladores; los desarrolladores conocen bien su labor, tienen experiencia desarrollando software, trabajando en equipo y siempre bajo presión del tiempo. Ellos tienen una visión actual y más precisa de cuál es el estado actual del proyecto, ya que son los que ven directamente el progreso del código. Si la gerencia no tiene buena coordinación con ellos y comienza a asignar tareas contradictorias con lo que están haciendo en el momento, esto mermará el progreso y el ritmo que llevan y seguramente causará insatisfacción entre los empleados.
La gerencia debe ser de preferencia alguien que haya pasado por el área de desarrollo y que tenga mucha experiencia en ello, de esta forma conocerá las necesidades de los desarrolladores y su mentalidad también, lo que permitiría tomar mejores decisiones y asignar nuevas actividades que no causen conflicto ni confusión con el resto del equipo. Aunque esto puede sonar muy obvio en primera instancia, en la práctica es demasiado común ver equipos de desarrolladores siendo liderados por gente que tiene nada o muy poco conocimiento de cómo se desarrolla el software. Los desarrolladores son la fuerza principal del proyecto, sin ellos, ningún proyecto podría llevarse a cabo, es por eso que es imperativo mantenerlos siempre contentos y motivados.
Estos son sólo algunos de los pasajes que se pueden leer en «El Arte de la Guerra”, podría citar el libro entero y aun así ajustar sus enseñanzas al desarrollo del software, pero eso me tomaría demasiado texto. Les recomiendo que si no lo han hecho todavía, lean el libro de Sun Tzu, se darán cuenta que sus enseñanzas son en realidad una filosofía que puede aplicarse a cualquier aspecto de la vida.
Aquí hay algunos blogs que encontré que también hablan de cómo utilizar «El Arte de
la Guerra» en el desarrollo de software. Noten como cada autor da una interpretación diferente, pero ambos son igualmente válidos. Les recomiendo que lean ambos:
http://epc-thethirdview.blogspot.mx/2010/06/art-of-war-in-software-development.html
http://accelerateddevelopment.blogspot.mx/2012/05/art-of-war-how-it-applies-to-software.html
