Blog jubilado de Paco Ros

Fue bonito mientras duró

Usa algú el teu programa?

Posted by Paco Ros en 24 \24\UTC enero \24\UTC 2009

Actualment estic treballant en un parell de projectes alhora on es dóna la circumstància de que hi ha una forta interactivitat entre els desenvolupadors, els clients, els caps i la direcció.

Cada un d’aquests components té una determinada tendència quant a la seva manera de pensar es refereix i tenir-los a tots contents no és una tasca fàcil.

He estat cercant recursos a la web sobre management i, per a la meva decepció hi ha poca cosa nova a l’horitzó i la majoria de tècniques cauen en els mateixos tòpics i errors ja que tendeixen a fer simil·lituds entre el món del desenvolupament de programes informàtics i altres disciplines fortament arrelades a les que es fa una descomposició de les tasques que han de fer les persones molt minuciosa, mentre que la clau està en una correcta definició de l’objectiu i en la relació entre totes les parts implicades.

L’objectiu

Tota la descomposició en tasques i la seva assignació a persones es converteix en una disciplina pròpia que pot arribar a fer perdre l’objectiu final que tot desenvolupament hauria de ternir:

Crear programes útils que es facin servir quant més millor

Aquesta afirmació, que pareix una obvietat, no es compleix en la majoria de casos i moltes vegades no ho fa perquè l’objectiu de l’equip ha estat desvirtuat i ha canviat per varis motius:

  • Interès de la direcció en generar ingressos: provoca que l’objectiu sigui lliurar el producte i desaparèixer, amb la qual cosa es creen productes que no són realment útils o no fan el que han de fer, els usuaris finals no el fan servir i els programadors no estan disponibles perquè ja s’ha pagat la factura i han desaparegut.
  • Els desenvolupadors fan més projectes dels que en tenen capacitat: provoca la introducció de massa bugs per manca de temps efectiu per desenvolupar-los. El client no confia en el programa perquè dóna massa errors o fa les coses malament i s’estima més fer servir altres eines per treballar com les suites ofimàtiques o paper i bolígraf. Tampoc hi ha temps disponible per a corregir els bugs amb efectivitat.
  • Els usuaris volen fer la feina dels analistes funcionals: provoca canvis constants als requeriments i una inexistent descripció de les funcions reals dels usuaris o, fins i tot, la inexistència d’usuaris capacitats per a dur a terme les tasques definides als requeriments. Finalment, el programa no el fa servir cap usuari perquè allò que fa no s’ha fet mai i no és responsabilitat de ningú.
  • Manca de capacitat tècnica dels caps de projecte: provoca que s’obligui als desenvolupadors a efectuar tasques tècniques inverosímils, a fer mal ús de llenguatges, bases de dades o llibreries que acaben provocant implementacions imprecisses respecte dels requeriments reals. El problema acaba arribant als usuaris que veuen com el programa no fa el que necessiten i no l’empren.
  • Manca d’objectius únics que es dóna quan l’objectiu dels programadors és acabar un mòdul, el dels caps de projecte, lliurar un programa, els de la direcció cobrar-lo el més aviat possible i el del client que faci una cosa fantàstica que ha vist a una altra banda: provoca que l’usuari final acabi treballant amb un programa que no s’assembla per res a la seva realitat del dia a dia.

Quina és la clau que permet desenvolupar programes realment útils? Un compromís absolut de tot el col·lectiu implicat en treballar sobre allò que és coneix, que ho faci bé i que els usuaris finals disfrutin de fer-los servir fins al punt de que el programa es converteixi en una part imprescindible del seu dia a dia.

Per aconseguir-ho, més enllà de l’aplicació de totes les tècniques de management que podem trobar (metodologies clàssiques, àgils, pròpies, diagrames varis estàndards o casolans, gestió de riscs…) és conèixer bé a les persones i saber entendre quines són les prioritats de cada una provocant una doble, triple, quàdruple o quíntuple moral per tal de tenir-los a tots contents.

Els programadors

Per a començar, cal conèixer molt bé als programadors i saber quines són les seves inquietuds i objectius a la vida. En podem trobar de moltes castes i tots són profitosos sempre. En general hi ha persones apassionades per la informàtica o el desenvolupament i persones sense cap interès que van a treballar per a cobrar a final de mes i complir professionalment amb la seva feina.

Dels primers podem esperar innovació i dels segons un gran compromís quant a plaços es refereix. La millor manera de motivar-los és amb nous reptes i amb diners respectivament.

Els clients

