Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

L’empresa informàtica

Apliquem tot l’anterior al nostre sector: quin paper té el software a l’economia, com es construeix un model de negoci de software, com es planifiquen les operacions i quina responsabilitat comporta la professió.

Utilitzarem el canvas, que s’explica a proposta de valor. Si encara no l’heu vist, llegiu primer aquella secció.

Software a l’economia

El software és omnipresent:

  • Substituint negocis tradicionals, com llibreries, publicitaris, música, telecomunicacions, selecció de personal, serveis financers, etc.
  • Menjant-se la cadena de valor de diferents negocis, tot i no substituir-los, com a la fabricació de cotxes, la carrera espacial, la logística i la distribució, etc.

El progrés humà podria veure’s com a quatre revolucions industrials:

  1. El vapor, l’aigua i la producció mecànica.
  2. La divisió del treball, l’electricitat i la producció massiva.
  3. L’electrònica, la informàtica i la producció automatitzada.
  4. L’anàlisi de dades, els dispositius mòbils, la intel·ligència artificial (avui, sobretot generativa i models de llenguatge), la robòtica i la genòmica.

No sempre podem fer investigació des de l’empresa. Però l’ús de les tecnologies de propòsit general ens dona un marc d’innovació que podem integrar en el nostre negoci.

La tecnologia ha transformat els negocis i també la societat, produint canvis disruptius a cadascuna d’aquestes revolucions que han afectat les persones i les seves feines.

La IA generativa n’és el darrer episodi, i ens toca de ple. Un exemple concret: l’accés al coneixement ja no passa necessàriament per visitar portals indexats, sinó per preguntar-ho a un assistent que respon i cita. Això mou la cadena de valor de qualsevol negoci que vivia de ser trobat (mitjans, portals de contingut, i també qui els construeix per encàrrec), i obliga a replantejar què s’hi ven. Ho veiem amb detall al capítol de màrqueting.

Un mercat global

El software és el producte més globalitzat que existeix. Distribuir-ne una còpia més no costa pràcticament res, no passa per cap duana i no s’ha de transportar. La conseqüència és que el mercat d’un equip de desenvolupament és global per defecte, i ho és en les dues direccions.

En contra:

  • El vostre competidor pot ser a qualsevol lloc del món, i no cal que el client se n’assabenti.
  • El client pot contractar directament equips a països amb estructures de costos molt més baixes (offshore), o a països propers i amb horaris compatibles (nearshore).
  • Això posa una pressió permanent sobre les tarifes. Convé assumir-ho aviat: una empresa petita d’aquí no guanya una guerra de preus contra una estructura de costos que és una fracció de la seva.

A favor:

  • Podeu facturar a clients de fora sense moure-us, i sense cap cost de distribució. Per fer-ho amb empreses de la resta de la UE cal estar donat d’alta com a operador intracomunitari, un tràmit que triga i que val la pena fer abans de necessitar-lo.
  • El mercat potencial és tan gran que els nínxols petits es tornen viables. Un producte molt especialitzat, que en un mercat local no tindria prou clients, pot tenir-ne prou a escala mundial.

A més, la vostra pròpia cadena de valor ja és global encara que no ho hàgiu decidit: el núvol on desplegueu és a un altre país, les llibreries que feu servir les mantenen persones que no coneixereu mai i part de la funcionalitat depèn d’APIs de tercers. És la dependència que ja apareix als socis clau, vista des de l’altra banda.

Què no es pot deslocalitzar

Si la competència en preu està perduda, la pregunta útil és què queda que no es pugui contractar a distància. Aquí és on competeix de veritat una empresa de proximitat:

  • Entendre el negoci del client, i no només el seu encàrrec.
  • La llengua, la cultura i el fus horari compartits.
  • El coneixement de la normativa que afecta el client aquí: protecció de dades, facturació, requisits del seu sector.
  • La presència física quan cal, i tenir algú responsable a qui reclamar.

Cap d’aquestes coses no surt a una comparativa de tarifes per hora, i totes són les que fan que un client us truqui a vosaltres.

La regulació com a força de mercat

Que siguem a la Unió Europea no és només una llista d’obligacions a complir: és el que dona forma al mercat on competireu.

