● Быстрое переключение между задачами. В силу своей доступности, менеджеру часто приходится прерываться для выполнения запросов от исполнителей и клиентов. Поэтому он должен уметь быстро включаться в другую работу. Это не очень хорошо в плане концентрации, но такова особенность работы менеджера. Ему приходится вести себя как порхающая бабочка, которая перелетает с цветка на цветок легко, плавно и быстро.
● Навыки переговоров. Менеджер – это, в первую очередь, общение. Львиная доля работы менеджера – это общение с клиентами, исполнителями и другими заинтересованными лицами. Это может быть разговор по телефону, живое общение или переписка (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. Предпроектная деятельность
Что мы должны сделать до начала проекта?
Во-первых, это общая оценка проекта.
Во-вторых, определить основные параметры проекта.
И, в-третьих, формализовать все моменты по проекту в виде концепции проекта (это письменный документ, а не что-то, что у вас в голове).
Начнем с оценки. Самый важный момент, надо различать оценку, обязательство и фактический показатель. Оценка – это прогноз по метрике. Обязательство – это обещание сделать в рамках определенных метрик. И фактическая метрика – это то, что по факту получилось.
Очень часто просят назвать очень точную оценку по краткому содержанию проекта. Тем самым заказчик уже закладывает гигантские риски в проект. Невозможно дать точную оценку на начальном этапе. Она в принципе не может быть точной. Есть такое понятие как "Конус неопределенности". На начальном этапе оценка очень широкая, затем по мере движения проекта вилка оценки уменьшается (т.к. уменьшается неопределенность в проекте). Таким образом, не пытайтесь очень точно оценить проект на самом раннем этапе. Лучше сосредоточьтесь на следующем – сделайте так, чтобы в 90% случаев фактическая метрика вошла в ваша начальный диапазон оценки.
Какие бывают виды оценки?
Быстрая оценка. Делается по одному взгляду на проект. Мы ее очень часто используем для первичной оценки проекта. Как она делается:
Делаем градацию по проектам. Например, 3 градации, у каждой своя вилка и критерии попадания под нее.
При оценке проекта соотносим ее с одной из градаций.
Получаем оценку (оценка этой градации, которая сделана заранее).
Плюс этого подхода в скорости и малых затратах. Минус – это очень приблизительный способ. Но для первого ознакомления с проектом этого бывает вполне достаточно. Еще момент – этот способ практически не требует технической квалификации от оценщика. Его задача – просто корректно соотнести проект с нужной градацией.
Модульная оценка. Вы разбиваете конкретный проект на крупные блоки, модули и отдельно оцениваете каждый модуль. Обычно это делает уже технический специалист, либо менеджер. Здесь, как минимум, нужно детально ознакомиться с концепцией или ТЗ проекта. Модулями могут быть крупные функциональные блоки, которые являются более-менее типовыми. Для таких блоков можно сделать типовые оценки. Например, сделать форум – это N часов (или X рублей). Это немного упрощает оценку.
Эта оценка существенно точнее предыдущего способа и, если у вас одиночный проект, то именно ее лучше всего использовать на начальном этапе. Вы также можете попросить дать оценку у других людей, не всего проекта, а отдельного модуля. Это также позволит вам получить более объективное представление о каждом модуле.
Детальная оценка. Вы разбиваете весь проект на мелкие кусочки – функции и компоненты и детально оцениваете каждый из них. Будет очень хорошо если это будут делать разработчики, и их будет несколько. Это сделает оценку существенно точнее. Параллельно вы можете проработать проект – выявить недостающие нюансы.