فصل ۱: مقدمه — معمای زیبا: سیستم‌های مدیریت مهندسی

فصل ۱: مقدمه

مسئله‌ای که با تلاش بیشتر حل نمی‌شود

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

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

از یادداشت‌های وبلاگ تا یک نقشه

کتابی که از یک وبلاگ بیرون آمد

لارسون این کتاب را یک‌جا ننوشت. سال‌ها در وبلاگش، Irrational Exuberance، بعد از هر مسئلهٔ دشوار یک یادداشت کوتاه می‌نوشت؛ یادداشتی دربارهٔ اینکه چرا آن تغییر جواب داد و آن یکی نه. این یادداشت‌ها در دیگ، اوبر و استرایپ انباشته شدند: سه محیط با سه مقیاس، از تیمی کوچک تا سازمانی که هر سال بزرگ‌تر می‌شد، و مسیری که از نوشتن کد شروع شده بود و به مدیریت سازمان رسیده بود. وقتی قرار شد کتابی نوشته شود، مادهٔ خام آماده بود و کار اصلی، مرتب‌کردن و دوختن آن‌ها به هم بود؛ یادداشت‌ها به بخش‌هایی چون سازمان‌ها و ابزارها و رویکردها تقسیم شدند و هر فصل شکل یک ابزار پیدا کرد. نتیجه، کتابی است که بوی یک مسئلهٔ واقعی را می‌دهد، نه بوی یک نظریهٔ مرتب؛ و همین است که فصل‌هایش را، حتی وقتی سال‌ها از نوشتنشان گذشته، هنوز می‌توان به کار برد.

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

پازل زیبا یعنی دیدن کل

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

چهار پرسش پیش از هر مداخله

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

مدیری که هنوز همه را بازبینی می‌کند

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

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

طراحی، نه آزمون فضیلت

سه اتصالی که مدیر زنده نگه می‌دارد

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

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