El mecanisme té nom, l’efecte Brussel·les, descrit per Anu Bradford. Qui vulgui vendre als centenars de milions de consumidors europeus ha de seguir-ne les normes, i com que mantenir dos sistemes diferents surt car, moltes empreses acaben aplicant la norma europea a tot el món. Així, una regulació pensada per al mercat interior es converteix en estàndard global. El Reglament General de Protecció de Dades (RGPD, GDPR en anglès) n’és el cas més clar.

Per a una empresa petita del sector, això té quatre conseqüències pràctiques:

  • És un cost real. Complir consumeix hores d’anàlisi, desenvolupament i documentació. S’ha de pressupostar, no descobrir a mitja feina.
  • Genera demanda. Cada norma nova obliga milers d’empreses a adaptar els seus sistemes, i aquesta feina la fa algú. L’adaptació al RGPD va ser un sector sencer; l’accessibilitat, el reglament d’IA i la facturació verificable generen el mateix ara. En aquest darrer cas l’obligació arriba per partida doble, perquè afecta qui factura i també qui li fa el programa de facturació.
  • És una barrera d’entrada que us pot protegir. Un proveïdor de fora que no pot o no vol assumir aquests requisits queda fora de bona part del mercat, i això compensa una part de la diferència de tarifes.
  • És coneixement no deslocalitzable. Enllaça directament amb el punt anterior: saber quina normativa afecta el client és un avantatge que no es contracta a distància.

Un exemple: on són les dades

El RGPD no prohibeix fer servir proveïdors de fora de la Unió, però sí que restringeix les transferències de dades personals fora de l’Espai Econòmic Europeu. Només es poden fer si el país de destí té una decisió d’adequació, o bé amb garanties com les clàusules contractuals tipus, que després de la sentència Schrems II obliguen a avaluar si la legislació d’aquell país respecta els drets dels afectats.

El cas dels Estats Units ha estat inestable: un primer acord es va anul·lar, el que el va substituir també, i el que hi ha ara ha estat impugnat des del primer dia. Qui hi construeix a sobre assumeix que pot tornar a canviar.

Si el vostre client és una administració pública, s’hi afegeix l’Esquema Nacional de Seguretat, que regula expressament la contractació de serveis al núvol, i és habitual que els plecs exigeixin que l’allotjament i el suport siguin dins de la Unió.

La conseqüència pràctica és que triar la regió del vostre proveïdor de núvol no és una decisió tècnica, és un requisit contractual. Heu de saber on es processen les dades, mantenir la llista de subencarregats i poder demostrar-ho.

En la direcció contrària, el reglament europeu de dades (Data Act) obliga els proveïdors de núvol a facilitar el canvi a un altre proveïdor i limita el que us poden cobrar per endur-vos-en les dades. Marxar continua costant feina, però ja no hauria de costar una factura de sortida.

La llista concreta de normes que us afecten i quan s’apliquen la teniu a impacte social.

La cara tècnica d’aquesta obligació, quins camps són dades personals i com es guarden, es tracta a dades personals.

Finalment, el context ha canviat els últims anys: el gir cap al nearshoring i la sobirania digital europea han creat demanda de proveïdors i allotjament dins de la UE, sovint per motius normatius. Per a una empresa d’aquí, això és una oportunitat concreta i no només un debat polític.

Estratègia de negoci

La innovació permet a l’empresa entrar al mercat i adaptar-se als canvis. L’empresa software ho pot fer de diverses maneres:

  • Fent la creativitat un hàbit (cultura corporativa).
  • Tenir un cicle de desenvolupament (SDLC) àgil.
  • Tenir un espai de treball (físic o virtual) funcional, flexible i mòbil. Tenim eines de gestió de codi i DevOps al nostre abast.
  • Incorporar la IA generativa a la pràctica de treball: assistents dins del cicle de desenvolupament. Canvia l’estructura de costos i, per tant, què podem oferir i a quin preu.

Què necessita el món empresarial del software?

  • Hi ha negocis completament software:
    • Creació, adaptació, ampliació i manteniment de programari estàndard i a mida.
    • Economia col·laborativa.
    • Programari com a servei (SaaS).
  • Tenim la tasca de la digitalització d’empreses:
    • Presència a internet (web, xarxes).
    • Estratègia de comunicació i màrqueting.
    • Venda online.
    • Digitalització dels processos de gestió (CRM, ERP, treball col·laboratiu, teletreball).
  • Tenim feina a les activitats de la cadena de valor:
    • Serveis dins de les empreses, especialment en automatització, qualitat, anàlisi de dades i business intelligence.
    • Interacció entre empreses (B2B), com adaptació de protocols i APIs REST.

