Главная Партнеры Контакты  
Юридическая компания — «Основной закон», консультации и помощь в возвращении депозитов, защита по кредиту

ЮК
"ОСНОВНОЙ ЗАКОН"  

г. Киев, бул. Пушкина, 2а                
тел.: (044) 334-99-77                               
         (095) 407-407-3
         (096) 703-11-82

график работы: пн.- пт. с 9:00 до 18:00
          
                           

 












Рассматривается вопрос о предоставление нотариусам права выдачи извлечения из Реестра прав на недвижимое имущество.
Министерством юстиции был разработан проект Закона «О внесении изменений в некоторые Законы Украины относительно предоставления информации о государст...


Держреєстрація речових прав на нерухоме майно та їх обтяжень у 2014 році буде здійснюватись за новою - удосконаленою та спрощеною - процедурою.
Постанова Кабінету Міністрів "Про затвердження порядку державної реєстрації прав на нерухоме майно та їх обтяжень і Порядку надання інформації з Держа...




Система Orphus


Небезпеки вимірювання еффектівностіTalent Management

  1. Ми всі зараз IT-компанії
  2. Теорія традиційного управління більше не працює
  3. Демінг і нова наука управління

Традиційні, сформовані на початку минулого століття вимір і оцінка ефективності співробітників на основі індивідуальних показників в корені не підходять для більшості сучасних робіт - "знаннєвих", що вимагають творчості, співпраці і вирішення проблем. Sam McAfee на Medium про те, чому і чим вони повинні бути замінені.

"Як би ви рекомендували оцінювати індивідуальну ефективність моїх інженерів?»

Було вже пізно, і у мене попереду була годинна поїздка. У мене не залишилося сил, щоб продовжувати відповідати на питання.

Але цей молодий інженер-менеджер, який поставив запитання і залишився після мого виступу, зачепив мене.

Це було, як якщо б він прочитав мої думки, вихопив то, що я вважаю найголовнішим інструментом управління і повернув його мені в формі питання.

Збуджений, я запитав: "Перш за все, навіщо ви хочете це робити?"

Молодий менеджер відповів: "Ну, мене тільки що підвищили, тепер я керую командою інженерів, які раніше були моїми колегами. Я хочу переконатися, що я добре справляюся. Я хочу мати можливість вимірювати роботу кожного з них, щоб отримувати базовий матеріал для подальшої оцінки їх ефективності. Я хочу переконатися, що все справляються зі своєю навантаженням ".

Здається цілком розумним, чи не так? Тим гірше, тому що це абсолютно невірно.

"Ну, - відповів я, звалюючи сумку з ноутбуком, -" Чому б тобі не пройти зі мною до стоянки і не описати те, що ти зараз робиш. А я дам тобі чесну зворотний зв'язок ".

Зрештою я залишив його з трьома конкретними практиками, які він міг би відразу застосувати до своєї команди. Але для того, щоб ви зрозуміли, в чому їх зміст, нам спочатку потрібно швидко поглянути на основні проблеми, з якими стикаються такі компанії, як та, звідки він.

Ми всі зараз IT-компанії

Марк Андрєєссен класно зауважив, що "програмне забезпечення з'їдає світ". Він мав на увазі зростаючу залежність від технологій практично в кожній галузі, а не тільки в IT-компаніях.

Зростання SaaS, хмарних і Big даних, штучного інтелекту і машинного навчання і повсюдність мобільних пристроїв з легким доступом до високошвидкісного інтернету є загрозою і можливість для традиційних компаній, особливо тих, які створені до інтернет-революції останніх кілька десятиліть. Ці компанії тепер знаходяться в позиції або "діяти як компанія-розробник програмного забезпечення", або бути розчавленими конкурентами.

Однак вони стикаються з серйозними перешкодами при проведенні внутрішніх змін. Їх зрілість має великий вплив на нові ініціативи, заважаючи внутрішнім новаторам досягти "прискорення" з їх проектами.

Існують три основні перешкоди для інновацій і гнучкості в цих компаніях, з якими я регулярно стикаюся:

  1. Організаційні структури, що перешкоджають співробітництву.
  2. Застарілі теорії управління глибоко вкоренилися в культурі компанії.
  3. Юридична або нормативна жорсткість, яка перешкоджає ризику.

Третій аспект повинен розглядатися на рівні вищого керівництва. Але будь-який менеджер, який очолює проект, може надати глибоке вплив на перші два.

