در functional spec چیز functional زیادی نیست¶
سند functional specification ننویسید¶
این سندهای blueprint معمولاً در نهایت تقریباً هیچ ربطی به محصول نهایی ندارند. دلیلش این است:
functional specها خیالاند¶
واقعیت را بازتاب نمیدهند. اپ تا وقتی سازندهها آن را نمیسازند، طراحها طراحیاش نمیکنند و آدمها استفادهاش نمیکنند، واقعی نیست. functional spec فقط کلمه روی کاغذ است.
functional specها برای راضی نگه داشتناند¶
درباره ایناند که همه حس کنند درگیرند و خوشحال باشند؛ چیزی گرم و نرم، اما نه چندان مفید. هرگز درباره گرفتن تصمیمهای سخت و آشکار کردن هزینهها نیستند؛ همان چیزهایی که برای ساختن اپ عالی لازماند.
functional specها فقط توهم توافق میسازند¶
توافق یک عده آدم روی چند پاراگراف متن، توافق واقعی نیست. ممکن است همه یک چیز را بخوانند، اما هرکس چیز متفاوتی فکر میکند. این ناگزیر بعداً بیرون میزند: «صبر کن، منظور من این نبود.» «ها؟ ما اینطور توصیفش نکرده بودیم.» «چرا، همین بود و همه قبول کردیم؛ حتی sign off هم کردی.» خودتان روال را میدانید.
functional specها مجبور میکنند مهمترین تصمیمها را وقتی بگیرید که کمترین اطلاعات را دارید¶
وقتی شروع به ساختن چیزی میکنید، کمترین شناخت را از آن دارید. هرچه بیشتر بسازید، بیشتر استفاده کنید و بیشتر بشناسید، بیشتر میدانید. همان وقت باید تصمیم بگیرید؛ وقتی اطلاعات بیشتر دارید، نه کمتر.
functional specها به اضافهبار قابلیت منجر میشوند¶
در مرحله spec مقاومتی وجود ندارد. نوشتن چیزی و اضافه کردن یک bullet point دیگر هزینهای ندارد. میتوانید کسی را که دردسرساز است با اضافه کردن قابلیت محبوبش راضی کنید. بعد در نهایت برای همان bullet pointها طراحی میکنید، نه برای انسانها. اینگونه سایتی میسازید که overload شده و ۳۰ tab بالای صفحه دارد.
functional specها اجازه تکامل، تغییر و بازسنجی نمیدهند¶
قابلیت sign off و توافق شده است. حتی اگر در توسعه بفهمید ایده بدی است، گیرش افتادهاید. specها با این واقعیت کنار نمیآیند که وقتی شروع به ساختن چیزی میکنید، همه چیز تغییر میکند.
پس به جای spec چه باید کرد؟ سراغ جایگزینی کوتاهتر بروید که شما را به چیز واقعی نزدیک کند. یک داستان یکصفحهای درباره کاری که اپ باید انجام دهد بنویسید. با زبان ساده و سریع. اگر توضیحش بیش از یک صفحه طول میکشد، بیش از حد پیچیده است. این فرایند نباید بیش از یک روز وقت بگیرد.
بعد شروع به ساختن رابط کنید؛ رابط جایگزین functional spec خواهد بود. چند sketch کاغذی سریع و ساده بکشید. بعد شروع کنید آن را در HTML کدنویسی کنید. برخلاف پاراگرافهای متن که تفسیرهای مختلف دارند، طراحیهای رابط زمین مشترکیاند که همه میتوانند روی آن توافق کنند.
وقتی همه شروع به استفاده از صفحههای یکسان کنند، سردرگمی ناپدید میشود. پیش از آنکه نگران کد back-end شوید، رابطی بسازید که همه بتوانند ببینند، استفاده کنند، کلیک کنند و «حس» کنند. تا جای ممکن خودتان را جلوی تجربه مشتری بگذارید.
specهای قفلشده را فراموش کنید. آنها مجبور میکنند تصمیمهای بزرگ و کلیدی را خیلی زود در فرایند بگیرید. از مرحله spec عبور کنید تا تغییر ارزان بماند و منعطف بمانید.
specهای بیمصرف¶
یک «spec» تقریباً بیمصرف است. من هرگز specای ندیدهام که هم آنقدر بزرگ باشد که مفید باشد و هم دقیق.
و کارهای کاملاً مزخرف زیادی دیدهام که بر اساس specها انجام شدهاند. این بدترین راه نوشتن نرمافزار است، چون بنا به تعریف یعنی نرمافزار برای مطابقت با نظریه نوشته شده، نه واقعیت.
—Linus Torvalds، سازنده Linux (از Linux: Linus On Specifications)
با blockerها بجنگید¶
فهمیدم آدمهایی که پیش از شروع هر طراحی بر سندهای requirements مفصل اصرار میکنند، واقعاً blocker هستند که فقط میخواهند فرایند را کند کنند؛ و معمولاً آدمهاییاند که چیزی برای مشارکت در طراحی یا فکر نوآورانه ندارند.
بهترین کارهای ما با چند مفهوم در ذهنمان درباره بهتر کردن یک سایت، ساختن سریع prototype ثابت، کمی تغییر طراحی و بعد ساختن prototype زنده با داده واقعی انجام شد. پس از امتحان کردن این prototype، معمولاً پروژه واقعی در حرکت بود و نتیجه خوبی داشتیم.
—Mark Gallagher، توسعهدهنده intranet شرکتی (از Signal vs. Noise)
منبع اصلی: There’s Nothing Functional about a Functional Spec