رشد شرکت

در نقطه‌ای از رشد شرکت، ممکن است تعدادی از رویدادها یا تراکنش‌های زیر رخ دهد:

• توسط شرکت دیگری تملک شوید
• توسط یک گروه سرمایه‌گذاری خصوصی یا سرمایه‌گذاری تملک شوید یا شرکت کوچک‌تری را بخرید
• با شرکت دیگری ادغام شوید

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

۱۴.۱ گروه‌های سرمایه‌گذاری

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

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

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

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

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

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

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

۱۴.۲ ارائه ناگهانی

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

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

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

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

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

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

۱۴.۴ آماده شدن برای یکپارچه‌سازی

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

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

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

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

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

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

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

این فرایند را

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

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

۱۴.۵.۱ انجام بررسی موشکافانه

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

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

همین ذهنیت هنگام ارزیابی فناوری یک شرکت کامل به کار می‌رود؛ فقط کمی درگیرتر است، اما پیچیده‌تر نیست. شما فناورید و در کار حل مسئله هستید. بیشتر چیزهایی که با آن‌ها روبه‌رو می‌شوید یا Coca-Cola و Pepsi هستند، یعنی غلط نیستند، فقط متفاوت‌اند، یا آن‌قدر کوچک‌اند که به‌سادگی حل می‌شوند. به همین دلیل شما، نه یک همکار در شرکت حسابداری، بهترین جایگاه را برای انجام این کار دارید. می‌توانید این مسائل را سریع ببینید و زمان را برای تمرکز بر حوزه‌هایی آزاد کنید که ممکن است مشکل‌ساز شوند.

قرار است حوزه‌های بزرگی را مرور کنیم که به کاوش عمیق‌تر نیاز دارند. هنگام انجام تحلیل، در نظر داشته باشید هر مشکل یا مسئله‌ای که آشکار شود

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

استک فناوری

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

حقوق مالکیت فکری (IPR)

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

داده

داده چگونه ذخیره و استفاده می‌شود؟ چه مقدار نگهداری می‌شود و برای تحلیل در دسترس است؟ تولیدکنندگان و مصرف‌کنندگان اصلی چه کسانی‌اند؟ مالک داده کیست و چه محدودیت‌هایی، اگر وجود دارد، بر استفاده از آن حاکم است؟ داده در چه حوزه‌های قضایی قرار می‌گیرد، آیا GDPR مرتبط است، و آیا داده حساسی وجود دارد که زیر انطباق قرار بگیرد، مانند PII، PCI یا HIPAA؟

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

پشتیبانی

معمولا چه مسائلی توسط کاربران یا مشتریان سیستم‌هایی که نگهداری می‌شوند گزارش می‌شود؟ چه مقدار زمان صرف پشتیبانی در برابر توسعه ویژگی‌های جدید می‌شود؟

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

امنیت

نگرش عمومی نسبت به امنیت چیست؟ آخرین بار چه زمانی گذرواژه‌های اصلی چرخانده شدند؟ یک توسعه‌دهنده چقدر دید دارد؟ آیا محیط تولید جدا از محیط توسعه وجود دارد؟

اگر اعتبارنامه‌های کاربران ذخیره می‌شود، گذرواژه‌ها در پایگاه داده چگونه ذخیره می‌شوند؛ متن ساده در برابر نمک‌گذاری‌شده؟ از اینکه هنوز چه تعداد گذرواژه‌ها را به‌صورت متن آشکار ذخیره می‌کنند شگفت‌زده خواهید شد! چه آزمون‌هایی روی محیط‌های تولید اجرا شده، چه تزریق SQL چه تست‌های نفوذ؟ امنیت چیزی است که شرکت یا از ابتدا در آن می‌سازد یا

بعدتر روی آن لایه می‌کند؛ حالت دوم در حالت ایده‌آل چیزی نیست که بخواهید ببینید.

کد منبع

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

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

حوزه‌های دیگری که باید نگاه کنید حول امنیت است. ببینید پیکربندی، نام‌های کاربری و گذرواژه‌ها در کد چگونه مدیریت می‌شوند. اگر زیرساخت به‌شدت توسط APIها تغذیه می‌شود، نگاه کنید چگونه ساخته شده‌اند؛ آیا سازگاری وجود دارد؟ خطاها و استثناها چگونه مدیریت می‌شوند؟ آیا فرض زیادی وجود دارد که چیزها خراب نمی‌شوند، یا در سراسر کد بررسی کافی انجام می‌شود؟

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

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

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

سیستم تولید

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

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

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

در بخشی از این حوزه، تأیید کنید چه کسی مسئول پرداخت و تمدید سرویس‌هاست. غیرمعمول نیست، به‌ویژه در شرکت‌های کوچک‌تر، که سرویس‌های رایجی مانند حساب‌های AWS، GitHub یا GoDaddy صرفا به این دلیل که کارت اعتباری توسعه‌دهنده اصلی هر ماه شارژ می‌شود و بعد با فرم هزینه بازپرداخت می‌شود، «مالکیت» او محسوب شوند.

بیشتر این‌ها، همان‌طور که در این کتاب مرور کرده‌ایم، مشکلاتی برای حل کردن‌اند؛ اما قانونی بودن چنین حساب‌های اصلی از نظر مالکیت باید پیش از تکمیل هر تراکنشی شناسایی و حل شود.

