توسعه نرم‌افزار به روش تَرکه‌ای (Lean)

مطلبی که می‌خوانید ترجمه‌ قسمت ۱۹۰ از رادیو مهندسی نرم‌افزار است. رادیو مهندسی نرم‌افزار هر یکی دو هفته یک بار مصاحبه‌ای درباره‌ یکی از موضوعات حوزه‌ مهندسی نرم‌افزار با افراد خبره و با تجربه در موضوع مورد بحث ترتیب می‌دهد.

در این قسمت، کریستوف ابرت، رییس بخش مدیریت شرکت خدمات مشاوره‌ای وکتور، با فرانسیس پالیش درباره نگرشش به بکارگیری روش ترکه‌ای در تولید محصول صحبت می‌کند. این مصاحبه حول ۵ اصل کلیدی توسعه ترکه‌‌ای یعنی این موارد است: تمرکز سر تا سری (end-to-end) در خلق ارزش برای مشتری، حذف هدررفت، بهینه‌سازی جریان‌های ارزش، قدرت بخشیدن به افراد و بهبود مستمر. این پادکست IEEE به جای تئوری‌های مدیریت یا تولید، به مبحث توسعه ترکه‌ای نرم‌افزار می‌پردازد. در این پس‌زمینه، به دنبال آن هستیم که این سوال اصلی را طرح کنیم که کدام اصول طراحی، باعث تحویل ارزش می‌شوند و چگونه برای مدیریت بهینه تغییر بکار گرفته شده‌اند؟ بسیاری از مثال‌های عملی بیانگر نحوه بکارگیری روش ترکه‌ای بدون در تنگنا قرار دادن توسعه است.

کریستف، آیا ممکن است خود را معرفی کنید.

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

من در تعدادی از مشاوره‌های صنعتی شرکت داشته‌ام و درس‌هایی هم در دانشگاه اشتوتگارد و دیگر دانشگاه‌ها ارائه کرده‌ام. در سال‌های گذشته چند مورد کتاب پرفروش نیز داشته‌ام. آخرین کتابم، Global Software and IT است که توسط WILEY و IEEE انتشار یافته است. در این گفتگو، نگاهی به توسعه ترکه‌ای خواهیم داشت و اینکه چطور در نرم‌افزار و IT به خدمت گرفته شده است. اغلب توسعه ترکه‌ای، به تولید کارخانه نسبت داده می‌شود. ما قواعد آن و اینکه چطور در پروژه‌های نرم‌افزاری و IT بکار گرفته می‌شوند را بیان می‌کنیم. برای این منظور، به آخرین شماره مجله نرم‌افزار IEEE ارجاع می‌دهیم. در آنجا ما تعدادی مطالعه موردی درباره به خدمت گرفتن روش ترکه‌ای در نرم‌افزار و IT داشته‌ایم.

بسیار خوب. من فکر می‌کنم خیلی از شنوندگان ما با موضوع چابک (Agile) در حوزه مهندسی نرم‌افزار آشنا هستند. اما شاید خیلی با موضوع توسعه نرم‌افزار با رهیافت ترکه‌ای آشنا نباشند. آیا می‌توانید خصوصاً برای کسانی که با چابک آشنا هستند، ارتباط ترکه‌ای و چابک را تصویر کنید؟ آیا خیلی مشابه هم هستند؟ تفاوت‌ها و مشترکاتشان چیست؟

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

منظورتان این است که چابک برای پروژه‌های خاص است اما ترکه‌ای بیشتر یک فلسفه و یک امر کلی است؟

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

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

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

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

بله. فکر می‌کنم زمان آن رسیده است که به شکل خلاصه مؤلفه‌های اصلی توسعه ترکه‌ای را معرفی کنم. آن زمان می‌بینید که هرکدام از این مؤلفه‌های اصلی، یک همزاد (برادر یا خواهر) در چابک دارند.

