چگونه یک ابزار داخلی بسازیم که تیم واقعاً از آن استفاده کند، بدون انتظار برای تیم مهندسی

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

این راهنما برای چه کسانی است

تیم‌های عملیات، مدیران دفتر، بنیان‌گذاران و کسب‌وکارهای در حال رشد که فرایندی حیاتی را با گام‌های دستی، پیام‌های چت و اتکا به حافظه اداره می‌کنند.

در پایان چه خواهید داشت

- راهی برای تشخیص اینکه کدام فرایند دستی واقعاً به ابزار نیاز دارد

- مسیر ساختی از یک روند آشفته تا نرم‌افزاری که مردم به آن اعتماد کنند

- ابزاری داخلی که مالکش هستید و می‌توانید تغییرش دهید، نه یک قلم دیگر در فهرست انتظار

هر کسب‌وکار در حال رشد بر چند فرایند می‌گردد که هیچ‌جا خانه ندارند: تأییدی که در چت انجام می‌شود، تحویل کاری که در ذهن کسی ثبت شده، و وضعیتی که همه درباره‌اش می‌پرسند چون هیچ‌جا نوشته نشده است. ابزارهای داخلی برای همین‌اند. دلیل ساخته‌شدن اندک آن‌ها دیگر هزینه نیست؛ این است که هرگز از فهرست انتظار تیم مهندسی بالاتر نرفته‌اند. این راهنما درباره‌ی ساختن ابزار درست به‌دست خودتان است، تا واقعاً ساخته شود.

کدام فرایند واقعاً به یک ابزار داخلی نیاز دارد؟

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

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

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

چرا بیشتر ابزارهای داخلی رها می‌شوند؟

ابزارهای داخلی به دلایلی پیش‌بینی‌پذیر شکست می‌خورند، و دانستن این دلایل از پیش، بخش بزرگی از چیزی است که ابزار شما را زنده نگه می‌دارد.

آزمون پذیرش

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

مسیر ساخت از آشفتگی دستی تا نرم‌افزار چیست؟

گذر از فرایندِ درونِ ذهن آدم‌ها به یک ابزار، توالی قابل‌اعتمادی را دنبال می‌کند. پریدن از گام نخست همان دلیلی است که چرا این‌همه ابزار مسئله‌ی نادرست را حل می‌کنند.

یک ابزار داخلی واقعی، با دامنه‌ی مشخص

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

چطور نگذاریم به یک ابزار مرده‌ی دیگر بدل شود؟

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

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

خلاصه‌ی کوتاه

پرسش‌های متداول

چطور بدانم اول کدام ابزار داخلی را بسازم؟

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

چرا ابزارهای داخلی این‌قدر رها می‌شوند؟

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

نسخه‌ی اول یک ابزار داخلی باید شامل چه باشد؟

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

آیا برای ساختن یک ابزار داخلی به توسعه‌دهنده نیاز دارم؟

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