El desgaste de un mal ritmo

Uno de los factores que afecta a la productividad de un programador es llevar un ritmo que no es el adecuado. Cuando un programador lleva un mal ritmo?

• Si las tareas no están claras. Si el programador no tiene clara cual es su tarea seguro que la terminara muy rápido y el resto del tiempo no sabrá que hacer.
• Si el ritmo de trabajo es pausado. Si se esta en un mantenimiento o en sistema de resolución de incidencias entonces el trabajo entra en forma de grifo (a veces son gotas y a veces son autenticas cataratas) y muy descentralizado (la tarea de hoy puede no tener nada que ver con la de mañana) pero si es un desarrollo de una aplicación entonces el programador necesita ver profundidad en su trabajo. Si a un programador se le da el primer trabajo que se le ocurra al jefe entonces el programador cogerá un mal ritmo.

Lo que hay que evitar por todos los medios es que el programador se pueda quedar desocupado. Si el programador esta desocupado empecerá a pensar cosas como ¿estoy perdiendo el tiempo? ¿Deberia hablar con el jefe? ¿..?  (seguro que esto te suena) etc.. y no estará concentrado en la tarea lo cual le hace no solo hacer la tarea mas lenta si no que estará predispuesto a hacer las cosas peor.

Es mejor bombardear al programador con curro que tenerlo haciendo cualquier cosa.

Desarrollo enmarcado

La mayor técnica de desarrollo en equipo que se usa en las empresas (no por su efectividad si no por su simplicidad) es empezar a echar líneas de código a ver lo que sale.

Si las cosas se piensan mejor, se pueden pensar una serie de directrices que deben seguir los programadores ya que “la traducción” del negocio a líneas de código se hace con una relación más o menos mecánica.

Por ejemplo, si se tiene que hacer una aplicación que guarde informes que siempre tienen tres partes bien diferenciadas entonces:

•        A ver lo que sale: Se hace la división de alto nivel del trabajo que el responsable considere oportuno (tu las ventanas, tu guardar en base de datos, tu la ventana de informe de gasto que tiene una lógica mas compleja, etc…) y cada programador se pone a la tarea. Las fronteras van a apareciendo a medida que se desarrolla y se resuelven como se puede
•         Enmarcado: Se considera todo el problema sin dividirlo y se define una base que al crecer puede dar una solución al problema. Primero se desarrolla un CORE que crea un informe base que es común y es muy configurable para poder dotar a cada informe de su forma definitiva. Cada programador parte de ese CORE para implementar su tarea.

Mucho ojo con el desarrollo enmarcado ya que conceptualmente todo es muy bonito pero los problemas de verdad (los que hacen perder tiempo o pueden tumbar una idea) aparecen siempre a bajo nivel. Se debe tener una CORE maduro antes de empezar a programar y uno de los programadores que participaron en el CORE debe de hacer uno de los informes. Esto último es importante ya que por muy bien que se piense el marco de trabajo cuando se divida el trabajo (dentro del marco) empezaran a aparecer problemas y habrá que ajustar el marco. También es importante elegir el (o los) informe que tiene que hacer el programador del CORE, tiene que ser lo mas representativo posible.