Sari la conținutul principal

Scurtă prezentare a agenției

Ce ar trebui să pregătească o agenţie înainte de a preda dezvoltarea.

Un ghid al agenției pentru pregătirea unei oferte de dezvoltare: rezultatul clientului, proiecte, domeniu de aplicare, aprobări, dependențe, responsabilități comerciale și acceptare.

O bună dezvoltare nu necesită ca agenţia să devină consultanţă software. Este nevoie de o explicaţie clară a rezultatului clientului, lucrările fiind comandate şi deciziile care rămân la agenţie.

Scopul este de a face responsabilitatea vizibilă. Un dezvoltator nu ar trebui să ghicească dacă un ecran lipsă, o integrare sau o cerere de client târziu face parte din angajamentul convenit.

Descrie rezultatul clientului înainte de tehnologie

Explică ceea ce clientul încearcă să livreze și cine o va folosi. Implementarea acestor desene poate face parte din sarcină, dar nu explică ce trebuie să realizeze aplicația.

De exemplu, o scurtă ilustrativă ar putea fi: Creați un portal partener în cazul în care partenerii aprobați prezintă cereri și personalul clientului le revizuiască. Agenția furnizează proiectele de interfață și consolidează feedback-ul clientului.

Este un exemplu, nu o referire la un angajament existent al clientului.

Defineşte limita dezvoltatorului

Se precizează dacă comisionul acoperă o cerere completă, o punere în aplicare pe frontend, o componentă de suport sau o integrare. Se menționează părțile care vor fi furnizate de agenție sau de altă parte.

O clădire parțială are nevoie de puncte de integrare clare. Cine furnizează API? Cine deține implementarea finală? Cine testează rezultatul combinat? Fără aceste răspunsuri, o mică componentă poate dobândi o responsabilitate mult mai mare implicită.

A se furniza deciziile de proiectare, inclusiv statele

Designurile furnizate ar trebui să identifice comportamentul dorit al desktop-ului și cel mobil și stările importante ale unui ecran. Conținutul gol, erorile de validare, statele de încărcare și finalizare au nevoie de un răspuns.

În cazul în care agenția nu a proiectat un stat, marcați-l ca o decizie de a rezolva. Asta este mai bine decât lăsând dezvoltatorul să inventeze comportamentul și descoperirea mai târziu că clientul se aștepta la ceva diferit.

Identificați care active și text sunt aprobate și care sunt provizorii. Mediul de dezvoltare nu ar trebui să facă un locador să arate ca o copie aprobată față de clienți.

Stabilirea traseului de revizuire și comunicare

Numeşte o persoană care consolidează feedback-ul pentru agenţie. Explică dacă dezvoltatorul va participa la şedinţele clienţilor, răspunde la întrebări prin intermediul agenţiei sau participă doar la discuţii tehnice convenite.

Stabilește cine poate aproba o schimbare. O idee client, o preferință agenție și o cerință contractuală nu sunt în mod automat același lucru. Păstrarea unui registru decizional ajută pe toată lumea să înțeleagă ce a intrat efectiv domeniul de aplicare.

Un acord cu eticheta albă are nevoie, de asemenea, de reguli practice: întâlnirea introducerilor, accesului, marcării rezultatelor şi permisiunii de a menţiona proiectul în mod public. Aceste puncte aparţin mai degrabă acordului decât presupunerilor.

Împărtășiți dependențele fără a împărtăși secretele neglijent

Enumeră sistemele relevante, documentația, aranjamentele de găzduire, registrele centrale și conturile terților. Explică cine le deține și modul în care va fi asigurat accesul adecvat.

Nu plasați parole sau secrete API într-un formular general de anchetă scurt sau obișnuit proiect. Utilizați un canal securizat convenit și limitați accesul la ceea ce are nevoie sarcina.

Pentru integrare, include conturi de testare disponibile, sarcini utile eșantion fără date private și un contact pentru întrebări de afaceri-regulă. O legătură API singur nu explică ceea ce clientul așteaptă conexiunea pentru a realiza.

Asigurați-vă că acceptarea beton

Descrieți ce va analiza agenția la fiecare etapă. Un exemplu util de acceptare indică o acțiune și un rezultat: un partener depune o cerere, personalul o poate revizui și partenerul vede statutul convenit.

De acord modul în care problemele vor fi înregistrate, modul în care feedback-ul este consolidat și modul în care sunt gestionate modificările în afara domeniului de aplicare. Scopul nu este de a face revizuirile dificile. Este de a distinge completarea caracteristicii promise de punerea în funcțiune a unuia nou.

Defineşte pachetul de livrare

Predarea convenită ar putea conține coduri, note de implementare, informații de configurare, orientări de administrare și o listă de dependențe. Termenii de proprietate și de licență determină ce poate fi transferat sau reutilizat; nu le deduce de la accesul la un depozit numai.

Acceptarea separata, o perioada de defect-corectie convenita si orice dezvoltare viitoare. Un proiect finalizat nu ar trebui sa se transforme in liniste in disponibilitate tehnica nelimitata pentru agentie sau clientul sau.

Un prim mesaj util

Dă rezultatul dorit, partea pe care doriți să o dezvoltați, starea de proiectare, integrările cunoscute, fereastra de livrare dorită și orice parametri bugetari.

Acest lucru este suficient pentru a începe o conversație concentrată. Domeniul de aplicare detaliat poate fi convenit odată ce limitele importante sunt înțelese.

Explorarea parteneriatelor pentru dezvoltarea agenţiilor sau trimite un scurt agentie.