خلق از دلِ لحظه

خلق کردن برای من، مرز نمی‌شناسد. نه در بند صفر و یک می‌ماند و نه در فاز کوانتوم و نه در نت‌های موسیقی. این بداهه‌نوازی آماتور، مانند یک ایده‌ی نرم‌افزاری درخشان، از دلِ یک آن بی‌برنامه متولد شد؛ لحظه‌ای که فقط به ندای درونم گوش دادم و گذاشتم جاری شوم.

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

ببینید و بشنوید👇🏻
https://youtu.be/LurNrEjGhsY

🎥 چهارمین ویدئوی مجموعه‌ی شش بُعد معماری نرم‌افزار توی یوتیوب منتشر شد.

🌀 معماری نرم‌افزار خیلی بیشتر از کُد و نموداره.

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

متافور کلاسیک برای نرم‌افزار، جعبه‌ی سیاهـه: ورودی میره داخل، پردازش انجام میشه، و خروجی همون چیزی میشه که ما به‌عنوان رفتار سیستم تجربه می‌کنیم.

توی این ویدئو در مورد بُعد رفتاری مختصرا صحبت کردم. جایی که معماری واقعی، خودش رو نشون میده.
اینکه سیستم چطور تغییر می‌کنه، چه ریتمی داره، چطور با محیط درگیر میشه، و تصمیم‌های معماری چطور روی تجربه‌ی کاربر و کیفیت نهایی تاثیر میذارن.

اگه معماری رو فقط به ساختار و اجزا محدود کنیم، نصف داستان از دست میره.
ولی وقتی رفتار رو بفهمیم، تازه میشه سیستمی ساخت که نه فقط کار کنه، بلکه رشد کنه، سازگار بشه و پایدار بمونه.

📌 ویدئوی کامل رو ببینید:
https://www.youtube.com/watch?v=KBOk_f0f9ow

سلام به همگی
اولین روز پاییزتون بخیر و شادی باشه🍂🍁

نیم‌ساعت دیگه شروع می‌کنیم

🎥 سومین! ویدئوی مجموعه‌ی شش بُعد معماری نرم‌افزار توی یوتیوب منتشر شد

سلام به همگی، پاییزتون رنگی و قشنگ باشه بدور از خبرهای بد! 🍁🍂

معماری نرم‌افزار فقط رسم جعبه و خط نیست! 🤯

در قسمت سوم از مجموعه شش بُعد معماری نرم‌افزار، به بُعد حیاتی ساختاری (Structural Dimension) پرداختم.

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

در این ویدیو می‌تونیم ببینیم که:

🔹چرا معماری، فراتر از کد و نمودارها است.
🔹چطور انتخاب‌ها و تصمیمات ساختاری، بر تمام جوانب یک سیستم تأثیر می‌گذارند.
🔹چگونه با درک کامل بُعد ساختاری، می‌توان معماری‌هایی ساخت که نه تنها کارآمد باشند، بلکه توانایی رشد و سازگاری با آینده را نیز داشته باشند.

شش بعد معماری نرم‌افزار اضلاع مهم، حیاتی و مکملی هستند که من برای یک انتخاب معماری صحیح نرم‌افزار معرفی کردم. در هر ویدئو بصورت مختصر به هر کدام از این ابعاد پرداخته خواهد شد.

✅ برای تماشای ویدیو و درک عمیق‌تر این بُعد مهم، همین حالا کلیک کنید:
https://www.youtube.com/watch?v=faQUQ63kIDo

🔴 بدهی فنی: یک استعاره‌ی خسته! چرا باید به جای Technical Debt از System Debt بگیم؟

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

در ارائه‌ام در آخرین رویداد "نقطه" توضیح دادم که دیگه نمی‌تونیم از اصطلاح Technical Debt استفاده کنیم. این استعاره رنگ خودش رو باخته و نمی‌تونه واقعیت پیچیده‌ی سیستم‌های نرم‌افزاری رو توصیف کنه.
من همیشه از اصطلاح مناسب‌تری به اسم بدهی سیستمی (System Debt) استفاده کردم. به دلایل زیر من همیشه از این واژه استفاده می‌کنم:

🔹 مسئولیت مشترک
بدهی فقط مربوط به تیم توسعه نیست. همون‌طور که در مقاله‌ام نوشتم:

Calling it technical makes it sound like only developers are responsible. Debt often comes from business decisions, cultural habits, or organizational structures.

میتونیم بگیم بدهی سیستمی یک چتر بزرگ‌تره که همه‌ی بدهی‌های فنی، سازمانی و فرهنگی رو در بر می‌گیره.

