По моему опыту у любой группы технарей есть множество моментов, которые делать хочется, да и нужно, более того, необходимо. При этом приходится регулярно либо проводить изменения "без объявления войны", либо долго и занудно объяснять начальству/заказчику, далекому от разработки, почему сейчас мы убьем очередные 2 недели на какую-то заумь, смысл в которой очевиден только программистам.

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

Итак, давайте рассмотрим простую ситуацию -- мы в отделе решили заняться клиентской оптимизацией. Нам очевидно, зачем это необходимо. Осталось убедить в этом руководство. А теперь представьте -- прихожу я к генеральному директору и говорю: "Дорогой директор, мы решили в нашем перегруженном графике выделить месяц на переверстку сайта и панелей управления, переработку процедуры выкладки материалов на боевой сервер и изменить настройки сервера". Вопрос будет только один -- "зачем?!" И вот тут, если я отвечу что-нибудь в духе "Ну, это уменьшит количество 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%. Что ж, это я точно смогу обеспечить, тут я уверен.

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

Запись добавлена 16.04.2010 в 5:52. Автор Boris Bogdanov. Категории: Управление проектами. Комментарии к этой записии можно отслеживать по RSS 2.0. Вы можете оставить комментарий, или trackback со своего собственного сайта.
теги: project management, постановка задачи, переговоры с заказчиком, Управление проектами.

• Роман об управлении проектами
• Давайте провалим проект
• Снес яйцо — кудахтай! Или не забудьте рассказать о сделанном