چرا محصول‌ها در فاصله‌ی «نیاز» تا «ساخت» شکست می‌خورند

وقتی یک محصول نرم‌افزاری به نتیجه نمی‌رسد، اولین متهم معمولاً تیم فنی است: «کد ضعیف بود»، «برنامه‌نویس‌ها دیر تحویل دادند». اما اگر پروژه‌های ناموفق را کنار هم بگذارید، الگوی دیگری دیده می‌شود. در اغلب آن‌ها کد کار می‌کرد؛ فقط چیزی ساخته شده بود که مسئله‌ی اصلی را حل نمی‌کرد.

مشکل در فاصله‌ای است که میان «آنچه کسب‌وکار لازم دارد» و «آنچه در عمل ساخته می‌شود» وجود دارد. این مقاله درباره‌ی همین فاصله است.

شکاف از کجا شروع می‌شود

صاحب کسب‌وکار مسئله را به زبان خودش می‌گوید: «مشتری‌ها جواب نمی‌گیرند»، «فروشمان در پیام‌رسان‌ها از دست می‌رود». تیم فنی اما به زبان دیگری فکر می‌کند: جدول، سرویس، صفحه، API. میان این دو زبان باید کسی ترجمه کند. اگر این ترجمه انجام نشود، هر طرف با برداشت خودش جلو می‌رود.

نتیجه آشناست: کارفرما چیزی را تحویل می‌گیرد که دقیقاً همان است که گفته بود، ولی آن چیزی نیست که می‌خواست.

پنج نشانه‌ی اینکه در این شکاف افتاده‌اید

• راه‌حل قبل از مسئله تعریف شده است. جلسه با «یک اپ می‌خواهیم» شروع می‌شود، نه با «این مشکل را داریم».
• معیار موفقیت وجود ندارد. کسی نمی‌تواند بگوید محصول چه زمانی «موفق» حساب می‌شود.
• دامنه مدام بزرگ می‌شود. هر هفته قابلیت تازه‌ای اضافه می‌شود و تاریخ تحویل عقب می‌رود.
• تصمیم‌ها شفاهی‌اند. هیچ سندی نیست که بگوید چرا این مسیر انتخاب شد.
• اولین نمایش، آخر کار است. کارفرما محصول را وقتی می‌بیند که تغییر دادنش گران شده است.

اگر دو یا سه مورد از این‌ها را در پروژه‌ی خودتان می‌بینید، مشکل شما فنی نیست؛ مشکل تعریف است.

چرا «برنامه‌نویس بهتر» این مشکل را حل نمی‌کند

یک تیم فنی قوی، چیزی را که به او گفته شده سریع‌تر و تمیزتر می‌سازد. اگر تعریف اشتباه باشد، فقط سریع‌تر به مقصد اشتباه می‌رسید. به همین دلیل است که اضافه کردن نیرو به پروژه‌ای که تعریف روشنی ندارد، اغلب آن را کندتر می‌کند.

بستن شکاف در عمل

بستن این فاصله یک کار مشخص است، نه یک مهارت مبهم. سه لایه دارد:

1. تعریف دقیق مسئله. پیش از هر راه‌حل، باید روشن شود چه کسی، در چه موقعیتی، چه مشکلی دارد و امروز چطور با آن کنار می‌آید. درباره‌ی این مرحله در هفت پرسش پیش از نوشتن اولین خط کد نوشته‌ام.
2. سند مکتوب. دامنه، اولویت‌ها و معیار موفقیت باید نوشته شوند. ابزار این کار PRD است.
3. دروازه‌ی تأیید در هر گام. هر مرحله خروجی مستندی دارد که کارفرما می‌بیند و تأیید می‌کند. این‌طور اشتباه در همان مرحله دیده می‌شود، نه شش ماه بعد. جزئیات این روش در صفحه‌ی روش کار آمده است.

یک نفر باید مالک کل مسیر باشد

شکاف وقتی باز می‌ماند که مسئولیت تکه‌تکه باشد: یکی نیاز را می‌گیرد، دیگری طراحی می‌کند، سومی می‌سازد و هیچ‌کس پاسخ‌گوی نتیجه‌ی نهایی نیست. تجربه‌ی من این است که وجود یک مسئول پاسخ‌گو برای کل مسیر بیش از هر ابزار و متدی اثر دارد.

این همان نقشی است که من در پروژه‌ها بر عهده می‌گیرم: مسئله را تعریف می‌کنم، سامانه را معماری می‌کنم و ساخت را همراه تیم توسعه تا انتشار هدایت می‌کنم. محصولاتی مثل پاسخینو و راهرو با همین روش ساخته شده‌اند.

جمع‌بندی

محصول شما احتمالاً به برنامه‌نویس بیشتری نیاز ندارد؛ به تعریف دقیق‌تری نیاز دارد. اگر مسئله روشن، مکتوب و تأییدشده باشد، ساختن آن بخش قابل‌پیش‌بینی کار است.

اگر در ابتدای یک پروژه هستید، خدمت کشف و تعریف محصول دقیقاً برای همین نقطه طراحی شده است.