Egy jó szoftverprojekt-leírás bemutatja a problémát, a felhasználókat, az érintett rendszereket és azt, hogy mit jelent a siker, a megoldást pedig nyitva hagyja, hogy a partnerek tegyenek rá javaslatot. Küldje el minden partnernek ugyanazt a leírást egy költségkeret-sávval és annak egyértelmű listájával, hogy mi rögzített, és a visszakapott ajánlatok elég pontosak lesznek ahhoz, hogy összevethesse őket.
A projektleírás arra való, hogy a válaszok összehasonlíthatók legyenek
Egy projektleírásnak egyetlen feladata van: hogy több partner is elég jól megértse a problémáját ahhoz, hogy megoldást javasoljon rá, olyan becsléssel, amelyben megbízhat. Ha minden partner a saját feltételezéseivel tölti ki a hézagokat, az ajánlatok a munkaterjedelemben térnek el, nem a minőségben, és a legolcsóbb gyakran az, amelyik a legkevesebbet feltételezte.
Ezért a leírás legyen pontos a problémát illetően, és visszafogott a megoldást illetően. Írja le, minek kell igaznak lennie, amikor a projekt elkészült, és hagyja, hogy a partnerek elmagyarázzák, hogyan jutnának el odáig. Az erre a nyitott részre adott válaszaik lesznek a leghasznosabbak mindabból, amit olvasni fog.
Kezdje az üzleti problémával és azzal, hogyan ítéli meg a sikert
Nyisson azzal, miért létezik a projekt: mi nem működik ma, kit érint, és mibe kerül, ha így hagyja. Ha azt írja, hogy az operatív csapata minden rendelést kézzel gépel át az e-mailekből az ERP-be, az sokkal többet elárul egy partnernek, mintha egy rendeléskezelő portált kérne.
Aztán írja le, hogyan ítéli meg a sikert. Válasszon néhány megfigyelhető eredményt, például a rendelésenként megtakarított időt, az ügyfelekhez már el nem jutó hibákat vagy egy dátumot, amikorra egy régi rendszer kikapcsolható. Ezekből a kritériumokból később a mérföldkövek átvételi kritériumai lesznek, ezért úgy fogalmazza meg őket, hogy valaki ellenőrizni tudja.
A funkciók előtt írja le a felhasználókat, a rendszereket és az adatokat
Az integrációs és adatmunkát könnyű alábecsülni, ha a partner nem látja. Mielőtt funkciókat sorolna fel, írja le, ki fogja használni a szoftvert, mely rendszerekkel kell együttműködnie, és milyen adatokat kezel. Az itt maradt hiányok később változtatási kérelmekként térnek vissza.
- Felhasználók: kik ők, nagyjából hányan vannak, hol és milyen eszközökön dolgoznak.
- Meglévő rendszerek: melyek ezek, ki a gazdájuk, és dokumentált API-t kínálnak-e, vagy csak adatbázist és fájlexportot.
- Adatok: mi személyes, bizalmas vagy szabályozott, hol vannak ma, és mennyit kell belőlük migrálni.
- Üzemeltetés: ki fogja üzemeltetni a szoftvert az indulás után, és milyen tárhely- vagy felhőszabályai vannak már a cégének.
- Korlátok: nyelvek, akadálymentességi igények, biztonsági szabványok és minden nem módosítható határidő, az okával együtt.
Adjon meg költségkeret-sávot és azt a határidőt, amely valóban számít
Sok megrendelő visszatartja a költségkeretet, hogy lássa, mit javasolnak a partnerek. Az eredmény: különböző projektekre szóló ajánlatok, az egyik partner a minimumra tervez, a másik mindenre, amit említett. Egy sáv, akár egy széles is, lehetővé teszi, hogy minden partner a sávba illő legjobb projektet javasolja, és egyenesen megmondja, ha nem fér bele.
Ugyanígy járjon el az idővel. Mondja meg, melyik dátum rögzített és miért, például egy lejáró szerződés vagy egy szabályozói határidő miatt, és melyik dátumok csak kívánságok. Egy partner csak akkor tud egy kemény határidőhöz igazodni, ha tudja, melyik az.
Jelölje meg, mi rögzített, a többit hagyja nyitva
Minden követelményt jelöljön rögzítettnek, preferáltnak vagy nyitottnak. A rögzített azt jelenti, hogy egy ajánlat nélküle nem érvényes, például uniós tárhely vagy bejelentkezés a meglévő identitásszolgáltatóján keresztül. A preferált azt jelenti, hogy oka van rá, de megfontolna alternatívát. A nyitott azt jelenti, hogy a partner javaslatát kéri.
A technológiát hagyja nyitva, hacsak nincs valódi oka rögzíteni, például egy házon belüli csapat, amely karbantartja majd a kódot, vagy egy platform, amelyet a cége szabványként használ. Ha mégis rögzít egy választást, indokolja meg, hogy a partnerek ne az ellene való érveléssel töltsék az ajánlatukat.
Végül kérje meg a partnereket, hogy ugyanabban a szerkezetben válaszoljanak: hogyan értik a problémát, mi a megközelítésük, milyen szakaszokra és mérföldkövekre bontják a munkát, milyen feltételezésekkel és kockázatokkal számolnak, milyen csapattal dolgoznak, és mi az üzleti modell. A közös szerkezet teszi az ajánlatokat a gyakorlatban összehasonlíthatóvá.
Hibák, amelyek miatt az ajánlatok összehasonlíthatatlanok
Sok használhatatlan ajánlat egy olyan leírásra adott válasz, amely eleve ilyet hívott elő. Ezeket a mintákat távolítsa el, mielőtt elküldi a sajátját.
- Problémaleírás nélküli funkciólista, így minden partner csak találgatja a prioritásait.
- Hosszú specifikáció, amely rögzíti a megoldást, mielőtt bárki megvizsgálta volna a problémát.
- Egy szó sincs a meglévő rendszerekről vagy az adatmigrációról, amelyek aztán változtatási kérelmekként térnek vissza.
- Egyes partnerek telefonon plusz részleteket kapnak, így az ajánlataik más-más kérdésekre válaszolnak.
- Olyan szavak, mint „egyszerű”, „szabványos” vagy „olyan, mint egy ismert alkalmazás”, amelyek minden olvasónak mást jelentenek.
- Nincs határidő a kérdésekre, vagy a válaszokat csak a kérdező partner kapja meg.
Kérjen kérdéseket, és olvassa őket az értékelés részeként
Adjon a partnereknek meghatározott időszakot a kérdésekre, válaszoljon írásban, és minden választ küldjön el mindegyiküknek. A kérdések önmagukban is elárulnak valamit: az a partner, amely az adatairól, a felhasználóiról és az átvételi kritériumairól kérdez, már a megvalósításon gondolkodik.
Ha a probléma még túl bizonytalan ahhoz, hogy jól le lehessen írni, mondja ki, és teljes ajánlat helyett kérjen egy rövid, fizetős feltáró szakaszt. A találgatásokra épülő fix árajánlat a kockázati tartalékában rejti el az ismeretleneket; a feltáró szakasz tényekkel váltja fel a találgatásokat. Ha szeretné, hogy mérnökök olvassák el a projektleírását, vagy válaszoljanak rá, elküldheti a „Projekt indítása” űrlapunkon.
A legfontosabbak
- Írja le a problémát, a felhasználókat és azt, hogy mit jelent a siker, a megoldást pedig hagyja nyitva.
- Az integrációs és adatmunkát könnyű alábecsülni, ezért soroljon fel minden érintett rendszert és adatkészletet.
- Adjon meg költségkeret-sávot, és mondja meg, melyik határidő rögzített és miért.
- Minden követelményt jelöljön rögzítettnek, preferáltnak vagy nyitottnak, és egységes szerkezetben kérje az ajánlatokat.
- A kérdésekre írásban válaszoljon, és minden választ minden partnerrel osszon meg.
GYIK
Milyen hosszú legyen egy szoftverprojekt-leírás?
Elég hosszú ahhoz, hogy kitérjen a problémára, a felhasználókra, a rendszerekre, az adatokra, a korlátokra, a költségkeret-sávra és az ütemtervre, ami a legtöbb projektnél elfér néhány oldalon. Ha sokkal hosszabbra nyúlik, valószínűleg a megoldást írja le, nem a problémát.
Megosszam a költségkeretemet a szoftverfejlesztő partnerekkel?
Igen, sávként. Enélkül a partnerek nagyon különböző méretű projekteket javasolnak, és nem tudja összevetni őket. Egy sáv lehetővé teszi, hogy minden partner megmutassa, mit tenne azon belül, és őszintén megmondja, ha nem elég.
Kérjek fix árat a projektleírásra adott válaszban?
Csak akkor, ha a leírás elég részletesen bemutatja a munkát ahhoz, hogy becsülni lehessen. Ha fontos kérdések még nyitottak, kérjen fix áras feltáró szakaszt vagy kimondott feltételezésekre épülő becsült sávot, és a fejlesztés árát akkor rögzítsék, amikor az ismeretlenek tisztázódtak.