يمكنك كتابة مواصفات تقنية لا تشوبها شائبة ، ولكن ما فائدة ذلك إذا كان المطور الخاص بك يبكي؟

مالك منتج كروي يعمل في مجرة ​​بعيدة جدًا. يكتب ملاحظات بطلاقة على منديل ويعطيها بصمت للمطورين. وسرعان ما يتلقى منتجًا نهائيًا يلبي توقعاته بنسبة 100 ٪. حتى لو كان هذا المنتج عبارة عن خدمة معقدة عبر الأنظمة الأساسية مع لعبة ورق والقدرة على التكيف.



هل هذا ممكن عمليا؟



"لا يا أخي ، لا يمكنك أن تخدعنا! يجب كتابة الشروط المرجعية طويلة ودقيقة ، "يقول كبار السن ذوي الشعر الرمادي. "المعارف التقليدية جادة!" - صدى جون ذو الفم الأصفر. يعترف محلل أعمال متمرس: "تركتني زوجتي بسبب مهمة فنية قصيرة".



اسمحوا لي أن أختلف.



لا يجب أن تستغرق كتابة المعارف التقليدية وقتًا طويلاً. علاوة على ذلك ، من الأسهل كتابة الاختصاصات الجيدة من الاختصاصات السيئة. إذا كنت تعرف بعض الحيل ، بالطبع. سأخبرك عن هذا اليوم. ومع ذلك ، بدلاً من المناديل ، ما زلت أوصي باستخدام التقاء .

ماذا دهاك؟

لقد كنت أكتب المهام للمطورين لأكثر من 11 عامًا. تم تصنيع التطبيقات والألعاب وخدمات الويب وأنظمة إدارة علاقات العملاء ومنصات التدريب وغيرها من المنتجات بناءً عليها. خلال هذا الوقت ، انتقلت من كتابة مستندات تصميم من 200 صفحة إلى اختصاصات مقتضبة في عدة خطوات. وبطبيعة الحال ، ملأ كل النتوءات الممكنة.



سنة بعد أخرى ، في شركات مختلفة ، لاحظت كيف أن المنتج ومصممي الألعاب والمسوقين يحددون المهام. وما هي عواقب "السمات" المختلفة لتصميم هذه المهام. كيف يتم تغيير بداية السباق لمدة أسبوع ، لمعرفة ما يريده العميل بالضبط. كما هو الحال في حالة من الذعر ، يقومون بإصلاح الوظيفة التي تم سكبها للتو في المنتج. مدى سرعة إسقاط نتيجة التطبيق بسبب الحالات غير المحسوبة. كيف تنخفض المبيعات ويغادر المستخدمون المخلصون. كيف ينفد المطورون عندما يضطرون إلى العبث بالمهام الصعبة.



كان لدي انطباع بأن الكثير من أولئك الذين حددوا مهام التطوير لا يعرفون كيفية القيام بذلك بشكل جيد . ومسألة جودة المعارف التقليدية نفسها خارج نطاق الاهتمام: يقولون ، لقد كتبوا مهمة وقواعد ، لن يكتشفوها ، أم ماذا؟ علاوة على ذلك ، هناك دائمًا أشياء أكثر إثارة للاهتمام يجب القيام بها: مناقشة الفرضيات الجديدة ، والاجتماعات ، واستراحات القهوة. نتيجة لذلك ، يعاني الجميع - العملاء والمطورين والشركات.

هناك نقيضان عند كتابة المعارف التقليدية

كلما زاد حجم المنتج الذي تعمل عليه ، زادت تكلفة الخطأ وزادت أهمية جودة المواصفات الفنية (شكرًا ، غطاء!). لذلك ، كلا الخيارين غير مناسبين إذا كنت تفعل شيئًا أكثر جدية من صفحة مقصودة. في المنتجات الكبيرة والتنافسية ، يجب أن تكون كتابة TOR سريعة وذكية وموسيقى الروك أند رول . دعونا نرى كيف نصل إلى هناك.

,

1. 
   
   – , , . , ( ).
2. 
   
   – , . , – , . .. , , . , – , .
3. PM-
   
   – , , . «», , .
4. QA
   
   – , . user journey . , , , .
5. ينبغي أن ترضي المعارف التقليدية قائد الفريق ،
   
   وهذا يعني أنها لا تتطلب أي طقوس وتفسيرات خاصة لنقلها إلى التنمية. على سبيل المثال ، إذا أنهى منتج ما المهمة الفنية وصدمته حافلة هناك ، في المكتب مباشرةً ، فلا ينبغي أن يمنعه ذلك من القيام بالمهمة الفنية بأفضل طريقة ممكنة.

هل من الصعب تلبية كل هذه المتطلبات؟ على الاطلاق.



على العكس من ذلك ، إذا كنت تتذكرها ، فلن تتمكن من كتابة المعارف التقليدية السيئة بصراحة. لأن كل هذه المتطلبات تتلخص في شيء واحد فقط - رعاية الأشخاص الذين يتفاعلون مع هذه المعارف التقليدية.