Теорія традиційного управління більше не працює

Два мислителя початку двадцятого століття, Фредерік Тейлор і Генрі Гант, надали глибоке і тривале вплив на традиційну модель управління. Вони були серед тих, хто сформував інтелектуальну основу теорії управління в епоху становлення промислового виробництва США. На жаль, їх триваюче вплив на практику управління в інформаційну еру не робить нам ніякої користі.

Тейлор вважається батьком наукового менеджменту, зокрема, дослідження часу і діяльності. Як один з перших консультантів з управління, Тейлор зробив революцію у виробництві, застосовуючи спостереження і вимірювання до виконання завдань у виробничій системі. Розбиваючи виробництво на дискретні завдання і вимірюючи їх середній час завершення, Тейлор зміг зробити більш точні оцінки довжини проектів. Він також використовував цей метод, щоб допомогти роботодавцям підвищити ефективність бізнес-процесів шляхом настройки або зміни окремих етапів процесу.

Значною мірою саме через вплив Тейлора, роботодавці зосереджені на тому, щоб використовувати в якості показника ефективність співробітників. Це мало сенс для до-механізованого фізичної праці. Але це не той світ, в якому ми живемо зараз.

Приблизно в той же період Гант розробив сумнозвісну діаграму Ганта для управління проектами. Діаграма Ганта, яку ви все майже напевно бачили, є основою для візуалізації всіх ресурсів і завдань, необхідних для завершення проекту.

діаграма Ганта

Діаграма Ганта була розроблена для фізичних робіт по виробництву і збірці, вона не особливо корисна для "знанієвої" роботи. На її підставі винагороджують або карають співробітників на основі індивідуальних завдань, щоб точно налаштувати виробничі процеси, і при цьому повністю ігноруються залежності між паралельними завданнями.

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

Демінг і нова наука управління

Одним з найбільш ранніх критиків вимірювання індивідуальної ефективності був У. Едвардс Демінг. Демінг визнав і підкреслив небезпеку надмірного зосередження уваги на індивідуальних результатах в своїх роботах і бесідах ще на початку 1950-х років.

Він підкреслював, що якість продукції будь-якої виробничої системи пояснюється, в основному, зміною та організацією цієї системи, а не продуктивністю кожного окремого працівника. Таким чином, недоречно, вважав Демінг, винагороджувати або карати окремих працівників за виконання ними їх роботи.

Особливо часто Демінг звертався безпосередньо до практики індивідуальних річних бонусів за результатами, в якості одного з аспектів цього надмірної уваги до "індивідуальним результатами".

Демінг поділився своїми думками про причинності в складній системі в інтерв'ю 1994 роки для Industry Week (опублікованому через рік після його смерті):

"Дуже великі шанси, що те, що сталося, сталося як наслідок системи, в якій людина працює, а не його власних зусиль. Іншими словами, індивідуальна ефективність не може бути виміряна. Ви вимірюєте тільки сукупний ефект системи і його зусиль. Ви не можете розділити їх ".

Справді.

У співпраці з японськими вченими і інженерами в ході зусиль з відновлення після Другої світової війни, він працював над розширенням можливостей робітників (як команди) робити власні поліпшення в цеху, що стало основним компонентом так званого виробництва "Just-in-Timе".

Відома Toyota Production System - нащадками якої є як методологія Agile, так і Lean Startup - один з результатів цього широкого співробітництва японської індустрії з Демінгом. Ця новаторська філософія в кінцевому підсумку повернеться в США в процесі обміну досвідом між автовиробниками США і керівниками Toyota в 1980-х роках і, нарешті, стане відомою як Lean.

І, якщо вже Демінг був такою значущою фігурою не тільки для створення "Just-in-Time" -виробництва в Японії і "Lean Manufacturing" в США, але і в кінцевому підсумку для Lean Startup і Agile Software Development, можливо, ми повинні вислухати його попередження про те, чому не варто вимірювати індивідуальну ефективність.

"Я думав, що зможу відстежити час, що витрачається кожним інженером на виконання поставлених завдань, в нашій системі відстеження проектів", - сказав молодий інженер-менеджер, коли ми попрямували до моєї машині. "Це буде промовляти, хто швидше, і хто з усіх сил намагається виконати свою роботу".

