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

«– Э-э! – запротестовал Ондатр. – Прошу немедленно отколдовать мне книгу обратно!
– Сделанного не воротишь! – сказал Волшебник. – Но вы получите новую книгу! Извольте!
– “О нужности всего сущего”, – прочел Ондатр. – Но ведь это же совсем не та книга! В моей трактовалось о тщете всего сущего.
Однако Волшебник только расхохотался.»
Туве Янссон, «Шляпа Волшебника».

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

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

Мы это называем Продуктивное Сообщество.

Оно состоит из четырех компонентов.

1. Люди. Первая и самая главная компонента. Если вы строите внутрикорпоративное сообщество, это ваши руководители, менеджеры среднего звена, рядовые сотрудники, удаленные сотрудники, рабочие на производстве и так далее. Если вы считаете, что ваша организация — это больше чем ее персонал, то в сообщество входят ваши партнеры и клиенты.
2. Цель. Поскольку мы говорим не о публичных сообществах, а корпоративных, то цель должна удовлетворять оба субъекта корпоративных коммуникаций – человека и организацию. Поэтому цель должна быть сформулирована как для организации, так и для каждого участника сообщества.
3. Место. Вот тут уже и появляется онлайн площадка, которая может объединить людей так, как это нельзя было сделать обычными средствами – командировками, телефонными звонками, конференц-залами, переговорными комнатами. В качестве площадки выступают корпоративные порталы и корпоративные социальные сети.
4. Первые три компонента формируют онлайн сообщество. Мы называем его Продуктивным Сообществом в том случае, если
   • организация получает от онлайн сообщества пользу и;
   • люди в сообществе получают пользы больше, чем лично сами в сообщество привносят.

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

Владимир Иваница Facebook | LinkedIn

ссылка на оригинал статьи http://megamozg.ru/post/20802/

Согласно проведенному ВЦИОМ опросу, более половины опрошенных россиян (55%) считают возможным предсказывать будущее, когда как только 38% в это не верят. Оставшиеся 7% респондентов не определились.

Двадцать пять лет назад, в 1990 году, на этот же вопрос утвердительно ответило всего 43% респондентов, 21% отрицательно, а 36% опрошенных не могли дать определенного ответа. В тоже время, уменьшилось число скептиков, считающих, что люди не могут обладать колдовскими способностями и наводить порчу. Утвердительно на вопрос о существовании колдунов и ведьм в 1990 году ответило 37% респондентов, в 2015 — 48%.

По данным ВЦИОМ видно, что в целом, относительное количество верящих в сверхъестественное снизилась за счет того, что «не определившиеся» пополнили ряды скептиков, но, как видно из приведенных выше цифр, в абсолютном исчислении потенциальных «клиентов» колдунов и ведьм стало больше.

Больше всего верящих в сверхъестественное среди женщин (58%), когда мужчины не так доверчивы (36%). Также больше верят в паранормальное жители малых городов (50%), тогда как жители столиц более скептичны (38%).

В приметы верит половина жителей (50%), но женщины в два раза чаще (62%), чем мужчины (36%).

Вера россиян в астрологические прогнозы осталась на уровне начала «нулевых» (33% в 2000 и 31% в 2015, среди женщин – 41%), но уверенность в астрологах в целом пошатнулась: доля сомневающихся в правдивости прогнозов возросла с 56% до 62%.

Пошатнулась и вера в «целителей». Доли тех, кто верит в возможность лечения гипнозом или биополем сократились с 63% до 41% и с 49% до 35% соответственно. Нынешняя молодежь относится к этому более скептически, чем те, кто видел «заряжание» банок с водой у телевизора.

Наибольшее недоверие у россиян вызывает возможность общения с мертвыми при помощи спиритических сеансов, но и тут все плохо: с 1990 доля верящих в возможность «позвонить на тот свет» возросла с 10 до 16% по сравнению с 1990 годом.

Полная таблица с результатами опросов ВЦИОМ за 1990 и 2015 годы

Источник: ВЦИОМ

ссылка на оригинал статьи http://geektimes.ru/post/265032/

Организационные и процессуальные вопросы иногда создают проблемы и мешают их исправлять. Мартин Л. Эббот и Майкл Т. Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические сбои в малых, средних и больших product-группах. Этот список был сформирован на основе их опыта, а также в ходе коммуникаций с клиентами и лег в основу их первой книги.

Архитектурные ошибки

1. Проектирование реализации, но не поиск архитектурного решения

Какие из следующих подходов вы бы использовали для описания архитектуры своего продукта?

Вариант А: «Мы Java-магазин, работающий на GlassFish, Apache Felix с MySQL и СУБД MongoDB».

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

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

2. Проектирование без расчета на ошибку

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

Гибель «Титаника» — один из самых известных примеров ошибки проектирования, стоившей целого проекта: отсеки корабля не были полностью изолированными, и когда корабль дал крен на нос, вода просто переливалась поверх переборок, пока не залила всё

3. Вертикальное масштабирование вместо распределения нагрузки