من یکی از این موارد که IEEE، تمایز داده است را گفتم که همان ارزش‌آفرینی است و من به این علت با این مورد شروع کردم که حوزه دید درستی به ما می‌دهد. شما قطعاً درست گفتید. مورد دوم، تمرکز بر افراد است. ارزش، منظره بیرونی است؛ اینکه نیاز مشتری‌ها چیست. اما مورد دوم، افراد و تیم هستند؛ اینکه چطور می‌توانیم تیم را برای تعامل بهتر قدرت ببخشیم و افراد چگونه می‌توانند به منظور ارزش‌آفرینی با همدیگر کار کنند.

مورد سوم، حذف هدررفت‌ها (Waste) است. پیشتر به این بعد اشاره کردم که می‌توانید در سطح کد با بکارگیری برخی تکنیک‌های هوشمندانه خطاها را کاهش دهید و یا در سطح محصول از ویژگی‌‌هایی که باعث پیچیدگی‌های بعدی می‌شود جلوگیری کنید که در اصطلاح Fred Books، به آن پیچیدگی‌های ناخواسته (Accidental Complexity) گفته می‌شود که چیزهایی هستند که لازم نیستند و ارزشی به همراه نمی‌آورند.

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

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

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

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

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

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

اما آنچه باید قطعاً به عنوان یک شاغل انجام دهیم این است که از آنچه در حوزه‌های دیگر مهندسی اتفاق می‌افتد آگاه باشیم. دقت کنیم که با نگاه کردن به دیگر صنعت‌ها چه می‌توانیم بیاموزیم. این نقد دیگر من به کسی است که می‌گوید: « ترکه‌ای برای من نیست. من در نرم‌افزار هستم و ترکه‌ای به کارم نمی‌آید زیرا محصول‌مان متفاوت است». من انتظار دارم که ذهن این فرد برای دریافت محرک‌های جدید باز باشد. مانند محرک‌هایی که از معماری و مهندسی عمران گرفتیم. من می‌بینم که محرک اولیه برای رشد معماری نرم‌افزار در طی ۱۵ سال گذشته، از مهندسی عمران بوده است.

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

بله، نکته خوبی بود. ما می‌توانیم برای اولویت‌بندی و مسائل این‌چنینی از آن استفاده کنیم. فکر می‌کنم این کاملاً درست باشد که بهترین استفاده را از حوزه چابک، از ترکه‌ای و حوزه‌ تولید و ... ببرید و روش خود را طوری که مناسب سازمان و نیاز‌هایتان باشد، گسترش دهید. شاید بهتر باشد به اولین نکته‌ای که اشاره کردید برگردیم. در مورد ارزش‌آفرینی که من فکر می‌کنم خیلی با مبحث مهندسی نیازها (Requirement Engineering) نیز مرتبط است و این حوزه‌ای است که شما خیلی در آن فعال هستید. نقطه تعادل مناسب کدامست؟ برخی مواقع گفته می‌شود که برای اینکه بتوانید اطمینان یابید که از ابتدا کار را درست انجام می‌دهید باید مقداری زیادی طراحی‌های از قبل داشته باشید. این را در خارج از فضای ترکه‌ای گاهی می‌شنوید. از طرف دیگر، می‌شنویم که گفته می‌شود طراحی را در آخرین زمان ممکن انجام دهید. شما آن را چگونه و چه زمان انجام می‌دهید؟ چه مقدارش را از پیش انجام می‌دهید و چه مقدارش را به تأخیر می‌اندازید؟

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

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

مورد دیگری که با موضوعی که ما «حذف هدررفت‌ها» نامیدیم ارتباط دارد، درک این مطلب است که چه نیازمندی‌ها و ویژگی‌هایی تأثیر زیادی بر روی معماری دارد. و روشن است که این موارد باید در ابتدای کار، درک شوند زیرا اگر چیزی تأثیر زیادی بر روی معماری دارد بهتر است که آن را در ابتدا انجام دهیم. مثال خوب آن، ویژگی‌های کیفی مانند امنیت (Security) و قابلیت استفاده (Usability) و ... است که باید از همان ابتدا ارزیابی شود زیرا دیر انجام دادن آن، به معنای از دست دادن زمان زیاد و دوباره‌کاری است.

