چطور یک نفر یک ابزار ۴۰ هزار دلاری در سال را با چیزی که در یک روز ساخت جایگزین کرد

مارتا عملیات یک شرکت لجستیک ۳۰ نفره در گوادالاخارا را اداره می‌کرد. تیمش از یک پلتفرم مدیریت پروژهٔ سازمانی استفاده می‌کرد که سالانه حدود ۴۰٬۰۰۰ دلار برایشان آب می‌خورد — لایسنس به‌ازای هر صندلی، ردهٔ ویژه برای قابلیت‌های گزارش‌دهی، به‌علاوهٔ یک مشاور که دو سال پیش برای راه‌اندازی گردش‌کارهای اولیه استخدام کرده بودند.

این چیزی است که هیچ‌کس در تیم نمی‌خواست بلند بگوید: شاید از ۱۵٪ آن استفاده می‌کردند.

راننده‌ها مسیرهای روزانه‌شان را در ابزار ثبت می‌کردند. دیسپچرها یک تختهٔ Kanban را چک می‌کردند تا ببینند چه کسی در دسترس است. مارتا یک گزارش هفتگی می‌کشید که تحویل‌های به‌موقع و مسائل باز را نشان می‌داد. همین بود. نمودارهای گانت، تراز‌سازی منابع، برنامه‌ریزی اسپرینت، ردیابی زمان، و داشبوردهای سبد پروژه؟ هیچ‌کس دستشان نمی‌زد. داشتند پول یک چاقوی ارتشی سوئیسی را می‌دادند تا پاکت‌ها را باز کنند.

لحظه‌ای که جا افتاد

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

مارتا برنامه‌نویس نبود. یک بار یک دورهٔ Python گرفته بود و بعد از هفتهٔ سوم رهایش کرده بود. اما گردش‌کارهای خودش را بهتر از هر کسی می‌فهمید. می‌توانست دقیقاً توصیف کند تیمش به چه نیاز دارد چون هر روز درون آن فرایندها زندگی می‌کرد.

تصمیم گرفت پیش از امضای تمدید، خودش یک جایگزین بسازد.

او واقعاً چه ساخت

مارتا یک صبح شنبه با یک سازندهٔ اپ هوش مصنوعی نشست و شروع به توصیف آنچه نیاز داشت کرد، یک قطعه در هر زمان.

یک صفحهٔ ثبت مسیر. راننده‌ها باید در شروع شیفتشان چک‌این می‌کردند، ایستگاه‌های اختصاص‌داده‌شده‌شان را می‌دیدند، و هر کدام را تکمیل‌شده علامت می‌زدند. بدون مزخرفات گانتِ کشیدن و رها کردن — فقط یک فهرست با چک‌باکس و یک برچسب زمانی. او این را به اسپانیایی ساده توصیف کرد و تماشا کرد که سازندهٔ اپ یک رابط کارآمد با یک پایگاه داده پشتش تولید می‌کند.

یک داشبورد دیسپچر. یک صفحهٔ واحد که نشان می‌داد کدام راننده‌ها فعال‌اند، چند ایستگاه باقی دارند، و یک نشانگر رنگی برای اینکه آیا روی برنامه هستند. مارتا منطق را توصیف کرد: سبز اگر تا ظهر دست‌کم ۶۰٪ ایستگاه‌ها را تکمیل کرده بودند، زرد اگر بین ۴۰ تا ۶۰٪، قرمز زیر آن. سازنده این را به فرمت شرطی و یک نمای زنده‌به‌روزشونده ترجمه کرد.

یک گزارش هفتگی. اعدادی که مارتا واقعاً هر جمعه می‌کشید: کل تحویل‌ها، درصد به‌موقع، مسائلی که راننده‌ها علامت می‌زدند (مثل یک آدرس بد یا نبودن مشتری در خانه)، و یک مقایسه با هفتهٔ قبل. از سازنده خواست یک جدول خلاصه و یک نمودار میله‌ای ساده تولید کند. تولید کرد.

یک ردیاب مسائل ساده. وقتی یک راننده چیزی را علامت می‌زد — آدرس اشتباه، بستهٔ آسیب‌دیده، شکایت مشتری — باید جایی می‌رفت که مارتا بتواند ببیندش و اختصاصش دهد. نه یک سیستم تیکتینگ کامل. فقط یک فهرست با یک وضعیت (باز / در حال انجام / حل‌شده) و امکان اضافه کردن یک یادداشت.

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

۴۰٬۰۰۰ دلار واقعاً چه می‌خرید

وقتی مارتا اپ چهارصفحه‌ای‌اش را با پلتفرم سازمانی مقایسه کرد، فاصله واضح بود — اما نه در جهتی که انتظار داشت.

ابزار سازمانی صدها قابلیت داشت و برای پیکربندی به یک مشاور نیاز داشت. اپ مارتا چهار صفحه داشت که مستقیماً به شیوهٔ کار قبلی تیمش نگاشته می‌شدند. بدون نیاز به آموزش. بدون بدهی پیکربندی.

