В октябре 2010 года Стив Джобс отправил электронное письмо Филу Шиллеру (старший вице-президент Apple по маркетингу) с темой «Топ 100 — А». Письмо содержало план сверхсекретной встречи под названием «Топ 100», которая должна была состояться в начале 2011 года.

Статью с обзором ситуации с микроэлектроникой в России я закончил утверждением, что сейчас в России есть технические возможности для создания любых военных микросхем (если не считаться с ценой). Однако и в комментариях к той статье, и во многих других — всех больше волновал вопрос отсутствия (на уровне погрешности измерений) производства чисто-коммерческих (гражданских) высокотехнологичных продуктов. Этот вопрос волновал и меня, потому я постоянно мучил вопросами всех, кто так или иначе связан с высокими технологиями и бизнесом в России.

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

Под катом попробуем разобраться чем отличаются «высокотехнологичные» компании от «низкотехнологичных», что нужно, чтобы высокотехнологичные компании могли рождаться и выживать, почему с софтом у нас лучше, чем с хардом, с чего начиналась кремниевая долина в США и можно ли её «скопировать», почему Китай всех рвет, а также — окинем взором все, что происходит в Сколково, Роснано, фонде перспективных исследований и приведут ли они к расцвету российских инноваций. Безусловно, я где-то могу ошибаться — буду рад дополнениям в комментариях.

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

Весной 2006 года Кевин Систром стоял за кофемашиной в кафе Caffé del Doge в Пало-Альто, когда к стойке подошел основатель Facebook Марк Цукерберг. Годом ранее Цукерберг уже ужинал с Систромом — он предложил ему уйти с последнего курса Стэнфорда, чтобы разработать фотосервис для Facebook. Кевин тогда отказался. Оставшись в Стэнфорде, Систром разработал приложение Instagram, которое Цукерберг недавно приобрел за $1 млрд. (Сумма поражает, особенно если знать, что у стартапа нет не только выручки, но и модели ее получения. В компании Instagram, возраст которой еще не достиг двух лет, по-прежнему лишь 14 сотрудников.) В итоге Цукерберг все же захватил Кевина в ряды армии Facebook, с чем его и поздравляем.

Если в истории с Систромом Цукерберг сделал ставки и не прогадал, то с сооснователем WhatsApp Брайаном Актоном все сложилось иначе. В 2009 году его не взяли на работу в Facebook, а в 2014 компания покупает WhatsApp за $16 млрд. Как же так получается, что большие и инновационные компании отказываются от перспективных сотрудников (будем называть их гуру или «звездами»), за которых в будущем будут гоняться с утроенной скоростью, предлагая просто сумасшедшие деньги? Ориентация на метрики, а не на результат.

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

После статьи «Управленческие инструменты: 4-фазный алгоритм решения проблем с людьми или «А чего ты хочешь, если ты такой хреновый менеджер?» нам писали: мол, ну так же не бывает, что со всем людьми и во всех случаях этот алгоритм работает? Это правда — этот алгоритм не очень хорошо работает, когда другой человек не видит с вами общего будущего. И/или же хочет вас банально отжать на что-то.

Один из самых полезных управленческих опытов в своей жизни я получил от руководства ремонтом собственной квартиры. На тот момент я уже 4 года работал менеджером — сначала руководил командой по тестированию Java на мобильных устройствах (мы работали с Sun), потом руководил командой в Intel. Я прочел Тома Демарко. Джоэла Спольски, прошел несколько управленческих тренингов. В общем, чувствовал себя очень крутым управленцем. Но это меня не спасло.

Управление ремонтом квартиры требует немного других навыков, тем более когда тебе противостоит опытный прораб. Мой прораб в самом начале сотрудничества применил переговорный инструмент “Формула нужды”, чем и обеспечил себе однозначную и безоговорочную победу.

Сам по себе инструмент достаточно часто применяется в переговорах с заказчиками — прежде всего, ими и применяется. Итак, как выглядит Формула нужды:

Введение

