کار دانش‌‌محور ناب – بخش چهارم- ساختار تبادل اطلاعات

ساختار تبادل اطلاعات

سازمان‌ها دریافته‌اند که خیلی از مشکلات بزرگتر و پیچیده‌تر از آن هستند که از عهده یک نفر بربیایند لذا به طور فزاینده‌ای از تیم‌ها برای انجام کار دانش‌محور استفاده می‌کنند. با این حال، وقتی چندین نفر در یک فرآیند مشارکت دارند، ارتباط مؤثر ضروری است – خصوصاً تیم‌هایی که اعضایی در نقاط مختلف دنیا دارند. یک سیستم ناب می‌تواند ارتباطات را بواسطه ارائه راهکارهایی ارتقا بخشد. در ادامه راهکارهایی اشاره می‌شود:

تعریف کنید چه کسی، چند وقت یکبار، و چه اطلاعاتی را باید منتقل کند

کارکنان دانش‌محور باید بدانند که چه کسی از خروجی کار آنها استفاده می‌کنند[1]. هنگامی‌که تأمین‌کننده کار در ارتباط مستقیم با “مشتری” (به طور معمول شخصی در همان تیم) باشد‌، این دو می‌توانند با هم همکاری کنند تا مطمئن شوند که خروجی مطابق انتظار عمل می‌کند. اگر ارتباطات مکرر جریان غنی از اطلاعات ایجاد کند، مشکلات را می‌توان خیلی زود کشف و برطرف کرد. و وقتی‌‌که محتوای مورد نظر در ارتباط مشخص شود، افراد اطلاعات مورد نیاز خود را دریافت می کنند و مجبور نیستند وقت خود را تلف کنند تا بفهمند دیگران چه می‌گویند.

یکی از ابزارهایی که ویپرو برای کمک به ارتباطات به کار گرفت، ماتریس ساختار طراحی بود. در DSM، وظایف یا کارهای پروژه در امتداد ردیف‌ها و ستون‌های یک ماتریس لیست می‌شود، و تیم ارتباط اقلام را با یکدیگر مشخص می‌کند، همچنین هر رابطه به عنوان یک وابستگی مستقیم یا یک حلقه بازخورد مشخص می‌شود. سپس براساس جبر ماتریسی (Matrix algebra) ترتیب کارها پیشنهاد می‌شود. (برای اطلاعات بیشتر مقاله «آیا مهندسان شما وقتی که باید با یکدیگر صحبت می کنند؟» را مطالعه نمایید)[2]. ریاضی کمی دشوارفهم است، اما ویپرو از یک نسخه‌ی صفحه گسترده (spreadsheet) استفاده کرد که هر تیمی می‌توانست آن را بفهمد. با فشار یک دکمه، برنامه وظایف را مرتب و تعیین می‌کرد که کی و کدامیک از اعضای تیم نیاز دارند تا با یکدیگر تعامل کنند.

درک مشترک ایجاد کنید

اعضای تیم‌های دانش‌محور به‌طور فزاینده‌ای در سراسر مرزهای جغرافیایی، فرهنگی، زبانی و عملکردی کار می‌کنند. این بدان معنی است که ممکن است آنها برداشت یکسانی از آنچه که تعامل می‌شود نداشته باشند. کلمات یکسان ممکن است برای افراد مختلف معنای متفاوتی داشته باشد. تعامل بین پرسنل یک شرکت آمریکایی را با یک ارائه‌دهنده‌ی خدمات فن‌آوری اطلاعات در هند در نظر بگیرید. در یک تعاملی که مستند شده بود سوالی به ظاهر ساده  مطرح شد: “آیا می توانید کار را تا یک مهلت مشخص انجام دهید؟” از نظر پرسنل شرکت آمریکایی بله یعنی بله و خیر یعنی خیر- و اگر کار درست پیش نرود ممکن است فریاد بزنند و با مشت روی میز بزنند. در مقابل، هندی‌ها غالباً پاسخ خیر را غیرمستقیم بیان می‌کنند که همتایان آمریکایی ممکن است آن را بله برداشت کنند. و هنگامی‌که هندی‌ها با مشکل مواجه می‌شدند، آنها را در قالب سؤالاتی ملایم مطرح می‌کردند، که عمدتاً توسط کارکنان امریکایی که به چنین ظرافت‌های کلامی عادت ندارند، نادیده گرفته شد. با وجود اینکه ارتباطات بین دو گروه ساختار یافته بود وقتی مطالب واضح منتقل نمی‌شد، به روزرسانی‌های منظمی بین طرف‌های مشخصی با تمرکز بر مجموعه‌ای از نقاط بحث وجود داشت. شرکت آمریکایی دریافت که هرگاه با تأمین کننده جدیدی وارد تعامل می‌شود، باید دقیقاً چگونگی ارتباط را برای تامین کننده مشخص کند.

