Как правильно рассчитать зарплату технику?
Участвуйте в вебинарах по умным зарплатам: научим разрабатывать эффективные работающие системы мотивации для нужных должностей
На сайте ведутся работы
сегодня 10929 Подписчиков
C. ЧТО ИДЕТ СЛЕДОМ ЗА "CLOUD COMPUTING"?
Как известно, основные этапы развития (от больших мэйнфреймов к сегодняшним) компьютеров упрощенно можно представить так:
Большой компьютер (Mainframe) -> Personal Computer (PC) стационарный -> Personal Computer (PC) мобильный, пр. ноутбук -> Smartphone -> … .
В настоящее время, многие эксперты даже проводят аналогии между большими компьютерами (MainFrame), которые также сдавали в аренду, которые занимали пространства схожие по масштабам с теми, что занимают сегодняшние центры обработки данных и представляющие собой аналогичные центры затрат.
См., например, здесь. Это уже не дата-центр. Это 1 компьютер “Эниак” (1946 год).
Современный центр обработки данных является, по мнению ряда экспертов, аналогией мейнфрейма. См, например, в обсуждении Так что же с поиском правильной бизнес-идеи?. Некоторые из экспертов даже приводят для иллюстрации философский закон отрицания отрицания в том смысле, что “на новом витке развития повторилось то, что уже было”.
Нельзя не заметить и сходство бизнес - моделей: снова аренда, снова громадный центр затрат и… снова пропаганда идеи централизации в противовес персональному использованию компьютера.
Понимая известную условность аналогий, попробуем предположить появление “Personal Cloud Computing” или “Private Cloud Computing” - т.е., “персонального облака”. Подобно тому, как персональный компьютер вытеснил мейнфрейм, так и “персональные облака” начнут вытеснять “общежития данных”.
Термины “частное облако” или “персональное облако” постепенно входят в моду. См., например,
и можно нагуглить еще.
Скорее всего – количество материалов на эту тему будет увеличиваться. При этом, несмотря на общность названий, речь во всех этих материалах идет о разных вещах, хотя проблемы, о которые пытаются решить авторы одни и те же.
Поэтому далее здесь под “персональным облаком” понимается не "личный винчестер c сервисами”, а персональный компьютер, умеющий вступать в группу и/или группа разных компьютеров, которые обмениваются вычислительными и иными ресурсами друг с другом, а также данными, но не находятся в одном центре, а находятся там, где им заблагорассудится. В частном случае, они могут представлять собой и распределенную базу данных.
В “персональное облако” могут входить не только компьютеры, но и иные устройства, подключенные к Интернет, в частном случае и домашние (например, телевизоры, принтеры, холодильники и т.д.).
Сохраняя все “облачные” возможности, “персональное облако” обеспечивает и персональное хранение данных. Это личное “облако”, которое Пользователь может “носить с собой” (хоть в смартфоне). “Персональное облако” каждого Пользователя может “дружить” (обмениваться данными, взаимно пользоваться вычислительными ресурсами друг друга) с “персональными облаками" других пользователей. Данные, не теряя структуры, функциональности использования и ссылочной целостности, легко перемещаются с компьютера на компьютер.
Близкое по духу описание – см. здесь: “Темная материя Интернета” http://habrahabr.ru/blogs/p2p/112491 . Основной акцент этого интересного материала сделан на совместном использовании вычислительных ресурсов.
I am agreed with this blog and i just want say that this article is very nice and
very informative article.
Эта парадигма создавалась из утилитарного стремления к идеалу, как в управленческом, так и в тризовском смысле. Формулировки идеальности (которые соответствуют по духу и замыслу тем, что сформулировал Генрих Альтшуллер, создавая ТРИЗ, и которые продвигали эту разработку) следующие:
1) Идеально - это когда программу сможет в отсутствие Автора не только сопровождать, но и развивать программист с меньшей квалификацией, чем Автор программы.
2) Идеально - когда добавление новой функциональности в программу не потребует внесения изменений и/или добавлений в программный код (более того, в совершенно идеальной программе увеличение функциональности приводит к сокращению кода); причём всё это без ущерба для любых параметров (например, быстродействия и т.д.).
И чтобы программы писались настолько быстро и сопровождались настолько просто, что их создание и сопровождение можно было бы поручить детям. А взрослые и умные специалисты пусть бы занялись чем-нибудь великим.
Сразу начнем с сути дела. Существует некий язык записи сути задачи. Если его применять, то сложные (креативные) задачи решать становится удобнее.
Как и любая модель, эта модель тоже жизнь собой не заменяет, однако авторы статьи попробовали и убедились в том, что действительно удобно. Хотя поначалу кажется непривычным… Впрочем, авторы, уважая время Коллег, постеснялись бы писать о привычном, знакомом, общеизвестном.
Рассмотрим серию примеров. Пока намеренно несложных. (Более сложные мы в дальнейшем тоже рассмотрим).
Действительно, создать качественную программу "из объектов", двигаясь "снизу вверх" (от подсистем к системе; от реализации к проекту), можно только при условии предельной простоты такой программы.
Однако, похоже, существует инерция мышления, оставшаяся с тех времен, когда все писали на низком уровне, и мысли о реализации неизбежно занимали наибольший промежуток времени. И многие программисты (конечно, не все) часто думают "снизу вверх". Больше над реализацией, чем над проектом.
Но, например, хороший архитектор никогда не проектирует дом "из квартир", а думает о нем сразу "в целом", "вписывает" в контекст окружающей среды, пользуется знаниями о готовых "стилях" (или создает свой стиль, зная о других). Хороший авиаконструктор не проектирует новый самолет "из его элементов", но пытается понять, как машина "летает в целом", или отталкивается от "принципов полета этого класса машин" и т.д., и т.п.
Мышление "снизу вверх" сродни попытке сложить организм из атомов углерода и водорода. Теоретически так сделать можно, но очень уж "многофакторно" и затратно как по времени, так и по ресурсам. И все равно, несмотря на затраты и при квалифицированной работе, получится урод + "теория неизбежности ошибок" вместо качественного продукта. За исключением, может быть, тех случаев, когда "организмом" (перепутав термины) назвали что-то предельно простое (например, 1 звено СН).
Видеозаметка С.В. Сычева об оценке качества идей и эффективности решений на примере it-разработок: уровни сложности заданий - уровни достигнутых результатов.
Для решения некоторых задач программирования в качестве "инструмента", облегчающего разработчику абстрагирование от конкретики, предлагается использовать "абсолютно тупого героя", которому поручается некая деятельность. Поскольку этот герой непроходимо туп (мы даже пишем его с маленькой буквы, чтобы и тени величия в нем не наблюдалось), то задача поручить ему деятельность, которая, тем не менее, должна быть выполнена — нетривиальна.
Тем не менее, надо описать решение так, чтобы тупой (несколько тупых) смогли качественно и незатратно порученную задачу выполнить.
Остальное понятно из контекста разбираемых примеров:
Один раз решили научить тупого молоть уголь и рисовать угольной крошкой по трафаретам на поверхностях и чуть не наломали дров. Сначала научили тупого рисовать углем "бабушку" на "окошке". Для этого, велели ему:
Кто придумал такую тупую инструкцию вспомнить уже невозможно — так, что материться глупо — надо работать. Поэтому с помощью воплей, дубины, «соцпакета» и 10-ти тупых администраторов кое-как упомянутый художественный результат достигался.
Причем 10 тупых администраторов периодически посещали семинары по мотивации тупых, где их учили более правильным "соцпакетам", в результате применения которых тупой должен был бы "раскрыться" и стать Личностью. А уж Личность смогла бы рисовать не только бабушек, но и птичек.
Однако, в связи с развитием рыночных отношений, задание усложнилось.
Товаров все больше и больше, поэтому непонятно, что рекламировать из имеющегося ассортимента, тем более что макет газетной полосы не резиновый, а кегль шрифта тоже имеет нижнюю границу. Руки опускаются, а в голову приходят уж очень общие идеи типа: "Все для всех всегда". А реклама магазина все больше и больше становится похожа на рекламу банка: там тоже "Для всех и повсеместно". Чтобы упомнить все товары, нужно долго обучаться мнемотехнике.
Создавшаяся ситуация неопределенности усложняет и работу отдела рекламы, и контроль над ним. Товар - с колес, макет - в пожаре... Все заняты текучкой. Некогда планировать, некогда искать идеи, некогда отслеживать эффективность. Надо продавать, изготавливать, размещать: Стоп! Очень уж удобная позиция. Остановимся на несколько часов и посмотрим на десятки тысяч, нет, сотни тысяч товаров и услуг иначе...
Данная закономерность была сформулирована автором в 1993 году в Иркутске. Ряд фактов уже тогда давали возможность построить модель, которую, тем не менее, нужно было проверять в течение долгого времени. Последующие 13 лет позволили сделать ряд обобщений, подтвердивших изначальную гипотезу. И в 2006 году автор счёл возможным первую версию закономерности опубликовать открыто.
Летом 2013 года публикуется версия 2.0 - более полная, развернутая и содержащая одно существенное методическое отличие от первой версии.
Автор будет признателен Коллегам, которые найдут "узкие места" данной работы и направят автору критические замечания и/или примеры, как подтверждающие, так и опровергающие положения изложенные в материале.
Два великих человека радикально высказались об оптимизации: "Единственный способ оптимизировать затратный проект – это его закрыть" (Питер Друкер) и "Идеальная система - та, которой нет, а функции ее выполняются" (Генрих Альтшуллер).
Этот материал посвящен (основанным на ТРИЗ) приемам сокращения работ при сохранении и улучшении их результатов. В этой части работы вслед за классиками сформулируем: "Лучшая работа – та, которую делать не надо, но результат ее получается".
В материале приведен список основной литературы по ТРИЗ.
В разные годы издавались и другие книги (как правило, меньшим тиражом) других авторов. Но мы рекомендуем начинать знакомство именно с классики ТРИЗ - книг Г.С. Альтшуллера. Как правило, найти эти книги можно в крупных библиотеках.
Фрагмент выступления Сергея Сычёва на ежегодном TRIZ-RI ФОРУМе
"Открытые бизнес-методики и технологии",
Москва, 27 сентября 2011 г.
Рекомендация 2.2 (из 10-ти).
Молодая фирма, стартуя, имеет бизнес-план, как минимум, на первые три года жизни (по крайней мере, иметь его чрезвычайно полезно). Результаты, на которые надо выйти за эти три года, и будем считать "эталонными". Кроме "эталонных", зададим промежуточные результаты — те, на которые надо выйти к заданным срокам. Фактические результаты в стартовый период" будем сравнивать не с эталонными, а с промежуточными результатами.
Важный момент: промежуточные результаты задаются на старте, а не по "факту" (от достигнутого).
Сравните:
а) план вырос потому, что подошел срок, когда пора выйти на показатели, намеченные в бизнес-плане;
б) план вырос потому, что достигли хороших результатов, а всегда хочется больше.
Пункт а), в отличие от пункта б), протеста не вызывает.
24 сентября 1998 г. умер великий человек. Генрих Саулович Альтшуллер, создатель и первый разработчик ТРИЗ - теории решения изобретательских задач, приемов развития творческого воображения, ЖСТЛ - жизненной стратегии творческой личности.
Уже сейчас ясно: это наука следующего тысячелетия. И нам будет трудно объяснить внукам, почему власть и электорат, начальники и ученые, спец. органы и педагоги так боялись новой науки в веке уходящем... Наверное потому, что ТРИЗ и ЖСТЛ меняют мышление, а значит и жизнь. Генрих Саулович считал, что человек должен прожить ее Достойно - на пределе своих возможностей. И он позволил себе так жить. Возможно, наши внуки окажутся сильнее нас...
И.Л. Викентьев
Данная закономерность была сформулирована автором в 1993 году в Иркутске. Ряд фактов уже тогда позволил построить модель, которую, тем не менее, нужно было проверить… Последующие 13 лет позволили сделать ряд обобщений, подтвердивших изначальную гипотезу.
Материал публикуется с некоторыми сокращениями и в то же время – с небольшими дополнениями.
Вы не поверите, но цель настоящей статьи – совсем не критика, ведь устранить несуразности, описанные ниже, не составит труда, а затраты копеечные. Авторов материала по должности нередко приглашают вычитывать разнообразные "концепции заведений", "системы менеджмента качества", "технологии клиентоориентированного обслуживания" и т.п. Но иногда приходится говорить: "Протрите, пожалуйста, столик, а только потом положите концепцию".
В статье приводятся, прежде всего, ошибки коммуникации с Гостем и простые решения, их устраняющие. Мы намеренно опускаем ошибки сервировки, подачи на стол и нарушение застольного этикета со стороны официантов.
Фрагмент выступления 08 апреля 2014 года на конференции "Открытые бизнес-методики и технологии", г. Ростов-на-Дону
"ТРИЗ" - Теория Решения Изобретательских Задач – самая сильная, на сегодняшний день, система создания новых идей и изобретений известна во многих странах: Германии, Великобритании, США, Швеции, Франции, Японии, Корее, Израиле, Вьетнаме, Испании, Финляндии, Канаде и др.
Книги автора ТРИЗ Генриха Альтшуллера [15.10.1926 - 24.09.1998] переведены на десятки иностранных языков. Большинство успешных компаний активно используют её для совершенствования своих товаров и услуг.
Если Вы бываете в Европе по делам бизнеса или с частными целями, найдите время заехать к нам в Прагу. На консультацию, на стажировку, на деловой завтрак. За свежими идеями, за новыми методиками, за иной обстановкой и за иными возможностями.
В Праге Вас встретят наши лучшие эксперты. Мы предложим Вам качественные программы бизнес-обучения по-европейски. В том числе, сделанные "под Вас". В том формате, в каком удобно Вам.
Часто бывает так: людей на работу взяли, а дело не движется. Звонков мало, заявок еще меньше, клиентская база тает… И не только в отделе продаж.
А Вы возьмите к себе "на работу" наших специалистов.
Каждый из нас имеет более чем 20-летний опыт практического внедрения системы управления предприятием, администрирования бизнес-процессов в отделах: активных продаж, закупки (снабжения), продвижения, складском хозяйстве, бухгалтерии, IT и пр.
С нашим приходом на предприятие уже через короткое время процессы управления организацией начинают работать как хорошо отлаженный механизм. А штатные сотрудники привыкают выполнять свои функции.
По мере развития компании обостряется необходимость умного сокращения усилий и затрат для достижения той же результативности (или даже повышения результативности при сокращении усилий и затрат)...