۱۴.۵.۲ هدایت بررسی موشکافانه

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

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

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

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

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

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

۱۴.۵.۳ ارائه یافته‌ها

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

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

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

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

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

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

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

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

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

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

۱ نمای کلی هدف

۲ روش‌شناسی: چه زمانی انجام شد، چه کسی حاضر بود، چه موادی

ارائه شد، چه چیزی در دسترس نبود

۳ خلاصه یافته‌ها

۴ مواد پشتیبان

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

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

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

۱۴.۵.۴ پاسخ دادن به بررسی موشکافانه

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

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

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

لازم نیست صفحه‌ها سند بسازید، اما باید بتوانید موارد زیر را بدون مشکل زیادی تولید کنید:

• نمودارهای سطح‌بالای معماری/شبکه، فهرست همه فناوری‌ها، شامل نسخه‌ها، و مجوزها، تاریخ‌های تمدید و هزینه‌ها
• چارت سازمانی با نام همه افراد
• سند آشناسازی کارمند جدید و مسائل پشتیبانی اخیر
• اولویت‌های توسعه آینده

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

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

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

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

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

زیرساخت هم همین‌طور است. اگر محیط ابری دارید، بازبینی آن در دستور کار خواهد بود. اقدام کنید تا کسی حساب خاص فقط‌خواندنی بسازد که دید کافی برای نگاه کردن بدهد، بدون ترس از تغییر دادن چیزی.

۱۴.۶ واگذاری زمام امور

در نقطه‌ای از مسیر حرفه‌ای خود، مسئولیت‌ها را به فردی تازه واگذار خواهید کرد. دلایل این کار می‌تواند زیاد باشد، مانند بزرگ‌تر شدن شما از نقش، یا دیگر هم‌راستا نبودن نقش با کاری که می‌خواهید انجام دهید. دلیل دیگر، مرتبط با این فصل، تملک شدن است، وقتی جایی برای دو CTO وجود ندارد. مانند فیلم کلاسیک دهه ۸۰ Highlander، فقط یکی می‌تواند وجود داشته باشد.

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

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

سروکار داشتید. همین محدودیت‌ها باید به CTO جدید منتقل و با او به اشتراک گذاشته شوند. این دلایل دانش تجاری ارزشمندی‌اند که حتی باهوش‌ترین CTO هم نخواهد دانست.

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

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

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

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

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

۱۴.۷ تحویل گرفتن زمام امور

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

چیزهای زیادی باید درباره شرکت بیاموزید، پس برای آشنا شدن با شرکت، محصول، مشتریان و کارکنان وقت بگذارید. هیچ‌کس واقعا در ۳۰ روز اول انتظاری از شما ندارد، و ۹۰ روز زمان دارید پیش از آنکه هر نوع چشم‌اندازی شروع به شکل گرفتن کند.

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

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

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

Charles Moon، که در سازمان‌های زیادی به‌عنوان CTO/رئیس R&D خدمت کرده، بهترین بیان را دارد: «درباره سیاست داخلی سنجیده باشید، چون ممکن است اطراف شما کسانی باشند که از نقشه‌راه فناوری قبلی حمایت می‌کردند. بیشتر تغییرها باید به‌عنوان بهبودهای مثبت ناشی از پیشرفت فناوری/بازار مدیریت شوند.»

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

جمع‌بندی

• تملک شدن اگر درست مدیریت نشود می‌تواند حواس‌پرتی بزرگی باشد.
• خرید یک شرکت کوچک‌تر اگر بتوانید پیشنهاد آن‌ها را هرچه سریع‌تر

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

• ساختن معماری‌ای که یکپارچه‌سازی را آسان می‌کند، شرکت شما را

برای گفت‌وگوهای راهبردی‌تر باز می‌کند.

• بررسی موشکافانه بازجویی نیست، بلکه گفت‌وگویی است که پیرامون هدفی

مشخص طراحی شده است.

• زمینه‌مند کردن نتایج در زبانی که افراد غیر فنی بتوانند

پردازش کنند، امکان تصمیم‌گیری‌های راهبردی سطح‌بالا را فراهم می‌کند.

• تحویل گرفتن از یک CTO موجود بیشتر درباره گوش دادن و آموختن

دشواری‌ها و چالش‌های اوست، نه تغییر دادن همه چیز.

• هنگام واگذاری زمام امور به CTO دیگر، مهم است همه را،

از جمله تیم خود را، برای موفقیت آماده کنید.

چک‌لیست

چند مورد از موارد زیر را می‌توانید ادعا کنید که پوشش داده‌اید؟

• می‌توانید بدون اطلاع قبلی تصویری واقع‌بینانه اما خوش‌بینانه از سازمان خود ارائه کنید و احتمال اینکه بخشی از یک رویداد تراکنشی باشید را می‌دانید

• آماده‌اید دست‌کم بررسی موشکافانه حداقلی را طی کنید
• قوت‌های معماری را می‌فهمید اما نسبت به حوزه‌هایی که

به کار بیشتری نیاز دارند ناآگاه نیستید

• می‌توانید یک CTO جدید را از فرایندهایی عبور دهید که به برخی تصمیم‌ها منجر شده‌اند