David Anderson - Kanban ។ កាន់បាន

លោក David J Anderson

ការផ្លាស់ប្តូរការវិវត្តន៍ប្រកបដោយជោគជ័យសម្រាប់អាជីវកម្មបច្ចេកវិទ្យារបស់អ្នក។

បោះពុម្ពដោយមានការអនុញ្ញាតពី Lean Kanban Inc.

យើងសូមថ្លែងអំណរគុណដល់សហគមន៍ Lean Kanban Russia ដែលតំណាងដោយ Alexey Pimenov, Vyacheslav Tsyrulnik, Anton Manin, Sergey Baranov និង Igor Filipyev សម្រាប់ជំនួយរបស់ពួកគេក្នុងការរៀបចំការបោះពុម្ពផ្សាយ។

រក្សារសិទ្ធគ្រប់យ៉ាង។

គ្មានផ្នែកនៃសៀវភៅនេះអាចត្រូវបានផលិតឡើងវិញក្នុងទម្រង់ណាមួយដោយគ្មានការអនុញ្ញាតជាលាយលក្ខណ៍អក្សរពីម្ចាស់កម្មសិទ្ធិបញ្ញា។

* * *

ឧទ្ទិសដល់ Nikola និង Natalie

បុព្វបទ

ខ្ញុំតែងតែយកចិត្តទុកដាក់ចំពោះការងាររបស់ David Anderson ។ ខ្ញុំបានជួបគាត់នៅខែតុលា ឆ្នាំ 2003 នៅពេលដែលគាត់បានផ្ញើមកខ្ញុំនូវច្បាប់ចម្លងនៃសៀវភៅ Agile Management for Software Engineering: Applying Theory of Constraints for Business Results។ ដូចដែលចំណងជើងបានបង្ហាញ សៀវភៅនេះត្រូវបានជះឥទ្ធិពលយ៉ាងខ្លាំងដោយទ្រឹស្តីនៃឧបសគ្គ (TOC) របស់ Eliyahu Goldratt ។ 1
Theory of Constraints គឺជាវិធីសាស្រ្តគ្រប់គ្រងផលិតកម្មដ៏ពេញនិយមដែលត្រូវបានបង្កើតឡើងក្នុងទសវត្សរ៍ឆ្នាំ 1980 ដោយ Eliyahu Goldratt ដែលផ្អែកលើការស្វែងរក និងគ្រប់គ្រងឧបសគ្គនៃប្រព័ន្ធសំខាន់ៗដែលកំណត់ភាពជោគជ័យ និងប្រសិទ្ធភាពនៃប្រព័ន្ធទាំងមូលទាំងមូល។ ចំណាំ។ ed ។

ក្រោយមកនៅខែមីនា ឆ្នាំ 2005 ខ្ញុំបានទៅជួបលោក David នៅក្រុមហ៊ុន Microsoft ដែលនៅពេលនោះគាត់កំពុងធ្វើការយ៉ាងជិតស្និទ្ធជាមួយនឹងតារាងលំហូរ។ សូម្បីតែក្រោយមកនៅក្នុងខែមេសា ឆ្នាំ 2007 ខ្ញុំមានឱកាសដើម្បីសង្កេតមើលពីរបៀបដែលប្រព័ន្ធ kanban របកគំហើញដែលគាត់បានអនុវត្តនៅក្នុង Corbis ដំណើរការ។

ខ្ញុំផ្តល់កាលប្បវត្តិទាំងមូលនេះ ដើម្បីឱ្យអ្នកមានអារម្មណ៍សម្រាប់ល្បឿនដែលមិនអាចបញ្ឈប់បាន ដែលការគិតរបស់អ្នកគ្រប់គ្រងរបស់ដាវីឌកំពុងរីកចម្រើន។ គាត់មិនប្រកាន់ខ្ជាប់គំនិតតែមួយទេ ដោយព្យាយាមធ្វើឲ្យពិភពលោកទាំងមូលចូលទៅក្នុងវា។ ផ្ទុយទៅវិញ គាត់ព្យាយាមគិតគូរពីបញ្ហាទាំងមូល បើកចំហរចំពោះដំណោះស្រាយផ្សេងៗ ព្យាយាមអនុវត្ត និងវាយតម្លៃគោលការណ៍ការងារ។ អ្នកនឹងឃើញលទ្ធផលនៃវិធីសាស្រ្តនេះនៅក្នុងសៀវភៅនេះ។

ជាការពិតណាស់ ល្បឿនគឺល្អដរាបណាវាស្ថិតក្នុងទិសដៅត្រឹមត្រូវ ហើយខ្ញុំប្រាកដថា David កំពុងធ្វើដំណើរក្នុងទិសដៅត្រឹមត្រូវ។ ជាពិសេសខ្ញុំកោតសរសើរចំពោះការងារចុងក្រោយបំផុតជាមួយប្រព័ន្ធ kanban ។ ខ្ញុំតែងតែជឿថាគោលការណ៍នៃការគ្មានខ្លាញ់អាចត្រូវបានអនុវត្តដោយផ្ទាល់ចំពោះការអភិវឌ្ឍន៍ផលិតផល ផ្ទុយពីគំនិតរបស់ TOC ។ លើសពីនេះទៅទៀត នៅខែតុលា ឆ្នាំ 2003 ខ្ញុំបានសរសេរទៅលោក David ដូចខាងក្រោម: "ចំណុចខ្សោយសំខាន់មួយនៃ CBT គឺការប៉ាន់ស្មានមិនដល់សារៈសំខាន់នៃទំហំគណបក្ស។

ប្រសិនបើអាទិភាពចម្បងរបស់អ្នកគឺស្វែងរក និងជួសជុលឧបសគ្គ នោះច្រើនតែមានន័យថាអ្នកគ្រាន់តែដោះស្រាយបញ្ហាខុស។" ខ្ញុំនៅតែជឿថាសេចក្តីថ្លែងការណ៍នេះជាការពិត។

នៅឯកិច្ចប្រជុំរបស់យើងក្នុងឆ្នាំ 2005 ខ្ញុំបានស្នើម្តងទៀតទៅលោក David ឱ្យមើលទៅលើសពីការផ្តោតទៅលើបញ្ហាជាប់គាំងនៅក្នុង TOC ។ ខ្ញុំបានពន្យល់គាត់ថា ការឃោសនាបំផ្លើសនៃប្រព័ន្ធផលិតកម្មតូយ៉ូតា (TPS) មិនមានជាប់ពាក់ព័ន្ធជាមួយការស្វែងរក និងលុបបំបាត់ការកកស្ទះនោះទេ។ Toyota សម្រេចបាននូវការកើនឡើងផលិតភាពដោយកាត់បន្ថយទំហំច្រើន និងភាពប្រែប្រួល ដែលកាត់បន្ថយបរិមាណសារពើភ័ណ្ឌដែលត្រូវការ។ វាគឺជាការកាត់បន្ថយនៃសារពើភ័ណ្ឌដែលនាំទៅដល់ការសម្រេចបាននូវអត្ថប្រយោជន៍សេដ្ឋកិច្ច ហើយនេះអាចធ្វើទៅបានដោយប្រព័ន្ធកាត់បន្ថយការងារក្នុងដំណើរការដូចជា kanban ។

នៅឆ្នាំ ២០០៧ ខ្ញុំបានទៅលេង Corbis ។ លទ្ធផលនៃការណែនាំនៃប្រព័ន្ធ kanban មើលទៅគួរអោយចាប់អារម្មណ៍។ ខ្ញុំបានចង្អុលបង្ហាញទៅលោក David ថាគាត់បានធ្វើឱ្យប្រសើរឡើងយ៉ាងខ្លាំងនូវវិធីសាស្ត្រ kanban ដែលប្រើនៅក្រុមហ៊ុន Toyota ។ ហេតុអ្វីបានជាខ្ញុំគិតដូច្នេះ? ប្រព័ន្ធផលិតកម្មតូយ៉ូតាត្រូវបានធ្វើឱ្យប្រសើរឡើងដើម្បីដោះស្រាយការងារដដែលៗ និងអាចព្យាករណ៍បានជាមួយនឹងរយៈពេលឯកសណ្ឋាន និងការចំណាយលើការពន្យារពេលឯកសណ្ឋាន។ នៅក្រោមលក្ខខណ្ឌទាំងនេះ វាជាការត្រឹមត្រូវក្នុងការប្រើវិធីសាស្រ្តដូចជា FIFO-prioritization ("ដំបូងចូល ចេញដំបូង")។ វាក៏ត្រឹមត្រូវផងដែរក្នុងការទប់ស្កាត់ការទទួលការងារ ប្រសិនបើដែនកំណត់នៃកិច្ចការមិនពេញលេញត្រូវបានឈានដល់។ ទោះជាយ៉ាងណាក៏ដោយ ប្រសិនបើយើងកំពុងដោះស្រាយជាមួយនឹងសកម្មភាពដែលមិនកើតឡើងដដែលៗ និងមិនអាចទាយទុកជាមុនបានជាមួយនឹងរយៈពេលខុសៗគ្នា និងការចំណាយលើការពន្យារពេលខុសៗគ្នានោះ វិធីសាស្រ្តទាំងនេះមិនអាចចាត់ទុកថាល្អបំផុតនោះទេ ហើយនេះគឺពិតជាករណីនៃការអភិវឌ្ឍន៍កម្មវិធី។ យើងត្រូវការប្រព័ន្ធទំនើបជាងនេះ ហើយនេះគឺជាសៀវភៅដំបូងគេដែលពិពណ៌នាពួកវាយ៉ាងលម្អិតជាក់ស្តែង។

ខ្ញុំចង់ព្រមានអ្នកអានអំពីរឿងមួយចំនួន។ ជាដំបូង ប្រសិនបើអ្នកគិតថាអ្នកដឹងពីរបៀបដែលប្រព័ន្ធ kanban ដំណើរការ នោះអ្នកប្រហែលជាមានន័យថា អ្នកដែលប្រើក្នុងការផលិតគ្មានខ្លាញ់។ គំនិតនៅក្នុងសៀវភៅនេះគឺមានភាពជឿនលឿនជាងប្រព័ន្ធសាមញ្ញដែលប្រើដែនកំណត់ WIP ឋិតិវន្ត។ 2
WIP - ការងារកំពុងដំណើរការ ចំនួនការងារដែលកំពុងដំណើរការ។ ចំណាំ។ ed ។

ការកំណត់កាលវិភាគ FIFO និងថ្នាក់សេវាកម្មតែមួយ។ សូមយកចិត្តទុកដាក់ចំពោះភាពខុសគ្នាទាំងនេះ។

ទីពីរ កុំគិតថាវិធីសាស្រ្តនេះគឺជាប្រព័ន្ធគ្រប់គ្រងដែលមើលឃើញ។ ការមើលឃើញនៃការងារដែលកំពុងដំណើរការដែលត្រូវបានសម្រេចជាមួយនឹងក្តារខៀនគឺមានប្រយោជន៍ណាស់ ប៉ុន្តែវាគ្រាន់តែជាទិដ្ឋភាពតូចមួយនៃវិធីសាស្រ្តនេះប៉ុណ្ណោះ។ ប្រសិនបើអ្នកអានសៀវភៅនេះដោយយកចិត្តទុកដាក់ អ្នកនឹងឃើញរឿងដែលគួរឱ្យចាប់អារម្មណ៍ជាច្រើននៅក្នុងនោះ។ ព័ត៌មានដ៏មានតម្លៃបំផុតត្រូវបានលាក់ ជាឧទាហរណ៍ ក្នុងទិដ្ឋភាពដូចជារចនាសម្ព័ន្ធនៃដំណើរការសម្រាប់ការទទួល និងបញ្ជូនកិច្ចការ ការគ្រប់គ្រងធនធានដែលមិនអាចជំនួសបាន និងការប្រើប្រាស់ថ្នាក់សេវាកម្ម។ កុំរំខានដោយផ្នែកដែលមើលឃើញ បើមិនដូច្នេះទេ អ្នកនឹងខកខានពេលដ៏រំភើបបំផុត។

ទី៣ កុំបញ្ចុះតម្លៃវិធីទាំងនេះព្រោះវាហាក់ដូចជាងាយស្រួលប្រើពេក។ ភាពងាយស្រួលនៃការប្រើប្រាស់គឺជាលទ្ធផលនៃគំនិតរបស់ David អំពីរបៀបដើម្បីទទួលបានអត្ថប្រយោជន៍អតិបរមាជាមួយនឹងលទ្ធផលអប្បបរមា។ គាត់ដឹងពីតម្រូវការរបស់អ្នកអនុវត្តយ៉ាងច្បាស់ ហើយបានយកចិត្តទុកដាក់យ៉ាងខ្លាំងចំពោះអ្វីដែលពិតជាដំណើរការ។ វិធីសាស្រ្តសាមញ្ញបង្ហាញពីស្ថេរភាពខ្ពស់ហើយស្ទើរតែតែងតែនាំទៅរកលទ្ធផលល្អបំផុតក្នុងរយៈពេលវែង។

