Руслан Раянов - Как создать продающий сайт с нуля Страница 8

Здесь следует упомянуть о так называемом конусе неопределенности. Это понятие используется при оценке проекта. В начале проекта, когда у вас есть только смутные представления о том, как будет выглядеть и функционировать проект, точность оценки оставляет желать лучше. И это объективное обстоятельство, поскольку на этом этапе у вас мало информации для более точной оценки. По мере детализаций требований, точность оценки возрастает.

Рис. 4.1 Конус неопределенности – оценка проекта уточняется по мере движения проекта к финальной точке.

Как видно из рисунка, в начале проекта разброс может составлять от 0.25х до 4х, т.е. диапазон составляет 16х.

Нет смысла требовать от исполнителей точную оценку проекта на самой начальной фазе. Этим самым вы закладываете мину замедленного действия, которая скажется в более поздних стадиях проекта, когда станет ясно, что реальность очень сильно отличается от начальной оценки. Вместо этого вы должны как можно сильнее сузить основание конуса за счет точных, четких требований и тесного взаимодействия с исполнителями.

В моей практике был такой случай, когда заказчик поставил задачу очень обобщенно, в виде концепции без уточнения требований, и мы были вынуждены делать проект по таким обобщенным требованиям. Все это негативным образом сказалось, на конечном продукте, поскольку ожидания клиента в деталях отличались от реализованного продукта. Потребовались дополнительные доработки, конус начал сужаться поздно, уже на стадии разработки. Все это привело к увеличению бюджета проекта.

Сужайте основание конуса неопределенности как можно быстрее.

На данный момент у вас уже есть основная информация по сайту, также вы провели некоторые маркетинговые исследования в первых двух главах, и у вас есть поставщики различных услуг, необходимых для создания сайта. В следующей главе вы узнаете как вести проект, на что необходимо обращать внимание в первую очередь при выполнении проекта и как сделать так, чтобы проект укладывался в заданные сроки.

Глава 5. Работа над проектом

Проект начинает набирать свой ход. Появляются какие-то промежуточные результаты в виде различных графических файлов и программных модулей сайта. Вы составили совместно со своими поставщиками услуг хорошие, четкие технические задания и уже кажется, что ваша задача, как организатора всего процесса, в большей степени выполнена.

То, без чего любой проект не проживет долго.

Подобная расслабленность нередко приводит к печальным результатам. На данном этапе создания сайта любимым вашим словом должно быть слово “КОНТРОЛЬ”. Вы должны жестко контролировать процесс развития проекта. Если один из подрядчиков начинает давать слабину, вы должны вовремя предпринять меры и нейтрализовать проблему. В противном случае ваш проект будет все сильнее и сильнее выбиваться из графика. Это связано с тем, что обычно работы по сайту взаимозависимы.

Допустим, если веб-дизайнер сдает работу на две недели позже, то верстка и проработка интерфейса сдвигается также на две недели. Это может негативно сказаться на разработке движка сайта поставщиком программного кода, т.к. у них есть свои планы, которые приходится адаптировать в связи с опозданиями по данному проекту. Задержки на фазе разработки тормозят работу продвиженцев и специалистов по рекламе. Поэтому обязательно “закручивайте гайки” вовремя.

Контроль - основа качественного менеджмента проекта

Как осуществлять контроль? Должен ли я разбираться в технических деталях, чтобы контролировать процесс? На мой взгляд, это было бы хорошо, но не является необходимым. Вы, как руководитель проекта, должны определить метрики проекта, которые позволяют определить слабые места. Например, для разработки сайта – это процент разработанных модулей для сайта от всего количества необходимых по ТЗ модулей. Для продвижения – это, в первую очередь, позиции в поисковых системах по ключевым запросам. Если эти позиции постепенно улучшаются, то это значит, что все идет хорошо. Для контекстной рекламы получается совсем просто – это количество целевых посетителей и конверсия. Например, если у вас конверсия составляет 0.5%, то наверно пора что-то делать. Конечно, если только вы не продаете дворцы в Шотландии. О конверсии вы поговорим в одном из бонусов к этой книге.

Организация проверок

