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

После написания статьи о потребностях «продажников» в CRM, я стал более плотно заниматься этой темой + на мое удивление, мне пришло много предложений от хабраколлег написать такую систему и вместе ее продавать, посмотреть на их, уже готовую CRM-ку.

Напомню, что мои основные требования были: online + удобство + малая цена

Кому интересна тема CRM применительно к небольшим компаниям — мои находки и мысли на этот счет.

Итак, что же такое CRM и кому и зачем она нужна. По сути CRM нужна не только отделу продаж, но и всем сотрудникам компании, которые связаны с работой с клиентами. В больших компаниях (телеком, банки) это такие большие системы как Oracle Siebel, MS Dynamics CRM и прочие монстры. В таких системах помимо автоматизации операционной работы (завести контакты, вести учет переговоров, выставлять счета и заводить кейсы) существует много наворотов типа BI, маркетинговых кампаний или совместной работы.

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

1. База аккаунтов (организаций) и контактов
2. Возможность быстрого доступа к ней лучше online
3. Ведение истории переговоров
4. Напоминалки (типа, через 3 месяца не забыть позвонить клиенту)
5. Ведение протоколов встреч, записи звонков, короче видеть всю историю взаимоотношений

Под катом хорошие варианты:

Позволю себе вольность начать серезную тему с шуточной аналогии, дабы поднять Читатель, Ваше настроение и раскрепостить сознание. Для тех кто в танке не видел классическую сагу *звездные войны* — речь идет об использовании таинственной Силы, о чем шептал призрак Оби Вана Люку Скайуокеру (на фото) и, что в конце концов помогло ему (Люку), используя легкий истребитель, порвать подбить вражескую военную станцию планетарных размеров одной ракетой.

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

Природа одарила человека мощным интеллектом, который представляет модели окружающего мира в серой логике. Представьте, что вы создали объектную модель, коды методов в которой оперируют не черно-белой (ЧБ) логикой (true — false или 1 и 0), a серой, где логическое выражение может иметь значение 0.7 или даже 0.5. И это значение может мутировать, подстраиваться под изменения окружающего мира.

Наши средства для общения, книги, методы обмена идеями сильно отстают от таких моделей — поскольку они используют ЧБ логику.

Серая логика — это мощное оружие против лжи, демагогии и политических игр. Для меня было очень тяжело переключиться от простых ЧБ правил и процессов, с которыми я работал будучи простым программистом. Во «взрослой» жизни ПМ-а все оказалось сложней…

Всем нам знакомо правило первого экрана гласящее «Пользователь не прокручивает страницу, поэтому вся информация должна быть на верху», основано оно на том, что пользователь не использует полосы прокрутки, потому что ему лень.
Ребята в компании cxpartners (Великобритания, Бристоль) решили проверить это утверждение и провели исследование, представляю перевод их отчёта.

Продолжаю публикацию переводов статей Лео Бабауты с сайта mnmlist.com. Предыдущие переводы здесь и здесь.

Мы все спешим. Каждый день.

Многим это нравится. Быть занятым — это, своего рода, социальный статус. Спешащий человек выглядит важным.

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

Перевод шестого поста Марка Састера из серии про качества успешного предпринимателя (предыдущие посты: 1, 2, 3, 4, 5).
__________



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

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

Лукас Дэйли заметил:

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

Для меня в процессе поиска хороших предпринимателей недостаточно найти большую дозу того или иного качества. Как я уже говорил, упорство без гибкости в подходе (способности изменить курс) не дает хорошего результата. Это же относится и к лидеру-вдохновителю, который не способен добиваться результата. Вы наверняка видели таких: они отлично смотрятся на сцене на конференциях, но к этому все и сводится. Перед крупнейшими заказчиками они выглядят достойно, но их приходится прятать от сотрудников, чтобы они не сбили тех с курса своими советами, за реализацией которых они не станут следить. Хорошему лидеру требуется не только вдохновение, но и трудолюбие.

Если вы еще не видели фильм «Непокоренный» (Invictus, есть трейлер), то посмотрите. В нем показаны первые годы работы Нельсона Манделы на своем посту. Он работал настолько усердно, что терял сознание от изнеможения. Его охранники, сотрудники спецслужб, жаловались на недостаток отдыха. А он неустанно защищал и пропагандировал свою позицию.

Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции PHPCONF 2009 8 октября (Web Architect Workshop Day) с мастер-классом «Метод организации репозитория исходного кода». Для выступления были заблаговременно подготовлены презентация, а также текст доклада. Несмотря на отличную организацию мероприятия, для публичного доступа так и не были выложены материалы докладов, входящих в программу конференции. В качестве компенсации я решил таки опубликовать материал, использованный в моем выступлении. Кроме данной статьи, (которая является логическим продолжением предыдущей), посвященной конфигурационному менеджменту, для публичного обозрения доступны слайды презентации.
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.

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

Всегда объясняйте клиенту, зачем вы спрашиваете о бюджете

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

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


Клиент не должен думать, что вы выманиваете у него деньги.

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

