пятница, 5 сентября 2014 г.

Математики и программисты по Дейкстре

Уже длительное время наблюдал разность между математиками и программистами. Это проявляется как противопоставление самих их представителей («программисты — это всего лишь дискретные математики«, а вот ответку вспомнить пока не получается), в изобретении существующих математических велосипедов программистами, а также незнании ряда базовых или почти базовых вещей за соседним забором. И что относительно меня, то успел побывать существенное время в обеих лагерях.

Сейчас, читая Дейкстру (Programming as a discipline of mathematical nature), обнаружил интересное описание этой разности:

  1. In the standard mathematical curriculum the student becomes familiar (sometimes even very familiar!) with a standard collection of mathematical concepts, he is less trained in introducing new concepts himself.
  2. In the standard mathematical curriculum the student becomes familiar (sometimes even very familiar!) with a standard set of notational techniques, he is less trained in inventing his own notation when the need arises.
  3. In the standard mathematical curriculum the student often only sees problems so "small" that they are dealt with a single semantic level. As a result many students see mathematics rather as the art of organizing their symbols on their piece of paper than as the art of organizing their thoughts.

Не в моем переводе (не с первой попытки нашел на русском):

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

Написано это все в мае 1973 года, и сейчас, с возрастанием сложности систем и с более активной типизацией на прикладной стороне, эта разность стала ещё более явной.


на 18:00
Ярлыки: ,

четверг, 14 августа 2014 г.

Продолжение изучения иностранных языков

Ранее описанный процесс изучения инстранных языков усовершенствовался, и досовершенствовался до того, что сейчас опубликована более продвинутая статья на сайте Gomel in English.


на 18:00
Ярлыки: ,

среда, 13 августа 2014 г.

Астрономия — Фото 2014 — II


на 18:00
Ярлыки: , ,

вторник, 12 августа 2014 г.

Разработчики МПЦ «Ипуть»

Разбирая архивы нашел фото, на котором есть почти все разработчики процессорно-релейной централизации «Ипуть».

Слева направо:

Бочков К. А.
Руководитель проекта, решение всех политических, организационных и стратегических вопросов.
Логвиненко А. В.
Архитектура системы, разработка ядра ПРЦ, общая стратегия доказательства безопасности.
Ермоленко А. В.
Разработка алгоритмов работы станции, интеграция с устройствами и внешними системами ж.д. автоматики и телемеханики.
Кузьмич М. C.
Разработка безопасной системы сетевой передачи данных, разработка АРМа, разработка системы принятия решений.
Сивко Б. В.
Доказательство безопасности устройств связи с напольными объектами, разработка драйвера связи с напольными объектами.
Харлап С. Н.
Испытания системы на безопасность, разработка аппаратной части узлов интеграции с напольными объектами.
Зобов С. М.
Внедрение, испытания, дизайн и наладка системы, разработка алгоритмов работы станции, разработка подсистемы тестирования алгоритмов, электропитание.

Из ключевых не хватает только А. Ковриги, занимавшегося всеми вопросами с точки зрения ж. д. автоматики и телемеханики.

Кроме вышеописанного списка в разработке участвовало и неиллюзороно помогало более десятка других людей. Кроме того, значимые силы были задействованы специалистами КТЦ Белорусской железной дороги.

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


на 18:00
Ярлыки:

понедельник, 11 августа 2014 г.

Парижская школа

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

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

Если рассматривать глобально, то длительное время люди стремились изобразить на холсте реальность (мишки в лесу, натюрморты, портреты, …). Были конечно различия (на Западе как можно идеальнее и красивее, на Востоке изобразить как есть и найти там красоту и пр.), но в общем случае генеральный вектор к реальности был одинаков. Однако после какого-то момента ещё больше приближаться к реальности нет особого смысла. Если можно сделать фото, то зачем перерисовывать то же самое, только вручную? Соответственно, если мы фотографигруем мишек в лесу, то то же самое делать руками бессмысленно. Поэтому если хотим изобразить что-то, то лучше найти что-то более со смыслом (чего трудно в реальности), или сменить акцент. Что в свое время и сделала Парижская школа, выйдя из тупика (который был изображен в виде квадрата Малевича, он же символ конца искусства).

