SaaS
آپ ہر دو ہفتے ریلیز کرتے ہیں اور سال میں دو بار اس کے بارے میں لکھتے ہیں
سافٹ ویئر ٹیموں کے پاس کہنے کو چیزیں کم نہیں ہوتیں۔ وہ اس شخص کی کمی رکھتی ہیں جو انہیں کہے، کیونکہ لکھنا ہمیشہ وہ کام ہوتا ہے جو ریلیز لیٹ ہونے پر ٹال دیا جاتا ہے — اور ہر بار ٹل جاتا ہے، یہاں تک کہ بلاگ کی تازہ ترین پوسٹ گیارہ مہینے پرانی ہو اور "تعارف" کہہ رہی ہو۔
ناکامی ساختی ہے، تحریری نہیں
ہر ٹیم جانتی ہے کہ اسے زیادہ لکھنا چاہیے۔ انجینئر لکھ سکتے ہیں؛ بانی لکھ سکتا ہے؛ عام طور پر کوئی ایسا ہوتا ہے جسے یہ پسند ہے۔ مسئلہ یہ ہے کہ لکھنے کی اپنی کوئی ڈیڈ لائن نہیں ہوتی، اور جس چیز کی ڈیڈ لائن نہیں وہ ہر دو ہفتے، ہمیشہ کے لیے، کسی بھی ڈیڈ لائن والی چیز سے ہار جاتی ہے۔
منصوبہ یہ گمشدہ ڈیڈ لائن فراہم کرتا ہے۔ ایک تاریخ والا سلاٹ جس کے ساتھ ایک موضوع اور ایک لکھنے والا منسلک ہو، ایک پرسکون ہفتے میں کی گئی وعدہ ہے، جو ایسے ہفتے میں لاگو ہوتا ہے جو پرسکون نہیں، اور مسودہ اس بات سے قطع نظر کہ کسی کو یاد ہے یا نہیں، ظاہر ہو جاتا ہے۔ اس کی منظوری منٹوں میں ہوتی ہے؛ اسے بالکل صفر سے لکھنے میں وہ دوپہر لگتی ہے جو کبھی نہیں آتی۔
یہی پوری دلیل ہے۔ یہ نہیں کہ کوئی ماڈل آپ کی ٹیم سے بہتر لکھتا ہے — نہیں لکھتا۔ بات یہ ہے کہ منگل کو آپ جو مسودہ ایڈٹ کریں وہ موجود ہوتا ہے، اور وہ پوسٹ جو آپ لکھنا چاہتے تھے، موجود نہیں ہوتی۔
روڈ میپ ایک منصوبہ ہے جو آپ پہلے ہی لکھ چکے ہیں
چھ ماہ میں سے زیادہ تر پہلے ہی طے شدہ ہے۔ آپ تقریباً جانتے ہیں کہ اگلے دو سہ ماہیوں میں کیا ریلیز ہوگا، پروڈکٹ کے کون سے حصے غلط سمجھے جاتے ہیں، کن انٹیگریشنز کے لیے آپ کو بار بار کہا جاتا ہے، اور کن سوالات کا جواب سپورٹ میں ہر ہفتے آتا ہے۔
ان میں سے ہر ایک ایک موضوع ہے۔ روڈ میپ تال فراہم کرتا ہے — ایک ریلیز ایک چینج لاگ اندراج کے بجائے کئی سلاٹوں کی قطار بن جاتی ہے — اور سپورٹ ہمیشہ کا حصہ فراہم کرتی ہے، کیونکہ مہینے میں بیس بار پوچھا جانے والا سوال ایک ایسا مضمون ہے جو ایک بار لکھ کر ہمیشہ کے لیے لنک کیا جا سکتا ہے۔
خالی جگہیں چھوڑیں۔ ریلیزیں تاخیر سے آتی ہیں، اور بغیر خالی سلاٹ کے منصوبہ تاخیر سے آئی ریلیز کو ایک ایسی چیز کے تین مضامین بنا دیتا ہے جو ابھی موجود ہی نہیں۔ سلاٹوں کا ایک چوتھائی حصہ کھلا رکھنا سستی نہیں؛ یہی منصوبے کا وہ حصہ ہے جو آپ کے اصل شیڈول سے ٹکرانے کے بعد بھی باقی رہتا ہے۔
- 1بلاگکیا شامل ہوا اور یہ کیوں موجود ہے۔ پہلے مسئلہ، پھر فیچر۔
- 2فیس بک / انسٹاگرامایک جملے کا خلاصہ، ان لوگوں کے لیے جو کبھی چینج لاگ نہیں کھولیں گے۔
- 3بلاگکسی نے اصل میں اسے کیسے استعمال کیا۔ ٹھوس، اور مشکل حصے چھوڑ کر نہیں۔
- ·اگر تاخیر ہو جائےسلاٹ ریلیز کے ساتھ آگے بڑھ جاتے ہیں۔ کوئی ایسی چیز کا اعلان نہیں کرتا جو موجود ہی نہ ہو۔
- 4بلاگوہ سپورٹ سوال جس کا جواب یہ ریلیز آخرکار دیتی ہے، ایک بار لکھا گیا۔
تال روڈ میپ مقرر کرتا ہےموضوعات سپورٹ مقرر کرتی ہے
آپ کی چینج لاگ مواد نہیں ہے۔ یہ ایک رسید ہے۔
دو لکھنے والے، بعض اوقات تین
ایک جو پروڈکٹ کی وضاحت کرتا ہے، اور ایک جو کمپنی کے بارے میں بات کرتا ہے
یہ واقعی دو مختلف آوازیں ہیں، اور انہیں ملانا وہ خاص بے جان پن پیدا کرتا ہے جس کے لیے سافٹ ویئر بلاگز مشہور ہیں — ایسا مضمون جو نہ کسی تکنیکی وضاحت جیسا ہو نہ کسی چیز کا انسانی بیانیہ۔
تکنیکی لکھاری
بتاتا ہے کہ کوئی چیز کیا کرتی ہے، درستگی سے، بغیر صفتوں کے۔ جانتا ہے کہ آپ کی پروڈکٹ کس کے لیے ہے اور کس کے لیے نہیں، اور اسے ایسا کہنے کی اجازت ہے۔ یہ وہ لکھاری ہے جس کے مضامین سپورٹ ٹکٹوں سے لنک کیے جاتے ہیں۔
کمپنی کی آواز
فیصلوں، سمجھوتوں اور آپ جس چیز کی طرف بڑھ رہے ہیں اس کے بارے میں لکھتا ہے۔ یہ ایک ایسے طریقے سے کارآمد ہے جو ناپنا مشکل ہے مگر ملازمت کی بھرتی، سیلز کی کالوں اور کسی کے بڑے فراہم کنندہ کے بجائے چھوٹے فراہم کنندہ کے انتخاب کی وجہ میں واضح ہوتا ہے۔
وہ جو جواب دیتا ہے
آپ کی پالیسی کے تحت تبصروں کو سنبھالتا ہے۔ جو ممکن ہو اس کا جواب دیتا ہے، جو ممکن نہ ہو اسے نشان زد کرتا ہے، اور روڈ میپ کے بارے میں کبھی قیاس آرائی نہیں کرتا۔ سپورٹ کے واقعے سے ملتا جلتا کچھ بھی فوراً کسی انسان کے پاس بھیج دیا جاتا ہے۔
منظوری کی پڑتال یہاں واقعی اہم کام کرتی ہے
بیکری کے لیے بغیر منظوری کا مضمون ایک چھوٹی شرمندگی ہے۔ سافٹ ویئر کمپنی کے لیے یہ سپورٹ کا بوجھ، سیلز کی اعتراض، یا ایک وعدہ ہے جس پر کسی نے اتفاق نہیں کیا۔ ایک مسودہ جو کسی حد کو تھوڑا غلط بیان کرے گاہک آپ کے سامنے دہرائے گا، اور جو مسودہ کسی تاریخ کی طرف اشارہ کرے اسے وعدہ سمجھا جائے گا۔
اس لیے یہ وہ صورت ہے جہاں آٹو پائلٹ کو سب سے زیادہ احتیاط کی ضرورت ہے۔ ایک معقول ترتیب یہ ہے کہ آٹو پائلٹ صرف ان مختصر سوشل سلاٹوں پر چلے جو پہلے سے شائع شدہ چیز کو دہراتے ہیں، اور پروڈکٹ کے بارے میں کوئی دعویٰ کرنے والی ہر چیز پر منظوری لازمی ہو۔ قیمت، گنجائش یا تاریخوں سے متعلق ہر چیز کو ہمیشہ کسی انسان کے پڑھنے چاہیے، اور یہ بات لکھاری کے قواعد میں لکھ دینا بہتر ہے تاکہ ایسے مسودے قطار میں لگنے کے بجائے روک کر نشان زد کیے جائیں۔
رپورٹ ایک چھوٹی ٹیم کو کیا بتاتی ہے
منصوبہ بندی بمقابلہ اشاعت وہ عدد ہے جو اہم ہے، اور سافٹ ویئر ٹیم کے لیے پہلی سہ ماہی میں یہ عموماً تکلیف دہ ہوتا ہے۔ یہی اس کا واحد ایماندار پیمانہ بھی ہے کہ کہیں لکھائی پھر سے ریلیز کے آگے ہار تو نہیں گئی۔
استقبال اتنا اہم نہیں جتنا لگتا ہے۔ تکنیکی مضمون اپنی پزیرائی دنوں میں نہیں مہینوں میں پاتا ہے، اور دوسرے ہفتے اس کا فیصلہ کرنا ان مضامین کو ختم کر دے گا جو کام آتے۔ شروع میں موضوعات کا توازن زیادہ کارآمد ہے: یہ دکھاتا ہے کہ آپ صرف شائع شدہ چیزوں کے بارے میں لکھ رہے ہیں یا نہیں، جو عام ناکامی کا انداز ہے اور اسی وجہ سے اتنے سافٹ ویئر بلاگز پیراگرافوں والی چینج لاگ جیسے لگتے ہیں۔
ایماندارانہ بات: اگر آپ کی پروڈکٹ واقعی تکنیکی ہے تو سب سے گہرے مضامین کو اب بھی ایک انجینئر کے ایک دوپہر کی ضرورت ہوتی ہے۔ منصوبہ جو بدلتا ہے وہ یہ ہے کہ وہ دوپہریں شیڈول ہو جاتی ہیں اور لکھائی کا باقی اسی فیصد حصہ ان سے مقابلے کرنا چھوڑ دیتا ہے۔