<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های Moodi</title>
        <link>https://virgool.io/feed/@moodi</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-06-07 08:54:00</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/90174/avatar/WUEybi.png?height=120&amp;width=120</url>
            <title>Moodi</title>
            <link>https://virgool.io/@moodi</link>
        </image>

                    <item>
                <title>برنامه نویسی نامرد</title>
                <link>https://virgool.io/fboard/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D9%86%D8%A7%D9%85%D8%B1%D8%AF-ytblpti3ezui</link>
                <description>حتما در مورد ورزش بدن سازی و زیبایی اندام این جمله رو شنیدید که میگن ورزش نامردیه!دلیل اصلی این حرف در واقع این هست که شما وقتی توی بدن سازی به یک نقطه قابل قبولی میرسی، این که توی اون نقطه بمونی خیلی سخته و به محض قطع کردن تمرین بدنت از فرم خارج میشه و بعد از مدت کوتاهی انگار نه انگار.البته سرعت این از بین رفتن به خیلی مولفه ها بستگی داره ولی چون موضوع بحث ما نیست ازش عبور میکنیم.با این مقدمه میخوام عرض کنم شغل و حرفه ی برنامه نویسی به مراتب نامرد تر از ورزش بدنسازیه به دو دلیل:اول:  سرعت تغییرات و رشد توی این علم خیلی زیاده و شما میتونید این علم رو با بقیه علوم یا حرفه ها مثل مهندسی عمران یا مکانیک و ... مقایسه کنید. شما یک مهندس عمران 20 سال پیش رو با مهندس امروز مقایسه کنی میبینی که چارچوب علم هر دو تقریبا یکی هست و جزییاتی عوض شده. یا حتی میتونی کتابهای مربوط به اون رشته رو نگاه کنی. (کتاب های برنامه نویسی یا معماری نرم افزاری که 20 سال پیش نوشته شدن الان به عنوان کاغذ باطله هم شاید به درد نخورن)دوم: محصولی که تو رشته های دیگه تولید میشه سالها میتونه استفاده بشه و حتی بعد از اون به موزه منتقل میشه. مثل خودرو کلاسیک میشه و مخاطب خودشو پیدا میکنه، یا بنای ساخته شده به آثار باستانی و حتی میراث فرهنگی تبدیل میشه. ولی خب نرم افزاری که مثلا 20 سال پیش با فاکس پرو تولید شده الان همه بهش میگن آشغال !شاید برای دوستانی که قدمتشون بیشتره زرنگار مثال بدی نباشه. تو زمان خودش غوغا کرد. ولی خب الان هیچ اثری ازش نیست. یا مثالهایی دیگه ای مثل NC، MS-DOS یا Q-Basic یا چیزهای دیگه.برای مورد اول راه حل هایی وجود داره. مثلا اینکه همیشه یه وقت قابل قبولی برای خودت بذاری و بتونی خودتو بروز نگه داری. ولی در عمل کار سختیه. چرا که وقتی تو کارت پیشرفت میکنی (تا ابد که نمیتونی دولوپر ساده باشی)، توقعات ازت بیشتر و بیشتر میشه. به همین خاطر پروژه ها و تسک های بیشتری سمتت میاد و این خودش مانع از رشد فنی ات میشه هرچند ممکنه ارتقای سازمانی برات داشته باشه. یا مثلا اینکه کم کم از کار اجرایی فاصله بگیری و بیشتر وقتت رو صرف مطالعه یا مشاوره کنی که بروز بمونی.برای مورد دوم ولی راه حل خاصی وجود نداره. شاید بشه گفت در حد یک ایده میشه دنبالش کرد. یه موزه مجازی یا واقعی درست کرد از زبانهای برنامه نویسی، یا محصولات خاص تولید شده تو زمان خودش.</description>
                <category>Moodi</category>
                <author>Moodi</author>
                <pubDate>Fri, 25 Mar 2022 21:17:11 +0430</pubDate>
            </item>
                    <item>
                <title>قوانین فیزیک و نرم‌افزار</title>
                <link>https://virgool.io/@moodi/%D9%82%D9%88%D8%A7%D9%86%DB%8C%D9%86-%D9%81%DB%8C%D8%B2%DB%8C%DA%A9-%D9%88-%D9%86%D8%B1%D9%85%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-bjpdn2vrwisu</link>
                <description>برای راه‌اندازی یک پروژه برای کارفرما، یک سری از فاکتورها هستن که بدجوری جلوی کار رو می‌گیرن و از قضا اصلا توی ریسک‌های پروژه دیده ‌نمی‌شن. در این نبشه میخوام یکی از اون‌ها رو بعلاوه راه‌حل‌ شرح بدم و در مقاله‌های بعدی هم دونه دونه چیزهایی که بهش برخوردم و رویکردهایی که ازشون جواب گرفتم رو خواهم گفت. اگه به درد کسی هم نخوره، لاقل خاطره که میشه.اینرسیاین واژه یک اصطلاح فیزیکیه ولی خب در مورد کارفرمایی به کار میره که در حال حاضر یک سیستم برای انجام فرآیندهاش داره و از قضا اون سیستم رو هم یاد گرفته و ازش راضیه. حفره‌هاش رو می‌شناسه و در مجموع برای اینکه بیاد توی یک سیستم جدید حسابی مقاومت می‌کنه و می‌خواد با همون وضعیت ای بسا تا ابد هم پیش بره. مثلا موقع نیازسنجی و مصاحبه تمام فرآیند رو شرح نمی‌ده تا سیستم جدید ناقص تولید بشه و بتونه ازش ایراد بگیره و اصطلاحا هواش کنه.از کوچک‌ترین چیزای ساده موقع تحویل سیستم جدید ایراد می‌گیره و هی می‌خواد ثابت کنه که سیستم قبلش بهتره و نیازی به سامانه جدید نیست. سعایت و بدگویی می‌کنه. حتی تخریب شخصیتی می‌کنه شاید باورتون نشه و این مورد بیشتر در لایه‌های بالادستی و مدیران هست که شاید به نظر غیرمحتمل میاد، ولی من تجربه‌اش کردم.با فشار زیاد و ارسال حجم زیادی از نیازمندی‌های جدید می‌خواد تو رو درگیر توسعه و پشتیبانی کنه تا نتونی به تولید برسی و اون وقت هم از عقب افتادگی‌‌ت توی تولید سوء استفاده کنه و هم از طرفی تولید رو عقب بندازه و با سامانه قبلیش زندگی کنه.  اینا فقط نمونه‌هایی از مشکلاتی که به اینرسی بر‌میگرده بود و زیاد وارد جزئیات نمی‌شم. اما:راه‌حلبا افزایش میزان شفافیت می‌شه تا اونجایی که می‌شه اعتماد بهره‌بردار رو جذب کرد تا اگر کسی صرفا از روی تنبلی مرسوم مقاومتی داره از مسیر کنار بره. مثلا ما برای این کار بعد از شناسایی هرکدوم از آدما‌ی بهره بردار، برای اونهایی که واقعا از سر دلسوزی مقاومت میکردن، یک سری جلسات گذاشتیم تا شیوه تولید و اجرا رو هم باهاشون مشورت کنیم، حتی اگر در نهایت بازم روش خودمون رو اجرا کردیم، ولی این حس رو القا کردیم که این محصول نهایتا برای شماست.جلوی توسعه و حتی پشتیبانی اون سیستم قدیمی رو گرفتیم تا کم کم احساس کنن که این سیستم دیگه پاسخگوی نیازشون نیست و عملا درخواست ها در سامانه جدید پیاده سازی شده و به بهره‌برداری خواهد رسید.تا می‌تونستیم و سیاست‌های بالادستی و پلن تولیدمون اجازه میداد، امکانات در سیستم جدید اضافه می‌کردیم و سعی می‌کردیم کاری کنیم تا بهره‌برداران نرمال رو که منطق سرشون می‌شه جذب سیستم جدید کنیم.با بررسی شرایط بعضی از نفرات که کار فنی بلد بودن و به همین دلیل ساده همیشه منتقد و صاحب نظر بودن! و هی سنگ اندازی میکردن رو با یک ملاحظاتی وارد تیم تولید کردیم تا اگر واقعا اینکاره هستن بیان کمک کنن که برد-برد بشه و یا حتی اگر بلد هم نیستن، به جهت حضورشون در تیم تولید گاردشون نسبت به سیستم جدید برداشته بشه.با راه‌اندازی و تاکید روی روال تست هوشمند و اجرای چند ابزارخاص کنترل کیفیت، خطاها رو به حداقل رسوندیم تا اعتماد به کارکرد سیستم روز به روز افزایش پیدا کنه. در واقع سعی کردیم بجای تولید بیشتر، تولید رو با کیفیت‌تر کنیم درست نقطه مقابل چیزی که کارفرما (مخصوصا از نوع دولتیش) دوست نداره و همه‌اش میخواد ده تا فرآیند ناقص داشته باشه برای شوآف، تا دو تا فرآیند کامل داشته باشه برای کار.با کنترل برخی چارچوب‌های اخلاقی حتی بعضی ترفند‌هایی که اونا اجرا میکنن رو علیه‌ خودشون می‌شه استفاده کرد. سربسته عرض کنم که در مقابل اینرسی که فیزیکیه، در اینجا از قوانین نیوتون کمک میگیریم بدین صورت که هر عملی را عکس العملی است به همان اندازه و در نقطه مقابل.شاید این مشکلات ساده به نظر بیاد یا حتی اصلا به نظر نیاد. ولی اینا مثل سرطان می‌مونه آروم آروم بزرگ می‌شن و یک دفعه یک چالشی ایجاد می‌کنن که منجر به شکست در پروژه می‌شه و همه زحمات تیم رو به باد می‌ده. </description>
                <category>Moodi</category>
                <author>Moodi</author>
                <pubDate>Thu, 30 Apr 2020 03:40:09 +0430</pubDate>
            </item>
                    <item>
                <title>تخصص یا تعهد؟</title>
                <link>https://virgool.io/@moodi/%D8%AA%D8%AE%D8%B5%D8%B5-%DB%8C%D8%A7-%D8%AA%D8%B9%D9%87%D8%AF-r7ia1umvuohf</link>
                <description>وقتی که پروژه رو تحویل گرفتم، با همه شرایط و مشکلاتش کاملا آشنا بودم چون خودم دو سال بود که به عنوان دولوپر اونجا بودم. چون فرآیند تغییر مدیریت و تحویل پروژه به من خیلی سریع و غافلگیر کننده بود اولش مقاومت کردم و قبول نکردم. چند جلسه‌ای با مدیر مجموعه صحبت کردم که کس دیگه‌ای رو برای اینکار انتخاب کنه، ولی ایشون قبول نکرد.خلاصه من که دیگه چاره‌ای نداشتم بین دو تا انتخاب مونده بودم. یا باید استعفا می‌دادم چون واقعا توی مدیریت پروژه هیچ تجربه و تخصصی نداشتم و با چارچوب‌های ذهنی خودم تضاد داشت. یا با شرایط کنار می‌اومدم خلاصه با گرفتن یک سری پوئن از مدیرمون قبول کردم.نکته: همیشه وقتی شرایط اون طور که می‌خوای پیش نمی‌ره و برات تهدید ایجاد می‌کنه، می‌تونی با بررسی ملاحظاتی، از اون تهدید بیشترین فرصت‌ها رو استخراج کنی. من عملا با گرفتن اون پوئن‌ها (البته نه فقط برای خودم بلکه برای تیم) اولین ترفند مذاکره برد-برد رو یاد گرفتم.اولین قدم در شروع مدیریت بررسی دقیق شرایط نه چندان خوب موجود بود. برای اینکه بدونم چجوری باید حرکت کنم، با یک آدم خبره و و متخصص در این حوزه قرار ملاقات منظم گذاشتم تا به طور مستمر نحوه کارم رو باهاش چک کنم و ابزار‌های موجود برای کنترل پروژه رو بشناسم.نکته: داشتن تخصص توی کارها همیشه یک اصله، اما اشکال کار مدیریت اینه که چون مثل کار‌های فنی، عدم تخصص افراد به همین راحتیا مشهود نمی‌شه. اینکه ما بدونیم مدیریت هم دقیقا مثل برنامه‌نویسی نیاز به یک سری علم و آگاهی و تکنیک داره خیلی مهمه. متاسفانه توی کشور ما، هرکسی توی یک کار فنی موفق ظاهر میشه، بعد از مدتی توی اون بخش مدیر میشه! بدون توجه به اینکه اصلا اون توی کار فنی خوبه و دلیل نمیشه توی مدیریت هم خوب باشه. با یک اشتباه می‌تونه هم سابقه کار خوب فنی‌ش رو خراب کنه، هم مدیریت رو. به همین خاطر من سعی کردم با اهل فن پیش برم تا هم یاد بگیرم هم کمترین اشتباه رو داشته باشم. برای اینکه کارفرما هم تحت تاثیر شرایط و تغییرات مدیریت دچار ترس و تصمیمات عجله‌ای نشه، چندتا فیچر کوچک رو سریع انجام و تحویل دادم تا حسن نیتم رو به اونا هم ثابت کنم و عملا چندتا مسکن بهشون تزریق کردم تا یه مدت کاری به کارمون نداشته باشن ببینیم چه بلایی سرمون آمده. اما مهم ترین بخش برای شروع، شارژ کردن عوامل تیم بود. این بچه‌ها سالها بود که داشتن توی این تیم فعالیت می‌کردن و نتیجه خاصی هم نگرفته بودن. همه انگشت‌نما شده بودن در حالی که قصور از نحوه کارکردن اینا نبود و داشت در حقشون کم‌لطفی می‌شد. با اون پوئن‌ها یکم تیم رو شارژ کردم تا با امیدواری به آینده نگاه کنن و گذشته رو کنار بگذارن.نکته: تمام سرمایه یک پروژه، منابع انسانی اون هستن. باید بدونیم که اگر اونا حالشون خوب نباشه، هرچی هم با زور و تهدید فشار کار کنیم، به رغم وجود کمیت، کیفیتی در کار نخواهد بود. در پست‌های بعدی خواهم گفت که چقدر از اون کارهایی که قبلتر به ضرب و زور و فشار تولید شده بود رو بخاطر بی‌کیفیتی حذف و بازنویسی کردیم.</description>
                <category>Moodi</category>
                <author>Moodi</author>
                <pubDate>Sat, 25 Apr 2020 01:04:23 +0430</pubDate>
            </item>
                    <item>
                <title>شرایط خوب ساختنی است نه یافتنی</title>
                <link>https://virgool.io/@moodi/%D8%B4%D8%B1%D8%A7%DB%8C%D8%B7-%D8%AE%D9%88%D8%A8-%D8%B3%D8%A7%D8%AE%D8%AA%D9%86%DB%8C-%D8%A7%D8%B3%D8%AA-%D9%86%D9%87-%DB%8C%D8%A7%D9%81%D8%AA%D9%86%DB%8C-qsym1diors0u</link>
                <description>لازمه برای اینکه جهت‌گیری نوشته‌هام برای خودم روشن بشه و عملا بتونم یک مسیر روشن رو توی نوشتن طی کنم تا منتج به نتیجه مطلوب بشه باید فضاسازی از محیط و موضوعی که می‌خوام در موردش صحبت کنم، داشته باشم. شاید یکم پخش و پلا باشه مرقومه‌های اول، ولی خب حوصله کنید. ابتدای باز بهتر از پایان باز و بی جهته.مقدمهتازه که وارد شرکت شده بودم، خیلی برام شرایطش غریب بود. کلا که تغییر برام سخت بوده همیشه ولی خب چیزی که شرایط رو سخت‌تر می‌کرد، جو بدی بود که قبلا نسبت به پروژه این تیم توی شرکت وجود داشت و عملا همه به چشم یک تیم کند و کارنکن به همه اعضا نگاه می‌کردن. بارها شده بود که ازم می‌پرسیدن: شما جدید اومدی تو کدوم تیم هستی؟ می‌گفتم: بله، توی تیم فلان؛ سریع با یک لحن تمسخر آمیزی می‌گفتن: عه؟! مگه اون پروژه هنوز شکست نخورده؟ انگار تمام منابع شرکت رو در اختیار تیم گذاشته بودن و توی یک مدت طولانی هیچ نتیجه‌ای نگرفته بودن. اصلا اولش که اومدم برام سوال بود که چرا تیم‌های دیگه مثلا ۷ یا ۸ نفرن حدودا ولی این تیم ۲۲ نفر هستن؟!خلاصه فارق از اینکه این حرفا و رفتارها خیلی اذیت کننده بود، من یک دولوپر ساده بودم و اینا به من ربطی نداشت. من باید تسک‌هامو انجام می‌دادم و عملا توی حیطه مدیریت پروژه نه تخصصی داشتم نه شناختی و نه اصلا اجازه داشتم دخالت کنم. این شد که فکر کردم برم با مدیر مجموعه صحبت کنم تیمم رو عوض کنم و اگر قبول نکرد، از این شرکت برم. خلاصه که خیلی سخت بودچیزی که قلقلکم می‌داد بمونم این بود که شرایط خوب رو باید ساخت و براش تلاش کرد. درست نیست که بریم توی شرایط خوب و حس کنیم کار بزرگی کردیم؛ باید جایی که مشکل داره رو درست کرد. شاید علت اصلی که جلوی خیلی تصمیماتم مثل مهاجرت به یک کشور خوب با شرایط کاری و مالی خوب، رو می‌گرفت این طرز فکرم بود.خلاصه کم کم شروع کردم به کار و سعی کردم هرچی در توانم هست رو با بقیه اعضای تیم به اشتراک بذارم تا هرچی می‌شه هم سطح فنی و هم انسجام تیم رو بیشتر کنم. مدیرمون هم البته آدم خوبی بود و خیلی وقتا نمی‌شه گفت حمایت می‌کرد ولی خب سنگ‌اندازی هم نمی‌کرد. اوایل بعضی بچه‌های قدیمی‌تر یه مقاومت یا بعضا سنگ‌اندازی هایی می‌کردن ولی خب در کل چون نیت من خودنمایی نبود، قاطبه اعضا با من همراه بودن.مؤخرهالان که دارم این نوشته رو به رشته تحریر در میارم، قریب به ۳ ساله که مدیر همون پروژه هستم و نه تنها پروژه با اون حجم بزرگ تقریبا تموم شده و نه تنهاتر که توی این سالیان چندتا پروژه کوچک دیگه هم تولید و تحویل شده، بلکه تیم ما هم از یک تیم کرخت و مصرف کننده منابع، به تیم برتر بین حدود ۲۲ تا تیم پروژه تبدیل شده. اونم به مدت دو سال پیاپی.با این مقدمه و مؤخره که عرض کردم، می‌تونم بگم بزرگترین درسی که علیرغم تمامی مشکلات (که بعدا در سیاهه‌های بعدی خواهم گفت) توی این ۵ سال کار بدست آوردم اینه که باید خیلی کار کرد. خیلی زیاد ممارست داشت و به این راحتیا کوتاه نیومد. کوتاه اومدن و عوض کردن زمین بازی راحت‌ترین کاری هست که میشه کرد. ولی باید موند و شخم زد و صبر داشت تا محصول به بار بشینه ظاهرش شعاره ولی واقعیته.</description>
                <category>Moodi</category>
                <author>Moodi</author>
                <pubDate>Wed, 22 Apr 2020 20:37:54 +0430</pubDate>
            </item>
            </channel>
</rss>