توسعه و تولید ذاتاً متفاوت هستند. ولی مدیران توسعه و کارهای مرتبط با آن اغلب تفکرشان با فلسفه‌ی مدیریتی که کاملاً از محیط تولید برآمده، شکل گرفته است.
تصور کنید مدیر شعبه‌ای از یک فست‌فود هستید. کاملاً منطقی به نظر می‌آید که بعضی یا همه‌ی اقدامات زیر را برای بهره‌وری تولید به کار ببندید:
- کمینه کردن خطا. کاری کنید که ماشین‌ها (و ماشین انسان) تا حد ممکن روان کار کنند.
- برخورد سخت با کسانی که در کار اشتباه می‌کنند.
- مواجهه با کارکنان همانند قطعات قابل تعویض ماشین
- بهینه‌سازی حالت پایدار. به اینکه کار چطور روی غلتک می‌افتد یا چقدر طول می‌کشد از کار بایستد، فکر هم نکنید.
- استاندارد کردن فرآیند. انجام دادن تمام کارها عین دستورالعمل.
- حذف آزمایش و تجربه. آدم‌های دفتر مرکزی برای همین حقوق می‌گیرند.
اگر در کار فست‌فود (یا هر محیط تولیدی دیگر) باشید، این‌ها رویکردهایی منطقی خواهند بود؛ ولی شما در آن محیط کار نمی‌کنید. ذهنیت «چیزبرگر بساز، چیزبرگر بفروش» برای محیط توسعه می‌تواند مهلک باشد. فقط می‌تواند به تضعیف روحیه‌ی کارکنان شما و پرت کردن حواسشان از مسائل اصلی کمک کند. این شیوه‌ی مدیریت در تقابل مستقیم با کار خواهد بود.
برای مدیریت مؤثر متخصصان، باید اقداماتی تقریباً خلاف موارد بالا انجام دهید. رویکرد معکوس پیشنهادی‌مان را در بخش‌های پیش رو شرح داده‌ایم.
جایی برای خطا بگذارید #
برای بیش‌تر متخصصان، اشتباه‌های گاه و بی‌گاه بخشی طبیعی و سالم از کار است. ولی ممکن است خطا در کار، کنار مفهوم گناه قرار داده شود. برای تغییر این نگرش، باید به طور ویژه‌ای تلاش کنیم.
در صحبت با گروهی از مدیران نرم‌افزار، بر مبنای تصوری که از طراحی مبتنی بر تکرار داشتیم، یک استراتژی ارائه دادیم. ایده این است که بعضی از طرح‌ها ذاتاً مستعد نقص هستند؛ آن‌ها قرار است کنار گذاشته شوند، نه اینکه ترمیم شوند. باید انتظار چنین بن‌بست‌هایی را در کار طراحی داشت. زحمت از دست رفته برای این بن‌بست، هزینه‌ی کمی برای یک شروع تازه است. در کمال شگفتی، بسیاری از مدیران حس می‌کردند این موضوع یک مشکل حل‌نشدنی برای رییس‌شان به وجود خواهد آورد: «چطور محصولی که شرکت برای تولید آن پول داده را دور بریزیم؟». به نظر می‌آمد اعتقاد دارند بهتر است نسخه‌ی معیوب را از نابودی نجات دهند، حتی اگر در طولانی مدت برایشان هزینه‌ی بیش‌تری داشته باشد.
ایجاد فضایی که اجازه‌ی خطا نمی‌دهد، به سادگی افراد را تدافعی می‌کند. آن‌ها چیزهایی را که ممکن است بد از کار در بیایند، امتحان نمی‌کنند. وقتی تلاش می‌کنید فرآیند را سیستمی کنید، وقتی سازوکارهایی سفت‌وسخت تحمیل می‌کنید که کارکنان مجاز به هیچ تصمیم استراتژیکی نباشند (تا مبادا اشتباه کنند)، این تدافعی بودن را تشویق می‌کنید. با برداشتن هر قدم در راستای مهار خطا، ممکن است سطح متوسط فناوری کمی بهبود یابد، ولی روابط انسانی در تیم به شدّت آسیب می‌بیند.
رویکرد دیگر این است که کارکنان را ترغیب کنیم کمی اشتباه کنند. برای انجام این کار، هر از گاهی از آن‌ها بپرسید به چه بن‌بست‌هایی رسیده‌اند، و مطمئن شوید می‌دانند «هیچ بن‌بستی» بهترین جواب نیست. وقتی افراد خراب‌کاری کردند، باید به آن‌ها تبریک گفت؛ این بخشی از چیزی‌ست که برایش پول می‌گیرند.
مدیریت: تعریف عامیانه #
مدیریت به قدر کافی پیچیده هست که نتوان تعریف ساده‌ای از آن ارائه داد. ولی تمام ریزه‌کاری‌های آن وقتی با مدیری با تجربه در یک رویداد کاری در لندن برخورد کردیم، به یک‌باره ناپدید شد. او کل دیدگاهش از موضوع را در یک جمله جمع‌بندی کرد:
مدیریت، فشارآوردن است.
این برابر با همان دیدگاهی‌ست که مدیریت به همه چیز فکر می‌کند و افراد زیردست فقط دستورات را اجرا می‌کنند. بازهم این تفکر ممکن است در تولید چیزبرگر کارآمد باشد، ولی نه برای کاری که با ذهن (و نه با دست) انجام می‌شود. در چنین محیطی همه باید فکرشان را به کار بگیرند. ممکن است بتوانید با فشارآوردن آدم‌ها را فعال‌تر کنید، ولی نمی‌توانید آن‌ها را خلاق، مبتکر و متفکر کنید.
حتی اگر فشار آوردن به افراد در کوتاه مدت باعث افزایش بهره‌وری آن‌ها شود، در بلند مدت مفید نخواهد بود: برای کارمند، چیزی ناامید کننده‌تر از این نیست که حس کند انگیزه‌ی خودش برای انجام کار کافی نیست و لازم است توسط مدیر «تکمیل شود».
ناراحت‌کننده‌ترین موضوع درباره‌ی این روش مدیریت این است که تقریباً همیشه زاید است. برای اینکه کارمندان‌تان کار کنند، به ندرت نیاز به اقدامات دیوصفتانه دارید. اغلب آن‌ها کارشان را دوست دارند. حتی ممکن است لازم باشد گاهی قدم‌هایی بردارید تا کم‌تر کار کنند و در نتیجه، کار باارزش بیش‌تری انجام دهند (درباره این ایده در فصل سوم، ویَن منتظر شماست، بیش‌تر صحبت می‌کنیم).
فروشگاه آدمیزاد #
نگاه به انسان به چشم قطعه‌ای از ماشین، در محیط تولید مرسوم است. وقتی قطعه‌ای فرسوده می‌شود، قطعه‌ی دیگری جایگزین می‌کنید. قطعه‌ی جایگزین و قطعه‌ی اصلی، معادل هم هستند و می‌توانید آن را با همان شماره قطعه سفارش دهید.
بسیاری از مدیران توسعه همین نگرش را دارند. به جد تلاش می‌کنند خودشان را قانع کنند که هیچ‌کس جایگزین‌ناپذیر نیست. از ترس اینکه فردی کلیدی کار را ترک کند، خودشان را مجبور می‌کنند باور کنند چیزی به اسم فرد کلیدی وجود ندارد. از این گذشته، مگر ذات مدیریت همین نیست که مطمئن شویم کار با یا بدون افراد ادامه پیدا می‌کند؟ آن‌ها طوری رفتار می‌کنند که انگار یک «فروشگاه جادویی آدمیزاد» وجود دارد که می‌توانند زنگ بزنند و بگویند: «یک جرج گاردنهایر جدید برایم بفرستید؛ فقط کمی کم‌تر افاده‌ای باشد.»
یکی از مشتری‌های من متعجب بود که یکی از کارمندان عالی، در بازنگری حقوقش چیزی غیر از پول درخواست کرده است. او گفته بود که اغلب در خانه ایده‌های خوبی داشته ولی اینترنت کند خانگی‌اش او را اذیت می‌کند. آیا شرکت می‌تواند برای او اینترنت بهتر و کامپیوتر سریع‌تر بخرد؟ البته که شرکت می‌توانست. در سال‌های بعد حتی یک اتاق کار کوچک با تجهیزات کامل برایش ساخت. ولی مشتری من یک مورد نادر بود. برایم جای سؤال است که مدیری با درک کم‌تر در این شرایط چه کاری می‌کرد؟ برای بسیاری از مدیران، هر کاری که کارکنان برای اثبات فردیت‌شان انجام دهند، یک تهدید است.
— تیموتی لیستر
یک مثال از مدیر با درک پایین، رییسی بود که نشانه‌های شدید «مورد تهدید فردیت کارکنان قرار گرفتن» را بروز داد: کارمندی بسیار با استعداد داشت که برای بازدید از موقعیت مشتری‌ها، همیشه در سفر بود و از حساب شرکت هزینه می‌کرد. تحلیل هزینه‌های او نشان داده بود او برای غذا بیش از مقدار متعارف دیگر همکاران هزینه می‌کند. ۵۰درصد بیش‌تر از دیگران برای غذا خرج می‌کرد. رییس او در یادداشتی عمومی و با اوقات تلخی او را «جنایت‌کار غذایی» نامیده بود. در حالی که کل مخارج آن کارمند نامتعارف نبود؛ هرچقدر برای غذا بیش‌تر خرج می‌کرد، جای دیگر صرفه‌جویی کرده بود. آن فرد پرخرج‌تر نبود، فقط متفاوت بود.
منحصر به فرد بودن هر کارمند برای مدیری که شیوه‌ی مدیریتی را کورکورانه از دنیای تولید به‌کار گرفته است، آزاردهنده است. از سوی دیگر، یک مدیر طبیعی «انسان‌ها»، درک می‌کند که منحصر به فرد بودن برای حیات پروژه واجب و مؤثر است و باید پرورش داده شود.
پروژه در حالت پایدار، مرده است #
تفکر حالت پایدارِ برآمده از تولید، به طور خاص برای کار پروژه‌ای نامناسب است. تمایل داریم فراموش کنیم که هدف اصلی پروژه این است که به موقع وارد و به موقع از کسب‌وکار خارج شود. تنها حالت پایدار در چرخه‌ی زندگی یک پروژه، مرگ است. به جز وقتی که در حال پیش‌برد پروژه ای لغو شده یا در حال لغو باشید، تمام تمرکز مدیریت پروژه باید وقف پویایی کار توسعه باشد. با این حال، ارزش افراد برای یک پروژه جدید را اغلب بر اساس ویژگی‌های حالت پایدار آن‌ها ارزیابی می‌کنیم: چقدر می‌توانند کد بنویسند یا مستندات تولید کنند. به اینکه هر کدام چقدر خوب با کل کار جور می‌شود، خیلی کم توجه می‌کنیم.
چند سال قبل، تدریس یک دوره‌ی درون سازمانی طراحی را بر عهده داشتم که یکی از مدیران ارشد سراغم آمد تا از من بخواهد برخی افراد در دوره را (از پروژه‌ی او) ارزیابی کنم. او به طور خاص در مورد یک زن کنجکاو بود. مشخص بود که در مورد آن زن تردید دارد: «نمی‌توانم ببینم چه آورده‌ای برای پروژه دارد. در برنامه‌نویسی، آزمون نرم‌افزار یا هر کار دیگری عالی نیست.» با کمی تحقیق و بررسی این حقیقت جالب روشن شد: زن مورد نظر طی ۱۲ سال حضورش در شرکت، در هیچ پروژه‌ای نبوده، مگر اینکه به موفقیت بزرگی رسیده باشد. روشن نبود که چه آورده‌ای برای پروژه دارد، ولی هر وقت حضور داشت، پروژه‌ها به موفقیت می‌رسیدند. بعد از یک هفته مشاهده‌ی او در کلاس و صحبت با برخی از همکارانش، به این نتیجه رسیدم که او یک کاتالیزور عالی‌ست. تیم‌ها با حضور او بهتر با هم جور می‌شدند. او به افراد کمک می‌کرد ارتباط برقرار کنند و با هم کنار بیایند. وقتی او عضوی از تیم بود، پروژه‌ها لذت‌بخش‌تر بودند. هنگامی که تلاش کردم نظرم را برای مدیر بگویم، جا خوردم. مدیر، نقش کاتالیزور را برای یک پروژه ضروری نمی‌دانست. — تام دی‌مارکو
کاتالیزور مهم است چون پروژه همواره در حالت ناپایدار است. کسی که می‌تواند کمک کند پیوستگی لازم بین اعضا به وجود بیاید، به اندازه‌ی دو نفر که فقط کارشان را انجام می‌دهند، می‌ارزد.
برای فکر کردن به کار وقت نداریم، فقط باید انجامش دهیم #
اگر عهده‌دار انجام یک کار باشید، چه میزان از زمان‌تان را واقعاً باید به انجام دادن آن اختصاص دهید؟ قطعاً ۱۰۰درصد نیست. باید زمانی برای بارش فکری، بررسی روش‌های جدید، فهمیدن چگونگی پرهیز از برخی کارهای فرعی، مطالعه، تمرین و کمی بطالت، کنار بگذارید.
با نگاهی به سال‌هایی که خودمان مدیریت می‌کردیم، نتیجه گرفتیم که هر دوی ما از این نظر خارج از مسیر بودیم. ما بیش‌تر وقت‌مان را صرف تلاش برای به سرانجام رساندن کارها می‌کردیم و تقریباً وقت کافی برای پرسیدن سؤال اساسی نمی‌گذاشتیم: «آیا اصلاً این کار باید انجام شود؟». ذهنیت حالت پایدار چیزبرگری حتی به سختی تظاهر می‌کند که با ایده‌ی فکر کردن در کار موافق است. کاملاً تمایل دارد که تمام انرژی را در مرحله‌ی انجام کار صرف کند. اگر بهانه‌ای برای زمان نگذاشتن برای تفکر لازم باشد، بهانه همیشه فشار زمانی است – گویا تا‌به‌حال کاری بوده که بدون فشار زمانی انجام شده باشد.
اهمیت یک رویکرد سنجیده‌تر، با بالا رفتن ریسک به شدت افزایش می‌یابد. این زمانی است که لازم است تمام توان به کار گرفته شود و به همین دلیل باید بیاموزیم وقت کم‌تری صرف انجام کار کنیم و بیش‌تر درباره‌ی آن فکر کنیم. در همین راستا، هرچه تلاش جانانه‌تری لازم باشد، اهمیت اینکه اعضای تیم یادبگیرند به خوبی تعامل کنند و از آن لذت ببرند، بیش‌تر می‌شود. همان پروژه‌ای که باید تا یک تاریخ معین و غیرممکن انجام شود، دقیقاً همانی است که باید به طور مکرر جلسات بارش فکری و حتی یک شام کاری یا کارهای مشابه آن داشته باشد تا کمک کند افراد به عنوان یک کل مؤثر با هم جور شوند.
همه‌ی این توصیه‌ها توجه و مراقبت بیش از حد است. همه، این موارد را می‌دانند و مطابق آن عمل می‌کنند، درست است؟ نخیر! ما بسیار مشتاقیم که به سمت انجام دادن کار حرکت کنیم؛ هر کاری می‌کنیم تا تنها ۵درصد وقت خود را صرف مجموع این کارها کنیم: برنامه‌ریزی، بررسی روش‌های جدید، آموزش، مطالعه، برآورد کردن، بودجه‌بندی، زمان‌بندی و تخصیص پرسنل. (رقم ۵درصد از تجزیه و تحلیل پروژه‌های توسعه‌ی سیستم برآمده، امّا به نظر می‌رسد بتوان آن را تعمیم داد؛ شاید به کل گروه کارکنان حقوق‌بگیر.)
آمارها درباره‌ی مطالعه به طور خاصی دلسرد کنند‌ه‌اند: به عنوان مثال، یک توسعه‌دهنده نرم‌افزار به‌طور متوسط حتی یک کتاب در موضوع کار خود ندارد و تا کنون کتابی در این زمینه نخوانده است. این واقعیت برای هر کسی که نگران کیفیت کار در این زمینه باشد ترسناک است؛ برای کسانی مثل ما که کتاب می‌نویسند، واقعاً غم‌انگیز است.