برنامه نویسی با حدود 20 سال سابقه را تصور کنید که در سلسله مراتب سازمانی به کارشناس ارشد ارتقا سافته است اما ابدا احساس رضایت ندارد. در چنین موقعیتی معمولا مسئله اصلی نه صرفا شغل و عنوان سازمانی، بلکه شکاف عمیقی میان انتظارهای روانی فرد و واقعیت نقش فعلی اوست. برنامه نویسی که به حدود چهل سالگی رسیده و سالها تجربه حرفه ای دارد، ناخواسته وارد مرحله ای از زندگی شغلی می شود که در آن دیگر صرف انجام وظایف فنی برایش معنا ساز نیست. ارتقای عنوان به کارشناس ارشد اگر با تغییر واقعی در میزان اثرگذاری، اختیار تصمیم گیری و دیده شدن همراه نباشد، به جای ایجاد رضایت، حس بی معنایی را تشدید می کند. فرد احساس می کند نامش تغییر کرده اما جایگاهش نه، و این تضاد به شکل غر زدن و نارضایتی بروز می یابد.
از سوی دیگر، در این سن معمولا مقایسه های درونی شدت می گیرد. فرد خود را با هم سن و سالانش، با مسیرهای شغلی که تصور می کرد باید تا این نقطه طی می شد و حتی با نسخه ایده آل ذهنی از خودش مقایسه می کند. اگر احساس کند که هنوز نیازمند توجه و تایید مستقیم تیم لید است، این نشانه آن است که هویت حرفه ای او به طور کامل از تایید بیرونی جدا نشده است. در حالی که در این مرحله از مسیر شغلی، انتظار نانوشته این است که فرد بیشتر نقش مرجع، راهنما یا ستون فکری تیم را داشته باشد، نه دریافت کننده توجه مداوم.
از زاویه دیگر، ممکن است تیم لید نیز ناخواسته به این سردرگمی دامن زده باشد. بسیاری از لیدها تصور می کنند ارتقای عنوان به تنهایی پیام قدردانی و اعتماد را منتقل می کند، در حالی که برای افراد با تجربه بالا، گفتگوهای عمیق، مشارکت در تصمیم های کلان و شنیده شدن نظرات تخصصی اهمیت بیشتری دارد. اگر این تعامل شکل نگرفته باشد، فرد دچار این برداشت می شود که نادیده گرفته شده، حتی اگر از نظر سازمانی ارتقا یافته باشد.
در لایه عمیق تر، این وضعیت می تواند نشانه یک بحران هویت شغلی باشد. برنامه نویسی که سالها هویت خود را بر اساس حل مسئله و تولید خروجی فنی تعریف کرده، اکنون در نقطه ای قرار گرفته که باید تعریف جدیدی از ارزش خود بسازد. اگر سازمان یا خود فرد به این بازتعریف توجه نکند، احساس سردرگمی، بی انگیزگی و طلب توجه افزایش می یابد. غر زدن در اینجا بیشتر یک علامت است تا مشکل اصلی؛ علامتی از این که فرد نمی داند دقیقا چه می خواهد و چه چیزی باید جایگزین انگیزه های قبلی شود.
در نهایت، مسئله نه در سن است و نه در عنوان شغلی، بلکه در نبود گفتگوی شفاف درباره انتظارات دو طرف و مسیر آینده نهفته است. اگر این فرد بتواند نقش خود را فراتر از یک برنامه نویس ارشد ببیند و تیم لید نیز او را به عنوان یک عامل اثرگذار و بالغ حرفه ای وارد تعامل کند، بخش زیادی از این نارضایتی فروکش خواهد کرد. بدون این هم راستاسازی، حتی ارتقاهای بعدی نیز تنها به عمیق تر شدن این احساس سردرگمی منجر می شوند.
راه حل در وهله اول از باز کردن یک گفتگوی صادقانه و بدون قضاوت آغاز می شود. فردی که دچار چنین سردرگمی شده، بیش از هر چیز نیاز دارد احساس کند شنیده می شود، نه اینکه صرفا مدیریت می شود. گفتگویی که در آن تیم لید به جای دفاع از تصمیم های گذشته یا ارجاع به ساختار سازمانی، درباره دغدغه ها، انتظارات و تصویر ذهنی این فرد از آینده شغلی اش پرسش کند، می تواند نقطه شروع بازسازی اعتماد باشد. این گفتگو باید به وضوح مشخص کند که ارتقای عنوان دقیقا به چه معنا بوده و چه انتظارات جدیدی از او وجود دارد.
در گام بعد، لازم است نقش فرد به شکل ملموس بازتعریف شود. کارشناس ارشد اگر همچنان همان کارهای قبلی را انجام دهد، طبیعی است که احساس بی اثری کند. سپردن مسئولیت هایی که نیازمند قضاوت، انتقال تجربه، یا اثرگذاری بر مسیر فنی تیم هستند، به او کمک می کند تا ارزش خود را در سطحی بالاتر از اجرای صرف کدها ببیند. این تغییر نقش باید واقعی باشد، نه نمادین، و خروجی آن نیز قابل مشاهده و قابل اندازه گیری شود تا حس پیشرفت درونی شکل بگیرد.
همزمان، خود فرد نیز نیاز دارد مسئولیت بخشی از این وضعیت را بپذیرد. عبور از مرحله وابستگی به توجه مستقیم لید، بخشی از بلوغ حرفه ای است. اگر او بتواند به جای انتظار برای دیده شدن، وارد حل مسائل کلان تر شود، پیشنهاد بدهد، مسیرها را نقد کند و از تجربه خود برای بالا بردن کیفیت تصمیم ها استفاده کند، به تدریج جایگاه جدیدش تثبیت می شود. این تغییر نگرش، احساس کنترل و معنا را به او باز می گرداند.
از منظر سازمانی، ایجاد مسیر رشد شفاف برای افراد باتجربه بسیار حیاتی است. وقتی مشخص نباشد بعد از کارشناس ارشد چه افقی وجود دارد، ذهن فرد پر از ابهام و مقایسه می شود. حتی اگر مسیر مدیریتی در کار نباشد، تعریف مسیرهای تخصصی، منتورینگ یا نقش های استراتژیک می تواند این خلأ را پر کند. شفافیت در این مسیرها از شکل گیری توقعات ناپیدا و نارضایتی های پنهان جلوگیری می کند.
در نهایت، حل این مسئله نیازمند زمان و پیگیری است، نه یک جلسه یا یک تصمیم مقطعی. بازخوردهای دوره ای، بررسی احساس فرد نسبت به نقش جدید و اصلاح تدریجی تعامل لید و کارشناس ارشد، کمک می کند تا این سردرگمی به یک گذار سالم تبدیل شود. اگر این فرآیند به درستی مدیریت شود، فرد نه تنها از وضعیت فعلی خارج می شود، بلکه می تواند به یکی از پایدارترین و تاثیرگذارترین اعضای تیم تبدیل گردد.
ناتوانی آموخته شده؛ زخمی که از گذشته می آید و آینده را می بندد وقتی در گذشته چند بار برای رسیدن به یک هدف تلاش کنیم و نتیجه نگیریم، کم کم باور میکنیم که «نمیتوانیم» و در نهایت حتی وقتی شرایط تغییر کرده باشد باز هم تلاش نمیکنیم. این باور مثل یک دیوار شیشه ای جلوی چشم ما قرار میگیرد. ما میتوانیم از آن عبور کنیم، اما مغز ما میگوید: «فایده ای ندارد، دوباره شکست میخوری». و همین جمله کافی است تا حتی دست به کار هم نشویم.
ریشه مشکل در کجاست؟ انسان ها از کودکی با موفقیت ها و شکست های کوچک و بزرگ روبرو میشوند. کودک وقتی چند بار سعی میکند کفش هایش را خودش بپوشد و موفق نمیشود و از طرف دیگر کسی به او میگوید «تو بلد نیستی» یا «بذار من انجام بدم»، کم کم باور میکند که واقعا نمیتواند. این باور همراه او بزرگ میشود و در حوزه های مختلف رشد میکند. در بزرگسالی هم همینطور است. یک کارمند که چند بار درخواست ارتقای شغلی اش رد شده باشد، ممکن است دیگر هیچ وقت درخواست ندهد، حتی اگر شایسته آن جایگاه باشد. یک دانشجو که چند بار امتحان ریاضی را خراب کرده باشد، شاید بعدا حتی برای یادگیری پایه ای ترین مفاهیم هم انگیزه نداشته باشد. این ها نمونه های معمول ناتوانی آموخته شده هستند. فرض کن فردی دو بار کسب و کار کوچکش را راه انداخته و هر دو بار شکست خورده است. بار اول به خاطر نبود تجربه کافی و بار دوم به خاطر شرایط بد اقتصادی. بعد از این دو شکست، او دیگر حتی فکر راه اندازی یک کسب و کار کوچک هم نمیکند، چون باور کرده «من توان این کار را ندارم». در حالی که اگر با تجربه های قبلی، این بار با برنامه ریزی دقیق تر شروع کند، شانس بالایی برای موفقیت دارد. ولی ناتوانی آموخته شده راه را بسته است.
گاهی افراد در برقراری ارتباط با دیگران شکست میخورند. مثلا چند بار دیده اند که حرف شان جدی گرفته نشده یا گروهی آنها را نپذیرفته. کم کم فکر میکنند که «من آدم اجتماعی نیستم» یا «هیچ کس من را نمیپذیرد». در نتیجه حتی وقتی در محیط جدیدی قرار میگیرند که آدم ها مهربان تر و پذیرا تر هستند، باز هم از برقراری ارتباط دوری میکنند و فکر میکنند نتیجه همان خواهد شد.
ذهن انسان به طور طبیعی به دنبال کاهش ریسک و صرفه جویی در انرژی است. وقتی مغز چند بار نتیجه منفی بگیرد، یک الگوی ساده میسازد: «این کار انجام نمیشود، پس تلاش نکن». این مکانیسم برای حفظ انرژی و جلوگیری از درد طراحی شده، اما در دنیای امروز این مکانیسم بیشتر از اینکه کمک کننده باشد، مانع رشد ما میشود.
ناتوانی آموخته شده یک محدودیت واقعی نیست؛ یک تصویر ذهنی است که در اثر تجربه های تلخ گذشته ساخته شده. اگر این تصویر را درست نکنیم، سال ها جلوی چشممان می ماند و آینده را تار میکند. اما اگر آگاهانه با آن روبرو شویم و قدم های کوچک اما مداوم برداریم، میتوانیم آن را شکست دهیم و مسیر موفقیت را دوباره بسازیم.
گاهی شما برای یک شرکت تبدیل میشوید به یک مهره ی سوخته. اما زمانی هم میرسد شرکتی که در آن فعالیت میکنید برای شما سوخته است و دیگر چیزی به شما اضافه نمیکند. در این حالت میگویم در زمین سوخته بازی نکنید. بازی در زمین سوخته، آن هم در دنیای کنونی که همه چیز به سرعت در حال تغییر است خطرناکترین پدیده است. چون شما با زمان و عمر خودتان در جنگید. چیزی که نه متوقف میشود و نه تبعات کوتاه مدتی دارد که هشدار دهنده باشد. به خودتان می آیید و میبینید بیش از حد در نقطه ای متوقف شده اید که به نفعتان نیست، چیزی به شما اضافه نکرده و به نشانه های آن هم توجهی نکرده اید. پذیرفتن این واقعیت که مجموعه ای که در آن کار میکنید چیز جدیدی به شما نخواهد افزود نشانه های متعددی دارد.
بزرگترین نشانه را باید درون خودتان جستجو کنید: احوالتان! از اینکه در فضای مجموعه قرار میگیرید احساس خوبی دارید؟ چقدر از توانتان را برای کارتان خرج میکنید؟ چقدر تمرکز دارید؟ چقدر به سمت تسک بیس شدن حرکت کرده اید؟ چقدر مسئولیت پذیریتان در این شرکت را حفظ کرده اید؟ چقدر امید دارید که در اینجا پیشرفت کنید؟
من آدمهای توانمندی دیده ام که صرفا چون در زمین سوخته شان بازی کرده اند، تبدیل شده اند به آدمهای ضعیف، فاقد اعتماد به نفس و بسیار شکننده. ترس از جابجا شدن، ترس از بیکاری و ترس از رها شدن آنها را در مورد خودشان منفعل کرده بود. گاهی باید به آدمها یادآوری کنیم که آنها عزت نفس دارد و باید برای آن حرکت کنند. باید به آنها نشان داد در زمینی شخم میزنند که دیگر بذری برای آنها رشد نخواهد داد. اما چگونه؟ بزرگترین چیزی این آدمها آن را گم کرده اند خودآگاهی است. آنها تصویر درستی از خودشان در آن سازمان ندارند. آنها درون خودشان همه چیز را عادی میبینند اما تعجب میکنند چرا هم رده های خودشان ارتقا میگیرند اما آنها نه. معمولا این نقص را نوعی بی عدالتی در مورد خودشان قلمداد میکنند و بیشتر درون خودشان فرو میروند. دیواری دور خودشان و شرکت میکشند و اجازه ی هیچ نوع انتقادی را نمیدهند چون به نظر آنها نوعی ظلم در موردشان جریان دارد.
برای ایجاد خودآگاهی لازم است به آنها یادآوری کنیم که مدتهاست چیزی از این زمین برداشت نکرده اند. بذر (کار) آنها بی نقص است، باهوش هستند و تلاش کرده اند اما این زمین دیگر برای آنها مناسب نیست. باید یادآوری کنیم که سن آنها منتظر اتفاقات و شانس نمی ماند و با سرعت رو به جلو در حرکت است. آیا 2 سال دیگر باز هم آنها توان آمدن و ماندن در این شرکت را دارند؟
آنها را قضاوت نکنیم. به آنها حمله نکنیم. باید در فضای کاملا حمایتی و بسیار ایزوله، خودآگاهی شان را فعال کنیم تا آن دیدی که ما و دیگران به آنها دارند را به خودشان پیدا کنند. تنها در این صورت است که به خروج فکر خواهند کرد.
در مورد آینده ی حرفه ای آنها صحبت کنید. یادآوری کنید که هیچ آینده ی حرفه ای در این شرکت با این فرآیند نخواهد داشت. آیا تمام آرزوهای کاری آنها همین نقطه ای است که در آن متوقف شده اند؟ به احتمال بسیار زیاد خیر.
این بسیار مهم است که شرکتی که دیگر چیزی برای شما ندارد نوع خاتمه همکاری با شما را “عدم تمدید قرارداد” درج کند یا “استعفا”. همگی از بار تبعاتی که این دو عبارت دارند اطلاع داریم. عزت نفستان چه میگوید؟ از زمین سوخته استعفا میدهید یا اجازه میدهید شما را از آنجا اخراج کنند؟ شما زمین سوخته را نمیخواهد یا آن شما را؟ در هر صورت چه به عنوان کسی که به این نتیجه رسیده در زمینی سوخته بازی میکند یا مدیری که باید این صحبتها را با یک فرد منفعل انجام دهد تا آن را به یک خروج با عزت هدایت کند این مقاله را میخوانید، همگی میدانیم که پول تنها هدف از شغل و کار نیست. ما کار میکنیم چون روح و روان ما به آن نیاز دارد و اگر کاری میکنید که روح و روانتان را آشفته میکند، آنرا ترک کنید. آن را تغییر دهید چون فرصت زندگی بسیار محدودتر از چیزی است که فکرش را میکنیم.
روایتی از نقطه بلوغ تیمی و اهمیت مهارت های نرم: تیم زمانی رشد میکند که آدمها بدانند چطور باید با هم کار کنند در یک مقطع از مسیر کاری خودم، درست مثل خیلی از رئیس ها یا مدیرانی که ابتدا بار پروژه ها را روی دوش تخصص فنی میگذارند، من هم تصورم این بود که اگر فردی از نظر تکنیکال قوی باشد، میتواند همه چرخ ها را به حرکت دربیاورد. سالها همین نگاه را داشتم. اما هر چه پروژه ها بزرگ تر شدند، هر چه تعاملات بین واحدی پیچیده تر شد و هر چه فشار زمانی و مسئولیتهای واقعی بیشتر شد، کم کم دیدم که آن چیزی که تیم را جلو میبرد فقط مهارت فنی نیست؛ بلکه چیزی عمیق تر و انسانی تر به اسم مهارت نرم یا سافت اسکیل (Soft Skill) است. این جا بود که نقطه عطف من شروع شد؛ جایی که فهمیدم “توانایی انجام کار”، با “توانایی همکاری”، “توانایی پذیرفتن مسئولیت” و “توانایی مدیریت رفتار و احساسات” زمین تا آسمان فرق دارد. تخصص فنی مثل یک موتور قوی است، اما سافت اسکیل ها سیستم کنترل و هدایت همان موتورند. موتور بدون هدایت، سرعت ایجاد میکند ولی تصادف هم رخ خواهد داد.
در همین مسیر به فردی در تیم رسیدم که مدتها کنارش کار کرده بودم. از نظر فنی، نسبتا قوی بود. همیشه وقتی چالش فنی داشتیم، او یکی از انتخابهای اول بود. اما با گذشت زمان و رشد پروژه ها، دیدم جایی گیر کرده ایم که دیگر با توانایی فنی حل نمیشود. تیم نیاز به بلوغ ارتباطی داشت. نیاز به واکنش حرفه ای در شرایط فشار داشت. نیاز به گزارش دهی دقیق، مدیریت زمان واقعی، درک اولویت ها، همکاری فعال و مسئولیت پذیری داشت. و دقیقا در همین نقطه بود که کمبودها خودش را نشان داد.
مشکل این نبود که بلد نیست کار فنی را انجام بدهد. مشکل این بود که: • در لحظه فشار، به جای تحلیل، واکنش احساسی نشان میداد • در مواجهه با اشتباه، بیشتر دنبال دفاع بود تا اصلاح • گزارش کارها نامنظم بود و تیم عقب میافتاد • مسئولیتهایش گاهی نیمه کاره میماند • در همکاری، شنیدن و فهمیدن طرف مقابل ضعیف بود • در تعاملات بین واحدی، زبان حرفه ای نداشت • در مدیریت زمان، تخمینها واقعی نبود • در مواجهه با تغییرات سریع، انعطاف رفتاری نداشت اینها دقیقا چیزهایی هستند که هیچ کامپایلری خطا نمیگیرد اما تیم را از درون دچار سکته میکند. من در این نقطه فهمیدم که اگر این فرد سافت اسکیل های خودش را تقویت نکند، هم خودش در مسیر حرفه ای آسیب میبیند و هم تیم در یک سقف نامرئی گیر میکند. هیچ تیمی با صرفا یک یا چند نفر فنی قوی رشد نمیکند؛ تیم زمانی رشد میکند که آدمها بدانند چطور باید با هم کار کنند. این مرحله برای من تبدیل شد به یکی از بزرگترین درسهای مدیریتی ام. اینکه: • آدم فنی قوی، الزاماً یک هم تیمی خوب نیست • تیم حرفه ای بدون بلوغ رفتاری شکل نمیگیرد • خروجی نهایی فقط نتیجه مهارت نیست، نتیجه رفتار است • اعتبار فرد در تیم، از نحوه برخوردش با سختی ها ساخته میشود • توانایی کنترل احساسات، مهمتر از توانایی حل مسئله است • شفاف حرف زدن و شفاف گزارش دادن، نصف مدیریت پروژه است • مسئولیت پذیری واقعی یعنی قبول کردن اشتباه بدون توجیه
امروز که به این نقطه رسیده ام، دیگر نگاه من به تیم فقط مبتنی بر عملکرد فنی نیست. من به این رسیده ام که سافت اسکیل ها ستون اصلی فرهنگ کاری هستند. بدون آنها، هر مهارت فنی بالاخره به بن بست میرسد. داستان من در این تجربه، داستان رسیدن به این درک است که برای ساختن یک تیم حرفه ای، باید اول آدمها را از نظر رفتاری و ارتباطی رشد داد. باید کمک کرد یاد بگیرند چطور گوش بدهند، چطور گفتگوی حرفه ای داشته باشند، چطور در بحران آرام بمانند، چطور مسئولیت نتایج کارشان را بر عهده بگیرند، چطور بازخورد بگیرند و چطور بازخورد بدهند. مهارت فنی آدمها “خروجی” میدهد، اما سافت اسکیلهایشان “رشد” ایجاد میکند. امروز رشد فردی اعضای تیم برایم مهم تر از خروجی های روزمره است. چون میدانم اگر این بلوغ شکل نگیرد، هیچ پروژه بزرگی به پایان درست نمیرسد.
پروژه نرم افزاری مثل سفارش پیتزا نیست که بشود در چند ثانیه قیمتش را حدس زد. هر پروژه نیاز به تحلیل، تعریف دقیق، تخمین زمان، درک ارزش، بررسی ریسک ها و محاسبه جزئیات دارد. اینکه بدون شناخت کامل پروژه، فقط یک ضرب ساده «تعداد ساعت × نرخ ساعتی» را به عنوان نسخه نهایی ارائه دهیم، نه حرفه ای است و نه به نفع فعالان این صنعت.
در اسکرین شاتی که مشاهده میشود، نویسنده پست در لینکدین از دوستانش درخواست میکند در مورد قیمت گذاری یک پروژه وب با او همفکری کنند. اما درست در بخش کامنت ها، یکی از کاربران بدون اینکه به هیچ یک از اصول حرفه ای قیمت گذاری، تعریف پروژه، سطح پیچیدگی، ریسک ها، تسک ها، یا حتی ساختار تیم اشاره کند، یک عدد خام و بسیار ساده ارائه میدهد: «ساعتی کار بدین، مثلا ۲۰۰ ساعت به ازای هر ساعت ۱ تومن.» این دقیقا همان سوتی بزرگ است؛ سوتی ای که نه تنها برای تیم های حرفه ای گران تمام میشود، بلکه باعث میشود برداشت عمومی از ارزش کار نرم افزاری به شکل خطرناک و اشتباه کاهش پیدا کند. پروژه نرم افزاری مثل سفارش پیتزا نیست که بشود در چند ثانیه قیمتش را حدس زد. هر پروژه نیاز به تحلیل، تعریف دقیق، تخمین زمان، درک ارزش، بررسی ریسک ها و محاسبه جزئیات دارد. اینکه بدون شناخت کامل پروژه، فقط یک ضرب ساده «تعداد ساعت × نرخ ساعتی» را به عنوان نسخه نهایی ارائه دهیم، نه حرفه ای است و نه به نفع فعالان این صنعت. این مقاله، دقیقا به همین دلیل و از دل همین سوتی شکل گرفته است. برای اینکه نشان دهد چرا قیمت گذاری نرم افزار نمیتواند «حدسی و سرانگشتی» باشد، و چرا تیم های ۱ تا ۳ نفره باید از یک روش علمی، منطقی و قابل دفاع استفاده کنند. اینکه برخلاف کامنت ناشیانه زیر آن پست، قیمت گذاری واقعی شامل چندین مرحله مهم است که اگر نادیده گرفته شوند، نتیجه آن برای تیم، برای مشتری و برای کل بازار مخرب خواهد بود. قیمت گذاری پروژه های نرم افزاری برای تیم های کوچک قیمت گذاری پروژه های نرم افزاری یک مرحله مهم و تأثیرگذار در شروع همکاری است. تیم های کوچک که معمولا بین 1 تا 3 نفر هستند، باید از روش های ساده و دقیق برای تخمین قیمت استفاده کنند تا هم هزینه های خود را پوشش دهند و هم اعتماد مشتری حفظ شود. قیمت گذاری درست، زمینه مدیریت زمان، کنترل ریسک و تضمین سود تیم را فراهم می کند. شناخت دقیق نیاز ها اولین گام، درک کامل از خواسته های مشتری است. هر نقطه مبهم می تواند زمان انجام پروژه را چند برابر کند. این موارد باید شفاف باشند: توضیح کامل امکانات، تعداد ماژول ها و بخش ها، فناوری های مورد نیاز، ارتباط بخش های مختلف و سطح امنیت و زیرساخت باشد. نادیده گرفتن این مرحله معمولا باعث ضرر مالی می شود. تخمین زمان واقعی تیم کوچک نباید خوشبینانه قیمت دهد. هر بخش باید جداگانه زمان بندی شود: تحلیل، طراحی، توسعه، تست و اصلاحات. بهتر است زمان تخمینی را ضرب در 1.3 کنید تا ریسک تاخیر پوشش داده شود. تعیین مدل قیمت: ساعتی یا ثابت مدل ساعتی در این روش مبلغ مشخصی برای هر ساعت تعریف می شود. مناسب برای پروژه های مبهم است. مزیت: انعطاف بالا عیب: نامشخص بودن مبلغ نهایی برای مشتری مدل ثابت مناسب برای پروژه های کوچک و مشخص. مشتری از اول مبلغ نهایی را می داند. تیم باید حدود 20 درصد برای تغییرات احتمالی لحاظ کند. توجه به ارزش پروژه قیمت فقط زمان نیست. گاهی پروژه ارزش بسیار بزرگتری برای مشتری ایجاد می کند: افزایش فروش، اتومات کردن فرآیند های زمان بر، کاهش هزینه های نیروی انسانی، پروژه های با ارزش اقتصادی بالا باید قیمت بالاتری داشته باشند. ارزیابی ریسک ها ریسک ها مستقیما روی هزینه تأثیر دارند. ریسک های رایج برای تیم های کوچک: تغییر نیاز های مشتری، نیاز به یادگیری فناوری جدید، وابستگی به سرویس های خارجی، محدودیت زمانی، ابهام در داده ها. قیمت باید بخشی برای پوشش این موارد داشته باشد. روش محاسبه ساده برای تیم های 1 تا 3 نفر
زمان کل را حساب کنید
نرخ ساعتی هر نفر را مشخص کنید
20 تا 30 درصد ریسک اضافه کنید
10 تا 20 درصد برای پشتیبانی بعد از تحویل بگذارید
مبلغ نهایی را رند کنید نمونه: اگر پروژه 120 ساعت زمان ببرد با نرخ 300 هزار تومان: • هزینه پایه: 36 میلیون • ریسک 20 درصد: 7 میلیون • پشتیبانی 10 درصد: 3.6 میلیون • مبلغ نهایی: حدود 46 میلیون تومان قرارداد شفاف قرارداد واضح اختلافات را کاهش می دهد. باید شامل این موارد باشد: محدوده دقیق کار، زمان بندی، تعداد دفعات اصلاح، شیوه پرداخت، شرایط فسخ، پشتیبانی. نحوه ارائه قیمت نحوه بیان قیمت به اندازه عدد آن مهم است. وقتی روند، زمان، چالش ها و دلیل قیمت واضح توضیح داده شود، احتمال پذیرش آن بالاتر می رود. تیم کوچک باید منظم و قابل اعتماد دیده شود.
در دسترس پذیر بودن یک نرم افزار ارتباط مستقیمی با نوع معماری دارد. یکی از بخش های تاثیر گذار در مبحث دسترس پذیری، مدیریت خطاها، اشتباهات و شناخت دقیق مسیرهای منجر به خاموشی سیستم است. یکی از دغدغه های معماران نرم افزار، مدیریت اشتباهات، خطاها و درنهایت شکستهای سیستم است. این مساله به قدری اهمیت دارد که یک بخش کامل در کتاب Software architecture in practice نوشته ی Paul Clements را به خود اختصاص داده است.
مدیریت خطاها همچنین بخشی زمانبر، پرهزینه اما به همان اندازه پرفایده از فرآیند توسعه و نگهداری نرم افزار است که باید در لایه ی معماری به آن پرداخته شود. اما قبل از اینکه وارد مبحث اصلی شوم، مایلم با مفاهیمی که شاید برای شما و من که بخصوص در ایران فعالیت میکنیم تازگی داشته باشد شروع کنم. این مفاهیم به تفاوت های اساسی بین واژه های اشتباه و خطا می پردازد که میتواند دید ما را به معماری سیستم در لایه تحلیل بهبود بخشد. یک تعریف ساده اما بسیار کلیدی: مجموعه ای از اشتباهات باعث ایجاد خطا میشوند. تکرار و تداوم خطاها باعث شکست سیستم میشود. بنابراین از نظر من یک اشتباه به خودی خود و به تنهایی شاید مهم نباشد. احتمالا اصلا دیده هم نمیشود و از زیر چشم تحلیلگران، توسعه دهندگان، تک لیدها و حتی QA عبور کرده باشد. اما توالی اشتباهات در یک سیستم قطعا منجر به بروز خطا خواهد شد. سیستم های پیچیده معمولا از جانب اشتباهات تکراری، ساده و کوچک شکست میخورند. در دنیای امروز که اعتقاد دارم مرز بین تکنولوژی های فرانت اند و بک اند دیگر مثل دهه های قبل خیلی قابل تفکیک نیست، اشتباهات فرانت هم در بروز خطا و شکست در بک اند و در نهایت کل سیستم موثر است. برای شما مثالی میزنم: تصور کنید در یک سیستم توسعه داده شده با React شما کلیدی دارید که با کلیک بر روی آن سرویسی فراخوانی میشود. تا آنجا که به کاربرنهایی و آنچه بر روی مانیتور خود میبیند مربوط است، اگر با یکبار کلیک بر روی این کلید، تا زمان دریافت Response (درست یا غلط) کلید Disable نشود، کاربر میتواند به طور مداوم روی آن کلیک کند و میتوانید حدس بزنید که اتفاقی خواهد افتاد: بالا رفتن بی دلیل بار ریکوئستها به سمت سرور و در نهایت بروز خطا در بهترین حالت و یا کرش کردن سیستم در بدترین حالت و از دسترس خارج شدن سیستم. هرچند که برای این موضوع روشهای متداولی در بک اند مانند Rate limiting و روشهای متنوع دیگری وجود دارد که از بروز این اتفاق جلوگیری کند، اما در اینجا یک اشتباه در فرانت صورت گرفته. چون طبق آنچه ما از فرآیندهای کاری یک تیم نرم افزاری میدانیم، فارغ از اینکه آیا تیم بک اند کار خود را بلد است و میداند کجا باید از Rate limit استفاده کند، توسعه دهنده فرانت هم باید کار خود را در نهایت ظرافت و وسواس پیش ببرد. پیش فرض هردو تیم باید این باشد که تیم مقابل ممکن است اشتباه کند پس ما باید تسک جاری را با رعایت حداکثر احتمالات ممکن تمام کنیم. در سناریوی بالا غیرفعال نکردن کلید فراخوانی سرویس در لایه فرانت زمانی که ریکوئست ارسال میشود، لزوما یک خطا نیست، اما حتما یک اشتباه است. روشن کردن یک نخ سیگار در انبار کاه و روشن کردن همان نخ سیگار در یک بیابان پیامدهای خیلی متفاوتی خواهد داشت. هنر معمار نرم افزار در برنامه ریزی برای شکستهای سیستم، هدایت تیم ها و تحلیلگران به سمتی است که کمترین خسارت ممکن حتی در صورت بروز برخی اشتباهات رخ دهد. چنین اشتباهاتی معمولا از دید تحلیلگران و حتی تیم QA پنهان هستند اما من معتقدم مسئولیت مستقیم آن برعهده ی Code Reviewer و تک لید تیم فنی ست. از مهمترین موضوعات در ساخت سیستمهایی با قابلیت دسترس پذیری بالا، درک ماهیت شکست هایی است که ممکن است در حین کار رخ دهد. وقتی به ماهیت شکست ها پی بردیم، میتوانیم استراتژیهای کاهش خسارت را در نرم افزار فراهم کنیم. علت شکست را خطا میگوییم. به طور مشخص لغت fault به خطا اشاره میکند. حالا این خطا میتواند دلایل داخلی یا خارجی داشته باشد. حالت های میانی بین وقوع خطا و وقوع یک شکست را اشتباهات مینامیم که به طور مشخص با لغت errors ساخته میشوند. ما همیشه به اشتباه خطاها را errors توصیف میکنیم، در حالی که خطا یک fault در سیستم است که میتواند حاصل چندین error یا اشتباه باشد. محاسبه دسترس پذیری تمام این مباحث برای بالابردن امکان در دسترس بودن سیستم است. ممکن است شما برای فروش یک سرویس یا سیستم مجبور به امضای یک SLA (توافق سطح سرویس) باشید. اگر در هر صورتی نتوانید یک SLA خود ارائه کنید، احتمالا بیزینس شما که بر مبنای آن سیستم بناشده است به ورشکستگی میرسد. درک تمایز بین اشتباهات و خطاها در زمان معماری سیستم میتواند ما را به طراحی نرم افزار برساند که در برابر شکستهای سیستمی مقاوم باشد.اما برای اینکه بسنجیم یک سیستم نرم افزاری چقدر برابر شکست ها مقاوم است فرمولی وجود دارد: MTBF = میانگین زمان بین شکست ها MTTR = میانگین زمان ترمیم
این فرمول باید به این صورت تفسیر شود که هنگام فکر کردن درباره ی دسترس پذیری، باید راجع به چیزی فکر کنید که موجب شکست سیستم شما میشود، احتمال وقوع آن شکست چیست و باید در یک مدت معین ترمیم شود.
تفاوت بنیادی بین معماری نرم افزار و تفکر سیستمی از یک منظر کاربردی آغاز میشود. اما واقعا چه تفاوتی بین معماری نرم افزار با تفکر سیستمی وجود دارد و درک این تفاوت چه فایده ای برای ما خواهد داشت؟ در یکی از پروژه های مهم شرکت که به محصولی استراتژیک ختم میشود، تیم توسعه با تیم محصول دچار یک مشکل اساسی شد. تیم توسعه معتقد بود جریان تولید محصول به دلیل فقدان تفکر سیستمی منحرف شده و ایرادات اساسی در پروژه وجود دارد. ادامه ی این اختلاف منجر به توقف موقت پروژه برای ارزیابی مشکل شد. آنچه از دید من بعنوان تک لید تیم توسعه رخ داده، حذف تفکر سیستمی و پرداختن جزئی به معماری نرم افزار در این محصول بود که به بهانه ی توسعه ی با متدولوژی اجایل اتفاق افتاد. این موضوع بهانه ای شد برای نوشتن این مقاله. در واقع من معتقدم بخش بزرگی از تعارضات بین تیم های توسعه و محصول از عدم درک تفاوت های ذاتی بین معماری نرم افزار و تفکر سیستم است. از منظر معماری نرم افزار، ساختار داخلی یک سیستم نرم افزاری اهمیت دارد. اینکه ماژولها، سرویسها، لایه ها و قراردادها بین بخش های مختلف چگونه با پیاده سازی میشوند. درواقع هدف اصلی معماری نرم افزار این است که بتواند با نقاط مشخص تماس و قراردادهای واضح، رفتار سیستم در مواجهه با نیازهای کاربر، مقیاس پذیری، نگهداری، امنیت و کارایی را تضمین کند. بنابراین وقتی به معماری نرم افزار نگاه میکنیم، معمولا سوالهایی در ذهن مطرح میشود: این ماژولها چه نقشی ایفا میکنند؟ دادهها چگونه در میان اجزا جریان پیدا میکنند؟ چه قراردادهایی برای ارتباط بین سرویسها تعریف شده است؟ چگونه میتوان در آینده با تغییرات کوچک، سیستم را با کمترین هزینه تغییر داد؟ اما در تفکر سیستمی دامنه ای گسترده تر وجود دارد که فراتر از مرزهای نرم افزار را شامل میشود. این رویکرد به تحلیل و طراحی کل سیستم و محیط آن نگاه میکند به ویژه در تعاملات میان اجزا، بازخوردها و پویایی بین فرآیندها و ذینفعان توجه میکند. تفکر سیستمی بر این نکته تاکید دارد که هر جز هر فرآیند و هر فناوری در یک شبکه ی پیچیده قرار دارد و تغییر در یک نقطه میتواند اثرات غیرمستقیم و گاهی پنهان در سایر بخش ها ایجاد کند. بنابراین در تفکر سیستمی باید به همپوشانی اجزا و Dependency های متقابل نگاه کرد. سوالات کلیدی که در تفکر سیستمی ایجاد میشود شامل این موارد است: هدف سیستم چیست؟ ورودیهای اصلی آن چه هستند و چه بازخوردهایی تولید میشوند؟ چه محدودیتهایی وجود دارد و چگونه میتوان به پایداری بلندمدت دست یافت؟ تغییر در یک بخش چگونه بر کل سیستم اثر میگذارد و چه همآهنگی با فرایندهای کسبوکار و ذینفعان وجود دارد؟ معماری نرم افزار و تفکر سیستمی در معماری نرم افزار (در دل سیستم) در تفکر سیستمی (دیدگاهی کلان تر) این ماژولها چه نقشی ایفا میکنند؟ هدف سیستم چیست؟ داده ها چگونه در میان اجزا جریان پیدا میکنند؟ ورودی های اصلی آن چه هستند و چه بازخوردهایی تولید میشوند؟ چه قراردادهایی برای ارتباط بین سرویسها تعریف شده است؟ چه محدودیتهایی وجود دارد و چگونه میتوان به پایداری بلندمدت دست یافت؟ چگونه میتوان در آینده با تغییرات کوچک، سیستم را با کمترین هزینه تغییر داد؟ غییر در یک بخش چگونه بر کل سیستم اثر میگذارد و چه هماهنگی با فرایندهای کسبوکار و ذینفعان وجود دارد؟ از نظر دامنه، معماری نرمافزار محدود به ساختار و رفتار نرمافزار است و با تصمیمهای فنی مربوط به طراحی، پیادهسازی و نگهداری سروکار دارد. تفکر سیستمی اما کل سیستم و محیط آن را میبیند؛ از ابعاد فنی تا فرایندهای کسبوکار، دادهها، فناوریهای دیگر و محدودیتهای محیطی و اقتصادی را در یک چارچوب یکپارچه مطالعه میکند. از منظر ذینفعان به چه صورت است؟ در رابطه با ارتباط با ذینفعان، معماری نرمافزار عمدتاً با تیمهای فنی، مدیران فناوری و سایر افراد دخیل در توسعه نرمافزار در تعامل است و غالباً در جلسات طراحی و تصمیمگیری درباره فناوریها و معماری لازم بهکار گرفته میشود. تفکر سیستمی اما با نقـشها و فرآیندهای کسبوکار، کاربران نهایی، تأمینکنندگان، سازمانهای مربوط به محیط قانونی و اقتصادی و حتی جامعهی کاربران سروکار دارد. به این معنا، تفکر سیستمی دیدی از سیستم است که با فشارها و محدودیتهای محیطی و اقتصادی نیز سروکار دارد و به پایداری بلندمدت و همزمانی میان اجزا و فرایندها اهمیت میدهد. جمع بندی رویکرد عملی به ترکیب این دو نگاه منجر میشود تا بتوان سیستمهای پیچیده را بهروایت دقیقتری طراحی کرد. از یکسو باید معماری نرمافزار را با استفاده از الگوهای معماری مناسب، APIهای واضح، قراردادهای بین سرویسها و نگرشهای مدرن مانند میکروسرویس یا رویکرد سرویسگرایی بهگونهای طراحی کرد که اجزای نرمافزار با هم به خوبی کار کنند و قابلیت نگهداری و گسترشپذیری را فراهم کنند. از سوی دیگر باید با تفکر سیستمی به تحلیل الزامات کسبوکار، فرایندها، دادهها و محدودیتهای محیطی پرداخت تا بتوان به یک راهحل جامع دست یافت که نه تنها از منظر فنی کارایی خوبی داشته باشد بلکه با محیط کسبوکار و ذینفعان همسویی کامل داشته باشد.
ذینفع کیست؟ کاربران نهایی، مالکین محصول/بنگاه، تیمهای توسعه و فنی، تیمهای عملیات و پشتیبانی، ذینفعان سازمانی/سایر واحدها، تامینکنندگان و شرکای فناوری، کاربران خارجی و جامعه، نهادهای قانونی و استاندارد.
منطقی نیست که افراد باهوش را استخدام کنیم و بعد به آنها بگوییم چهکار کنند. ما افراد باهوش را استخدام میکنیم که آنها به ما بگویند باید چهکار کنیم.
چالشی که در تیمهای نرم افزار غالبا از سمت افراد باتجربه (و نه جونیور) رخ میدهد، مواجهه با کارشناسانی است که میگویند: ” من همیشه منتظر بودم که فلان تسک را به من بدهید، اما هیچوقت اینکار را نکردید”. این انتقاد به رهبر تیم معمولا زمانی رخ میدهد که در جلسات فیدبک از انفعال کارشناس انتقاد میکند. اما آیا واقعا این انتقاد به شما وارد است؟ شما افراد را محدود میکنید یا آماده پذیرش نظرات کارشناسانه ی آنها هستید؟ تمایلِ کنترل محور: میخواهم همه چیز را خودم مشخص کنم تا از خطا جلوگیری شود. میل به آزادیِ کامل: میخواهم به تیم اعتماد کنم و اجازه بدهم هر کس با سبکِ خودش کار را پیش ببرد. شما بعنوان رهبر تیمتان باید دو روش انتخاب کنید. یا تمایل به کنترل یا میل به آزادی عمل.
واقعیت این است که این دو گرایش معمولا با هم سازگار نیستند. اما میشود با ایجاد چهارچوب های مشخص و فرآیندهای بازخورد مستمر تعادلی پایدار ایجاد کرد. چرا افراد باهوش غالبا منفعل هستند؟ این جمله ی استیو جابز را پرینت کردم و روی یکی از دیوارهای اطراف تیممان نصب کردم. من واقعا دلیل انفعال افراد باهوش تیمها را نمیدانم، فقط هربار که این بازخورد را به آنها داده ام، نتیجه ی خوبی گرفتم. بنابراین تصمیم گرفتم این جمله را مدام به آنها یادآوری کنم که شما باید به ما بگویید که چه کنیم و اصلا برای همین شما را استخدام کردیم! منطقی نیست که افراد باهوش را استخدام کنیم و بعد به آنها بگوییم چهکار کنند. ما افراد باهوش را استخدام میکنیم که آنها به ما بگویند باید چهکار کنیم. استیو جابز اما برای پاسخ به پرسش بالا، ممکن است راهکارهای زیر موثر باشند: فرهنگ سازی کنیم: وقتی تیم یا سازمان فضای امنی برای ابراز ایدهها فراهم نمیکند، افراد باهوش یا محتاط میشوند یا سکوت میکنند تا از انتقاد یا اشتباه جلوگیری کنند.فرهنگ بازخورد سازنده و «چارچوب نقد سازنده» ایجاد کنید. تأکید کنید که هر ایده ارزشمند است، به شرط ارائه مستندات و دادههای پشت آن. تقسیم درست مسئولیتها: هوشمندها معمولاً به خوبی ریسکها را میشناسند و ممکن است از عواقب اشتباه بترسند. این ترس میتواند به عدم مداخله یا ارائهٔ راهحل منجر شود. قسیم مسئولیتها به گونهای که هر کس بداند چه تصمیمی را میگیرد و چه دادههایی لازم است، و اینکه اشتباه فرصت یادگیری است. ارائه زمانبندی منطقی: تعیین زمانبندیهای منطقی برای تحلیل و تصمیمگیری و احترام به فرایند آزمایش-یادگیری (Experimentation-and-learning). تشویق به ارائهٔ آزمایشهای کوچک و نتایج قابل اندازهگیری. با مطالعه و تحقیق بیشتر راه حل و پیشنهادات زیادی میتوان به این لیست اضافه کرد که افراد باهوش منفعل را به افراد باهوش سوپراستار تبدیل کرد.
با حضور پررنگ هوش مصنوعی، برخورداری از تفکر سیستمی میتواند در آینده ی نزدیک از بیکار یا کم کار شدن برنامه نویسها جلوگیری کند.اما چگونه یک برنامه نویس به مهندس نرم افزار تبدیل میشود؟ در این مقاله مسیر حرکت برای تبدیل شدن یک کدنویس به فردی دارای تفکر سیستمی را بررسی خواهیم کرد.
سیستم چیست؟
برای درک فرآیند تفکر سیستمی، ابتدا باید مفهوم سیستم را به خوبی درک کنیم. سیستم چیست و اصولا به چه چیزی میگوییم سیستم؟
به زبان ساده، سیستم مجموعه ای از عناصر یا اجزاست که با هم کار میکنند تا یک هدف یا نتیجه خاصی را ایجاد کنند.هر جز در عملکرد یک سیستم نقش دارد و با سایر اجزا تعامل برقرار میکند.
بنابراین وقتی میگوییم سیستم، معمولا به سه نکته اشاره میکنیم:
اجرا یا عناصر: هر سیستم از چند جز تشکیل شده است.
روابط و تعامل ها: این اجزا از طریق قوانین یا فرآیندهای مشخصی با هم در ارتباط هستند.
هدف یا خروجی: یک سیستم برای دستیابی به یک هدف یا تولید یک خروجی مشخص ایجاد میشود.
حال سیستم ها ویژگیهای رایجی هم دارند. مانند بازخورد از خروجی سیستم به ورودی برای مثلا تنظیمات بهتر، محیط سیستم، مثل اینکه ورودیهای سیستم از چه محیط دریافت میشودو مجموعه پذیری و ساختارمندی که میتواند سیستم را به صورت سلسله مراتبی یا شبکه ای با زیرسیستمهای دیگر هماهنگ کند.
بنابراین میتوانیم از طریق این نکات وجود یک سیستم را به روشهای زیر تشخیص دهیم:
وجود چند جز که با هم کار میکنند.
وجود هدف یا نتیجه مشخص.
وجود ارتباطات و بازخوردها بین اجزا.
وجود محدودیت ها و محیطی که سیستم در آن عمل میکند.
بعد از درک اینکه سیستم چیست، میتوانیم تعریف مشخصی از سیستم در دنیای نرم افزار داشته باشیم. شاید نزدیکترین تعریف از سیستم، ایجاد فرآیندی است که با دریافت ورودیهایی، خروجی های مورد انتظار را برای کاربر تولید میکند. از لحظه دریافت ورودی یا لحظه ایجاد خروجی، در دل این فرآیند سیستمی، اجزایی پیچیده یا ساده مشغول اجرای مجموعه کارهایی هستند که با تعامل با یکدیگر هدف نهایی را تولید میکنند.
بعنوان مثال، عملیات ورود کاربران به یک سامانه را برای شما ساده سازی و تشریح میکنم و میبینیم که آیا این عملیات میتواند یک سیستم باشد؟
برای چنین هدفی، باید فرمی برای ورود نام کاربر و رمز عبور وجود داشته باشد. سپس یک فرآیند باید نحوه ورود اطلاعات را در فرم ارزیابی کند. بعد از آن اطلاعات دریافت شده باید با مخرنی از اطلاعات از قبل ذخیره شده تطابق داده شوند. در صورت صحیح بودن این اطلاعات عملیاتی برای تثبیت کاربر در سامانه انجام و یا در غیر اینصورت، پیام خطایی به کاربر نمایش داده شود.
کل این فرآیند از اجزای فرم، مکانیسم Validation، ارتباط با دیتابیس، بانک اطلاعاتی و پیام رسانی تشکیل شده اند که به تنهایی کار خاصی انجام نمیدهند اما در تعامل با هم در یک سلسله مراتب مشخص، هدف ارزشمندی را انجام میدهند. هدف مشخصی دارد، ارتباطات و بازخورد دارد، از محیط پیرامون خود جهت دریافت ورودی استفاده میکند و محدودیتهایش مشخص شده است. بنابراین به این فرآیند میتوانیم سیستم احراز هویت بگوییم.
تفکر سیستمی
پس از درک مفهوم سیستم، وقت آن است که به موضوع تفکر سیستمی بپردازیم. منظور از تفکر سیستمی چیست و یک برنامه نویس چطور میتواند سیستمی فکر کند و این چه تاثیری در او و عملکرد او ایجاد میکند؟
یک برنامه نویس را (بدون توجه به سطح آن – حرفه ای یا غیر حرفه ای) در نظر بگیرید که درک کاملی از تمام اجزای یک سیستم دارد. اما اگر به شکل بالا که نمونه یک سیستم ساده ی Authentication (احراز هویت) است نگاه کنید، میبینید که خطوطی که تعامل اجرا را با یکدیگر شکل داده اند درنهایت اجزا را به یک دیگر متصل کرده و تشکیل یک سیستم داده اند.
به این که این خطوط و این تعامل چگونه بین اجزای یک سیستم شکل میگیرند، تفکر سیستمی میگوییم.
حال بیایید همان شکل شماتیک را بدون خطوط متصل کننده اجزا ببینیم:
بدون خطوط تعاملی و متصل کننده اجزا به هم، سیستم ما شکل منسجمی ندارد. درواقع یکسری اجزا خواهند بود که نوع ارتباط آنها با یکدیگر مشخص نیست. این سیستم اکنون از دید یک برنامه نویس بدون تفکر سیستمی، تنها لیستی نامرتب از اجزایی خواهند بود که در یک سیستم احراز هویت از او خواسته شده تا تولیدشان کند:
میبینید که از دید فردی که بجای مکانیسم، لیستی از فیچرها را میبینید، همه چیز بهم ریخته، مبهم و پیچیده است. یک برنامه نویس بدون درک سیستمی که مشغول خلق آن است حتی نمیتواند چیدمان درستی از اولویت فیچرها را ترسیم کند. هرچند که ممکن است بتواند یک فیچر را با دقت عملکردی زیادی بنویسید اما از کنار هم چیدن درست آنها و درک تعامل آنها باهم احتمالا عاجز است. بنابراین زمانی میتوانیم بگوییم یک برنامه نویس مجهز به تفکر سیستمی شده است که بتواند اجزای سیستم را به هم متصل و خروجی مورد انتظار را از آن دریافت کند.
مسیر رسیدن به تفکر سیستمی برای یک برنامه نویس چگونه است؟
من یک رودمپ مشخص برای شما ترسیم میکنم. مسیری که خودم رفتم و از نظر من پاسخگو است.
ابتدا باید بتوانید دید معماری و طراحی خودتان را تقویت کنید. بهتر است اول به سراغ مفاهیم معماری ساده و متداولی مثل MVC/MVVC بروید. بعد ذهن خودتان را به سمت معماری های سرویس گرا (SOA)، میکروسرویس ها و Event-driven هدایت کنید. این معماری ها به دلیل وجود کامیونیتی های بسیار منابعی غنی از یادگیری معماری و اصول آنرا به در اختیارتان قرار میدهند.
سپس شروع به تمرین کنید: طراحی سیستمهای کوچک. بعنوان مثال با چند ماژول ساده شروع کنید و سعی کنید قابلیتها و محدودیتهای ناشی از تعامل با سایر ماژول ها مدل کنید.
مدل سازی در نرمافزار به فرایند ایجاد نمایش های مبهم یا پیچیدهٔ یک سیستم به صورت ساده و قابل فهم است تا بتوان با آن طراحی، تحلیل و پیادهسازی را بهتر انجام داد. مدلها نماینده ای انتزاعی (ساده شده) از بخشهای مختلف سیستم اند که الزامات، رفتارها و ارتباطات بین اجزا را بیان میکنند بدون اینکه به جزئیات پیادهسازی ریزهکاریهای کد اشاره کنند.
گام بعدی میتواند تحلیل سیستم عملی باشد. بعنوان مثال وب سرویس سفارش آنلاین را کاملا تجزیه و تحلیل کنید. نقشه ارتباطات و تعاملات آنرا رسم کنید و سعی کنید بفهمید اولویتها در این چنین سیستمی چطور ترسیم شده.
فراموش نکنید باید در مقام طراح و معماری سیستم دوستی بخصوصی با کاغذ و قلم یا ابزارهای دیجیتال برای رسم ارتباطات داشته باشید. من ابزار آنلاین Draw.io را که مدتهاست خودم از آن استفاده میکنم پیشنهاد میکنم. این سامانه یک ابزار غنی برای رسم سریع از چرکنویس تا طراحی های نهایی در فازهای تحلیل و طراحی سیستمهای نرم افزاری ست. حتی اگر مثل من سنتی باشید، علاقه بسیاری پیدا خواهید کرد تا معماری هایتان را پرینت کنید تا وقتی دراز کشیده اید بتوانید بازهم آنها را مطالعه و گره های دیده نشده طراحی تان را پیدا کنید.
پیشنهاد میکنم هر هفته یک پروژه یا بخشی از سیستم را به طور هدفمند بررسی کنید. اینکه چخ مشکلاتی دارد؟ رفتارها چگونه است؟ چه بازخوردی از کاربران یا سایر اجزا میگیرید؟
سپس هر دوهفته یک “بازبینی معماری” ساده انجام دهید. آیا شرایط تغییر میکند؟ آیا طراحی پاسخگوی نیازهای آینده است؟
استفاده از نقشه های معماری
نقشه های معماری کمک بسیار بزرگی در ویژوال کردن افکار یک طراح سیستم دارند. آنها میتوانند پیچیده ترین مسائل را به صورت انتزاعی رسم کنند تا هم بتوانند دید وسیعتری از افکارشان بدست آورند و هم قادر باشند آنرا به دیگران با پیچیدگی کمتری توصیف کنند.
در این بین من شخصا علاقه خاصی به UML دارم. حتی اگر در ابتدایی ترین قدمهای ورود به عرصه ی طراحی یک سیستم باشید، تنها با رسم چند شئی از UML میتوانید یک سیستم ساده طراحی کنید. اما آنچه باید در UML در تفکر سیستمی به دنبالش باشید، مدلهای ساختاری یا Structure diagrams است.
مدلهای ساختاری UML تمرکز اصلی شان تبین ساختار سیستم به صورت ویژوال است تا رفتار آن را بتوان با خیال راحت تری طراحی کرد. در این مدلها بیشتر به اینکه “چه چیزهایی وجود دارند و چگونه به هم وصل میشوند” پرداخته میشود تا اینکه “چه اتفاقی میافتد و چگونه اجرا میشود”. دوراقع وجود اشیا در سیستم و ارتباط آنها با یکدیگر در این فاز اولویت دارد به درک اینکه چه اتفاقی در این تعامل میوفتد یا چگونه اجرا میشوند.
اما فایده ی ذاتی مدلهای ساختاری UML چیست؟ میتونم به طراحی قابل نگهداری اشاره کنم. شما با مشاهده کلاسها و روابط میتوانید نقاط تکرار، وابستگی های سنگین و نقص ها را در طراحی تان کشف کنید.
همینطور مشخص میشود چه ارتباطی با دیگر ذینفعان غیرفنی پروژه خواهید داشت. مانند مدیرپروژه یا تحلیلگران کسب و کاری.
مدیریت پیچیدگی ها که حاصل از تفکیک سیستم به ماژولها و تعریف قراردادهای واضح بین آنهاست از فواید دیگر استفاده از مدلهای ساختاری است. در نهایت ارتباطی که این شکل طراحی در نگاه به کل سیستم، روابط بازخوردی و جریان داده دارد به فرایند ایجاد تفکر سیستمی در فرد کمک میکند.
جایگاه تحلیل در تفکر سیستمی
تحلیل به تعیین حدود سیستم، عناصر کلیدی و روابط به آنها منجر میشود. با تحلیل میتوان مرزهای زیرسیستمها را مشخص کرد تا نگاه شما به کل سیستم روشنتر شود.بنابراین تحلیل در تفکر سیستمی میتواند دامنه کار را واضح تر کند.
تفکر سیستمی به بازخوردهای مثبت و منفی اهمیت میدهد.تحلیل کمک میکند تا بفهمیم چه بازخوردهایی وجود دارد، چگونه موجب پایداری یا ناپایداری میوشند و چگونه تاخیرها میتوانند رفتار سیستم را تغییر دهند. با مدلسازی که در بالا اشاره کردم میتوانید مسیر این بازخوردها را دنبال کنید.
همچنین تحلیل کمک میکند تا لایه های تصمیم گیری و قیود را مشخص کنید و میتوانید ببینید در چه جاهایی تصمیم ها و فشارهای فنی به یکدیگر میرسند. این کار به طراحی راهکارهایی با پایداری بلندمدت و قابلیت ارتقا میکند.
تحلیل قبل از اجرا به تشخیص اثرات جانبی تغییرات در یک جز میپردازد که برای جلوگیری از شکستهای غیرمنتظره در سیستمهای پیچیده حیاتی است.
در تحلیل میتوانید از سناریوی جادویی what-if پاسخ سیستم به تغییرات را پیشبینی کنید.
سناریوهای what-if، تمرینی است برای بررسی “اگر فلان اتفاق بیفتد چه میشود؟” با هدف درک اثرات احتمالی و انتخاب بهینه، بسیار در تحلیل یک سیستم و واکنش به بازخوردها موثر است.
اما شروع یک تحلیل در کمک به تفکر سیستمی چگونه باید باشد؟ از نظر من همیشه با سوال های کلیدی شروع کنید:
– هدف سیستم چیست؟ – کاربران چه کار میخواهند انجام دهند؟ – چه بازخوردی وجود دارد؟
برای پاسخ به این سوالات از مدلهای سطح بالا شروع کنید و به تدریج به جزئیات بپردازید. منظور از مدلهای سطح بالا، مدلهای بسیار ساده سازی شده انتزاعی است که جزئیات بسیار محدودی در آنها وجود دارد. در انتها باید تحلیلهای انجام شده را با ذینفعان به اشتراک بگذارید و بازخوردها را دریافت و از این طریق تحلیلتان را اعتبارسنجی کنید.
تمرینی برای تفکر سیستمی
امیدوارم تا اینجا مفهوم تفکر سیستمی، اجزای آن و کاربرد آن برای شما روشن باشد. اگر بخواهید میتوانید با تمرین زیر این مسیر را ادامه دهید: طراحی یک سیستم مدیریت موجودی ساده با دیدگاه تفکر سیستمی.
هدف از این تمرین درک بازخوردها و اثرات جانبی تغییرات در یک سیستم کاملاً ساده و مرکز بر روابط بین تقاضا، موجودی، سفارش و هزینه است.
گامها:
تعیین هدف سیستم
مثلاً: نگهداری موجودی بهگونهای که هزینه نگهداری کمین باشد و سطح سرویس مشتری بالا بماند.
شمای کلی اجزا (IDEA را در ذهن تمرین کنید)
Demand (تقاضا)
Inventory (موجودی)
Reorder Point/Order Quantity (نقطه بازنشانی و مقدار سفارش)
Supplier/Lead Time (فروشنده و زمان تحویل)
Costs (هزینههای نگهداری، خرید، کاهش موجودی، تاخیر در تحویل)
مشخص کردن بازخوردهای کلیدی
بازخورد منفی: اگر موجودی خیلی پایین باشد، سطح سرویس کاهش مییابد و مشتریان از دست میروند.
بازخورد مثبت: اگر تقاضا بالا رود و موجودی محدود باشد، شاید سفارش بیشتری بدهیم، اما هزینه نگهداری افزایش میابد.
تاخیرهای زمانی: با طولانی شدن زمان تحویل، نیاز به افزایش امنسای یا سطح موجودی داریم.
مدل ساده (زبان ساده یا نمودار کُدی)
یک مدل مفهومی با سه متغیر:
موجودی فعلی (I)
تقاضای دورهای (D)
سفارش جدید (Q)
قوانین ساده:
اگر I <= reorder_point، سفارش جدید به اندازه (Q) داده میشود.
هزینهها: نگهداری = نگهداشتن موجودی در هر دوره، خرید=قیمت واحد * مقدار سفارش، کمبود = هزینه بابت عدم تامین در صورت کمبود.
سناریوهای what-if ساده
سناریو A: تقاضا افزایش مییابد (D ↑)
سناریو B: زمان تحویل از supplier طولانیتر میشود (Lead Time ↑)
سناریو C: قیمت واحد کالا کاهش مییابد (قیمت ↓) برای هر سناریو: تخمین کنید چگونه I، هزینهها و احتمال کمبود تغییر میکند.
تحلیل نتایج
مقایسه سه سناریو با حالت پایه: کدام سناریو کمترین هزینه کل را دارد با حفظ سرویس مناسب؟
سوالات تفکر سیستمی: آیا تغییر در یک جزء (مثلاً Lead Time) چه اثراتی بر سایر اجزا دارد؟ آیا باید تغییراتی در reorder_point یا Q بدهیم؟