Сейчас пришел к такому выводу, что в ряде других областей наблюдается или наблюдалось такое же явление. Например, в научной фантастике, зародившейся где-то на Ж. Верне и Г. Уэллсе, а в дальнейшем был расцвет в виде т.н. классики (Беляев, Саймак, Бредбери, Хайнлайн). Однако, через некоторое время фантастика попала в кризис, рубеж которого находился где-то в районе Суммы Технологий Лема. Данное явление обсуловлено тем, что в фантастике нужно было успешно совмещать несколько вещей. Во-первых, быть достаточно подкаванным в науке, и разбираться в последних достижениях достаточно глубоко. Во-вторых, эту информацию преобразовывать читателю таким образом, чтобы он все это понял. И в-третьих, находить на этой научном гребне что-то новое, делая шаг вперед. Так как научный разрыв постоянно увеличивался от простых людей, то совмещать все это становилось сложнее и сложнее, и в конце концов фантастика свалилась в миры фэнтези. Таким образом, акцент с реальности сместился в фантазирование, оторванное от реальности.

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

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


на 18:00
Ярлыки: ,

воскресенье, 10 августа 2014 г.

Удобны ли ваши API?

Написанное здесь обусловлено тем, что в последние год-два приходилось сталкиваться наверное раз пять с различными проявлениями в отношении пользователей к API и документации в целом. В данном сообщении в основном все базируется на одноименной статье Стивена Кларка, имеющейся в книге «Идеальная разработка ПО», и в е-виде содержимое на находится. Стивен провел более 10 лет работая над совершенствованием API в Microsoft'е, с 1998-го года, с такими инструментами, как Visual Studio.

Удобство API

Сплошь и рядом попадается ситуация, когда проектирование библиотек, API и т.п. происходит как есть, для себя, по каким-то высшим или подсознательным катеогриям, но без какого-либо обращения внимания на пользователей, их разнообразие и решаемые ими задачи. Так получается, что потери reengineering'a с той стороны либо совершенно не волнуют, либо списываются на глупость или неусидчивость пользователей, и более того, идут аргументы вида «а вы используете неправильно, не ходите туда и не делайте так, делайте как мы».

Цитата С. Кларка:

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

Я не хочу сказать, что у меня не было трудностей с API фирмы Microsoft. Напротив, чуть ли не самые серьезные проблемы, с которыми я когда-либо сталкивался, были связаны с пониманием API библиотек MFC. Но в отличие от ситуации с инструментами, в том, что мне не удается разобраться в правильном использовании VFC, я винил только себя. Ни разу я не подумал, что проблема крылась в проектировании API.

Такая реакция на плохо спроктированные API встречается очень часто. Многие разработчики объясняют возникающие трудности своей неопытностью в обращении с API. Будь у них побольше времени, то они бы во всем разобрались. Я много раз слышал, как разработчики говорят, что им просто не хватает ума для освоения API.

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

Работа с API не представляет собой работу со всем API целиком

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

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

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

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

Разные пользователи

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

Три типа пользователей из статьи:

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

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

В данном случае одно из решений — сценарно-ориентированное проектирование. Так понял, что в данном случае это когда на сооветствющем уровне абстракции готовятся API и документация для соответствующего типа пользователя.

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

Архитектура API и интерфейс пользователю

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


на 18:00
Ярлыки: ,

суббота, 9 августа 2014 г.

Первая публикация с вариантом на английском

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

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

Отпраздновать что ли…


на 18:00
Ярлыки:

пятница, 8 августа 2014 г.

О проблемах менеджмента в 1855-м году

Цитата из произведения North & South, для упрощения из версии Penguin Readers. Здесь Mr Thornton — собственник нескольких мануфактор, буржуй-предприниматель; Margaret — главная героиня. Диалог первый, относительно смысла в начале книги:

(Mr Thornton) 'Yes, the fools are going to strike. They think the cotton trade is as good as it was last year. They want better pay, but because we won't explain why we have refused their demand, and tell them we may have to lower wages, they think we are trying to cheat them.'

