du har en uppfattning om en lysande ny produkt. Du har till och med en budget för att skapa den. Nu behöver du ett team av erfarna mjukvaruutvecklare att göra det. Men hur vet du om leverantören passar dina krav? Du förhandlar.
en bra begäran om förslag (RFP) kommer att förenkla dessa förhandlingar både för dig och för utvecklingsteamet. Ett av huvudmålen för en RFP är att hjälpa dig att samla erbjudanden från olika lag och välja det förslag som uppfyller dina krav bäst. En bra mjukvaruutveckling begäran om förslag tillåter en leverantör att erbjuda den mest effektiva tech stack. Den som kommer att lösa problemet din produkt är avsedd att lösa på det mest effektiva sättet.
i det här inlägget visar vi dig hur du skriver en begäran om förslag. För att hjälpa dig att ge ditt utvecklingsteam viktig information om ditt projekt. Vi visar dig korrekt formatering. Och ge exempel på mjukvaruutveckling RFP du kan använda som referens eller ens en mall.
Vad är RFP?
i den större världen är en RFP ett dokument skrivet av statliga organisationer, ideella organisationer och företag. De brukar göra det för stora projekt som måste vara konkurrenskraftigt bud på. Dessa är vanligtvis stora kontrakt som kräver due diligence. Så, en ideell skriver en RFP och uppmanar leverantörer att bjuda på det. Leverantörerna lämnar in sina förslag enligt kraven i RFP. Förslaget med lägsta pris eller bästa valuta för pengarna tilldelas kontraktet.
en begäran om mjukvaruutveckling är i huvudsak densamma. Du skriver ner dina krav. Skicka dem sedan till ett mjukvaruutvecklingsföretag. De gör sin forskning och erbjuder ett förslag till dig. Du samtycker antingen till det, omförhandlar eller går någon annanstans.
en RFP bör vara det första steget du tar innan du letar efter en mjukvaruleverantör för din produkt. Dokumentet ska innehålla kritiska detaljer, specifika krav, även den förväntade leveranstidslinjen. Enkelt uttryckt är en RFP en grund för vidare diskussioner om ditt projekt med ett utvecklingsteam.
hur man skriver en RFP
att skriva en bra begäran om förslag till mjukvaruutveckling tar lite tid. Men resultaten du kommer att få från det är definitivt värda det.
det finns ingen officiellt dokumenterad RFP-formatering. Eller några officiella regler om hur man skriver ett partnerskapsförslag måste du följa. Men det finns allmänt accepterade god praxis. Och saker som anses vara bra att ha i en övertygande RFP. Vi ska titta på dessa nästa.
introducera oss till ditt företag och marknad
det är bra att börja med en kort introduktion av ditt företag. Bara lite allmän information om vad det är du gör kommer att räcka. Vad är företagets uppdrag? Vilka är dina värderingar? Vilka är dina långsiktiga mål?
beskriv ditt projekt / produkt idea
introducera utvecklingsteamet till din idea. Vilket problem skulle produkten lösa? Vilka smärtor är det tänkt att hjälpa till med? Se till att nämna din målgrupp. Om du har marknadsundersökningar till hands lägga till en kort sammanfattning av det också. Andra frågor du kanske vill svara på detta steg är:
- Hur kommer den föreslagna programvaran att hjälpa dig att uppnå de långsiktiga målen?
- vilka affärsprocesser kommer denna nya produkt att förbättras?
- om det finns en befintlig lösning, finns det några flöden i den?
- vilka potentiella komplikationer förutser du?
Läs mer: Vad passar produktmarknaden och hur vi på Fulcrum hjälper våra kunder att hitta den
viktiga funktioner
du behöver inte namnge alla funktioner du tycker att din produkt ska ha. Faktum är att under upptäcktsstadiet kommer de flesta av de funktioner du föreställde dig att bevisas onödiga. Medan de funktioner du inte ens tänkte på kommer att visa sig vara väsentliga.
men att låta oss veta vilka funktioner du tycker är helt avgörande kommer att låta oss förstå logiken för den produkt du har i åtanke. Så vi kommer att kunna förstå produkten bättre. Och erbjuda lösningar som passar den logiken.
Läs Mer: tre Prioriteringstekniker med vilka Fulcrums produkter rockar
begränsningar
finns det några budget-eller juridiska begränsningar? Kanske finns det några tekniska begränsningar? Se till att nämna dem alla i din RFP.
Projektomfång och resultat
det är ganska utmanande att uppskatta omfattningen av ett mjukvaruprojekt när det bara är en ide. Särskilt om du inte har en djup förståelse för mjukvaruutvecklingsprocessen. Så gå inte in på teknikaliteter här. Lista bara det arbete du förväntar dig att göra. Och de resultat du förväntar dig att få.
Metrics
nämn de mätvärden som är mest viktiga för ditt företag. Så utvecklingsteamet kan designa produkten med de specifika mätvärdena i åtanke.
Förslagskrav och urvalskriterier
det är bra att ange kraven för svarförslaget om du har några. Behöver du veta teknikområdet som mjukvaruutvecklarna använder? Måste du se portföljen?
om den tidigare erfarenheten på samma marknad är avgörande för ditt projekt måste du nämna det också. Om det finns andra kriterier som kommer att påverka valet av säljaren, namnge dem också här.
andra saker att lägga till i din förslagsförfrågan
som du kan se den förfrågningsformatering som vi föreslår här har ingen alltför teknisk information. De flesta av kunderna inte har kompetens att veta eller bryr sig om saker som:
- infrastrukturkrav;
- metoder för mjukvaruutveckling;
- eller metoder för projektledning.
men om dessa tekniska saker verkligen är viktiga för ditt projekt och du kan namnge dem – gör det.
RFP exempel
vi kan inte visa dig ett verkligt exempel på en RFP från vår egen praxis. Vi tror att det skulle vara oetiskt av oss att dela en sådan sak. Men här är vad en hypotetisk RFP kan se ut för ett av projekten från vår portfölj:
vi är en bilhandlare från Kiev, Ukraina. Vi är den största återförsäljaren av vårt varumärke i Östeuropa.
vår nuvarande webbplats är föråldrad. Det ger inte all information om våra produkter, saknar användbarhet och passar inte våra affärsmål.
för att åtgärda dessa problem behöver vi en ny webbplats som kommer att vara innovativ, användarvänlig och funktionell. Det måste ge våra kunder maximal information om våra produkter och tjänster.
de viktigaste funktionerna vi ser är:
- informativ katalog;
- lånekalkylator;
- provkörningsbokning;
- Avancerad sökning;
- funktionell adminpanel för våra chefer.
den huvudsakliga metriska vi planerar att fokusera på är omvandlingsfrekvens.
för att fatta ett beslut av partnerskapet krävs en PRD. Lösningen du erbjuder måste vara skalbar. Vi vill också se över din portfölj. Och få information om din tekniska stack och metoder du använder i ditt arbete.
om du vill diskutera din PRD eller hur vi närmar oss den i Fulcrum, boka ett samtal med vår affärsutvecklingschef.
- hur man tecknar Win-Win-kontrakt med leverantörer: Programvaruutvecklingskontrakt på Fulcrum Rocks
- alla Whys och Hows för att skriva en kommunikationsplan för ett mjukvaruprojekt
- Vad är en Arbetsförklaring, och behöver ditt projekt det?
- Outsourcing fiasko: smärtsamma lärdomar från IT Outsourcing gått dåligt