يبدو للكثيرين أن Yandex هي شركة كبيرة متجانسة ذات عمليات منظمة صارمة ، ولكن هذا ليس كذلك. نحن نبحث باستمرار عن اتجاهات جديدة ، ونبدأ مشاريع جديدة ونجرب أسواقًا جديدة. خدمة الاستشارات عبر الإنترنت مع Yandex.Health Doctor هي واحدة من الشركات الداخلية الكلاسيكية الناشئة.
جئت لقيادة تطوير الصحة في وقت كانت فيه الخدمة لا تزال صفحة تحتوي على ملخص عن الويكي الداخلي. في هذا المنشور ، أرغب في مشاركة مناهج التطوير التي قمنا بتطويرها على مدار عامين ونصف من العمل في الخدمة.
تنويه:الشركة الناشئة لها خصائصها الخاصة. مهمتنا الرئيسية هي القيام بأقصى عدد من التجارب لكل وحدة زمنية وإصدار ميزات المنتج بأقصى سرعة ممكنة. في الوقت نفسه ، يجب أن نحافظ على جودة المنتج عند هذا المستوى بحيث لا يكون عارًا عليه.
[مكان لهيب حول عدم ضمير البعض] . ألاحظ أن السرعة العالية لتقديم الميزات تعني ، من بين أمور أخرى ، الحفاظ على رمز عالي الجودة إلى حد ما. خلاف ذلك ، فإن المنتج يختنق عاجلا أو آجلا في البق.
جميع النقاط أدناه عانت بطريقة أو بأخرى ، كل واحد لديه حالة من الحياة الحقيقية.
كود الجودة والهندسة المعمارية
- نقوم بتقليل الوقت اللازم لتقديم الميزات إلى الإنتاج مع الحفاظ على الجودة المقبولة.
- تتضمن أي مهمة حلين: سريع وصحيح. بالنسبة لأي ميزة ، نفكر في كلا الخيارين بحيث يمكن ترقية الحل السريع إلى الحل الصحيح ، مما يجعل العمل غير الضروري لـ "الطرد" كحد أدنى. بعد طرح حل سريع ، نبحث عن بعض الوقت ونفهم ما إذا كانت هناك حاجة إلى الحل الصحيح.
- بشكل حاسم. غالبًا ما يكون الفارق الزمني بين "حل الطريقة الأولى التي تحصل عليها من خلال تسجيل عكاز" و "حل جميل ودقيق" هو عشر دقائق. لذلك ، نفكر دائمًا قبل الكتابة.
- إذا كان هناك خيار بين التحسين البسيط والقدرة على القراءة / الهندسة المعمارية - اختر الثاني. لن يحل جزءان من الثانية أي شيء ، ومع هذا الكود لا يزال علينا أن نحيا ونحافظ عليه.
- نحن نفكر في المستقبل. المستقبل القريب أكثر أهمية من الآفاق البعيدة. إذا كان من الممكن جعل القرار صعبًا (اقرأ "طويل") ومرناً ، أو بسيطًا ، ولكن مسمرًا ، فإنه يستحق التسمير ثم إعادة البناء حسب الضرورة. من الأفضل قضاء يوم على حل بسيط الآن وشهر على إعادة هيكلة محتملة في غضون عام ، أكثر من أسبوعين الآن (نعم ، هذا ما يسمى الدين الفني). من المهم أن تستحق مثل هذه القرارات مناقشتها مع الفريق. وحدها ، يمكنك تقييم احتمال توسيع هذه الميزة بشكل غير صحيح في المستقبل القريب.
التكنولوجيا الجديدة
التقنيات الجديدة رائعة ، دعنا نستخدمها. لكن منتجنا ليس ساحة اختبار. إذا كنت تريد تطبيق خوارزمية أو تقنية جديدة ، فيمكن القيام بذلك في الظروف التالية:
- تحمل التكنولوجيا ربحًا ملموسًا (التحسين ، وجودة العمارة ، والتعليمات البرمجية ، وقابلية التوسع ، وكل هذا مطلوب حقًا ، وليس بعيد المنال) ؛
تتناسب التكنولوجيا بشكل طبيعي مع المكدس الحالي (لا تحتاج إلى كتابة جزء من الخدمات في Go إذا كانت جميع التعليمات البرمجية مكتوبة في Python) ؛ - لا تقلل التكنولوجيا من جودة الهندسة المعمارية وإمكانية قراءة الكود (هذا موضوعي ، لذلك يتم مناقشته مع الفريق) ؛
- لا يستغرق تطبيق ودعم تقنية جديدة (بما في ذلك البحث عن مطورين جدد) وقتًا أطول من العمل ضمن إطار التكنولوجيا الحالية. مرة أخرى ، كل هذا يتوقف على الربح المتوقع وتتم مناقشته مع الفريق ؛
- تتم مناقشة أي تقنية جديدة مع الفريق: إذا كانت رائعة ، فمن المناسب للجميع استخدامها ، إن لم يكن حقًا ، فإن المناقشة الجماعية تسمح لك بفهم ذلك بسرعة ؛
لا تحتاج إلى تنفيذ الخوارزميات التي تم تنفيذها بالفعل في المكتبات الجاهزة بشكل مستقل (باستثناء الحالة عندما تكون جزءًا صغيرًا من إطار عمل ضخم ولا معنى لسحبها كلها لحل واحد). - إذا فعلت شيئًا رائعًا ومريحًا ، فشارك الحل مع الفريق (أو الأفضل ، داخل Yandex).
التواصل
- نناقش الحل معا. كلما كانت الوظيفة أكثر تعقيدًا وحرجة ، زادت أهمية مثل هذه المناقشة. إذا كان شخص ما لا يحب الحل ، فإننا نقنع بعضنا البعض حتى يتم التوصل إلى اتفاق. أو أن وقت المناقشة لن يتجاوز الوقت المعقول.
- إذا لم يكن من الممكن الموافقة ، فإن الكلمة الأخيرة تصل إلى الرأس. لدينا ديمقراطية معقولة ، وليس مجلس النواب البولندي في القرن السابع عشر . في الوقت نفسه ، يتلقى القائد ناقصًا كبيرًا في الكارما ويجب أن يعاني من المعاناة الأخلاقية. وبالتأكيد عدم استخدام هذا الحق في كثير من الأحيان.
- بمجرد أن نقرر ، نفعل ما تم الاتفاق عليه. حتى لو اختلفت بشدة. لا شيء "أعرف أفضل من جميع خبراء المنتجات هؤلاء كيفية تقديم خدمة ، لذلك سأفعل ما أعتقد أنه ضروري"
- "ليس في همز - لم يتم". الجميع يتبع مهامه الخاصة. إذا كانت الميزة جاهزة للاختبار ، فستحتاج إلى التأكد من طرحها في الاختبار. إذا كانت جاهزة للإفراج عنها ، فأنت بحاجة إلى التأكد من دخولها المنتج في أقرب وقت ممكن. لا يتذكر الأشخاص المسؤولون عن تشكيل الإصدار دائمًا كل ميزة. لا تتردد في تذكيرها. [مكان لهب حول توزيع المسؤولية بين الأدوار في الفريق.] .
- من الضروري تشغيل الرأس. إذا كانت المهمة تبدو غريبة أو غير مفهومة أو طويلة جدًا ، فيجب إخبار المدير بوضوح وبصوت عالٍ. وقم بذلك حتى يكون لديك فهم واضح لماذا يجب أن يكون كل شيء على هذا النحو. يحدث أن الأسئلة الصحيحة المطروحة في الوقت المناسب توفر أسابيع من التطوير.
إدارة الوقت
- إذا كانت المهمة لا تصلح في غضون فترة زمنية معقولة ، يجب أن نتحدث عنها بصوت عال. لا يجب أن تجلس وتقطع المهمة لعدة أشهر بتقييم لمدة ثلاثة أيام. إذا كانت تسحب بكثافة ، فهناك خطأ ما. ربما هناك سوء فهم في الإنتاج أو قللنا من حجم العمل. على أي حال ، يجب إعادة مناقشة هذه المهام (ونتيجة لذلك ، يتم تأجيلها أو حتى دفنها في بعض الأحيان).
- يجب أن تحل المشاكل التي تنشأ بشكل مستقل. ولكن إذا كان من الواضح أن العملية قد تم تأجيلها ، فتأكد من التحدث عنها وطلب المساعدة من الزملاء. التمسك لعدة أيام في الدولة "يجب أن أفعل كل شيء بنفسي وألا أشغل رفاقي" أمر سيء للغاية.
- لا أحد ينظر في أي وقت يأتي كل منا ويغادر حتى ننجح ، ولا يبدأ نظامنا في التدخل في عمل الفريق. لكن الجلوس ليلاً فقط لأنه ليس لديك الوقت للقيام بشيء ليس ضروريًا. إذا تحول هذا إلى عادة ، فإن المشكلة تكون أعمق - في التخطيط ، وإعادة تقييم قدرات المرء الخاصة ، وما إلى ذلك. في حين أن المطور يعمل وقتًا إضافيًا في الليل (ونتيجة لذلك كل شيء في الوقت المناسب) ، فإن فرص رؤية شخص ما لهذه المشكلة وحلها تقل كثيرًا.
- يحدث أننا بحاجة إلى إطلاق ميزة مهمة بحلول التاريخ المتفق عليه (أو في أقرب وقت ممكن). في هذه الحالة ، نذهب إلى العمل الإضافي. علاوة على ذلك ، يتلقى القائد ناقصًا كبيرًا في الكارما ويجب أن يعاني من المعاناة الأخلاقية. وبالتأكيد عدم اغتنام هذه الفرصة في كثير من الأحيان. يتم تعويض هذا العمل الإضافي. [مكان لهيب حول العمل الإضافي والتعويض] .
خطايا مميتة
هذا قسم منفصل. هنا حاولت سرد ما أعتقد أنه خاطئ وضار عند العمل في فريق. كل عنصر له وزنه الخاص. يتحدث البعض عن مشاكل كبيرة للغاية ، والبعض الآخر ليس بالغ الأهمية. لذا ، ما يجب تجنبه بكل الوسائل:
- العمل ، لا يشمل الرأس: "قيل لي أن أفعل - فعلت". يجب أن يفهم كل عضو في الفريق جوهر الميزة التي يصنعها وتأثيرها على المنتج.
- رمي الميزات التي لم يتم تفريغها في حث مع الكلمات "فعلت كل شيء". ما نقوم به يجب أن يعمل في الإنتاج. في حين أن الميزة ليست في prod ، فهي ليست جاهزة.
- وافق على القيام بذلك بطريقة واحدة ، ثم قم به بهدوء على طريقتك الخاصة. أعلاه كان بالفعل حول "أعرف أفضل من أي شخص أفضل". ولكن مرة أخرى تذكر أن هذا سيئ لن يضر.
- تشديد الميزات المهمة ، والبحث في مناقشة المشاكل النادرة وغير الواقعية ، ولكن المحتملة المحتملة. إذا لم تتمكن في وقت معقول من معرفة كيفية التغلب على مشكلة ثانوية ونادرًا ما تتكرر ، فإننا نتفق ببساطة على كيفية التعايش معها.
- لا تعرب عن المشاكل في الوقت المناسب ، محاولاً حل كل شيء بنفسك (عادةً في الليل). مثل هذه البطولة لا تؤدي إلا إلى فشل المصطلحات والتعب والشعور بالتقليل من شأن: "أنا أقوم بمآثر هنا ، لكنني أيضًا أنتقد بسبب عملي البطيء!"
- من المؤلم الرد على انتقاد المدونة والدخول في توضيح العلاقة. حتى إذا قال أحد الزملاء أن الشفرة مشتركة تمامًا ("فلنعيد كتابة كل شيء!") ، تعامل مع هذا الأمر بفهم وناقش لماذا يعتقد ذلك. بالنسبة لك شخصيًا ، هذا لا يقل فائدة عن الخدمة ككل.
- اذهب إلى الشخص. من خلال انتقاد رمز أو حل ، فإننا لا ننتقد إلا الرمز أو الحل ، ولكن في أي حال من الأحوال الشخص الذي كتبه أو اقترحه. بالنظر إلى الفقرة السابقة ، لا تخف من الانتقاد. أفضل وقت معقول للجدل مع الزملاء من إرسال قرار غير ناجح للحث.
المجموع
هنا يمكنك كتابة المزيد عن مليون شيء. ولكن كلما كان المنشور أقصر ، كان من الأسهل قراءته
حتى النهاية ، وآمل ذلك حقًا. ونعم ، أنا لا أتناول النقد بشكل مؤلم (بشرط ألا تحصل على شخصية ؛). لذا دعونا نناقش!