La nostra estratègia d’entrada al mercat hauria d’incloure:

  • La visibilitat d’un equip innovador i ben format.
  • La nostra cartera de solucions i la nostra creativitat.
  • Solucions sensibles a l’èxit del client a l’estructura de costos (per ús).
  • Bona comunicació escrita en les propostes tècniques, justificades i amb detall.
  • Codi font lliurat al client amb la promesa que podrà ser assumit per qualsevol altre proveïdor.

Deute tècnic

El deute tècnic és el resultat de decisions tècniques dolentes o subòptimes que finalment generen problemes per a mantenir i expandir una solució. Com a integrants de l’economia del software, tenim una responsabilitat en reduir aquest deute.

La raó del deute tècnic pot ser:

  • Una decisió de negoci conscient: sortir abans al mercat acceptant que després caldrà refer-ho. És legítim, sempre que quedi anotat i tingui data de retorn.
  • Un mal disseny o una mala implementació, que ningú no ha decidit i ningú no vigila.

La diferència és qui mana: el primer és deute que es demana, el segon és deute que s’acumula sol. Si no es paga, en ambdós casos el resultat és el mateix: un codi que no s’entén, que no és robust, que està mal documentat, que provoca infelicitat als programadors i que molt difícilment es pot modificar o estendre.

Què podem fer per reduir el deute?

  • Tenir clara l’estratègia tècnica inicial. Fer una bona avaluació de les possibilitats, i fer-ho amb un objectiu ben definit.
  • Tenir un responsable d’arquitectura.
  • Dissenyar amb la seguretat com a requisit.
  • Pensar com es podrien substituir els components o llibreries de la nostra solució.
  • Mantenir la refactorització a petita escala dins del procés, millorant el codi.
  • Tenir testos de regressió automatitzats.
  • Millorar la cobertura dels tests.
  • Reescriure codi, si cal. És un moviment perillós, però de vegades necessari.
  • Fer una bona documentació.
  • Tenir bons canals de comunicació per a gestionar problemes.

Model de negoci

El nostre model de negoci software ha de descriure el tipus de negoci dins del context del mercat, a qui va dirigit i com s’aconseguiran els ingressos necessaris.

El model de negoci descriu com fa una organització per a crear, lliurar i capturar valor en un context econòmic, social o cultural.

Si utilitzem el canvas com a eina per a definir el model de negoci, podem trobar els següents aspectes.

Segments de clients

Segons a qui venem:

  • B2B (venda a altres empreses)
  • B2C (venda a usuari final)
  • C2C (som el mercat on es troben compradors i venedors).

Dins de cada cas, cal concretar encara qui decideix la compra, qui la paga i qui farà servir el producte, que sovint no són la mateixa persona.

Tipologia de producte

No és el mateix segmentar clients que classificar el producte, tot i que sovint es barreja. Podem caracteritzar el producte segons diversos paràmetres.

Segons l’àmbit:

  • Estàndard (“de caixa”): generalista, solució global. Pot permetre configuració o personalització.
  • A mida: fet a mida, per a un problema concret del client.
  • Híbrid: producte estàndard que permet desenvolupaments a mida gràcies a una API o similar. Pot ser obert o tancat.

Segons la plataforma destí:

  • Per a una o diverses plataformes: Android, iOS, etc.
  • Plataforma agnòstica. Habitualment basada en web.

Segons la interacció dels usuaris:

  • One-to-many (clients)
  • Many-to-many (usuaris productors i usuaris consumidors).

Segons el model de llicències:

  • Propietari
  • Open-source

Proposta de valor

Explicar la proposta de valor: una afirmació que identifica els beneficis clars, mesurables i demostrables que els clients obtenen en comprar cadascun dels productes o serveis. Caldria explicar-ho per cada segment.

En software significa explicar almenys les funcionalitats, el rendiment, l’arquitectura i el model de suport.

Canals

Fases:

  1. Coneixement: web, màrqueting online.
  2. Avaluació: versió gratuïta limitada, període de prova.
  3. Compra: contracte, comerç electrònic, botiga d’aplicacions.
  4. Lliurament: on-premise vs off-premise (cloud) vs híbrid.
  5. Suport: issue/bug tracker, CRM.