នេះគឺជាសៀវភៅដ៏គួរឱ្យចាប់អារម្មណ៍ និងចាំបាច់ ហើយសមនឹងទទួលបានការសិក្សាដោយប្រុងប្រយ័ត្ន។ កម្រិតនៃអត្ថប្រយោជន៍ដែលអ្នកទទួលបានពីវាអាស្រ័យទៅលើថាតើអ្នកយកចិត្តទុកដាក់ក្នុងការអានកម្រិតណា។ គ្មានសៀវភៅផ្សេងទៀតនឹងណែនាំអ្នកអំពីគំនិតទំនើបទាំងនេះប្រសើរជាងនេះទេ។ ខ្ញុំសង្ឃឹមថាអ្នករីករាយនឹងវាដូចដែលខ្ញុំធ្វើ។

Don Reinertsen,

ផ្នែក I
មូលដ្ឋាន

ជំពូកទី 1
ការដោះស្រាយភាពលំបាករបស់អ្នកគ្រប់គ្រង Agile

ក្នុងឆ្នាំ 2002 ខ្ញុំជាអ្នកគ្រប់គ្រងផ្នែកអភិវឌ្ឍន៍នៅការិយាល័យដាច់ស្រយាលរបស់ក្រុមហ៊ុន Motorola នៅទីក្រុង Seattle នៃផ្នែកទូរស័ព្ទចល័តរបស់ Motorola (វាត្រូវបានគេហៅថា PCS) ហើយបានរកឃើញថាខ្លួនខ្ញុំស្ថិតក្នុងស្ថានភាពលំបាកមួយ។ នាយកដ្ឋានរបស់ខ្ញុំគឺជាផ្នែកមួយនៃការចាប់ផ្តើមដែលក្រុមហ៊ុន Motorola ទទួលបានកាលពីឆ្នាំមុន។ យើងបានបង្កើតកម្មវិធីបណ្តាញសម្រាប់ការបញ្ជូនទិន្នន័យឥតខ្សែ ដូចជាការទាញយកឥតខ្សែ និងការគ្រប់គ្រងឧបករណ៍។ កម្មវិធី back-end ទាំងនេះគឺជាផ្នែកមួយនៃប្រព័ន្ធរួមបញ្ចូលគ្នាដែលត្រូវបានភ្ជាប់យ៉ាងតឹងរ៉ឹងទៅនឹងលេខកូដអតិថិជនទូរស័ព្ទចល័ត ក៏ដូចជាធាតុផ្សេងទៀតនៅក្នុងបណ្តាញទូរគមនាគមន៍ និងហេដ្ឋារចនាសម្ព័ន្ធប្រតិបត្តិការ ដូចជាការចេញវិក្កយបត្រជាដើម។ ថ្ងៃផុតកំណត់ត្រូវបានកំណត់ដោយអ្នកគ្រប់គ្រងដែលមិនយកចិត្តទុកដាក់លើភាពស្មុគស្មាញផ្នែកវិស្វកម្មនៃគម្រោង ហានិភ័យ ឬទំហំរបស់វា។ កូដស្នូលបានវិវត្តន៍ពីការចាប់ផ្ដើមដំបូង ដោយលក្ខណៈពិសេសជាច្រើនដែលបានគ្រោងទុកពីដំបូងត្រូវបានពន្យារពេលរហូតដល់ពេលក្រោយ។ អ្នកអភិវឌ្ឍន៍ជាន់ខ្ពស់ម្នាក់បានទទូចថាផលិតផលរបស់យើងត្រូវបានគេហៅថា "គំរូ" ។ យើងត្រូវការយ៉ាងខ្លាំងដើម្បីបង្កើនផលិតភាព និងគុណភាពផលិតផល ដើម្បីបន្តតាមតម្រូវការរបស់អាជីវកម្ម។

នៅក្នុងសកម្មភាពប្រចាំថ្ងៃរបស់ខ្ញុំក្នុងឆ្នាំ 2002 និងនៅក្នុងដំណើរការនៃការធ្វើការលើសៀវភៅមុន។ 1
Anderson, David J. ការគ្រប់គ្រងរហ័សរហួនសម្រាប់វិស្វកម្មកម្មវិធី៖ ការអនុវត្តទ្រឹស្តីនៃឧបសគ្គសម្រាប់លទ្ធផលអាជីវកម្ម. Upper Saddle River, NJ: Prentice Hall, 2003 ។

ខ្ញុំមានការព្រួយបារម្ភជាចម្បងជាមួយនឹងបញ្ហាពីរ។ ទីមួយ របៀបការពារក្រុមពីការទាមទារដែលកំពុងកើនឡើងនៃអាជីវកម្ម និងសម្រេចបាននូវអ្វីដែលឥឡូវនេះហៅថា "ល្បឿនល្អបំផុត" នៅក្នុងសហគមន៍ដែលមានភាពរហ័សរហួន។ ហើយទីពីរ តើខ្ញុំអាចអនុវត្តវិធីសាស្រ្តរហ័សរហួននៅទូទាំងអង្គភាពដោយជោគជ័យដោយរបៀបណា ដើម្បីយកឈ្នះលើការតស៊ូដែលជៀសមិនរួចក្នុងការផ្លាស់ប្តូរ?

ការស្វែងរកល្បឿនត្រឹមត្រូវ។

ក្នុងឆ្នាំ 2002 សហគមន៍រហ័សរហួនបានគិតថា ល្បឿនដ៏ល្អប្រសើរគឺគ្រាន់តែជា "សប្តាហ៍ធ្វើការ 40 ម៉ោង"។ 2
Beck, Kent ។ ការសរសេរកម្មវិធីខ្លាំងបានពន្យល់៖ ទទួលយកការផ្លាស់ប្តូរ។បូស្តុន: Addison Wesley, 2000. ការបោះពុម្ពជាភាសារុស្សី: Beck K. Extreme Programming ។ សាំងពេទឺប៊ឺគៈ ពេត្រុស ឆ្នាំ ២០០២។

គោលការណ៍នៃសេចក្តីប្រកាស Agile 3
Beck, Kent et al ។ , "គោលការណ៍នៅពីក្រោយការតាំងបង្ហាញភាពរហ័សរហួន។" http://www.agilemanifesto.org/principles.html ។ ការបកប្រែជាភាសារុស្សី៖ http://agilemanifesto.org/iso/ru/principles.html ។

ពួកគេបាននិយាយថា "ដំណើរការរហ័សរហួនរួមចំណែកដល់ការអភិវឌ្ឍន៍ដ៏ល្អប្រសើរ។ អ្នកឧបត្ថម្ភ អ្នកអភិវឌ្ឍន៍ និងអ្នកប្រើប្រាស់ត្រូវតែត្រៀមខ្លួនដើម្បីរក្សាល្បឿនថេរដោយគ្មានកំណត់។ កាលពីពីរឆ្នាំមុន ក្រុមការងាររបស់ខ្ញុំនៅ Sprint PCS បានបន្តឮពីខ្ញុំថា "ការអភិវឌ្ឍន៍កម្មវិធីតាមខ្នាតគឺជាការរត់ម៉ារ៉ាតុង មិនមែនជាការរត់ប្រណាំងនោះទេ។" ប្រសិនបើសមាជិកក្រុមត្រូវរក្សាល្បឿនថេរក្នុងដំណើរការនៃការធ្វើការលើគម្រោងរយៈពេលមួយឆ្នាំកន្លះ នោះពួកគេមិនអាចត្រូវបានអនុញ្ញាតឱ្យឆេះអស់ក្នុងរយៈពេលមួយខែ ឬពីរខែនោះទេ។ គម្រោងនេះត្រូវតែរៀបចំផែនការ រៀបចំថវិកា កំណត់ពេលវេលា និងវាយតម្លៃ ដើម្បីធានាថាសមាជិកក្រុមបានចំណាយពេលវេលាសមស្របក្នុងការងារជារៀងរាល់ថ្ងៃ និងមិនហត់នឿយពេក។ ក្នុងនាមជាអ្នកគ្រប់គ្រង ភារកិច្ចរបស់ខ្ញុំគឺដើម្បីសម្រេចគោលដៅនេះ។ និងបំពេញតាមតម្រូវការអាជីវកម្មទាំងអស់។

នៅពេលដែលខ្ញុំនៅក្នុងមុខតំណែងជាអ្នកគ្រប់គ្រងដំបូងរបស់ខ្ញុំ (វាគឺនៅក្នុងឆ្នាំ 1991 នៅពេលចាប់ផ្តើមដែលបង្កើតក្តារថតវីដេអូសម្រាប់កុំព្យូទ័រផ្ទាល់ខ្លួន និងតូចជាង) នាយកប្រតិបត្តិ។ 3
នាយកប្រតិបត្តិ - នាយកប្រតិបត្តិ (CEO) ។ ចំណាំ។ ed ។

គាត់បាននិយាយថាអ្នកគ្រប់គ្រងមានគំនិតអវិជ្ជមានខ្លាំងអំពីខ្ញុំ។ ខ្ញុំតែងតែឆ្លើយថា "ទេ" នៅពេលដែលឱកាសរបស់យើងជាអ្នកអភិវឌ្ឍន៍បានអស់ហើយ ហើយផលិតផល ឬមុខងារកាន់តែច្រើនត្រូវបានទាមទារពីពួកយើង។ ដល់ឆ្នាំ 2002 ខ្ញុំបានក្លាយទៅជាទម្លាប់មួយ៖ ខ្ញុំបានចំណាយពេលដប់ឆ្នាំទៀតដោយមិនព្រមធ្វើតាមការចង់បានរបស់ម្ចាស់អាជីវកម្ម។

ក្រុមអភិវឌ្ឍន៍ និងនាយកដ្ឋាន IT នៃក្រុមហ៊ុនគឺពឹងផ្អែកយ៉ាងខ្លាំងទៅលើក្រុមផ្សេងទៀតដែលតែងតែចរចា សុំទាន គំរាមកំហែង និងដំណើរការឡើងវិញ សូម្បីតែផែនការដែលបានរចនាច្បាស់លាស់ និងច្បាស់លាស់បំផុតក៏ដោយ។ ភាពងាយរងគ្រោះក៏រួមបញ្ចូលផងដែរនូវផែនការដោយផ្អែកលើការវិភាគដោយប្រុងប្រយ័ត្ន និងបទពិសោធន៍ជាប្រវត្តិសាស្ត្រ។ ក្រុមភាគច្រើន ខ្វះការវិភាគហ្មត់ចត់ និងបទពិសោធន៍ជាប្រវត្តិសាស្ត្រ មិនអាចទប់ទល់នឹងអ្នកដែលបានជំរុញឱ្យពួកគេទទួលយកការប្តេជ្ញាចិត្តដែលមិនច្បាស់លាស់ និងជាញឹកញាប់មិនអាចទៅរួចនោះទេ។