Многие продукты все еще полагаются на реляционную базу данных (MySQL, Oracle, SQL Server и т.д.) в качестве основного хранилища. Вместо сегментирования клиентов по множеству небольших баз данных (каждый хостинг с несколькими клиентами для повышения эффективности затрат) многие компании по-прежнему полагаются на дорогое и высокопроизводительное оборудование для масштабирования монолитной системы.

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

4. Использование неверных инструментов

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

Организационные неудачи

5. Разделение по функциям

В прошлом, когда мы создавали и продавали программное обеспечение, роль функциональных менеджеров заключалась в полной изоляции функциональных отделов таким образом, чтобы нейтрализовать все отвлекающие факторы и позволить максимально сосредоточиться на выполнении задачи. Было хорошо, когда каждая команда имела узкоспециализированную направленность, а результат работы передавался на линию сборки. Сегодняшние SaaS-компании производят услугу, и изменения в решение вносятся раз в две недели, а иногда и несколько раз в день. Это обязывает product-менеджеров говорить с инженерами чаще, а инфраструктурных инженеров реагировать еще до начала кодирования. Функциональная организация иногда приводит к снижению качества, медленному выходу на рынок, низкому уровню инноваций и конфликтам между функциональными командами. Лучшие команды сегодня — это многопрофильные, автономные и контролирующие сервис от зарождения идеи до поддержки (по дизайнерскому принципу Уильяма Макдоноу «от колыбели до колыбели» для развития услуг). Если вы сомневаетесь в этом принципе, спросите себя: «Что мы делаем в период кризиса?». Почти всегда ответ будет следующий: «Собираем людей из разных команд, закрываем их в комнате и просим, чтобы они решили проблему». Если это важно в кризис, то почему мы не делаем этого каждый день?

6. Слишком большие команды

Еще одна важная ошибка в масштабировании организации — наличие излишнего количества людей, работающих с одним кодом. Когда команда составляет более чем 15-20 инженеров, связи между ними и координация начинают страдать. Разногласия возникают в планировании ресурсов, субординации и принятии решений. Эти конфликты занимают отведенное на производство нового функционала время, что снижает ценность продукта для клиентов.

Изоляция неисправностей в службах (см. п. 2 про архитектуру) может создать естественные разделения в продукте, которые нейтрализуют эти конфликты. Хорошо, когда команда отвечает за несколько служб (логин, регистрация, поиск), но две команды не должны быть в ответе за одну и ту же службу.

7. Неумение ухаживать за своим садом

Хорошие руководители всегда засеивают, поливают и пропалывают свой «сад» сотрудников: привлекают новые таланты (посев), развивают членов команды (полив), а при необходимости позволяют им уйти (прополка). Для лучшего результата необходимо постоянно оценивать свою команду. Нам нравится анализировать производительность работника по трем направлениям: мастерство, рост и поведение. Категория умения — это то, насколько хорошо они знают и выполняют роль, для которой были наняты.

Если это Java-разработчик, насколько хорошо он кодирует на Java? Категория роста — имеют ли коллеги возможность выйти за пределы их нынешней роли. Готовы ли некоторые из них стать старшими разработчиками? Способны ли они быть архитекторами? Хотят ли и в состоянии руководить? Последняя категория — поведение. Насколько поведение соответствует культуре компании? Эта часто упускаемая из виду категория оказывает наибольший негативный эффект на команду в целом. Сотрудник может быть отличным разработчиком Java и лучшим в мире архитектором масштабируемых систем, но если он демотивирует или мешает остальной части команды, от него нужно избавляться как от сорняка.

Сбой процесса

8. Неспособность учиться

Пророческая фраза Сантаяна «Кто неспособен учиться на ошибках истории, обречен повторять ее» — верна для организаций и продукции. Сервис оказался недоступен в результате сбоя, и если вы хотите только восстановить его работоспособность, то упускаете потрясающую возможность сделать выводы и научиться новому. Каждую неудачу следует рассматривать как повод больше не повторять ошибок прошлого. Требуется самодисциплина, чтобы потратить время и провести тщательное расследование. Если считаете, что причиной отключения вашего сервиса был аппаратный сбой, вы точно промахнулись. Продолжайте задавать вопрос «Почему?», пока не обнаружите основные причины в архитектуре, людях и процессах.

9. Вера в Agile как в панацею

Гибкая методология разработки — великая вещь, но ее использование не решает проблем со структурой команды (см. пункты 5 и 6 в разделе неудач с организацией) или бизнес-задачами, такими как коммуникации между продуктовым и торговым отделом. Понимание Agile как части бизнес-процесса, а не просто теории разработки программного обеспечения очень важно для достижения успеха. Наконец, Agile может исправить часть проблем, для решения которых она предназначена. Ожидать от нее гарантии получения конкретных результатов в конкретные даты аналогично ожиданиям, что плотник починит ваш санузел (см. п. 4 в архитектурных ошибках).

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