Segons el lliurament:

  • On-premise: el software s’instal·la i funciona a les instal·lacions del client.
  • Cloud-based: el software funciona al núvol o a un proveïdor d’allotjament (SaaS).
  • Híbrid: barreja els dos anteriors. Hi ha instal·lació, però també es compta amb el núvol per al seu funcionament.

Relació amb els clients

Segons el model de negoci. Podem utilitzar eines CRM integrades en el nostre ERP, comunitats a les xarxes, auto-servei.

Ingressos

Podem tenir un o més fluxos:

  • Aplicacions de pagament. Els clients paguen per instal·lar un producte.
  • Publicitat a l’aplicació. L’aplicació és gratuïta, però veneu llocs d’aplicacions per a publicitat.
  • Compres des de l’aplicació. L’aplicació és gratuïta, però guanyes venent productes o serveis mitjançant una aplicació.
  • Subscripcions. Els usuaris paguen anualment o mensualment una quota de subscripció.
  • Model d’ingressos de programari basat en l’ús. Els clients paguen només pel que fan servir.
  • Desenvolupaments a mida. Els clients paguen per desenvolupar funcionalitats a mida.
  • Càrrecs per suport, serveis empresarials i consultoria.
  • Consum o crèdits. Habitual a les funcionalitats amb IA, on el cost per petició és real i es trasllada al client.
  • Nucli obert (open core) o doble llicència. Una versió lliure i una de comercial, amb funcionalitats o condicions diferents.

Si veneu per una botiga d’aplicacions, compteu que se’n queda una part de cada venda: és un canal que no controleu i que fixa el seu preu.

Activitats clau

  • Programació.
  • Suport i consultoria.
  • Anàlisi, venda o accés a dades.
  • Optimització interna i innovació.
  • Formació contínua.

Recursos clau

  • El nostre codi, que pot ser propietari o open source, i llibreries de tercers.
  • Les nostres dades (com a actius).
  • Programadors que donen valor a l’empresa.
  • Ordinadors.
  • Local físic vs teletreball.
  • Subscripcions a serveis o comptes de desenvolupament.

Costos

Revisar els costos dels recursos clau.

Distingiu els fixos dels variables. Al núvol i a les funcionalitats amb IA la despesa creix amb cada client i amb cada petició, de manera que abans de posar preu a una subscripció heu de saber què us costa servir un client. Si no ho sabeu, no sabeu si teniu marge.

Socis clau

  • Dependència d’empreses tecnològiques.
  • Botigues d’aplicacions, amb les seves normes, tecnologies i comissions.
  • APIs de tercers.

Aquesta dependència no és només tècnica. Un proveïdor pot apujar el preu, canviar la llicència o tancar el servei, i el vostre marge se’n ressent sense que hàgiu tocat res. De cada peça crítica convé saber què costaria substituir-la.

Propietat intel·lectual

El que veneu és codi, i el codi és propietat d’algú. Val la pena saber de qui, perquè aquí es cometen dos errors cars: regalar el que us podríeu haver quedat, i lliurar alguna cosa que no teníeu dret a lliurar.

Com es protegeix el software

El software es protegeix per drets d’autor, no per patents. La protecció és automàtica des del moment en què s’escriu el codi: no cal registrar res. Registrar-lo (al Registre de la Propietat Intel·lectual) només serveix per tenir una prova de la data i l’autoria si algun dia hi ha conflicte.

Els drets d’autor protegeixen el codi, tant el font com l’objecte. No protegeixen ni la idea, ni la funcionalitat, ni l’algorisme en si: qualsevol pot fer un programa que faci exactament el mateix que el vostre, sempre que no copiï el vostre codi.

Sobre les patents, el conveni europeu exclou expressament els programes d’ordinador com a tals. Sí que es poden patentar invencions implementades per ordinador que tinguin un efecte tècnic addicional, però és un procés car i llarg que rarament té sentit per a una empresa petita.

De qui és el codi que escriviu

Depèn de la relació que hi hagi, i la diferència és gran:

  • Si sou treballadors per compte d’altri, la llei ho resol: els drets d’explotació del programa que feu en l’exercici de la vostra feina són de l’empresa, llevat de pacte en contra. El codi que escriviu a la feina no és vostre.
  • Si sou una empresa o un freelance que treballa per encàrrec, no hi ha cap cessió automàtica. Si el contracte no diu res, els drets continuen sent vostres i el client només té una llicència implícita per a la finalitat encarregada.

