سلام دوستان عزیزم
۵۰۰ دوره آموزشی مکتب‌خونه رایگان شد.
دوره آموزش پایگاه داده بنده نیز در لیست دوره ها قرار داره.
فراهم‌کردن دسترسی گسترده‌تر به آموزش باکیفیت، یکی از اهداف اصلی مکتب‌خونه است. در ادامه این مسیر، در طرح «ایرانِ ماهر» ۵۰۰ دوره آموزشی تا ۸ شهریور رایگان شده است.
این طرح که با همراهی مدرسان مکتب‌خونه اجرا شده، فرصتی فراهم می‌کند تا افراد بیشتری بتوانند بدون دغدغه مالی، مهارت‌های مورد نیازشان را برای ورود به بازار کار، پیشرفت شغلی یا توسعه فردی یاد بگیرند.
دوره‌های رایگان ایران ماهر موضوعات متنوعی را پوشش می‌دهند؛ از برنامه‌نویسی، هوش مصنوعی و آی‌تی تا زبان، مدیریت، بازاریابی، مالی، حسابداری و مهارت‌های شغلی.
برای استفاده از این فرصت، از طریق لینک زیر دوره مورد نظرتان را انتخاب کنید و با وارد کردن کد IRANMAHER در مرحله پرداخت، آن را با تخفیف ۱۰۰٪ دریافت کنید.
اگر فکر می‌کنید این فرصت می‌تواند برای فرد دیگری هم مناسب باشد، این پست را با او به اشتراک بگذارید.
https://land.maktabkhooneh.org/iranmaher/?utm_source=linkedin&utm_medium=social&utm_campaign=iranmaher-linkedin-social-mk
۵۰۰ دوره آموزشی مکتب‌خونه رایگان شد.
دوره آموزش پایگاه داده بنده نیز در لیست دوره ها قرار داره.
فراهم‌کردن دسترسی گسترده‌تر به آموزش باکیفیت، یکی از اهداف اصلی مکتب‌خونه است. در ادامه این مسیر، در طرح «ایرانِ ماهر» ۵۰۰ دوره آموزشی تا ۸ شهریور رایگان شده است.
این طرح که با همراهی مدرسان مکتب‌خونه اجرا شده، فرصتی فراهم می‌کند تا افراد بیشتری بتوانند بدون دغدغه مالی، مهارت‌های مورد نیازشان را برای ورود به بازار کار، پیشرفت شغلی یا توسعه فردی یاد بگیرند.
دوره‌های رایگان ایران ماهر موضوعات متنوعی را پوشش می‌دهند؛ از برنامه‌نویسی، هوش مصنوعی و آی‌تی تا زبان، مدیریت، بازاریابی، مالی، حسابداری و مهارت‌های شغلی.
برای استفاده از این فرصت، از طریق لینک زیر دوره مورد نظرتان را انتخاب کنید و با وارد کردن کد IRANMAHER در مرحله پرداخت، آن را با تخفیف ۱۰۰٪ دریافت کنید.
اگر فکر می‌کنید این فرصت می‌تواند برای فرد دیگری هم مناسب باشد، این پست را با او به اشتراک بگذارید.
https://land.maktabkhooneh.org/iranmaher/?utm_source=linkedin&utm_medium=social&utm_campaign=iranmaher-linkedin-social-mk
❤26🙏4👍2👏1
یکی از چالش‌هایی که این روزها توی شرکت‌ها زیاد باهاش برخورد میکنم، مخصوصاً در حوزه BI، تعریف درست مسئله است.
گاهی می‌بینم سازمان اصلاً واحد یا نقش مشخصی برای این کار نداره و هر بخشی، از زاویه خودش، شروع می‌کنه به تعریف مسئله و ارائه راهکار.
اینجاست که کم‌کم داستان جالب میشه! 😄
چون همین موضوع میتونه باعث ایجاد تضاد منافع بین واحدهای مختلف، مخصوصاً کسب‌وکار و فناوری اطلاعات، بشه.
به نظرم قبل از اینکه بریم سراغ زیرساخت فنی، دیتابیس، ابزار BI یا انتخاب تکنولوژی، باید یک چیز دیگه رو درست کنیم:
زیرساخت کسب‌وکار.
یعنی اول مشخص کنیم:
🔹 چه کسی مسئله رو تعریف می‌کنه؟
🔹 چه کسی مالک مسئله است؟
🔹 نقش IT دقیقاً چیه؟
🔹 ارتباط بین واحد کسب‌وکار و IT چطور باید باشه؟
🔹 تصمیم‌گیری در مورد راهکار با چه کسیه؟
🔹 و اصلاً مسئله‌ای که داریم حل می‌کنیم، دقیقاً چیه؟
خیلی وقت‌ها مشکل اصلی سازمان کمبود تکنولوژی نیست.
مشکل اینه که چند نفر دارن یک مسئله رو، هر کدوم از زاویه خودشون، تعریف می‌کنن.
من معمولاً قبل از اینکه وارد اصلاح زیرساخت فنی بشم، سعی میکنم این بخش رو شفاف کنم؛ چون اگر نقش‌ها و ارتباطات درست نباشه، بهترین معماری و بهترین ابزار BI هم در نهایت میتونه تبدیل به یک نقطه اصطکاک جدید بین واحدها بشه.
هدف اینه که جلوی این سایش‌ها رو قبل از اینکه تبدیل به یک مشکل جدی برای سازمان بشن بگیریم.
حالا کنجکاوم بدونم شما توی سازمانتون برای این موضوع چه راهکاری دارید؟
تعریف مسئله معمولاً دست چه کسیه؟ و وقتی بین کسب‌وکار و IT اختلافی پیش میاد، چطور حلش می‌کنید؟
و البته...
اگر چنین چالش‌هایی دارید و دنبال یک نفر می‌گردید که وسط این دعواها بایسته و مسئله رو جمع کنه، می‌تونید روی من حساب کنید! 😄
قول نمی‌دم همه از جلسه راضی بیان بیرون،
ولی قول میدم مسئله بالاخره صاحب پیدا کنه! 😂
اگر هم دوست دارید عکس «قبل از جلسه» رو بفرستید و «جنازه تحویل بگیرید»، اون مدل همکاری رو باید با تیمم بررسی کنم! 😂
ولی جدا از شوخی، بخش زیادی از کاری که انجام میدم دقیقاً همینجاست؛
جایی بین کسب‌وکار، IT، داده و آدم‌ها.
جایی که معمولاً مشکل، نبودن تکنولوژی نیست؛
مشکل اینه که هنوز معلوم نیست کی باید چه کاری رو انجام بده و اصلاً داریم چه مسئله‌ای رو حل می‌کنیم.
گاهی می‌بینم سازمان اصلاً واحد یا نقش مشخصی برای این کار نداره و هر بخشی، از زاویه خودش، شروع می‌کنه به تعریف مسئله و ارائه راهکار.
اینجاست که کم‌کم داستان جالب میشه! 😄
چون همین موضوع میتونه باعث ایجاد تضاد منافع بین واحدهای مختلف، مخصوصاً کسب‌وکار و فناوری اطلاعات، بشه.
به نظرم قبل از اینکه بریم سراغ زیرساخت فنی، دیتابیس، ابزار BI یا انتخاب تکنولوژی، باید یک چیز دیگه رو درست کنیم:
زیرساخت کسب‌وکار.
یعنی اول مشخص کنیم:
🔹 چه کسی مسئله رو تعریف می‌کنه؟
🔹 چه کسی مالک مسئله است؟
🔹 نقش IT دقیقاً چیه؟
🔹 ارتباط بین واحد کسب‌وکار و IT چطور باید باشه؟
🔹 تصمیم‌گیری در مورد راهکار با چه کسیه؟
🔹 و اصلاً مسئله‌ای که داریم حل می‌کنیم، دقیقاً چیه؟
خیلی وقت‌ها مشکل اصلی سازمان کمبود تکنولوژی نیست.
مشکل اینه که چند نفر دارن یک مسئله رو، هر کدوم از زاویه خودشون، تعریف می‌کنن.
من معمولاً قبل از اینکه وارد اصلاح زیرساخت فنی بشم، سعی میکنم این بخش رو شفاف کنم؛ چون اگر نقش‌ها و ارتباطات درست نباشه، بهترین معماری و بهترین ابزار BI هم در نهایت میتونه تبدیل به یک نقطه اصطکاک جدید بین واحدها بشه.
هدف اینه که جلوی این سایش‌ها رو قبل از اینکه تبدیل به یک مشکل جدی برای سازمان بشن بگیریم.
حالا کنجکاوم بدونم شما توی سازمانتون برای این موضوع چه راهکاری دارید؟
تعریف مسئله معمولاً دست چه کسیه؟ و وقتی بین کسب‌وکار و IT اختلافی پیش میاد، چطور حلش می‌کنید؟
و البته...
اگر چنین چالش‌هایی دارید و دنبال یک نفر می‌گردید که وسط این دعواها بایسته و مسئله رو جمع کنه، می‌تونید روی من حساب کنید! 😄
قول نمی‌دم همه از جلسه راضی بیان بیرون،
ولی قول میدم مسئله بالاخره صاحب پیدا کنه! 😂
اگر هم دوست دارید عکس «قبل از جلسه» رو بفرستید و «جنازه تحویل بگیرید»، اون مدل همکاری رو باید با تیمم بررسی کنم! 😂
ولی جدا از شوخی، بخش زیادی از کاری که انجام میدم دقیقاً همینجاست؛
جایی بین کسب‌وکار، IT، داده و آدم‌ها.
جایی که معمولاً مشکل، نبودن تکنولوژی نیست؛
مشکل اینه که هنوز معلوم نیست کی باید چه کاری رو انجام بده و اصلاً داریم چه مسئله‌ای رو حل می‌کنیم.
❤7👍3
یکی از چیزهایی که توی بعضی تیم‌ها می‌بینم، بیشتر از اینکه شبیه تیم باشه، شبیه مسابقات انتخاباتیه! 😂
هنوز پروژه شروع نشده، ولی یارکشی شروع شده:
«تو با مایی؟»
«اون با اوناست.»
«پس اینو به اون نگو!»
«جلسه داریم؟ کی تو جلسه‌ست؟»
«فلانی هم هست؟ پس من نمیام!» 😐
گاهی اوقات یک تیم ۱۰ نفره داریم با ۴ تا جبهه!
هر جبهه هم یک رهبر داره، یک تحلیلگر داره، یک سخنگو داره و البته چند نفر هم هستن که هنوز نمی‌دونن دقیقاً عضو کدوم جبهه‌ان! 😂
بعد کم‌کم آثارش خودش رو نشون میده.
لجبازی شروع میشه.
تقصیرها میفته گردن همدیگه.
اطلاعات تبدیل میشه به سلاح جنگی.
جلسه‌ها به جای حل مسئله، میشه دادگاه.
ناهار خوردن هم میشه محل تجدید قوا! 😄
یه عده با هم میرن ناهار و درباره یه عده دیگه حرف می‌زنن.
یه عده دیگه هم همون موقع یه جای دیگه نشستن و دارن درباره گروه اول حرف می‌زنن!
و در نهایت، هیچ‌کس دیگه دقیقاً نمی‌دونه مشکل اصلی چی بوده.
فقط همه مطمئنن که:
«مشکل از اوناست!» 😂
اینجاست که به نظرم نقش یک مربی یا لیدر خیلی جدی میشه.
قرار نیست فقط KPI و تسک و خروجی تیم رو نگاه کنه.
باید بفهمه چه کسی با چه کسی مشکل داره، چرا مشکل داره و این اختلاف داره چه بلایی سر کار میاره.
چون اگر این داستان به موقع مدیریت نشه، یه اختلاف ساده بین دو نفر میتونه کل تیم رو تبدیل کنه به جنگ داخلی.
و بدتر از همه اینکه معمولاً وسط این جنگ، پروژه هم یه گوشه نشسته و داره با خودش میگه:
«بچه‌ها من فقط قرار بود تحویل داده بشم... چرا به خاطر من جنگ جهانی راه انداختید؟!» 😂
به نظرم یکی از نشونه‌های یک تیم سالم این نیست که همه با هم دوست صمیمی باشن.
اینکه بتونن با وجود اختلاف نظر، هنوز کنار هم کار کنن خیلی مهم‌تره.
شما توی تیم‌هاتون با این مدل یارکشی مواجه شدید؟ 😄
هنوز پروژه شروع نشده، ولی یارکشی شروع شده:
«تو با مایی؟»
«اون با اوناست.»
«پس اینو به اون نگو!»
«جلسه داریم؟ کی تو جلسه‌ست؟»
«فلانی هم هست؟ پس من نمیام!» 😐
گاهی اوقات یک تیم ۱۰ نفره داریم با ۴ تا جبهه!
هر جبهه هم یک رهبر داره، یک تحلیلگر داره، یک سخنگو داره و البته چند نفر هم هستن که هنوز نمی‌دونن دقیقاً عضو کدوم جبهه‌ان! 😂
بعد کم‌کم آثارش خودش رو نشون میده.
لجبازی شروع میشه.
تقصیرها میفته گردن همدیگه.
اطلاعات تبدیل میشه به سلاح جنگی.
جلسه‌ها به جای حل مسئله، میشه دادگاه.
ناهار خوردن هم میشه محل تجدید قوا! 😄
یه عده با هم میرن ناهار و درباره یه عده دیگه حرف می‌زنن.
یه عده دیگه هم همون موقع یه جای دیگه نشستن و دارن درباره گروه اول حرف می‌زنن!
و در نهایت، هیچ‌کس دیگه دقیقاً نمی‌دونه مشکل اصلی چی بوده.
فقط همه مطمئنن که:
«مشکل از اوناست!» 😂
اینجاست که به نظرم نقش یک مربی یا لیدر خیلی جدی میشه.
قرار نیست فقط KPI و تسک و خروجی تیم رو نگاه کنه.
باید بفهمه چه کسی با چه کسی مشکل داره، چرا مشکل داره و این اختلاف داره چه بلایی سر کار میاره.
چون اگر این داستان به موقع مدیریت نشه، یه اختلاف ساده بین دو نفر میتونه کل تیم رو تبدیل کنه به جنگ داخلی.
و بدتر از همه اینکه معمولاً وسط این جنگ، پروژه هم یه گوشه نشسته و داره با خودش میگه:
«بچه‌ها من فقط قرار بود تحویل داده بشم... چرا به خاطر من جنگ جهانی راه انداختید؟!» 😂
به نظرم یکی از نشونه‌های یک تیم سالم این نیست که همه با هم دوست صمیمی باشن.
اینکه بتونن با وجود اختلاف نظر، هنوز کنار هم کار کنن خیلی مهم‌تره.
شما توی تیم‌هاتون با این مدل یارکشی مواجه شدید؟ 😄
❤15👍1
دو تا گل خوردی. 😐
نیمه اول تموم شده و تیم هم واقعاً افتضاح بازی کرده.
حالا وقتشه مربی بره وسط رختکن و شروع کنه:
«این چه وضع بازی کردنه؟!
اصلاً معلومه دارید چیکار می‌کنید؟!
این تیم با این وضع به هیچ جا نمی‌رسه!»
بعد هم چند تا بازیکن رو تحقیر کنه که روحیه‌شون هم کامل نابود بشه. 😑
جالبه که هنوز خیلی‌ها فکر می‌کنن این یعنی «رهبری مقتدر».
در حالی که خیلی وقت‌ها اسمش فقط تخلیه عصبانیت مدیریتیه! 😂
واقعیت اینه که تیم، فقط مجموعه‌ای از آدم‌ها نیست که کنار هم کار می‌کنن.
تیم یک رابطه‌ست.
گاهی مدیر از تیم چیزی می‌خواد و تیم بهش نمی‌ده.
گاهی تیم چیزی از مدیر می‌خواد و مدیر بهش نمی‌ده.
و دقیقاً از همین‌جا فاصله شروع میشه.
نه یک‌دفعه.
آروم‌آروم...
با یک جلسه که کسی حرف واقعی‌اش رو نمی‌زنه.
با یک تصمیم که فقط از بالا گرفته میشه.
با چند بار شنیدنِ «الان وقت این بحث‌ها نیست».
با مدیری که فقط خروجی می‌خواد، ولی هیچ‌وقت نمی‌پرسه:
«برای اینکه این خروجی رو بسازید، از من چی لازم دارید؟»
و بعد یک روز می‌بینیم تیم هست...
جلسه هست...
KPI هست...
گزارش هم هست...
ولی تیم بودن نیست.
به نظرم یکی از مهم‌ترین وظایف یک رهبر این نیست که وقتی تیم خراب کرد، بیشتر فشار بیاره.
این نیست که صدایش را بلندتر کند.
این نیست که دنبال مقصر بگردد.
وظیفه‌اش اینه که بفهمه:
«من برای بهتر شدن این تیم، خودم چه چیزی رو باید تغییر بدم؟»
گاهی اوقات موندن در همین وضعیت موجود، خیلی دردناک‌تر از تغییر کردنه.
و تیم‌های خوب دقیقاً همین‌جا خودشون رو نشون میدن.
ممکنه دو تا گل خورده باشن...
ولی برمی‌گردن توی زمین و میگن:
«خب... حالا بریم جبرانش کنیم.» 🔥
شاید فرق یک مدیر معمولی و یک رهبر واقعی همین باشه:
مدیر می‌پرسه:
«کی خراب کرد؟»
رهبر می‌پرسه:
«چطور دوباره برگردیم به بازی؟»
حالا یک سؤال جدی:
اگر تیم شما عملکرد خوبی نداره...
اولین چیزی که باید تغییر کنه چیه؟
آدم‌های تیم؟
یا مدل رهبری ما؟
بیاید ببینیم چند نفر جرأت دارن گزینه دوم رو انتخاب کنن. 👀
نیمه اول تموم شده و تیم هم واقعاً افتضاح بازی کرده.
حالا وقتشه مربی بره وسط رختکن و شروع کنه:
«این چه وضع بازی کردنه؟!
اصلاً معلومه دارید چیکار می‌کنید؟!
این تیم با این وضع به هیچ جا نمی‌رسه!»
بعد هم چند تا بازیکن رو تحقیر کنه که روحیه‌شون هم کامل نابود بشه. 😑
جالبه که هنوز خیلی‌ها فکر می‌کنن این یعنی «رهبری مقتدر».
در حالی که خیلی وقت‌ها اسمش فقط تخلیه عصبانیت مدیریتیه! 😂
واقعیت اینه که تیم، فقط مجموعه‌ای از آدم‌ها نیست که کنار هم کار می‌کنن.
تیم یک رابطه‌ست.
گاهی مدیر از تیم چیزی می‌خواد و تیم بهش نمی‌ده.
گاهی تیم چیزی از مدیر می‌خواد و مدیر بهش نمی‌ده.
و دقیقاً از همین‌جا فاصله شروع میشه.
نه یک‌دفعه.
آروم‌آروم...
با یک جلسه که کسی حرف واقعی‌اش رو نمی‌زنه.
با یک تصمیم که فقط از بالا گرفته میشه.
با چند بار شنیدنِ «الان وقت این بحث‌ها نیست».
با مدیری که فقط خروجی می‌خواد، ولی هیچ‌وقت نمی‌پرسه:
«برای اینکه این خروجی رو بسازید، از من چی لازم دارید؟»
و بعد یک روز می‌بینیم تیم هست...
جلسه هست...
KPI هست...
گزارش هم هست...
ولی تیم بودن نیست.
به نظرم یکی از مهم‌ترین وظایف یک رهبر این نیست که وقتی تیم خراب کرد، بیشتر فشار بیاره.
این نیست که صدایش را بلندتر کند.
این نیست که دنبال مقصر بگردد.
وظیفه‌اش اینه که بفهمه:
«من برای بهتر شدن این تیم، خودم چه چیزی رو باید تغییر بدم؟»
گاهی اوقات موندن در همین وضعیت موجود، خیلی دردناک‌تر از تغییر کردنه.
و تیم‌های خوب دقیقاً همین‌جا خودشون رو نشون میدن.
ممکنه دو تا گل خورده باشن...
ولی برمی‌گردن توی زمین و میگن:
«خب... حالا بریم جبرانش کنیم.» 🔥
شاید فرق یک مدیر معمولی و یک رهبر واقعی همین باشه:
مدیر می‌پرسه:
«کی خراب کرد؟»
رهبر می‌پرسه:
«چطور دوباره برگردیم به بازی؟»
حالا یک سؤال جدی:
اگر تیم شما عملکرد خوبی نداره...
اولین چیزی که باید تغییر کنه چیه؟
آدم‌های تیم؟
یا مدل رهبری ما؟
بیاید ببینیم چند نفر جرأت دارن گزینه دوم رو انتخاب کنن. 👀
👍11🤡2❤1
اگه برای پولدار شدن، اول باید پولدار باشی چی؟! 🤔😂
نه، اشتباه تایپی نکردم!
امروز از مربی عزیزم یک فیلم می‌دیدم که بحثش دقیقاً همین بود:
بودن، انجام دادن و داشتن.
ما معمولاً اینطوری فکر می‌کنیم:
اول باید داشته باشم ➡️
بعد باهاش یک کاری انجام بدم ➡️
بعد به یک احساسی برسم.
مثلاً:
«اگه یه هواپیمای شخصی داشته باشم، می‌تونم هر وقت دلم خواست برم سفر و تفریح، اون‌وقت خیلی خوشحال و راضی می‌شم.» ✈️😎
یا:
«اگه پول بیشتری داشته باشم، خیالم راحت میشه و احساس ثروتمند بودن میکنم.» 💰
ولی یک سؤال جالب مطرح شد:
نکنه مسیر برعکس باشه؟ 🤔
یعنی اول اون چیزی که می‌خوای احساس کنی رو در خودت ایجاد کنی.
بعد بر اساس اون احساس، رفتار کنی.
و در نهایت، اون «داشتن» هم کم‌کم شکل بگیره.
مثلاً اگر می‌خوای ثروتمند باشی، از خودت بپرسی:
اگر واقعاً ثروتمند بودم،
چطور فکر می‌کردم؟
چطور تصمیم می‌گرفتم؟
چطور با آدم‌ها حرف می‌زدم؟
چطور ریسک می‌کردم؟
چطور فرصت‌ها رو می‌دیدم؟
حالا یک مثال بامزه‌تر:
فرض کنید یک سرمایه‌گذار اتفاقی به پست شما بخوره و بگه:
«من برای ایده‌ات سرمایه‌گذاری میکنم.» 😎💰
به نظرت از نوشته و رفتارت چه چیزی باید بگیره؟
حس غنی بودن؟
یا:
«داداش فقط یه سرمایه‌گذار پیدا بشه، زندگیم درست میشه!» 😂
شاید ما خیلی وقت‌ها منتظریم چیزی را داشته باشیم تا تبدیل به آدمی بشیم که می‌خوایم باشیم.
در حالی که شاید باید اول اون آدم بشیم تا بعضی از اون چیزها وارد زندگیمون بشن.
من خودم تجربه‌های مختلفی از این موضوع داشتم و جالب اینجاست که یکی دیگه از استادهای عزیزم هم سال‌ها قبل تقریباً همین مفهوم رو به شکل دیگه‌ای بهم گفته بود.
و راستش هر بار که تجربه‌اش کردم، بیشتر بهش فکر کردم.
شاید سؤال درست این نباشه که:
«چی می‌خوام داشته باشم؟»
بلکه این باشه:
«وقتی به چیزی که می‌خوام رسیدم، قرارِ چه آدمی باشم و چه حسی داشته باشم؟»
و بعد...
از همین امروز همون آدم باشم. 🎯
حالا کنجکاوم بدونم شما چی فکر می‌کنید؟ 👇
تا حالا شده اول «حس و حالِ داشتنِ یک چیز» رو در خودتون ایجاد کنید و بعد خود اون اتفاق بیفته؟
یا کلاً می‌گید:
«نه داداش، اول هواپیما رو بده، بعد درباره حسش صحبت می‌کنیم!» 😂✈️
نه، اشتباه تایپی نکردم!
امروز از مربی عزیزم یک فیلم می‌دیدم که بحثش دقیقاً همین بود:
بودن، انجام دادن و داشتن.
ما معمولاً اینطوری فکر می‌کنیم:
اول باید داشته باشم ➡️
بعد باهاش یک کاری انجام بدم ➡️
بعد به یک احساسی برسم.
مثلاً:
«اگه یه هواپیمای شخصی داشته باشم، می‌تونم هر وقت دلم خواست برم سفر و تفریح، اون‌وقت خیلی خوشحال و راضی می‌شم.» ✈️😎
یا:
«اگه پول بیشتری داشته باشم، خیالم راحت میشه و احساس ثروتمند بودن میکنم.» 💰
ولی یک سؤال جالب مطرح شد:
نکنه مسیر برعکس باشه؟ 🤔
یعنی اول اون چیزی که می‌خوای احساس کنی رو در خودت ایجاد کنی.
بعد بر اساس اون احساس، رفتار کنی.
و در نهایت، اون «داشتن» هم کم‌کم شکل بگیره.
مثلاً اگر می‌خوای ثروتمند باشی، از خودت بپرسی:
اگر واقعاً ثروتمند بودم،
چطور فکر می‌کردم؟
چطور تصمیم می‌گرفتم؟
چطور با آدم‌ها حرف می‌زدم؟
چطور ریسک می‌کردم؟
چطور فرصت‌ها رو می‌دیدم؟
حالا یک مثال بامزه‌تر:
فرض کنید یک سرمایه‌گذار اتفاقی به پست شما بخوره و بگه:
«من برای ایده‌ات سرمایه‌گذاری میکنم.» 😎💰
به نظرت از نوشته و رفتارت چه چیزی باید بگیره؟
حس غنی بودن؟
یا:
«داداش فقط یه سرمایه‌گذار پیدا بشه، زندگیم درست میشه!» 😂
شاید ما خیلی وقت‌ها منتظریم چیزی را داشته باشیم تا تبدیل به آدمی بشیم که می‌خوایم باشیم.
در حالی که شاید باید اول اون آدم بشیم تا بعضی از اون چیزها وارد زندگیمون بشن.
من خودم تجربه‌های مختلفی از این موضوع داشتم و جالب اینجاست که یکی دیگه از استادهای عزیزم هم سال‌ها قبل تقریباً همین مفهوم رو به شکل دیگه‌ای بهم گفته بود.
و راستش هر بار که تجربه‌اش کردم، بیشتر بهش فکر کردم.
شاید سؤال درست این نباشه که:
«چی می‌خوام داشته باشم؟»
بلکه این باشه:
«وقتی به چیزی که می‌خوام رسیدم، قرارِ چه آدمی باشم و چه حسی داشته باشم؟»
و بعد...
از همین امروز همون آدم باشم. 🎯
حالا کنجکاوم بدونم شما چی فکر می‌کنید؟ 👇
تا حالا شده اول «حس و حالِ داشتنِ یک چیز» رو در خودتون ایجاد کنید و بعد خود اون اتفاق بیفته؟
یا کلاً می‌گید:
«نه داداش، اول هواپیما رو بده، بعد درباره حسش صحبت می‌کنیم!» 😂✈️
👍15❤1👏1🤡1
یه تصمیم گرفتم...
می‌خوام هفته‌ای ۱۰ ساعت از وقتم رو بفروشم! 😂
البته نه به بالاترین پیشنهاد!
به جالب‌ترین مسئله‌ای که ارزش حل کردن داشته باشه. 😎
این روزها خیلی از شرکت‌ها و سازمان‌ها کلی آدم، کلی سیستم و کلی داده دارن؛
ولی بعضی وقت‌ها یک مشکل ساده باعث میشه همه‌چیز قفل بشه.
مثلاً:
🔹 دیتابیس داریم، ولی وقتی سیستم کند میشه کسی دقیق نمی‌دونه مشکل کجاست.
🔹 BI داریم، ولی هنوز برای تصمیم‌گیری باید از چند نفر بپرسیم «به نظرتون چی کار کنیم؟» 😄
🔹 تیم فنی داریم، ولی تیم بیشتر داره «کار انجام میده» تا اینکه واقعاً «مسئله حل کنه».
🔹 سرویس داریم، ولی مشتری تجربه خوبی ازش نداره.
🔹 یا اصلاً سازمانی داریم که احساس می‌کنه باید یک تغییر جدی ایجاد کنه، ولی نمی‌دونه از کجا شروع کنه.
من تصمیم گرفتم هفته‌ای ۱۰ ساعت از وقتم رو اختصاص بدم به چنین مسئله‌هایی.
حوزه‌هایی که می‌تونم کنارتون باشم:
🧠 معماری و سیستم‌های داده
⚙️ SQL Server و Performance Tuning
📊 BI و Data Strategy
👥 تیم‌سازی و ساختار تیم‌های فنی
🚀 محصول و سرویس
🎯 Service Design و حل مسئله
قرار نیست بیام چندتا اسلاید درست کنم، تحویل بدم و برم! 😁
ترجیح میدم کنار تیم باشم، مسئله رو بفهمیم، ریشه‌ش رو پیدا کنیم و ببینیم واقعاً چه کاری میشه براش کرد.
پس اگر توی شرکت یا سازمانتون یک مسئله جدی دارید که مدت‌هاست کسی نتونسته درست حلش کنه...
شاید همون مسئله‌ای باشه که من دنبالشم. 😉
📩 اگر فکر می‌کنید می‌تونیم کنار هم کاری کنیم، بهم پیام بدید.
و یک سؤال هم از شما:
اگر قرار بود فقط ۱۰ ساعت در هفته وقت داشته باشید و بخواید با شرکت‌ها کار کنید، روی چه مسئله‌ای تمرکز می‌کردید؟
کنجکاوم بدونم 👇
می‌خوام هفته‌ای ۱۰ ساعت از وقتم رو بفروشم! 😂
البته نه به بالاترین پیشنهاد!
به جالب‌ترین مسئله‌ای که ارزش حل کردن داشته باشه. 😎
این روزها خیلی از شرکت‌ها و سازمان‌ها کلی آدم، کلی سیستم و کلی داده دارن؛
ولی بعضی وقت‌ها یک مشکل ساده باعث میشه همه‌چیز قفل بشه.
مثلاً:
🔹 دیتابیس داریم، ولی وقتی سیستم کند میشه کسی دقیق نمی‌دونه مشکل کجاست.
🔹 BI داریم، ولی هنوز برای تصمیم‌گیری باید از چند نفر بپرسیم «به نظرتون چی کار کنیم؟» 😄
🔹 تیم فنی داریم، ولی تیم بیشتر داره «کار انجام میده» تا اینکه واقعاً «مسئله حل کنه».
🔹 سرویس داریم، ولی مشتری تجربه خوبی ازش نداره.
🔹 یا اصلاً سازمانی داریم که احساس می‌کنه باید یک تغییر جدی ایجاد کنه، ولی نمی‌دونه از کجا شروع کنه.
من تصمیم گرفتم هفته‌ای ۱۰ ساعت از وقتم رو اختصاص بدم به چنین مسئله‌هایی.
حوزه‌هایی که می‌تونم کنارتون باشم:
🧠 معماری و سیستم‌های داده
⚙️ SQL Server و Performance Tuning
📊 BI و Data Strategy
👥 تیم‌سازی و ساختار تیم‌های فنی
🚀 محصول و سرویس
🎯 Service Design و حل مسئله
قرار نیست بیام چندتا اسلاید درست کنم، تحویل بدم و برم! 😁
ترجیح میدم کنار تیم باشم، مسئله رو بفهمیم، ریشه‌ش رو پیدا کنیم و ببینیم واقعاً چه کاری میشه براش کرد.
پس اگر توی شرکت یا سازمانتون یک مسئله جدی دارید که مدت‌هاست کسی نتونسته درست حلش کنه...
شاید همون مسئله‌ای باشه که من دنبالشم. 😉
📩 اگر فکر می‌کنید می‌تونیم کنار هم کاری کنیم، بهم پیام بدید.
و یک سؤال هم از شما:
اگر قرار بود فقط ۱۰ ساعت در هفته وقت داشته باشید و بخواید با شرکت‌ها کار کنید، روی چه مسئله‌ای تمرکز می‌کردید؟
کنجکاوم بدونم 👇
❤11👍1
زنگ زدم به مدیر دیتابیس یه شرکت بزرگ!!! 😐
دارم باهاش در مورد HA و Always On صحبت میکنم، طرف برگشته میگه:
«Always On رو چطوری راه‌اندازی می‌کنید؟ با Replica Log انجام ندین‌ها!»
😐😐😐
بعضیا هم میان میگن Always On رو با Log Shipping انجام بدین!
داداش... یه لحظه وایسا! 😂
Replication یه تکنولوژیه.
Log Shipping یه تکنولوژیه.
Always On Availability Group هم یه تکنولوژیه.
این‌ها سه تا چیز متفاوتن که هر کدوم برای یک سناریو و یک نیاز طراحی شدن.
اینکه همه‌شون یه جوری داده رو از یه جا به یه جای دیگه منتقل می‌کنن، دلیل نمیشه یکی باشن! 😂
اول اینکه Log Shipping نمیاد Always On رو راه‌اندازی کنه.
دوم اینکه Replication هم جایگزین Always On برای HA نیست.
ممکنه توی یک معماری حتی چندتاشون کنار هم استفاده بشن، ولی مکانیزم و هدفشون یکی نیست.
حالا سؤال من اینه:
چطور میشه مسئول معماری و مدیریت دیتابیس یک سازمان بزرگ باشی، ولی هنوز تفاوت این مفاهیم پایه رو ندونی؟ 🤦♂️
واقعاً از توی لپ‌لپ پیداتون می‌کنن؟ 😂
طرف مثلاً با UI یه Backup بگیره، چندتا Job بسازه، بعد بشه Database Manager؟!
مدیریت دیتابیس فقط این نیست که بدونی کدوم دکمه رو کجا بزنی.
DBA واقعی باید بدونه:
چرا این تکنولوژی رو انتخاب می‌کنه؟
چه Trade-offهایی داره؟
کجا باید ازش استفاده کنه؟
و مهم‌تر از همه، کجا نباید استفاده کنه؟
چون وقتی پای HA و DR وسطه،
دیگه بحث فقط SQL Server نیست...
بحث معماریه.
حالا شما بگید:
تا حالا با چه تصمیم معماری عجیبی توی SQL Server برخورد کردید که با خودتون گفتید:
«واقعاً کی اینو طراحی کرده؟! 😂»
دارم باهاش در مورد HA و Always On صحبت میکنم، طرف برگشته میگه:
«Always On رو چطوری راه‌اندازی می‌کنید؟ با Replica Log انجام ندین‌ها!»
😐😐😐
بعضیا هم میان میگن Always On رو با Log Shipping انجام بدین!
داداش... یه لحظه وایسا! 😂
Replication یه تکنولوژیه.
Log Shipping یه تکنولوژیه.
Always On Availability Group هم یه تکنولوژیه.
این‌ها سه تا چیز متفاوتن که هر کدوم برای یک سناریو و یک نیاز طراحی شدن.
اینکه همه‌شون یه جوری داده رو از یه جا به یه جای دیگه منتقل می‌کنن، دلیل نمیشه یکی باشن! 😂
اول اینکه Log Shipping نمیاد Always On رو راه‌اندازی کنه.
دوم اینکه Replication هم جایگزین Always On برای HA نیست.
ممکنه توی یک معماری حتی چندتاشون کنار هم استفاده بشن، ولی مکانیزم و هدفشون یکی نیست.
حالا سؤال من اینه:
چطور میشه مسئول معماری و مدیریت دیتابیس یک سازمان بزرگ باشی، ولی هنوز تفاوت این مفاهیم پایه رو ندونی؟ 🤦♂️
واقعاً از توی لپ‌لپ پیداتون می‌کنن؟ 😂
طرف مثلاً با UI یه Backup بگیره، چندتا Job بسازه، بعد بشه Database Manager؟!
مدیریت دیتابیس فقط این نیست که بدونی کدوم دکمه رو کجا بزنی.
DBA واقعی باید بدونه:
چرا این تکنولوژی رو انتخاب می‌کنه؟
چه Trade-offهایی داره؟
کجا باید ازش استفاده کنه؟
و مهم‌تر از همه، کجا نباید استفاده کنه؟
چون وقتی پای HA و DR وسطه،
دیگه بحث فقط SQL Server نیست...
بحث معماریه.
حالا شما بگید:
تا حالا با چه تصمیم معماری عجیبی توی SQL Server برخورد کردید که با خودتون گفتید:
«واقعاً کی اینو طراحی کرده؟! 😂»
❤18👌6🤷♂1🔥1😱1
سلام عزیزان
مورفین دیتابیس ، NOLOCK؛ ! 💊😈
مشتری زنگ می‌زنه:
«سیستم کنده! گیر می‌کنه!»
تیم فنی بررسی می‌کنه:
ای وای ، Blocking داریم، Deadlock داریم.
میتی‌کمان وارد میشه. 🦸♂️
میگه:
«جلوی همه جدول‌ها WITH (NOLOCK) بذارید.» 😎
و بعد Deploy...
🚀 سیستم سریع میشه
😍 مشتری راضی
😌 تیم فنی نفس راحت
چند روز بعد:
«بچه‌ها چرا گزارش‌ها با هم نمی‌خونه؟»
«موجودی‌هامون خرابه!»
«این عددها از کجا اومده؟!» 😐
و تیم فنی:
میره توی دیوار! 😂
چون NOLOCK یعنی:
من منتظر نمی‌مونم! هرچی هست بخون! حتی اگه هنوز وسط تغییر باشه! 🤦♂️
مثل بچه‌ای که میره سر ماهیتابه‌ای که مادرش برای مهمونی درست کرده و میگه:
«فقط یکی برمی‌دارم!» 😋
بعد مادر محترمه با کفگیر میاد:
«اینارو برای مهمونی درست کردم، نه برای تو!» 😂
پس قبل از اینکه برای درمان Blocking، NOLOCK رو روی همه‌چی بپاشیم، شاید بد نباشه بپرسیم:
اصلاً چرا Blocking داریم؟
چون:
سریع‌تر خواندن، لزوماً یعنی درست‌تر خواندن نیست. 🔥
شما هم پروژه‌ای داشتید که NOLOCK توش تبدیل شده باشه به چسب زخم دائمی؟ 😁
مورفین دیتابیس ، NOLOCK؛ ! 💊😈
مشتری زنگ می‌زنه:
«سیستم کنده! گیر می‌کنه!»
تیم فنی بررسی می‌کنه:
ای وای ، Blocking داریم، Deadlock داریم.
میتی‌کمان وارد میشه. 🦸♂️
میگه:
«جلوی همه جدول‌ها WITH (NOLOCK) بذارید.» 😎
و بعد Deploy...
🚀 سیستم سریع میشه
😍 مشتری راضی
😌 تیم فنی نفس راحت
چند روز بعد:
«بچه‌ها چرا گزارش‌ها با هم نمی‌خونه؟»
«موجودی‌هامون خرابه!»
«این عددها از کجا اومده؟!» 😐
و تیم فنی:
میره توی دیوار! 😂
چون NOLOCK یعنی:
من منتظر نمی‌مونم! هرچی هست بخون! حتی اگه هنوز وسط تغییر باشه! 🤦♂️
مثل بچه‌ای که میره سر ماهیتابه‌ای که مادرش برای مهمونی درست کرده و میگه:
«فقط یکی برمی‌دارم!» 😋
بعد مادر محترمه با کفگیر میاد:
«اینارو برای مهمونی درست کردم، نه برای تو!» 😂
پس قبل از اینکه برای درمان Blocking، NOLOCK رو روی همه‌چی بپاشیم، شاید بد نباشه بپرسیم:
اصلاً چرا Blocking داریم؟
چون:
سریع‌تر خواندن، لزوماً یعنی درست‌تر خواندن نیست. 🔥
شما هم پروژه‌ای داشتید که NOLOCK توش تبدیل شده باشه به چسب زخم دائمی؟ 😁
👍18❤5
وقتی CPU بی‌دلیل ۱۰۰٪ میشه، اول Waitها رو نگاه کن! 😐😂
چند روز پیش توی یکی از مراکز، یک کندی عجیب داشتیم.
طبق معمول اولین کاری که من همه‌جا میکنم اینه که Monitoring رو راه می‌اندازم.
ولی اینجا هرچی نگاه می‌کردیم، چیز خاصی پیدا نمی‌کردیم.
نه Query خاصی، نه Index عجیب‌غریبی، نه چیزی که بگیم «آهاااا! خودشه!» 😐
ولی همین که ساعت شلوغی می‌شد...
و CPU می‌رفت هوا و کل مجموعه می‌خوابید! 😂
شروع کردیم به کلنجار رفتن با Indexها، CPU، Queryها و...
ولی نتیجه؟ تقریباً هیچ!
یه لحظه با خودم گفتم:
«بذار اصلاً ببینم این بدبخت الان سر چی Wait کرده!» 🤔
من Waitها رو بررسی کردم و دیدم بالای لیست نشسته:
🔥
اینجا بود که قضیه جالب شد.
نسخه SQL Server هم 2025 بود.
(البته قبلاً نصب شده بود؛ خودم شخصاً با نصب آخرین نسخه‌ها در محیط عملیاتی خیلی موافق نیستم 😁)
یک بررسی کردم و مشخص شد در SQL Server 2025، برای SQL Authentication تغییراتی در مکانیزم رمزنگاری Credentialها ایجاد شده که در بعضی شرایط و مخصوصاً زمان Load بالا، میتونه فشار قابل‌توجهی روی CPU ایجاد کنه.
یعنی ما داشتیم دنبال Index و Query می‌گشتیم...
مجرم داشت رمزنگاری می‌کرد! 😂
با فعال کردن Trace Flag مربوطه، رفتار رو به مدل SQL Server 2022 برگردوندیم و بعد هم باید Passwordها Reset می‌شدن تا Credentialها با مدل جدید/مناسب ذخیره بشن.
نتیجه؟
اینکه CPU تا قبلش داشت برای خودش زندگی می‌کرد:
📈 ۹۰٪... ۹۵٪... ۱۰۰٪...
بعد از تغییرات:
زیر ۵٪! 😐😂
یعنی تمام اون کندی وحشتناک، نه از Index بود، نه از Query، نه از کمبود CPU...
بنده‌خدا داشت Password رمزنگاری می‌کرد! 😂
و اما درس این داستان:
سر جدتون فقط چون یک نسخه جدید اومده، سریع نبریدش Production! 😂
اول ببینید نسخه جدید چه تغییراتی کرده، چه Known Issueهایی داره، چه رفتارهایی عوض شده.
بذارید حداقل چند تا Cumulative Update و Patch ازش رد بشه، چند ماه توی دنیای واقعی خودش رو نشون بده، بعد برید سراغ Production.
اینکه شما اولین نفر باشید که SQL Server 2025 رو توی Production نصب کرده، لزوماً یعنی:
«چقدر خفنیم» نیست! 😁
گاهی یعنی:
«تبریک میگم، شما اولین نفری هستی که قراره این Bug رو پیدا کنی!» 😂😂
راستی شما هم تجربه‌ای از این مدل مشکل‌های عجیب بعد از Upgrade داشتید؟
#SQLServer #DBA #SQLServer2025 #PerformanceTuning #Monitoring #WaitStats #Database #Performance
چند روز پیش توی یکی از مراکز، یک کندی عجیب داشتیم.
طبق معمول اولین کاری که من همه‌جا میکنم اینه که Monitoring رو راه می‌اندازم.
ولی اینجا هرچی نگاه می‌کردیم، چیز خاصی پیدا نمی‌کردیم.
نه Query خاصی، نه Index عجیب‌غریبی، نه چیزی که بگیم «آهاااا! خودشه!» 😐
ولی همین که ساعت شلوغی می‌شد...
و CPU می‌رفت هوا و کل مجموعه می‌خوابید! 😂
شروع کردیم به کلنجار رفتن با Indexها، CPU، Queryها و...
ولی نتیجه؟ تقریباً هیچ!
یه لحظه با خودم گفتم:
«بذار اصلاً ببینم این بدبخت الان سر چی Wait کرده!» 🤔
من Waitها رو بررسی کردم و دیدم بالای لیست نشسته:
🔥
PREEMPTIVE_OS_CRYPTOPSاینجا بود که قضیه جالب شد.
نسخه SQL Server هم 2025 بود.
(البته قبلاً نصب شده بود؛ خودم شخصاً با نصب آخرین نسخه‌ها در محیط عملیاتی خیلی موافق نیستم 😁)
یک بررسی کردم و مشخص شد در SQL Server 2025، برای SQL Authentication تغییراتی در مکانیزم رمزنگاری Credentialها ایجاد شده که در بعضی شرایط و مخصوصاً زمان Load بالا، میتونه فشار قابل‌توجهی روی CPU ایجاد کنه.
یعنی ما داشتیم دنبال Index و Query می‌گشتیم...
مجرم داشت رمزنگاری می‌کرد! 😂
با فعال کردن Trace Flag مربوطه، رفتار رو به مدل SQL Server 2022 برگردوندیم و بعد هم باید Passwordها Reset می‌شدن تا Credentialها با مدل جدید/مناسب ذخیره بشن.
نتیجه؟
اینکه CPU تا قبلش داشت برای خودش زندگی می‌کرد:
📈 ۹۰٪... ۹۵٪... ۱۰۰٪...
بعد از تغییرات:
زیر ۵٪! 😐😂
یعنی تمام اون کندی وحشتناک، نه از Index بود، نه از Query، نه از کمبود CPU...
بنده‌خدا داشت Password رمزنگاری می‌کرد! 😂
و اما درس این داستان:
سر جدتون فقط چون یک نسخه جدید اومده، سریع نبریدش Production! 😂
اول ببینید نسخه جدید چه تغییراتی کرده، چه Known Issueهایی داره، چه رفتارهایی عوض شده.
بذارید حداقل چند تا Cumulative Update و Patch ازش رد بشه، چند ماه توی دنیای واقعی خودش رو نشون بده، بعد برید سراغ Production.
اینکه شما اولین نفر باشید که SQL Server 2025 رو توی Production نصب کرده، لزوماً یعنی:
«چقدر خفنیم» نیست! 😁
گاهی یعنی:
«تبریک میگم، شما اولین نفری هستی که قراره این Bug رو پیدا کنی!» 😂😂
راستی شما هم تجربه‌ای از این مدل مشکل‌های عجیب بعد از Upgrade داشتید؟
#SQLServer #DBA #SQLServer2025 #PerformanceTuning #Monitoring #WaitStats #Database #Performance
👍32❤2👏1
سلام عزیزانم
امیدوارم عالی باشین
پیشنهاد میکنم فیلم moneyball رو ببینید، و ببینید که تحلیل دیتا حتی توی ورزش و تیم چیدن و بازی کردن هم، میتونه چقدر تاثیر داشته باشه.
شاد باشین
حمیدرضا صادقیان
امیدوارم عالی باشین
پیشنهاد میکنم فیلم moneyball رو ببینید، و ببینید که تحلیل دیتا حتی توی ورزش و تیم چیدن و بازی کردن هم، میتونه چقدر تاثیر داشته باشه.
شاد باشین
حمیدرضا صادقیان
👍11❤3
Forwarded from Mindcraft
🧠 Mindcraft
Think Better. Lead Better.
یه جایی به بعد، آدم می‌فهمه مشکل خیلی از چیزهایی که در زندگی و کارش داره، کمبود دانش نیست...
نوع فکر کردنشه.
ما کلی کتاب می‌خونیم،
کلی دوره می‌بینیم،
کلی درباره مدیریت و رهبری و موفقیت حرف می‌زنیم...
اما وقتی پای یک تصمیم سخت،
یک آدم سخت،
یک تیم ناکارآمد
یا یک موقعیت پیچیده وسط میاد،
همون آدم قبلی هستیم. :)
اینجا برای من از همین سؤال شروع میشه:
چطور میشه بهتر فکر کرد؟
چطور خودمون رو بهتر مدیریت کنیم؟
چطور تیم بسازیم؟
چطور آدم‌ها رو بفهمیم؟
چطور تصمیم‌های بهتری بگیریم؟
چطور از «متخصص خوب بودن» به «رهبر خوب بودن» برسیم؟
و شاید مهم‌تر از همه...
چطور خودمون رو قبل از اینکه بخوایم دیگران رو رهبری کنیم، بسازیم؟
Mindcraft قراره جایی برای همین گفتگوها باشه.
نه قرار نیست اینجا نسخه موفقیت بپیچیم.
نه قرار نیست هر روز یک جمله انگیزشی بگیم که:
«اگر باور داشته باشی، می‌تونی دنیا رو فتح کنی!» 😂
قرارِ درباره چیزهایی حرف بزنیم که واقعاً در دنیای کار و زندگی باهاشون درگیریم؛
از توسعه فردی و رهبری
تا مدیریت، ساختن تیم، تصمیم‌گیری و طراحی سازمان.
گاهی هم احتمالاً چیزهایی می‌نویسم که خودم هنوز دارم باهاشون کلنجار می‌رم.
چون شاید رشد واقعی، بیشتر از اینکه جواب پیدا کردن باشه، سؤال‌های بهتری پرسیدنه.
Welcome to Mindcraft 🧠
Think Better. Lead Better.
خوش باشین
حمیدرضا صادقیان
Think Better. Lead Better.
یه جایی به بعد، آدم می‌فهمه مشکل خیلی از چیزهایی که در زندگی و کارش داره، کمبود دانش نیست...
نوع فکر کردنشه.
ما کلی کتاب می‌خونیم،
کلی دوره می‌بینیم،
کلی درباره مدیریت و رهبری و موفقیت حرف می‌زنیم...
اما وقتی پای یک تصمیم سخت،
یک آدم سخت،
یک تیم ناکارآمد
یا یک موقعیت پیچیده وسط میاد،
همون آدم قبلی هستیم. :)
اینجا برای من از همین سؤال شروع میشه:
چطور میشه بهتر فکر کرد؟
چطور خودمون رو بهتر مدیریت کنیم؟
چطور تیم بسازیم؟
چطور آدم‌ها رو بفهمیم؟
چطور تصمیم‌های بهتری بگیریم؟
چطور از «متخصص خوب بودن» به «رهبر خوب بودن» برسیم؟
و شاید مهم‌تر از همه...
چطور خودمون رو قبل از اینکه بخوایم دیگران رو رهبری کنیم، بسازیم؟
Mindcraft قراره جایی برای همین گفتگوها باشه.
نه قرار نیست اینجا نسخه موفقیت بپیچیم.
نه قرار نیست هر روز یک جمله انگیزشی بگیم که:
«اگر باور داشته باشی، می‌تونی دنیا رو فتح کنی!» 😂
قرارِ درباره چیزهایی حرف بزنیم که واقعاً در دنیای کار و زندگی باهاشون درگیریم؛
از توسعه فردی و رهبری
تا مدیریت، ساختن تیم، تصمیم‌گیری و طراحی سازمان.
گاهی هم احتمالاً چیزهایی می‌نویسم که خودم هنوز دارم باهاشون کلنجار می‌رم.
چون شاید رشد واقعی، بیشتر از اینکه جواب پیدا کردن باشه، سؤال‌های بهتری پرسیدنه.
Welcome to Mindcraft 🧠
Think Better. Lead Better.
خوش باشین
حمیدرضا صادقیان
❤13
Forwarded from Mindcraft
من با فرآیندهای بد مشکل دارم! 😂
هر جا وارد یک مجموعه می‌شم، حتی اگر قرار نباشه کارم Process Improvement باشه، ناخودآگاه شروع میکنم به کشف فرآیندها:
این کار چرا اینطوری انجام میشه؟
چند نفر درگیرشن؟
کجا دوباره‌کاری داریم؟
کجا منتظر آدم‌ها هستیم؟
و مهم‌تر از همه:
چرا برای کاری که میشه سیستم انجام بده، هنوز داریم از نیروی انسانی استفاده می‌کنیم؟! 😄
حتی در حوزه Database و Data هم فقط خود دیتابیس برام مهم نیست.
مدل Data Model، گزارش‌گیری، ارتباط با ذینفع، تعامل تیم فنی و حتی نحوه گزارش دادن به مدیران رو به چشم یک فرآیند می‌بینم.
چند روزه وارد یک کسب‌وکار جدید شدم و دارم فرآیندهاش رو کشف میکنم.
بخش زیادی هنوز دستی انجام میشه.
فعلاً دارم As-Is رو درمیارم تا ببینم کجا میشه:
زمان رو کم کرد،
هزینه رو کم کرد،
خطا رو کم کرد،
و رضایت آدم‌ها رو بیشتر کرد.
توی همین چند روز هم دو سه تا ایده با کارفرما مطرح کردم که خوشش اومد. 😎
برای من این دقیقاً جاییه که Service Design، Data و Business به هم می‌رسن.
گاهی یک فرآیند فقط نیاز به اصلاح داره...
گاهی هم باید کلاً از
«بذار فلانی انجامش بده»
برسه به
«سیستم خودش انجامش میده.» 🚀
شما وقتی وارد یک کسب‌وکار جدید می‌شید، اولین چیزی که سعی می‌کنید بفهمید چیه؟
— حمیدرضا صادقیان
در مسیر بهتر فکر کردن، بهتر ساختن.
@Minddcraft
هر جا وارد یک مجموعه می‌شم، حتی اگر قرار نباشه کارم Process Improvement باشه، ناخودآگاه شروع میکنم به کشف فرآیندها:
این کار چرا اینطوری انجام میشه؟
چند نفر درگیرشن؟
کجا دوباره‌کاری داریم؟
کجا منتظر آدم‌ها هستیم؟
و مهم‌تر از همه:
چرا برای کاری که میشه سیستم انجام بده، هنوز داریم از نیروی انسانی استفاده می‌کنیم؟! 😄
حتی در حوزه Database و Data هم فقط خود دیتابیس برام مهم نیست.
مدل Data Model، گزارش‌گیری، ارتباط با ذینفع، تعامل تیم فنی و حتی نحوه گزارش دادن به مدیران رو به چشم یک فرآیند می‌بینم.
چند روزه وارد یک کسب‌وکار جدید شدم و دارم فرآیندهاش رو کشف میکنم.
بخش زیادی هنوز دستی انجام میشه.
فعلاً دارم As-Is رو درمیارم تا ببینم کجا میشه:
زمان رو کم کرد،
هزینه رو کم کرد،
خطا رو کم کرد،
و رضایت آدم‌ها رو بیشتر کرد.
توی همین چند روز هم دو سه تا ایده با کارفرما مطرح کردم که خوشش اومد. 😎
برای من این دقیقاً جاییه که Service Design، Data و Business به هم می‌رسن.
گاهی یک فرآیند فقط نیاز به اصلاح داره...
گاهی هم باید کلاً از
«بذار فلانی انجامش بده»
برسه به
«سیستم خودش انجامش میده.» 🚀
شما وقتی وارد یک کسب‌وکار جدید می‌شید، اولین چیزی که سعی می‌کنید بفهمید چیه؟
— حمیدرضا صادقیان
در مسیر بهتر فکر کردن، بهتر ساختن.
@Minddcraft
👍6❤3🔥1
Forwarded from Mindcraft
بعضی‌ها با تغییر مشکل ندارن؛
با این مشکل دارن که تغییر، جایگاهشون رو تغییر بده!
تا حالا شده وارد یه مجموعه بشی و بخوای یه کاری رو درست کنی، ولی چند نفر عجیب جلوی کارت وایسن؟
نه مستقیم میگن «نکن»...
شروع می‌کنن به راهکار دادن! 😄
ترس از دست دادن شغل
ترس از اینکه یکی ازشون بالاتر بره
ترس از نورچشمی شدن یک نفر دیگه
ترس از افزایش حقوق اون
ترس از اینکه مدیر بفهمه خیلی از کارهایی که انجام می‌دادن، شاید اصلاً لازم نبوده!
من توی یکی از پروژه‌ها دقیقاً اینو دیدم.
هر بار یک راهکار عجیب می‌دادن.
منم بحث نمی‌کردم.
می‌ذاشتم اجرا بشه.
مشکل دوباره اتفاق می‌افتاد...
راهکار رد می‌شد...
تا بالاخره مسئله از ریشه حل شد.
و بعدش؟
سکوت! 😄
گاهی چیزی که ما اسمش رو می‌ذاریم «مقاومت در برابر تغییر»،
در واقع ترس از دست دادن جایگاهه.
شما با این مدل آدم‌ها چطور برخورد می‌کنید؟
من از این جنس تجربه‌ها و نگاه‌ها درباره آدم‌ها، تیم‌ها و سازمان‌ها اینجا می‌نویسم:
— حمیدرضا صادقیان
در مسیر بهتر فکر کردن، بهتر ساختن.
Telegram channel : @Minddcraft
با این مشکل دارن که تغییر، جایگاهشون رو تغییر بده!
تا حالا شده وارد یه مجموعه بشی و بخوای یه کاری رو درست کنی، ولی چند نفر عجیب جلوی کارت وایسن؟
نه مستقیم میگن «نکن»...
شروع می‌کنن به راهکار دادن! 😄
ترس از دست دادن شغل
ترس از اینکه یکی ازشون بالاتر بره
ترس از نورچشمی شدن یک نفر دیگه
ترس از افزایش حقوق اون
ترس از اینکه مدیر بفهمه خیلی از کارهایی که انجام می‌دادن، شاید اصلاً لازم نبوده!
من توی یکی از پروژه‌ها دقیقاً اینو دیدم.
هر بار یک راهکار عجیب می‌دادن.
منم بحث نمی‌کردم.
می‌ذاشتم اجرا بشه.
مشکل دوباره اتفاق می‌افتاد...
راهکار رد می‌شد...
تا بالاخره مسئله از ریشه حل شد.
و بعدش؟
سکوت! 😄
گاهی چیزی که ما اسمش رو می‌ذاریم «مقاومت در برابر تغییر»،
در واقع ترس از دست دادن جایگاهه.
شما با این مدل آدم‌ها چطور برخورد می‌کنید؟
من از این جنس تجربه‌ها و نگاه‌ها درباره آدم‌ها، تیم‌ها و سازمان‌ها اینجا می‌نویسم:
— حمیدرضا صادقیان
در مسیر بهتر فکر کردن، بهتر ساختن.
Telegram channel : @Minddcraft
❤6💯2🤝2👍1
Forwarded from Mindcraft
۳ دقیقه دیر اومدن = کتک‌کاری؟! 🤦🏻♂️
امروز اداره پست بودم.
۸:۰۳ یکی از کارمندها اومد.
رئیسش گفت: «این چه وضع اومدنه؟ من از ۷ سر کارم!»
کارمند گفت: «ساعت کاری ۸ شروع میشه، فقط ۳ دقیقه دیر کردم.»
بحث بالا گرفت،
بعد رسید به «لوازمتو جمع کن گورتو گم کن»
و نهایتاً هم کار به درگیری و کتک‌کاری کشید! 😐
با خودم گفتم:
خب داداش… فرض کن دیر اومده.
بشین باهاش حرف بزن.
مشکلت چیه؟
چرا دیر میای؟
چطور می‌تونیم کمک کنیم حلش کنیم؟
اگر هم حل نشد، محترمانه بگو:
«با این شرایط نمی‌تونیم ادامه بدیم.»
چرا برای حل یک مشکل ۳ دقیقه‌ای،
باید یک بحران درست کنیم؟!
به نظرتون مشکل اینجا «دیر اومدن» بود یا مدیریت بلد نبودن؟
امروز اداره پست بودم.
۸:۰۳ یکی از کارمندها اومد.
رئیسش گفت: «این چه وضع اومدنه؟ من از ۷ سر کارم!»
کارمند گفت: «ساعت کاری ۸ شروع میشه، فقط ۳ دقیقه دیر کردم.»
بحث بالا گرفت،
بعد رسید به «لوازمتو جمع کن گورتو گم کن»
و نهایتاً هم کار به درگیری و کتک‌کاری کشید! 😐
با خودم گفتم:
خب داداش… فرض کن دیر اومده.
بشین باهاش حرف بزن.
مشکلت چیه؟
چرا دیر میای؟
چطور می‌تونیم کمک کنیم حلش کنیم؟
اگر هم حل نشد، محترمانه بگو:
«با این شرایط نمی‌تونیم ادامه بدیم.»
چرا برای حل یک مشکل ۳ دقیقه‌ای،
باید یک بحران درست کنیم؟!
به نظرتون مشکل اینجا «دیر اومدن» بود یا مدیریت بلد نبودن؟
👍12❤1
Forwarded from Mindcraft
«ماشینم خورد به درخت!»
این جمله رو که می‌شنوم، همیشه با خودم میگم:
خب... ماشینت خودش رفت خورد؟! 😂
خیلی وقت‌ها حتی برای اتفاق‌هایی که خودمون باعثش بودیم، یک فاعل بی‌گناه پیدا می‌کنیم!
«دستکشم گم شد.»
«سیستم خراب شد.»
«بکاپ Failed شد.»
«این Job اجرا نشد.»
همه مقصرن...
جز من! 😐
مثلاً بکاپ‌ها یک ماهه Failed شدن و من چک نکردم.
یک Disaster اتفاق میفته و اطلاعات از بین میره.
حالا میگم:
«بکاپ‌ها مشکل داشتن!»
خب قبول...
ولی تو کجا بودی؟!
به نظرم یکی از مهم‌ترین چیزهایی که باید توی تیم‌ها بسازیم، همین Ownership هست.
اینکه آدم بتونه خیلی ساده بگه:
«اشتباه کردم.»
«یادم رفت.»
«من باید چک می‌کردم.»
نه اینکه برای هر اتفاقی یک مقصر بیرونی پیدا کنیم.
حالا یک سؤال جدی:
توی تیم شما مسئولیت‌پذیری واقعاً وجود داره، یا همه فقط دنبال مقصرن؟
و مهم‌تر:
خودمون چقدر اجازه می‌دیم آدم‌ها مسئولیت اشتباهاتشون رو بپذیرن؟
این جمله رو که می‌شنوم، همیشه با خودم میگم:
خب... ماشینت خودش رفت خورد؟! 😂
خیلی وقت‌ها حتی برای اتفاق‌هایی که خودمون باعثش بودیم، یک فاعل بی‌گناه پیدا می‌کنیم!
«دستکشم گم شد.»
«سیستم خراب شد.»
«بکاپ Failed شد.»
«این Job اجرا نشد.»
همه مقصرن...
جز من! 😐
مثلاً بکاپ‌ها یک ماهه Failed شدن و من چک نکردم.
یک Disaster اتفاق میفته و اطلاعات از بین میره.
حالا میگم:
«بکاپ‌ها مشکل داشتن!»
خب قبول...
ولی تو کجا بودی؟!
به نظرم یکی از مهم‌ترین چیزهایی که باید توی تیم‌ها بسازیم، همین Ownership هست.
اینکه آدم بتونه خیلی ساده بگه:
«اشتباه کردم.»
«یادم رفت.»
«من باید چک می‌کردم.»
نه اینکه برای هر اتفاقی یک مقصر بیرونی پیدا کنیم.
حالا یک سؤال جدی:
توی تیم شما مسئولیت‌پذیری واقعاً وجود داره، یا همه فقط دنبال مقصرن؟
و مهم‌تر:
خودمون چقدر اجازه می‌دیم آدم‌ها مسئولیت اشتباهاتشون رو بپذیرن؟
❤9👏3👍1