Руслан Раянов - Управление проектом разработки сайта или веб-приложения. От идеи до внедрения
- Название:Управление проектом разработки сайта или веб-приложения. От идеи до внедрения
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Руслан Раянов - Управление проектом разработки сайта или веб-приложения. От идеи до внедрения краткое содержание
Эта книга раскрывает некоторые моменты и нюансы по ведению проекта разработки веб-приложения.
Подробно рассматриваются основные стадии проекта: концепция, оценка, создание технического задания, планирование, разработка, ввод в эксплуатацию, сопровождение.
В книге представлена информация об управлении параметрами проекта и выделенными ресурсами под проект.
Содержание книги послужило основой для нашего практического курса WPM (Web project Management).
Управление проектом разработки сайта или веб-приложения. От идеи до внедрения - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
h. Риски. Каковы риски проекта? Выпишите список рисков, связанных с проектом. Вы можете их категоризовать. Например, организационные, технические, внешние, по параметрам проекта. Далее для каждого риска вы проставляете степень критичности и степень вероятности (от одного до трех). Далее в порядке приоритетности прорабатываете каждый риск – пишите меры, которые уменьшают вероятность и критичность риска. Тем самым вы получите карту рисков проекта и план по их обработке.
i. Ориентировочный план. Вы примерно должны определить, как вы достигнете цели проекта. Здесь не нужна детализация – просто определите этапы достижения цели. Это позволит команде разработки в целом понимать в какую сторону надо двигаться. Для каждого этапа наметьте ориентировочные сроки. Здесь следует понимать, что это не обязательство или план к исполнению. Это просто желательный план развития проекта, который в процессе может изменяться.
2. Краткое описание. Очень желательно иметь лаконичное описание, которое позволит сразу схватить суть проекта и показать его особенность. Это нужно для взаимодействия с внешним миром (дизайнеры, программисты, партнеры и т.д.). Хорошее описание сэкономит вам кучу времени при взаимодействии с возможными исполнителями на проект – вам не будут писать те, кто заведомо не подходит.
3. Критерии отбора исполнителей. Лучше их заранее проработать, чтобы опять же сэкономить время. Что могут включать эти критерии:
a. Общие требования, например, технологии, географическое расположение, образование, студия/фрилансер, под ключ/специализация. Указывайте требования так, чтобы сразу по максимуму отсеять кандидатов. Подумайте с какими кандидатами вы точно не хотели бы работать. При этом не указывайте аморфные «мастер своего дела» и прочее – это совершенно ни о чем не говорит кандидатам.
b. Мини тест на адекватность. Если кандидат хочет с вами работать, то пусть сделает простую последовательность действий, которую вы для него подготовили. Например, отправить на почту письмо с темой «ХХХ» с вложением КП в формате PDF. Если исполнитель вам пишет не в вашем формате, то скорее всего он будет так же себя вести и на проекте. Исполнительность – это первое, что нужно проверять для кандидатов.
Итак, мы написали концепцию. Исходя из этой концепции, мы будем инициировать проект. В следующей главе мы изучим моменты, связанные непосредственно с началом проекта.
Глава 5. Начинаем проект
Для начала давайте определимся, из чего мы исходим в начале проекта:
У нас есть концепция со всем параметрами.
У нас есть техническое задание. Мы не рассматривали его написание в этой книге. По сути, это техническое описание, что надо сделать на проекте. Обычно оно состоит из макетов и системных требований.
Состав команды разработки определен. Опять же мы лишь частично затронули момент с поиском исполнителей на проект. Предполагаем, что команда разработки у нас уже есть.
Вы – менеджер этого проекта. Т.е. у вас есть все полномочия по принятию решений на этом проекте, а также выделены ресурсы на проект, которыми вы можете распоряжаться.
Инициацию проекта можно условно разделить на 2 пункта:
Подготовка и выделение ресурсов
Планирование проекта
В плане подготовки инструментов и выделения ресурсов вам необходимо рассмотреть следующие моменты:
Вы должны обеспечить подготовку тестового домена, сервера, где будет работать тестовое приложение, базы данных, инструментов разработки (SVN, среды разработки и др.). Одним словом, вы должны подготовить тестовую среду.
Дайте права и полномочия членам проекта. Это доступы к системе планирования, доступ к тестовому приложению (база, код, иногда сервер). Дайте контакты участников проекта.
Необходимо провести обучение участников проекта предметной области. Особенно это важно для таких проектов, где предметная область очень далека от простого разработчика, например, специфические процессы продаж, сложное производство и т.д. Также на этом этапе важно выработать общую терминологию и пояснить ее участникам проекта.
Определение границ проекта для участников. Разработчики должны понимать область проекта, иначе есть риски, что проект пойдет не в том направлении. Обсудите параметры проекта с разработчиками, чтобы они понимали требуемый уровень качества и приоритеты клиента.
Наконец, проведите общее совещание по проекту. Это обобщает все вышесказанное + дает возможность познакомиться членам проекта.
Теперь переходим к плану проекта. Как надо планировать? Систем планирования очень много, я просто расскажу свое видение этого вопроса.
Как мы говорили выше, изначально лучше планировать общими этапами с очень примерными сроками. Очередной крупный этап детализируется на итерации (1-2 недели).
Скрупулезно планировать вы должны только текущую итерацию. Определите совместно с заказчиком, что вы должны сделать на этой итерации. По сути это будут приоритеты заказчика на итерацию.
Сформулируйте, исходя из приоритетов, задачи для исполнителей. При этом следует понимать, что сам приоритет – это по факту не задача. Задача требует указания контекста и особенностей. Также в задаче вы можете дать рекомендации по решению и описать особенности, если это требуется. Для каждой задачи необходимо определить следующие параметры:
Исполнитель
Дедлайн
Оценочное время
Чек-лист. Задание проще всего формулировать в виде чек листа. Так будет проще закрывать задачу исполнителю, а вам – проверять. Чек-лист – это антипод монолитного куска текста в котором размышления автора перемешиваются с заданием и вопросами к исполнителю. Структурируйте свои задачи в форме простых и понятных действий, которые надо сделать исполнителю для закрытия задачи.
Таким образом, у вас на итерацию будет пакет задач для исполнителей, который они должны сделать к определенному сроку. Если итерация составляет 1 неделю, то лучше, чтобы задачи были сделаны к четвергу, чтобы было время внести корректировки в рамках этой итерации. По окончании итерации необходимо написать отчет, в котором мы отражаем насколько хорошо мы закрыли приоритеты клиента на эту итерацию.
Еще очень важный момент по планированию – планируйте так, чтобы в конце итерации всегда получать рабочий результат. Что это значит? Представьте, что вы рисуете картину, например, портрет. Сначала вы делаете общий набросок, на котором определяете контуры лица. Затем вы наносите на холст крупные детали (глаза, рот, нос). После этого вы переходите к более мелким деталям (уголочки глаз, губ, морщинки). И, наконец, вы переходите к теням и т.д. На каждом этапе вы получаете полный рисунок и постепенно его детализируете.
Читать дальшеИнтервал:
Закладка: