робовійни. Економо-Соціальний та Інформаційно-Навчальний аспект
СЕЛЕКЦІЯ ТОЧОК УВАГОНАГОЛОСУ - МОЯ
http://misto.ridne.net/viewthread.php?tid=9732
СЕЛЕКЦІЯ ОБРАНОШМАТКІВ - МОЯ
-1-
Wins and Who Loses in Google and Uber's Breakup Over Driverless Taxis?
Ентоні Вінг Коснер (Anthony Wing Kosner)
2/03/2015 @ 10:03AM
...
робота «нижче API» - це абсолютний тупик.
Водії Uber, «клікери» - виконавці завдань Mechanical Turk, конкурсанти 99design, працівники
TaskRabbit і чистильники HomeJoy - все це потенційні жертви подальшої автоматизації.
За великим рахунком, розробка ПЗ зводиться до створення моделей систем - моделей,
які можна виконувати, оптимізувати і комбінувати з іншими моделями. Це означає, що
з часом такі API (...Application Programming Interface (API) - це не готові рішення, це середовище,
інтерфейс для створення своїх проектів. Ви ж не їсте заморожений котлети з
магазину? Ви спочатку їх посмажите, чи не так? Ця аналогія дуже ясно відображає
суть API...) зможуть координувати все більш складні набори завдань. «У міру
потовщення програмного шару, - розрив між завданнями вище API і нижче API
розширюється. У той же час економічна мотивація буде підштовхувати інженерів, що
працюють вище API, автоматизувати завдання нижче API: самоврядні автомобілі і
дрони-кур'єри не змусять себе чекати ».
...
Частка праці, опосередкованого за допомогою API, поки що мала, але вона зростає. Як
написав Фархад Манджу (Farhad Manjoo) в New York Times, «Uber і, ширше кажучи, програмно керований ринок праці, котрий він представляє,
відтворює кардинальну зміну стилю праці і самого ставлення людей до роботи.
Навіть якщо ви не збираєтеся стати водієм Uber, «уберізація» роботи може незабаром
зачепити й ваш фах» . Ефект Uber потенційно може поширитися на юристів, лікарів і
навіть (у більш віддаленому майбутньому) самих венчурних капіталістів.
Тиск автоматизації залишить таким робочим зовсім мало можливостей впливати на
реальність - якщо тільки вони не вміють щось, що важко автоматизувати, або
володіють навичками, що роблять їх роботу якісно кращою автоматизованого
продукту. Важливість моделювання задач і управління ними продовжить рости, але ж
і технології, оперативно і ретельно зіставляють навички з потребами економіки,
будуть розвиватися. Щоб економіка 21 століття залишалася продуктивною Як для
Людей,- Так і для Капіталу, вона повинна буде стати набагато більш гнучкою, ніж то
нормативно можливо в первісних рамках проектів «уберізаціі» і «гуглофікаціі»
роботи.
(с) Ентоні Вінг Коснер (Anthony Wing Kosner)
повний оригінал:
http://www.forbes.com/sites/anthonykosner/2015/02/04/google-cabs-an...
кирилична версія:
http://bitnovosti.com/2015/05/11/google-cabs-and-uber-bots-will-cha...
-2-
Peer Instruction: A User’s Manual
http://erazvitie.org/article/pervyj_kavaler_minervy
... У традиційній системі освіти студент отримує інформацію, слухаючи лекції в
навчальній аудиторії в оточенні інших студентів, після чого йде додому і
намагається усвідомити почуте. Ерік Мазур зрозумів, що це абсурдно. Лекції були
корисні тільки тоді, коли вони були єдиним способом передавати інформацію учням.
Але зараз … студент читає про предмет дома, а в аудиторії - працює над його
розумінням разом з однокурсниками і викладачем. Цю модель багато хто зараз іменує
«перевернута класна кімната» ... Найголовніше ...- не «ПЕРЕДАЧА Інформації
студенту», оскільки він шляхом читання вже її отримав, а допомога в її ОСВОЄННІ.
Мазур перестав читати лекції і звернувся до методу, винайденому 2400 років тому - до
методу Сократа, коли викладач задає питання, а не дає готові відповіді. У 1997 році
була опублікована книга Peer Instruction: A User's Manual («Peer instruction: керівництво користувача»),
в якій він пояснив концепцію peer instruction і надав читачеві матеріали для її
застосування в аудиторії. ... В XXI столітті нам давно пора відмовитися від лекції як
від панівної моделі навчання.
Оскільки роботи і комп'ютери забирають собі багато робочих місць, нам
необхідно навчати людей займати ті новаторські та креативні посади, на які
комп'ютери і роботи претендувати не можуть.
... Якщо для отримання оцінки треба буде щось створити, мислити критично і діяти як
новатор, то екзаменаційна перспектива буде вже не такою однозначною як раніше. А
це страшно. Адже студенти навіть не можуть припустити, як їх творчість буде
оцінено іншими людьми. Але їм треба зрозуміти, що це сама суть реального життя. І
це не оцінка того, наскільки добре ти зубрів інформацію та застосовуються
стандартні формулу - з цими завданнями сучасні комп'ютери справляються набагато
краще людини. Нам же потрібна креативна робоча сила XXI століття, яка буде мати
потрібні навички мислення для новаторської роботи. Всі інші робочі місця просто
зникнуть.
upd:
-3-
_ailev_ *Никакого "над API" и "под API" не будет*
http://ailev.livejournal.com/1186391.html
Anatoly Levenchuk (ailev) 2015-05-12 22:32:00
В феврале 2015 в оборот было запущено обсуждение архитектуры предприятия будущего
как состоящей из компонент (позиций/профессий/jobs) "над API" и "под API", причём
профессии "под API" в свою очередь делятся на "автоматизацию менеджента" и "роботов" (
http://www.forbes.com/sites/anthonykosner/2015/02/04/google-cabs-an... ):
Главная идея тут в том, что middle management заменяется API -- вся диспетчеризация уходит в
софт. Менеджеры принимают решения о том, как настроить API, менеджеры больше не
поручают работы и не контролируют их выполнение (http://rein.pk/replacing-middle-management-with-apis/). И после этого говорится, что выживут только те
содержательные профессии, которые будут заказчиками работ, а исполнители работ
все будут автоматизированы (сначала в части менеджмента, а потом и вообще
заменены роботами). В Uber останутся только пассажиры и API, а таксисты все будут
заменены роботами.
Мне кажется, что тезис абсолютно неверный: по факту над API остаются не столько
"работы-профессии", сколько просто потребительские позиции (позиция пассажира над
API, позиция таксиста под API, а сам API выполняет функции линейного менеджмента). В
подобной фразеологии говорится, что в предприятии остаются только строители API
(пользовательский интерфейс клиента и диспетчеризация работ) и роботостроители
(пока роботостроители заменяются создателями пользовательских интерфейсов для
работников "под API"). Тотальная автоматизация (http://ailev.livejournal.com/1131557.html -- humans need not to apply), только и всего, ничего нового кроме
замечания что профессионалы "под API" перестают иметь шанс повышения и
переквалификации, ибо вряд ли из таксистов можно пойти в программисты
диспетчерских программ того же Uber.
Но вот тезис о дисинтермедиации содержательных (инженерных,
производственных) работников путём ухода внутрь софта функций диспетчирования
ресурсов (чем и занимается по большей части инженерный менеджмент) -- это да, этот
тезис выживает. Дальше можно обсуждать, насколько можно упихнуть в API
лидерство (например, как обеспечивается лидерство среди таксистов Uber или
Яндекс-такси). Или насколько подобный менеджмент будет съедать всё менее и менее
коммодитизируемые работы (всё-таки поездки в такси и другие потребительские
сервисы довольно однородны). Или насколько речь идёт о внешнем по отношении к
фирме API (приём и распределение заказов), или подобные рассуждения можно применить
и по отношению к корпоративным информационным системам управления работами (PLM,
ERP, EAM и т.д.).
Тут нужно заметить, что речь идёт о довольно редкой архитектурной парадигме --
коммуникационной (а не продуктной и не процессной), то есть мы говорим о
функционировании предприятия как о сети поручений на работу upstream и выполнении
этих поручений downstream (напомню про DEMO -- http://ailev.livejournal.com/644440.html) и лидерство тут в том, чтобы минимизировать
отказы/саботажи в выполнении поручений. В принципе, lean-kanban-TOC тоже можно
рассматривать как попытку формализовать как-то работу инженерного менеджера, это
подход к постановке задачи по созданию подобного софта. Да, там очень много
противоречащих друг другу принципов и правил, но это не мешает потихоньку делать
соответствующий солвер-планировщик и вымывать линейных менеджеров из
организации. Это, конечно, не исключает автоматизацию работ как над, так и под
таким API -- автоматизацию всего "вокруг API". Слово API при этом просто начинает
обозначать корпоративный софт, ничего более. Разнообразие архитектур
предприятий с учётом перехода менеджерских функций к софту сейчас поднимется.
Шапкозакидательно? Конечно. Но уже сейчас довольно много линейных менеджеров
просто прокладки между работниками и какими-нибудь корпоративными
информационными системами (проектного управления, ERP, EAM). Читают информацию с
экрана и доводят её до содержательных работников, затем спрашивают у
содержательных работников и вводят эту информацию на экран. Прям телефонистки на
старинных ATC. И не нужно говорить, что интерфейс телефона много проще, чем
интерфейс корпоративного софта. Хороший пользовательский интерфейс к
содержательным работникам вполне с коммуникацией справится, даже если ему
придётся при этом принять форму робота телеприсутствия и говорить на разных
диалектах производственного матерного языка и отпускать пошлые шутки в целях
управления вниманием работников.
З повагою, Сергій.
|
![[*]](images/xp/default_icon.gif){kind=icon}
