Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий. Владимир Завертайлов

Чтение книги онлайн.

СКАЧАТЬ style="font-size:15px;">      Различают два ключевых формата работы. Time & Material – оплачивается время, затраченное командой, в таком случае задачи можно менять как угодно. И Fixed Price – цена и задачи оговариваются на берегу. У обоих вариантов есть как плюсы, так и минусы. Time & Material переносит риски на заказчика, но работу можно организовать быстрее и гибче. Fixed Price – заставляет разработчика зашивать риски и подстраховку в смету, лишает гибкости и снижает скорость выпуска функций из-за процедуры согласования бюджета, но яснее воспринимается клиентом. Существуют также гибридные модели.

      Условия заказчика регламентируются тремя способами:

      

Требования. Постановки задач, технические задания (ТЗ), тикеты[1], рисунки на салфетках, бэклоги… Управление требованиями, выявление, уточнение, актуализация, расстановка приоритетов занимают массу времени. Рассмотрим подробно работу с требованиями и способы приоритизации в главе 4.

      

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

      

Тикет-система. Хранит задачи для команды и статусы по ним. Может быть частью системы управления требованиями или существовать отдельно. Может быть только для внутренних нужд команды, а может пускать заказчика внутрь.

      Команда проекта. В digital команда может сжиматься до одного человека, а-ля веб-мастера, и включать в себя заказчика. Либо наоборот: разрастаться, выделяя отдельные функции в роли. Как строить и выращивать команды, мы разберем в главе 7. Командная работа подразумевает делегирование. Например, менеджер справится с задачами аналитика и тестировщика, но с ростом проекта целесообразно выделить это в отдельные роли. Или программист может администрировать серверы, если квалификация соответствует. Но как только серверного хозяйства становится много – приходится выносить это в отдельную роль – администратора. Для примера будет такая команда:

      

Менеджер. Ну тут все понятно, это – вы. Головой отвечаете за проект, работаете в области высоких энергий и мгновенной ответственности за базар. Про вас вся эта книга.

      

Разработчик (программист). Бородатый чувак, который пилит код. Пока без дебрей на чем, бэкенд-фронтенд. Универсальный боец.

      

Дизайнер. Отвечает за весь визуал и интерфейсы. Хотя пошла мода на специализации UI/UX-дизайнеров и т. д. Подробнее об организации дизайна поговорим в главе 6.

      

Аналитик. Конкретизирует требования. Подробнее об этом поговорим в главе 4, посвященной аналитике.

      

QA (quality assurance, тестировщик). Тестирует продукт.

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

      

Руководство. Ваш непосредственный СКАЧАТЬ