Каждое описанное действие или элемент необходим для создания жизнеспособного проекта который будет радовать основателя и приносить результаты.

1. You can’t manage what you can’t measure. W. Edwards Deming

2. Обязательные законы к пониманию — причины-следствия, инь-янь, законы композиции, законы жизнеспособности систем (ТРИЗ)

3. WRM - студийная система в которой мы ведем все наши проекты

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

5. Персонажи (actors) — люди, клиенты, другие системы

6. Набор данных (DataSet) — именованные данные, пример: Регистрационные данные: имя, email, пароль, фото

7. Экран (Screen) — экран системы с ее элементами интерфейса, визуальное представление в виде макета или фотографии реального экрана устройства.

8. Транзакция (transaction) — воздействие персонажа на систему и ответная реакция системы на это воздейстие. Является основным базовым элементом любого создаваемого интернет-проекта.

1. Реальные ситуации как вызовы. Job Stories.
2. Миссия
3. Цели
4. Функции / возможности системы
5. Сценарии использования системы

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

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

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

Что обозначает неминуемый успех проекта.

Фиксируем все в нашей системе WRM:

Каждый проект (система) призывается в жизнь для решения вполне конкретной главной задачи - это и называется миссией проекта.

Если мы упешно прошли этап формирования проблемных ситуаций или вызовов, то миссией будет - обобщение всех этих ситуаций одним предложением. Что их объединяет?

Чтобы сформулировать миссию ответьте на вопрос - что будет результатом от жизнедеятельности проекта?

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

Хорошая миссия позволяет не сбиться с пути, ставить правильные цели ведущие к нужному результату, не размываясь на неверные шаги.

Итак надо записать - какая польза и ценность, чем проще чем лучше.

Пример миссии корпортативного сайта по продаже товаров производимых под заказ и услуг (из нашей системы работы над проектами WRM):

Миссия проекта выполняется путем достижения целей проекта.

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

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

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

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

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

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

Транзакция является базовым элементом любого сайта (системы, мобильного приложения ...).

Табличка транзакций выглядит следующим образом:

Фактически таблчика транзакций (иногда в комплекте с зарисовками) - являются примером дизайн решений:

Фактически сценарий — это детальная проработка дизайн решения которое идет в дизайн-оформление, в проектировку интерфейсов, в программирование, и после в тестирование и приемку.

Целевой сценарий взаимодействия состоит из расшифрованных на точные взаимодействия описанных ранее транзакций.

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

Сценарий использования системы состоит из следующих элементов:

• Название
• Участники — кто взаимодействуют с системой по сценарию и производят над ней некоторые воздействия
• Цель — без цели сценарий бесполезен — что намеревается достигнуть этим сценарием?
• Активаторы — события инициирующие выполнение сценария
• Предварительные условия — без выполнения которых старт сценария не имеет смысла
• Гарантии результата — измеряемые критерии, подтверждающие правильность выполнения сценария
• Основной ход событий — последовательность транзакций приводящих к выполнение сценария к достижению обозначенной цели.
• Системные процессыы — связанные сценарии которые могут быть запущены к выполнению внутри системы (рассылка сообщений, пережим картинок, публикация в разных сетях информации по расписанию, очистка неиспользованных картинок и тд.)

1. Клиент самостоятельно, или при помощи аналитиков студии (оплачивается отдельно) формулирует необходимое целевое действие в рамках дерева целей проекта.
2. Под данный сценарий студией предоставляется вариант решения сформулированный в свободной форме (с двумя шагами откроем форму и тут будет окошко, жмем окей и после этого редирект на главную) с указанием стоимости в виде количества требуемых транзакций на реализацию данного решения.
3. Клиент выбирает какое решение ему необходимо и подходит по бюджету и добавляет его к заказу.
4. После оплаты решение прорабатывается до деталей в виде составленных транзакций со всеми элементами - роли, действия, затрагиваемые элементы интерфейса, реакция системы.
5. Клиент вносит несущественные коррективы в предоставленное решение (при необходимости) и утверждает.
6. Утвержденный сценарий отправляется в разработку (подшивается в дорожную карту планируемого выпуска).

1. После разработки сценарий тестируется на заявленное выполнение на тестовом стенде в студии, проверяется автоматическими тестами (Capybara) c автоотчетом и отправляется на доставку в общий проект клиенту.
2. По почте клиент получает акт выполненных работ где указаны инструкции как ознакомится с результатами.
3. Несоответствие согласованного сценария с фактическим результатом фиксируется клиентом в формате:
   • Картинка - (скриншот с пояснениями, захват экрана) номер сценария,
   • исходная ситуация перед началом выполнения сценария
   • окружение на котором происходит проверка (браузер, версия, операционная система с версией, сетевое подключение).
   • Выполняемые шаги (взаимодействия) в виде номеров транзакций
   • Ожидаемый результат
   • Фактический результат
4. Передачей результатов работа считается публикация в репозиторий клиента исходного кода программы (в случае с базовым стеком - публикация в heroku).

Сложность интернет-проекта (системы) измеряется количеством целевых сценариев которые выполняются в итоговом проекте.

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

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

• Используемый набор технологий при производстве и доставке продукта в окружение клиента.
• Коэффициент срочности.

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

