تفاوت تعهد، برآورد و هدف برای تیم های نرم‌افزاری در توسعه محصول

به این جمله دقت کنید: " براساس برآورد من، ما میتوانیم در تاریخ x برای رسیدن به هدف y متعهد باشیم"

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

برآورد Estimate:

برآورد کردن در حقیقت همان حدس زدن درمورد زمان اتمام کاری (task) توسط تیم توسعه دهنده است و این حدس زدن میبایست براساس داده های قبلی، همانند عملکرد تیم برای تسک های مشابه در گذشته باشد. از طرف دیگر برآورد را نمی توانیم به یک عدد مشخص مانند روز و ساعت نسبت دهیم، بلکه برآورد می بایست به صورت "محدوده" Range در نظر قرار بگیرد.

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

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

هدف Target:

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

تعهد Commitment:

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

بعنوان مثال:

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

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

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

یکبار دیگر با هم مرور می کنیم:

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

اهداف: زمان هایی هستند که باید به آنها برسیم (deadline) به صورت معمول دد لاین ها توسط افرادی خارج از تیم توسعه تعیین می شوند.

تعهدات: زمانی است که تیم توسعه خود را متعهد می داند تا پایان آن کار یا محصول مورد نظر را تحویل دهد.

تعهدات چگونه مدیریت می شوند:

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

کجا به مشکل میخوریم:

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

این مشکل به چه دلیل به وجود می آید؟

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

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

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

چرا برآورد ها ترسناک هستند:

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

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

راهکار چیست:

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