آموزش تحلیل نرم افزار بخش اول

[سید علا سبزپوش]

سعی دارم در سلسله مقالاتی مسایل مهم که در تحلیل و مهندسی نرم افزار نقش مهمی دارند را برای شما در چند مقاله بنویسم

بخش اول

علاقه مندیهای مشتری

فرض کنید که یک مشتری می خواهد یک سایت برای فروش وسایل کوهنوردی ایجاد کند ، در این سایت مشتریان می توانند وسایل کوهنوردی را بخرند ، خوب این مشتری به شما مراجعه می کند و از شما می خواهد که سایتی برای او طراحی و ایجاد کنید .

گام اول : 2 چیز در هر پروژه نقش حیاتی دارد.

1چقدر هزینه دارد؟

2-چقدر زمان لازم دارد؟

نکته مهم این است که مشتری هم از نظر بودجه و هم از نظر زمانی ، محدودیت دارد و ما همیشه باید این نیاز مشتری را درک کنیم ، نمی توانیم زمان را بی پایان یا خیلی زیاد بدهیم ،

 

گام اول که ما انجام می دهیم

در گام اول مشتری فقط ایده را به ما ارایه می کند ، وما برداشتی اولیه خواهیم داشت ، در مثال بالا، ما در برآورد اولیه تصور می کنیم که این سایت به تعدادی کد  html,java script ,css  نیاز دارد

برای ارایه زمان و بودجه دو راه وجود دارد

1-تکراری : اگر پروژه پیشنهادی ما از قبل انجام شده و ما نیاز به ایجاد پروژه جدیدی نداریم ، مشکل ما حل شده است ، چرا که فقط نیاز به تغییرات گرافیکی و کدهای ساده ای دارد

2-جدید : مشکل اینجاست ، اگر پروژه کاملا جدید باشد و ما از قبل انجام نداده باشیم ، سختی کار اینجاست ،

چون تا زمانی که اطلاعات کافی نداشته باشیم ، نمی توانیم زمان و هزینه را برآورد کنیم .

اشتباهی که اکثرا انجام می دهند ، همان برآورد اولیه است ، یعنی افراد قبل از تشخیص کامل نیاز مشتری اقدام به تولید یک نرم افزار می کنند ، به عبارتی تشخیص نیازهای آنان به نوعی توهم و برآوردی و ساخته ذهن آنان است ، در نتیجه خروجی محصول مطابق آنچه در ذهن مشتری است نمی باشد ، پس پروژه ، ناموفق خواهد بود

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

 

1-حالت اول : ممکن است از نظر کد نویسی سایت کاملا نیاز مشتری را برآورده می کند اما ساختار سایت مطابق میل مشتری نیست لذا مشتری آن را نمی پسندند و از آنجا که به امور فنی آگاه نیست ، پروژه را نمی پذیرد

2-حالت دوم : بدلیل عدم داشتن ارتباط با مشتری ممکن است سایت هم از نظر ساختاری و هم از نظر گرافیکی نظر مشتری را جلب کند ولی کار کردن با آن سخت باشد لذا مشتری از کار با آن هراس دارد و این امر در مورد بیشتر مشتریان صادق است ، اکثر کاربران نرم افزار ها از دست زدن به برخی از گزینه های نرم افزاری هراس دارند . خوب نتیجه شکست پروژه

 

3-حالت سوم: ممکن است هم ساختار و هم گرافیک و هم سهولت ، نظر مشتری را جلب کند ، اما برخی حالتهای ویژه برای مشتری مد نظر هست که در سیستم وجود ندارد مثلا در مثال بالا اگر مشتری به سایت مراجعه کند و کالایی را انتخاب کرد ، ولی آن کالا موجودی نداشت راه کار چیست ؟

 

پس با بررسی 3 حالت فوق به این نتیجه می رسیم که اشتباه عمده برنامه نویسان و تحلیل گران در تحلیل نیازهای مشتریان ، حدس و گمان است ، یعنی حدس می زنند که اگر نرم افزار اینگونه باشد و فلان امکان را داشته باشد بهتر است ، اما در دنیای واقع که با مشتری روبرو می شویم  ، واقعیت چیز دیگری را نشان می دهد

