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

Time is money

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

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

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

“Хочу сайт, где пользователи смогут писать посты с картинками, оставлять комментарии, выставлять рейтинги, обмениваться сообщениями, а так же на сайте будет магазин с книгами, книги будет добавлять администратор сайта, он так же будет следить за порядком на сайте. Сайт должен иметь “лёгкий” дизайн и соответствовать web 2.0″

Начнем по порядку:

  1. Пытаемся понять бизнес-идею заказчика, если у Вас это не получилось – необходимо добиться этого понимания, глядя на данное описание можно предположить 2 варианта для получения отдачи с сайта – процент с продажи книг и контекстная реклама (о которой не было сказано ни слова, но очень часто предполагается по умолчанию)
  2. Задайте следующие вопросы заказчику:
    • Какие нагрузочные требования к системе, сколько будет зарегистрированных пользователей, сколько онлайн (я сомневаюсь, что заказчик адекватно поймет словосочетание “конкурирующие запросы”)?
    • Нужна ли поддержка мультиязычности?
    • В каких браузерах должен корректно отображаться сайт?
    • Какие требования к безопасности сайта (понятно, что мы не будем писать дырявое приложение, но лучше заранее знать что сайт будет работать по HTTPS и URL будут уникальны для каждого пользователя)
  3. Разбейте проект на составляющие – составьте фиче-лист проекта
  4. Все вопросы которые возникают – записываем, и не забываем задать их заказчику, каждый вопрос желательно сопровождать пояснениями, дабы не смущать заказчика, а так же не мешало бы подталкивать его к правильному ответу, который бы минимизировал часть рисков (к примеру на вопрос о поддержке различных браузеров, лучше упомянуть, что самые популярные нынче это IE6.0+, FF 2.0+ и Safari 3.0+, иначе есть риск, что придется подгонять дизайн под какие-нить ископаемые, типа Netscape 8.0)
  5. Итоговую оценку с подробными комментариями и вопросами отсылаем заказчику в формате XLS – пусть он сам попробует добавить/убрать некоторые пункты

Составление фиче-листа

Данный пункт требует определенных навыков, дабы расшифровать требования и ничего не упустить, и вот некоторые советы по составлению фиче-листа:

  1. Каждый пункт должен включать 2 оценки – среднюю, и максимальную (это если сработают все риски, риски лучше сразу описывать)
  2. Выделите следующие части в отдельные пункты
    • разработка и внедрение дизайна
    • разработка архитектуры системы
    • разработка БД
    • анализ требований (собственно это чем вы будете заниматься до старта проекта, включая написания документации)
    • если у Вас команда разработчиков, то так же должен быть пункт “Передача знаний” – это время на митинги, и тому подобные рабочие процессы, которые кушают бюджет
    • менеджмент – включает в себя общение с заказчиком и сам менеджмент как таковой
    • тестирование – нам же нужна “живая” система
    • деплоймент системы на сервер заказчика
  3. Выделите отдельным пунктом “бесплатный сыр” – то что Вы бы сделали, даже если бы не было такого требования, к примеру – интеграция WYSIWYG редактора или поддержка User Friendly URL, интеграция Google Analytics и Google AdSense

А теперь попытаемся выделить основные пункты из нашего “описания”:

  1. Обычное явление для сайта – присутствие страниц со статической информацией, которая может изменятся администратором, по личному опыту – для 90% сайтов необходимо было реализовывать данный функционал
  2. У нас на сайте присутствует как минимум 3 роли : гость, зарегистрированный пользователь, администратор, а может еще будет модератор?
  3. У нас есть как минимум 5 сущностей кроме пользователей: книги, посты, комментарии и рейтинги, а так же сообщения для приватных бесед, если чуть-чуть подумать, то появляются еще категории для книг и тэги для постов (дабы следовать web 2.0), необходимо все предположения уточнить у заказчика.
  4. Дизайн аля web 2.0 может оказаться и с flash’ом или заказчик видел где-то, что-то и он хочет подобное, так что продолжаем формировать список вопросов
  5. Если у нас электронный магазин, предполагается ли интеграция payment gateway’ев, если да, то каких.
  6. Обмен сообщениями между пользователями – тоже довольно скользкий момент, возможно заказчик имеет ввиду чат, или всё же простенькую систему внутренних сообщений? Пользователи могут отсылать сообщения любому другому пользователю, или будет список друзей?