'But why can't you explain your reasons?' asked Margaret.

'Do you give your servants reasons for the way in which you spend your money? We manufacturers have a right to choose what we do with it.'

'What about the rights of the workers?' said Margaret quietly.

'I'm sorry, I did not hear what you said.'

'I would rather not repeat it,' she said. 'I don't think you will understand.'

'Please try and explain,' said Mr Thornton, who really wanted to know what she had said.

'I meant that the workers have rights too. Surely they deserve to know why you cannot pay them more.'

Mr Thornton paused for a moment and then said, 'In my opinion, the workers are like children. I do not think we mill owners try to keep them like that — it is just the way they are. They need to be told what to do and, like children, they do not need to be given reasons why.'

В моем переводе:

(Мистер Торнтон) 'Да, эти дураки собираются бастовать. Они думают, что торговля хлопком идет также хорошо, как и в прошлом году. Они хотят большей оплаты труда, но так как мы не будем объяснять почему мы отказываем на их требования, и почему зарплата будет меньше, они думают что нас хотят обмануть.'

'Но почему вы не объясните своих причин?' спросила Маргарет.

'А вы объясняете своим слугам почему и как вы тратите свои деньги? Мы промышленники имеем право делать то, что считаем нужным.'

'А что насчет прав рабочих?' сказала Маргарет тихо.

'Извините, но я не услышал что вы сказали.'

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

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

'Имею ввиду, что рабочие имеют права тоже. И конечно, они заслужили того, чтобы знать почему вы не можете платить больше.'

М-р Торнтон сделал паузу и затем сказал: 'По моему мнению, рабочие как дети. Я не думаю что мы, владельцы, должны обращаться с ними таким образом. Это просто у них такая роль. Им нужно говорить, что делать, и, также как и с детьми, им не нужно объяснять почему.'

И вторая цитата, уже ближе к концу книги:

'My business has failed,' Mr Thornton said, 'and I am looking for a position in Milton where I can experiment with some ideas that I have.'

'What experiments are these?' asked Mr Colthurst respectfully.

'I now believe that an organisation can be much more successful if the employers and workers talk freely to one another and see each other as people. If an employer has a new plan, the workers may not realise how carefully he has thought about it. But if he discusses it with his workers, they will feel they are part of it and will want it to be successful.'

В моем переводе:

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

'А что за эксперименты?' списил мистер Колтурст с уважением.

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

И это при всем том, что не то что современных теорий управления, но даже Юнга и Фрейда ещё нет. А те, кто пуп земли, во многом и ныне там.


на 18:00
Ярлыки: ,

суббота, 19 апреля 2014 г.

Астрономия — Фото 2014 — I


на 18:00
Ярлыки: , ,

пятница, 18 апреля 2014 г.

Carlos Bueno — Mature Optimization

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

Из неё хотелось бы процитировать некоторые вещи.

Сложные проблемы и простые решения

For every difficult problem there is a soliution which is simple, obvious, and wrong.

У каждой сложной проблемы есть простое и очевидное решение… но оно неправильное.

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

Простой и целевой мониторинг

It’s a common mistake to overload your dashboard with too much information. The fanciest hospital monitor can describe something as complex and important as a living being with less than ten metrics. "While the human is operating normally, the heart rate graph should never change drastically, go below 60, or above 100." You can do the same with a computer system. A dashboard is for monitoring, not diagnosis. It’s only job is to tell you that something is wrong, and give a rough clue about where to look next.

Это общая ошибка перегружать ваш мониторинг большим количеством информации. Самый модный монитор в больнице может описать такую сложную и важную систему [как человек] с использованием менее чем 10-тью параметров. "Когда человек в порядке, то его сердечный пульс никогда быстро не изменяется, не уменьшается менее 60 и не увеличивается более 100." Вы можете сделать то же самое с компьютерной системой. Панель мониторинга, а не система, ставящая диагноз. Её задача - говорить что что-то пошло не так, и дать грубое направление того, на что смотреть в дальнейшем.

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


