Руслан Раянов - Управление проектом разработки сайта или веб-приложения. От идеи до внедрения Страница 7

Еще момент, выберите уровень технических решений и качества. Здесь имеет смысл брать ориентир на другие сайты, т.е. этот блок сделать примерно как на site.ru. Конечно, это очень субъективно, но позволит команде разработке сделать свое представление о выбранном уровне качества.

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

Что в нее входит:

1.       Основные параметры проекта:

a.       Цель проекта и результат. Что в итоге вы должны получить? Зачем вам нужен этот проект? Входными данными для какого следующего проекта будет результат текущего проекта? Четко определите критерии завершения проекта.

b.       Сроки. Сколько в целом месяцев/недель займет проект?

c.       Бюджет. Сколько вы запланировали заложить средств на реализацию проекта?

d.       Объем. Что нужно реализовать в рамках проекта? Что мы оставим за бортом? Определите границы проекта.

e.       Команда. Кто будет реализовывать этот проект? Кто за что будет отвечать на проекте?

f. Ресурсы. Какие дополнительные ресурсы вам потребуются для реализации проекта? Это могут быть знания, технические средства, место для работы и т.д.

g.       Приоритеты внутри проекта. Что в проекте важнее всего из параметров? Сроки, бюджет, качество, объем? Возьмем, например, самолет. В нем важны, в первую очередь, качество и объем. Объем нельзя урезать, да и качество должно быть максимальным. Теперь возьмем социальную сеть. В ней могут быть важны бюджет (т.к. это деньги инвестора) и качество. Объем здесь не так важен – его можно развивать по ходу запуска проекта. Понимание приоритетов даст вам в будущем возможность варьировать параметры проекта. Например, вы не успеваете сделать в срок, а сроки являются приоритетом. Что делать? Либо уменьшайте объем, либо увеличивайте бюджет, либо внедряйте более простые и быстрые решения. При этом, разумеется, вы исходите из прописанных приоритетов проекта.

h.       Риски. Каковы риски проекта? Выпишите список рисков, связанных с проектом. Вы можете их категоризовать. Например, организационные, технические, внешние, по параметрам проекта. Далее для каждого риска вы проставляете степень критичности и степень вероятности (от одного до трех). Далее в порядке приоритетности прорабатываете каждый риск – пишите меры, которые уменьшают вероятность и критичность риска. Тем самым вы получите карту рисков проекта и план по их обработке.

i. Ориентировочный план. Вы примерно должны определить, как вы достигнете цели проекта. Здесь не нужна детализация – просто определите этапы достижения цели. Это позволит команде разработки в целом понимать в какую сторону надо двигаться. Для каждого этапа наметьте ориентировочные сроки. Здесь следует понимать, что это не обязательство или план к исполнению. Это просто желательный план развития проекта, который в процессе может изменяться.

2.       Краткое описание. Очень желательно иметь лаконичное описание, которое позволит сразу схватить суть проекта и показать его особенность. Это нужно для взаимодействия с внешним миром (дизайнеры, программисты, партнеры и т.д.). Хорошее описание сэкономит вам кучу времени при взаимодействии с возможными исполнителями на проект – вам не будут писать те, кто заведомо не подходит.

3.       Критерии отбора исполнителей. Лучше их заранее проработать, чтобы опять же сэкономить время. Что могут включать эти критерии:

a.       Общие требования, например, технологии, географическое расположение, образование, студия/фрилансер, под ключ/специализация. Указывайте требования так, чтобы сразу по максимуму отсеять кандидатов. Подумайте с какими кандидатами вы точно не хотели бы работать. При этом не указывайте аморфные «мастер своего дела» и прочее – это совершенно ни о чем не говорит кандидатам.

b.       Мини тест на адекватность. Если кандидат хочет с вами работать, то пусть сделает простую последовательность действий, которую вы для него подготовили. Например, отправить на почту письмо с темой «ХХХ» с вложением КП в формате PDF. Если исполнитель вам пишет не в вашем формате, то скорее всего он будет так же себя вести и на проекте. Исполнительность – это первое, что нужно проверять для кандидатов.

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

Глава 5. Начинаем проект

Для начала давайте определимся, из чего мы исходим в начале проекта:

У нас есть концепция со всем параметрами.

У нас есть техническое задание. Мы не рассматривали его написание в этой книге. По сути, это техническое описание, что надо сделать на проекте. Обычно оно состоит из макетов и системных требований.

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

Вы – менеджер этого проекта. Т.е. у вас есть все полномочия по принятию решений на этом проекте, а также выделены ресурсы на проект, которыми вы можете распоряжаться.

Инициацию проекта можно условно разделить на 2 пункта:

Подготовка и выделение ресурсов

Планирование проекта

В плане подготовки инструментов и выделения ресурсов вам необходимо рассмотреть следующие моменты:

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

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

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

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

Наконец, проведите общее совещание по проекту. Это обобщает все вышесказанное + дает возможность познакомиться членам проекта.