Я бачив по його очах, що у молодого інженера найкращі наміри. Він хотів досягти успіху на своєму новому посту. І, крім того, він явно поважав інженерів, які йому підпорядковувалися (він зовсім недавно був одним з них), і щиро хотів надати підтримку і керівництво будь-якому члену своєї команди, який, можливо, з усіх сил намагається встигати.

"Це була б жахлива ідея з двох причин", - сказав я. "По-перше, вимір часу з виконання окремих завдань майже нічого не говорить про якість. По-друге, ви стимулюєте індивідуальну роботу, замість спільної ".

Незважаючи на неперевершений успіх Toyota Production System і Lean Manufacturing у всьому світі, адаптація Lean-практики для "знаннєвих" робіт в великих організаціях була надзвичайно повільній. Я сильно підозрюю, що принаймні однією з причин є те, що вплив Тейлора і Ганта на управлінські вчення все ще дуже сильне.

Раніше менеджмент мав тенденцію оцінювати співробітників за такими показниками, як якість, швидкість, вартість і дохід. У сьогоднішньому світі єдиними навичками, які дійсно важливі, є творчість, рішення проблем і співробітництво. Всі обслуговуючі, адміністративні та офісні завдання 20-го століття - навіть на рівні білих комірців - стають автоматизованими набагато швидше, ніж ви, ймовірно, вважаєте.

Оскільки цифрова трансформаційна хвиля продовжує радикально перетворювати компанії, два паралельних і взаємодоповнюючих явища діють в дуеті.

По-перше, компанії поступово переходять від положення, коли більшість співробітників мають оперативне або проектне мислення, до мислення, орієнтованого на клієнта або продукт. Паралельно завдання, які безпосередньо не пов'язані з основним процесом виробництва продуктів та обслуговування клієнтів, або передаються на аутсорсинг спеціалізованим фірмам, або повністю перетворюються в автоматизований процес.

Таким чином, незважаючи на те, що, безумовно, ще є неавтоматизована робота, виконувана фізичними особами, зазвичай вона більш низькокваліфікована, ніж основна робота компанії з розробки продуктів з високою доданою вартістю. Переважна більшість робіт по розробці продуктів виконуються командами.

Якщо ви очолюєте компанію, яка здійснює такий перехід до продукту і клієнта, досить імовірно, що найцінніші дії, які відбуваються у вашій компанії прямо зараз, виконуються не окремими особами, а скоріше групами в спільній і творчій роботі. Таким чином, немає сенсу намагатися вимірювати, а тим більше оцінювати, окремих осіб в цих групах.

Це більш-менш те, що я сказав молодому менеджеру, поки завантажував свою куртку і сумку для ноутбука в машину.

"Послухай, ти хочеш, щоб все в команді працювали разом, вірно? Тоді вам потрібно розробити свою структуру стимулювання і оцінки навколо команди, а не людини ", - сказав я.

Ось що я йому порадив:

  • Виміряйте загальну продуктивність роботи, а не активність конкретних людей. Організуйте свою роботу (за допомогою backlog-а, to do list-а, чого завгодно) в порядку важливості завдань для бізнесу. Єдиний показник, який дійсно має значення, - це швидкість, з якою ваша команда може доставити результати клієнтам.
  • Групуйте своїх людей навколо одного робочого елемента за один період часу. Дозвольте їм зосередитися на спільному створенні, тестуванні і доставці клієнтам цього робочого елементу, перш ніж братися за будь-яку нову роботу з черги. Більш того, нехай вони самі вибирають пари або групи для роботи (можливо, спочатку зовсім невеликі).
  • Надихайте команду покращувати процес самостійно. Регулярно проводите спільні зустрічі, щоб мати можливість кинути ретроспективний погляд на те, що працює, а що ні. Дозвольте команді виявити проблеми і запропонувати ідеї, які, на їхню думку, допоможуть.

Ваше завдання як керівника полягає в тому, щоб допомогти визначити пріоритетність на основі потреб бізнесу, усунути перешкоди, які уповільнюють роботу команди, і повідомляти про прогрес. Це основне. Додайте до цього якесь керівництво по кар'єрі і наставництво, і ви вже кращий менеджер, ніж більшість з них.

Quot;Як би ви рекомендували оцінювати індивідуальну ефективність моїх інженерів?
Збуджений, я запитав: "Перш за все, навіщо ви хочете це робити?
Здається цілком розумним, чи не так?
Quot;Послухай, ти хочеш, щоб все в команді працювали разом, вірно?
Главная Партнеры Контакты    
Cистема управления сайта от студии «АртДизайн»