وقتی تو استارت‌آپ‌ها و شرکت‌های مختلف، از کارمندان درباره‌ی مدیر ارشد فناوری یا به اختصار CTO (Chief Technology Officer) می‌پرسیم، معمولا میگن: “آهان! همونی که فقط پول می‌گیره تا یک گوشه بشینه و روی فناوری و تکنولوژی فکر کنه.” یا “همون کسی که دقیقه 90 یهو تصمیم می‌گیره بپره وسط پروژه من و بگه کلا باید عوض بشه”. از این دست تعریف‌ها از مدیران فناوری زیاد میشه اما چیزی که از مجموعه‌ی این نظرات بر میاد اینه که: هیچ تعریف مشخص و دقیقی از شغل مدیریت ارشد فناوری و وظایفش وجود نداره.

در این مطلب می‌خوایم درباره‌ی این نقش صحبت کنیم و یک دسته‌بندی نسبتا خوب از وظایف CTO ارائه بدیم.

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

یکی از نقش‌هایی که در شرکت‌ها وجود داره و بسیاری، اون رو با CTO اشتباه می‌گیرن، معاونت مهندسی یا VP Engineering (Vice President of Engineering) هست. وظایف معاونت مهندسی بیشتر شامل مدیریت بخش‌ها و افراد فنی میشه. با این که کارهای مدیریتی رو گردن معاونت مهندسی می‌اندازن، اما CTO وقتی در کارش جلو میره، کم‌کم به یک مشکل اساسی بر می‌خوره. مشکل اینه که به تدریج دیگه نمی‌تونه ساختار کلی نرم‌افزار رو (که تعیین کردنش یک کار مدیریتی محسوب میشه) از نحوه ساخت اون (که وظیفه‌ی CTO هست) جدا کنه.

فرض کنید می‌خواید یک سری اصول و چارچوب‌های کلی طراحی کنید که در اون، چابکی و مهارت افراد به اوج خودش برسه و بتونن بیشترین توان خودشون رو بکار بگیرن. چطور میشه این کار رو کرد وقتی بعضی از نیرو‌ها با سبک توسعه‌ی آزمون-محور (TDD: Test-Driven Development) کار می‌کنن و بعضی نه؟ یا وقتی بعضی، از مدل پیش-ساخت (Pre-build) و بعضی دیگر از روش 5-چرا (five whys) برای تحلیل ریشه‌ای عیب‌ها استفاده می‌کنن؟ طراحی اونها به کنار، پیاده سازیشون چطور؟ مجبور کردن افراد به رعایت اونها چی؟ مگه قرار نشد این کارها ربطی به مدیر فناوری نداشته باشه؟!

خب پس نتیجه می‌گیریم، مدیر فناوری باید تکنیک‌های مدیریت افراد رو هم یاد بگیره. حالا سؤالی که ذهن همه رو مشغول کرده اینه که پس بالاخره چی شد؟

CTO کارش چیه؟

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

وظایف CTO رو میشه به 5 قسمت تقسیم کرد:

 1. انتخاب پلتفرم (بستر نرم‌افزار) و طراحی فنی.

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

2. دیدن تصویر کلی (همزمان با جزئیات کامل).

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

 3. نشون دادن راه‌ها و گزینه‌های مختلف.

یکی دیگه از نشونه‌های CTOهای خوب، اینه که آیه یأس نمی‌خونن. یعنی هیچ وقت نمیگن “امکان نداره” یا “ما نمی‌تونیم”. در عوض سعی می‌کنن گزینه‌های مختلفی در همون راستا ارائه بدن. مثلا اگه مدیرعامل خواست محصول رو کلا عوض و اون رو در راستای نیازهای دسته‌ی دیگری از مشتریان تنظیم کنه، باید یک نفر باشه تا تمام نیازهای این پروژه جدید رو بسنجه و هزینه‌های ممکن رو در هر حالت تخمین بزنه. بعضی از مدیران فنی عادت دارن به صورت خودسر، جای شما تصمیم بگیرن و بهترین گزینه از نظر خودشون رو به شما پیشنهاد بدن، اما این   اصلا خوب نیست. CTO باید تمام گزینه‌ها رو با هزینه‌ها و جزئیات بگه و انتخاب رو به مدیرعامل بسپاره.

4. 80% خروجی با 20% هزینه … ممکنه؟

