Trabajar desde casa - interrupciones

Una de las ventajas de dedicarme al desarrollo de software es que se puede hacer (casi) desde donde sea y (en la mayoría de los casos) a cualquier hora. Lo único que se necesita es una computadora y motivación.

La mayor parte del tiempo que llevo como desarrollador lo he hecho desde casa y hasta el momento me ha funcionado bien. He escuchado comentarios de personas donde dicen que ellos no podrían trabajar desde casa. Una de las razones mencionadas son las constantes interrupciones. Si bien es cierto que en la oficina también ocurren, en casa pueden llegar a ser más estresantes. La diferencia al estar en casa es el tipo de interrupción, la persona que nos interrumpe y sobre todo nuestra actitud al atenderla o posponerla.

Cuando he trabajado desde la oficina de la empresa, la mayoría de las interrupciones eran por compañeros de trabajo, consultas de trabajo, preguntas del cliente, invitaciones a ir por un café o simplemente platicar. No se sienten como interrupciones, a menos que tenga algo urgente que entregar, se sienten más bien como actividades que forman parte del día laboral. Al estar en la oficina no siento la obligación de estar todas las horas de trabajo pegado en la computadora produciendo código, el simple hecho de estar presente en la oficina me hace sentir que estoy trabajando. Además mi mente sigue de alguna forma en el mismo contexto. Puedo estar platicando con mis compañeros de oficina de cosas relacionadas con el trabajo o con lo que ocurre en la oficina.

Al estar trabajando en casa las interrupciones son distintas. Hubo un tiempo en que mi esposa no trabajaba, y era sólo yo el que trabajaba desde casa (hoy ambos trabajamos desde casa). Toda mi comunicación con la oficina era a través de la computadora (chat, email, etc.). Cuando mi esposa me interrumpía, para preguntarme cualquier cosa relacionada con la casa, era algo estresante. Incluso pasaba con preguntas sencillas que no me tomaban más de unos segundos contestar. Ese “estrés” no ocurría cuando trabajaba desde la oficina de la empresa con las interrupciones ¿por qué?.

Creo que esto se debe a que las interrupciones en casa son distintas porque en lugar de ser un compañero de trabajo quien te habla, ahora es tu familia (hijo, esposa, pariente) quien te interrumpe y eso saca a tu mente del ambiente laboral. Al principio esto puede llegar a ser más estresante que las interrupciones en la oficina por el cambio de contexto. Dejas de pensar en lo que pasa en el trabajo para pensar en lo que pasa en la casa. Cambias de unos pendientes a otros y parece que tienes más cosas en que pensar (lo del trabajo y lo de la casa). Además al hablar de cosas de la casa, en la casa, sentía la urgencia de regresar al trabajo, sentía la necesidad de estar las ocho horas pegado al monitor escribiendo código.

Una forma de lograr una separación de contextos fue crear una “oficina” en casa. Utilizar un lugar en la casa donde la familia pueda ver que estas trabajando. Y por lo tanto saber que no estas disponible en ese momento, a menos que sea realmente necesario. También fue necesario un cambio de actitud de mi parte y darme tiempo para salir de ese cuarto de vez en cuando en horas de trabajo. Ya sea por agua o café y platicar un poco con la familia como lo haría con mis compañeros de oficina. No tenia que fingir que no estaba en casa para evitar interrupciones, al contrario, aprovechar que estaba en casa para estar en casa. Con esto la familia sabe que sí estas y que no tiene que interrumpirte en cuanto algo se ofrece porque seguramente no tardaras en salir y si no sales es porque estas muy ocupado. Para esto puede ayudar la técnica pomodoro.

Creo en conclusión que algo que ayuda a lidiar con las interrupciones, cuando se trabaja desde casa, es que en lugar de tratar de impedir las interrupciones en el día las incluyo como parte del día laboral. Cada cierto tiempo salgo de la “oficina”, mi mente se distrae del trabajo, atiendo las posibles interrupciones en ese momento cuando ya no estoy pensando en trabajo. Estas “interrupciones programadas" evitan el estrés por el cambio continuo de contextos. Al regresar a la computadora mi mente esta lista para empezar otro periodo de trabajo continuo, sin interrupciones sorpresa.

