Правила игры 11 мая 2015 года


  • Мы не вписываем часы в присланные вами таблички excell.
  • Мы не переписываем договор по просьбе ваших юристов.
  • Мы задаем прямые вопросы по делу. Во всем есть смысл, мы много раз зададим вопрос "зачем" или "для чего это нужно" до начала каких-либо действий. Будьте готовы дать на него вразумительный ответ.
  • Написанному — верить, сказанное — записать. Мы не читаем мысли, не додумываем, не ссылаемся на диалоги из прошлых бесед по важным вопросам. Все значимые результаты нашего общения с кем-либо всегда приобретают письменные формы, сформулированные в измеряемых и проверяемых критериях, без словесного мусора и обобщений. Записав что-либо, убедитесь что проверились в главреде
  • Мы берем в работу уже начатые проекты. У вас проект законченный на 80% - не беда, без проблем, но вы для начала опишете нам понятные причины завершения сотрудничества с предыдущей командой, после чего мы сами с ними свяжемся для уточнения вашей характеристики с предыдущей командой - уточним как шло ваше сотрудничество, вовремя ли проходили приемки и платежи и прочие моменты.
  • Мы работаем так как сами считаем нужным. Наш процесс уже прошел проверку годами, и мы его не меняем. Все материалы и наработки которые у вас есть - это отличная фактура для того чтобы вы смогли коротко и ясно описать ваш проект для предварительного интервью с нами.
  • Понимания ради мы предлагаем вам сходить к стоматологу, и в момент сеанса уточнять как ему лучше воспользоваться тем или иным инструментом для сверления вашей полсти рта, уточнить что делать ему надо а что не надо по вашему мнению. Вы уже пришли к специалистам - наслаждайтесь делегированием, ожидайте результатов.
  • Мы учитываем ваше мнение, требования и пожелания. Работая с нами ваше мнение по процессу работы над проектом мы учтем и зафиксируем в требованиях.
  • Первый контакт и знакомство

    Цель: зарезервировать время на предварительное интервью проекта.
    Зачем: мы работаем в плановом режиме, ценим общее время время, поэтому к любой встрече рекомендуем клиенту подготовиться заранее.
    Активность: Клиент на сайте (либо по телефону) оставляет заявку, мы выходим на связь, знакомимся, общаемся.
    Результат: Забронированное скайп-интервью проекта клиента на дату-время. (вторник / четверг).

  • Предварительное скайп-интервью

    Цель: обсудить проект, узнать больше деталей, принять решение о сотрудничестве.
    Зачем: до начала работ определить направление и масштабы работ, уберечь от неверных ожиданий клиента, провести первичную диагностику для формирования предложения.
    Активность: Вместе с клиентом общаемся по скайпу в течение 30 минут, задаем друг другу вопросы, отвечаем.
    Результат: Принятое решение о входе или нет в проект, понимание стоимости и времени работ.

  • Коммерческое предложение

    Цель: Сделать предложение от которого клиент не сможет отказаться.
    Зачем: Оформить письменно студийное понимание задач клиента, дать возможность его уточнить и определить общее видение.
    Активность: Мастерская присылает коммерческое предложение клиенту, клиент его комментирует и принимает решение о входе в сотрудничество.
    Результат: Принятие решение о дате подписания договора / об отказе от сотрудничества. Обмен документами.

  • Подписание договора

    Цель: Стартовать проект.
    Зачем: Мы работаем официально.
    Активность: Подписание бумаг, выставление счета на предоплату, предоплата клиентом.
    Результат: Работы по проекту начались.

  • ...

    работа кипит.

  • Создание продукта!

    Как всегда этим все и заканчивается.

  1. Отвечаем на главный вопрос жизни.
  2. Анализируем. Собираем артефакты.
  3. Проектировка решения - формируем образ продукта.
  4. Делаем дизайн и графическое оформление.
  5. Разработка продукта.
  6. Тестирование и приемка.
  7. Запуск. Шампань.
  8. Поддержка и развитие.

Определяем терминологию

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

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

Сначала мы определяем главную задачу продукта.

Продукт создается для выполнения возложенной на него главной задачи.

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

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

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

42 8160e4301600011c671ebde55c0d1ff69a068ab4f54673927af5a8e76011bb45

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

Теперь мы можем ответить на вопросы.

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

Пример 1: сервис “Мое дело"

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

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

Пример 2. Аналогичной ситуации в другом контексте: спортивный клуб по американскому футболу.

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

Видимая главная задача: распределенный сбор информации по игрокам и формирование отчетной ведомости.

Примеры решенных главных задач вы можете найти в нашем портфеле по каждой тематике.

Дополнительные интересные вопросы для помощи поиска главной задачи.

Вообразите себе ситуацию что вы нанимаете ваш продукт для выполнения работы для вас.

На какую работу вы нанимаете ваш продукт?

Для решения какой задачи в своей ситуации пользователь воспользуется продуктом.

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

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

Итак мы подошли к самому интересному, запишите это на бумажку - какую задачу предлагается решить продукту для пользователя?

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

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

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

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

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

