Помоги проекту - поделись книгой:
В следующей главе будем изучать, кто такой менеджер проекта, а также коснемся вопроса, какое участие в проекте принимает заказчик.
Глава 2. Менеджер проекта и заказчик.
Менеджер проекта – это главный человек на проекте. Именно от него во многом зависит успех. Именно менеджер проекта принимает ключевые решения. Именно менеджер объединяет людей с разными навыками и возможностями для достижения определенной бизнес-цели.
Давайте выделим основные функции, которые выполняет менеджер на проекте:
● Взаимодействие с заказчиком. Менеджер выясняет детали проекта, вносит корректировки в проект по пожеланиям заказчика, докладывает клиенту о ситуации на проекте. Менеджер – это вход для заказчика в группу разработки.
● Взаимодействие с исполнителями. Это постановка задач, пояснение их особенностей, проведение планерок и т.д. Важен постоянный контакт между исполнителями и менеджерами. Менеджер должен знать, как идет выполнение задач и общий моральный климат на проекте. Исполнители также должны чувствовать поддержку менеджера и его активное участие (особенно при удаленном способе работы). Менеджер должен давать адекватную обратную связь исполнителю по его работе и стилю выполнения задач (медленно/быстро, количество ошибок, дедлайны, форма отчета, полнота решения и т.д.).
● Бизнес-аналитика. Очень часто менеджер выполняет эту роль. Он изучает предметную область заказчика, прорабатывает отдельные моменты и выступает внутри команды от имени заказчика в решении вопросов по бизнес-логике. В больших проектах для проработки бизнес-логики выделяется отдельный человек, который занимается только этим (бизнес-аналитик).
● Контроль выполнения задач. Контроль может выполняться по 2 параметрам: по качеству и по срокам. Для первого параметра менеджер должен обладать некоторой технической квалификацией. Обычно эту работу делают тестировщики, но в небольших проектах эта задача возлагается на менеджера. Второй параметр – это чисто управленческий момент. Если задача не выполнена в срок, то надо разбираться почему, есть ли проблемы, когда будет сделана и т.д.
● Планирование проекта. Менеджер на основании технического задания составляет план итераций и планы по каждой итерации отдельно. Нет смысла прописывать весь план очень подробно. Все равно будут изменения и ваш план будет перекраиваться не раз. Гораздо лучше составить общий примерный план и четко спланировать очередную итерацию (на 1-2 недели).
● Выделение ресурсов. Обычно у менеджера есть набор ресурсов. Это могут быть денежные средства, время, люди, программные средства и т.д. Задача менеджера – грамотно и экономно ими распорядится для достижения цели проекта за минимальное количество шагов.
● Решение проблем. Если возникают какие-то проблемы на проекте, то обычно именно менеджер их разруливает. У него для этого есть все полномочия и права, а также ответственность. Исполнители также должны стараться самостоятельно решать проблемы. Они знают принципы и могут на основании них решать большинство таких моментов. Проблемы на проекте могут быть очень разнообразными, но можно выделить несколько типов:
○ человеческий фактор. Обычно это конфликт между людьми. Изучайте переговоры – это позволит эффективно и взаимовыгодно решать любые вопросы.
○ проблемы с ПО. Что-то не так работает, сбои и т.д.
○ нехватка ресурсов. Это самый частый вид проблем. Не хватает времени, выход за рамки бюджета, не хватает квалификации для решения задач и т.д. Все это провоцирует напряженность на проекте, и задача менеджера – так эффективно перераспределить ресурсы, чтобы проект дальше продолжил свое шествие к намеченной цели.
● Метрики и отчеты. Метрики обычно считаются автоматически. Отчеты необходимо писать для заказчика, а также для внутреннего пользования (для руководства). Эти моменты обеспечивают прозрачность проекту и работу на нем.
Теперь давайте рассмотрим качества, которые присущи хорошему менеджеру:
● Во-первых, он должен понимать и принимать основные принципы разработки и ведения проекта. Менеджер должен быть оплотом этих принципов и борцом за них. Если этого нет – то проект будет сложно продвигаться.
● Быстрое переключение между задачами. В силу своей доступности, менеджеру часто приходится прерываться для выполнения запросов от исполнителей и клиентов. Поэтому он должен уметь быстро включаться в другую работу. Это не очень хорошо в плане концентрации, но такова особенность работы менеджера. Ему приходится вести себя как порхающая бабочка, которая перелетает с цветка на цветок легко, плавно и быстро.
● Навыки переговоров. Менеджер – это, в первую очередь, общение. Львиная доля работы менеджера – это общение с клиентами, исполнителями и другими заинтересованными лицами. Это может быть разговор по телефону, живое общение или переписка (email, чат или отчет). В любом случае, если вы хотите быть менеджером, вам надо прокачать навык переговоров и продаж, которые идут рука об руку.
● Системность. Системность позволяет добиваться результатов меньшими усилиями. Вы просто регулярно применяете определенные методики и практики. Это, в первую очередь, требует определенной дисциплины и мотивации. Людям всегда сложно дается внедрение новых паттернов поведения, особенно заставляющих их делать что-то дополнительное. Научитесь смотреть на все через призму систем и процессов, протекающих в них. Все в этом мире – это системы и подсистемы. Научитесь видеть взаимосвязи между звеньями системы. Очень часто для прорыва в системе нужно поменять лишь структуру, расположение звеньев, не трогая содержимое. Продумайте это на своем примере.
● Умение говорить на техническом и бизнес-языке. Вы должны понимать своих клиентов. Обычно они говорят на языке маржи, процентных ставок и т.д. Т.е. они говорят на языке своей предметной области. Разработчики обычно говорят в терминах базы данных, процедур, классов, URL и т.д. Вы должны понимать их терминологию и уметь соотносить бизнес-язык заказчиков с техническим языком разработчиков. Не ставьте задачу исполнителю на бизнес-языке, т.к. возникает большой риск непонимания и последующего неверного решения. Будьте транслятором между этими 2 мирами, а не испорченным телефоном.
● Общее понимание различных предметных областей. Это значительно помогает вам в решении задач клиентов и общении с ними. Вы должны иметь представление, как работает склад, на чем зарабатывают банки, как работает интернет-магазин в полном цикле, как обрабатываются лиды (продажи) и др. Чем больше вы знаете подобных типовых решений, тем проще вам будет подобрать решение для текущего клиента.
● Исполнительность. Исполнительность означает, что если вы задумали сделать какое-то дело, то вы его просто ДЕЛАЕТЕ, а не бесконечно его затягиваете, ожидая идеального момента, придумываете сложности и т.д. Этот навык крайне важен для менеджера. Просто берем и делаем. Проблемы с исполнительностью часто бывают у интеллигентных или просто умных людей. Они слишком много думают и мало делают. Сделайте упор именно на Делание, а не Продумывание. В конечном счете именно действия будут определять ваш результат, а не мысли (хотя правильные мысли тоже хорошая штука). Мысли без действия – это как семена без земли. Положив их в коробку, вы никогда не получите урожая.
● Навык принятия решения и ответственность. Ответственность для менеджера должна быть привычным делом. Сила менеджера соотносится с тем, насколько масштабные проблемы он может взять на себя. Принимая любое решение, вы берете на себя его последствия. Никогда не будьте страусом – просто пряча от проблемы голову в песок. Ответственно принимайте решения, основанные на правильных принципах и здравом смысле, и в 95% вы будете правы (5% – бывают фатальные случаи, когда сложно предугадать развитие ситуации).
Мы рассмотрели вкратце, кто такой менеджер, чем он занимается и каким он должен быть. Теперь давайте перейдем к заказчику.
Каковы основные обязанности заказчика на проекте? Да, именно обязанности. Ни в коем случае не должно быть такой ситуации, когда заказчик дал деньги и растворился на пару месяцев, считая что проект – это ответственность только исполнителя. В этом случае риски проекта очень высоки. Если у заказчика твердое желание успешно завершить проект, то необходимо с его стороны выполнять следующие обязанности:
● Своевременно и однозначно отвечать на вопросы исполнителя. Здесь очень важно, чтобы заказчик и исполнитель говорили на одном языке. Проще всего – с помощью макетов (т.е. визуальный язык). Также учитывайте скорость ответа. Связанные с этим моментом простои довольно легко устранить на организационном уровне. И последний момент – прорабатывать вопросы лучше не по одному, а целой пачкой – так будет проще и оперативнее. Требуйте от исполнителя не один одиночный вопрос, а сразу пачку и обсуждайте голосом эти вопросы (письменно – гораздо хуже, т.к. довольно сложно понять – правильно ли вас понял исполнитель).
● Своевременно готовить материалы для сайта – текст, графику и т.д. Если вы хотите, чтобы проект завершился до дедлайна, то в вашей силе этому поспособствовать – оперативно реагируйте на запросы по контенту. Очень часто из-за этого возникают простои. Либо контент меняется по несколько раз, т.к. заказчик недостаточно основательно продумал его с самого начала. Конечно, правки всегда могут быть, но их не должно быть очень много – это тормозит команду разработки (конечно, в идеальном случае это вообще не должно пересекаться – разработка и наполнение контентом, но в реальных условиях это довольно частая практика. Еще момент в пользу такого подхода – заказчик неявно начинает тестировать сайт на реальных данных).
● Своевременно давать обратную связь по проекту и направлять в нужное русло. По моему мнению, это самая важная функция заказчика. Его задача – не дать проекту уйти с нужного курса. Заказчик должен постоянно отслеживать текущий результат проекта и принимать меры, если получает неподходящий результат. Менеджер проекта и команда разработки не всегда могут полностью оценить бизнес-потребность в том или ином элементе. Именно заказчик лучше всех знает, как это будет применяться в его бизнесе. Поэтому только он может внести важные коррективы, которые позволят максимально эффективно использовать сайт в его бизнесе.
● Тестировать с точки зрения бизнес-процессов заказчика. Этот пункт несколько перекликается с предыдущим. Тестировщики от разработчиков обычно просто тестируют функциональность на предмет соответствия решения условиям задачи. Однако они не смогут выявить организационные ошибки и неучтенные бизнес-потребности. Это можно сделать только задействовав ресурсы заказчика. Правильно ли идут информационные потоки, все ли данные учтены, будет ли удобно сотрудникам заказчика работать в системе, каковы показатели эффективности каждой роли и т.д.
Помимо необходимых действий, есть еще пожелания к заказчикам. Это несколько рекомендаций, которые увеличивают шансы проекта на успех.
Следить за проектом. Мы об этом уже говорили и еще раз повторим. Нельзя пускать проект на самотек, какая бы хорошая команда разработки у вас ни была.
Выполнять пожелания и запросы по проекту от исполнителя. Это ускорит процесс выполнения проекта, а также позволит избежать возможных ошибок.
Согласовать взаимодействие с исполнителем. Что это значит? Это значит, что исполнитель должен четко знать ваши приоритеты и цели, связанные с проектом. Это упрощает принятие решений и взаимодействие. Также желательно определить приоритеты по параметрам проекта (бюджет, сроки, объем, качество). При необходимости, это позволит менеджеру проекта правильно перераспределять ресурсы.
В случае обнаружения ошибки указывайте точно местоположение ошибки (URL, под каким пользователем, браузер) и что конкретно не так (описание ошибки, ссылка на скрин). В некоторых более сложных случаях надо также указывать, как должно быть в итоге + ручные расчеты, чтобы исполнитель их мог проверить под отладчиком (т.е. вручную пройти программу и посмотреть внутренние вычисления).
Сразу определять свои ожидания по срокам и бюджетам. Если какой-то параметр для вас очень критичен и имеет строгий дедлайн – то дайте эту информацию менеджеру проекта. Не должно быть такого, когда вы посередине проекта начинаете вдруг требовать его форсированного завершения. В этом случае это крайне негативно будет влиять на качество.
Избегать задержек, связанных с финансами и контентом. Заранее готовьте материалы и откладывайте деньги под бюджет проекта. Это позволит избежать непроизводительных задержек с вашей стороны. Задержки в любом случае будут в проекте, и тут редко кому удается их избежать. Поэтому задача заказчика – хотя бы в относительно простых моментах их не допускать.
В этой главе мы рассмотрели, чем на проекте занимаются менеджер и заказчик. Далее мы переходим к первому этапу ведения проекта – проработке идеи проекта и ее тестированию.
Глава 3. Идея проекта. Как проработать и проверить идею.
Сложно переоценить этот этап. Именно здесь вы можете сэкономить большую кучу денег. Перед началом проекта вы обязаны проверить – действительно ли проект даст тот результат, на который вы нацелились? У вас должна быть некоторая степень уверенности, что выполнив проект, вы получите тот или иной бизнес-результат.
Имея в голове эту цель, мы займемся вопросом проработки идеи проекта, а также рассмотрим вопрос “Как протестировать свою идею на рынке”.
Первое, что вам надо сделать – это понять, а нужен ли кому-то проект кроме вас. Т.е. важно в самом начале определить аудиторию, которая будет потреблять результаты вашего проекта. Для этой цели очень удобно использовать сервис Wordstat – wordstat.yandex.ru. Определите целевые запросы, которые будет набирать ваша целевая аудитория в поисковиках и посмотрите, какая у них частотность в Wordstat – там самым вы поймете, есть ли у вас рынок или нет, и насколько он большой.
Если у вас рынок есть, то поздравляю, двигаемся дальше.
Изучаем конкурентов – кто они, какая у них посещаемость, сколько их в нише, какая у них товарная линейка и т.д. Составьте список своих конкурентов и проанализируйте их. Чем лучше вы будете знать конкурентов, тем больше нюансов вы сможете учесть в своем проекте.
Также изучите по конкурентам такой важный момент как бизнес-модель. На чем именно делают деньги ваши конкуренты? Это не всегда просто выяснить. Не всегда самый доходный товар или услуга на виду. Возможно вы видите только очень привлекательный и дешевый front end продукт, а основные деньги делаются на другом товаре, который предлагается только теплым клиентам. Подумайте об этом: что в вашем случае может быть front end продуктом (максимально простой вход для клиента), а что back end продуктом (на чем делаются основные деньги).
Примечание. Здесь мы не будем подробно останавливаться как проводить исследования целевой аудитории, конкурентов и их продукции. Сейчас наша цель – это управление проектом в целом. Поэтому, мы лишь поверхностно коснемся этих, без сомнения, важных вопросов.
Пока все, что мы сделали – это, в основном, аналитика, т.е. без реального взаимодействия с рынком. А именно только оно может достоверно показать, имеет ли ваш проект шанс на успех. Для этого вам необходимо организовать тест вашей идеи. Наверно самый лучший вариант – это сформулировать свое очень заманчивое для клиента предложение, сформировать лендинг (т.е. простой одностраничный сайт) и запустить на него рекламу.
В результате вы получите какое-то количество кликов (пусть будет к примеру 200 или 500). Из них к вам обратилось 5 человек. В итоге вы получаете конверсию – 5 / 200 * 100% = 2,5%. Если ваша конверсия составит более 1%, то, значит, ваша идея стоит того, чтобы попробовать. Если нет – то, возможно, ваше предложение не настолько заманчивое, и следует над ним поработать.
Конечно, не во всех областях так просто выделить предложение и сделать лендинг под него. Например если вы задумали сделать агрегатор-биржу или социальную сеть, то здесь так просто не получится проверить с помощью лендинга. Альтернативой может служить опрос целевой аудитории в социальной сети – будут ли они использовать такой сервис и т.д. Вообще общение с целевой аудиторией очень помогает – оно раскрывает такие моменты, о которых вы даже и не могли подумать.
При создании предложения делайте его чуть лучше, чем в среднем по рынку (имеется в виду по цене). В идеале, это должно быть предложение, от которого просто глупо отказываться.
Этап тестирования очень часто пропускается (мы и сами его пропускали в некоторых своих проектах, и обжигались на этом). Сделайте хотя бы простой опрос из 100 человек (желательно как можно ближе к целевой аудитории проекта). Это не займет много времени, но зато может вам сэкономить очень приличную сумму денег и время.
С тестами закончили, теперь давайте сформулируем цель проекта. Что мы в итоге хотим от него получить. При этом цель, конечно, лучше ставить в вещественных параметрах и в цифрах. Напишите, какой конкретно результат у вас будет по завершению проекта. Это могут быть:
– деньги
– трафик
– функционал
– аудитория
– какие-либо единицы в проекте (видео, тексты и т.д.).
Определите точную метрику и дату, к которой вы хотите ее получить. Ставьте значение на границе своих возможностей. Слишком много – это будет демотивировать и подрывать весь проект, мало – тоже плохо (будет все затягиваться и интерес к проекту быстро пропадет).
Следующий момент – оцените, от чего вам придется отказаться. В мире очень много возможностей и успеха добивается тот, кто умеет отказаться от хорошего в пользу великого. Ваши ресурсы не безграничны, поэтому определитесь сразу, готовы ли вы пожертвовать всем остальным ради этого проекта.
Напишите список альтернативных проектов и осознанно откажитесь от каждого в пользу текущего проекта. Конечно, если у вас большая команда, то вы можете делегировать мелкие проекты. Здесь мы говорим о проектах, которые могут занимать практически все ваши текущие ресурсы (время, люди, деньги, энергия).
Также стоит рассмотреть вопрос о запуске сначала какого-то более мелкого проекта, пилотного проекта. Мне нравится идея прототипных решений – вы не делаете сразу большое полноценное решение – сначала вы делаете пилотный быстрый проект для получения обратной связи. Т.е. этот проект гораздо легче основного проекта и на нем вы понимаете, будет ли это работать или нет. В каком-то смысле, проведение теста и является пилотным проектом, но степень “пилотности” может быть разной.
К примеру, при разработке доски объявлений, вы можете сделать сначала самую простую доску (возможно на бесплатном движке, либо сделать свой движок с ограниченным количеством функций). Поработать с ним, понять, что в итоге вам нужно и сделать уже свой полноценный движок со всеми наворотами.
Как мы уже упоминали, сразу соотносите свои ресурсы с проектом. Сможете ли вы его потянуть в том виде, который вы определили. Нет ли разрыва между возможностями и потребностями? Самое важное – будьте честными с собой. На берегу решите все моменты с ресурсами для проекта, чтобы потом не закрывать проект на середине пути. Два самых важных параметра – это деньги и время. Хватит ли вам денежных средств для поднятия проекта до того момента, пока он не станет окупать сам себя? Будет ли у вас время на полноценное участие в проекте? Без проработки этих 2 параметров риски проекта существенно увеличиваются.
На этой немного суровой ноте мы заканчиваем главу про проработку идеи проекта и переходим к предпроектной деятельности. На этом этапе вы уже твердо решили, что проект будем делать и теперь мы переходим к тактическим вопросам подготовки проекта к запуску.
Глава 4. Предпроектная деятельность
Что мы должны сделать до начала проекта?
Во-первых, это общая оценка проекта.
Поделиться книгой: