Представляю вашему вниманию перевод статьи под названием "Better together; the practice of successful creative collaboration" от Stefan Klocek. Перевели специально для пользователей Хабрахабра с одобрением компании Cooper.

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



Двое (или больше) творческих людей могут использовать эти добродетели, если будут хорошо играть в команде. Практика “парного дизайна”, используемая в Cooper, взрослела больше чем десять лет, и развивается вместе с ростом компании, формируя новые пары, в которых дизайнеры учатся друг у друга каждый день. Хотя не существует никакой магической формулы, но большинство самых успешных совместных работ такого плана на нашей памяти обладали на удивление схожими характеристиками.

Запуская наш проект в регионе, где часовой пояс был отличен от московского, мы столкнулись с проблемой разницы местного времени и времени сервера (московский часовой пояс). Надо сказать, что логика работы проекта сильно привязана к датам и времени и оставлять дату в московском времени было нельзя. Практически все даты у нас хранились в MySQL базе в формате DATETIME, что, как в последствии оказалось, не лучшим образом подходит для организации работы приложения в нескольких часовых поясах.

Вместе с ростом мобильного интернета растёт и необходимость оптимизации скорости работы мобильных сайтов. Даже самые современные смартфоны на Android, iOS, WebOS, BlackBerry OS и др. обладают процессорами с частотой не более 1Ghz, а скорости 3G можно считать достаточно медленными (скорость загрузки в 3 раза меньше DSL).

Мобильные устройства унаследовали проблемы “больших” машин: от количества http-запросов до эффективности работы JavaScript.

Особенности мобильных устройств

Кроме того, что они часто помещаются в карман и их легче потерять, существует несколько ключевых отличий мобильных устройств по отношению к десктопам:

• маленькое разрешение экрана;
• медленные соединения;
• ограниченный размер кэша;
• много различных устройств и форм-факторов;
• низкая мощность процессоров;
• широкая поддержка HTML5;
• относительно новые браузеры (в этом мире не знают о IE6).

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

1. Выучить новый язык программирования

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

Среди языков программирования отличный познавательный эффект и наверстывание опыта дают: Lisp (или Scheme), Форт, PostScript или Factor (стековые языки программирования), Haskell (строго типизированный, чистый функциональный язык) либо OCaml (объектно-ориентированный язык функционального программирования), Пролог (логическое программирование), Erlang (отличные паралельные вычисления).

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

Этот дайджест основан на моем приличном опыте мониторинга и анализа сайтов на рынке веб-разработок (исследования конкурентов в ADV, мониторинг и анализ участников «Тэглайн», проведение заказных аудитов для студий и пр.).

Я попытался систематизировать основные «ляпы» и упущения по нескольким основным категориям, на которых и остановлюсь подробнее:

• Ошибки позиционирования;
• Ошибки расстановки приоритетов;
• Неправильная презентация компании и услуг;
• Неправильная презентация портфолио и кейсов;
• Ошибки в коммуникации с заказчиком;

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

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

Поехали.

Гибкие и «жесткие»

Есть гибкие методологии разработки (Agile), такие как Scrum, простые и постигаемые за пару дней. А есть «жесткие», увесистые, требующие многомесячного погружения, такие как RUP.

Гибкие методологии убеждают нас «поверить», что из-за того, что требования постоянно меняются, можно к черту отказаться от многолетнего опыта разработки программного обеспечения, впитанного классическими методологиями, тем же «водопадом», все решительно упростить и броситься в объятья «коммунистической» свободы, честности и равенства.

А чего бояться-то? Сумасшедшие бородатые специалисты говорят о процессах, артефактах, матрицах зависимости (Requirements Traceability Matrix) — а мы в рубахе, босиком, раз и… запрограммируем любой интернет-проект за 3 спринта! Ура, товарищи, к победе.

Так вот, «упрощение», предлагаемое гибкими методологиями, очень условное и коварное. «Расслабились» с одной стороны, придется хорошенько поднатужиться с другой.

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

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

Люди сидят, молчат и, молча, обижаются. А потом, когда предел ожидания достигнут, они вместо того, чтобы придти ко мне и рассказать о проблеме, также молча идут в соседнюю фирму на собеседование.

Дальше текст немного в «чёрном» стиле Славы Панкратов (case), но это нынче модно. Я надеюсь, вас не смутит обращение на «ты», поскольку оно лучше передаёт эмоциональную составляющую и смысл статьи.

Представляю вашему вниманию перевод статьи под названием "Fundamental Guidelines Of E-Commerce Checkout Design" от Christian Holst. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением издания Smashing Magazine.

Грустная статистика систем электронной коммерции — согласно последним исследованиям, по крайней мере 59,8% потенциальных покупателей покидают сайт на этапе оформления заказа и его оплаты (у разных исследований разные показатели — от 59,8% у MarketingSherpa до 83% у SeeWhy).

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

Не так давно, а именно в октябре 2010 года, компания Zend немного обновила систему сертификации PHP5 инженеров. Так, если раньше тестирование проводилось по версии 5.1, то теперь проводится по 5.3 (привет namespaces, late static bindings и замыкания). Были переформированы темы тестирования — вместо 12ти прежних, теперь их 10. И что самое главное, из Zend маркета убрали подготовительные тесты. Раньше их можно было приобрести в количестве 1, 5 или 10 штук за относительно скромные деньги (10 стоили порядка 22$). Сейчас же вместо них за довольно-таки нехилую сумму в 1000$ можно приобрести так называемый Test Prep: Zend PHP 5.3 Certification Training (подготовительный online-треннинг для продвинутых php-программистов) и ваучер на прохождение тестирования. Кстати, о ваучере… если для версии 5.1 он стоил 125$, то теперь цену подняли до 195$.

Буду собирать тут первоапрельские шутки веб-разработчиков за 2011 год.
Если хотите найти их самостоятельно — лучше не заходите в пост.

Архитектура и платформа проекта Одноклассники

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

Чтобы ускорить и стандартизировать процесс расчета стоимости разработки сайтов, мы, несколько лет назад, внедрили простую excel-табличку, которой пользуемся до сих пор. Возможно, она и вам послужит на пользу. Вот краткое описание процесса расчета:

Любой проект по разработке — это время команды, которое мы продаем. Значит, менеджеру, который делает предложение клиенту, нужно получить часы с разбивкой по видам деятельности и этапам, потом перевести их в деньги. Для этого мы делаем табличку (готовый пример ниже), в которой:

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

Первая часть материала.

Во второй части мы поговорим о презентации предложения, подведении итогов и всяких полезных советах.

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

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

Итак, сегодня я хотел бы поговорить непосредственно о самом процессе продажи в веб-студии, а именно – об участии в тендере на разработку сайта. Даже когда заказчик не объявляет о проведении тендера в открытую, в подавляющим большинстве случаев вы все равно будете соревноваться с другими компаниями, в которые был отправлен запрос – вариант «скрытого тендера».

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

Давайте разобьем процесс организации продажи на основные этапы, а потом подробно обсудим каждый их них:

1. Брифинг, уточнение задания;
2. Подготовка и состав предложения;
3. Конкурентная разведка;
4. Презентация предложения;
5. Подведение итогов и «after party».

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

В догонку к посту про макет бизнес модели, не менее полезный «самый короткий в мире маркетинговый план» (так его назвал автор, Келли Одел).

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

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

Введение

Все началось с того, что я стал системным администратором у одного провинциального Интернет-провайдера. Помимо администрирования различного рода ресурсов, мне в присмотр достался один молодой, но бурно развивающийся ресурс. Ресурс представлял из себя классический LAMP проект. Сайт, на котором генераторами контента являлись обычные пользователи.
* К слову, в то время я ничего не понимал в *nix системах, хоть и все сервера которые мне достались, были именно на нем, разбирался я во всем этом достаточно быстро.

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

В 1983 Стив Джобс сумел переманить Джона Скалли из Пепси в Эппл одним из самых известных высказываний в бизнесе: «Ты хочешь до конца своих дней продавать газировку или хочешь попытаться изменить мир?»

Джобс и Скалли совместно управляли Эппл, смешивая передовые технологии (первый Мак), прорывную рекламу (известнейший ролик 1984 года) и дизайн высшего класса. Но вскоре отношения испортились, и сейчас Скалли больше известен как человек, потребовавший отставки Джобса после битвы в совете директоров за контроль над компанией.

Сегодня Скалли впервые публично говорит о Стиве Джобсе и секретах его успеха. Это первое интервью Скалли о Стиве Джобсе после того, как в 1993 он был вынужден покинуть компанию.