برنامهریزی چشمانداز
هایلایتهای علی امیدیان
این فصل را خواندم و موارد زیر به نظرم برای ساخت و انتقال چشمانداز فناوری مفید و کاربردی بود. هر نکته به بخش مرتبط در متن لینک شده است. برای کاملتر شدن مسیر مطالعه، فصل ۲؛ مدیریت رو به بالا و فصل ۴؛ ساختن تیم نیز ادامه طبیعی این موضوع هستند.
- CTO باید نسخه خودش از بیانیه چشمانداز را داشته باشد؛ نسخهای که بر خروجی گروه خودش تمرکز دارد اما از چشمانداز و مأموریت کلی شرکت پشتیبانی میکند. به این «چشمانداز بزرگ» میگوییم. 💡 چشمانداز فنی باید مستقل باشد، اما از جهتگیری کلی شرکت تغذیه کند.
- خوشبختانه، یا بدبختانه بسته به دیدگاه شما، صنعت ما هیچوقت ثابت نمیماند و در هر پیچوخم جا برای بهبود وجود دارد. 💡 ثبات در فناوری توهم است؛ فرصت بهبود همیشه در تغییر پنهان است.
- فناوریهای تازه برای کاربرد درست خوباند، نه برای همه و هر چیز 💡 انتخاب فناوری باید از مسئله واقعی شروع شود، نه از جذابیت ابزار تازه.
- CTO بدون چشمانداز، ناخدایی بدون مقصد است؛ باید بدانید کجا میروید تا بدانید چه زمانی رسیدهاید. 💡 چشمانداز مقصد میدهد و مقصد امکان سنجش پیشرفت را فراهم میکند.
- بهتر است معیارهای موفقیت خود را محکم کنید تا وقتی به آن رسیدید اختلافی وجود نداشته باشد. 💡 موفقیت مبهم بعدها به اختلاف تعبیر تبدیل میشود.
- درک مشتری، انگیزههایش، خواستههایش و اهدافش به شما کمک میکند محصولتان را بهتر تحویل دهید. 💡 چشمانداز معتبر از شناخت مشتری واقعی ساخته میشود.
- بهترین توصیه هنگام صحبت با مشتریان این است: روی هیچ چیز نپرید، فقط گوش کنید. راهحل ندهید، وعده ندهید، اطمینان ندهید؛ فقط گوش کنید. 💡 در گفتوگو با مشتری، شنیدن پیش از حل کردن مهمترین مهارت است.
- بازی تلفن را که شاید در کودکی بازی کرده باشید به یاد بیاورید. 💡 درخواستهای مشتری در مسیر انتقال تحریف میشوند؛ شفافسازی مستقیم ارزشمند است.
- کسبوکار فقط یک بازی بزرگ تلفن است. 💡 CTO باید مراقب فاصله میان درخواست اصلی و روایت رسیده به تیم فنی باشد.
- برخی مشتریان از نظر فناوری از شما جلوترند؛ برخی نیستند. 💡 همه مشتریان را با یک سطح بلوغ فنی نبینید؛ هر گروه نیاز متفاوتی دارد.
- اگر چشمانداز شما در چند ماه قابل اجرا باشد، دیگر چشمانداز نیست بلکه پروژه است. 💡 چشمانداز باید افق بلندتر و مجموعهای از پروژهها را در بر بگیرد.
- چشماندازهای بزرگ برای برنامهریزی، زمانبندی و اجرا تلاش زیادی میطلبند. چشمانداز خوب از ضرورت میآید، نه از اینکه «کاری برای انجام دادن» باشد. 💡 چشمانداز زمانی ارزش دارد که پاسخ به نیاز واقعی کسبوکار باشد.
- وقتی کسبوکار بتواند زود و مکرر منافع چشمانداز شما را ببیند، اشتهایش برای ادامه حمایت و تأمین مالی شما کم نمیشود. 💡 تحویلهای کوچک و قابل مشاهده، حمایت بلندمدت را زنده نگه میدارند.
- ما چیزها را نامگذاری میکنیم تا به آنها شخصیت و احساس بدهیم. 💡 نام خوب برای پروژه، روایت و مالکیت احساسی ایجاد میکند.
- نام خوب پروژه به چشمانداز شما جان میدهد و میگذارد همه از نظر احساسی در آن سرمایهگذاری کنند. 💡 نامگذاری بخشی از ارتباطات راهبردی چشمانداز است.
- اشکالی ندارد همه پاسخها را نداشته باشید. 💡 صداقت درباره نادانستهها از پاسخسازی عجولانه قابل اعتمادتر است.
- ما در محیطی همیشه در حال تغییر هستیم که گاهی ترسناک به نظر میرسد و این فکر را باقی میگذارد که همیشه در حال عقبافتادن هستید. 💡 اضطراب عقب ماندن از فناوری طبیعی است، اما نباید تصمیمها را فلج کند.
- وقتی پای فناوری در میان است، هر تصمیمی بهتر از بیتصمیمی است. 💡 تصمیم آگاهانه و قابل اصلاح، از تعلیق دائمی بهتر است.
- که من آن را «احساس گناه شروعکننده» مینامم؛ چیزی بیشباهت به پشیمانی خریدار نیست، همان حس که انتخاب اشتباهی کردهاید. 💡 تردید پس از شروع تصمیم بزرگ طبیعی است؛ آن را نشانه شکست ندانید.
- نگران نباشید؛ هیچ تصمیمی برگشتناپذیر نیست، یا دستکم نمیتواند یک اصلاح مسیر کوچک را تحمل نکند. 💡 چشمانداز خوب امکان اصلاح مسیر را از ابتدا در خود جا میدهد.
- چیزها تغییر میکنند، و اغلب با یادگیری و کشف بیشتر ما تغییر میکنند. 💡 یادگیری در مسیر اجرا باید به تغییر محترمانه فرضیات منجر شود.
- اگر فونداسیونی لرزان داشته باشیم که در برابر نیروهای بیرونی تحمل ندارد، هرچه بسازیم همیشه نقطه ضعف خواهد بود. 💡 معماری و زیرساخت ضعیف، هر دستاورد بعدی را شکننده میکند.
- شناسایی حوزهها یا ستونها، علم یا قواعد کسبوکاری نیست که باید بسازید؛ بلکه حوزههایی است که در حالت ایدهآل دوست دارید برونسپاری کنید 💡 ستونها چیزهاییاند که باید به آنها تکیه کنید، نه لزوما مالک همه جزئیاتشان شوید.
- تیم جداگانه کوچک تیم کوچکی است که برای چند روز راه میافتد تا در حوزهای بسیار باریک عمیقتر شود و اطلاعات لازم را بیاورد تا بتوانید تصمیمهای آگاهانهتری بگیرید. 💡 برای تصمیمهای بنیادین، کاوش کوتاه و متمرکز بهتر از حدس زدن است.
- برای ابتکارهای بلندمدت، انتظار میرود که لازم باشد چند قدم عقب بروید تا بتوانید به جلو بپرید. 💡 عقبنشینی کنترلشده گاهی بخشی از حرکت درست رو به جلو است.
- امیدوارم یکی از اهداف چشماندازتان کاهش پیچیدگی و سربار کلی باشد. 💡 چشمانداز فنی خوب معمولا سیستم را سادهتر و قابل نگهداریتر میکند.
- همانطور که یک بازیکن خوب پوکر به شما میگوید، وقتی میبینید دستتان دیگر برنده نمیشود، مهم نیست تا اینجا چقدر پول شرط بستهاید؛ بیرون بکشید. 💡 هزینه غرقشده نباید شما را به ادامه مسیر اشتباه مجبور کند.
- بگذارید سرویس جا بیفتد و زمان بگذارید تا تأیید کنید همه چیزهایی را که نیاز دارید دارد. 💡 مهاجرت به سرویس جدید باید با مشاهده بلوغ و تناسب واقعی انجام شود.
- زندگی وقتی قطعات کمتری برای مدیریت دارید سادهتر است. 💡 کاهش سطح عملیات روزمره یکی از بردهای مهم معماری است.
- یک کاری که باید بتوانید بدون فکر انجام دهید این است که چشماندازتان را برای هر کسی که میپرسد، مختصر و آسانفهم توضیح دهید. 💡 چشماندازی که ساده توضیح داده نشود، به سختی حمایت میگیرد.
- برای بعضیها این کار میتواند بسیار دشوار باشد؛ اینکه توضیحاتشان را از حالت بیش از حد فنی خارج کنند تا هر کسی بفهمد. 💡 ترجمه زبان فنی به زبان عمومی، مهارت کلیدی رهبر فناوری است.
- ارائه آسانسوری مینامیم. اساسا توضیح کوتاهی است که میتوان آن را در حدود ۳۰ ثانیه طوری بیان کرد که هر شنوندهای بفهمد چه میگویید. 💡 ارائه آسانسوری ابزار فشردهسازی چشمانداز برای مخاطب غیرتخصصی است.
- ساختن ارائه خود 💡 ارائه خوب ساخته و تمرین میشود؛ اتفاقی و فیالبداهه نیست.
- یکی از سختترین کارهایی که ممکن است در مقطعی انجام دهید ساختن بودجه برای چشماندازتان است. 💡 چشمانداز بدون بودجه قابل دفاع، در سطح آرزو باقی میماند.
- مشکل رایج بودجهها کمبود جزئیات است. 💡 بودجه دقیق اعتماد CFO، CEO و هیئتمدیره را میسازد.
- دومین حذف، منابع لازم برای پروژه است. این باید شامل سختافزار، مجوزهای نرمافزاری، خدمات شخص ثالث و منابع ابر باشد 💡 بودجه فقط نیروی انسانی نیست؛ منابع عملیاتی و سرویسها هم باید دیده شوند.
- کسبوکار پروژه را سریع-خوب-ارزان (fast-good-cheap) میخواهد. 💡 مثلث زمان، کیفیت و هزینه را باید شفاف و قابل مذاکره کرد.
- Warren Buffet گفت: «نمیتوانید با باردار کردن نه زن، یک نوزاد را در یک ماه به دنیا بیاورید.» 💡 برخی محدودیتهای زمانی با پول بیشتر حل نمیشوند.
- غیرمعمول نیست، بهویژه برای پروژههای چشماندازی، که کسبوکار ROI بخواهد. 💡 برای پروژههای بزرگ باید بتوانید منطق بازگشت سرمایه را توضیح دهید.
- شیطان آشنا بهتر است 💡 در لحظه خستگی پروژه، سیستم قدیمی دوباره وسوسهانگیز به نظر میرسد.
- اکثریت عظیم پروژههای بزرگ میلغزند؛ این واقعیت زندگی است. اما مستند نکردن اینکه چرا میلغزند و ارتباط ندادن آن، کاری جز آماده کردن شما و تیمتان برای شکست نمیکند. 💡 لغزش پروژه مشکل است؛ پنهان کردن دلیل آن مشکل بزرگتر است.
- بسیاری از CTOها دوست ندارند خبر بد بدهند و وقتی چیزها خیلی عقب میافتد، تمایل دارند روی آن را بپوشانند. این نگرش اشتباه است 💡 خبر بد اگر زود و روشن گفته شود، هنوز قابل مدیریت است.
- در غیاب اطلاعات، مردم خودشان جاهای خالی را پر میکنند، چه بهتر چه بدتر 💡 سکوت ارتباطی، روایتهای کنترلنشده تولید میکند.
این فصل پوشش میدهد
- اهمیت بیان روشن یک چشمانداز
- برنامهریزی چشمانداز بر اساس نیازهای کسبوکار
- تعریف ارزش واقعی چشمانداز برای مشتریان
- برنامهریزی برای تغییرات بلندمدتی که کسبوکار را دگرگون میکنند
- تنظیم انتظارات و پرهیز از وعدههای نادرست
- قرار دادن یک برنامه اقتصادی کنار چشمانداز
- انتقال چشمانداز به مخاطبان متفاوت
- جا دادن فرسودگی و تغییر در خود چشمانداز
CEO فقط مسئول اداره شرکت نیست؛ مسئول رهبری شرکت هم هست. رهبری یعنی نگاه به جلو، پیشبینی نیازهای بازار و برداشتن گامهایی برای جلوتر بودن، نه واکنش نشان دادن به رویدادهای بیرونی. نقش شما بهعنوان CTO، رهبر فناوری سازمانی، تفاوتی ندارد. کافی نیست فقط چراغها را روشن نگه دارید؛ باید مطمئن شوید روشن میمانند و برای مدت طولانی همچنان درخشان میتابند، فارغ از اینکه چه چیز دیگری در جریان است. شرکت به شما نگاه میکند تا مطمئن شود توان تحویل ارزش و رشد برای مشتریان را دارد. وقت گذاشتن برای ساختن یک چشمانداز، صیقل دادن آن، ترسیم مسیر و ارتباط دادن این سفر، به کسبوکار اعتماد لازم را میدهد که بداند در دستان مطمئنی قرار دارد. برای روشن کردن مفاهیم، شرکت خیالی خودمان، HomeMax PLC، را معرفی کنیم. فرض کنیم این شرکت بیش از ۴۰ سال سابقه دارد و برای صاحبان خانههای مسکونی بیمه گارانتی خانه فراهم میکند. آنها روی فناوری legacy کار میکنند؛ ترکیبی از RPG و Cobol که همه از طریق نرمافزار ترمینال و در برابر پایگاه داده Db2 روی AS/400ها اجرا میشود. هیچوقت واقعا CTO رسمی نداشتهاند و بنیانگذار بهجای آن تیم کوچکی از توسعهدهندگان را هدایت میکرده است. بهتازگی یک شرکت سرمایهگذاری خصوصی آنها را خریده است؛ شرکتی که مشتاق گسترش بازارشان است و اولین CTO آنها را آورده تا تحول فناوری را پیش ببرد.
۳.۱ چشمانداز بزرگ
سازمان شما به احتمال زیاد همین حالا هم بیانیه چشمانداز یا مأموریت دارد. تفاوت ظریف اما مهم است: بیانیه چشمانداز هدف مأموریت و نتیجه نهایی است، در حالی که بیانیه مأموریت را میتوان نسخه عملمحور بیانیه چشمانداز دانست؛ چیزی که توضیح میدهد چرا سازمان وجود دارد، چه نوع خدمات و محصولاتی ارائه میکند و چه چیزی آن را منحصربهفرد میکند.
از دل میدان: نمونههایی از بیانیه چشمانداز
برای اینکه نشانهای از یک بیانیه چشمانداز خوب داشته باشید، به چند نمونه از شرکتهای بزرگ و شناختهشده نگاه کنیم. LinkedIn جایگاه خود را با «ایجاد فرصت اقتصادی برای هر عضو نیروی کار جهانی» مشخص میکند، در حالی که Disney میگوید «سرگرم کردن، آگاه کردن و الهام بخشیدن به مردم سراسر جهان از طریق قدرت داستانگویی بیهمتا»، و Microsoft میگوید «یک رایانه روی هر میز و در هر خانه». وجه مشترک همه اینها این است که همگی گزارههایی بسیار آسانفهم و عاری از اصطلاحات تخصصی دارند. بیانیه چشمانداز شرکت HomeMax ما میتواند این باشد: «به دست آوردن آرامش خاطر درباره ارزشمندترین دارایی شما».
CTO باید نسخه خودش از بیانیه چشمانداز را داشته باشد؛ نسخهای که بر خروجی گروه خودش تمرکز دارد اما از چشمانداز و مأموریت کلی شرکت پشتیبانی میکند. به این «چشمانداز بزرگ» میگوییم. این همان چیزی است که به سمت آن کار میکنید، دلیل رفتن شما به آن سمت است، و تعریف میکند وقتی به آنجا رسیدید شما و کسبوکار چه کارهایی میتوانید انجام دهید؛ جزئیات کوچکی که خیلیها اغلب از قلم میاندازند. هرچند عالی است که بگویید به نقطه مشخصی میروید، مهم است به مردم یادآوری کنید هنگام رسیدن قرار است چه کنید. چشمانداز شما باید دو تا پنج سال آینده را از نقطه فعلی در بر بگیرد. طولانیتر از آن برای مردم سخت خواهد بود که با آن ارتباط بگیرند، چون کسبوکار ممکن است پیش از تحقق چشمانداز شما تغییر کند، چرخش کند یا حتی فروخته شود. چشمانداز خوب چشماندازی است که بتوان آن را تحویل داد و جشن گرفت. هیچوقت نمیخواهید رهبری باشید که برای او «فردا هرگز نمیرسد». البته چشمانداز شما باید با تغییر کسبوکار و چشمانداز فناوری تکامل یابد و تغییر کند، و بعدتر بررسی میکنیم این کار چگونه انجام میشود. نکته مهم اینجاست: اگر از CTO موجودی تحویل میگیرید که ماشینی خوب روغنکاریشده ساخته است، چشمانداز شما ممکن است صرفا این باشد که آن را در همان جهت نگه دارید و تکامل را ادامه دهید. خوشبختانه، یا بدبختانه بسته به دیدگاه شما، صنعت ما هیچوقت ثابت نمیماند و در هر پیچوخم جا برای بهبود وجود دارد. فرصتهای زیادی برای افزودن بهبودهای خود خواهید داشت. وقتی چشماندازتان را کنار هم میگذارید، باید به دو مخاطب متفاوت آگاه باشید: کسبوکار و گروه خودتان. کسبوکار میخواهد بداند چشمانداز شما برای آنها چه معنایی دارد، با واژگانی که تا حد ممکن از واژه مد روز خالی باشد. این را بخش «چه چیزی» و «چرا»ی چشماندازتان بدانید. گروه خودتان هم میخواهد همین را بشنود، اما گوشت بیشتری روی استخوان میخواهد: جزئیات بسیار بیشتر و اینکه این کار چگونه محقق خواهد شد. این بخش «چگونه»ی چشمانداز شماست.
۳.۱.۱ بخش «چه چیزی»/«چرا»
کسبوکار علاقه دارد بداند چشمانداز شما برای آنها چه معنایی دارد. این شامل بقیه شرکت بیرون از گروه شماست: اعضای هیئتمدیره، سرمایهگذاران و حتی مشتریان. اگر چشمانداز شما نتواند با هر یک از این گروهها حرف بزند و منفعتی به آنها بدهد، چیزی بیشتر از هدف یک پروژه نیست؛ یا فقط پرداخت بدهی فنی. چشمانداز میتواند درباره منافع اقتصادی، ویژگیهای مهم یک پلتفرم یا فرصتهایی باشد که میتوانند گشوده شوند.
از دل میدان: هیچ دادهای جا نماند
در یکی از شرکتهای پرتفویی که CTO آن بودم، پس از مشاهده کسبوکار و ارزشهایشان، یعنی فرهنگی که تصمیمها را با داده هدایت میکرد، باید تعریف میکردم چشمانداز من چه خواهد بود. برای پشتیبانی از چشمانداز CEO، گروه خودمان را متمرکز کردم بر اینکه مطمئن شویم کسبوکار همه دادههای ممکن را برای تصمیمگیری آگاهانه در اختیار دارد؛ بنابراین به گزاره ساده «هیچ دادهای جا نماند» رسیدم. حتی از دپارتمان هنر خواستم بنری عظیم با فونت و سبک فیلم Back to the Future بسازد؛ خیرهکننده بود، و داشتن یک دپارتمان هنر کامل در داخل شرکت هم بسیار به کار آمد. با توجه به اینکه ذخیرهسازی داده چقدر ارزان شده است، دیگر بهانهای برای ثبت نکردن یا نگه نداشتن داده وجود نداشت. این چیزی بود که در گذشته شرکت را گزیده بود، و از آن پس هر کاری میکردیم برای پشتیبانی از همان گزاره و دسترسپذیر کردن داده برای کسبوکار بود. هر بار که ویژگی یا نسخهای جدید از پلتفرم منتشر میکردیم، بهراحتی میتوانستیم درباره اجرای چشماندازمان حرف بزنیم و توضیح دهیم با انباشته شدن داده بیشتر، چگونه فهم و فرصتهای تازهای باز میشود.
بیانیه چشمانداز لازم نیست بیش از حد پیچیده یا ظریفپردازیشده باشد. باید چیزی بگوید که شنوندگان بتوانند درونیاش کنند و ببینند چگونه به آنها کمک میکند. برای شرکت HomeMax ما که در فناوری legacy فرو رفته و میخواهد به محیط وب و موبایل حرکت کند، بهجای تکیه بر کارکنان مرکز تماس برای رسیدگی به هر درخواست خسارت و هر بهروزرسانی، بیانیه چشمانداز میتواند این باشد: «پلتفرمی خودگردان و مشتریمحور بر پایه داده».
۳.۱.۲ بخش «چگونه»
شما و گروهتان باید چشماندازتان را تحویل دهید. اینجا جایی است که باید با جزئیات بیشتری توضیح دهید معنی آن چیست و چیزها چگونه برای پشتیبانی از آن چشمانداز تغییر یا سازگار میشوند. چشمانداز موفق چشماندازی است که همه آن را درک کنند و بتوانند آن را در هر حوزهای که مسئولش هستند وارد کنند. برای هر تصمیمی که شما و تیمتان میگیرید، بپرسید آیا این تصمیم شما را یک گام به چشمانداز نزدیکتر میکند یا یک گام دورتر؟ آیا استخدام جدیدی که در آستانه انجامش هستید، قرارداد با آن فروشنده خدمات، یا تصمیم درباره استک فناوری شما را به هدف نزدیکتر میکند؟ چشمانداز شما باید گروهتان را هیجانزده کند؛ چیزی باشد که بتوانند پشت آن بایستند. برای آزمودن تعهد تیم فنیتان بپرسید: «آیا آنها، یعنی گروه شما، به چشمانداز شما باور دارند؟» اگر ندارند، فروختن چشماندازتان به کسبوکار تقریبا ناممکن خواهد بود. اگر همان افرادی که در سنگرها هستند و روزانه روی مشکلات مشتری، باگها یا ابتکارهای ویژگی کار میکنند نتوانند پشت چشمانداز شما بایستند، احتمال دارد چشماندازتان را اشتباه گرفتهاید، یا آن را آنقدر روشن بیان یا خرد نکردهاید که واقعی به نظر برسد.
از دل میدان: چشماندازی ابری
با CTOای روبهرو شدم که به بیانیه چشمانداز خود افتخار میکرد: «ما یادگیری ماشین را وارد تحلیلهایمان میکنیم.» قطعا چشماندازی بزرگ بود، اما وقتی از او پرسوجو کردم، جزئیات نداشت. آنها فکر نکرده بودند این برای کسبوکار چه معنایی دارد و مشتریانشان چگونه سود میبرند. به گروه خودش هم بخش «چگونه» گفته نشده بود؛ بخش «چرا» هم از قبل غایب بود. بنابراین آنها دنبال سایهای میدویدند و تلاش میکردند مسئلهای را حل کنند که وجود نداشت. مسئله اینجا این بود که CTO فقط چون یادگیری ماشین جذاب به نظر میرسید، سوار موج آن شده بود. میدانست داده زیادی در پایگاههای دادهاش دارد و فکر میکرد این به مسیر حرفهایاش کمک میکند. هیچ فکری نشده بود که آیا این کار واقعا کار درست است یا نه. فناوریهای تازه برای کاربرد درست خوباند، نه برای همه و هر چیز؛ و نگذارید شروع کنم به تعداد چشماندازهای blockchain که مجبور شدیم خردشان کنیم!
۳.۱.۳ موفقیت را تعریف کنید
یکی از زیباییهای چشمانداز روشن و خوب بیانشده این است که چیزی به شما میدهد که به سوی آن بدوید و، مهمتر از آن، پیشرفت خود را با آن بسنجید. CTO بدون چشمانداز، ناخدایی بدون مقصد است؛ باید بدانید کجا میروید تا بدانید چه زمانی رسیدهاید. با تعریف چشماندازتان، میتوانید نقطههای عطف کوچکتری را بهعنوان بخشی از آن قرار دهید، هرکدام را بردی کوچک بدانید و بهتناسب با گروهتان جشن بگیرید. هرچند بسیاری از CTOها چشماندازی ندارند، آنهایی هم که دارند وقتی درباره شکل موفقیتشان دقیق پرسیده میشود کمی مبهم میشوند. با کلیگویی و گزارههای گسترده حرف میزنند. بهتر است معیارهای موفقیت خود را محکم کنید تا وقتی به آن رسیدید اختلافی وجود نداشته باشد. بیایید چند نمونه از گزارههای چشماندازی را با تجزیهشان ببینیم؛ برخی از آنها درباره شرکت HomeMax ما کاربرد دارند. اینها از بیانیه چشمانداز فراگیر که به کسبوکار اعلام شده پشتیبانی میکنند: دادن کنترل بیشتر به مشتری.
جدول ۳.۱ نمونههایی از گزارههای چشماندازی
| گزاره | چه چیزی | چگونه | موفقیت |
|---|---|---|---|
| همه سختافزارها را منسوخ کنیم و کاملا به ابر برویم. | سربار نگهداری داراییهای فیزیکی را حذف کنیم تا بتوانیم به مدل پرداخت به میزان مصرف برویم؛ مدلی که آمادهسازی اولیه مشتریان جدید را شتاب میدهد. | خرید سختافزار را متوقف کنیم، یادگیری گزینههای ابر را آغاز کنیم و حوزههایی را شناسایی کنیم که میتوانیم بدون به خطر انداختن کسبوکار، بردهای زودهنگام داشته باشیم. | وقتی آخرین سرور خاموش شود و اتکا به دفتر/دیتاسنتر صفر باشد. |
| به سمت معماری API-محور حرکت کنیم. | دادهها/خدماتمان را به شکلی امن و قابل اتکا در دسترس قرار دهیم تا مشتریان بتوانند بدون انتقال فایل مستقیما با ما یکپارچه شوند. | نقاط تماسی را که مشتریانمان برای ارسال و دریافت داده نیاز دارند، و نیز شیوه جابهجایی داخلی داده را شناسایی کنیم تا از سربار داده رها شویم. | تعامل مشتری بدون نیاز به ارسال یا پیوست کردن فایل؛ خودخدمت با استفاده از API. |
| سیستم legacy را جایگزین کنیم. | سیستم را به معماری مدرن و پشتیبانیشده منتقل کنیم که به ما امکان دهد با تلاش بسیار کمتر به درخواستهایی پاسخ دهیم که مشتریان مدتهاست مطرح میکنند. | همه قواعد کسبوکار و مسئولیتهای این سیستم را استخراج کنیم و سپس طراحی یک یا چند سیستم را برای تحویل گرفتن تدریجی شروع کنیم. | وقتی سیستم legacy سرانجام خاموش شود و دیگر از هیچ مشتریای پشتیبانی نکند. |
| مشتری را با رابط مدرن وب و موبایل توانمند کنیم. | مرکز تماس را از مدیریت همه تعاملات بیرون بکشیم و بهجای آن اجازه دهیم مشتریان خودشان کار را انجام دهند. | استفاده از یک چارچوب مدرن وب که به شکل امن با APIهای پشتصحنه صحبت میکند. | مشاهده کاهش چشمگیر در تعداد تماسهایی که فعالانه پاسخ داده میشوند. |
بقیه فصل عمیقتر وارد برنامهریزی میشود و نشان میدهد این برنامهریزی چگونه از چشمانداز فراگیر شما پشتیبانی میکند.
۳.۲ تعامل با مشتریان
وقتی کار روی چشماندازتان را آغاز میکنید، یکی از مهمترین ذینفعانی که باید پیش از همه در ذهن داشته باشید مشتری است. این از شناسایی اینکه مشتری شما کیست شروع میشود. مشتری فرد یا گروهی است که خروجی اصلی شما را مصرف میکند. در شرکتهای بزرگ، ممکن است این فرد مشتری اصلی شرکت نباشد بلکه یک گروه داخلی باشد. با این حال، هر که هستند، دلیل وجود شما هستند. درک مشتری، انگیزههایش، خواستههایش و اهدافش به شما کمک میکند محصولتان را بهتر تحویل دهید. اینها اصول استاندارد مدرسه کسبوکارند. با این همه، بسیاری تصور میکنند این روششناسی قلمرو انحصاری گروه فروش و بازاریابی است و باید در سطح شرکت به کار رود. بسیاری شباهتهایی را که در سطح دپارتمان عمل میکند نمیبینند، بهویژه دپارتمانی مانند گروه CTO که مسئول فناوریای است که مشتری با آن تعامل خواهد کرد.
۳.۲.۱ مشتری خود را بشناسید
بسته به شرکت، ممکن است دسترسی مستقیم به مشتریان نداشته باشید. در عوض باید از طریق مدیر حساب یا مهندس فروش پیش بروید. این احتمالا چیز خوبی است، بهخصوص برای CTO تازهکاری که شاید در صحبت با مشتری جا نیفتاده باشد. آخرین چیزی که CEO میخواهد این است که به دلیل وعده بیش از حد یک CTO بیشازحد مشتاق یا افشای چیزی که نباید گفته میشد، ریسک از دست دادن یک حساب بزرگ ایجاد شود. بهترین توصیه هنگام صحبت با مشتریان این است: روی هیچ چیز نپرید، فقط گوش کنید. راهحل ندهید، وعده ندهید، اطمینان ندهید؛ فقط گوش کنید. میخواهید بدانید مشتری چگونه با سیستمهای شما تعامل میکند و هر نقطه درد را کشف کنید. مجموعه خوبی از پرسشها برای شروع شامل اینهاست:
- کدام سیستم/خدمت نقطه تماس اصلی با شرکت ماست؟
- اگر داده مبادله میکنید، آن داده را از کجا تأمین میکنید؟
- پس از دریافت داده مبادلهشده، چه اتفاقی برای آن میافتد؟
- معمولا هر روز چگونه از این خدمت استفاده میکنید؟
- تیم شما برای موفق شدن به در دسترس بودن چه چیزی تکیه دارد؟
- در آینده نزدیک به دنبال بهبود یا تغییر کدام جنبه از فرایندهایتان هستید؟
پاسخهای این پرسشها شکل میدهند که مشتریان شما را چگونه میبینند، و چیزی که برای شما و تیمتان بدیهی به نظر میرسد ممکن است برای دیگران دشوار یا دستوپاگیر باشد. برای همین مجموعه نمونه پرسشها، به چند پاسخ نگاه کنیم که از دید یک صاحبخانه درباره شرکت HomeMax ما صدق میکند:
- فقط میتوانم از طریق خط کمک مرکز تماس تعامل کنم.
- اگر لازم باشد اطلاعاتم را تغییر یا بهروزرسانی کنم، باید آن را از پشت تلفن بخوانم.
- تا وقتی هنگام تمدید تأییدیه نگیرم، هیچ ایدهای ندارم که آیا نماینده دادههای من را دریافت کرده یا نه.
- فقط زمانی نیاز به تعامل دارم که چیزی خراب شده باشد و باید یک درخواست خسارت را شروع کنم. همچنین باید درباره وضعیت درخواست خسارت تماس بگیرم.
- میخواهم نماینده تماس بهموقع پاسخ دهد.
- میخواهم بتوانم خودم تغییرات را انجام دهم، عکسهایی برای پشتیبانی از درخواست خسارت بارگذاری کنم و بدون یک تماس وضعیت را بررسی کنم.
روشن است که مشتری نهایی انتظار دارد بخش زیادی از تجربه را خودش، با سرعت و زمان خودش، پیش ببرد. چیز غیرمعمولی نیست، اما چیزی که به CTO میگوید این است که لزوما هنوز در مرحلهای نیستیم که نیاز به ارائه محصولات یا ویژگیهای تازه داشته باشیم. در عوض باید اصطکاک تعامل با شرکت از طریق تلفن را حذف کنیم.
از دل میدان: مسئله را حل کنید، نه نشانه را
برای یکی از مشتریانی که با او کار کردیم، رابطه با مشتریانشان عالی بود و نرخ نگهداشت بیش از ۹۵٪ داشتند. مدیر حساب راضی بود و مشتریای هم که با او سروکار داشتند همینطور. لایه پایینتر چندان خوشحال نبود؛ فریادشان این بود که سربار مدیریتی زیادی وجود دارد. گردش بالایی از کارکنان موقت داشتند که وارد پورتال مشتری میشدند، و زمانی که برای ساخت و برچیدن حسابهای کاربری لازم بود دردسرساز بود. CTO جدید، بهعنوان بخشی از تحویل گرفتن نقش، تماس گرفت تا خود را معرفی کند. با شنیدن این شکایت، هیچ وعدهای نداد اما از مشتریان دیگر شروع کرد به پرسیدن اینکه تجربهشان چگونه است. طولی نکشید که ورود یکپارچه بخشی از چشمانداز او شد تا مشتریان دیگر نگران مدیریت کاربران نباشند.
علاوه بر این، دانستن اینکه مشتری شما به کجا میرود برای چشمانداز و برنامههای آیندهتان بسیار مفید خواهد بود. مثلا فرض کنید کشف میکنید بیشتر مشتریانتان بر پایه استک Microsoft هستند و برنامه دارند به سرویس ابر Microsoft Azure بروند. هرچند شاید هنوز تصمیم نگرفته باشید از کدام ابر ارائهدهنده استفاده کنید، منطقی است تا حد ممکن به جایی بروید که مشتریانتان آنجا هستند، تا اصطکاک را کاهش دهید. نکته این است که بدون صحبت کردن و شناختن مشتریانتان این را نمیدانستید.
۳.۲.۲ همتای شما
برای حسابهای بزرگتر، توصیه میشود اگر منطقی است همتای خود، یعنی CTO یا VP مهندسی آنها، را بشناسید. یکی از بزرگترین مزایا این است که این رابطه کانالی برای حل مسائل پیش از بزرگ شدنشان ایجاد میکند و همچنین بینشی درباره تفکر و برنامههای آنها به شما میدهد. با استفاده از این رابطه، در بهترین موقعیت هستید تا مطمئن شوید چشمانداز و برنامههایتان از چشمانداز و برنامههای آنها پشتیبانی میکند. این رابطه ویژه میتواند در زمانی که سردرگمی فراگیر است نتایج مثبتی به همراه داشته باشد. چند بار در موقعیتی بودهاید که به شما گفتهاند مشتری ویژگی X را خواسته، و وقتی این درخواست را میشنوید گیج میشوید؟ این درخواست از زنجیره پایین آمده و توسط توسعه محصول بررسی شده است، و فقط همینطور به شما اطمینان داده میشود. با این حال چیزی در دلتان درست نمینشیند. از چه کسی میپرسید؟ بازی تلفن را که شاید در کودکی بازی کرده باشید به یاد بیاورید. در دایرهای مینشینید، چیزی در گوش نفر سمت چپتان زمزمه میکنید، او باید همان را به سمت چپ خود زمزمه کند و همینطور ادامه مییابد تا به شما برگردد. چیزی که در گوش راستتان میشنوید همان چیزی نیست که اول گفته بودید. اما وقتی از فردی به فرد دیگر منتقل شده، هرکس آن را تفسیر کرده و با واژههای خودش چیزی را که فکر کرده شنیده بازگو کرده است. کسبوکار فقط یک بازی بزرگ تلفن است. اغلب درخواستهای مشتری اینگونه به شما میرسند و به همین دلیل دانش شما از نحوه تعامل آنها و رابطه ویژهتان میتواند وارد شود و روز را نجات دهد؛ با طلب شفافیتی که حستان به شما هشدار میداد. گاهی باید پرسش پایهای را از آنها بپرسید: چه چیزی را میخواهید حل کنید؟ مشتریان موجودات افسانهای نیستند که همیشه حق داشته باشند و باید اطاعت شوند. آنها افرادی با کسبوکارهایی مانند شما هستند که میکوشند به نفع مشتریانشان مسئله حل کنند. هر چیزی که آنها با آن دستوپنجه نرم میکنند ممکن است مشکل شما هم بشود. وضعیتی که این موضوع معمولا در آن رخ میدهد زمانی است که مشتریان جهشهای رشد را تجربه میکنند و ناگهان بیشتر زیر ذرهبین قرار میگیرند؛ مثلا وقتی به سطحی میرسند یا وارد بازار جغرافیایی تازهای میشوند که به انطباق یا اعتبارسنجی نیاز دارد. کمک به مشتری برای آسیب نزدن، احتمالا یکی از مهمترین و سودمندترین پیامدهای جانبی شریک بودن با اوست.
از دل میدان: فایل ایمیلی ناامن
با مشتریای کار کردم که مبادله داده اصلیاش ساختن یک فایل و سپس ایمیل کردن روزانه آن به مشتری بود. مسئله اصلی این بود که این فایل دادههای حساس زیادی داشت و از مکانیزم انتقالی عبور میکرد که ذاتا ناامن است. مشتری اصرار داشت آن را با ایمیل لازم دارد. CTO شرکت هنوز تازهکار بود و احساس نمیکرد اختیار دارد این درخواست را به مشتری رد کند. وقتی پس از شنیدن این موضوع دوباره کنترل قلبم را به دست آوردم و ضربانش را به حالت عادی برگرداندم، نکات گفتوگوی لازم را به CTO دادم تا گفتوگو با مشتری را باز کند و بفهمد چرا احساس میکنند این اطلاعات را با ایمیل لازم دارند. معلوم شد ایمیل فقط راهی بوده تا کاربر بتواند اطلاعات را بهسادگی در یک اشتراک شبکه سمت خود ذخیره کند. چون کاربر هر صبح از قبل با پورتال خودشان تعامل داشت، CTO یک قابلیت دانلود فایل اضافه کرد تا بتوانند آن را از همانجا دریافت کنند. همه بسیار خوشحالتر شدند، چون داده اکنون ثبت میشد و از کانالی امن منتقل میشد، بدون اینکه کسی آبرو از دست بدهد.
برخی مشتریان از نظر فناوری از شما جلوترند؛ برخی نیستند. برای آنهایی که جلوترند، آرزو کنید بیشتر شبیهشان شوید و از چشماندازشان بیاموزید. برای آنهایی که عقبترند، راههایی پیدا کنید که کمکشان کنید ناخواسته خود را در معرض ریسک غیرضروری قرار ندهند.
چشمانداز شما باید مصرف پاییندستی خدماتتان را در خود وارد کند، یا دستکم به آن توجهی داشته باشد. به این شکل مرتبط میمانید و پیش از وقوع سردردهای احتمالی از آنها جلوگیری میکنید.
۳.۳ برنامهریزی بلندمدت
همانطور که اشاره کردهام، اگر چشمانداز شما در چند ماه قابل اجرا باشد، دیگر چشمانداز نیست بلکه پروژه است. چشمانداز تلاشی چندپروژهای است که شاید تکمیل آن سالها طول بکشد. چشماندازها معمولا ماهیتی انقلابی دارند، اما اگر شرکت در میانه تغییر تحولآفرین باشد میتوانند تکاملی هم باشند. هرچند بیسابقه نیست، نادر است پروژهای آنقدر بزرگ باشد که سالها طول بکشد تا هر نوع تحویلدادنی داشته باشید. اگر در چنین وضعیتی قرار گرفتید، فرض کنید چیزی را جا انداختهاید و برگردید و خودتان را به چالش بکشید تا تحویلدادنیهای کوچکتری پیدا کنید، حتی اگر به معنای رفتن از مسیر کمی متفاوت باشد. بخش بعدی بررسی میکند برای تبدیل چشماندازتان به برنامهای قابل اقدام که برای کسبوکار پذیرفتنی باشد چه لازم است.
۳.۳.۱ زمانبندی همه چیز است
چشماندازهای بزرگ برای برنامهریزی، زمانبندی و اجرا تلاش زیادی میطلبند. چشمانداز خوب از ضرورت میآید، نه از اینکه «کاری برای انجام دادن» باشد. مثالهای خوب پروژههای بازتصور هستند که در آنها سیستمهای legacy زیر نوسازی و ارتقای سنگین میروند؛ مانند شرکت HomeMax ما. اینها میتوانند تلاشهایی چندساله باشند، در حالی که همزمان باید سیستم موجود را نگه داشت و پشتیبانی کرد. هنگام پرداختن به چنین پروژه بالقوه مختلکننده اما پاداشدهندهای، باید بسیار آگاه باشید که کسبوکار چگونه واکنش نشان میدهد و اشتهایش برای حمایت از شما، هم مالی و هم از نظر صبر، چقدر قوی است. اگر هیچکدام را تأمین نکنید، پیش از اینکه حتی یک خط کد ببرید یا یک سرویس را روشن کنید، محکوم به شکستید. باید مانند کسبوکار فکر کنید: پیش از امضا کردن، چه چیزی لازم داشتید تا قانع شوید؟ نخستین چیزی که باید در نظر بگیرید برنامه زمانی شرکتتان است. آیا کسبوکاری فصلی هستید؟ کم پیش میآید شرکتی هیچ دورهای از سال نداشته باشد که دوره ممنوعیت تغییر باشد. برای مثال، شرکتهای خردهفروشی، چه آنلاین و چه آفلاین، به احتمال زیاد در دورههای سنگین فروش مانند فروشهای پس از Thanksgiving یا فصل Christmas هیچ تغییر یا انتشار بزرگی نمیخواهند، در حالی که شرکتهای آموزشی دوست ندارند در آغاز سال تحصیلی یا اطراف زمان امتحان تغییری ببینند. این دورهها را شناسایی کنید و مطمئن شوید مطابق آن برنامه میریزید. برای سازمانهایی که چنین زمانهای فصلی دارند، وقتی این زمانها در نظر گرفته شوند، میتوانند هر سال سه یا چهار ماه زمان مهندسی را از توسعههای جدید بگیرند، چون منابع باید برای پشتیبانی سیستمها جابهجا شوند. زمان لازم برای تغییر زمینه تیم بین پروژهها را دستکم نگیرید، بهخصوص اگر تیم از نوامبر تا ژانویه چند ماهی از پروژه دور بوده و تعطیلات هم وارد ترکیب شده باشد. دومین نکته، تحمل شرکت برای صبر کردن تا تحقق چشمانداز شماست. روشن بگویم: هرچه در آغاز بگویند، هرگز مانند شما صبر تحویل را ندارند. بیتردید پرسش «فیل را چگونه میخورید؟» را شنیدهاید؛ یعنی پروژه آنقدر بزرگ است که نمیتوانید تصور کنید چگونه انجام میشود. اما پاسخ ساده است: «هر بار یک لقمه»، که روش خوبی است برای گفتن اینکه باید مسئله را به تکههای کوچکتر و قابل خوردن تقسیم کرد. چشمانداز شما هم همینطور است؛ باید آن را به لقمههای کوچک تقسیم کنید تا کسبوکار بتواند از آن تغذیه کند و حس پیشرفت داشته باشد. حوزههایی را شناسایی کنید که میتوانید جداشان کنید و به کسبوکار تحویل دهید. اینها باید مواردی باشند که کسبوکار بتواند بلافاصله منفعت واقعی از آنها بگیرد.
از دل میدان: اول یک گام کوتاه، بعد یک پرش
شرکت سرمایهگذاری خصوصی من را آورد تا برنامه یک CTO را بررسی کنم، چون از بلندپروازی برنامه کمی نگران بودند. برنامه خوب بود: پروژهای برای نوسازی، کاهش اتکا به دیتاسنتر و شروع استفاده از مزایای ابر. مسئله این بود که CTO جهشی بیش از حد بزرگ برمیداشت؛ از ذهنیت بسیار سنتی سرور به معماری ابرزاد میرفت؛ تغییر بیش از حد، با ریسک بسیار بزرگ. پیشنهاد کردم برنامه به گامهای کوچکتری نیاز دارد تا کسبوکار گرم شود و او چند برد به دست آورد تا اعتماد و باور به چشماندازش ساخته شود. این شامل شناسایی سرورهای قدیمیتر و انتقال آنها به ابر بهجای تمدید سختافزار بود. بله، کاملا ابرزاد نبود، اما با کاهش اتکا به سختافزار، به سمت چشمانداز پیش میرفتیم، اجازه میدادیم کسبوکار در مسیر مزایا را ببیند و همه را با این دنیای تازه رایانش مجازی گرم میکردیم؛ چیزی که به او زمان خرید تا به حرکت رو به جلو ادامه دهد.
وقتی کسبوکار بتواند زود و مکرر منافع چشمانداز شما را ببیند، اشتهایش برای ادامه حمایت و تأمین مالی شما کم نمیشود. در زمانهای نادر، یا شاید معمول، که خود را در حال لغزش میبینید، داشتن تحویلدادنیهایی که قبلا تحویل دادهاید به کسبوکار اعتماد میدهد که بیش از تحمل معمول به شما اعتماد کند. ضعیفترین موقعیت این است که پروژه حس کند بزرگتر میشود، بیشتر طول میکشد و تاریخ انتشار هرچه دورتر و دورتر میرود. رهبری شما زیر سؤال میرود و کسبوکار ممکن است اعتمادش را از دست بدهد و تأمین مالی شما را کلا قطع کند. بله، این بدترین سناریو است، اما حتی با نیتهای خوب نادر نیست.
بدینوسیله این را نامگذاری میکنم
نمیتوانم بگویم چند بار نشستهام و به CTO هیجانزدهای گوش دادهام که از چشماندازش میگوید، همه منافع را شرح میدهد و چالشها و پاداشهای آن سوی مسیر را یادآوری میکند. اما وقتی میپرسم اسمش را چه گذاشتهاند، فقط نگاه خالی میبینم. اسم؟
ما چیزها را نامگذاری میکنیم تا به آنها شخصیت و احساس بدهیم. به چیزهای نامدار دل میبندیم و بنابراین میخواهیم موفق شوند. به همین دلیل برای سه پسرم اسم گذاشتم، بهجای اینکه صرفا بگویم کودک شماره ۱، کودک شماره ۲ و کودک شماره ۳؛ که راستش بسیار آسانتر بود. نام خوب پروژه به چشمانداز شما جان میدهد و میگذارد همه از نظر احساسی در آن سرمایهگذاری کنند.
در نامگذاری بیش از حد زرنگبازی درنیاورید، چون این فقط نامی داخلی است؛ اما هر از گاهی نام خوب میتواند بیرون هم راه پیدا کند، پس با فکر انتخاب کنید. به نظر من خوب است آن را تمرینی مشارکتی کنید تا همه احساس کنند فرصت اظهار نظر دارند. گاهی این نامها میتوانند حول یک تم باشند؛ مثلا Lord of the Rings، یا Star Wars کلاسیک میتواند میدان غنیای برای انتخاب باشد؛ پروژههای انبار داده بزرگ گرایش دارند «Death Star» نامیده شوند. نام خوبی مانند Project Gandalf، که دیدهام برای پروژه تحول legacy استفاده شده بود و پروژه دو فاز داشت: Gandalf-the-Gray و سپس Gandalf-the-White، یا Codename Borg، برای توصیف ساخت یک انبار داده بزرگ، همگی با روایت خودشان کمک میکردند مردم تصور کنند و بر هدف کلی متمرکز بمانند. یکی از بهترین نامهایی که دیدم Gump Platform بود. سیستمی برای مدیریت دستگاههای Internet of Things (IoT) بود و یکی از نیازمندیهای اصلیاش این بود که همیشه به کار ادامه دهد؛ به یاد بیاورید به Forrest Gump توصیه شده بود فقط به دویدن ادامه بدهد.
۳.۳.۲ در ذهن داشته باشید
وقتی میخواهید برنامه چشماندازتان را بچینید، باید درباره موارد زیر فکر کنید:
- مسئله کلیای که میخواهید حل کنید چیست؟ شناسایی مسئلههایی که میخواهید حل کنید پاسخ دادن به پرسش «چرا» را آسانتر میکند، وقتی کسبوکار از شما میخواهد چشماندازتان را توجیه کنید.
- منافع برای شرکت و/یا مشتری چیست؟ پاداشهایی را برجسته کنید که چشماندازتان برای کسبوکار و مشتری میآورد. این میتواند توان انعطافپذیری بیشتر در برابر خواستههای مشتری یا گشودن فرصتهای تازه باشد.
- آیا به زمان حساس است؟ اگر چشماندازتان هر زمانی میتواند شروع شود، عالی است. اما اگر در سال زمانهایی بهتر از زمانهای دیگر وجود دارد، این را برجسته کنید و آن را فرصتی برای برنامهریزی بیشتر بدانید.
- معیارهای موفقیت شما چیست؟ آیا با کسبوکار همراستاست؟ شناسایی سنجههای موفقیت برای دانستن اینکه چه زمانی تمام کردهاید حیاتی است. فکر کنید کسبوکار ابتکار شما را چگونه تفسیر میکند و موفقیت را چگونه رتبهبندی میکند. به یاد داشته باشید درد شما لزوما درد آنها نیست.
- افراد اصلیای که برای موفقیت نیاز دارید چه کسانیاند؟ اگر برای موفقیت چشماندازتان به افراد کلیدی نیاز دارید، آنها برای اداره روزمره کسبوکار چقدر حیاتیاند، و چگونه میتوانید غیبتشان را جایگزینسازی یا کماثر کنید؟
- آیا این اساسا پروژه نوسازی/بازتصور است؟ آیا میخواهید یک بخش قدیمی از سیستمهای legacy را مدرن کنید؟ هرچند این ممکن است بسیاری از مشکلات شما را حل کند، مشتریان و کسبوکار ممکن است کاملا راضی باشند؛ پس باید کمی خلاقانهتر فکر کنید که چرا به دنبال تغییر وضع موجود هستید.
- این چه اثری بر تداوم کسبوکار خواهد داشت؟ ابتکارهای بزرگ همیشه حواسپرتی ایجاد میکنند. این برای دپارتمان شما و کسبوکار چه معنایی دارد؟ حتی اگر برای منابع اضافی برنامهریزی میکنید، کسی باید آنها را مدیریت کند و این کار از روشن نگه داشتن سیستمهای موجود کم خواهد کرد.
آماده بودن برای اثر چشماندازتان کمک میکند همه ملاحظات را مرور کنید، تا وقتی کسبوکار شما را تحت فشار گذاشت، بتوانید نشان دهید همه نگرانیهایشان را در نظر گرفتهاید. اشکالی ندارد همه پاسخها را نداشته باشید. شناسایی حوزهای که در آن به ورودی بیشتر نیاز دارید، بسیار پذیرفتنیتر از این است که همان لحظه پاسخی بلوفگونه بدهید و بعدا همان پاسخ گریبانتان را بگیرد.
۳.۴ وارد کردن جابهجاییهای لرزهای
توجه کردهاید که ما در یکی از پویاترین و متغیرترین صنایع هستیم؟ چیزی که سال گذشته لبه نوآوری محسوب میشد اکنون یا بالغ شده و بهعنوان جریان اصلی پذیرفته شده، یا رنگ باخته و فراموش شده است. ما در محیطی همیشه در حال تغییر هستیم که گاهی ترسناک به نظر میرسد و این فکر را باقی میگذارد که همیشه در حال عقبافتادن هستید. این طبیعی است و باید پذیرفته شود. تصمیم درست درباره یک فناوری خاص خود نوعی هنر است و حوزهای است که بعدتر در فصل به آن پرداخته میشود. اما برای تمرکز این موضوع، نگاه میکنیم چگونه یک محیط در حال تغییر را وارد برنامههای بلندمدت خود کنید. در سفری چندساله، چیزی که در آغاز پروژه بالقوه پرریسک دانسته میشد، ممکن است دو یا سه سال بعد به هنجار تبدیل شده باشد. آخرین کاری که میخواهید انجام دهید تحویل چیزی است که پیش از انتشار از قبل کهنه شده باشد.
۳.۴.۱ فلج تصمیمگیری
رنج کشیدن بر سر اینکه آیا یک مسیر مشخص درست است یا نه، اتلاف وقت و محروم کردن خود از فرصت تغییر جهت است. وقتی پای فناوری در میان است، هر تصمیمی بهتر از بیتصمیمی است. چیزی که در آن زمان، با توجه به همه دادهها و استدلالها، درست است، همیشه مسیر درست خواهد بود.
از دل میدان: احساس گناه شروعکننده
هیچکس دوست ندارد فکر کند تصمیم اشتباهی گرفته است؛ بنابراین وقتی CTO مسیر مشخصی را انتخاب میکند، گاهی چیزی دارد که من آن را «احساس گناه شروعکننده» مینامم؛ چیزی بیشباهت به پشیمانی خریدار نیست، همان حس که انتخاب اشتباهی کردهاید. همه ما در مقطعی آن را حس میکنیم و از خود میپرسیم آیا فرد دیگری هم همین تصمیم را میگرفت. این حس که به syndrome impostor هم مرتبط است، موضوعی که بعدتر به آن میپردازم، این است که موفقیت کل پروژه به همان یک تصمیم وابسته است و اگر اشتباه باشد همه چیز محکوم است. نگران نباشید؛ هیچ تصمیمی برگشتناپذیر نیست، یا دستکم نمیتواند یک اصلاح مسیر کوچک را تحمل نکند.
بگذارید شما را از راز کوچک پروژههای بزرگ و بلندمدت آگاه کنم: چیزها تغییر میکنند، و اغلب با یادگیری و کشف بیشتر ما تغییر میکنند. اشکالی ندارد برخی فرضهای اولیهمان را تغییر دهیم و دوباره دربارهشان فکر کنیم. کلید کار پیدا کردن چارچوب یا روشی است که تغییر را بدون برگرداندن ساعت به صفر، ممکن و پذیرا کند. این بخش چارچوب فکریای پیشنهاد میکند که به شما اجازه میدهد بدون به خطر انداختن کل پروژه، تغییر را جا دهید.
۳.۴.۲ ستونهای چشمانداز خود را شناسایی کنید
همه ما اهمیت فونداسیون خوب برای پایداری و استحکام خانهای را که بر آن ساخته میشود میدانیم. در دنیای فناوری ما هم باید فونداسیون خوبی داشته باشیم که بتوانیم روی آن بسازیم و شرکت خود را موفق کنیم. اگر فونداسیونی لرزان داشته باشیم که در برابر نیروهای بیرونی تحمل ندارد، هرچه بسازیم همیشه نقطه ضعف خواهد بود. شما به فونداسیونی خوب نیاز دارید؛ اگر بخواهید، ستونهایی که از پروژه شما پشتیبانی کنند. مزیت فکر کردن به فونداسیون بهعنوان ستون این است که هر ستون مشخصی میتواند جایگزین شود، تا وقتی بقیه همچنان کار میکنند و از چشماندازتان پشتیبانی میکنند. عقب بنشینید و فکر کنید ستونهای شما چیست. اینها بزرگترین مؤلفههایی هستند که برای پشتیبانی از اجرای چشماندازتان باید به آنها تکیه کنید. برای روشن شدن، چند مثال ببینیم. فرض کنید تصمیم گرفتهاید بهعنوان بخشی از چشماندازتان به سمت معماری API-محور حرکت کنید تا واحدهای کسبوکار و مشتریان بتوانند به دادهها و خدماتی که لازم دارند دسترسی پیدا کنند. ستون اینجا مکانیزمی خواهد بود که از طریق آن نقطه پایانیهای API را به شکلی امن و مقیاسپذیر ارائه خواهید کرد. فرض کنیم برای توکن امنیتی خود HTTP REST نقطه پایانیها با JWT را انتخاب میکنید. این زبان یا چارچوب شما را محدود نمیکند، اما تفکرتان را به یک روششناسی محدود کرده تا بتوانید بر پیادهسازیهایتان تمرکز کنید. مثال دیگر اینکه چشماندازتان تشخیص داده جمعآوری و مدیریت داده مؤلفهای بزرگ است و باید بتوانید حجمهای بزرگ را بدون افت عملکرد ذخیره کنید. ستون شما اینجا ذخیرهسازی و مدیریت داده است. سخت شروع نکنیم؛ یک دریاچه داده بسازید، که اصطلاحی شیک برای فضای ذخیرهسازی بزرگی است که میتواند هر نوع دادهای را بگیرد، تا بتوانید داده را آنجا پارک کنید و بعدا تصمیم بگیرید چگونه و کجا آن را تبدیل کنید. برای مثال، AWS S3 نقطه شروع بسیار خوبی است. شناسایی حوزهها یا ستونها، علم یا قواعد کسبوکاری نیست که باید بسازید؛ بلکه حوزههایی است که در حالت ایدهآل دوست دارید برونسپاری کنید، از جمله استفاده از چارچوب یا کتابخانه، تا بدون دردسر یا نگهداری روزمره به شما خدمات بدهند. اینها خدماتی هستند که میتوانید آنها را کالای پایههایی بدانید که چشماندازتان بر آنها تکیه دارد.
۳.۴.۳ پایش ستونها
پس از شناسایی ستونها، باید فعالانه تکاملشان را زیر نظر داشته باشید. میخواهید ببینید چگونه بالغ و پذیرفته میشوند تا بفهمید چطور میتوانید آنها را بدون اختلال زیاد وارد چشماندازتان کنید. اگر ستون را درست شناسایی کرده باشید، یعنی چیزی که خاص کسبوکار شما نیست اما به آن تکیه دارید، جایی کسی در تلاش است آن را کالاییسازی کند.
از دل میدان: Cloud، واژهای دیگر برای کالاییسازی
کالاییسازی زمانی است که یک فرایند یا فناوری به نقطهای میرسد که نقش، نوآوری و رقابت در یک فضا به وضعیت قابل قبولی میرسد. سرورهای وب و ایمیل دو مثال خوباند. اخیرا پایگاههای داده هم وارد همین جهان شدهاند، چون اجرا و نگهداری خوشه سرورهای پایگاه داده خودتان در مقایسه با خرید پایگاهداده بهعنوان خدمت از یکی از ابر ارائهدهندههای بزرگ، بیش از حد پرهزینه است. در روزگار قدیم باید تیمی کامل از DBAها برای نگهداری پشتیبانگیریها، بهینهسازیها و جابجایی هنگام خرابی داشتید، در حالی که اکنون همه اینها فقط یک کلیک در پنجره مرورگر فاصله دارند. برخی این را از دست دادن کنترل میبینند، اما در واقع یعنی بخش بزرگی از فناوری را دیگر لازم نیست مدیریت کنید.
با هر معمار سنتی صحبت کنید، به شما میگوید فونداسیون خوب فونداسیونی است که دسترسپذیر باشد. اگر دیدید یکی از ستونهایتان از یک جابهجایی لرزهای عبور میکند و در جهت متفاوتی جا افتاده است، باید یک تیم کوچک جداگانه اختصاص دهید تا بررسی کند آیا واقعا زمان چرخش کردن به سمت آن تغییر رسیده یا نه. تیم جداگانه کوچک تیم کوچکی است که برای چند روز راه میافتد تا در حوزهای بسیار باریک عمیقتر شود و اطلاعات لازم را بیاورد تا بتوانید تصمیمهای آگاهانهتری بگیرید. اگر سیستم خود را درست طراحی کرده باشید، این تغییر باید نسبتا روان و بدون دردسر زیاد باشد؛ در فصلهای بعدی بحث میکنم چگونه در طراحی خوب و تحملپذیر نسبت به تغییر، خود را عایق کنید. برای ابتکارهای بلندمدت، انتظار میرود که لازم باشد چند قدم عقب بروید تا بتوانید به جلو بپرید. با این حال، این رویکرد فقط باید برای قطعات بنیادین بزرگ پذیرفته شود. تغییر چارچوبها یا زبانها در همان رده ستونهای بنیادین نیست. اینها مختلکنندهترند و میتوانند موفقیت پروژه را به خطر بیندازند، چون حوزههایی نیاز به توسعه دوباره پیدا میکنند. چنین تصمیمهایی نیز از آغاز به همان اندازه مهماند، اما سطحشان کلانتر است. اینکه در آن زمان چگونه این تصمیمها را برای تیمتان میگیرید در فصل بعدی شرح داده میشود.
۳.۴.۴ جستوجوی سادگی
امیدوارم یکی از اهداف چشماندازتان کاهش پیچیدگی و سربار کلی باشد. هر چیزی که شما را به آن نزدیکتر کند باید بررسی و پذیرفته شود. آخرین چیزی که میخواهید افزایش مسئولیتهای نگهداری روزمره است که به هسته کسبوکار مربوط نیست.
از دل میدان: هزینه غرقشده
همانطور که یک بازیکن خوب پوکر به شما میگوید، وقتی میبینید دستتان دیگر برنده نمیشود، مهم نیست تا اینجا چقدر پول شرط بستهاید؛ بیرون بکشید. در کسبوکار به این فرایند تصمیمگیری هزینه غرقشده میگویند. همان حسی است که چون تا اینجا خیلی سرمایهگذاری کردهاید، باید آن را تا پایان ببینید، حتی اگر بدانید احتمال موفقیت اندک است. این را بارها دیدهام و معمولا AWS یا Azure آمده و بازی را عوض کرده است. تیمهایی را دیدهام که سیستمهای پیچیده و مفصل ساختهاند، فقط برای اینکه AWS با یک سرویس پرداخت به میزان مصرف تلاشهایشان را کاملا «باطل و بیاثر» کند. پرسش آنوقت این میشود: آیا باید به چیزی که توسعه دادهاند بچسبند یا منتقل شوند؟ در آغاز پاسخ همیشه این است که با چیزی که دارید بمانید؛ بگذارید سرویس جا بیفتد و زمان بگذارید تا تأیید کنید همه چیزهایی را که نیاز دارید دارد. بهمحض اینکه داشت، منتقل شوید، بار عملیاتی خود را کاهش دهید و به چالش بعدی پروژه بروید. زندگی وقتی قطعات کمتری برای مدیریت دارید سادهتر است.
در روزگاری که کلانداده همهجا پرطرفدار بود، ابزار مد روز Apache Hadoop بود؛ سیستمی برای مدیریت مجموعهدادههای بزرگ روی چند ماشین به شکل افزونهدار. ابزار بزرگی بود اما مدیریت و نگهداریاش کابوس بود. با این حال، واقعا تنها گزینه جدی برای مدیریت مجموعهدادههایی بود که روی یک دیسک سخت جا نمیشدند. این مجموعه مهارت آنقدر داغ و پرتقاضا بود که کسانی که مهارت Hadoop داشتند دستمزدهای بالایی طلب میکردند. یکشبه این زیرصنعت ناپدید شد، وقتی ابر ارائهدهندهها پیشنهادهای کلانداده بهعنوان خدمت خود را ارائه کردند؛ مثلا سرویس Amazon S3. هرچند این ضربه بزرگی به کسانی بود که در این حوزه تخصص داشتند، برای شرکتهایی که میخواستند از این حوزه بدون سربار Hadoop استفاده کنند سود بزرگی بود. چیزها تغییر خواهند کرد و میکنند. هنگام نگارش این متن، صنعت در زمینه مدیریت سرورها از یکی از همین تغییرات لرزهای عبور میکند؛ با تشویق شما به کنار گذاشتن حتی آن نیاز پایهای: «رایانش بدون سرور»، هنر نیاز نداشتن به مدیریت هیچ سروری. بسیاری از پروژههای داخلی دور ریخته میشوند، چون دنیای serverless خود را ثابت میکند و پذیرفته میشود. برنامه چشمانداز قوی اجازه تغییر میدهد و آن را بهعنوان بردی برای کاهش کلی پیچیدگی میپذیرد.
۳.۵ ارائه آسانسوری
یک کاری که باید بتوانید بدون فکر انجام دهید این است که چشماندازتان را برای هر کسی که میپرسد، مختصر و آسانفهم توضیح دهید. به همه مجموعه مهارتها و پیشینههای متفاوت افراد در شرکتتان فکر کنید. فکر کنید چگونه چشماندازتان را برای آنها توضیح میدهید، با دانستن اینکه به احتمال زیاد در نقطهای تحت تأثیر قرار خواهند گرفت، تا آنها هم بتوانند در هیجان شریک شوند و بخشی از سفر باشند. برای بعضیها این کار میتواند بسیار دشوار باشد؛ اینکه توضیحاتشان را از حالت بیش از حد فنی خارج کنند تا هر کسی بفهمد. این مهارتی است که پس از تسلط، میتوان بارها و بارها در همه جنبههای نقش شما بهعنوان رهبر فناوری از آن استفاده کرد؛ بهویژه وقتی تلاش میکنید برای مادرتان توضیح دهید چه کار میکنید؛ «او با کامپیوتر کار میکند» نهایت چیزی بود که مادرم میتوانست به دوستانش توضیح دهد. در کسبوکار عبارت رایجی داریم که آن را ارائه آسانسوری مینامیم. اساسا توضیح کوتاهی است که میتوان آن را در حدود ۳۰ ثانیه طوری بیان کرد که هر شنوندهای بفهمد چه میگویید. این روش به راهی محبوب تبدیل شد برای پرسیدن اینکه آیا ایده استارتاپ خود را آنقدر صیقل دادهاید که اگر به سرمایهگذاری برخوردید، بتوانید بهراحتی برایش توضیح دهید و امیدوارانه آنها را برای سرمایهگذاری شگفتزده کنید.
تاریخچه: ارائه آسانسوری
درباره منشأ این اصطلاح اجماعی وجود ندارد. برخی ادعا میکنند از دهه ۱۹۹۰ آمده؛ برخی آن را به دهه ۱۹۷۰ نسبت میدهند، و یک روایت تا دهه ۱۸۵۰ عقب میرود، زمانی که Otis آسانسور اولیه را توسعه داد. روایتی که من ترجیح میدهم، چون مرتبطتر به نظر میرسد، درباره دو روزنامهنگار Vanity Fair است که هیچوقت نمیتوانستند سردبیرشان را گیر بیاورند تا ایدههای داستانی را ارائه کنند. برای حل این مشکل، در مسیر آسانسور همراهش میشدند و فکرهایشان را به او ارائه میکردند.
این بخش درباره این است که چه چیزی ارائه آسانسوری خوب میسازد و چگونه میتوانید آن را تمرین کنید تا اجباری یا غیرطبیعی به نظر نرسد. هرچند به آن «ارائه» شما میگوییم، در واقع طرح کلی شماست، چون امیدواریم وقتی آن را برای دیگران توضیح میدهید، CEO/هیئتمدیره آن را تأیید کرده باشد و شما در مسیر برنامهریزی و اجرا باشید.
۳.۵.۱ ساختن ارائه خود
وقتی از CTO تازهکاری میپرسید ارائه چشماندازش چیست، اغلب چهرهای هراسان شکل میگیرد و بعد شروع میکند به پرحرفی، با واژههای عالی فراوان که همهشان با جزئیات وحشتناک و واژههای مد روز فناوری زیاد همراهاند. کاملا طبیعی است؛ بیایید تلاش کنیم به آن بپردازیم.
مسئله محتوا نیست، بلکه ارائه و وارد کردن آن به قالبی است که طبیعی، ریتمدار و بالاتر از همه، درگیرکننده باشد. چند گام را مرور کنیم که کمک میکند چشماندازتان را به مجموعهای از گزارهها تبدیل کنید؛ گزارههایی که حتی شنوندهای با کمترین آمادگی فناوری را جلو بکشد و به پرسیدن بیشتر وادارد:
- تا پنج مورد بنویسید که منافع چشماندازتان را برای کارکنان یا مشتریان توصیف کند. اینها دستاوردهایی هستند که کسبوکار یا مشتری پس از تحویل چشمانداز شما میتواند از آنها استفاده کند؛ مثلا بینش بیشتر برای مشتری تا بتواند موفقیت را با مقایسه داده سالبهسال بسنجد.
- تا پنج ویژگی داخلی چشماندازتان را بنویسید. این فهرست شامل ویژگیهایی است که شاید آنها را داخلی شرکت یا حتی دپارتمان خودتان بدانید و بیشتر فناوریمحورند؛ مثلا کاهش سربار همراه با افزایش ظرفیت مدیریت داده از طریق انتقال به پایگاه داده مدیریتشده در ابر.
- از فهرست فاصله بگیرید و آن را دستکم یک شب رها کنید. این مهم است؛ همه چیز برای جا افتادن به زمان نیاز دارد، پس بگذارید مغزتان هنگام خواب این موارد را پردازش کند.
- اکنون ۱۰ مورد دارید؛ موارد تکراری یا ضمنی را حذف کنید تا به فهرستی ششتایی برسید. اگر گام ۳ را انجام داده باشید، این آسان خواهد بود، چون فهرست وقتی در نوری دیگر دیده شود بسیار متفاوت به نظر میرسد. مواردی را پیدا کنید که در واقع یک چیز را میگویند اما با واژههای متفاوت، یا ضمنیاند؛ مثلا اگر به ابر میروید، ضمنی است که اتکای سختافزاری خود را هم کاهش میدهید.
- از شش مورد آخر دستکم یک ساعت فاصله بگیرید. یک بررسی نهایی مطمئن میکند پیش از تمرکز، همان شش مورد درست را دارید.
- شش مورد را به ترتیب اهمیت رتبهبندی کنید. اکنون آنها را از منظر کسبوکار به ترتیب اهمیت بچینید.
- برای هر یک از شش مورد، یک جمله فنی و یک جمله غیرفنی بسازید. با جمله فنی شروع کنید، چون طبیعیتر احساس میشود؛ سپس نسخهای دیگر بنویسید که کسبوکارمحورتر باشد و واژه مد روز یا اصطلاحات تخصصی نداشته باشد.
- آغازگر، همان قلاب، را پیدا کنید. باید جمله آغازینی پیدا کنید که شنونده را درگیر کند و او را برای ۲۰ ثانیه بعد، هنگام مرور فهرستتان، مشتاق نگه دارد. این میتواند گزاره مسئلهای باشد که میخواهید حل کنید، مثل «باید مشتری را در چند ساعت آمادهسازی اولیه کنیم، نه در ماههایی که اکنون طول میکشد»؛ یا تشبیهی به چیزی که میشناسند، مثل «تصور کنید با توانمند کردن مشتریان HomeMax برای خودخدمتی، به Uber گارانتی خانه تبدیل شویم».
به همین سادگی است. آیا فهرست نهایی درست به نظر میرسد؟ آیا همه نکات بزرگ را زدهاید؟ اکنون بگذارید همه اینها مدتی جا بیفتد، پیش از اینکه تمرین بلند گفتن آن را شروع کنید.
۳.۵.۲ تمرین و صیقل دادن ارائه
تا وقتی آن را بلند نگفتهاید، نمیدانید درست صدا میدهد یا نه. چند نفر قابل اعتماد، هم فنی و هم غیرفنی، پیدا کنید تا جملههای آغازینتان را روی آنها امتحان کنید. چند بار اول درست از آب درنمیآید. دلسرد نشوید؛ این چیزی است که با تمرین بهتر میشود. آغازگر باید همیشه یکسان باشد، اما بسته به مخاطب میتوانید نسخههای فنی و کسبوکاری هر ویژگی مورد را که شناسایی کردهاید جابهجا کنید. در ابتدا غیرطبیعی و اجباری احساس میشود. هرچه بیشتر انجامش دهید، واژهها هنگام خروج از دهانتان آشناتر صدا میدهند. هر بار، با خواندن زبان بدن فردی که روبهرویتان ایستاده است، راههای کمی متفاوت برای گفتن همان چیز پیدا میکنید. هرچه بیشتر انجام دهید، کمتر رباتوار و از پیش نوشتهشده خواهد بود. شخصیت طبیعی شما بیرون میآید و هیجانی که حس میکنید در نحوه ارائه کردنتان آشکار خواهد شد. تکرار همه اضطرابهای «شب اول» را از بین میبرد و اجازه میدهد در واژهها آرام شوید، تا وقتی لازم شد بدون اطلاع قبلی ارائهاش کنید، به شکلی بیرون بیاید که شنونده را درگیر کند و او را به پرسیدن اطلاعات بیشتر وادارد. موفقیت با دیدن اینکه فرد به اندازه شما هیجانزده میشود، درگیر مجموعهای از پرسشها میشود و جزئیات بیشتر میخواهد سنجیده میشود. ارائه شما مردم را همراه میکند، حمایتشان را میآورد تا زمان لازم برای انجام کارها به شما داده شود. بهعنوان مثال، ارائه برای HomeMax میتواند چنین باشد: با اجازه دادن به مشتریان برای مدیریت دادههای خودشان روی دستگاه موبایل یا مرورگر، بار کلی مرکز تماس را کاهش میدهیم، در حالی که کیفیت داده را افزایش میدهیم و تعامل را ترویج میکنیم. با حرکت به معماری مدرن و مقیاسپذیر، فرصت یکپارچگی بیشتر با شخص ثالثها را باز میکنیم تا محصولاتی ارائه کنیم که مکمل پیشنهاد ما باشند؛ مثلا ارائه خدمت سالانه خانه برای رسیدگی به موارد کوچک پیش از اینکه به مشکل بزرگ تبدیل شوند. در این ارائه بسیار ساده، نشان دادهایم که هزینههای عملیاتی کلی را کاهش میدهیم؛ به یکی از بزرگترین حوزههای نگرانی، یعنی کیفیت داده، میپردازیم؛ و با ترویج یا اشاره به ابر، مثلا، نشان میدهیم خودمان را برای بازارها و محصولات تازه آماده میکنیم.
۳.۶ کنار هم گذاشتن بودجه
یکی از سختترین کارهایی که ممکن است در مقطعی انجام دهید ساختن بودجه برای چشماندازتان است. بودجه در پایهایترین سطح یعنی این کار چقدر برای شرکت هزینه خواهد داشت. همه ما میدانیم پروژههای نرمافزار و IT به اضافههزینه و تأخیر معروفاند، اما کنترل محکم هزینهها مطمئن میکند کسبوکار در سفر پیادهسازی و تحویل کنار شما میماند. این بخش مؤلفههای اصلی بودجه و اینکه چگونه خودتان را صادق نگه دارید پوشش میدهد تا وقتی لازم شد واکنش نشان دهید، بتوانید بدون ترس زیاد این کار را انجام دهید.
۳.۶.۱ چه چیزهایی را شامل کنید
مشکل رایج بودجهها کمبود جزئیات است. جالب اینجاست که بزرگترین مورد از قلم افتاده، هزینه پرسنل داخلی است. منطق این است که چون این هزینه از قبل برای کسبوکار وجود دارد، چرا باید آن را وارد کرد؟ میتوانید ببینید چرا این خط فکری ناقص است. مسئله این نیست که کسبوکار از قبل هزینه را میپردازد، بلکه این است که این نیروها در اصل برای چه کاری استخدام شدهاند. اگر قرار است بهصورت جزئی یا تماموقت روی چشمانداز شما کار کنند، یعنی بالقوه روی چیز دیگری کار نمیکنند. آیا حوزهای از کسبوکار هست که دیگر خدمت دریافت نکند و به پشتیبانی جایگزین نیاز داشته باشد؟ به احتمال زیاد. در هر صورت، هزینه هر فردی که روی پروژه کار میکند باید حساب شود. حتما افزایش سالانه هزینه حقوقها، و هر پاداش که میخواهید پاداش دهید، را لحاظ کنید، چون بیشتر شرکتها هر سال میخواهند حقوقها را درصد مشخصی افزایش دهند؛ ۲٪ تا ۵٪ بسته به عملکرد/تورم.
از دل میدان: پارادوکس کاهش قیمت ابر
ابر اگر درست استفاده شود سود اقتصادی بزرگی میآورد. برای پروژههایی که چند سال طول میکشند، حتما تورم را وارد کنید؛ واقعیت اقتصادی اینکه بیشتر چیزها سالبهسال گرانتر میشوند. بیشتر خدمات ابر تلاش میکنند هزینه خدمات را پایین بیاورند. تجربه به ما میگوید هرچند این درست است، صرفهجوییها معمولا با افزایش استفاده از دست میروند. چون فکر میکنیم ارزانتر است، بیش از آنچه احتمالا نیاز داریم استفاده میکنیم و باور داریم هنوز کاملا در بودجه است. من این را پارادوکس کاهش قیمت ابر مینامم.
دومین حذف، منابع لازم برای پروژه است. این باید شامل سختافزار، مجوزهای نرمافزاری، خدمات شخص ثالث و منابع ابر باشد. صرفا وارد کردنشان کافی نیست؛ باید بهدرستی با پیشرفت پروژه همخوان و همراستا باشند. برای مثال، اگر کاری در ابر انجام میدهید، هزینههای ابر در چند ماه اول به احتمال زیاد با میانه پروژه یکسان نخواهد بود، چه برسد به نزدیک پایان. با دقت فکر کنید هزینهها چگونه و چه زمانی تغییر میکنند. به دنبال تنظیم انتظار واقعبینانه برای کسبوکار هستید که این کار طی یک دوره زمانی مشخص چقدر هزینه خواهد داشت. هرگز به عادت کنار هم گذاشتن عددهایی نیفتید که فکر میکنید CEO میخواهد ببیند، چون نگران شوک برچسب قیمت هستید؛ یعنی شوک اولیه در برابر هزینه پروژه. از چنین شروع بودجهای ضعیف هیچ خیری بیرون نمیآید.
۳.۶.۲ بودجه را بچینید
بودجه شما به مدل بسیار پیچیدهای نیاز ندارد؛ یک صفحهگسترده ساده کافی است، با ماهها در بالای صفحه و هزینهها در هر ردیف، شکستهشده به هزینههای ماهانه. وقتی نخستین بهترین حدس خود را کامل کردید، نفر بعدی که باید آن را با او مرور کنید CFO است. او میتواند هر ردیف هزینه را بررسی کند، هر هزینه را تأیید یا تنظیم کند تا مطمئن شوید همه هزینهها را درست نشان میدهید. پس از تکمیل این مرور، این سناریوی بهترین حالت شما محسوب میشود؛ سناریویی که همه هزینهها را تا حد ممکن دقیق گرفته است. اکنون آمادهاید چند سناریوی چه-میشود-اگر کنار هم بگذارید تا وقتی CEO یا هیئتمدیره روی بودجه به شما فشار آوردند بتوانید واکنش نشان دهید. کشمکش رایجی وجود دارد که در آن کسبوکار پروژه را سریع-خوب-ارزان (fast-good-cheap) میخواهد. اما معمولا فقط دو مورد از این سه را در یک زمان میتوانیم تحویل دهیم. بنابراین کسبوکار باید انتخاب کند کدام دو مورد را میخواهد. اگر خوب و ارزان میخواهد، باید آماده باشد که بیشتر طول بکشد. اگر سریع و خوب میخواهد، باید انتظار داشته باشد برای کیفیت بالاتر یا منابع بیشتر هزینه بیشتری بپردازد. گزینه سریع و ارزان را انتخاب نمیکنند، چون بیشترشان در دل میدانند رؤیایی احمقانه است، اما این مانع پرسیدنشان نمیشود. مدل سریع-خوب-ارزان در واقع مدل خوبی برای ساخت دو بودجه اضافی است، چون این کار جایی هم برای خزش دامنه فراهم میکند، یعنی جایی که نیازمندیها کمی تغییر میکنند. بودجه اصلی خود را بردارید و فرض کنید به چالش کشیده شدهاید که آن را سریعتر کنید؛ همیشه فرض میکنیم هرچه باشد خوب را میخواهیم. برای تحویل سریعتر چه باید خرج کنید؟ آیا افزایش هزینه نیروهاست یا آوردن پیمانکارهای کوتاهمدت؟ واقعا چقدر میتوانید آن را سریعتر کنید؟ به یاد داشته باشید، همانطور که Warren Buffet گفت: «نمیتوانید با باردار کردن نه زن، یک نوزاد را در یک ماه به دنیا بیاورید.» بعضی چیزها به دلیلی همانقدر طول میکشند. اما آماده باشید وقتی از شما پرسیده شد، هرچند فرضی باشد: اگر پول مسئلهای نبود، چقدر سریع میتوانستید این چشمانداز را تحویل دهید؟ این پرسشی است که دوستان ما در سرمایهگذاری خصوصی اغلب مطرح میکنند، چون معمولا روی خط زمانی فشردهاند و تنها چیزی که میتوانند کنترل کنند جریان پول است. حوزه دیگری که میتوانید درباره آن مذاکره کنید تعداد ویژگیهای درخواستی است؛ آیا چیزی در پروژه هست که اگر لازم نبود، کارها را آسانتر/ارزانتر میکرد؟ همچنین باید به گزینه سریع-ارزان نگاه کنید. هنگام نگاه به این گزینه، لزوما این نیست که میخواهند ارزانتر باشد؛ میتواند صرفا بازتاب مقدار محدودی از منابع داخلی در دسترس باشد، چون آن منابع برای بخشهای دیگر کسبوکار حیاتیاند. اینجا جایی است که میتوانید تعداد قابل توجهی ویژگی را حذف کنید و مشخص کنید کدام موارد را حذف خواهید کرد تا بتوانید این مدل بودجه را برآورده کنید. نگه داشتن این مدلها/گزینهها به شما اجازه میدهد حد بالا و پایین خود را تعیین کنید. همچنین هزینهها را در طول سال یا سالها نقشهبرداری میکند، و وقتی CEO یا CFO به تأیید بودجه نگاه میکند، میتواند این پروژه را با هزینههای رقیب همراستا کند و بهترین زمان برای چراغ سبز دادن به شما را تعیین کند.
۳.۶.۳ پیگیری
نیازی به گفتن نیست، اما ارزش گفتن دارد، که این کار یکباره نیست. وقتی چراغ سبز گرفتید و بر اساس یکی از سناریوها شروع کردید، باید همه بودجهها را دستکم ماهانه بهروز نگه دارید. عادت کنید در پایان هر ماه همه هزینهها را مرور کنید و آنها را با همه صورتحسابها و هزینهها تطبیق دهید تا مطمئن شوید در مسیر هستید. مدیر پروژه شما، با این فرض که نرمافزار پروژهتان بتواند منابع را پیگیری کند، میتواند بگوید دقیقا چه کسی و چه مدت روی پروژه کار کرده است. آیا کسی بیش از زمان برنامهریزیشده مشارکت کرده؟ مراقب منابع بیشبودجهگرفته و کماستفاده باشید. اینها میتوانند شما را به حس کاذب زیر بودجه بودن آرام کنند، اما در واقع ممکن است آن افراد در تعطیلات بوده باشند یا جای دیگری کار کرده باشند و نتوانسته باشند زمانی را که برنامهریزی شده بود صرف کنند. سناریوهای دیگر را هم بهروز نگه دارید. احتمال زیادی هست که وقتی پروژه شروع شد و پس از چند تحویلدادنی موفق، مدیریت واقعا هیجانزده شود و CEO از شما بخواهد برنامههایتان را شتاب دهید کنید. اگر چنین شد، اگر شیر تأمین مالی کمی بیشتر باز شد، باید بتوانید ببینید این چه اثری بر تحویلدادنیهای شما دارد. با همراستا نگه داشتن بودجههای جایگزین، میتوانید به آن پرسش پاسخ دهید، و با تغییر یا تکامل شرایط، چشماندازها ممکن است جذابتر از آنچه در آغاز به نظر میرسیدند شوند. دستکم هر فصل، بودجه فعلی خود را با CFO مرور کنید. او شما را صادق نگه میدارد و مطمئن میشود عددها واقعبینانهاند. بودجهای خوب چیدهشده و بهروز، هرچند میتواند و خواهد توانست تغییر کند، به CEO و هیئتمدیره اعتماد میدهد که در عددها میتوان به شما اعتماد کرد.
۳.۶.۴ بازگشت سرمایه (ROI)
غیرمعمول نیست، بهویژه برای پروژههای چشماندازی، که کسبوکار ROI بخواهد. معنای سادهاش این است: به ازای هر دلار خرجشده، کسبوکار چقدر در عوض دریافت خواهد کرد؟ پیشبینی دقیق این سنجه بسیار سخت است اما ناممکن نیست. برای پروژههایی که به دنبال جایگزینی یا ارتقای سیستمهای legacy هستند، این همان صرفهجویی هزینه خواهد بود. هر مجوز نرمافزاری یا قرارداد پشتیبانیای را که دیگر برای نگهداری لازم نیست، ارتقاهای سختافزاری، و مهمتر از همه، هزینههای مدیریتی کاهشیافته برای مدیریت سیستمها را لحاظ کنید. این آسانترین مورد برای برآورد است. برای انواع دیگر پروژههای چشماندازی، جایی که تغییرات قابل توجهی در نحوه کار کسبوکار ایجاد میکنید، عدد دادن برای گشودن بازارهای تازه کمی سختتر است، بهویژه اگر کسبوکار را آماده میکنید تا سکوی پرتابی برای تنوع یا عمق بیشتر محصول داشته باشد. در این موارد باید سراغ همتایانتان بروید و ورودی آنها را بگیرید تا ببینید آیا میتوانند به شما کمک کنند هزینههای کاهشیافته یا فرصت افزایش درآمد را بفهمید یا نه. گاهی این یک حس جمعی است که کار درستی است، بنابراین ROI سنجه قابل توجیهی برای سنجش نیست. منظور از جمعی این است که کل تیم مدیریت پشت شماست. در مورد شرکت HomeMax ما، ROI میتواند از کاهش تعداد نیرو در مرکز تماس و کاهش هزینه خرید، نگهداری و میزبانی سختافزار فیزیکی محاسبه شود.
۳.۷ برنامهریزی نزدیکمدت و انتظارات
شروع هر پروژه بزرگ همیشه میتواند مسئلهساز باشد. بله، همه هیجانزدهاند، همه انتظار دارند چیزهای بزرگی از آن بیرون بیاید، اما مشکل این است که هر پروژه بزرگ آمادهسازی زیادی لازم دارد. این معمولا چیزهایی پشت صحنه است؛ چیدمان و جریان کد، ابر شکلدهی، طراحی اولیه معماری و غیره، که مؤلفههای واقعا قابل مشاهده ندارند، یا دستکم برای کسبوکار ندارند، و پس از دو یا سه ماه بدون چیزی برای نشان دادن، کسبوکار ممکن است کمی عصبی شود.
از دل میدان: هر خانهای به فونداسیون خوب نیاز دارد
یکی از راههایی که در گذشته این نوع موقعیتها را مدیریت کردهام استفاده از تشبیه ساختن خانه است. کسبوکار معمولا درباره اینکه با هر اتاق چه میتواند بکند، چگونه قرار است تزئین کند و آشپزخانه را چگونه تجهیز کند هیجانزده است. من این اشتیاق را با گفتن اینکه اکنون در مرحله کندن فونداسیون هستیم تعدیل میکنم. وقتی آن تمام شد، میگویم در مرحله لولهکشی یا کشیدن کابل برق هستیم. با ادامه پروژه، آن مرحله را به ساخت خانه تشبیه میکنم؛ بالا رفتن دیوار خشک، نصب شدن درهای داخلی. این انتظار را تنظیم میکند و به کسانی که با پروژههای نرمافزاری آشنا نیستند اجازه میدهد واقعا حس پیشرفت پروژه را درک کنند.
چیزی که از آن جلو میزنیم پیشبینی زمانی است که خستگی کسبوکار شروع به نشستن میکند؛ نقطهای که کسبوکار به پروژه بلندمدت شما نگاه میکند، فراموش میکند قرار بود اینقدر طول بکشد، یا اگر لغزش شروع شده باشد، و شروع میکند به پرسیدن اینکه آیا ادامه دادن ارزش دارد یا نه. این پدیده، دره اندوه، که James Milbery، شریک بنیانگذار ParkerGale Capital نامگذاری کرده و در فصل ۱ توصیف شده، اشتیاق کسبوکار به یک پروژه بلندمدت را ترسیم میکند، و اگر دقت کنید کجای منحنی هستید میتوانید جلوی anguish را بگیرید. این نقطهای است که ممکن است در کسبوکار مخالفانی وجود داشته باشند که در گوش CEO زمزمه میکنند اعتمادشان را به موفقیت این پروژه از دست دادهاند، یا در حال از دست دادن آن هستند. این زمانی است که سیستم legacy قدیمی بسیار جذاب به نظر میرسد؛ نگرش این است که «شیطان آشنا بهتر است». نقش شما این است که مطمئن شوید هرگز وارد دره اندوه نمیشوند، اما اگر دیدید آنجا هستند، باید مسیری برای خروج نشان دهید. بیایید ببینیم چگونه این کار را انجام میدهید.
۳.۷.۱ ارتباطات
کنترل دقیق پروژه و مطمئن شدن از اینکه همه چیز در طول مسیر ثبت میشود، گام نخست است. اکثریت عظیم پروژههای بزرگ میلغزند؛ این واقعیت زندگی است. اما مستند نکردن اینکه چرا میلغزند و ارتباط ندادن آن، کاری جز آماده کردن شما و تیمتان برای شکست نمیکند. کسبوکار باید بداند چه زمانی اتفاقها رخ میدهند و چرا. بسیاری از CTOها دوست ندارند خبر بد بدهند و وقتی چیزها خیلی عقب میافتد، تمایل دارند روی آن را بپوشانند. این نگرش اشتباه است؛ در عوض باید کسبوکار را شرکای خود ببینید که به اندازه شما در موفقیتتان نفع دارند. لغزشها معمولا به دلیل ظاهر شدن منطق کسبوکاری پیشبینینشده یا رسیدگی به اداره روزانه کسبوکار رخ میدهند. این چیزها باید ارتباط داده شوند، و ممکن است از عجیبترین جاها کمک برسد. فراموش نکنید موفقیتها را جشن بگیرید، هر نقطه عطف که میرسد. مراقب دامنه جشن باشید. حتما بردهای کوچکتر، مانند اسپرینتهای موفق، را بهصورت داخلی با گروه خود جشن بگیرید، اما وقتی پای کسبوکار در میان است، توصیه عمومی این است که بیرون از گزارش اینکه پیشرفت خوب پیش میرود، بیش از حد هیجانزده نشوید. زمانی که میخواهید جشن را بزرگتر کنید پس از آن است که ارزشی تحویل دادهاید که کسبوکار میتواند از آن بهره ببرد. این زمانی است که پروژه شما شروع میکند ارزش خود را ثابت کند و هر منفینگری بیجا را دفع کند. صحبت از تحویل به کسبوکار شد، مطمئن شوید در برنامه کلی پروژه زمان قابل توجهی برای آموزش و پشتیبانی کسبوکار گذاشتهاید، وقتی شروع میکنند از تحویلدادنیهای شما استفاده کنند. طبیعی است که درباره لغزش زمان دچار هراس شوید، چون منابع چند هفته مصرف شدهاند تا کسبوکار را آمادهسازی اولیه کنید و برخی ناصافیها را رفع کنید. این مورد انتظار است و باید برنامهریزی شود. بدترین اتفاق این است که زمان استفاده نشود و کسبوکار مثل ماهی در آب با آن کنار بیاید، و شما زمان را به برنامه پروژهتان برگردانید؛ مشکل خوشایندتری برای داشتن. ساختن این برنامه ارتباطی برای انواع مخاطبان، مثلا مدیریت ارشد شاید سطح جزئیات متفاوتی از کل شرکت بگیرد، و تعیین آهنگ انتشار انتشار آن، شما را به عادت تحویل خبر خوب یا بد میرساند. میتواند به سادگی یک ایمیل با نکته گلولهایهای سطح بالا باشد، یا یک یا دو اسلاید سریع در جلسه مدیریت ثابت.
۳.۷.۲ کنترل روایت
هرچند این از بسیاری جهات شبیه کمپین سیاسی به نظر میرسد، چندان متفاوت از کنترل پیامرسانی نیست. در غیاب اطلاعات، مردم خودشان جاهای خالی را پر میکنند، چه بهتر چه بدتر. هرچه دامنه چشماندازتان بلندتر باشد، بیشتر باید انتظارات را تعدیل کنید. در نقطهای، چشمانداز شما زندگی خودش را پیدا میکند. منظور این است که این پروژه شروع میکند به تبدیل شدن به نجاتبخش همه مشکلات. هر مسئلهای، نگرانی مشتری، فرصت فروش؛ چشمانداز شما آن را حل خواهد کرد. وعده جهان تازهای که در آن هیچ مسئلهای وجود ندارد رؤیایی بسیار فریبنده است، و شگفتزده میشوید که چقدر سریع میتواند جا بیفتد. در محافل مدیریت پروژه، این مقصد نهایی چیزی است که ویژگی creep نام دارد. ویژگی creep زمانی است که ویژگیهای کوچکتر مدام اضافه میشوند، چون بزرگ به نظر نمیرسند، پس اضافه کردنشان تفاوت زیادی ایجاد نخواهد کرد. مانند کاههایی که به پشت شتر اضافه میشوند، در نقطهای همان یک کاه کمرش را میشکند. ویژگی creep میتواند پروژهای کاملا خوب را نابود کند؛ تا زمانی که تحویل داده میشود، انتظارات به واقعیت نزدیک نیستند، هرچند شاید به همه هدفهایی که از ابتدا تعیین کرده بودید رسیده باشید. هرچند اصول استاندارد و قوی مدیریت پروژه در این مشکل کمک زیادی میکند، همچنان باید مطمئن شوید این موضوع بیرون از گروهتان هم ارتباط داده میشود. یک راه این است که در هر بهروزرسانی دورهای انتظارات را تنظیم دوباره کنید، تا مردم یادشان بماند چه چیزی را تحویل میدهید و چه چیزی را تحویل نمیدهید. هیچ ضرری ندارد همانجا هر سوءبرداشت را روشن کنید. این بهویژه برای تنظیم دوباره کردن انتظارات در سراسر سازمان و محافل غیررسمی مهم است. بهتر است ناامیدیهای کوچک را همان زمان تحویل دهید که یک ویژگی یا راهکار اضافی مشخص در موج اول انتشارها نخواهد بود، تا اینکه بعدا مجبور شوید از شکست احتمالی پروژه در برآورده کردن هیاهو دفاع کنید، چون بیش از حد مؤدب بودید و سوءبرداشتها را اصلاح نکردید.
جمعبندی
- ساختن چشماندازی که ارزش بلندمدت ایجاد کند به شما اجازه میدهد از هر پویایی در حال تغییر جلوتر باشید.
- جدا کردن «چه چیزی» از «چگونه» کمک میکند بهتر بر مخاطبان متفاوت تمرکز کنید.
- چشمانداز خوب سنجههای موفقیتی دارد که بهآسانی قابل اندازهگیریاند.
- دانستن اینکه مشتری فوری شما کیست و ساختن رابطهای ویژه با او برای شناخت نقاط دردش، اعتبار لازم را به چشمانداز شما میدهد.
- چشماندازها پروژههای کوتاهمدت نیستند؛ مجموعهای از پروژهها هستند که در بعضی موارد سالها طول میکشند.
- دانستن اینکه چگونه چشماندازتان را در خط زمانی شرکت ببافید، اصطکاک پذیرش را کاهش میدهد.
- با توجه به مدت زمانی که تکمیل یک چشمانداز میبرد، ساختن سازگاریپذیری برای فناوری در حال تغییر حیاتی است.
- ساختن و تمرین نکتههای گفتوگویتان، تا بتوانید چشماندازتان را بسیار مختصر و درگیرکننده منتقل کنید، خریدن حمایت افراد در همه سطوح نسبت به مسیری که آنها را میبرید آسانتر میکند.
- همراستا کردن بودجه با چشمانداز، هر غافلگیری اقتصادی آینده را حذف میکند و انتظارات را درست تنظیم میکند.
- تنظیم برنامه ارتباطی برای بهروز نگه داشتن همه ذینفعان کمک میکند وقتی هنوز راه زیادی باقی مانده است، جلوی زیر سؤال رفتن اعتبار چشماندازتان گرفته شود.
چکلیست
چند مورد از موارد زیر را میتوانید ادعا کنید که پوشش دادهاید؟
- چشماندازی بلندمدت ساختهاید و مشخص کردهاید چگونه به آن خواهید رسید
- چشماندازتان را در داخل سازمان، در سطوح فنی مختلف، منتقل کردهاید
- منافع کسبوکاریای را که چشماندازتان خواهد آورد با جزئیات بیان کردهاید
- خط زمانیی ساختهاید که نشان میدهد امیدوارید چشماندازتان چه زمانی پیادهسازی شود و چه چیزهایی در دسترس خواهد بود
- بهبودهای فناوری لازم را شناسایی کردهاید که اجازه میدهند با چشماندازتان مرتبط بمانید
- ارائه آسانسوری خود را تمرین و ارائه کردهاید تا دیگران بتوانند سریع چشماندازتان را بشناسند
- میتوانید با اطلاع بسیار کوتاه، مرور و گزارش پیشرفت دقیق درباره چشماندازتان ارائه دهید
خلاصه هوش مصنوعی
خلاصه فصل
CTO فقط مسئول روشن نگه داشتن چراغها نیست؛ باید چشمانداز فناوری بسازد که اعتماد کسبوکار را جلب کند. فصل تفاوت بیانیه چشمانداز و مأموریت را روشن میکند و با مثال HomeMax PLC نشان میدهد چگونه یک شرکت legacy میتواند تحول فناوری را آغاز کند. چشمانداز باید بر نیازهای واقعی کسبوکار، ارزش مشتری و تغییرات بلندمدت متکی باشد.
- چشمانداز باید برای مخاطبان مختلف (تیم فنی، مدیریت، مشتری) به زبان مناسب هر کدام ترجمه شود.
- برنامه بودجه و «آسانسور» (elevator pitch) کنار چشمانداز قرار میگیرند تا انتظارات واقعبینانه شود.
- برنامهریزی نزدمدت و بلندمدت باید انعطاف برای فرسودگی تیم و تغییرات بازار داشته باشد.
این خلاصه با کمک هوش مصنوعی بر اساس محتوای فصل تهیه شده و جایگزین مطالعه کامل متن نیست.