درخواست زمان بندی حدسی قبل از شروع پروژه، قابل اعتماد نیست - بخش 1

حد اقل میتوان گفت ، درخواست زمان انجام یک تسک یا پروژه، آیتم مورد اعتمادی نیست، حال ببینیم چرا ؟

1- عملیاتی که جهت تولید یک محصول نرم افزاری انجام میشود، یک عمل تکراری و یک مسیر قبلا طی شده نیست. فرآیند بسته بندی یک یخچال که روزانه در یک کارخانه انجام میشود، یک فرآیند تکراری است، لذا میشود مسیر مورد نیاز برای طی شدن این پروسه را بررسی نمود و بر اساس آن زمان بندی داشت ، ولی در فرآیند تولید نرم افزار، چالشها و مشکلات و مسیری که می بایست طی شود تا محصول آماده گردد، کاملا راز آلود ، نامشخص می باشد ! ضمنا در فرآیند Software Development، هر برنامه نویس شیوه و Style خودش را دارد، این شیوه اختصاصی پیاده سازی، ممکن است  در مقایسه با دیگری زمان برتر یا سریعتر به محصول را از حالت ایده به واقعیت تبدیل کند. حتی اگر به سراغ HackerRank و اینطور سایتها بروید، خواهید دید که یک مساله ساده، چندین مدل پیاده سازی دارد !

2- برنامه نویس مادر مرده از کجا بداند با چند مشکل، با چه میزان کلاس و اینترفیس و اسکریپت قرار است سر و کله بزند ؟ گاهی فقط تولید کد از نظر تایپ ساده هم به دلیل پیچیده و بزرگ بودن مساله، زمان بر و مشکل است . ضمنا از کجا بداند با چند Bug یا مشکل در پیاده سازی روبرو خواهد شد ؟

3- در اکثر موارد آنچه به عنوان تحلیل در اختیار برنامه نویس قرار می گیرد، فقط یک تحلیل سطحی یا مبتنی بر فهم تحلیلگر یا کارفرما یا مدیر از پروژه تا Task می باشد .  مابقی وجوه داستان باید در حین پیاده سازی توسط برنامه نویس کشف و پیاده سازی و تست گردد !  وقتی پای گزارش و پیاده سازی بیزینس وسط بیاید، داستان به طور کلی متفاوت خواهد بود.

4- وجود تعداد زیاد Library و سورس کد که قابل دانلود و استفاده می باشد هم یک عامل در متنوع بودن زمان بندیها خواهد بود. انتخاب یک سورس کد از Github و استفاده از آن در یک پروژه حال بدون توجه به اینکه انتخاب درست یا بهینه ای بوده یا نه و صرفا در جهت انجام کار، میتواند در عامل زمان تاثیر بسزایی داشته باشد.

5- در کارهای تیمی، خطا یابی و رفع مشکل به این سادگیها هم نیست. شکل خطایابی و حل مشکل تیمها می تواند متفاوت باشد. در کنار این مساله، باید دید آیا قدرت، هوش و تمرکز همه افراد یک تیم فنی یک دست است ؟ قطعا نیست.  پس نمی توان تیم A را با تیم B مقایسه نمود و این سبب میشود درخواست یک زمان بندی دقیق تقریبا غیر ممکن گردد، چرا ؟  چون معیار زمان بهینه و مورد قبول چیست ؟  اگر یک تیم زمان را 5 ماه و دیگری 2 ماه اعلام نمود، کدام یک  به ما زمان بندی دقیق ، درست و مبتنی بر واقعیتی داده است و میتوان به آن اعتماد کرد ؟

6- اصلا فرض کنید یک زمان بندی اولیه هم به ما داده شد. اگر در این بین نیاز به روالی داشتیم که به تفکر کردن و پیدا کردن راه حل نیاز داشت، از کجا بدانیم یک فرد یا یک تیم چطور می تواند تفکر کند، با چه سرعتی می تواند مشکلی را حل کند و این مساله کاملا نسبی است. این قصه شبیه فشار دادن دسته دستگاه پرس نیست که بشود با مثلا فریاد زدن یا تشویق یا تنبیه یا تهدید یا ایجاد هیجان به آن سرعت بخشید و میزان فشرده شدن دکمه پرس را در واحد زمان افزایش داد. یک برنامه نویس باید زمان داشته باشد تا فکر کند. چقدر زمان لازم دارد تا فکر کند ؟ کی میداند چقدر ؟

7- در تیمهای فنی، همیشه فریاد تیم تیم تیم و نزدیک بودن اعضای تیم به هم بلند است، وقتی در کنار آن پرفورمنس هر فرد مجزا و شخصی بررسی میشود . حالا اگر زمان بندی تیم توسط یک یا چند نفر خراب شد چه؟ اگر مثلا API آماده نشود، زمان بندی تیم فرانت اند چه میشود ؟  زمان بندی کل پروژه به فنا رفته است که !

در قسمت بعدی به بررسی چگونگی کمتر درب و داغان شدن و کمتر تاثیر بد پذیرفتن بر اثر زمان بندی غلط و غیر قابل اطمینان خواهیم پرداخت ...