Mit kell egy ügynökségnek előkészítenie, mielőtt átadná a fejlesztést.

Egy jó fejlesztési átadás nem követeli meg, hogy az ügynökség szoftver tanácsadó legyen, hanem világos magyarázatot igényel az ügyfél eredményéről, a megrendelt munkáról és az ügynökségnél megmaradó döntésekről.

A cél az, hogy a felelősség látható legyen. A fejlesztőnek nem kell találgatnia, hogy egy hiányzó képernyő, egy integráció vagy egy késői ügyfél kérés része-e a megállapodás szerinti kötelezettségvállalásnak.

Ismertesse az ügyfél végeredményét a technológia előtt

Magyarázza meg, hogy mit próbál az ügyfél szállítani, és ki fogja használni. "Végrehajtása ezeket a terveket" lehet a feladat része, de ez nem magyarázza meg, hogy mit kell az alkalmazás.

Például, egy illusztrációs jelentés lehet: "Hozzon létre egy partnerportált, ahol a jóváhagyott partnerek benyújtják a kérelmeket, és az ügyfél munkatársai felülvizsgálják azokat. Az ügynökség biztosítja az interfész tervezését, és megszilárdítja az ügyfél visszajelzéseit". Ez a projekt felhasználói utazást és felelősségi megosztást biztosít.

Ez egy példa, nem pedig egy meglévő ügyfél szerepvállalásra való utalás.

Határozza meg a fejlesztő határait

Jelölje meg, hogy a szakbizottság teljes kérelmet, előlapot, háttérkomponenst vagy integrációt tartalmaz-e. Nevezze meg azokat a részeket, amelyeket az ügynökség vagy egy másik fél szállít.

A részleges építmény egyértelmű integrációs pontokat igényel. Ki biztosítja az API-t? Ki a végső telepítés tulajdonosa? Ki teszteli az összesített eredményt? E válaszok nélkül egy kis komponens sokkal nagyobb implicit felelősséget szerezhet.

Adja meg a tervezési döntéseket, beleértve az államokat is.

A mellékelt terveknek azonosítaniuk kell a tervezett asztali és mobil viselkedést, valamint a képernyő fontos állapotát. Az üres tartalom, a hitelesítési hibák, a betöltés és a befejezés mind választ igényel.

Ha az ügynökség nem tervezett egy államot, jelölje meg, mint megoldási döntést. Ez jobb, mint hagyni, hogy a fejlesztő feltalálja a viselkedést, és később felfedezi, hogy az ügyfél elvárt valami mást.

Annak megjelölése, hogy mely eszközöket és szövegeket hagyták jóvá, és melyek ideiglenes jellegűek. A fejlesztési környezet nem teszi lehetővé, hogy a helytartó jóváhagyott, személyre néző példánynak tűnjön.

A felülvizsgálati és kommunikációs pálya létrehozása

Nevezzen meg egy személyt, aki megerősíti az ügynökség visszajelzéseit. Magyarázza meg, hogy a fejlesztő részt vesz-e az ügyféltalálkozókon, az ügynökségen keresztül válaszol-e a kérdésekre, vagy csak egyeztetett technikai megbeszéléseken vesz részt.

A kliens ötlet, az ügynökségi preferencia és a szerződéses követelmény nem automatikusan ugyanaz a dolog. Fenntartása döntési nyilvántartás segít mindenkinek megérteni, hogy mi ténylegesen belépett a hatálya.

A fehér címke-rendszer gyakorlati szabályokat is igényel: a bemutatkozások, a hozzáférés, a teljesítmények meghirdetése és a projekt nyilvános említésének engedélyezése. Ezek a pontok inkább a megállapodásban, mint a feltételezésekben találhatók.

Megosztani a függőségeket anélkül, hogy a titkokat gondatlanul megosztanánk

Sorolja fel a vonatkozó rendszereket, dokumentumokat, hosting megállapodásokat, adattárakat és harmadik fél számláit. Magyarázza meg, hogy ki a tulajdonos, és hogyan lesz megfelelő hozzáférés.

Ne helyezze jelszavakat vagy API titkokat egy általános projekt rövid vagy rendes lekérdezési űrlapra. Használjon egy elfogadott biztonságos csatornát, és korlátozza a hozzáférést, amire a feladatnak szüksége van.

Az integrációt illetően tartalmazza a rendelkezésre álló tesztszámlákat, a magánadatok nélküli mintaterheléseket és az üzleti szabályokhoz kapcsolódó kérdéseket. Az API link önmagában nem magyarázza meg, hogy az ügyfél mit vár el a kapcsolattól.

Konkrét elfogadás

Írja le, mit fog az ügynökség felülvizsgálni minden mérföldkőnél. Hasznos elfogadási példa tartalmaz egy intézkedést és egy eredményt: a partner kérelmet nyújt be, a személyzet felülvizsgálhatja azt, és a partner látja az elfogadott státuszt.

Egyetértés arról, hogyan rögzítik a kérdéseket, hogyan konszolidálják a visszajelzéseket, és hogyan kezelik a hatókörön kívüli változásokat. A cél nem az, hogy megnehezítsék a módosításokat, hanem az, hogy megkülönböztessék az ígért funkció kitöltését az új funkció üzembe helyezésétől.

Határozza meg a szállítási csomagot

A megállapodás szerinti átadás tartalmazhat kódot, telepítési jegyzeteket, konfigurációs információkat, adminisztrációs útmutatót és a függések listáját. A tulajdonjog és az engedély feltételei határozzák meg, hogy mit lehet átadni vagy újra használni; nem szabad azokat kizárólag az adattárhoz való hozzáférésből levonni.

Külön elfogadás, elfogadott halasztási időszak és bármilyen jövőbeli fejlesztés. A befejezett projekt nem válhat az ügynökség vagy ügyfele számára korlátlan technikai hozzáférhetetlenné.

Hasznos első üzenet

Adja meg a kívánt eredményt, a kívánt részt, a design állapotot, az ismert integrációt, a kívánt szállítási ablakot és a költségvetési paramétereket. Ezután nevezze meg a döntéshozó és preferált kommunikációs megállapodást.

Ez elég egy koncentrált beszélgetéshez. A részletes hatókör akkor fogadható el, ha a fontos határokat megértjük.

Az ügynökségek fejlesztési partnerségeinek feltárása vagy Küldjön egy ügynökségi beszámolót.