Ровно четыре месяца как мы находимся в самостоятельном плавании по волнам собственного бизнеса. Мы как никогда чувствуем себя «в седле» и испытываем огромный душевный подъем. Однако есть сложности, которые приходится преодолевать стартаперу; о них и о своем личном опыте я и хочу поведать.

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

Миф 1. Я создам свое дело и буду полностью свободен.

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

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

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

В голову пришли следующие варианты:

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

1 поле: email
Пользователь оставляет email, id создается автоматически, на email он получает пароль, авторизация либо по ID либо по email, username задается пользователем уже в профиле

+ Черт, это все таки одно поле! По умолчанию может быть сгенерен устойчивый к перебору пароль.
± username свободно меняются, и могут оставаться пустыми. Учитывать пользователей по айдишникам мне не хочется
— ЧПУ приобретают вид ufosite.nl/users/18567, скорее всего пользователь захочет сменить свой пароль. При ЧПУ вида ufosite.nl/users/customusername наступает ад для поисковиков. Строить ЧПУ на основе email, который, к тому же, далеко не все захотят публиковать — это подарок спамерам и ЧПУ становятся не совсем ЧПУ.

Введение

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


Совершенно очевидно, что сжимать сроки до бесконечности невозможно. Существует определённый предел. Например, известным экспертом в области оценки трудоёмкости разработки ПО Стивом Макконнеллом (Steve McConnell) этот порог определён как 25% от исходных оценок (см. мою предыдущую статью).
Но этот топик не об оценках трудоёмкости…
Вот я выше написал «совершенно очевидно...». Думаете, это действительно очевидно? Всем?
Мой недавний опыт показал, что это очевидно далеко не всем. Проект был очень крупный и срок сдачи неумолимо приближался. Было принято решение резко расширять команду, чтобы успеть. Довод про «9 женщин» никто не принял. Команда была расширена и в срок мы всё равно не успели. Можно ли было как-то, кроме как на словах, показать, как будут развиваться события? Вот о том, как смоделировать такую ситуацию, и будет моя статья.

Вступление

Я уже довольно давно читаю Хабр, и много раз видел посты про тайм-менеджмент и про то, как «улучшить свою жизнь за 5 минут». Так случилось, что около полутора лет назад я и сам заинтересовался тайм-менеджментом, и с тех пор постоянно испытываю разные методики в надежде скомпилировать нечто своё, полностью удовлетворяющее моим потребностям. Пару месяцев назад я в очередной раз пересмотрел свой подход к управлению временем, и, кажется, нашёл нечто, асимптотически стремящееся к идеалу :). Именно этой методикой я и хочу поделиться с уважаемыми хабраюзерами в надежде на то, что кто-нибудь сможет почерпнуть из неё что-то полезное.

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



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

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

Некоторое время назад, наша компания — www.eye-tracker.ru — провела тест на главной странице русскоязычного сайта известной CMS Друпал – www.drupal.ru Задачей теста было найти ссылку на демо-сайт этой CMS. В качестве испытуемых бралось две группы по 5 человек – «компьютерщики» и «менеджеры». Обе группы не имели отношения к сайтам и не работали с CMS.

«Лучше на 100% выполнять не очень верную стратегию, чем на 70% верную»

— Выражение одного моего работодателя.

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

Сбалансированная система показателей (ССП), в английском варианте — Balanced Scorecard (BSC). ССП — это механизм последовательного доведения до персонала стратегических факторов успеха, целей компании и контроль их достижения через так называемые ключевые показатели эффективности (КПЭ), в английском варианте — Key Performance Indicator (KPI).(с) wikipedia

Эта система была разработа профессорами Гарвардской школы бизнеса Нортоном и Капланом.

Это целая система управления предприятием, или крупным отделом, которая базируется на следующих постулатах:
1)управлять надо тем, что можно считать
2)Стратегия предприятия может выражаться в количественном выражении очень четко
3)каждый сотрудник предприятия должен знать за какой стратегический блок он в ответе, и зная как это важно для всей компании сильнее замотивирован в выполнении собственного плана

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

Пользователи интернета тратят 80% времени, изучая информацию на «первом экране». Несмотря на то, что прокруткой они тоже пользуются, только 20% их внимания приходится на то, что расположено ниже «первого экрана».

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

Промедление — это то, чем мы занимаемся каждый день:

1. «Мне завтра нужно сдать курсовую, которую я еще не начинал, но, чтобы сконцентрироваться, мне сейчас надо отдохнуть и попить кофе»
2. «Я хочу начать бегать по утрам, но сначала мне нужно сдать сессию и найти хорошую работу, которая обеспечит мне стабильность и уверенность»
3. «Перед тем, как начать работать, мне нужно ответить на 11 писем и поговорить с друзьями по аське о летней поездке в Испанию, чтобы не отвлекаться в течение дня»

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

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

update: Теперь есть электронные версии книг!

Начнём…

Перевод свеженького поста «Questions to ask clients before designing their website» Брайана Хоффа, автора блога «The Design Cubicle».

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

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

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