🔹استراتژی در مقابل ریسک
مدیریت بدهی نباید یک اتفاق تصادفی باشه؛ باید یک تصمیم آگاهانه باشه.

"The key is intentionality. Conscious debt is strategy. Unconscious debt is risk."

بدهی سیستمی اصطلاح جامع‌تریه که همه‌ی این عوامل رو زیر یک چتر میاره. و مدیریت آگاهانه‌اش می‌تونه بزرگ‌ترین مزیت رقابتی شما باشه.

مقاله کامل رو از لینک زیر می‌تونید بخونید 👇🏻
https://masoudbahrami.com/article/technical-debt-more-than-code-more-than-a-metaphor/

🎥 ویدئو جدید: Technical Debt Is a LIE Introducing System Debt؟

اغلب وقتی از بدهی فنی (Technical Debt) صحبت می‌کنیم، همه‌چیز رو گردن کد و توسعه‌دهنده‌ها می‌ندازیم.
اما واقعیت اینه که ریشه‌ی مشکل معمولاً در جای دیگه‌ست، تصمیم‌های سازمانی، فرهنگ تیمی، و فشارهای بیزنسی.

توی این ویدئو، بر اساس مقاله‌ی من، توضیح می‌دم چرا باید به جای بدهی فنی از مفهوم بدهی سیستمی (System Debt) صحبت کنیم و چطور این مفهوم و این دیدگاه می‌تونه کمک کنه که پایه محکم و بهتری جهت بررسی بدهی‌های یک محصول برای مدیرها، PMها و تیم‌های فنی بوجود بیاد.

🔹 موضوعات کلیدی:

🔵 بدهی فنی فقط نوک کوهه یخه
🔵 بدهی سازمانی و فرهنگی، عامل اصلی فرسایش تیم‌هاست
🔵 چطور تصمیم‌های بیزنسی، توسعه‌ی نرم‌افزار رو بدهکار می‌کنن
🔵 گام‌هایی برای ساخت تیم‌هایی که بدهی رو آگاهانه مدیریت می‌کنن

📺 تماشا در یوتیوب:
👉 https://www.youtube.com/watch?v=TYQq5plYNyM

📖 متن کامل مقاله:
👉 https://masoudbahrami.com/article/technical-debt-more-than-code-more-than-a-metaphor/

رویداد دوم نقطه:
چطور تصمیم‌ها در تیم شما گرفته می‌شوند؟

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

📌 سؤالات برای بحث:

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

🗓 سه‌شنبه ۲۹ مهرماه ۱۴۰۴ | 🕖 ۱۹:۰۰ تا ۲۰:۳۰
💻 آنلاین

🔗 ثبت‌نام: https://luma.com/0zeu5bn1

سلام به همگی عزیزان و همراهان گرامی✋
ساعت 19:00 برنامه شروع میشه، بی‌صبرانه منتظر دیدن و شنیدن شما هستیم

رویداد سوم نقطه:
با موضوع: Clean Product

در فضای توسعه نرم‌افزار فارغ از نقش و عناوین افراد، این موضوع جا افتاده است که باید کد تمیز بنویسیم؛ خوانا، قابل نگهداری، زیبا.
اما خب متاسفانه کمتر کسی در مورد محصول تمیز صحبت کرده، یا حساس بوده 🤔

نرم‌افزار می‌تونه از نظر فنی بی‌نقص باشه، اما از درون پرایراد و کثیف، پر از هدف‌های مبهم، تصمیم‌های پراکنده و چراهای فراموش‌شده. اتفاقا تصور می‌کنم این سناریو را خیلی از ماها تجربه کرده باشیم!

مفهوم Clean Product یعنی بازگرداندن وضوح، هدف و یکپارچگی به چیزی که می‌سازیم، نه فقط به نحوه‌ی ساختنش.
اما تعریف Clean این‌جا ساده نیست؛ بدون context درست و مناسب Clean Product نمی‌تواند make sense کند

در این سخنرانی، مسعود بهرامی از زبان، تصمیم‌ها و نیت‌هایی می‌گوید که تمیزی واقعی یک محصول را شکل می‌دهند، و دوگانگی میان Clean Code و Clean Product به‌عنوان فرمول یک محصول موفق را معرفی می‌کند

این رو از من داشته باشید که:

محصول زمانی تمیز است که تصمیم‌هایش معنا داشته باشند، نه فقط کدهایش

🗓 سه‌شنبه ۲۹ مهرماه ۱۴۰۴
🕖 ساعت ۱۹:۰۰ تا ۲۰:۳۰
💻 آنلاین