من خیلی این روش شما را تقدیر می‌کنم که اغلب تأکید می‌کنید که مسأله، فقط چیزی نیست که مشتری می‌گوید که می‌خواهد بلکه باید عمیقاً متوجه شوید که مشتری واقعاً چه چیزی را می‌خواهد. لازم است آن‌قدر عمیق شوید تا بفهمید مشتری واقعاً این موارد از قبیل کارآیی (Performance)، مقیاس‌پذیری (Scalability) و ... را نیاز دارد.

درباره موضوع تصمیم‌گیری در ابتدای کار و اینکه چه کاری را انجام دهیم و اینکه آن کار چقدر مناسب است، نیاز به مقدار زیادی مهارت‌های نرم (Soft Skills) است. این کار یک مذاکره سرراستی نیست. زیرا به این شکل نیست که (به مشتری) بگویید: «به من آن نیازمندی را بده و اگر این کار را سریع انجام بدهی من به نیازمندی‌های دیگر نیاز ندارم.» این‌طور نیست. درعوض، به همراه مشتری، نیازمندی، تکامل و توسعه داده می‌شود.

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

جنبه دیگر مرتبط با ارزش‌آفرینی، این است که ممکن است فردی، دانش را هم در حوزه ارزش قرار دهد. من می‌دانم موضوعی با عنوان تصمیم‌گیری مبتنی بر مجموعه (Set Based Decision Making) وجود دارد که فکر می‌کنم از فرهنگ تولید ترکه‌ای کارخانه‌ای می‌آید. در آنجا، انتخاب‌های خود را باز نگه می‌دارید. اجازه می‌دهید که روش‌های جایگزین برای مدت زمان بیشتری، زنده بمانند. این گاهی مواقع برای مدیران، آزاردهنده است زیرا به مدیران نشان نمی‌دهد که چه بگویند. مدیران دوست دارند که روی میز بزنند و بگویند که: « فقط انجامش دهید. تصمیم بگیرید که کدام مسیر را می‌خواهید بروید و انجامش دهید و پروژه را به پایان برسانید.» اما شاید یکی از چیزهایی که ما می‌خواهیم در ترکه‌ای انجام دهیم این است که سعی کنیم گزینه‌ها را باز نگه داریم. زیرا اگر حتی در آینده یکی از آنها را دور بیاندازید، این هدررفت نبوده است زیرا برایتان ارزش آورده است. نه به معنای یک مصنوع (Artifact) بلکه خود دانشی که داشته است فکر می‌کنم ارزشمند بوده است.

این قطعاً درست است. در واقع شما دو نکته خیلی درست را اشاره کردید. یکی اینکه، ما به‌ صورت پیوسته در حال یادگیری هستیم و حتی در ارزیابی طراحی‌های مختلف یا در تصمیم‌گیری‌های صریح هم در حال یادگیری هستیم مثلاً اینکه کدام بخش سیستم را کامل‌تر از دیگر بخش‌ها، تست کنیم. همان طور که گفتید به‌صورت پیوسته چیزی را دور می‌اندازیم و بقیه را نگه می‌داریم. من به خاطر می‌آورم که یکی از آموخته‌های مهمی که در ۱۵-۱۰ سال گذشته داشته‌ایم مربوط به تصمیم‌های زیادی بوده است که در شرایط غیرقطعی داشته‌ایم، (که البته در همه زمینه‌های مهندسی این‌طور است اما ما در مورد نرم‌افزار و IT صحبت می‌کنیم) بنابراین به تکنیک‌هایی نیاز داریم که امکان چنین تصمیم‌گیری‌هایی را فراهم کند. و البته باید آن تصمیم‌ها را به‌صورت کارآیی اجرا کنیم که داستان دیگری است.

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