Промежуточный фиче-лист включает в себя следующие пункты:

  • Entities:
    • Static Pages
    • Users
    • Users Friends
    • Blog Posts
    • Blog Posts Tags
    • Blog Rates
    • Blog Comments
    • Books
    • Books Categories
    • Messages
  • Free Section
    • User Friendly URL
    • WYSIWYG Editor
    • Google Analytics
    • Google AdSense
  • Design
  • Architecture
  • Database Architecture
  • Knowledge transfer
  • Management
  • Testing
  • Deployment

Далее лучше всего разбить данный список по ролям (гость, пользователь, администратор), а для таких пунктов как менеджмент, тестирования, анализ требований и передача знаний оценка будет указана в процентах от общего времени разработки, на данный момент это 10% для менеджмента, 30% для базового тестирования и по 5% на анализ и передачу знаний (такие значения выведены личным опытом и здравым смыслом).

В итоге у меня получился фиче-лист с очень приблизительной оценкой, впрочем описание тоже не радует деталями. В действительности после выяснений всех деталей, может оказаться, что заказчик хотел всего лишь что-то наподобие WordPress MU, а магазин представлял бы всего-лишь – ссылки на Amazon с указанием реферала, хотя, с таким же успехом, заказчик может хотеть и социальную сеть, со всеми соответствующими атрибутами…

Если Вам интересна данная тема, могу посоветовать прочитать еще статейку о клоне YouTube.

13 thoughts on “Оцениваем проекты”

  1. Скоро напишу ответную статью, только с планированием в MS Project.
    Но бывают и проблемные проекты, где не надо с нуля что-то разрабатывать. Например перенести существующий сайт с коммерческой CMS на бесплатную.. Joomla или Drupal. Причём известно что коммерческая в разы лучше. Как такое оценивать, если внутренности бесплатной цмс-ки неизвестно какого качества?

  2. В таких случаях обычно оценка получается достаточно заоблачной (т.к. слишком много рисков), поэтому мы предлагаем заказчику работать по схеме “dedicated developers” – т.е. разработчики работают “от забора до обеда”, но такое прокатывает только с теми заказчиками, с которыми хорошо знакомы…

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

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

  5. Оценка проектов это не единственная моя обязанность, насчет ЗП – таки секрет, могу сказать, что на жизнь хватает, и пока все попытки переманивания не увенчались успехом ;)

    1. Интересно узнать в каком направлении двигаться чтобы ЗП была секретом и чтобы попытки переманивания не увенчивались успехом. Ведь не всякий программист до этого доходит. Я вижу что не всегда знания = рост зарплаты. Т.е. у нас есть куча ребят, которые много чего знают и много чем интересуются, но .. это же не значит, что всех назначат менеджерами проектов – это физически невозможно. Поэтому вопрос – “что делать”, как вы думаете? Я, конечно, не совсем профан, я знаю что бОльшая зарплата = больше организованности, больше взятой на себя ответственности и т.д., но интересно ваше мнение.

  6. Действительно, такое планирование, позволяет заказчику лучше понять, то что он хочет. Исполнителю – то что нужно сделать, что он может сделать, и что не может.
    Именно так работают профессионалы! Нульзя наобещать с три короба, а потом не выполнить.

  7. очень хорошо оценюеш проекты, подробно описуеш, мне понравилось. спасибо

  8. Добрый день, Антон!
    Подскажите пожалуйста, в приведенном Вами фич-листе, указаны актуальные временные затраты на тот или иной функционал?
    Я конечно же понимаю что много зависит от уровня разработчика, и т.п. Но все равно хотелось бы знать.

    Спасибо.

Comments are closed.