Barrapunto
La información que te interesa
http://especiales.barrapunto.com/

Title    Proyectos de informática: ¡Reacciona antes de estrellarte!
Date    Lunes, 18 Julio de 2011, 07:30h
Author    mig21
Topic   
from the autoayuda dept.
http://especiales.barrapunto.com/article.pl?sid=11/07/18/0719242

El objetivo de este texto es intentar ser útil a quienes se hayan topado con alguno de los siguientes problemas: el mantenimiento de lo existente en producción se come el grueso del tiempo de desarrollo, cualquier cosa compleja o ambiciosa se torna en imposible, puesto que, por ejemplo, la capacidad del equipo equivale al 20% de lo que debería por no estar organizados adecuadamente, la situación lleva años estancada, y no se hace nada que pueda cambiar esto en lo sustancial. Siguen en la página ampliada los consejos para hacer autocrítica, identificar y prevenir los problemas y tratar de mejor el presente y el futuro.


1. Autocrítica y consciencia de la situación.


2. Identificar los recursos que dispones

3. Prevención de problemas

4. Identificación y gestión de los problemas en curso

Partiendo de la base que lo que tenéis en uso/producción es "más o menos usable/vendible", y que lo queréis hacer sobre la marcha (1):
Paso 1, localización y segmentación de problemas:

A) Dividir entre lo que afecta (A.1) y lo que no afecta (A.2) a la experiencia del usuario.
B) Diferenciar lo que no funciona o funciona pero no es escalable (B.1; crashes y problemas que ocasionan "consumo" del personal de soporte técnico, querys de 5 minutos, etc.), y lo que es horrible a nivel de código "pero funciona bien como caja negra y no hace crash nunca" (B.2).
C) Diferenciar lo que funciona pero supone gastos fijos (C.1; e.g. cosas sin automatizar que requieren procesos manuales como pueda ser el despliegue de contenido a N nodos remotos, el no usar gestores de versiones adecuados, no tener backups, etc.), de lo que no tiene coste dejándolo como está (C.2).

Tras el primer paso, el problema se reduce a modificar: A.1, B.1, C.1 (si lo queréis es vender un buen producto, reduciendo los fallos y el tiempo dedicado a mantenimiento).

Paso 2: priorización

Pasada de priorización #1 (sobre A.1,B.1,C.1): Elimina todo lo que veas en A.1, B.1, C.1 que puedas dejar de hacer, por no ser vital para el negocio, de A.1, ya sea simplificando procesos o haciéndolo de otra manera (e.g. cambiar Intranet hecha "a mano" por un CMS, sin tunear a medida, algo austero pero que cumpla lo mínimo que necesitáis). Tras la limpieza, quedaría: A.1', B.1', C.1'

Pasada de priorización #2 (sobre A.1, B.1): Juntad el 80% de los casos más graves de A.1' y B.1', que se puedan resolver en el 30% del tiempo sin generar dependencias en los casos restantes (tuneado de la "Regla de Pareto" pero con un 80-30 en lugar del 80-20). Etiquetad esos casos como "AB.1-rápido", el resto, dividirlos entre "AB.1-fácil-pero-lento" y "AB.1-muy-difícil"

Pasada de priorización #3 (sobre C.1): Determinar los gastos fijos que suponen, separando en dos grupos: C.1-pinchazo (hasta el 5% de los costes fijos de la empresa, i.e. la empresa podría ir boyante, pero las chapuzas se comen los beneficios) y C.1-sangría (riesgo de cerrar la empresa).

Paso 3, ejecución:

Pre-ejecución: No asignar a nadie una tarea para la que no esté capacitado (la buena voluntad no siempre es suficiente), la pueda hacer en un tiempo razonable, y el resultado sea de calidad. Si esas restricciones no son posibles, volved al paso 1, y simplificar más todavía las tareas hasta que las podáis acometer (si es imposible, y depende del cierre de la empresa, pagad a uno o varios figuras un pastón -e.g. pasta por delante y además, si en 3 años le va bien a la empresa, te llevas un X como bonus-).

Ataque #1: "C.1-sangría"
Ataque #2: "AB.1-rápido"
Ataque #3: "AB.1-fácil-pero-lento"
Ataque #4: Volver al Paso 1, con sólo "AB.1-muy-difícil" y "C.1-pinchazo"
5. Enfocar el presente y el futuro

Suponiendo que ya conoces la situación, eres consciente de tus capacidades y la de quienes están a tu cargo, puedes prever/evitar problemas, y has reenfocado/solucionado los problemas del "pasado". ¿Ahora qué? ¿Cómo enfocar el camino?

5.1. Visualiza dónde estás y a dónde te diriges

Si el desarrollo está estancado, y no cambias nada, dentro de dos años, suponiendo que puedas mantener el negocio en funcionamiento, seguirás prácticamente igual. Estando en situación de "detenimiento psicológico", haciendo las cosas a remolque, anclado en el mantenimiento, es equivalente a estar parado: arrancar no será fácil. En mi opinión, lo que más sirve es tener una visión del camino a dónde quieres/puedes ir, e ir haciéndolo más o menos de acuerdo a un programa, susceptible de cambios por los requisitos que puedan llegar de fuera, etc.

Si no tienes ni idea de a dónde quieres ir, ni por donde, ni con quien, lo tienes crudo. Si tienes un plan a largo plazo, aún cuando este no sea el mejor del mundo, es infinitamente mejor que ir a la deriva, que te llevará a estrellarte tarde o temprano, pues los problemas no se solucionarán solos, sino que irán a peor.

5.2. Multiplica la capacidad de programación

En la industria del software, descontando la parte del espectáculo, el hacerse la foto, vender la moto, y demás cuentos, lo que acostumbra a determinar la supervivencia del negocio es el resultado de trabajo enfocado en la parte de desarrollo. Si el desarrollo no funciona adecuadamente, el negocio malvivirá de los éxitos del pasado o cerrará en el largo plazo, salvo que no tenga competencia, claro está. La parte clave en el desarrollo es el programador, quien marca la diferencia. Por mucho que se haya pretendido, principalmente por parte de consultoras plagadas de gestores mediocres, el programador no es ninguna commodity, desde el momento que un programador excelente puede ser de 5 a 20 veces más productivo que uno "normal" (y como normal no incluyo a los que son más perros que un trillo, que como en todas las profesiones, haylos). Hay gente con más y menos talento, más y menos formación, y si bien no puedes convertir a un burro en una eminencia, la mayoría de la gente que programa tiene mucho potencial de mejora. Se me ocurren las siguientes claves de la "reprogramación de programadores" (ejemplos, si alguien tiene más, que lo comente):
5.3. Usa las mejores técnicas y herramientas


Sintonía de hoy:

Iron Maiden - Wasted Years


Links

  1. "proyección psicológica" - http://es.wikipedia.org/wiki/Proyecci%C3%B3n_(psicolog%C3%ADa)
  2. "1" - http://preguntas.barrapunto.com/comments.pl?cid=1263353&sid=86323&tid=83
  3. "programar bien es difícil, y que no se aprende en 21 días" - http://norvig.com/21-days.html
  4. "Jenkins" - http://en.wikipedia.org/wiki/Jenkins_(software)
  5. "usando generadores de "workspaces", es para alucinar en colores" - http://www.google.com/#q=cmake+problems
  6. "Iron Maiden - Wasted Years " - http://www.youtube.com/watch?v=SwB9zg7Tbx8

© Copyright 2017 - Barrapunto S.L., All Rights Reserved

printed from Barrapunto, Proyectos de informática: ¡Reacciona antes de estrellarte! on 2017-12-16 20:39:29