حقیقت آن است که بیشتر مشکلات تحلیل همان حدس و گمان افراد تحلیل گر است ، تحلیل کاملا با حدس و گمان متناقض است ، شما باید برای فهمیدن نیازهای مشتری ، مشتری را در یک حلقه loop   پرس و جو قرار دهید تا بتواند ، آنچه درذهن او می گذرد را به واقعیت تبدیل کنید و آنچه که در ذهن او غیر واقعی بود با ارایه استدلال منطقی به واقعیت تبدیل کنید . به قولی دیگر رابطه  face to face  با مشتر ی برای فهمیدن نیازهای آن امری حیاتی است.

 

استراتژی اولیه

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

فراموش نکنید که همه چیز را مکتوب کنید و اگر می توانید از مشتری امضای تایید بگیرید تا بعدا اگر حرف خود را عوض کرد ، مسولیتش به عهده او باشد .

 

استراتژی تکرار برای رسیدن به هدف

اشتباه بزرگ گروههای برنامه نویسی این است که فکر می کنند باید تمام مراحل تحلیل و تشخیص نیازمندیها را در همان اول کار انجام دهند ، سپس شروع به کد نویسی کل پروژه می کنند . اشتباه اشتباه اشتباه

 
شما باید از استراتژی تکرار استفاده کنید ، د ر  این استراتژی پروژه شما به تدریج بزرگ می شود ، همچنین هر محله کاری شما هم تحلیل و هم کدونیسی را دارد به دو شکل زیر دفت کنید



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

 
اما در استراتژی تکرار ما به تبع انجام تحلیل و تشخیص نیازها ، کار کد نویسی هم انجام می شود ، در این حالت شما در هز بار ملاقات با مشتری در واقع یک نسخه از سیستم به مشتری تحویل می دهید ، علاوه بر این مشتری در این حالت یکی از اعضای پروژه است  نمودار زیر را نگاه کنید



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




همانطور که در شکل بالا می بینید ، نرم افزار در هر محله تکرار ، شما 4 مرحله اصلی تولید را انجام می دهید

1-تشخیص نیازها 2-طراحی 3-کد نویسی 4-تست نرم افزار

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

به عبارت دیگر هر تکرار در واقع خود یک پروژه کوچکی است.


این بحث ادامه دارد

[سید علا سبزپوش]

بخش دوم

مشتری چه می خواهد؟

همه ما می دانیم سخت ترین بخش تحلیل دانستن و شناخت نیازهای مشتری است . در این بخش به برخی روشهای می پردازیم

فرض کنید یک آژانس خدمات مسافرتی ، تورهایی را برگزار می کند ، مدیر عامل این شرکت به شما اینگونه سیستم را توصیف می کند

1-سیستمی تحت وب که در اینترنت کار کند

2-معاملات و سفارشات را بتوانیم پی گیری کنیم

3-کاربران بتوانند یصورت آنلاین تور ثبت نام کنند

4-کاربران بتوانند هتل مورد نظرشان را انتخاب کنند

 

شما آنالیزور سیستم  هستید و باید در ابتدا با مدیر عامل شرکت صحبت کنید مرحله اول با مدیر یک جلسه کاری خواهید داشت ، قبل از جلسه فرمهای جمع آوری اطلاعات به شکل زیر آماده کنید



در بخش عنوان شما باید سرفصل را بنویسید ودر بخش description  توضیحات مربوط به آن عمل را تا حد امکان یادداشت کنید ، دقت کنید که در هر برگه فقط و فقط یک عمل را بنویسید این نکته بسیار مهمی است ،

تمام افکار مدیر عامل را عنوان بندی به همران توضیحات یادداشت کنید و همانطور که گفتم و دوباره تاکید می کنم هر عنوان برگه فقط و فقط یک عمل را انجام می دهد

 

الان فرض کنید یکی از موارد 4 گانه بالا را در یک برگ می نویسیم فرض کنید مورد چهارم انتخاب هتل،

خوب عنوان موضوع : انتخاب هتل توسط مشتری

توضیح : کاربران باید بتوانند از لیست پیشنهادی سایت هتل مورد نظرشان را بر اساس تعداد ستاره ها انتخاب کنند

این تازه اول کار است

پس از آنکه شما کلیه سرفصلها را نوشتید کمی در مورد آنها فکر کنید حالا نوبت شماست ، شما باید هر گونه سوالی که داشتید از مشتری بپرسید شما می توانید در همان جلسه و یا شاید جلسه بعدی سوالات خود را بپرسید .

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