на 18:00
Ярлыки: ,

четверг, 17 апреля 2014 г.

Леви-Брюль — Первобытное мышление

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

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

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

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

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

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

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

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

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


на 18:00
Ярлыки: , ,

среда, 9 апреля 2014 г.

Смерть начальникам!

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

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

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

Flat-флагманами с данной организацией являются Valve , Atlassian и Github. Сложно спорить с компаниями в сотни человек, выпустившими на рынок такие продукты как Half-Life, Steam, Counter-Strike, JIRA, Confluence и GitHub, имеющими в наличии сотни сотрудников и существующих на рынке почти 20 лет.

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

Для движения в эту сторону в ряде компаний сотрудникам позволяется выделать какой-то процент своего времени на свои проекты (например в Google это 20%). Но как другой пример это Valve, где этот показатель составляет 100%, и такая организация для привычных иерархий может видится контринтуитивной. Здесь никто не может заставить работать над каким-то проектом — вы сами себе задаете вопросы над чем хотите работать и приступаете — присоединяетесь к какому-либо проекту или стартуете свой. При этом постоянно имеются сильные проекты, в которые требуются новые люди, и поиск новых людей внутри компании всегда ведется — в случае отсутствия сильных людей или недостатка ресурсов работать всегда есть над чем.

Ощущение того, как работают такие компании и почему они организованы именно так, хорошо передается в руководстве для новичков Valve. Здесь менеджеры полностью отсутствуют как класс. Имеются лиды (lead) проектов, как ответственные за целостность проекта, но это не люди с ролью руководителя.

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

Valve очень долгое время была flat, и её организация такова практически с самого начала. Однако сейчас имеются фирмы, которые провели процесс конвертации из пирамиды в flat. Например компания Treehouse (60 сотрудников) летом 2013-го года превратилась в flat, и есть описание причин и подробностей этого процесса, как в конечном счете компания начала работать.

Следующий пример — компания Crisp, 35 человек, и описание того, как осуществляются решения в их flat-структуре.

И ещё одно сообщение о впечатлении после года работы в Github.


на 18:00
Ярлыки: , ,

четверг, 13 марта 2014 г.

Способы улучшения качества сна от MyZeo

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

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

Основными признаками и целями о улучшения являются: Total Sleep, Deep, REM, Wake и Time to Z. Каждый из факторов имеет свои особенности — способы определения и решения проблемы.

Total Sleep
Общая продолжительность сна. Здесь проблема появляется тогда, когда время, отведенного на сон, недостаточно (дела, внешние факторы, …) либо физиологически спать больше не получается (бессонница). Но это бессонница общей продолжиельности сна, а не его прерывания.
Deep
Недостаток глубокого сна. Если вы не спите днем, то эта фаза сна хорошо выражена в первые фазы цикла (например первые 3 часа ночного сна; здесь темно-зеленые области). Иначе — проявляется слабее. Во время этой фазы идет физическое восстановление (например иммунной системы).
REM
Фаза быстрого сна (REM). Еслине спим днем, то REM проявляется ближе к утру. Если спим днем, то днем эта фаза существенно проявляется. Во время этого типа сна восстанавливается психика. Т.е. если работа умственная или напряженная, то улучшение этого сна критически важно.
Wake
Фактор просыпания. Проявляется если вы просыпаетесь ночью, как на продолжительное (десятки минут), так и короткое время (пара минут). Что отдельно следует сказать, это то, что многие люди не помнят, как они просыпались на короткое время, и данный факт можно установить только с помощью прибора, снимающего электроактивность мозга (MyZeo это умел, приложения смартфонов этого не умеют; для снятия надо надевать какую-нибудь штуку на голову, обычно на лоб). Например я наблюдал такое у себя на ночных гафиках от MyZeo — малые красные полоски.
Time to Z
Это время, которое требуется на то, чтобы заснуть. Это может быть как длительное валяние (например 0.5-1.5 часа), так и долгое бессознательное засыпание (10-15 минут без памяти этого факта).

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

    

на 18:00
Ярлыки: , ,
Подписаться на: Сообщения (Atom)