Новая страница

Смета по MVC 💰

Эта страница описывает методологию правильной декомпозиции проекта и последующую позадачную оценку.

Шаблоны типовых смет

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

https://docs.google.com/spreadsheets/d/1fZ1G54NZEVJUOBv09se_0hFLecKLl-TtVPp63lcc6Tw/edit#gid=975165868

Видео

• Часть 1. Методика https://youtu.be/VPVuy-qBIM8
• Часть 2. Каталог фич https://youtu.be/LhQwWwQI0OQ
• Часть 3. Практика https://youtu.be/d7ryBx25orw

Шаги осмечивания проекта

• Шаг 1. Разбить на модели
• Шаг 2. Разбить модели на фичи по MVC
• Шаг 3. Выделить типы работ для каждой фичи
• Шаг 4. Выставить оценки и комментарии по реализации
• Шаг 5. Разбить на этапы и платежи. Назначить сроки
• Шаг 6. Работа с Google Таблицами
• Каталог фичей
• Значения по умолчанию

Шаг 1. Разбить на модели

Что такое ООП

Вот что:

Что такое модель

Модель - ключевое понятие для любого веб-проекта. Моделью называется массив (набор) однотипных элементов. Например, если у вас есть коробка карандашей, то карандаши — это модель, а карандаш - элемент (item) модели. Или Солнечная система — модель, а планеты — элементы модели. Причем Солнце к модели Солнечной системы не относится. Это элемент модели "Звезды", так как тогда у нас получается массив. Думаю, суть вы уловили.

Признаки модели

1. То, что похоже на Класс - Объект. Модель = класс + объекты
2. То, чего несколько (объекты)
3. То, с чем можно CRUD (Create, Read, Update, Delete)
4. То, что будет масштабироваться

Примеры моделей

• Пользователи (Юзеры)
• Товары
• Записи блога
• Платежи
• Заказы
• Объекты (здания)
• Города

Моделью не является

• Главная страница и страница контактов
• Страница блога, она как солнце, одна. Мы не можем в админке насоздавать еще несколько главных страниц и вывести пользователю их список
• Товары в корзине. Это связь моделей Юзер и Товар
• Бонусный баланс пользователя. Это либо свойство юзера, либо динамическое значение, которое считается на основе транзакций пользователя
• Полы пользователей (м/ж), так как их количество никогда не меняется

Маленькие модели

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

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

• Цвета или размеры товаров в каталоге
• Достижения (ачивки) для пользователей (имеется ввиду массив типов ачивок, например, "просмотрено 100 страниц" — одна ачивка на весь сайт, "заказано товаров на 10000 рублей" — вторая ачивка)

Шаг 2. Разбить модели на фичи по MVC

Особенность наших смет - разделение на фичи (задачи) по принципу MVC (Model, View, Controller). Такой подход помогает менеджерам выделять и классифицировать фичи. Это означает, что для каждой модели мы оцениваем:

• Model. Структура данных
• View. Страницы и их описание
• Controller. Функционал

Разумеется, это упрощенная схема MVC, где вся логика лежит в контроллере. Каталог фич мы рассмотрим ниже после всех шагов составления сметы.

Шаг 3. Выделить типы работ для каждой фичи

На этом шаге работ у вас уже должны быть заполнены первые два столбца теплосметы "Модель" и "Задача".

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

{primary} Можете ставить "?" в клеточках, где точно будут часы, но вы пока не знаете сколько.

Возможны следующие виды работ и привлекаемых специалистов:

• Проектирование (проект-менеджер, дизайнер или аналитик)
• Дизайн (дизайнер)
• Front-end (front-end разработчик)
• Back-end (back-end разработчик)
• Тестирование (тестировщик)

Давайте пройдемся по типам работ подробнее.

1. Проектирование. Есть всегда. Сама величина может колебаться от 1 до 8 часов
2. Дизайн. Может отсутствовать в фичах, где нет вывода на фронтенд (интеграции, рассылки и тд), а также на страницах, собираемых на CSS-фреймворках типа Vuetify или Bootstrap.
3. Front-end. Может отсутствовать в фичах, где нет вывода на фронтенд. Если есть дизайн, то работы по front-end точно есть.
4. Back-end. На веб-сайтах работы по back-end есть почти всегда. Хотя их может быть меньше чем front-end. Может и не быть совсем, например, на верстке email-шаблона или создании HTML5 анимации.
5. QA. Тестирование есть на любой задаче, где есть front или back программирование.

Шаг 4. Выставить оценки и комментарии по реализации

Цифры для оценки можно взять из трех источников:

