https://virgool.io/feed/@soleimani مهندس نرم‌افزار، وبلاگ‌نویس سابق fa 2026-06-10 15:11:28 https://files.virgool.io/upload/users/18633/avatar/WqaRuH.png?height=120&width=120 https://virgool.io/@soleimani https://virgool.io/@soleimani/%DB%8C%DA%A9-%D9%85%D8%B7%D8%A7%D9%84%D8%B9%D9%87-%DB%8C-%D9%85%D9%88%D8%B1%D8%AF%DB%8C-%D8%A7%D9%86%D8%AA%D8%B4%D8%A7%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D9%88-%D8%A8%D9%87-%D9%85%D8%AE%D8%A7%D8%B7%D8%B1%D9%87-%D8%A7%D9%86%D8%AF%D8%A7%D8%AE%D8%AA%D9%86-%DB%8C%DA%A9-%D8%AA%D8%AC%D8%A7%D8%B1%D8%AA-qbrfhg4z66bv این روزها و با گسترش تجارت‌های برخط، اخبار در حوزه‌ی نشت و یا سرقت اطلاعات کاربران نیز به سرعت در حال افزایش است. در این میان به فراخور نوع تجارتی که روی یک کسب و کار برخط پایه‌گذاری می‌شود، میزان هزینه و دقتی که تیم‌های فنی و توسعه‌دهندگان روی این موضوعات نیز باید انجام دهند، افزایش می‌یابد.در این یادداشت با یک مورد عملی، نگاهی اجمالی دارم به آن‌چه توسعه‌دهندگان می‌توانند انجام دهند تا یک تجارت را دچار آسیب‌های غیرقابل جبران کنند. موضوع در مورد یکی از درگاه‌های پرداخت‌یاری است که به تازگی فعالیت خود را شروع کرده است. ذکر این نکته نیز لازم است که من تخصصی در حوزه‌ی امنیت ندارم و از ابزار خاصی هم برای کشف این مورد استفاده نکرده‌ام. فقط مشاهداتم را دنبال کردم و به نتیجه رسیدم. به طور معمول سارقان اینترنتی کار خود را از مشاهده‌ی داده‌های آشکار برای کشف نقاط نفوذ در کاربردهای مختلف نرم‌افزاری آغاز می‌کنند. برای مثال به داده‌های موجود در سرآیند درخواست‌های وب مرتبط با این درگاه پرداخت‌یار دقت کنید:از داده‌های موجود در این سرآیند اطلاعات ذی‌قیمتی را می‌توان استخراج کرد. برای مثال محدودیت تعداد درخواست به واسط برنامه‌نویسانه وب چه تعداد است و یا خادم وب این وب‌کاربرد چیست و نسخه‌ی آن چگونه است. البته این داده‌ها شاید در نگاه اول چندان کاربردی نباشند. اما بهتر است بدانید که متخصصان امنیت همین داده‌ها را نیز دستکاری می‌کنند تا کار برای سارقان و حمله‌کنندگان سخت‌تر شود. اما نکته‌ی اصلی در این داده‌ها، سرآیندی با کلید phpdebugbar-id است. به طور عمومی در حوزه‌ی توسعه‌ی نرم‌افزار ابزارهایی که با عبارت‌هایی از جنس debug نام‌گذاری می‌شوند، برای بررسی رفتار نرم‌افزار در فراخوانی‌های مختلف استفاده می‌شوند. حالا اگر کلید سرآیندی با ترکیبی از این نام در یک درخواست وب مشاهده شود، با احتمال خوبی یک ابزار بررسی عملکرد نرم‌افزار روی این محصول در دسترس است. با کمی جستجو در اینترنت می‌توان به این نتیجه رسید که به طور مشخص ابزار phpdebugbar نیز یکی از همین ابزارها است که به توسعه‌دهندگان کمک می‌کند رفتار نرم‌افزار، چه در مورد فراخوانی توابع و کلاس‌ها و چه در حوزه‌ی سرآیندهای وب و یا فراخوانی‌های پایگاه داده، مورد ارزیابی قرار گیرد. برآورد اولیه‌ی من این بود که احتمالا دسترسی به خروجی این ابزار برای کاربران با آدرس IP مشخصی محدود شده است و در دسترس همگان نیست. هر چند که همین رفتار هم در انتشار یک محصول غلط است اما خب می‌شد با کمی اغماض پذیرفت. برای بررسی صحت این موضوع یک آدرس بی‌ربط از واسط برنامه‌نویسانه را فراخوانی کردم و متاسفانه ابزار خطایاب در دسترس من نیز بود. تا اینجا من می‌توانستم از ابزار خطایاب برای بررسی چهارچوب توسعه‌ی نرم‌افزار و یا همان فریم‌ورک استفاده کنم و ساختار نرم‌افزار هدف را ارزیابی کنم. اما نکته‌ی بدی که کار را مجددا خطرناک‌تر می‌کرد وجود بایگانی از درخواست‌ها در همین ابزار خطایاب بود. همان‌طور که در تصویر مشخص است، من می‌توانستم به بایگانی کاملی از درخواست‌های ارسال شده به این وب‌کاربرد دسترسی داشته باشم. با توجه به داده‌هایی که این ابزار در اختیار من می‌گذارد به سادگی به شمای فراخونی‌های پایگاه داده‌ی مرتبط با هر درخواست دسترسی پیدا کردم. در گام بعدی سایر اطلاعاتی که روی هر درخواست در اختیارم بود را نیز ارزیابی کردم و متوجه شدم که تمامی سرآیندهای فراخوانی‌های http نیز در این بایگانی وجود دارد. به این ترتیب من به سادگی می‌توانستم علاوه بر به دست آوردن توکن‌های ارتباط سایر کاربران از طریق فراخوانی‌های پایگاه داده، این توکن‌ها را از روی سرآیندها نیز استخراج کنم، آن‌ها را جعل کرده و به جای آن‌ها درخواست‌های مختلف را به نرم‌افزار ارسال کنم. البته بلافاصله بعد از انجام این بررسی سطحی، مشکل را به شرکت مربوطه گزارش کردم.از این مطالعه‌ی موردی چه می‌آموزیم؟ما به عنوان توسعه‌دهندگان نرم‌افزار، نقشی کلیدی در تجارت‌های مختلف ایفا می‌کنیم. بسیار مهم است که همان‌طور که همواره در مسیر یادگیری تکنولوژی‌های مختلف و افزایش سطح دانش خود در زبان‌های برنامه‌نویسی هستیم، به موضوعات مرتبط با امنیت وبکاربردها نیز بهای لازم را بدهیم. استفاده از ابزارهای مختلف در مسیر توسعه‌ی نرم‌افزار و رفع خطاهای آن امری ناگزیر و اجتناب‌ناپذیر است. اما در کنار آن باید با استفاده از روش‌های مختلف بررسی کیفیت کدها قبل از انتشار محصول روی محیط عملیاتی، از عدم وجود هر نوع حفره‌ی امنیتی هر چند ساده نیز جلوگیری کنیم. در صورتی که تیم ما توان ارزیابی امنیتی محصول ما را ندارد، بهتر است از شرکت‌های مرتبط با این موضوعات کمک بگیریم و اجرای آزمون‌های امنیتی را به آن‌ها بسپاریم. قطعا کشف آسیب‌پذیری قبل از انتشار محصول و توسط تیم‌های متخصص، بهتر از کشف آن‌ها پس از انتشار است. حسین سلیمانی حسین سلیمانی Tue, 13 Apr 2021 12:15:34 +0430 https://virgool.io/@soleimani/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-microservice-%DA%A9%DB%8C-%D9%88-%DA%A9%D8%AC%D8%A7-vrpkr7h6vn8w احتمالا بسیاری از شما نام معماری Micro Service را شنیده‌اید. در این یادداشت کوتاه این عبارت را خدمت‌های کوچک ترجمه کردم. البته به ذهنم رسید که شاید خدمت‌های کوچک به هم پیوسته هم ترجمه بامزه‌تری باشد اما در نهایت این یکی مختصرتر بود.مساله‌ای که می‌خواهم راجع به آن صحبت کنم نه در مورد مفاهیم مربوط به معماری مبتنی بر خدمت‌های کوچک است و نه مزایا و معایب آن. در مورد این موارد با یک جستجوی ساده در اینترنت می‌توانید دانش خود را افزایش دهید. موضوع درباره‌ی این است که چه زمانی بهتر است از این روش برای توسعه نرم‌افزار و ارائه خدمت بهره ببریم.با توجه به اینکه سرعت رشد نرم‌افزار در جهان فعلی به شدت بالا است، به طور معمول توسعه‌دهنده‌های نرم‌افزار در مقابل اصطلاحات و روش‌های جدید، هیجان‌زده می‌شوند و همین باعث استفاده‌های بی‌حاصل و غیرضروری از روش‌های جدید توسعه و انتشار نرم‌افزارها شود. نمونه قابل لمس این موضوع را می‌توان در فضای توسعه روساخت وب مشاهده کرد. هر روز تکنولوژی‌ها و چهارچوب‌های توسعه‌ی جدیدی ارائه می‌شوند و توسعه‌دهندگان، هیجان‌زده از این ابزارها، از شاخه‌ای به شاخه‌ی دیگر در حال حرکت هستند.در ادامه به اختصار تجربه‌ی اندک خودم را در حوزه شاخص‌هایی که باید در زمان انتخاب معماری خدمت‌های کوچک جلوی چشم داشته باشیم، با شما به اشتراک می‌گذارم.اندازه‌ی محصول را بشناسیدبسیار پیش می‌آید که توسعه‌دهنده‌ها و معماران نرم‌افزار بدون توجه به مقیاس محصول، یک معماری آرمانی برای محصول نهایی را پیشنهاد می‌دهند. دقت کنید که معماری مبتنی بر خدمت‌های کوچک زمانی بهینه است که شما یک محصول با مشتری مقیاس متوسط یا بزرگتر از آن را پیش رو داشته باشید. در صورتی که مقیاس مشتری و به طبع آن محصول در حال توسعه، کوچک باشد، استفاده از معماری مبتنی بر خدمت‌های کوچک تنها هزینه تولید و به ثمر رساندن محصول را بیشتر می‌کند و از قضا در مواقعی ممکن است سرعت به روزرسانی و رفع نیازمندی‌های مشتری را نیز به نسبت یک معماری تک خدمتی، کندتر کند.توانمندی خودتان را بشناسیداین موضوع از جمله‌ی مواردی است که باید در زمان استفاده از معماری‌های مبتنی بر خدمت‌های کوچک به خوبی تحلیل و ارزیابی شده باشد. معماری مبتنی بر خدمت‌های کوچک، دانش گسترده‌ای در حوزه‌ی ابزارهای مختلف برای مکانیزم‌های ارتباط بین خدمت‌ها، راه‌اندازی، انتشار، بروزرسانی و ... را نیاز دارد. اگر خودتان و یا تیم‌تان چندان تجربه‌ای در این حوزه ندارید، استفاده از این روش برای شما سردرد بسیاری خواهد داشت. چه آن‌که محصول نهایی نیز با آسیب‌پذیری‌های عملکردی و غیرعملکردی بسیار زیادی نیز مواجه خواهد شد.حوصله‌ی صاحبان سرمایه‌ی محصول را بشناسیدمعماری مبتنی بر خدمت‌های کوچک در ذات خود همراه با انجام کارهای بیشتر در زمان انتشار نسخه‌ی اولیه است. اگر صاحبان سرمایه‌ی محصول حوصله‌ی کمی برای انتشار نسخه‌ی اول محصول را دارند، این معماری به احتمال خوبی شما را با شکست مواجه می‌کند. شاید بهتر باشد نسخه‌ی اولیه را در قالب یک اثبات ادعا، با معماری ساده‌تری آماده کرده و در نسخه‌های بعدی نسبت به تغییر گام به گام معماری اقدام کنید.تفاوت تحقیق و کسب تجربه با توسعه‌ی یک محصول تجاری را بشناسیدتیم‌های توسعه نرم‌فزار، خاصه جوان‌ترها، معمولا دنبال کسب تجربه‌های جدید و بهبود رزومه کاری خود هستند. اما یک تفکر بالغ، از فرصت‌های پیش آمده در مسیر کاری خود، همزمان برای کسب تجربه و البته ارائه‌ی بهینه و کم‌هزینه محصول به مشتری استفاده می‌کند. پس پیش از آن‌که نگاهتان به رزومه کاری خودتان باشد، راه درست و بهینه برای توسعه محصول مورد نظر را پیدا کنید. مطمئن باشید که فرصت کسب تجربه در زمان مناسب و روی محصول مناسب را کسب خواهید کرد.پس کی و کجا؟اگر تمامی موارد ذکر شده در بالا، که البته هر کدام را می‌توان ساعت‌ها بسط و نشر داد، را بررسی کردید و همچنان خدمت‌های کوچک را مناسب‌ترین گزینه برای توسعه محصول نهایی ارزیابی کردید، حالا وقت آن است که دست به کار شوید. ابزارهای توسعه‌ی اشتراکی را راه بیاندازید، مکانیزم‌های یکپارچه‌سازی و انتشار مداوم را مستحکم کنید. فرآیند‌های بهینه برای توسعه‌ی اشتراکی نرم‌افزار را با تیم‌تان قرارداد کنید و کار را شروع کنید.پی‌نوشتاین یادداشت قبل‌تر در لینکداین منتشر شده بود و ترجیح دادم در اینجا هم برای ماندگاری بیشتر ذخیره‌اش کنم. حسین سلیمانی حسین سلیمانی Tue, 30 Mar 2021 09:09:49 +0430 https://virgool.io/@soleimani/%D8%A8%D8%A7-%DA%86%D8%A7%D9%84%D8%B4-%D8%A7%D9%86%DA%AF%DB%8C%D8%B2%D9%87-%DB%8C-%DA%A9%D8%A7%D8%B1-%D8%AF%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84%D8%A7%D8%AA-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA%DB%8C-%DA%86%D9%87-%DA%A9%D9%86%DB%8C%D9%85-i0h7i9tvwool اگر در بازار توسعه نرم‌افزار و مهندسی آن باشید، احتمالا شما هم زیاد با این دوراهی برخورد کرده‌اید که کار در یک شرکت زیرساختی و پروژه‌ی B2B را انتخاب کنید و یا وارد کارزاری هیجان‌انگیز از برخورد مستقیم خروجی کارتان با کاربران نهایی و عموم مردم شوید. مساله‌ای که در این یادداشت می‌خواهم به آن بپردازم مقدمه‌اش را در لینکداین نوشتم:مقدمه‌ای که منتج به این یادداشت شد.صورت مساله به نظرم واضح است. چطور می‌توانیم در یک شرکت که هدف‌گذاری محصولاتش فروش به کسب و کارهای دیگر است و نه الزاما عموم مردم، به تیم و کارکنان انگیزه لازم برای کار را بدهیم؟ کارکنان و توسعه‌دهندگان در این پروژه‌ها همواره این سوال را از خود می‌پرسند که اگر در تیم فلان نرم‌افزار موبایل که برای مثال ۱۰ میلیون کاربر دارد، کار می‌کردند، بهتر نبود؟ آیا آنجا چیزهای بیشتری یاد نمی‌گرفتند؟ مسائل و مشکلاتی که در آن پروژه‌ها وجود دارد چیست؟ رزومه‌ی کاری من پس از کار در این محصول که نامش در هیچ‌جایی نیست چه می‌شود؟ سوال‌هایی از این دست در کنار همان مشکلات ذکر شده در صورت مساله، باعث می‌شود انگیزه همکاری در این شرکت‌ها به مرور در بین کارکنان تنزل پیدا کند و در واقع نگهداشت نیروی انسانی ماهر و توانمند در این محصولات سخت‌تر و سخت‌تر شود. در ادامه کمی در مورد گام‌ها و روش‌هایی که می‌توان برای بهبود این شرایط و افزایش انگیزه توسعه‌دهندگان برای فعالیت در این محصولات به کار برد، می‌نویسم.گام اول؛ محیط و روال توسعه محصول حرفه‌ای داشته باشیددر برخی از تیم‌های با محصولات زیرساختی، به دلایل مختلف، فرآیندهای حرفه‌ای توسعه و انتشار محصول نادیده گرفته می‌شوند. از ابزارهای قدیمی برای نگهداشت و یا مدیریت پروژه استفاده می‌شود و سرعت استفاده تیم از محصولات حاشیه‌ی توسعه نرم‌افزار، همچون ابزارهای مدیریت مخازن کد و یا خودکارسازی روال آزمون و انتشار، بسیار کند و در برخی مواقع ناچیز است. تعریف یک فرآیند حرفه‌ای توسعه نرم‌افزار با روال‌های صحیح از تعریف صورت مساله، اعمال زمان‌بندی در رسیدن فعالیت‌ها، روال‌های شفاف بررسی کیفیت کد، الزامی بودن پیاده‌سازی آزمون‌های سطح واحد برای کد، مستندسازی دقیق، استفاده از ابزارهای خودکارسازی روال انتشار و ایجاد مراحل مختلف انتشار محصول از جمله مواردی است که می‌تواند فضای تیم را حرفه‌ای نگه دارد و اطمینان کافی را به توسعه‌دهندگان بدهد که آن‌ها در محیطی بسیار حرفه‌ای و حتی حرفه‌ای‌تر از محصولات کاربرمحور، فعالیت می‌کنند.گام دوم؛ مصورسازی و مستندسازی کنید چیزی که اندازه و کاربرد یک پروژه‌ی زیرساختی را به رخ می‌کشد نه تعداد خط کد آن و یا طراحی کلاس‌ها و توابع، بلکه شمایی واقعی از آن‌چیزی است که در نهایت برای محصول شما اتفاق می‌افتد. توسعه‌دهندگان با دیدن یک تصویر بزرگ از آن‌چیزی که در کل محصول در حال وقوع است و اجزای مختلف آن به صورت شماتیک، یک دید سریع از اهمیت کار خود پیدا می‌کنند. چیزی که در محصولات کاربرمحور بسیار شفاف است و نیاز به شرح و بسط طولانی و عجیبی ندارد.نمایش جایگاه خروجی هر تیم در سبد محصولات و یا محصول بزرگ‌مقیاس، ارزش مادی و معنوی‌ای که این خروجی تولید می‌کند و سایر مواردی از این دست، در قالب‌های جذاب بصری می‌توانند هیجان اولیه کافی‌ای برای کارکنان تازه‌وارد ایجاد کنند و توسعه‌دهندگان قدیمی را نیز از اهمیت کار خود مطمئن کنند.مستندات معماری در سطح کلان به همراه نمودارهای سطح جز که اجزای کلی یک سامانه زیرساختی را نمایش دهد و وظیفه هر جز را به صورت قبل فهمی تعریف کند، می‌تواند توسعه‌دهندگان را نسبت به آنچه در حال وقوع است هوشیار کرده و دقت عمل کارکنان را بالا ببرد. گام سوم؛ هزینه‌های عدم وجود محصول را شفاف کنیدمهم است که توسعه‌دهندگان بدانند اگر کار آن‌ها نباشد در عمل چه اتفاقی خواهد افتاد؟ اینکه برای مثال «ما امنیت دیجیتال شرکت‌ها را تامین می‌کنیم» حتما جمله‌ی شفاف و قانع‌کننده‌ای برای یک توسعه‌دهنده روساخت وب که وظیفه توسعه بخش پایش رخدادها را به عهده دارد، نیست. جملات باید شفاف باشند. اگر روساخت بخش پایش، عملکرد سالمی نداشته باشد چه می‌شود؟ چه هزینه‌ای برای مشتریان و بهره‌برداران خواهد داشت؟ شرکت چه میزان پاسخگو خواهد بود؟ این سوالات باید پاسخ‌های شفافی داشته باشند. گام چهارم؛ چالش‌های فنی و آموزش‌های در مسیر توسعه را شفاف کنیدیکی از مسائلی که در پروژه‌های زیرساختی وجود دارد حس درجا زدن و عدم حرکت در لبه‌ی توانمندی‌های مرتبط با اعضای تیم است. این در حالی است که به تجربه به من ثابت شده است که چالش‌های پروژه‌های زیرساختی بسیار زیاد و به مراتب پیچیده‌تر هستند. ممکن است جنسی از چالش‌ها در اینجا وجود نداشته باشد اما به دلایل مختلف در مسیر توسعه این پروژه‌ها، نه تنها چالش‌های منحصر به فردی بررسی و مرتفع می‌شوند بلکه چالش‌های مرتبط با محصولات کاربرمحور هم مرور می‌شوند. نکته‌ی مهم دیگر در این مسیر، آموزش‌های متنوع به فراخور چالش‌های موجود در این محصولات است. مهم است که برای اعضای تیم مرور شود که چه چیزهایی در طول مسیر توسعه این محصول یاد گرفته‌اند و دانش آن‌ها چقدر در مسیر توسعه رشد کرده است. مقایسه این میزان از یادگیری با آن‌چه که در محصولات کاربر محور اتفاق می‌افتد نیز می‌تواند در بسیار از موارد ذهن افراد را نسبت به جذابیت کار شفاف‌تر کند. گام پنجم؛ محرمانگی یا قطره‌چکانی اطلاعات را به حداقل ممکن برسانیددر برخی موارد به دلیل محرمانگی‌های خودساخته و گاهی هم به دلیل پیچیدگی‌های ذاتی صورت مساله‌ی محصولات زیرساختی، مدیران و توسعه‌دهندگان ارشد از توصیف آنچه که در کاربرد محصول در حال وقوع است طفره می‌روند و به صورت قطره‌ای و در باز‌ه‌ی زمانی طولانی‌مدتی یک تصویر نسبتا شفاف از محصول به همکاران ارائه می‌دهند. بخشی از این اتفاق طبیعی است. اما این مهم است که فاصله ورود همکاران تا فهم مناسب آن‌ها از اهمیت و روش بهره‌برداری از محصولات، حداقل زمان ممکن باشد. هر چه زودتر توسعه‌دهندگان به ابعاد واقعی مساله و کاربرد محصول آشنا شوند، زودتر می‌توانند برای مسائل راه‌حل داشته باشند و احساس خوبی از کار در محصول را داشته باشند. وجود مستندات و مصورسازی که قبل‌تر ذکر شد، می‌تواند در این گام نیز بسیار کمک‌کننده باشد. مستندسازی را همیشه جدی بگیرید. گام ششم؛ اشتراک دانش درون سازمان را به حداکثر ممکن برسانیدمحصولات زیرساختی به صورت ذاتی طیف گسترده‌ای از دانش را با خود به همراه می‌آورند. اما در عین حال حجم بالای فعالیت مورد نیاز برای توسعه این محصولات، منتج به شکل‌گیری ساختارهای سازمانی بزرگ و پیچیده‌ای می‌شود. خروجی این ساختارهای بزرگ و سنگین، تیم‌هایی با وظایف محدود و مشخص است که کمتر از آنچه در باقی تیم‌ها می‌گذرد اطلاع دارند. این امر نه تنها منتج به جزیره‌ای شدن سازمان خواهد شد، بلکه همان حس درجازدن را در کارکنان تقویت خواهد کرد. می‌توان با تعریف روال‌های پایدار و منظمی از ارائه‌ها و دورهمی‌های مختلف فنی، دانش را بین اعضای شرکت به اشتراک گذاشت و همه‌ی تیم‌ها را با ابعاد کلان مساله آشنا کرد. تیم‌ها می‌توانند به صورت ماهانه آن بخش از محصول یا محصولاتی را که آماده‌ی انتشار کرده‌اند برای اعضای شرکت نمایش دهند و چالش‌های مختلف را با آن‌ها به اشتراک بگذارند. گام هفتم؛ راه خلاقیت را نبندیدساختارهای پیچیده‌ای که البته به نظر من بخش ناگزیر محصولات زیرساختی هستند، در برخی موارد سدی در مقابل خلاقیت و بروز ایده‌های نو توسط توسعه‌دهندگان می‌شوند. دادن اختیارات مشخص با حفظ نظم توسعه سبد محصول، می‌تواند کمی از این مشکل را برطرف کند و اجازه دهد تیم‌ها خلاقیت‌های خود را در روال توسعه محصولات بروز دهند. ارائه الگوهای مناسب از این خلاقیت‌ها به سایر تیم‌ها می‌تواند انگیزه‌ی مضاعفی برای افراد خلاق باشد. گام هشتم؛ معماری محصول را برای انتشار در بازه‌های زمانی کوتاه بهینه کنیدیکی از بزرگترین مشکلات در محصولات زیرساختی، کندی روند انتشار محصول است. به این ترتیب که با تعریف حداکثری نیازمندی‌ها از سمت مشتری، محصول در یک بازه‌ی زمانی بلندمدت به انتشار می‌رسد و همین باعث فرسودگی و کاهش انگیزه‌ی اعضای تیم می‌شود. بهتر است به جای اجرای یک طراحی بی‌نقص و شامل تمام نیازمندی‌های مشتری، محصول را به فازهای کوچکتر تقسیم کرده و در محدوده‌های زمانی کوتاه‌تری گام به گام به انتشار نهایی نزدیک کنید. خطاها در سطوح مختلف معماری، طراحی و پیاده‌سازی را در این مسیر را بپذیرید. باور کنید که هزینه‌ی این خطاها در بلند مدت و با ایجاد انگیزه در تیم جبران خواهد شد. انتشار پایلوت‌های مختلف روی شبکه مشتری می‌تواند انگیزه‌ی اصلی در این مسیر باشد. اجزای محصول را به مرور و جز به جز روی شبکه آزمایشگاهی و یا بخش کوچکی از شبکه مشتری منتشر کنید. این امر فرسایش تیمی را کمتر کرده و تیم را زودتر با چالش‌های مختلف مشتری روبرور می‌کند. گام نهم؛ اجازه انتشار دانش‌های کسب شده به خارج از سازمان را بدهیدمحصولات کاربرمحور در راستای ایجاد چهره‌ای جذاب و فنی به کاربران خود، به راحتی دانش کسب شده در محصول را به سایرین به اشتراک می‌گذارند و حتی از این امر برای بهبود وجهه‌ی فنی خود بهره می‌گیرند. اما محصولات زیرساختی به دلایل مختلف تجاری و یا محدودیت‌هایی از طرف کارفرمای پروژه کمتر دانش خود را به اشتراک می‌گذارند. همین امر سبب می‌شود که امکان ساخت یک چهره‌ی فنی از توسعه‌دهندگان سلب شود. اما در بسیاری از موارد، محصولات زیرساختی نیز می‌توانند با حذف داده‌های شخصی از دانش موجود، سخت‌گیری کمتر در انتشار اطلاعات محصول و همچنین اختصاص زمان کاری برای انتشار دانش به صورت عمومی، اجازه دهند تا توسعه‌دهندگان تجارب خود را با سایرین به اشتراک بگذارند و وجهه فنی شخصی خود را بهبود دهند. امری که برای بخش بزرگی از توسعه‌دهندگان نرم‌افزار در فضای کاری امروز مهم و تاثیرگذار است. گام دهم؛ مسیر پیشرفتی شفاف و قابل دستیابی را برای اعضا تعریف کنید واضح است که بخشی از تعریف مسیر پیشرفت برای افراد به تصمیمات کلان در سطح محصول و سازمان برمی‌گردد. اما نباید از این نکته هم غافل شد که می‌توان مستقل از تصمیمات کلان سازمانی، برای هر توسعه‌دهنده مسیر پیشرفت شغلی و شخصی نسبتا معقولی را تعریف کرد که در آن فرآیند یادگیری و بهبود توانایی‌های فنی و غیرفنی افراد هدف‌گذاری شود. این امر پیچیدگی چندانی ندارد و با شناخت کافی از شخصیت توسعه‌دهندگان و گاهی با گفتگو و تعامل قابل دستیابی است.چالش اصلی در این بخش تعریف همان مسیر پیشرفت سازمانی است که در محصولات زیرساختی با ساختار عریض و طویل، کمی پیچیده است. با همکاری سازمانی می‌توان این موضوع را نیز شفاف کرد که البته حقیقتا این یکی، از سخت‌ترین کارها در محصولات زیرساختی است. جمع‌بندیهدف من از انتشار این یادداشت یادآوری برخی نکات به خودم و همکارانم در پروژه‌های توسعه‌ نرم‌افزارهای زیرساختی بود. سعی کردم مواردی که می‌گویم وابستگی زیادی به ساختار سازمان و تصمیمات کلان سازمانی نداشته باشد. به نظر من این مجموعه گام‌ها در سطح هر تیمی قابل اجرا است و از این نظر می‌تواند برای مدیران میانی سازمان‌ها بسیار کمک‌کننده باشند. البته که حتما می‌توان گام‌های بیشتری هم برداشت. حسین سلیمانی حسین سلیمانی Wed, 17 Feb 2021 11:59:31 +0330