Reqs1 44a94a34dba153ee2a246dc8eca52633f93191cef7ac0d22509d801b8daa09f7 Reqs2 741db73718b2813603710967631155c413c9326a15a272cf7f13f7e6afce893b Reqs3 a46d1d8b3995e9c7e2e0cce8ac54eb11fec3dfbe911fd5f0b32b0aeb5632437b Reqs4 f6cb0251da0009f5027f6804e72bb882298b33466eb7f983d13cea4682ba7420

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

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

Solut2 9f690cb2eccec5227a13c556e2f206554b2f19973d56768319b42c1d6c936060 Solut1 f49ce91b761fb0a200157ef1517f2707e8093f2aefec3ea5bd092db7fd0f5db0

На этом шаге мы оформляем все в конечные цветовые гаммы, рисуем графические интерфейсы и получаем финальное оформление продукта.

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

Des0 3cfddb39ef0c3efed431d93b138058b6c99231e174b41e491ab5cb12be2ab242 Des1 99bf68e18fdcf0972da9b61a51b908b75c461485c8e26e69165ed9ffa64020c7 Des2 655f3d4e633a5a95b9d35e5989aa6694bebccecf2c6a48d59b3bb88bad507ecc

Rails — это прежде всего инфраструктура.

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



  • Независимость от (безболезненная для проекта замена) разработчика — использование фреймворка гарантирует, что "следующий разработчик" просто "подхватит" проект и продолжит разработку без переделок и задержек, уже зная что там "внутри"
  • Решаются только бизнес-задачи — используя Rails вы исключаете как правило до 80% избыточных действий из процесса разработки. Мы не тратим человеко-часы на решение уже "решенных задач" - как лучше нам выбирать результаты из базы данных, как именно нам отобразить страницу, и не изобретаем велосипеды. Все общественные наработки по давно избитым проблемам есть, и мы их просто применяем.
  • Огромнейшее сообщество разработчиков — в виде вовлеченных и идейных комитеров, в постоянном режиме выявляющих и устраняющих найденные баги и ошибки.
  • Устойчивость и стабильность — Rails очень хорошо и подробно задокументирован и оттестирован.
  • Быстрые результаты разработки — возможность получить MVP от одной недели разработки!
  • Фиксированные сроки и бюджет — принцип управления проектом, сформулированный в компании «37 signals». В вольном переводе означает «зафиксировать сроки и бюджет, сделать гибким функционал». Помогает уберечь проект от увечий, убивающих любое благое дело.
  • Безопасность из коробки — на уровне фреймворка, а не разработчика, его знаний основ сетевой безопасности.
  • Rails написан на языке Ruby — для знающих и понимающих Английский язык он совершенно понятен (для ознакомления с исходными кодами).
  • Никаких платных и скрытых лицензий — это Open Source и во всей экосистеме активно используются другие Open Source решения. Они совершенно бесплатны.
  • ... — многое другое, следите за обновлениями.

На основе собранных тестовых сценариев происходит проверка продукта, его тестирование и приемка.

На данном этапе жизнь проекта только начинается, и мы можем успешно продолжать сотрудничество для развития вашего продукта.

  1. Вы являетесь владельцем действующего (приносящего операционную прибыль) / проинвестированного (есть финансовое обеспечение) бизнеса, либо вы должны иметь возможность принимать управленческие решения в вашем бизнесе в рамках проекта (требуется подтверждение, прописано в договоре), в том числе и нести за них материальную ответственность.
  2. Вы четко представляете что именно для себя или для своей компании вы получаете воспользовавшись данной услугой разработки в нашей компании.
  3. Вы можете до начала работ предоставить табличку экселя в которой цифрами покажете примерное место где вы и на сколько планируете заработать во времени, после успешного внедрения разработанного для вас решения.
  4. Вы в состоянии перечислить 3-5 измеряемых бизнес требований (попадающих в ваши бизнес-процессы) которые должны быть удовлетворены разработкой и внедрением Rails приложения.
  5. Вы умеете считать деньги, время ваших сотрудников и вам не надо пояснять как формируется ценообразование и экономическая целесообразность любых видов услуг.
  6. Ну и почти последнее, но не последнее по важности — вы понимаете и принимаете вместе с нами как факт того что результат проекта зависит он всех участников проекта - в первую очередь от вас, во вторую от нас.
    При всем уважении, но мы не сможем сделать вам то, чего вы не в состоянии нам пояснить в измеряемых величинах, ничего личного, но мы в таких случаях всегда напомним вам что мы понимаем только "измеряемые и проверяемые" требования. *
  7. Вы разбираетесь в технологиях которые планируете применять к бизнесу в рамках работы с нами (вы можете нам пояснить разницу между HTTP и Браузером, между WiFi и HiFi), либо с вашей стороны присутствует специалист (квалификацию которого можно подтвердить) понимающий базовые технические термины нашей работы - что такое Web, Rails и 1С. К сожалению мы не занимаемся обучением базовой компьютерной грамотности и базовым навыкам пользования компьютерными устройствами и сервисами.
* При необходимости наши аналитики конечно же помогут вам сформулировать ваши требования в измеряемых величинах, обращайтесь.
Хозяйке на заметку: если вы ответили отрицательно на любой из пунктов, скорее всего мы не сможем работать с вами, к сожалению.

По возможностям

Калькулятор ищите в новом разделе цены на веб разработку.