Так сложилось, что в этом году, как это ни печально, не состоится Barcamp.lv. А жаль… Во многом жаль из-за того, что на этом баркампе я собирался выступить. Если вы читали недавние мои посты, то содержание доклада вряд ли будет неожиданным, но презентацию, как мне кажется, всё же стоит посмотреть:
Итак, первый раунд мы выиграли — можем отодвинуть другие задачи и взяться за дело. Про технические особенности реализации я особо распинаться не буду — существует множество доступных материалов.
У нас была очевидная цель — получить быстрый результат, чтобы иметь карт-бланш на дальнейшие изменения. Что ж, мы взяли свободно распространяем минифаер, написанный на php, малость обработали его напильником, изменили способ показа баннеров у нас на сайте, внесли еще пару быстрых изменений. По дороге выяснилось, что как минимум в нашем случае minify падает, если ему разом скормить jQuery, jQuery UI и свои скрипты. Что ж, разнесли на 2 блока. Оценка сайта по Yslow выросла с 53 до 68. Не идеал, но для начала — достаточно. Что же теперь? Как говорит Саша Орлов, “снес яйцо — кудахтай”. Итак, надо было показать, что внесены правильные изменения, что мы не зря потратили время, да и вообще молодцы.
Проблема в том, что просто сидеть и ждать результатов несколько… некорректно. Т.е. произошедшие после этого изменения можно списать на что угодно. Как известно “после не значит из-за”. При этом не забудьте, что изменения могут быть как положительные, так и отрицательные, при этом совершенно не связанные с произведенными работами (скажем, начались праздники, и количество заказов упало).
По моему опыту у любой группы технарей есть множество моментов, которые делать хочется, да и нужно, более того, необходимо. При этом приходится регулярно либо проводить изменения “без объявления войны”, либо долго и занудно объяснять начальству/заказчику, далекому от разработки, почему сейчас мы убьем очередные 2 недели на какую-то заумь, смысл в которой очевиден только программистам.
Неспособность объяснить необходимость той или иной штуки так, чтобы это было очевидно не гику — большая беда для разработчиков. Не так давно я смотрел на презентации стартапов в рамках РИТ++, и лишний раз увидел, что люди просто не способны взглянуть на проблему со стороны и рассказать о ней так, чтобы заинтересовать другого человека.
Итак, давайте рассмотрим простую ситуацию — мы в отделе решили заняться клиентской оптимизацией. Нам очевидно, зачем это необходимо. Осталось убедить в этом руководство. А теперь представьте — прихожу я к генеральному директору и говорю: “Дорогой директор, мы решили в нашем перегруженном графике выделить месяц на переверстку сайта и панелей управления, переработку процедуры выкладки материалов на боевой сервер и изменить настройки сервера”. Вопрос будет только один — “зачем?!” И вот тут, если я отвечу что-нибудь в духе “Ну, это уменьшит количество http-запросов, ускорит рендеринг на стороне клиента, плюс файлы будут нормально кешироваться”, то задачу можно считать похороненой — генеральному наплевать на количество запросов к серверу и, отмечу, тут он совершенно прав.
Итак… зачем же мы всё это делаем? читать дальше »
Недавно заказывал очередную порцию книг для отдела. Про пришедшие книги стоит рассказать отдельно (скажем, справочник по MySQL оказался очень приличным), но в ходе розысков, я увидел, что переиздали “Deadline. Роман об управлении проектами“.
Книга очень и очень достойная. Это действительно роман, более того, роман с налётом детектива, настоящий easy reading. О художественных достоинствах можно долго спорить, но в легкой, едва ли не игровой форме обсуждаются основные вопросы, с которыми сталкивается каждый проджект — формирование команды, планирование, взаимодействие с руководством и заказчиками.
Если я не ошибаюсь, до этого было лишь одно издание, общим тиражом 3000 экземпляров. Впрочем, всегда есть возможность скачать книгу в электронном варианте.