Aquest segon cas és font de conflictes, perquè el client sol donar per fet que allò que ha pagat és seu. Poseu-ho per escrit sempre, triant entre:

  • Cessió dels drets d’explotació: el client se’ls queda i vosaltres ja no en podeu fer res.
  • Llicència d’ús: el client pot fer servir el software per al que s’ha acordat, però la propietat continua sent vostra.
  • Dipòsit del codi (escrow): el codi font queda dipositat en un tercer i el client només hi accedeix si vosaltres desapareixeu o incompliu. És l’opció intermèdia quan el client vol garanties i vosaltres no voleu cedir res.

I aquí hi ha una decisió de negoci, no només jurídica: si cediu tot el codi a cada client, no podreu reutilitzar mai la vostra pròpia feina. L’alternativa habitual és mantenir un nucli propi que llicencieu a tothom, i cedir només allò específic de cada projecte. És així com una empresa petita es va construint un actiu en comptes de començar de zero cada vegada.

Recordeu també que lliurar el codi font al client, que abans hem posat com a argument de venda, és exactament una d’aquestes decisions. Preneu-la a consciència i poseu-hi preu.

Les llibreries que feu servir

El vostre producte no és només codi vostre: cada dependència que hi afegiu ve amb una llicència i unes obligacions que assumiu en distribuir-lo.

  • Llicències permissives (MIT, BSD, Apache 2.0): podeu incorporar el codi a un producte propietari. L’obligació bàsica és mantenir l’avís de copyright i l’atribució.
  • Llicències copyleft (GPL): si distribuïu un producte derivat, l’heu de distribuir també sota GPL i amb el codi font. Fixeu-vos que l’obligació s’activa en distribuir: si modifiqueu codi GPL i el feu servir només internament, sense donar-ne cap còpia a ningú, no heu de publicar res. La LGPL és més laxa i permet enllaçar-hi sense contagiar tot el producte.
  • AGPL: tanca precisament aquell forat. Considera que donar accés al programa per la xarxa compta igual que distribuir-lo. Si oferiu un servei web basat en codi AGPL que heu modificat, heu de posar el vostre codi font a disposició dels usuaris del servei, i dir “nosaltres no distribuïm res, només oferim un SaaS” no serveix de defensa.

Els dos errors típics són posar codi GPL dins d’un lliurament propietari a un client, i muntar un servei sobre una peça AGPL sense adonar-se’n. Cap dels dos es descobreix fins que algú mira, i llavors la solució acostuma a ser reescriure.

La pràctica sensata és mantenir l’inventari de dependències i les seves llicències, revisar-lo abans de cada lliurament i automatitzar la comprovació dins del cicle de desenvolupament.

La marca

Registrar el nom de la societat al Registre Mercantil no us dona cap dret sobre la marca. Són dues coses diferents i molta gent ho descobreix tard.

  • La denominació social identifica l’empresa davant de l’administració.
  • La marca protegeix el nom comercial amb què us presenteu al mercat, i es registra a l’OEPM per a l’estat o a l’EUIPO per a tota la Unió Europea.

Abans d’imprimir res, comproveu que el nom estigui lliure com a marca i que el domini també ho estigui.

Treballar amb IA generativa

Els assistents de generació de codi ja formen part del cicle de desenvolupament. Com a eina tècnica no ens toca discutir-la aquí, però com a decisió d’empresa té conseqüències jurídiques, contractuals i de preu que convé tenir clares abans, no després.

De qui és el codi que genera un model

Els drets d’autor exigeixen autoria humana. El criteri que s’imposa als tribunals és que allò que ha generat una màquina sense aportació creativa d’una persona no està protegit, mentre que la vostra contribució sí que ho està. En un fitxer on heu escrit la major part i el model ha completat la resta, la vostra part continua protegida i la seva, probablement, no.

Això té una conseqüència contractual directa que sovint es passa per alt: si signeu una cessió de tots els drets sobre un lliurament, hi pot haver parts sobre les quals no hi ha drets a cedir. No prometeu al client una protecció que no podeu garantir, i deixeu escrit al contracte si heu fet servir assistents i en quina mesura.

El risc de contaminació de llicències

