в Аналитика

Оценка проекта и составление сметы

Сегодня я хотел бы рассказать о принципах оценки проекта, которые я выработал за время общения с клиентами как в студии, так и на фрилансе.
Я не раз сталкивался с клиентами, которые очень мало понимают в создании сайтов или веб-приложений. Их ТЗ зачастую — «Хочу такой же сайт как на ****.ru, только с перламутровыми пуговицами». На первый взгляд кажется, что работать с такими заказчиками очень тяжело. На деле же это не тяжелее, чем работать с ТЗ на 60 страниц. В таких ТЗ обычно клиент подробно описывает нюансы дизайна, но совершенно упускает из виду функционал. Приходилось работать и с проектами, у которых всё ТЗ — это 5-10 макетов дизайна. Бывало разное. Но во всех случаях одинаково хорошо действовала схема составления подробной сметы. Об этом и пойдёт речь.

Иногда лучше совсем без ТЗ

Бедственное положение с грамотными ТЗ сложилось по простой человеческой причине. Составление технического задания на разработку проекта — это целая дисциплина. Очень сложно не скатиться в описание мелочей, сложно выделить и структурировать требования. К тому же это вдвойне сложно, если понятия не имеешь, чего на деле хочешь. Наверное поэтому мне больше импонируют клиенты, которые НЕ делают непрофессиональные ТЗ. Считаю (на основании собственного опыта), что плохо написанное ТЗ создаёт в разы больше проблем, чем его полное отсутствие. Но есть конечно и минусы. Попробую перечислить и то, и другое по-порядку.

Плюсы задания «Сделайте как там»

  1. Заказчик уже в целом представил себе как будет выглядеть и работать приложение (остановимся на понятии приложения, оно более всеобъемлющее) и показал нам действующий прототип.
  2. Мы застрахованы от неверно истолкованных терминов. Часто в тупик вводит разная интерпретация слов модуль, страница, логотип, адрес, товар, каталог и т.д. Над каждым термином приходится потратить значительное время. При готовом примере можно дать ссылку и отправить скриншот — двусмысленности много меньше
  3. ТЗ — штука нужная. И если его нет, то у вас на руках все карты. Составьте такой проект приложения, чтобы всё было понятно вам. А заказчику каждый пункт «перелинкуйте» с существующим сайтом/программой. Тогда и вы и клиент будете знать точный набор функционала.
  4. По готовому проекту проще делать смету. Это я вам как тимлид и программист заявляю.

Конечно без минусов никуда

  1. Не все нюансы проекта можно посмотреть. Некоторые вещи (управление контентом, личный кабинет, закрытые для ВИП-пользователей зоны и т.д.) будут не видны вам и могут подразумеваться клиентом как должное. У нас был случай, когда мы сдавали, казалось, готовый проект. И в последний момент клиент спросил, где личный кабинет клиента и долго удивлялся, почему мы не нашли его на сайте-источнике.
  2. Не забываем, что ТЗ — это прежде всего страховка для вас и клиента в сложных ситуациях. Конечно все мы люди и стараемся всё решить миром. Но shit happens. Поэтому, имея на руках утверждённое ТЗ и смету гораздо проще «искать правду». Поэтому ТЗ прийдётся составлять и согласовывать вам, а это дополнительное время, которое не включишь в счёт.

Ближе к телу. Как на счёт сметы?

Составление ТЗ — большая тема для отдельной статьи. Вернёмся к смете и оценке проекта.
Для примера возьмём наш любимый хабр. Углубляться в детальную оценку не буду, проект достаточно сложный. Сделаю наброски ТЗ по созданию клона хабра.
Прежде всего давайте определимся, что идти будем от общего к частному. А значит первым делом выпишем список сущностей проекта.

Я предпочитаю использовать термин «модули», что возможно не совсем корректно, но так уж исторически сложилось.

Модули

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

  • Посты — базовый функционал сайта. Основной контентный элемент.
  • q&a — явно отдельный модуль.
  • Так, блоги.
  • И не только блоги, ещё и категории блогов.
  • Люди. Очевидно, что это пользователи.
  • Компании. Категоризация блогов и пользователей.

Так, продолжим осмотр главной.

Очевидно, что на сайте есть поиск.


И регистрация с авторизацией.

Немного побродив по сайту, сразу выявляем ещё сущности:

  • Комментарии есть у каждого поста.
  • Категории компаний.
  • О, работа! Значит есть вакансии.
  • А раз есть вакансии, то должны быть и резюме.
  • И регионы. Значит географические категории для вакансий.
  • И просто категории вакансий.
  • У пользователей есть профиль. На отдельный модуль не тянет, но запомним.
  • Рейтинги. Пользователей и постов. Ещё карма какая-то. Учтём.
  • Лучшее за 24 часа — это подмодуль. Надо учесть.
  • Блок работы.
  • Блок вопросов.
  • Прямой эфир.

Итак, у нас уже есть общее представление о сайте. Собран ещё не весь функционал, но давайте остановимся пока на этом.

Spreadsheet — наше всё

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

Как же ты рассчитываешь трудозатраты?

Поверьте, очень популярный вопрос.
Во-первых я делю каждую задачу на атомарные операции. Создать модуль — это значит создать таблицу в базе (прикидываю сразу, какое кол-во таблиц нужно), занести данные об этой таблице в модель (вы же знаете свой фреймворк, значит представляете, за сколько можно сгенерировать или подготовить модель), создать соответствующий контроллер.
Во-вторых веду волшебную таблицу — сколько запланировал на задачу и сколько реально на неё потратил.
В-третьих засекаю время при работе на те или иные задачи.
В-четвёртых ВСЕГДА беру запас на смету в 1.5-2 раза на новые таски. Ещё ни разу не прогадал.

А смысл сметы?

В итоге потратив час-два-три на составление детальной сметы, я сильно выигрываю в целом и получаю:

  1. Готовый план работ на близжайшее время
  2. Фактический документ, по которому можно реально оценить проект и выставить счёт на предоплату. Причём это будет не шаровый счёт из разряда «у вас куча денег, потребую-ка я с вас за проект 5 тысяч», а мотивированный стоимостью часа работ документ.
  3. «Тесто» для создания ТЗ. Как по грамотному ТЗ легко составить смету, так верно и обратное. По грамотной смете легко составить ТЗ.
  4. Опять-таки полный перечень работ, понятный в целом заказчику. И приписка в контракте «час работ сверх сметы стоит **$»

Постскриптум

Каков бы ни был ваш проект, его надо где-то размещать. Если живёте на Украине, можете воспользоваться услугами хостинга PLASMA ХОСТИНГ УКРАИНА. У них шаред от 5ти гривен. А для многих предложений ещё и домен .ua бесплатно.

  • Me

    В смете главная часть — это деньги. И это не просто часы * ставку. Надо учитывать множество рисков, что бы проект не ушёл в минус.

    • Согласен с вами. Но без более-менее точно оценки трудозатрат проекта ни один адекватный менеджер не станет выставлять счета и оговаривать сроки. Так что любая оценка проекта начинается с поэтапного плана, графика работ или по-часовой сметы. Именно имея такие данные, можно делать прогнозы, выставлять компенсирующие суммы, удваивать сроки и т.д. Общаться с заказчиком, имея шаровую оценку вроде «если хотите клон хабра, я возьмусь сделать за полгода и за 9 тысяч долларов».
      На детальную оценку, скажем хабра, нужно потратить где-то 2 часа времени, излазить и выписать весь функционал, прикинуть, что нужно сделать для его реализации. Тогда оценка будет гораздо ближе к реальности. И стоимость можно будет указать реальную.

  • Аноним

    По существу