1. Позвав программистов для оценки
2. Файла с типовыми сметами. Отнеситесь к файлу критически, в типовых сметах оценивались другие задачи для других проектов.
3. Используя интуицию. В конечном счете других источников не существует. Разработчики не зависимо от опыта тоже используют интуицию.

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

Комментарии

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

Шаг 5. Разбить на этапы и платежи. Назначить сроки

Этапы

Этапность — сложная вещь. Даже сложнее выставления часов на задачи, потому что раз этапы большие, то и ошибки получатся более заметные. Старшие менеджеры должны внимательно проверять этапность.

1. Техническая зависимость. Некоторые задачи требуют, чтобы были сделаны другие
2. Бизнесовая зависимость для клиента. Клиент хочет сразу начать что-то трогать и/или наполнять сайт контентом
3. Бизнесовая зависимость для вас. Если вы оставите на последний этап никому ненужные работы, то вам будет очень трудно уговорить заказчика начать и закончить такой этап. Все этапы должны быть нужны заказчику.
4. Равномерность. Желательно, чтобы этапы были примерно равну друг другу по объему работ. Так удобнее работать.
5. Водопад удобнее скрама. Для выполнения удобно делить работы на этапы по типам. Например, 1-й этап — дизайн, 2-й фронтенд, 3-й бэкенд.
6. Если понадобится ускориться, этапы можно "параллелить".
7. Этапность нужна не для частичных деплоев, а для частичной сдачи-приемки работ. То, что этапы неудобно выкатывать по отдельности нормально. Сперва сделаете все этапы, потом выкатите. Постарайтесь не обещать поэтапные выкаты.

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

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

Платежи

1. Платежи должны быть максимально равномерными. Нет, не так. Между вами и заказчиком сальдо все время должно быть минимальным. То есть никто никому не должен много денег или работ.
2. Чтобы платежи были равномерными, можно делать платежи разными долями этапов. Например, в 1-м небольшом этапе 100% аванс, а во 2-м большом разбейте оплаты 50/50.
3. Не берите больших предоплат на креативных этапах (концепция, дизайн и тп). На этапе дизайна вероятность разорвать отношения максимальна.
4. Не забывайте закрываться актами. Это не относится к сметам, но все же. Когда вы хотите выставить счет, сперва вы должны закрыть предыдущий этап актом.

Сроки

Сроки определяются формулой

Срок (раб дни) = Объем работ / 8 * K

где K — коэффициент срочности. Обычно он колеблется от 1,5 до 2,5 и зависит от ряда факторов. В этой документации есть значению по умолчанию для коэффициента. Если нужно его изменить, обратитесь к старшему менеджеру.

Не забывайте, что в месяце примерно 20 рабочих дней, а не 30.

Если клиент торгуется

Нельзя по просьбе клиента снижать стоимость фичи без причины.

Для начала можно соединить нашего техлида и их технического специалиста для обсуждения спорных моментов (может мы просто друг друга не поняли).

Для снижения стоимости:

• либо выключаем фичи

• либо еще раз уточняем задачу, переоцениваем с программистом, вдруг действительно не так поняли задачу

• ищем альтернативные более дешевые способы решить задачу

  • Вместо ЛК просто отправлять инфу на емейл
  • Вместо отрисовки каждой страницы предложить отрисовать UI kit
  • Вместо отрисовки и верстки предлоожить Vuetify или Bootstrap

  {primary} Предложите клиенту сразу 2-3 варианта, включая заведомо слишком дорогой

Шаг 6. Работа с Google Таблицами

Настройте права доступа к таблице

1. Если даете посмотреть таблицу Мише, выпейте Новопассит дайте ему доступ на редактирование на misha.radionov@gmail.com. Другим менеджерам студии, соответственно, давайте доступ на редактирование по их емейлам.
2. Дайте доступ на редактирование всем, у кого есть ссылка
3. С помощью защищенного диапазона сделайте диапазон исключение так, чтобы ничего нельзя было редактировать, кроме стообца "делаем: да/нет". Настройте диапазон так, чтобы Миша и другие менеджеры, относящиеся к проекту могли редатировать этот диапазон.
4. Обязательно! Перед отправкой сметы клиенту, откройте ее в "инкогнито", чтобы проверить, что смета открывается и редактируется только столбец "Делаем?".

Внесение правок в смету

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

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

Инструменты Google Таблиц, которые используются в теплосмете

• Градиентное раскрашивание
• Условное суммирование
• Выпадающие списки (проверка данных)
• Фиксирование прокрутки строк и столбцов
• Защищенные диапазоны шаг 1
• Защищенные диапазоны шаг 2

Каталог фичей

Model. Сама модель