تنسيق TK الخاص بي

هذا التنسيق عبارة عن مزيج فضفاض إلى حد ما من قصة المستخدم + تعريف تم .



لقد ظهر كنتيجة لسنوات عديدة من التطور: في كل مرة رأيت فيها مشكلة منهجية ، قمت بتغيير شكل المعارف التقليدية الخاصة بي بحيث لا تظهر هذه المشكلة في المستقبل. والنتيجة هي تنسيق مقتضب ونظيف بصريًا يمكن حتى للجنون التقاطه بسهولة. بالإضافة إلى أنه يفي بالمتطلبات الموضحة أعلاه.



هذا ما تبدو عليه القصة النموذجية في معرفتي التقليدية:







وبغض النظر عن حجم المنتج الذي نطوره وتعقيده ، فإن أي معارف تقليدية ستتألف من مثل هذه القصص البسيطة (سيزداد عددها فقط).





هام: يجب ألا تصف القصص وظائف كبيرة جدًا (على سبيل المثال ، عدة شاشات) أو صغيرة جدًا (على سبيل المثال ، زر واحد). عادةً ما تكون القصة الواحدة ميزة واحدة أو ميكانيكي منتج. على سبيل المثال ، يمكن للقصة أن تصف بشكل كامل تسجيل مستخدم جديد. لتعيين مهمة لتخطيط صفحة مقصودة جديدة ، كقاعدة عامة ، فإن قصة واحدة تكفي أيضًا.



إذا كانت المواصفات الفنية كبيرة وهامة ، فقبل قائمة القصص أكتب بإيجاز: لماذا نقوم بذلك وما هي النتائج التي نريد تحقيقها . فقط حتى المطورين لديهم صورة كبيرة.

بشكل عام ، اتضح أن شيئًا مثل هذا:

مثال

حسنًا ، لفهم كيفية عملها - دعنا نقسم بعض المنتجات إلى مثل هذه القصص. على سبيل المثال ، قررنا إنشاء تطبيق يسمى "التشغيل العصبي". في ذلك ، ستجري الشبكة العصبية محادثات حميمة مع المنتجات التي لم تقض يومًا (وليس لديها أصدقاء).



من أجل التبسيط ، نفترض أن لدينا بالفعل شبكة عصبية مدربة ونحتاج إلى إنشاء واجهة لها في شكل تطبيق.



من المحتمل أن تتكون المعارف التقليدية من الأسطر التالية:

1. إذن المستخدم
2. ملف تعريفي للمستخدم
3. شاشة الاتصال بالقدم العصبي
4. شاشة "كتالوج Neuroboot"
5. شاشة الملف الشخصي والإعدادات
6. نافذة الدفع المنبثقة
7. اتصال التحليلات

يبقى أن ترسم كل قصة (بالشكل أعلاه) وترسلها إلى التطوير. قلت لك أنه سيكون سهلا.

---

خارقة الحياة الصعبة

هناك عدد من التقنيات التي تساعدني في العمل على منتج كل يوم. فيما يلي تلك التي تتعلق بكتابة الاختصاصات.

اختراق الحياة رقم 1: التفاصيل بشكل متكرر

الآن أنا لا أكتب المواصفات الفنية على الإطلاق - فهم أنفسهم ، في الخلفية ، يظهرون في عملية العمل. عندما تظهر مهمة جديدة ، أكتشف على الفور: ما هي المهام الفرعية اللازمة للقيام بذلك؟ ثم أقوم بإصلاح كل مهمة فرعية بتنسيق القصة (فقط الاسم والتفاصيل ستظهر لاحقًا).



وبالتالي ، لدي على الفور اختصاصات عامة جاهزة. يبقى فقط تفصيل القصة إلى الحد الذي سيكون من الممكن فيه إعطاء المهمة الفنية للتطوير.



يتم التفصيل أيضًا في الخلفية: أثناء البحث والتفكير في التفاصيل ، أقوم على الفور بتدوين الملاحظات داخل السطور المقابلة. بدلاً من التصميم ، أقوم بإدخال نماذج أولية من NinjaMock .



هذا النهج يسرع العمل بشكل كبير. بالإضافة إلى ذلك ، يتيح لك عدم تفويت الصورة الكبيرة وعدم التعمق في التفاصيل مسبقًا.

اختراق الحياة رقم 2: عدم العمل مع الجينات

كان هناك مثل هذا الفيلم القديم حيث جعل الجني أمنياته تتحقق بأسوأ طريقة ممكنة.



بالطبع ، لن يبحث المطور العقلاني على وجه التحديد عن فرصة للإيذاء. لكن في بعض الأحيان لا يهتم الناس بما يعملون عليه. ثم يقومون بالمهمة "كما هو مكتوب" ، وليس الخوض في سبب الحاجة إليها. بشكل دوري ، سينتج عن ذلك ملفات كبيرة وصغيرة. حسنًا ، نعم ، تم وضع الإنتاج ... لكن لم يكتب أحد في المهمة ما يجب التحقق منه - ما إذا كان هذا التنفيذ سيؤدي إلى كسر كل شيء آخر.



