Дата: 06.10.2016
Если вам задают вопрос: «Когда начнем еще один проект? Где оставить хороший отзыв о вас?», вы понимаете, что все идет хорошо. Но если вы слышите от команды вопросы вроде: «А что мне сейчас делать?», то это тревожный звонок, который говорит, что в вашей команде не все в порядке.
В любой момент команда должна понимать, над какими задачами работать. А менеджер проекта должен знать, чем занимается каждый член его команды. Если у вас запланированы простои в работе по тем или иным причинам (ждете дизайн, пишется API, готовится контент), уведомляйте об этом команду на старте проекта и оговаривайте занятость каждого человека на этот момент.
Любой член вашей команды должен четко понимать, чем он будет заниматься завтра, послезавтра, через неделю, через месяц на этом проекте.
Вопрос, как правило, возникает из-за отсутствия планирования либо плохой коммуникации внутри команды. Команда должна четко видеть даты всех будущих вех, релизов, этапов тестирования, демонстраций для клиента и тому подобного. Это позволяет мобилизовать силы перед важными событиями, распределять нагрузку в течение каждой итерации проекта, планировать свой график работы (ранний уход с работы, отгул, отпуск).
Это может быть вопрос не только про доступы, но и про проектные документы, ссылки на макеты, ТЗ, план-график и прочее. Проектная информация должна собираться централизованно, у всех членов команды к ней должен быть быстрый доступ и все должны знать, где она находится.
Вы можете использовать различные инструменты для реализации такого хранилища информации: общая папка на сервере, облачное хранилище, база знаний и другие инструменты. Мы в качестве такого хранилища используем проектный портал, где хранятся все ссылки на макеты, доступы, ссылки на Google-документы и так далее.
Портал доступен всей команде, по мере появления новой информации он актуализируется. Команда знает, что вся информация по проекту находится в одном месте. Другой плюс проектного портала – погружение новых сотрудников в проект происходит гораздо быстрее, им сразу становятся доступными все данные о проекте, вы избавляете себя от поиска и пересылки писем с полезными материалами, поиска нужных ссылок и затерявшейся информации в чатах.
Такой вопрос, заданный в середине или конце проекта, должен сильно вас насторожить. Он означает, что проектная команда не видит планируемый результат, к которому нужно стремиться. Продуктивность у такой команды ниже, чем могла бы быть.
Наш мозг устроен таким образом, что мы работаем упорнее, увереннее, с вдохновением, когда видим смысл вещей и понимаем конечный результат. Чтобы исключить подобные вопросы, четко формируйте цель проекта на старте: принесет ли этот проект миллионы заказчикам, сделает ли популярнее его услугу, привлечет ли еще больше лояльных пользователей и так далее.
Также важно формулировать цель проекта для конкретно вашей компании и вашей команды (например, получат ли ребята определенный опыт, поставят ли новый рекорд)
Этот вопрос вовсе не означает, что у вас не самый лучший QA-специалист. Возможно, вы плохо документируете происходящее, описываете или ставите задачи.
На старте проекта должна быть закреплена договоренность о том, какие устройства, операционные системы, версии браузеров будут поддерживаться, где взять устройства для тестирования и тому подобное. Опираясь на эту информацию, команда работает над проектом. И если этот вопрос возник только на этапе QA, задумайтесь: все ли вы предусмотрели в продукте, что было необходимо?
Опираясь на наш опыт, мы создали чек-лист для QA, в котором фиксируется вся эта информация. Но об этом в следующих статьях.
Клиенту на старте проекта лучше уточнить по каким вопросам к кому стоит обращаться, какие вопросы решает менеджер по продажам, какие аккаунт-менеджер, а какие – менеджер проекта. В том числе необходимо договориться о способе обращения.
К примеру, если вопрос срочный и важный – телефонный звонок, если не срочный – почта или мессенджер.
Если возник такой вопрос, значит, вы не смогли вовлечь клиента в проектную работу (или степень его вовлечения была низкой). Вероятно, концепция проекта не обсуждалась детально на старте работ, не было хорошо налаженных коммуникаций, не проводились демонстрации решения. Вероятнее всего, степень удовлетворенности у клиента от полученного продукта будет низкой, и вам понадобится потратить значительное количество времени и усилий, чтобы исправить эту ситуацию.
Если вы все же попали в подобную ситуацию, начать можно с демонстрации результата, проговаривания всех функций и опций продукта. Пусть клиент сам потрогает продукт, а вы ему покажете, на что именно обратить внимание. Возможно, он даже не подозревает, какую удобную опцию вы добавили или какое интересное дизайнерское решение вы использовали.
Покажите админку сайта клиенту, расскажите, для чего она и какие действия можно в ней совершать. Вполне вероятна ситуация, что доступ потребуется в срочном порядке для решения важных вопросов – и клиент должен знать, где его взять, не позвонив вам.
Чтобы исключить такие вопросы, мы отправляем клиенту документ с доступами и паролями к тем сервисам, с которыми работают его веб- или мобильные приложения, и указываем даты следующей оплаты хостинга, доменов, сервисов.
Кажется, что на этот вопрос ответа нет. Но менеджер проекта должен попытаться влезть в «шкуру» клиента, понять его бизнес, цели, мотивы. Главными инструментами для понимания клиента будут хорошо налаженные коммуникации, прототипирование, поиск и демонстрация примеров.
Если вопрос возник, проект может быть под угрозой. В частности – немотивированный менеджер проекта может угробить проект, какие бы классные специалисты на нем ни работали, какие бы длинные сроки ни были и какие бы простые задачи ни стояли.
Что нужно делать:
Этот небольшой список вопросов поможет вам идентифицировать проблемы в вашем проекте. Мы же желаем, чтобы подобных вопросов в вашей проектной деятельности становилось меньше. Если у вас есть свои особые индикаторы проблем в проекте, будем рады их обсудить в комментариях.
Источник: http://rb.ru/opinion/top-10-problems/
комментарии
Оставить коментарийоставить комментарий