Recuperarea costurilor software este cea mai grea problemă în dezvoltarea informaticii și licențele sunt doar o soluție.
Trebuie să abordăm problematica diferit pe scara istoriei informaticii.
La începuturi s-a pus problema de a scrie programe numai și numai pentru un utilizator, chiar dacă acesta le rula de mai multe ori schimbând seturile de date. În acest caz, utilizatorul care era și client și plătitor încheia un comntract pentru realizarea programului. Se plătea, așa fel încât în final dezvoltatorul încasa tot ce era de încasat. La fiecare rulare, după ce i se achitase programul pe care el îl realizase, se plăteau toate cheltuielile făcute cu rularea, cu perforarea de cartele cu seturile noi de date, cheltuielile cu hârtia de imprimantă, cheltuielile cu timpul de calculator și dacă era cazul se plăteau și cheltuieli cu mici modificări cerute de client dacă se schimbau elemente simple în algoritm, în structura de pe cartele sau în modul de prezentare a rezultatelor la imprimantă. Programul era al clientului și acesta îl plătise integral.
Cu timpul, programatorii au identificat și probleme pe care mai mulți clienți ar fi trebuit să le soluționeze. În acest scop programatorii au elaborat programe:
- mai generale;
- mai fiabile;
- mai flexibile;
- mai performante.
Aceste programe prin complexitatea lor au necesitat eforturi de programare cu mult mai mari, deci la produse finite au însemnat produse software foarte scumpe, imposibil de achiziționat doar de către un utilizator. Aceste programe erau destinate rezolvării unor probleme precum:
- programare liniară;
- transporturi optime;
- alocare și nivelare resurse;
- prognoze economice;
- optimizare trasee;
- drum critic;
- optimizarea de stocuri;
- ordonanțarea producției;
- calculul de necesar;
- evidența de personal;
- calculul de salarii;
- evidența contractelor.
Dacă un astfel de produs software ajungea să aibă un preț P, dezvoltatorii făceau de fapt o investiție care trebuia recuperată, ceea ce presupunea studierea grupului țintă al clienților care era estimat ca având N clienți, care în medie fiecare utiliza respectivul produs de M ori pe an. Dezvoltatorul își propunea să recupereze investiția în cel mult K ani. De aici rezulta prețul pe o rulare RP, care era dat de relația:
RP = P/(N*M*K).
Variațiile care apăreau în mod real generau situații foarte diferite de cele planificate la început.
dacă numărul real de clienți NR era mai mare decât numărul planificat N și dacă numărul de rulări reale medii MR era mai mare decât numărul planificat al rulărilor M, menținând prețul pe rulare RP la nivelul planificat, recuperarea costurilor se realiza într-un interval mai mic.
Realitatea era destul de contradictorie și nu de puține ori au fost situațiile în care produsele au fost cotate ca fiind investiții nerentabile pentru că dezvoltatorul nu a decis reducerea arbitrară a nivelului prețului pentru o rulare RP, care ar fi dus la creșterea numărului de clienți, recuperându-și dacă nu toată investiția, cel puțin o parte.
Am cunoscut și cazuri în care dezvoltatorul a construit programe de succes, utilizate pe termen lung și după trecerea celor K ani el mai vindea produsul, încasând în continuare bani pe un program care se amortizase la el în centrul de calcul. Am văzut și situații când un program se realizase doar că un programator s-a ambiționat, iar când l-a lansat nu a avut clienți și a fost o pierdere pe toate liniile.
În ziua de azi problema recuperării este esențială, iar studerea grupului țintă trebuie să fie etapă a ciclului de dezvoltare, căci aplicațiile online sunt investiții și din start recuperarea investiției este legată de:
- numărul de clienți;
- frecvența cu care clienții accesează aplicația;
- valoarea fiecărei trenzacții;
- viteza de propagare a calităților aplicației în afara grupului țintă;
- nivelul redus al cheltuielilor de mentenanță;
- nivelul pierderilor generate de erorile aplicației în rapor cu clienții.
Acum sunt aplicații online pentru tot felul de plăți, pentru tot felul de alocări în timp real de resurse care își recuperează cheltuielile făcute pentru realizarea lor printr-un procent foarte mic din valoarea tranzacției plăti de intermediar, dar încoporat în tariful, prezentat clientului și acceptat de acesta.
Trebuie să abordăm problematica diferit pe scara istoriei informaticii.
La începuturi s-a pus problema de a scrie programe numai și numai pentru un utilizator, chiar dacă acesta le rula de mai multe ori schimbând seturile de date. În acest caz, utilizatorul care era și client și plătitor încheia un comntract pentru realizarea programului. Se plătea, așa fel încât în final dezvoltatorul încasa tot ce era de încasat. La fiecare rulare, după ce i se achitase programul pe care el îl realizase, se plăteau toate cheltuielile făcute cu rularea, cu perforarea de cartele cu seturile noi de date, cheltuielile cu hârtia de imprimantă, cheltuielile cu timpul de calculator și dacă era cazul se plăteau și cheltuieli cu mici modificări cerute de client dacă se schimbau elemente simple în algoritm, în structura de pe cartele sau în modul de prezentare a rezultatelor la imprimantă. Programul era al clientului și acesta îl plătise integral.
Cu timpul, programatorii au identificat și probleme pe care mai mulți clienți ar fi trebuit să le soluționeze. În acest scop programatorii au elaborat programe:
- mai generale;
- mai fiabile;
- mai flexibile;
- mai performante.
Aceste programe prin complexitatea lor au necesitat eforturi de programare cu mult mai mari, deci la produse finite au însemnat produse software foarte scumpe, imposibil de achiziționat doar de către un utilizator. Aceste programe erau destinate rezolvării unor probleme precum:
- programare liniară;
- transporturi optime;
- alocare și nivelare resurse;
- prognoze economice;
- optimizare trasee;
- drum critic;
- optimizarea de stocuri;
- ordonanțarea producției;
- calculul de necesar;
- evidența de personal;
- calculul de salarii;
- evidența contractelor.
Dacă un astfel de produs software ajungea să aibă un preț P, dezvoltatorii făceau de fapt o investiție care trebuia recuperată, ceea ce presupunea studierea grupului țintă al clienților care era estimat ca având N clienți, care în medie fiecare utiliza respectivul produs de M ori pe an. Dezvoltatorul își propunea să recupereze investiția în cel mult K ani. De aici rezulta prețul pe o rulare RP, care era dat de relația:
RP = P/(N*M*K).
Variațiile care apăreau în mod real generau situații foarte diferite de cele planificate la început.
dacă numărul real de clienți NR era mai mare decât numărul planificat N și dacă numărul de rulări reale medii MR era mai mare decât numărul planificat al rulărilor M, menținând prețul pe rulare RP la nivelul planificat, recuperarea costurilor se realiza într-un interval mai mic.
Realitatea era destul de contradictorie și nu de puține ori au fost situațiile în care produsele au fost cotate ca fiind investiții nerentabile pentru că dezvoltatorul nu a decis reducerea arbitrară a nivelului prețului pentru o rulare RP, care ar fi dus la creșterea numărului de clienți, recuperându-și dacă nu toată investiția, cel puțin o parte.
Am cunoscut și cazuri în care dezvoltatorul a construit programe de succes, utilizate pe termen lung și după trecerea celor K ani el mai vindea produsul, încasând în continuare bani pe un program care se amortizase la el în centrul de calcul. Am văzut și situații când un program se realizase doar că un programator s-a ambiționat, iar când l-a lansat nu a avut clienți și a fost o pierdere pe toate liniile.
În ziua de azi problema recuperării este esențială, iar studerea grupului țintă trebuie să fie etapă a ciclului de dezvoltare, căci aplicațiile online sunt investiții și din start recuperarea investiției este legată de:
- numărul de clienți;
- frecvența cu care clienții accesează aplicația;
- valoarea fiecărei trenzacții;
- viteza de propagare a calităților aplicației în afara grupului țintă;
- nivelul redus al cheltuielilor de mentenanță;
- nivelul pierderilor generate de erorile aplicației în rapor cu clienții.
Acum sunt aplicații online pentru tot felul de plăți, pentru tot felul de alocări în timp real de resurse care își recuperează cheltuielile făcute pentru realizarea lor printr-un procent foarte mic din valoarea tranzacției plăti de intermediar, dar încoporat în tariful, prezentat clientului și acceptat de acesta.
în lucru acum
(17 noiembrie 2017)
No comments:
Post a Comment