Reunión inter-comunidades Julio 2013

El pasado sábado 27 de Julio las comunidades tecnológicas de Tijuana (grupos de usuario) realizaron su reunión mensual el mismo día como parte de un mismo evento. Cada grupo contó con una hora para realizar su presentación. Uno de los objetivos del evento fue, para quienes no pueden asistir a todos los grupos cada mes, en esta ocasión pudieran asistir a las presentaciones de los otros grupos. En mi caso, cada mes asisto a la reunión de tijuana.js y trato de asistir a la de Tijuana .Net. Quisiera asistir a las demás; pero no puedo dedicar tantos días al mes para vistas a user groups. El hecho de que todos se reunieran el mismo día hizo que pudiera reservar el día entero para dedicarlo a las comunidades y así fue que pude asistir a reuniones de grupos a los que no había podido asistir antes.

El evento se realizó en las instalaciones del bitcenter, el cual se a vuelto “el lugar de reunión de las comunidades” (gracias a Ricardo Rosales que nos ayuda con eso). Inició a las 8 de la mañana y a tijuana.js le tocó la primera presentación. Pensé que por ser los primeros (a las 8:30 am) iba a estar casi sin asistentes; pero la realidad fue que ya había gente, quizás más que en una reunión mensual por separado.

(Presentación "Plain old Vanilla JavaScript" por Yves Mancera)

El programa fue:

8:30 tijuana.js : "Plain old Vanilla JavaScript" por Yves Mancera
9:30 RubyTij : ¿Cómo pensar en BDD? por Javier Murillo
10:30 Google Developer Group Tijuana : Instalar Ubuntu en una Chromebook
11:30 gultij.org : Introducción a Vagrant
--- descanso de 12:30 a 14:30 ---
14:30 DefConGroup Tijuana : Intervención de llamadas VOIP
15:30 Comunidad .NET Tijuana : Xamarin (desarrollo multiplataforma con .NET)

Conforme pasó el tiempo fue llegando más gente (después de esa foto fuimos por 20 sillas más). Al final se cumplió uno de los objetivos. Que las personas pudieran conocer a los otros grupos a los que por lo general no pueden asistir. Eso fue algo que me gustó porque todos somos una sola comunidad tecnológica, sin importar las herramientas especificas que a veces utilizamos. Todos podemos aprender de todos.

Con este evento pude darme cuenta que hay más gente (además de quienes participan mes con mes) que les gustaría asistir a las reuniones de la comunidad; pero que por motivos de horario y/o distancia (había gente fuera de Tijuana) no logran asistir. Este tipo de eventos les da la posibilidad de participar en la comunidad. Algo a tomar en cuenta es que al ser un evento que reúne a varios grupos, es difícil tratar temas de nivel intermedio o avanzado. Por lo que se llegó a la conclusión de seguir con las reuniones mensuales por separado y una vez cada ciertos meses realizar la reunión en conjunto. 

Aunque la mayoría de la promoción se realizó con el evento en Facebook, las fotos del evento se publicaron en Google+. Échenles un vistazo y nos vemos en el siguiente inter-comunidades Tijuana.

Sobre arquitectura en capas – parte 2

Desde hace algún tiempo, cuando un proyecto necesita acceder a una base de datos relacional, lo común es utilizar un ORM. El ORM se encarga de realizar la conversión desde objetos/colecciones en el lenguaje de OOP a registros/tablas en el modelo relacional y viceversa. En otros proyectos se ha optado incluso por usar una base de datos no relacional (NoSQL), donde no es siquiera necesario el mapeo entre clases y tablas. El uso de estas herramientas (ya sea ORM o NoSQL) nos ayuda a trabajar en un nivel más alto de abstracción. Ya no vemos SQL directamente, ahora trabajamos con objetos (entidades) como nuestros datos.

