Смета по MVC 💰

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

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

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

Шаблоны

Видео

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

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

Что такое ООП

Вот что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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.

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

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

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

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

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

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

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

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

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

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

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

/img/selects.png

/img/protected_ranges.png

/img/protected_ranges1.png

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

features

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

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

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

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

view-features

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

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

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

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

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

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

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

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

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

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

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

Оплаты

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

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

Типы обмена

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

Дополнительные фичи при интеграциях
Еще несколько параметров обменов

Технические

Рассылки

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

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

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

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

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

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

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

Версия #6
Алексей Качалков создал 14 November 2022 17:49:42
Наталья Денисова обновил 12 August 2024 15:51:14