ایسی ہدایات جن پر اچھی کوٹیشن بنے

ہدایات کوٹیشن کیوں طے کرتی ہیں

آپ کے منصوبے کی کوٹیشن دینے والا اسٹوڈیو گھنٹوں کا اندازہ لگا رہا ہوتا ہے۔ جہاں آپ کی ہدایات واضح ہوں، تخمینہ قریب ہوتا ہے۔ جہاں مبہم ہوں، اسٹوڈیو کو اندازہ لگانا پڑتا ہے، اور ہر ایک مختلف اندازہ لگاتا ہے: ایک عدد کم رکھنے کے لیے سب سے سادہ ورژن فرض کرتا ہے، دوسرا اپنے بچاؤ کے لیے سب سے پیچیدہ۔ آخر میں آپ قیمتوں کے بجائے اندازوں کا موازنہ کر رہے ہوتے ہیں۔

اچھی ہدایات اندازے ختم کر دیتی ہیں۔ انہیں لمبا ہونے کی ضرورت نہیں، اور انہیں سافٹ ویئر ڈیزائن کرنے کی کوشش نہیں کرنی چاہیے۔ انہیں بیان کرنا ہے کہ اسے کون استعمال کرے گا، انہیں کیا کرنا ہے، یہ کس سے جڑتا ہے، کون سا ڈیٹا رکھتا ہے اور کن پابندیوں میں رہتا ہے۔ یہی جواب زیادہ تر گھنٹے، اور اسی لیے زیادہ تر کوٹیشن، طے کرتے ہیں۔

اچھی ہدایات میں کیا ہوتا ہے

1. 01

   مسئلہ، ایک پیراگراف میں

   آج کیا غلط ہو رہا ہے، کس کے لیے، اور اس سے آپ کا کتنا وقت، کتنی غلطیاں یا کتنا کاروبار ضائع ہوتا ہے۔ یہی اسٹوڈیو کو کوئی سادہ جواب تجویز کرنے دیتا ہے اگر ہو۔

2. 02

   صارفین

   اسے استعمال کرنے والا ہر قسم کا شخص: گاہک، عملہ، مینیجرز، ایڈمنسٹریٹرز، شراکت دار۔ ہر ایک کے لیے وہ تین سے پانچ کام جو اسے کر سکنا لازم ہے۔

3. 03

   اسکرینز

   صفحات یا اسکرینز کی ایک کچی فہرست۔ اس کا درست ہونا ضروری نہیں؛ اس کا ہونا ضروری ہے۔ اسکرینز حجم کی سب سے واضح اکائی ہیں۔

4. 04

   انضمامات

   ہر وہ سسٹم جس سے اسے بات کرنی ہے: اکاؤنٹنگ، ⁨CRM⁩، ⁨ERP⁩، پیمنٹ فراہم کنندہ، ای میل، سنگل سائن آن، کسی شراکت دار کی ⁨API⁩۔ اگر معلوم ہو تو پروڈکٹ اور ورژن کا نام لیں۔

5. 05

   ڈیٹا

   یہ کیا محفوظ کرتا ہے، تقریباً کتنا، کیا اس میں سے کچھ ذاتی یا ضابطہ شدہ ہے، اور کیا موجودہ ڈیٹا کسی پرانے سسٹم سے منتقل کرنا ہے۔

6. 06

   پلیٹ فارمز

   صرف ویب، یا ⁨iOS⁩ اور ⁨Android⁩ ایپس بھی۔ کون سے براؤزرز اور ڈیوائسز اہم ہیں۔ کیا اسے آف لائن کام کرنا ہے۔

7. 07

   پابندیاں

   حقیقی ڈیڈ لائنز (لانچ کی تقریب، کسی ضابطے کی تاریخ) اور وہ جو صرف ترجیحات ہیں۔ ہوسٹنگ کے تقاضے، جیسے ڈیٹا کینیڈا میں رکھنا۔ رسائی اور زبان کے تقاضے۔

8. 08

   پہلے سے کیا موجود ہے

   ڈیزائنز، برانڈ گائیڈ، پرانا سسٹم، ابتدائی نمونہ، دستاویزات۔ ہر ایک کام بچا بھی سکتا ہے، بڑھا بھی سکتا ہے۔

