Как написать предложение по разработке программного обеспечения

Как написать успешное предложение по разработке программного обеспечения.

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

Цель предложения по разработке программного обеспечения - представить решение, которое будут прочитаны деловыми людьми, поэтому делайте его простым и по существу; насколько это возможно, избегайте технических терминов. Следующая схема может быть использована как есть для подготовки успешного предложения по разработке программного обеспечения. Важно помнить, что у людей, которым вы собираетесь представить предложение, не так много времени, чтобы прочитать длинный документ. Можете поверить в это, я написал сотни предложений за свои 20 с лишним лет работы в информационных технологиях: деловые люди хотят информации, достаточной для того, чтобы они могли принять обоснованное решение.

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

Предложение Длина

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

Управляющее резюме

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

Шаблон

Следующий план на самом деле является хорошим шаблоном, который вы можете использовать для подготовки собственного предложения по разработке программного обеспечения. Я всегда помню о правиле Elevator Pitch при подготовке предложения, и вы должны тоже. По сути, лифт оговаривает, что ваше предложение не должно быть намного длиннее, чем время, необходимое для того, чтобы подняться на лифте с первого этажа на верхний этаж здания по пути, чтобы представить предложение.

Название Проекта

С подзаголовком или обобщенной информацией о предложении

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

Если вы отвечаете на RFP (Request For Proposal), включите любую информацию, которая требуется или указана как обязательная в RFP. Я также видел запросы предложений, в которых вас просят поставить подписи утверждения в дополнение к заголовку на первой странице, но в этом примере я поставил подписи на странице с разделом «Изменения».

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

Утверждения

Этот раздел имеет решающее значение для процесса, будь то ответ на запрос предложения, из этого шаблона или из какого-либо другого источника. В этом разделе документируются подтверждения того, что проект запущен, и содержится обязывающее соглашение между различными участниками проекта. Вы никогда не должны начинать проект, пока не получите все необходимые подписи и не получите обязательства от руководителя проекта и заинтересованных сторон начать проект. В противном случае вы можете оказаться в затруднительном положении, если проект будет отменен, или если масштаб проекта изменится или результаты.

При наличии утверждений внести изменения в объем и результаты намного сложнее, и в случае возникновения разногласий подписание согласований обеспечит четкое (э) понимание того, что было согласовано. Конечно, всегда есть вопрос интерпретации.

Утверждения должны включать имя человека, его должность, подпись и, наконец, дату подписания документа.



имя	Название роли	Подпись	Дата

Изменения

В разделе «Изменения» содержится журнал всех изменений, которые были внесены или будут внесены в документ «Предложение по разработке программного обеспечения». Он не документирует никаких изменений объема самого проекта или любого другого аспекта проекта. Раздел «Изменения» должен включать как минимум имя лица, вносящего изменение, дату изменения и комментарий или описание изменения.



Автор	Дата изменения	Описание или комментарий

Глоссарий и сокращения

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

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

Следующие акронимы взяты из текущего шаблона. Они приведены в качестве примера.

RFP: Запрос предложений
ROI: возврат инвестиций
CAGR: совокупный годовой темп роста
IT: информационные технологии
CAPEX: капитальные затраты
UoM: Единица измерения

Объем

Объем предложения должен описывать на высоком уровне общие детали проекта, что включено и что исключено. Объем должен включать общее описание, продолжительность проекта, основные цели. Чего вы пытаетесь достичь с помощью этих инвестиций в предлагаемый проект разработки программного обеспечения?

Лента новостей

В этом разделе будут указаны даты начала и окончания (ориентировочные). Обязательно создайте буфер и планируйте непредвиденные обстоятельства. Хорошее практическое правило - добавить к временной шкале буфер на 75%.

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

В состав участников проекта должны входить руководитель проекта и заинтересованные стороны. Чемпионом обычно является руководитель, который управляет общим проектом и бюджетом. Заинтересованная сторона обычно является внутренним промоутером или спонсором. Они также могут быть лидерами в зависимости от масштабов проекта и / или типа организации, которая запрашивает предложение по разработке программного обеспечения. Остающийся список содержит типичные роли, которые люди выполняют в проекте.

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

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



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

