ग्राहकों की असुविधा से प्रोडक्ट बनने तक - Airbridge API टीम की डेवलपमेंट प्रोसेस

B2B मार्केटिंग टूल Airbridge को API टीम किस प्रोसेस के ज़रिए बनाती है, इस पर एक परिचयात्मक लेख

• ग्राहकों के अनुरोध और आइडिया इकट्ठा करना
• प्राथमिकता के आधार पर हल किए जाने वाले मुद्दों का चयन
• Kick off करना
  • यह समझना कि काम क्या है और user scenario को ठोस रूप देना
  • डेवलपर भी इसी चरण से शामिल होकर तकनीक पर सक्रिय रूप से अपनी राय देते हैं
• Tech spec लिखना
  • summary, background, goals, non-goals, work plan, अपेक्षित Q&A, considerations, milestones लिखना
  • जिस code पर काम होना है, उसका 30% पहले से लिखकर एक व्यवहार्य योजना बनाना
  • counterpart के साथ मिलकर review करना
• code पर काम
  • हर code के लिए उसके अनुरूप test code लिखना आवश्यक
• QA & Code Review
  • Feature branch के ज़रिए अपने-आप QA Endpoint तैयार होना
  • Code Review में मदद के लिए test execution automation और static analysis tools का automation चलाना
• Release
  • साथियों के साथ मिलकर बेहतर product बनने का जश्न मनाना

इस प्रोसेस के ज़रिए feedback cycle को छोटा किया गया, डेवलपमेंट चरणों को पारदर्शी बनाकर schedule को अधिक predictable बनाया गया, और features में error आने की संभावना कम की गई

• नई feature deployment से होने वाली errors समान अवधि की तुलना में 18% कम हुईं, और छोटे unit वाले tickets इस प्रोसेस से गुजरने के बाद भी सिर्फ 5 दिनों में release हुए

[yunyun0505]

स्कूल में software engineering की कक्षा में एक बात ज़रूर सिखाई जाती है। “योजना चरण में बदलाव करना सबसे कम लागत वाला होता है, और development पूरा होने के बाद बदलाव करना सबसे महंगा पड़ता है।” यह ऐसी बात है जिसे जानने के बावजूद अमल में लाना मुश्किल होता है। खासकर तेज़ी से आगे बढ़ने वाले startup में यह और भी सच है.
Airbridge की development team मुश्किल होने पर भी उस दिशा में आगे बढ़ने की कोशिश कर रही है जिसे वह सही मानती है।