Неспособность объяснить необходимость той или иной штуки так, чтобы это было очевидно не гику — большая беда для разработчиков. Не так давно я смотрел на презентации стартапов в рамках РИТ++, и лишний раз увидел, что люди просто не способны взглянуть на проблему со стороны и рассказать о ней так, чтобы заинтересовать другого человека.

Итак, давайте рассмотрим простую ситуацию — мы в отделе решили заняться клиентской оптимизацией. Нам очевидно, зачем это необходимо. Осталось убедить в этом руководство. А теперь представьте — прихожу я к генеральному директору и говорю: “Дорогой директор, мы решили в нашем перегруженном графике выделить месяц на переверстку сайта и панелей управления, переработку процедуры выкладки материалов на боевой сервер и изменить настройки сервера”. Вопрос будет только один — “зачем?!” И вот тут, если я отвечу что-нибудь в духе “Ну, это уменьшит количество http-запросов, ускорит рендеринг на стороне клиента, плюс файлы будут нормально кешироваться”, то задачу можно считать похороненой — генеральному наплевать на количество запросов к серверу и, отмечу, тут он совершенно прав.

Итак… зачем же мы всё это делаем? Снижение числа запросов? Гм… и что? Ускорение загрузки и рендеринга страниц? Уже ближе, но, если быть кристально честными, нам-то какое дело? Так зачем же?.. Ответ прост и банален — деньги. Мы рассчитываем, что клиентская оптимизация с одной стороны увеличит уровень конверсии, т.е. количество заказов, а с другой стороны — снизит отток клиентов. И вот это уже — довод. Простой вопрос — а чем подтверждается этот довод? Ну что ж… тут вопрос… Те, данные, которые нам доступны, не слишком новы. Но всё же:

• Amazon: 100 ms of extra load time caused a 1% drop in sales. (Source:Greg Linden, Amazon)
• Google: 500 ms of extra load time caused 20% fewer searches. (Source:Marrissa Mayer, Google)
• Google: trimming page size by 30% resulted in 30% more map requests. (Source: Marrissa Mayer, Google)
• Yahoo!: 400 ms of extra load time caused a 5 to 9% increase in the number of people that clicked “back” before the page even loaded. (Source: Nicole Sullivan, Yahoo!)

Итого — “большие мальчики” достаточно давно заметили связь между скоростью загрузки страниц и удовлетворенностью клиентов и своими доходами. В итоге, скажем, Google использует скорость загрузки в качестве доп. фактора при ранжировании. Тот же Гугл вместе с Яху достаточно давно ведет пропагандисткую работу и предоставляет инструментарий для оценки скорости работы сайта и оптимизации.

Итого, делаем простое предложение: давайте мы потратим неделю на первичную оптимизацию, посмотрим эффективность. Я уверен, что затраты на эту работу оправдаются. Чтобы расходы “отбились”, положим, за 6 месяцев, мы должны увеличить количество заказов хотя бы на 0,3%. Что ж, это я точно смогу обеспечить, тут я уверен.

Итак, первый раунд мы выиграли — можем отодвинуть другие задачи и взяться за дело.

© AJAX Planet, 2010. | Постоянная ссылка | Комментарии

Интересна эта тема? Посмотрите архив сообщений по теме Управление проектами.

Книга очень и очень достойная. Это действительно роман, более того, роман с налётом детектива, настоящий easy reading. О художественных достоинствах можно долго спорить, но в легкой, едва ли не игровой форме обсуждаются основные вопросы, с которыми сталкивается каждый проджект — формирование команды, планирование, взаимодействие с руководством и заказчиками.

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

© AJAX Planet, 2010. | Постоянная ссылка | Комментарии

Интересна эта тема? Посмотрите архив сообщений по теме Управление проектами, Книги.

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

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

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

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

Бороться с этим можно только обязательным обучением (при чем не для проформы, а нормальным, чтобы эти дятлы что-то поняли) и тупой грубой обязаловкой сверху. Не занесены клиенты? Депремирован.

Так к чему я это? Ах, да, у меня из плана проекта вычеркнули обучение и порезали время на перенос данных.

© AJAX Planet, 2006. | Постоянная ссылка | Комментарии

Интересна эта тема? Посмотрите архив сообщений по теме Управление проектами.