ក្នុងពេលជាមួយគ្នានេះ និយោជិតបានយល់ស្របជាមួយនឹងបន្ទុកការងារដ៏ឆ្កួតលីលា ហើយបន្ទុកការងារហួសប្រមាណបានក្លាយជាបទដ្ឋាន។ គ្មាននរណាម្នាក់ហាក់ដូចជាបានគិតអំពីការពិតដែលថាវិស្វករកម្មវិធីក៏អាចមានជីវិតសង្គមឬគ្រួសារដែរ។ ស្តាប់ទៅព្រឺព្រួច តែវាជាការពិត! ខ្ញុំដឹងឧទាហរណ៍ច្រើនពេក ដែលបន្ទុកការងារលើសចំណុះបានបំផ្លាញទំនាក់ទំនងគ្រួសារជារៀងរហូត។ វាពិបាកនឹងអាណិតអ្នកអភិវឌ្ឍន៍ធម្មតាណាស់។ នៅក្នុងរដ្ឋ Washington ដែលជាផ្ទះរបស់ខ្ញុំ ប្រាក់ចំណូលរបស់វិស្វករផ្នែកទន់គឺស្ថិតនៅលំដាប់ទីពីរបន្ទាប់ពីទន្តបណ្ឌិត។ ដូចនៅសម័យក្រុមហ៊ុន Ford ពោលគឺក្នុងទសវត្សរ៍ឆ្នាំ 1920 នៅពេលដែលមនុស្សនៅក្នុងរោងចក្ររបស់គាត់រកបាន 5 ដងច្រើនជាងមធ្យមភាគជាតិ វាមិនដែលកើតឡើងចំពោះនរណាម្នាក់ក្នុងការគិតអំពីភាពឯកកោនៃការងារ ឬសុខុមាលភាពរបស់អ្នកឯកទេសទេ: ពួកគេគឺជា បង់ច្រើនណាស់! វាពិបាកក្នុងការស្រមៃមើលសហជីពការងារនៅក្នុងឧស្សាហកម្មដែលផ្អែកលើចំណេះដឹង ដូចជាការអភិវឌ្ឍន៍កម្មវិធី ពីព្រោះគ្មាននរណាម្នាក់នឹងពិនិត្យឱ្យបានហ្មត់ចត់អំពីមូលហេតុនៃជម្ងឺផ្លូវកាយ និងផ្លូវចិត្តដែលជួបប្រទះដោយអ្នកអភិវឌ្ឍន៍នោះទេ។ ឧទាហរណ៍ និយោជកដែលមានទំនួលខុសត្រូវច្រើនជាងមុន ផ្តល់វិធានការដូចជាការម៉ាស្សា ឬការព្យាបាលចិត្តសាស្ត្រ។ ឬពួកគេចំណាយពេលថ្ងៃសុខភាពផ្លូវចិត្ត - ហើយនេះគឺជំនួសឱ្យការយកចិត្តទុកដាក់ក្នុងការសិក្សាពីមូលហេតុឫសគល់នៃបញ្ហា។ អ្នកនិពន្ធបច្ចេកទេសនៅក្រុមហ៊ុនសូហ្វវែរល្បីមួយធ្លាប់ប្រាប់ខ្ញុំថា "មិនអីទេប្រសិនបើខ្ញុំប្រើថ្នាំប្រឆាំងនឹងជំងឺធ្លាក់ទឹកចិត្តព្រោះមនុស្សគ្រប់គ្នាធ្វើ!" អ្នកសរសេរកម្មវិធីជាធម្មតាទៅជាមួយការទាមទារទាំងអស់ ទទួលបានប្រាក់ខែល្អ និងទទួលរងនូវផលវិបាក។ ខ្ញុំចង់ផ្លាស់ប្តូរស្ថានភាពនេះ ដើម្បីស្វែងរកវិធីសាស្រ្តឈ្នះ-ឈ្នះ ដែលអាចឱ្យខ្ញុំនិយាយថាបាទ/ចាស ហើយនៅតែការពារក្រុមរបស់ខ្ញុំ ដោយធានាថា ល្បឿនដ៏ល្អប្រសើរត្រូវបានសម្រេច។ ខ្ញុំចង់នាំសមាជិកក្រុមរបស់ខ្ញុំត្រឡប់ទៅសហគមន៍ និងគ្រួសារវិញ ហើយកែលម្អលក្ខខណ្ឌដែលបង្កឱ្យមានភាពតានតឹង និងបញ្ហាសុខភាពសម្រាប់អ្នកអភិវឌ្ឍន៍ដែលមានអាយុក្រោមសាមសិបឆ្នាំ។ ដូច្នេះ ខ្ញុំបានសម្រេចចិត្តចាប់ផ្តើមដោះស្រាយបញ្ហាទាំងនេះ។

ក្នុងការស្វែងរកការគ្រប់គ្រងការផ្លាស់ប្តូរជោគជ័យ

បញ្ហាទីពីរដែលមានក្នុងចិត្តខ្ញុំគឺការគ្រប់គ្រងការផ្លាស់ប្តូរនៅក្នុងអង្គការធំៗ។ ខ្ញុំជាអ្នកគ្រប់គ្រងផ្នែកអភិវឌ្ឍន៍នៅ Sprint PCS ហើយបន្ទាប់មកនៅ Motorola ។ នៅក្នុងក្រុមហ៊ុនទាំងពីរ មានតម្រូវការខ្លាំងដើម្បីផ្លាស់ទីទៅវិធីសាស្រ្តការងារដែលអាចបត់បែនបាន។ ប៉ុន្តែនៅក្នុងករណីទាំងពីរនេះ ខ្ញុំមានបញ្ហាក្នុងការអនុវត្តវិធីសាស្ត្ររហ័សរហួនលើក្រុមច្រើនជាងមួយ ឬពីរ។

ទាំងពីរលើកនេះ ខ្ញុំមិនមានសិទ្ធិអំណាចគ្រប់គ្រាន់ដើម្បីគ្រាន់តែបញ្ជាឱ្យមានការផ្លាស់ប្ដូរដើម្បីឱ្យមានក្រុមច្រើន។ ខ្ញុំបានព្យាយាមអនុវត្តការផ្លាស់ប្តូរតាមសំណើរបស់ថ្នាក់ដឹកនាំជាន់ខ្ពស់ ប៉ុន្តែមិនមានសិទ្ធិអំណាចចាំបាច់នោះទេ។ ខ្ញុំត្រូវបានស្នើសុំឱ្យមានឥទ្ធិពលលើមិត្តរួមការងារ ដើម្បីអនុវត្តការផ្លាស់ប្តូរដូចគ្នានៅក្នុងក្រុមរបស់ពួកគេ ដូចដែលខ្ញុំបានធ្វើនៅក្នុងរបស់ខ្ញុំ។ ប៉ុន្តែពួកគេមិនប្រញាប់ប្រញាល់ក្នុងការទទួលយកវិធីសាស្ត្រដែលហាក់ដូចជាដំណើរការល្អបំផុតនៅក្នុងក្រុមរបស់ខ្ញុំ។ ការតស៊ូនេះប្រហែលជាមានហេតុផលជាច្រើន។ ជាញឹកញាប់ជាងនេះទៅទៀត ខ្ញុំបានលឺថាក្រុមនីមួយៗមានស្ថានភាពផ្ទាល់ខ្លួន ហើយវិធីសាស្ត្ររបស់ខ្ញុំនឹងត្រូវកែសម្រួលទៅតាមតម្រូវការជាក់លាក់របស់អ្នកដទៃ។ នៅពាក់កណ្តាលឆ្នាំ 2002 ខ្ញុំបានដឹងថាវាគ្មានប្រយោជន៍ក្នុងការចេញវេជ្ជបញ្ជាយ៉ាងម៉ត់ចត់នូវដំណើរការអភិវឌ្ឍកម្មវិធីណាមួយនោះទេ ពោលគឺវាមិនដំណើរការទេ។

ដំណើរការត្រូវតែសម្របទៅតាមស្ថានភាពជាក់លាក់នីមួយៗ ដូច្នេះការដឹកនាំសកម្មរបស់ក្រុមនីមួយៗត្រូវបានទាមទារ។ ហើយជារឿយៗនេះមិនគ្រប់គ្រាន់ទេ។ ទោះបីជាមានភាពជាអ្នកដឹកនាំត្រឹមត្រូវក៏ដោយ វាមិនមានភាពប្រាកដប្រជាថាការផ្លាស់ប្តូរសំខាន់ៗអាចកើតឡើងដោយគ្មានរចនាសម្ព័ន្ធដែលបានបង្កើតឡើង និងការណែនាំអំពីរបៀបកែតម្រូវដំណើរការទៅតាមស្ថានភាពផ្សេងៗនោះទេ។ ប្រសិនបើអ្នកគ្រប់គ្រង គ្រូបង្វឹក ឬវិស្វករដែលមានទំនួលខុសត្រូវមិនមានគំនិតច្បាស់លាស់អំពីអ្វីដែលត្រូវធ្វើ នោះការសម្របខ្លួនណាមួយទំនងជាប្រធានបទ។ ក្នុងពេលជាមួយគ្នានេះដែរមានប្រូបាបខ្ពស់នៃកំហុស - ឧទាហរណ៍ការណែនាំនៃគំរូដំណើរការមិនសមរម្យ។

ខ្ញុំបានព្យាយាមគ្របដណ្តប់បញ្ហានេះនៅក្នុងសៀវភៅ Agile Management for Software Engineering ដែលខ្ញុំកំពុងសរសេរនៅពេលនោះ។ ខ្ញុំឆ្ងល់ថា "ហេតុអ្វីបានជាការអភិវឌ្ឍន៍រហ័សរហួនផ្តល់លទ្ធផលសេដ្ឋកិច្ចប្រសើរជាងវិធីសាស្រ្តបែបប្រពៃណី?" ខ្ញុំចង់អនុវត្តរចនាសម្ព័ន្ធនៃទ្រឹស្ដីនៃឧបសគ្គក្នុងគោលបំណងនេះ។ 4
Goldratt, Eliyahu M. តើអ្វីទៅជាទ្រឹស្ដីនៃការរឹតត្បិត ហើយតើវាគួរអនុវត្តដោយរបៀបណា? Great Barrington, MA: North River Press, 1999 ។

នៅក្នុងដំណើរការនៃការស្រាវជ្រាវ និងសរសេរសៀវភៅនេះ ខ្ញុំបានដឹងថា គ្រប់ស្ថានភាពទាំងអស់សុទ្ធតែមានតែមួយគត់។ ហើយតើឧបសគ្គ ឬឧបសគ្គអាចដូចគ្នាសម្រាប់ក្រុម និងគម្រោងណាមួយនៅពេលណាក៏បាន? ក្រុមនីមួយៗមានលក្ខណៈប្លែកពីគេ៖ ជំនាញផ្សេងៗគ្នា ឱកាស បទពិសោធន៍។ គម្រោងនីមួយៗមានភាពខុសប្លែកគ្នាពីគម្រោងផ្សេងទៀតទាក់ទងនឹងថវិកា កាលវិភាគ វិសាលភាព និងហានិភ័យ។ អង្គការក៏មានភាពខុសប្លែកគ្នាផងដែរ៖ ពួកគេមានខ្សែសង្វាក់តម្លៃខុសៗគ្នា និងដំណើរការក្នុងទីផ្សារផ្សេងៗគ្នា (រូបភាព 1.1)។ វាហាក់ដូចជាខ្ញុំថា នេះអាចផ្តល់នូវតម្រុយដល់ការយល់ដឹងអំពីភាពធន់នឹងការផ្លាស់ប្តូរ។ ប្រសិនបើការផ្លាស់ប្តូរដែលបានស្នើឡើងនៅក្នុងវិធីសាស្រ្ត និងអាកប្បកិរិយាការងារមិនផ្តល់ឱ្យ នោះតាមគំនិតរបស់និយោជិតដែលជាអត្ថប្រយោជន៍ជាក់ស្តែងនោះគាត់នឹងមិនទទួលយកពួកគេទេ។ ប្រសិនបើការផ្លាស់ប្តូរទាំងនេះមិនប៉ះពាល់ដល់អ្វីដែលក្រុមយល់ថាជាអ្នកកំណត់ ឬរារាំងទេ នោះក្រុមនឹងទប់ទល់។ ម៉្យាងទៀតការផ្លាស់ប្តូរដែលបានស្នើឡើងដោយមិនគិតពីបរិបទនឹងត្រូវបានបដិសេធដោយបុគ្គលិកដែលដឹងពីបរិបទនៃការងារយ៉ាងល្អឥតខ្ចោះ។

អង្ករ។ ១.១. ហេតុអ្វីបានជាវិធីសាស្ត្រអភិវឌ្ឍន៍ទូទៅខុស

វាហាក់ដូចជាថាវានឹងប្រសើរជាងប្រសិនបើដំណើរការថ្មីចាប់ផ្តើមអភិវឌ្ឍ ដោយលុបបំបាត់ដែនកំណត់មួយបន្ទាប់ពីមួយផ្សេងទៀត។ នេះជាចំណុចសំខាន់នៃទ្រឹស្ដីនៃឧបសគ្គរបស់ Goldratt។ ដោយដឹងថាខ្ញុំនៅមានច្រើនដែលត្រូវរៀន ខ្ញុំបានដឹងពីតម្លៃនៃសម្ភារៈ ហើយប្រញាប់ប្រញាល់ឆ្ពោះទៅមុខក្នុងការធ្វើការលើសាត្រាស្លឹករឹត។ វាច្បាស់ណាស់សម្រាប់ខ្ញុំថា សៀវភៅនេះមិនបានផ្តល់ដំបូន្មានអំពីរបៀបអនុវត្តគំនិតក្នុងទ្រង់ទ្រាយធំនោះទេ ហើយក៏មិនបានផ្តល់ជំនួយច្រើនក្នុងការស្វែងរកវិធីដើម្បីគ្រប់គ្រងការផ្លាស់ប្តូរដែរ។

វិធីសាស្រ្តរបស់ Goldratt ដែលត្រូវបានគូសបញ្ជាក់ក្នុង គោលបំណងស្វែងរកដែនកំណត់ ហើយបន្ទាប់មកវិធីដើម្បីលុបបំបាត់ពួកគេ ដើម្បីកុំឱ្យពួកគេរារាំងការអនុវត្ត។ បន្ទាប់ពីនោះ ឧបសគ្គថ្មីមួយកើតឡើង ហើយវដ្តនេះកើតឡើងម្តងទៀត។ វាគឺជាវិធីសាស្រ្តម្តងហើយម្តងទៀតដែលធ្វើអោយប្រសើរឡើងនូវការអនុវត្តជាប្រព័ន្ធដោយកំណត់អត្តសញ្ញាណ និងដកចេញនូវឧបសគ្គ។