جنبه دیگری که به نظر من به همان میزان مرتبط است این است که وقتی ما انتخاب‌هایی برای تصمیم‌گیری داریم باید این تصمیم را هم بگیریم که چه زمانی انتخاب کنیم. همان‌طور که پیش از این گفتم، گاهی خوب است که این کار را زود انجام دهیم زیرا اگر اشتباه بکنیم، تأثیرات جانبی (Side Effect) زیادی دارد و دوباره‌کاری زیادی ایجاد می‌کند و گاهی مواقع بهتر است که آن را دیر انجام دهیم یا حتی مناسب است آن را برای همیشه باز نگه داریم همانطوری که ما امروزه از طراحی متغیر (Variant Design) استفاده می‌کنیم به این ترتیب که تعدادی نقاط تغییرپذیری (Variation Point) نگاه می‌داریم که می‌توانیم در آن نقاط، به روش کارایی پیاده‌سازی‌های مختلف را تعویض کنیم. این کار را همان‌طور که پیش از این گفتم وقتی که به سمت تولید یک نسخه گران‌قیمت از برنامه می‌رویم انجام می‌دهیم تا اطمینان حاصل کنیم که بتوانیم سیستم‌ را از راه دور، بروزرسانی کنیم و نیاز نباشد برای آن کدهای مختلف داشته باشیم. وقتی در ارتباط با حذف هدررفت‌ها فکر می‌کنیم، این پیش‌بینی و طرح‌ریزی برای‌ تصمیم‌ها در زمان درست، آموخته مهم دوم است.

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

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

اما شما گفتید که هنوز در ابتدای کار اغلب یک روش تصمیم‌گیری خیلی سلسله‌مراتبی را می‌بینیم. منظور توسعه ترکه‌ای، از قدرت بخشیدن به افراد این است که برای اینکه تیم بتواند تصمیم‌گیری کند و تصمیمات درستی بگیرد، باید به آنها دانش داده شود. باید مهارت داده شود تا پس‌زمینه‌های کار را درک کنند. این چیزی است که ما اغلب در مورد پیاده‌سازی واقعی آن مردد هستیم. زیرا در این صورت، از دید بیرونی تیم به اموری خواهد پرداخت که کار آنها نیست. به‌عنوان مثال باید کسب‌وکار مشتریان را بشناسند. باید ارتباطات با اجزاء و مؤلفه‌های دیگر را بشناسند. آنها باید تعامل بین ویژگی‌ها را بشناسند. باید نقشه راه (Roadmap) را بشناسند. در اینجا هر مدیر معمولی می‌گوید که چرا تیم باید همه این چیزها را بداند؟

فکر می‌کنم مدیران از نظر روانشناسی هم نمی‌خواهند اجازه دهند کار به این شکل پیش برود.

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

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

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

طبق تجربیات شما، آیا این خیلی سریع رخ می‌دهد؟ در شرایطی که مدیر خط (Line Manager) می‌ترسد که تیم نتواند تصمیمات را به‌درستی و به‌صورت مؤثر بگیرد.

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

فکر می‌کنم باید این از طرف مدیریت ارشد روشن باشد که آنها واقعاً می‌خواهند این ریسک را بکنند و چنین کاری را تشویق کنند و روشن کنند که این یک تغییر در فرهنگ است.

دستورالعمل موفقیت در این کار این است که با تغییرات کوچک و تدریجی در مسئولیت‌ها، بگذاریم به تدریج، مسئولیت‌ها رشد یابند. این روش که با درنظر گرفتن ۳ عاملی که پیش از این اشاره کردم به تدریج رشد یابید، عموماً جواب می‌دهد.

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

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

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

