В целом, управление проектами — это область, которая объединяет многие бизнес-процессы. Досконально изучить управление проектами в области информационных технологий вы можете окончив курсы по it менеджменту, а в настоящей статье рассмотрим основные аспекты процесса управления проектом на примере разработки сайта.
Статистически 90% проектов гибнут, не проживая и двух лет, являясь все это время дотационными.
Проект по построению небольшого, но качественного интернет-решения требует управления многими процессами. Все они базируются на балансе содержания проекта, его стоимости, времени исполнения (deadline) и уровня качества. Это именуется «тройственной ограниченностью» проекта. Все составные зависят друг от друга. Правильный баланс и является хорошим результатом «управления проектом». Плюс удовлетворение заказчика.
С нашей точки зрения для небольших проектов наиболее подходящей является следующая упрощенная методология ведения IT-проектов:
1. Выработка концепции и планирование (Envisioning & Planning)
- Определяются бизнес цели и проводится экспертиза проекта. Это очень важный этап, на котором принимается решение о принципиальной жизнеспособности проекта. Включает в себя четкое понимание по вопросам: - Какова идея и сущность проекта; - Определение целевой аудитории; - Инновационность, анализ конкурентов и аналогов (техническая часть и их затраты на продвижение); - Типичные бизнес-процессы будущего проекта; - Пути монетизации проекта, бизнес-модель; - Пути продвижения после запуска проекта (анализ эффективности по тройственной ограниченности, оценка ROI); - Возможно — базовое техническое задание проекта. - Выбор подрядчиков (составные части: функционал, дизайн, верстка, поддержка, продвижение). Лучший подрядчик будет обладать выдающимися характеристиками по всем перечисленным ниже параметрам. Но и цена его будет предельно высока. Дня небольших проектов это будет неподъемным с точки зрения параметра цены из упомянутой тройственной ограниченности в проектном менеджменте. Итак, основные параметры выбора подрядчика: - компания/исполнитель (его опыт, специализация, размер, стабильность, доступные ресурсы (персонал, суб-подрядчики и пр.), - преимущества и отличия от конкурентов, доказательства профессионализма, наличие сертификатов и наград, участие в ассоциациях, конференциях, миссия и видение). - предложенный путь проекта (график выполнения, разделение на задачи, обновление статуса по задачам (отчеты), соответствие Request for Proposal (RFP это заявка от заказчика с базовыми требованиями к исполнителю) и разработка технического задания (ТЗ) проекта, вопросы изменения ТЗ по ходу проекта, общение напрямую с разработчиками или только через ПМ (проджект менеджера). Часто составление технической документации по проекту является отдельной большой составной частью проекта на основе решений этапа Envisioning & Planning. - отношения (помощь в планировании, определении KPI, обучение использования продукта, определение уровня поддержки, процедуры в случае отказа или выхода их строя, атак на систему) - контроль над техническими операциями проекта и процедуры перехода на работу с другими подрядчиками, пределы эволюционирования разрабатываемого проекта. - цены (методы ценообразования (почасовые, попроектные), общая цена проекта, включая обновления, обучение, поддержку, продвижение). - рекомендации (доверие к подрядчику, портфолио, подобные проекты, рекомендации прошлых клиентов, являются ли они текущими клиентами). - интервью (есть ли хорошее чувство или как говорится «личная химия» между вами и подрядчиком, слушет ли подрядчик о ваших потребностях, либо говорит вам, что является вашими потребностями, воспринимает ли подрядчик с энтузиазмом ваш проект, предлагает ли подрядчик некоторые творческие идеи к вашему проекту, о которых вы уже возможно задумывались, обучают ли вас потенциальные подрядчики в процессе переговоров и повышают ли вашу квалификацию). - Выбор методов и инструментов управления проектом (для больших компаний это к примеру Jira и Scrum, для небольших проектов — обычно Ticket Systems или Google Docks плюс Skype). - Определение характеристик платформы (CMS/CMF). Для небольших проектов обычно выбираются популярные Open Source решения, так как они максимально эффективны для решения первоначальных задач проекта. Основные вопросы, решаемые при выборе платформы: - Подходящая базовая архитектура и функционал платформы; - Простота расширяемости и готовых платных и бесплатных функциональных решений (Extensions); - Масштабируемость и предельные нагрузки для платформы; - Необходимый уровень безопасности; - Развитость комьюнити и документации. 2. Разработка и стабилизация проекта (Developing & Stabilizing). После анализа идеи, оценки затрат на внедрение и выбора подрядчика начинается процесс разработки. Он включает:
- Определение характеристик проекта; - Идея и стилистика дизайна проекта (отдельное направление проектного менеджмента — в больших компаниях направления курируют «арт-директор» и «креативный директор» (нетривиальные ходы в позиционировании). - Разработка юзабилити и прототипирование проекта (wireframes, максимизация удобства и оптимизация интерфейса). - SEO-friendly и контентная иерархия проекта (на основе SEO анализа конкурентов, SEO-специалистом составляется семантическое ядро и необходимая структура, архитектура верстки определяется соответственно верстальщиком) - Необходимые требования для пользователей; - Работа над самим контентом, его качеством и структурой. - Функциональное наполнение, выражающее сущность вашего проекта и достижение целей - Визуальный дизайн. Должен нравиться вам, быть удобным и расставлять акценты на проекте, выделяя и подчеркивая главное, ставя на второе место дополнительное. - Технические требования (панируемая нагрузка по посещаемости, «тяжелый» контент, уровни доступа к функциональным частям, время загрузки страниц, спецификация хостинга). - Организацию процесса разработки; - Вовлеченность и заинтересованность разработчиков в проекте. - Взаимосвязь заказчика и разработчика по ходу процесса для достижения нужного результата. - Ознакомление заказчика с интерфейсной частью панели администратора и необходимых действиях с его стороны. - Доступ заказчика к статусу задач по проекту (% завершенности, оставшиеся задачи, возможность комментирования и уточнения, создания новых задач). - Периодические отчеты исполнителя. - Минимизация рисков; - Сохранение кода (backups или системы контроля версий как Subversion (SVN) или Git). - Требования качества (бесперебойность, различные нагрузки, скорость работы, сложность техподдержки, расширяемость, безопасность данных). - Тестирование качества (допустимые рамки отклонений качества). - Базовая минимизация нетехнических рисков проекта. В частности ключевые юридические документы для технического решения (Terms of Servises, Privacy Policy). Возможно со стороны субподрядчика.
3. Внедрение (Deploying)
- Запуск проекта; - IT инфраструктура — размещение и хостинг (In-house, Partner или External data center). - Миграция проекта (взаимоотношение сервера разработки, продакшн-сервера и live-серверов проекта). - Распределение нагрузки (использование механизмов кэширования, varnish, зеркала проекта, Fail-safe механизмы). - Обучение заказчика использованию сайта, загрузке контента и т.п. - Разработка рабочих процессов (workflows) по поддержке проекта со стороны заказчика. - Поддержка со стороны подрядчика (Support & Maintenance). - Соглашение об уровне услуг — Service Level Agreement. SLA высокого уровня прописаны в отраслевых стандартах типа CobiT или ITIL, но в небольших проектах между заказчиком и исполнителем должно взаимопонимание об основных параметрах SLA: - гарантии исправления ошибок (какие ошибки и в каких рамках исправляются). - фиксированное время ответа на любой запрос заказчика. - обновления на более новые версии CMS. - автоматический мониторинг состояния проекта. - выделенный менеджер для контактов. - регулярные проверки и аудит. - технические метрики (см. требования качества).