9. 09

   لانچ کے بعد

   اسے کون چلائے گا، صارفین کی مدد کون کرے گا، اور کیا آپ سپورٹ پلان چاہتے ہیں یا آپ کی اپنی ٹیم سنبھالے گی۔

10. 10

    بجٹ کی حد

    یہ سودے بازی میں خطرہ لگتا ہے، لیکن یہ جاننے کا سب سے تیز طریقہ ہے کہ آپ کا خیال اس میں آتا ہے یا نہیں، اور نہ آئے تو کیا کاٹیں۔ اچھا اسٹوڈیو بتائے گا کہ اس کے اندر کیا حقیقت پسندانہ ہے۔

فیچرز نہیں، اسکرینز اور صارفین گنیں

فیچرز کی فہرستیں وہ جگہ ہیں جہاں ہدایات غلط ہوتی ہیں۔ “صارفین کا انتظام” کا مطلب ایک سائن اِن صفحہ بھی ہو سکتا ہے اور رولز، دعوت ناموں، منظوریوں اور آڈٹ لاگز کا مکمل نظام بھی۔ صارفین اور اسکرینز کی فہرست کو غلط پڑھنا مشکل ہے، کیونکہ ہر اسکرین کو ڈیزائن، تعمیر اور جانچ سے گزرنا ہے، اور صارف کی ہر قسم ان سب میں اجازتیں شامل کرتی ہے۔

پانچ منٹ میں لکھی بیس کے قریب اسکرینز اور صارفین کی چار اقسام اسٹوڈیو کو فیچرز کی تفصیل کے تین صفحات سے زیادہ بتاتی ہیں۔ اگر یقین نہ ہو کہ کوئی چیز ایک اسکرین ہے یا دو، تو یہی کہہ دیں؛ یہ پہلی کال کے لیے اچھا سوال ہے۔

ہر انضمام اور ڈیٹا کے ہر ماخذ کا نام لیں

انضمامات وہ جگہ ہیں جہاں تخمینے سب سے زیادہ غلط ہوتے ہیں، کیونکہ دوسرا سسٹم کسی کے اختیار میں نہیں۔ اس کی دستاویزات پرانی ہو سکتی ہیں، اس کا ٹیسٹ ماحول موجود نہ ہو، اور اس کی حدیں صرف حقیقی استعمال میں ظاہر ہوں۔ ہر انضمام کا نام لینے والی ہدایات اسٹوڈیو کو کوٹیشن سے پہلے ہر ایک جانچنے دیتی ہیں، بجائے اس کے کہ دوسرے مہینے میں پتا چلے۔

• پروڈکٹ کا نام لیں: “ہمارا اکاؤنٹنگ سافٹ ویئر” کے بجائے “⁨QuickBooks Online⁩”۔
• بتائیں کہ ڈیٹا کس سمت جاتا ہے: صرف پڑھنا، صرف لکھنا، یا دونوں، اور کتنی بار۔
• بتائیں کہ کیا آپ کے پاس پہلے سے ⁨API⁩ کی رسائی ہے، یا اسے کون دے گا۔
• کسی پرانے سسٹم سے ڈیٹا کی منتقلی کا ذکر کریں، ریکارڈز کی تخمینی تعداد اور آپ کے خیال میں وہ کتنے صاف ہیں۔

پابندیاں صاف بیان کریں

پابندیاں زیادہ تر فیچرز سے زیادہ کام بدلتی ہیں، اس لیے انہیں لکھ دیں چاہے وہ واضح لگیں۔