اما چه کسی می‌تواند یک معیار و روش ارزیابی به شما بدهد که بتوانید همه خطاها را بیابید؟ اگر این‌قدر ساده بود، احتمالاً این تعداد متدولوژی نداشتیم. یافتن معنای هدررفت (برطبق محصول و شناختی که از کسب‌وکار دارید) در کاری که هم‌اکنون انجام می‌دهید، یک کار چالشی است. شاید چیزی باشد که برای نسخه جاری، هدر دادن زمان باشد اما برای نسخه‌های بعدی، ارزش داشته باشد. در این مورد، یک مثال کلیدی که ما اغلب در صنعت استفاده می‌کنیم این است که: «کاری که می‌کنم را تا چه مقداری باید مستند کنم؟» در تکنیک‌های توسعه چابک تأکید می‌شود که کد همان مستند است. این ممکن است صحیح باشد اما نرم‌افزارهای صنعتی حرفه‌ای شاید استانداردهایی را پیروی کنند که الزام کند محصول به‌خوبی مستند شود. در این صورت به چه شکل باید کد یا معماری یا استراتژی تست، مستند شود؟ این چیزی نیست که در دانشگاه تدریس شود. منظورم این است که این مهارت‌ها به صورت گام به گام، ساخته می‌شود تا به شناخت درستی از آن برسید. خیلی افراد هستند که کار نگهداری و توسعه جدید می‌کنند و می‌دانند که چه مقدار از مستندات اضافه‌کاری است و چه مقدارش برای اصلاح خطاهای نسخه‌های قبلی مفید است و چه مقدارش، در مرزها قرار می‌گیرد و بیشتر باعث سربار در محصول جاری‌تان می‌شود. این همان چیزی است که به آن قاعده‌ به مقدار کافی خوب (Good Enough Principle) می‌گوییم. باید خیلی مراقب باشید که در صنایع حساس مثلاً پزشکی یا اتومبیل، کارهایی نکنید که بعداً مشخص شود که برای رسیدن به سطوح امنیت و اطمینان موردنظر کافی نبوده است اما در عین‌ حال روشن است که باید در درک این مطالب که چه مقدار لازمست و چه مقدار کافیست نیز تجربه کسب کنیم. این چیزی است که از ما به‌عنوان یک مهندس حرفه‌ای انتظار می‌رود. این امر به صنعت وابسته است، به انتظارات کاربران وابسته است و برای آن نیاز به درک کسب و کار و همچنین درک عمیق مهندسی هست. این چیزی است که تیم طی زمان، وقتی به سمت توسعه به روش ترکه‌ای می‌رود آن را فراخواهد گرفت.

ما در مورد هدررفت در مورد مهندسی نیازمندی‌ها صحبت کردیم. مسائلی از قبیل تولید بیش از حد، توسعه محصول غلط، داشتن ویژگی‌هایی که مشتریان آنها را واقعاً نمی‌خواهند، اینها می‌توانند نمونه‌های روشنی از هدررفت باشند. اما فکر می‌کنم اگر در حیطه مهندسی، این عنوان (هدررفت) را برای خیلی چیزهای دیگر هم بکار ببریم معنی می‌دهد. بعنوان مثال اگر به روش ترکه‌ای در تولید کارخانه‌ای نگاه بیاندازید، برخی دستگاه‌ها و ابزارها هستند که تعویض بین آنها، هزینه دارد. فکر می‌کنم به این نوع هزینه‌های مرتبط با ابزارهای سخت‌افزاری، هدررفت از نوع حرکتی (Motion) گفته می‌شود. در نرم‌افزار هم نوع مشابهی از هدررفت داریم یعنی هدررفت مرتبط با تعویض محتوا (Context Switch). مثلاً یک فرد خبره در ۵ پروژه متفاوت درگیر می‌شود و مدیر اغلب، تعویض محتوایی که در ذهن این فرد رخ می‌دهد را نادیده می‌گیرد. اینکار می‌تواند هزینه معادل ۲۰٪ زمان فرد یا چیزی شبیه به این را داشته باشد. این مفید است که توجه مدیران را به این شرایط ناخوش جلب کنیم.

بله، کاملاً درست است که گاهی مواقع به سمت چنین شرایطی حرکت می‌کنیم. باید مراقب فعالیت‌های توسعه‌ای که انجام می‌دهیم باشیم یعنی در ارتباط با فعالیت‌های برای فهمیدن ویژگی‌ها، فهمیدن هدررفت‌ها یا برای اینکه چه چیزی از لحاظ نیازمندی لازم است یا لازم نیست.