Просматривая ленту, наткнулся на статью Неправильное использование атомов и трудноуловимая бага в VCL. После прочтения возникла мысль описать еще одну проблему в той же самой области, о которой не рассказано в этой статье. Наша команда натолкнулась на нее самостоятельно, потом оказалось, что это уже известный баг VCL. Разработка ведется на Delphi 7, и я не уверен, существует ли ошибка в более новых версиях. Судя по приведенным чуть ниже ссылкам, есть, как есть и исправление. На исправление версии 7 надеяться, по понятным причинам, не приходится.

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

Поиск бага

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

Использование технологии EFI Byte Code (сокращенно – EBC) позволяет создавать кроссплатформенные приложения и драйверы, выполняемые на виртуальном процессоре, реализованном в составе firmware платформы. Архитектура этого процессора определена в спецификации Unified Extensible Firmware Interface. В идеале, EBC-программа должна взаимодействовать исключительно с ресурсами виртуальной машины, системными таблицами UEFI и другими объектами, абстрагированными от аппаратной реализации платформы. На практике, точное следование данному принципу существенно ограничивает функциональность программного продукта. Выйти из положения не потеряв кроссплатформенности можно, если использовать подпрограммы в нативном коде центрального процессора, условно получающие управление в случае детектирования заданной аппаратной платформы.

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

Знакомьтесь, это обычный «литровый» пакет молока:

• Проверка на внимательность: там 900 грамм. Рядом несколько по 950. Но пакет может быть воспринят как литровый.
• Проверка на знание физики. Рядом лежит похожий кефир. Объём измеряется в миллилитрах, масса — в граммах. Плотность кефира трагически выше плотности воды. То есть 900 грамм кефира 3,2% жирности — это примерно 874,5 миллилитров.

Второй пациент:



25 лет гарантии. Круто, правда? Есть одна проблема. Надо сохранять чек. Проверка, опять же, на знание физики. Чек у них печатается на обычной кассовой термоленте (я проверил на месте). У меня в офисе лежит много чеков. Мы их ксерокопируем, потому что через год-два они полностью выцветают. Самый старый чек, который видел коллега, держался 3 года в папке в архиве. UPD: смотрите самый низ топика, Икея ответила.

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

Осторожно, трафик: под катом много находок с фотографиями.

Недавно, когда я изучал досовые бут-секторы, я обнаружил довольно загадочную вещь. DOS распознает, является ли бут-сектор загрузочным, по нескольким критерям, и один из них (странно, да?) — есть ли в первых двух байтах jump-инструкция, которая указывает, соответственно, куда-нибудь за BPB. В модуле MSDISK.INC из MS-DOS 3.21 OAK как раз и происходят такие проверки. Модуль проверяет, начинается ли BPB с прыжка, при этом за верную jump-инструкцию он принимает опкоды EBh (short JMP), E9h (JMP), или 69h. Стоп. 69? Это же IMUL!
Не-а, не IMUL. Комментарий в коде утверждает, что это «direct jump»:

   cmp   byte ptr cs:[DiskSector],069H  ; Is it a direct jump?
   je    Check_Signature                ; don't need to find a NOP
   cmp   byte ptr cs:[DiskSector],0E9H  ; DOS 2.0 jump?
   je    Check_Signature                ; no need for NOP
   cmp   byte ptr cs:[DiskSector],0EBH  ; How about a short jump.
   jne   BadDisk

Хорошо, вот только про 69h в документации 8086 ничего не сказано! Да, в 8186 и далее — это опкод IMUL, но то, что 8086 умеет IMUL — крайне маловероятно. Тем более, комментарий ясно указывает, что это прыжок.

Может быть, на процессорах 8086 69h ведёт себя как прыжок? Вопрос хороший, вот только информации по этому поводу почти нет.

На одном из давних тренингов мы отрабатывали кейс “Сотрудник не присылает вовремя отчеты”. Кейс абсолютно не привязанный к реальной жизни — ведь такого же не бывает, чтобы люди не присылали вовремя отчеты, верно?

