در این اپیزود در مورد کار مربی‌گری و مشاوره و تفاوت آن‌ها صحبت می‌شود. مارکوس ولتر و مارتین لیپرت که هر دو بصورت حرفه‌ای در حوزه‌های مشخصی از مهندسی نرم‌افزار، کار مشاوره و مربی‌گری می‌کنند، تجربیاتشان را با شما به اشتراک می‌گذارند.
ما تصمیم نگرفته‌ایم که چه کسی سئوال کند و چه کسی مطالب را ارائه کند. می‌خواهیم به یک روش برنامه‌ریزی نشده و منعطف اینکار را بکنیم! وقتی می‌خواهیم در مورد مشاوره و مربی‌گری صحبت کنیم فکر می‌کنم ابتدا باید آنها را تعریف کنیم. آیا می‌خواهید امتحان کنید؟
بله، صادقانه بگویم که من یک تعریف واقعاً روشنی از تفاوت بین مشاوره و مربی‌گری ندارم. شاید بیشتر به این خاطر باشد که من در کارم، همواره به عنوان مربی عمل کرده‌ام اما در قرارداد ممکن است مشتری بیشتر به مشاوره علاقه نشان دهد.
وقتی به عنوان مربی عمل می‌کنید، چکار می‌کنید؟ شاید به این روش، برداشتی از آن پیدا کنیم.
در پروژه‌هایی که من شرکت داشته‌ام، کمک می‌کرده‌ام که تیم چیزی را یاد بگیرد و کاری که احتمالاً قبلاً انجام نداده را انجام دهد. به عنوان مثال، اینکه اسکرام را به عنوان یک فرآیند چابک (Agile Process) بکارگیرند. کمکشان می‌کردم که اسکرام را اعمال کنند. من واقعاً اسکرام را برای آنها انجام نمی‌دادم بلکه کمک‌شان می‌کردم که این کار را بکنند. شاید تفاوت همین باشد. شما به عنوان مشاور همواره کاری را برای مشتری انجام می‌دهید و چیزی را برایش آماده می‌کنید. چیزی را پیاده‌سازی می‌کنید یا نرم‌افزاری را می‌دهید یا مسئله‌ای را برای‌شان حل می‌کنید اما به عنوان مربی بیشتر کمک‌شان می‌کنید که خودشان کارها را انجام دهند.
این قطعاً همان روشی است که من برای مجزا ساختن این دو استفاده می‌کنم. من اگر پروژه‌ای داشته باشم که برای یک هفته یا یک ماه طول بکشد، عموماً آن را مربی‌گری می‌نامم زیرا همان کاری را که گفتی انجام می‌دهم. در واقع کمک‌شان می‌کنم که کار کنند اما مشاوره را معمولاً برای موردی بکار می‌برم که برای دو یا سه روز به سراغ تیم می‌روم و بوسیله آموزش کمک‌شان می‌کنم که در جهت خاصی هماهنگ شوند مثلاً تلاش می‌کنیم که اولین مرحله تولید یک DSL برای یک تنظیم‌کننده یخچال را بیابیم. برای من اینطور است که چیزهای کوتاه‌مدت که اساساً فقط شامل صحبت کردن و شاید تولید یک پروتوتایپ باشند را مشاوره می‌نامم و وقتی کاری را برای مدت طولانی‌تری انجام می‌دهم و مانند یک عضو واقعی تیم هستم و کار واقعی را انجام می‌دهم یا اینکه برای مدت طولانی کمک‌شان می‌کنم، آن را مربی‌گری می‌نامم اما روشن است که تعریف واقعاً روشنی نیست.
بله، خصوصاً در کارهای روزمره.
بله، منظورم این است که فکر می‌کنم مهم باشد که این موضوع مربی‌گری و مشاوره‌‌ای که داریم در موردش صحبت می‌‌‌کنیم را از رفتار آدم‌های کاسب کلاسیک متمایز کنیم که بیشتر با خودجلوه‌گری همراه است! :-)
بله، چون این چیزها برای ما مهم نیست و این کارها را خیلی دوست نداریم! :-)
وقتی ما در مورد مشاوره صحبت می‌کنیم واقعاً منظورمان کار عملی نرم‌افزار است نه امور تجاری.
بله، من هم همینطور.
فکر می‌کنم یکی از اهداف اصلی مشاوره و مربی‌گری، انتقال دانش است. می‌خواهید به تیمی کمک کنید که چیزی را فرا بگیرد یا در انجام آن خوب شود. درسته؟
بله، فکر می‌کنم بین مشاوره و مربی‌گری با یک قرارداد ساده اجاره افراد (Body Leasing) -که بعلت نبود مثلاً نیروی کافی برای توسعه کد بسته می‌شود- تفاوت زیادی وجود دارد.
بسیار خوب. آنچه می‌خواهیم انجام دهیم این است که کمی توضیح دهیم که به عنوان مربی یا مشاور چه می‌کنیم. بعد از آن می‌توانیم کمی نظرمان را در این مورد توضیح دهیم که چه صلاحیت‌های ضروری برای افرادی که می‌خواهند این شغل را داشته باشند، وجود دارد. این خطر را دارد که اینطور به نظر برسد که می‌خواهیم به شما بگوییم چقدر وارد هستیم اما منظورمان این نیست. راستش ما اخیراً نامه‌ای دریافت کردیم که ارسال‌کننده به ما یادآوری کرده بود که با این وجود باید این اپیزود را اجرا کنیم. بخاطر همین، دور هم جمع شدیم و اجرایش کردیم زیرا بعضی افراد واقعاً دوست دارند در مورد این موضوع بشنوند.
بسیار خوب، لطفاً در مورد یکی دو نمونه پروژه‌ (که درگیرش بوده‌اید) و کارهای روزمره‌اش بگویید.
یکی از نمونه پروژه‌ها برای من این بوده است که با تیمی همراه شده‌ام که می‌خواستند روش‌های چابک مثلاً اسکرام را به خدمت بگیرند. آنها واقعاً می‌خواستند این حس را پیدا کنند که برای آنها بکارگیری اسکرام یعنی چه؟ آنها من را دعوت کردند و ما دوسه روز در مورد اینکه اسکرام چیست و چطور تعریف شد و خصوصاً اینکه انجام اسکرام برای آنها چه معنی می‌دهد صحبت کردیم یعنی در مورد این ترجمه دانش تئوری به زندگی عملی روزمره (صحبت کردیم). ما حسی پیدا کردیم که اسکرام به چه معنی است و چطور می‌توانند آن را آغاز کنند و چطور می‌توانند آن را ادامه دهند. اینکار عموماً بیشتر با یک روش کارگاه مانند انجام می‌شود. کنار هم و بدون میز می‌نشینیم و از تخته‌های الصاقی (Pin board) یا وَرَقی (Flip chart) استفاده می‌کنیم. بصورت تعاملی مسائل را با گروه بحث می‌کنیم.
شما گفتید «گروه». آنها چه نوع افرادی هستند؟
فکر می‌کنم خیلی متنوع باشد: توسعه‌دهنده‌ها، مدیر پروژه‌ها، گاهی حتی مدیران محض (Pure Manager). فکر می‌کنم دامنه‌اش به همه نقش‌هایی که در شرکت‌ها برای توسعه نرم‌افزار می‌شناسید، بکشد. مشتری‌های من عموماً شرکت‌های بزرگ بوده‌اند و داخل خود ساختارهای سلسله‌مراتبی داشته‌اند و از من کمک می‌خواسته‌اند. در این نوع شغل‌های دوروزه کارگاهی یک دستور جلسه ثابت یا 200 صفحه اسلاید آماده نمی‌کنید که همه وقت را برایشان صحبت کنید بلکه کم و بیش بصورت تعاملی به افراد توضیح می‌دهید که معنای چیزی چیست و چه سئوال‌هایی در موردش هست. من دوست دارم با فهرستی از سئوال‌ها آغاز کنم. مشتریان، سئوال‌های بیشتری هم می‌افزایند. در ابتدای کارگاه، به آنها می‌گوییم که سئوال‌هایتان چیست و مهم‌ترین چیزها و بزرگترین سئوال‌هایی که در ذهنتان دارید چیست. ما سئوال‌ها را اولویت‌بندی و فهرست می‌کنیم و گام به گام به سراغ همه آنها می‌رویم. در حین پاسخ دادن به این سئوال‌ها، مقداری اصطلاحات و دانش تئوری را مطرح می‌کنم. (مثلاً می‌گویم که) الان باید در مورد نحوه گذشته‌کاوی (Retrospective) کردن (نام یکی از جلساتی که در اسکرام برگزار می‌شود - مترجم) صحبت کنم یا الان باید در مورد چگونگی برنامه‌ریزی‌ Sprint (در اسکرام، دوره‌ها Sprint خوانده می‌شوند - مترجم) صحبت کنم اما این تکه بحث‌های تئوری بیشتر اینطور هستند که به هنگام لزوم ارائه می‌شوند.
فکر می‌کنم این شغل‌های کوچک دو سه روزه، مرسوم باشند.
من دو نوع تجربه مشاوره کاملاً متفاوت داشته‌ام. یکی مشاوره دادن در ارتباط با یک ابزار مشخص است مثلاً مدل کردن با Eclipse یا Texts و چیزهای شبیه به آن. در این حالت کارگاه بیشتر با قالب آموزشی انجام می‌شود. مشتریان به من می‌گویند که می‌خواهند فلان نوع زبان را بسازند و می‌دانند که برای آن کار XText خوب است؛ بعد ما با همدیگر ساختن آن را شروع می‌کنیم و کمک‌شان می‌کنم که زبان را بسازند و ابزار را به آنها آموزش می‌دهم.
نوع دیگر شغل که برای من جذابیت خیلی بیشتری دارد، در حالتی است که مشتری می‌گوید: ما در مورد این مبحث زبان‌های مختص حوزه (Domain Specific Language) و توسعه برآمده از مدل (Model Driven) شنیده‌ایم و فکر می‌کنیم چیزهای خوبی باشد و می‌خواهیم ببینیم که آیا می‌توانیم در محیط خودمان آنها را بکار ببریم؟ در اینجا دو حالت وجود دارد، یک حالت این است که می‌گویند که ما یک مورد خاص در ذهن داریم مثلاً اخیراً برای یک شرکت کار کردم که یخچال می‌ساختند و در مورد تعریف یک DSL برای توضیح ترمودینامیک و الگوریتم‌های خنک‌سازی یخچال‌هایشان فکر می‌کردند. کاری که کردیم این بود که تلاش کردیم، اولین نسخه این زبان را بسازیم. قبل از هرچیز باید مسئله را می‌فهمیدم بنابراین سئوالات زیادی پرسیدم و سعی کردم بفهمم که توضیح دادن چگونگی خنک کردن یخچال، یعنی چه؟ من باید می‌فهمیدم که چه چیزی را می‌خواهند توضیح دهند. بعد از آن، نشستیم و تلاش کردیم با یک نوت‌بوک، کار نوشتن پروتوتایپ یک زبان را آغاز کنیم. اگر فرض کنیم که خودم قانع شوم که DSL راه خوبی (برای مسأله آنها) است، آنگاه من باید آنها را قانع کنم که اینکار جواب می‌دهد و زحمتی که برای ساختن زبان متحمل می‌شوند، قابل قبول است.
یک حالت دیگر هم این است که مثلاً گاهی مواقع مشتریان نام من را در کنفرانس‌ها می‌بینند و می‌گویند حال که شما به اینجا آمده‌اید یک ارائه یک ساعته یا یک ساعت و نیمه در مورد DSL برای تیم یا همه توسعه‌دهنده‌ها در شرکت بگذارید. این‌ها شرایط متداول مشاوره‌های من بوده است.
فکر می‌کنم برای من، یک حالت دیگر این بوده است که بصورت کلاسیک آنها را برای چند ماه بصورت دو یا 3 روز در هفته مربی‌گری می‌کرده‌ام تا اسکرام یا روش‌های چابک دیگر را در کارهای روزمره‌شان به خدمت بگیرند و کمک‌شان می‌کرده‌ام که در این راه موفق باشند.
یعنی شما هر هفته برای یکی دو روز بر می‌گشتید؟
بله، در ابتدا کار را سنگین‌تر مثلاً با 3 یا 4 روز در هفته آغاز می‌کردیم و بعد از چند هفته آن را به 2 یا یک روز در هفته یا 1 روز در ماه، کاهش می‌دادیم.
بله، این کاری است که من هم انجام داده‌ام و این همان چیزی است که من به آن مربی‌گری می‌گویم. من دقیقاً همین کار را می‌کنم با این تفاوت که من اغلب با فرآیند‌های توسعه نرم‌افزار سروکار ندارم بلکه در عوض، بیشتر در مورد تکنولوژی‌ها و کارهای مشخص سروکار دارم. من هم به همین روش کار می‌کنم. با کار سنگین‌تر آغاز می‌کنم و بعد زمان آن را کاهش می‌دهم.
گاهی از من هم برای (مشاوره دادن) برخی تکنولوژی‌ها درخواست می‌شود. من دو وجه دارم. یکی از علاقه‌مندی‌هایم در مورد فرآیند‌ها و سبک‌های چابک است و بخش دیگر قلبم برای تکنولوژی‌های جالب مثلاً تکنولوژی‌های مربوط به Java Script و OSGi می‌تپد. خیلی مفرح است که با تیم‌هایی همراه شوید که مثلاً دارند OSGi را به خدمت می‌گیرند و برخی چالش‌های تکنیکی که دارند را متوجه شوید مثلاً برخی مسائل مربوط به بارگذاری کلاس‌ها و این چیزها! به نظر من این‌ها مسائل خیلی جذابی هستند و خیلی مفرح است که با آنها بر روی این مسائل کار کنید تا چیزها بکار بیافتند خصوصاً اگر در مدت زمان کوتاهی مثلاً یکی دو روز باشد. آنها امیدوارند در چنین مدتی اینگونه مسائل‌شان حل شود. همواره خیلی جذاب و مفرح است که سیستم‌های مختلف و افراد مختلف را ملاقات می‌کنید.
فکر می‌کنم تا پایان مصاحبه باید برگردیم و بازهم در مورد آن بخش‌هایی از شغل مشاوره که دوست داریم و آنچه دوست نداریم صحبت کنیم اما دیدن سیستم‌های مختلف و تیم‌های مختلفی که با سیستم‌های مختلف کار می‌کنند قطعاً یک امتیاز بزرگ است.
برای یک مشاور خوب بودن چه چیزی مهم است؟ شما گفتید که این تفکیک بین امور مربوط به فرآیند‌ها (ی توسعه نرم‌افزار) و برخی تکنولوژی‌های خاص از قبیل OSGi -که شما را بیشتر با آن می‌شناسند- را دوست دارید. به نظر شما برای یک مشاور خوب بودن چه پیش‌شرطی مهم است؟
به نظر من یکی از مهمترین پیش‌شرط‌ها این است که دوست داشته باشید به صحبت‌های افراد گوش دهید.
جالب شد چون فکر می‌کردم که مشاور همه‌اش صحبت می‌کند!
من هم دوست دارم که صحبت کنم! اما فکر می‌کنم خیلی مهم باشد که به صحبت‌های افراد گوش دهیم تا مشکلات‌شان را بفهمیم و نسبت به سیستمشان، نسبت به مشکلاتشان و نسبت به تیم‌شان، کاملاً با احترام باشیم. گاهی مشاورانی را می‌بینم که وقتی می‌آیند (گویی) رئیس بزرگ هستند و همه چیز را می‌دانند و خیلی به مشتریان اهمیت نمی‌دهند، می‌گویند معماری شما کاملاً اشتباه است و باید به این روش یا آن روش عمل کنید. این روش کار من نیست و چیزی نیست که به آن علاقه داشته باشم.
این یک چالش جالب است. مگر نه؟ اگر به عنوان مثال، مورد OSGi را درنظر بگیریم، افراد می‌دانند که شما OSGi را کاملاً می‌شناسید. آنها ممکن است شما را استخدام کنند تا در ارتباط با مشکلات OSGi کمکشان کنید. شما باید در برخی جنبه‌ها بهتر از آنها بدانید در غیراینصورت استخدامتان نمی‌کردند. از طرف دیگر، شما نمی‌توانید آنجا بروید و بگویید شما همه نادان هستید و همه کارهایتان اشتباه است و بیایید که به روش دیگری آن را انجام دهیم در عوض می‌خواهید که تیم شما را کاملاً دوست داشته باشد.
چه من اهمیت بدهم چه ندهم، این (روش کار) درست نیست!
بنابراین رمزش این است که دانشتان را در مورد تکنولوژی یا هر چیز دیگری عرضه کنید اما مجبورشان نکنید.
من مجبورشان نمی‌کنم و فکر می‌کنم وقتی داخل یک تیم به عنوان مربی یا مشاور عمل می‌کنید، حتماً به این خاطر شما را استخدام کرده‌اند که در مورد یک تکنولوژی خاص یا روش توسعه، دانش کافی ندارند و در مورد بخش‌هایی از کاری که انجام می‌دهند نیاز به کمک دارند اما نادان نیستند. من (در خلال کار مشاوره‌ام) تیم‌ها و افراد بسیار بسیار خوبی را دیده‌ام که خوب کار می‌کرد‌‌ه‌اند. فکر می‌کنم یک مزیت این کار مشاوره این است که این دو طرف را کنار هم می‌گذاریم، شاید من کمی در مورد OSGi بیشتر از آنها بدانم اما آنها در مورد حوزه کارشان، سیستم‌ها، ساختارها و شرایط جانبی‌شان خیلی بیشتر از من می‌دانند؛ در مورد همه چیزهایی که هر روزه باید با آنها درگیر شوند و من از آنها بی‌اطلاعم. فکر می‌کنم این دو دانش را باید بهم پیوند دهید تا کاری انجام شود و مسئله‌ای حل شود.
شاید داریم سعی می‌کنیم چیز یکسانی را به روش‌های مختلفی بیان کنیم. برای من اینطور است که اگر یک عقیده اختصاصی در مورد چیزی داشته باشم، آنها را متوجهش می‌کنم و به آنها می‌گویم که دارند اشتباه عمل می‌کنند با این حال می‌دانم که مرزها کجاست. تلاش نمی‌کنم که یک عقل کُل باشم. در یک حوزه خاص، کمکشان می‌کنم و احتمالاً (در آن حوزه) چیزهای بیشتری می‌دانم اما در مورد دیگر چیزها کنار می‌ایستم. اگر چیزی از من بخواهند که نمی‌دانم، باید بگویم که نمی‌دانم، ایده‌ای ندارم.
من فکر می‌کنم اینکه بگویید عقیده من اینجور یا آنجور است کاملاً مقبول است اما وقتی این فقط به عنوان عقیده من باشد. ممکن است حقیقت یا حقیقت در سراسر جهان مطابق با آن باشد و ممکن هم هست که عقیده من فقط برآمده از تجربه‌های گذشته‌‌ام باشد که با آنچه آنها انجام می‌دهند متفاوت باشد.
بنابراین فکر می‌کنم کار برای من بیشتر شبیه به اشتراک گذاشتن تجربیاتم بوده است و اینکه تلاش کنم تا تجربیاتم را با شرایط آنها تطبیق دهم و یاد بگیریم که از آن تجربیات چه چیزی می‌توانیم بیاموزیم تا مسئله‌ای را حل کنیم یا چیزی را بهتر کنیم.
چیز دیگری که من در کار خودم متوجه شدم این بود که گاهی واقعاً انرژی لازم برای فهم عمیق مسأله واقعی مشتری را صرف نکرده‌ام. گاهی به جایی می‌روید و با افراد نیم‌ساعت صحبت می‌کنید و بعد می‌خواهید مشکل آنها را در یکی از جعبه‌هایی که برای چیزهای مختلف ساخته‌اید بگذارید و می‌خواهید حل کردن مسأله‌شان را آغاز بکنید اما مسائل را واقعاً نفهمیده‌اید، در این هنگام شروع بکار می‌کنید و کمکشان می‌کنید که پروتوتایپ یا هر چیز دیگری را بسازند اما مدتی بعد می‌فهمید که خیلی خوشبین بوده‌اید و قضیه پیچیده‌تر از این حرف‌ها است. مسائل عمیق‌ترند و آنقدر آسان نیستند. بنابراین همانطور که شما گفتید واقعاً مهم است که وقت بگذاریم و به افراد گوش دهیم و تلاش کنیم که ورودی‌ها را بفهمیم.
بله، در یکی از پروژه‌هایی که وارد شدم، برای مدت نسبتاً طولانی با تیم کار می‌کردم و همراه با تیم توسعه می‌دادم، در بحث‌های معماری و طراحی شرکت می‌‌کردم و حتی در کارهای برنامه‌نویسی روزانه شرکت می‌کردم، گاهی آنها از من می‌پرسیدند که آیا یک ایده طراحی برای فلان مسأله داری؟ و من اغلب می‌گفتم باید 3 بار بپرسی تا یک جواب واقعاً خوبی بگیری! زیرا اولین جواب من بیشتر شبیه این است که: بله، این مثل فلان چیز می‌ماند و راه‌حلش A است. بعد از 2 ساعت آنها برمی‌گردند و می‌گویند ما به یک مشکلاتی خورده‌ایم. می‌آیی یک نگاهی بکنی؟ و من می‌فهمم بله، راه حل A اشتباه بوده است، ساده‌انگارانه بوده است یا کاملاً افتضاح بوده است. (می‌گویم) بیایید راه حل B را امتحان کنیم. من یک ایده برای B دارم و بعد از 3 ساعت دوباره به من می‌گویند: خیلی مطابقت پیدا نمی‌کند، می‌توانی یک نگاهی بکنی؟ و بعد با همدیگر راه‌حل C را پیدا می‌کنیم. بنابراین این شرایط به اشتراک گذاشتن تجربیات و بحث با آنها، از جنس بهتر دانستن چیزی یا کمتر و زیادتر دانستن چیزی نیست بلکه بیشتر شبیه به داشتن تجربیات مختلف از افراد مختلف است تا ببینیم که چه چیزی می‌توانیم از آنها بیاموزیم و چه راه‌حلی می‌توانیم پیدا کنیم.
برخی می‌گویند که مشاور نباید دانش افرونه‌ای فراهم کند بلکه فقط باید کمک کند که چیزهایی که تیم هم‌اکنون می‌داند برایشان توضیح داده شود و چیزها را کنار هم قرار دهد و دستیابی به یک تیم خلاق و مولد را تسهیل بخشد. در اینباره من می‌گویم نوع مشاوره‌هایی که من می‌کرده‌ام اینطور نبوده است. من نمی‌گویم که این اشتباه است یا اتفاق نمی‌افتد اما نوع مشاوره‌ای که من می‌دهم نیست. من برای حوزه‌های کاملاً معینی از تخصص‌ها استخدام می‌شوم و نقش من کسی نیست که بخواهد تیم را یکپارچه کند اما فکر می‌کنم اینطور افراد هم وجود داشته باشند.
بله، در ارتباط با مشاوره‌هایی که در ارتباط با فرآیند توسعه داشته‌ام، نوع کارم بیشتر به همین شکل بوده است زیرا اینکه «من» فرآیندی را انجام دهم یا آن را و آن را تجربه کنم معنی نمی‌دهد. تیم است که آن را تجربه می‌کند و باید آن را بپذیرد، تغییرش دهد و یاد بگیرد که چطور با آن فرآیند برخورد کند. آنها باید آزمایشات خودشان از بکارگیری آن فرآیند را داشته باشند. این‌ها شرایطی است که من به تیم کمک می‌کنم که دریابد چه چیزی درست و چه چیزی غلط است و من از قبل نمی‌دانم که چه چیزی درست یا غلط است.
یکی از چیزهایی که من فکر می‌کنم برای یک مشاور خوب بودن مهم است و به درآمد روزانه‌تان مرتبط می‌شود این است که باید یک پروفایل روشن داشته باشید. من همواره به این روش کار می‌کنم. من در حوزه‌های خاصی کار می‌کنم و در همان حوزه‌ها (مقاله و کتاب) منتشر می‌کنم و در کنفرانس‌ها سخنرانی می‌کنم. بنابراین افراد فرض می‌کنند که من در آن حوزه‌ها، تجربه دارم و این چیزی است که می‌توانم بفروشم و در آن زمینه کار کنم. من نمی‌توانم تصوری از مشاوره دادن کسی داشته باشم که در زمینه خاصی تمرکز نکند. آیا چنین افرادی وجود دارند؟ در آنصورت شاید همان روش اجاره افراد (Body Leasing) باشد، اینکه به پروژه‌ای بروید و فقط کار کنید.
شاید همان اجاره افراد باشد، نمی‌دانم. من اغلب تلاش می‌کنم که موضوعاتی که به آنها علاقه دارم را دنبال کنم. مثلاً همان OSGi که برایم جالب است زیرا من واقعاً این نوع از پیمانه‌ای بودن (Modularity) را دوست دارم. البته نمی‌گویم که هر شب خواب OSGi را می‌بینم! من چیزها را یاد می‌گیرم و خوشحال می‌شوم که آنها را به اشتراک بگذارم. به عنوان مثال به دیگران کمک کنم که چیزهای OSGi را راه بیاندازند اما البته اگر بخواهم برای20 موضوع مختلف مشاوره بدهم، نمی‌توانم به همه آنها علاقه داشته باشم و در همه موضوعات خوب باشم. واقعاً دوست دارم در چیزی خوب باشم و به دیگران آن را توضیح دهم و کمکشان کنم.
شرایطی را دوست ندارم که مشتری برای یک متخصص Hibernate درخواست کرده است و رئیستان شما را برای او می‌فرستد زیرا در پروفایل شما خوانده که 20 سال پیش در یکی از پروژه‌هایتان Hibernate را برای یک هفته استفاده کرده‌اید اما الان چون متخصص آن را ندارید شما به سراغ مشتری می‌روید و باید به ایشان مشاوره بدهید و تمام چیزی که می‌توانید انجام دهید این است که شب قبل آن تلاش کنید چه راه حلی وجود دارد که به قدر یک گام خیلی خیلی جزیی از مشتری جلو باشید. این چیزی است که من دوست ندارم و در همه سال‌های گذشته از این مسئله اجتناب کرده‌ام که بخواهم در زمینه‌ای مشاوره بدهم که واقعاً در آن خبره نیستم و چیزی نمی‌دانم.
شخصاً باید خودم به چیزی که به مشتری می‌گویم مطمئن باشم. باید اطمینان داشته باشم که آنچه در موردش صحبت می‌کنم را می‌دانم و در مورد آنچه پیشنهاد می‌کنم مطمئن باشم. نه به این معنا که بطور کامل چیزی باشد که آنها نیاز دارند که این خود سئوال دیگری است اما باید مطمئن باشم که چیزها مطابق با قواعدی هستند که کار می‌کند و قبلاً آنها را انجام داده‌ام. من موافقم که برای یک مشاور خوب بودن باید در زمینه خاصی که درباره‌اش مشاوره می‌دهم، کاملاً حرفه‌ای باشم. این واقعاً حیاتی است.
بله، همینطور فکر می‌کنم باید صادق باشید. اگر سئوالی پرسیدند که چون قبلاً آن را انجام نداده‌اید برایش پاسخی ندارید یا شاید ایده‌ای برایش ندارید، در چنین شرایطی من همواره می‌گویم که ایده‌ای ندارم و با تیمی که قبلاً چنین شرایطی داشته باشد برخورد نکرده‌ام؛ می‌توانم تصور کنم که راه‌های A، B یا C ممکن است جواب بدهد، باید امتحانش کنیم ولی من واقعاً جواب را نمی‌دانم. فکر می‌کنم به عنوان یک مشاور برای یک زندگی سالم این مطلب مهم است.
درسته، زیرا مشتری‌ها خیلی سریع این را می‌فهمند که دارید در مورد چیزهایی صحبت می‌کنید که واقعاً آنها را نمی‌شناسید. این را حس می‌کنند. حس می‌کنند که نامطمئن شده‌اید و فقط دارید حرف می‌زنید.
بله، عموماً آنها در این شرایط که می‌گویید واقعاً ایده‌ای ندارید، عصبانی نمی‌شوند. البته شاید اگر قرار باشد برای سه روز پشت سرهم این را بگویید که واقعاً ایده‌ای ندارم که مشکل شما چیست و متوجه نشده‌ام که چه چیزی می‌تواند کمک‌تان کند، در اینصورت باید قبلاً اشتباهی رخ داده باشد.
این نکته خوبی بود. شما چگونه مشتری‌های خود را پیدا می‌کنید؟ یا اینکه مشتری‌ها چطور شما را پیدا می‌کنند؟ منظورم این است که چطور مطمئن می‌شوید که آنچه الان در موردش صحبت کردید اتفاق نیافتد؟ چگونه به هم پیوند می‌خورید؟
عموماً دوست دارم که قبلاً با آنها صحبت کرده باشم. منظورم پیش‌فروش نیست. آن چیز دیگری است. دوست دارم که قبلاً با آنها صحبت کنم و بفهمم که مسئله و شرایط چیست؟ انتظارات چیست؟ چه انتظاری از من دارند؟ به آنها می‌گویم که آیا فکر می‌کنم می‌توانم به آنها کمک کنم یا نه. خیلی زیاد پیش می‌آید که به آن مشتری‌های بالقوه می‌گویم من در این حوزه‌ها تجربه دارم و می‌توانم کمکتان کنم اما در مورد آن بخشی که اشاره کردید، متخصص نیستم، داستان زندگی‌ام را می‌گویم و به ایشان می‌گویم که ولی الان برای دانش خوب بهتر است از کس دیگری کمک بخواهید. این خیلی بهتر است که آنجا بنشینید و نقش متخصص چیزی را بازی کنید که واقعاً نیستید.
من هم همین کار را می‌کنم. همواره سعی می‌کنم از قبل با آنها صحبت کنم. خیلی موارد، فقط لازمست 5 دقیقه صرف کنید و به خوبی می‌فهمید چه چیزی از شما می‌خواهند. گاهی کمی پیچیده‌تر است. اخیراً برای یک مشتری کار می‌کردم که بعد از جلسه مشاوره معلوم شد آنها اصلاً هیچ مشاوره‌ای نمی‌خواسته‌اند بلکه می‌خواستند من بنویسم که آنچه آنها انجام داده‌اند درست بوده است! قضیه کاملاً سیاسی بود و این واقعاً ناگوار بود. من از ادامه کار با آنها کناره‌گیری کردم زیرا این مضحک بود. اما در حالت کلی از قبل صحبت کردن با آنها ایده خوبی است. گاهی به آنها می‌گویم که من این چیزها را نمی‌دانم، بگذارید یکی از همکارانم را بیاورم یا می‌گویم به شما پیشنهاد می‌کنم که از فلان فرد درخواست کنید. یک بار یک شرکت من را برای کار معمول DSL در زمینه جاوا و Spring استخدام کرد. من یک روز آنجا مشغول بودم تا فهمیدم که آنها DSL نمی‌خواهند فقط می‌خواهند از Spring استفاده کنند. به آنها گفتم چرا با ابرهارد ولف تماس نمی‌گیرید؟ او را استخدام کنید.
بله، برای من و هم برای شرکتی که در آن کار می‌کنم یعنی شرکت IT Agile همینطور است. فقط شما نیستید که می‌توانید بگویید که شما نباید از من درخواست کنید و از کس دیگری درخواست کنید بلکه شرکت شما هم فکر می‌کنم همین رویه را باید پیروی کند. این که بگوید ما بر روی فلان چیز و بهمان چیز تمرکز داریم. مثلاً اگر شما دوست دارید که در مورد تیم‌های چابک توزیع شده جهانی مشاوره شوید از فلان شخص (اسمی در مصاحبه گفته شد که متوجه آن نشدم - مترجم) درخواست کنید.
شما چطور در مورد قیمت تصمیم می‌گیرید؟ منظورم این است که شاید معنی ندهد که بگوییم در اینجا و در حال حاضر باید X دلار در روز بپردازید زیرا این وابسته به کشور و صنعتی است که در آن مشغول هستید. شما چطور قیمت را تعیین می‌کنید؟
به آنها می‌گویم از مدیرم بپرسید! :-)
من مستقل بودم، هنوز هم مستقل هستم اما این روزها ...
پس شما نمی‌توانید از مدیرتان بپرسید؟ :-)
من هم می‌خواهم که از مدیرم بپرسند که همان شماره تلفن است فقط اسمش فرق می‌کند! :-) روشی که عموماً استفاده می‌کنم این است که می‌گویم اگر روزانه فلان مبلغ را بگیرم خوبه و اگر متوجه شوم شرکتی که من را خواسته یک بانک است و کلی پول دارد، 200-300 یورو به آن مبلغ اضافه می‌کنم و اگر یک شرکت کوچک باشد که بگویند ما نمی‌توانیم این مقدار را بپردازیم، اگر یک مسئله جالب باشد یا فقط 5 کیلومتر با جایی که زندگی می‌کنم فاصله داشته باشد یا چیزی باشد که بتوانم خودم یادگیری داشته باشم، مبلغ را کاهش می‌دهم. اما فکر می‌کنم برای مشاور، مهم است که وقتی برای یک پروژه مشتری می‌رود، عدد مشخصی را در ذهن داشته باشد زیرا آنها می‌خواهند بدانند شما چقدر می‌خواهید.
من فکر می‌کنم به اینکه چند ساعت در پروژه شرکت می‌کنید هم بستگی دارد. آیا می‌خواهند فقط برای چند روز شما را داشته باشند یا چند سال؟
بله، درست است. به چیزهای زیادی وابسته است. یکی از آنها البته این است که شما در مورد آن موضوع خاص چقدر معروف هستید. اگر برای چیزی معروف هستید و آنها دقیقاً برای همان موضوع شما را استخدام می‌کنند روشن است که می‌توانید مبلغ بیشتری درخواست کنید. به عنوان مثال من در سال 2004 با BMW همکاری کردم. در آن زمان من تجربه‌هایی در مورد توسعه برآمده از مدل داشتم اما مطلقاً هیچ تجربه‌ای در مورد نرم‌افزارهای تعبیه‌شده (Embedded Software) نداشتم. آنها از من پرسیدند که آیا می‌خواهم با ایشان کار کنم. من گفتم: بله، من می‌توانم در مورد توسعه برآمده از مدل کمکتان کنم اما هیچ تجربه‌ای در مورد سیستم‌های تعبیه شده ندارم، من با نرخ کمتر از آنچه بطور معمول می‌گیرم موافقت نمی‌کنم اما در حین این پروژه شما چیزهای زیادی در مورد سیستم‌های تعبیه‌شده یاد می‌گیرم. بنابراین در نهایت با نرخی کار کردم که عموماً با آن نرخ کار نمی‌کردم اما خیلی خوب بود، آنجا برای من یک سال طول کشید و واقعاً خیلی یاد گرفتم و معامله خوبی بود. چیزهای شبیه به این هم اتفاق می‌افتد.
کمی در مورد توانایی‌ها یا مهارت‌هایی که برای یک مشاور خوب بودن نیاز دارید صحبت کنیم. از دیدگاه فنی باید واقعاً موضوعی را که در موردش مشاوره می‌دهید را بشناسید. فکر می‌کنم این مسأله روشن است. و طبق تجربه‌های من ایده خوبی است که این را آشکار کنید مثلاً با مقالات، صحبت در کنفرانس‌ها و ... تا همه کسانی که مشتریان بالقوه شما هستند شما را به این موضوعات بشناسند زیرا این باعث می‌شود که مشتری‌های بالقوه راحت‌تر پیدا شوند.
بله، این پیدا کردن مشتریان را آسان‌تر می‌کند زیرا ممکن است شما را در کنفرانس‌ها ببینند و مثلاً به شما ایمیل بزنند. بنابراین واقعاً نیاز زیادی به بازاریابی و فروش و این چیزها نخواهید داشت.
بله، من واقعاً هیچگاه چنین کارهایی نکرده‌ام. من به عنوان مشاور، هیچگاه هیچ نوع کار مربوط به فروشی انجام نداده‌ام. در 90% کارهایی که کرده‌ام مشتری‌ها به سمت من آمده‌اند.
شاید این خاص شما باشد! :-)
مطمئن نیستم. اینطور فکر نمی‌کنم. اگر به دیگرانی که پروفایل روشنی دارند مثلاً پیتر هسباخ، ماتیاس برن یا فرانک بوشمان نگاه کنید، من فکر نمی‌کنم که آنها مشتری‌ها را صدا کنند که آیا می‌توانیم برایتان کار کنیم. فکر نمی‌کنم اینطور جواب بدهد.
بله، ولی شاید دقیقاً همان افراد اینطور باشند، افراد معروفی که زیاد در کنفرانس‌ها شرکت می‌کنند، اینها الان به ذهن شما رسیدند. شما در مورد افراد دیگر فکر نکردید مثلاً کسانی که چند باری در کنفرانس‌ها شرکت کرد‌ه‌اند ...
آنچه من می‌گویم این است که من در مورد روش دیگر مشتری پیدا کردن نمی‌توانم صحبت کنم زیرا هیچگاه انجامش نداده‌ام. شاید شما بتوانید. شاید شرکت شما، شرکت IT Agile بتواند. من نمی‌دانم.
ما هم در شرکت IT Agile بازاریابی‌های زیادی با کارهایی از قبیل صحبت در کنفرانس‌ها و نوشتن کتاب کرده‌ایم. ما چیزهای زیادی از اینجور محصولات تبلیغاتی مثلاً روزنامه دیواری و ... را داشته‌ایم.
شما کافی‌ماکس داشتید!
ما کافی‌ماکس داشتیم، خودکار داشتیم، ... فکر می‌کنم چیزی که در مورد این محصولات تبلیغاتی مهم است این است که رابطه روشنی با شرکت و پروفایل شما داشته باشد. همه شرکت‌ها خودکارهای تبلیغاتی دارند. این مهم نیست که شما خودکار و پَد تبلیغاتی داشته باشید. این‌ها رابطه‌ای با شرکت و پروفایل‌ شما نمی‌سازند. خیلی جذاب‌تر است که محصولات تبلیغاتی داشته باشید که افراد آن را مستقیماً به محیط و کارهای شما نسبت دهند. ما در IT Agile اینطور فکر می‌کنیم. این فقط من نیستم، من همه آن قطعات و کالاهای تبلیغاتی IT Agile را اختراع نکرده‌ام. بیشترشان را آنا هوک، اختراع کرده است. فکر می‌کنم خلق این چیزهای کوچک کار فوق‌العاده‌ای بوده است، شما می‌توانید آنها را به مهندسی نرم‌افزار و در انتها به IT Agile منتسب کنید.
بله، ما در مورد مهارت‌های یک مشاور صحبت کردیم. فکر می‌کنم یکی از این توانایی‌ها که شما قبلاً به آن اشاره کردید گوش دادن است و فقط گوش دادن هم نیست، می‌بایست متوجه شوید و نوع مشکلاتی که تیم دارد را بفهمید و همینطور باید تا حدودی تحرکات تیم را متوجه شوید، اینکه دو سه نفر کلیدی در تیم چه کسانی هستند که اگر دانش را به آنها منتقل کنید آنها می‌توانند آن را بیشتر گسترش دهند. بنابراین فکر می‌کنم آشنا شدن با افراد و مسائلشان و تلاش برای فهمیدن اینکه تیم چطور کار می‌کند، مطلب مهم دیگر است.
بله، کلاً مهارت‌های ارتباطی. فهمیدن، گوش دادن و توانایی توضیح دادن شفاف چیزها به افراد، توضیح دادن مفاهیم، توضیح دادن ایده‌ها. واقعاً اینطور نیست که اگر ایده فوق‌العاده‌ای در ذهن داشته باشید لزوماً می‌توانید آن را منتقل کنید.
این هم جالب است که (داشتن این مهارت‌ها) با صحبت کردن در کنفرانس‌ها و نوشتن مقاله، مشابهت دارد زیرا آنها هم مربوط به انتقال دانش‌ هستند. اگر یک مشاور، ارائه‌ها و نوشته‌های خوبی داشته باشد، نشانه خوبی است که اگر او را استخدام کنید، می‌تواند دانش و ایده‌هایش را به تیم شما منتقل کند. درسته؟
بله، دقیقاً. ما الان در مورد پروفایل شفاف صحبت کردیم. مثلاً شاید افراد شما را به این بشناسند که در DSL ها خوب هستید، فکر کنم بهتر است که اینها هر نیمسال یکبار، تغییر نکنند، مثلاً امسال متخصص طراحی باشید، سال بعد متخصص فرآیندهای چابک باشید، بعد متخصص OSGi، بعد Scala، بعد متخصص Clojure، بعد متخصص Tomcat، بعد متخصص Spring و بعد ... . برای من این موضوع جالب است که در حالی که تنها در دو جنبه فرآیندهای چابک و OSGi فعال هستم، حتی در این شرایط که واقعاً به هر دو جنبه علاقه دارم، گاهی افراد گیج می‌شوند و از من می‌پرسند که: واقعاً؟! شما در زمینه فرآیندهای چابک هم کار می‌کنید؟ جالبه!
این خیلی ساده‌تر است که برای یک مدت طولانی بر روی یک موضوع خاص تمرکز کنیم و بین موضوعات مختلف جابجا نشویم.
وقتی مشتری‌ها تلاش می‌کنند چیزی را برای من توضیح دهند، یکی از چیزهایی که به صورت منظم انجام می‌دهم این است که گوش می‌دهم و تلاش می‌کنم بفهمم. بعد آنچه گفته‌اند را دوباره با زبان و کلمات خودم بیان می‌کنم، یا شاید با دیاگرام و روی تخته تلاش می‌کنم چیزها را توضیح دهم. شاید بتوانم این تکنیک را توصیه کنم اینکه فقط تلاش نکنید منفعلانه گوش دهید بلکه تلاش کنید آن را درک کنید و با آن دانش، با گسترش دادن یا مثال ساختن از آن، کاری انجام دهید.
بله، من فکر می‌کنم این یک تکنیک شناخته‌شده در روانشناسی هم هست، تکنیک گوش دادن فعال.
بنابراین بیایید به نقاط مثبت و منفی این شغل نگاهی بیاندازیم. بیا با جنبه‌های منفی آغاز کنیم که نمی‌توان از دستش خلاص شد. فکر می‌کنم یک مورد منفی ناامیدکننده خیلی خیلی بزرگ وجود دارد که ...
سفر کردن؟
بله، سفر کردن آزار می‌دهد!
من می‌توانم بگویم حتی اگر کارت عضویت از هر کدام از خطوط هوایی جهان را داشته باشید، وضعیت تنها کمی بهتر می‌شود زیرا می‌توانید در یک اتاق ساکت بنشینید و غذا داشته باشید و ... اما با این وجود آزار می‌دهد!
اگر می‌خواهید مشاور شوید باید بتوانید سفر کنید و هرچه مسن‌تر شوید کم‌انگیزه‌تر می‌شوید. می‌توان پیش‌بینی کرد که داریم ریسک می‌کنیم.
بله، خصوصاً اگر خانواده و فرزندانی دارید.
ولی مشکل اینجاست که پروژه‌های جذاب معمولاً در آن جاهایی نیست که شما زندگی می‌کنید مگر آنکه در سیاتل یا سانفرانسیسکو باشید. اما اگر یک آدم معمولی در یک شهر معمولی از یک کشور معمولی هستید، همواره باید بین پروژه‌های جذاب و پروژه‌های خانگی انتخاب کنید. الان من حدود 10 سال است که به عنوان مشاور کار می‌کنم و فقط 2 هفته پیش بود که توانستم برای یک مشتری کار کنم که بتوانم شب‌ها پیش پدر و مادرم باشم. معمولاً مشتری‌ها در جای دیگری هستند و باید در هتل اقامت کنید و همه دردسرهای سفر را خواهید داشت.
حتی اگر مشتری خوبی باشد و هتل خوبی باشد، کمک می‌کند که فقط کمی مسائل بهتر و ساده‌تر و خانوادگی‌تر شود اما فقط کمی.
وقتی جوان بودم (یعنی وقتی بچه بودم :-))، من یک سال تمام نزد مشتری کار می‌کردم. روشی که جبرانش می‌کردم این بود که در طول تابستان برای 2-3 ماه، تعطیل می‌کردم بنابراین چیزی داشتم که منتظرش باشم. با این حال در رابطه‌هایم دچار مشکل می‌شدم. بنابراین، این دردآور است، ممکن است ارزشش را داشته باشد، من هنوز به عنوان مشاور کار می‌کنم اما به دلایل مشخصی دیگر به آن مقدار سفر نمی‌کنم. اما شما باید به این مسئله آگاه باشید.
مورد منفی دیگر؟ چیزی سراغ دارید؟
فکر می‌کنم یک مورد منفی دیگر این است که نمی‌توانید برای مدت طولانی با یک تیم باشید و همکارانی پیدا کنید. ما عموماً در IT Agile جلساتی داریم، ما داخل شرکت به هم همکار می‌گوییم اما مانند این نیست که داخل یک تیم توسعه محصول باشید. هنگام توسعه محصول، افراد را هر روزه می‌بینید و با آنها آشنا می‌شوید و یک خانواده کاری دارید. اما در اینجا آن حس را ندارید مگر آنکه برای جایی به مدت خیلی طولانی کار کنید. من برای کاری به مدت 6 سال مشغول بودم البته نیمه‌وقت بود اما مربوط به یک پروژه بود، در انتها همان حس را داشتم که گویی بخشی از خانواده‌ام هستند اما این استثنا است.
یک ریسک دیگر در این ارتباط وجود دارد که اگر با تیمی واقعاً کار نکنید، برایتان سخت می‌شود که یاد بگیرید. من می‌خواهم دوباره در مورد مثال یخچال‌سازی صحبت کنم. من از آن شرکت تا حدی آموختم که چطور یخچال می‌سازند اما نکته اینجاست که من مشاور یخچال‌‌سازی نیستم و نهایتاً برایم اهمیتی ندارد. اگر شما همیشه خبره‌ترین فرد در یک موضوع خاص باشید، احتمال این‌که در آن موضوع از دیگران چیزی یاد بگیرید خیلی کم است؛ قطعاً چیزهای دیگری را یاد می‌گیرید اما آنها خیلی مرتبط با پیشرفت حرفه‌ای شما نیستند. بنابراین فکر می‌کنم این یک مشکل است بهمین خاطر خیلی از مشاورها به کنفرانس‌های زیادی می‌روند و یک شبکه بزرگ دارند و با افراد زیادی صحبت می‌کنند، حتی اگر با هم در یک شرکت نباشند و مانند یک خانواده بزرگ نباشند اما همچنان یک شبکه بزرگ از دوستان و دیگر همکاران تشکیل می‌دهند تا این را تا حدی جبران کنند.
بله، من واقعاً دوست دارم که به کنفرانس‌های زیادی بروم و با این افراد و حضار دیگر صحبت کنم. تلاش می‌کنم که از کنفرانس‌ها برای یاد گرفتن از دیگران استفاده کنم. نه اینکه به سخنرانی‌هایشان گوش دهم بلکه با آنها صحبت می‌کنم و به حرف‌هایشان گوش می‌دهم.
بله، موافقم. و در نهایت، ریسک دیگر این است که به یک سخنران تبدیل شوید، به کسی که فقط سخن می‌گوید. اینکه تعدادی اسلاید منتشرشده داشته باشید و می‌دانید که چه بگویید اما هیچگاه واقعاً عمل نمی‌کنید فقط سخن می‌گویید. از یک طرف این ریسک وجود دارد و نباید به این طریق رفتار کنید اما به عنوان یک مشاور، گاهی این حس را دارید که تا حدی اجتناب‌ناپذیر است. من همواره وقتی پروژه‌ها در یک جهت صحیح قرار می‌گیرند، آنها را ترک می‌کنم و تا آخر کار، وقتی مشکلات بزرگ واقعی پیدا می‌شوند نمی‌ایستم. شما می‌دانید که چگونه است! ابتدای کار، همه چیز راحت است. گاهی وقت‌ها حس می‌کنم که ترجیح می‌دهم در جایی کار کنم که واقعاً چیزی را بسازیم نه اینکه فقط در مورد ساختن چیزها صحبت کنیم.
بله، قطعاً. من پروژه‌هایی که واقعاً در آن چیز مشخصی را انجام می‌دهیم را بیشتر دوست دارم، اهمیت ندارد که از جنبه تکنیکی جذاب باشد یا از جنبه فرآیند توسعه. اما جذاب است که برای مدت طولانی در کنار تیم باشید تا ببینید در طول زمان، چه رخ می‌دهد و شما با مشاوره‌تان چه مشکلاتی را بعد از یک یا دو سال ایجاد کرده‌اید! فکر می‌کنم بعد از این مدت زمان، اگر با تیم همراه شوید، سودمند است زیرا در مورد تجربیاتی که به اشتراک گذاشته‌اید، فرا می‌گیرید در غیر اینصورت در انتها به شرایطی خواهید رسید که دانشتان تنها از صحبت کردن با دیگران حاصل می‌شود و تجربه‌هایتان در طول زمان کم و کمتر می‌شود و دانشتان را تنها از برخی پروژه‌های مشاوره تولید خواهید کرد که هیچگاه واقعاً آنها را تا آخر انجام نداده‌اید.
بیا در مورد جنبه‌های مثبت مشاور بودن صحبت کنیم.
فکر می‌کنم مطلب واضح این است که خیلی افراد جالب را ملاقات می‌کنید. تعداد زیادی تیم‌های خوب را می‌بینید. می‌توانید تکنولوژی‌های مختلف، پروژه‌های مختلف، سیستم‌های مختلف و حوزه‌های مختلف را ببینید که جذاب است. هیچگاه واقعاً کسل‌کننده نمی‌شود.
خوبه! :-)
شما تجربه دیگری دارید؟ :-)
موافقم که همیشه محیط‌ها متفاوتند به عنوان مثال اخیراً برای یک شرکت کار کردم که ماشین‌های لیتوگرافی می‌ساخت که بخشی از تولید چیپ بود و با حدود یک ساعت و نیم آموزش برای آشنایی در مورد چگونگی کار کردن این ماشین‌ها آغاز کردند که به شدت جذاب بود. همین یادگرفتن در مورد سیستم‌ها و محیط‌های مختلف و کارهای جالب مختلفی که افراد می‌کنند، یک جنبه بسیار بسیار عالی این شغل است. اینکه هیچگاه کسل نمی‌شوید را من صد در صد مخالفم زیرا نمی‌دانم تا بحال چه تعداد DSL های XText در سطح Hello Word ساخته‌ام. احتمالاً دیگر بهتر از این نمی‌شوم! این کسل‌کننده است! بهمین خاطر است که همیشه تلاش می‌کنم تا مطمئن شوم مشتریانم حداقل حوزه خاصی که می‌خواهند برایش زبان بسازیم را به من پیشنهاد دهند زیرا واقعاً دوست ندارم که Hello Word استاندارد خودم را بسازم زیرا خیلی کسل‌کننده است. در حالت کلی، موافقم که (آنچه گفتید) مزیت بزرگ این شغل است.
فکر می‌کنم این هم مزیت است که در ساختارهای متداول شرکت‌ها، قرار نمی‌گیرید.
منظورتان سیاست‌ها (یِ سازمانی) است؟
سیاست‌ها، سلسله‌مراتب‌ها، رئیس‌تان، مقامتان و ... . اینها واقعاً در کارهای روزمره‌تان در سایت مشتری، مطرح نیست. گاهی آن نحوه کار کردن در شرکت‌های بزرگ و سلسله‌مراتب بزرگ، آزاردهنده است!
یا نحوه کار نکردن!
یا شاید نحوه کار نکردن! گاهی خوب‌ است که می‌گویید بسیار خوب، کار تمام شد و به شرکت کوچک مشاوره‌ای‌تان برمی‌گردید و یا بسراغ تیم دیگری می‌روید و زندگی می‌تواند شکل دیگری پیدا کند.
نکته مثبت دیگر می‌تواند این باشد -دقت کنید که آن را بسنجید- که می‌توانید بصورت مستقل کار کنید. اگر می‌خواهید که سفر کنید و می‌خواهید کل سال را کار کنید، می‌توانید این مقدار پول را بدون ریسک خاصی کسب کنید، اینطور نیست که 10ها هزار یورو برای چیزی سرمایه‌گذاری کنید. مانند استارتاپ‌ها نیست البته استارتاپ چیز دیگری است، با یک استارتاپ موفق، می‌توانید خیلی بیشتر از یک مشاور درآمد داشته باشید اما احتمالاً اگر در یک شرکت عادی کار کنید، نمی‌توانید به این مقدار درآمد داشته باشید. من اینطور فکر می‌کنم البته هیچگاه آن کار را نکرده‌ام. البته لازمه‌اش این است که کل سال‌تان را یعنی 200 روز در سال را کار کنید و آن را به تکه‌های کوچک مشاوره‌های مجزا‌ بشکنید زیرا اگر برای یک پروژه یکسان برای مدت طولانی کار کنید، حقوق روزانه‌تان واقعاً پایین می‌آید. بنابراین اگر می‌خواهید که مسافرت کنید و مشتری‌های زیاد متفاوتی داشته باشید، می‌توانید مقدار درآمد زیادی داشته باشید. این یک جنبه جذاب این شغل است.
بله، خصوصاً برای کسانی که برای خودشان کار می‌کنند و مشاور مستقل هستند.
بله، اگر حقوقتان به مقدار پولی که خودتان درمی‌آورید، بستگی داشته باشد. واضح است که در مورد افرادی که برای خودشان کار می‌کنند و مستقل هستند اینطور است و همینطور چنانچه در شرکت‌های مشاوره‌ای کلاسیک کار کنید (اینطور است). من می‌دانم که دست‌کم در برخی از آنها، حقوق شما به مقدار درآمدی که خودتان برای شرکت درمی‌آورید بستگی دارد. در آنجا نیز این همبستگی (بین درآمدی که تولید کرده‌اید و حقوقتان) وجود دارد.
مطلب این است که اگر تعداد زیادی مشاوره‌های کوچک انجام دهید، باید انعطاف خیلی زیادی در مورد تعطیلی‌‌هایتان داشته باشید. مجبورید وقتی می‌خواهید تعطیلات داشته باشید، کار کنید. من دیگر این کار را نمی‌کنم به همین خاطر است که درآمدم طی چند سال اخیر کاهش یافته است چون نمی‌خواهم همه وقتم را با مشتری سپر کنم و هر روزه سفر کنم.
بنابراین، این هم (درآمد) قطعاً بالقوه یک مورد مثبت است. اما آیا مورد مثبت دیگری هم در مورد شغل ما وجود دارد؟ به نظرم، بزرگترین مزیت شغل ما همین یادگیری در مورد سیستم‌های مختلف و جاهایی است که افراد آن را استفاده می‌کنند. منظورم این است که (بفهمید) تکنولوژی‌هایی که شما می‌توانید بفروشید را افراد چگونه و کجا استفاده می‌کنند. زیرا اگر موضوع خاصی تمرکز کنید و روی آن موضوع با مشتری‌های مختلف کار کنید، می‌توانید ببینید که مثلاً افراد DSL ها را چگونه استفاده می‌کنند و با این مشاهدات خیلی یاد می‌گیرید که جذاب است.
بسیار خوب، فکر می‌کنم اینها اساساً چیزهایی بودند که آماده کرده بودیم. درسته؟
بله، چیزهایی بودند که بصورت نقل قول آماده کرده بودیم.
بله، از قصد خیلی محاوره‌ای ضبط کردیم و برایش خیلی زیاد آماده نکردیم. ما هر دو تجربه مشاوره داریم و نمی‌خواستیم در قالب مصاحبه‌گر و مصاحبه‌شونده اجرا کنیم. بنابراین شاید یک کمی آماده‌نشده و آشفته به نظر برسد. با این حال امیدواریم، خوشتان آمده باشد.