Servicii de solution design pentru proiecte software

Serviciul se adresează unei inițiative software concrete, al cărei scop este înțeles, dar a cărei formă nu este încă suficient de clară. Poate fi potrivit când:

• Un proces de business are nevoie de suport software, însă rolurile și limitele fluxului nu sunt cartografiate.
• Există un concept de produs, dar prima versiune utilă și posibilitățile ulterioare sunt amestecate în aceeași listă.
• Un sistem existent necesită o schimbare importantă, iar efectele asupra datelor, integrărilor sau operării nu sunt clare.
• Sunt posibile mai multe direcții tehnice, iar stakeholderii au nevoie de o comparație explicită.
• Brief-ul de dezvoltare enumeră funcționalități, dar nu și regulile de business, excepțiile sau cerințele de calitate din spatele lor.
• Organizația are nevoie de o decizie structurată înainte să aleagă între un proiect fixed-scope, livrare agilă sau prototipare.

Solution design nu înlocuiește strategia de transformare la nivelul întregii organizații. Nu implementează software-ul, nu garantează un perimetru complet și nu produce automat o estimare fixă. Colaborarea trebuie construită în jurul deciziei pe care organizația trebuie să o ia în continuare.

O listă de funcționalități nu descrie o soluție. Designul trebuie să țină cont de oamenii, procesele, informațiile și tehnologiile existente din jurul ei.

Scop și utilizatori

Definim activitatea pe care sistemul o va susține, persoanele implicate și rezultatul de care are nevoie fiecare rol. Separăm nevoile utilizatorilor de o preferință pentru un anumit ecran sau o anumită tehnologie.

Fluxul actual și excepțiile

Urmărim activitatea așa cum se desfășoară în prezent, inclusiv aprobări, transferuri, întârzieri, soluții ocolitoare și cazuri neobișnuite. Un flux idealizat poate ascunde tocmai regulile care fac implementarea dificilă.

Limita sistemului

Stabilim ce responsabilități aparțin soluției propuse și ce rămâne în sarcina oamenilor, aplicațiilor existente, furnizorilor sau etapelor ulterioare. Această limită influențează perimetrul proiectului, integrările și responsabilitatea operațională.

Date și integrări

Identificăm înregistrările importante, proprietarii lor, modul în care se modifică și sistemele externe implicate. Accesul, calitatea interfețelor și constrângerile furnizorilor trebuie tratate ca dependențe, nu ca presupuneri.

Cerințe de calitate și operare

Consemnăm cerințele specifice proiectului privind accesul, auditarea, disponibilitatea, performanța, localizarea datelor, recuperarea, mentenabilitatea și suportul. Cerințele juridice, de reglementare sau securitate trebuie aprobate de specialiștii potriviți.

Întrebările exacte depind de inițiativă, însă o colaborare utilă poate investiga:

• Ce decizie a utilizatorului sau a organizației trebuie să susțină soluția?
• Ce fluxuri și trasee de excepție intră în perimetrul primei livrări?
• Ce informații sunt necesare, de unde provin și cine răspunde de ele?
• Ce sisteme existente trebuie păstrate, schimbate sau conectate?
• Ce cerințe sunt confirmate, presupuse, contestate sau încă necunoscute?
• Ce opțiuni de arhitectură respectă constrângerile și ce compromisuri implică?
• Ce dependențe pot schimba fezabilitatea, ordinea sau costul?
• Ce dovezi va folosi responsabilul deciziei pentru acceptarea unei implementări ulterioare?
• Ce întrebări necesită un prototip, o investigație tehnică sau o evaluare de specialitate?
• Ce activități aparțin etapei curente, uneia viitoare sau nu fac deloc parte din inițiativă?

Documentația trebuie să facă vizibile întrebările fără răspuns. Absența unei obiecții nu trebuie interpretată drept acord.

Activitățile și materialele se stabilesc în funcție de decizia urmărită. În funcție de perimetru, colaborarea poate include elementele de mai jos.

Analiza perspectivelor și a informațiilor existente

Analizăm brief-ul, cercetarea disponibilă, diagramele existente, informațiile despre proces și constrângerile relevante. Consemnăm perspectivele diferite fără să presupunem că există deja consens.

Modelarea fluxurilor și rolurilor

Descriem actorii, pașii, regulile de business, deciziile, transferurile și excepțiile la nivelul necesar pentru alegerea soluției. Designul detaliat al interfeței aparține serviciilor UX sau UI atunci când este necesar.

Cerințe funcționale și nefuncționale

Organizăm comportamentul necesar separat de așteptările privind calitatea, accesul, auditarea, performanța și operarea. Marcăm ipotezele, sursele, responsabilii și stadiul aprobării.

