Работа с рисками ты должна предвидеть ситуации, негативно влияющие на результат, и устранять или уменьшать их. Твой результат это когда команда достигает поставленных по плану ключевых результатов, отрабатывая риски на уровне мелких работ.
Работа с качеством полученный результат должен соответствовать как ожиданиям качества от заказчика, так и собственным требованиям к качеству команды, например, таким, как качество кода, качество документации и базы знаний, тестовых сценариев. Каждый проектный результат проверен и соответствует заявленному качеству: протестирован, продемонстрирован, подтвержден опытным путем и т. д.
Работа с коммуникациями выстраивание всех коммуникационных потоков в проекте: как внутри, так и наружу. Результат: отсутствие простоев или лишней работы из-за «не договорились», отсутствие конфликтов с внешними относительно команды ролями.
Это роли. От проекта к проекту каждая роль может исполняться отдельным человеком или один человек может подхватывать несколько ролей. Помни: каждый новый специалист «съест» кусочек ресурса проекта. Ты должна понимать, каким результатом для команды обосновано присутствие в ней каждого участника.
Не в каждом проекте нужен выделенный представитель каждой роли. Оцени необходимость в результате каждой роли и прими решение, насколько она важна, критична для этого проекта.
Акцент твоей работы в роли менеджера будет меняться по ходу проекта:
Старт проекта. Ничего не понятно, результат существует в виде общей концепции, риски «не получить результат в конце» максимальны. Ты акцентируешь свое внимание на понимании архитектуры/концепции и построении плана проекта. Выстраиваешь основные потоки коммуникаций. Основная задача выйти из предпроектного тумана «ничего не понятно» и перейти в штатный режим работы.
Проект. Когда работа встает на стабильные рельсы и разработчики начинают «строгать» фичи, а также появляются осязаемые кусочки результата, ты переключаешься на контроль и управление ожиданиями: демонстрируешь промежуточные результаты, получаешь уточнения и новые вводные, актуализируешь путь к успеху, т. е. план проекта. Это этап производства тебе надо в заявленные сроки и с ожидаемым качеством прийти к целевому результату.
Завершение проекта. Когда же проект близится к финалу и кусочки соединяются в итоговое решение, ты переключаешься на качество во всех его проявлениях и на введение решения в эксплуатацию. Основная задача запустить решение в эксплуатацию. А значит, оно должно работать, и работать хорошо. А пользователи должны хотеть им пользоваться.
Этап проекта диктует менеджеру, как отрабатывать риски и планы, ускорять поставки и управлять изменениями, как шлифовать качество и оформлять результат.
Я намеренно не упоминаю выше такие пункты, как «проведение дэйли», «совещания» и «заведение задач»: ведь сами по себе эти действия не несут результата это всего лишь инструменты, которые команда может применять, а может и не применять для улучшения своего результата.
Итак, краткие тезисы этой главы:
Ролей в команде разработки много. Каждая для своего результата. Определи целевой результат и, исходя из него и доступной команды, распредели роли.
Роль не равно человек. Береги ресурсы, если проекту не нужна/не ценна работа какой-то роли.
Роль менеджера в достижении общего результата.
Акценты в твоей работе зависят от текущего состояния результата всего проекта.
Ну все понятно, а начинать-то с чего? \ Старт проекта
Как гласит один из законов Мерфи, «все, что хорошо начинается, кончается плохо. Все, что плохо начинается, кончается еще хуже».
От правильного старта проекта зависит довольно многое. Чем лучше подумать на старте, тем меньше потом придется переделывать. Это совершенно не значит, что надо долго думать и мало делать. Делать-то как раз надо много, и с самого начала.
Проект, в зависимости от того, что надо получить и как, конечно же, стартует по-разному. Ниже нарисована примерная схема старта, где сверху на этапах указаны действия, а снизу под линией результат этого этапа.
1. Опишите все, что хочет заказчик. Лучше начать с простого наброска документа от самого заказчика, которое называется первоначальным Видением. Это не Техническое задание, а именно то, как заказчик видит конечный результат. А потом его надо проговорить словами. Как раз в разговоре вы начнете понимать, что важно для заказчика и чего он хочет достичь на самом деле. Не факт, что именно это написано в Видении. Там может оказаться описание того, КАК заказчик себе представляет решение целевой бизнес-задачи. И не всегда это решение верно.
На первых проектах у тебя может не хватить опыта это понять и предложить, как на самом деле надо. И работа будет отталкиваться именно от Видения заказчика. Это не хорошо и не плохо, это жизнь. И решение, которое придумал заказчик, если даже оно не идеальное, будет работать. Ну и прекрасно. В любом случае попросите сначала описать, а потом рассказать словами задачу. И записывай все, что скажет заказчик. Именно этими записями ты расширишь первоначальное Видение.
В этом пункте используй те же принципы, что и в главе по декомпозиции задач (см. главу «Декомпозиция задач»). На тебя будет валиться куча информации по самым разным аспектам будущего проекта: идеи по реализации, элементы обязательных требований, просьбы по процессам работы и законы, которые влияют на работу отрасли. Старайся выделять «области» будущего проекта и прописывай там каждый такой факт или требование. В первой версии области могут быть такими:
Функции продукта.
Техника и инфраструктура.
Процессы совместной работы.
Этапы, контрольные точки и дедлайны.
Источники информации для будущего сбора требований.
Пользователи, роли и их ограничения.
Риски.
Прочее.
Раскладывай входящий поток по нужным областям, выделяй подчиненные области, сегментируй информацию. Чем конкретнее факт и его влияние на будущий результат, тем больше пользы проекту. Плюс ты сразу заметишь, каких данных тебе НЕ хватает. Например, про функции данных много, а про сроки ничего не сказано. А еще так ты можешь неожиданно увидеть противоречия в желаниях заказчика («Хочу много, дешево и вчера»). Это все надо обсуждать, и это тоже часть работы по управлению ожиданиями заказчика.
2. Конкуренты продукта. Посмотри, есть ли конкуренты целевого продукта на рынке. Сядь и проанализируй их. Твоя задача понять, что в них хорошо, а что плохо, и честно своровать хорошие идеи, пометив плохие, чтобы не вляпаться. В цивилизованном мире это называется бенчмаркинг. Затем включаешь здравый смысл и дописываешь Видение так, как себе представляешь, предлагая дополнительные возможности, детали и удобные моменты. Вероятно, заказчик часть из них выкинет, но это не страшно. Ваша совместная задача прийти к общему знаменателю в головах, зафиксированному на бумаге.
3. Границы проекта. Как только вы более или менее зафиксировали Видение, пришло время прописать Границы проекта. Это дополнительный раздел, где четко описано, что НЕ будет входить в систему и где заканчивается то, что уже описано. Чтобы не было недопонимания потом в стиле: «Я думал, раз вы делаете мостик, то и асфальтированную освещенную дорогу в 5 км к нему сделаете, а иначе как им пользоваться?» Это тоже должно входить в полный вариант Видения. Или следует четко прописать, что никаких подъездных путей и освещения в конечном результате не предусмотрено.
В этой части важно еще описать, что дополнительно будет поставляться в рамках результата проекта документация (в каком виде и какого объема?), дополнительные материалы, дополнительные работы в виде обучения, маркетинга, поддержки и т. д. Или не будут поставляться. Здесь нет задачи от чего-то сразу отказаться. Тут задача максимально четко прописать границы. Вот и прописывай. Чем лучше пропишешь, тем меньше надо будет доделывать по завершении проекта и тем более счастливыми будут все участники.