بیشتر تیم‌ها تجربیات را یادداشت می‌کنند اما کمتر آن‌ها را به کار می‌گیرند. آنچه حسابرسی‌های NASA نشان داد، نحوه عملکرد Pause and Learn، و حلقه‌ای که هر تجربه را به یک تغییر واقعی متصل می‌کند.
ابراهیم الکوبییسی · · زمان مطالعه: 6 دقیقه ·
هر پروژه با یک لیست تمام می‌شود: چه چیزهایی خوب پیش رفت، چه چیزهایی اشتباه بود و چه کارهایی را متفاوت انجام می‌دادیم. لیست بایگانی می‌شود. پروژه‌ی بعدی شروع می‌شود و بیش از آنچه تیم‌ها اعتراف می‌کنند، دوباره همان اشتباهات را تکرار می‌کند.
مشکل به‌ندرت در ثبت کردن است؛ مشکل در فاصله‌ی میان تجربه‌ای است که شناسایی شده و تجربه‌ای که اعمال شده است. یکی از مستندترین برنامه‌های تجربیات کسب‌شده در جهان، یعنی برنامه NASA، این فاصله را اندازه‌گیری کرده است. یافته‌های آن ابتدا ارائه می‌شود و سپس یک حلقه‌ی کوچک برای بستن این فاصله در پی می‌آید.
شناسایی شدن با آموختن یکی نیست
یک تجربه زمانی شناسایی می‌شود که کسی آن را یادداشت کند. زمانی آموخته می‌شود که سازمان به دلیل آن، رفتار متفاوتی از خود نشان دهد. میان این دو، حجم عظیمی از کار قرار دارد که اکثر فرآیندهای تجربیات کسب‌شده هرگز به کسی واگذار نمی‌کنند.
تحقیقات در سازمان‌های پروژه‌محور، این الگو را مستقیماً نام می‌برند. در International Journal of Project Management، Duffield و Whitty دریافتند که فرآیندهای تجربیات کسب‌شده به‌ندرت اتفاق می‌افتند و وقتی هم اتفاق می‌افتند، به‌جای یادگیری سازمانی، بر «شناسایی تجربیات» تمرکز دارند. خروجی کار یک سند است، در حالی که نتیجه‌ی مورد انتظار، تغییر در نحوه‌ی کار تیم بعدی است. این دو متفاوت هستند و تنها یکی از آن‌ها به‌راحتی تولید می‌شود.
آنچه حسابرسی‌های خودِ NASA نشان داد
NASA تجربیات را جدی می‌گیرد. این سازمان سیستم اطلاعات تجربیات کسب‌شده (LLIS) را مدیریت می‌کند و الزامات رویه‌ای آن (NPR 7120.6) مشخص می‌کند که تجربیات چگونه جمع‌آوری، تأیید، ارزیابی و کدگذاری شوند. همین امر، حسابرسی‌های آن را به یک مورد مطالعاتی مفید تبدیل می‌کند. اگر تجربیات در آنجا متوقف شوند، علت آن کمبود نیت و اراده نیست.
در سال 2001، دفتر حسابرسی عمومی ایالات متحده (که اکنون دفتر پاسخگویی دولتی است) از مدیران برنامه و پروژه‌ی NASA نظرسنجی کرد. از 115 نفری که پاسخ دادند:
- 27% قبل از نظرسنجی از وجود LLIS مطلع نبودند.
- 17.5% تجربه‌ای را که از طریق LLIS یافته بودند، اعمال کرده بودند.
- 58% گفتند سیستم‌های فعلی اجازه نمی‌دهند تجربیات درست را در زمان درست بازیابی کنند.
GAO نتیجه گرفت که «تجربیات به‌طور معمول شناسایی، جمع‌آوری یا به اشتراک گذاشته نمی‌شوند.» یادگیری اتفاق می‌افتاد، اما عمدتاً از طریق بازبینی‌ها و گفتگو با همکاران، نه از طریق سیستمی که برای این کار ساخته شده بود.
در سال 2012، دفتر بازرس کل NASA دوباره به این موضوع بازگشت. آن‌ها 28 پروژه‌ی علمی و پرواز فضایی را که بین سال‌های 2005 تا 2011 راه‌اندازی شده بودند، مورد بررسی قرار دادند. شانزده مدیر پروژه گفتند که اصلاً از LLIS استفاده کرده‌اند و تنها شش نفر از آن‌ها آن را مفید دانستند. دوازده نفر تجربیاتی را ثبت کرده بودند، اما تنها ده نفر از ضرورت ثبت تجربیات اطلاع داشتند. مدیران، سیستم را قدیمی و جستجو در آن را دشوار توصیف کردند و بسیاری پروژه‌های خود را بسیار منحصربه‌فرد می‌دانستند که تجربیات گذشته را شامل نمی‌شود. OIG همچنین دریافت که تنها دو مرکز NASA در نحوه‌ی اجرای فرآیند خود، به‌طور کامل از NPR 7120.6 پیروی می‌کردند.
این الگو در طول یازده سال ثابت بوده است. تجربیات ذخیره می‌شدند، اما تعداد کمی بازیابی می‌شدند و تعداد کمتری نیز باعث تغییر در کار می‌شدند.
چرا تجربیات متوقف می‌شوند؟
با مطالعه‌ی دقیق حسابرسی‌ها، سه علت همواره تکرار می‌شوند. این موارد فراتر از پروازهای فضایی نیز صدق می‌کنند.
- تجربیات به‌صورت داستان نوشته می‌شوند، نه دستورالعمل. خواندن یک پاراگراف درباره‌ی آنچه اتفاق افتاده، برای اقدام کردن دشوار است. این متن نمی‌گوید کدام سند، مرحله یا تصمیم باید از این پس متفاوت باشد.
- تجربیات جدا از جریان کار قرار دارند. یک پایگاه داده‌ی مجزا از افراد پرمشغله می‌خواهد که به دنبال اطلاعات بگردند. اکثر آن‌ها این کار را انجام نمی‌دهند، به‌خصوص وقتی تحت فشار زمان هستند. GAO دریافت که مدیران بیش از آنکه از سیستم یاد بگیرند، از همکاران و بازبینی‌ها یاد می‌گیرند.
- هیچ‌کس بررسی نمی‌کند. ثبت کردن محاسبه می‌شود، اما اعمال کردن خیر. وقتی تنها معیار، تعداد تجربیات ثبت‌شده باشد، تیم‌ها در ثبت کردن بسیار ماهر می‌شوند.
هیچ‌کدام از این‌ها صرفاً یک مشکل تکنولوژیک نیست. هر کدام یک حلقه‌ی مفقوده هستند: حلقه‌ای میان تجربه و چیزی که باید تغییر دهد، و حلقه‌ای میان آن تغییر و شواهدی که نشان دهد تغییر رخ داده است.
Pause and Learn: یادگیری در حین اجرای پروژه
مرکز پرواز فضایی NASA Goddard بخشی از این مشکل را با روشی به نام Pause and Learn حل کرد. تیم پروژه به‌جای انتظار برای بازبینی پایان پروژه، در نقاط کلیدی از چرخه حیات پروژه متوقف شده و با هم به Reflection می‌پردازند.
As Edward Rogers and Barbara Fillip describe it, a standard session brings 10 to 20 people from one project team together for about 90 minutes. It covers four or five topics chosen in advance and works through three questions: what went well, what did not, and what we would do differently. Ground rules are read at every session. The discussion is captured as a knowledge map, reviewed with the project manager, and shared in later workshops. Sessions are planned in the project's lessons learned plan, not called only when something breaks.
روش Pause and Learn دو نکته را به‌درستی رعایت می‌کند: اول اینکه درس‌ها را زمانی ثبت می‌کند که حافظه هنوز تازه است؛ و دوم اینکه گفتگو را در همان تیمی نگه می‌دارد که قرار است بر اساس آن عمل کند. آنچه این روش به‌تنهایی انجام نمی‌دهد، تضمین این است که پروژه بعدی حتماً از آن درس استفاده کند. برای این کار به یک مرحلهٔ دیگر نیاز است.
یک فرآیند درس‌های آموخته‌شده که چرخه را کامل می‌کند
The international standard for knowledge management systems, ISO 30401, sets requirements for establishing, implementing, maintaining, reviewing and improving a knowledge management system. The NIST Baldrige Excellence Framework asks, in item 4.2, how you build and manage organisational knowledge, how you share best practices, and how you use your knowledge to embed learning in the way your organisation operates. Both point to the same idea: knowledge has a lifecycle, and capture is only its first stage.
در عمل، یک چرخهٔ کاری شامل سه مرحله است.
1. Capture in four fields. For each lesson, write what you expected, what actually happened, why the gap occurred, and what you will change. The last field is the one that matters. If a team cannot name a change, it has an observation, not a lesson.
2. Link the lesson to its target. Every lesson should point to the procedure, checklist, template or decision it changes. Update that document, and record the link. Now the lesson lives where the next team will work, not in a folder they have to remember to open.
3. Check that the next project applied it. When a later project reaches the step the lesson affects, confirm that the updated procedure was used. If it was, the lesson is applied. If it was not, find out why. Perhaps the change was unclear, or the step was skipped. That finding is itself a lesson, and it goes back to step one.
قاعدهٔ ما در Roadyom این است: اثبات قبل از ادعا. برای درس‌ها، این یعنی هیچ چیزی تا زمانی که در کار بعدی نشان داده نشود، آموخته‌شده محساد نمی‌شود. بنابراین چرخه را با آخرین مرحلهٔ آن بسنجید. یک شاخص ساده و کاربردی این است: از درس‌های ثبت‌شده در سال گذشته، چند مورد به یک دستورالعمل لینک شده‌اند و چند مورد از آن‌ها توسط پروژه بعدی اجرا شده‌اند؟ رشد این عدد سخت‌تر از شمارش تعداد درس‌های ثبت‌شده است، اما تنها عددی است که به شما می‌گوید آیا در حال یادگیری هستید یا خیر.
درسی که تغییری را نام نبرد، یک مشاهده است. تغییری که هیچ مرحلهٔ بعدی از آن استفاده نکند، یک پیش‌نویس است.
نحوه اجرای این چرخه توسط Prism
Prism تصمیمات و دانش یک سازمان را به عنوان گام‌هایی در خودِ فرآیند کار نگه می‌دارد. یک تیم می‌تواند در هر مرحله، یک رکورد Pause and Learn باز کند، آنچه انتظار می‌رفت، آنچه رخ داد، علت آن و تغییرات لازم را ثبت کند و هر درس را به دستورالعملی که باید به‌روز شود، لینک کند. Prism یک درس را تنها زمانی «نهادینه شده» می‌داند که به یک دستورالعمل لینک شده باشد و مرحلهٔ بعدی آن را اجرا کرده باشد. تا آن زمان، درس به عنوان «باز» قابل مشاهده باقی می‌ماند. افراد تصمیم می‌گیرند چه چیزی تغییر کند؛ Prism ثبت می‌کند که آیا آن تغییر پابرجا ماند یا خیر.
منابع
- Survey of NASA’s Lessons Learned Process (GAO-01-1015R). U.S. General Accounting Office (now Government Accountability Office), 2001.
- Review of NASA’s Lessons Learned Information System (IG-12-012). NASA Office of Inspector General, 2012.
- Mapping Lessons Learned to Improve Contextual Learning at NASA. NASA Goddard Space Flight Center (E. W. Rogers, B. Fillip), NASA Technical Reports Server, 2016.
- Developing a systemic lessons learned knowledge model for organisational learning through projects. International Journal of Project Management 33(2) (S. Duffield, S. J. Whitty), 2015.
- ISO 30401:2018 Knowledge management systems — Requirements. International Organization for Standardization, 2018.
- Baldrige Excellence Builder 2021–2022 (Item 4.2, Information and Knowledge Management). NIST Baldrige Performance Excellence Program, 2021.
نظرات
یکپارچه شده در ROADYOM Prism
بیشتر بدانید
