همزمان که تیم در حال جهتگیری و شروع به کار است، شروع به کشف و ردیابی وظایفی میکند که برای ساخت پروژه نیاز دارد. در این مرحله اولیه، خیلی مهم است که یک نقشه جامع از بخشهایی که باید در لحظه آخر کنار هم قرار بگیرند، ایجاد نکنند. اگر تیم کارهای زیادی را انجام دهد اما «یک چیز» قابل کلیک و تست کردن وجود نداشته باشد، احساس پیشرفت سخت است. یک تیم میتواند کارهای زیادی انجام دهد اما احساس ناامنی کند چون هنوز چیزی واقعی برای نمایش ندارد. خیلی چیزها «انجام شدهاند» اما هیچچیز واقعاً «تمام نشده» است.
در عوض، آنها باید هدفشان این باشد که چیزی ملموس و قابل دمو (Demoable) را زود – در همان هفته اول یا حدوداً – بسازند. این کار مستلزم ادغام عمودی روی یک تکه کوچک از پروژه است به جای اینکه لایههای افقی را کمکم انجام دهند.
ما میتوانیم پروژهها را در دو لایه اصلی تصور کنیم: فرانت-اند (Front-end) و بک-اند (Back-end)، یا طراحی و کد. اگرچه از لحاظ فنی لایههای بیشتری وجود دارد، اما این دو چالش اصلی ادغام در بیشتر پروژهها هستند. فرض کنید پروژه با طراحی زیادی شروع میشود. تیم میتواند صفحههای متنوعی را طراحی کند و حتی آنها را به عنوان قالب (templates) یا نما (views) پیادهسازی کند. اما تا زمانی که آنها به یک بک-اند متصل نشوند، هیچچیزی کار نمیکند. کار فرضی و حدسی باقی میماند.
همینطور در مورد بک-اند. کارهای زیادی میتوانند تیک بخورند، اما بدون هیچ رابط کاربری (UI) – چه کاری میتوانید با آن انجام دهید؟ چطور قضاوت میکنید که کار روی یک تکه خاص از منطق کسبوکار (Business logic) واقعاً درست است بدون اینکه با آن تعامل داشته باشید؟
آنچه ما در عوض میخواهیم این است که یک برش (slice) از پروژه را انتخاب کرده و آن را ادغام کنیم. سپس وقتی این کار انجام شد، تیم چیزی ملموس دارد که اثبات کردهاند کار میکند (یا کار نمیکند و باید بازنگری شود). هر کسی میتواند روی تعامل (interaction) کلیک کند و ببیند که آیا ویژگی (feature) کاری که باید را انجام میدهد و آیا کاری که میکند، همان چیزی است که آنها میخواهند.
مشتریان در پروژهها ما یک ویژگی در Basecamp 3 ساختیم که به شرکتهای خدماتی اجازه میداد مشتریان را به پروژههایشان دعوت کنند و اسناد، پیامها یا لیست کارهای انتخاب شده را با آنها به اشتراک بگذارند. مفهوم، که در طرح اولیه (pitch) تعریف شده بود، قسمتهای متحرک مختلفی داشت:
• دسترسی مشتری (Client Access): قبل از این ویژگی، مدل دسترسی Basecamp همه یا هیچ بود. ما به راهی نیاز داشتیم تا برخی افراد را دعوت کنیم تا فقط بخشهایی از یک پروژه را ببینند. این موضوع پیامدهای بزرگی برای بک-اند و کشینگ (caching) داشت.
• مدیریت مشتری (Client Management): ما به راهی برای اضافه کردن مشتریان به پروژهها و قابلیت مدیریت مشتریان به صورت جداگانه از اعضای تیم نیاز داشتیم.
• سوئیچ دیداری (Visibility Toggle): هر بخش از محتوا در یک پروژه باید یک توگل (toggle) برای نمایش آن به مشتریان یا عدم نمایش آن داشته باشد.
تیم متشکل از یک طراح و یک برنامهنویس بود. پس از اینکه آنها جهتگیری کردند و با نحوه کار کد موجود آشنا شدند، طراح سوئیچ دیداری را به عنوان بهترین نقطه برای ادغام اولیه انتخاب کرد.
این مرکزیترین بخش رابط کاربری (UI) در پروژه بود. این همان چیزی بود که در ویدئوهای دمو ظاهر میشد و تعاملی بود که مشتریان بیشتر از آن استفاده میکردند. طراح یک ماکآپ (mockup) پیکسل به پیکسل (pixel-perfect) نساخت. در عوض، او با نشانههای تعاملی (affordances) و جایگاههای مختلف در قالبهای HTML برنامه آزمایش کرد. آیا توگل باید دو دکمه رادیویی باشد، یک چکباکس، یا یک دکمه سفارشی که وضعیت خود را تغییر میدهد؟ در همین حین، برنامهنویس منتظر نماند. او از طرح اولیه (pitch) راهنمایی کافی برای شروع به بررسی مدل دسترسی (access model) داشت.
به محض اینکه طراح در جهتگیری اصلی رابط کاربری (UI) اطمینان پیدا کرد، به برنامهنویس پیام داد و توگل ابتدایی (stubbed toggle) را به او نشان داد. برنامهنویس برای مدتی از مشکل دسترسی فاصله گرفت و توگل را به اندازهای متصل (wired) کرد که روی تمام انواع محتوای پشتیبانی شده ظاهر شود، هنگام کلیک وضعیتش تغییر کند، و وضعیتش را در پایگاه داده (database) ذخیره کند.
در این مرحله، توگل در واقع قابلیت دید محتوا را تغییر نمیداد. اما از دیدگاه شرکت خدماتی کار میکرد. طراح میتوانست روی آن کلیک کند، آن را حس کند، و قضاوت کند که چقدر خوب با دادههای زنده روی یک سرور استیجینگ (staging server) کار میکند. هنوز کارهای طراحی بیشتری روی توگل وجود داشت. اما برنامهنویس دیگر نیازی به درگیر شدن نداشت. با متصل شدن نشانههای تعاملی (affordance)، طراح میتوانست به آزمایش با کپی (copy)، جایگذاری، رنگ، رندر (rendering) در نمای موبایل و موارد دیگر ادامه دهد. در همین حال، برنامهنویس میتوانست به مدل دسترسی یا هر چیز مهم دیگری که باید انجام میشد، بازگردد.
حدود سه روز پس از شروع پروژه، طراح توگل کارا را به یک مدیر نمایش داد (دمو کرد). مکالمه آنها به چند تنظیمات (tweaks) بیشتر منجر شد و سپس آنها توانستند توگل را «تمام شده» اعلام کنند. یک تکه مهم از پروژه طراحی، پیادهسازی، دمو و قطعی شد. تیم از نمایش پیشرفت ملموس احساس خوبی داشت. و تیم و مدیریت هر دو با دیدن یک بخش کارا، اعتماد به پروژه پیدا کردند.
با کلیک کردن روی یک تعامل اصلی (core interaction) در مراحل اولیه، آنها توانستند تأیید کنند که آنچه امیدوار بودند در تئوری منطقی باشد، در عمل نیز درست به نظر میرسید و منطقی بود.
این مثال کوتاه چند نکته را در مورد نحوه ادغام تیمها در دورههای کوتاه برای اتمام یک بخش از پروژه در هر بار، نشان میدهد.
چون بخشهای متحرک مهم قبلاً در فرآیند شکلدهی (shaping process) تعریف شده بودند، برنامهنویسان نیازی نیست هنگام شروع پروژه بیکار بمانند و منتظر طراحی باشند. راهنمایی کافی در طرح اولیه (pitch) برای آنها وجود دارد تا از همان ابتدا روی مشکلات بک-اند کار کنند. آنها نمیتوانند یک تکه از قابلیت (functionality) را بدون دانستن اینکه در فرانت-اند به کجا منجر میشود، به اتمام برسانند، اما باید اطلاعات کافی در طرح اولیه برای تصمیمات مدلسازی اساسی (foundational modeling decisions) وجود داشته باشد.
برنامهنویسان برای شروع پیادهسازی نیازی به یک طراحی پیکسل به پیکسل ندارند. تنها چیزی که نیاز دارند، نقاط پایانی (endpoints) هستند: عناصر ورودی (input elements)، دکمهها، مکانهایی که دادههای ذخیره شده باید ظاهر شوند. این نشانههای تعاملی، هسته طراحی رابط کاربری هستند.
سوالات در مورد فونت، رنگ، فاصله (spacing) و چیدمان (layout) میتوانند پس از قرار گرفتن و اتصال (hooked up) نشانههای تعاملی خام در کد حل شوند. کپیرایتینگ (Copywriting)، نشانههای تعاملی اساسی و مقداری سیمکشی (wiring) تنها چیزی است که برای امتحان یک نسخه کارا و زنده در مرورگر یا روی دستگاه نیاز داریم. سپس میتوانیم به سوالات اساسی در مراحل اولیه پاسخ دهیم: آیا منطقی است؟ آیا قابل درک است؟ آیا کاری که میخواهیم را انجام میدهد؟ این بدان معناست که اولین رابط کاربری که یک طراح به یک برنامهنویس میدهد، میتواند بسیار ابتدایی به نظر برسد، مانند مثال زیر. بیشتر شبیه یک برد بورد (breadboard) است تا یک طراحی بصری یا یک ماکآپ صیقلی.
این اسکرینشات از یک برنامه ثبتنام برای دورههای چندروزه است. طراح آن را به صورت دستی در HTML ساخت. به سختی هیچ استایلی (style) وجود دارد – فقط به اندازه کافی سلسلهمراتب بصری (visual hierarchy) برای اطمینان از اینکه چیدمان قابل استفاده است و برای لایههای آینده استایلدهی آماده است. در حالی که طراحی ساده به نظر میرسد، تصمیمات زیادی در آن منعکس شده است.
• تصمیم برای درخواست زمان ورود اما نه زمان خروج، از بحثهای دقیق در مورد منطق کسبوکار و مدل قیمتگذاری (pricing model) گرفته شده است.
• گزینههای خاص در لیست کشویی (pulldown) زمان ورود، با قوانینی مطابقت دارند که باید در مورد زمان شارژ برای وعدههای غذایی و اقامت شبانه تدوین میشد.
• طراحیهای اولیه طراح از یک انتخابگر تاریخ (date picker) به سبک تقویم برای روزهای ورود و خروج استفاده میکرد. اما این به مشکلات تجربه کاربری (UX) منجر شد. برخی دورهها طولانی بودند (چند هفته) با فازهای مختلف. در یک انتخابگر تاریخ استاندارد به سبک تقویم، فضایی برای برچسبگذاری فازها روی جعبههای روز وجود نداشت. با یک لیست کشویی (pulldown)، او میتوانست از گروههای گزینه (option groups) برای برچسبگذاری گروههای تاریخ در صورت نیاز استفاده کند. به این ترتیب کاربران نیازی به مراجعه به یک برنامه زمانبندی در جای دیگر نداشتند تا مطمئن شوند که تاریخهای درستی را انتخاب میکنند.
در اینجا یک مثال دیگر آورده شده است. این اولین بخش کارا از یک برنامه برای گرفتن داده از مصاحبههای مشتری است.
در این مرحله اولیه، نام پروژه (Basecamp) و موضوع مصاحبه (Jan) هاردکد (hard-coded) شده بودند و بیشتر لینکها به جایی نمیرفتند. ببینید این طراحی چقدر خام (raw) است. اقدامات (actions) لینکهای متنی ساده با رنگهای پیشفرض آبی و بنفش مرورگر هستند. جعبههای حاوی نقاط داده (data points) به سختی با حاشیههای سیاه ساده استایل داده شدهاند.
با این حال، همین طراحی خام، برخی از تبادلات مهم را آزمایش میکند. طراح انتخاب کرد که تا آنجا که ممکن است دادهها را در قسمت بالایی صفحه (above the fold) نشان دهد تا بررسی مصاحبهها آسان باشد. این کار فضای کافی در هر بخش برای رابط کاربری (UI) برای اضافه کردن، ویرایش یا حذف نقاط داده باقی نگذاشت.
این باعث شد طراح صفحههای جداگانه برای اضافه کردن و ویرایش دادهها در هر بخش ایجاد کند. این اولین طراحی برای اضافه کردن و ویرایش «پولها» (pulls) – نوعی داده در این تکنیک مصاحبه – است. باز هم، ببینید چقدر خام است.
فقط به اندازه کافی طراحی در اینجا وجود دارد تا به سرعت آن را متصل (wire up) کرده و آزمایش کنید. تیم میتواند روی این کلیک کند تا قضاوت کند که آیا ناوبری (navigating) به یک صفحه جداگانه برای ثبت دادهها قابل قبول است یا خیر. اگر کار کند، میتوانند استایلدهی اضافی را بعداً اضافه کنند. اگر کار نکند، زمان زیادی را صرف پیادهسازی یک طراحی پیکسل به پیکسل نکردهاند.
همترازی (alignment) زیبا، رنگها و تایپوگرافی (typography) در مرحله اول اهمیت ندارند. استایلدهی بصری در محصول نهایی مهم است، نه در مراحل اولیه. بزرگترین عدم قطعیتها در مورد این است که آیا کار خواهد کرد، آیا منطقی خواهد بود، و پیادهسازی آن چقدر سخت خواهد بود. پس از اتصال عناصر، میتوان آنها را دوباره مرتب کرد (rearranged)، دوباره استایل داد (restyled)، و دوباره رنگ کرد (repainted) تا کار انجام شده بهبود یابد. اول کاری کنید که کار کند، سپس آن را زیبا کنید.
همین امر در مورد کار بک-اند نیز صدق میکند. لازم نیست همه یا هیچ باشد. گاهی اوقات یک طراح فقط به یک اسکلتبندی (scaffolding) نیاز دارد – چند فیلد که دادهها را ذخیره میکنند یا مقداری کد برای ناوبری از یک صفحه ابتدایی (stubbed screen) به دیگری. در مواقع دیگر، او نیاز دارد تا یک متغیر را در قالب (template) با مجموعهای از دادههای واقعی پر کند تا بتواند روی نمایشهای مختلف (ردیفها، ستونها، جعبههای رسانه و غیره) تکرار (iterate) کند تا بهترین طراحی را پیدا کند. کار اولیه بک-اند میتواند به صورت استراتژیک پراکنده (patchy) باشد.
ممکن است یک کنترلر (controller) برای رندر (render) قالبها وجود داشته باشد اما مدلی (model) نباشد. یا یک کنترلر و بخشهایی از یک مدل با دادههای ساختگی (mock data) اما بدون پشتیبانی برای ایجاد یا بهروزرسانی دادهها. صفحههایی که هنوز متصل نیستند، میتوانند حداقل با مسیرها (routes) برای ناوبری بین آنها متصل شوند.
هنگامی که زمان تست اولین تکه از برنامه مصاحبه رسید، تیم میدانست که دادههای حساسی از مصاحبههای واقعی وارد آن خواهد شد. آنها نیاز داشتند که آن را با نوعی احراز هویت (authentication) محافظت کنند. به جای ساخت پشتیبانی کامل از نام کاربری و رمز عبور – یا حتی ادغام یک راهکار شخص ثالث – آنها فقط از HTTPAuth ساده برای هاردکد کردن یک رمز عبور استفاده کردند.
این به تیم اجازه داد تا افزودن دادهها از مصاحبههای واقعی را خیلی زود در چرخه کاری امتحان کند، بدون اینکه برای اتصال کد احراز هویتی که هیچچیزی در مورد مشکلاتی که سعی در حل آن داشتند به آنها یاد نمیداد، کند شوند. نکته اصلی این است که یک تعامل رفت و برگشتی (back-and-forth) بین طراحی و برنامهنویسی روی یک تکه از محصول ایجاد کنید. به جای یک تحویل بزرگ، به نوبت افزودن تدریجی نشانههای تعاملی، کد، و سبکدهی بصری را انجام دهید. گام به گام، روی ویژگی واقعی در حال پیشرفت (feature-in-progress) کلیک کنید تا قضاوت کنید که چگونه پیش میرود و قدم بعدی چیست.
در مثالهای بالا، تیم ابتدا لاگین (log in) را نساخت. آنها قبل از حل مشکل اضافه کردن دادههای مصاحبه، راهی برای ایجاد یک پروژه مصاحبه و یک موضوع مصاحبه نساختند. آنها مستقیماً به میانه (وسط) پریدند، جایی که مشکل جالب بود، و همه چیزهای دیگر را موقتی (stubbed) کردند تا به آن برسند.
برای بسط این موضوع، سه معیار برای انتخاب اینکه چه چیزی را اول بسازید، در نظر بگیرید:
اول، باید اصلی (core) باشد. سوئیچ دیداری (visibility toggle) در مفهوم «مشتریان در پروژهها» اصلی بود. بدون آن، کارهای دیگر بیمعنی میشدند. این را با یک جنبه جانبیتر از پروژه مقایسه کنید، مانند قابلیت تغییر نام مشتری. هر دو «مورد نیاز» بودند، اما یکی مرکزیتر و مهمتر بود که در مراحل اولیه چرخه کاری اثبات شود. در برنامه مصاحبه، ثبت دادههای مصاحبه اصلیتر – بیشتر در میانه – از راهاندازی یک پروژه تحقیقاتی جدید بود.
دوم، باید کوچک (small) باشد. اگر اولین بخش کار به اندازه کافی کوچک نباشد، فایده زیادی در جدا کردن آن از بقیه وجود ندارد. هدف این است که چیزی معنادار را در چند روز به پایان برسانید و شتاب ایجاد کنید – داشتن چیزی واقعی برای کلیک کردن که نشان دهد تیم در مسیر درست است.
سوم، باید نوآورانه (novel) باشد. اگر دو بخش از پروژه هم اصلی (core) و هم کوچک (small) هستند، چیزی را ترجیح دهید که هرگز قبلاً انجام ندادهاید. در ویژگی «مشتریان در پروژهها»، رابط کاربری (UI) برای اضافه کردن مشتریان تقریباً مشابه رابط کاربری برای اضافه کردن کاربران عادی بود. شروع با آن پروژه را به جلو میبرد، اما به تیم چیزی یاد نمیداد. عدم قطعیت را از بین نمیبرد. شروع با سوئیچ دیداری اعتماد همه را بالا برد زیرا ثابت کرد که یک ایده جدید کار خواهد کرد.