اما هزینهٔ واقعی ابزار سازمانی هرگز اشتراک نبود. اصطکاکی بود که تیمش هر روز دورش کار می‌کرد. دیسپچرها از طریق WhatsApp هماهنگ می‌کردند چون اپ موبایل پلتفرم برای به‌روز کردن وضعیت یک تحویل چهار ضربه می‌خواست. مارتا یک Google Sheet جداگانه برای گزارش هفتگی نگه می‌داشت چون ماژول گزارش‌دهی داخلی برای کشیدن همان پنج عدد به پیمایش سه منو نیاز داشت. راننده‌ها یک صفحهٔ راه‌حل دور زدن را در اسناد راهنما برای صفحهٔ ثبت مسیر نشانه‌گذاری کرده بودند چون جریان پیش‌فرض فازهای پروژه‌ای را فرض می‌کرد که استفاده نمی‌کردند.

اپ مارتا راه‌حل‌های دور زدن نداشت چون از روی همان راه‌حل‌های دور زدن ساخته شده بود. هر صفحه وجود داشت چون کسی در تیم آن کار را به‌طور غیررسمی انجام می‌داد — روی WhatsApp، روی یک صفحهٔ گسترده، روی یک تخته‌وایت — و مارتا فقط نسخهٔ غیررسمی را برای سازنده توصیف کرد.

بخش‌هایی که او را غافلگیر کردند

سه چیز که مارتا انتظارش را نداشت:

اصلاح سریع بود. وقتی یک راننده پیشنهاد اضافه کردن یک فیلد یادداشت به هر ایستگاه را داد، مارتا تغییر را در زمان ناهارش برای سازنده توصیف کرد و همان بعدازظهر منتشرش کرد. با ابزار سازمانی، تغییراتی مثل این از یک صف تیکت پشتیبانی می‌گذشت و گاهی هفته‌ها طول می‌کشید.

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

او مدام بهترش کرد. در دو هفتهٔ بعد، یک صفحهٔ پنجم اضافه کرد: یک نمای ماهانه برای رئیسش که روندهای تحویل و برآوردهای هزینه به‌ازای هر مسیر را نشان می‌داد. با ابزار سازمانی، این یک درخواست گزارش سفارشی می‌بود. با اپ خودش، یک گفت‌وگوی ۲۰ دقیقه‌ای با سازنده بود.

این چه چیزی نیست

این داستانی دربارهٔ بد بودن نرم‌افزار سازمانی نیست. اگر یک شرکت ۵۰۰ نفره هستید که پروژه‌های پیچیدهٔ بین‌بخشی با وابستگی‌ها، محدودیت‌های منابع و الزامات انطباق اجرا می‌کنید، احتمالاً به آن چاقوی ارتشی سوئیسی نیاز دارید.

اما اگر یک تیم ۳۰ نفره هستید که از ۱۵٪ یک ابزاری استفاده می‌کند که بیشتر از یکی از کارمندانتان هزینه دارد، چیزی ناجور است. ابزار مشکل نیست — عدم تطابق است.

و آن عدم تطابق زمانی اجتناب‌ناپذیر بود. پیش از اینکه بتوانید بدون کدنویسی یک اپ بسازید، انتخاب‌هایتان این بود: پول ابزار بزرگ را بدهید، چیزی را در صفحه‌های گسترده سرهم کنید، یا یک برنامه‌نویس برای ساختن نرم‌افزار سفارشی استخدام کنید (که هزینه و جدول زمانی خودش را می‌آورد). حالا یک گزینهٔ چهارم هست: آنچه نیاز دارید را توصیف کنید و خودتان بسازیدش.

محاسبه

اعداد مارتا بعد از یک ماه:

  • ابزار سازمانی: حدود ۳٬۳۰۰ دلار در ماه (۴۰ هزار دلار در سال)
  • اشتراک سازندهٔ اپ هوش مصنوعی: زیر ۱۰۰ دلار در ماه
  • زمان ساخت: ۸ ساعت (یک شنبه)
  • زمان اصلاح: ۲۰ تا ۳۰ دقیقه به‌ازای هر تغییر
  • زمان پذیرش تیم: صفر — روز اول گرفتندش

او به یک CTO یا یک تیم مهندسی نیاز نداشت. به این نیاز داشت که توصیف کند تیمش واقعاً چطور کار می‌کند — و به یک سازندهٔ اپ هوش مصنوعی که آن توصیف را به نرم‌افزار کارآمد تبدیل می‌کرد.

چیزی که باید درباره‌اش فکر کنید

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

اگر آن فهرست روی یک برگهٔ یادداشت‌چسبان جا می‌شود، شاید دارید بابت پیچیدگی‌ای که نیاز ندارید زیادی می‌پردازید.

لازم نیست جایگزین را در یک روز بسازید. می‌توانید فقط با یک صفحه شروع کنید — همانی که بیشترین اهمیت را دارد — و ببینید چه حسی دارد. هزینهٔ امتحان کردن چند ساعت است. هزینهٔ امتحان نکردن یک سال دیگر پرداخت بابت قابلیت‌هایی است که هرگز دستشان نمی‌زنید.

اگر می‌خواهید ببینید ساختن ابزار خودتان چه شکلی است، Proyecta را امتحان کنید و با چیزی شروع کنید که تیمتان بیشتر از همه از آن شکایت می‌کند.