ខ្ញុំបានដឹងថាអ្នកអាចបញ្ចូលគ្នានូវវិធីសាស្រ្តនេះជាមួយនឹងបច្ចេកទេសមួយចំនួនពីវិស័យផលិតកម្មគ្មានខ្លាញ់។ តាមរយៈការធ្វើគំរូនៃដំណើរការវដ្តជីវិតនៃការអភិវឌ្ឍន៍កម្មវិធីជាចរន្តតម្លៃ និងបង្កើតប្រព័ន្ធតាមដាន និងការមើលឃើញដើម្បីចាប់យកការផ្លាស់ប្តូរស្ថានភាពនៃការងារដែលកំពុងលេចចេញជា "លំហូរ" តាមរយៈប្រព័ន្ធនោះ ខ្ញុំអាចកំណត់អត្តសញ្ញាណឧបសគ្គ។ សមត្ថភាពក្នុងការកំណត់អត្តសញ្ញាណឧបសគ្គគឺជាជំហានដំបូងឆ្ពោះទៅរកគំរូមូលដ្ឋាននៃ TOC ។ Goldratt បានបង្កើតកម្មវិធីនៃទ្រឹស្តីនេះរួចហើយចំពោះបញ្ហាលំហូរការងារដែលមានឈ្មោះច្របូកច្របល់នៃ "ស្គរ-សតិបណ្ដោះអាសន្ន-ខ្សែពួរ" ។ ទោះយ៉ាងណាក៏ដោយ ខ្ញុំបានដឹងថា កំណែសាមញ្ញនៃប្រព័ន្ធនេះអាចត្រូវបានអនុវត្តនៅក្នុងវិស័យនៃការអភិវឌ្ឍន៍កម្មវិធី។

នៅក្នុងលក្ខខណ្ឌនៃប្រភពដើម, drum-buffer-rope គឺជាឧទាហរណ៍នៃថ្នាក់នៃដំណោះស្រាយដែលគេស្គាល់ថាជាប្រព័ន្ធទាញ។ ដូចដែលយើងនឹងឃើញនៅក្នុង kanban ក៏ជាឧទាហរណ៍មួយនៃប្រព័ន្ធប្រភេទនេះផងដែរ។ ផលប៉ះពាល់នៃប្រព័ន្ធទាញគឺថាពួកគេកំណត់ WIP ទៅនឹងចំនួនដែលបានកំណត់ទុកជាមុន ដោយការពារបុគ្គលិកពីការលើសទម្ងន់។ លើសពីនេះ មានតែកម្មករដែលប្រឈមមុខនឹងការរឹតបន្តឹងដោយផ្ទាល់ប៉ុណ្ណោះ នៅតែផ្ទុកពេញ។ អ្នកផ្សេងទៀតគួរតែមានពេលទំនេរ។ ខ្ញុំបានដឹងថាប្រព័ន្ធទាញអាចដោះស្រាយបញ្ហាទាំងពីរដែលធ្វើឱ្យខ្ញុំព្រួយបារម្ភ។ ប្រព័ន្ធទាញនឹងអនុញ្ញាតឱ្យខ្ញុំណែនាំការផ្លាស់ប្តូរបន្ថែម ដែល (ខ្ញុំសង្ឃឹមថា) នឹងកាត់បន្ថយការតស៊ូយ៉ាងខ្លាំងចំពោះពួកគេ ក៏ដូចជាធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការសម្រេចបាននូវល្បឿនដ៏ល្អប្រសើរ។ ខ្ញុំបានសម្រេចចិត្តប្តូរទៅប្រព័ន្ធស្គរ-សតិបណ្ដោះអាសន្ន-ខ្សែពួរឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន។ ខ្ញុំចង់ពិសោធជាមួយការវិវត្តនៃដំណើរការបន្ថែម ហើយមើលថាតើវាផ្តល់ល្បឿនដ៏ល្អប្រសើរ និងកាត់បន្ថយភាពធន់នឹងការផ្លាស់ប្តូរដែរឬទេ។

ឱកាសបែបនេះបានលេចឡើងនៅរដូវស្លឹកឈើជ្រុះឆ្នាំ 2004 នៅក្រុមហ៊ុន Microsoft ដែលត្រូវបានពិពណ៌នាលម្អិតនៅក្នុងសៀវភៅនេះក្នុងការវិភាគឧទាហរណ៍។

ពីស្គរ - សតិបណ្ដោះអាសន្ន - ខ្សែទៅកានបាន

ដំណោះស្រាយ Drum-buffer-rope នៅក្រុមហ៊ុន Microsoft បានបង់ផ្តាច់។ ភាពធន់ខ្សោយ ដំណើរការច្រើនជាងបីដង ពេលវេលានាំមុខត្រូវបានកាត់បន្ថយ 90% ហើយការព្យាករណ៍បានប្រសើរឡើង 98% ។ នៅរដូវស្លឹកឈើជ្រុះឆ្នាំ 2005 ខ្ញុំបានរាយការណ៍អំពីលទ្ធផលដែលសម្រេចបាននៅក្នុងសន្និសីទមួយនៅទីក្រុងបាសេឡូណា 5
Anderson, David J., និង Dragos Dumitriu, "ពីអាក្រក់បំផុតទៅល្អបំផុតក្នុងរយៈពេល 9 ខែ: ការអនុវត្តដំណោះស្រាយ Drum-Buffer-Rope នៅក្នុងនាយកដ្ឋានព័ត៌មានវិទ្យារបស់ Microsoft" ការបន្តនៃសន្និសីទ TOCICO World Conference, Barcelona, ខែវិច្ឆិកា 2005 ។

ហើយក្នុងរដូវរងាឆ្នាំ ២០០៦ គាត់បានធ្វើរបាយការណ៍មួយទៀត។ ការងាររបស់ខ្ញុំបានទាក់ទាញចំណាប់អារម្មណ៍របស់ Donald Reinertsen ដែលបានធ្វើទស្សនកិច្ចពិសេសទៅកាន់ការិយាល័យរបស់ខ្ញុំនៅ Redmond ។ គាត់ចង់ធានាខ្ញុំថាអ្វីគ្រប់យ៉ាងបានត្រៀមខ្លួនជាស្រេចសម្រាប់ការផ្លាស់ប្តូរពេញលេញទៅកាន់ Kanban ។

Kan-ban -ពាក្យជប៉ុនដែលបកប្រែតាមព្យញ្ជនៈទៅជា "បន្ទះសញ្ញា" ។ នៅក្នុងការផលិត បន្ទះក្តារបែបនេះត្រូវបានប្រើដើម្បីមើលឃើញពីការកើនឡើងនៃល្បឿនផលិតកម្ម ដែលអនុញ្ញាតឱ្យផលិតផលិតផលកាន់តែច្រើន។ និយោជិតនៅដំណាក់កាលនីមួយៗនៃដំណើរការមិនអាចបន្តទៅដំណាក់កាលបន្ទាប់នៃការងារបានទេ រហូតទាល់តែមានសញ្ញាសមរម្យត្រូវបានផ្តល់ឱ្យតាមរយៈក្រុមប្រឹក្សាភិបាល kanban ។ ទោះបីជាខ្ញុំបានដឹងអំពីអត្ថិភាពនៃយន្តការនេះក៏ដោយ ខ្ញុំមិនជឿថាវាមានប្រយោជន៍ ឬសូម្បីតែអាចដំណើរការបានទាក់ទងនឹងការងារបញ្ញា ជាពិសេសការអភិវឌ្ឍន៍កម្មវិធី។ ខ្ញុំបានយល់ថា kanban ផ្តល់នូវល្បឿនដ៏ល្អប្រសើរ ប៉ុន្តែមិនដឹងអំពីកេរ្តិ៍ឈ្មោះដ៏ល្អរបស់វា ជាវិធីសាស្រ្តនៃការលើកទឹកចិត្តដល់ការកែលម្អដំណើរការបន្ថែម។ ខ្ញុំមិនដឹងថា Taiichi Ohno ដែលជាអ្នកបង្កើតប្រព័ន្ធផលិតកម្មតូយ៉ូតា បាននិយាយថា “គោលការណ៍សំខាន់ពីរនៃប្រព័ន្ធផលិតកម្មតូយ៉ូតា គឺស្វ័យប្រវត្តិកម្មដែលជួយមនុស្សបានទាន់ពេលវេលា និងស្វ័យប្រវត្តិកម្ម ឬស្វ័យភាព។ ឧបករណ៍មួយត្រូវបានប្រើដើម្បីគ្រប់គ្រងប្រព័ន្ធ - នេះគឺជា kanban ។ ម្យ៉ាងវិញទៀត Kanban មានសារៈសំខាន់ចំពោះដំណើរការនេះ។ កៃហ្សេន("ការកែលម្អជាបន្តបន្ទាប់") ដែលប្រើប្រាស់ដោយក្រុមហ៊ុនតូយ៉ូតា។ វាគឺជាយន្តការដែលធ្វើឱ្យប្រព័ន្ធដំណើរការ។ ឥឡូវនេះ ជាមួយនឹងបទពិសោធន៍ប្រាំឆ្នាំនៅពីក្រោយខ្ញុំ ខ្ញុំទទួលយកការពិតទាំងស្រុង។

ជាសំណាងល្អ ដុន បានបង្កើតករណីដ៏គួរឱ្យទាក់ទាញមួយសម្រាប់ការប្តូរពីស្គរ - សតិបណ្ដោះអាសន្ន - ខ្សែពួរទៅជា kanban ។ វាស្តាប់ទៅដូចជា esoteric: ប្រព័ន្ធ kanban ផ្តល់នូវការផ្លាស់ប្តូរយ៉ាងរលូនពីពេលវេលារងចាំទៅការស្ទះជាជាងស្គរ-សតិបណ្ដោះអាសន្ន-ខ្សែពួរ។ ទោះជាយ៉ាងណាក៏ដោយ ការយល់ដឹងពីភាពខុសគ្នានេះគឺមិនសំខាន់ទេក្នុងការអាន និងស្វែងយល់សៀវភៅនេះ។

ដោយពិនិត្យមើលឡើងវិញនូវដំណោះស្រាយដែលអនុវត្តដោយ Microsoft ខ្ញុំបានដឹងថា ប្រសិនបើយើងយល់ភ្លាមៗថាវាជាលទ្ធផលនៃប្រព័ន្ធ kanban នោះលទ្ធផលនឹងដូចគ្នា។ ខ្ញុំបានរកឃើញថាវាគួរឱ្យចាប់អារម្មណ៍ដែលវិធីសាស្រ្តពីរផ្សេងគ្នានាំទៅរកលទ្ធផលដូចគ្នា។ ដូច្នេះ ដោយសារវាជាដំណើរការដូចគ្នា ខ្ញុំមិនមានអារម្មណ៍ថាត្រូវមើលវាជាផលិតផលរបស់ប្រព័ន្ធស្គរបណ្ដោះអាសន្នទេ។

ខ្ញុំចាប់ផ្តើមចូលចិត្តពាក្យ "kanban" ចំពោះឃ្លាដ៏ស្មុគស្មាញនេះ។ វាត្រូវបានប្រើនៅក្នុងការផលិតគ្មានខ្លាញ់ (ដូចគ្នានឹងប្រព័ន្ធផលិតកម្ម Toyota) ។ អង្គភាពនៃចំណេះដឹងនេះបានទទួលការចែកចាយ និងការទទួលស្គាល់ច្រើនជាងទ្រឹស្តីនៃឧបសគ្គ។ Kanban ទោះបីជាមានដើមកំណើតពីប្រទេសជប៉ុនក៏ដោយ វាមានអត្ថន័យតិចជាងស្គរ ទ្រនាប់ និងខ្សែពួររួមបញ្ចូលគ្នា។ ពាក្យនេះងាយស្រួលនិយាយ ពន្យល់ ហើយដូចដែលវាបានប្រែក្លាយនៅពេលក្រោយ ដើម្បីបង្រៀន និងអនុវត្ត។ នេះជាកន្លែងដែលវាជាប់គាំង។

ការលេចឡើងនៃវិធីសាស្រ្ត kanban

នៅខែកញ្ញា ឆ្នាំ 2006 ខ្ញុំបានចាកចេញពី Microsoft ដើម្បីដឹកនាំការអភិវឌ្ឍន៍កម្មវិធីនៅ Corbis ដែលជាក្រុមហ៊ុនផ្ទុករូបថត និងកម្មសិទ្ធិបញ្ញាឯកជនដែលមានទីតាំងនៅកណ្តាលទីក្រុង Seattle ។ ដោយមានការបំផុសគំនិតដោយអ្វីដែលក្រុមហ៊ុន Microsoft សម្រេចបាន ខ្ញុំបានសម្រេចចិត្តអនុវត្តប្រព័ន្ធទាញ kanban នៅក្នុង Corbis ។ នៅទីនេះផងដែរ លទ្ធផលបានទទួលជោគជ័យយ៉ាងខ្លាំង ដែលនាំទៅដល់ការអភិវឌ្ឍន៍នៃគំនិតភាគច្រើនដែលបានបង្ហាញនៅក្នុងសៀវភៅនេះ។ វាគឺជាសំណុំបន្ថែមនៃគំនិតទាំងនោះ—ការមើលឃើញលំហូរការងារ ប្រភេទធាតុលំហូរការងារ ចំណាត់ថ្នាក់ ថ្នាក់នៃសេវាកម្ម របាយការណ៍គ្រប់គ្រងពិសេស និងការវិភាគសកម្មភាព ដែលកំណត់វិធីសាស្ត្រ Kanban ។