🔗 ثبت‌نام: https://luma.com/qc2yhog5

سلام خدمت همه عزیزان و همراهان گرامی 👋

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

🔵 پلن‌ها:
🔹کوتاه – ۵ ساعت: بررسی سریع و راهنمایی فوری برای تیم‌های کوچک
🔹ماهانه – ۲۰ ساعت: بررسی کامل، Roadmap جامع، جلسات Mentoring و Code Review برای تیم‌های در حال رشد
🔹 پرمیوم – 42 ساعت: معماری کامل، Roadmap چند فصلی، mentoring، Code Review، CI/CD و DevOps guidance، پشتیبانی مستمر برای تیم‌های بزرگ

اگر نیاز شما متفاوته و یا چیزی خارج از این پلن‌ها نیاز دارید، با من تماس بگیرید تا یک برنامه کاملاً شخصی‌سازی‌شده برای تیم شما بسازیم.

🔗 جزئیات و جلسه هماهنگی رایگان رو از لینک زیر می‌تونید مشاهده کنید
https://masoudbahrami.com/fractional-cto-software-architecture/

🔵 لازم به ذکر هم هست که کماکان جلسات منتورشیپ person-to-person و رایگان من در Adplist هم برقرار است
https://adplist.org/mentors/masoud-bahrami

سلام به همگی عزیزان و همراهان گرامی خسته نباشید

کمتر از 1 ساعت دیگه شروع میشه این برنامه. منتظرتون هستیم😍

خیلی خوشحالم که مقاله و دیدگاه من درباره Technical Debt در آخرین مقاله موسسه جهانی و معتبر CIO.inc با عنوان “How to Fix Decades of Technical Debt” نقل‌قول شده و مورد استناد قرار گرفته است.

این نوشته من همینطور بر روی چندین موسسه و سایت شناخته‌شده جهانی زیر مجموعه Information Security Media Group (ISMG) منتشر و رفرنس داده شده: 🔹 BankInfoSecurity.com 🔹 InfoRiskToday.com 🔹 DataBreachToday.com

🔴 موسسه CIO.inc یکی از معتبرترین و معروف‌ترین موسسات دنیا برای مدیران ارشد IT و رهبران فناوری است و انتشار دیدگاه من در این سطح، فرصتی مناسب برای مطرح شدن گفتمان فنی و سازمانی در سطح جهانی است.

توی این مقاله به پیشینه استعاری بدهی فنی پرداخته‌ام و کاستی‌ها و سوءبرداشت‌های رایج درباره آن را بررسی کرده‌ام. نکته کلیدی که بر آن تأکید کردم این است که بدهی فنی صرفاً مشکلات کد نیست؛ بلکه در اصل یک میانبر زمانی است که بعداً باید با اختصاص زمان مناسب بازپرداخت شود.

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

فراموش نکنیم که زمان مهم‌ترین عامل در توسعه نرم‌افزار است و نحوه مدیریت آن تعیین‌کننده موفقیت یا شکست پروژه‌هاست. متأسفانه این جنبه حیاتی اغلب نادیده گرفته می‌شود و به فراموشی سپرده شده است.

همینطور پیشنهاد کردم به جای اصطلاح بدهی فنی، از عبارات بدهی سیستم System Debt یا بدهی کسب‌وکار Business Debt استفاده کنیم. چرا که وقتی فقط به کد محدود می‌کنیم، اینطور القا می‌شود که مسئولیت فقط بر دوش توسعه‌دهنده‌هاست، در حالی که واقعیت پیچیده‌تر است و شامل کل سیستم، فرآیندها و تصمیم‌گیری‌ها می‌شود.

🔵 همچنین توی مقاله چهار گروه بدهی را معرفی کردم:

🔹 بدهی از جنس Code-level : توابع نامرتب، نامگذاری ناسازگار و منطق تکراری
🔹 بدهی از جنس Architectural : ماژول‌های به شدت وابسته، تفکیک ناکافی مسئولیت‌ها
🔹 بدهی از جنس Process : نبود تست‌های خودکار، CI/CD کند یا مستندسازی ناقص
🔹 بدهی از جنس Business : نیازمندی‌های محصول نامشخص، تغییر دامنه، یا ویژگی‌های موقتی برای رضایت ذی‌نفعان

از این بابت خوشحالم که گفتمان من نه تنها در سطح فنی، بلکه در سطح سازمانی و دغدغه‌های مدیران میانی و ارشد نیز مطرح شده است.

خیلی خوشحال می‌شوم اگر بازخورد، نظر یا تجربه‌ای درباره این موضوع دارید با من در میان بگذارید.