В смете мы просто закладываем несколько часов на проектирование и бэкенд для каждой модели. Чем сложнее модель, тем больше часов на нее нужно заложить (2-6 часов). Здесь мне нечего писать про модели, но в разделе Написание ТЗ модели будут чуть ли не самой важной частью.

Соглашения по модели ищите в последнем разделе "Значения по умолчанию".

View. Вывод модели

Вывод чуть сложнее, но тоже легко осмечивается. Чаще всего задачами по выводу для модели являются:

• Index Вывод списка элементов модели (listing, index) на всю страницу. Например, каталог товаров, категория товаров, страница блога, список заказов в ЛК пользователя, рейтинговая таблица пользователей.
• Show Страница единичной записи модели, элемента модели (single, show). Например, карточка товара, страница новости, публичный профиль юзера.
• Блок (часть страницы) вывода show или index модели на какой либо странице. Например, вывод списка просмотренных товаров на главной. Или вывод списка похожих товаров на странице товара. Вывод последней статьи в сайдбаре.
• Нефункциональные страницы, не служащие связанные с конкретной моделью. Например, главная страница, страница контактов, какая-то промо-страница (LP)

Controller. Функционал модели

Стандартные функциональности. Круды (CRUD)

«Большинство приложений это возомнившие о себе CRUD’ы» Taylor Otwell, автор фреймворка Laravel

В программировании есть хороший паттерн CRUD (Create, Read, Update, Delete). Используйте его для поиска фичей по управлению моделями. Многие программисты рассматривают его только как управление справочниками в админке, но это не верно. CRUD может дать вам гораздо больше как для декомпозиции проекта, так и для создания его архитектуры.

Почти все приложения можно представить в виде CRUD. Тогда реализовать их становится гораздо проще.

Например, что такое чекаут (оформление заказа) в интернет-магазине? Особая функциональность? Нет, это create для модели Заказ.

Давайте разберем CRUD подробнее:

• Create (C). Создание элемента модели
• Read. Выводы:
  • Index (V) вывод списка элементов модели. Относится к View
  • Show (V) вывод единичного элемента модели. Относится к View
• Update (C). Редактирование элемента модели
• Delete (C). Удаление элемента модели

Как это использовать? CRUD хорошо помогает при определениии функицонала (C) и выводов (страниц, V). Вам будет проще вспомнить или прдумать нужный функционал и декомпозировать запутанные сценарии.

ИМ. Частые функциональности для интернет-магазина

• Чекаут (создание элемента модели заказа)
• Корзина (по сути, обертка для управления связью товар-юзер)
• Wishlist (тоже, по сути, обертка для управления связью товар-юзер)
• Оплата (ниже)
• Доставка (может быть моделю)
  • Расчет стоимости доставки
    • Интеграция с агрегаторами доставки (Shiptor)
    • Или собственная логика расчета стоимости доставки
  • Отправка данных в транспортную компанию (интеграция)
  • Интеграция по статусам заказов (доставлен, "в пути" и тд)
• ЛК
  • История заказов
    • Повторить заказ
    • Отменить заказ
    • Вывод статуса заказа
    • Уведомления об изменении статуса заказа
  • Купоны, Бонусы
  • Адрес доставки
• Лютые фильтры
  • Пагинации
  • Сортировки
  • Вывод плиткой/списком
• Подписка на отсутствующий товар
• ...

ЛК. Частые функциональноси для личных кабинетов

• Регистрация
  • Подтверждение по email
  • Подтверждение по SMS
• Авторизация
  • логин/пароль
  • телефон/SMS
  • Социальные сети
• "Забыли пароль?"
• Редактирование личных данных
  • Смена пароля
• Блок личных данных справа вверху
• Единая авторизация на нескольких сайтах

Оплаты

• Интеграция с эквайрингом
• Модель платежей
  • Админка платежей
  • Вывод платежей пользователю
• Генерация счета на оплату
• Генерация актов, актов сверки
• Настройка отправки чеков в налоговую
• Выплаты исполнителям
• Подписки (регулярно взимаемые платежи)
• Дополнительные валюты (кроме рублей)
• Интеграция с банком по статусам оплат

Интеграции / API

Примеры интеграций

• CRM (лиды)
• 1C (склад, заказы, …)
• Google Таблицы (экспорт в таблицу)
• Доставка (для e-commerce)
• Эквайринг (любые движения средств)
• SMS, мессенджеры (уведомления)
• Маркетплейсы (для e-commerce)
• Счетчики, аналитика (события, e-commerce, …)
• Retail Rocket (рекомендации для e-commerce)
• Телефония
• Онлайн-консультанты (спорно)
• Сервисы рассылок (транзакционные типа MailGun и интерфейсные типа MailChimp)
• Сервисы онлайн-бронирования (yclients, …)
• Календарь (экспорт, импорт)