នៅក្នុងសៀវភៅនេះ ខ្ញុំបានពិពណ៌នាអំពី Kanban (អក្សរធំ) ជាវិធីសាស្រ្តនៃការផ្លាស់ប្តូរវិវត្តន៍ដោយប្រើប្រព័ន្ធទាញ kanban (អក្សរតូច) ការមើលឃើញ និងឧបករណ៍ផ្សេងទៀតដើម្បីជំរុញការបញ្ចូលគំនិតគ្មានខ្លាញ់ទៅក្នុងការអភិវឌ្ឍន៍បច្ចេកវិទ្យា និងប្រតិបត្តិការ IT ។ វាគឺជាដំណើរការវិវត្តន៍មួយជំហានម្តងៗ។ Kanban អនុញ្ញាតឱ្យអ្នកសម្រេចបាននូវការបង្កើនប្រសិទ្ធភាពដំណើរការជាក់លាក់តាមបរិបទ ជាមួយនឹងការតស៊ូតិចតួចបំផុតក្នុងការផ្លាស់ប្តូរ ខណៈពេលដែលរក្សាបាននូវល្បឿនដ៏ល្អប្រសើរសម្រាប់អ្នកពាក់ព័ន្ធទាំងអស់។

សៀវភៅ Kanban របស់ David Anderson កាន់កាប់ពីទំព័រទីមួយ។

ជាមួយនឹងរូបភាព ក្រាហ្វ និងការសន្និដ្ឋានជីវប្រវត្តិសង្ខេបរបស់លោក David បង្ហាញពីវិធីសាស្រ្ត Kanban សម្រាប់ការគ្រប់គ្រងគម្រោងដ៏ឈ្លាសវៃ។ ការគ្រប់គ្រងគម្រោងគឺគួរឱ្យចាប់អារម្មណ៍នៅពេលដែលបានប្រាប់នៅក្នុងមនុស្សដំបូងដោយអ្នកអភិវឌ្ឍន៍ផ្ទាល់នៃវិធីសាស្រ្តនេះ។

អំពីអ្នកនិពន្ធ

បានចុះបញ្ជីនៅលើប្លក់ផ្លូវការរបស់ David J Anderson ដូចទំ ប្រធានក្រុមហ៊ុន Lean Kanban Inc. គាត់ក៏ tអ្នកគ្រប់គ្រង និងអ្នកប្រឹក្សាយោបល់តាំងពីទសវត្សរ៍ឆ្នាំ 2000 វាគ្មិន និងជាម្ចាស់ផ្ទះសន្និសីទតាំងពីឆ្នាំ 2005 ។ ជាលើកដំបូងនៅក្នុងតំណែងជាអ្នកដឹកនាំ គាត់ស្ថិតនៅក្នុងឆ្នាំ 1991 ដូច្នេះបទពិសោធន៍របស់គាត់អនុញ្ញាតឱ្យអ្នកប្រៀបធៀប kanban និង waterfall ដោយស្មោះត្រង់ ភាពរហ័សរហួន ច្របូកច្របល់ និងវិធីសាស្រ្តគ្រប់គ្រងគម្រោងផ្សេងទៀត។

គាត់បានបង្កើត kanban ដើម្បីបង្កើនកម្រិតនៃការងារបញ្ញា និងច្នៃប្រឌិត។ គោលដៅរបស់ David គឺដើម្បីចែកចាយទាន់ពេលវេលា បំពេញតាមគោលដៅ និងគ្រប់គ្រងក្រុមហ៊ុនទំនើបទូទៅឱ្យបានគ្រប់គ្រាន់។

ដោយប្រើឧទាហរណ៍ជាក់ស្តែងពីជីវិតរបស់ Microsoft, Motorola និង Corbis គាត់បានប្រាប់ និងបង្ហាញគោលការណ៍ វិធីសាស្រ្ត និងការណែនាំសម្រាប់ការអនុវត្ត kanban នៅក្នុងក្រុមហ៊ុនមួយ។

បន្ទុកអត្ថន័យ និងខ្លឹមសារនៃសៀវភៅ

សៀវភៅ . ផ្លូវជំនួសទៅAgile ត្រូវបានសរសេរដោយអ្នកដែលបង្កើត kanban តាំងពីដំបូង។សៀវភៅនេះគួរឱ្យចាប់អារម្មណ៍ និងផ្តល់ព័ត៌មានណាស់។ នៅទីនេះ ខ្សែបន្ទាត់រវាងទស្សនវិជ្ជារបស់ Kaizen ត្រូវបានបង្ហាញយ៉ាងគួរឱ្យចាប់អារម្មណ៍ ( ការកែលម្អជាបន្តបន្ទាប់), វិធីសាស្រ្ត ( គ្មានខ្លាញ់) និង Kanban (វិធីសាស្រ្តនៃការអភិរក្សធនធានមនុស្ស និងសម្ភារៈ)។

Kaizen គឺជាទស្សនវិជ្ជា និងក្រមសីលធម៌នៃទំនាក់ទំនងរវាងកម្មកររោងចក្រ និងការគ្រប់គ្រង។

ការផលិតគ្មានខ្លាញ់គឺប្រព័ន្ធគ្រប់គ្រងគម្រោងដែលត្រូវបានបង្កើតឡើងនៅក្រុមហ៊ុនតូយ៉ូតា ដើម្បីលុបការខ្ជះខ្ជាយពេលវេលា និងធនធានទាំងអស់ចេញពីដំណើរការរបស់ក្រុមហ៊ុន។

កាន់បានគឺជាវិធីសាស្រ្តគ្រប់គ្រងគម្រោងដែលផ្តល់មធ្យោបាយមួយ។កំណត់ភារកិច្ចដែលកំពុងដំណើរការក្នុងពេលដំណាលគ្នា។ ប្រសិនបើមានដែនកំណត់លើមនុស្ស ឧបករណ៍ ឬពេលវេលា kanban ជួយចែកចាយកិច្ចការ និងគម្រោង។

Anderson ត្រូវបានជះឥទ្ធិពលយ៉ាងខ្លាំងដោយទ្រឹស្តីនៃឧបសគ្គក្នុងការសរសេរសៀវភៅនេះ។ សៀវភៅនេះពោរពេញដោយដែនកំណត់ WIP ឧបសគ្គ និងសមត្ថភាពដោយស្មោះត្រង់កំណត់ការផ្ទុកអតិបរមាក្នុងមួយឯកតានៃពេលវេលាដែលរក្សាគុណភាពនៅកម្រិតដ៏ល្អប្រសើរមួយ។

ទ្រឹស្តីនៃឧបសគ្គ (TOC) របស់បណ្ឌិត Eliyahu Goldratt គឺជាវិធីសាស្រ្តគ្រប់គ្រងអាជីវកម្មផលិតកម្ម។ រូបវិទូជនជាតិអ៊ីស្រាអែលម្នាក់បានបង្កើតទ្រឹស្ដី និងវិធីសាស្រ្តជាក់ស្តែងសម្រាប់ការគ្រប់គ្រងអង្គការ ក្បួនដោះស្រាយសម្រាប់ប្រតិបត្តិការផលិតកម្ម ការដឹកជញ្ជូន និងទីផ្សារទំនិញ។ វិធីសាស្រ្តជាប្រព័ន្ធក្នុងការកំណត់អត្តសញ្ញាណឧបសគ្គនៅក្នុងក្រុមហ៊ុនជួយរៀបចំអ្វីៗគ្រប់យ៉ាង។ យោងតាមបទពិសោធន៍របស់ Goldratt ។ ជាញឹកញាប់ជាងនេះទៅទៀត គោលការណ៍ក្រុមហ៊ុនក្លាយជាឧបសគ្គ។

ដែនកំណត់ WIP (កំពុងដំណើរការ) - ចំនួនកិច្ចការដែលអាចបើកក្នុងពេលតែមួយ។

Bottleneck - ពេលមួយនៅក្នុងលំហូរការងារនៅពេលដែលមានភាពធ្ងន់ធ្ងរ ដែនកំណត់ធនធាន ឬឱកាស. នៅលើដ្យាក្រាម វាពិតជាមើលទៅដូចជាកតូចចង្អៀតនៃដបមួយ៖ ទាំងមុន និងក្រោយស្ថានភាពបែបនេះ បន្ទាត់ពង្រីកនៅលើដ្យាក្រាម។

ស្តេរ៉េអូអំពី kanban

នៅពេលដែលយើងឮអំពី kanban យើងតែងតែស្រមៃមើលក្តារដែលមានស្ទីគ័រ - គំរូនេះត្រូវបានដាក់លើយើងដោយប្រព័ន្ធផ្សព្វផ្សាយ។ តាមន័យធៀប មានបញ្ជីនៃកិច្ចការបិទបើក ដំណើរការ និងបញ្ចប់នៅលើជញ្ជាំង។ . អ្នកអាចប្រើជញ្ជាំងនិម្មិត និងកម្មវិធីដើម្បីគ្រប់គ្រងគម្រោង ដែលបញ្ជីនៃកិច្ចការ អាទិភាព និងចំណុចសំខាន់ៗផ្សេងទៀតនឹងត្រូវបានបញ្ចូល។

វិធីសាស្រ្ត kanban នៅទីនេះនឹងមិនមែនជាក្តារ និងមិនមែនជាស្ទីគ័រទេ ប៉ុន្តែ ដំណើរការនៃការត្រួតពិនិត្យនិងផ្ទេរភារកិច្ចនៅលើជញ្ជាំង. តាមច្បាប់អ្វី អ្នកណា និងហេតុអ្វីបានផ្លាស់ទីស្ទីគ័រ តើស្ទីគ័រប៉ុន្មានអាចត្រូវបានរក្សាទុកក្នុងជួរឈរ "អនុវត្ត" ហេតុអ្វីបានកំណត់ចំនួននៅក្នុងជួរឈរនេះ - នេះគឺជា David នៅលើទំព័រ"កាន់បាន. ផ្លូវជំនួសដើម្បីភាពរហ័សរហួន។

Kanban មិនមែនជាបន្ទះស្អិតទេ។ស្ទីគ័រគ្រាន់តែជាសូចនាករនៃបន្ទុកការងារប៉ុណ្ណោះ។

Anderson បានរចនា kanban ដូច្នេះយើងមិនចាប់ផ្តើមគម្រោងថ្មីរហូតដល់គម្រោងមុនៗត្រូវបានបញ្ចប់។ ដូច្នេះសម្រាប់អ្នកអភិវឌ្ឍន៍ម្នាក់ ចំនួនស្ទីគ័រត្រូវបានជ្រើសរើស - ឧទាហរណ៍ 3-5 ហើយភារកិច្ចជាច្រើនក្នុងមួយឯកតានៃពេលវេលាអាចត្រូវបានបើកសម្រាប់គាត់។ ទាល់តែបញ្ចប់កិច្ចការណាមួយ គាត់អាចទទួលការងារថ្មីបាន។

យើងនិយាយច្រើនអំពីម៉ោងមនុស្ស និងតម្លៃរបស់វា ប៉ុន្តែច្រើនតែមិនដឹងថាមានការងារដែលមានផលិតភាពមួយម៉ោង និងម៉ោងដែលយកចេញពីជីវិត។ ហើយមានការងារមួយសប្តាហ៍ដែលមានផលិតភាពដែលអ្នកត្រូវឈប់សម្រាកឈឺ។ ដាវីឌនិយាយអំពីល្បឿននៃការងារនេះនៅពេលណា រាល់ម៉ោងមានផលិតភាព ហើយនេះគឺជាស្ថានភាពដែលមានសុខភាពល្អជាប្រចាំរបស់ក្រុម.

Agile, Scrum និង Kanban

Anderson ប្រាកដថាវិធីសាស្រ្ត Agile និង Scrum មានរូបមន្ត និងរឹង។ តាមគំនិតរបស់គាត់ ការគ្រប់គ្រងគម្រោងគួរតែមានលក្ខណៈបុគ្គលនៅក្នុងក្រុមហ៊ុននីមួយៗ។ ដូច្នេះហើយ Agile និង Scrum ជាមួយនឹងក្បួនដោះស្រាយសកម្មភាពស្តង់ដាររបស់ពួកគេគឺហួសសម័យ ដូចជាវិធីសាស្ត្រជំហានម្តងមួយៗ Waterfall បុរាណ។ ការហាមប្រាម - វិធីសាស្រ្តគឺដូច្នេះ ក្រុមហ៊ុនជាក់លាក់ដែលបំភ័យអ្នកប្រកាន់ខ្ជាប់នៃវិធីសាស្រ្តដែលអាចបត់បែនបាន!