از لحاظ تاریخی مثال‌های فراوانی وجود دارد. بعنوان مثال اگر Netscape را درنظر بگیرید، در ابتدا سهم بزرگی از بازار در حد ۹۰٪ را داشت. اما در عرض چند سال نسبت به Microsoft Explorer اُفت کرد. این چیزی بود که یقیناً کسی انتظارش را نداشت. اما ناکارآمدی اصلی در محصول Netscape، رشد غیرقابل کنترل پیچیدگی (بدون اینکه هیچ‌گونه معماری یا مستندات محصول یا حتی مدیریت پروژه وجود داشته باشد) بود. و این فاکتورها با هم، می‌توانند هر محصولی را (حتی اگر سهم ۹۰٪ از بازار را داشته باشد) با سرعت خیلی زیادی نابود کنند. این‌ها داستان‌هایی است که باید همواره به خاطر داشته باشیم. برای اینکه تاریخ تکرار نشود باید از آن درس بگیریم.

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

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

باید اینجا روشن کنم، وقتی من از فعالیت‌های موازی صحبت می‌کنم منظورم فعالیت‌های مهندسی است. اگر شما فرد خبره‌ای دارید که فعالیت‌های مربوط به مهندسی معماری‌تان را انجام می‌دهد ممکن است چنین فرد ارشدی، بتواند همزمان از پس ۴ یا ۵ محصول برآید ولی از دیدگاه فردی، تجربه‌های گسترده نشان می‌دهد که باید کارها را به ۲ یا ۳ عدد محدود کنیم و نباید کارهای زیادی را بصورت موازی انجام دهیم. این آموخته‌هایی است که من در صنعت با آن روبرو می‌شوم. آنها می‌گویند: «من به آن متخصص در ۵ پروژه مختلف نیاز دارم. چه کار باید بکنم؟ من نمی‌توانم از این مهارت یکی دیگر بسازم!» من به آنها می‌گویم: «یکی دیگر بسازید!» این را فقط از دیدگاه فردی به این خاطر که مهندس‌ها حس خوبی پیدا می‌کنند، نمی‌گویم. آنها (مهندسان) به من می‌گویند اگر بتوانند در زمینه کاری‌شان یادگیری بیشتری داشته باشند، تقویت می‌شوند. اما مدیریت فکر می‌کند که من این متخصص را دارم. چرا باید هزینه دو یا سه تای دیگر را بپردازم؟ یک رویه خوب چابک در اینجا این است که بصورت جفت (Pair) کار کنیم. اگر یکی مریض باشد یا نباشد، دیگری دانشش را دارد که همتایش چه کار می‌کرده است. این کاملاً منطقی است که دانش‌مان را به اشتراک بگذاریم و تنها آن یک متخصص را نداشته باشیم که نتوانیم واقعاً جایگزینش کنیم. وقتی این درک شود، پیشرفت در جهت بهبود آسان‌تر می‌شود.

به سراغ چهارمین موضوعی که در ابتدا عنوان کردید، برویم: «بهینه‌سازی زنجیره ارزش یا بهینه‌سازی جریان». این موضوعی است که فکر می‌کنم خیلی مهم است. دونالد رینسترن که در زمینه موضوع جریان (Flow) و مدیریت محصول به روش ترکه‌ای متخصص است، حدود یک سال پیش، برای تعدادی از همکاران‌مان در حوزه ترکه‌ای و مدیریت محصول یک سخنرانی در زیمنس داشت. او تمرکز خیلی زیادی بر روی تئوری صف (Queuing Theory) دارد. اینکه در یک فرآیند، در عوض استفاده از ظرفیت منابع افراد، بر روی جریان کار و بر روی توان عملیاتی (Throughput) کل سیستم تمرکز کنیم. این موضوع به نوعی، با مبحث مدیریت ترافیک مرتبط است. مثلاً در اتوبان‌های آلمان، اگر بخواهیم ظرفیت تک‌تک تعداد زیادی افراد را بالا ببریم، با یک ترافیک عظیم روبرو می‌شویم و کسی نمی‌تواند جایی برود. فکر می‌کنم بهینه‌سازی جریان، حتی نسبت به بودجه و زمانبندی، ساده‌تر قابل کنترل باشد. احتمالاً منطقی است که دانش بیشتری در این موضوع تئوری صف داشته باشیم. فکر می‌کنم این موضوع در حوزه تولید ترکه‌ای کارخانه‌ای کاملاً شناخته‌شده باشد اما به نظر می‌رسد نرم‌افزاری‌ها خیلی آن را نشناسند.

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

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