در یک مجله‌‌ی شناخته شده نیز نیاز سازماندهیِ تبادل اطلاعات و ایجاد درک مشترک مشهود بود. یک ویراستار ممکن است مقاله‌ی طولانی را از یک نویسنده خارجی بگیرد و آن را برای ویرایش به همکارش بسپارد. چنین کارهایی به دلیل ضرورت تحویل به موقع و باکیفیت، اغلب چالش برانگیز و پر استرس است. مدیریت این معضل را فهمید اما این مسئله را اجتناب‌ناپذیر می‌دانست: آنها معتقد بودند که دست به دست کردن این نوع کار ذاتاً مشکل است زیرا ویراستاری شامل دانش ضمنی در موضوع و نحوه‌ی بیان ایده‌ها است و هیچ دو ویراستاری به یک روش به یک مقاله نمی‌پردازند.

این موارد درست بودند – اما بخشی از مشکل این بود که هیچ فرایند مشخصی برای ارتباط دو ویراستار در مورد هدف مقاله و چگونگی دستیابی به آن وجود نداشت. اغلب آنها اصلاً صحبت نمی‌کزدند. حتی وقتی آنها مشورت می‌کردند، گفتگوها بدون ساختار بود. این دو (ویراستار یابنده‌ی مقاله و ویراستاری که قرار بود ویراستاری کند) ممکن است در مورد پیش‌نویس و کارهای قبل از انتشار نظرات بسیار متفاوتی داشته باشند، و هیچ وسیله رسمی برای نزدیک کردن نقاط تعارض وجود نداشت.

مجله فرایند مشخصی برای ارسال پیشنهاد مقالات داشت: قرار بود هر پیشنهاد شامل توضیحی کتبی از ارزش محتوایی و برنامه‌ی ویرایش مقاله باشد. اما اغلب این پیشنهاد براساس توضیحات نویسنده‌ی مقاله، و پیش‌نویسی بود که در نهایت ممکن بود به طور قابل توجهی از پیشنهاد فاصله داشته باشد. گاهی اوقات ویراستاری که مقاله بدستش رسیده بود ممکن بود با ارائه پیشنهادی شفاهی به سردبیر، فرایند را دور بزند.

در یک رویکرد مؤثرتر ابتدا هر ویراستار یک پیشنهاد کتبی ارائه می‌کند، تا دلایل انتشار مقاله و ارزش قابل ارائه به خوانندگان درآن ثبت شود. هنگامی‌که پیش‌نویس کاملی از مقاله دریافت شد، هر دو ویراستار (هم گیرنده و هم ویراستار اختصاص داده شده) باید یک نقد مفصل و طرح ویراستاری بنویسند. (مورد دوم ممکن است شامل ساختار و طول، نیاز برای محتوای تکمیلی، استفاده از مثال‌ها و تخمین زمانی لازم برای تکمیل کار باشد.) مرحله آخر گفتگوی ساختار یافته‌ایست که توسط یک ویراستار برتر تسهیل می‌شود تا در آن هر سه روی این موضوعات به توافق برسند.

