https://virgool.io/feed/@soheilsam مربی و مشاور چابک‌سازی سازمانی، توسعه دهنده fa 2026-04-15 04:39:38 https://files.virgool.io/upload/users/89/avatar/2Z8NWI.jpeg?height=120&width=120 https://virgool.io/@soheilsam https://virgool.io/Whitenoise/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D9%85%D8%AD%DB%8C%D8%B7-%DA%A9%D8%A7%D8%B1%DB%8C-%D8%AE%D9%88%D8%AF-%D8%B1%D8%A7-%D8%A8%D9%87-%D8%A2%D8%AA%D8%B4-%D8%A8%DA%A9%D8%B4%DB%8C%D8%AF-vjdu0pe2xkrm تابه‌حال خرابکاری کرده‌اید؟ من کرده‌ام! شمع روشنی را در نزدیک‌ترین فاصله ممکن با دستمال‌کاغذی‌ها رها کردم! فاجعه‌ای رخ داد! خوش‌اقبال بودم که کسی آسیب ندید؛ اما تعداد زیادی لحاف و تشک اجدادی تبدیل به کربن شد!حقیقتش را بخواهید، خرابکاری مقوله‌ای علمی است! درواقع می‌توان خرابکاری را فرموله کرد، آموزش داد و حتی لیسانس و نشان خرابکاری گرفت... باورش دشوار است!؟ برای من هم سخت بود؛ ولی با من همراه شوید تا با منسجم‌ترین راهنمای خرابکاری جهان که هنوز هم کاربرد دارد آشنایتان کنم! به این گزاره‌ها دقت کنید:توصیه‌های تشکیلاتی!لجوجانه تلاش کنید که همه کارها را از «کانال‌های تعریف‌شده‌اش» انجام دهید؛ جلوی استفاده از میانبرها را بگیرید!مدام حرف بزنید! بدون انقطاع و پشت سر هم!از هر فرصتی برای ارجاع کارها به یک کمیته - جهت مطالعه و تحقیقات بیشتر، استفاده کنید! کمیته‌هایی شلوغ که هیچ‌گاه کمتر از 5 نفر نیستند!یک موضوع بی‌ربط را بارها گوشزد کنید!روی ادای صحیح کلمات و واژگان موجود در قراردادها، مکالمات و نامه‌ها چانه‌بزنید! (ملا نُقَطی باشید!)به کارهایی که قبلاً روی آن‌ها تصمیم گرفته‌شده است، گیرِ مجدد بدهید!ترس و اضطرار را اشاعه دهید! خیلی معقول عمل کنید و اطرافیانتان را به متانت و خونسردی دعوت کنید تا از عجله اجتناب کنند تا به عواقب تلخ آن دچار نشوند!نگران مناسب بودن هر تصمیمی در هرجایی باشید! صلاحیت تصمیم‌گیرنده‌ها را زیر سؤال ببرید و مدام هشدار دهید که ممکن است تصمیمشان با اراده یا سیاست برخی از رده‌های بالاتر در تعارض باشد!توصیه برای مدیران و سرپرستان!اصرار داشته باشید تا دستورات را کتبی دریافت کنید!خود را در برابر دستورات به کج‌فهمی بزنید! سؤالات بی‌پایان بپرسید یا مکاتبات و بگومگوهای بی‌پایان انجام دهید.هر کاری که می‌توانید برای به تأخیر انداختن تحویل کارها انجام دهید. حتی اگر بخشی از کار آماده است، تحویل آن را به آماده شدن کل کار موکول کنید.لوازم ضروری کار را تا زمانی که به‌کلی تمام نشده، سفارش ندهید! فرصت کوتاه شما برای درخواست و ثبت سفارش جدید، جریان کار را به سمت خاموشی و توقف سوق خواهد داد.لوازم بسیار گران باکیفیت بالا سفارش دهید که تهیه آن‌ها دشوار باشد. در این فاصله مدام هشدار دهید که ابزار [یا فرایند] بی‌کیفیت منجر به کار بی‌کیفیت خواهد شد.در تعیین تکالیف کاری، همیشه کارهای کم‌اهمیت را ابتدا تعیین تکلیف کنید.اصرار داشته باشید تا محصولات کم‌اهمیت‌تر، بی‌نقص و کامل انجام شوند. مدام آن‌ها را برای بازنویسی یا دوباره‌کاری به عقب ارجاع دهید.در مسیردهی‌ها اشتباه کنید تا کارها یا لوازم به‌جاهای نادرست فرستاده شوند.وقتی فرد جدیدی را آموزش می‌دهید، اطلاعات ناقص یا گمراه‌کننده به او بدهید.برای کاهش روحیه، و صدالبته تولید، با کارکنان ناکارآمد صمیمی باشید و درحالی‌که سزاوار نیستند مدام تشویقشان کنید! نسبت به کارکنان کارآمد تبعیض‌آمیز برخورد کرده و ایرادگیری کنید.جلسات را درست درزمانی که کارهای مهمی برای انجام هست، برگزار کنید!به شکلی که معقول به نظر برسد، دوباره‌کاری کنید! نسخه‌های تکراری از فایل‌ها نگه‌داری کنید.روال مربوط به اخذ تصمیمات، دستورات، پرداخت چک‌ها و انجام دیگر کارها را پیچیده کنید. مجوزهای لازم را چند برابر کنید!تمامی آیین‌نامه‌ها و قوانین را کلمه به کلمه تا نقطه آخر اعمال کنید.توصیه برای کارمندان!آهسته کارکنید! به راه‌هایی فکر کنید که برای انجام کار نیاز به حرکات اضافی داشته باشید. ابزار غیردقیق استفاده کنید؛ از چکش سبک بجای چکش سنگین‌تر استفاده کنید و ازاین‌دست!تا می‌توانید در روال انجام کارها تعلیق و وقفه، تعبیه کنید. اگر چیزی را اندازه می‌گیرید، چندین بار این کار را بکنید. چیزهایی را فراموش کنید تا به خاطر آن‌ها مجبور به رفت‌وبرگشت باشید.حتی اگر زبان و متن را متوجه می‌شوید، وانمود کنید که مسئله یا دستورالعمل به آن زبان را درک نکرده‌اید.وانمود کنید که درک دستورالعمل یا کار، بسیار پیچیده و دشوار است. آن‌ها را مجبور کنید چندباره توضیح دهند.کارتان را ناقص انجام دهید و کمبود امکانات، تجهیزات و ابزارها را ملامت کنید.هیچ‌گاه دانش و تجربه خود را به همکار جدید یا کم‌تجربه‌تر از خودتان انتقال ندهید.کارهای اداری را بغرنج کنید. فرم‌ها را با اطلاعات بیخود و ناخوانا یا ناقص پرکنید تا آن‌ها مجبور به دوباره‌کاری شوند.در صورت امکان به گروهی که مشکلات کارمندان را به مدیریت بازتاب می‌دهد ملحق شوید یا کمک کنید تا چنین گروهی ایجاد شود. مطمئن شوید که روال کار برای مدیریت در کسل‌کننده و ناکارآمدترین حالت ممکن قرار دارد.لوازم و درخواست‌ها را نادرست مسیردهی کنید.چیزهای خوب را با چیزهای بد، مستعمل، از رده خارج و مرجوعی ترکیب کنید!اگر در اواخر جنگ جهانی دوم در کشورهای تحت اشغال آلمان نازی زندگی می‌کردید و سن قانونی هم داشتید می‌توانستید با عمل کردن به این موارد، نشانِ «شهروند خوبِ خرابکار» دریافت کنید و به متفقین برای آزادسازی کشورتان کمک کنید.اطلاعات عمومی نه‌چندان بیخودیمواردی که در بالا خواندید بخشی از یک سند تاریخی است که توسط ستاد خدمات راهبردی ایالات‌متحده آمریکا (US OSS) در سال 1944 تهیه شد و متفقین آن را در خلال جنگ جهانی دوم برای راهنمایی شهروندانی که طرفدارشان بودند توزیع کردند. این سند که «راهنمای میدانیِ خرابکاری ساده» یا Simple Sabotage Field Manual، نام داشت، به شهروندان کشورهای اشغالی یاد می‌داد که چگونه می‌توانند با انجام یک سری اقدامات میدانی ساده، درحالی‌که غیرقابل‌کشف و در حاشیه‌ای امن قرار می‌گیرند، بهره‌وری در محل کار و زندگی خود را به‌شدت کاهش دهند تا درنهایت به فروپاشی از درون منجر گردد. این دستورات را با اصطلاحات «کارشکنیِ بی‌خطر» یا «حماقتِ هدفمند» نیز می‌شناسند.این سند در سال 2008 به همراه لیستی از افرادی که برای این سرویس مخفی کار می‌کردند، از حالت طبقه‌بندی‌شده خارج و در اختیار عموم قرار گرفت. در میان اسامی، نام این افراد به چشم می‌خورد:رالف بانچ Ralph Bunche - دانشمند علوم سیاسی و برنده جایزه صلح نوبلاسترلینگ هایدن Sterling Hayden - ستاره هالیوودالیزابت مکینتاش Elizabeth McIntosh - مامور مخفی و نویسنده کتاب دختر مخفیموریس بِرگ Moe Berg - مربی و ستاره بیسبالآرتور گلدبِرگ Arthur Goldberg - قاضی ارشد دیوان عالیپائول مِلون Paul Mellon - پرورش‌دهنده اسب و میلیونر مشهورآرتور مایر شلیزنگر جونیور Arthur M. Schlesinger Jr - مورخ، جامعه شناس و برنده جایزه پولیتزرجان فورد John Ford - فیلمساز مشهور هالیوودسمت راست بالا به پایین: پائول ملون - جان فورد - الیزابت مکینتاش - استرلینگ هایدن سمت چپ بالا به پایین: رالف بانچ - موریس برگ - آرتور گلدبرگ - آرتور شلیزنگرخوب است بدانیم که «ستاد خدمات راهبردی»، سازمانی منسجم بود که از بااستعدادترین دانشمندان علوم ارتباطات، سیاست و جامعه شناسان خبره در سال 1942 تشکیل شد تا به مأموریت اصلی خود یعنی جمع‌آوری اطلاعات (جاسوسی)، تولید پروپاگاندا، براندازی و برنامه‌ریزی پساجنگ بپردازد. این تشکیلات پس از جنگ جهانی دوم منحل و به نحوی در آژانس اطلاعات مرکزی (CIA) ادغام شد و هم‌اکنون با عنوان ستاد فرماندهی عملیات ویژه (US SOCOM) به مأموریت‌های جدید خود ادامه می‌دهد.سخن پایانینزدیک به هشتاد سال پیش، برای فروپاشاندن و تخریب یک سیستم پیچیده تطبیق‌پذیر – کشور، شرکت و اداره، مواردی طراحی و توصیه‌شده است که به شکل عجیبی امروزه هم بسیاری از آن‌ها و مصادیقشان را در محیط‌های کاری شاهدیم. عجیب‌تر اینکه بسیاری از آن‌ها، نه به‌عنوان عامل منحوس خرابکاری و فروپاشی که به‌عنوان یک استاندارد عُقلایی، متد طلایی یا تجربه موفق پذیرفته‌شده‌اند! راهنما دارای ابعاد و سرفصل‌های متعدد و جالبی است (12 بند) که در این یادداشت به بخش‌های سازمانی آن (بند 11) پرداخته شد. می‌توانید متن اصلی اسکن شده را اینجا و متن تایپ‌شده و خواناتر را اینجا دریافت کنید.تاکیدم این نیست که هرکدام از این موارد می‌تواند به‌تنهایی یک تَشَکل یا سازمان تجاری را به فروپاشی نزدیک کند یا اگر چنین رفتارهایی از کسانی سر زد، از روی عمد بوده یا قطعاً توطئه‌ای در کار است! بلکه قصد داشتم توجه مدیران، کارمندان و مسئولان واحدهای تجاری را به این نکته جلب کنم که اگر تعداد خوبی از این موارد و یا مصادیقشان را در گوشه‌ای از سازمان مشاهده کردید، خطر فروپاشی ازآنچه در آینه می‌بینید به شما نزدیک‌تر است!بسیاری از این توصیه‌ها پس از 100 سال تمرین مداوم، تبدیل به فرهنگ شده‌اند و به‌صورت ناخودآگاه از افراد سر میزنند، بنابراین اصلاح بسیاری از آن‌ها درواقع کاری فرهنگی است و خبر خوب این است که تمام این مخاطرات و ابتکارات خرابکارانه، در تفکرِ مدیریت جدید قابل‌پیشگیری و ترمیم هستند یا اگر هم حوصله، زمان یا پول سرمایه‌گذاری بر روی تفکرات جدید مدیریتی را ندارید، تنها کافی است سعی کنید برعکس این دستورات عمل کنید!... شاید هم بد نباشد، پوستری از فرامین آن در شرکت نصب کنید! :-)تقدیم به...این یادداشت، درواقع تکه‌ای از یک پیش‌نویسِ پرشاخ و برگ ولی پراکنده در مورد چابکی سازمانی است که طی یک سال گذشته به آن مشغول بودم. پیشنهاد دوستانم در ویرگول و داتین برای پیوستن به کمپین 1000 نفری، بهانه و انگیزه‌ای شد تا بخش تقریباً آماده‌تری از آن را در این کمپین سهیم باشم. برای من که همکاری‌ام با بانک سپه و شرکت‌های تابعش در سال‌های دور و نزدیک، نقطه عطفی در زندگی حرفه‌ای‌ام بوده، داتین به‌عنوان شریک فنی بانک سپه نیز همواره ارج‌وقربی معنادار برایم داشته است. امیدوارم هر دو در پیمودن مسیر رشدشان، چابک و از خرابکاری‌ها مصون بمانند. سهیل صمدزاده سهیل صمدزاده Sat, 07 Aug 2021 20:24:49 +0430 https://virgool.io/@soheilsam/%D8%AA%DB%8C%D8%B1%DB%8C-%D8%A8%D9%87-%D9%82%D9%84%D8%A8-safe-ym1ehfl3sanh داستان ازآنجا شروع شد که چندی پیش برایان ریورا، نیگل تارلو و دیو اسنودن، از پیشگامان و اساتید دنیای چابک فرصتی داشتند تا با رهبران و مدیران فناوری ارتش و نیروی دریایی ایالات‌متحده آمریکا دیدار کرده و طی گفتگوهایی، ایشان را با پیچیدگی‌های دنیای چابک و همچنین معضلات چارچوب‌های عظیم‌الجثه، و دست و پاگیر مانند SAFe، بیشتر آشنا کنند.شواهد متعدد نشان می‌دهد که ارتش و بخصوص وزارت دفاع ایالات‌متحده در مسیر چابکی بیشتر برای توسعه نرم افزارهایش، قصد تغییر و پذیرش یکی از این چارچوب‌ها را داشته است و منجر به آن شد که آقای نیکولاس چِیلان – Nicolas M. Chaillan، افسر ارشد نرم‌افزار و مسئول پروژه DevSecOps در نیروی هوایی ایالات‌متحده، در قالب یک گزارش جامع، علاوه بر پوشش سوالات و چالش‌های نرم‌افزاری متنوع، بخشی را نیز به بیان دیدگاه خود و گروهش نسبت به استفاده از چارچوب‌های مقیاس‌پذیر به‌ویژه چارچوب SAFe در سازمان متبوعش اختصاص دهد.انتشار این گزارش بسیار مهم، واکنش‌های بین‌المللی فراوانی را در پی داشته است. برای اینکه اهمیت این موضوع را بهتر درک کنید باید خاطرنشان کنم که مطالعه جنبش‌ها و تحولات تاریخی در صنعت نرم‌افزار نشان می‌دهد که ارتش‌های جهان به‌طور کل و وزارت دفاع و ارتش ایالات‌متحده آمریکا به‌طور خاص، همواره منشأ و خاستگاه انواع ابتکارات، چارچوب‌ها، مفاهیم، فرایندها، تکنیک‌ها و تاکتیک‌های عمدتاً خوب و گاهی هم نچندان خوب بوده‌اند!تولد چیزی به نام آرپانت به‌عنوان نتیجه پروژه‌ای در آژانس DARPA در سال 1967 که امروز همه آن را به‌عنوان اینترنت می‌شناسیم، پذیرش و استانداردسازی سوتفاهمی به نام Waterfall در سال 1985 (استاندارد شده در وزارت دفاع آمریکا DOD-STD-2167A)، آن‌هم پس از انتشار مقاله آقای وینستون دبلیو رویس در سال 1970، سرمایه‌گذاری بر روی حلقه اودا - OODA که توسط یک سرهنگ و استراتژیست اسطوره‌ای نیروی هوایی به نام «جان بوید – John Boyd» توسعه داده شد و دستاوردهای آن بعدها پشتوانۀ تحقیقات یک خلبان کارکشته و باهوش فانتوم اف-4 به نام دکتر جف سادرلند برای خلق چارچوب محبوب اسکرام قرار گرفت! این گراف آن‌قدر پهناور، درهم‌تنیده و جذاب است که می‌تواند انگیزه یک تحقیق جامع و دوست‌داشتنی باشد! به نظر می‌رسد همه‌چیز از ارتش شروع‌شده باشد و آن‌طور که معلوم است درنهایت هم در ارتش خواهد مرد!به نظر می‌رسد همه‌چیز از ارتش شروع‌شده باشد و آن‌طور که معلوم است درنهایت هم در ارتش خواهد مرد!Scrum: The Art of Doing Twice the Work in Half the Timeتمرکز و حساسیت غریزی ارتش در گزینش فناوری و این بار روی چارچوب‌های مقیاس‌پذیر، نکاتی کلیدی را هویدا کرده است. بازار مکاره تجارت چارچوب‌های رنگ‌ووارنگ در جهان بسیار داغ است و ایران نیز از گزند آن در امان نمانده و در سال‌های اخیر بسیاری از سازمان‌های متوسط و بزرگ، توسط مشاوران و بازاریابان چشم آبی این چارچوب‌ها، تور شده و هزینه‌های گزافی را نیز برای تقریباً هیچ متحمل شده‌اند! گزارش آقای چِیلان به‌روشنی نشان می‌دهد که این چارچوب‌ها و به‌ویژه چارچوب معظم SAFe، چندان هم چابک و «ایمن» نیستند!به دلیل اهمیت اسلاید و نکات بسیار کلیدی و آموزنده‌اش، ترجمه آن را به همراه برخی اشارات تکمیلی در ادامه خواهم آورد. امیدوارم راهگشای تصمیمات و انتخاب‌های آتی شرکت‌ها و سازمان‌ها، بخصوص آنانی که علاقه بسیار زیادی به مقیاس‌دهی به همه‌چیز دارند، قرار گیرد.اسلاید شماره 12ترجمه اسلاید 12: Questions about the Agile/SAFe Memoیادداشتی با موضوع به‌کارگیری DevSecOps و Agile، با امضای افسر ارشد نرم‌افزار در تاریخ 26 نوامبر 2019 ثبت و به‌تمامی مدیران اجرایی برنامه (PEO) و مدیران پروژه (PM) ارسال گردیده و در آن نسبت به استفاده از چارچوب‌های سخت‌گیرانه و تجویزی مانند چارچوب SAFe، به‌شدت ابراز نگرانی و یاس شده است.چرا؟وزارت دفاع (DoD) هنوز از ساختارهای آبشاری (Waterfall) یا آبچاری (Water-Agile-Fall) استفاده می‌کند پس تا زمانی که نتوانیم واقعاً اسکرام یا کانبان بنیادین را پیاده‌سازی کنیم، چیزی برای «مقیاس دهی (SCALE)» وجود نخواهد داشت. چابکی باید بر سرتاسر برنامه (Program) اعمال شود و نه‌فقط بر روی تیم توسعه، که شامل این موارد است: قراردادها و پیمان‌ها، مدیریت برنامه، گزارش دهی مستقیم به رهبران (نه واحد مدیریت ارزش کسب‌شده – EVM) و غیره!تا زمانی که «مبانی» را به‌طور صحیح در اختیار ندارید، نمی‌توانید به چیزی مقیاس دهید. در بهترین حالت، این چارچوب‌ها به دلیل «نگاشت‌ها و الگوهایشان»، ما را درخطر سقوط به آنچه همه می‌شناسیم قرار داده و به «توسعه آبشاری» بازخواهند گرداند.چارچوب SAFe ممکن است برای تیم‌هایی که از مفاهیم DevSecOps یا DevOps استفاده نمی‌کنند، مفید باشد ولی اصل کلیدی در DevSecOps، تفکیک کردن کارها و تیم‌ها از هم است و هماهنگی‌ها و همگام‌سازی‌های موردنیاز احتمالی تنها باید از طریق «مالکان محصول» انجام شود. تیم‌ها اگر از یک سرویس‌مِش، طراحی DDD و یا مایکروسرویس‌ها استفاده می‌کنند، اصولاً نباید نیازی به همگام‌سازی و هماهنگی‌های پیچیده داشته باشند. در این حالت نیازی به چارچوب‌های سفت‌وسخت نیست. اگر در پیاده‌سازی این موضوع مسئله دارید پس مدل صحیحی از DevSecOps را پیاده نکرده‌اید.بخش‌های خوب از هر چارچوب را بگیرید و در تیم خود بکار ببندید. مدارک و گواهی‌نامه‌ها همیشه پاسخگو نیستند.اساساً «هدف» اصلی در توسعه نرم‌افزار در «امنیت - SAFE» بودن نیست، بلکه «نوآوری» کردن و «ساختن» است! نمی‌توانید بدون اینکه ریسک کنید، چیزی بسازید ... بلکه کاملاً برعکس:«یادگیری مستمر: سریع شکست بخور ولی از یک دلیل واحد، دو بار شکست نخور!» - تغییرات افزایشی کوچک که ریسک‌ها را تخفیف داده و شرایطی امن برای انجام سریع تغییرات (تغییرات سریع) ایجاد می‌کنند.چارچوب SAFe تاکنون توسط هیچ‌کدام از سازمان‌های تجاریِ موفق، مورداستفاده قرار نگرفته است (فیس‌بوک، گوگل، نتفلیکس و غیره)عملکردها و وظایف بالاسری بیش اندازه و افراطی (آبشاری‌مانند)به دنبال هماهنگی و همگامی کارهای مالکان محصولتان می‌گردید؟ مدل‌های بسیار زیادی مانند اسکرام در اسکرام وجود دارند. این کار (هماهنگی مالکان محصول) نباید تأثیری بر روی توسعه‌دهنده‌ها داشته باشد.پایان ترجمه/لیست زیر شامل منابع ارزشمند و برگزیده‌ای است که به‌نوعی از زوایای متنوع به‌نقد این ابزارها و فرایندهای سنگین‌وزن پرداخته‌اند.شوربختانه به دلیل قرارگرفتن در بخشی بسیار ویژه از جغرافیای جهان، احتمالاً برای مشاهده برخی از این منابع علمی نیاز به مختصری ارتکاب به جرم و دور زدن فیلتر اینترنت هستید!! پیشاپیش از سوی خودم بابت این موضوع از شما پوزش می‌خواهم!کن شوئیبر – آگوست 2013: unSAFe at any speedویدئویی تماشایی از آقای جز هامبل در کنفرانس GOTO2015 با عنوان: Why Scaling Agile Doesn't Workدیو اسنودن – مارچ 2014: SAFe: the infantilism of managementکریس مَتز – آگوست 2013: Two Legs Goodدومینیک ماکسیمینی – سپتامبر 2013: A critical view on SAFeران جفریس – آوریل 2014: Issues with SAFeیادداشتی دیگر از آقای ران جفریس – فوریه 2014: SAFe - Good But Not Good Enoughمایک کات مِیِر – مارچ 2015: Let’s Acknowledge Safe For What It Is… And Move Onآقای نیل کیلیک – مارچ 2012: The Horror Of The Scaled Agile Frameworkتعبیری جالب از آقای مایک کان: L.A.F.A.B.L.Eپیتر هاندرمارک – ژانویه 2014: Scaling Scrum to the Organizationتعبیر جالب مارتین فالر: SAFe: Shitty Agile For Enterprises! در پنل هیجان‌انگیز GOTO2014 با عنوان: A Retake on the Agile Manifestoو توضیحات جالب مقامات ارشد ارتش در خصوص حلقه اودا - OODA:رودریک یاپ – فوریه 2019: OODA Loop: The Difference Between Tempo and Speedرودریک یاپ – فوریه 2019: OODA Loop: How The Taliban Used It سهیل صمدزاده سهیل صمدزاده Fri, 20 Dec 2019 18:00:08 +0330 https://virgool.io/@soheilsam/%D8%B3%D9%81%D8%A7%D8%B1%D8%B4-%DA%86%D8%A7%D8%A8%DA%A9%DB%8C-%D9%88-%D8%A8%D8%A7%D8%B2%D8%AA%D8%B9%D8%B1%DB%8C%D9%81-%DA%A9%D8%A7%D8%B1-nbqr4lp7i0l8 یک نقص جدی هم که ریشه در سوءتفاهم دارد آن است که اغلب مجموعه‌هایی که به فکر «سفارش دادن چابکی» می‌افتند، مثل سفارش یک پیتزا پپرونی، درواقع به دنبال بسته‌ای می‌گردند که کمک کند تا کارمندان، «بیشتر کار کنند!»ریشه این خطای شناختی در «تعریف کار - Definition of The Work» نهفته است و وقتی دیر یا زود نوبت به اصلاح «تعریف کار» می‌رسد، مقاومت در برابر چابکی آغاز می‌شود!قرن‌ها عقبه مدیریت سنتی و تهاجم فرهنگی صنعت به توسعه نرم‌افزار، باعث شده اغلب سازمان‌ها نسبت به تعریفی که از کار دارند بسیار مطمئن و به آن مغرور باشند. مفهوم «کار» در این فضا، همان «تولید صنعتی» است! تولید نرم‌افزار مثل تولید کلوچه! ازاین‌رو منطقی است که به دنبال سیستم‌هایی برای «انجام درستِ کار» باشند تا تن دادن به ابتکارهایی برای «انجام کارِ درست»: ما کارمان درست است ولی متأسفانه درست کار نمی‌کنیم! - خیلی آشناست؛ نه؟!مواد اولیه، که همان ایده‌های ناب، افکار، طراحی‌ها و تکالیف هستند از بالا روی سرِ کارگران ریخته شده و در کف کارگاه باید فراوری و بسته‌بندی شوند! ماهیت کار در این سازمان‌ها «چیزی واقعاً واضح» تلقی می‌شود!باید صادقانه اعتراف کرد که نقش «اسکرام تجاری» یا بهتر بگویم «تجارت اسکرام»، در رشد فزاینده این کج‌فهمیِ ویرانگر، بسیار پررنگ بوده و هست!انجام کار در اسکرام یک هنر است! اسکرام از شما توقع دارد در انجام دادن کار مانند یک آرتیست عمل کنید.اما آنچه در این میان اهمیت دارد این حقیقت است که چابکی درنهایت باعث بیشتر کار کردن کارمندان خواهد شد؛ ولی پس از بازتعریف کار! ماهیت کار در چابکی، دست‌کم در توسعه نرم‌افزار، مترادف «خلق» است و خلق کردن، فعالیتی پیچیده است! این بازتعریف از کار، شاید تأثیرات ساختاری عمیق و جدی طلب کند: جریان مدیریت را تحت تأثیر قرار دهد. ساختارهای قدرت را دگرگون کند. توازن هزینه‌ها را برهم زند. ادغام و تفکیک‌هایی ایجاد کند و حتی باعث جابجایی فیزیکی افراد شود!تأثیراتی که اغلب «رادیکال» شمرده می‌شوند؛ و بله! چابکی از این منظر، تفکری رادیکال است!قبل از سفارش پیتزای پپرونی مان به این نکات مهم توجه کنیم. آنگاه شاید تصمیم بگیریم سفارشمان را به آینده موکول کنیم! وقتی که احتمالاً ازلحاظ مبانی فکری آماده‌تر هستیم. سهیل صمدزاده سهیل صمدزاده Thu, 12 Dec 2019 16:27:30 +0330 https://virgool.io/@soheilsam/%D9%85%D8%B1%D8%A8%DB%8C-%DA%86%D8%A7%D8%A8%DA%A9-%D9%88-%D8%AA%D9%85%D8%B1%DB%8C%D9%86-%D8%AF%D8%B1-%D9%85%D8%B3%D8%A7%D8%A8%D9%82%D9%87-lgxqvvteuj7q مربی‌گری چابک از بسیاری جهات به مربی‌گری در ورزش‌های حرفه‌ای مثل فوتبال یا بسکتبال شباهت دارد! اما دست‌کم در یک بُعد به‌مراتب از آن پیچیده‌تر و دشوارتر است!مربی‌گری در ورزش‌های حرفه‌ای به شکل قاعده‌مندی به دو فضای مجزا تقسیم می‌شود: فضای مسابقه و فضای غیر مسابقه!مربی یک تیم ورزشی، تیم را در زمان‌هایی که در مسابقه نیستند، تمرین می‌دهد تا مهارت‌های فردی و تیمی، تکنیکی و تاکتیکی آن‌ها برای روز واقعه – مسابقه، حفظ‌شده یا ارتقاء یابد. مربی فرصتی ناب برای تمرین دادن دارد و بازیکن‌ها هم تمرکزی برای تمرین کردن! بازیکنان و حتی خود مربی، در زمان تمرین چیزهایی می‌آموزند و در زمان مسابقه آن‌ها را تثبیت می‌کنند!وقتی یک مربی فوتبال در زمان غیر مسابقه، بازیکنان تیم را وادار می‌کند در یک محدوده کوچک چند متری دوبه‌دو بر سر توپ بجنگند - ابتکاری به نام سوئِت باکس (SweatBox) که بیل شِنکلی، مربی اسطوره‌ای لیورپول، آن را اجرا می‌کرد، و یا به افراد توصیه می‌کند تا حین دست‌به‌دست کردن توپ، دراز و نشست بروند، یا دروازه‌بان‌های کم‌تجربه‌تر را وادار می‌کند تا قبل از همه به زمین تمرین رفته و عرض دروازه‌ها را به شکل رفت و برگشتی و بدون توقف، در سه ست پانزده‌تایی طی کنند، عمدتاً مجبور نیست توضیح بدهد که چرا این کار را می‌کند و یا این چه ربطی به «فوتبال» دارد! همه در فوتبال حرفه‌ای این مبنای فکری را پذیرفته‌اند که امروز روز «مسابقه» نیست و ما «تمرین» می‌کنیم، پس اگر فوتبال بازی نکردیم، هیچ ایرادی ندارد!اما فضای مربی‌گری چابک در توسعه نرم‌افزار تنها یک‌لایه دارد: مسابقه! تیم محصول، هرلحظه‌اش روز واقعه است: روز مسابقه! برای تیم محصول، مسابقه یک رویداد تقویمی برنامه‌ریزی‌شده در آینده نیست، بلکه روالی روزانه است! پس باید در حین همان مسابقه‌ای که بر سر تولید ارزش کسب‌وکار در جریان است، تمرین هم داده شوند! هیچ فرصت مجزا و مستقلی برای نشستن روی چمن‌ها، اردو زدن در سواحل پر اکسیژن اسپانیا، و تمرین کردن بدون دغدغه وجود ندارد و اگر هم وجود داشته باشد، بسیار محدود، اتفاقی و دست‌ساز خواهد بود – مانند رویدادهای جذاب و مفید هکتون یا فرصت فراغت 20درصدی گوگل به کارکنانش برای کار خارج از چارچوب!برای تیم محصول، مسابقه یک رویداد تقویمی برنامه‌ریزی‌شده در آینده نیست، بلکه روالی روزانه است!بسیار اهمیت دارد که مربیان چابک و سازمان‌های نرم‌افزاری با ویژگی‌های اتمسفری که در آن کار می‌کنند آشنا باشند. خیلی به‌ندرت می‌توانید به‌سادگی مانند یک مربی فوتبال، تمرینی را تدارک ببینید که در ظاهر با منطق مسابقه جور درنیاید – سوئِت باکس بیل شِنکلی را به یاد بیاورید: هیچ‌کس ربط منطقی و مستقیم تقلای شدید بر سر توپ در یک محوطه کوچک را با بازی فوتبال حرفه‌ای درک نمی‌کرد!اگر می‌خواهید مثلاً مالک محصول، مهارت داستان‌گویی را تمرین کند، اگر می‌خواهید گوش‌هایش به افعال، اسم‌ها و رابطه بین آن‌ها در کلام مشتری حساس باشد؛ اگر می‌خواهید اسکرام‌مستر یا لیدر مهارت‌های ناب تسهیلگری را از طریق توجه فعالانه به سکوت‌ها در گفتگوها بیاموزد؛ مجبورید در حین مسابقه او را تمرین دهید!آن‌ها امکان فاصله گرفتن از مسابقه برای تمرین کردن را ندارند! شوربختانه درون یک لیگ قاعده‌مند و مدیریت‌شده فوتبال قرار نداریم، اینجا کارزار پیچیده تولید نرم‌افزار است!برای استعاره، دروازه‌بانی را تصور کنید که در طول یک بازی جدی جام حذفی، درعین‌حال که با پرش‌های بلندش مانع ورود توپ به دروازه می‌شود، عرض دروازه را نیز باراهنمایی مربی بارها و بارها می‌پیماید! تکرار و تمرینی که باعث تقویت حافظه تصویری او برای درک شهودی ابعاد سنگری می‌شود که از آن محافظت می‌کند! او و مربی‌اش فرصت دیگری برای تمرین کردن ندارند! من نامش را «تمرین در مسابقه» گذاشته‌ام!سخن آخر...اما این شناخت، یک معرفت دوسویه است! اگر قرار است و ناچاریم که تمرینات در حین مسابقه و بدون ایجاد وقفه در جریان تولید ارزش صورت‌پذیرند، تنها گزینه بهینه، کمی وسواس در انتخاب مربی و پس‌ازآن اعتماد به او است!اگر چیزی باعقل جور درنمی‌آید، اگر پیشنهادهای مربی در ظاهر با روال و قواعد ذهنی شما تناقض دارند، اگر ربط منطقی بین تمرین و تولید نرم‌افزار نمی‌یابید، قبل از مقاومت و فشار به مربی برای تشریح مفصل و متقاعد کردن شما که: «ما اینجاییم تا فوتبال بازی کنیم، نه اینکه دراز و نشست توپی برویم!»، به این بیندیشید که احتمالاً در حال تمرین کردن چیزی در حین مسابقه هستید! چیزی که جایی در کارزار روزانه، بدون آن‌که خودتان بدانید، بدردتان خواهد خورد! سهیل صمدزاده سهیل صمدزاده Thu, 05 Dec 2019 16:31:00 +0330 https://virgool.io/@soheilsam/%DA%86%D8%B1%D8%AE%DB%80-%D9%86%DB%8C%D8%A7%D8%B2-%D8%AF%D8%B1-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-yeegcnikqzgz در چابک‌سازی‌های ناقص و کج‌وکولـۀ سازمانی، بخصوص در مقیاس‌های بزرگ، گاهی دیده می‌شود که همان سیلوهای سنتی (واحد تحلیل، واحد طراحی، واحد ...)، همچنان ولی این بار با نام و نشانی مدرن به حیاتشان ادامه می‌دهند. گویی ذهن واحدسازِ بشر، در کنترل کردن این عطشش ناتوان است. مثلاً در ساختار جدید، «واحد تحلیل» سابق به «تیم محصول» یا از آن هم بدتر، «تیم مالکان محصول!» تغییر نام می‌دهد! این پدیده احتمالاً از آنجا سرچشمه می‌گیرد که تغییر دادنِ نام و نشان‌ها، بسیار ساده‌تر از تغییر منش‌ها و روش‌ها است. البته تغییر دادنِ نام و نشان‌ها همواره مفیدند، به شرطی که مقصد و مقصود نباشند!مشاهده دوم از سری مشاهدات لارمن صراحتاً به این موضوع اشاره‌کرده است:«پیرو مورد شمارۀ (۱)، هرگونه ابتکار برای تغییر به شکلی تقلیل خواهد یافت تا معنای اصطلاحات جدید، مترادف با همان وضع فعلی، بازتعریف یا چندپهلو شوند.»از توضیح این واضحات و مقدمه که بگذریم، اما پسِ پشتِ این کج شکلی و کج‌فهمی، خطر جدی‌تری در کمین چابک‌اندیش قصه ما نشسته است. در هر فرایندِ نقش‌محورِ مبتنی بر تعامل، درک صحیح از «چرخۀ نیاز» بسیار اهمیت دارد. اهمیتش آنجا بیشتر نمایان می‌شود که بدانید حتی می‌توانید چابکی خود را با آن محک بزنید.چرخۀ نیاز در یک سازمان چابکِ اسکرامی اینگونه است که:سازمان به مالک محصول نیاز دارد.مالک محصول به اسکرام‌مستر نیازمند است.اسکرام‌مستر برای نگهداری چابکی به پشتیبانی سازمان نیاز دارد.مالک محصول به تیم توسعه نیاز دارد.تیم توسعه برای چابک بودن و ماندن، به اسکرام‌مستر نیازمند است.چرخۀ نیاز، همان‌طور که از نامش پیداست، ترسیم‌کنندۀ ارتباطات مستقیم و کلان است. بدیهی است تمام اجزای سیستم به‌واسطه همین ارتباط‌های یک‌به‌یک، به‌صورت غیرمستقیم هم به هم وابسته و نیازمند هستند. مثل نیاز غیرمستقیمِ تیم توسعه به سازمان و بالعکس.اما مهم‌ترین و پر مناقشه‌ترین جزء این پنج ارتباط، «نیاز مالک محصول به تیم توسعه» است. منظومۀ چابک‌سازی‌های کج‌وکوله تحت تاثیر نیروی جاذبه‌ای مرموز به مرور به سویی متمایل می‌شود که گویی این تیم توسعه است که به مالک محصول نیازمند است. اینکه مالک محصول همچون مادر یا پدری سالار و دلسوز، تأمین‌کنندۀ نیاز اساسی یعنی خوراکِ (بخوانید داستان کاربر) تیم توسعه است و مانند نگهبان پرندگان باغ هر از گاهی تکه‌ای نان (بخوانید آیتم بک‌لاگ) را آماده و به درون قفس پرندگان (بخوانید اسپرینت) پرتاب می‌کند!درواقع جهت پیکان در این نیاز کاملاً معکوس است. مالک محصول است که در تمام مراحل کارش به تیم توسعه وابسته که هیچ، نیازمند است! درک این چرخه و سرمایه‌گذاری بر روی چنین تغییر دیدگاه‌هایی، آنچه ناموفق‌ها از آن بی‌بهره‌اند را به شما هدیه خواهد کرد: فرهنگ چابکی! سهیل صمدزاده سهیل صمدزاده Tue, 18 Jun 2019 17:56:31 +0430 https://virgool.io/@soheilsam/%DA%86%D8%A7%D8%A8%DA%A9-%D8%AA%DB%8C%D9%84%D9%88%D8%B1%DB%8C%D8%B2%D9%87-ych4r4a3qazd یعنی این تفکر تیلوریسم و آبشاری را هر جور که می‌زنی و از هر دری که بیرون می‌رانی، بازهم پنجره‌ای یافته و به داخل می‌جهد!!اخیراً خیلی مد شده که شبیه چنین چیزهایی را در مورد افراد و حواشی ساختارهای سازمانیِ به‌اصطلاح چابک، بشنویم:ما نیروهای کار بلدِ چندکاره داریم، بنابراین به هیچ فردی توی تیم وابسته نیستیم.اگر با کنار گذاشتن کسی از مجموعه، دچار مشکل تولید بشم، پس طرز مدیریت خوبی نداشتم!اگر ما به یک نفر خیلی نیاز داشته باشیم پس ساختار سازمانی خوبی نداریم!ما خیلی خفنیم، هرکس رو با هرکس دیگه میشه توی تیم‌مون جایگزین کرد!محصول ما به فرد خاصی وابسته نیست. هرکسی رو میشه با خیال راحت جابجا کرد!درواقع باید به این عده از شبه چابک‎اندیشان یادآور شد که تن عالی‌جنابان تیلور، ماکس وِبِر و هنری فایول – از پیشگامان مکتب تیلوریسم و مدیریت علمی-اداری، هم با مشاهده این وصله‌کاری‌های خوفناک و نامیمون، در گور می‌لرزد!تقریباً هر متدلوژی‌ای حول سه محور اساطیری می‌چرخد. هر مکتب و جهان‌بینی در توسعه که کیفیت برای آن مطلوب است، این سه مؤلفه را بازتعریف کرده است. البته هر یک به شیوه و ذائقه خودش: افراد – محصول – فرایند.3P’s: People, Product, Process (, Performance)در هیچ سبکِ توسعه‌ای، چه رسد به آن‌ها که وابسته به دانشکاران‌اند (Knowledge Workers)، افراد به‌مثابه آجرهای سفالی و بدون خون و خونریزی، قابل تعویض و جایگزینی نیستند. شگفت اینکه حتی در یک ساختمان هم به این سادگی‌ها نمی‌توان یک آجر را با همتایش جابجا کرد! برای نمونه، اصول چهارده‌گانه مدیریت اداری – هِنری فایول را ببینید (اصل دوازدهم) تا متوجه شوید که برادران زاویه‌دارِ تیلور-مکتب هم، هرگز این‌گونه فجیع به کشتنِ خود برنخاسته بودند که ما چابک کاران، به زندگی نشسته‌ایم!خط آخر: استراتژی و ساختار سازمانی خود را به‌گونه‌ای بچینیم که به همۀ افراد وابسته باشد! خودسازمان‌دهی و چندکاره بودن، یک صفت جمعی است. نگاه خطی به مناسبات تیمی و روابط انسانی در تیم‌ها، وصله زدنِ ناشیانۀ تکه‌ای از جهان‌بینیِ سنتی بر پیکرۀ چابکی است. وصله‌های ناجوری که به آن نمی‌چسبند! سهیل صمدزاده سهیل صمدزاده Thu, 25 Apr 2019 19:03:43 +0430 https://virgool.io/@soheilsam/%DA%A9%DB%8C%D9%85%DB%8C%D8%A7%DB%8C-%D9%87%D9%85%DA%A9%D8%A7%D8%B1%DB%8C-gaxqdxyu3n0d چهار مانع همکاری - مورتن تی. هانسنتیم‌هایی که از ذهنیت و خودسازمان‌دهی خوبی برخوردارند، با حداقلِ فرایندها هم می‌توانند موفق عمل کنند. در مقابل، تیم‌هایی که ذهنیت مناسبی ندارند دائماً در حال تقلا برای دست‌کاری و افزودن فرایندهای رنگ‌ووارنگ به جریان کاریشان هستند، به این امید که بتوانند به عنصرِ گم‌شدۀ «همکاری» که تیم‌های نوع اول به‌صورت طبیعی از آن بهره‌مندند، دست بیابند! ناتوانی سازمان در همکاریِ مؤثر، مانند موجودی شرور و موذی، همیشه در پشت فرایندهای پیچیده‌ای که خودش سازمان را مجبور به خریدنشان کرده است، پنهان می‌شود!همکاری: کار کردن باهم برای دست‌یابی به «یک» چیز یا هدفی مشترک!جالب اینجاست که بازار مکارۀ ابزارها و فرایندها هم دقیقاً از همین روزنۀ همیشه باز، سوءاستفاده کرده و محصولات پیچیدۀ خود را به شرکت‌ها قالب می‌کند. درواقع از هراسی که سازمان‌ها از عریان ماندن و دیده شدن معایبشان دارند برای فروش چنین بالاپوش‌ها یا زیرپوش‌هایی، استفاده می‌کنند.به‌جرئت می‌توان گفت، در تیم‌ها و سازمان‌های نوع دوم، گاهی بیش از نیمی از «پتانسیل» تیم، صرفِ حل‌وفصل مسائل کم‌ارزش و اقدامات غیر محصولی می‌شود:اختراع جلسات طولانیجدال و گیس‌وگیس‌کِشی‌های متعدد در طول و عرض سلسله‌مراتبنصب و ور‌رفتن با ابزارهای نجومی دست‌وپا گیرتدارکِ آیین و مراسم‌های بی‌حاصلدست‌کاری مداوم ترکیب تیم‌هاایجاد رقابت خونین در رشد عمودی در سازمان و درجاتِ شغلیسمی کردن فضای سازمان با پذیرش برنامه‌های سنگین ارزیابی عملکردسرگرم شدن به‌نوعی بازی و جنگِ داخلی بر سر ارزیابی‌های فردی... بجای تمرکز بر جَنگِ بزرگی که بیرون از ساختمان شرکت، و در بازار در جریان است!If you want to go fast, go alone; if you want to go far, go together! - African Proverb خط آخر: شوربختانه تمام سازمان‌ها حتی مقتصدترین‌هایشان، بدون آنکه خود بدانند، در ازای این پتانسیل‌های هدررفته، پول می‌پردازند و از سویی دائما در پی یافتن راهی برای صرفه جویی در هزینه‌ها هستند! سازمان‌ها و بخصوص مدیران ارشد باید به این موضوع بیندیشند که دقیقاً بر روی چه چیزی سرمایه‌گذاری می‌کنند؛ بر روی یک قایم‌باشکِ دائمیِ بی‌صرفه یا عنصرِ ارزشمندِ «همکاری»! سهیل صمدزاده سهیل صمدزاده Mon, 08 Apr 2019 17:23:49 +0430 https://virgool.io/@soheilsam/%D9%86%D8%AC%D8%A7%D8%AA-%D8%AC%D9%86%DA%AF%D9%84-%D8%A7%D9%84%D9%85%D8%A7%D8%B3-%D8%AF%D9%88%D9%82%D9%84%D9%88-%D8%AF%DB%8C%D8%B2%D8%A7%DB%8C%D9%86-%D8%A7%D8%B3%D9%BE%D8%B1%DB%8C%D9%86%D8%AA-tgn8liykkwo0 روش‌های حل مسئله که بر پایه الگوی الماس دوقلو بناشده‌اند - مثل دیزاین اسپرینت، شما رو زمانی به نتیجه مطلوب نزدیک خواهند کرد که کامل و صحیح اجرا شوند و مهم‌تر از اجرای کامل و صحیحشان، داشتن درک صحیح از خود پرکتیس هست. اینکه چرا به این شکل عمل می‌کنیم و به شکل دیگری عمل نمی‌کنیم!الماس‌های دوقلو تفکرطراحیدر هر پنج مرحله/روز دیزاین اسپرینت از الگوی واگرایی (Diverge)/همگرایی (Converge) برای حل مسئله استفاده میشه، که به‌نوعی با روش سنتی (ولی همچنان کاربردی) «طوفان فکری گروهی»، زاویه داره! در طول اسپرینت، تیم بارها از هم دور و دوباره به هم نزدیک میشه! برخی از این انبساط و انقباض‌ها محسوس هستند و برخی نامحسوس!برای درک بیشتر نحوه کار این سیستم، این تمثیل میتونه کمک کنه: فرض کنید که من و شما در جنگلی انبوه گم شدیم! خب، اینجا یک مشکل وجود داره، گم‌شدن در جنگل، و یک چالش برای من و شما: جون سالم به دربردن از جنگل، قبل از تاریک شدن هوا! این چالشِ مخصوص من و شما در مواجهه با اون مشکل هست، ممکنه افراد دیگه، چالش دیگری رو انتخاب کنند، مثلاً: ماندن در جنگل و دوام آوردن تا صبح!برای حل این چالش، من و شما از هم جدا می‌شیم (واگرایی) و قرار می‌ذاریم که سر ساعت مشخصی به همون نقطه برگردیم! (همگرایی)؛ دو ساعت بعد، من با آب سالم برای نوشیدن برمی‌گردم و شما، با یک نقشه راه برای رسیدن به دهکده کوچکی که اون سمت رودخانه پیداش کردید! توجه کنید که هیچ تقسیم‌کاری صورت نگرفته، ممکن بود اگر من هم بیشتر جلو می‌رفتم یا مسیر دیگه‌ای رو برای جستجو انتخاب می‌کردم، به یک دهکده می‌رسیدم یا خودرویی رو می‌دیدم؛ ولی هر دو متعهد به بازگشت سر ساعت بودیم و در این تایم‌باکس، چیزی که من تونستم به‌دست بیارم، آب برای نوشیدن بود! و این عالیه! می‌بینید؟ سطح «عدم قطعیت» خیلی بالاست!یک نکته مهم دیگه اینکه، هدف اصلی ما به‌عنوان یک کسب‌وکار وسط اون جنگل مخوف، جون سالم به دربردن قبل از تاریک شدن هوا بود، ولی من و شما بعد از این رفت‌وبرگشت اسپرینتی، هنوز از جنگل جون سالم به درنبردیم! بردیم؟ نه!در عوض «چیزی اعتبارسنجی شده» رو یاد گرفتیم که به‌احتمال‌زیاد میتونه ما رو از این مخمصه نجات بده!ماشین تولید آگاهی، دیزاین اسرپرینت!... و خط آخر: ورودی هر دیزاین اسپرینت، یک «چالش» خوش‌تعریف و خروجی آن، یک «آگاهی» است! این آگاهی ارزشمند، در جای دیگری دستمایه توسعه محصولی کار کننده خواهد شد. به دیزاین اسپرینت به چشم یک ماشین تولید آگاهی از مواد خامِ چالش و دانش، نگاه کنیم. سهیل صمدزاده سهیل صمدزاده Mon, 11 Mar 2019 19:44:03 +0330 https://virgool.io/@soheilsam/%D8%B3%D8%B1-%DA%A9%DB%8C%D8%B3%D9%87-%D8%B1%D8%A7-%D8%B3%D9%81%D8%AA-%DA%A9%D9%86-pkorb59hkszm Photo Credit: pexels.comدرسته که «بازخوردی که نکُشتت، قوی‌ترت می‌کنه!»، ولی این رِسِپی برای اینکه نکُشتت، یک ادویه مخصوص لازم داره که تمایز ایجاد میکنه!هر کسب‌وکار نوپا و نوزادی، در بدو تولدش یک کیسه ژتون اعتباری خدادادی با ظرفیت مشخص داره! اینکه حجمش چقدره یا اعتبار کی از کی بیشتره، واقعاً معلوم نیست و راستش، مهم هم نیست! روند و استراتژی خرج کردنشه که مهمه!ژتون‌های داخل این کیسه، شکلی از اعتباره که یک کسب‌وکار در مسیر بازخورد‌گیری ازش استفاده میکنه. یک جور صندوق اعتباری بازخورد! درواقع در هر سیکل بازخورد‌گیری (به هر شکل و روشی که عمل میشه)، مقداری از این ژتون‌ها رو خرج می‌کنیم!نکته اصلی اینه که، کاربر یا مشتری، چشمه‌ی لایزال بازخورد نیست! اینکه امورات یک کسب‌وکار مدام از طریق «اگر بخوره، صدا میده!» یا «حالا میزنیم، ببینیم کاربر چی میگه!»، «همینطور MVPوار توسعه بدیم!»، بگذره، یک‌جور ریخت‌وپاش و بی‌بندوباری در خرج کردن از کیسه است.رفتار کاربرها، بخصوص در مواجهه با سرویس‌های آنلاین، نشان داده که به شکل طبیعی، ظرفیت محدودی در تحمل چیزهایی که دوست ندارند، دارند! بازخورد دادن وظیفه تکوینی و «توکار» کاربرها نیست! واضحه که ظرفیت و اعتبار این صندوق در مسیر رشد کسب‌وکار میتونه با مدیریت صحیح محصول و مانورهای اعتبارساز، افزایش پیدا کنه ولی ولخرجی از اعتبار اولیه، نوید بی‌پناهی کسب‌وکار در روزهای سرد و تاریک را می‌دهد!دیر یا زود یک روزی در چرخه حیات محصول فرا میرسه که به بازخوردهای کافی، صادقانه و حیاتی کاربر نیاز داریم، ولی کیسه‌مون خیلی خالیه!... و خط آخر: مدیران محصول چابک عزیز، ولخرج نباشید، سرکیسه رو کمی سفت کنید، اقتصادی‌تر عمل کنید و به فکر زمستان‌های متعدد پیشِ رو باشید! سهیل صمدزاده سهیل صمدزاده Sat, 09 Mar 2019 17:33:14 +0330 https://virgool.io/@soheilsam/%D8%A8%D9%87%D8%A8%D9%88%D8%AF%D9%85%D8%B3%D8%AA%D9%85%D8%B1-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF-%D8%AA%D8%A6%D9%88%D8%B1%DB%8C-%D9%85%D8%AD%D8%AF%D9%88%D8%AF%DB%8C%D8%AA%D9%87%D8%A7-dweyuibyhbxu بهبود مستمر در تونل ارزش - Inspired by Even Leybournوقتی به امید بهبود فرآیندهای کاری در توسعه یا تولید، دست به تغییر و اصلاح امور می‌زنید، اغلب بعد از برطرف شدن یک مشکل، مسائل جدیدی خودشون رو نشون میدن که به نظر میاد قبلاً وجود نداشتند!جمله آشنایی هست که مدیران بیان می‌کنند: ما واقعاً این‌همه مشکل داشتیم و خبر نداشتیم؟!فرض کنید الآن مسئله یک تیم توسعه نرم‌افزار، تولید شدن باگ‌های زیاد هست و شما با سلسله اقداماتی بعد از زمانی مشخص تولید باگ رو مدیریت کردید و درنتیجه تعداد اونها به حداقل ممکن رسیده. معمولاً بلافاصله بعد از دستیابی به چنین دستاوردی، چیزهای بدقواره دیگه‌ای شروع به رژه رفتن جلوی چشمتون می‌کند. چیزهایی که روز اول اونها رو نمی‌دیدید! مثلاً، جلسه‌ها به نظرتون طولانی و بی‌کیفیت میان! دموها خوب نیستند! افراد تیم حرف هم رو به اون خوبی که باید متوجه نمیشن! دست‌به‌دست شدن طراحی‌ها تو ذوق میزنه! و ازاین‌دست مشکلات...اولین چیزی که به ذهن ممکنه بیاد اینه که «آیا اقدامات انجام‌شده برای رفع مسئله باگ، باعث به وجود اومدن این مشکلات جدید شده؟» پاسخ اینه که، بله! احتمالش هست که همین‌طور باشه! ولی تئوری محدودیت‌ها (Theory of Constraints) معتقده که اکثراً این‌جور نیست! مشکلات جدیدی که حالا خودشون رو نشون دادند، قبلاً هم وجود داشتند ولی به دلیل وجود محدودیت‌های تو چشم تر و چغر تر (مثل باگ‌های کلافه کننده!)، از افق دید سازمان خارج بودند. برای همینه که بهبود مستمر که در پنج گام تئوری محدودیت‌ها مطرحه، تأکید زیادی بر روی تکرار داره. طبق نظریه دکتر گُلدرات، کار روی محدودیت‌ها به این شکل شروع میشه که بعد از شناسایی محدودیت، گام دوم بهره‌برداری بهینه از هر آنچه که هست است، بعد بقیه اجزای سیستم رو با محدودیت موجود که حالا داره با حداکثر توان کار میکنه، بالانس می‌کنیم و درنهایت سعی می‌کنیم گره‌ها و محدودیت‌های اون جزء رو با استفاده از خلاقیت، فنّاوری، پول یا پارتی باز و رفع کنیم! همه این چهار عمل برای هر محدودیتی که در سیستم وجود داره و اراده‌ای هم برای برطرف کردنش هست، از اول تکرار میشه تا تمام محدودیت‌ها یا دست‌کم آونهایی که حل‌شدنی هستند، برطرف بشن! بعد از حل یک مشکل یا رفع یک محدودیت، مشکلات جدیدی خودنمایی می‌کنند که میتونید به همان روش قبل اونها رو هم برطرف کنید. در تمام طول این مسیر، مطمئن بشید که پشتیبانی مدیریت رو در اختیار دارید. مدیران و رهبران امروز باید به این مدل‌های ذهنی و تئوری‌ها مجهز باشند و خودشون و همکارانشون رو برای مشکلات و محدودیت‌هایی که یکی پس از دیگری خودنمایی می‌کنند، سرزنش نکنند. البته از مشاوران و کارشناسان تغییر در سازمان هم انتظار میره که این مباحث رو قبل از شروع کار برای مجموعه تبیین کرده باشند!همونطور که هم علم میگه و هم تجربه، طبیعت کار در بهبود مستمر به همین شکل هست.این یادداشت قبلا در اینجا منتشر شده است. سهیل صمدزاده سهیل صمدزاده Sun, 24 Jun 2018 12:59:44 +0430 https://virgool.io/@soheilsam/%D8%A8%DA%A9%D9%84%D8%A7%DA%AF-%DA%86%D9%88%D8%A8%DB%8C-%D8%A7%D8%AC%D8%AF%D8%A7%D8%AF-%D8%A8%DA%A9%D9%84%D8%A7%DA%AF-%D9%85%D8%AD%D8%B5%D9%88%D9%84-yfbxk4yau3ob پیشینه آنچه ما امروز به نام بک‌لاگ (Backlog) می‌شناسیم شاید به عصر نوسنگی، حدود ۱۰ هزار سال قبل، بازگردد!زمانی که انسان خردمند (Homo sapiens) از عادت صدها هزار ساله مهاجرت و کوچ‌نشینی خود دست کشید و به یکجانشینی روی آورد. او به‌زودی آموخت که چگونه باید برای گذران زمستان‌های سرد، در فصول گرم‌تر سال هیزم کافی «جمع‌آوری» و «نگهداری» کند. او بدون آنکه بداند، مفهومی ارزشمند به نام بک‌لاگ را اختراع کرده بود! بک‌لاگ‌های هیزمی، با توجه به اهدافی که انسان برای خلقشان در سر داشت، «به‌مرورزمان» خصوصیات حیاتی و ویژه‌ای به خود گرفتند: از سوختنی‌ترین چوب‌های موجود در جنگل ساخته‌شده‌اند. در میان آن‌ها چوب‌های نسوز و بی‌کیفیت دیده نمی‌شود. به‌منظور افزایش بهره‌وری و حفظ انرژی، از جمع‌آوری و شکستن چوب‌هایی که قابلیت «خوب سوختن» ندارند اجتناب می‌شود.تقریباً همه قطعات چوب موجود در بک‌لاگ به یک اندازه بریده و یا شکسته شده‌اند.قطعات «خُرد نشدۀ خیلی بزرگ‌تر» در ردیف‌های زیرین قرار می‌گیرند.هر قطعه از چوب موجود در بک‌لاگ بدون نیاز به کار و فراوری اضافه، بلافاصله قابل انداختن در آتش است. همه قطعات برای سوختن، بالقوه «آماده» هستند.برای صرفه‌جویی و استفاده حداکثری و بهینه از فضا، قطعات چوب با توجه به زوایای هندسی‌شان در کنار هم چیده و «جور» می‌شوند.خشک ماندن و «سلامت» بک‌لاگ‌های چوب به شکل مستمر بازرسی می‌شود تا از پوسیدگی و باران محفوظ بمانند.همه قطعات چوب در ابعادی که «مناسب مصرف» است بریده و خرد می‌شوند. نه آن‌قدر بزرگ‌اند که حملشان مشکل باشد و نه آن‌قدر کوچک‌اند که انرژی و «ارزش» کمی در هر واحد تولید کنند.در زمان مصرف، قطعات چوب از «بالاترین ردیف» بک‌لاگ برداشته می‌شوند. احتمالاً قادر به برداشتن قطعات زیرین نیستید.عموماً حجم بک‌لاگ‌ها به‌اندازه طول یک‌فصل سرد در نظر گرفته می‌شود و از انبار مازاد چوب پرهیز می‌شود.قطعات چوب با توجه به ابعاد دهانه و حجم اجاق خانه شکسته می‌شوند. استفاده مستقیم و بی‌واسطه از بک‌لاگ کلبه‌ای در کلبۀ دیگر به‌ندرت امکان‌پذیر بوده است.تمام‌کارهای بک‌لاگ با مشارکت تمام اعضای خانواده انجام می‌شده است. از انتخاب و جمع‌آوری چوب از جنگل گرفته تا شکستن و چیدن آن‌ها در پشت خانه! خصوصیات بک‌لاگ‌های چوبی، احتمالاً بیش از این‌هاست. ویژگی دیگری می‌شناسیم که در لیست بالا نیاورده باشم؟ به نظر می‌رسد دلیل تأکید چارچوب‌های چابک، مانند اسکرام، بر واژه بک‌لاگ برای «فهرستی اولویت‌دار از ویژگی‌های ارزش‌آفرین محصول»، اشاره غیرمستقیم و ظریف به اشتراکاتی است که با بک‌لاگ های چوبی قدیمی دارد. آیا بک‌لاگ محصول شما نیز به همان خوبی بک‌لاگ هیزمی موجود در کلبۀ اجداد قرون‌وسطایی‌مان هستند؟ فصول سرد در طول پروژه‌های توسعه محصول چه زمانی فرامی‌رسند؟آیا عدم قطعیت موجود در پروژه‌های توسعه محصول، همچنین ماهیت چرخش انتقالی پرشتاب این‌گونه پروژه‌ها و درنتیجه فرارسیدن زودبه‌زود فصول تاریک، سرد و پر چالش در آن‌ها، مؤید آن نیست که لازم است زمان بیشتری صرف بک‌لاگ‌های محصولمان کنیم؟ حتی بیش ازآنچه همکاران نوسنگی‌مان برای رسیدگی به بک‌لاگ‌های چوبی‌شان صرف می‌کردند! سهیل صمدزاده سهیل صمدزاده Mon, 30 Apr 2018 18:23:43 +0430