Si seguimos con el ejemplo del artículo anterior, donde se nos pide que un usuario pueda ingresar a un sistema usando su nombre y contraseña. Al usar herramientas como EntityFramework (un ORM) podemos cambiar nuestra capa de acceso a datos.La cual pudiera usar EF para realizar las consultas y actualizaciones. De esta forma no necesitamos escribir SQL y seguimos con nuestra misma arquitectura en 3 capas. Quedando el código algo así:

public User FindByUsername(string username)
{
  var db = new MySampleAppContext();
  return db.Users.SingleOrDefault(user => user.Username == username);
}

Pero nuestro objetivo no es tener 3 capas, ese era solo un medio para un fin. Recordemos para qué tenemos nuestra capa de acceso a datos. La capa de acceso a datos existe para que la capa de reglas de negocios no tenga que ”pensar” en detalles de tablas, registros y SQL. Es la misma razón por la que existen los ORMs, para abstraer el acceso a datos. Entonces… nuestra capa de acceso a datos es una abstracción del ORM que a su vez es una abstracción del acceso a datos, una abstracción redundante. Debemos de limitar nuestras abstracciones por lo que podemos utilizar el ORM directamente en nuestra capa de negocio. De ese modo podemos aprovechar mejor las características de la herramienta y nos ahorramos el trabajo de mantener una capa ya innecesaria. Comparemos el código de la capa de negocios con y sin una capa de acceso a datos.

//con capa de acceso a datos
public bool ValidateUser(string username, string password)
{
    var userRepository =  new Dal.UserRepository();
    var user = userRepository.FindByUsername(username);
    if (user == null) return false;
    var cryptoService = new CryptoService();
    return cryptoService.ComputeHash(password) == username.Password;
}

//Usando ORM en la capa de negocios
public bool ValidateUser(string username, string password)
{
    var db =  new MySampleAppContext();
    var user = db.Users.SingleOrDefault(x => x.Username == username);
    if (user == null) return false;
    var cryptoService = new CryptoService();
    return cryptoService.ComputeHash(password) == username.Password;
}

Podemos ver que el código es muy similar; pero usando EF ya nos ahorramos una capa (un proyecto). Podemos hacer uso de características de EF desde nuestra capa de reglas de negocio (como lazy loading, entre otras) sin tener que tratar de replicarlas en nuestra capa de acceso a datos.

En conclusión podemos decir que ahora, con el uso de herramientas como ORM (o una base de datos no relacional), ya no es necesario crear una capa de acceso a datos porque las herramientas cumplen con el propósito que tenia esa capa. La capa de acceso a datos tenia sentido cuando escribíamos SQL directamente en nuestra aplicación; pero ya no.

Artículo relacionado: Sobre arquitectura en capas – parte 1

Octavo Super Happy Dev House Tijuana

El pasado Sábado 27 de Abril asistí al octavo SHDHTJ en las instalaciones de MindHub. Inicio a las 9 am aunque hubo quienes llegaron desde antes. Después de que llegó algo de gente se hizo una presentación sencilla por parte de Gabriel Flores sobre de lo que se trata el evento. Hubo caras nuevas y algunas ya conocidas. 

Una buena noticia que nos dieron al iniciar el evento fue que MindHub,  por el gusto de haberlos elegido como sede del evento (sus palabras), nos quisieron regalar las pizzas para los asistentes. Lo cual fue un buen detalle que fue bien recibido. Además los asistentes cooperaron con sodas, cervezas, vino, queso y botanas. También Octavio Álvarez llegó con lo que había quedado del code retreat que había sido una semana antes.

En esta ocasión hubo menos interrupciones externas, por lo que tuvimos más oportunidad de trabajar en el proyecto que teníamos en mente. Trabajé haciendo pair programming con Gabo en lo que pretendemos será el nuevo sitio para la Comunidad .Net Tijuana. La idea es trabajar con algo nuevo y ligero como WebMatrix que es algo que no utilizo.

