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