Бизнес-возможности

Большинство доступных шаблонов определяют этот раздел как «Бизнес-проблема» или «Постановка проблемы», однако я часто сталкивался с руководителями бизнеса, которые обижались на то, что у них есть проблема в их бизнес-подразделении или процессе. Я помню, как один директор буквально выгнал меня из своего офиса, потому что я заявил, что мы исправляем процесс, и она сказала мне, что это не будет кто-то из ИТ (информационных технологий), который будет диктовать, если у нее есть проблема с ней процессы или нет.

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



Заявление о бизнесе	Как система удовлетворит требования
Затронутый бизнес-процесс, ситуация, проблема	Как предлагаемое решение улучшит целевую сферу бизнеса
Какие потребности решаются	Как текущий проект решит эту проблему

Обзор решения

В разделе «Обзор решения» вы можете предоставить общий обзор системы. Этот обзор может включать в себя карту навигации, если предложение относится к веб-сайту или веб-приложению. Вы также можете включить блок-схему процесса. Также вы можете включить схему основных компонентов системы.

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

Особенности и результаты

В этом разделе представлен механизм, позволяющий сопоставить особенности предлагаемой системы с материальными результатами. Я также видел этот раздел, содержащий оценку времени для завершения конечного результата, но мне не нравится использовать его, потому что он слишком ограничивает и создает связь. При работе над проектом конечные результаты могут не совпадать в точности так, как написано, поэтому, если вы на бумаге взяли на себя обязательство завершить результат к определенному времени, это устраняет или снижает любую эластичность позже, когда вы фактически выполняете проект.

Еще один столбец, который можно добавить, - это Релиз, которому принадлежит Результат. Это удобно, если проект будет реализован в течение длительного периода времени и будет несколько выпусков. Это также может относиться к проекту, основанному на Agile или Lean, где каждая функция или пользовательская история принадлежит выпуску.

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



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

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

Бюджет и рентабельность инвестиций, вероятно, являются наиболее важной частью для некоторых руководителей. Все они хотят знать, во сколько им обойдется система или какое влияние этот проект окажет на бюджет их отдела. Это особенно верно, если проект не был включен в капитальные затраты в начале финансового года.

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

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

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

Это даст хорошее представление об инвестициях, необходимых для создания программного проекта. Большинство руководителей, с которыми я работал, хотели знать, какой будет норма прибыли или сколько будет стоить этот проект с течением времени, поэтому я также включаю простое значение ROI и CAGR, используя свои собственные оценки и предположения (которые должны быть объяснены) в предложении или с использованием предоставленных оценок и предположений.



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

ROI

Расчет ROI очень прост. По сути, формула - прибыль - стоимость деленная на стоимость. Формула представлена ниже:

Единственным недостатком является то, что при расчете не учитывается время, поэтому рентабельность инвестиций хороша для краткосрочных проектов, но для долгосрочных проектов я обычно включаю CAGR (сложный годовой темп роста). Расчет CAGR - это годовая норма прибыли для определенного момента времени.

CAGR

Формула CAGR:

Первая часть - это деление конечного значения на начальное. Результат возводится в степень 1 за количество вложенных лет. Полученное значение вычитается на 1.

Льготы

В этом разделе вы перечисляете бизнес-преимущества, которые предоставляет программный проект. Их можно перечислить в виде маркеров, если они связаны с общими целями. Они должны продемонстрировать, как программное обеспечение или система повысят ценность для бизнеса.

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

Ограничения

В разделе ограничений должны быть перечислены все материальные и нематериальные ограничения, которые вы можете предвидеть. Это может быть связано с оборудованием, некоторым сезонным фактором, например, с остановкой производственного предприятия, что на большинстве заводов происходит не реже одного раза в год.

Постарайтесь преуменьшить ограничения или изобразить их как минимальные. Не перечисляйте какие-либо отрицательные аспекты программного обеспечения или системы или, если необходимо, предлагайте обходные решения.