Як написати пропозицію щодо розробки програмного забезпечення

Як написати успішну пропозицію щодо розробки програмного забезпечення.

Кевін Лангедок

Мета пропозиції щодо розробки програмного забезпечення полягає в тому, щоб надати рішення, яке будуть читати ділові люди, тож будьте простим і доречним; триматися подалі від технічних умов, наскільки це можливо. Наступний план можна використовувати як такий, щоб підготувати успішну пропозицію щодо розробки програмного забезпечення. Важливо пам’ятати, що люди, яким ви збираєтесь представити пропозицію, не мають багато часу для читання довгого документа. Ви можете це взяти у мене, я за свої 20 років роботи в галузі інформаційних технологій написав сотні пропозицій: ділові люди хочуть достатньо інформації, щоб дозволити їм прийняти обґрунтоване рішення.

Якщо ви відповідаєте на Запит пропозицій (RFP) і повинні дотримуватись певного діапазону сторінок, оскільки сторінки попередньо надруковані або вимоги до вмісту змушують надмірно довгу пропозицію, то подумайте про використання резюме. я додав розділ, де описано, як підготувати його нижче.

Тривалість пропозиції

Я бачив шаблони та дискусії, які виступають за пропозиції, що тривають 50 або більше сторінок. Повірте, ви втратите інтерес керівника бізнесу після п’ятої сторінки. Після того, як пропозиція буде прийнята, проектна документація, природно, буде більш детальною, оскільки вона буде призначена для команди проекту та буде робочим планом системи. Це стосується більшості клієнтів, але (так, завжди є але, але), якщо пропозиція відповідає на Запит пропозицій (RFP), ви повинні дотримуватися RFP. Крім того, уряд чи військова установа, ймовірно, матимуть суворі вказівки щодо підготовки пропозиції щодо розробки програмного забезпечення та можуть містити кілька сторінок (10, 20, 30, 50 або більше) залежно від складності системи.Це правило все ще справедливо для великих організацій, які можуть мати офіційний процес подання пропозицій, особливо якщо вони є державною корпорацією і повинні дотримуватися будь-яких норм або стандартів Сарбаннеса-Окслі чи ISO.

Резюме

Якщо пропозиція перевищує 20 сторінок, ви можете розглянути резюме, яке є однією сторінкою розділів пропозиції. Ви навіть можете надати резюме у форматі PowerPoint. Якщо ви плануєте використовувати резюме у презентації пропозиції щодо розробки програмного забезпечення, презентуйте пропозицію, використовуючи резюме, і керівник може прочитати пропозицію пізніше, наприклад, під час ділового польоту.

Шаблон

Наступний план - це насправді хороший шаблон, який можна використовувати для підготовки власної пропозиції щодо розробки програмного забезпечення. Я завжди пам’ятаю правило Elevator Pitch під час підготовки пропозиції, і ви теж повинні. В основному Elevator Pitch передбачає, що ваша пропозиція не повинна бути набагато довшою, ніж час, необхідний для того, щоб піднятись ліфтом від першого поверху до верхнього поверху будівлі, коли ви подаєте пропозицію.

Назва проекту

З підзаголовком або узагальненою інформацією щодо пропозиції

Пропозиція повинна містити заголовок та підрозділ, що узагальнює контекст пропозиції програмного забезпечення. Ви також включаєте назву підрозділу, служби, відділу або організації, для яких призначений проект.

Якщо ви відповідаєте на запит про надсилання пропозиції (RFP), укажіть будь-яку інформацію, яка є обов’язковою або вказана як обов’язкова у запиті про подання пропозицій. Я також бачив RFP, які вимагають, щоб ви поставили підписи схвалення на додаток до заголовка на першій сторінці, але в цьому прикладі я помістив підписи на сторінці з розділом «Зміни».

Зміст

На наступній сторінці ви повинні включити зміст із переліком основних розділів пропозиції. За бажанням ви можете включити номери сторінок, якщо пропозиція перевищує п’ять сторінок або якщо це вимагається ЗПП.

Схвалення

Цей розділ має вирішальне значення для процесу, будь то відповідь на запит про надсилання пропозицій, із цього шаблону чи з іншого джерела. У цьому розділі задокументовано підтвердження того, що проект є готовим, та передбачено обов'язкову угоду між різними учасниками проекту. Ви ніколи не повинні розпочинати проект, поки не отримаєте всі необхідні підписи та не отримаєте зобов’язання чемпіона проекту та зацікавлених сторін розпочати проект. В іншому випадку, ви можете опинитися у зв’язку, якщо проект скасовано або якщо обсяг проекту зміниться або результати.

Із затвердженими затвердженнями, зміна обсягу та кінцевих результатів набагато важче вносити, і якщо виникають суперечки, підписані схвалення дадуть чітке розуміння того, про що було узгоджено. Звичайно, завжди є питання тлумачення.