🔗 مقاله CIO.inc: https://www.cio.inc/how-to-fix-decades-technical-debt-a-29899

🔗 مقاله کامل من: https://masoudbahrami.com/article/technical-debt-more-than-code-more-than-a-metaphor/

📘 10 + 1 Common Software Architecture Mistakes.pdf

این کتابچه مروری سریع بر ۱۰+۱ اشتباه متداول در معماری نرم‌افزار است که در تیم‌های ایرانی مشاهده کرده‌ام. البته که مواردی که در این فایل ذکر شده فقط مختص ایران یا صنعت خاصی نیستند؛ بسیاریشون کاملا جهان شمول هستند.

در این فایل می‌خوانید:
🔵 متداول‌ترین اشتباهات معماری که باعث کاهش سرعت و چابکی تیم‌ها می‌شود
🟡 علائم، اثرات و راه‌حل‌های عملی برای جلوگیری از این اشتباهات
⚪️ نکات کاربردی برای طراحی معماری نرم‌افزار پایدار و مقیاس‌پذیر

نسخه: 1.0.0

🔗 Download the PDF

✍️ نویسنده: Masoud Bahrami
🌐 MasoudBahrami.com

Introducing Exploratory Domain Discovery

Many modeling techniques help us describe what happens in a system; how events unfold, how people interact, how stories flow.

But few help us understand why things are the way they are, or how to reshape them strategically.

Exploratory Domain Discovery (EDD) is a collaborative modeling and design approach aimed at enabling strategic clarity in complex domains. It helps teams reach a shared understanding of their problem space by combining structured exploration with visual collaboration, turning scattered insights into a coherent, evolving model of the domain.

🔘 Watch the video:
https://youtu.be/pH2i1rAAEVQ

🔴 Try EDD:
https://exploratorydomaindiscovery.com/

اطلاع رسانی رویداد آنلاین Exploratory Domain Discovery - Live Demo

یکی از بزرگ‌ترین چالش‌ها در توسعه‌ی نرم‌افزار و طراحی محصول، ایجاد درک مشترک از دامنه‌ی مسئله میان اعضای تیم است. برنامه‌نویسان، مدیران محصول و تحلیل‌گران معمولاً از زاویه‌های متفاوتی به مسئله نگاه می‌کنند و این تفاوت دیدگاه می‌تواند تصمیم‌گیری و طراحی را پیچیده کند.

کارگاه EDD یک رویکرد مشارکتی و عملی است که به تیم‌ها این امکان را می‌دهد که:
✅ تصویری مشترک از دامنه‌ی مسئله ایجاد کنند،
✅ مفاهیم و مرزهای اصلی سیستم را شفاف‌سازی کنند،
✅ و تصمیم‌های طراحی را بر اساس فهم مشترک اتخاذ کنند.

📅 زمان: جمعه، ساعت 17:00 الی 18:30
🌐 محل: آنلاین – LinkedIn Live
💬 شرکت رایگان است!
در این جلسه، EDD را روی یک مثال واقعی به‌صورت زنده مرور خواهیم کرد و کاربرد آن در پروژه‌های واقعی را بررسی می‌کنیم.

🔗 لینک حضور در رویداد(لطفا دکمه attend رو بزنید). لطفا با بقیه هم به اشتراک بگذارید.
https://www.linkedin.com/events/7392826863901016064/

🔗جهت اطلاعات بیشتر در مورد EDD به لینک زیر مراجعه فرمائید
https://exploratorydomaindiscovery.com/

📣 Finally I managed to release my handbook:
How to Fail Test Automation Easily!
Lessons I’ve Learned (and Unlearned) from Failed Test Automation

This handbook dives deep into 60+ real-world mistakes in test automation that I’ve seen countless teams make, small, daily habits that silently destroy test reliability, slow down development, and erode confidence.

📙 Inside, you’ll find practical guidance and examples on:

1. Strategy & Mindset: How teams think about testing, not just how they do it. Avoid treating testing as a checkbox or a late-phase activity.
2. Test Design & Intent: Writing meaningful tests, avoiding overlapping coverage, and focusing on behavior, not implementation.
3. Technical & Execution Mistakes: Handling flaky, slow, or fragile tests, and creating resilient test setups.
4. Tools & Infrastructure: Choosing frameworks wisely, CI/CD pipelines, observability, and maintaining test suites.
5. Team & Collaboration: Breaking silos between QA, Dev, and Product, defining ownership, and improving knowledge sharing.
6. Cost & Value: Understanding ROI, avoiding uneconomical tests, and prioritizing what really matters.
7. Context & Local Challenges: Real-world constraints, common anti-patterns, and strategies to test effectively in complex domains.