با هر کدام از پرسنل شرکت یا سازمان صحبت کنید ابتدا ایده های آنان را بپرسید همانند کاری که با مدیر عامل انجام دادید و سپس سوال و جواب خود را بپرسید
یک نکته مهم

شما الان هم با پرسنل شرکت و هم با مدیر عامل صحبت کرده اید ، باید جمع بندی اولیه از نیازها داشته باشید

اما مشکل شما این است که اگر چه مشتری نیازهای خود را بیان کرده است اما نمی داند که شما چکا رمی کنید و قراره چه کاری انجام دهید ، هنوز خیلی چیزهای نا معلوم است ، خوب راهکار چیست ؟

 

شما باید از جلوه های بصری استفداده کنید مثلا اگر می توانید در این مرحله نسخه کوچک از نرم افزار بنویسید خیلی خوب است البته در این مرحله صرفا تاکید بر روی اینترفیس است همان ظاهر نرم افزار است و شاید هم شما با استفاده ار ابزارهای دیگر فرض کنید  power point  روال نرم افزار را بصورت گرافیکی برای مشتری نمایش می دهید .

علاوه بر این بد نیست که شما نحوه کار و روال و فرایندهای کاری پرسنل سازمان را از نزدیک ببینند و مشاهدات خود را یادداشت برداری کنید .

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

 

یک نکته : همیشه زمان مصاحبه را با کاربران را غنیمت بشمرید چون مشتری بدلیل مسایل کاری حاضر نیست هر وقت بخواهید کاربران خود را برای جواب دادن به سوالهای شما در اختیارتان قراردهد

 

خلاصه ای که تا الان فهمیدیم آن است که ما ابتدا ایده ها را می گیریم و سپس بر اساس تجربه خود سعی می کنیم سوالاتی را مطرح کنیم که به واسطه این سوالات به جزییات سیستم پی می بریم

علاوه بر آن اگر سیستم برای یک شرکت یا سازمان باشد نباید دایره تحقیق خود را به یک نفر محدود کنیم بلکه حتما تا حد امکان با تعدادی بیشتری از پرسنل که قرار است با سیستم کار کنند مصاحبه کنیم.

 

خوب اکنون شما مصاحبه هایی را انجام داده اید به شرکت خود بر می گردید ، جلسه اول با برنامه نویسان شرکت ، توجه داشته باشید که هم فرد تحلیل گر و هم تیم برنامه نویسی باید و باید در مورد موضوع پروژه اطلاعاتی داشته باشند ، فرضا اگر قرار است سیستم حسابداری بنویسید همگی سعی کنید در مورد حسابداری مطالعاتی داشته باشید و غیره

 

خوب تیم برنامه نویسی به همراه تحلیل گر تشکیل جلسه می دهد ، تصمیم حیاتی باید گرفته شود

1-این پروژه چقدر زمان می برد؟

2-این پروژه چقدر هزینه دارد؟

یکی از اشتباهات رایج آن است که تحلیل گران بدون پرسیدن نظر تیم برنامه نویسی و در نظر گرفتن امکانات و تواناییهای آنان زمان را خودشان مشخص می کنند و این از اشتباهات مهلک پروژه ها است

شما باید نتیجه تحلیل خود را در اختیار تیم برنامه نویسی قرار دهید ، آنها با شما مانند یک مشتری رفتار می کنند ، یعنی آنها می شوند تحلیل گر و شما آنالیزور ، تبدیل به مشتری می شوید ، در طی همین جلسه سوالات بیشتری مطرح خواهد شد که فرد تحلیل گر ممکن است برای آنها جوابی نداشته باشد و باید دوباره با مشتری جلسه داشته باشد

علاوه بر آن تیم برنامه نویسی پس از اطلاع از چند وچون پروژه ، برای هر عمل نوشته شده در کارتهای بالا (شکل1 ) زمان مورد نیاز خود را مطرح می کندعلاوه بر این فرمها را تفکیک می کنید شما باید اینگونه تفکیک کنید

1-مبنای محاسبه بر اساس فرم است خوب فرم خود را مشخص کنید زمان مورد نیاز برای طراحی گرافیکی فرم چقدر است

