Каждое описанное действие или элемент необходим для создания жизнеспособного проекта который будет радовать основателя и приносить результаты.
  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:

Job story1 03ef4a5e37b215bd69e5db706c207587dcbbd9d575ecfaab07667010956e2d3e
Job story2 c37a4dd6ff363eeccc99dfc4854e07d4bf457e3c34133026903c07ad401822cf

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

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

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

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

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

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

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

Mission 0b4fbc2b60390399b16e9693dc516612dd09fd64e69103aa9f32a2a453cf923c

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

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

Goals 3d8dcf1638ad615075d57a6d75b313368f9f47757f9fc9b3cdc00e1e13a02904

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

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

Features 81745161b86c424ff05cade7e75654d26dec3b43bff57f69900bd728b289ab31

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

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

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

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

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

Сценарий взаимодействия Участник Воздейсвие Реакция системы
Добавление новости Менеджер добавляет новость через форму система новость сохраняет и показывает ее
Лайк под аватаркой Гость кликает на звездочку аватарки система подсвечивает выбранную звездочку

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

Board1 85c17ff63e8c2af7010f9f5ae8e57301c4ee6823ac4fc02d6269d03f982a130c
Board2 b737f1a89fad03a75592dac776b565ce5bc74bb9db2c44e300c290b68cce8c7e
Cases d594307bb80c98522c41e7470049e88b174ce31bb7bab53acd3cb8eb3c1454d1

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

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

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

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

  • Название
  • Участники — кто взаимодействуют с системой по сценарию и производят над ней некоторые воздействия
  • Цель — без цели сценарий бесполезен — что намеревается достигнуть этим сценарием?
  • Активаторы — события инициирующие выполнение сценария
  • Предварительные условия — без выполнения которых старт сценария не имеет смысла
  • Гарантии результата — измеряемые критерии, подтверждающие правильность выполнения сценария
  • Основной ход событий — последовательность транзакций приводящих к выполнение сценария к достижению обозначенной цели.
  • Системные процессыы — связанные сценарии которые могут быть запущены к выполнению внутри системы (рассылка сообщений, пережим картинок, публикация в разных сетях информации по расписанию, очистка неиспользованных картинок и тд.)
Use case b2d7edbc9347b9843b02a1253809963a5eca1d9256b307085f18b74784b758fb
  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 у.е. за транзакцию
Услуга Активность (отчуждаемый) Результат оказания услуги Стоимость
Секретарь

Фиксация и формализация входящей информации

  1. Запись во время встречи
  2. Обработка и подытог информации
  • Аудиозапись
  • Текстовая расшифровка дискуссии
  • Саммари.
169 у.е. / 1,5 часа
Стратегическая сессия

Формулировка главной задачи, дерева целей и job stories, фиксация требований

  1. Интерьвю с аналитиком
  2. Проработка проблемных ситуаций и путей разрешения
  3. Построение цепочек воздействие-реакция (выявленная транзакция)
  • Выявленые проблемы и ситуации к решению (job stories)
  • Сформулированна миссия
  • Построенно дерево целей
  • Оценка количества транзакций
269 у.е. / 1,5 часа
Формализация дизайн-решения

Детализация сценариев, экранов и структур данных.

  1. Проработка целей и учет требований
  2. Создание сценариев
  • Сценарии и приемочные критерии
  • Макеты экранов
  • Структуры данных
  • Точная оценка количества транзакций
3 у.е. / за 1 транзакцию
Веб разработка

Реализация поставленных занаий

  1. Ruby On Rails разработка
  2. Тестирование
  3. Проверка качества
  4. Доставка результата
  • Функционирующее веб приложение (сайт)
  • Проверяемое качественно и количественно в браузере
  • Гарантировано решающее поставленные задачи согласно сценариям.
[цена стека] у.е. / за 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

    Напишите в форму на главной или в почту mailbox@pavlyut.com.