برخی از مشکلات سیستم نرم افزاری به دلیل دلایل مختلف مانند الزامات متناقض یا ساختار کد پیچیده ، حل آن دشوار است. برای اطمینان از دستیابی به یک راه حل به نتیجه مورد انتظار ، من برخی از مراحل را که از شش کلاه تفکر و قانون پارکینسون الهام گرفته است ، دنبال می کنم.
ادوارد د بونو شش کلاه تفکر را به عنوان یک روش حل مسئله و تصمیم گیری توسعه داد که دیدگاه های متنوعی را ترغیب می کند. هر “کلاه” نشان دهنده روشی متفاوت برای تفکر است: کلاه سفید بر حقایق و داده ها ، کلاه قرمز روی احساسات و شهود ، کلاه سیاه بر روی خطرات و احتیاط ، کلاه زرد روی مزایا و خوش بینی ، کلاه سبز بر خلاقیت و خلاقیت تمرکز دارد. ایده های جدید و کلاه آبی در مورد سازمان و کنترل روند تفکر. با استفاده منظم از هر کلاه ، افراد و تیم ها می توانند موضوعات جامع تری را کشف کنند و منجر به تصمیمات خوب و مؤثر شود.
Cyril Northcote Parkinson قانون پارکینسون را تدوین کرد ، که می گوید “کار برای پر کردن زمان موجود برای تکمیل آن گسترش می یابد.” این بدان معناست که اگر یک کار مهلت طولانی تر از حد لازم داشته باشد ، احتمالاً در تمام مدت زمان آن طول خواهد کشید ، حتی اگر زودتر نیز تکمیل شود. این قانون ناکارآمدی در مدیریت زمان و بهره وری را که اغلب در محل های کار و بوروکراسی ها دیده می شود ، برجسته می کند. برای مقابله با این امر ، تعیین مهلت های کوتاه تر و متمرکز تر به بهبود کارآیی و جلوگیری از تعلل غیر ضروری کمک می کند.
برای تأیید اینکه آیا یک راه حل به نتیجه مورد انتظار می رسد ، من این مراحل را دنبال می کنم:
- یک مهلت کوتاه (1-2 روز) تعیین کنید.
- دامنه را بر اساس مهلت محدود کنید.
- اثبات مفهوم (POC) ایجاد کنید.
- اگر POC نتیجه مورد انتظار را برآورده می کند ، الزامات نرم افزار را بر اساس آن لیست کنید.
- گزینه های اجرای را تجزیه و تحلیل کنید.
- تغییرات لازم را برنامه ریزی کنید.
برای مراحل 1 و 2 ، قانون پارکینسون به من کمک می کند تا بر روی شناسایی تغییرات کوچک و با تأثیر زیاد در یک بازه زمانی محدود تمرکز کنم.
برای مرحله 3 ، من از کلاه های زرد ، قرمز و سبز برای حل مشکل در مقیاس کوچک استفاده می کنم ، حتی اگر کیفیت آن را به خطر بیاندازد. با این حال ، من برای حفظ تمرکز بر روی هدف ، به مهلت توجه می کنم.
برای مرحله 4 ، من فقط درصورتی که POC با هدف هدف برآورده شود ، ادامه می دهم. در این مرحله ، من به کلاه های سفید ، سیاه و آبی تغییر می کنم تا بر اساس اجرای POC ، الزامات عملکردی و غیر عملکردی را ذکر کنم.
برای مرحله 5 ، با الزامات تعریف شده ، حداقل دو گزینه اجرای را با جوانب مثبت و منفی آنها در نظر می گیرم. سپس من اینها را با سایر ذینفعان برای جمع آوری بازخورد به اشتراک می گذارم. موارد زیر نمونه هایی از سؤالاتی را نشان می دهد که من این مرحله را انجام می دهم:
- آیا این تغییر هدف خود را انجام می دهد؟
- چگونه می توان عوارض جانبی منفی را کاهش داد؟
- چگونه می توان مزایا را اندازه گیری کرد؟
- چگونه می تواند تغییر به عقب سازگار باشد؟
- آیا تغییرات برای کاربر مهم است؟
سرانجام ، در مرحله 6 ، من در مورد گزینه اجرای با تیم تصمیم می گیرم و الزامات موجود در بلیط موجود در سیستم ردیابی انتشار نرم افزار را مستند می کنم.
با استفاده از این روش ، من در طول حرفه خود چندین مشکل نرم افزاری را حل کرده ام. امیدوارم این روش برای دیگران نیز مفید باشد.