• Ruby on Rails стабильной официальной версии на момент заключения договора, включая
  • Slim (Haml) шаблонизатор
  • Twitter Bootstrap в качестве основы для сборки HTML+CSS макетов.
  • База PostgreSQL стабильной свежей версии.
  • jQuery + CoffeeScript в качестве основы для работы с JavaScript на странице.
• Тестирование кода: Rspec + Capybara
• Контроль качества кода: RuboCop
• Доставка результатов: Heroku.com (+ Amazon S3 для хранилища данных)

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

Формат взаимодействия - электронная почта указанная в заявке и договоре-оферте, а также наша система управления проектами WRM.

Технология	Коэффициент влияния на стоимость	Стоимость
Базовый технологический стек:	1	2.5 у.е. за транзакцию
1 внешняя корректно (100%) документариованная API-система	0.5	1.25 у.е. за транзакцию
1 внешняя некорректно (< 100% используемых функций) документированная API-система, или плохо работающая (через раз новые результаты)	2.9	7.25 у.е. за транзакцию
1 внешняя система 1С (битрикс / система учета) ...	1.9	4.75 у.е. за транзакцию
Любая дополнительная технология веб разработки вне базового стека	0.5	1.25 у.е. за транзакцию
Доставка кода на VPS / VDS через Capistrano	0.5	1.25 у.е. за транзакцию

Услуга	Активность	(отчуждаемый) Результат оказания услуги	Стоимость
Секретарь Фиксация и формализация входящей информации	Запись во время встречи Обработка и подытог информации	Аудиозапись Текстовая расшифровка дискуссии Саммари.	169 у.е. / 1,5 часа
Стратегическая сессия Формулировка главной задачи, дерева целей и job stories, фиксация требований	Интерьвю с аналитиком Проработка проблемных ситуаций и путей разрешения Построение цепочек воздействие-реакция (выявленная транзакция)	Выявленые проблемы и ситуации к решению (job stories) Сформулированна миссия Построенно дерево целей Оценка количества транзакций	269 у.е. / 1,5 часа
Формализация дизайн-решения Детализация сценариев, экранов и структур данных.	Проработка целей и учет требований Создание сценариев	Сценарии и приемочные критерии Макеты экранов Структуры данных Точная оценка количества транзакций	3 у.е. / за 1 транзакцию
Веб разработка Реализация поставленных занаий	Ruby On Rails разработка Тестирование Проверка качества Доставка результата	Функционирующее веб приложение (сайт) Проверяемое качественно и количественно в браузере Гарантировано решающее поставленные задачи согласно сценариям.	[цена стека] у.е. / за 1 транзакцию

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

Студийная позиция по ценам однозначана и проста - вы платите только за то что вы получаете (можете использовать), ни центом больше, но и ни центом меньше.

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

Возьмите ручку и бумагу и пометьте сколько у вас планируется элементов (объектов) и взаимодействий.

Любая система состоит из элементов (объектов / структур данных и их характеристик) а также взаимодействий между ними (транзакций).

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

Вот и вся базовая система сайтостроения.

Примеры объектов в системе и их характеристик, которые помогут вам выявить ваши объекты.

• Новость
  • Название
  • Картикна
  • Текст
  • ...
• Статья
  • Заголовк
  • Тизер
  • Автор
  • ...
• Товар
  • Наименование
  • Артикул
  • Цена
  • ...
• Место работы (если это резюме HH)
  • Период
  • Должность
  • Выполняемые задачи
  • ...
• Электронный подарок
  • Фото
  • Цена
  • Категория
  • ...

И так далее.

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

Так мы подходим к базовому проектированию ресусров в сети - CRUD.

CRUD - create, read, update, delete.

Каждый объект как правило нужно иметь возможность

• read index - просматривать все объекты данного типа.
• new - перейти в режим добавления нового объекта (форма)
• create - создавать
• read - просматривать.
• edit - перейти в режим редактирования нового объекта (форма).
• update - сохранять изменения.
• delete - удалять

На каждое такой сценарий работы с объектом мы можем предположить количество последовательностей "воздействие пользователя - реакция системы"

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

Но стоит учесть что каждая система не состоит из базовых сценариев обслуживания объектов, есть также нетипичные действия, такие как:

• Поставить под чем-то лайк - тут одна транзакция
• Проработать на страинце в каком-то конструкторе (воздейсвтий очень много может быть и реакций на них) - тут до 100 может быть
• и так далее.

Теперь просто посчтитайте сколько у вас получилось объектов и попробуйте прикинуть стоимость проекта, также добавив примерное понимание ваших нестандартных решений.

Для прогрозирования (в среднем по индустрии на неизвестность берут именно этот процент) - добавьте к полученному вами количеству сценариев еще 30%.

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

Впишите в форму ваше значение и вы получите "ориентир", который построен на вашей оценке.

Виды работ	Базовый стек +	Количество транзакций
Секретарь: Стратегическая сессия: Формализация решения: Веб разработка:	Количество good API: Количество bad API: Внешних систем 1С / Битрикс:	Количество транзакций:
Итого:		0 у.e

Напишите в форму на главной или в почту [email protected].