modlost.net

Si no saben que es Crunch Time pueden revisen este post. Crunch Time es una de las malas practicas más generalizadas en la gestión de proyectos informáticos y consiste en exigir a los miembros del equipo a trabajar mas horas y a trabajar fines de semanas o feriados.

¿Por qué llegan la mayoría de proyectos al Crunch Time? Hay diferentes razones y entre ellas podría mencionar:

• Mala definición del alcance del proyecto: Si al definir el alcance del proyecto solo intervienen los vendedores, el cliente y el jefe de proyecto entonces todo saldrá mal. Los vendedores solo quieren vender y tienen de bajar tiempos, recursos con el fin de vender aun así sepan lo que pasará. Los clientes muchas veces no saben lo que quieren o quieren algo que es imposible realizar con el tiempo y dinero que pueden invertir. Los jefes de proyecto por lo normal tampoco saben de tecnologías y no piden un juicio experto (consultan al arquitecto de software)
• Mala estimación de tiempos: Tiene que ver mucho con lo anterior. El cliente quiere que todo sea rápido. El vendedor promete un tiempo para convencer al cliente sin consultar si es viable. El jefe de proyecto trata de cumplir con lo imposible porque ya todo esta bajo contrato, etc.
• Mala estimación de cantidad de recursos: A menos recursos más ganancia (vendedor), menos costo (cliente). El jefe de proyecto tendrá que exigir más y más al equipo.
• Over-engineering: Hacer más de lo que necesita el cliente, un ejemplo clásico es tratar de hacer un sistema extremadamente flexible. Al final el cliente nunca necesitará aprovechar esa extrema flexibilidad y peor aún esa flexibilidad no funciona correctamente.

¿Que resultado obtendremos con esto?

• Un equipo desmotivado y por ende un mal producto
• Un cliente enojado debido a que el tiempo, costo y calidad del producto no es el esperado
• Los miembros del equipo van renunciando, esto lleva a que en el siguiente proyecto se cometan los mismos errores

Y al parecer nadie aprende de estos errores, nadie trata de cambiar:

• Enseñar a los vendedores sobre tecnologías y que siempre consulten al arquitecto de software
• El arquitecto de software debe lo suficientemente fuerte para poder decir las cosas como son y no callar
• Presentar al cliente opciones factibles/reales para solucionar sus necesidades. Si quiere menos costo o tiempo disminuir las funcionalidades para mantener la calidad del producto. De que le sirve al cliente un producto que se entrego a tiempo y con los costos exactos y no es de buena calidad. Tarde o temprano el producto será más y más costoso para el cliente.
• El jefe de proyecto debe negociar y no tratar de cumplir por cumplir
• Documentar las experiencias adquiridas sean buenas o malas para tomarlas en cuenta en los siguientes proyectos

Y mi recomendación final: Digan NO al Crunch Time!!!! o cobren mucho mucho mucho mas!!!! :P

Dedicado a mis amigos que en estos
momentos están en Cruch Time.

The TransformersC theme for SummerBoard really rocks! You can find it in BigBoss's Apps and Things source if you have a jailbreaked iPhone. Transformer's fans will love it!

Some Japanese guys found a weird way to show every day their hate to Micro$oft Windows Vista!

LOL

¡La programación es una parte vital de todo proyecto de desarrollo de software! Lamentablemente hay personas que creen que no es así y solo piensan en contratar mano de obra barata, dando como resultado proyectos con mas problemas de lo normales. En fin, ese es otro tema y lo trataré en otro artículo.

Hay diferentes formas de ver la programación:

• Como algo que no te gusta pero tienes que hacerlo porque esta en tu curricula.
• Como algo que no te gusta pero tienes que hacerlo para luego poder comenzar como programador pero dejarlo lo mas pronto posible para poder luego postular por un puesto de analista programador, analista, jefe de proyecto, etc.
• Como algo que no te apasiona pero que tampoco te parece terrible hacerlo.
• Como algo que te apasiona y te interesa aprender más y más.
• Como un arte.

Este artículo va orientado para todos los apasionados por la programación y mas aun para los que ven la programación como un arte.

Ayer hablando con un amigo sobre realizar un podcast del rol del arquitecto de software, me sorprendió con su primera reacción:

Estas seguro que el Perú esta preparado para saber lo que realmente tiene que hacer un arquitecto de software

Wow!, nunca lo había planteado en esos términos pero si estoy convencido que hay mucho por mejorar y replantear respecto al rol del arquitecto de software en el Perú. No hay un consenso generalizado sobre este tema, en ningún lado y menos espero lo que lo haya en el Perú.

Este tema va a ser muy interesante para un podcast y mucho mejor si los participantes no comparten las mismas ideas. Pero lo primero lo primero, dentro de unas horas voy a publicar el tercer episodio de modlost.net radio, luego me concentraré en el podcast de arquitectura y haré un post preliminar para calentar la discusión.