И вот одному менеджеру не досталось пары, и я встал играть роль сотрудника. До этого всем пар хватало, поэтому к роли сотрудника я был не очень готов…

Моим собеседником оказался молодой человек, назовем его Егор, технический директор небольшой компании.

Цель кейса — донести до сотрудника обратную связь, что отчеты надо присылать вовремя. Егор начал сразу с места в карьер:

— Александр, как же так, почему Вы не присылаете мне отчеты?

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

— Егор, а чего ты хочешь, если ты такой хреновый менеджер?!

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

— Что значит “хреновый менеджер”?!!! Это недопустимо — так разговаривать с руководством…

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

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

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

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

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

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

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

Джон Кейси (Jon Casey), сотрудник Центра полупроводниковых исследований и разработок IBM

На днях Джон Кейси, сотрудник Центра полупроводниковых исследований и разработок IBM, дал весьма интересное интервью. В нем Кейси сообщил о том, что корпорация IBM ищет достойные альтернативы технологии КМОП и архитектуре фон Неймана, поскольку действие закона Мура все замедляется, и необходимо что-то качественно новое.

Сам Джон Кейси — не человек со стороны, у него весьма высокая квалификация в сфере технологий создания интегральных схем. Кейси принимал участие в некоторых очень интересных проектах, включая один из последних проектов: исследование возможности ухода технологий за пределы закона Мура. Именно эта тема и стала основным докладом Джона Кейси на симпозиуме, который был посвящен отраслевой стратегии Международной ассоциации полупроводникового оборудования и материалов SEMI в Калифорнии (США).

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

Почему ты не можешь дать точную оценку трудоемкости разработки?
Почему ты не можешь завершить все работы в два раза быстрее?

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

AutoCAD начала 80-х

Зум появился очень давно, на заре эры графических интефейсов, с первыми векторными редакторами.
Но с тех пор он не был использован почти нигде, кроме САПР и программ для работы с графикой. Про него вспомнили только когда появились мобильные устройства — на маленьком экране не умещались большие фотки и веб-страницы.
В мобильных интерфейсах зум стал вполне привычным и естественным и продолжает эволюционировать. Но на десктопе зум заброшен и, на мой взгляд, совершенно напрасно. Zoomable user interface (ZUI) даёт ряд преимуществ, позволяющих лучше решить актуальные задачи. Я решил описать эти преимущества по типам зума, с примерами.

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

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

Слышали ли вы когда-нибудь в свой адрес упреки в неконструктивности? Может быть, сами кого-то упрекали? Как вы понимаете, что вот это конкретное обсуждение не конструктивно, а вот это конструктивно?

Если начать думать на эту тему, то тут есть на что потратить пару часов. Эту задачу мы сейчас постараемся облегчить. И в рамках нашей серии статей по управленческим инструментам (ушедшей в отпуск на время новогодних праздников), разберем принципы конструктива, предложенные когда-то Энди Гроувом, одним из основателей компании Intel.

Принципы простые, но объясняют довольно много рабочих и не только рабочих конфликтов. И разобравшись с ними вы:

• Поймете причины поведения своих коллег, руководства и заказчиков в некоторых ситуациях
• Занесете в свой арсенал несколько простых приемов, которые помогут вам легче договариваться по работе
• Сможете абсолютно точно объяснить любому коллеге, что он неконструктивен (и в чем именно), если он действительно неконструктивен

Здесь не будет полюбившихся нам матриц 2 на 2, но пару схем мы разберем.

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

^{Cравните: популярный новостной сайт на Западе и в Китае}

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

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

Сначала немного о фундаменте.
Итак, что же нужно, чтобы в компании была внедрена ERP система? Ну, во-первых в туалетах должно быть чисто. Состояние туалетов — это состояние компании в целом. Вы будете смеяться, но это так и есть. Если в туалетах грязно, то вначале надо решить системные проблемы в компании, а потом уж и за ERP можно браться.