Agile គឺជាវិធីសាស្ត្ររហ័សរហួនដែលកម្មវិធីជាប្រវត្តិសាស្ត្របានចាប់ផ្តើមក្នុងទម្រង់នៃការដាក់ឱ្យដំណើរការនូវបច្ចុប្បន្នភាពទៅកម្មវិធីរៀងរាល់ពីរបីខែម្តង។ ការសរសេរកម្មវិធីឡើងវិញពីរបីសប្តាហ៍ដើម្បីបន្ថែមមុខងារនីមួយៗបង្កើនល្បឿនដំណើរការអភិវឌ្ឍន៍ និងកាត់បន្ថយហានិភ័យ។

Scrum គឺជាវិធីសាស្រ្តដ៏រហ័សមួយផ្សេងទៀតជាមួយនឹងការធ្វើឡើងវិញខ្លីៗ ប៉ុន្តែមានការគ្រប់គ្រងកាន់តែច្រើនលើដំណើរការសរសេរកម្មវិធី។ មានការរត់ប្រណាំង - រយៈពេលនៃពេលវេលាជាមួយនឹងកិច្ចការជាក់លាក់ដែលត្រូវបញ្ចប់។ ពួកគេត្រូវបានកំណត់យ៉ាងតឹងរ៉ឹង។ មាន backlogs - បញ្ជីនៃភារកិច្ចជាទូទៅដែលត្រូវបានចែកចាយដោយម្ចាស់ផលិតផល។ វាមិនមែនជាកម្មសិទ្ធិរបស់ក្រុមអភិវឌ្ឍន៍ទេ ប៉ុន្តែផ្តល់អាទិភាពដល់ការងារ។

លោក David Anderson

កាន់បាន. ផ្លូវជំនួសដើម្បីភាពរហ័សរហួន

លោក David J Anderson

បោះពុម្ពដោយមានការអនុញ្ញាតពី Lean Kanban Inc.

រក្សារសិទ្ធគ្រប់យ៉ាង។

* * *

ឧទ្ទិសដល់ Nikola និង Natalie

បុព្វបទ

ខ្ញុំតែងតែយកចិត្តទុកដាក់ចំពោះការងាររបស់ David Anderson ។ ខ្ញុំបានជួបគាត់នៅខែតុលា ឆ្នាំ 2003 នៅពេលដែលគាត់បានផ្ញើមកខ្ញុំនូវច្បាប់ចម្លងនៃសៀវភៅ Agile Management for Software Engineering: Applying Theory of Constraints for Business Results។ ដូចដែលចំណងជើងបានបង្ហាញ សៀវភៅនេះត្រូវបានជះឥទ្ធិពលយ៉ាងខ្លាំងដោយទ្រឹស្តីនៃឧបសគ្គ (TOC) របស់ Eliyahu Goldratt ។ ក្រោយមកនៅខែមីនា ឆ្នាំ 2005 ខ្ញុំបានទៅជួបលោក David នៅក្រុមហ៊ុន Microsoft ដែលនៅពេលនោះគាត់កំពុងធ្វើការយ៉ាងជិតស្និទ្ធជាមួយនឹងតារាងលំហូរ។ សូម្បីតែក្រោយមកនៅក្នុងខែមេសា ឆ្នាំ 2007 ខ្ញុំមានឱកាសដើម្បីសង្កេតមើលពីរបៀបដែលប្រព័ន្ធ kanban របកគំហើញដែលគាត់បានអនុវត្តនៅក្នុង Corbis ដំណើរការ។

ខ្ញុំចង់ព្រមានអ្នកអានអំពីរឿងមួយចំនួន។ ជាដំបូង ប្រសិនបើអ្នកគិតថាអ្នកដឹងពីរបៀបដែលប្រព័ន្ធ kanban ដំណើរការ នោះអ្នកប្រហែលជាមានន័យថា អ្នកដែលប្រើក្នុងការផលិតគ្មានខ្លាញ់។ គំនិតនៅក្នុងសៀវភៅនេះគឺមានភាពជឿនលឿនជាងប្រព័ន្ធសាមញ្ញដែលប្រើដែនកំណត់ WIP ឋិតិវន្ត ការកំណត់កាលវិភាគ FIFO និងថ្នាក់សេវាកម្មតែមួយ។ សូមយកចិត្តទុកដាក់ចំពោះភាពខុសគ្នាទាំងនេះ។

ការដោះស្រាយភាពលំបាករបស់អ្នកគ្រប់គ្រង Agile

នៅក្នុងសកម្មភាពប្រចាំថ្ងៃរបស់ខ្ញុំក្នុងឆ្នាំ 2002 និងក្នុងសៀវភៅមុនរបស់ខ្ញុំ (1) ខ្ញុំមានការព្រួយបារម្ភជាចម្បងជាមួយនឹងបញ្ហាពីរ។ ទីមួយ របៀបការពារក្រុមពីការទាមទារដែលកំពុងកើនឡើងនៃអាជីវកម្ម និងសម្រេចបាននូវអ្វីដែលឥឡូវនេះហៅថា "ល្បឿនល្អបំផុត" នៅក្នុងសហគមន៍ដែលមានភាពរហ័សរហួន។ ហើយទីពីរ តើខ្ញុំអាចអនុវត្តវិធីសាស្រ្តរហ័សរហួននៅទូទាំងអង្គភាពដោយជោគជ័យដោយរបៀបណា ដើម្បីយកឈ្នះលើការតស៊ូដែលជៀសមិនរួចក្នុងការផ្លាស់ប្តូរ?

ការស្វែងរកល្បឿនត្រឹមត្រូវ។

ក្នុងឆ្នាំ 2002 សហគមន៍ដែលរហ័សរហួនបានយល់ឃើញថាមានល្បឿនល្អបំផុតថាជា "សប្តាហ៍ធ្វើការ 40 ម៉ោង"(2)។ គោលការណ៍នៃ Agile Manifesto (3) បាននិយាយថា "ដំណើរការរហ័សរហួនលើកកម្ពស់ការអភិវឌ្ឍន៍ដ៏ល្អប្រសើរ។ អ្នកឧបត្ថម្ភ អ្នកអភិវឌ្ឍន៍ និងអ្នកប្រើប្រាស់ត្រូវតែត្រៀមខ្លួនដើម្បីរក្សាល្បឿនថេរដោយគ្មានកំណត់។ កាលពីពីរឆ្នាំមុន ក្រុមការងាររបស់ខ្ញុំនៅ Sprint PCS បានបន្តឮពីខ្ញុំថា "ការអភិវឌ្ឍន៍កម្មវិធីតាមខ្នាតគឺជាការរត់ម៉ារ៉ាតុង មិនមែនជាការរត់ប្រណាំងនោះទេ។" ប្រសិនបើសមាជិកក្រុមត្រូវរក្សាល្បឿនថេរក្នុងដំណើរការនៃការធ្វើការលើគម្រោងរយៈពេលមួយឆ្នាំកន្លះ នោះពួកគេមិនអាចត្រូវបានអនុញ្ញាតឱ្យឆេះអស់ក្នុងរយៈពេលមួយខែ ឬពីរខែនោះទេ។ គម្រោងនេះត្រូវតែរៀបចំផែនការ រៀបចំថវិកា កំណត់ពេលវេលា និងវាយតម្លៃ ដើម្បីធានាថាសមាជិកក្រុមបានចំណាយពេលវេលាសមស្របក្នុងការងារជារៀងរាល់ថ្ងៃ និងមិនហត់នឿយពេក។ ក្នុងនាមជាអ្នកគ្រប់គ្រង ភារកិច្ចរបស់ខ្ញុំគឺដើម្បីសម្រេចគោលដៅនេះ។ និងបំពេញតាមតម្រូវការអាជីវកម្មទាំងអស់។

នៅពេលដែលខ្ញុំនៅក្នុងមុខតំណែងអ្នកគ្រប់គ្រងដំបូងរបស់ខ្ញុំ (វាគឺនៅក្នុងឆ្នាំ 1991 នៅពេលចាប់ផ្តើមដែលបង្កើតក្តារថតវីដេអូសម្រាប់កុំព្យូទ័រផ្ទាល់ខ្លួន និងតូចជាង) នាយកប្រតិបត្តិបាននិយាយថា ការគ្រប់គ្រងមាន "គំនិតអវិជ្ជមាន" យ៉ាងខ្លាំងចំពោះខ្ញុំ។ ខ្ញុំតែងតែឆ្លើយថា "ទេ" នៅពេលដែលឱកាសរបស់យើងជាអ្នកអភិវឌ្ឍន៍បានអស់ហើយ ហើយផលិតផល ឬមុខងារកាន់តែច្រើនត្រូវបានទាមទារពីពួកយើង។ ដល់ឆ្នាំ 2002 ខ្ញុំបានក្លាយទៅជាទម្លាប់មួយ៖ ខ្ញុំបានចំណាយពេលដប់ឆ្នាំទៀតដោយមិនព្រមធ្វើតាមការចង់បានរបស់ម្ចាស់អាជីវកម្ម។

អំពីសៀវភៅ
ការណែនាំស៊ីជម្រៅអំពី kanban ពីអ្នកត្រួសត្រាយ kanban លើកដំបូងដែលមានអាយុ 30 ឆ្នាំក្នុងការអភិវឌ្ឍន៍កម្មវិធី។

David Anderson ដែលបានអនុវត្តវិធីសាស្ត្រ kanban នៅក្នុងក្រុមហ៊ុនជាច្រើន ហើយបានកែលម្អវាជាបន្តបន្ទាប់ បង្ហាញពីរបៀបណែនាំគំនិតគ្មានខ្លាញ់ទៅក្នុងការអភិវឌ្ឍន៍បច្ចេកវិទ្យា និងប្រតិបត្តិការ IT ប្រកបដោយប្រសិទ្ធភាព ដោយមានការតស៊ូតិចតួចបំផុតក្នុងការផ្លាស់ប្តូរ ខណៈពេលដែលរក្សាបាននូវល្បឿនល្អបំផុតសម្រាប់បុគ្គលិកដែលពាក់ព័ន្ធទាំងអស់។

Kanban កំណត់យ៉ាងរហ័សនូវបញ្ហាដែលជះឥទ្ធិពលដល់ការអនុវត្ត និងបង្ខំក្រុមឱ្យផ្តោតលើការដោះស្រាយដើម្បីបន្តដំណើរការការងារ។ តាមរយៈការធ្វើឱ្យបញ្ហាគុណភាព និងដំណើរការអាចមើលឃើញ kanban ផ្តល់ឱកាសមួយដើម្បីវាយតម្លៃផលប៉ះពាល់នៃពិការភាព ឧបសគ្គ ភាពប្រែប្រួល និងការចំណាយសេដ្ឋកិច្ចលើលំហូរការងារ និងលំហូរការងាររបស់បុគ្គលិក។

គ្រាន់តែកំណត់ការងារដែលមិនទាន់បានបញ្ចប់តាមរយៈ kanban នាំឱ្យប្រសើរឡើងនូវគុណភាពការងារ និងផលិតភាព។ ការរួមបញ្ចូលគ្នានៃលំហូរការងារដែលមានភាពប្រសើរឡើង និងគុណភាពដែលប្រសើរឡើងជួយកាត់បន្ថយពេលវេលានាំមុខ និងធ្វើអោយប្រសើរឡើងនូវការព្យាករណ៍ និងលទ្ធភាពនៃការផ្តល់ការងារទាន់ពេល។ តាមរយៈការបង្កើតទម្លាប់ចេញផ្សាយទៀងទាត់ និងការប្រកាន់ខ្ជាប់នូវកាលវិភាគ kanban ជួយបង្កើតទំនុកចិត្តជាមួយអតិថិជន និងសមាជិកផ្សេងទៀតនៃស្ទ្រីមតម្លៃ — នាយកដ្ឋានផ្សេងទៀត អ្នកលក់ និងដៃគូដែលពឹងផ្អែក។

Kanban ត្រូវបានបង្ហាញឱ្យឃើញថានឹងបង្កើនការពេញចិត្តរបស់អ្នកប្រើតាមរយៈការចេញផ្សាយជាទៀងទាត់, អាចទុកចិត្តបាន, និងមានគុណភាពខ្ពស់នៃកម្មវិធីដែលមានតម្លៃ. វាក៏ត្រូវបានបញ្ជាក់ផងដែរក្នុងការធ្វើឱ្យប្រសើរឡើងនូវផលិតភាព គុណភាព និងកាត់បន្ថយពេលវេលាផលិត។ មានភ័ស្តុតាងដែលថា kanban អាចជាកាតាលីករសម្រាប់ការលេចចេញនូវអង្គការដែលមានភាពរហ័សរហួនជាងមុន តាមរយៈការផ្លាស់ប្តូរវប្បធម៌វិវត្តន៍។

