دوره آزمایشی نرم افزار مدیریت پروژه: برنامه‌ی تست قدم‌به‌قدم
برای اینکه دوره آزمایشی نرم افزار مدیریت پروژه به تصمیم روشن برسد، یک پروژه‌ی واقعی و یک صف پشتیبانی واقعی را وارد سیستم کنید، همان کسانی را دعوت کنید که هر روز با آن کار خواهند کرد و سناریوها را مرحله‌به‌مرحله تست کنید. در پایان، پلن را بر اساس تعداد کاربر و امکاناتی که واقعاً استفاده شد انتخاب کنید، نه بر اساس فهرست ویژگی‌ها.
بیشتر دوره‌های آزمایشی بی‌نتیجه تمام می‌شوند، نه به این دلیل که نرم‌افزار بد بوده، بلکه چون کسی برنامه نداشته است. مدیر یک حساب می‌سازد، دو سه وظیفه‌ی نمونه مثل «تست ۱» تعریف می‌کند، چند منو را باز می‌کند و بعد کار روزمره او را با خودش می‌برد. آخر دوره هم تنها چیزی که می‌ماند یک حس مبهم است. این راهنما برای جلوگیری از همین اتفاق نوشته شده و نمونه‌ها را با هماهنگ، محصول برساوش فناوران برای پروژه و پشتیبانی، نشان می‌دهد؛ اما روش آن برای ارزیابی هر سامانه‌ای کاربرد دارد. اگر هنوز در مرحله‌ی مقایسه‌ی کلی معیارها هستید، اول راهنمای انتخاب سیستم مدیریت پروژه و تیکتینگ را بخوانید؛ این مقاله درباره‌ی گام بعد است: اجرای خود آزمایش.
قبل از شروع دوره آزمایشی چه چیزهایی را آماده کنیم؟
یک ساعت آماده‌سازی پیش از فعال شدن حساب، ارزش چند روز آزمون بی‌هدف را دارد:
- یک پروژه‌ی جاری، نه پروژه‌ی ساختگی: پروژه‌ای انتخاب کنید که همین حالا در جریان است، چند نفر درگیرش هستند و موعد واقعی دارد. داده‌ی نمایشی هیچ‌وقت گره‌های واقعی را نشان نمی‌دهد.
- یک صف پشتیبانی واقعی: اگر تیمتان به مشتری هم پاسخ می‌دهد، بخشی از درخواست‌های واقعی را وارد آزمایش کنید تا تیکتینگ هم سنجیده شود.
- آدم‌های درست: علاوه بر مدیر، دست‌کم یک کارشناس اجرایی، یک نفر از پشتیبانی و کسی که بیشتر وقتش بیرون از دفتر است را دعوت کنید. اگر فقط مدیران تست کنند، نتیجه درباره‌ی گزارش‌ها خوب است و درباره‌ی کار روزانه چیزی نمی‌گوید.
- پنج تا هشت معیار موفقیت: جمله‌هایی مثل «هیچ درخواست ایمیلی بدون مسئول نماند» یا «سرپرست بتواند از محل کار وضعیت را به‌روز کند». معیار مبهم، تصمیم مبهم می‌سازد.
- یک مسئول آزمایش: یک نفر که پیگیر برنامه باشد، سوال‌ها را جمع کند و با فروشنده در تماس بماند.
چطور نرم افزار مدیریت پروژه را تست کنیم؟ برنامه‌ی چهار مرحله‌ای
طول دوره‌ی آزمایشی را با فروشنده هماهنگ کنید و آن را به چهار مرحله‌ی تقریباً هم‌اندازه تقسیم کنید. اگر زمان کوتاه‌تر است، مرحله‌ها را فشرده کنید اما ترتیبشان را حفظ کنید.
مرحله‌ی اول: پروژه و وظایف
- پروژه‌ی انتخابی را بسازید و کارهای آن را به‌صورت وظیفه با مسئول و موعد تعریف کنید.
- چند وظیفه را به افراد مختلف واگذار کنید و ببینید هر نفر چطور از کار جدیدش باخبر می‌شود.
- برای موعدهای نزدیک یادآوری بگذارید و بررسی کنید که روی تقویم دیده می‌شود.
- یک نقشه، قرارداد یا عکس را به وظیفه‌ی مربوط پیوست کنید و از یک کاربر دیگر بخواهید پیدایش کند.
مرحله‌ی دوم: تیکت و درخواست مشتری
- یک ایمیل واقعی به نشانی پشتیبانی بفرستید و یک فرم وب را پر کنید؛ بررسی کنید هر دو به تیکت تبدیل می‌شوند. جزئیات این روند در مقاله‌ی تبدیل ایمیل به تیکت آمده است.
- تیکت را به یک کارشناس بدهید، اولویتش را تعیین کنید و پاسخ را تا بسته شدن دنبال کنید.
- گزارش پیشرفت پروژه را باز کنید و ببینید بدون پرسیدن از کسی می‌فهمید کار کجاست یا نه.
مرحله‌ی سوم: کار میدانی و ارتباط تیم
- از همکاری که بیرون از دفتر کار می‌کند بخواهید با اپ اندروید وضعیت یک وظیفه را عوض کند و یک فایل اضافه کند.
- اگر پلن پیشرو را می‌سنجید، یک گفت‌وگو در پیام‌رسان سازمانی را به یک وظیفه یا تیکت وصل کنید و بعد از چند روز ببینید هنوز کنار کار پیدا می‌شود.
- در همان پلن، تابلوی کانبان و گانت و داشبورد را با داده‌ی همین پروژه نگاه کنید، نه با نمونه‌ی آماده.
مرحله‌ی چهارم: جمع‌بندی و تصمیم
- معیارهای موفقیت را یکی‌یکی علامت بزنید: محقق شد، نیمه، محقق نشد.
- از هر کاربر سه جمله بخواهید: چه چیزی کارش را راحت‌تر کرد، چه چیزی گیج‌کننده بود، بدون چه چیزی نمی‌تواند کار کند.
- سوال‌های باقی‌مانده را برای فروشنده بفرستید و پلن مناسب را از روی داده‌های این دوره انتخاب کنید.
چک لیست آزمایش نرم افزار: کارت امتیاز
این جدول را در جلسه‌ی پایانی پر کنید. ستون «چه کسی تست کرد» مهم است؛ امتیازی که فقط مدیر داده باشد، نیمی از واقعیت است.
| سناریو | چه کسی تست کرد | نتیجه | پلن لازم در هماهنگ |
|---|---|---|---|
| ساخت وظیفه، واگذاری و موعد | مدیر پروژه و کارشناس | محقق / نیمه / نه | آغاز |
| یادآوری و تقویم | کارشناس اجرایی | محقق / نیمه / نه | آغاز |
| پیوست فایل به وظیفه | دو کاربر متفاوت | محقق / نیمه / نه | آغاز |
| ایمیل یا فرم وب به تیکت | کارشناس پشتیبانی | محقق / نیمه / نه | با فروشنده بررسی شود |
| گزارش پیشرفت | مدیر | محقق / نیمه / نه | آغاز |
| کار با اپ اندروید در محل | نیروی میدانی | محقق / نیمه / نه | آغاز |
| پیام‌رسان متصل به وظیفه و تیکت | کل تیم | محقق / نیمه / نه | پیشرو |
| کانبان، گانت و داشبورد | مدیر و سرپرست‌ها | محقق / نیمه / نه | پیشرو |
| پرتال مشتری و SLA | مسئول پشتیبانی | محقق / نیمه / نه | سرآمد |
کدام پلن هماهنگ؟ تصمیم بر اساس کاربر و امکانات
دو سوال پلن را تعیین می‌کند: چند نفر باید وارد سیستم شوند و کدام امکانات در دوره‌ی آزمایشی واقعاً به کار آمد.
- آغاز، تا ۱۵ کاربر: کارهای اصلی را پوشش می‌دهد: وظیفه و پروژه، صف تیکت، یادآوری تقویمی، فایل‌های پیوست، گزارش پیشرفت و اپ موبایل، همراه با پشتیبانی و به‌روزرسانی. اگر کارت امتیاز شما فقط در ردیف‌های آغاز سبز است، پلن بزرگ‌تر لازم نیست.
- پیشرو، تا ۵۰ کاربر: اگر تیم از کانبان و گانت، داشبورد، اتوماسیون اعلان‌ها، پیام‌رسان سازمانی یا تماس و جلسه‌ی داخلی استفاده کرد و نمی‌خواهد کنارشان بگذارد. پشتیبانی این پلن اولویت‌دار است.
- سرآمد، کاربر نامحدود: وقتی مشتری‌ها باید خودشان از پرتال درخواست ثبت و پیگیری کنند، تعهد سطح خدمات لازم است، روند کار شما با گردش‌کار سفارشی تعریف می‌شود یا سطوح دسترسی سازمانی می‌خواهید. استقرار و آموزش هم در این پلن آمده است.
یک خطای رایج این است که پلن را بر اساس تعداد امروز تیم انتخاب کنند. اگر می‌دانید تیم در دوره‌ی قرارداد بزرگ‌تر می‌شود، این موضوع را همان ابتدا با فروشنده مطرح کنید.
ابری یا روی سرور خودمان؟ این را هم در آزمایش بسنجید
محل نصب هماهنگ انتخابی است: سرویس ابری یا سرور داخلی شرکت؛ دسترسی وب و اپ اندروید به این انتخاب بستگی ندارد. در دوره‌ی آزمایشی از خودتان بپرسید: نیروهای بیرون از دفتر از کجا وصل می‌شوند؟ آیا تیم فناوری اطلاعات توان نگه‌داری و پشتیبان‌گیری سرور را دارد؟ سیاست سازمان درباره‌ی محل نگه‌داری اطلاعات مشتری چیست؟ برای مقایسه‌ی مفصل‌تر، نصب نرم‌افزار مدیریت پروژه روی سرور سازمان را ببینید.
ارزیابی نرم افزار تیکتینگ قبل از خرید: سوال‌هایی برای فروشنده
- داده‌هایی که در دوره‌ی آزمایشی وارد کرده‌ایم بعد از خرید چه می‌شود؟ (این را صریح بپرسید و پاسخ را مکتوب بگیرید.)
- آیا اطلاعات فعلی ما از اکسل یا نرم‌افزار قبلی منتقل می‌شود و دامنه‌اش در کدام پلن یا بند قرارداد می‌آید؟ برساوش فناوران این انتقال را به‌عنوان خدمت انجام می‌دهد.
- آموزش کاربران و راه‌اندازی چطور انجام می‌شود و در کدام پلن آمده است؟
- پشتیبانی از چه کانالی است و پلن پیشرو و سرآمد چه تفاوتی در اولویت پاسخ دارند؟
- اگر تعداد کاربران از سقف پلن بیشتر شد، ارتقا چگونه است؟
- به‌روزرسانی‌ها چطور اطلاع‌رسانی و اعمال می‌شوند، به‌ویژه در نصب روی سرور سازمان؟
اشتباه‌هایی که دوره آزمایشی را هدر می‌دهد
- تست با داده‌ی ساختگی و وظیفه‌هایی که هیچ‌کس مسئولش نیست.
- دعوت نکردن کاربران میدانی و پشتیبانی تا روزهای آخر.
- سنجیدن همه‌ی امکانات به‌جای امکاناتی که واقعاً لازم دارید.
- تصمیم بدون جلسه‌ی پایانی و بدون نوشتن نتیجه‌ی هر معیار.
سوالات متداول
دوره آزمایشی هماهنگ چقدر است؟
هماهنگ دوره‌ی آزمایشی دارد و شرایط و مدت آن را کارشناسان برساوش فناوران هنگام درخواست با شما هماهنگ می‌کنند.
چند نفر را باید در آزمایش وارد کنیم؟
کافی است از هر نقش اصلی یک نفر حضور داشته باشد: مدیر، کارشناس اجرایی، پشتیبانی و نیروی میدانی. تعداد کم ولی متنوع، نتیجه‌ی واقعی‌تری از جمع بزرگ ولی یکدست می‌دهد.
آیا در آزمایش باید همه‌ی امکانات را امتحان کنیم؟
نه. فقط سناریوهایی را بسنجید که در کار روزانه‌ی شما تکرار می‌شوند. امکاناتی که استفاده نشدند، دلیلی برای انتخاب پلن بالاتر نیستند.
پرتال مشتری و SLA را در کدام پلن می‌توان سنجید؟
پرتال مشتری، تعهد سطح خدمات، گردش‌کار سفارشی و سطوح دسترسی سازمانی در پلن سرآمد هماهنگ هستند. اگر به آن‌ها نیاز دارید، پیش از شروع بگویید تا در آزمایش دیده شوند.
بعد از آزمایش، اطلاعات قبلی ما چطور منتقل می‌شود؟
انتقال اطلاعات فایل‌های اکسل یا سیستم قدیمی خدمتی است که برساوش فناوران ارائه می‌دهد و دامنه‌ی آن در پلن و قرارداد مشخص می‌شود.
برای برنامه‌ریزی آزمایش با پروژه‌ی واقعی خودتان، درخواست دمو و آزمایش هماهنگ را بفرستید یا ابتدا صفحه‌ی سامانه مدیریت پروژه و تیکتینگ را مرور کنید.
