SaaS
আপনি প্রতি দুই সপ্তাহে রিলিজ দেন, কিন্তু বছরে মাত্র দুবার লেখেন
সফটওয়্যার টিমের কাছে বলার মতো জিনিসের অভাব নেই। অভাব সেই ব্যক্তির, যিনি বলবেন, কারণ রিলিজ দেরি হলে লেখাই সবার শেষে পিছিয়ে যাওয়া কাজ — আর প্রতিবারই সেটা পিছিয়ে যায়, যতক্ষণ না ব্লগের সর্বশেষ পোস্টটি এগারো মাসের পুরোনো হয়ে "introducing" দিয়ে শুরু হয়।
ব্যর্থতাটি কাঠামোগত, সম্পাদনাগত নয়
প্রতিটি টিম জানে তাদের বেশি লেখা উচিত। ইঞ্জিনিয়াররা লিখতে পারেন; প্রতিষ্ঠাতা লিখতে পারেন; সাধারণত কেউ একজন এটা উপভোগও করেন। সমস্যা হলো, লেখার নিজস্ব কোনো ডেডলাইন নেই, আর ডেডলাইনহীন যেকোনো কাজ ডেডলাইনযুক্ত যেকোনো কাজের কাছে হেরে যায় — প্রতি দুই সপ্তাহে, চিরকাল।
একটি পরিকল্পনা সেই অনুপস্থিত ডেডলাইন জোগায়। তারিখযুক্ত একটি স্লট, যার সঙ্গে বিষয় ও লেখক যুক্ত, আসলে শান্ত এক সপ্তাহে করা একটি প্রতিশ্রুতি, যা অশান্ত সপ্তাহে কার্যকর হয় — আর কেউ মনে রেখেছেন কি নেই, খসড়াটা তবু তৈরি হয়ে যায়। এটি অনুমোদন করতে মিনিট লাগে; শূন্য থেকে লিখতে লাগে এমন এক বিকেল, যা কখনও আসে না।
এটাই পুরো যুক্তি। এটা নয় যে কোনো মডেল আপনার টিমের চেয়ে ভালো লেখে — লেখে না। বরং মঙ্গলবার আপনি সম্পাদনা করা একটি খসড়ার অস্তিত্ব আছে, আর যে পোস্ট লেখার ইচ্ছা ছিল তার নেই।
রোডম্যাপ আসলে আপনার আগেই লেখা একটি পরিকল্পনা
ছয় মাসের বেশিরভাগই আগেই ঠিক হয়ে আছে। আপনি মোটামুটি জানেন পরের দুই কোয়ার্টারে কী রিলিজ হবে, প্রোডাক্টের কোন অংশগুলো ভুল বোঝা হয়, কোন ইন্টিগ্রেশনের জন্য বারবার অনুরোধ আসে, এবং কোন প্রশ্নগুলো প্রতি সপ্তাহে সাপোর্টে পৌঁছায়।
এগুলোর প্রতিটিই একটি বিষয়। রোডম্যাপ ছন্দটা দেয় — একটি রিলিজ একটি চেঞ্জলগ এন্ট্রি নয়, বরং স্লটের একটি ধারায় পরিণত হয় — আর সাপোর্ট দেয় চিরসবুজ অর্ধেকটা, কারণ মাসে বিশবার জিজ্ঞাসিত একটি প্রশ্ন এমন একটি লেখা যা একবার লিখে চিরকাল লিংক করে রাখা যায়।
ফাঁকা রাখুন। রিলিজ পিছিয়ে যায়, আর কোনো ফাঁকা স্লটহীন পরিকল্পনা পিছিয়ে যাওয়া একটি রিলিজকে এমন তিনটি পোস্টে পরিণত করে যা এখনও বলবতে নেই। চতুর্থাংশ স্লট ফাঁকা রাখা ঢিলেমি নয়; এটাই পরিকল্পনার সেই অংশ যা আপনার বাস্তব সময়সূচির সংস্পর্শে টিকে যায়।
- 1ব্লগকী রিলিজ হয়েছে এবং কেন এটির অস্তিত্ব। প্রথমে সমস্যা, পরে ফিচার।
- 2ফেসবুক / ইনস্টাগ্রামএক বাক্যের সংস্করণ, যাঁরা কখনোই চেঞ্জলগ খুলবেন না তাঁদের জন্য।
- 3ব্লগকেউ বাস্তবে কীভাবে এটি ব্যবহার করেছেন। সুনির্দিষ্ট, আর অস্বস্তিকর অংশগুলো রেখে দেওয়া।
- ·যদি পিছিয়ে যায়স্লটগুলো রিলিজের সঙ্গে এগিয়ে যায়। যা নেই, তার কোনো ঘোষণা হয় না।
- 4ব্লগএই রিলিজ যে সাপোর্ট প্রশ্নের অবশেষে উত্তর দেয়, তা একবারে লেখা।
রোডম্যাপ নির্ধারণ করে ছন্দসাপোর্ট নির্ধারণ করে বিষয়
আপনার চেঞ্জলগ কনটেন্ট নয়। এটি একটি রসিদ।
দুজন লেখক, মাঝে মাঝে তিনজন
একজন পণ্যটি ব্যাখ্যা করেন, আর একজন কোম্পানি সম্পর্কে কথা বলেন
এরা সত্যিই আলাদা কণ্ঠস্বর, আর এদের এক করে ফেললে সেই বিশেষ নিরীহ ভাবটাই তৈরি হয়, যার জন্য সফটওয়্যার ব্লগগুলো পরিচিত — এমন পোস্ট যা না কোনো কারিগরি ব্যাখ্যা, না কোনো মানবিক বিবরণ।
কারিগরি লেখক
কোনো জিনিস ঠিক কী করে, সেটি বিশেষণ ছাড়া, নির্ভুলভাবে ব্যাখ্যা করেন। আপনার পণ্য কীসের জন্য আর কীসের জন্য নয়, তা জানেন, এবং তা বলার অনুমতি তাঁর আছে। এই লেখকের পোস্টগুলোই সাপোর্ট টিকিট থেকে লিংক করা হয়।
কোম্পানির কণ্ঠস্বর
সিদ্ধান্ত, আপস আর আপনি কোন দিকে যাচ্ছেন তা নিয়ে লেখেন। এটি এমনভাবে কাজে লাগে যা মাপা কঠিন, কিন্তু নিয়োগে, সেলস কলে এবং কেউ বড় বিক্রেতার বদলে ছোট বিক্রেতা বেছে নেওয়ার কারণে স্পষ্ট।
যিনি উত্তর দেন
আপনার নীতির নিচের মন্তব্য সামলায়। যা পারে উত্তর দেয়, যা পারে না তা চিহ্নিত করে, এবং রোডম্যাপ নিয়ে কখনো অনুমান করে না। সাপোর্ট ঘটনার মতো কিছু দেখা দিলে সঙ্গে সঙ্গে একজন মানুষের কাছে পাঠায়।
অনুমোদনের গেট এখানে সত্যিকারের কাজ করে
একটি বেকারির জন্য অনুমোদনহীন পোস্ট মাত্র একটি ছোট লজ্জা। একটি সফটওয়্যার কোম্পানির জন্য তা সাপোর্টের বোঝা, সেলসের আপত্তি, বা এমন প্রতিশ্রুতি যাতে কেউ রাজি হননি। একটি খসড়া যদি কোনো সীমা সামান্য ভুলভাবে বর্ণনা করে, গ্রাহক তা আপনার মুখোমুখি উদ্ধৃত করবেন, আর কোনো খসড়া তারিখের ইঙ্গিত দিলে তা প্রতিশ্রুতি ধরা হবে।
তাই অটোপাইলট এখানেই সবচেয়ে বেশি সতর্কতা প্রাপ্য। একটি যুক্তিসঙ্গত ব্যবস্থা হলো: ইতিমধ্যে প্রকাশিত কিছু পুনরুক্তি করে এমন ছোট সোশ্যাল স্লটে অটোপাইলট, আর পণ্য সম্পর্কে দাবি করে এমন সবকিছুতে অনুমোদন। মূল্য, ক্ষমতা বা তারিখ সম্পর্কিত যেকোনো কিছু স্থায়ীভাবে একজন মানুষের পড়া উচিত, এবং লেখকের নিয়মে সেটি লিখে রাখা মূল্যবান, যাতে এই ধরনের খসড়া সারিবদ্ধ না হয়ে আটকে রাখা ও চিহ্নিত হয়।
রিপোর্ট একটি ছোট দলকে কী বলে
পরিকল্পিত বনাম প্রকাশিত — এটিই সেই সংখ্যা যা গুরুত্বপূর্ণ, আর সফটওয়্যার দলের জন্য প্রথম ত্রৈমাসিকে এটি সাধারণত অস্বস্তিকর। লেখা আবার রিলিজের কাছে হেরে গেছে কি না, তার একমাত্র সৎ পরিমাপও এটি।
সংবর্ধনা দেখতে যতটা মনে হয় ততটা গুরুত্বপূর্ণ নয়। একটি কারিগরি লেখা দিনে নয়, মাসের হিসেবে তার পাঠক খুঁজে নেয়, আর দ্বিতীয় সপ্তাহে বিচার করলে আপনি সেই লেখাগুলোই বাদ দেবেন যেগুলো কাজে আসত। শুরুতে বিষয়ের ভারসাম্য বেশি কাজের: এটি দেখায় আপনি কি শুধু যা শিপ হয়েছে তা নিয়েই লিখছেন — এটিই স্বাভাবিক ব্যর্থতার ধরন, আর এ কারণেই এত সফটওয়্যার ব্লগ অনুচ্ছেদযুক্ত চেঞ্জলগের মতো পড়ায়।
সৎ অংশটি: আপনার পণ্য সত্যিই কারিগরি হলে, সবচেয়ে গভীর লেখাগুলোর জন্য একজন প্রকৌশলীর এক বিকেল এখনো দরকার। পরিকল্পনা যা বদলায় তা হলো, সেই বিকেলগুলো সময়সূচিতে ঢোকে, আর লেখার বাকি আশি শতাংশ আর তাদের সঙ্গে প্রতিযোগিতা করে না।