💡 Beyond the lessons, the book also includes:
✅ Checklists for healthy testing habits and common bad smells
✅ A Test Strategy Template to guide your team’s approach
✅ Domain-Centric Test Naming examples to align tests with business intent
✅ A Metrics Cheat Sheet showing what to measure (and what to ignore)

With concrete JavaScript examples, realistic scenarios (like bookings, orders, and accounting), and actionable solutions, this book helps you build tests that actually protect both the software and the business.

Whether you are a developer, QA engineer, architect, or team lead, this book will help you recognize bad practices, understand why they happen, and adopt healthy testing habits that improve confidence, speed, and maintainability.

🙏 It’s completely free, if you find it useful, please share it with your team, colleagues, or anyone who’s passionate about better testing.

✍️ Author: Masoud Bahrami
🌐 MasoudBahrami.com
📘 Version: 1.0.0

Download for free:
https://leanpub.com/TestAutomationMistakes

سلام به همگی عزیزان عصر جمعتون بخیر باشه
لایو به زودی استارت میخوره. منتظرتون هستیم

📚 فهرست منابع و لینک‌های پیشنهادی که در طول لایو دمو به آنها اشاره شد

🔹 وب‌سایت رسمی EDD
🔗 https://exploratorydomaindiscovery.com
خانه‌ی EDD، شامل مقالات، مثال‌ها، ابزارها و نظریه‌های پایه.

🔹 معرفی رسمی Exploratory Domain Discovery
🔗 https://exploratorydomaindiscovery.com/b/introducing-exploratory-domain-discovery/
مقدمه‌ای رسمی بر EDD، هدف، ساختار و طرز فکر پشت آن.

🔹 اولین جریان اکتشاف (مثال دمو)
🔗 https://exploratorydomaindiscovery.com/b/the-first-flow-of-exploratory-domain-discovery/
یک نمونه‌ی عملی و گام‌به‌گام از اولین جریان اکتشاف.

🔹 معرفی Domain Circular Pattern (خیلی مهم) ❗️
🔗 https://exploratorydomaindiscovery.com/b/domain-circular-patterns/
توضیح مفهوم چرخه‌ی ارزش و تکرار الگوها در دامنه‌های پیچیده.

🔹 قلب EDD
🔗 https://exploratorydomaindiscovery.com/b/the-heart-of-exploratory-domain-discovery/
بررسی فلسفه‌ی پشت EDD و مفهوم Main Point.

🔹 بلوک‌های سازنده‌ی EDD
🔗 https://exploratorydomaindiscovery.com/b/building-blocks-of-edd/
شرح دقیق بلوک‌های اساسی مورد استفاده در جلسات اکتشاف.

🔹 چهار نقش از پنج نقش
🔗 https://exploratorydomaindiscovery.com/b/the-4-out-of-5-roles/
تشریح نقش‌ها و دینامیک بین افراد در ورکشاپ EDD

🔹 سخنرانی کنفرانس Naming is Caring با موضوع DDD Europe 2024
🔗 https://2024.dddeurope.com/program/naming-is-caring/
متدولوژی EDD اولین بار توسط مسعود بهرامی در DDD Europe 2024 معرفی شد. این رویکرد در ابتدا با عنوان Breadth-First Exploration ارائه شده بود و بعدها برای انعکاس بهتر هدف و گستره‌ی آن به Exploratory Domain Discovery تغییر نام پیدا کرد.

📺ویدئوی رویداد سوم نقطه با موضوع: موضوع: چطور تصمیم‌ها در تیم شما گرفته می‌شوند؟

در تیم‌های نرم‌افزاری، تصمیم‌ها فقط گرفته نمی‌شوند، ساخته می‌شوند، توسط آدم‌ها، نقش‌ها و فرهنگ تیم. توی این تیم‌ها تصمیم‌گیری فقط انتخاب بین چند گزینه نیست؛ بلکه ملغمه‌ای است از قدرت، ارتباط، فرهنگ و تعامل بین نقش‌های مختلف است.

در این گفت‌وگوی جمعی از سری برنامه‌های آنلاین نقطه درباره‌ی "فلو تصمیم‌گیری" در تیم‌ها صحبت شد.

ویدئوی این رویداد در کانال یوتیوب منتشر شده است. می‌توانید از طریق لینک زیر ویدئوی کامل رو مشاهده بفرمائید.(توضیح اینکه متاسفانه بخاطر مشکلی که پیش اومد، قسمت‌های ابتدایی برنامه ریکورد نشده)

https://www.youtube.com/watch?v=krbVAXXZsho