Ir al contenido principal

Errores al Realizar Estimaciones

Casi siempre antes de iniciar un proyecto, es necesario saber cuanto tiempo nos vamos a tardar. Esto es para saber si realmente vale la pena hacerlo o no. Cuando el proyecto es personal no es tan complicado calcular, bueno por lo menos no es un riesgo; pero cuando es un proyecto que se va a cobrar y el cliente o jefe quiere saber si vale la pena realizarlo, a veces esa presión no nos deja estimarlo bien. Muchas veces los errores son cosas que pasan seguido y se pueden evitar si las identificamos.

El primer error es no querer estimar, es común escuchar o pensar "yo no sé estimar" y ese es nuestro pretexto para no ser responsables del estimado. Es normal no atinarle al tiempo que se lleva una tarea, sobre todo si es la primera vez que estimamos cuanto tiempo se lleva algo. Estimar es una habilidad que se obtiene practicando. Si queremos ser mejores estimando, debemos estimar más. Entre más lo evitemos, menos aprendemos a realizarlo.

Otro error al estimar es el ser muy optimista. Esto es pensar que todo va a salir bien a la primera. O que las cosas no van a cambiar. Cuando estamos trabajando en un proyecto de software, las cosas "nunca" van de acuerdo al diseño original (por algo lo llamamos desarrollo). Cuando estimamos debemos tomar en cuenta que lo más probable es que nuestra primera propuesta de solución no sea la adecuada. Siempre hay que agregar el "colchón" por si las dudas.

Ser muy pesimista es un error también, generalmente pasa después de que tuvimos problemas en proyectos anteriores por ser muy optimistas. Aquí el síntoma es que le ponemos tanto "colchón" a las tareas que puede parecer que el proyecto no vale la pena desarrollarlo por todo el tiempo que se llevaría. Encontrar el balance viene con la práctica.

Para poder saber el tiempo que nos lleva realizar un proyecto debemos poder definir las tareas  necesarias para completarlo. Otro error frecuente es no descomponer el proyecto en tareas concretas. A veces por no ponernos a pensar un momento a que se refiere cada tarea, podemos llevarnos una sorpresa al momento de realizarla y darnos cuenta que en realidad se lleva menos o más tiempo del que habíamos pensado. Es importante estimar cada parte del proyecto.

El último error de mi lista es no revisar que tan cerca estuvimos del estimado original una vez que terminemos cada tarea y el proyecto. Para poder aprender necesitamos saber que tan cerca o lejos estuvimos y entender el porqué. Esto nos va a ayudar a tomar esos factores en cuenta la próxima vez.

Comentarios

  1. me parece muy acertado lo que dices y se puede ver claramente una estructura en ello, deberías escribir una metodología para estimación de proyectos.

    ResponderBorrar
    Respuestas
    1. Estoy intentando dejar el cobro por hora a la hora de tomar proyectos, quizás sí sea buena idea definir una metodología para crear el estimado. Una vez platicamos de eso en el podcast dev3Cast y ahí se mencionaron algunas metodologías. http://www.dev3cast.com/2015/09/23/estimacion-de-proyectos/

      Gracias por tu comentario.

      Borrar

Publicar un comentario

Entradas más populares de este blog

Bloqueos

Una de las preguntas típicas de las juntas matutinas en los equipos de desarrollo de software es ¿Hay algún bloqueo? Si lo hay, se trata de ver qué es lo que está esperando esa persona y encontrar la forma de que se desbloquee; pero ¿Qué son los bloqueos? Los bloqueos son obstáculos que te impiden realizar o avanzar en tu trabajo. Evitan que puedas seguir progresando en el proyecto.

He notado que es común en las personas con menos experiencia decir que tienen un bloqueo cuando están batallando, debido a su poca experiencia, en la forma de resolver un problema. Han intentado varias formas y se empiezan a quedar sin ideas de como puede ser resuelto el problema o como pueden cumplir con el requerimiento especificado. Al quedarse sin opciones de qué intentar dicen que tienen un bloqueo con la tarea y que a menos que alguien les diga como resolverlo, no se puede avanzar en la tarea.

En personas con más experiencia, ese tipo de bloqueos no ocurren, una persona con experiencia ha visto pro…

Firebird 2.1 UPDATE OR INSERT

Another great feature that I like in Firebird 2.1 is the UPDATE OR INSERT statement. It's a really time saver and it makes the SQL cleaner.

For example suppose I have a products table like the one I use in my last post and an inventory table to store the product stock. Before Firebird 2.1 if I want to set the stock for a product I needed to check if a record for that product_id already exists; if the product_id already exists then I write an update. If not then I write an insert statement. So I ended up with something like this:


IF EXISTS(SELECT * FROM inventory WHERE product_id = :product_id ) THEN
UPDATE
inventory
SET
stock = :stock
WHERE
product_id = :product_id;
ELSE
INSERT INTO inventory
(product_id, stock)
VALUES
(:product_id, :stock);

In this example I only update one field but when I have to update a big table I ended up with a big chunk of code and thinking: "there should be another (better) way to do this".

Fortunately now with Firebird 2.1 there…

Database Mail en MS SQL Server 2005

Configuración de Database Mail en MS SQL Server 2005

Primero se debe de habilitar, ya que por omisión el componente esta deshabilitado, Utilizando el SSMS (SQL Server Management Studio)


Si no esta habilitado aparecerá un mensaje preguntado si lo habilita, después aparece esta ventana donde se pregunta al usuario que es lo desea hacer.


Seleccionamos la primera opción para crear un perfil.


Configuramos el perfil y le agregamos por lo menos una cuenta.


Seleccionamos el perfil como public y default.


Para mandar correo se utiliza el procedimiento msdb.sp_send_dbmail por lo tanto el usuario que intente mandar correo debe de tener permiso para la base de datos msdb.

Referencias:
http://www.sqlservercentral.com/columnists/cBunch/introtodatabasemailinsql2005.asp