در بسیاری از سازمان‌های پروژه‌محور، وقتی یک پروژه به پایان می‌رسد، یکی از آخرین کارهایی که انجام می‌شود جمع‌آوری و آرشیو مستندات است. پوشه‌های پروژه بسته می‌شوند، مدارک نهایی در سامانه قرار می‌گیرند، نقشه‌ها و گزارش‌ها ثبت می‌شوند و معمولاً این احساس شکل می‌گیرد که «تجربه پروژه» برای سازمان باقی مانده است. سال‌ها بعد، وقتی پروژه مشابهی شروع می‌شود، افراد سراغ همان آرشیو می‌روند، فایل‌های پروژه قبلی را پیدا می‌کنند و تصور می‌کنند با دسترسی به آنها می‌توانند از تجربه گذشته استفاده کنند. اما یک سؤال ساده وجود دارد: آیا آنچه در آرشیو پیدا می‌شود واقعاً همان چیزی است که تیم پروژه آینده به آن نیاز دارد؟ پاسخ همیشه مثبت نیست.
یک پروژه معمولاً حجم زیادی سند از خود به جا می‌گذارد، اما همه آنچه در طول پروژه آموخته شده در این اسناد وجود ندارد. گزارش‌ها، نقشه‌ها، قراردادها، برنامه‌های زمان‌بندی، صورتجلسات، مکاتبات و مدارک فنی عمدتاً نشان می‌دهند چه چیزی قرار بوده انجام شود و در نهایت چه چیزی انجام شده است. در حالی که بخش مهمی از دانش پروژه در فاصله میان این دو نقطه شکل گرفته است؛ جایی که تیم پروژه با یک مسئله مواجه شده، تصمیمی گرفته، مسیر اولیه را تغییر داده، اشتباهی مرتکب شده، راه‌حلی پیدا کرده یا متوجه شده است که فرض اولیه چندان درست نبوده است.
این همان چیزی است که نیک میلتون در مقاله‌ای با عنوان «Storing project files is not the same as storing knowledge» روی آن دست می‌گذارد. از نگاه او، نگهداری فایل‌های پروژه با نگهداری دانش پروژه یکی نیست؛ چون فایل‌ها عمدتاً آنچه را که برنامه‌ریزی و اجرا شده ثبت می‌کنند، اما الزاماً «نگاه به گذشته» یا همان Hindsight را که از تجربه پروژه حاصل شده، ثبت نمی‌کنند. مقاله نیک میلتون
این تفاوت در ظاهر ساده است، اما در عمل یکی از چالش‌های جدی مدیریت دانش در سازمان‌های پروژه‌محور به شمار می‌رود.
فرض کنیم پروژه‌ای صنعتی به پایان رسیده است. در آرشیو سازمان، برنامه زمان‌بندی اولیه و برنامه نهایی پروژه وجود دارد. برای پروژه بعدی که مشابه همین پروژه است، مدیر پروژه می‌تواند هر دو را پیدا کند و حتی تفاوت‌هایشان را هم ببیند. اما چیزی که احتمالاً در این فایل‌ها پیدا نمی‌کند این است که چرا برنامه اولیه محقق نشد. آیا برآورد زمان فعالیت‌ها اشتباه بود؟ آیا تأمین یک تجهیز خاص زمان بیشتری از انتظار گرفت؟ آیا پیمانکار آمادگی لازم را نداشت؟ آیا تغییرات طراحی باعث به‌هم خوردن برنامه شد؟ یا اساساً در زمان برنامه‌ریزی، ریسکی دیده نشده بود؟
خود فایل زمان‌بندی پاسخ این سؤال‌ها را نمی‌دهد.
حتی اگر صورتجلسات و مکاتبات پروژه هم در آرشیو موجود باشد، پیدا کردن پاسخ از میان صدها یا هزاران سند کار ساده‌ای نیست. تازه ممکن است بخشی از این دانش اصلاً هیچ‌وقت در سندی ثبت نشده باشد. شاید مدیر پروژه و اعضای تیم در جلسات مختلف به این نتیجه رسیده باشند که برای پروژه مشابه، باید از ابتدا زمان بیشتری برای یک فعالیت خاص در نظر گرفت. شاید واحد تأمین به تجربه فهمیده باشد که یک نوع تجهیز خاص، به دلیل شرایط بازار یا محدودیت‌های حمل، نیازمند برنامه‌ریزی زودهنگام است. شاید تیم کنترل کیفیت متوجه شده باشد که یک روش بازرسی در اجرا جواب نمی‌دهد و باید از ابتدا تغییر کند.
اینها دقیقاً همان چیزهایی هستند که برای پروژه آینده ارزش دارند، اما لزوماً در پوشه پروژه قبلی پیدا نمی‌شوند.
از این منظر، شاید بتوان گفت سازمان‌ها گاهی بیش از اندازه به «ذخیره کردن» توجه می‌کنند و کمتر به «یاد گرفتن» توجه دارند.
این موضوع را می‌توان در پروژه‌های مختلفی که در سازمان‌های صنعتی و پروژه‌محور دیده می‌شود، به‌وضوح مشاهده کرد. یکی از مشکلاتی که در گفتگوهای مرتبط با مدیریت دانش پروژه بارها خودش را نشان می‌دهد، مسئله آرشیو نامناسب پروژه‌هاست. در نگاه اول، چنین مسئله‌ای یک مشکل مستندسازی به نظر می‌رسد؛ یعنی باید فایل‌ها بهتر نگهداری شوند، ساختار آرشیو مشخص باشد و دسترسی به مدارک آسان‌تر شود. این اقدامات قطعاً لازم‌اند، اما مسئله عمیق‌تر از این حرف‌هاست.
وقتی یک پروژه قدیمی در دسترس نباشد، سازمان فقط چند فایل را از دست نداده است؛ بخشی از حافظه خود را از دست داده است.
حتی اتفاقاتی مانند آسیب دیدن یا از بین رفتن مدارک یک پروژه می‌تواند نشان دهد که وابستگی سازمان به حافظه مستند تا چه اندازه جدی است. وقتی برای ادامه یا بازسازی یک پروژه به نقشه‌ها، مدارک فنی یا اطلاعات تصمیم‌های گذشته نیاز داریم و این اطلاعات در دسترس نیست، تازه متوجه می‌شویم که آرشیو پروژه فقط یک مخزن فایل نیست؛ بخشی از زیرساخت یادگیری سازمان است.
اما حتی یک آرشیو کامل هم به‌تنهایی سازمان را یادگیرنده نمی‌کند.
فرض کنید تمام مدارک یک پروژه بدون نقص نگهداری شده‌اند. همه نقشه‌ها موجودند، قراردادها ثبت شده‌اند، مکاتبات و صورتجلسات قابل دسترسی‌اند و حتی یک موتور جست‌وجوی مناسب هم برای پیدا کردن آنها وجود دارد. حالا یک پروژه جدید شروع می‌شود و تیم پروژه تصمیم می‌گیرد از پروژه قبلی استفاده کند. آنها می‌توانند دقیقاً ببینند پروژه قبلی چه کرده است. اما هنوز یک سؤال مهم بی‌پاسخ مانده است: «اگر تیم قبلی امروز دوباره آن پروژه را شروع می‌کرد، چه چیزی را متفاوت انجام می‌داد؟»
به نظرم ارزش واقعی مدیریت دانش دقیقاً در همین سؤال قرار دارد.
در مدیریت دانش، قرار نیست فقط گذشته را برای آینده نگه داریم؛ قرار است تجربه گذشته را به شکلی در اختیار آینده قرار دهیم که تصمیم‌گیری را بهتر کند. این یعنی باید از سطح «چه اتفاقی افتاد؟» عبور کنیم و به «چرا اتفاق افتاد و دفعه بعد چه کار کنیم؟» برسیم.
برای مثال، نگهداری پیشنهاد فنی و مالی یک پروژه ممکن است برای سوابق سازمان ضروری باشد، اما برای پروژه بعدی لزوماً کافی نیست. چیزی که پروژه آینده به آن نیاز دارد این است که بداند در پیشنهاد قبلی چه فرضی اشتباه بوده، چه بخشی از قیمت‌گذاری واقع‌بینانه نبوده، کدام ریسک دیده نشده و اگر دوباره قرار باشد برای پروژه مشابه پیشنهاد تهیه شود، چه تغییری باید در آن ایجاد شود.
همین موضوع درباره بودجه هم صدق می‌کند. بودجه اولیه و هزینه نهایی دو سند مهم هستند، اما دانش واقعی زمانی ایجاد می‌شود که بدانیم اختلاف این دو از کجا آمده است. اگر هزینه پروژه از برآورد اولیه بیشتر شده، صرفاً ثبت رقم نهایی چیزی به پروژه بعدی یاد نمی‌دهد. باید مشخص شود چه چیزی باعث افزایش هزینه شده، کدام بخش قابل پیشگیری بوده و در پروژه مشابه بعدی چه تغییری باید در برآورد یا مدیریت هزینه ایجاد شود.
در طراحی و مهندسی نیز همین اتفاق می‌افتد. نگهداری نقشه اولیه پروژه مهم است، اما گاهی نقشه نهایی و تغییرات ایجادشده در طول اجرا ارزش دانشی بیشتری دارند. مهم‌تر از آن، دانستن دلیل این تغییرات است. اگر در طراحی تغییری ایجاد شده، پروژه بعدی باید بداند این تغییر ناشی از چه تجربه‌ای بوده است. در غیر این صورت ممکن است همان طراحی اولیه دوباره انتخاب شود و همان مسیری که قبلاً منجر به اصلاح شده، دوباره طی شود.
این همان جایی است که مفهوم «As-Built» در کنار مستندات اولیه اهمیت پیدا می‌کند. آنچه در نهایت ساخته شده، همیشه دقیقاً همان چیزی نیست که در ابتدا طراحی شده بود. فاصله میان این دو، خودش یک منبع دانش است. اگر سازمان فقط نسخه اولیه و نسخه نهایی را ذخیره کند اما درباره علت تغییرات چیزی نداند، بخش مهمی از تجربه پروژه از دست رفته است.
پس برای استخراج دانش از پروژه، لازم است بعد از اجرا مکث کنیم و پروژه را دوباره مرور کنیم. این مرور نباید صرفاً یک جلسه تشریفاتی برای تکمیل فرم درس‌آموخته‌ها باشد. اگر قرار باشد اعضای پروژه در پایان کار چند فرم را پر کنند و بنویسند «ارتباطات باید بهتر باشد» یا «برنامه‌ریزی دقیق‌تر انجام شود»، احتمالاً چیز زیادی به دانش سازمان اضافه نشده است.
مرور واقعی تجربه نیازمند گفت‌وگو و تحلیل است. باید از افراد پرسید چه چیزی طبق انتظار پیش رفت، چه چیزی پیش نرفت، علت چه بود، در طول پروژه چه چیزی یاد گرفتیم و اگر امروز دوباره در ابتدای پروژه قرار می‌گرفتیم، چه تصمیمی را تغییر می‌دادیم.
سؤال آخر از همه مهم‌تر است.
»با دانشی که امروز داریم، اگر به روز اول پروژه برگردیم، چه کاری را متفاوت انجام می‌دهیم؟«
پاسخ به این سؤال همان چیزی است که در فایل‌های پروژه وجود ندارد و باید از ذهن و تجربه افراد استخراج شود.
اینجاست که روش‌هایی مانند After Action Review، جلسات Retrospect و سایر فرآیندهای یادگیری از تجربه اهمیت پیدا می‌کنند. این روش‌ها کمک می‌کنند تجربه افراد از حالت یک خاطره شخصی خارج شود و به دانشی تبدیل شود که دیگران هم بتوانند از آن استفاده کنند. البته انجام چنین کاری زمان می‌خواهد. نیاز به فضای گفت‌وگو، مشارکت افراد درگیر پروژه و گاهی تسهیلگری حرفه‌ای دارد. اگر این فرآیند جدی گرفته نشود، معمولاً افراد به بیان کلیات بسنده می‌کنند.
انجمن‌های خبرگی نیز می‌توانند در همین نقطه نقش مهمی داشته باشند. تجربه‌ای که در یک پروژه اتفاق افتاده، الزاماً فقط برای همان پروژه ارزش ندارد. ممکن است مسئله‌ای که یک تیم در تأمین کالا با آن مواجه شده، برای پروژه دیگری هم تکرار شود. ممکن است تجربه یک پروژه در انتخاب پیمانکار، کنترل کیفیت، مدیریت اسناد یا برنامه‌ریزی بتواند برای ده‌ها پروژه دیگر مفید باشد.
در جلسات انجمن‌های خبرگی، بخش مهمی از این دانش در جریان گفت‌وگو شکل می‌گیرد. یک نفر تجربه‌ای را مطرح می‌کند، فرد دیگری می‌گوید در پروژه خودش شرایط مشابهی داشته و راه متفاوتی را امتحان کرده است، نفر سوم به یک ریسک اشاره می‌کند که قبلاً دیده نشده بود و در نهایت گروه می‌تواند از میان این تجربه‌ها به یک توصیه کاربردی برسد. این فرآیند چیزی نیست که بتوان صرفاً با جست‌وجوی کلمات کلیدی در آرشیو پروژه به آن دست پیدا کرد.
به همین دلیل، مدیریت دانش پروژه را نمی‌توان به مدیریت اسناد تقلیل داد. مدیریت اسناد بیشتر به این سؤال پاسخ می‌دهد که «اطلاعات کجاست؟» اما مدیریت دانش باید یک قدم جلوتر برود و بپرسد «از این اطلاعات چه چیزی یاد گرفته‌ایم؟»
البته این دو در مقابل یکدیگر نیستند. یک نظام مدیریت دانش خوب به یک نظام مدیریت اسناد خوب نیاز دارد. اگر مدارک پروژه‌ها درست نگهداری نشوند، بخش مهمی از حافظه سازمان از بین می‌رود. مسئله این است که نباید تصور کنیم با تکمیل آرشیو، کار ما تمام شده است.
شاید بهتر باشد به جای اینکه آرشیو پروژه را فقط یک محل نگهداری سوابق ببینیم، آن را بخشی از یک سیستم یادگیری بدانیم. در چنین سیستمی، اسناد پایه و شواهد را فراهم می‌کنند، افراد تجربه خود را به اشتراک می‌گذارند، فرآیندهای مرور و تحلیل به استخراج درس‌آموخته کمک می‌کنند و در نهایت دانش استخراج‌شده به شکلی در اختیار پروژه‌های بعدی قرار می‌گیرد که بتوانند واقعاً از آن استفاده کنند.
در این حالت، یک پروژه فقط یک مجموعه فایل به پروژه بعدی تحویل نمی‌دهد؛ بلکه مجموعه‌ای از تجربه‌های تحلیل‌شده، تصمیم‌های آزموده‌شده و توصیه‌های کاربردی را نیز منتقل می‌کند.
تفاوت این دو رویکرد در نتیجه‌ای که برای سازمان ایجاد می‌کنند بسیار جدی است. اگر پروژه بعدی فقط فایل‌های پروژه قبلی را دریافت کند، ممکن است همان تصمیم‌ها را تکرار کند، همان ریسک‌ها را نبیند و حتی همان اشتباهات را دوباره تجربه کند. اما اگر بداند تیم قبلی چه چیزی را تجربه کرده و با نگاه امروز چه توصیه‌ای برای تیم آینده دارد، گذشته می‌تواند به ابزاری برای پیش‌بینی و تصمیم‌گیری بهتر تبدیل شود.
شاید بتوان این موضوع را با یک تعبیر ساده توضیح داد: فایل‌های پروژه حافظه سازمان هستند، اما درس‌آموخته‌ها تجربه سازمان‌اند. حافظه به ما کمک می‌کند به خاطر بیاوریم چه اتفاقی افتاده است؛ تجربه به ما کمک می‌کند بدانیم با آن اتفاق چه کنیم. هدف مدیریت دانش هم دقیقاً همین است؛ اینکه سازمان مجبور نباشد برای یاد گرفتن هر درس، دوباره هزینه اجرای یک پروژه را بپردازد.
هر پروژه‌ای که تمام می‌شود، در واقع می‌تواند نقطه شروع پروژه دیگری باشد. اگر سازمان فقط مدارک آن را نگه دارد، بخش زیادی از این فرصت از دست می‌رود. اما اگر بتواند از دل تجربه پروژه بفهمد چه چیزی درست کار کرده، چه چیزی جواب نداده و دفعه بعد چه باید کرد، آن پروژه حتی بعد از پایان رسمی خود نیز برای سازمان ارزش ایجاد می‌کند.
در نهایت، مسئله این نیست که فایل‌های پروژه را ذخیره کنیم یا نکنیم. آنها باید ذخیره شوند. مسئله این است که بدانیم فایل، پایان فرآیند یادگیری نیست؛ نقطه شروع آن است.
پروژه‌های گذشته برای سازمان یک سؤال مهم به جا می‌گذارند: اگر امروز دوباره همان پروژه را شروع می‌کردیم، چه چیزی را متفاوت انجام می‌دادیم؟
پاسخ این سؤال همان دانشی است که باید برای آینده حفظ شود.
به تعبیر دیگری، سازمان نباید فقط گذشته را به آینده تحویل بدهد؛ باید تجربه‌شده‌ترین نسخه گذشته را به آینده منتقل کند.
چرا که هدف واقعی مدیریت دانش، تکرار کردن کاری که قبلاً انجام داده‌ایم نیست؛ هدف این است که پروژه بعدی مجبور نباشد همان مسیر را دوباره طی کند تا خودش به همان نتیجه برسد.