També cal conèixer molt bé el client. El pitjor que pot passar a un projecte és haver de recollir els requeriments d’una persona que, relament, no treballa en allò que defineix. Sempre s’ha de procurar parlar amb l’usuari real, encara que sigui per corroborar el que ha contat una tercera persona.

Jo estic molt acostumat a iniciar els projectes en dues fasses: un plec tècnic on s’indica l’abast del programa a desenvolupar (què es farà i què no) i després un análisi on es detallarà exactament com s’ha de comportar cada funcionalitat pressupostada i quàntes dades s’hauran de moure i emmagatzemar.

Sovint a la fasse d’análisi s’acaben demanant coses diferents a les pressupostades. És un problema de la natura del desenvolupament de programes i afecta en primer lloc al plaç d’entrega i en segon lloc al cost del projecte. La millor solució al problema passa per utilitzar un cicle de vida iteratiu, és a dir, desenvolupar allò que s’ha acordat i un cop que estigui acabat i s’estigui fent servir pressupostar i desenvolupar les millores desitjades. És important detectar aquest problema a temps perquè pot suposar dupliar o triplicar el volum del projecte tant en feina com en cost.

Addicionalment, ajuda als clients que demanen més del que necessiten a ajustar-se a les seves necessitats reals propiciant un prorama més eficaç i menys costós.

Les iteracions es poden basar en la progressiva automatització de les funcionalitats. Sovint el client vol pitjar un botó i que tot es faci tot sol mentre que no costa gaire haver d’apretar-ne un parell en una primera fase i millorar l’automatització en fases posteriors, tanmateix els processos massa automatitzats acostumen a escapar a l’enteniment dels usuaris que no conèixen els efectes secundaris d’aquells processos automàtics tan llargs i complexos que potser afecten a tot el sistema.

La direcció

Per una altra banda hi ha la direcció que és alhora la més complicada de convèncer i la que més saviesa ens pot aportar. Passa que la direcció sol tenir bons coneixements en termes de recursos i doblers, quant el desenvolupament de programes és, en una gran part, un problema de la relació entre persones.

Cal explicar-los que la capacitat d’un programador decau després de les 6-7 hores de treball intensiu i que estan tractant amb un recurs molt escàs amb una taxa d’atur pròxima al 0% així que és quasi impossible augmentar la producció de programes amb més dedicació i que tampoc es millora injectant recursos (programadors) a la meitat del projecte(*)

També és molt important la seva col·laboració en cas de conflictes amb els clients, ja que sovint la solució passarà per una ampliació del projecte al contracte i, de no fer-ho, l’empresa pot estar perdent una oportunitat de negoci.

(*) Si que es pot fer si el projecte usa tecnologies molt conegudes i està prou modularitzat.

Altres

Per últim hi ha un conjunt de terceres parts afectades que han de desenvolupar una part del projecte. La meva experiència amb les terceres parts és molt negativa, així que procur evitar que el bon funcionament del programa depengui de la feina d’un tercer, tanmateix les relacions amb tercers solen estar regulades contractualment, així que el millor és acabar la feina fent que el programa sigui útil i usable i donar totes les facilitats possibles a la tercera part de manera que pugui acabar la seva feina sense afectar a la funcionalitat principal del programa. Si desenvolupau amb un model de tres capes, evitau en tot el possible que la tercera part hagi d’atacar la base de dades i oferiu sempre funcionalitat de la capa de negoci per que puguin fer la seva feina.

Factors d’èxit

En general, hi ha alguns factors que ajudaran a que el projecte sigui un èxit (això és, que el facin servir i sigui útil):

  • Tenir un equip de desenvolupadors tècnicament competents i ben compenetrats.
  • Explicar un cop i un altre al client que podrà treballar, que serem allà quan ens necessiti i que el que es veu a les pel·lícules és ciència ficció, però que es pot parlar en una fase posterior.
  • Explicar a la direcció que cal una planificació prèvia de les persones i que és molt negatiu alterar-la. Addicionalment ha de saber que en l’actualitat el personal tècnic competent és mal de trobar.
  • Evitar les implicacions excessives de terceres parts i procurar que la seva feina no pugui afectar al funcionament principal del programa.
  • Posar a disposició dels usuaris finals les parts acabades del programa el més aviat possible i dedicar immediatament un apartat a la correcció de bugs i millores senzilles que milloraran la relació amb el client final.

Conclusió

Sempre serà preferible un programa útil que no fa tot el desitjable que un que ho fa tot però no és útil o no ho fa bé. Cap dels dos és un èxit, però el primer ho pot ser a una segona o tercera fasse, mentre que el segon no ho serà mai.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: