https://virgool.ir/feed/@asad.safariاسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاریfa2026-11-11 15:23:14https://files.virgool.ir/upload/users/13316/avatar/AD8ecB.pnghttps://virgool.ir/@asad.safarihttps://virgool.ir/@asad.safari/چرا-نباید-هر-چیزی-که-در-کتاب-و-مقالات-می-خوانیم-اجرا-کنیم-d5indwpr6ej6این روزها ما شاهد گسترش خیلی خیلی زیاد و یکباره ترجمه مطالب انگلیسی به فارسی در تمام رشته ها و بخصوص حوزه مدیریت هستیم، مطالب بسیار زیبا که کاملا به نظر اجرایی و مفید میایند. مطالبی که از دل دنیای واقعی آمدند، کارآمد هستند، و تنها کافی است ما آنها را یاد بگیریم و اجرا کنیم: مثلا چگونه به کارمندان بازخورد بدهیم، چگونه تیم بسازیم، چگونه افراد را مدیریت کنیم، چگونه در تیم ها تعامل نماییم… اما مشکل کجاست؟ مشکل اینجاست که زمینه یا فرهنگ خودمان را در هنگام اجرای این ایده‌های مترقی کاملا نادیده می‌گیریم و فرض بر این هست که هر ایده‌ای در هر جایی قرار است کار کند.یک محقق بنام ارین میییر چندین سال بر روی همین موضوع کار کرده، که مثلا آیا ایده اسپاتیفای که در کشوری مثل سوئد یک زمانی کار می‌کرد، چرا در ایران کار نمی‌کند؟ یا چرا شیوه بازخورد دادن در یک کشوری مثل آمریکا مثلا با هند بسیار متفاوت است؟ پژوهش ایشان در قالب یک کتاب به نام Culture Map ارائه شده، که ابعاد مختلف فرهنگی کشورها را در 6 جنبه مختلف بررسی کرده است. متاسفانه در این تحقیقات خیلی به ایران پرداخته نشده، اما کشورهایی هستند که بسیار از نظر فرهنگی شبیه ما هستند. قصد من در این پست این نیست که این کتاب را معرفی کنم، بلکه بیشتر می‌خواهم، با چند مثال دوستان را متوجه این داستان نمایم که چرا هر ایده قشنگی را نباید سریع بکار بگیریم.مثال اول: صریح و بدون پرده بازخورد بدهیم، توصیه درست یا غلط؟جدیدا در کشور کتابی معروف شده، که به اسم صراحت تمام عیار، که در مورد شیوه بازخورد دادن است، توصیه کتاب به صراحت بالا در بازخورد دادن است و کلی مثال هم در داخل کتاب آورده شده که به نظر ایده تمام کمالی را به ما ارائه می‌کند، اما در چه کانتسکت و فرهنگی این مثال ها کار کردند؟بگذارید همین مثال را با با پژوهش کالچر مپ بررسی نماییم. دو عنصر اساسی کالچر مپ، بحث “تعامل” و “بازخورد” است.این پژوهش از نظر تعامل کشورها را در دسته های “High Context” و “Low Context” دسته بندی کرده است: (در شکل پایین میتوانید این طیف را مشاهده کنید)در کشورهایی با فرهنگ “Low Context” ، یک تعامل و گفتگوی خوب: دقیق، ساده و روشن است. ظاهر و باطن پیام یکی است و لازم به خواندن معنی نهفته در پیام نیست. تکرار جملات اگر به شفاف سازی ارتباط کمک کند، از آن استقبال می شود، در غیر اینصورت کار بیهوده‌ای است.اما در کشورهایی با فرهنگ “High Context”، یک تعامل و گفتگوی خوب: پیچیده، ظریف و لایه ای است. پیام‌ها بین خطوط گفته شده و لابه لای همین خطوط خوانده می شوند. پیام ها غالباً ضمنی هستند و به طور واضح بیان نمی شوند. به نوعی باید پیام‌ها رمزگشایی نیز بشوند. حالا شما دقیقا تعاملات روزانه خودمان را در کار و خانه و شهر، در نظر بگیرید، ما بیشتر “High Context” هستیم یا “Low Context” ؟من زمانی این را با عمق وجود درک کردم که با تیم های خارجی کار کردم، در کارنامه کاری من 3 سال همکاری با تیم فرانسوی و تقریبا شش هفت ماهی که الان به صورت مستمر با یک تیم مستقر در بریتانیا کار می‌کنم. اتفاق جالب این بود، مثلا وقتی یکی از اعضای تیم یا مدیران بالا دستم، چیزی می‌گفتند، سعی م‌یکردم منظور آنها را رمز گشایی کنم، "منظور این چی بود؟ چرا یه همچین چیزی گفت ..." ولی بخصوص در تیم بریتانیایی، دقیقا منظور همان چیزی بود که گفته شده بود.یا مثلا من عادت کرده بودم، مقدمه چینی کنم، یک چیزی رو بیست بار تکرار کنم، که باعث سر رفتن حوصله مخاطبم میشد.یا در زاویه دیگر، از نظر جنبه “بازخورد” کشورها اینگونه دسته بندی شدند:در کشورهایی با خاصیت “بازخورد مستقیم”، بازخورد منفی به یک همکار رک و پوست کنده، صریح، صادقانه ارائه می‌شود. پیامهای منفی لازم نیست توسط پیام‌های مثبت تلطیف شوند. در هنگام انتقاد اغلب از توصیف‌های مطلق استفاده می شود (کاملاً نامناسب ، کاملاً غیرحرفه ای). اما در کشورهای آن سوی دیگر طیف، بازخورد منفی برای یک همکار به نرمی، با ظرافت و به صورت دیپلماتیک ارائه می شود. پیام‌های مثبت برای بسته بندی پیام های منفی مورد استفاده قرار می‌گیرند. در هنگام انتقاد اغلب از توصیف‌های شرحی استفاده می شود (به نوعی نامناسب، کمی غیرحرفه ای). انتقاد فقط در خلوت صورت می گیرد.دوباره بر اساس مشاهدات خودتان، ما در کدام سر طیف قرار داریم؟حالا شما این دو عنصر را در کنار هم قرار بدهید، ما در فرهنگی هستیم که “یک تعامل و گفتگوی خوب، پیچیده، ظریف و لایه ای است. پیام‌ها بین خطوط گفته شده و لابه لای همین خطوط خوانده می شوند. پیام ها غالباً ضمنی هستند و به طور واضح بیان نمی شوند” و شیوه بازخورد “بازخورد منفی برای یک همکار به نرمی، با ظرافت و به صورت دیپلماتیک ارائه می شود. پیام‌های مثبت برای بسته بندی پیام های منفی مورد استفاده قرار می‌گیرند”، چگونه ما ایده صراحت تمام عیار را بدون در نظر گرفتن شیوه تعاملی غالب فرهنگ خودمان، سریع اجرا می‌کنیم؟آیا اصلا صراحت ما، طرف مقابل حس صراحت میگیرد؟ یا دوباره در حال رمزگشایی همان بازخورد ما است؟ بدلیل اینکه در این فرهنگ تعامل بر اساس همین ایده بنا شده است.مثال دوم: از بین بردن تمام سلسله مراتب به یکباره و ساخت تیم های فلتدر این مورد نیز یک بررسی خوبی انجام شده است، طیف مربوط به سلسله مراتب یا میل به برابری خواهی در افراد:مثلا در اینجا می‌بینید، سوئد به صورت رادیکال در طیف سمت چپ در سمت “برابری طلبی” و برعکس میل به ایجاد سلسله مراتب قرار گرفته است. اما کشورهای غالبا شرق یا خاورمیانه به صورت رادیکال سمت راست قرار دارند. در فرهنگ “برابری طلبی”، فاصله ایده آل بین رئیس و زیردستان کم است. بهترین رئیس در میان افراد بیشتر نقش یک تسهیلگر دارد ساختارهای سازمانی مسطح یا فلت هستند. ارتباطات غالباً از خطوط سلسله مراتبی چشم پوشی می‌کند. اما برعکس، در فرهنگ سلسه مراتبی، فاصله ایده آل بین رئیس و زیردستان زیاد است. بهترین رئیس یک کارگردان یا گرداننده کار قوی است که از جلوی کار همه را هدایت می کند. پست و مقام مهم است. ساختارهای سازمانی چند لایه و ثابت هستند. ارتباطات از خطوط سلسله مراتبی تعیین شده پیروی می کند.من خودم چندین بار همین داستان را تجربه کردم، بعد از ایجاد تیم فلت با هزینه بالا و توافق با مدیریت ارشد، اعضای تیم که باید از این تغییر استقبال می‌کردند، بدتر، حس می‌کردند که اوضاع آشوب شده، معلوم نیست چه خبر است، دوباره دنبال نقش و مسئولیت می‌گشتند، شرح شغلی من چی هست؟ من به چه کسی باید گزارش بدهم، چرا اینجا صاحب نداره و …هدف تو از نوشتن این مطالب چه بود؟هدف من از نوشتن این مطلب منصرف کردن شما از اجرای ایده های جدید نبود و نیست، بلکه یادآوری مفهموم “کانتکست مهم هست”، اینکه هر ایده مترقی را بدون در نظر گرفتن کانکست بخواهیم اجرا کنیم، در بسیاری اوقات علاوه بر اینکه نتیجه نخواهیم گرفت، احتمالا نتیجه کاملا بر عکس چیزی که فکر میکردیم، خواهد شد.آیا شما کانفورتیست شده ای؟کانفورتیست، به کسی می‌گویند که وضعیت موجود را توجیه می‌کند، و به جای ایجاد تغییرات اساسی، دنبال حفظ وضعیت فعلی یا صرفا ایجاد تغییرات کوچک و البته کم تاثیر است.نه من، کانقورتیست نشدم، بلکه چند سالی است، که با تکیه بر اصل “کانتکست مهم هست”، سعی می‌کنم، با شناخت خوب و کافی از وضعیت موجود و کانکتکست، و تشخیص شدنی بودن تغییرات، و برنامه ریزی صرفا شیفت بعدی، شروع به تغییرات کنیم، و این یعنی شیفت مداوم و پایدار. فرض کنید، ما بخواهیم به یک قله برسیم، مسیر رسیدن به قله میتواند از مسیرهای متفاوتی باشد، یک مسیر، یک شیب بسیار تند که برای بالا رفتن آن به انرژی بسیار بالایی نیاز داریم، من که تا به حال کوهنوردی نکردم و شرایط بدنی لازم را نیز ندارم، در میانه این شیب به احتمال زیاد کم خواهم آورد، و دوباره میل به برگشت به همان نقطه قبلی خواهم داشت. اما اگر به جای این شیب تند، از مسیری می‌رفتیم، که چند استراحتگاه در مسیر نیز داشت، جایی که میتوانستیم چایی، املتی بخوریم و دوباره به راه بفتیم، احتمال رسیدن به قله بیشتر خواهد شد.چابک و موفق باشیداسد صفریاین نوشته قبلا در وبلاگ دنیای چابک با عنوان "چرا نباید هر چیزی که در کتاب و مقالات می‌خوانیم اجرا کنیم؟" منتشر شده است. اسد صفریاسد صفریSun, 25 Jul 2021 14:48:37 +0430https://virgool.ir/@asad.safari/چگونه-چابکی-از-دست-می-رود-bhmaykihnjouچند سال قبل به یک مجموعه کمک کردم تا در مسیر چابکی خود حرکت کند. در آن زمان، شرکت دچار مشکلات بسیار اساسی در حوزه منابع انسانی و کیفیت در حوزه محصولات تولیدی بود. خود این باعث ایجاد استرس بیش از حد در کارکنان و مدیریت مجموعه شده بود. اما بعد از چند ماه با انجام چند خلاقیت در حوزه فرآیند، بدهی فنی، منابع انسانی، تیم سازی و ... توانستیم تقریبا، کیفیت محصول را به حد قابل قبول برسانیم، و از نظر روابط انسانی تنش و بسیاری از مشکلات رفع شده بود. همین باعث شد که شرکت به سرعت، تعداد مشتریان خود را افزایش داده، از سوی دیگر محصولات جدیدی نیز به سبد محصولات اضافه کند. سرمایه گذارهای جدید نیز به مجموعه اضافه شدند. تقریبا شرکت از 40 نفر به 100 نفر رشد پیدا کرد. در آن زمان دیگر من از مجموعه جدا شده بودم. تقریبا بعد از 18 ماه، با افراد شرکت که صحبت میکردم، اذعان داشتند شاهد مشکلات روابط انسانی هستند و برخی از محصولات دچار چالش کیفیت شده اند یا یک سری مشکلات دیگر، مثلا با بزرگ شدن مجموعه مدیران میانی جدیدی به ساختار اضافه شدند که آنها چالش ایجاد کردند و ... . اما چرا باید چنین مشکلاتی پیش می آمد؟ چرا چابکی ثابت نمی ماند؟چند چیز چابکی را از بین می‌برد، که در زیر تعدادی از آنها را ذکر میکنم:1- وقتی یک یا چند نفر به تیم اضافه یا از آن کم شود، آن تیم یک تیم تغییر کرده نیست بلکه یک تیم جدید است.رفت و آمد زیاد نیروها، یا رشد سریع و فرآیندهای تحمیل شده به از دست دادن چابکی منجر خواهد شد. استارتاپ های موفق غالباً با این مسئله مواجه می شوند. هنگامی که یک استارتاپ به سرعت رشد می‌کند، آنها اغلب بوروکراسی و فرآیندهایی را معرفی می کنند که به چابکی صدمه می رساند. وقتی یک یا چند نفر به تیم اضافه یا از آن کم شود، نمی توان گفت این همان تیم است ولی تغییر کرده، بلکه این یک تیم جدید است. پروسه تیم سازی همانند مدل تاکمن باید برای تیم و همانطور روابط سازمانی دوباره تکرار شود. من بارها به یاد دارم، که مدیران سازمان میگفتند، ما وقتی کوچک تر بودیم، همین افراد بسیار همدل تر با هم همکاری می کردند ولی الان نه. به یاد داشته باشیم، وقتی تعداد زیادی نفرات جدیدی به سازمان اضافه می‌شود یا سازمان رشدهای بزرگی را تجربه می کند، این سازمان دیگر همان سازمان قبلی نیست و آموخته‌های قبلی دیگر این جا بدرد نمی خورند. بسیاری از یادگیری ها باید دوباره تکرار شود، فرآیندها، ساختارها و ... دوباره باید مورد بازبینی قرار بگیرند زیرا که بسیاری از موارد برای آن سازمان قبلی بودند و این سازمان جدید. 2- وقتی نشانه های خوب شدن دیده میشود، از تمرین دست برمی‌داریممن یک مادربزرگ داشتم، خدا بیامرزدش، بنده خدا علاقه خاصی به مراجعه به دکتر داشت، هر بار یک کیسه دارو میگرفت، داروها تا چند روز که حس میکرد بهتر شده، مصرف میکرد، بعد میگذاشت کنار، بعد دوباره مراجعه به دکتر. برای همین یک کیسه پر قرص و شربت مصرف نشده، همیشه برای ایشون داخل کمدشون بود. علاقه شون بیشتر مراجعه به دکتر بود.تحول سازمان یک پروژه نیست که بگوییم فلان تاریخ تمام شد. تحول یک مسیر هست که ما انتخاب کردیم در آن گام برداریم. مثلا یکی از نشانه ها اینکه، خوب به نظر دیگر همه چیز بهتر شد، آیا ما دلیلی داریم با یک مربی چابک با دستمزد گران همچنان همکاری کنیم؟ بهتر نیست به اتمام قرارداد فکر کنیم. مورد بعدی این است، که وقتی با دیدن اولین نشانه ها شما فکر می کنید، همه چیز دیگر بهتر شده، در واقع اجازه نمی دهید که تغییرات به فرهنگ سازمان بچسبند. برای مثال در مدل اجایل فلوئنسی ما برای فلوئنت شدن، در ناحیه Delivering به بیشتر از 3 تا 24 ماه زمان نیاز داریم. اما سازمان سریع اقدام به شروع محصولات جدید کرده یا اینکه اقداماتی از نظیر رفاکتور کردن بخشهایی را متوقف کرده بود. سازمان اشاره شده، در ابتدای شروع تحول، سرمایه گذاری خوبی از نظر حمایت انجام داده بود، اما بعد از چند ماه و دیدن اولین نتایج و جدا شدن مربی، با این دید که دیگر همه چیز خوب شده است، تمام اقدامات پیش بینی شده بهبود را کنار گذاشته بود.اما آنها باید چه کار بکنند؟مسلما، دوباره باید همه چیز مورد بازنگری قرار بگیرد همانند یک سازمان جدید. یک برنامه برای تحول چابک چیده شود اما این بار باید هوشیار تر باشند که قرار نیست با دیدن نشانه ها یا رشدها، برنامه های بهبود را کنار بگذارند و درگیر فرآیند اجرای کار روزانه بشوند. جمع بندی: 1- تحول یک پروژه نیست، بلکه یک سفر به سمت مقصد مشخص است. تحول مستمر چیزی است که نباید آن را فراموش کرد. سازمان همیشه در حال تغییر است، پس تحول مستمر نیز در جریان باید باشد. 2- با دیدن نشانه های اولیه نباید فرض کنیم که تحول تمام شده است و اقدامات بهبود را کنار بگذاریم چون در این صورت دوباره مشکلات خودشات را نشان خواهند داد. 3- وقتی تیم یا سازمان بزرگ می شود، افرادی به آن اضافه می شوند، این دیگر همان سازمان قبلی نیست، پس بسیاری از چیزهایی که قبلا کار میکردند دیگر کار نخواهند کرد، بسیاری از موارد مانند ساختار، شیوه کاری و ... به صورت مستمر باید مورد بازنگری قرار بگیرد. چابک و موفق باشیداسد صفریاسد صفریاسد صفریThu, 05 Nov 2020 14:53:36 +0330https://virgool.ir/@asad.safari/نحوه-ارزیابی-عملکرد-تیم-های-چابک-m9pvnjedizw9انتهای اسپرینت چهار بود و جلسه بازبینی اسپرینت را انجام داده بودیم، زنگ تلفن به صدا در آمد، مدیر ارشد واحد ایران پشت خط بود.-“سلام، خوبی اسد؟”-“سلام، ممنون مهندس، شما خوبی؟”-“…اسپرینت تون خیلی عالی شده بود” (به حالت ذوق زده)-“چطور مهندس؟”-“جیرا رو چک کردم، Velocity بالاتر رفته بود، خیلی عالی، همینجوری ادامه بدید…”ما هم ذوق کردیم از تعریف و تمجید مهندس. آخر اسپرینت پنجم شد و یک بخشی از کارها باگ داشت یا بخشی از شرایط پذیرش مالک محصول محقق نشده بود. مالک محصول اصرار داشت که این ها را نپذیرد، و بالطبع امتیاز این آیتم ها به تیم تعلق نمی گرفت و تقریبا Velocity تیم نصف می شد. اما برای اینکه مهندس خوشحال بشه، التماس به مالک محصول که “تو رو خدا این ها را قبول کن و برای باقی مانده یک آیتم جدید تو جیرا ثبت می کنیم”.اتفاقی که از اسپرینت بعد ادامه داشت، Velocity بالا بود و مهندس خوشحال، و تمام تلاش تیم برای خوشحال نگه داشتن مهندس بود و چیزی که برای تیم مهم نبود شرایط پذیرش مالک محصول و نیاز واقعی مشتری ها بود.این داستانی که گفتم، تجربه واقعی ما از پروژه ای بود که قبلا اینجا در مورد آن نوشتم.یکی از سوالات همیشگی دوستان این است که چگونه تیم ها را ارزیابی کنیم؟ از چه شاخص هایی برای ارزیابی عملکرد نفرات یا تیم استفاده کنیم؟ یکی از محبوبترین این شاخص ها در تیم های چابک Velocity است. اما Velocity چه مشکلی دارد؟ و بهتر است از چه شاخص هایی استفاده کنیم؟علاوه بر داستان اولیه (منحرف کردن تیم از تمرکز بر روی مشتری و نیاز واقعی) یکی دیگر از مشکلات اندازه گیری Velocity بالا رفتن تخمین ها است. بدلیل اینکه Velocity یعنی رضایت ذی نفعان، پس عداد یا امتیازهایی که به کارها به عنوان تخمین داده میشد نیز به مرور افزایش پیدا می کرد.واقعیت در مورد اندازه گیریمردم را هر طوری اندازه بگیرید، همانگونه رفتار خواهند کردیابه من بگو که چگونه من را اندازه خواهی گرفت، تا بگویم چگونه رفتار خواهم کرددر یک کارخانه تولید میخ، گفتند پاداش بر اساس وزن میخ تولیدی خواهد بود، اندازه میخ های افزایش پیدا کرد. گفتند، پاداش بر اساس تعداد میخ ها است، اندازه میخ ها کوتاه تر شد ولی تعداد بالاتر رفت. مردم را هر طوری اندازه بگیرید، همانگونه رفتار خواهند کرد، پس خیلی مهم است که چه چیزی را اندازه بگیرید.اما واقعا در تیم توسعه چه چیزی را باید اندازه بگیریم؟یکی از قوانین مهم در تعیین شاخص اندازه گیری، یک بعدی نبودن آن است. یعنی با ارزیابی تنها یک شاخص، شما معمولا چیز خوبی بدست نخواهید آورد. در اینجا اصلا قصد من این نبود که بگویم Velocity بد است یا خوب.ولاسیتی - Velocity را می توان اندازه گرفت، می توان به عنوان شاخص از آن استفاده کرد، ولی به تنهایی کافی نیست.Output و Outcomeاوت پوت - Output یعنی میزان خروجی و Outcome (برآیند) میزان تاثیر کار. اگر تیم خروجی محور باشد، در نهایت تعدادی قابلیت تولید خواهند کرد که اهمیتی به مصرف یا تاثیر آن بر مشتری و بازار ندارند و صرفا در فکر افزایش سطح تولید هستند(کارخانه کلوچه سازی)، برآیند محور بودن بدنبال حداکثری سازی تاثیر خروجی بر روی بازار یا مشتریان است، شاید همان شعار قابلیت کم ولی تاثیر بیشتر.یک نکته مهم در مورد اوتکام یا برآیند این است، این برآیند حس و ذهنیتی است که کاربر یا مشتری نسبت به استفاده از خروجی شما خواهد داشت. در واقع شما نمی توانید آن را دستکاری کنید، تنها کاری که می توانید انجام بدهید این است که به نیازهای اساسی کاربر/مشتری توجه داشته باشید که با ارائه خروجی درست و به موقع و گرفتن بازخورد، بتوانید برای او برآیند مطلوب را خلق کنید..ارزش محور بودن به جای خروجی محور بودننرم افزار قابل استفاده اصلی ترین معیار سنجش پیشرفت استهمانطوری که در اصول بیانیه چابک خواندیم، اصلی معیار سنجش پیشرفت، نرم افزار قابل استفاده است. نرم افزاری که مشکل کسب کار یا مشتری را رفع کند. نرم افزاری که راه حل باشد نه اینکه سوپی از قابلیت ها.خیلی از نرم افزارهایی که ما می بینیم بیشتر شبیه یک سوپ یا آش هستند که همه چیز داخل آن ها است.اما چگونه در عمل میتوان توجه تیم را به سمت نرم افزار قابل استفاده برد؟یکی از روش هایی که در همین تیم استفاده کردیم، اضافه کردن یک فیلد با عنوان ارزش تجاری در جیرا بود، این فیلد توسط مالک محصول پر میشد. با توجه به این تغییر یکی از معیارهای تیم، تولید بیشترین ارزش تجاری در هر اسپرینت بود(البته توجه کنید که گفتیم یک بعدی نباید سنجش کنیم). شاید Velocity بالا رفته باشد ولی ارزش تجاری پایین بود، پس اوضاع تولید ما خوب نیست.وقتی Velocity و Business Value در کنار هم قرار می گیرند، می توانند باعث ایجاد تعادل Output و Outcome شوند.البته به غیر از اینها، شاخص های دیگری نیز هستند، مثلا تعداد باگ در هر نسخه، متریک های آنالیز کد(مثل کدهای تکراری)، Lead Time، انحراف تخمین و …، قبلا از استفاده از هر کدام باید در نظر بگیرید که هیچ یک از اینها به تنهایی کار نمی کنند و در نظر بگیرید که مردم را هر طوری اندازه بگیری همانطور رفتار خواهند کرد.چابک و موفق باشیداسد صفریاین نوشته قبلا در وبلاگ دنیای چابک منتشر شده بوداسد صفریاسد صفریMon, 28 Sep 2020 10:54:18 +0330https://virgool.ir/IranAgile/چگونه-داستان-کاربر-بنویسیم-مثال-از-تورم-کشور-rbalqrunxea7یک دوستی از من خواست که داستان‌های کاربری که نوشته بود را بررسی کنم، دیدم همه چیز را در قالب معروف User Story نوشته، و بیشتر از کارکرد و نیت اصلی داستان کاربر، فقط حواسش به قالب آن بوده است. بیشتر در قید فرم بوده تا محتوا. داستان کاربر یک مفهوم خیلی ساده است، که ما کار را از منظر و چشم کاربر نگاه کرده و در تلاشیم تا نیاز اساسی او را رفع نماییم. یک قالب ساده نیز مانند نمونه زیر دارد. اما در عین سادگی، بسیاری از دوستان در استفاده از همین مفهوم اشتباه می کنند. بعنوان ___________(کاربر/مشتری/پرسونا)میخواهم ______________ (یک قابلیت/امکان/فیچر)تا بتوانم ________________ (نیاز/دلیل/برآیند مورد انتظار) در همین راستا، خواستم مفهوم واقعی داستان کاربر یا همان User Story را به او توضیح بدهم، دیدم ذهنش کلا درگیر تورم و وضعیت اقتصادی کشور هست، گفتم شاید بد نباشد که از همین به عنوان مثال واقعی استفاده کنیم. از او پرسیدم "به نظرت مردم چرا می ریزن ماشین، دلار، سکه و ... ثبت نام می کنند؟" جواب داد: "با این بی ارزش شدن پول، نگران هستند خوب..." گفتم: "پس داستان این کاربر ما با همان فرمتی که خودت نوشتی، چی میشه؟"بعنوان کسی که نگران ارزش پولش هست (پرسونا)من دلار میخرم (چیزی که میخواهد یا انجام میدهد)تا بتوانم ارزش موجودی خودم را حفظ کنم و فقیرتر نشوم (دلیل و چرایی یا برآیندی که دنبالش هست)حالا فرض کنید، دولت مثل تیم های فنی، به نیاز کاربر اهمیتی نمی‌دهد، و امور را از نگاه خودشان بررسی می‌کنند (تیم های فنی به همه امور فنی نگاه می کنند). در همین مثال، بانک مرکزی، یک نیازمندی تعریف می‌کند، بعنوان بانک مرکزیما خرید و فروش دلار رو محدود به 2000 دلار در سال می کنیمتا بتوانیم بازار ارز را کنترل کنیمدقیقا قالب داستان کاربر رعایت شده، اما به نیاز کاربر اصلی توجهی نشده و بیشتر به خودشان پرداخته اند، مثل اینکه تیم دیتابیس، نگران حجم دیتابیس است و برای همین اجازه نمی‌دهد که رکورد جدیدی ثبت شود. در مثال خودمان، این محدودیت باعث خواهد شد که کاربران ما دست به اقدام دیگری بزنند:بعنوان کسی که نگران ارزش پولش هست (پرسونا)من طلا و سکه میخرم (چیزی که میخواهد یا انجام میدهد)تا بتوانم ارزش موجودی خودم را حفظ کنم و فقیرتر نشوم (دلیل و چرایی یا برآیندی که دنبالش هست)اگر توجه کنید، نیاز همان است، ولی اقدام تغییر پیدا کرد. اگر طلا و سکه مسدود شود، چون نیاز هنوز برطرف نشده، شاهد اقدامات دیگر خواهیم بود.عدم درک درست نیاز و مشکل مشتری باعث خواهد شد تا تصمیم های ما اشتباه باشند، مثلا در یک جلسه بگوییم، بعنوان سیستم حاکمیتیمی‌خواهیم بر عایدی درآمد مالیات تعیین کنیم تا با سود جویان و دلالان مقابله کنیم (اینکه مالیات اصلا بد نیست، ولی آیا همه دلال هستند) در واقع، از داده های موجود برداشت اشتباه انجام داده ایم، کار مدیر محصول تشخیص نیاز اصلی است. آیا عمده مردمی که طلا/دلار/ و ... می خرند دنبال یک شب پولدار شدن و دلالی هستند یا حفظ ارزش دارایی؟ تشخیص این کار مدیر محصول است. تا زمانی که ما نیاز اصلی کاربر یا مشتری را درست تشخیص ندهیم، اقدامات یا قابلیت هایی که ارائه می‌کنیم، اثر بخش نخواهند بود. حالا چه در قالب "بعنوان ___ می خواهم ___ تا بتوانم___" بنویسم یا Use Case یا هر اسم دیگری، کاربران با همان روش هایی که بلد هستند کار خود را به پیش خواهند برد و آن قابلیت و اقدام ما بی استفاده خواهد ماند. از کجا مشکل یا نیاز واقعی را کشف کنم؟واقعیت این است که ما علاقه داریم، در اتاق خود بنشینیم و با فرضیات خودمان شروع کنیم به طراحی راه‌حل. اما برای درک مسئله، ما باید وارد فضای مسئله بشویم و فضای مسئله جایی نیست جز کف بازار. نمی‌شود، در اتاق های خودمان باشیم، با صاحب مسئله صحبت نکنیم و با دردهای او همدلی نکرده باشیم و فرض کنیم مشکل را درک کردیم، به همه بگوییم دلال و سفته باز و بر اساس آن راه حل طراحی کنیم. در این مسیر نیز ما امکان دارد با خطاهای شناختی مواجه بشویم، مثلا پخش یک ویدئو در فضای مجازی، اینکه مردم هجوم آوردن تا دلار بخرند، شاید ما را با این خطا مواجه کند که همه اینگونه هستند(تعمیم دادن یا Over-generalization) یعنی با یک دیتای کم نتیجه گیری کنیم. یا صرفا دنبای داده هایی بگردیم که فرضیات ما را تایید کنند(خطای میل به تایید (Confirmation Bias))، دیدی گفتم مردم همه دلال شدند.نصف بیشتر داستان کاربر، درست دیدن، همدلی کردن، فهمیدن، و تعریف کردن نیاز و مسئله کاربر است. اگر این را درست تعریف کنیم، راه حل پدیدار خواهد شد. پس، لطفا در بند قالب و تمپلیت گیر نکنیم و به درد و نیاز اصلی در فضای مسئله باشیم.مثال دیگری از داستان کاربر در فضای توسعه نرم افزارچابک و موفق باشیداسد صفریاسد صفریاسد صفریFri, 24 Jul 2020 20:39:27 +0430https://virgool.ir/IranAgile/اسکرام-مستر-باهوش-ناامید-نمی-شود-czivxlehuhm5اینترنت شرکت به شدت مشکل داشت و دائم قطع و وصل میشد، یا کلا کند بود، در این لحظات اکثر بچه ها به مشکل میخوردند، یا حتی باید دست از کار می کشیدند. در جلسات رترو انتهای اسپرینت چند بار این بعنوان مانع مطرح شد.من بعنوان نماینده تیم، این رو چندین بار با شرکت و مدیران مطرح کردم، ولی ترتیب اثری داده نشد، و موضوع چندین اسپرینت ادامه داشت.حس کردم مدیران نسبت به اتلاف و هزینه این اتلاف آگاهی ندارند، و تصمیم گرفتم این اتلاف را تابلو یا بصری سازی کنم.در ابتدای اسپرینت، از همه بچه در خواست کردم، تعداد دقایقی بخاطر نبودن اینترنت بلاک می شوند، را لاگ بزنند. در انتهای اسپرینت این لاگ ها رو جمع کردم، بعد تبدیل به پول کردم. متوسط حقوق ساعتی ضربدر میزان جمع ساعت تلف شده.مثلا در اسپرینت 13 شد 8000 دلار، بعد رفتم یک سایت فروش خودرو دست دوم و ماشین های 8000 دلاری جستجو کردم و یکی رو انتخاب کردم.عکس ماشین رو پرینت کردم و زیرش زدم، “این اسپرینت ما این ماشین رو آتیش زدیم :cry:” و این رو بر روی تابلوی اسپرینت تیم چسباندیم.هر زمانی که مدیری میخواست از تیم ما بازدید کنه، با دیداین عکس ها بسیار تعجب میکرد و دقیقا از همان اسپرینت ها، کم کم، مشکل سرعت اینترنت بهتر شد.شاید خیلی وقت ها به این برمیخوریم: افراد غر میزنند که شرکت و مدیران به فلان درخواست یا مشکل ما اهمیت نمی دهد، اما برخی مواقع با یک تکنیک درست بصری سازی یا تابلو کردن اتلاف یا مشکل، شما می توانید در آنها آگاهی ایجاد کنید. و آگاهی نصف حل کردن مشکل هست.منبعاین نوشته قبلا در وبلاگ دنیای چابک نیز منتشر شده بود. اسد صفریاسد صفریTue, 21 Jul 2020 16:27:27 +0430https://virgool.ir/IranAgile/چرا-گوگل-یا-شرکتهای-مشابه-از-اسکرام-استفاده-نمیکنند-ولی-همچنان-موفق-هستند-tfvgvdsaenmsبا یکی از دوستان در مورد چابک و اسکرام صحبت می‌کردیم، سوال پرسید چرا هیچ وقت نمی‌شنویم که شرکتهایی مثبت گوگل یا نتفلیکس از اسکرام استفاده کنند، یا حتی اگر استفاده کنند اصلا اصراری بر روی آن ندارند. (برعکس شرکتهایی کوچک که در تمامی آگهی استخدام تاکید دارند، آشنایی با اسکرام و … )به نظرم رسید که این سوال خوبی هست و جوابش می‌تونست برای همه جذاب باشه. برای همین تصمیم گرفتم نوشته کوچکی در این خصوص بنویسم.در کتاب اسپرینت، آقای جیک نپ (کارمند اسبق گوگل) یک جمله جالب در مورد گوگل دارد: “گوگل، آزمودن را ترغیب می‌کند، آزمودن نه تنها در مورد خود محصول، بلکه در زمینه روش‌های به کار رفته توسط افراد و تیم‌ها”وقتی تصویر یک کارمند از یک شرکت “دعوت به آزمودن باشد”، یعنی در مورد فرهنگ غالب آنجا صحبت می‌کند. یک سوال اساسی، آیا نهایت چابک بودن و هدف از اسکرام مگر همین نیست؟ در واقع اگر ما خوب بتوانیم فرهنگ چابک را جا بیندازیم، به چنین دستاوردی خواهیم رسید.سوال دوم، پس چرا ما مانند گوگل ابتدا به دنبال فرهنگ یا تغییر شیوه فکری حرکت نکنیم؟یک نقل قول از آقای باکمینستر فولر هست با مضمون، “اگر می‌خواهید به مردم روش جدیدی برای اندیشیدن بیاموزید، لازم نیست زحمت آموزش دادن آن را متحمل شوید. در عوض، به آنها ابزاری بدهید که استفاده از آن، به استفاده از روش جدید اندیشیدن منجر شود.”در واقع، اسکرام ابزاری برای تمرین تفکر چابک هست، که مبتنی بر آن تفکر طراحی شده است. بودن نقشی مثل اسکرام مستر نیز برای تضمین این هست که آیا ما صرفا یک ابزار داریم، یا ابزاری داریم که به قول آقای فولر،استفاده از آن، به استفاده از روش جدید اندیشیدن منجر می‌شود.اما چرا شرکت‌های مثل گوگل از این ابزار برای این تمرین استفاده نمی‌کنند؟وقتی شالوده و بنیان یک شرکت بر اساس این تفکر بنا نهاده شده باشد، خود این بهترین ابزار است و ناخودآگاه تمام اقدامات بر اساس این فلسفه اجرا خواهد شد.پس در واقع با اینکه فقط تکرار کنیم که تفکر جدید باید ایجاد شود، کاری از پیش نخواهد رفت، آموزش، نصحیت، سخنرانی، تاثیر چندانی نخواهد داشت. ابزارهایی لازم داریم که بر اساس این تفکر طراحی شده باشند و ما این تفکر را روزانه تجربه کنیم. اما شرکت‌هایی که تفکر در آن نهادینه شده باشد، دیگر نباید نگران ابزار باشند.ما سالها اسکرام استفاده کردیم ولی خبری از تفکر چابک نیست؟شاید تعدادی دوستان در اعتراض به نوشته بیان کنند، که ما سالها درگیر اسکرام بودیم و خبری از تفکر چابک نبود. دو نکته اساسی هست، یک اینکه، تنها ابزار شما برای تمرین تفکر و اندیشه چابک نباید صرفا اسکرام باشد، نکته دوم، وجود نقشی مانند اسکرام مستر یا مربی چابک، برای این هست که ابزار مناسب را برای تیم خود بر اساس کانتکست مربوطه پیدا کرده یا حتی آن را بسازند. متاسفانه بسیاری از اسکرام مسترهای ما بدلیل تجربه کم خودشان یا شرایط شرکت، صرفا تبدیل شدن به منشی یا کنترل پروژه، و توجهی به ابزاری فکر و تمرین تفکر چابک ندارند یا صرفا دست به دامن آموزش یا نصحیت کردن می شوند که از سوی اعضای تیم همه اینها تئوری تلقی خواهد شد یا اینجا بدرد نمی‌خورد.برای مثال، با یک تیمی برای مدت محدودی کار می‌کردم، بارها مدل پیچیدگی، و عدم قطعیت را توضیح داده بودم، ولی همچنان در جلسات برنامه ریزی بدنبال تخمین زدن با قطعیت بالا بودند. من هر چقدر تلاش کردم که با گفتن مفهوم را منتقل کنم، ناموفق بود. در حرف همه قبول داشتند ولی در مقام عمل، کار دیگری می کردند. مجبور شدم ابزارهایی مثل تابلوی تخمین و ابزار برنامه ریزی بر اساس پیچیدگی را خلق کنم. کار با این ابزارها باعث شده بود، تیم درک عملی نسبت به تفکر پیچیدگی و عدم قطعیت داشته باشند.تجربه شما در ساخت یا استفاده از ابزارها برای ایجاد تفکر چابک، چه بوده است؟چابک و موفق باشیداسد صفریاین نوشته قبلا در وبلاگ دنیای چابک نیز منتشر شده است. اسد صفریاسد صفریMon, 22 Jun 2020 10:43:14 +0430https://virgool.ir/IranAgile/دو-روش-برون-سپاری-پروژه-های-نرم-افزاری-در-عمل-unamm2suskdbدر یک ماه اخیر به صورت اتفاقی با دوستان زیر مجموعه بانک مرکزی و یک سری دوستان از اپراتورهای رسمی کشور صحبت می کردم. یکی از چالش هایی که مطرح می کردند همکاری با شرکت هایی است که پروژه‌های نرم افزاری یا مخابراتی به آنها سپرده شده است اما در تعامل و همکاری با چالش های بزرگی مواجه هستند. یکی از چالشها این بود که چگونه ما هم چابک باشیم و هم بتوانیم یک قرارداد به صورت رسمی بین طرفین نوشته شود.در پروژه های چابک به صورت پیش فرض ما پذیرای تغییرات هستیم تا با پاسخگویی به این تغییرات از نوسانات بازار یا رقابت باز نمانیم. اما شرکتی که پروژه برون سپاری شده را پذیرفته است برای خود برنامه دیگری دارد و سود آنها معمولاً جاییست که سریعتر پروژه مذکور را به اتمام برساند و سراغ پروژه های دیگر بروند.پس عملاً یک تضاد منافع بزرگ در اینجا وجود دارد یکی از طرفین به دنبال بستن سریع پروژه است، طرف دیگر بدنبال رفع نیاز خود است، چه نیازهایی که از قبل مشخص شده است و چه نیازهایی که بعدا معلوم می شود. از سوی دیگر ساختار حقوقی شرکتها اجازه نمی‌دهد که قراردهای باز ببندند.همین یک دلیل ساده باعث شکست خوردن اکثریت پروژه های برون سپاری شده است. برای حل این مشکل اکثر شرکت ها متوسل به قراردادهای ترکمنچای می‌شوند. یک واحد حقوقی خیلی‌قوی قراردادی را تنظیم می کند که آن مجری پروژه نتواند از زیر هیچ تغییری در برود و از سوی دیگر آن شرکت نیز، با تفسیر بندهای قرارداد که منظورش این نبود یا ما این را پیاده سازی کردیم به دنبال این است که دعوای حقوقی را به پیش ببرد. حالا یک سری شرکت هم دوره های آموزشی “مدیریت ادعا” به مردم یاد می‌دهند.عملاً دور و بر خودتان را نگاه کنید یک پروژه مشخص دومین یا سومین بار است که به شرکت‌های مختلف برون سپاری شده است. یا حتی پروژه برون سپاری با مفاد قرارداد توافق شده وسر زمان نیز تحویل داده شده، ولی عملاً نیاز فعلی کسب و کار را برطرف نکرده است.چرا شرکت‌ها به دنبال برون سپاری پروژه های نرم‌افزاری هستند؟یکی از دلایل بسیار مهم برون سپاری پروژه های نرم افزاری دشوار بودن یا پرهزینه بودن نگهداری تیم های نرم‌افزاری است. باید قبول کنیم که جذب و نگهداری و جلو بردن تیم های نرم افزاری کار بسیار دشواری است و هم از نظر نفراتی که در آن تیم ها وجود دارم هم از نظر پیچیدگی تکنولوژی.بسیاری از شرکت ها قبل از برون سپاری، تیم‌های داخل سازمان داشتند ولی به دلیل اینکه پروژه ها جلو نمی‌رفت فکر کردند که با برون سپاری می توانند سرعت دریافت خروجی ها را بالا ببرنند. عملاً زمانی که شما پروژه را برون‌سپاری می کنید ریسک انجام نشدن کار (چه از نظر ابعاد تکنولوژی یا مسائل منابع انسانی یا …) یا سرموقع انجام نشدن آن را، برون سپاری کردید و عملاً مجری این ریسک را قبول کرده است.اینکه ما نیروی برنامه نویس با تجربه چندانی نداریم چون تعداد زیادی از این بچه‌ها مهاجرت کرده‌اند و یا موارد این چنینی، دیگر ریسک شما نیست و ریسک شرکتی است که این پروژه را قبول کرده است.اما با این حال که پروژه و ریسک آن به شخص ثالث سپرده شده است ولی همچنان شرکت نتایج مطلوب خود را دریافت نمی کند، چه از نظر پیشرفت پروژه یا از نظر برآورده شدن نیازها.برای همین بسیاری از شرکت‌ها به فکر افتادند که دوباره تیم های نرم افزاری خود را ایجاد کنند و به جای برون سپاری از استراتژی درون سپاری بهره بگیرند.مدل برون سپاری ها باید تغییر کندشما در برون سپاری پروژه های نرم افزاری باید یک اصل طلایی را بخاطر بسپارید:هسته اصلی یا مزیت رقابتی کسب و کار خود را به هیچ وجه برون سپاری نکنید، تیمی منسجم و با انگیزه دور این مزیت رقابتی ایجاد کنید و با تمرکز بالا خلاقیت کنید، آن رابسازید، تحویل داده فیدبک بگیرید و دوباره اصلاح کنید و …. اما هر چیز به جز آن را برون سپاری کنید، بگذارید بر روی اصل داستان متمرکز باشید.مثال کاربردیبرای اینکه این مثال را با هم چک کنیم، فکر کردم مدل نقشه واردلی می‌تواند به ما در درک اصل طلایی برون سپاری کمک کند.تصویر بالا نقشه واردلی را نمایش میدهد. این نقشه در واقع دو بعد اساسی دارد، بعد جریان ارزش (اینکه اجزای یک سیستم با هم کار می کنند تا یک ارزش را به مشتری یا کاربر برسانند)، بعد تکامل (هر جزء سیستم، یک چرخه تکامل دارد).در نقشه واردلی، به جای اینکه در مورد یک سیستم به صورت کلی صحبت شود، آن را به اجزای مختلف می‌شکند(کامپوننتایز) و در مورد هر جزء جداگانه تصمیم گیری می شود. اصلی ترین نکته نقشه واردلی، در واقع این هست که هر جزء اولین بار در چرخه پیدایش بوده، افراد کمی با آن آشنا هستند یا به آن دسترسی دارند، اما به مرور و با گسترش استفاده کم کم به چرخه انتهایی یا کالایی شدن پیش خواهد رفت. (عکس زیر را مشاهده کنید)تلفن را فرض کنید. یک روز فقط در آزمایشگاه بود، کسی اصلا نمی دانست چیست؟ اینکه مردم آیا نیاز دارند، شک داشتند، درک درستی از چیستی آن نبود – به چه دردی می خورد؟ عدم قطعیت بالا ، پیش بینی پذیری بسیار پایین (پیدایش). بعد یک سری شرکت یا افراد پولدار صاحب تلفن شدند، کم کم افراد نحوه استفاده از آن را درک کردند – بازار در حال شکل گرفتن … (سفارشی). در گام بعدی، به سرعت تعداد استفاده کننده ها بیشتر شد، تقریبا اکثریت جامعه به آن دسترسی داشتند، شرکتهای ارایه کننده خدمات نیز بیشتر شد، رقابت بر روی خدمات بیشتر شد، انواع گوشی تلفن عرضه می شد (محصول) و در گام نهایی اینقدر در دسترس بود که هر کسی تلفن نداشت جای تعجب داشت، همه می دانستند تلفن چیست، آن را پذیرفته بودند و تقریبا از نظر تکنولوژی به بلوغ و ثبات رسیده است (کالا).همین نقشه تکامل را در مورد فالکون شرکت اسپیس ایکس در نظر بگیرید، وقتی اولین پرتاب برای ناسا انجام شد، یعنی وارد حوزه سفارشی شد. در مرحله بعدی تعداد شرکتهایی مثل اسپیس ایکس بیشتر خواهد شد و این محصول پرتابگر را در بازار ارائه خواهند کرد (محصول)، و شاید یک روزی بسیاری از مردم بلیط بخرند و از آن استفاده کنند (کالا). (کسب و کار ناسا پرتاب نبود، آن را برون سپاری کرد، و بر روی کسب و کار اصلی خود تمرکز کرد.)مثال واقعی یک شرکت بورسیفرض کنید، یک شرکت بورسی، بنابر افزایش تقاضا در بازار سرمایه، میخواهد برای سرعت بخشیدن و گرفتن سهم بازار، به سمت معاملات الگوریتمی حرکت کند. به صورتی که با طراحی و ارائه الگوریتمهای معامله بازار را قبضه کند به نوعی که این در بلند مدت مزیت رقابتی این شرکت بورسی شود. اما به فکر این است که این پلتفرم را برای سرعت بخشیدن در توسعه به یک شرکت دیگر برون سپاری کند. اما مدیر فنی آنها، به صورت اتفاقی این نوشته را مشاهده می‌کند، و تصمیم می‌گیرد، اصل طلایی را در برون سپاری رعایت کند. او با کشیدن نقشه واردلی کار خود را شروع می نماید. (همانند شکل زیر)نقشه واردلی، ابتدا از کاربر و نیاز او شروع می کند، کاربر بدنبال چه چیزی است؟مدیر فنی ما شروع کرد، به استخراج کردن کامپوننت ها یا اجزای سیستم. برای برآورده کردن نیاز کاربر، چه اجزایی باید وجود داشته باشند.در ادامه از نظر تکامل، هر کدام از اجزاء را در ستون خود قرار داد.اکنون نوبت انتخاب برای درون سپاری و برون سپاری بود. (همانند شکل زیر)بخش کالا، در واقعی جایی هست که اصلا نیازی نیست ما در مورد آنها دغدغه داشته باشیم. بخش محصول، جایی هست که محصولاتی در بازار وجود دارند که ما باید آنها را پیدا کنیم برای خریداری یا اجاره.اما جایی که ما نیاز به تیم توسعه داریم، بخش سفارسی و پیدایش هست. حالا بر اساس تخصص های این حوزه شروع به استخدام نفرات و متخصصین کرد.اگر خود پلتفرم برون سپاری می شد، چه اتفاقی می‌افتاد؟هر روز، یک الگوریتم جدید باید توسعه داده شود و هر الگوریتم نیازمندی خود را دارد، هر الگوریتم موجب تغییر در خود پلتفرم خواهد شد. حالا فکر کنید، شما این حجم تغییرات را به یک شرکت دیگر بسپارید؟ در بهترین حالت که آنها راغب به انجام این تغییرات نیز باشند، چندین مدت طول خواهد کشید که آنها این تغییرات را اعمال کنند … و دوباره تغییرات… با این اوصاف واقعا این می تواند باعث ایجاد مزیت رقابتی برای این شرکت شود؟اما فکر کنید، یک تیم با انگیزه بر روی این پلتفرم کار کنند، خود آنها از کاربران بازخورد بگیرند، اصلاح کنند، دوباره نسخه جدید و …سخن پایانیبرون سپاری پروژه های نرم افزاری بشدت در ایران با چالش مواجه شده است. بهترین شیوه این است که شرکتها در استراتژی برون سپاری خود تجدید نظر کنند. نه به این معنی که دیگر برون سپاری نکنند. اما آنچه برون سپاری می کنند را تغییر بدهند.هسته اصلی یا مزیت رقابتی کسب و کار خود را به هیچ وجه برون سپاری نکنید، تیمی منسجم و با انگیزه دور این مزیت رقابتی ایجاد کنید و با تمرکز بالا خلاقیت کنید، آن رابسازید، تحویل داده فیدبک بگیرید و دوباره اصلاح کنید و …. اما هر چیز به جز آن را برون سپاری کنید، بگذارید بر روی اصل داستان متمرکز باشید.چابک و موفق باشیداسد صفریاین نوشته قبلا در این آدرس منتشر شده بود اسد صفریاسد صفریSat, 13 Jun 2020 12:07:01 +0430https://virgool.ir/IranAgile/اسکرام-چیست-h8byhzxo7rslدر این چند سال تجربه کاری، در صنعت های مختلفی کار کردم، از جمله بانک، بورس، شرکتهای استارتاپی و … . یک الگو تکرار شونده اکثرا در همه این شرکتها بود که یک جنس یا یک طیف خاصی از پروژه معمولا شکست می خورند یا حداقل چالش زیادی داشتند. برای مثال پروژه های IT یا توسعه یک نرم افزار جدید از این دست پروژه بودند.یادم هست در یک شرکت بانکی بزرگ و دولتی، قرار بود یک نرم افزار مدیریت املاک و مستقلات تولید شود تا بتوان لیست جامعی از املاک و مستغلات درست کرد با هدف مدیریت بهینه مستغلات بانک و تصمیم گیری درست درخصوص شرایط نگه داری یا واگذاری املاک. مثلا شاید یک بانک بزرگ در یک گوشه از کشور یک ملکی دارد که آن اجاره داده شده است، اما سالها فراموش شده و شاید هم از آن سواستفاده می شود، یا در سالهای اخیر فشار زیادی بر روی بانک ‌ها هست که املاک خود را واگذار کنند، اما کدام ملک باید واگذار شود؟ این باعث شد که نیاز به یک نرم افزار جامع مدیریت املاک حس شود.یک پروژه بنام مدیریت جامع املاک در آن بانک معظم تعریف شد و یک تیم نرم افزاری کار را بر روی آن شروع نمود.در واقع بنابر مدل آبشاری همانطور که در شکل زیر مشاهده می کنید، پیش فرض اصلی تیم بود. این مدل آبشاری دو فاز اساسی دارد: فاز اول، برنامه ریزی شامل : گرد آوری نیازمندی، تحلیل نیازمندی ها و طراحی، که در این فاز ابتدایی ما وارد اجرا نمی شویم و خروجی این فاز بیشتر مستندات و خوراک فاز بعدی است. در فاز بعدی، ما وارد فاز اجرا و نظارت و نهایتا تحول خواهیم شد.علتی که به این مدل آبشاری گفته می شود این است که، خروجی هر مرحله برای بخش بعدی قطعی هست و همانند یک آبشار که آبی که از بالا به پایین میریزد قابل بازگشت نیست، خروجی نیز قابل برگشت نیست.در همین پروژه ذکر شده، کلی دوستان تحلیلگر شروع به جمع آوری نیازمندی ها کردند، برای همین منظور مجبور شدند با دایره مربوطه در بانک جلسات مصاحبه داشته باشند و … . پس از جمع آوری نیازمندی های ، آنها به زبان قابل فهم نیروهای فنی تحلیل و طراحی شده و در قالب سندهای تحلیل-طراحی بدست برنامه نویس ها رسید. (این پروسه شاید ماهها به طول انجامید). در ادامه چندین ماه دیگر نیز ادامه داشت تا پیاده سازی اتفاق بیفتد، بعد از پیاده سازی، تیم تست با استفاده از سندهای تحلیل شروع به تست کرد، و بعد اینکه مطمئن شدند که خروجی پیاده سازی شده با سندهای تحلیل مطابقت دارد، آماده تحویل و استقرار خروجی شدند. نرم افزار نصب شد ولی کسی از آن استفاده نکرد؟ چرا؟ با اینکه این همه زحمت کشده شده بود؟خوب موقعی که یک ملک نیاز بود ثبت شود، اطلاعات بین واحدهای مختلف پخش بود، و درواقع یک اپراتور دسترسی به همه آنها نداشت اما برای ثبت و تایید فرم باید همه اطلاعات وارد میشد یا کلی اقلام اطلاعاتی که هیچ کس به آنها دسترسی نداشت یا وارد کردن اطلاعات برای یک ملک خاص خیلی سخت و پیچیده بود و یک کارمند دولتی خیلی حال نداشت این همه اطلاعات را وارد کند، و موارد زیاد دیگری که باعث می شد واحد سفارش دهنده تمایلی به استفاده از خروجی استقرار یافته نداشته باشد زیراکه اعتقاد داشتند این نرم افزار نیاز آنها را برآورده نمی‌کند یا خیلی پیچیده است یا .. پس نیاز بود که کلی تغییرات انجام شود.شاید بشود، کاسه و کوزه را بر سر تحلیلگرها شکست که چرا درست تحلیل نکردید؟ چرا برنامه نویس ها پیچیده آن را پیاده سازی کردند؟ یا می شود کاسه کوزه را بر سر مشتری سفارش دهنده شکست که چرا از اول همه چیز را نگفتید؟ ولی همانطور که در اول این نوشته گفتم، یک جنس از پروژه ها هستند که این اتفاق به صورت مکرر در آن اتفاق می افتد. پس احتمالا مشکل جایی دیگری هست.پروژه‌ها یا مسئله‌های طیف مشخص و طیف پیچیده با هم فرق دارنداکثر پروژه های نرم افزاری در طیف پیچیده دسته بندی می شوند، از این لحاظ که نه سمت مشتری “دقیقا” میدانند چه نیازمندی دارند و معمولا با دیدن خروجی، قطعیت پیدا می‌کنند(آها ما این رو میخواهیم). هم سمت اجرا کننده پروژه، روشهای و ابزارها، طرح ها و … قطعیت ندارند، مثلا شاید از یک دیتابیس برای ذخیره سازی اطلاعات استفاده کنیم که در ادامه به این نتیجه برسیم که انتخاب بهتری هم هست. از طرف دیگر، شرایط بازار و رقابت نیز باعث می شود ما در برنامه اجرایی قطعیت کامل نداشته باشیم.مدل آبشاری در طیف مسئله های مشخص عالی عمل می‌کندمدل آبشاری در مسئله های پیچیده کاربردی نیست و موجب ایجاد محصولات بدردنخور و اتلاف منابع خواهد شدذات مسئله‌های پیچیدهما در پروژه ها یا مسئله های پیچیده به چند چیز یقین داریم:۱- چیزی که مشتری درخواست داده یا آنچیزی که ما فکر می‌کنیم که مشتری به این قابلیت یا فیچر نیاز خواهد داشت با آنچیزی که واقعا نیاز دارد، معمولا متفاوت هست.۲- ما قطعا میدانیم که روش اجرایی که از اول برنامه ریزی کردیم، چیزهایی پدید خواهد آمد که نمی دانستیم. پس برنامه اجرایی و روش انجام نیز قطعیت ندارد.۳- موارد ۱ و ۲ باعث می شود که مطمئن شویم، که تغییر در مسئله های پیچیده، امری اجتناب ناپذیر بوده و به جای دوری از آن باید راهی پیدا کنیم که پذیرای آن باشیم.خیلی ساده، ما اگر بتوانیم، تغییرات را در گام های نخست پیدا کنیم، پس هزینه تغییرات کم خواهد بود، در نتیجه خواهیم توانست به سهولت آنها را انجام بدهیم. با انجام آنها نیاز اصلی مشتری رفع شده و خواهیم توانست رضایت بالای مشتری را بدست بیاوریم.به تفکر “پاسخگویی سریع به تغییرات” چابک یا چابکی گفته می شود.اسکرام روشی برای حل مسئله های پیچیدهاسکرام یک چارچوب چابک است که با آن میتوانیم مسئله های پیچیده را حل نماییم. مسئله پیچیده به مواردی گفته می شود، دانش ما نسبت به مسئله ناقص است و به مرور این دانش پدیدار خواهد شد. مثلا توسعه نرم افزار برای یک بانک، راه اندازی یک استارتاپ، ترافیک، پیش بینی آب و هوا، یا ساختن واکسن کرونا.اسکرام با استفاده از یک روش چرخشی افزایشی باعث کاهش ریسک و افزایش میزان پیش بینی پذیری می شود.آیا ما “محصول درستی” می سازیم؟آیا ما محصول را به “شیوه درستی” میسازیم؟بخش دوم – اجزا و نحوه کار اسکرامنمایی از اجرای اسکراماین نوشته قبلا در این آدرس منتشر شده است.اگر به تازگی با اسکرام آشنا شدید یا در اوایل کار خود هستید، این دوره آنلاین بهترین پیشنهاد برای شما خواهد بودچابک و موفق باشیداسد صفریاسد صفریاسد صفریMon, 11 May 2020 10:13:36 +0430https://virgool.ir/IranAgile/چگونه-در-یک-شرکت-پروژه-محور-محصول-محور-باشیم-h7ei9zkxwpjqیکی از مشکلات اساسی که شرکت‌های نرم افزاری با آن مواجه هستند، شتر گاو پلنگ بودن میان دو دنیای پروژه محوری و محصول محوری است. در دنیای پروژه محور ما از اول به دنبال یک “زمان و برنامه” هستیم: 1- چه زمانی کار به اتمام می رسد 2- برنامه دقیق اجرا چیست؟ تا بعد آن یک واحد نظارتی دیگر بر اساس این برنامه و زمان اعلام شده ، پیشرفت پروژه را ارزیابی کند. در نگرش پروژه محور، سوال همیشگی این است "چه زمانی تمام می شود"، بخاطر همین همیشه اصلی ترین چالش شیوه تخمین زدن زمان پروژه است.اما در دنیا محصول محور، یک محصول تا زمانی که برای مشتری/شرکت ارزش خلق کند زنده خواهد ماند و تا هر زمانی که زنده است، توسعه ادامه خواهد داشت(چرخه عمر محصول).فرض کنیم، نرم افزاری مانند اینستاگرام را بخواهیم پروژه در نظر بگیریم که یک شرکت پیمانکار از شرکت فیسبوک گرفته تا انجام دهد، احتمالا در نظام مدیریت پروژه سوال این است که “کی این پروژه تمام می شود؟ ساختار شکست کار به چه صورتی است؟” اما در واقعیت امروز؛ دائما تیم اینستاگرام با مشتری در تماس است، بازخورد می‌گیرد، بر اساس همین بازخورد یا مشاهده رقبای خود، اقدام به توسعه قابلیت‌های جدید می‌کند. در نگاه محصولی، ارزیابی عملکرد با ارزشی که محصول برای مشتری خلق می‌کند، صورت می پذیرد، اما در نگاه پروژه محور، متر موفقیت، هماهنگ بودن پیشرفت پروژه با برنامه از پیش تعیین شده و یا عقب/جلو بودن از آن است. اینکه کدام نظام بد یا خوب است، مسئله ما نیست، هر دو نظام جایگاه خود را دارند. اما واقعیت این است که نظام چابک مبتنی بر خلق ارزش بوده و چارچوب های چابک مثل اسکرام نیز بر اساس همین قاعده بنا نهاده شده اند. منتهی مشکل آنجا شروع می شود که در نظام تفکری چابک، میخواهیم ادبیات نظام پروژه محور را انجام بدهیم.فرض کنید من در شرکتی مدیر پروژه هستم، در آنجا مدیرانی که بیشترین پروژه را تمام کرده باشند، پاداش بیشتری خواهند گرفت، آیا من حاضر خواهم بود که به بازخوردهای کاربر/مشتری در زمان توسعه یا بعد از تحویل گوش بدهم؟ در حالی که در تفکر چابک، پذیرفتن بازخورد کاربر و تغییرات بعنوان اصلی ترین مزیت رقابت سازمان در نظر گرفته شده است. برخی سازمانها برای چابک سازی، عنوان مدیر پروژه را به مالک محصول تغییر می‌دهند، اما همچنان متر موفقیت، مترهای نظام پروژه محور باقی می ماند، پس مسلما ما نتایج همان نظام را بدست خواهیم آورد.باز تاکید میکنم، منظور من این نیست که نظام مدیریت پروژه بد است. اما در صنعت نرم افزار، 1- اساسا دامنه کار ما از اول مشخص نیست 2- بعد از تحویل محصول، بخش اعظمی از دامنه کار معلوم می شود 3- محصولات نرم افزاری معمولا انتها ندارند البته تا زمانی که کنار گذاشته شوند.باید قبول کرد که بسیاری از سازمانهای ما با اینکه می‌خواهند ولی هنوز کامل محصول محور نشده اند(به دلایل مختلف، مانند کارفرما، ساختارهای سنتی و … )، اما در این نوشته می‌خواهم کمی سعی کنم ارتباطی بین دو دنیا را برقرار کنیم.در دنیای پروژه، ما نیاز داریم اسکوپ یا دامنه کار را با جزئیات زیادی دربیاوریم،  تخمین بزنیم که چقدر طول می‌کشد، بعد یک برنامه اجرایی داشته باشیم، مثلا با گانت چارت. مشتری الان میداند چه زمانی پروژه تمام می شود و خیالش راحت است، منتهی در پروژه هایی که اساسا مبتنی بر فیدبک مشتری/کاربر است، یا کلا دامنه شفاف نیست و به مرور کشف می شود، خیلی سخت هست که بتوانیم این روال را داشته باشم. اما باید چه کرد؟نکته مهم: البته روش معرفی شده برای شرکتی و جایی هست که واقعا نتیجه و ارزشی که برای کاربر نهایی خلق می شود مهم باشد یا اساسا جنس کارهایی که انجام می‌دهند مبهم یا دامنه مشخص نداشته باشد، اگر اساسا این در شرکت شما نیست، کلا نیازی به ادامه متن نیست (:1- برای چیزی که داریم برنامه ریزی کنیمبه جای اینکه فکر کنیم ما یک پروژه داریم، باید این را در نظر بگیریم ما یک محصول داریم با چندین نسخه که هر نسخه میتواند یک پروژه باشد. یعنی هر نسخه یک دامنه، زمان و هزینه خواهد داشت. پس بسیاری (نه همه) از قواعد مدیریت پروژه را میتوان در بستر نسخه انجام داد.ما معمولا دو نوع نسخه بندی میتوانیم انجام بدهیم:1- مبتنی بر زمان2- مبتنی بر فیچرهر دوی این روش ها، در نهایت به یک لیستی از فیچر یا قابلیت و یک زمان دست پیدا خواهیم کرد، اما بهتر است در نگاه فیچر محور یا زمان محور، به برآیند نیز فکر کنیم، که هدف ما از ارایه این نسخه چیست؟ دلیل این اقدام این است که اگر روزی قرار بود در دامنه این نسخه تغییر بدهیم بتوانیم سنگ محکی داشته باشیم که کدام اقلام را فعلا میتوان انجام نداد.2- چند نسخه جلوتر را باید برنامه ریزی کنیم؟در محصولات ناشناخته یا پر ابهام، بهتر است همیشه یک نسخه را برنامه ریزی داشته باشید، اما گر باز نیاز بود(بر اساس فشار مدیریت یا مشتری یا …) می‌توانید چند نسخه را جلو-جلو به همین صورت برنامه ریزی کنید. منتهی معمولا برنامه ریزی بیش از 3 نسخه جلوتر غیر واقعی خواهد بود.برخی شرکتها مشتری خود را به ریلییز، دوره ای و منظم عادت می‌دهند، مثلا هر یک و نیم ماه یک ریلییز خواهیم داشت که در یک سال، 8 بار خواهد بود.3- قیمت چگونه تعیین می شود؟زمانیکه کل دامنه معلوم نیست، چگونه بر روی پروژه قیمت گذاری کنیم؟ این قسمت یکی از گیرهای اساسی است. (لطفا این را از من نشنیده بگیرید، حتی شرکتهایی که زمان خیلی زیادی در مرحله قیمت دادن صرف کردند و از انواع روشها برای قیمت دادن استفاده می کنند، به تجربه دیدم این عدد بیشتر از یک حدس و گمان نیست)یک روش جایگزین این است که می‌توانید به جای قیمت گذاری از مفهوم بودجه استفاده کنید. مثلا این محصول تا چقدر می ارزد که ما بودجه صرف آن کنیم.یا حتی اگر قیمتی تعیین شده (حالا با هر روشی)، بهتر است به آن نگاه بودجه داشته باشید. مثلا قیمت روی کل پروژه 1 میلیارد تعیین شده است. اما با توجه به قطعی نبودن نیازمندی ها، دامنه احتمال دارد تغییر کند. پس ما به اندازه یک میلیارد قرار شده برای این محصول کار کنیم. پس با ارزشترین کارها در نسخه ها ابتدایی انجام می شود و بعد بر اساس بازخورد به جلو حرکت می‌کنیم. برای اینکه حتی اگر مشتری نتوانست بودجه بیشتری برای این پروژه بگذارد، محصول قابل استفاده و نیازهای مشتری را رفع نماید.در واقع بودجه برای تحقق چشم انداز است تا رسیدن به Initial Plan . هر لحظه برنامه میتواند تغییر پیدا کنداگر بودجه تعیین شده تمام شد، و همچنان مشتری خواهان توسعه بود، می‌توانیم بودجه جدیدی برای توسعه در نظر بگیریم، اینکه مشتری از کجا بداند ما سر او کلاه نمیگذاریم، با همراه دائمی او در فرآیند توسعه و تحویل اقلام در نسخه های کوچک خواهد بود. (واقعیت این است نظام قرارداد در ایران بسیار قدیمی است و کاملا مبتنی بر شرایط پایدار و قطعیت تعیین شده و در بسیاری اوقات نمیتوان در قرارداد چابک عمل کرد، و بهترین گزینه داشتن یک قرارداد اما تعامل با مشتری در طول انجام کارها و ایجاد توافق برای ادامه راه بر اساس همان بودجه تصویب شده است، یا برخی مواقع قرار داد بر اساس متریال و زمان T&M میتوان گزینه خوبی باشد یعنی هر چند تا ریلییز کار انجام شد کارفرما پول بپردازد. در این مدل قرار اعتماد بین طرفین بسیار حیاتی است)4- چگونه پیشرفت را اندازه بگیریم؟در روش قدیمی، پیشرفت به یک برنامه نیاز دارد، مثلا گانت چارت، و یک سیستم لاگ زدن. متر ما در اسکرام Done  شدن اقلام قابل تحویل به مشتری در انتهای اسپرینت خواهد بود.ما معمولا پیشرفت انجام کار را در سطح نسخه و نه محصول/پروژه اندازه می‌گیریم، و دلیل آن عادت دادن تیم و مشتری به مهم بودن نتیجه هر نسخه است و اینکه هر نسخه را به چشم یک پروژه نگاه می کنیم. نمودار Release Burndown یکی از بهترین گزینه ها در این خصوص است.برای اینکه این نوشته کاربردی تر باشد و باتوجه به اینکه در ایران ابزار اصلی شرکتها جیرا است، نمودار را با این ابزار ایجاد و شرح می‌دهم، اما با اکسل یا حتی امکان رسم دستی نیز وجود دارد.در قسمت نسخه های جیرا، یک نسخه جدید اضافه کنید و بعد اقلام مربوط را به نسخه اضافه کنید. دقت داشته باشید که تنها اقلامی را اضافه کنید که میخواهید در این نسخه تحویل شود (پیش بینی می‌کنید تحویل این اقلام ارزش بیشتری داشته باشد، البته بهتر است انتخاب اقلام بر اساس یک نقشه راه باشد که در کتاب مدیریت محصول چابک میتوانید در این خصوص بیشتر مطالعه کنید)حالا بعد از انجام چند اسپرینت اتوماتیک نمودار بردن داوون برای شما ایجاد خواهد شد(منظور باز شدن و بسته شدن اسپرینت ها در جیرا): این نمودار کمک می‌کند مدیر پروژه/محصول و تیم روند پیشرفت نسخه را ببینند و اگر نیاز به تغییر باشد، آن را سریع اعمال کنند. مثلا در شکل بالا شاهد این هستیم که 6 اسپرینت برای انجام مابقی اقلام این نسخه لازم است، اگر فکر می‌کنیم، 6 اسپرینت خیلی دیر است، می‌توانیم در اسکوپ باقی مانده این نسخه تجدید نظر کنیم.5- تغییرات در اسکوپ نسخهیکی از مواردی که تیم ها را اذیت می کند، موارد پیش بینی نشده هر نسخه هست. یعنی مواردی به دامنه این نسخه اضافه شده که از اول بر روی آنها توافق نشده بود، ولی الان مشتری یا خودمان می‌خواهیم این قابلیت نیز در این نسخه ارایه شود.در شکل بالا، در اسپرینت 3 و در جلسه دمو، نیاز شده دو استوری جدید هر کدام با 5 پوینت به دامنه نسخه اول اضافه شود. کار کرد این نمودار این است که شما همیشه بتوانید میزان کار باقی مانده را به راحتی ببینید و تصمیم مناسب آن لحظه را بگیرد که معمولا نیاز به رایزنی در مورد تغییر دامنه نسخه خواهد بود. برای اینکار خیلی ساده، یک گزارش وجود دارد که شما میتوانید دامنه باقی مانده از نسخه را ببینید و آن را الویت بندی کرده و مواردی که برای این نسخه حیاتی نیستند را از نسخه بیرون بیندازید.فرض کنید برای مثال باید تا سه تا اسپرینت بعد یعنی 1.5 ماه دیگر نسخه را ارایه کنیم، ولی الان برای کار باقی مانده ما به 5 اسپرینت نیاز داریم(بر اساس نمودار)، و سرعت انجام کار 6 پوینت و کار باقی مانده 30 پوینت است. برای اینکه در 3 اسپرینت کار بسته شود، یا باید تیم سرعت را به 10 پوینت برسانند که معمولا نیاز به اضافه کاری خواهد بود که در بلند مدت اصلا توصیه نمی شود، اما راه حل دیگر، بازی با دامنه خواهد بود.6- از تکنیک MoSCoW استفاده کنیدمعمولا در این مرحله که شما نیاز دارید بر روی دامنه مذاکره کنید، تکنیک MoSCoW روش موثری است:در اینجا همراه با ذینفعان بر روی الویت بندی باید کار کرد، مثلا مانند تصویر زیر:آیتمهای با الویت Will معمولا از نسخه حذف می شوند و به بک لاگ یا نسخه بعد اضافه می شوند، پس در نتیجه نمودار ریلیز برن داوون چنین چیزی نشان خواهد داد:ما شاید بتوانیم در تفکر چابک، یک نسخه یا یک اسپرینت را پروژه در نظر بگیریم( البته همچنان باید منتظر بازی کردن با دامنه باشیم)، اما مسلما نمیتوانیم کل یک محصول پیچیده را یک پروژه در نظر بگیریم و انتظار داشته باشیم که با قواعد دنیای پروژه محور، بیشترین ارزش ممکن را خلق کنیم.چابک و موفق باشیداسد صفریاین نوشته قبلا در این آدرس نیز منتشر شده بود. اسد صفریاسد صفریMon, 30 Dec 2019 23:58:05 +0330https://virgool.ir/IranAgile/تجربه-سفر-چابک-در-شرکت-تحلیلگر-امید-داستان-واقعی-تحول-چابک-fuaipspiu0rjتحلیلگر امید شرکتی است که سرویس WealthTech بر پایه هوش مصنوعی برای زیاد کردن پول مشتریانش ارایه می دهد. زمانی که در این شرکت دعوت به همکاری شدم، انتظاری که از من داشتند پیاده سازی اسکرام بود اما بر اساس تجربه میدانستم که اسکرام مثل یک دکمه است که میخواهیم برای آن یک کت بدوزیم. اینکه هدف شرکت پیاده سازی اسکرام باشد، هدف خوبی نیست. واقعا چرا باید اسکرام را پیاده سازی کنیم؟ آیا مشکل اساسی شرکت پیاده نشدن اسکرام است؟ یا در واقع میخواهد با پیاده سازی اسکرام چه مشکلی را حل کند؟در بسیاری اوقات اسکرام پیاده می شود، ولی واقعا چیزی بهتر نمی شود.وقتی تنها ابزار من چکش باشد همه چیز را میخ خواهم دید و به جای حل مشکل سازمان بدنبال پیاده سازی اسکرام خواهم بود.پروژه تحلیلگر امید را چگونه شروع کردیم؟سعی کردم در شرکت امید، از مدل اجایل فلوئنسی برای پیشبرد چابک سازی استفاده کنم. مدل اجایل فلوئنسی سه گام اساسی برای چابک سازی دارد:1- شناسایی فرصت2- دیاگ زدن3- دست یابی به فرصتمرحله اول: شناسایی فرصتبه طور کلی در این گام، سعی می شود که درک کنیم دغدغه سازمان چیست؟ کلمه فرصت/چالش با هم می آیند. سازمان با چه چالشی مواجه است که فکر می‌کند نیاز به یک روش دیگر کار دارد.در مورد شرکت امید، این شناسایی در طی یک هفته اول که در سازمان بودیم انجام شد، شامل صحبت کردن با تیمها و اعضای فنی و مدیران محصول و مدیران ارشد ... .نکته مهم در اینجا این است که همه دوستان از ظن خودشان یار شما می شوند. کار یک مربی در اینجا این است که درک کند که مسائل زیرین و اساسی چیست؟ مثلا اینکه جلسات دیلی به موقع برگزار نمی شود، شاید مسئله اساسی نباشد.چیز مهمی که در امید در جریان بود این بود، که امید در یک مدت کوتاه رشد سریعی انجام داده بود، این رشد سریع باعث شده بود یک سری از سیستم ها خیلی سریع توسعه داده شوند، حتی برای بالا آوردن این سیستم ها جشن گرفته شده بود اما امروز میزان باگ به میزان باور نکردنی بالا بود. این میزان باگ بالا باعث شده توسعه فیچرهای جدید بشدت کند شود، از طرف دیگر، این کند جلو رفتن توسعه فیچرها باعث شده بود فکر کنیم که چرا امور کند است؟ خود این باعث شده سطح اعتماد کمتر شود، آیا آنها واقعا کار می‌کنند؟ خود این کم رنگ تر شدن اعتماد، باعث ایجاد مشکلات روابط انسانی نیز شده بود. حتی بچه های فنی نیز نسبت به هم و توانایی همدیگر با شک نگاه می کردند.حتی علاوه بر این، سود مالی بخاطر عدم پیشرفت به موقع پروژه، کاهش یافته بود و در برخی از موارد، باگ ها باعث ضرر و زیان مالی زیادی برای شرکت شده بودند.این نکته بسیار مهمی است که ما چالش اصلی را پیدا کنیم و صرفا درگیر نشانه ها یا علائم بیماری نشویم. معمولا زیاد می شنوید، فلانی کدنویسی بلد نیست، مدیر شاید بگوید باید نیروی فنی جدید بیاورم، اسکرام مستر می گوید جلسات اسکرام درست برگزار نمی‌شوند و ... حتی شاید بخاطر پایین بودن میزان اعتماد یا خدشه دار شدن روابط انسانی یک دور آموزش کارتیمی بگذاریم اما آیا ریشه داستان حل می شود؟فرصت شناساسی شده در امیدبهبود کیفیت سیستم جهت حداکثری کردن رضایت مشتریان، ذینفعان و بخصوص اعضای تیمدر حالی که کیفیت، چالش شماره یک ما بود، در همان حال می توانست فرصت هم بشود که با پرداختن به آن، اوج بگیریم.انتخاب ناحیه فلوئنسی بر اساس فرصت/چالشمدل اجایل فلوئنسی یک مدل بلوغ نیست، معمولا در مدل بلوغ هر چقدر بیشتر بهتر است اما در مدل اجایل فلوئنسی که ما چهار ناحیه داریم، هر ناحیه برای خودش منافع مشخص و در عین حال هزینه مشخصی دارد. یعنی به تنهایی هر ناحیه ی مدل بالغ کامل است. در صورتی که ناحیه بالاتر نیاز ما نباشد، صرفا هزینه غیر لازمی را انجام خواهیم داد.توضیح خلاصه نواحی مختلف فلوئنسیناحیه Focusing در واقع همان پایه و فونداسیون چابک است و یک تیم چابک فلوئنت در این حوزه می ‌تواند از منافع حاصل شده از شفافیت و کار تیمی به صورت ملموس بهره ببرد. هر چند که فلوئنت بودن در این ناحیه شامل مهارت های فنی پایدار نیست، اما بدست آوردن و نمایش موفقیت در این حوزه باعث ایجاد تمایل بیشتر برای سرمایه‌گذاری های آتی و بدست آوردن مهارت هایی در ناحیه های بعدی می‌شود. همچنین این ناحیه برای تیم هایی خوب است که به نگهداری بلند مدت از نرم‌افزارهای خود نیاز ندارند.برای تیم هایی که نیاز دارند نرم افزار خود را به صورت بلند مدت نگه داشته یا بهبود دهند ناحیه Delivering می تواند انتخاب بهتری باشد. این ناحیه در واقع نمایانگر پایداری چابک است. تیم‌های فلوئنت در این ناحیه باگ کمتری دارند، بازدهی آنها بالا بوده و نسبت به درخواست های کسب و کار پاسخگو هستند. فلوئنت بودن در این ناحیه می تواند برای بسیاری از تیم‌ها جهش بزرگی محسوب شود.سازمان هایی که می‌خواهند با سرعت تغییرات بازار هماهنگ باشند یا حس می کنند که تغییرات مهلک بازار می تواند بقای آنها را به خطر بیاندازد ناحیه Optimizing می تواند انتخاب بهتری باشد. در واقع ناحیه Optimizing وعده اصلی چابک است. چابکی کسب و کار به همراه خلاقیت. گرچه این ناحیه باعث بوجود آمدن منافع زیادی برای کسب و کار می شود ولی نیازمند تغییرات اساسی در ساختار سازمانی خواهد بود. انجام چنین تغییراتی معمولا در سازمان های کوچک راحت تر است.ناحیه Strengthening برای سازمان‌هایی است که مدیران و رهبران به دنبال خلاقیت حداکثری در سازمان هستند و معمولا این اتفاق در سازمان های کوچک و متوسط امکان پذیرتر است. در واقع این آینده چابک است یعنی جدیدترین تکنیک های چابک در همین مسیر در حال حرکت هستند. اما نکته احتیاطی در این جا است که رسیدن به این ناحیه نیاز به تحقیقات بسیاری در خصوص آخرین سبک های مدیریت و سرمایه‌گذاری سنگین برای اجرایی کردن این سبک های جدید کاری خواهد داشت.بر اساس فرصت/چالش اصلی انتخاب شده برای امید، ما ناحیه دوم یا Delivering را انتخاب کردیم اما نیم نگاهی هم به ناحیه Optimizing داشتیم که در صورت پایداری بتوانیم تارگت آینده ما آن باشد، اما تمرکز اصلی در این دوره بر روی ناحیه Delivering بود.اما چرا ناحیه Deliveringانتخاب شد؟متریک اصلی این ناحیه بر اساس تعریف خود مدل اجایل فلوئنسی این است: " تیم می‌تواند آخرین کار خود را با کمترین ریسک و هزینه هر زمان که کسب و کار درخواست داد ارائه کند." و منفعت دیگر "سطح خرابی ها در سیستم پایین است، بنابراین تیم زمان کمتری برای رفع باگ‌ها به هدر خواهد داد و زمان بیشتری در راستای بهبود می‌تواند استفاده کند." و مورد بعد "سطح پایین خرابی‌ها و بدهی فنی بر روی میزان رضایت شغلی و روحیه افراد تاثیر گذار بوده و باعث ماندگاری و افزایش بازدهی افراد تیم‌ها شده است."خوب این موارد دقیقا همان مواردی بود که ما برای فرصتی که کشف کرده بودیم لازم داشتیم. پس بر اساس همین، ناحیه دوم انتخاب شد. نکته مهم: ناحیه Delivering بر پایه ناحیه Focusing استوار است. یعنی شما باید در مسیر، حتما به تمرینات این ناحیه نیز سر بزنید.خوب در هفته اول ما فرصت را کشف کرده بودیم، و تارگت خودمان را نیز انتخاب کرده بودیم، الان زمان دیاگ زدن بود.مرحله دوم: دیاگ زدندیاگ یک ابزار مخصوص تسهیل گران مدل اجایل فلوئنسی است. کار کرد این ابزار این است که، فاصله شما را با ناحیه ای که تارگت کردید را مشخص می کند یا بعبارت ساده تر مانند یک جی پی اس مشخص می کند که شما کجا هستید و چه مسیری را برای رسیدن به آن تارگت انتخاب شده باید بپیمایید.دیاگ زدن تیم های امید در قالب یک ورکشاپ انجام شد، و نتیجه برای تیم و مدیران ارشد در قالب یک گزارش آماده شد. مهمترین کارکرد این گزارش این است که مدیریت می داند که چه کاری باید برای حمایت از تیم در مسیر انجام بدهند، و خود تیم نیز بداند که چگونه باید مسیر را طی کند.با توجه به شرکتی بودن موارد این دیاگ، جزئیات زیاد آن قابل انتشار نیست.مرحله سوم: دست یابی به فرصتگام بعد از دیاگ زدن، حرکت به سمت تارگت انتخاب شده بود، یعنی در مرحله اول تارگت خودمان انتخاب کردیم، در دیاگ زدن، درک کردیم کجا هستیم و الان زمان حرکت و دست یابی به فرصت ها بود. این مرحله در واقع همان مرحله مربی گری تیم ها و مدیران است.در خواست ما از مدیران، برای تارگت ناحیه اول یا همان Focusing (که زیربنای تارگت اصلی ما بود)، موارد زیر بودند:● محیط مناسب که متمرکز بر بازدهی بالا دارد (به خصوص اتاق مخصوص تیم) ایجاد کنید.● مطمئن شوید که شخصی با تخصص در حوزه کسب و کاری و آشنا به ارزش های مشتری در دسترس بوده و به عنوان نماینده کسب و کاری تیم عمل نماید.● سعی کنید موانع کار تیمی موثر را برطرف نمایید مانند رتبه بندی رقابتی، پاداش های انفرادی.● اعضای تیم را در مورد مهارت های Focusing آموزش داده و زیر نظر مربی قرار دهید.● مدیران را آموزش بدهید تا آن ها محیط مناسب جهت کار تیمی را ایجاد نمایند و به جای مدیریت افراد به دنبال مدیریت سیستم های کاری باشند.مدیران همکاری خوبی در تمامی موارد انجام دادند، مثلا شکستن تیم ها به تیم های محصول یکی از کارهایی بود که انجام دادیم، یا اینکه اعضای تیم محصول دور هم سر میز مشترک نشستند. یا اینکه مدیران به جایی پیگیری کار از شخص که قبلا روال بود، سعی کردند کار را از تیم بخواهند. در نهایت نزدیک به ۸ تیم جدید محصول محور شکل گرفت و ساختار تیم ها نظیر Role and Responsibility، چارت ساختار تیم، ماتریس شایستگی و اهداف و ماموریت تیم ها توسط افراد هر تیم مشخص شد.ساختار تیم های محصول محوردر سطح تیم نیز، تیم فرآیندهای اسکرام و کانبان را شروع کرد، جلسات برنامه ریزی اسپرینت و بازبینی و بازنگری اسپرینت شروع شد. از طرف دیگر بردهای فیزیکی برای هر تیم ایجاد شد و ... .متاسفانه خیلی از شرکت ها در این مرحله استاپ می شوند، و معمولا تصویر خیلی از دوستان از چابکی، فقط همین اندازه است، ولی این ناحیه، تارگت اصلی نبود حتی رسیدن کامل به آن دستاورد خاصی حساب نمی‌شد. تارگت اصلی ناحیه Delivering بود. برای این ناحیه بزرگترین چیزی که از مدیران انتظار داریم، زمان و زمان و زمان بود. مدیران اکثرا با خرج کردن پول مشکلی ندارند اما با سرمایه گذاری زمانی یا رفتاری مشکل دارند. نقطه قوت امید این بود که مدیرعامل پشتیبان این حرکت بود و حاضر بود اعتماد کند و سرمایه گذاری را انجام بدهد.این سرمایه گذاری به منزله کم تر شدن ظرفیت تیم برای انجام فیچرهای جدید برای چند ماه میشد.در سطح تیم، کارهای زیادی باید انجام میشد. اصلی ترین کار این بود که یک جاهایی از سیستم باید رفاکتور میشد، یک جاهایی باید از اول نوشته میشد، تست (از انواع مختلف به سیستم باید سیستم اضافه میشد)، اما یک خطری که امکان داشت اتفاق بیفتد این است که ما در دام رفاکتور بی انتها بیفتیم. برای این منظور ما از یک تکنیک ساده استفاده کردیم، بالای ۱۰۰ باگ اخیر سیستم را بررسی کردیم، معمولا باگ ها نشانه های خوبی از نقاط باگ خیز و شکننده سیستم برای ما است. بعد بر اساس این شواهد شروع کردیم، به آماده سازی لیست اولویت بندی شده از رفاکتورها.رفاکتورها و اضافه شدن تست به مرور در اسپرینت ها انجام میشد. اما باید می دانستیم این کارها منجربه کاهش میزان باگ ها میشود، به عبارت ساده اگر چیزی را نتوانیم اندازه بگیریم نمی توانیم آن را بهبود بدهیم. در شروع کار، یک ویجت گزارش باگ به سیستم اضافه کردیم که کاربران و تسترها می توانستند باگ های سیستم را گزارش کند و این باگ ها در جیرا خودکار ثبت می شد. عدد در هفته های اول باور نکردنی بود، ۳۰ تا ۴۵ باگ در هفته.اولین گام همراهی در تغییر، ایجاد حس اورژانس استوقتی اولین بار بچه ها این عدد و نمودار بالا را دیدن، واقعا برایشان باور کردنی نبود، "واقعا ما اینقدر باگ داریم ...". برخی اوقات برای ایجاد حس اورژانس شما نیاز دارید وضعیت واقعی را جلوی چشم بیاورید، همین.برای همراهی بیشتر اعضای تیم این عدد را تبدیل به چالش کردیم، که آیا می توانیم این را به صفر برسانیم؟ چالش 40 به 4. خود این عدد به صورت بصری روی یک مانتیور انداخته شد که جلوی چشم تیم ها باشد. حالا در هر اسپرینت کارهایی که انجام می شد، تیم بدنبال این بود که آیا این عدد کمتر شده است؟ یعنی رفاکتور هم بخاطر رفاکتور یا اینکه فلانی گفته کلین کد بنویسید نبود، بلکه برای افزایش کیفیت سیستم و رضایت مشتریان است.تاثیر کار را ببین، با قدرت تر جلو برویکی از کارهای جالب و موثری که کشف کردیم، این بود که تعدادی از کاربران محصول تیم، که در خود سازمان بعنوان تریدر مشغول به افزایش ثروت مشتریان بودند، را درگیر مساله کردیم. هر روز بعد از تایم بازار و در انتهای جلسات دیلی استنداپ، یکی از دوستان را صدا می کردیم، و دو تا سوال از آنها می پرسیدیم: ۱. امروز چند تا باگ ثبت کردید؟ ۲. به نظرتون نسبت به دیروز کیفیت سیستم بهتر شده است یا خیر؟ سوال اول عدد آمار بود و سوال دوم حس مشتری به سیستم بود. این پرکتیس باعث شده بود افراد فنی تیم، هر رفاکتور یا بهبود که در سیستم انجام می دهند دنبال نتیجه باشند که آیا امروز توانستیم در مشتری حس بهتری ایجاد کنیم و نکته جالب هم همین بود که با کاهش میزان باگ، دقیقا حس منتقل میشد.لیست استخراجی برای رفاکتور، یک لیست ثابت نبود و در طول اسپرینت ها و مشاهده نتایج تغییر می کرد. اما نتیجه باور نکردنی بود. در چهار ماه علاوه بر اینکه تیم توانسته بود این عدد رو تقریبا زیر ۴ برساند از سوی دیگر کار کردن بر روی فیچرها جدید را نیز شروع کرده بود.البته فقط رفاکتور کردن نبود، بلکه بدهی فنی دیگر نیز بود، مثلا کامل کردن مانتیورینگ سرویس ها، اضافه کردن هلث چک و مستند سازی بخش های مهم سیستم، ... جز بدهی فنی ها دیگری بودن که در پروسه انجام شدند. یا کلی اقدام دیگر اعم از ایجاد یک محیط تست شبیه پروداکشن، اضافه شدن تستر و ... . ولی مهم ترین نکته داشتن زمان و تمرکز و همراهی افراد فنی خوب در کنار تیم بود.بعد از دیدن نتایج و کاهش باگ، بشدت روابط انسانی افراد نیز بهبود پیدا کرد.امیرمهدی یکی از برنامه نویس های امید، گزارش کاملی از پرکتیس های فنی در اینجا نوشته است.اما نتیجه چه بود؟همانطور که اول گفتم، مشکل شرکت استفاده نکردن از اسکرام نبود، چیزی که شرکت لازم داشت یک محصول با کیفیت بود که در آن 1- اضافه کردن فیچرها به آن راحت تر شود 2- منجربه رضایت مشتریان شده 3- از سوی دیگر توسعه دهندگان نیز به کیفیت کار خود افتخار کنند.نمودار باگ گزارش شدهولی مهمترین نکته حس بچه های تیم بود، برای مثال این کامنت یک سری از بچه های فنی شرکت است:نتایج ملموس در طول پنج ماه برای کسب و کار،کاهش بشدت زیاد بدهی فنی، و توانایی تیم برای پرداختن به توسعه فیچرافزایش ملموس سطح اعتماد بین افراد تیم و لیدرهاافزایش میزان سود شرکت بر اثر توانایی جذب مشتریان و نگه داری مشتریان قبلیاز نکات مثبت امید این بود که مدیرعامل شرکت همراهی خوبی با ما در راستای تحول چابک انجام میداد.(واقعا بدون همراهی واقعی تحول چابک امکان پذیر نیست)، مثلا یکی از اقدامات مثبت مدیریت، توافق نامه ای برای هدایت عملکرد کل لیدرهای سازمان طراحی شده بود که ایشون زمان خوبی هر هفته برای دادن و گرفتن فیدبک صرف می کرد و مابقی تایم را به حل دغدغه های لیدرها می پرداخت. تقریبا این جمله بین لیدرها و مدیران کامل جا افتاده بود که “انسان ها و روابط شان فراترند از فرآیندها و ابزارها ”.بخاطر اینکه، اصلی ترین ذینفع ما در این پروژه، شخص خود مدیرعامل بود، از ایشون درخواست کردم که در یک جمله نظرشون رو در خصوص نتیجه پروژه انجام شده داشته باشم:“گاهی اوقات در سازمان افراد دچار سوگیری قضاوتی می شوند. فرض کنید شما یک سیستم پیشرفته پیاده سازی می کنید و بعد از ۲ سال تمامی راه حل ها و معماری هایی که کنار هم چیده اید شبیه به فرزندتان هستند. به دلیل sunk cost و گذشته ای که از این ماژول ها میشناسید، سازمان در تصمیم گیری محتاط می شود و ممکن است یک تصمیم اشتباه گذشته را به خاطر هزینه هایی که برایش کرده ایم ادامه دهیم. در این نقاط حتما باید یک فرد متخصص و باتجربه به سازمان وارد شود و با reference point جدید اطلاعاتی، شروع به قضاوت کند و تصمیمات بهتری برای پروژه های اشتباه یا پرخرج بگیرد. شما اسدجان به خوبی این کار رو انجام دادید. درک عمیق از روابط انسانی، پیدا کردن ریشه مسایل به جای پرداختن به شاخ و برگ ها، حضور مداوم در تیم ها و تجربه شگرف و شناخت مشکلات کار تیمی در ایران باعث شد، چالش های قبلی که در امید بود کاملا محو شود. واقعا از شما متشکرم.”آینده امید چگونه است؟نکته مهم در تحول سازمانی، این است که از اول بدانیم، تحول یک پروژه نیست. یعنی پایانی ندارد. تحول یک سفر بی انتها است که بالا و پایین زیادی خواهد داشت. بخصوص تا نقطه فلوئنسی فاصله زیادی وجود دارد، یعنی بسیاری از این تغییرات برای همیشه پایدار باشند، من در ابتدای این سفر همراه دوستان امید بودم و امیدوارم این مسیر همچنان در آینده توسط خود دوستان ادامه داشته باشد.چابک و موفق باشیداسد صفریاین نوشته قبلا در این آدرس نیز منتشر شده بود.نوشته های بیشتر در حوزه چابکاسد صفریاسد صفریSat, 07 Dec 2019 12:41:44 +0330https://virgool.ir/Software/royce-waterfall-bilsblcok1mdاین روزها همه جا صحبت از نارکارآمدی روش واترفال در صنعت توسعه نرم افزار یا اصولا حوزه پروژه های پیچیده است، اما بسیار جالب است که بدانیم قصه یا داستان این روش چه بوده است؟جریان از این قرار بود که دکتر وینستون رویس، در سال 1970 مقاله ای منتشر کرد که در آن قصد داشته تجربیات خود را در زمینه توسعه نرم افزارهای بزرگ و پیچیده ناسا منتشر کند. او مقاله را با شکل مفهومی از مراحل تولید شروع می کند، نیازمندی -تحلیل- طراحی – کدنویسی – تست.ولی در ادامه توضیح میدهد که این روش برای تولید نرم افزارهای بزرگ و پیچیده اصلا مناسب نیست و نظر او بیشتر روش‌های چرخشی مبتنی بر پروتوتایپ بوده است.“I believe in this concept, but the implementation described above is risky and invites failure.” -Royceاما متاسفانه، خوانندگان بی‌حوصله، متن را با دقت مطالعه نمی‌کنند و فقظ با دیدن نمودار، گمان برده می شود که رویس در تایید روش واترفال این مقاله را نوشته است، البته در آن مقاله اشاره ای به اسم واترفال نیز نشده بود. لینک مقاله اصلی رویسدر سال 1985 وزارت دفاع آمریکا، که بدنبال یک روش استاندارد برای توسعه پروژه های خود بوده، با استناد به همین عکس دوم مقاله رویس، این روش را به عنوان یک روش استاندارد معرفی می کند و به همین راحتی روش واترفال بدنیا می آید و در آن زمان که توضیح روش واترفال آسان تر بوده، به سرعت مورد استقبال قرار می گیرد. مقاله وزارت دفاعالبته بعد از آن، وزارت دفاع در نسخه تکمیلی اقدام به اصلاح این اشتباه کرده بود، ولی برای این کار کمی دیر شده بود بخاطر اینکه ایده اصلی به شدت گسترش پیدا کرده بود. لینک شرح کامل داستاننکته آموزنده این داستان این است، که افراد به “اشکال” بیشتر از متن یا نوشته توجه می کنند، آموزه دوم هم اینکه، غالبا شرکت ها و افراد دنبال روش های استاندارد هستند و در همین خصوص به سندروم “چون فلان جا اینکار رو کرده پس این درست است”، دچار خواهیم شد.این نوشته قبلا در این آدرس نیز منتشر شده است. اسد صفریاسد صفریFri, 31 Aug 2018 20:54:01 +0430https://virgool.ir/IranAgile/better-planning-vvfttueipwitدر گذشته روش های توسعه نرم افزار معمولا Plan-driven بودند یعنی در ابتدای پروژه زمان زیادی (مثلا نصف زمان پروژه) صرف تحلیل و طراحی پروژه می کردیم و در نهایت با داشتن یک طرح کامل می توانستیم پیاده سازی را شروع کنیم. اما به تدریج با زیر سوال رفتن این روش ها (که اثبات کردند طراحی های پیچیده قابل پیش بینی نیستند و باید در مرور زمان و در خلال پیاده سازی پروژه کشف شوند) و ظهور روش های برنامه ریزی تجربی گرا مانند اسکرام، ما دائما در روند پروژه درحال برنامه ریزی هستیم.اما مشکل این است که این روش خود مشکلات اساسی برای تیم های برنامه‌نویسی ایجاد می کند؛ چون ما مجبوریم دائما در حال برنامه‌ریزی باشیم و همیشه در طرح هایی که بوجود می‌آوریم جای صحبت و تغییر را باقی می گذاریم و در اینصورت است که انرژی بسیار زیادی از ما گرفته می شود.دلیل اینکه چرا این موضوع برای من مهم شد، این است که : در تیم های اخیری که با آن ها بودم شاهد این هستم که ما یک روز و یا کمی کمتر یا بیشتر برای برنامه ریزی وقت صرف می کردیم، ولی در انتهای روز چندین موضوع بودند که در مورد آنها نتیجه گیری نشده است، یا آنقدر همه تیم خسته شده بودند که بعبارتی ماسمالی کرده بودیم و در هنگام پیاده سازی کلی مشکل بخاطر برنامه ریزی ضعیف به وجود می‌آمد.همه ما معتقد هستیم که برنامه ریزی خوب در اول یک اسپرینت دقیقا مثل یک سال بخور نون و تره، یک عمر بخور نون کره است، یعنی هر چقدر در این جلسه بتوانیم خرد جمعی را بکار بگیریم و مسائل را از زوایای مختلف نگاه کنیم، راه حل های بهتر و خلاق تری کشف خواهند شد و درپیاده سازی سریعتر و بهتر عمل خواهیم کرد.نیروی اراده باعث این مشکل می شود؟همه اذعان دارند که ما خسته شدیم و این خسته گی باعث این قضیه می شود ولی برای خود من سوال بود که اصلا چرا خسته می شویم و آیا این دلیل علمی دارد؟ برای همین تحقیقاتی در این مورد کردم و به یک کتاب عالی برخوردم، Willpower یا نیروی اراده.نیروی اراده، انرژی ذهنی است که باعث متعادل شدن احساسات، عملکرد و رفتار ما می شود. یعنی به عبارتی این انرژی باعث می شود که ما عاقلانه فکر و عمل کنیم  و اگر این انرژی ته بکشد ما شاید رفتارها یا کارهای خارج از عرف و عقل انجام بدهیم یا تصمیم هایی بگیریم که بعدها از انجام آن پشیمان شویم (و اسمش رو بگذاریم چون خسته بودم یا حوصله نداشتم گفتم این کار را انجام دادم ).  نیروی اراده یک انرژی است، پس صرفا یک چیز انتزاعی نیست و واقعیت دارد. این انرژی هم مثل برخی از منابع انرژی پایان پذیر و بسیار محدود است. هر زمان این انرژی ته می کشد، کنترل امور ذهن و افکار به بخش ناخودآگاه مغز که آن هم به صورت خودکار و خیلی نه عاقلانه ما را کنترل می کند سپرده می شود. با انجام کارهای فکری (هر کاری که نیاز به تصمیم گیری و فکر دارد) مقداری از این انرژی مصرف می‌شود (مقدار بستگی به موضوع و نوع بحث دارد) هر چقدر از یک موضوع فکری دور شویم و به استراحت بپردازیم، دوباره انرژی شروع به پر شدن می‌کند و کنتور انرژی بالا می رود.سوال، آیا ما دائم در طی روز کار فکری می کنیم؟ جواب: نه. بسیاری از کارهای ما، حتی کارهای تخصصی، تبدیل به عادت شده اند. کاری که تبدیل به عادت شده باشد بسیار انرژی کمی میسوزاند.اما نکات کلیدی برای جلسات برنامه ریزی:1- با شکم خالی جلسه برگزار نکنیدبدترین زمان برای جلسات زمانی هست که تمام اعضا حاضر در جلسه گرسنه هستند، همان زمانی که هرکس در حال سوزاندن گلوکز می باشد و منجر به ایجاد احساس گرسنگی و ضعف می شود، به همین خاطر زمانی که گرسنه هستیم بدترین زمان برای انجام کار فکری است. بعلاوه بدلیل پایین آمدن گلوکز یا همان قند خون، بهترین چیز این است که در همان اتاق جلسه شکلاتی یا چیزهای شیرینی باشد تا این قند خون تقویت شود.2- قبل از جلسه برنامه ریزی، جلسه باید آماده شده باشدموضوعاتی که قرار است در جلسه روی آنها صحبت شود باید قبل از جلسه آماده شده باشند، آمادهشدن یعنی اینکه، مالک محصول باید بداند که هدف او در اسپرینت بعد چیست؟ چه کارهایی قرار است برای رسیدن به هدف انجام شود(از نظر ویژگی های نرم افزار) در مورد نیازمندی های اسپرینت  حتما با مشتری ها یا ذی نفعان صحبت کرده باشد تا دقیقا مشخص شود که نیازمندی چیست؟ (این به معنی این نیست که تا ته پروژه باید همه کارها را در یک روز انجام بدهد، بلکه به مرور و همگام با تیم نیازمندی ها باید شفاف شوند) سعی شود شرایط پذیرش کار تا آنجایی که امکان پذیر هست مکتوب شده باشد و منتظر جلسه نشویم3- انرژی محدود است پس اولویت بندی لازم استهمانطور که گفتیم انرژی کار فکری بسیار محدود است، بخصوص اگر تعداد نفرات جلسه یا تنوع فکری نفرات زیاد باشد. پس یکی از کارهای مهم این است که چند مورد مهم جلسه که حتما باید درمورد انها به نتیجه برسیم باید اولویت بندی شده باشد. یعنی ابتدا سعی نکنیم قورباغه را قورت بدهیم بلکه سعی کنیم از اولویت بالا شروع کنیم.4- تایم باکس باشیم یکی از سخترین کارها در جلسات رعایت تایم باکس است، ولی اگر ما محتوای جلسه را ابتدا اماده کنیم و دوم اولویت بندی کنیم، خواهیم توانست که متمرکز شویم و آیتم های اولویت بالا را برنامه ریزی کنیم. نگران این نباشید که به نتیجه نرسیدیم، هر چیزی نیاز به هزینه دارد، و با تمرین خواهیم توانست به آن برسیم.5- ما در طول اسپرینت هم در حال برنامه ریزی هستیمبعضی از موضوعات واقعا نیازی نیست در جلسات برنامه ریزی روی آنها زمان زیادی بگذاریم، بهترین زمان جلسات روزانه است که در طول روزها بتوانیم با صحبت مختصر به نتیجه برسیم.6- Swarm کنیدشاید در طول اسپرینت نیاز به یک کار فکری باشد و این هم نیاز به خرد جمعی باشد، بهترین کار این است که یک جلسه با حضور همه یا بخشی از نفرات تیم برگزار شود، این جلسه نیز باید 1- تایم باکس باشد 2- فقط حول و حوش یک موضوع خاص باشد 3- زمانبدی شروع خوبی داشته باشد7-  جلسه نیاز به تسهیل گر داردبهترین متخصص های دنیا هم اگر در جلسه ای باشند،آن جلسه نیاز به تسهیل گر دارد یعنی کسی که بیشتر از موضوع جلسه به فکر کیفیت جلسه باشد. این نفر باید بتواند موضوع جلسه را باز کند، نفرات را به سمت تصمیم گیری هدایت کند و جلسه را ببندد. بعضی وقت ها، روی یک موضوع باید بیشتر بحث شود، بعضی وقت ها نظرات کسانی که حرف نمی زنند باید پرسیده شود، بعضی وقت ها جلسه به گره می خورد باید برویم سراغ موضوع بعدی، یا از روش شش کلاه فکری یا هر روش دیگری استفاده کنیم .امیدوارم که برای دوستان مفید بوده باشدچابک و موفق باشیداسد صفریاین نوشته قبلا در این آدرس منتشر شده بود اسد صفریاسد صفریTue, 24 Jul 2018 00:31:00 +0430