Схвалення повинні містити ім’я особи, її титул, після чого підпис та, нарешті, дату підписання документа.



Ім'я	Назва / роль	Підпис	Дата

Зміни

Розділ Зміни містить журнал усіх змін, які були внесені або будуть внесені в документ Пропозиції щодо розробки програмного забезпечення. У ньому не зафіксовано жодних змін в обсязі самого проекту чи будь-яких інших аспектів проекту. Розділ "Зміни" повинен містити як мінімум ім'я особи, яка вносить зміни, дату зміни та коментар чи опис змін.



Автор	Дата зміни	Опис або коментар

Глосарій та абревіатури

Перелічіть будь-які терміни чи скорочення та їх визначення. Не припускайте, що всі знають значення термінів або скорочень, особливо якщо ви плануєте використовувати зовнішніх консультантів, а терміни є внутрішніми, закладеними у вашу корпоративну культуру та жаргон. Кожна організація має власну мову та абревіатури. Добре використовувати їх у пропозиції, якщо вони належним чином задокументовані.

Крім того, якщо використовуються будь-які галузеві абревіатури, вони також повинні бути задокументовані, щоб кожен чітко розумів значення термінів та абревіатур та формулював кращі тлумачення.

Наступні абревіатури походять від поточного шаблону. Вони наводяться як приклад.

RFP: Запит на пропозицію
Рентабельність інвестицій: рентабельність інвестицій
CAGR: складений річний темп приросту
ІТ: Інформаційні технології
CAPEX: Капітальні витрати
UoM: одиниця виміру

Сфера дії

Сфера пропозиції повинна на високому рівні окреслювати загальні деталі проекту, що включено та виключено. Сфера застосування повинна містити загальний опис, тривалість проекту та основні цілі. Що ви намагаєтесь досягти завдяки цій інвестиції у запропонований проект розробки програмного забезпечення.

Часова шкала

Цей розділ буде включати дати початку та закінчення (приблизні). Обов’язково вбудуйте буфер та сплануйте непередбачені ситуації. Хорошим правилом є додавання буфера 75% до вашої хронології.

Учасники проекту

Учасники проекту повинні включати переможця проекту та зацікавлені сторони. Чемпіоном, як правило, є керівник, який керує загальним проектом та бюджетом. Зацікавлена сторона, як правило, є внутрішнім промоутером або спонсором. Вони також можуть бути чемпіонами залежно від обсягу проекту та або типу організації, яка подає запит на розробку програмного забезпечення. Решта списку містить типові ролі, які люди виконують у проекті.

Далі подано лише як приклад типу ролей, які можуть мати учасники проекту. Деякі люди можуть виконувати більше однієї ролі. Залежно від обсягу проекту, список учасників проекту може бути дуже довгим, або одна і та ж особа може виконувати різні ролі.

Список повинен містити будь-яку інформацію, яка належним чином ідентифікує особу, її роль у проекті, як з ними зв’язатися та які їх обов’язки. Ви можете включити іншу інформацію залежно від RFP або типу організації, з якою ви будете працювати, та їхньої внутрішньої політики.



Член команди	Роль	Контактна інформація	Обов'язки
	Чемпіон
	Зацікавлена сторона
	Керівник проекту
	Архітектор
	Аналітик
	Розробник

Можливість ведення бізнесу

Більшість доступних шаблонів визначають цей розділ як “Бізнес-проблема” або “Постановка проблеми”, однак я часто стикався з керівниками підприємств, які ображаються на те, що вони мають проблеми у своєму бізнес-підрозділі чи процесі. Я пам’ятаю, один директор буквально викинув мене зі свого кабінету, бо я заявив, що ми фіксуємо процес, і вона сказала мені, що це не буде хтось із ІТ (інформаційних технологій), який буде диктувати, якщо у неї проблема з її процесами чи ні.

Тож будьте обережні з формулюванням. Я завжди використовую термін «ділова можливість», оскільки врешті-решт пропозиція є відповіддю на ділову можливість вдосконалити процес, підтримати процес або автоматизувати процес



Ділова заява	Як система задовольнить вимоги
Постраждалий бізнес-процес, ситуація, проблема	Як запропоноване рішення покращить цільову сферу бізнесу
Яка потреба вирішується	Яким чином поточний проект вирішить цю проблему?

Огляд рішення

У розділі "Огляд рішення" ви можете надати огляд системи на високому рівні. Цей огляд може містити навігаційну карту, якщо пропозиція стосується веб-сайту або веб-програми. Ви також можете включити блок-схему потоку процесів. Також ви можете включити схему основних компонентів системи.

Завдання полягає в тому, щоб надати людині, яка приймає рішення, достатньо інформації, щоб вона зрозуміла, що таке система, як вона буде працювати і які основні будівельні блоки. Звичайно, це лише орієнтир, оскільки організація може мати офіційний формат, який визначає, що вам потрібно буде надати в пропозиції, особливо якщо ви маєте справу з державним органом чи міністерством оборони.