Конечно, проверки большинство людей не любит. Ни проверяемые лица, ни проверяющие.

У проверяемых часто возникает эффект “честного водителя”, когда проезжая мимо поста дорожной автоинспекции он чувствует некоторое волнение, мини-стресс, хотя при этом понимает, что ему нет повода волноваться. Плюс к этому – в этом можно увидеть некоторое ограничение своей свободы, что обычно не нравится людям.

Проверяющим хочется верить, что все идет хорошо, и они не желают разбивать свою иллюзию. В случае выявления проблем придется проводить ряд дополнительных мер и процедур по нейтрализации последствий. Лично мне кажется, что при проверках необходимо помнить один очень важный факт, который позволит вам сэкономить много денег. Ошибки надо исправлять на ранней стадии.

Стоимость исправления ошибки на ранней стадии несоизмеримо ниже, чем на поздних стадиях проекта. Особенно это четко прослеживается на этапе выработки требований и составления ТЗ. Если вы заложите какое-то неверное требование, то исправить эту ошибку перед началом работы над сайтом не составляет труда. Однако, чем дальше вы будете продвигаться по проекту, тем больше будет стоимость исправления этой ошибки.

Приведу пример: допустим, вы решили сделать дизайн с фиксированной шириной в 1000px (наиболее распространенный вариант на сегодня). Вы утвердили все ТЗ, дизайнер сделал макет, вы его утвердили. На данный момент стоимость исправления этой ошибки возросла, но не сильно, т.к. при исправлении придется только оплатить дизайнеру доработки макета страниц сайта.

В случае если сайт уже сделан разработчиками и макет сверстан, то стоимость еще возрастает, поскольку придется делать доработки на нескольких уровнях – дизайн, верстка, возможно JS программирование.

Допустим, сайт уже работает пару лет, и вы решили изменить это требование, например, уменьшить ширину до 900px. Тогда цена исправления становится еще больше, т.к. после исправления необходимо весь сайт протестировать на предмет проблемы с корректным выводом контента.

Ошибки надо исправлять на ранней стадии.

Делайте свои проверки регулярными и по четким метрикам. У вас может быть свой набор метрик. В случае проблем выясняйте причину и, что более важно, как поставщик будет ее решать.

Примечание. По возможности не меняйте поставщиков на время проекта. Это довольно негативно сказывается на качестве проекта и на его конечной цене. Прибегайте к этому только в крайнем случае, когда остальные методы воздействия уже не срабатывают. Надеюсь, что вам это не понадобится, поскольку мы довольно скрупулезно подошли к выбору поставщиков.

Также хорошим приемом обращения с поставщиками является брать с них некоторые личные обещания. Это подстегивает их делать работу в срок, поскольку невыполнение обещаний негативно влияет на репутацию. Но при этом помните, что если вы выдавливаете из поставщика нереальный срок исполнения и обещание сделать задачу к заданному сроку – вы тем самым подрываете ваши взаимоотношения и весь проект в целом. Делайте это очень осторожно и в умеренных дозах.

Взаимодействие для экстремалов

Если у вас довольно много проектов, и вы имеете хорошую команду, то можете попробовать совместить закон Паркинсона и закон Парето.

Закон Паркинсона гласит, что работа заполняет все отведенное ей время.

Закон Парето говорит нам о том, что 80% всей важной работы выполняется 20% сотрудников.

Есть много вариаций на тему этих законов, но для нас сейчас важно не это. Одним из советов Стива Джобса по разработке было: “Разрабатывайте рывками. Делайте за месяц то, что в обычном планировании может занять полгода”.

Закон Паркинсона + Закон Парето = небольшое технологическое чудо

Вы можете попробовать этот подход. Запланируйте под определенный проект максимально краткий срок. Тут конечно есть множество ограничений, и с этим надо экспериментировать, прежде чем внедрять в большой проект. Если вы это примените к части некоторого большого проекта, то в итоге это может сильно повысить риски выхода всего проекта за рамки времени и бюджета. Это возможно провернуть только с проверенной командой, которая знает правила игры. И эти люди должны быть из первых 20%, т.е. это должны быть самые эффективные профессионалы в своих областях.