2-زمان پیاده سازی کدهای مربوط به آن فرم چقدر است ؟

3-زمان مورد نیاز برای طراحی بانک اطلاعاتی مورد نیاز برای آن فرم چقدر است ؟

4-زمان مورد نیاز برای نوشتن کویری   query  مناسب برای عملیات آن فرم چقدر است ؟

5-زمان مورد نیاز برای پیاده سازی هر گزارش چقدر است ؟

 

 خوب فرد تحلیل گر همه زمانها برای هر کدام از اعمال را جمع آوری می کند . نباید اختلاف بین برنامه نویسان زیاد باشد مثال زیر دقت کنید که سه برنامه نویس برای انجام هر کدام از اعمال زیر زمان مورد نیاز را پیش بینی کرده اند

 

 

نوع عمل                           برنامه نویس 1                برنامه نویس 2                برنامه نویس 3

 

پی گیری معاملات                        6 روز                           7 روز                            10 روز

اضافه کردن لیست هتلها                 5 روز                            10 روز                           15 روز

 

و غیره

 

همانطور که می بیند هر کدام از برنامه نویسان تخمین متفاوتی داده است اما نباید اختلاف زمانی خیلی زیاد باشد ریشه این اختلاف برآورد زمانی در کجاست ؟

1-ممکن است تیم برنامه نویسی شما منسجم نباشد و ازنظر تجربه با هم اختلاف فاحشی دارن

2-ممکن است تحلیل شما مشکل دارد و به تبع آن برداشت و فهم برنامه نویسان متفاوت بوده است

 

دقت کنید مورد اول قابل حل است و ربطی به تحلیل و مشتری ندارد سعی کنید تیم برنامه نویس شما پا به پای هم رشد کنند

اما مورد دوم کمی مشکل تر است ، فهم افراد متفاوت است ، شما باید مواردی که زمان برآوردی تیم شما اختلاف دارد را دوباره بازنگری کنید و دوباره آن را به برنامه نویسان خود تفهیم کنید هر کدام از برنامه نویسان باید دلیل قانع کننده برای زمان پیشنهادی خود ارایه دهد

شما گام به گام حرکت کنید

از اولین کارت تحلیل شروع کنید ، زمان تخمینی هر کدام را یادداشت کنید و در هر صورت برنامه نویسان دلیل خود را هم باید بیان کنند ، با هم بحث کنید که چرا اینقدر زمان می برد ، قرار است از چه ابزاری استفاده کنید و الی آخر تا سر زمان توافقی برسید و همچنین به روش نوشتن توافق کنید

سپس به کارت دوم تا آخر به همان ترتیب ادامه دهید  . وقتی تمام کارتهای تحلیل را بررسی کردید و بر زمان مورد نیاز توافق حاصل شد در آخر جمع کل زمانها را یادداشت کنید و آن را به مشتری اعلام کنید

خوب فرض کنید ما زمان را جمع کردیم نتیجه حاصل این بود که برای انجام این پروژه به 248 روز زمان نیاز است

وای چقدر زیاد مشتری قبول نمی کند ، مشتری نهایتا 90 روز را قبول می کند خوب راهکار چیست چه باید کرد

ادامه این بحث و جواب این سوال را در بخش بعدی خواهم گفت

امیدوارم تا اینجا مفید بوده

[سید علا سبزپوش]

بخش سوم

برنامه زمانی عملی

مشتری نرم افزار خود را در زمانی که خود معین می کند لازم دارد ، ما نیازمندیهای مشتری را داریم و تخمین زدیم که هر کدام از کارتهای نیازمندیها چقدر زمان می برد مشکل اینجاست که انجام همه آنها با توجه به برآورد ما زمان زیادی می طلبد .

آنچه مشتری می خواهد زمان 90 روزه
آنچه ما با یک نفر نیرو تخمین زدیم زمان 489 روزه است