• رسائی: اگر سافٹ ویئر عوامی ہے تو بتائیں کہ کون سی سطح چاہیے۔ ⁨W3C⁩ کی رسائی کی رہنما ہدایات ⁨A⁩، ⁨AA⁩ اور ⁨AAA⁩ سطحیں طے کرتی ہیں ⁦^[1]⁩، اور کسی ایک کا نام لینا ایک مبہم خواہش کو ایسے تقاضے میں بدل دیتا ہے جس کی قیمت لگائی اور جانچ کی جا سکے۔
• پرائیویسی: اگر اس میں ذاتی معلومات ہیں تو بتائیں۔ کینیڈا کا ⁨PIPEDA⁩ معلومات کے منصفانہ اصولوں پر قائم ہے جیسے رضامندی، جمع کرنے کی حد، حفاظتی اقدامات اور انفرادی رسائی ⁦^[2]⁩۔ آپ کے مشیر بتا سکتے ہیں کہ کیا لاگو ہے؛ اسٹوڈیو کو یہ جاننا ہے کہ یہ لاگو ہے۔
• ضابطہ شدہ ڈیٹا: صحت، مالیات یا حکومت کے ڈیٹا کے اپنے قواعد ہیں۔ ان کا ذکر پہلی گفتگو میں کریں، کوٹیشن کے بعد نہیں۔
• ہوسٹنگ: کیا ڈیٹا کینیڈا میں رہنا لازم ہے، کیا آپ کا کوئی پسندیدہ کلاؤڈ فراہم کنندہ ہے، یا کیا اسے آپ کے اپنے سرورز پر چلنا ہے۔
• زبانیں: پہلے دن سے انگریزی اور فرانسیسی ایک مختلف منصوبہ ہے، بمقابلہ ابھی انگریزی اور بعد میں فرانسیسی۔
• ڈیڈ لائنز: کون سی تاریخیں طے ہیں، اور کیوں۔

کیا چھوڑ دیں

ہدایات کوئی ڈیزائن یا تکنیکی تفصیل نہیں، اور ایسی لکھنے کی کوشش عموماً الٹی پڑتی ہے۔

• ٹیکنالوجی چھوڑ دیں، جب تک یہ حقیقی پابندی نہ ہو (آپ کی ٹیم پہلے سے کوئی خاص نظام چلاتی ہو، یا کوئی ریگولیٹر کوئی خاص ہوسٹ لازم کرے)۔ اسٹوڈیو کو اپنا انتخاب تجویز کرنے اور سمجھانے دیں۔
• تفصیلی اسکرین ڈیزائن چھوڑ دیں جب تک وہ پہلے سے آپ کے پاس نہ ہوں۔ کسی اہم اسکرین کا خاکہ مدد کرتا ہے؛ ہر اسکرین کا بالکل درست نمونہ ڈیزائن کسی کی جانچ سے پہلے فیصلے پکے کر دیتا ہے۔
• وہ فیچرز چھوڑ دیں جن کے بارے میں یقین نہیں، یا انہیں “بعد میں” کے طور پر الگ لکھیں۔ “شاید” سے بھری کوٹیشن کا موازنہ مشکل ہے۔
• وہ خفیہ تفصیلات چھوڑ دیں جو ابھی بتانے کی ضرورت نہیں۔ اسٹوڈیو مسئلے کی شکل سے کوٹیشن دے سکتا ہے؛ اسے گاہکوں کے نام یا مالی نتائج نہیں چاہئیں۔

ہدایات، تخمینے میں بدلی گئیں

اوپر کے جدول والا بکنگ پورٹل، ویب ایپ، ⁨iOS⁩ اور ⁨Android⁩ ایپس، کارڈ سے ادائیگیوں، کلائنٹ کے اکاؤنٹنگ سسٹم سے کنکشن، انگریزی اور فرانسیسی، اور ذاتی معلومات کے ساتھ، ہمارے تخمینہ ٹول میں ایسا دکھتا ہے۔ نیچے کی حل شدہ مثال آج کے ہمارے نرخ نامے سے حد دکھاتی ہے، کردار کے لحاظ سے گھنٹوں اور ادائیگی کے شیڈول کے ساتھ۔

اسے تخمینہ ٹول میں کھولیں اور ایک وقت میں ایک جواب بدلیں: موبائل ایپس ہٹا دیں، فوری اپ ڈیٹس شامل کریں، صاف معیاری ڈیزائن پر جائیں۔ حد کو بدلتا دیکھنا یہ جاننے کا سب سے تیز طریقہ ہے کہ آپ کی اپنی ہدایات کے کون سے حصے سب سے اہم ہیں۔

