home | login | register | DMCA | contacts | help | donate |      

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я


my bookshelf | genres | recommend | rating of books | rating of authors | reviews | new | форум | collections | читалки | авторам | add

реклама - advertisement



Розрахунок щастя

Як же зробити щасливими самих себе, наших працівників та колег по команді? Як перетворити це щастя на більшу продуктивність і прибутки?

Щоб відповісти на ці питання, потрібно повернутися до Toyota та хрестового походу Таїчі Оно проти марнування. Мета позбутися цієї проблеми привела його до ідеї «безперервного покращення». Недостатньо досягти певного рівня продуктивності та залишатися там – ідея полягає в постійній перевірці ваших робочих процесів на предмет їх вічного покращення. Досконалість, звичайно, не має меж, але кожен здобуток у цьому напрямку має значення.

Як і роботу та час слід розбивати на керовані частини, покращення треба нарізати на окремі кроки. У японській мові для цього є спеціальне слово кайдзен – «безперервне покращення». Що невеличке можна зробити просто зараз, щоб покращити вашу роботу?

У Scrum це розглядається наприкінці кожного спринту під час того, що я називаю «ретроспективою». Спочатку члени команди показують, чого вони досягли протягом останнього спринту (що в них «Виконано» та може потенційно бути представлене клієнтам для відгуку). А потім вони сідають і думають, що пройшло добре, що могло пройти краще та що можна покращити в наступному спринті. Яке покращення робочого процесу вони як команда здатні запровадити просто зараз?

Щоб бути ефективною, ця зустріч потребує певної емоційної зрілості та атмосфери довіри. Головне – пам’ятати, що ви не шукаєте когось винного, а розглядаєте можливі недоліки процесу. Чому це сталося саме так? Чому ми це пропустили? Що може зробити нас швидшими? Дуже важливо, щоб люди брали на себе відповідальність за свою роботу і її результати як команда та шукали рішення як команда. Водночас люди повинні мати мужність порушувати питання, які дійсно їх турбують, орієнтуючись на пошук рішення, а не звинувачення. А решта команди повинна мати зрілість слухати відгуки, сприймати їх та шукати розв’язання, а не займати оборонну позицію.

У циклі Демінга (плануйте, робіть, перевіряйте, дійте) ретроспективна зустріч – це частина перевіряйте. Головне – дістатися кроку дійте (кайдзен), який дійсно змінить робочий процес та зробить його кращим наступного разу. Недостатньо лише ділитися відчуттями, потрібно мати змогу діяти.

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

Ось як це працює. Наприкінці кожного спринту кожен член команди відповідає лише на декілька запитань:

1. Як ви почуваєтесь щодо своєї ролі в компанії за шкалою від 1 до 5?

2. Як ви почуваєтесь щодо компанії в цілому за тією самою шкалою?

3. Чому ви так вважаєте?

4. Яка одна річ могла б зробити вас щасливішими в наступному спринті?

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

А тепер ключовий момент. Команда бере це одне головне покращення та робить його найважливішою річчю, яку слід зробити в наступному спринті, – зі вступними випробуваннями. Як ви доведете, що покращення досягнуто? Потрібно визначити, що таке успіх, чітко та доступно, щоб у наступній ретроспективі спринту було дійсно легко побачити, чи досягли ви кайдзену.

Кілька років тому я вирішив розширити свою компанію Scrum, Inc. до консультаційної агенції з повним набором Scrum-послуг. Ми відстежили нашу швидкість і виявили, що кожного однотижневого спринту виконуємо завдань приблизно на сорок балів. Після запровадження показника щастя одразу виявилось, що наші сюжети не досить добрі. Вони не були достатньо підготованими, не мали визначення готовності та були надто розпливчастими. Я попрацював над цим, і ми почали писати кращі сюжети. Але протягом наступного спринту вони все ще були недостатньо добрими. Це відображали наші оцінки щастя. У третьому спринті виникла нова проблема. Ми взялися за неї. Так і пішло. Усього за кілька тижнів наша швидкість збільшилася із сорока балів за спринт до ста двадцяти. Ми потроїли продуктивність, просто питаючи, що може зробити людей щасливішими. Як результат, наші клієнти також стали щасливішими, а наші прибутки різко підскочили. Усе, що треба було для цього зробити, – почати питати в команди: «Що може зробити вас щасливішими?», а потім давати їм це.


Scrum. Навчись робити вдвічі більше за менший час

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


Щастя – це успіх | Scrum. Навчись робити вдвічі більше за менший час | Робіть усе видимим