Типы обмена

Интеграции бывают разных типов и имеют разную трудоемкость:

• Разовые программистом. Никакого UI, программист загружает предоставленные данные скриптом, запускается через терминал (консоль)
• UI-ные. Когда в админке есть кнопка (я называю ее "рубильник"), которая запускает обмен данными
• Триггерные. Наша система ждет, пока к ней обратится внешняя ил
• По расписанию. Соответственно, обмен происходит по расписанию

Дополнительные фичи при интеграциях

• Очереди при отправке данных на клиенте (браузере пользователя). Например, отправка заявки в CRM при отправке ФОС.
• Документация для пользователей API (в идеале, использовать Swagger или что-то подобное)
• Логирование, обработка ошибок
• Настройка расписания обмена данными
• Аутентификация

Еще несколько параметров обменов

Технические

• Сущность, по которой идет обмен (товары, заказы, заявки и тд)
• Направление обмена (принимаем или отдаем данные)
• Что происходит при добавлении новых сущностей, удалении (премодерация, архивация)
• Либо база полностью накатывается взамен старой Управленческие
• Был ли у нас опыт такой интеграции
• Разбирается ли клиент в этом сервисе (был ли у клиента опыт)
• Описание API и скорость реакции тех поддержки
• Есть ли русскоговорящая тех поддержка (для менеджеров и клиентов удобнее)

Рассылки

Тут есть варианты:

1. Отправка получателей рассылки в самостоятельный рассылочный сервис типа MailChimp или SendPulse
2. Создание функицональности рассылок и использование API рассылочного сервиса типа MailGun

В первом варианте вы создаете только:

• Форму для сбора емейлов
• Один односторонний обмен с рассылочным сервисом

Во втором варианте вы делаете:

• Модель рассылок
• Модель листов рассылки (опционально). Лист - статический набор пользователей
• Модель сегментов (опционально). Сегмент - динамеческий набор, определяемый набором параметров
  • Параметры для сегментов. Например, город, дата заказа, купленный товар, пол пользователя и тд.
• Модель отчета рассылки (опционально). Отслеживание статуса каждого отправленного письма: доставлено, не доставлено, открыто, клик по ссылке в письме
• Собственно, функицонал рассылки
• Интеграцию с рассылочным сервисом (MailGun - из коробки)
• Функционал отписки от рассылки
• Запланированные рассылки по расписанию
• Автоматически планируемые рассылки. Например, через день после регистрации или за час до вебинара
• Очередь. Всегда нужна для рассылок
• ...

Другие частые функциональности для модели

• Нотификации. В комментариях перечисляйте способы нотификации (email, sms, мессенджер, push, UI сайта и тд) и события (новый заказ, новая регистрация и тд)
• Админка (обычно, весь CRUD для администратора)
• Поиск обычный по вхожениям запроса
• Поиск ElasticSearch по опечаткам, с учетом окончаний, схожих звучаний, синонимов, ключевых слов, с учетом релевантности и тд.
• Фильтр на листинге (да, это контроллер, а не вывод)
• Сортировка на листинге
• Пагинация (разбиение на страницы), кнопка "подгрузить еще"
• Статистика по данным модели для пользователя: дашборды, графики, BI
• Комментарии

Частые функциональности без модели

• Формы обратной связи, не создающие записей в БД
• Мультиязычность
• Мультидоменность
• Версия для слабовидящих
• Поддержка скринридеров (для незрячих людей)
• Тонкая настройка аналитики (e-commerce, цели)
• Микроразметка, OG и другие тэги

Значения по умолчанию

• ТЗ — 6 SP
• Тестовая площадка — 2 SP. Создание тестовой площадки, репозитория, настройка CI
• Админка (модель) на бэк ставить больше часов, там много работы и ее могут делать не все программисты
• Интеграции (модель) относятся к моделям
• В задаче "Модель" (модель) в комментарии «Проектирование БД. Миграции, сиды. Описание полей, связей, политики удаления». Ставим больше SP на модель.
• Адаптив - 30% от работ по фронтенду
• Автотесты - 50% от работ по бэкенду
• Ручное тестирование - 50% от стоимости работ по бэкенду+фронтенду
• Коэффициент задержки для расчета сроков — 1,5
• Срок подготовки сметы от 2 до 5 рабочих дней
• В каждую смету добавляем услугу "убрать вебмастеринг" стоимостью 10% от суммы договора.
• Объем и список работ для блока Прелонч тут, первый блок с заголовком "Создание Продакшен сервера"