ایک ہی ہدایات کئی اسٹوڈیوز کو بھیجنا

ایک سے زیادہ کوٹیشن لینا سمجھداری ہے، اور تحریری ہدایات ہی انہیں قابلِ موازنہ بناتی ہیں۔ ہر اسٹوڈیو کو ایک ہی دستاویز بھیجیں، ہر اسٹوڈیو کے سوالات کا تحریری جواب دیں، اور ہر جواب سب کو بھیجیں۔ ورنہ بہترین سوال پوچھنے والے اسٹوڈیو کو سب سے درست تصویر ملتی ہے، اور اس کی کوٹیشن دیانت داری کی وجہ سے بدتر لگتی ہے۔

• ہر اسٹوڈیو سے اس کے عدد کے پیچھے کے مفروضے لکھنے کو کہیں، اور مجموعوں سے پہلے ان کا موازنہ کریں۔
• کردار کے لحاظ سے گھنٹے مانگیں، تاکہ دیکھ سکیں کہ جانچ، ڈیزائن اور پروجیکٹ مینجمنٹ شامل ہیں یا نہیں۔
• پوچھیں کیا شامل نہیں: ہوسٹنگ، سپورٹ، تیسرے فریق کی فیسیں، مواد اور ڈیٹا کی منتقلی۔
• دوسروں سے بہت کم کوٹیشن سے محتاط رہیں۔ اس کا عموماً مطلب ہے کہ ہدایات کا کچھ حصہ مختلف پڑھا گیا، یا چھوڑ دیا گیا۔

ایک صفحے کا ٹیمپلیٹ

• منصوبے کا نام اور ایک جملہ کہ یہ کیا ہے۔
• آج کا مسئلہ، ایک پیراگراف میں۔
• صارفین: ہر قسم، اُن تین سے پانچ کاموں کے ساتھ جو انہیں کرنے ہیں۔
• اسکرینز: صارف کے لحاظ سے گروپ کی گئی کچی فہرست۔
• انضمامات: ہر سسٹم، ڈیٹا کی سمت، اور کیا رسائی موجود ہے۔
• ڈیٹا: کیا محفوظ ہوتا ہے، کیا یہ ذاتی یا ضابطہ شدہ ہے، اور کوئی منتقلی۔
• پلیٹ فارمز: ویب، ⁨iOS⁩، ⁨Android⁩، آف لائن۔
• پابندیاں: ڈیڈ لائنز، ہوسٹنگ، رسائی، زبانیں، تعمیل۔
• کیا موجود ہے: ڈیزائنز، برانڈ، پرانے سسٹمز، دستاویزات۔
• لانچ کے بعد: اسے کون چلاتا ہے اور کون سپورٹ کرتا ہے۔
• بجٹ کی حد، اور کمی کرنی پڑے تو سب سے اہم کیا ہے۔

بھیجنے کے بعد کیا ہوتا ہے

1. 01

   سوالات

   ہم ہدایات پڑھتے ہیں اور ان سے اٹھنے والے سوالات کے ساتھ واپس آتے ہیں، عموماً انضمامات، ڈیٹا اور صارفین کے کرداروں کے بارے میں۔

2. 02

   مفروضوں کے ساتھ تخمینہ

   آپ کو ایک حد، کردار کے لحاظ سے گھنٹے، اور اُن مفروضوں کی فہرست ملتی ہے جن پر یہ قائم ہے، تاکہ آپ ٹھیک دیکھ سکیں کہ کس چیز کی قیمت لگی۔

3. 03

   ابتدائی جائزہ

   اگر آپ آگے بڑھیں، تو پہلا مرحلہ اسکرینز، انضمامات اور ڈیٹا کی تفصیل سے تصدیق کرتا ہے، اور حد تعمیر کی ایک مقررہ قیمت تک تنگ ہو جاتی ہے۔

4. 04

   تبدیلیاں، کام سے پہلے قیمت کے ساتھ

   اس کے بعد جو بھی بدلے وہ تبدیلی کے آرڈر کے طور پر لکھا جاتا ہے اور اس پر کام شروع ہونے سے پہلے منظور ہوتا ہے۔