Како написати предлог за развој софтвера

Како написати успешан предлог за развој софтвера.

Кевин Лангуедоц

Сврха предлога за развој софтвера је да пренесе решење које ће прочитати пословни људи, па нека буде једноставно и прецизно; клоните се техничких услова што је више могуће. Следећи приказ се може користити као такав за припрему успешног предлога за развој софтвера. Важно је имати на уму да људи којима ћете представити предлог немају пуно времена за читање подужих докумената. Можете ми то узети, написао сам стотине предлога током својих 20 и више година у области информационих технологија: пословни људи желе тек толико информација да им омогуће доношење утемељене одлуке.

Ако одговарате на захтев за предлог (РФП) и морате поштовати одређени опсег страница, јер су странице унапред одштампане или вас захтеви за садржај приморају на предугачак предлог, размислите о коришћењу сажетка. додао сам одељак у коме је описано како се припрема један у наставку.

Дужина предлога

Видео сам шаблоне и дискусије који заговарају предлоге који трају 50 страница или страница. Верујте ми, изгубићете интересовање пословног руководиоца након пете странице. Једном када се предлог прихвати, пројектни документи ће, природно, бити детаљнији јер ће бити намењени пројектном тиму и биће радни нацрти система. Ово се односи на већину клијената, али (да увек постоји али, али) ако је предлог одговор на захтев за предлог (РФП), тада се морате придржавати РФП-а. Такође, влада или војна агенција ће вероватно имати строге смернице о томе како припремити предлог за развој софтвера и може садржати неколико страница (10, 20, 30, 50 или више) у зависности од сложености система.Ово правило и даље важи за велике организације које могу имати формални поступак предлагања, посебно ако су јавна корпорација и морају се придржавати било којих прописа или стандарда Сарбаннес-Оклеи-а или ИСО-а.

Резиме пословног плана

Ако је предлог на више од 20 страница, можете размотрити давање сажетка који је једнострани у одељцима у предлогу. Можете чак и да пружите сажетак у ПоверПоинт формату. Ако планирате да користите сажетак у презентацији предлога за развој софтвера, представите га помоћу сажетка и извршни директор може да прочита предлог касније, на пример током пословног лета.

Тхе Темплате

Следећи приказ је заправо добар образац који можете користити за припрему сопственог предлога за развој софтвера. Увек имам на уму правило о висини лифта приликом припреме предлога, а требали бисте и ви. У основи Елеватор Питцх предвиђа да ваш предлог не би требало да буде дужи од времена потребног да се лифтом од приземља до последњег спрата зграде кренете да представите предлог.

Назив пројекта

Са поднасловом или резимираним информацијама о предлогу

Предлог треба да има наслов и пододељак који резимира контекст софтверског предлога. Укључујете и назив одељења, службе, одељења или организације којима је пројекат намењен.

Ако одговарате на РФП (Захтев за предлог), тада у РФП укључите све информације које су потребне или су обавезне. Такође сам видео РФП-ове који захтевају да уз наслов додате потписе одобрења на првој страници, али у овом примеру потписе стављам на страницу са одељком „Измене“.

Преглед садржаја

На следећој страници треба да приложите садржај који наводи главне одељке предлога. Можете да додате бројеве страница ако предлог премашује пет страница или ако то захтева РФП.

Одобрења

Овај одељак је пресудан за процес, било да је одговор на РФП или из овог шаблона или из неког другог извора. Овај одељак документује потврде да је пројекат у покрету и пружа обавезујући споразум између различитих чланова пројекта. Никада не би требало да започињете пројекат док не добијете све потребне потписе и ако се шампион пројекта и заинтересоване стране не обавежу да започну пројекат. У супротном, могли бисте се наћи у обавези ако је пројекат отказан или ако се обим пројекта промени или се испоручују.

Са успостављеним Одобрењима, промене у обиму и испорукама је много теже извршити, а ако постоје спорови, потписивање одобрења пружиће јасно (е) разумевање онога што је договорено. Наравно, увек постоји питање тумачења.

Одобрења треба да садрже име особе, њен наслов, праћен потписом и на крају датум потписивања документа.



Име	Наслов / улога	Потпис	Датум

Промене

