تصمیمهای فناوری وقتی محکم میشوند که قضاوت متخصص زودتر وارد فرآیند شود، مالکیت تصمیم شفاف بماند و مسیر ارجاع قاعدهی نوشته داشته باشد.
بیشتر تصمیمهای بد فنی که دیدهام، نتیجهی کمسوادی نبوده؛ نتیجهی دیرآمدن آدم درست بوده است. معماری در جلسهای بسته میشود که کسی از تیم داده در آن نیست، و سه ماه بعد همان تیم باید با آن زندگی کند.
راهحل، جلسهی بیشتر نیست. چیزی که کار میکند یک شبکه است: مسیرهای مشخصی که یک تصمیم پیش از قطعیشدن از آنها عبور میکند، با نامهای واقعی و مهلتهای واقعی.
سه حرکتی که ترتیبشان مهم است
- قضاوت متخصص را زود وارد کنید
پیش از نوشتن سند، از هر حوزهی متأثر یک نفر را بخواهید فقط یک سؤال بپرسد. نظرِ زود، بازنویسیِ دیر را حذف میکند.
- مالکیت را شفاف بنویسید
یک نام برای تصمیمگیرنده، فهرست مشورتشوندگان، و تاریخ. «تیم تصمیم گرفت» یعنی هیچکس تصمیم نگرفته است.
- مسیر ارجاع را از قبل تعریف کنید
اگر تا مهلت به توافق نرسیدید، چه کسی گره را باز میکند و با چه معیاری؟ این جمله را قبل از اختلاف بنویسید، نه در میانهی آن.
چطور بفهمیم کار میکند
- تعداد تصمیمهایی که بعد از تصویب دوباره باز میشوند، کم میشود.
- مخالفتها زودتر و در سند ظاهر میشوند، نه دیرتر و در راهرو.
- تازهواردها میتوانند بپرسند «چرا اینطور؟» و پاسخ نوشتهای پیدا کنند.
شبکهی تصمیمگیری یک نمودار سازمانی تازه نیست؛ عادتی است که هر بار کمی زمان میگیرد و ماهها دوبارهکاری را حذف میکند.
دانشمند ارشد داده · مهندسی داده و هوش مصنوعی — دربارهی پروژهها، تجربهها و یادداشتهای خودم مینویسم.