یک مورد درباره تحلیل زنجیره ارزش (Value Stream Analysis) این است که اولین بار که این تصویر را آماده می‌کنیم، (اغلب با قرار دادن یادداشت‌هایی بر روی تخته وایت‌برد این کار را می‌کنیم)، وقتی که تیم این کار را به پایان رساند (زیرا آنها کسانی هستند که محیط را می‌شناسند) آنها خواهند گفت با اینکه همیشه با آن مواجه بوده‌ایم اما واقعاً هیچ‌گاه این‌طوری آن را ندیده بودیم. در این حال، با حذف برخی واسطه‌ها و با نگاه کردن به کارهایی که در پروژه اخیر انجام داده‌ایم و نگاه به مقدار زیادی از فعالیت‌ها که برگشت خورده‌اند (به‌عنوان مثال نیازمندی‌های ناکافی که موجب ۵ یا ۱۰ بار دوباره‌کاری شده است) حتی با عمیق‌تر شدن و تمرکز روی این موضوع که چه محصولی را ارائه می‌کنیم، بحث‌های خیلی مفیدی داخل تیم شکل می‌گیرد. مثلاً اینکه چطور می‌توان این زنجیره فعالیت‌ها را ساده کرد؟ و این تمرین خیلی سودمندی است.

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

درست است. این کمک می‌کند که شما به تصویر درست برسید. چیزی که قطعاً معنی نمی‌دهد این است که یک تیم بزرگ داشته باشید و بخواهید که خودشان تصویر (Value Stream) را بکشند زیرا اولاً معمولاً تکنولوژی اینکار را ندارند و دوماً آنها فقط بر روی چیزی که می‌دانند تمرکز می‌کنند و بقیه چیزها را حدس می‌زنند. آنچه ما اغلب انجام می‌دهیم این است که در کنار تیم‌های کوچک‌تر یا برخی مواقع با تک‌تک‌ افراد، می‌نشینیم و گام به گام آن تصویر را می‌سازیم. بعد تیم‌ها را جمع می‌کنیم و از آن‌ها می‌خواهیم که به تصویر تولید شده نگاه کنند و در مورد آن بحث کنند و تجربیات خود را به اشتراک بگذارند و بعد اگر بخواهید می‌توانید دور برخی نقاط مشکل‌زا را با قرمز خط بکشید. و بعد مثلاً به تیم‌های مهندسی نیازمندی‌ و تیم تست، آن را نشان دهید و بگویید که: «در اینجا ما، مقدار دوره‌های طولانی داریم که پرهزینه است زیرا در زمان تست متوجه می‌شویم که بیان مشخصات (Specification) اشتباه بوده است و برخی چیزها فراموش شده است. چرا نیازمندی‌ها را از لحاظ تست‌پذیری، بازبینی نمی‌کنید؟» این یکی از تکنیک‌های خاص و بازبینی بسیار مؤثر است که من در کل چرخه تولید نرم‌افزار می‌شناسم. با این کار، بهتر فرا گرفته می‌شود که چطور باید بیان مشخصات نیازمندی‌ها را مستند کرد در عین حال تست‌کننده‌ها هم زودتر متوجه هدف واقعی سیستم می‌شوند. مطمئناً با بهبود دادن این نقاط مشکل‌زا، پیشرفت خواهید کرد.

آیا مثال‌هایی می‌شناسید که توانسته باشند این رویه‌ای که در موردش صحبت می‌کنیم را به‌سادگی پشت سر گذاشته باشند؟ آیا برای افراد علاقه‌مند، در مورد اولین گام‌هایی که باید داشته باشند، توصیه‌هایی دارید؟