Un assistent pot generar codi molt semblant al que ha vist entrenant-se, i part d’aquell codi tenia llicència copyleft. El problema és que això se salta l’inventari de dependències: no arriba com una llibreria que podeu revisar, arriba amb l’aspecte de codi vostre.

Dues mesures raonables: revisar el que genera com revisaríeu el codi d’un tercer, i tenir en compte que les versions de pagament de les eines principals ofereixen indemnització en cas de reclamació per drets d’autor. És un criteri legítim a l’hora de triar proveïdor.

Confidencialitat

Enganxar codi o dades d’un client dins d’una eina de tercers és una comunicació de dades, encara que no ho sembli. Segons què hi poseu, pot ser un incompliment de l’acord de confidencialitat amb el client i, si hi ha dades personals, una comunicació a un encarregat que no heu declarat enlloc.

Val el mateix que hem vist a on són les dades: heu de saber on va a parar i poder-ho justificar. Abans de fer servir una eina, mireu si el pla que teniu contractat entrena amb les vostres dades i on les processa.

La responsabilitat no es delega

Responeu del que lliureu, l’hagi escrit qui l’hagi escrit. Davant del client i davant de la llei, “ho ha generat la IA” no és una defensa. Això inclou els errors, les vulnerabilitats i les llicències del codi que hi hagi a dins.

Hi ha també una obligació formal que agafa moltes empreses per sorpresa: el reglament europeu d’IA exigeix que qualsevol organització que faci servir sistemes d’IA garanteixi un nivell suficient de formació en IA del seu personal, i és de les obligacions que ja són vigents. No hi ha multa directa associada, però sí responsabilitat si algú sense la preparació adequada provoca un dany.

L’efecte sobre el preu

Aquesta és la part que us afecta el pla econòmic. Si una eina us permet fer en tres hores el que abans us ocupava vuit, i factureu per hores, l’única cosa que heu aconseguit és cobrar menys per la mateixa feina. La productivitat se l’emporta el client.

Per això la IA empeny cap als models de preu tancat o per valor: si el que veneu és el resultat i no les hores, la millora de productivitat us la quedeu vosaltres. És una decisió que val la pena prendre abans de fer el primer pressupost.

Un últim avís tècnic amb conseqüències econòmiques: produir codi més de pressa també vol dir acumular deute tècnic més de pressa, i el coll d’ampolla es desplaça d’escriure a revisar. Si el pla operacional no preveu temps de revisió, el guany de productivitat és aparent.

Pla operacional

El model de negoci diu què venem i a qui. El pla operacional diu com ho produïm, i sobretot quant costa fer-ho. És el pont entre la idea i el pla econòmic: cada recurs que hi apareix s’ha de convertir en una despesa concreta.

Per a una empresa de software, els blocs són:

  • Infraestructura: local o teletreball, i el cost real de cada opció. Si teletreballeu, no desapareix la despesa, es transforma (eines de col·laboració, compensacions, espais puntuals de reunió).
  • Recursos materials: equips de desenvolupament, llicències, subscripcions a serveis al núvol, comptes de desenvolupador de les stores, dominis i certificats. Les subscripcions són despesa recurrent, no inversió: apareixen cada mes.
  • Recursos humans: quins perfils calen, amb quina dedicació, quan s’incorporen i quant costen amb la seguretat social inclosa. Definiu també qui fa la feina comercial i de suport, que sovint no s’assigna a ningú i acaba menjant-se el temps de desenvolupament.
  • Proveïdors i contractacions externes: gestoria, serveis que subcontracteu, l’assegurança de responsabilitat civil professional i les condicions de pagament de cadascun.

Dues coses que als projectes de software se solen oblidar en aquest apartat:

  • El manteniment del que ja heu lliurat, sovint lligat a un acord de nivell de servei (SLA) amb temps de resposta compromesos. Cada client nou incrementa la càrrega de suport de forma permanent, i això limita quants en podeu tenir amb l’equip actual.
  • El temps no facturable: formació, reunions comercials, propostes que no es guanyen. Si planifiqueu com si tot el temps fos productiu, els números no sortiran.

Impacte social

Els codis deontològics que hi ha a les referències d’aquest document ens donen una visió general de l’impacte de la professió de desenvolupament de software. La responsabilitat podria veure’s en tres àrees: negoci, tecnologia i societat.

Negoci

La pregunta a fer-se és: segueixo l’estratègia correcta? Aquesta estratègia ha de ser compatible a la de les altres dues àrees esmentades.

