صورت‌بندی مسئله
پیش از راه‌حل، مسئله را از سه زاویه می‌خوانم: جهت سازمان، محدودیت‌های واقعی و شکاف توانمندی.
شیوه رهبری
از مسئله سخت تا توانمندی قابل اتکا.
رهبری فناوری برای من یعنی تبدیل ابهام به تصمیم، تصمیم به معماری، معماری به مالکیت، و اجرا به شواهد.
- Strategy
- People
- Architecture
- Execution
- Evidence
قطب‌نمای تصمیم
شش پرسش که پیش از هر تصمیم مهم می‌پرسم.
مدل تصمیم
ساختن، یکپارچه‌کردن، حذف یا تعویق؛ هر انتخاب باید مالک و پیامد روشن داشته باشد.
مدل معماری
پیش از کشیدن نمودار اجزا: اختیار با کیست، داده کجاست، مرزها و وابستگی‌ها چیست و مسیر بازیابی کدام است.
مدل اجرا
کار بادوام، خواندن وضعیت از سیستم واقعی و راستی‌آزمایی؛ به‌جای اعلام موفقیت از روی نیت.
مدل تیم
شفافیت، مالکیت، استقلال و پاسخ‌گویی برای رشد رهبری فنی.
ارزیابی فناوری
سودمندی، بلوغ، پیامد عملیاتی، برگشت‌پذیری و باز ماندن گزینه‌ها.
استراتژی فناوری
استراتژی فناوری، بخشی از استراتژی سازمان است.
نقشه فناوری را از فهرست ابزارها شروع نمی‌کنم. اول جهت سازمان، محدودیت‌های واقعی و شکاف توانمندی را روشن می‌کنم؛ سپس تصمیم Build / Buy / Integrate، معماری، مالکیت و مدل عملیاتی را تا اجرا و شواهد runtime وصل می‌کنم.
- Organization Direction
- Constraints & Risks
- Capability Gaps
- Build / Buy / Integrate
- Architecture & Ownership
- People & Operating Model
- Execution
- Runtime Evidence
- Next Strategy Cycle
قضاوت پیش از ابزار
پیش از انتخاب فناوری، تصمیم را از چهار دروازه عبور می‌دهم.
این دروازه‌ها گفتگو را از مقایسه قابلیت‌ها به پیامدهای واقعی سازمانی و عملیاتی برمی‌گردانند.
Build / Integrate / Remove / Defer
هر گزینه باید استدلال مالکیت و پیامد داشته باشد؛ ساختن، پاسخ پیش‌فرض نیست.
Authority / State / Boundary
پیش از دیاگرام اجزا، authority و مالکیت state باید روشن باشد.
Failure / Recovery / Reversibility
طرحی که فقط مسیر موفق را توضیح می‌دهد، هنوز طرح عملیاتی نیست.
People / Decision Capacity
معماری باید تصمیم بهتر را در تیم توزیع کند، نه اینکه همه چیز را متمرکز کند.
حلقه عملیاتی
کار با deploy شدن تمام نمی‌شود.
هر تصمیم مهم باید از صورت‌بندی تا verification و یادگیری یک حلقه کامل داشته باشد. اگر شواهد برنگردد، استراتژی بعدی هم از واقعیت تغذیه نمی‌شود.
- Frame
- Decide
- Architect
- Enable People
- Execute
- Verify
- Learn
آدم‌ها به‌عنوان سیستم
هدف، قهرمان بودن CTO نیست؛ ساختن ظرفیت تصمیم در سازمان است.
Context، مرز و پاسخ‌گویی را طوری طراحی می‌کنم که تصمیم‌های خوب نزدیک‌تر به مسئله گرفته شوند.
- Contextمسئله و دلیلش برای همه روشن است.
- Ownershipهر دامنه و تصمیم، مالک مشخص دارد.
- Decision Frameworkاصل‌ها جای سلیقه را در تصمیم می‌گیرند.
- Autonomyتصمیم نزدیک به مسئله گرفته می‌شود.
- Accountabilityنتیجه با شواهد سنجیده و بازخورد می‌شود.
از فناوری تا توانمندی
زیرساخت وقتی ارزشمند می‌شود که به توانمندی قابل استفاده تبدیل شود.
سرور، شبکه، Kubernetes، دیتابیس یا AI به‌تنهایی اهرم نیستند. اهرم از authority، lifecycle، workflow، policy، بازیابی و تجربه استفاده ساخته می‌شود.
- قابلیت فنی خامCloud · Network · Compute · Storage · Kubernetes · Data · DNS · Mail · AI · Telemetry
- Product SystemAuthority · Source of Truth · API · Workflow · Policy · Automation · UX · Evidence · Recovery
- قابلیت سازمانیSelf-Service · Repeatability · Reliability · Governance · Safer Change · New Service Capability
ارزیابی فناوری
فناوری را با آینده‌ای که به ما تحمیل می‌کند می‌سنجم.
ابزار جذاب می‌تواند پیچیدگی و وابستگی پنهان بسازد. ارزیابی باید نتیجه، عملیات و راه خروج را هم ببیند.
Usefulness
آیا یک محدودیت واقعی را حل می‌کند؟
Maturity
چه چیزهایی هنوز آزمایشی‌اند؟
Boundary
کجا یکپارچه می‌شود و کجا مالکیت عوض می‌شود؟
Operations
هزینه روز دوم و بازیابی چیست؟
Reversibility
اگر انتخاب اشتباه بود، راه برگشت چقدر روشن است؟
Optionality
آیا تصمیم امروز حرکت بعدی را بی‌دلیل می‌بندد؟
برای چه بهینه می‌کنم
اصل‌ها پیش از ابزارها.
وضوح به‌جای پیچیدگی تصادفی
مرز responsibility، authority و failure باید برای تیم قابل توضیح باشد.
Capability به‌جای وابستگی
هدف، ساخت توان ماندگار سازمان است؛ نه ایجاد وابستگی بیشتر به فرد، vendor یا مسیر دستی.
Evidence به‌جای assumption
Status و تصمیم مهم باید تا حد ممکن به مشاهده و post-condition متصل باشند.
استقلال تیم به‌جای heroics
سیستم و سازمان خوب نباید برای هر تصمیم مهم به یک فرد قهرمان وابسته بمانند.
Recovery به‌جای طراحی فقط برای مسیر موفق
Failure رخ می‌دهد؛ کیفیت معماری در تشخیص، containment، recovery و بازگشت امن هم سنجیده می‌شود.
Optionality به‌جای lock-in زودهنگام
برای آینده prediction نمی‌کنم؛ boundaryهایی می‌سازم که تغییر بعدی را ممکن نگه دارند.
تجربه محصول به‌جای نمایش ابزار
پیچیدگی زیرساخت باید در workflow درست پنهان شود، بدون اینکه واقعیت عملیاتی یا failure را جعل کند.
آینده‌نگری
امروز را بساز؛ optionهای فردا را باز نگه دار.
آینده‌نگری برای من prediction نیست؛ ساختن architecture، team capability و boundaryهایی است که تغییر بعدی را بدون بازطراحی کامل ممکن نگه می‌دارند.
- NOW
حل محدودیت واقعی امروز
- NEXT
ساخت توانمندی بعدی
- LATER
باز نگه داشتن گزینه‌های آینده
شروع گفتگو
اگر فناوری باید سازمان شما را جلو ببرد، نه اینکه پشت سرش بماند، صحبت کنیم.
گفتگوی اول درباره مسئله شماست، نه درباره من: کجا گیر کرده‌اید، چه چیزی در خطر است و آیا من آدم درستِ حل آن هستم.
مسئله را مطرح کنید