در مورد همه این ۵ قاعده صحبت می‌کنید یا فقط در مورد زنجیره ارزش صحبت می‌کنید؟

در مورد همه‌اش.

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

مثال‌هایی وجود دارد که شرکت‌هایی که کمبود زمان داشتند، روش ترکه‌ای را به خدمت گرفتند. همان‌طور که پیش از این اشاره کردم مواردی از این دست در مجله IEEE منتشر شده است. خوب است که به نسخه مربوط به ۱۰ اکتبر سال ۲۰۱۲ نگاهی بیاندازید. در آن، تعدادی از این مطالعات موردی ارائه شده است. یکی از آن مواردی که من در آنجا خوشم آمد، یک موردی بود که مربوط به توسعه ابزارهای پزشکی در شرکت زیمنس بود. در آنجا گروهی به تعدادی از قواعد ترکه‌ای و چابک مانند اولویت‌بندی ویژگی‌ها و توسعه افزایشی (Incremental Development) توجه کرده بودند و نشان داده بودند که فقط از دیدگاه مهندسی نیازمندی‌ها، انتخاب هوشمندانه مجموعه‌ای از این قواعد که با آموزش و مهارت‌آموزی صحیح همراه باشد، منجر به بهبود ۳۰٪ در کارایی (در حوزه و محیط خاص خودشان) می‌شود.

مورد دیگر، یک مطالعه تجربی درباره بکارگیری کانبن و اسکرام در شرکت‌های با ابعاد کوچک و متوسط بود. در آنجا نیز نشان داده شده بود که مستقل از حوزه صنعتی شرکت‌ها، به‌طور خاص قواعد حذف هدررفت‌ها و زنجیره ارزش (که ما در اینجا در مورد آنها توضیح دادیم)، سودمندی بسیار زیادی در شرکتی که آن را به خدمت گرفته است داشته است. به‌عبارت دیگر، هر روزه نمونه‌های خوبی ارائه می‌شود که می‌توانیم از آنها یاد بگیریم. به خاطر دارم که برای آن نسخه خاص IEEE Software ما ۲۳ مقاله دریافت کردیم. بنابراین می‌بینید که دانش زیادی دراین‌باره وجود دارد. اما من از پیش‌زمینه تجربیات خودم می‌دانم که به همین تعداد شرکت هم بوده‌اند که تلاش کرده‌اند اما شکست خورده‌اند. آنها میزان تأکیدی که باید بر روی مدیریت تغییرات وجود داشته باشد را دست‌کم گرفته‌اند. ما در مورد تغییراتی که در این چرخه‌های بکارگیری دارید، خیلی صحبت کردیم. اگر تغییرات بیش از اندازه بدهید، شکست خواهید خورد. مثلاً اگر به تیم بگویید که: «از همین فردا شما قدرت داده می‌شوید.» به همین علت است که مدیریت تغییرات، یکی از فاکتورهای اصلی موفقیت است.

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

درست است. اصل اساسی در بهبود مستمر این است که آن را واقعاً به‌صورت مستمر بکار ببرید. اگر به اسکرام نگاه کنید، اگر آنجا این جلسات سرپایی روزانه (Daily Standup Meeting)، را دارید، یکی از دلایل اصلی‌اش این است که بتوانید تجربیات را به اشتراک بگذارید. این کار را می‌توانید در زمینه‌های کوچک‌تر یا بزرگ‌تر هم انجام دهید. فکر می‌کنم خوب است که هر روز عصر، یا مثلاً هرجمعه، جمع شویم و بگوییم: «چه می‌توانیم بیاموزیم؟ ما به‌عنوان یک تیم، از ماحصل کار که ممکن است به‌خوبیِ مورد انتظار نباشد، چه می‌توانیم بیاموزیم؟»

بسیار خوب. گفتگوی خیلی جذابی بود. من دیدگاه‌های شما نسبت به این موضوع را تقدیر می‌کنم. امیدوارم شنوندگان نیز چیزهایی یافته باشند که بتوانند درکارهای عملی خود بکار ببرند.