(Foto por Gabriel Flores)

Hubo buenas platicas en el transcurso del día y conocí a gente nueva. Al final no hubo presentación de proyectos como la edición pasada pero sí platicamos sobre ellos. Algo nuevo para mi en este tipos de eventos fue que, en lugar de programar con cerveza y papás fritas, ahora lo hicimos con vino tinto, queso, tomates secos y pitas (cortesía de Javier Aguilar). Ahora no podrá faltar el vino en los siguientes SHDHTJ.

Fue una experiencia muy agradable, al final del día había ganas de seguirle en un after party.

Sobre arquitectura en capas – Parte 1

Aun veo proyectos que separan los componentes de la aplicación en capas, utilizando el viejo modelo de 3 capas, el cual siento que ya no es la mejor opción ya que la forma de desarrollar software ha cambiado. En esta serie de artículos pretendo explicar porque ya no es necesaria una separación en 3 capas al momento de desarrollar un nuevo proyecto de software.

Primero debo empezar por definir qué es es la arquitectura en capas para mi, así que esta primera parte trata sobre eso.

¿Qué es la arquitectura en capas?

La arquitectura en capas consiste en separar las responsabilidades de nuestra aplicación de una manera horizontal. Esto se hace con la intención de elevar el nivel de abstracción. Ocultar la plomería de la aplicación poniendo una capa de abstracciones sobre ella. Las típicas capas de esta arquitectura, iniciando de abajo hacia arriba, se describen a continuación.

Capa de acceso a datos (también conocida como DAL por sus siglas en ingles): Es donde se escribe el código que habla con la base de datos. Es en esta capa donde se definen las consultas a la base de datos (el SQL). No realiza validaciones entre entidades, sólo las validaciones que van hacia la base de datos. La intención de esta capa es que el resto de la aplicación no se preocupe de los detalles (en cierta medida) de la estructura de la base de datos y trabaje a un nivel de objetos. Es la encargada de la entrada y salida de datos hacia y desde la base de datos. Ya que no debe de preocuparse de las reglas de negocio el código de la capa debería de ser fácil de seguir y de mantener. Las capas construidas encima de esta (es decir que usen esta capa) deben de dejar de pensar en tablas y registros para pensar en objetos y colecciones.

Capa de reglas de negocio (BL): Una vez que tenemos la abstracción de la capa de acceso a datos, sobre ella se construye una capa. En esta capa es donde se escriben las reglas de negocio, validaciones que involucran varias entidades, validación de estados y condiciones definidas en los requerimientos. Usa a la capa de acceso a datos para realizar las consultas y actualizaciones a la base de datos. La capa de negocio no sabe cómo es presentada la información al usuario o de cómo fue capturada por él. Al no preocuparse de como se presenta la información (UI) o de como es que se almacena (DAL), en el código solo deben observarse que las reglas (de negocio) definidas en los requerimientos se cumplan.

Capa de presentación (UI): Lo que el usuario ve. Es la capa donde se crean los componentes de la interfaz de usuario. Esta capa utiliza a la capa de negocio para realizar la tarea que el usuario requiera. La capa de negocio validará y regresará el resultado o error y la capa de presentación los mostrará al usuario. Entonces el código en esta capa sólo se encarga de pasar valores a la capa de negocio y de desplegar información, en la interfaz de usuario, que viene de la capa de negocio.

