Proyecto de software

Hoy le comentaba al sensei que me encanta trabajar en una empresa grande por lo que me enriquece en experiencia, no solamente concerniente a la seguridad, sino también al manejo de proyectos, trato con proveedores, programadores, con los jefes, otros empleados, etc.

El caso que me lleva a escribir estas líneas es, una vez más, el trato con los programadores/proveedores. Si bien la pelea suele ser porque no desarrollan correctamente la seguridad, hoy fue más bien un problema en el manejo del proyecto. Concretamente, el problema fue falla en el presupuesto, falla en cálculo de tiempos y falla en la comunicación... problemas clásicos.

Si bien existen libros completos sobre cómo manejar un proyecto, me interesa compartir lo que aprendí. Lo que describiré son cosas totalmente lógicas, pero muchas veces uno las termina obviando y ahí es cuando surgen los problemas.

Por un lado tenemos el grave problema de comunicación. La comunicación entre el proveedor y el cliente debe ser lo más fluida posible, a través de los interlocutores correctos, y durante toda la vida del proyecto.
La definición inicial es la parte más importante y el proveedor debe entender lo más cercano posible lo que el cliente desea... lo se, es difícil, pero es preferible invertir un poco más de tiempo modelando o esquematizando para que todos estén seguros que se entienden. Si la definición no está bien, resulta en pérdida de tiempo, usuarios furiosos y lo más importante... pérdida de dinero.
Luego es importante la comunicación durante el desarrollo y testeo. El proveedor debe molestar lo menos posible al cliente... si hay algo para probar, primero debe funcionar! Parece una pavada total lo que escribo, pero pasa, y seguido. El proveedor entrega un programa atado con alambres, y cuando el cliente comienza a probarlo, explota por todos lados, luego se arreglan algunas cosas, se vuelve pedir al cliente que testee, explota mil veces más, así que se arregla uno q otro problema y se vuelve a pedir al usuario que pruebe.... NO! ese no es el camino! El proveedor debe contar con una etapa de testing interna antes de molestar continuamente al usuario. Esto llega a enfurecer tremendamente al usuario, el cual tiene SU trabajo y no puede estar continuamente ayudando a los programadores a hacer algo que deberían hacer bien antes de entregarlo.
Más allá del problema arreglo-prueba-arreglo-prueba-... debe estar bien definido el interlocutor, y cuando se hacen las pruebas, la definición de los problemas encontrados debe estar armada correctamente. El interlocutor debe entender un poco de cada mundo, algo de parte de los programadores y algo de parte del cliente (aka funcionales). En proyectos chicos no suele haber funcionales y la comunicación es un caos. En estos casos, el proveedor debe explicar al cliente cómo debe documentar las pruebas realizadas. Si bien los programadores esperan una descripción correcta de lo que sucedió, los usuarios no suelen tener ni idea, y entregan datos casi inútiles. Por ello, el proveedor debe explicar al cliente que cuando encuentra un problema detalle qué fue lo que probó y cuál fue el resultado obtenido, si se incluye un screenshot, mejor.

Pasemos al tema presupuestario. En este caso la falla estuvo en no prever viajes. El proveedor se encuentra en una ciudad alejada y pensaba que podía realizar todo el trabajo sin hacer viajes... ERROR! Siempre es necesario realizar algún viaje, ya sea para hablar en vivo con el cliente, como para conocer el entorno donde se ejecutará su aplicación. Algo que anda sin problemas en el entorno de desarrollo, puede (por diversos factores) no funcionar en el entorno del cliente. El relevamiento del entorno en este caso conllevó perdida de tiempo y enfurecimiento del pobre administrador de dominio que tuvo que pelear para que las cosas anden.

Muy relacionado con el presupuesto está el tema "tiempos". Algo que se cree poder realizar en 6 meses no cuesta (hablando de dinero/estado mental) lo mismo que algo realizado en 2 años. Los plazos se escapan y no se gana lo que se esperaba. En el cálculo tiempo/precio se debe tener en cuenta la familiarización con el entorno del cliente, capacitación, testing, y viajes, entre otras cosas. También es necesario planificar la asignación de programadores, los cuales pueden estar abocados a más de un proyecto a la vez. El cliente no debe esperar, si se programa una fecha, se debe cumplir.


Si bien parece que son todas críticas al proveedor, la realidad es que el cliente siempre tiene la razón... sisi ok ok, los clientes tienen graves (por no decir GRAVES) problemas para describir que quieren, así como también para realizar y documentar las pruebas. El cliente también debe cumplir con su parte, en eso estamos de acuerdo.

El mayor problema con los proyectos chicos es que los mismos programadores hacen de diseñadores, funcionales y líderes de proyecto. Son muchos cargos juntos, realizar todos a la vez requiere de mucha experiencia (y desarrollar un estado mental superior...). Un programador que está hablando con el cliente es un programador que no está programando, y programador que está diseñando, no está programando... todo esto es tiempo, es decir, dinero y se debe prever muy bien, algo que es muy difícil.

Como la mayoría de los que leen este blog probablemente sean programadores, seguramente me insultarán con energía, pero mi único objetivo es plantear una experiencia de vida que puede ahorrarles problemas y salvar mucho dinero =)