Limitele sistemului și ale integrărilor

Cartografiem componentele, sistemele externe, circulația datelor și responsabilitățile. Evidențiem dependențele de acces și interfață care necesită confirmare tehnică.

Compararea opțiunilor de arhitectură

Comparăm direcții viabile folosind cerințele și constrângerile convenite. O recomandare trebuie să includă justificarea, dependențele, limitele și consecințele sale, nu să prezinte o tehnologie drept soluție universală.

Propunerea limitei de livrare

Grupăm capabilități coerente pentru o implementare inițială și identificăm lucrările ulterioare sau opționale. Este o propunere pentru decizie, nu garanția unui perimetru complet ori un angajament comercial fix.

Documentarea deciziei și predarea

Consemnăm deciziile, întrebările deschise, ipotezele, dependențele și pașii următori sugerați. Formatul materialelor trebuie să corespundă echipei care le va utiliza și procesului de aprobare.

O inițiativă poate trece succesiv prin mai multe direcții, dar un singur serviciu nu trebuie să le promită pe toate. Pornim de la incertitudinea care împiedică în prezent o decizie responsabilă.

1. Definim decizia

Numim inițiativa, responsabilul deciziei, întrebarea care trebuie clarificată și limitele colaborării. Înregistrăm constrângerile relevante de business și livrare.

2. Analizăm contextul existent

Revizuim utilizatorii, fluxurile, informațiile disponibile, sistemele, datele, integrările și deciziile anterioare. Separăm faptele observate de presupunerile stakeholderilor.

3. Modelăm comportamentul propus

Descriem rolurile, capabilitățile, regulile de business, informațiile și traseele de excepție. Identificăm conflictele și informațiile care lipsesc și care influențează limita sistemului.

4. Comparăm opțiuni viabile

Evaluăm opțiunile de arhitectură și livrare în raport cu criteriile aprobate. Documentăm compromisurile, dependențele și întrebările care necesită un specialist.

5. Propunem limita de livrare

Organizăm capabilitățile care ar putea fi livrate împreună și identificăm excluderile, activitățile ulterioare și dependențele externe. Confirmăm persoana care poate aproba propunerea.

6. Documentăm următoarea decizie

Predăm materialele convenite, ipotezele, întrebările deschise și justificarea opțiunilor. Următorul pas poate fi implementarea, un prototip, cercetare suplimentară sau decizia de a nu continua încă.

Nu orice inițiativă are nevoie de aceleași documente. Un model de flux poate fi suficient pentru clarificarea unui proces. Contextul sistemului și compararea opțiunilor pot fi mai utile pentru o inițiativă cu multe integrări. O structură timpurie a interfeței poate ajuta atunci când navigarea sau rolurile influențează cerințele. O investigație tehnică poate fi necesară atunci când fezabilitatea depinde de o interfață ori de o sursă de date specifică.

Alegem nivelul minim de detaliu care permite luarea deciziei. Diagramele, ecranele și specificațiile fără un cititor și un scop identificat adaugă volum, nu claritate.

Clientul furnizează, de regulă, contextul de business, accesul la stakeholderii relevanți, materialele existente, constrângerile cunoscute și persoanele autorizate să decidă. Rolul Xfinit este limitat la cercetarea, facilitarea, modelarea, analiza opțiunilor și documentația convenite pentru colaborare.

Accesul la terți, consultanța juridică sau de conformitate, recrutarea participanților, cercetarea originală, designul UX ori UI detaliat, estimarea cu preț fix și implementarea nu sunt incluse automat. Dacă sunt necesare, trebuie definite explicit.

• O descriere scurtă a problemei și a deciziei care este blocată.
• Persoanele sau rolurile care folosesc, dețin ori aprobă procesul relevant.
• Brief-uri, note despre flux, diagrame, cercetare sau capturi existente, chiar dacă sunt incomplete.
• Sistemele, furnizorii, sursele de date și integrările despre care crezi că sunt implicate.
• Constrângerile cunoscute de business, tehnologie, legislație, timp sau buget.
• Deciziile deja luate și ipotezele care mai trebuie analizate.
• Responsabilul intern care poate rezolva neînțelegeri și aproba pasul următor.

Nu trimite credențiale, date cu caracter personal sau extrase confidențiale din producție prin formularul inițial. Accesul și modul de gestionare a informațiilor trebuie convenite înaintea analizei detaliate.

Trimite problema, fluxul curent, sistemele implicate, constrângerile cunoscute și decizia pe care organizația trebuie să o ia. Xfinit poate defini un perimetru potrivit pentru solution design și poate separa activitățile de specialitate sau implementarea ulterioară.