رهبران فنی موفقیت را فراتر از پایداری سرویس چطور تعریف می‌کنند؟

یک فصل آرام می‌تواند نشان‌دهنده‌ی دو وضعیت کاملاً متفاوت در یک سازمان فناوری باشد.

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

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

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

سبد مشارکت‌های تیم را مشخص کنید

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

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

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

پس اولین وظیفه‌ی رهبر این است که ظرفیت را آگاهانه میان کارها تقسیم کند: چه چیزی باید حفظ شود؟ چه چیزی ارزش بهبود دارد؟ کدام توانمندی را باید در اختیار تیم‌های دیگر گذاشت؟ چه چیزی باید از چرخه‌ی کار خارج شود؟ و کدام ابهام ارزش بررسی کردن دارد؟

برای هر کار، یک توافق روشن درباره‌ی پیشرفت داشته باشید

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

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

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

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

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

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

حفاظت یعنی حفظ وضعیت مطلوب با تغییر شرایط

«سامانه را روشن نگه داریم» ممکن است کاری ثابت به نظر برسد، اما محیط کار ثابت نمی‌ماند.

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

پس حفاظت را به صورت وضعیتی تعریف کنید که باید در دل تغییر حفظ شود. مثلاً:

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

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

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

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

بهبود را در کل گردش‌کار بسنجید

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

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

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

• جریان کار: از شروع درخواست تا تحویل نتیجه‌ی پذیرفته‌شده چقدر زمان می‌گذرد؟
• کیفیت: نتیجه چقدر درست، کامل، امن و مناسب آن کار است؟
• بار انسانی: بررسی، اصلاح، ارجاع و هماهنگی چه مقدار وقت می‌گیرد؟
• هزینه: هر نتیجه‌ی موفق در مجموع چقدر تمام می‌شود، نه این‌که هر بار فراخوانی مدل چند است؟
• ماندگاری: چه کار تکراری‌ای واقعاً حذف شده و چه زحمت نگهداری تازه‌ای ساخته‌ایم؟
• تجربه: آیا کاربر مورد نظر می‌تواند کار را با اطمینان متناسب و نتیجه‌ی خوب به پایان برساند؟

پژوهش‌های تازه درباره‌ی مهندسی هوش مصنوعی این تفاوت را ملموس می‌کند. در مارس ۲۰۲۶، مؤسسه‌ی METR گزارش داد که پس از در نظر گرفتن خطای داوری، حدود نیمی از درخواست‌های تغییر کدِ ساخته‌شده با هوش مصنوعی که آزمون‌های خودکار را گذرانده بودند، از نظر نگه‌دارندگان مخزن پذیرفتنی نبودند. پژوهشگران محدودیت‌های این نتیجه را هم توضیح می‌دهند؛ از جمله این‌که بررسی فقط مجموعه‌ای از مخزن‌ها و شیوه‌ای ایستا برای مرور کد را دربرمی‌گرفت. اما یک نکته‌ی محدود و مهم روشن است: پاس کردن آزمون خودکار با تولید کدی که در یک پروژه‌ی واقعی بتوان از آن نگهداری کرد، یکی نیست. گزارش METR را بخوانید.

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

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

توانمندسازی را با کار تیم‌های دیگر بسنجید

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

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

برای هر سرمایه‌گذاری توانمندساز، این موارد را از قبل روشن کنید:

• قرار است کدام تیم‌ها از آن استفاده کنند؟
• چه گام دشواری را حذف می‌کند یا امن‌تر می‌سازد؟
• از پس کدام استثناها برنمی‌آید؟
• چه نشانه‌ای می‌گوید تیم‌های هدف واقعاً از آن استفاده می‌کنند؟
• چه کسی مالک پشتیبانی و ادامه‌ی حیاتش است؟
• اگر میزان استفاده پایین ماند، چه زمانی طراحی دوباره یا کنار گذاشته می‌شود؟

این کار جلوی راهبردِ «بساز تا شاید استفاده کنند» را می‌گیرد و در عین حال نمی‌گذارد اجبار، ظاهری از موفقیت بسازد. اگر تیم‌ها فقط چون راه‌های دیگر ممنوع است سراغ مسیر مشترک می‌روند، بررسی کنید آیا واقعاً زمان تحویل، بار ذهنی، مهندسی تکراری و ریسک عملیاتی کم شده است یا نه.

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

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

کنارگذاری و یادگیری را هم نتیجه‌ی واقعی بدانید

سازمان‌ها معمولاً در اعلام فناوری تازه خوب عمل می‌کنند، اما کمتر درباره‌ی پایان دادن به تعهدهای قدیمی حرف می‌زنند.

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

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

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

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

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

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

ترکیب کارها را مرور کنید، نه فقط موفقیت‌ها را

جلسه‌ی فصلی برای بررسی مشارکت‌های تیم نباید به مجموعه‌ای از داستان‌های موفقیت تبدیل شود. هدف این است که تعادل کارها را بسنجیم و درباره‌ی تقسیم ظرفیت بهتر تصمیم بگیریم.

در یک صفحه، پنج ردیف برای حفاظت، بهبود، توانمندسازی، کنارگذاری و یادگیری بگذارید. برای هر ردیف چهار سؤال را جواب دهید:

• برای کاربر، سازمان یا سامانه چه چیزی تغییر کرد؟
• چه شواهدی ادعا را پشتیبانی می‌کند و چه بخشی را نمی‌توان با اطمینان به این کار نسبت داد؟
• این کار چقدر از ظرفیت تیم و فرصت‌های دیگر را مصرف کرد؟
• قدم بعدی چیست؟

بعد به خانه‌های خالی نگاه کنید.

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

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

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

پایدار ماندن با ساکن ماندن فرق دارد

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

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

این‌ها شکل‌های متفاوتی از مشارکت‌اند و سازمان فنیِ جدی به همه‌شان نیاز دارد.

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