Съдържание:
- Дължина на предложението
- Резюме
- Шаблонът
- Заглавие на Проекта
- Съдържание
- Одобрения
- Промени
- Речник и съкращения
- Обхват
- Хронология
- Членове на проекта
- Бизнес възможност
- Преглед на решението
- Характеристики и резултати
- Бюджет и възвръщаемост на инвестициите
- Ползи
- Ограничения
Как да напиша успешно предложение за разработка на софтуер.
Кевин Лангедок
Целта на предложението за разработка на софтуер е да предаде решение, което ще бъде прочетено от деловите хора, така че бъдете лесни и точни; стойте далеч от техническите условия, доколкото е възможно. Следният контур може да се използва такъв, какъвто е, за да се подготви успешно предложение за разработка на софтуер. Важно е да имате предвид, че хората, които ще представите предложението, нямат много време да четат дълъг документ. Можете да го вземете от мен, аз съм написал стотици предложения през последните си 20 години в областта на информационните технологии: бизнесмените искат точно толкова информация, че да им позволят да вземат информирано решение.
Ако отговаряте на Заявка за предложение (RFP) и трябва да спазвате определен диапазон от страници, тъй като страниците са предварително отпечатани или изискванията за съдържание ви принуждават да имате прекалено дълго предложение, тогава помислете за използването на Резюме. Добавих раздел, описващ как да се подготви по-долу.
Дължина на предложението
Виждал съм шаблони и дискусии, които застъпват предложения, които продължават за 50 или страници. Повярвайте ми, ще загубите интереса на ръководителя на бизнеса след петата страница. След като предложението бъде прието, проектните документи естествено ще бъдат по-подробни, тъй като ще бъдат предназначени за екипа на проекта и ще бъдат работните планове за системата. Това ще се отнася за повечето клиенти, но (да, винаги има но, но), ако предложението е в отговор на Заявка за предложение (RFP), тогава трябва да се придържате към RFP. Също така, правителствена или военна агенция вероятно ще има строги насоки как да подготви предложение за разработка на софтуер и може да включва няколко страници (10, 20, 30, 50 или повече) в зависимост от сложността на системата.Това правило все още важи за големи организации, които могат да имат официален процес на предложения, особено ако са публична корпорация и трябва да се придържат към всякакви разпоредби или стандарти на Sarbannes-Oxley или ISO.
Резюме
Ако предложението е над 20 страници, можете да помислите за предоставяне на Резюме, което е едностранично на разделите в предложението. Можете дори да предоставите резюме във формат PowerPoint. Ако планирате да използвате Резюме в презентацията на предложението за разработка на софтуер, представете го с помощта на Резюме и изпълнителният директор може да прочете предложението по-късно, например по време на бизнес полет.
Шаблонът
Следващият контур всъщност е добър шаблон, който можете да използвате, за да подготвите собствено предложение за разработка на софтуер. Винаги имам предвид правилото за стъпката на асансьора, когато подготвям предложение, и вие също. По принцип Elevator Pitch предвижда, че вашето предложение не трябва да бъде много по-дълго от времето, необходимо за изкачване на асансьор от партера до последния етаж на сграда по пътя ви, за да представите предложение.
Заглавие на Проекта
С подзаглавие или обобщена информация за предложението
Предложението трябва да има заглавие и подраздел, обобщаващ контекста на софтуерното предложение. Включвате и името на подразделението, службата, отдела или организацията, за които е предназначен проектът.
Ако отговаряте на RFP (Искане за предложение), тогава включете всяка информация, която се изисква или е посочена като задължителна в RFP. Виждал съм и RFP, които изискват да поставите подписите за одобрение в допълнение към заглавието на първата страница, но в този пример поставих подписите на страницата с раздела Промени.
Съдържание
На следващата страница трябва да включите съдържание, изброяващо основните раздели на предложението. По желание можете да включите номерата на страниците, ако предложението надвишава пет страници или ако това се изисква от RFP.
Одобрения
Този раздел е от решаващо значение за процеса, независимо дали е отговор на RFP или от този шаблон или от друг източник. Този раздел документира потвържденията, че проектът е в ход и предоставя обвързващо споразумение между различните членове на проекта. Никога не трябва да стартирате проект, докато не сте получили всички необходими подписи и не сте поели ангажимент от шампиона на проекта и заинтересованите страни да стартирате проекта. В противен случай може да се окажете в обвързване, ако проектът бъде отменен или ако обхватът на проекта се промени или резултатите.
С установените одобрения промените в обхвата и резултатите са много по-трудни за извършване и ако има спорове, подписването на одобрения ще осигури ясно разбиране за договореното. Разбира се, винаги има въпрос за тълкуване.
Одобренията трябва да включват името на лицето, неговото заглавие, последвано от техния подпис и накрая датата на подписване на документа.
Име | Заглавие / Роля | Подпис | Дата |
---|---|---|---|
Промени
Разделът „Промени“ предоставя дневник на всички промени, които са направени или ще бъдат направени в документа „Предложение за разработка на софтуер“. Той не документира промени в обхвата на самия проект или друг аспект на проекта. Разделът Промени трябва да включва най-малко името на лицето, което прави промяната, датата на промяната и коментар или описание на промяната.
Автор | Дата на промяна | Описание или коментар |
---|---|---|
Речник и съкращения
Избройте всички термини или съкращения и техните определения. Не предполагайте, че всеки знае значението на термините или съкращенията, особено ако планирате да използвате външни консултанти и условията са вътрешни, вградени във вашата корпоративна култура и жаргон. Всяка организация има свой собствен жаргон и съкращения. Добре е да ги използвате в предложението, стига да са надлежно документирани.
Също така, ако се използват специфични за индустрията съкращения, те трябва да бъдат документирани, така че всеки да има ясно разбиране за значението на термините и съкращенията и да формулира по-добри тълкувания.
Следните съкращения са от текущия шаблон. Те са дадени като пример.
- RFP: Искане за предложение
- ROI: Възвръщаемост на инвестицията
- CAGR: Съставен годишен темп на растеж
- IT: Информационни технологии
- CAPEX: Капиталови разходи
- UoM: мерна единица
Обхват
Обхватът на предложението трябва да очертае на високо ниво общите подробности за проекта, какво е включено и изключено. Обхватът трябва да предоставя цялостно описание, продължителността на проекта и основните цели. Какво се опитвате да постигнете с тази инвестиция в предложения проект за разработване на софтуер.
Хронология
Този раздел ще включва началната и крайната дата (прогнозни). Не забравяйте да вградите буфер и да планирате непредвидени ситуации. Добро правило е да добавите 75% буфер към вашата времева линия.
Членове на проекта
Членовете на проекта трябва да включват шампиона на проекта и заинтересованите страни. Шампионът обикновено е изпълнителен директор, който управлява цялостния проект и бюджета. Заинтересованата страна обикновено е вътрешен организатор или спонсор. Те също могат да бъдат шампион в зависимост от обхвата на проекта и или от типа организация, която иска предложението за разработка на софтуер. Останалият списък съдържа типични роли, които хората изпълняват в даден проект.
Следното е предоставено само като пример за типа роли, които участниците в проекта могат да имат. Някои хора могат да имат повече от една роля. В зависимост от обхвата на проекта списъкът на членовете на проекта може да бъде много обширен или едно и също лице може да поеме различни роли.
Списъкът трябва да съдържа всякаква информация, която правилно идентифицира човека, неговата роля в проекта, как да достигне до тях и какви са техните отговорности. Можете да включите друга информация в зависимост от RFP или типа организация, с която ще работите, и техните вътрешни политики.
Член на екипа | Роля | Информация за връзка | Отговорности |
---|---|---|---|
Шампион |
|||
Заинтересована страна |
|||
Ръководител проект |
|||
Архитект |
|||
Аналитик |
|||
Разработчик |
Бизнес възможност
Повечето налични шаблони определят този раздел като „Бизнес проблем“ или „Декларация за проблем“, но често съм срещал бизнес лидери, които се обиждат от факта, че имат проблем в своята бизнес единица или процес. Спомням си, че един директор буквално ме изхвърли от кабинета си, защото бях заявил, че оправяме процес и тя ми каза, че няма да е някой от ИТ (Информационни технологии), който ще диктува дали има проблем с нейните процеси или не.
Така че бъдете внимателни с формулировката. Винаги използвам термина „Бизнес възможност“, тъй като в крайна сметка предложението е в отговор на бизнес възможност за подобряване на процеса, поддържане на процес или автоматизиране на процес
Бизнес декларация | Как системата ще задоволи изискването |
---|---|
Засегнат бизнес процес, ситуация, проблем |
Как предложеното решение ще подобри целевата бизнес област |
Разрешава се каква нужда |
Как ще се справи настоящият проект с него |
Преглед на решението
В раздела „Преглед на решенията“ можете да предоставите общ преглед на системата на високо ниво. Този преглед може да включва карта за навигация, ако предложението е за уеб сайт или уеб приложение. Можете също да включите блок-схема на потока на процеса. Също така можете да включите диаграма на основните компоненти на системата.
Целта тук е да се даде на човека, който взема решението, достатъчно информация, така че да разбере каква е системата, как ще работи и кои са основните градивни елементи. Разбира се, това е само насока, тъй като организацията може да има официален формат, който определя какво ще трябва да предоставите в предложението, особено ако имате работа с държавна агенция или министерство на отбраната.
Характеристики и резултати
Този раздел предоставя механизъм за картографиране на характеристика на предложената система към осезаем резултат. Виждал съм и този раздел, съдържащ прогноза за време за завършване на резултата, но не ми харесва да го използвам, защото е твърде ограничителен и създава равенство. Когато работите по проекта, резултатите може да не се подредят точно както е записано, така че ако сте се ангажирали на хартия да завършите даден резултат до определено време, това премахва или намалява еластичността по-късно, когато всъщност правите проекта.
Друга колона, която може да се добави, е изданието, към което принадлежи Доставката. Това е удобно, ако проектът ще бъде доставен за по-дълъг период от време и ще има няколко издания. Това може да се отнася и за Agile или Lean базиран проект, където всяка функция или потребителска история принадлежи към издание.
Концепцията е проста; за всяка характеристика в системата предоставете името на характеристиката, кратко описание и кой резултат ще задоволи изискването за характеристика.
Особеност | Описание | Доставим |
---|---|---|
Бюджет и възвръщаемост на инвестициите
Бюджетът и възвръщаемостта на инвестициите е може би най-важната част за някои ръководители. Всички те се притесняват да разберат колко ще им струва системата или колко голямо въздействие ще окаже този проект върху бюджета на отдела им. Това е особено вярно, ако проектът не е бил включен в Capex в началото на финансовата година.
Понякога, дори ако проектът е бил предвиден в бюджета, друг проект може да има предимство пред текущото предложение и средствата могат да бъдат отклонени от предвидения източник. Често се случват политически спорове на изпълнително и управленско ниво, за да се измъкне даден проект и често има непредвидени обстоятелства, които могат да имат предимство пред планираните проекти.
Така че бъдете готови да работите със заинтересованите страни, за да помогнете при преговорите, или бъдете гъвкави и инициативни, за да осигурите работещо решение, ако дадена бюджетна ситуация се обърка. По-добре е да приспособите проекта към бюджетната реалност, дори да разпространявате резултатите на системата за по-дълъг период от време или дори да се отдалечите от проекта. Много по-добре е да си тръгнете, отколкото да сте работили по проект и да не получавате пари и да се налага да прибягвате до съдебни спорове по пътя.
Следващата таблица е само за демонстрационни цели, за да ви даде представа как да подготвите бюджет. Естествено, ще трябва да добавите свои собствени договорени покупки, за да отговарят на вашия проект. След това попълвате количеството, единичната цена, мерната единица и общата позиция. След това съберете сумата на договорената покупка в долната част.
Това ще осигури добра картина на инвестицията, необходима за извършване на софтуерния проект. Повечето мениджъри, с които съм работил, искат да знаят каква ще бъде нормата на възвръщаемост или колко ще струва този проект с течение на времето, така че включвам и проста стойност на възвръщаемостта на инвестициите и CAGR, като използвам собствените си оценки и предположения (които трябва да бъдат обяснено) в предложението или използвайки предоставените оценки и предположения.
Елемент на проекта | Количество | Единична цена | UoM | Обща сума |
---|---|---|---|---|
Лиценз за софтуер |
||||
Машина (и) |
||||
Сървърна лицензия |
||||
Лиценз за база данни |
||||
Консултант по развитие |
||||
Управление на проекти |
||||
Обучение (време + материали) |
ROI
Изчисляването на ROI е много лесно. По принцип формулата е печалби - разходи, разделени на разходи. Формулата е предоставена по-долу:
Единственият недостатък е, че изчислението не отчита времето, така че възвръщаемостта на инвестициите е добра за краткосрочни проекти, но за дългосрочни проекти обикновено включвам CAGR (Compound Year Growth Rate). Изчислението на CAGR е годишна норма на възвръщаемост за определен момент от време.
CAGR
Формулата CAGR е:
Първата част е разделянето на крайната стойност на началната стойност. Резултатът се повишава до степен 1 за броя на инвестираните години. Получената стойност се изважда от 1.
Ползи
В този раздел изброявате бизнес ползите, които софтуерният проект ще осигури. Те могат да бъдат изброени във формат на символи, стига да са обвързани с общите цели. Те трябва да демонстрират как софтуерът или системата ще повишат бизнес стойността.
Накратко, как предложеното решение ще помогне на бизнеса да бъде по-успешен и да постигне своите цели? Използвайте положителни думи и изречения.
Ограничения
Разделът с ограничения трябва да изброява всички материални и нематериални ограничения, които можете да предвидите. Това може да се отнася до оборудване, някакъв сезонен фактор като спиране на производствен завод, което повечето заводи правят поне веднъж годишно като пример.
Опитайте се да омаловажите ограниченията или да ги нарисувате като минимални. Не изброявайте никакви негативни аспекти на софтуера или системата или ако трябва, тогава предоставете решения за заобикаляне.
© 2012 Кевин Лангедок