Vida digital más restrictiva que la real

Vaya por delante que siempre he odiado los sistemas DRM en cualquier aspecto porque desvirtuan la transparencia de la red.

Los editores de contenido ya hace tiempo que han entrado como elefantes en el mundo digital, relamiéndose por generar jugosos beneficios y ahorrarse los costes de imprenta y personal (sí, muchos aún piensan que el contenido se genera solo) y a veces nos muestran aberraciones como la que voy a relatar.

Me encanta el mundo del motor y los domingos aprovecho para leer alguna publicación del mundillo. El mecanismo utilizado consiste en ir al kiosco y hacerme con un ejemplar de Coche Actual o Auto Bild que son revistas más barats que Autopista, Automóvil, Car and Driver u otras en las que en tiempos pasados ha gastado barbaridades de dinero y de las que aún conservo montañas de ejemplares viejos.

Hoy he comprado Coche Actual porque el tema de portada de AutoBild no me interesaba demasiado y me he econtrado con una oferta de lanzamiento de la edición digital de la revista a través de http://www.motorpressdigital.com

El sistema, que incialmente parece una buena idea, se apoya en una segunda empresa llamada Zinio Digital que gestiona el proceso de compra – bien – a través del típico carrito de la compra y que conserva una librería de revistas adquiridas que se pueden descargar en cualquier momento – excelente –

Como están de promoción, se pueden descargar algunos ejemplares gratuitamente, así que me he registrado y he adquirido por 0 euros un ejemplar de Coche Actual y otro de Autorpista. El sistema ha sido muy satisfactorio hasta que ha llegado el momento de visualizar la «compra» donde son todo problemas:

Es obligatorio instalar un programa llamado Zinio Reader que sólo está dsiponible para Windows y Mac. Como estoy con el portátil, he instalado la versión para Mac, resultando en un programa es realmente nefasto: amén de que es necesario aceptar varias veces las condiciones (ridículas, abusivas y en inglés) de la licencia abre las publicaciones adquiridas a modo de lector de PDF, pero donde la visualización del ejemplar se hace a página completa y con una función de Zoom que no permite desplazarse dentro del documento. Se puede ver una captura de pantalla para contemplar la similitud del programa con un lector de documentos PDF.

Obviamente, cualquier lector de PDFs sería mucho más útil, así que me he desplazado al directorio donde se guardan las publicaciones adquiridas con la intención de abrir mi «adquisición» con un programa para leer PDFs o cualquier otro formato de fichero para la presentación de documentos maquetados. Como era de esperar, todas mis adquisiciones son ficheros con la extensión zno que únicamente pueden ser abiertos por el programa Zinio Viewer. Fisgando un poco, he podido comprobar que en esencia se trata de un PDF cifrado digitalmente con información adicional sobre el identificador de cliente y el identificador de editor.

Resumiendo, mi situación actual es tal que adquiero mi ejemplar (podría ser suscriptor y lo tendría en el buzón de casa) y me lo llevo. Puedo leerlo cuando yo quiera y donde yo quiera. También puede leerlo mi mujer y puedo prestárselo a un amigo si le interesa algún vehículo de los que aparecen en la publicación.

Cuando he leido la revista, puedo tirarla, guardarla en un armario y leer una prueba del Renault Clio Williams de hace más de 10 años. El ejemplar de hace más de 10 años también puedo prestárselo a un amigo y éste puede leerlo con sus propios ojos, con gafas, en el WC o en la terraza de su casa.

El cambio tecnológico que me proponen al principio me resultó muy atractivo porque me encantaría poder prescindir del espacio que ocupa el papel amén del «pecado ecológico» que cometemos cada vez que compramos algo de papel. Adicionalmente, podría seleccionar las pruebas por modelos y guardarlas separadas entre otra información que se peude encontrar en la web o enviársela por correo a un amigo que baja a trabajar en Tren para que la lea en su iPhone por la mañana.

El resultado ha sido un fichero único, inmanejable, ilegible, intocable y para que necesito un software cerrado, privativo y con unas condiciones de uso altamente restrictivas para leerlo. Un software y un formato de fichero que no cumplen ningún estándar y que hoy funcionan en sistemas propietarios y privativos de las empresas Microsoft y Apple sin ninguna garantía de que vayan a hacerlo en el futuro, amén de que mi adquisición digital debería estar cubierta por una garantía de 2 años según marca la LOCM vigente en España.

Por una parte admiro a los directivos de la empresa Zinio por engañar a tantos editores con los símbolos del dólar en los ojos que están condenados a la desaparición por no comprender cómo funciona la distribución digital de contenidos y por otra parte me entran unas ganas tontísimas de montar una web de compra de publicaciones en PDF de toda la vida.

Ni que decir tiene que NO pienso gastar ni un céntimo en este sistema.

Usa algú el teu programa?

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.

Trasllat del blog

Duc molt de temps sense escriure res al blog.

Estava força desactualitzat i m’he cansat d’actualitzar WordPress un cop i un altre, així que he procedit a dur-lo cap a wordpress.com i ara mateix es troba en procés de transferència de DNS. En general el procés no és còmode, he pogut migrar tots els posts, però he hagut de corregir molts de problemes amb els jocs de caracters i he donat per impossible recuperar el contingut quant a binaris es refereix, ja que wordpress.com és molt limitat a la seva versió bàsica en aquest aspecte i actualitzar totes les adreces dels posts és complicat, ja que no tenc accés directe a la base de dades.

La nova adreça del blog és https://pacoros.wordpress.com

Per la meva part, la feina m’ha absorbit una part important del temps, així com els estudis a la UOC, dels que esper desfer-me’n en uns 12 mesos des d’aquest moment i que seran els culpables de que aquest blog no estigui actualitzat una bona temporada.

D’altra banda, m’he iniciat en el món de la fotografia i m’he comprat una Nikon D60 molt bàsica, però que ja me va bé per anar practicant i anar penjant algunes fotos a flickr alhora que aprenc tot el que puc del grup de fotografia al que em va convidar en Xisco.

Els que em seguiu via RSS, podeu actualitzar l’adreça del fil cap a https://pacoros.wordpress.com/feed ja que l’antic blog quedarà inaccessible en breu. Gràcies per tenir-me enganxat als vostres agregadors :-)