خوب راه حل چیست ؟ چه کار باید کرد ؟
برای جواب به این سوال ابتدا شما باید فاصله زمانی تکرارها را مشخص کنید
همانطور که گفتیم ما در تحلیلمون به 2 مورد مهم نیاز داشتیم
1-user story   یا همان کارتهای داستانهای کاربر است که هر کدام یک نیاز توضیح می داد . ما باید از نیازهای کاربران مطلع باشیم . نیازی نیست همه چیز را از اول بدانیم و از جزییات آگاه باشیم بلکه نیازهای کلی در مرحله اول کافیست
2- iteration  تکرارها در واقع چرخه زمانی بود که در پایان هر چرخه یا تکرار جزیی از پروژه تحویل مشتری می شود .
پروژه باید به دوره های زمانی کوتاه مدت تقسیم بندی شود . مثلا 2 هفته ای یا ماهانه و در پایان هر دوره بخشی از نیارهای مشتری را تحویل می دهیم. و از مشتری نظر خواهی می کنیم و اگر نیازی بود نظر مشتری ،سریعا اعمال می شود و وارد دوره بعدی(iteration) می شویم 
وقتی یک تکرار iteration   جدید آغاز می شود . مشتری دیگر حق عوض کردن نیازهای قبلی خود را ندارد زیرا بر سر آن توافق شده است .

خوب با این مقدمه حالا شما در مقابلتان مجموعه ای از کارتهای نیازمندیها را می بینید که حاصل جلسات مشترک با مشتر ی است . از طرفی دیگر شما محدودیت زمانی دارید.
شما باید از بین کارتها ، کارتهایی (نیازهایی ) را اولویت بندی کنید که در همان محدوده مشخص شده توسط مشتری انجام شوند. شما بعد از بررسیهای طولانی و سخت ، بالاخره باید کارتهای نیازمندیها را اولویت بندی کنید.
برای اینکار با مشتری جلسه  بگزارید و مهمترین نیازها را تشخیص دهید و به آنها امتیاز دهید . شما در این جلسه باید به عنوان یک کارشناس به
مشتری کمک کنید تا بتواند اولویتها و نیازهای اولیه خود را تشخیص و انتخاب کند . فراموش نکنید که انتخاب اولویتها به عهده مشتری باشد.
خوب اکنون که نیازها اولیت بندی شد . شما باید ببینید که قرار است چند دوره تکرار در پروژه داشته باشید ، مثلا اگر قرار است زمان 90 روز باشد شما می توانید برای هر دوره تکرار زمان 30 روزه تعیین کنید
پس حالا در تکرار اول ، نیازهایی که دارای بالاترین اولویتها است را انتخاب کنید و آنها را در دوره اول تکرار انجام دهید و به همان ترتیبب در دوره بعدی تا آخر پروژه.
اما شما حالا اولویتها را مشخص کرده اید ، و تصمیم گرفتید که برخی اولویتها را در فاصله زمانی 30 روزه انجام دهید ، اما وقتی نگاه می کنید متوجه می شوید که زمان مورد نیاز این اولویتها بیش از 30 روز است .
خوب حالا شما باید دوباره اولویتها را مرور کنید و فقط نیازهایی را انتخاب می کنید که در محدوه قابل انجام باشد و همچنین نیازهای مهمتری هستند

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

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

2-فهمیدن نرم افزار : شما باید دقت کنید که یکی از موارد مهم در گروه نرم افزاری این است که افراد گروه ، پروژه را بفهمند ودرک کنند ، چرا که افراد نمی توانند بر چیزهای مبهم ونامعلوم براحتی کارکنند .

3-تصمیمات فنی و تکنیکی : شما باید یک روال و فرایندی برای تصمیمات فنی داشته باشید . مثلا با هماهنگی گروه تصمیم می گیرید که برای کار از چه ایزارهایی استفاده کنید که همگی به آن آشنا باشند و سرعت عمل شما را بالا می برد . از چه زبان برنامه نویسی استفاده می کنید.
چگونه کارهای برنامه را تقسیم بندی کنید و چگونه دوباره آنها را با هم تلفیق دهید

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


20  ضربدر 70 درصد = 14

عدد 20 نشان دهنده روزهای کاری است چرا که شما در یک فاصله 30 روزه تقویمی نمی توانید 30 روز کار کنید و بصورت تقریبی فقط 20 روز کاری دارید علاوه بر این در این 20 روز افراد شما 24 ساعته کار نمی کنند همچنین با در نظر گرفتن اوقات تلف شده فقط تا 70 در صد در هر روز شاید مفید باشند یعنی هر نفر از پرسنل شما در ماه کاری فقط تا 14 روز مفید می تواند کار کند .

ادامه دارد