Hagamos un ejemplo para entender mejor a que se refiere cada capa. Supongamos que se nos pide que en la aplicación que estamos desarrollando un usuario pueda ingresar al sistema con un nombre de usuario (username) y contraseña validos. Separando nuestra aplicación en capas como las definidas anteriormente tendríamos las siguientes clases (en C#).

Primero la capa de acceso a datos

namespace Dal
{
  public class UserRepository
  {
    public User FindByUsername(string username)
    {
      User user = null;
      var sql = "SELECT * FROM User WHERE Username = @Username";
      using(var connection = new SqlConnection(Config.ConnectionString)){
        var cmd = new SqlCommand(sql, connection);
        cmd.Parameters.AddWithValue("@Username", username);
        connection.Open();
        using(var reader = cmd.ExecuteReader())
        {          
              user = reader.read() ? 
                 new User(username, reader["password"]) : null;
        }
        return user;
      }
    }
  }
}

Ahora la capa de reglas de negocio:

namespace BL
{
  public class UsersService
  {
    public bool ValidateUser(string username, string password)
    {
      var userRepository =  new UserRepository();
      var user = userRepository.FindByUsername(username);
      if (user == null) return false;
      var cryptoService = new CryptoService();
      return cryptoService.ComputeHash(password) == username.Password;
    }
  }
}

Por último la capa de presentación:

...
void LoginButton_Click(object sender, EventArgs e)
{
   var usersService = new UsersService();
   if (usersService.ValidateUser(usernameTextbox.Text, passwordTextbox.Text))   
       MessageBox.Show("Bienvenido");
   else
       MessageBox.Show("Usuario o contraseña incorrectos");
}
...

Aquí puede verse la separación de la lógica en capas. En lugar de hacer la consulta a la base de datos directamente en el método de clic del botón, la capa de presentación delega la validación del usuario a la capa de negocio. La capa de negocio a su vez delega a la capa de acceso a datos la creación y ejecución de las consultas en SQL sobre la base de datos.

Así era como desarrollábamos una aplicación hace años; pero ya no.

Artículo relacionado: Sobre arquitectura en capas – parte 2

Comentarios Dispersos

Tengo varios años leyendo y subscrito a blogs. Los leo principalmente a través de FeedDeemon (que se conecta a Google Reader) y desde mi teléfono. Por lo que no tengo que necesariamente visitar el sitio para leer el artículo. Aun así hago clic en el link de algunas entradas para leer el articulo desde el sitio del autor y así ver los comentarios.

Los comentarios enriquecen el contenido, la idea que el autor quiere expresar. Pueden aportar otra perspectiva que complementa o que incluso invalida la sugerencia del autor. Si sólo leyera el articulo sin los comentarios, me quedaría con la perspectiva del autor sin conocer las otras opiniones.

Es por eso que últimamente me he puesto a pensar en el fenómeno de la “descentralización” de los comentarios. En ocasiones algunos buenos comentarios (opiniones) se pierden en twitter como respuestas a quien compartió el link. Lo mismo ocurre cuando el artículo se comparte en otras redes sociales. Puede haber buenos comentarios en las entradas que comparten el link que no necesariamente los puede leer el autor o algún lector del artículo.

Por otro lado, entiendo que hay ocasiones que los comentarios pueden llegar a ser tantos que (por falta de tiempo) sólo quisiera leer los comentarios de las personas que conozco. Cómo cuando en las redes sociales, un amigo comparte un link y los demás (amigos) comentamos sobre eso en la red social.

En lo personal me gusta que comenten directamente en la entrada del blog, porque así los comentarios persisten junto con el artículo y ayudan a mejorarlo. Es por eso que los invito a comentar directamente en los artículos.

Los grupos de usuarios son un pasatiempo

Uno de los primeros grupos de usuarios que conocí de cerca fue el de la comunidad .net Tijuana. Antes había escuchado del grupo de usuarios de Linux; pero nunca me acerque a ellos. Recuerdo que sentí que era algo en lo que todo desarrollador profesional debería participar. Por eso mismo empecé a asistir a las reuniones mensuales a las que tenia oportunidad y sobre todo a los eventos grandes que la comunidad organizaba.

Por ese mismo tiempo comencé a suscribirme a varios blogs y sitios que trataban sobre el desarrollo de software. Noté que varios de los temas, que trataban en las reuniones de la comunidad, eran presentaciones que ya había conocido a través de esos sitios que seguía. Aun así me gustaba participar en las reuniones e invitaba a colegas a asistir. Me preocupaba que otros sintieran que no les aportaba algo nuevo una presentación que quizás podían ver en línea. Decidí participar dentro de la comunidad presentando, tratando de cambiar las presentaciones de PowerPoint por presentaciones con código. Por lo menos de esa forma verían un ejemplo practico, en código, del tema. Algo distinto a la presentación en línea que pudieran encontrar.

Organizando otros eventos trataba (y aun trato) de atraer a más desarrolladores profesionales para que formen parte de la comunidad. Noté que por más esfuerzos, la respuesta de los profesionales es la misma. Sí hay gente nueva; pero hay mucho profesional que no le importa pertenecer a un grupo de usuarios. Llegué a pensar que lo que necesitaban era conocer el beneficio que es ir a aprender de otros colegas y hacer mejor su trabajo. Una vez que lo vieran iban a asistir.

Me di cuenta que en lugar de buscar la razón por la cual alguien no participa en la comunidad, debía buscar la razón por la que las personas sí participan. Recordé que yo no necesito la comunidad para ser mejor desarrollador. Me gusta asistir aunque el tema ya lo conozca. No voy con la única intención de aprender más. Voy por el gusto de estar ahí conviviendo con personas que tienen el mismo interés por la tecnología.

Hace tiempo a la comunidad de Tijuana .Net Microsoft la apoyaba con regalos. Recuerdo que tenían rifas al final de cada reunión, había un tesorero y toda la cosa. Ahora que he estado más involucrado en la comunidad, noté y supe que Microsoft ya no apoyaba al grupo. Aun así en las reuniones sigue habiendo soda y galletas. Gabriel Flores los lleva, se toma la molestia de ir a comprar con su dinero sólo porque le gusta organizar las reuniones, le gusta la comunidad. No lo hace porque Microsoft le dará premios.

Hace meses inicié el grupo de usuarios de JavaScript y al ser el organizador tengo que pagar el dominio, crear el sitio y pues me toca comprar las sodas. Al principio sentía que no debería de pagarlas yo, que eran las empresas las que debían pagar por esos gastos ya que estábamos dando un servicio a los profesionales. Aunque no es mucho gasto, pensaba que estaba haciendo algo mal por tener que pagar las sodas de mi cartera.

Hasta que entendí que las comunidades son un pasatiempo y como todo pasatiempo cuesta, no se busca beneficio de un hobby, sólo se hace por el gusto de hacerlo. A veces es difícil darse cuenta, ya que se trata de lo mismo que hago en mi trabajo y por eso sentía que no tenia que pagar por hacerlo. Ahora que veo la organización de la comunidad como un pasatiempo (y no necesariamente como algo de beneficio para mi trabajo; aunque me ha ayudado) disfruto más de las reuniones. Los gastos no me pesan porque sé que son para el pasatiempo que disfruto. Entiendo por que algunos desarrolladores profesionales no asisten y nunca asistirán a las reuniones, simplemente es un pasatiempo que no compartimos.

Comunidades de Profesionales

En Tijuana, donde vivo, hay varios grupos de usuarios (comunidades de desarrolladores de software). Son organizados sin fines de lucro, con el fin de compartir el conocimiento entre colegas.

Algo que he notado, en algunas de estas comunidades, es la falta de participación de los desarrolladores. En varias reuniones de los diferentes grupos se ve a las mismas personas participando, ya sea como presentador o asistente. Hay ocasiones que las reuniones son organizadas en escuelas y es entonces cuando se ve una gran asistencia; pero principalmente formada por estudiantes. ¿Por qué no asisten más profesionales a las reuniones?

Una razón puede ser que no les gusta el horario. O es muy temprano y por lo tanto es en hora de trabajo o es tarde y prefieren ir a casa a descansar que tener que esperar a que sea la hora de la reunión. Parece que el horario “ideal” es justo saliendo del trabajo y no es el mismo para todos.

No saben que existe la comunidad. Si no saben que el grupo de usuarios existe y que se reúnen cada cierto tiempo, es casi imposible que asistan. Para remediar esto necesitamos mayor difusión, quizás no solo en las redes sociales sino acercándose, como comunidad, a las empresas. Las empresas pueden ver beneficio en las reuniones y ayudar en la difusión entre su personal.

Otro factor puede ser el nivel de los temas. Es difícil poder complacer a todos en esto. Para algunos un tema puede ser muy avanzado y no poder seguir la sesión por ello; para otros puede ser demasiado básico y sentir que la reunión no le aporta ningún beneficio (por no aprender algo nuevo). Lo que se podría hacer es presentar los temas en más de una reunión y tratar de cubrir un nivel en cada una. Por ejemplo: Tecnología X introducción, intermedio y avanzado. Esto no será posible para todos los temas; y para los que sí, será difícil contar con la disponibilidad del ponente.

Al igual que el nivel de los temas. Es difícil tratar un tema sobre el cual la mayoría se sienta identificado. A veces son sobre tecnología nueva y no les aporta conocimiento necesario para ser mejores en su trabajo actual. O el caso contrario, cuando se tratan tecnologías viejas que ya no utilizan en sus proyectos.

El factor principal sobre la falta de participación de desarrolladores profesionales es que no ven un beneficio en asistir o exponer en los grupos de usuarios. Los beneficios personales que se pueden obtener dependen de cada quien. El beneficio colectivo que se busca es el de compartir el conocimiento, experiencias y pasar un buen rato con gente que tiene intereses en común (la comunidad).

¿Cómo vas?

En ocasiones, me ha tocado trabajar con clientes que constantemente están preguntando sobre el avance de alguna característica que (prácticamente) se acaba de solicitar. No se refieren al progreso del proyecto o algún modulo, sino a la tarea individual que puede tomar unas cuantas horas solamente.

Problema
Por un lado, esto llega a ser cansado para el equipo. Es molesto que te pregunten una y otra vez lo mismo, más aun si el tiempo que te tomas en contestar hace que la tarea sencilla te tome un poco más (esto a su vez provoca más preguntas sobre el estatus). El “¿Cómo vas?” constante desmotiva porque pone bajo estrés al equipo, evitando la creatividad. No permite que busquen nuevas y mejores soluciones para los problemas que se tratan de resolver. Esto puede llevar a que crezca la deuda técnica del proyecto, que a la larga puede resultar en costo de tiempo y dinero.

Por otro lado, puede causar frustración en el cliente porque siente que no se avanza en lo que se necesita. Al estar preguntando contantemente sobre el avance del proyecto y recibiendo respuestas del tipo “vamos donde mismo”, puede llegar a sentirse un estancamiento en el progreso.

Posible causa
Pasa cuando el cliente no tiene experiencia en trabajar con un equipo de desarrollo y (quizás) siente que es una forma de tener el proyecto bajo control.

Soluciones
Para evitarlo la solución obvia es hablar con el cliente para que evite esas interrupciones constantes. Sin embargo, en ocasiones, no es posible y aun cuando se hace no siempre se logra un cambio duradero. Algo que he intentado en esas situaciones es el dar estimaciones pesimistas. Con la intención de reducir las expectativas sobre el tiempo de entrega de la característica y evitar el ansia de verla terminada. Se debe tener cuidado en no exagerar en el pesimismo, no queremos que el cliente se nos vaya.

Otra cosa que intento es no contestar inmediatamente para así evitar la interrupción y al mismo tiempo ir acostumbrando al cliente a que cada pregunta puede tomar su tiempo de respuesta.

Si la situación continúa, lo otro que he hecho es contestar lo mismo a varias preguntas consecutivas, incluso aunque ya haya un poco de avance, para tratar de no alimentar esa necesidad de estar conociendo el más mínimo avance de algo que no es crítico como dando a entender que “no por mucho madrugar amanece más temprano”.

Esto he hecho para que se reduzcan los “¿Cómo vas?”; pero aun así, de pronto, aparecen.