Если ваша компания зависит от системы, выполняемой раз в год, например, в кибер-понедельник, то вам необходимо направить все средства на проведение нагрузочного тестирования производительности. Однако, проблема проверки в том, что она проводится на предполагаемых действиях пользователей. Это довольно эффективный способ тестирования, если ПО не меняется. Но в большинстве компаний программное обеспечение меняется часто, а следовательно, часто меняется и поведение клиентов. Клиенты запускают более тяжелые отчеты или делают в два раза больше запросов, если вы измените цвет кнопки поиска. Иначе говоря, их поведение отчасти непредсказуемо. И поскольку тестирование сравнивает текущую версию с базовой, подумайте, как некоторая промежуточная версия будет соотносится с последней? Не следует верить, что результаты тестирования покажут все возможные сбои. Вместо этого, разделение клиентов на зоны изоляции (см. пункт 2 в проблемах с архитектурой) поможет выкатить обновление для небольшой группы пользователей и использовать фактическое поведение клиентов на новом программном обеспечении для проведения тестирования.

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

• правильно подобранные и применённые инструменты и методологии;
• грамотный менеджмент в команде;
• опора на полученный ранее опыт.

Достаточно ли такой триады для успеха софтверного продукта?

Предыдущие посты:

• Проектирование программного обеспечения
• Разработка программного обеспечения: этапы и принципы
• Поддержка программного обеспечения

ссылка на оригинал статьи http://habrahabr.ru/post/269861/

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

На форуме «Открытые инновации» на стенде Фонда помощи слепоглухим представили два прототипа: перчатка для передачи и получения сообщений с помощью мессенджеров и рукав — только для получения. Технологии используют шрифт Брайля.

Разработчик перчатки показывает, как передавать букву «А»

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

Если мы хотим передать букву «А», то мы прикасаемся средним пальцем к ладони, а затем большим пальцем касаемся указательного — завершая набор. Буква «Б» — одновременное или последовательное касание среднего и указательного пальцев к ладони, затем — завершения набора касанием большого и указательного пальцев. Обучение этому методу слепоглухого, знающего шрифт Брайля, составляет двадцать-тридцать минут. Я, не знаю шрифта, за несколько секунд начал отправлять сообщения типа «АБ», а затем случайно обнаружил запятую и букву «Ц».

Для получения сообщений использованы вибромоторы с другой стороны перчатки. Суть та же: буква «А» — вибрация на среднем пальце в районе ногтя и завершение передачи буквы вибрацией на тыльной стороне ладони.

Неофициальное название этого рукава — «Рукав Гнитько», по имени Ксении Гнитько, создавшей его. Шесть вибромоторов отображают шрифт Брайля на руке носителя.

ссылка на оригинал статьи http://geektimes.ru/post/265030/

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

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

Среди популярных сервисов подкастов можно выделить такие, как iTunes и Soundcloud например, или русский сервис PodFM. До последнего времени iTunes занимал лидирующие позиции за счет огромной базы подкастов, за счет популярности iPhone, iPod, стремительного взлета Apple Music и большого размера экосистемы Apple в целом.

Однако теперь некоторые стриминговые сервисы пытаются переломить ситуацию.

Компания Google 27 октября анонсировала поддержку подкастов, которая через некоторое время появится в музыкальном сервисе Google Play Music. На данный момент этот раздел сервиса только начинает наполняться и пока недоступен для слушателей.

Google договорилась о сотрудничестве более чем с десятком популярных подкастеров и провайдеров шоу. Подкастеры из США уже получили возможность самостоятельно загружать свои подкасты по ссылке play.google.com/music/podcasts/publish.

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

Другой стриминговый сервис – Deezer – сделал серьезный шаг в направлении подкастинга еще в 2014 году. Тогда он приобрел компанию Stitcher, предоставляющую подкасты радиопередач. С тех пор количество подкастов Deezer увеличилось до 20 000. А в минувший четверг, 29 октября 2015 года, представители сервиса заявили, что у Deezer появилось еще 20 000 подкастов.

Сервис работает в более чем 180 странах и предлагает подкасты на разных языках. У Deezer есть договоренности о трансляции подкастов с NPR, Financial Times, Panoply, WNYC, This American Life и CBS Radio News. Теперь в список партнеров добавятся talkSPORT, Bayerischer Rundfunk, France 24 и Braincast. Сервис запускается на пяти новых рынках – в Германии, Бразилии, в Мексике, Испании и Колумбии.

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

Ранее, 15 октября, Deezer подтверждал, что намерен выйти на IPO. Руководство компании планировало продать более 8 миллионов акций. Предполагалось, что с помощью IPO Deezer сможет заработать примерно 330-414 миллионов долларов. Компания планировала IPO, невзирая на крупные финансовые потери, которые за последние 3,5 года составили 87 миллионов евро.

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

К сожалению, в Deezer не раскрывают детали стратегии и не объясняют, как сервис будет сокращать свои убытки. Не сообщается также, как Deezer будет бороться за свою аудиторию с конкурентами, будет ли отвоевывать аудиторию у Apple.

Правда, каким образом будет ее отвоевывать Google – тоже пока не известно.

ссылка на оригинал статьи http://megamozg.ru/post/20800/