Особливості та результати

Цей розділ забезпечує механізм відображення особливостей запропонованої системи до матеріального результату. Я також бачив цей розділ, який містить оцінку часу для завершення постачання, але мені не подобається користуватися цим, оскільки він занадто обмежує і створює нерівність. Під час роботи над проектом результати можуть не співпадати точно так, як це записано, отже, якщо ви зобов’язалися на папері закінчити кінцевий результат до певного часу, це знімає або зменшує будь-яку еластичність пізніше, коли ви фактично виконуєте проект.

Ще один стовпець, який можна додати, - це Випуск, до якого належить Доставка. Це зручно, якщо проект буде представлений протягом більш тривалого періоду, і буде кілька випусків. Це також може стосуватися проекту на основі Agile або Lean, де кожна функція або історія користувача належить до випуску.

Концепція проста; для кожної функції в системі вкажіть назву об’єкта, короткий опис та те, який результат задовольнятиме вимогу щодо функції.



Особливість	Опис	Результат

Бюджет та рентабельність інвестицій

Бюджет та рентабельність інвестицій - це, мабуть, найважливіша частина для деяких керівників. Вони всі хочуть знати, скільки їм обійдеться система або який вплив цей проект матиме на бюджет їхнього відділу. Це особливо вірно, якщо проект не був включений до складу капіталовкладень на початку фінансового року.

Іноді, навіть якщо проект було передбачено бюджетом, інший проект може мати пріоритет над поточною пропозицією, і кошти можуть бути спрямовані з передбаченого джерела. Часто відбуваються політичні суперечки на рівні виконавчої та управлінської влади, щоб розпочати проект, і часто трапляються непередбачені обставини, які можуть мати перевагу над запланованими проектами.

Тож будьте готові співпрацювати зі своїми зацікавленими сторонами, щоб допомогти у переговорах, або будьте гнучкими та ініціативними, щоб надати діюче рішення, якщо ситуація з бюджетом йде вбік. Краще адаптувати проект до бюджетної реальності, навіть поширюючи результати системи протягом більш тривалого періоду часу або навіть відійти від проекту. Набагато краще піти геть, ніж працювати над проектом і не отримувати зарплату, і доводиться вдаватися до судових процесів.

Наступна таблиця призначена лише для демонстрації, щоб дати вам уявлення про те, як скласти бюджет. Звичайно, вам потрібно буде додати власні позиції, щоб відповідати вашому проекту. Потім ви вводите кількість, одиницю ціни, одиницю виміру та загальну позицію. Потім підрахуйте підсумки позиції внизу.

Це дасть хорошу картину інвестицій, необхідних для реалізації проекту програмного забезпечення. Більшість керівників, з якими я працював, люблять знати, якою буде норма прибутку або скільки коштуватиме цей проект з часом, тому я також включаю просте значення рентабельності інвестицій та показник CAGR, використовуючи власні оцінки та припущення (які повинні бути пояснюється) у пропозиції або використовуючи подані оцінки та припущення.



Пункт проекту	Сума	Ціна за одиницю	UoM	Разом
Ліцензія на програмне забезпечення
Машина (и)
Серверна ліцензія
Ліцензія на базу даних
Консультант з розвитку
Управління проектами
Навчання (час + матеріали)

Рентабельність

інвестицій Розрахунок рентабельності інвестицій дуже простий. В основному формулою є прибуток - вартість, поділена на вартість. Формула подана нижче:

Єдиним недоліком є те, що при розрахунку не враховується час, тому рентабельність інвестицій хороша для короткострокових проектів, але для довгострокових проектів я, як правило, включаю CAGR (складений річний темп приросту). Розрахунок CAGR - це прибутковість за рік за певний момент часу.

CAGR

Формула CAGR:

Перша частина - це ділення кінцевого значення на початкове. Результат піднімається до рівня 1 за кількість вкладених років. Отримане значення віднімається на 1.

Переваги

У цьому розділі ви перелічите ділові переваги, які надасть проект програмного забезпечення. Їх можна перерахувати у форматі маркера, якщо вони відповідають загальним цілям. Вони повинні продемонструвати, як програмне забезпечення або система підвищують цінність бізнесу.

У двох словах, як запропоноване рішення допоможе бізнесу досягти успіху та досягти поставлених цілей? Використовуйте позитивні слова та речення.

Обмеження

Розділ обмежень повинен перерахувати будь-які матеріальні та нематеріальні обмеження, які ви можете передбачити. Це може стосуватися обладнання, деякого фактора сезонності, наприклад, закриття виробничого заводу, що, як приклад, робить більшість заводів принаймні раз на рік.

Спробуйте применшити обмеження або намалювати їх як мінімальні. Не перелічуйте жодних негативних аспектів програмного забезпечення чи системи, а якщо потрібно, надайте рішення для вирішення проблем.