لن أقول عن الاستعانة بمصادر خارجية ، لكن هذا النهج غير مقبول في المنتج. المطور الجيد هو بناء معبد وليس فقط رصف الطوب. أي أنه يرى الصورة الكبيرة ويتعمق في ما يحدث. غالبًا ما يقدم هؤلاء الرجال حلولًا بديلة ويحذرون أنفسهم من المزالق.



لذلك ، إذا كنت تريد أن تتم معارفك التقليدية بأفضل طريقة ممكنة ، فأنت بحاجة أحيانًا إلى تحسين ليس المعارف التقليدية ، ولكن ثقافة التطوير في الفريق. بشكل عام ، هذه مهمة رئيس الوزراء ، ولكن المنتج يمكن أن يؤثر أيضًا على الموقف. خاصة إذا كان الفريق يثق به (بفضل مواصفاته الفنية المدروسة والمصممة جيدًا ، على سبيل المثال).

Life hack # 3: فصل التعيين الفني عن التوثيق

الشروط المرجعية تجيب على السؤال "ما العمل؟" والتوثيق - على السؤال "كيف يتم ذلك / كيف يعمل؟" يتم كتابة المعارف التقليدية قبل تنفيذ المهمة ، ويتم كتابة الوثائق بعد ذلك.



إذا كنت بحاجة إلى إعادة ترتيب الخزانة ، فسأكتب مهمة بروح "إعادة الترتيب من هنا -> هنا". لكنني لن أرسم المخطط المعماري للمنزل الذي توجد فيه خزانة ملابس.



في بعض الأحيان ، هناك رأي مفاده أنه يجب كتابة المعارف التقليدية بحيث تكون ، كما كانت ، في نفس الوقت ، والتوثيق . هذه نظرية خبيثة. لن يعمل التوثيق الكامل ، لأنه من غير المعروف مسبقًا كيف سيتم تنفيذ الاختصاصات بالضبط. بالإضافة إلى ذلك ، يحتاج المطورون إلى مساحة للمناورة لا توفرها الوثائق. والشيء الرئيسي هو كتابة مثل هذه المعارف التقليدية عدة مرات وسيتضح أنها مرهقة.



هناك منتجات مختلفة وشركات ناشئة مختلفة. يمكن لأي شخص الاستغناء عن الوثائق على الإطلاق. ولكن إذا كنت لا تزال بحاجة إلى الوثائق ، فقم بتعيين يونيو الذي سيصف الوظيفة بالتفصيل بعد تنفيذها. لا تحتاج إلى مهارات خاصة لوصف الوظائف الحالية ، ولكنك ستوفر الوقت والأعصاب للموظفين الماهرين - مطوري المنتجات والمطورين.

اختراق الحياة # 4: تعلم البرمجة

ملاحظة تجريبية بحتة: المنتجات التي تعرف كيفية البرمجة أفضل في صياغة المهام. علاوة على ذلك ، ليس من الضروري أن تصبح عاملًا رئيسيًا في الخلفية ، يكفي إتقان أي لغة برمجة وفهم جوهر التفكير الحسابي.



في وقت من الأوقات كنت لا أزال أقوم بالترميز بشكل لا يمكن السيطرة عليه على الطيف القيمي ، وفي سنوات دراستي كان علي كتابة برامج تشغيل في المجمع. أي أنني على دراية بالبرمجة بشكل مباشر - وهذا بالطبع يساعد في إيجاد لغة مشتركة مع المطورين.

اختراق الحياة رقم 5: التفكير كثيرًا والكتابة قليلاً

تنشأ المشاكل الأكبر دائمًا مع المهام التي لا يفهمها العميل نفسه تمامًا. على سبيل المثال ، يحتاج إلى تقرير جديد في منطقة الإدارة ، لكنه لا يفهم تمامًا كيف سيتم تكوين هذا التقرير. مثل ، أنتم المبرمجين سوف تكتشفونها. لا ، الأمر لا يعمل بهذه الطريقة.



الطريقة الوحيدة لكتابة مشكلة جيدة يتم تنفيذها بشكل صحيح هي الفهم. من الناحية المثالية ، افهم المشكلة بشكل كافٍ بحيث يمكنك القيام بها بنفسك ... إذا كنت تعرف كيفية البرمجة.



ولكن عندما اكتشفت ذلك ، فلن تحتاج إلى تفريغ جميع المعلومات الموجودة في المعارف التقليدية. إنه مجرد فهم عميق للمهمة يتيح لك التخلص من الأشياء غير الضرورية وكتابة ما يهم فقط.

---

PS TK هي وسيلة وليست غاية. لذلك ، أحيانًا يكون أفضل المعارف التقليدية هو غيابها. سأخبرك يومًا ما كيف أطلقت منتجين بدون أي مواصفات فنية على الإطلاق.



PPS إذا كان لديك تنسيق خاص بك للاختصاصات أو متسللين للحياة عند كتابتها - يرجى مشاركتها في التعليقات.