اگر تبادل اطلاعات به خوبی مشخص شده باشد، افراد کارهایی را که پذیرفته‌اند (مسئولیت دارند) درک می‌کنند. این به آنها اجازه می‌دهد تا به جای تلاش برای حل کارهای سطحی، وقت خود را صرف حل مشکلات کنند.

اختلافات را با حقایق حل کنید، نه با نظرات

یک پژوهش طولانی، رفتارهایی را نشان می‌دهد که احساسات و غیرمنطقی‌بودن می‌توانند روند تصمیم‌گیری را تحریف کنند. به‌ویژه وقتی کاری دانش ضمنی دارد، این مسئله می‌تواند مشکل بزرگی باشد، زیرا اغلب به هیچ وجه مشخص نیست که چگونه یک متخصص به یک تصمیم خاص رسیده است و تا چه میزان تصمیم‌گیری او مبتنی‌بر بصیرت یا احساسات به جای واقعیت‌ها بوده است.

یکی از پروژه‌های ناب ویپرو چالش و مزیت ارتباطات غیرمبهم را در یک تیم نشان می‌دهد. تیم مورد نظر سیستمی را برای بازنگری‌های منظم  و زمانبندی‌شده ایجاد کرده بود که در آن اعضای با تجربه‌تر تیم کدهایی که توسط همکاران کم تجربه نوشته شده بود را ارزیابی می‌کردند. هر فرد کم‌تجربه هر بار بازنگری متفاوتی داشت. هدف یافتن و رفع بهتر انواع مختلف اشتباهات بود، تا به افراد کم ‌تجربه‌تر کمک کند تا بتوانند پیشرفت کنند و به اعضای تیم اجازه دهند تا یکدیگر را بشناسند. متأسفانه، بازنگرهای ارشد از استانداردهای مختلفی استفاده کرده و ارزیابی‌های مختلفی را ابلاغ کردند. آنچه که برای یکی روش کد‌نویسی خوبی بود ممکن بود برای دیگری خطا باشد. حتی وقتی بازنگرها در مورد خطایی توافق داشتند، اغلب آن‌را چیزهای متفاوتی می‌نامیدند. فقدان استانداردها و تعاملات مشترک باعث آسیب‌رسیدن به روحیه کارکنان جوان شد.

یکی از بازنگر‌ها متوجه مشکل شد و تیم‌ها را برای بحث در مورد آن فراخواند. این گروه آن را فرصتی برای استانداردسازی ارتباطات و همچنین کارهای اولیه دانستند. برخی از اعضای ارشد لیستی از خطاهای رایج و تعاریف آنها برای استفاده‌ی همه بازنگرها جمع اوری کردند. این تمرین منجر شد تیم بسیاری از اشتباهاتی که آنها خطای فازی قلمداد می کردند را تشخیص دهند- موضوعاتی مربوط به مواردی چون نحوه تعریف متغیرها و چگونگی تعبیه توضیحات در کد- در واقع کاملاً ملموس بودند. و وقتی این موارد شفاف شد، خطاها  بطور سیستماتیک رفع شدند.

زبان تیم به زودی آنقدر دقیق شد که حتی یک دستگاه نیز می توانست آن را بفهمد: محیط کدنویسی می‌توانست به‌طور خودکار ارزیابی کند که آیا توسعه‌دهنده‌ها دستورالعمل‌ها را رعایت کرده‌اند یا در صورت مغایرت با دستورالعمل، پرچم قرمز را بالا ببرد.

در پایان تیم دریافت که زمان کمتری برای یافتن خطا صرف می‌کند و زمان بیشتری را برای جلوگیری از خطاها در مرحله اول صرف می‌کند. در نتیجه بروز خطاها به طور چشم‌گیری کاهش یافت.

[1] (مخاطب یا بهره بردار کار آنها چه کسی خواهد بود)

[2] (For more on the DSM, see “Are Your Engineers Talking to One Another When They Should?” by Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, HBR November 2007.)

مترجم: وحیده بانی‌گل

بازنگری نهایی: یاسر کازرونی

بخش پایانی این مقاله را می توانید در اینجا مطالعه کنید.