پیچیدگی‌های الکی

Photo by Tony on Unsplashزندگی پیچیده است. آدم‌ها پیچیده هستند. اقتصاد پیچیده است. ساخت یک محصول دیجیتال پیچیده است. حالا این پیچیدگی‌ها را باهم ترکیب کنیم. اسم‌ش را بگذاریم بیزینس آنلاین. ترکیب چند تا چیز پیچیده باهم می‌‌شه یک سیستم خیلی پیچیده. کی می‌تونه از یکی سیستم خیلی پیچیده که هیچ کس از اجزائش سر درنمیاره انتظار سرویس خوب داشته باشه؟ هیچ کس. اصلا چطور می‌شه مدیریت‌ش کرد و محصول و سرویس خوب ارائه کرد؟یک قدم بیایم عقب. مشکل مدیریت پیچیدگی نیست. مشکل اضافه شدن پیچیدگی در طول زمانه. لیست زیر چیزهایی هستند که ساخت یک سرویس آنلاین خوب را دچار پیچیدگی بیشتر می‌کنند. ازشون دور بشید تا زندگی راحت‌تری داشته باشید.مشاورها و مربی‌ها مشکلات بیزینس یکتا هستند. یعنی راه حل مشکل تپسی برای اسنپ کار نخواهد کرد. در ضمن هیچ راه حل یک مرحله‌ای و نهایی هم وجود نداره. مشکلات باید فهمیده بشن، حس بشن، باید درد داشته باشند و دردش را همه‌ی تیم حس کنند. بعد می‌تونید راه حل‌ها را تست کنید و مرحله به مرحله بهبود را چک کنید. باید راه‌های مختلف را تست کنید تا به بهترین راه حل که بخش عمده‌ای از مشکل را حل می‌کند برسید.این مسیر قابل دور زدن نیست. میان بر ندارد. آدم‌هایی هستند که ادعا می‌کنند این مسیر را قبلا طی کردن و به شما توهم دانایی و اعتماد به نفس می‌دن. در عمل ولی اضافه کردن صدای جدید که حتی مشکل را هم متوجه نشده (چطور می‌تونه متوجه بشه وقتی جزئی از تیم نیست و حتی خود تیم مشکل را نمی‌دونه؟) باعث چند صدایی و پیچیدگی خواهد شد. در ضمن هزینه‌ی آموزش پیدا کردن مشکل/راه‌حل را هم پرداخت نکردیم و در آینده به شکل بدتری خودش را نشون خواهد داد. مشاوره بد نیست. مشاوره مثل یکی از نتایج جستجوی گوگل می‌مونه. چون تعداد زیادی کلیک گرفته بیشتر دیده میشه. آیا دوست دارید در جواب یک مشکل همیشه سراغ بالاترین لینک برید یا این‌که بلد بشید چطور باید در گوگل جستجو کنید؟ لقب‌هاآقای اصغر مدیریت تیم مهندسی بخش فرانت اند زیر مجموعه اپ زیر دسته‌ی سرچ را به عهده دارند. خانم فاطی مسئول ارشد ارتباط تیم زیرساخت با تیم مشتریان بیرونی سازمان هستند.القاب معمولا برای خوشحال کردن کارمندها به وجود میان. یا ایجاد حس ارباب و رعیتی. یا برای دادن حقوق کمتر یا بیشتر بدون دلیل منطقی. لقب‌ها باعث می‌شند خروجی وابسته به آدم‌های مختلف بشه: چرا برای رفع یک باگ معمولی در یک اپ احتیاج به چهار نفر باید داشته باشید؟ یک نفر در بخش بک‌اند وب‌سرویس را تغییر بده، یک نفر در بخش فرانت‌اند اپ را تغییر بده، یک نفر در بخش تست، تست کنه و یک نفر در بخش دوآپس تغییرات را دیپلوی کند و بعد احتمالا یک نفر از بخش سرویس تلفنی به یک نفر دیگه در بخش محصول خبر بده که باگ هنوز در یک حالت خاص وجود داره. تعجبی نداره چرا انقدر محصولات پر باگی داریم.یک نفر داریم که میتونه ایده‌ها را تبدیل به زبان کامپیوتر کنه. بهش میگیم دولوپر یا توسعه دهنده. یک نفر هم داریم که میتونه زبان و نیاز مشتری را متوجه بشه و به زبان اینترفیس ماشین تبدیل‌ش کنه. به این دومی هم میگیم دیزاینر. باقی القاب مثل بک‌اند دولوپر، فرانت‌اند ری‌اکت دولوپر (اپ نه فقط برازر) دیزاینر تجربه مشتری، طراح محصول (نه یو آی) اشتباه هستند. باعث می‌شند توانایی و دانش آدم‌ها محصور در این لقب بمونند. محرمانگیمیزان حقوق را حق ندارید به همکاران‌تون بگید. برای دیدن میزان فروش ایمیل بزنید. یو اس بی درایور کامپیوترها بسته است چون احتمال داره کسی بخواد اطلاعات ما رو بدزده. محرمانگی یکی از کشنده‌ترین پیچیدگی‌ها را به تیم تحمیل می‌کنه. هم در لایه‌ی کاری و تولید ارزش شما را به شدت کند می‌کنه و هم در لایه‌ی انسانی باعث شک و شایعه و سوتفاهم می‌شه. و اغلب این محرمانگی از کجا میاد؟ پاسخ‌گو نبودن مدیریت به تیم. و نکته‌ی خنده‌دار اینجاست که یکی از کارهای پرهزینه مدیریت، مدیریت کردن همین محرمانگی‌ها و ساید افکت‌های این تصمیمه. حقوق‌ها را پابلیک کنید. چرا همین الان پابلیک نیست؟ احتمالا چون مدیریت نمی‌تونه اعتراف کنه به اکبر بیشتر از اصغر پول دادم چون بهتر چونه می‌زد. اگر نگران سوال اصغر هستید، به جای مخفی کردن به یک ساز و کار عادلانه فکر کنید.محصول دیجیتال‌تون ممکننه دزدیده بشه؟ کدها به خودی خود ارزشی ندارند. همین الان کدهای دیجیکلا یا کافه‌بازار یا علی بابا لو بره. به چه دردی خواهند خورد؟ مطلقا به هیچ دردی.میزان فروش و سود و ضرر را همه نباید بدونند؟ چرا؟ احتمالا چون ممکنه فکر کنند من کم حقوق می‌گیریم یا وضع شرکت خوب نیست یا هرچیزی. مخفی کردن اعداد این سوال‌ها را از بین نمی‌بره. بهشون دامن می‌زنه.دپارتمان‌ها و تیم‌ها و ساختارتیم‌ها باید حول نیاز مشتری شکل بگیرند نه حول فلان تئوری یا حول نیاز مدیریت. چطور تشخیص بدیم ساختار غلطی داریم؟ اگر برای انجام یک کار باید خروجی از یک تیم به تیم دیگه داده بشه به احتمال زیاد تیم برای دلیور کردن ارزش به مشتری شکل نگرفته. برای مثال:خروجی تکمیل شده و نهایی از تیم طراحی برای پیاده سازی در تیم فنیمحصول تغییر کرده از طرف تیم فنی به تیم تیم تست برای تستمحصول تست شده به تیم دوآپس برای دیپلوی به سایتزنجیره خدمات مشکلی نداره. مشکل وقتی بوجود میاد که چرخه فیدبک قطع میشه یا جایی بین این تیم‌ها گم میشه. در ساخت محصول دیجیتال محصولی داخلی به عنوان تمام شده نمی‌تونیم داشته باشیم. مثلاً طراحی تکمیل شده به عنوان یک محصول برای ارائه به تیم فنی نمی‌تونه وجود داشته باشه. یا کد به عنوان یک محصول برای ارائه به تیم سیستم ادمین. این محصولات داخلی باید آنقدر در رفت و برگشت باشند که عملا مرزی بین تیم‌ها باقی نمونه.برنامه‌ریزیبرنامه‌ریزی میان مدت و بلندمدت ساخت یک محصول دیجیتال و پایبند موندن بهش خواب و خیاله. اگر بار اولی‌ست که شروع به ساخت یک ویژگی یا رفع یک باگ جدید کردید، به احتمال زیاد تخمین اصلا ممکن نیست. وقتی نمی‌تونیم تخمین برنیم یعنی برنامه‌ریزی هم نمی‌تونیم بکنیم. بنابراین فشار آوردن به تیم برای اعلام یک تاریخ (ددلاین) باعث تعهد به یک تاریخ الکی خواهد شد.چه کار کنیم؟ یک لیست درست کنیم و کارها را بر اساس ارزش سورت کنیم. یک باگ مهم که سرویس ما رو مختل کرده به بالای این لیست میره. اصلا مهم نیست چقدر زمان میبره و چه تخمینی برای انجام‌ش زده میشه. باید حل بشه. مورد دوم میتونه یک ویژگی باشه که درخواست زیادی براش وجود داره ولی در توضیح‌ش یادداشت می‌کنیم نمی‌خوایم بیشتر از دو هفته بابت‌ این کار وقت بگذاریم. هر هفته یک ربع این لیست را با تیم برسی میکنیم تا مطمئن بشیم همه طبق یک لیست ارزش مشغول کاریم. این مثال ساده سازی شده. برای این اینجا آمده که نشون بدم در مقابل روش سنتی برنامه‌ریزی کلاسیک و گان چارت و گزارش‌دهی و غیره، چه راهی باید پیش بگیرید. درباره‌ش بخونید و راه خودتون را پیدا کنید. وگرنه دچار پیچیدگی کلاسیک تعاریف برنامه ریزی و جابجایی نیروها خواهید شد. عالمان بی عملشامل کسانی میشه که معمولا عنوان سنیور را یدک می‌کشند و به جای حل مشکلات پیش پا افتاده فعلی دوست دارند روی مشکلات تخیلی آینده کار کنند. مثلاً سنیور دولوپری که مدام درباره اسکیل نشدن محصول برای کاربران آینده حرف میزنه. به جای این‌که متعهد به رفع باگ یک اشکال سی اس اس ساده ولی موثر بکلاگ باشه. یا دیزاینری که با تمام ترندهای اساسی طراحی آشناست و هر از چند وقتی پیشنهاد ریدزاین محصول را میده. در حالی ‌که در وضع فعلی کاربر به خاطر دیزاین اشتباه حتی نمی‌تونه ساده‌ترین کارها را انجام بده. نمونه‌ی این یکی به وفور پیدا میشه، اپ‌های بزک دوزک شده‌ی بی‌مصرف. یا مدیرعاملی که به فکر تغییر ساختاری تیم‌هاست وقتی حتی سرویس که بیزینس ارائه میده کوچکترین ارزشی ایجاد نمی‌کنه.قدم‌های بلند مثل استخدام افراد خیلی حرفه‌ای با فرهنگ متفاوت و یا تغییر اساسی پلتفورم معمولا با امید پشت سرگذاشتن پیچیدگی‌های کوچک برداشته می‌شن. ولی این پیچیدگی‌های کوچک به دلیل نیاز بیزینس متولد شدند، نمی‌تونید با یک شروع متفاوت نیازهای قبلی را محو کنید. خلق پیوسته و آهسته‌ی ارزش برای کاربر با قدم‌های بزرگ یا قهرمان‌های تکی به دست نمیاد. --نکته‌ی آخر، تیم شما بهترین تصمیم‌گیرنده برای بیزینس شماست. میزان رضایت کاربر هم بهترین نشان دهنده‌ی سلامت بیزینس. فرهنگی را ترویج کنید که آدم‌ها به راحتی بتوانند به همه‌چی دسترسی داشته باشند و بدون ترس اشتباه کنند. باقی چیزها خود به خود درست خواهند شد.