Одељак „Измене“ садржи евиденцију свих промена које су направљене или ће бити унесене у документ Предлога за развој софтвера. Не документује никакве промене у обиму самог пројекта или било ког другог аспекта пројекта. Одељак „Измене“ треба да садржи најмање име особе која врши промену, датум промене и коментар или опис промене.



Аутор	Датум промене	Опис или коментар

Речник и скраћенице

Наведите све појмове или акроними и њихове дефиниције. Немојте претпостављати да сви знају значење појмова или акронима, посебно ако планирате да користите спољне консултанте, а услови су интерни, уграђени у вашу корпоративну културу и жаргонизам. Свака организација има свој језик и скраћенице. У реду је користити их у предлогу све док су правилно документовани.

Такође, ако се користе било који акроними специфични за одређену индустрију, они такође морају бити документовани како би сви имали јасно разумевање значења израза и акронима и формулисали боља тумачења.

Следећи акроними потичу из тренутног шаблона. Они су дати као пример.

РФП: Захтев за предлог
РОИ: Повраћај улагања
ЦАГР: Сложена годишња стопа раста
ИТ: Информациона технологија
КАПЕКС: Капитални издаци
УоМ: Јединица мере

Обим

Обим предлога треба на високом нивоу да оцрта свеукупне детаље пројекта, шта је укључено и искључено. Обим треба да пружи општи опис, дужину пројекта и главне циљеве. Шта покушавате да постигнете овом инвестицијом у предложени пројекат развоја софтвера.

Временска линија

Овај одељак ће садржати датуме почетка и завршетка (процењени). Обавезно уградите међуспремник и планирајте непредвиђене случајеве. Добро правило палца је додавање бафера од 75% на временску линију.

Чланови пројекта

Чланови пројекта треба да укључују шампиона пројекта и заинтересоване стране. Шампион је обично извршни директор који управља целокупним пројектом и буџетом. Учесник је обично интерни промотер или спонзор. Они такође могу бити првак, у зависности од обима пројекта и / или врсте организације која захтева предлог за развој софтвера. Преостала листа садржи типичне улоге које људи обављају у пројекту.

Следеће је дато само као пример врсте улога које учесници у пројекту могу имати. Неки људи могу имати више улога. У зависности од обима пројекта, листа чланова пројекта може бити врло дугачка или иста особа може преузети различите улоге.

Листа треба да садржи све информације које исправно идентификују особу, њену улогу у пројекту, начин на који могу доћи до њих и које су њихове одговорности. Можете да укључите друге информације у зависности од РФП-а или врсте организације са којом ћете радити и њихових унутрашњих политика.



Члан тима	Улога	Контакт информације	Одговорности
	Шампион
	Стакехолдер
	Вођа пројекта
	Архитекта
	Аналитичар
	Програмер

Пословна прилика

Већина шаблона који су доступни дефинишу овај одељак као „Пословни проблем“ или „Изјаву проблема“, али често сам сретао пословне лидере који се вређају због чињенице да имају проблема у својој пословној јединици или процесу. Сјећам се да ме је једна директорка буквално избацила из своје канцеларије јер сам рекао да поправљамо поступак, а она ми је рекла да то неће бити неко из ИТ-а (Информациона технологија) који ће диктирати ако има проблема са њеним процесима или не.

Зато будите опрезни с формулацијама. Увек користим израз „пословна прилика“ јер је на крају предлог одговор на пословну прилику за побољшање процеса, подршку процесу или аутоматизацију процеса.



Изјава о пословању	Како ће систем задовољити захтев
Погођени пословни процес, ситуација, проблем	Како ће предложено решење побољшати циљно пословно подручје
Решава се која потреба	Како ће се садашњи пројекат тиме позабавити

Преглед решења

У одељку Преглед решења можете да пружите преглед система на високом нивоу. Овај преглед може да садржи навигациону мапу ако је предлог за веб локацију или веб апликацију. Такође можете укључити дијаграм тока тока процеса. Такође, можете укључити дијаграм главних компоненти система.

Циљ је дати особи која доноси одлуку довољно информација како би разумео какав је систем, како ће функционисати и који су главни грађевни блокови. Наравно, ово је само смерница јер организација може имати формални формат који дефинише шта ћете све морати да пружите у предлогу, посебно ако имате посла са владином агенцијом или министарством одбране.

Карактеристике и резултати

