Гид по созданию великолепных интернет-проектов
Каждое описанное действие или элемент необходим для создания жизнеспособного проекта который будет радовать основателя и приносить результаты.
Допущения и термины
-
You can’t manage what you can’t measure. W. Edwards Deming
-
Обязательные законы к пониманию — причины-следствия, инь-янь, законы композиции, законы жизнеспособности систем (ТРИЗ) -
WRM - студийная система в которой мы ведем все наши проекты
-
Результат (активности объекта) — отчуждаемая измеряемая отдача во внешний (от объекта) мир, который (результат) в дальнейшем будет использован для получения следующих результатов в общем древе целей. -
Персонажи (actors) — люди, клиенты, другие системы -
Набор данных (DataSet) — именованные данные, пример: Регистрационные данные: имя, email, пароль, фото -
Экран (Screen) — экран системы с ее элементами интерфейса, визуальное представление в виде макета или фотографии реального экрана устройства. -
Транзакция (transaction) — воздействие персонажа на систему и ответная реакция системы на это воздейстие. Является основным базовым элементом любого создаваемого интернет-проекта.
Этапы работы над проектом
- Реальные ситуации как вызовы. Job Stories.
- Миссия
- Цели
- Функции / возможности системы
- Сценарии использования системы
Реальные ситуации как вызовы. Job Stories.
Создание каждого проекта обусловлено внешними вызовами и проблемами реальных людей, которые проект обязатльено решит своим появлением.
Необходимо определить реальные проблемные ситуации, призывающие своим фактом воздействия на создателей и участников проекта к их решению при помощи создаваемой системы.
Этим предполагается что при успешной реализации необходимых для этого возможностей в системе - перечисленные на данном шаге вызовы реальных ситуаций будут считаться разрешенными положительно для создателей проекта.
Что обозначает неминуемый успех проекта.
Фиксируем все в нашей системе WRM:


Миссия или главная задача.
Каждый проект (система) призывается в жизнь для решения вполне конкретной главной задачи - это и называется миссией проекта.
Если мы упешно прошли этап формирования проблемных ситуаций или вызовов, то миссией будет - обобщение всех этих ситуаций одним предложением. Что их объединяет?
Чтобы сформулировать миссию ответьте на вопрос - что будет результатом от жизнедеятельности проекта?
Хорошая правильная миссия расположена в жизни людей, в их деятельности - помогает удовлетворять реальные потребности и сильно упрощает жизнь, дает комфорт и помогает получать удовлетворение от работы или развлечений.
Хорошая миссия позволяет не сбиться с пути, ставить правильные цели ведущие к нужному результату, не размываясь на неверные шаги.
Итак надо записать - какая польза и ценность, чем проще чем лучше.
Пример миссии корпортативного сайта по продаже товаров производимых под заказ и услуг (из нашей системы работы над проектами WRM):

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

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

Последовательности Воздейсвтие-Реакция (Транзакции).
В тот момент когда определено какие функции система должна реализовывать, необходимо определиться как она это будет делать.
Учтем для этого что определенные конкретные персонажи (люди, клиенты, другие системы - actors), находясь в различных ситуациях, путем взаимодействия с системой через ее интерфейсы, получат заранее определенные результаты, тем самым достигая основные цели системы.
Для оценки последующих трудозатрат и планирования решений мы всегда используем последовательности Воздейсвие-Рекация, для того чтобы оперделиться сколько будет стоит разарботка системы.
Транзакция является базовым элементом любого сайта (системы, мобильного приложения ...).
Табличка транзакций выглядит следующим образом:
Сценарий взаимодействия | Участник | Воздейсвие | Реакция системы |
---|---|---|---|
Добавление новости | Менеджер | добавляет новость через форму | система новость сохраняет и показывает ее |
Лайк под аватаркой | Гость | кликает на звездочку аватарки | система подсвечивает выбранную звездочку |
Фактически таблчика транзакций (иногда в комплекте с зарисовками) - являются примером дизайн решений:


Сценарии взаимодействий (UseCases).

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

Дизайн решение.
- Клиент самостоятельно, или при помощи аналитиков студии (оплачивается отдельно) формулирует необходимое целевое действие в рамках дерева целей проекта.
- Под данный сценарий студией предоставляется вариант решения сформулированный в свободной форме (с двумя шагами откроем форму и тут будет окошко, жмем окей и после этого редирект на главную) с указанием стоимости в виде количества требуемых транзакций на реализацию данного решения.
- Клиент выбирает какое решение ему необходимо и подходит по бюджету и добавляет его к заказу.
- После оплаты решение прорабатывается до деталей в виде составленных транзакций со всеми элементами - роли, действия, затрагиваемые элементы интерфейса, реакция системы.
- Клиент вносит несущественные коррективы в предоставленное решение (при необходимости) и утверждает.
- Утвержденный сценарий отправляется в разработку (подшивается в дорожную карту планируемого выпуска).
Разработка.
- После разработки сценарий тестируется на заявленное выполнение на тестовом стенде в студии, проверяется автоматическими тестами (Capybara) c автоотчетом и отправляется на доставку в общий проект клиенту.
- По почте клиент получает акт выполненных работ где указаны инструкции как ознакомится с результатами.
-
Несоответствие согласованного сценария с фактическим результатом фиксируется клиентом в формате:
- Картинка - (скриншот с пояснениями, захват экрана) номер сценария,
- исходная ситуация перед началом выполнения сценария
- окружение на котором происходит проверка (браузер, версия, операционная система с версией, сетевое подключение).
- Выполняемые шаги (взаимодействия) в виде номеров транзакций
- Ожидаемый результат
- Фактический результат
- Передачей результатов работа считается публикация в репозиторий клиента исходного кода программы (в случае с базовым стеком - публикация в 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, фиксация требований |
|
|
269 у.е. / 1,5 часа |
Формализация дизайн-решения
Детализация сценариев, экранов и структур данных. |
|
|
3 у.е. / за 1 транзакцию |
Веб разработка
Реализация поставленных занаий |
|
|
[цена стека] у.е. / за 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].