पहली सॉफ्टवेयर बातचीत के लिए सुरक्षित तैयारी करें

समस्या आज जैसे होती है वैसे बताएँ

हाल का सामान्य उदाहरण पूरी तरह तैयार स्पेसिफिकेशन से अधिक उपयोगी हो सकता है। काम कौन शुरू करता, किन साधनों से गुजरता, कहाँ रुकता और अच्छा नतीजा कैसा होता है, समझाएँ। वह निर्णय लाएँ जिसे स्पष्ट करना चाहते हैं: बनाना, जाँच करना या मौजूदा उत्पाद संभालना।

बैठक से पहले सुरक्षित उदाहरण बनाएँ

काल्पनिक ग्राहक सेवा प्रवाह में नाम, ईमेल और ऑर्डर संदर्भ काल्पनिक मानों से बदलें। समस्या समझाने वाली संरचना, त्रुटियाँ और हाथ से किए कदम बचाएँ। स्क्रीनशॉट में टैब, सूचनाएँ और खाते देखें। ढकी हुई स्प्रेडशीट में छिपे शीट या टिप्पणियाँ बच सकती हैं; विशेष रूप से बनाया छोटा उदाहरण जाँचना आसान हो सकता है।

सीमाएँ साझा करें, प्रवेश जानकारी नहीं

उपयोगकर्ता समूह, अनुमानित मात्रा, जरूरी इंटीग्रेशन, समय सीमा और दायरा मंजूर करने वाला व्यक्ति उपयोगी संदर्भ हैं। अनुमानों को अनुमान बताएँ। फॉर्म से पासवर्ड, API कुंजी, कार्ड विवरण, पूरा प्रोडक्शन डेटाबेस या गोपनीय ग्राहक दस्तावेज न भेजें। बाद में तकनीकी जाँच को पहुँच चाहिए तो अलग अधिकृत, सीमित और वापस ली जा सकने वाली प्रक्रिया बनाएँ।

छोटे सार में देखे गए तथ्यों और धारणाओं को अलग रखें

उपयोगी तैयारी एक पन्ने में आ सकती है: आवश्यक निर्णय, शामिल लोग, काम का मौजूदा क्रम और उसे बिना बदले छोड़ने का परिणाम। एक सामान्य उदाहरण और एक अपवाद जोड़ें। अगर किसी को अभी यह नहीं पता कि मंज़ूरी में देर क्यों होती है, तो उस देरी का स्पष्ट वर्णन सुविधाओं की लंबी सूची से अधिक उपयोगी है।

मान लें कि एक काल्पनिक बिक्री टीम स्प्रेडशीट से कोटेशन भेजती है और प्रबंधक ईमेल से छूट मंज़ूर करते हैं। सामान्य उदाहरण में एक कोटेशन को स्वीकृति तक देखें। अपवाद में दिखाएँ कि प्रबंधक के नवीनतम संस्करण देखने से पहले संशोधित कीमत ग्राहक को भेज दी गई। पहचानें कि कौन-सा संस्करण मंज़ूर हुआ, विक्रेता ने कहाँ देखा और ग्राहक को क्या मिला। नया CRM ही उत्तर है, ऐसा न मानें। समस्या संशोधन का नियम न होने या ज़िम्मेदारी अस्पष्ट होने की भी हो सकती है।

हर कथन को देखा गया तथ्य, अनुमान या अभी जाँचने योग्य बात कहें। कोई बताए कि संशोधन अक्सर होते हैं तो लिखें कि यह किसने बताया और कौन-सा नमूना स्थिति स्पष्ट कर सकता है। इसे मनगढ़ंत मासिक संख्या में न बदलें। आवश्यक रिकॉर्ड संबंध और संचार माध्यम काल्पनिक पहचान के साथ समझाएँ। दो संस्करण एक ही कोटेशन के हैं, यह समझाने के लिए असली ग्राहक की पहचान या व्यावसायिक शर्तें साझा करना आवश्यक नहीं है।

अगला कदम किसी खास अनिश्चितता को दूर करे

बातचीत में सबसे छोटे उपयोगी विकल्पों की तुलना करें। मौजूदा उपकरण स्वीकृत संस्करण सुरक्षित रख सकता हो तो उसकी सेटिंग बदलना पर्याप्त हो सकता है। प्रोटोटाइप स्पष्ट कर सकता है कि प्रबंधक बदलाव कैसे जाँचेंगे। वर्तमान सिस्टम आवश्यक रिकॉर्ड उपलब्ध कराता है या नहीं, यह जानने के लिए तकनीकी जाँच लग सकती है। इन अनिश्चितताओं को समझने के बाद पूरा ऐप बनाना अधिक ठोस आधार वाला विकल्प बनता है। लिखें कि कोई विकल्प क्यों चुना गया और कौन-सा प्रमाण यह चुनाव बदल सकता है।

हर अनुत्तरित प्रश्न का ज़िम्मेदार तय करें। बिक्री प्रमुख बता सकता है कि किन मूल्य परिवर्तनों के लिए नई मंज़ूरी चाहिए। अधिकृत सिस्टम प्रशासक उपलब्ध निर्यात या एकीकरण पहुँच जाँच सकता है। हर जाँच का परिणाम, सीमा और सहमत समीक्षा बिंदु तय करें। सीमित खोज कार्य ऐसा कुछ छोड़े जिसका व्यवसाय विकास आगे न बढ़ने पर भी उपयोग कर सके, जैसे सहमत कार्यप्रवाह, जाँची गई बाधा या तुलना किए गए काम के दायरे।

इच्छित परिणाम, विचार किए गए विकल्प, खुले प्रश्न और अगले निर्णय का लिखित सार भेजें या उस पर सहमति लें। सुझाई गई लागत या समय को सीमा और धारणाओं सहित प्रस्ताव के रूप में दर्ज करें। यह अभी न देखे गए एकीकरण का पुष्ट अनुमान नहीं है। योजना निर्भर होने से पहले गलत समझे गए शब्दों को स्पष्ट करें। बातचीत का पूरा प्रतिलेख सहमत निर्णय रिकॉर्ड की जगह नहीं लेता। उपयोगी परिणाम यह जानना है कि अगला तथ्य कौन स्थापित करेगा और वह परियोजना को कैसे प्रभावित करेगा।

अगला ठोस निर्णय लेकर निकलें

Orvun Labs को चाहा परिणाम और मुख्य बाधा बताएँ। बातचीत साझा समस्या विवरण और अगले जरूरी प्रमाण तक पहुँचे, अनिर्धारित विकास मंजूर कराने के दबाव तक नहीं।

• कौन-सा सामान्य उदाहरण समस्या सबसे अच्छी तरह समझाता है?
• क्या सुधारना जरूरी है और क्या वैसा रह सकता है?
• कार्यप्रवाह के सवालों का जवाब और निर्णय कौन देगा?
• क्या साझा फाइलों से रहस्य और निजी डेटा हटने की जाँच हुई है?