Овај одељак пружа механизам за мапирање карактеристика предложеног система у опипљиви резултат. Такође сам видео овај одељак који садржи временску процену за завршетак испоруке, али не волим да је користим, јер је превише рестриктивна и ствара неједнаку улогу. Када радите на пројекту, резултати се можда неће поклапати тачно онако како су записани, па ако сте се на папиру обавезали да ћете завршити испоруку до одређеног времена, то уклања или смањује еластичност касније када заправо радите пројекат.

Још једна колона која се може додати је издање којем припада Испорука. Ово је згодно ако ће се пројекат испоручивати током дужег временског периода, а биће и неколико издања. Ово се такође може применити на Агиле или Леан пројекат у коме свака карактеристика или Усер Стори припада издању.

Концепт је једноставан; за сваку карактеристику у систему наведите назив особине, кратак опис и која ће испорука задовољити захтеве карактеристике.



одлика	Опис	Испоручиво

Буџет и повраћај улагања

Буџет и повраћај улагања вероватно су најважнији део неких руководилаца. Сви желе да знају колико ће их систем коштати или колики ће утицај овај пројекат имати на њихов буџет одељења. Ово је нарочито тачно ако пројекат није био укључен у капитални капитал на почетку фискалне године.

Понекад, чак и ако је пројекат предвиђен буџетом, други пројекат може имати предност над тренутним предлогом и средства се могу преусмерити из предвиђеног извора. Често се одвијају политичка препуцавања на извршном и управљачком нивоу да би се пројекат покренуо са терена, а често постоје непредвиђене околности које могу имати предност над планираним пројектима.

Зато будите спремни да сарађујете са заинтересованом страном да бисте помогли у преговорима или будите флексибилни и проактивни да бисте обезбедили ефикасно решење ако се буџетска ситуација одмакне. Боље је пројекат прилагодити буџетској стварности, чак и ширећи системске резултате током дужег временског периода или чак отићи од пројекта. Много је боље одшетати него радити на пројекту, не примати плату и морати прибећи парници низ пут.

Следећа табела је само у сврху демонстрације како би вам пружила идеју о томе како припремити буџет. Наравно, мораћете да додате сопствене ставке поруџбина које одговарају вашем пројекту. Затим попуњавате количину, јединичну цену, мерну јединицу и укупан износ ставке. Затим саберите укупне ставке поруџбина на дну.

Ово ће пружити добру слику улагања потребног за израду софтверског пројекта. Већина руководилаца са којима сам сарађивао воле да знају колика ће бити стопа поврата или колико ће овај пројекат коштати током времена, тако да такође укључујем једноставну вредност повраћаја улагања и ЦАГР, било користећи сопствене процене и претпоставке (које морају бити објашњено) у предлогу или користећи достављене процене и претпоставке.



Ставка пројекта	Износ	Цена по јединици	УоМ	Укупно
Лиценца за софтвер
Машина (е)
Сервер лиценца
Лиценца базе података
Консултант за развој
Пројектни менаџмент
Обука (време + материјали)

РОИ

Израчун РОИ-а је врло једноставан. У основи је формула добит - трошак подељен трошком. Формула је дата у наставку:

Једина мана је што прорачун не узима у обзир време, тако да је повраћај улагања добар за краткорочне пројекте, али за дугорочне пројекте углавном укључујем ЦАГР (сложена годишња стопа раста). Израчун ЦАГР је стопа приноса из године у годину за одређени тренутак.

ЦАГР

Формула ЦАГР је:

Први део је подела крајње вредности са почетном вредношћу. Резултат је подигнут до степена 1 током броја година улагања. Добијена вредност се одузима са 1.

Предности

У овом одељку наводите пословне предности које ће софтверски пројекат пружити. Они се могу навести у набрајању док су повезани са укупним циљевима. Требали би показати како ће софтвер или систем побољшати пословну вриједност.

Укратко, како ће предложено решење помоћи предузећу да буде успешније и постигне своје циљеве? Користите позитивне речи и реченице.

Ограничења

Одељак ограничења треба да садржи сва материјална и нематеријална ограничења која можете предвидети. То се може односити на опрему, неки сезонски фактор попут угашења производног погона, што већина погона ради најмање једном годишње као пример.

Покушајте да умањите ограничења или их обојите као минимална. Не наводите негативне аспекте софтвера или система или ако морате, онда пружите решења за решавање проблема.