Ir al contenido principal

¿Cuándo lo tengo que terminar?


Me ha pasado que le pido a alguien que me ayude con cierta tarea de desarrollo de software y me pregunta que cuándo lo tiene que terminar. Mi respuesta generalmente es: "lo antes posible"; pero la persona que va a hacer el trabajo es quien debería de decirme cuándo considera que va a estar listo, claro que su respuesta debe estar justificada. Tampoco se trata de que invente un número.

Parece que estamos acostumbrados a que alguien más nos diga para cuándo ocupa lo que nos pide y nosotros ya veremos como le hacemos para cumplir con esa fecha. Quizás sea que esta costumbre la tenemos porque así se nos enseña en la escuela. Se nos pide un proyecto de tarea y se nos da una fecha de entrega. Es curioso; pero generalmente desarrollar el proyecto se toma todo el tiempo que tenemos... ni más, ni menos.

Se nos enseña que la persona que pide el trabajo nos dirá para cuándo lo quiere listo. No nos enseñan que como profesionales, somos nostros, los que debemos dar estimados.

Lo hacemos, también, porque al preguntar en cierta forma estamos evadiendo la responsabilidad de entregar algo completo en la fecha dada. Porque podemos alegar después que no quedó completo por falta de tiempo y sentir que no fue nuestra culpa. Podríamos decir que nos da miedo equivocarnos.

Si hacemos seguido eso que nos da miedo, después ya no nos dará miedo. Podemos intentar hacer estimados seguido.  Al principio es normal equivocarse, puede que seamos muy optimistas y después darnos cuenta que es más trabajo del previsto. Aun así debemos seguir practicado estimar el trabajo que nos piden. Incluso cuando no hay fecha límite, pensemos en: "¿Qué tengo que hacer y cuánto tiempo me tomará cada tarea?". De ese modo vamos practicando y podemos revisar al final del proyecto si tomamos en cuenta (en la estimación original) todo el trabajo que en realidad tuvimos que realizar.

La próxima vez que nos pidan un proyecto, recordaremos esos detalles que se nos pasaron en el proyecto anterior y los tomaremos en cuenta. Así cada vez, la estimación será más apegada a la realidad y en lugar de preguntar para cuándo, ahora nosotros daremos la fecha aproximada en que puede estar listo eso que nos piden, claro que siempre agregando algo de margen para los imprevistos.

Comentarios

  1. Buen post mi buen Mario. La comunicación y honestidad es de lo más importante. Me gusta mucho la idea de que en la escuela nos puedan enseñar a decir cuándo entregar (self-deadlines).

    Agregaría que es muy importante identificar el por qué estoy haciendo esto, además de saber quién es el más interesado o beneficiado de lo que estoy haciendo.

    Entender el valor de nuestro trabajo nos ayudará a priorizar, darle preferencia, y no sentir pesadez al ejecutarlo.

    "Happy estimations"

    ResponderBorrar
    Respuestas
    1. Gracias por tu comentario Josue, es cierto lo que comentas sobre que es importante identificar el porqué de lo que estoy haciendo. Entender eso ayuda a que todo el equipo aporte a la solución.

      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