Бизнес план западная методология разработки

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

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.

Когда использовать каскадную методологию?

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

2. «V-Model»

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

Пример нашей работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.

Когда использовать V-модель?

Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
Для малых и средних проектов, где требования четко определены и фиксированы.
В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

3. «Incremental Model» (инкрементная модель)

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

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.

Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.

Когда использовать инкрементную модель?

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

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

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

Модель быстрой разработки приложений включает следующие фазы:

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

Когда используется RAD-модель?

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

5. «Agile Model» (гибкая методология разработки)

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

В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

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

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

Когда использовать Agile?

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

6. «Iterative Model» (итеративная или итерационная модель)

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

На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.

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

Когда оптимально использовать итеративную модель?

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

7. «Spiral Model» (спиральная модель)

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

Спиральная модель предполагает 4 этапа для каждого витка:

планирование;
анализ рисков;
конструирование;
оценка результата и при удовлетворительном качестве переход к новому витку.

Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование. На проекте по разработке СЭД для ОДУ Сибири СО ЕЭС два совещания об изменении кодификации разделов электронного архива занимают в 10 раз больше времени, чем объединение двух папок программистом. Государственные проекты, в которых мы участвовали, начинались с подготовки экспертным сообществом дорогостоящей концепции, которая отнюдь не всегда бесполезна, поскольку окупается в масштабах страны.

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

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

О технологиях разработки:
Ещё раз про семь основных методологий разработки.
10 главных ошибок масштабирования систем.
8 принципов планирования разработки, упрощающих жизнь.
5 главных рисков при заказной разработке ПО.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Источник

В практике бизнес-планирования используются методики: международная, национальная, локальная.

Международная методика разработана ЮНИДО — Комитетом по проблемам промышленного развития Организации Объединенных Наций (UNIDO — United Nations Industrial Development Organization) и представляет собой единый подход к разработке технико-экономического обоснования (ТЭО) и бизнес-плана проекта, что позволяет общаться специалистам из разных стран мира. Большинство известных на данный момент компьютерных систем для бизнес-планирования опирается на методику ЮНИДО.

В соответствии с методикой ЮНИДО для обоснования инвестиций составляется или ТЭО, или бизнес-план. ТЭО отличается от бизнес-плана следующим:

• обычно ТЭО разрабатывается для проектов по внедрению новых технологий, процессов и оборудования на уже существующем, работающем предприятии, поэтому в нем часто отсутствуют анализ рынка, маркетинговая стратегия, описание предприятия и продукта, а также анализ рисков;
• в ТЭО приводятся информация о причинах выбора предлагаемых технологий, процессов и решений, принятых в проекте, результаты, обусловленные их внедрением, и экономические расчеты эффективности. Поэтому можно сказать, что по сравнению с бизнес-планом ТЭО ориентировано на технические объекты и рассматривает более узкий круг вопросов.

Методика ЮНИДО предлагает излагать материалы в ТЭО в следующей последовательности:

1. Общие исходные данные и условия.
2. Рынок и мощность предприятия.
3. Материальные факторы производства.
4. Место нахождения предприятия.
5. Проектно-конструкторская документация.
6. Организация предприятия и накладные расходы.
7. Трудовые ресурсы.
8. Планирование сроков реализации проекта.
9. Финансово-экономическая оценка проекта.

Согласно методике ЮНИДО, бизнес-план должен состоять из 11 глав.

Глава 1. Резюме — краткое изложение выводов и рекомендаций всех основных разделов бизнес-плана.

Глава 2. Предыстория и основная идея проекта — наименования и адреса учредителей проекта, стратегия проекта, история проекта, меры экономической и промышленной политики, способствующие его осуществлению.

Глава 3. Анализ рынка и стратегия маркетинга — обобщение результатов анализа рынка, спроса, прогнозируемого объема продаж, целевых рынков, пояснение стратегии маркетинга.

Глава 4. Сырье и материалы — общие данные о наличии: сырья (необработанного сырья и полуфабрикатов), обработанных промышленных материалов и комплектующих изделий, вспомогательных материалов, вспомогательных производственных ресурсов, коммунальных услуг, запасных частей; годовые потребности в материальных ресурсах и сметные расходы.

Глава 5. Место осуществления, строительная площадка и экологическая оценка — описание места осуществления проекта, строительной площадки, краткая характеристика экологических последствий.

Глава 6. Инженерное проектирование и технология — изложение производственной программы и указание производственной мощности предприятия, описание выбранной технологии, краткая характеристика основных видов производственных активов (оборудования и т.д.), их наличия и стоимости, описание схемы расположения объектов и охват проекта, основные инженерные сооружения.

Глава 7. Организация производства и накладные расходы — рассмотрение основных элементов организационной структуры и управления.

Глава 8. Людские ресурсы — указание необходимого состава и численности рабочей силы, состава и численности административного персонала, данных о стоимости и наличии таких ресурсов, потребностях в профессиональной подготовке.

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

Глава 10. Финансовая оценка — определение общих инвестиционных затрат — основных показателей инвестиционных затрат в местной и иностранной валюте по следующим статьям:

• земля и подготовленные строительные площадки;
• производственные объекты и инженерные сооружения;
• финансовая оценка, основанная на оценочных величинах (срок

окупаемости, простая норма прибыли, точка безубыточности,

внутренняя норма доходности, анализ чувствительности).

Глава 11. Экономический анализ издержек и прибыли —

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

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

В России в 1999 г. введены в действие Методические рекомендации по оценке эффективности инвестиционных проектов (вторая редакция), утвержденные Министерством экономики РФ, Министерством финансов РФ, Государственным комитетом РФ по строительной, архитектурной и жилищной политике Постановлением № ВК477 от 21.06.99 (в дальнейшем Методические рекомендации), где учтена специфика российской экономики на современном этапе:

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

Анализ методических рекомендаций по разработке бизнес-планов проектов (ЮНИДО, национальных) показывает, что структура и содержание разделов бизнес-плана различаются несущественно, несмотря на их разнообразие.

Локальные методики разработки бизнес-планов проектов создаются отраслевыми инвестиционными банками и учитывают отраслевую специфику деятельности и уникальность проектов. Бизнес-план должен быть достаточно подробным, чтобы, ознакомившись с ним, потенциальный инвестор смог получить полное представление о предлагаемом бизнес-проекте и понять его цели. Ниже приведена укрупненная структура разделов бизнес-плана, составленная на основе изучения структур ряда отечественных бизнес-планов реальных бизнес-проектов, а также структур, рекомендуемых в отечественной и зарубежной литературе и личного опыта автора:

Раздел 1. Резюме.

Раздел 2. Инициатор проекта.

Раздел 3. Идея предлагаемого проекта.

Раздел 4. Оценка рынка.

Раздел 5. План маркетинга.

Раздел 6. План производства.

Раздел 7. Организационный план.

Раздел 8. Инвестиционный план.

Раздел 9. Оценка риска и страхование.

Раздел 10. Финансовый план.

Раздел 11. Обеспечение.

Раздел 12. Приложение.

Сравнение и анализ структур бизнес-плана по методике ЮНИДО и локальной показывают их следующие различия:

• в методике ЮНИДО выделены в отдельные главы (4, 5, 6, 7, 8, 9) вопросы, которые в российских методиках входят в раздел «План производства»;
• в методике ЮНИДО в отдельные главы не выделены инвестиционный и организационный планы. Однако здесь рассматривается весь спектр вопросов, необходимых для разработки бизнес-плана и обоснования инвестиций.

Источник