فرض کنید چند نفر قصد دارن یک ویژگی (مثلا نرم‌افزاری) جدید بسازن و تو ذهن خودشون هم تمام جزئیاتش رو در آوردن. مثلا این ابزار جدید، کارهای الف و ب رو انجام میده. اما تو ذهن من به عنوان مدیر فناوری قضیه فرق داره، من می‌دونم که اونها در محاسبه‌ی هزینه‌ها (چه زمانی و چه مالی) اشتباه کردن). اما با این حال پیشنهاد رو رد نمی‌کنم. بلکه به دنبال راهی میگردم تا ببینم آیا میشه 20% از قابلیت‌هاش رو به ازای کم شدن 80% از هزینه‌ی کل، حذف کرد؟ مثلا می‌بینم با حذف قابلیت ب، میشه قابلیت الف رو هم چنان، تنها با 20% هزینه، عملی کرد. بیشتر مواقع هم با این واکنش از سوی پیشنهاد دهنده‌ها روبرو میشم: “واقعا؟ یعنی بیشتر هزینه‌ها به خاطر قابلیت ب بوده؟ ما این قابلیت رو همین جوری به عنوان چاشنی کار اضافه کرده بودیم!”

5. تربیت رهبران فنی.

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

وقتی چندین نفر می‌خوان با یک اِشِل و استاندارد کار کنن، لازمه که اون استاندارد هم تقویت و محکم‌تر بشه. مثلا، اینکه ما اساس کد‌هامون رو، PHP قرار دادیم، آیا ضرورت داشته؟ یا می‌تونستیم از زبان‌های دیگه هم استفاده کنیم؟ آیا اینکه بیشتر کد‌های وب رو به صورت رویه‌ای نوشتیم و نه شئ-گرا، مهم بوده یا اینکه اصلا لزومی نداشته؟ شاید یکی دلش خواست ماژول‌ها رو شئ-گرا بنویسه. با آموزش و سپردن کار به افرادی با علایق و گرایش‌های مختلف، می‌تونیم یک تیم حرفه‌ای از افراد شبیه به مدیران فنی درست کنیم که برای شرکت خیلی ارزشمند هست.

حالا می‌خوام یک مورد دیگه هم به این لیست اضافه کنم و دلیل جدا کردنش از بقیه اینه که شاید از نظر خیلی‌ها تجاوز به حریم نقش معاونت مهندسی (VP Engineering) محسوب بشه:

• تعیین متدولوژیِ توسعه محصول.

  تو روش‌های مرسوم برای توسعه محصول، معمولا معاونت مهندسی (VP Engineering) یا یک مدیر تمام وقت، مسئول اموری مثل: اطمینان از نوشتن مستندات کافی برای محصول توسط مهندسین، خوب اجرا شدن روند کنترل کیفیت در تولید انبوه (QA: Quality Assurance) و هم‌چنین برنامه‌ریزی برای انتشار نسخه‌های متفاوت نرم‌افزار‌ها برای محصولات مختلف و اجرای اون برنامه، هست. این امور، متدولوژی توسعه محصول رو تشکیل میدن. اما تو استارت‌آپ‌ها که همه اونها رو به سرعت عمل می‌شناسن، این متدولوژی، مهم‌تر از این حرفاست که فقط یک کار مدیریتی محسوب بشه.

این که تیم بخواد از روش آزمون-محور(Test-Driven Development) یا در-لحظه(JIT: Just In Time) برای توسعه استفاده کنه، روی معماری خیلی تأثیر میذاره و برای هرکدوم فرق داره. این امور به نظر باید جزء مسئولیت‌های مدیر ارشد فناوری و تیم “رهبران فنی” باشه. حالا اگه همش رو هم نگیم، حداقل تحلیل ریشه‌ای عیب و نقص‌ها رو دیگه باید اون‌ها انجام بدن. مثلا با روش 5-چرا (five-why). چون اگه این طور نباشه، چجوری می‌خوان نقاط کور پروژه رو پیدا کنن و خودشون رو با معماری هماهنگ کنن!؟ باید کسی باشه که تصویر کلی رو می‌بینه.

البته باور قلبی ما اینه که تمام این مطالب 100% درست و مطلق نیستن، پس اگر در این بحث دانش و نظر دیگه‌ای دارید، توی بخش نظرات در میون بذارید. ممنون.