សៀវភៅនេះឆ្លើយសំណួរ៖

- តើកាណានជាអ្វី?
ហេតុអ្វីបានជាក្រុមហ៊ុនរបស់អ្នកត្រូវការវា?
- តើត្រូវអនុវត្តវាដោយរបៀបណា?
- តើធ្វើដូចម្តេចដើម្បីទទួលស្គាល់ឱកាសសម្រាប់ការធ្វើឱ្យប្រសើរឡើងនៅក្នុងអាជីវកម្ម - និងអ្វីដែលត្រូវធ្វើជាមួយពួកគេ?

តើសៀវភៅនេះសម្រាប់អ្នកណា?
សម្រាប់អ្នកគ្រប់គ្រង និងប្រធានក្រុមហ៊ុន IT ។

អំពីអ្នកនិពន្ធ
David Anderson គឺជាស្ថាបនិកនៃសាកលវិទ្យាល័យ Lean Kanban និងសាលាគ្រប់គ្រង David J Anderson ដែលឧទ្ទិសដល់ការជួយអ្នកដឹកនាំ និងអ្នកគ្រប់គ្រងឱ្យសម្រេចបានលទ្ធផលល្អប្រសើរតាមរយៈការអនុវត្តល្អបំផុត។

Anderson មានបទពិសោធន៍ 30 ឆ្នាំនៅក្នុងក្រុមហ៊ុនបច្ចេកវិទ្យា។ គាត់បានណែនាំការអនុវត្តការគ្រប់គ្រងយ៉ាងរហ័សដល់ក្រុមហ៊ុនដូចជា Motorola និង Microsoft។

David គឺជាមនុស្សដំបូងគេដែលប្រើ kanban ក្នុងការអភិវឌ្ឍន៍កម្មវិធីក្នុងឆ្នាំ 2005 ។

Kanban មានន័យថា "បន្ទះសញ្ញា" នៅក្នុងភាសាជប៉ុន។ នៅក្នុងការផលិត បន្ទះក្តារបែបនេះត្រូវបានប្រើដើម្បីស្រមៃមើលអត្រាកើនឡើង ដែលអនុញ្ញាតឱ្យអ្នកផលិតផលិតផលកាន់តែច្រើនក្នុងតម្លៃទាប។ ឧទាហរណ៍ដ៏គួរឱ្យចាប់អារម្មណ៍មួយគឺវិធីសាស្រ្តរបស់ក្រុមហ៊ុនតូយ៉ូតា អរគុណដែលអស់រយៈពេលជាច្រើនឆ្នាំ គោលការណ៍នៃ "ទាន់ពេល" ត្រូវបានអនុវត្តយ៉ាងមានប្រសិទ្ធភាពជាមួយនឹងការចំណាយតិចតួចបំផុត។

លោក David Anderson ផ្តល់នូវបណ្តុំនៃគំនិតបន្ថែម (ការមើលឃើញនៃដំណើរការ និងច្បាប់នៃការងារ ការវាយបញ្ចូលធាតុការងារ ថ្នាក់នៃសេវាកម្ម ចំណាត់ថ្នាក់ រង្វាស់ និងក្រាហ្វសម្រាប់ការគ្រប់គ្រងគណនេយ្យ និងការវិភាគ) ដែលកំណត់វិធីសាស្ត្រ kanban ។

សៀវភៅនេះពិពណ៌នាអំពីឧបករណ៍ដើម្បីណែនាំគំនិតគ្មានខ្លាញ់ប្រកបដោយប្រសិទ្ធភាពទៅក្នុងការអភិវឌ្ឍន៍បច្ចេកវិទ្យា និងប្រតិបត្តិការ IT ជាមួយនឹងភាពធន់ទ្រាំតិចតួចបំផុតក្នុងការផ្លាស់ប្តូរ ខណៈពេលដែលរក្សាបាននូវល្បឿនដ៏ល្អប្រសើរសម្រាប់បុគ្គលិកដែលពាក់ព័ន្ធទាំងអស់។

បោះពុម្ពជាភាសារុស្សីជាលើកដំបូង។

ម្ចាស់កម្មសិទ្ធិ!បំណែកដែលបានបង្ហាញនៃសៀវភៅត្រូវបានដាក់ក្នុងកិច្ចព្រមព្រៀងជាមួយអ្នកចែកចាយខ្លឹមសារច្បាប់ LLC "LitRes" (មិនលើសពី 20% នៃអត្ថបទដើម)។ ប្រសិនបើអ្នកជឿថាការបង្ហោះសម្ភារៈបំពានសិទ្ធិរបស់អ្នក ឬអ្នកដ៏ទៃ សូមប្រាប់ពួកយើងឱ្យដឹង។

ថ្មីបំផុត! បង្កាន់ដៃសៀវភៅថ្ងៃនេះ

សក្ខីកម្មរបស់ Yvette Blanche
Demange Patricia
ទស្សនាវដ្ដី

ស៊ូហ្សាន ក្រោកពីថ្ម ហើយហៀបនឹងដើរត្រឡប់ទៅឡានវិញ ពេលឮសំឡេង៖

- មក! មករកខ្ញុំ! មករកខ្ញុំ! មក!

ហើយដូចជាលើកទីមួយ ពាក្យប្លែកៗទាំងនេះត្រូវបានបន្តដោយការយំដែលមិនអាចយល់បាន។ ក្មេងស្រីបង្កក។ សំឡេងនោះមានការត្អូញត្អែរខ្លាំងដែលនាងមិនអាចធ្វើចលនាបាន។

ហើយបន្ទាប់មកនាងបានលឺពាក្យទាំងនេះម្តងទៀត៖

“មក… មករកខ្ញុំ!” មក!

វាហាក់ដូចជា Susanna ភ្លាមៗថាខួរក្បាលរបស់នាងនឹងផ្ទុះចេញពីឃ្លាមួយនេះ។ អស់រយៈពេលជាច្រើននាទី នាងបានឈរដោយគ្មានចលនា ប៉ុន្តែបន្ទាប់មកបានប្រមូលកម្លាំងរបស់នាង ហើយប្រញាប់ទៅឡានដែលចតនៅក្រោមដើមឈើ។ នាងបានបញ្ចូលគន្លឹះបញ្ឆេះយ៉ាងលឿន ហើយចាប់ផ្តើមម៉ាស៊ីន។ នាងចង់ចេញពីទីនេះឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន។ ដរាបណាអ្នកមិនដឹង ឬឮអ្វីទាំងអស់។ វាមិនអាចជា! នាងគ្រាន់តែជា Susanna Lambert, Susanna Lambert, Susanna Lambert...
សត្វចចក
ម៉ាស៊ីនកិនអាឡិចសាន់ត្រា
ទស្សនាវដ្ដី

គាត់បានដើរតាម Julia ទៅកាន់វាលភក់ ... ក្មេងស្រីមានអារម្មណ៍ថាសម្លឹងមើលនាង ហើយស្ពឹកដោយភាពភ័យរន្ធត់។ ជើងភ្លាមក៏ចាប់ផ្ដើមលិចចូលជ្រៅទៅក្នុងកន្លែងកកកុញត្រជាក់។ យើងត្រូវតែចេញពីទីនេះ មុនពេលវាយឺតពេល! នាងបានព្យាយាមងាកទៅរកផ្លូវ៖ ទីនេះជាដីរឹង ចម្ងាយមួយម៉ែត្រ... ប៉ុន្តែមានអ្វីមួយដែលគ្រោះថ្នាក់ជាងវាលភក់ដ៏គួរឱ្យខ្លាចមួយកំពុងរង់ចាំនាង៖ មនុស្សចចកមួយក្បាលមានសក់ពណ៌ប្រផេះ! រូបសំណាករបស់គាត់ស្រាប់តែលេចចេញពីភាពងងឹត។ ក្បាលដ៏ធំបានហែលយឺតៗតាមពេលវេលាជាមួយនឹងខ្យល់ ហើយនៅក្នុងជម្រៅនៃរន្ធភ្នែក គ្រាប់ធ្យូងនៃភ្នែកបានបញ្ចេញពន្លឺពណ៌ក្រហមយ៉ាងគួរឲ្យកត់សម្គាល់។ Julia បានព្យាយាមចុងក្រោយដើម្បីទប់ទល់នឹងការភ័យខ្លាចរបស់នាង ប៉ុន្តែភាពភ័យរន្ធត់បានធ្វើឱ្យនាងពិការ៖ នាងមិនអាចបោះជំហានបានទេ។ សត្វចម្លែកដែលមើលទៅដូចចចក កំពុងតែខិតមកជិត។ មានតែជំហានពីរបីប៉ុណ្ណោះរវាងពួកគេ។ ឥឡូវនេះអ្នកអាចមើលឃើញរោមចៀមពណ៌ប្រផេះនៅលើក្រញាំរបស់សត្វចម្លែកនៅទីនេះ ក្រញ៉ាំមុតស្រួចភ្លឺក្នុងពន្លឺព្រះច័ន្ទ...
វេទមន្ត - សម្រេចចិត្ត។ ការបង្កើត
Nazimov Konstantin
ការធ្លាក់

សិស្សម្នាក់ គាត់ជាសិស្សគ្រប់ទីកន្លែង។ ការកម្សាន្ត និងការព្យាយាមរកប្រាក់។ រឿងធម្មតាមួយបាននាំឱ្យមានសោកនាដកម្មមួយ ហើយខ្ញុំក៏បានបញ្ចប់ ... នៅក្នុងពិភពនៃវេទមន្ត។ សូមសំណាងល្អជាមួយវា ខ្ញុំចូលចិត្តវា។ ពួកគេថែមទាំងបានជួយ និងប្រែក្លាយខ្លួនជា...សិស្សម្នាក់ ប៉ុន្តែរួចហើយនៅសាលាវេទមន្ត ហើយបានកំណត់ទៅធ្វើការ។

ប៉ុន្តែជីវិតប្រែក្លាយមនុស្សនិងវេទមន្តតាមដែលខ្លួនចង់បាន។ ពិភពលោកនេះមិនបានស្គាល់អ្នកប្រាជ្ញដ៏អស្ចារ្យដែលមានសមត្ថភាពរកលុយបានដោយខ្យល់អាកាសស្តើង។ គ្មាននរណាម្នាក់សាងសង់ពីរ៉ាមីតហិរញ្ញវត្ថុទេ។ ដូច្នេះហើយខ្ញុំអាចបង្វិលបានពេញលេញ។ ប៉ុន្តែបញ្ហាធ្ងន់ធ្ងរ និងការបោកប្រាស់បានបាត់ទៅហើយ។ គំនិតមួយបានក្លាយទៅជាដូចដែលមិត្តភក្តិរបស់ខ្ញុំ និងខ្ញុំមិនអាចបំបែកលទ្ធផលបាន។ ខ្ញុំត្រូវចេញទៅក្រៅផ្លូវរបស់ខ្ញុំ ហើយយកអ្វីៗទៅកម្រិតខុសគ្នាទាំងស្រុង។ ហើយវាពិបាកក្នុងការទាញវា៖ នេះគឺជាមាសនៃកាបូបលុយ និងក្រុមចោរ មនុស្សសាមញ្ញ និងមន្ត្រីការិយាធិបតេយ្យ។ ហើយក៏មានបញ្ហាជាមួយវត្ថុបុរាណ និងក្មេងស្រី បំណុលកាត និងរថយន្តដ៏ស្រស់ស្អាត។ អ្នកត្រូវសម្រេចចិត្តលឿន ប្រតិកម្មភ្លាមៗ។ អេ ប៉ុន្តែខ្ញុំចង់រស់នៅយ៉ាងស្រស់ស្អាត ហើយខ្ញុំសង្ឃឹមថាវានឹងដំណើរការ ទោះបីជាមិនមែនជាការពិត...
ស្ត្រីនៅក្នុងពណ៌ស
ប្រផេះ ឡារ៉ា
អ្នកស៊ើបអង្កេតនិងរន្ធត់, រន្ធត់

រាល់ថ្ងៃក្រោយពាក់កណ្ដាលអធ្រាត្រ មានរឿងកើតឡើងក្នុងប្រាសាទ…

