برنامهنویس و مدیر فنی سابق، فعال در حوزه استخدام و جذب، علاقهمند به ساختن! ساختن محصول، فرآیندها، تیمها و ...
راهبری یک جلسه ارزیابی فنی در نقش یک فرد غیر فنی!
چگونه یک جلسه ارزیابی فنی را به عنوان یک فرد غیرفنی راهبری کنیم؟!
(این پست به نوعی ترجمهی مقالهای است که خانم Anne de kerckhove مدیرعامل شرکت Freespee وIron Group آن را نوشته است)
من به مدت ۱۵ سال در حوزه استارتآپهای مبتنی بر فناوری فعالیت داشتهام. همچنین سرمایهگذار بیش از ۲۵ استارتآپی بودهام که مبتنی برای تکنولوژی و پلتفرمها هستند. در همه این سالها آموختهام که یک پلتفرم فناوری بد و یا یک تیم ناکارآمد میتواند یک کسب و کار با رشد بالا را به سرعت از بین ببرد و میتواند یک شرکت را هنگامی که بازار به سرعت در حال تغییر و رشد است فلج کند.
عملکرد و بهرهوری فناوری در شرکتهای مختلف تفاوت بسیاری دارد.
چند بار دیدهایم که یک تیم کوچک با ۱۰ نفر عضو توانسته است که در چالشهای فناوری به موفقیت بزرگی دست یابد که تیمهایی با هزاران نفر نتوانستهاند؟!
چند بار شاهد بودهایم که تزریق نقدینگی بزرگ به تیمهای فناوری در شرکتهای سری C نتیجه مناسبی نداشته است؟
خوب بودن در تکنولوژی چیزی فراتر از یک کد خوب است. در ادامه به پرسشهای کلیدی میپردازم که به یک فرد غیر فنی (که میتواند هر فرد سرمایهگذاری باشد) کمک میکند تا ارزیابی فنی را در جریان تملک و ادغام و یا سرمایهگذاریهای محتمل انجام دهد. این سوالات، سوالات اصلی من و بسیار تعیین کننده هستند. بدیهی است که مرتبط بودن آنها به مرحلهای از شرکت که در آن سرمایهگذاری میکنید بستگی دارد. این پرسشها بیشتر به سرمایه گذاریهای بعد از سری A مرتبط است. اگرچه یک تیم خوب از ابتدای کار به این ۶ پرسش میاندیشد.
۱- آیا تیم فناوری یک دورنما و نگرش مشترکی به نقشه راه محصول خود دارند؟ آیا میتوانند این نقشه راه را برای شما توضیح دهند؟
من پیشنهاد میکنم که هنگام ارزیابی حداقل با سه نفر از اعضای تیم فنی مصاحبه کنید، CTO، معمار فنی یا سرپرست DevOps و یک سرپرست تیم توسعه. هر سه نفر باید بتوانند دورنما و نقشه راه ۶ تا ۱۲ ماه آینده را توضیح دهند. پاسخها میبایست هماهنگ باشند. در مورد اصول معماری، انتخاب زبانهای برنامههای نویسی، نگرششان در مورد استفاده از منابع متن باز، تاریخهای کلیدی تعیین شده، چگونگی پیگیری پیشرفت کار و نگرششان به توسعه و استقرار سوال کنید.
بازدارندهها(از سرمایه گذاری): در صورتی که هیچ معماری یا نقشه راه مکتوبی وجود ندارد و یا در نتیجه سه مصاحبه جوابهای متفاوتی دریافت کردید، تیم مورد نظر برای سرمایهگذاری مناسب نیست
۲- آیا بین تیم فنی و کسب و کار نیازمندیهابه صورت مکتوب به اشتراک گذاشته میشود؟ آیا این دو تیم با یکدیگر هنگام شروع پروژهها یا نیازمندی های جدید باهم کار میکنند؟
بازدارندهها(از سرمایه گذاری): اگر یک سند مکتوب به همراه جزییات کافی بین تیم فنی و کسب و کار وجود ندارد، حتی اگر تیم فنی بسیار قوی باشد محکوم به شکست خواهند بود و مناسب سرمایهگذاری نیستند.
۳- فرآیند استقرار(deployment) چگونه است؟ آیا محیطهای مختلفی هنگام توسعه و محصول نهایی در نظر گرفته شده؟ آیا راهکارهایی برای roll back کردن وجود دارد؟ آیا یک قطعه کد کوچک را می توانند دیپلوی کرد یا برای یک امکان جدید هر بار باید کل سیستم را مجددا دیپلوی کرد؟
بازدارندهها(از سرمایه گذاری): اگر شرکت یک فرآیند شفاف و مکتوب برای دیپلوی کردن و یک محیط امن برای این کار ندارد بهتر است سرمایهگذاری نکنید!
هم چنین اگر پلتفرم مورد نظر دارای اجزای مختلف نیست و یک پلتفرم با یک جز بسیار بزرگ است، این پلتفرم چابک نخواهد بود. بهتر است سرمایهگذاری نکنید!
۴- آیا این پلتفرم میتواند به سادگی به پلتفرمهای خارجی(خارج از تیم) متصل شود؟ آیا میتواند APIهای سادهای ارائه دهد؟
بازدارندهها: اگر APIهای ساده و مستند شدهای وجود ندارد این تیم نمیتواند با تیمهای خارجی کار کند و یا بخشی از کار را برونسپاری کند. سرمایهگذاری نکنید!
۵- تیمها چقدر کد، پلتفرم، امکان توسعه و scale کردن، تاخیرها و یکپارچگی دادهها را تست میکنند؟
بازدارندهها: اگر یک برنامه مشخص برای تستهای فراتر از تستهای اولیه وجود ندارد، سرمایهگذاری نکنید!
۶- تیم فنی چقدر بر پلتفرم خود نظارت (monitoring) دارد؟
بازدارندهها: اگر تیم نظارتی بر سیستمهای خود ندارد، قطعا بارها در سیستم ازکارافتادگی اتفاق خواهد افتاد. سرمایهگذاری نکنید!
امیدوارم که این پرسشها به سرمایهگذاران غیر فنی کمک کند تا یک تیم فنی را سرمایهگذاری خود به چالش بکشند.
مطلبی دیگر از این نویسنده
دورکاری؛ هزار راه رفته در گیتلب! (قسمت اول)
مطلبی دیگر در همین موضوع
برنامه نویس خوب ،برنامه نویس بد
بر اساس علایق شما
آن که «آه» میکشد!