PMBoK… no puede faltar en su biblioteca

Buenos dias, estimados… Hoy he querido compartir con ustedes un librito bastante escaso, el cual siempre se sugiere leer cuando estas trabajando con proyectos, y más aun, si formas parte importante de ellos.

Es por este motivo, que dejo a su disposición el ejemplar del PMBoK Cuarta edición en Español, compendio de las buenas practicas en lo que respecta a proyectos, impulsado por PMI (Project Managemente Institute).

Link: http://www.mediafire.com/?lmchm4cat498scg

Salu2!

Ayer retome cariño con Teambox

Mientras veia que habia de nuevo en la web, recorde un buen portal del proyecto llamado Teambox, y pues entre a revisar más a fondo de lo que habia escarbado anteriormente. ¿Quieres saber de que se trata?

Entra a http://teambox.com/?from=gcuello

Opiniones?

Salu2!

Fracaso… una barrera mental y moral

Cuando algo no resulta de lo esperado… ¿ como lo consideras?

Alguien podría decirme que lo consideraría como un fracaso, pero ¿Será esa palabra la indicada para representar ese suceso?

Para mi, la palabra fracaso no existe. La razón es simple; sólo ha ocurrido algo que no se tenía contemplado.

El “fracasar” es un invento humano mental y moral. Lo pensamos así, porque es algo netamente social. La misma gente cree en el fracaso y hace que tu capacidad de elevarte baje sin verle el expectacular lado amable; el crecimiento en experiencia pura.

Si no exietiesen los “cambios de orientación” no habria crecimiento significativo y eso ocurre y todos los ámbitos. Debemos verlo como algo positivo, ya que si nunca caes cuando estás en la bicicleta, no puedes decir que sabes andar a la perfección.

Opiniones?

Salu2!

Programación y productividad… cuando no pueden conversar

Algunas veces, es complicado mezclar ambos términos ya que me ha tocado lidear con afanosos desarrolladores, los cuales intentan realizar todo a mano y está más que claro que es una pérdida de tiempo.

En mi experiencia, siempre me encuentro con que algunos proyectos casi siempre son “para ayer”, y que por causas de fluctuaciones externas aleatorias, a veces se deben dejar stand by por al menos un tiempo, y eres presionado a cumplir plazos que no son plenamente decentes. Lo cual lo único que logran es sentar a desarrolladores a solamente programar, y es sabido que eso solo apuntará al fracaso.

No todo en la vida es desarrollar y dejar unas cuantas sonrisas en la cara del cliente, pues… ¿Se ha considerado un pleno análisis aunque este sea breve?,¿Se ha considerado mantención en el sistema?, o algo más grave aún… ¿Y si alguien del equipo se va o se enferma por un tiempo extenso?

Son preguntas que muchas veces debes hacerte si tienes la labor de coordinar un equipo de desarrollo de software.

El éxito en un desarrollo de software dependerá del equipo entero. Algunas veces cuando tienes desarrolladores que se “casan” con un lenguaje de programación determinado y están obligados a cambiar de plataforma, comienza a aparecer la tan nombrada “resistencia al cambio” y lo peor de todo es que es dentro de tu propio equipo (pensando que casi siempre este fenómeno se da en la parte del cliente!). Muchas veces te envian/contratan un desarrollador artesanal y definitivamente es lo peor.

Aunque evangelices sobre la productividad del desarrollo de software, con frecuencia sientes que hablas al viento. Concuerdo que todos, como desarrolladores o más bien dicho como programadores, pasamos por una etapa de artesano, ya que nada puede describir lo exitante que es ver el propio resultado de la mano del hombre y la máquina trabajando en conjunto pero… ¿Es esto productivo para el desarrollo de una aplicación o sistema que esta contra el tiempo?

Definitivamente no. Es por esto que existen lineamientos que seguir y herramientas que pueden hacer el trabajo “artesanal” de una manera ágil, y con menos probabilidad de errores. Siendo así… ¿Por qué la resistencia al cambio hacia lo productivo, siendo que es una tremenda ventaja para que el software tenga éxito?

Pues tengo mis teorias al respecto. Considero que la mayoria de los desarrolladores quieren ser idolatrados por sus logros independientes o sus capacidades de “hacerlo a mano” logrando ser reconocidos como “desarrolladores héroes” pero… creo que eso no hacen bien para la vida de un proyecto informático, ya que este es un resultado de un trabajo en equipo, en el cual si se triunfa o se fracasa (aunque esta palabra no la considero dentro de mi léxico) se le debe atribuir al equipo completo.

Se debe ser productivo y completar a cabalidad los requisitos que son pedidos por los clientes, pero recordemos que no somos magos.

Opiniones?

Salu2!