Katerina យល់ថាជីវិតរបស់នាងត្រូវបានព្យួរដោយខ្សែស្រឡាយ។ នាងបានចាប់សំពត់របស់នាងដោយដៃម្ខាង ដើម្បីកុំឱ្យមានការរំខានដល់ការរត់របស់នាង ដៃម្ខាងទៀតត្រូវបានលាតទៅមុខ ដើម្បីកុំឱ្យក្បាលរបស់នាងធ្លាក់ចូលជញ្ជាំង។ ទីបំផុតទ្វារមួយ! ក្មេងស្រីនោះបានបើកវាភ្លាមៗ ហើយរត់ចេញពីច្រករបៀង។ អ្នកដេញតាមមិនយឺតយ៉ាវទេ៖ ជំហានរបស់គាត់ត្រូវបានគេឮកាន់តែខ្លាំងឡើង។ គាត់អាចតាមទាន់ Katerina នៅពេលណាមួយ!

- សម្រាប់ជំនួយ! សម្រាប់ជំនួយ! ក្មេងស្រីបានស្រែក។ - អ្នកណាម្នាក់! ជួយ!

នាងបានជាន់លើថ្ម ហើយវាយយ៉ាងខ្លាំង ធ្លាក់ទៅលើឥដ្ឋ។ Katerina បានលូនទៅម្ខាងហើយលាក់ខ្លួន។ សំណាងល្អងងឹតហើយអ្នកដេញតាមរត់ទៅមុខដោយមិនបានចាប់អារម្មណ៍នាងឡើយ។ Katerina ក្រឡេកមើលជុំវិញ៖ នាងដេកនៅក្នុងបន្ទប់ងងឹតគ្មានបង្អួច គ្មានពន្លឺ គ្មានអ្វីអាចមើលឃើញ...
Joker ប្រណាំង។ ហ្គេមរស់រានមានជីវិត
Nazimov Konstantin
ប្រឌិត, ប្រឌិតវីរបុរស

ហ្គេមនេះមិនមែនជារបៀបដែលខ្ញុំស្រមៃនោះទេ។ ការកុហក និងការក្បត់ ការស៊ីសំណូក និងសូម្បីតែទាសភាព ដើរទន្ទឹមគ្នានៅទីនេះ។ មានអ្នកលេងធម្មតា ដែលក្នុងនោះមានច្រើនណាស់ ដែលព្យាយាមរស់នៅតាមច្បាប់ និងកិត្តិយស។ ហើយវាក៏កើតឡើងដែរដែលពណ៌ខ្មៅត្រូវបានបង្ហាញថាជាស ដែលជាការកុហកសម្រាប់ការពិត។

តាមឆន្ទៈនៃបណ្តាញ កិច្ចការស្មុគស្មាញ និងបេសកកម្មត្រូវបានកំណត់នៅចំពោះមុខខ្ញុំ ដែលខ្ញុំមិនបានសង្ស័យឡើយ។ ការប្រណាំងសម្រាប់ការលុបបំបាត់ឬការរស់រានមានជីវិតត្រូវបានជំនួសដោយការហោះហើរពីអ្នកប្រមាញ់ប្រាក់រង្វាន់។ យើងត្រូវចូលទៅក្នុងការវាយប្រហារដោយអយុត្តិធម៌ និងអយុត្តិធម៌។ ដើម្បីកែលម្អជីវិតរបស់អ្នកលេងធម្មតា ដែលតាមភាពល្ងង់ខ្លៅ និងភាពឆោតល្ងង់របស់ពួកគេ បានដេញតាមការសន្យា ហើយបានរកឃើញថាខ្លួនពួកគេស្ថិតក្នុងស្ថានភាពអស់សង្ឃឹម។ ចូលទៅក្នុងហ្គេមពិភពលោកជិតខាង ដែលសត្វចម្លែកជួបនៅគ្រប់វេន ហើយចាត់ទុកអ្នកថាគ្មានអ្វីក្រៅពីសត្វព្រៃនោះទេ។ បើគ្មានអ្វីៗទាំងអស់នេះទេ អ្នកមិនអាចទៅដល់ទីបញ្ចប់បានទេ។

ពេញមួយហ្គេម មិត្តភ័ក្តិ និងសត្រូវនៅក្បែរខ្ញុំ ខ្លះជួយក្នុងគ្រាលំបាក ខ្លះទៀតត្រៀមខ្លួនរួចជាស្រេចដើម្បីរុញកាំបិតចូលខ្នងរបស់ខ្ញុំ ប៉ុន្តែខ្ញុំត្រូវតែពឹងផ្អែកលើខ្លួនឯង និងសំណាងល្អ។ គោលដៅមួយត្រូវបានកំណត់ ប្រេងសាំងត្រូវចាក់ចូលក្នុងធុង គ្រឿងអលង្ការនៅជុំវិញក ហើយជើងចុចឈ្នាន់ឧស្ម័នទៅនឹងឥដ្ឋ។ ជ័យជំនះនឹងមកដល់ ហើយខ្ញុំនឹងសម្រេចគោលដៅរបស់ខ្ញុំ! សង្ឃឹមដូច្នោះ…
ខ្មោចមកពីអ័ព្ទ
ម៉ាស៊ីនកិនអាឡិចសាន់ត្រា
ទស្សនាវដ្ដី

រហូតមកដល់ពេលនេះ Elena មិនបានយកចិត្តទុកដាក់នឹងការពិតដែលម្ចាស់ផ្ទះសំណាក់ដែលនាងស្នាក់នៅនោះនៅម្នាក់ឯងគ្រប់ពេលវេលា។ នាងស្មានថាប្រពន្ធរវល់តែចូលផ្ទះបាយ ឬរវល់នឹងការងារផ្សេងៗ ទើបមិនចេញមុខភ្ញៀវ…

កំណត់ "សប្តាហ៍" - ផលិតផលថ្មីកំពូល - អ្នកដឹកនាំសម្រាប់សប្តាហ៍!

2. បណ្តាសាសាកលវិទ្យាធិការ
រដូវក្តៅលីណា
ប្រលោមលោកមនោសញ្ចេតនា , ប្រលោមលោកស្នេហា , ប្រលោមលោក , ប្រលោមលោកស៊ើបអង្កេត ,

ខ្ញុំមានពេលមួយឆ្នាំដើម្បីបញ្ចប់។ មួយឆ្នាំ - ហើយខ្ញុំអាចទទួលបានសេរីភាព និងឯករាជ្យ ដែលខ្ញុំបានសុបិនតាំងពីកុមារភាព។ ទោះយ៉ាងណាក៏ដោយ ការស្លាប់ភ្លាមៗ និងគួរឱ្យសង្ស័យបំផុតរបស់ម្តាយខ្ញុំ បានធ្វើឱ្យពិភពលោករបស់ខ្ញុំវិលវល់។ នាងបានបន្សល់ទុកនូវសំណួរជាច្រើន ហើយឱកាសតែមួយគត់ដើម្បីស្វែងរកចម្លើយគឺត្រូវទៅសាកលវិទ្យាល័យដែលមានឥស្សរជនបំផុតនៃសាធារណរដ្ឋ។ ខ្ញុំគិតថាភាពល្ងង់ខ្លៅរបស់មិត្តរួមថ្នាក់ថ្មីនឹងជាបញ្ហាចម្បងរបស់ខ្ញុំ ប៉ុន្តែខ្ញុំគិតខុស។ ចម្លើយដែលខ្ញុំកំពុងស្វែងរក អាចនឹងធ្វើឱ្យខ្ញុំបាត់បង់ជីវិត ហើយសម្រាប់ហេតុផលមួយចំនួន ឥឡូវនេះខ្ញុំកាន់តែព្រួយបារម្ភអំពីជីវិតរបស់សាកលវិទ្យាធិការក្នុងស្រុក ដែលស្ថិតនៅក្រោមបណ្តាសា។
សាលា Arcturus ។ កូនក្រមុំចចក
Lime Sylvia
ប្រឌិត, ប្រឌិតបែបកំប្លែង

ពេលខ្លះការក្បត់មិនមែនជាទីបញ្ចប់ទេ ប៉ុន្តែជាការចាប់ផ្តើម។

ម្តងម្កាល - នេះគឺជាទ្វារទៅកាន់ពិភពលោកមួយទៀត ដែលសង្រ្គាមស្ថិតនៅលើកម្រិត។ កន្លែងដែលសត្វចចកប្រយុទ្ធរហូតដល់ស្លាប់សម្រាប់ស្ត្រីនិងបុរសរបស់ពួកគេផ្ទុកកាំភ្លើងជាមួយនឹងគ្រាប់កាំភ្លើង។ កន្លែងដែលឃាតករអាថ៍កំបាំងដើរតាម លេបត្របាក់បំពង់ករបស់អ្នកគ្រប់គ្នាដែលមើលទៅដូចអ្នកខ្លាំងណាស់។ កន្លែងដែលស្នាមញញឹមដែលមានចរិតល្អ គឺជាឱកាសប្រាកដក្នុងការធ្លាក់ចូលទៅក្នុងអន្ទាក់ ហើយចចកលាន់នៅពីក្រោយខ្នងរបស់អ្នក គឺជាឱកាសដើម្បីគេចចេញ។

ត្រៀមខ្លួនជាស្រេច សាលារៀនសត្វចចកកំពុងរង់ចាំអ្នកនៅទីនេះ មនុស្សឆ្កួតនៅខាងក្រៅទ្វារ និងបុរសអាថ៌កំបាំងដែលដោយហេតុផលមួយចំនួនបានសម្រេចចិត្តថាគាត់អាចមករកអ្នកពេលយប់។

ហើយទាំងអស់ដោយសារតែការក្បត់មិនមែនជាទីបញ្ចប់នោះទេប៉ុន្តែគ្រាន់តែជាការចាប់ផ្តើមប៉ុណ្ណោះ។
Arcturus Academy 2. ប្រពន្ធរបស់ចចក
Lime Sylvia
Fantasy, Cyberpunk

ពួកគេថាជីវិតនិងការទុកចិត្តត្រូវបាត់បង់តែម្ដង។ ពេលដែលខ្ញុំមានសំណាងហើយ ប៉ុន្តែវាទំនងជាសំណាងមិនបានកើតឡើងវិញនោះទេ។ មនុស្សឆ្កួតដែលសម្លាប់ក្មេងស្រីត្រូវបានរកឃើញ ប៉ុន្តែអ្នកអាយ៉ងនៅតែទាញខ្សែអាយ៉ងរបស់ខ្លួនដដែល។ សេចក្តីស្លាប់ដើរទៅមុខឥតឈប់ឈរ ហើយខ្ញុំត្រូវតែឈានទៅមុខមួយជំហាន។ លើកនេះ ដើម្បីជួយសង្រ្គោះមិនត្រឹមតែខ្លួននាងប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងជាសត្វចចក ដែលនាងត្រូវបានភ្ជាប់ដោយចំណងដែលមិនអាចបំបែកបាន។ គាត់ខ្លាំងជាងអ្នកផ្សេងទៀត ហើយនេះគឺជាចំណុចខ្សោយរបស់គាត់។ ដើម្បីឱ្យគាត់នៅរស់ ខ្ញុំត្រូវក្បត់គាត់។ ឬមានវិធីផ្សេងទៀត?

* * *

បុព្វបទ

ផ្នែក I មូលដ្ឋាន

ជំពូកទី 1 ការដោះស្រាយភាពលំបាករបស់អ្នកគ្រប់គ្រង Agile

ការស្វែងរកល្បឿនត្រឹមត្រូវ។

ក្នុងការស្វែងរកការគ្រប់គ្រងការផ្លាស់ប្តូរជោគជ័យ

ពីស្គរ - សតិបណ្ដោះអាសន្ន - ខ្សែទៅកានបាន

ការលេចឡើងនៃវិធីសាស្រ្ត kanban

អំពី​អ្នកនិពន្ធ

បន្ទុកអត្ថន័យ និងខ្លឹមសារនៃសៀវភៅ

Kaizen គឺជាទស្សនវិជ្ជា និងក្រមសីលធម៌នៃទំនាក់ទំនងរវាងកម្មកររោងចក្រ និងការគ្រប់គ្រង។

ដែនកំណត់ WIP (កំពុងដំណើរការ) - ចំនួនកិច្ចការដែលអាចបើកក្នុងពេលតែមួយ។

ស្តេរ៉េអូអំពី kanban

Kanban មិនមែនជាបន្ទះស្អិតទេ។ស្ទីគ័រគ្រាន់តែជាសូចនាករនៃបន្ទុកការងារប៉ុណ្ណោះ។

Agile, Scrum និង Kanban

សៀវភៅនេះឆ្លើយសំណួរ៖

ថ្មីបំផុត! បង្កាន់ដៃសៀវភៅថ្ងៃនេះ

កំណត់ "សប្តាហ៍" - ផលិតផលថ្មីកំពូល - អ្នកដឹកនាំសម្រាប់សប្តាហ៍!

អត្ថបទ​ដែល​ទាក់ទង

ផ្នែក I
មូលដ្ឋាន

ជំពូកទី 1
ការដោះស្រាយភាពលំបាករបស់អ្នកគ្រប់គ្រង Agile

អំពីអ្នកនិពន្ធ

អត្ថបទដែលទាក់ទង