Hem d’assegurar-nos de complir tota la llei i normativa en relació a la societat. En particular:

De totes aquestes normes, la data d’entrada en vigor canvia sovint i la trobareu al text oficial. El que no canvia és que us afecten abans del que sembla.

Com llegir una norma

Tenir la llista no és el mateix que saber què heu de fer. Per a qualsevol d’aquestes normes el recorregut és el mateix, i el RGPD serveix d’exemple perquè és el que segur que us tocarà.

  1. A qui s’aplica. Busqueu l’àmbit d’aplicació, que sol ser el primer article. El RGPD s’aplica a qui tracta dades de persones que són a la Unió, encara que l’empresa sigui fora, i no hi ha cap mínim de mida: ser dos no us en treu.
  2. Quin paper hi feu. Les normes reparteixen les obligacions per rols, i no teniu les mateixes segons on caigueu. Al RGPD sou responsables del tractament quan decidiu per què i com es tracten unes dades, i encarregats quan les tracteu per encàrrec d’un client. Si feu la botiga d’un client, el responsable és ell i vosaltres sou l’encarregat, i això s’ha de signar.
  3. Què us obliga a fer. Traduïu els articles a una llista de tasques amb responsable: mantenir el registre d’activitats, tenir una base legal per a cada dada, signar contracte amb els proveïdors que hi toquen, tenir un procediment per a les bretxes i una manera d’atendre els drets. Si una obligació no acaba en una tasca concreta, encara no l’heu entesa.
  4. Des de quan. Poques normes entren en vigor de cop. El reglament d’IA, per exemple, s’aplica per fases. Mireu el calendari abans de decidir que no us afecta encara.
  5. Què passa si no. Les multes són el que surt als titulars, però per a una empresa petita el cost real arriba abans: un client que us audita i no passeu, un concurs al qual no us podeu presentar, o la reclamació d’un usuari.

Sobre les fonts, llegiu el text oficial i les guies de l’autoritat de control (AEPD, APDCAT) abans que cap article que en parli. L’AEPD manté a més Facilita, una eina gratuïta pensada per a empreses petites amb tractaments de risc baix que us genera bona part de la documentació.

Com es tradueix tot això a l’esquema de la base de dades ho teniu a dades personals.

Tecnologia

Ens hem de preguntar: utilitzo l’eina correcta per la feina? És quelcom nou o reinventem la roda? Estic generant deute tècnic? Aquestes decisions impactaran al mercat del desenvolupament software, vist com un col·lectiu que interactua i acaba reprenent o col·laborant en solucions tècniques.

Societat

Ens preguntarem: millorem les vides de les persones? Pot utilitzar-se de forma nociva? Exclou persones? És ètic? És segur? A qui pertanyen les dades?

En aquesta àrea ens podem preguntar:

Impacte ambiental

Computació verda: ús eficient dels recursos informàtics, minimitzant l’impacte ambiental. Aproximacions:

  1. Longevitat dels productes, ja que el procés de fabricació és la part més significativa de l’ús de recursos naturals.
  2. Disseny eficient dels data centers.
  3. Eficiència del software (algorismes, assignació de recursos, virtualització, servidors de terminals).
  4. Gestió d’energia amb l’ús de components no utilitzats, reduir voltatges, parar màquines, fonts d’energia més eficients, etc.
  5. Reciclatge d’equips per ser reutilitzats.
  6. Cloud computing (virtualització) versus edge computing (més a prop).
  7. Teletreball, reduint el transport.

En particular, programació verda:

  1. Minimitzar l’emissió de CO2.
  2. Dissenyar les aplicacions eficientment per reduir el consum d’energia.
  3. Consumir electricitat amb la intensitat de CO2 mínima (mix de fonts).
  4. Construir aplicacions que siguin eficients amb el hardware, estenent la seva vida.
  5. Maximitzar l’eficiència energètica del hardware, reduint el nombre de servidors amb la major ràtio d’utilització.
  6. Reduir la mida i la distància recorreguda de les dades per la xarxa.
  7. Construir aplicacions conscients del CO2, que permetin gestionar la demanda i moure-la a regions o moments de menys intensitat.
  8. Per poder optimitzar, mesurar el CO2, l’energia, el cost, l’ús de xarxa i el rendiment.

Referències

Last change: , commit: feff8b3