<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های نوید نیک پی</title>
        <link>https://virgool.io/feed/@Navidnikpey</link>
        <description>راهبر وال‌پی</description>
        <language>fa</language>
        <pubDate>2026-06-10 14:07:41</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/560/avatar/f7DavV.jpg?height=120&amp;width=120</url>
            <title>نوید نیک پی</title>
            <link>https://virgool.io/@Navidnikpey</link>
        </image>

                    <item>
                <title>به نمره NPS اعتماد نکنیم!!!</title>
                <link>https://virgool.io/@Navidnikpey/%D8%A8%D9%87-%D9%86%D9%85%D8%B1%D9%87-nps-%D8%A7%D8%B9%D8%AA%D9%85%D8%A7%D8%AF-%D9%86%DA%A9%D9%86%DB%8C%D9%85-ls34bzzqyamr</link>
                <description> NPS روشیه که خیلی از شرکت ها برای سنجش وفاداری مشتریانشون استفاده می کنن، ولی به نظر من این روش چندان قابل اعتماد نیست.یکی از مشکلاتی که با نمره NPS دارم اینه که این معیار بر اساس پیش بینی رفتار آینده مشتریانه، نه رفتار واقعی اونها. ما می دونیم که پیش بینی رفتار آینده می تونه دقیق نباشه و این می تونه باعث شهNPS تصویر دقیقی از وفاداری مشتریان به یه شرکت رو نشون نده. مثلاً، ممکنه یکی از دوستانتون به دلایل مختلفی یه شرکت رو به شما توصیه کنه، ولی حتماً این به معنی رضایت کامل اون فرد از محصولات یا خدمات اون شرکت نیست.یه مشکل دیگه هم اینه که روش محاسبه NPS می تونه گیج کننده باشه. این معیار امتیازات رو به سه دسته تقسیم می کنه: ترویج کنندگان، متقاعد شدگان و مخالفان. این تقسیم بندی می تونه باعث شه تغییرات کوچیک در امتیازات، تاثیر بزرگی در NPS داشته باشه، که این می تونه تصویر واقعی از وفاداری مشتریان رو منعکس نکنه.یه مشکل دیگه هم اینه که NPS می تونه خیلی راحت تغییر کنه. اگر یه شرکت به مشتریانش برای پر کردن سوال NPS تشویق و یا تخفیفی بده، از نظر من داده ها تحریف میشن و نتایج غیرقابل اعتماد هستند.حالا اگر سوالتون اینه که چرا با این همه مشکل، هنوز شرکت ها ازNPS استفاده می کنن، می تونم بگم که چون جمع آوری داده ها ساده است، تقلید از دیگران رایجه، نتایج سوال NPS جذاب به نظر می رسه و ... . این ها همه باعث می شن که شرکت ها هنوز هم از NPS استفاده کنن.اما در نهایت، باید به یاد داشت که اون قسمتی که واقعاً مهمه، پاسخ به سوال &quot;چرا؟&quot; هست که بعد از سوال NPS میاد. این پاسخ می تونه اطلاعات خیلی ارزشمندتری در مورد تجربیات و نظرات مشتریان بده. به جای اینکه فقط روی یه عدد ساده مثل NPS تمرکز کنیم، بهتره که سعی کنیم بیشتر درک کنیم که مشتریانمون چه تجربه ای داشتن.</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Tue, 11 Jul 2023 23:28:05 +0330</pubDate>
            </item>
                    <item>
                <title>رودمپ‌ با Rبزرگ؛ فریبی برنامه‌ریزی شده برای القاء توهم کنترل در فضای پیچیده</title>
                <link>https://virgool.io/@Navidnikpey/%D8%B1%D9%88%D8%AF%D9%85%D9%BE-%D8%A8%D8%A7-r%D8%A8%D8%B2%D8%B1%DA%AF-%D9%81%D8%B1%DB%8C%D8%A8%DB%8C-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D8%B1%DB%8C%D8%B2%DB%8C-%D8%B4%D8%AF%D9%87-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%D9%84%D9%82%D8%A7%D8%A1-%D8%AA%D9%88%D9%87%D9%85-%DA%A9%D9%86%D8%AA%D8%B1%D9%84-%D8%AF%D8%B1-%D9%81%D8%B6%D8%A7%DB%8C-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-dxpx01ggwkfy</link>
                <description>مدتی هست به این فکر می‌کنم که چرا در طراحی رودمپ نمی‌تونیم از Feature setها و زمان دلیوریشون بگذریم. نوشته زیر حاصل مطالعه و تحقیق من، پیرامون این سوال است. به نظر میاد نمایش زیرکانه‌ی رودمپ‌ به شرکت‌ها کمک می‌کند از این حقیقت تلخ که نمی‌توانیم بر روی فضای پیچیده کنترل مطلق داشته باشیم، فرار کنند.رودمپ‌های دارای Feature و زمان‌بندی به سه دلیل برای بسیاری از ما جذابیت دارند:فقط ایده‌های بیزنسی‌ای که در تصورات ما هستند، قابل اطمینان‌اندتحویل Featureها  به منزله تحویل Value‌هاست.بهبود هماهنگی میان بخش‌های مختلف با کمک رودمپ‌ها به بهترین شکل ممکن صورت می‌گیرد.دیدگاه اول: فقط ایده‌های بیزنسی‌ای که در تصورات ما هستند، قابل اطمینان‌اندایده‌های بیرنسی معمولاً بر پایه فرضیات بسیار و هزاران متغیر بنا شده‌اند. اگر با این دیدگاه اولویت‌بندی کنیم، اولویت‌بندی‌مان بر اساس ارزشی که قرار است به مشتری تحویل داده شود، نیست. اما ما عاشق تفکراتمان هستیم و دوست داریم افکارمان تا حد ممکن درست باشند.خیلی بهتر است که با انجام آزمایش‌های کوچک، دامنه تغییرات را کاهش داده و فرضیات‌ را به چالش بکشیم. و سپس با کمک این اطلاعات، ایده‌های معقولانه‌ای بسازیم که ریشه در واقعیت دارند. اما این کار باعث می‌شود پیش‌بینی زمان‌بندی‌ها و ویژگی‌هایی که می‌توانیم به آن عمل کنیم حتی از قبل هم سخت‌تر شود. چنین کاری به مذاق‌مان چندان خوش نمی‌آید.دیدگاه دوم: تحویل Featureها  به منزله تحویل Value‌هاست.این دیدگاه شایع‌ترین تصور از رودمپ Featureی است. همانطور که یک لطیفه نمی‌تواند به طور حتم باعث خنداندن مردم شود، تحویل Featureها هم لزوماً باعث بهبود زندگی مشتریان نخواهد شد.فرض کنید کمدین هستید و می‌دانید که باید در نه ماه آینده‌ برنامه‌ جدیدی را اجرا کنید. آیا تمام این نه ماه را به تفکر به لطیفه‌هایتان اختصاص خواهید داد و سپس برنامه را اجرا خواهید کرد؟ مسلماً نه!کمدین‌ها مدام امتحان و آزمایش می‌کنند تا ببینند لطیفه‌هایشان چه بازخوردی دارد. وقتی مردم به لطیفه‌ای نخندند یعنی آن لطیفه نیاز به تغییر دارد یا باید کلاً قیدش را بزنند. وقتی هم مردم بخندند یعنی لطیفه جذابیت دارد. کمدین‌ها با بازی با داستان‌ها و نحوه تعریف‌شان می‌توانند حتی خنده بلندتری را بر لب حضار بنشانند.اصل ماجرا این نیست که چه ساخته‌اید بلکه مهم بازخوردیست که دریافت می‌کنید.برای این کار باید به مشتری خود گوش بدهیم و با توجه به بازخوردی که گرفته‌ایم آن را تغییر دهیم. مدل « بساز و فراموش کن» در این معادله هیچ جایی ندارد و این دقیقاً همان مقصدیست که رودمپ‌های دارای Feature و زمان‌بندی معمولاً به آن منتهی می‌شوند.دیدگاه سوم: بهبود هماهنگی میان بخش‌های مختلف با کمک رودمپ‌ها به بهترین شکل ممکن صورت می‌گیرداکثر فرآیندهای رودمپ‌سازی پاسخی به مشکلات پیرامون مقیاس‌پذیری(scaling problems) است. در پروسه Scale، تیم‌هایمان در هماهنگی با یکدیگر مشکل دارند و فرآیند رودمپ‌سازی ما را مجبور به همکاری می‌کند. رودمپ ابزاریست که برای بهبود همکاری با یکدیگر می‌سازیم.برقراری تعادل میان دوراندیشی و چاره‌اندیشی بهترین راه برای انجام کارهای پیچیده است. یعنی از طریق برنامه‌ریزی، تحلیل و طراحی بر اساس دانسته‌های قبلی خود پیشروی کنیم و با انعطاف و سرعت عمل به یافته‌هایمان عکس‌العمل نشان دهیم.ولی اکثر مشکلات پیرامون هماهنگی و تعامل با رودمپ حل نمی‌شود. وقتی به ناتوانی‌ها و ندانسته‌هایتان پی ببرید، رودمپ‌های دارای Feature و زمان‌بندی به جز پیروی از برنامه هیچ خاصیت دیگری نخواهند داشت.نمی‌توانید بر اساس آنچه هنوز نمی‌دانید هماهنگی و گفتگو کنید.تنها راه چاره این است که وقتی از مشکل یا اطلاعات جدیدی باخبر می‌شوید بتوانید به سرعت از خود واکنش نشان دهید. اغلب تیم‌های اسکرام در طول مسیر آنقدر انعطاف‌پذیر نیستند که به بقیه هم کمک کنند.وقتی هر تیم رودمپی جداگانه داشته و مجبور به پاسخگویی باشد وضعیت حتی از این نیز بدتر می‌شود. اینگونه هر تیم راغب می‌شود سایر تیم‌ها را نادیده بگیرد تا بتواند به تعهدات خودش عمل کند. در عمل نیز دقیقاً همین اتفاق روی می‌دهد. خیلی بهتر است که تیم دیگری به جای تیم شما برای بدقولی مجازات شود، حتی اگر این کار به ضرر شرکت باشد.بیایید خودمان را با رودمپ‌های دارای Feature و زمان‌بندی گول نزنیممواردی هم وجود دارند که در آن‌ها داشتن Feature بر روی رودمپ کاری عقلانیست (مانند وقتی که می‌خواهید محصول‌مان را بازسازی کنیم یا قراردادهای قیمت مقطوع با زمان‌بندی و اهداف ثابت یا زمانی که در حوزه‌های غیرپیچیده کار می‌کنیم). اما اگر بخواهیم اکتشاف، یادگیری و آزمایش را در اولویت بگذاریم، رودمپ‌های دارای Feature و زمان‌بندی از همان ابتدای کار ما را در مسیر شکست قرار می‌دهند.هدف اصلی کار در حوزه‌های پیچیده این است که با دانسته‌هایتان کار کنیم تا به ندانسته‌هایمان پی ببریم. برای آن که در مسیر درست حرکت کنیم باید خودمان را تطبیق دهیم، اصلاح کنیم، جلا دهیم و منعطف باشیم.وقتی مشکل تنهایی تیم خودتان را حل کردید باید حتی از قبل هم انعطاف‌پذیری بیشتری داشته باشید. پیچیدگی کار با گسترش تیم‌ها به طرزی تصاعدی افزایش می‌یابد.واکنش پیش‌فرض تیم‌ها در قبال عدم قطعیت بازگشت به برنامه‌ریزی‌، تحلیل و طراحی بیشتر است.حتی با وجود اینکه می‌دانیم این رویکرد در تیم‌های تکی با شکست مواجه می‌شود، به نحوی خودمان را گول می‌زنیم که شاید این کار در چند تیم موفقیت‌آمیز باشد.تحلیل بیش از حد بر اساس دانش ناکافی در مقایسه با واکنش جمعی و سریع تمام تیم‌ها بر اساس دانسته‌ها و آموخته‌ها رویکردی ناکارآمد است.حالا چه باید کرد؟مطمئن شویم تیم‌های جداگانه که بر روی یک محصول کار می‌کنند همگی از یک رودمپ کلی وابسته به هدف (رودمپ با rکوچیک) که اولویت‌ها را مشخص می‌کند، پیروی نمایند. بسیاری از شرکت‌ها برای هر تیم یک رودمپ جداگانه دارند. این کار عملاً به این معناست که هیچ کنترلی بر اولویت‌ها ندارند. تیم‌ها با یکدیگر جدل خواهند داشت و بر سر قلمروشان با یکدیگر نزاع خواهند کرد که این کارشان معمولاً به ضرر شرکت و با بی‌اعتنایی به کلیت ماجرا همراه می‌شود.بیانیه روش توسعه نرم‌افزار چابک لب کلام را به زیبایی تمام بیان می‌کند:«واکنش به تغییرات به جای پیروی از برنامه»در حوزه‌های پیچیده تنها تا زمانی می‌توانیم به برنامه‌هایمان (و رودمپ‌ها) اعتماد داشته باشیم که بیانگر واقعیت باشند. یعنی هرگز نمی‌توانیم بی چون و چرا به آن‌ها اعتماد کنیم. بلاخره زمانی می‌رسد که نمی‌توانیم مانع شویم و تفکر اولیه‌مان از واقعیت فاصله می‌گیرد. هر قدر هم صحبت کنیم، طراحی کنیم، تحلیل کنیم یا هماهنگ باشیم، هرگز به صورت تمام و کمال در کنترل نخواهیم بود.</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Sun, 24 Jul 2022 12:55:47 +0430</pubDate>
            </item>
                    <item>
                <title>مدیر محصول خوب...</title>
                <link>https://virgool.io/theproductmanager/%D9%85%D8%AF%DB%8C%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D8%AE%D9%88%D8%A8-il69l9al2ags</link>
                <description>مدیر محصول خوب ؛شیدای مشتری بودن، ماموریت اصلیشه، همیشه یادشه باید درخواست‌ها رو طوری اولویت‌بندی کنه که در نهایت، ارزش به مشتری دلیور بشه. رضایت‌مندی مشتریا براش همیشه در اولویته.خوب می‌دونه ارزش (Value) بعد از یادگیری بدست میاد. همیشه به فکر بهبود مستمره و اون رو یادآوری می‌کنه.به دنبال سوال درسته و قبل از هر حرکتی، مطمن میشه مشکل برای همه‌ی اعضای تیم شفاف شده، و این کارو با طرح سوال‌های درست انجام میده.غیر از محصولی که داره روش کار می‌کنه، به همه یاد‌آوری می‌کنه که باید به فکر ارزشی باشیم که قراره سازمان به مشتریانش ارايه بده و همیشه به کل زنجیره‌ی ارزش فکر می‌کنههم ولع یادگیری داره و هم شوق یاد دادنابتدا به ارزشی که قراره در نهایت خلق بشه فکر می‌کنه وبعد به هزینه‌شمهارت دیزاین و تجربه کاربری رو تا حد خوبی داره، می‌تونه با اسکچ منظور خودشو منتقل کنهخوب می‌دونه که جنگیدن برای بهترشدن محصوله و نه جنگیدن برای خودشداده‌ها سنگ صبورشن، سعی می‌کنه از داده‌ها بستر مناسبی بسازه که در نهایت با در نظر گرفتن اونا، چیزی که ندای درونش رو میگه می‌سازه و به تصمیمش ایمان دارهبعضی وقتا Pause می‌کنه و از بالا مسايل رو نگاه می کنهسعی می‌کنه رودمپ برای همه ذینفعان شفاف باشه تا با این شفافیت، هم‌راستایی خوبی بین ذینفعان ایجاد کنهاز رودمپ‌ محافظت می‌کنه، ولی اگر در مسیر، بفهمه که انگار نقشه‌ی بهتری وجود داره، هیچ ترسی از تغییرش نداره و با شجاعت از تغییر مسیر محصول صحبت می‌کنهبه مفاهیم مارکتینگ مسلطه و همیشه مواظب مشتریای بالقوه و بالفعلش هستدر فکر هم‌افزاییه درون تیمیه و برون تیمیهاطمینان حاصل می‌کنه که آیا مسیرمحصول در مسیر اهداف و استراتژی‌های کلان سازمان هست یا نهاول به ROI فکر می‌کنه، واسه همینم وقتی درخواستی برای توسعه سمتش میاد، به نسبت ارزش و      هزینه‌ش فکر می‌کنهنهایتا تا یک ماه‌ آینده بک‌لاگ چیده و همیشه تو فکر کوتاه‌کردن لوپ فیدبکه. اون همیشه برای چینش PBIها دلیل دارهقربانی نمی‌شه، با شنیدن از آدم‌های مختلف، مشکلات رو شفاف می‌کنه و راه‌حل‌های احتمالی رو تست می‌کنهصبر داره؛ چون می‌دونه اول باید مثلث و دایره رو یاد بگیره و بعد یه سبک نقاشی جدید ابداع کنه، تا مهرو امضای خودش رو داشته باشهیه مذاکره کننده‌ی عالیهسلامت روحی و روانی تیم به اندازه خروجی و شاید بیشتر براش مهمهجوری فکر می‌کنه که اگر توپ ازش رد شد، کسی نیست که از دروازه دفاع کنهبه چرخه توسعه‌ی محصول چنان واقفه که براش پریدن از روی MVP خلاف شرعه!ترندهای روز محصولات رو می‌شناسه، محصولات موفق رو دنبال می‌کنه.رقبا رو خوب می‌شناسه؛از نیاز‌ها و دردهای یوزرهای بالقوه و بالفعلش آگاهه و با ارتباط نزدیک و مستمر باهاشون همیشه ازشون خبر دارهعملکردش به شکلیه که کسی ازش گزارش نخوادهمیشه ایده جدید داره و نگهداری وضعیت فعلی محصول رو در خور رسالتش نمیدونههمیشه سهم بازارشو رصد می‌کنهمی‌تونه محصول رو، دردو سال آینده و در راستای ویژن سازمان تجسم کنهشفافهریسک می‌کنهبه ریویوی آخر اسپرینت احترام میذارهانسان خوبیه؛ نه به خودش دروغ میگه، نه به بقیهو در آخر…یه مدیر محصول خوب؛ می‌دونه همه این کارها کار تیم توسعه‌س…یه مدیر محصول خوب؛ مدیر محصوله ولی مدیریت نمی‌کنه…یه مدیر محصول خوب؛ ماموریت اصلیش خلق یک بستره، یه بستر که تیم توسعه توش بتونه خلاقیت خودش رو نشون بده…یه مدیر محصول خوب؛ میدونه یه مدیر محصول عالی بدون تیم هیچ معنی‌ای نداره…</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Sat, 19 Dec 2020 09:11:19 +0330</pubDate>
            </item>
                    <item>
                <title>مسی یا تیم مسی؟</title>
                <link>https://virgool.io/@Navidnikpey/%D9%85%D8%B3%DB%8C-%DB%8C%D8%A7-%D8%AA%DB%8C%D9%85-%D9%85%D8%B3%DB%8C-xizflgnnckua</link>
                <description>مدتهاست در جاهای مختلف چالش مشترکی رو تجربه کردم که بد ندیدم اینجا مطرح کنم...اونم اینه که سازمان‌ها و شاید بهتر بگم مدیران، همیشه به دنبال سوپراستارهایی هستند تا کارهارو به بهترین شکل ممکن انجام بدن. یا چالش‌ها رو حل کنند. دقت کنید، کارهارو! چالش‌هارو!البته که ما هممون از همچین فرهنگی میایم. این رو نباید نادیده گرفت. کانتکس موجود (البته این مختص به ایران نیست) این ذهنیت‌ها رو در ما شکل میده. یعنی اساسا ما دنیارو اینطور می‌بینیم که یکی باشه بره جمع کنه!!! و وای به حالمون وقتی این اون «یکی» ما مربیان چابکی باشیم!!!!!!! پس اگر بخوام کامل‌ترش کنم این فرهنگ ماست که دنبال سوپراستاری است که بتواند چالش‌های را حل کند. هر چقدر سعی می‌کنم ربطش ندم به تیلور و مدیریت علمی نمیشه واقعا. نه اینکه هدف‌دار این اتفاق بیفته، نه، مدیریت علمی سالها در ایران بوده، تدریش شده و وارد تاروپود ما شده. ما پرورده همون سیستم مدیریتی هستیم. و واقعیتش اینه که تیلور و مریدانش معتقدن بودن کار تیمی باعث کاهش کارایی همه اعضا میشه و نیازی به اعتماد به تیم نیست. بلکه سوپراستارهایی باید باشند تا کارها رو جمع کنند. پروژه‌ها رو در بهینه‌ترین میزان هزینه جمع کنند. دلیلش هم اینه که به نظر میاد انسان‌ها ذاتا از کارکردن بدشون میاد. ولی استثناهایی وجود دارن که اینطور نیستند و میشن سوپراستار. از لحاظ تیمی میشه این چالش رو در فوتبال به خوبی دید. بر کسی پوشیده نیست مسی به عنوان یک سوپراستار در دو تیم مختلف، عملکردهای متفاوتی داشته، در تیم ملی آرژانتین میشه بهش عملکرد افتضاحی رو نسبت داد.ولی همین مسی در تیم بارسلونا تونست هم در راستای هدف‌های تیمی و هم عملکرد فردیش سالها پادشاهی کنه. واقعا سوال اینجاست که چه فرقی وجود داره بین این دو؟این طوری که من می‌بینم، بستر و فرهنگی که در تیم بارسلونا وجود داره اینه که از هر پتانسیل و توانایی‌ای در راستای اهداف تیم بهره می‌بره و این به معنی دیده‌نشدن سوپراستار‌ها نیست. بستر، بستر همکاری و هماهنگیه.بستر در راستای Common Cause مهیا میشه. حالا برگردم به دنیای خودمون، در یک تیم توسعه محصول، اگر اون تیم در راستای اهداف ( کوتاه یا بلند ) موفق شه، آیا عملکرد‌های فردی دیده نمیشن؟به نظرم تشویق هم هست و چیزی که من دیدم اینه که در نهایت مدیران می‌خوان یکی رو تشویق کنن و اون رو به عنوان برگ برنده تیم اعلام کنند.  من منکر وجود و نیاز به سوپراستار در تیم‌ نیستم ولی معتقدم پس از حضورش باید طوری تیم رو هدایت کرد که همه در راستای هدفی فراتر از اعضا تلاش کنند. تعهدها فراتر از افراد باشه و کار تیمی به عنوان ارزش اول تیم برجسته بشه. در این صورت نه تنها اون سوپر استار بلکه حتی افراد با مهارت‌های پایین‌تر می‌تونن توانایی‌های بی‌نظیری رو نشون بدن و ما همیشه تیمی داریم که میشه تمام و کمال بهش اعتماد کرد...</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Tue, 20 Oct 2020 10:27:56 +0330</pubDate>
            </item>
                    <item>
                <title>کمپین ترکِ پرسیدن سوال «چرا» !!!!!</title>
                <link>https://virgool.io/@Navidnikpey/%DA%A9%D9%85%D9%BE%DB%8C%D9%86-%D8%AA%D8%B1%DA%A9%D9%90-%D9%BE%D8%B1%D8%B3%DB%8C%D8%AF%D9%86-%D8%B3%D9%88%D8%A7%D9%84-%DA%86%D8%B1%D8%A7-bxn39wilglea</link>
                <description>مدتیه در تعامل با تیم‌ها، وقتی قصد شفاف‌کردن مشکل اصلی رو برای همه داشتیم، سوالاتی که می‌پرسیدم رو می‌نوشتم و وقتی اونها رو مرور ‌کردم، به مواردی روبرو می‌شدم که جنسشون «چرایی» بود ولی واقعا نتیجه دلخواه رو نداده بود و عملا مخاطب (یا مخاطبان ) رو یا در بن‌بستی متوقف کرده بود و یا در یافتن ریشه اصلی مشکل مشاهده‌شده کمکی نکرده بود. هر چند نمی‌شد کانتکس رو نادیده گرفت ولی به اشتراکی بین همه‌شون رسیده بودم و می‌دونستم سوالاتی که می‌پرسم احتمالا نیاز به بازنگری دارند.چند روز پیش، به صورت کاملا اتفاقی نوشته‌ای در لینکدین دیدم با عنوان «پرسیدن سؤال چرا را متوقف کنید» وقتی مطلب رو خوندم متوجه شدم خیلی به نیاز من ربط داره، شاید ابزار خاصی بهم نمی‌ده ولی معضل این مدل سوالات رو مرور می‌کنه.برداشت آزاد خودم رو به فارسی نوشتم و با شما به اشتراک می‌گذارم تا اگر در پرسیدن سوال هنگام مواجه با مشکلات درون تیمی (فارغ از اینکه در تیم چه نقش دارید) به نتیجه دلخواه (ریشه اصلی مشکل )نمی‌رسید، خوندن این نوشته تلنگری در مسیر پرسیدن سوال‌هامون باشه. نوشته با یک مثال شروع میشه، مربی‌ای در هنگام مشاهده کدی قدیمی که تست نداشته از اعضای تیم می‌پرسه &quot;چرا برای این کد،هیچ تستی وجود نداره؟&quot; یکی ار اعضای تیم به سرعت جواب میده &quot;چون فردی که کد رو طراحی کرده، هیچگونه اطلاعات راجع به تست ثبت نکرده&quot; دقت کنید این سوال نه تنها مشکلی را حل نکرد بلکه حجم تنش رو هم بیشتر گرد و هیچ نگرش جدیدی به اعضای درگیر مشکل نداد.مشکل دیگه این مدل سوالات «چرا»  اینه که چون افراد تحت فشار قرار می‌گیرند، به کشف حقیقت‌های بیشتر علاقه نشون نمی‌دن و طبیعتا گفتگو به سمت راه‌حل پیش نخواهد رفت. برای همینه بعضی وقت‌ها می‌شنویم که بعد از چند سوال بهمون می‌گن حس‌ می‌کنن در حال تلف‌کردن وقت هستیم و یا سوال می‌پرسن نمیشه مدت این مکالمات (جلسات) کوتاه‌تر بشه؟؟!! انسان تحت فشار، بحث طولانی و پیچیده دوست ندارد ...حالا واقعا این سؤالات «چرا» چه مشکلی دارند؟فهرستی از سوالات « چرا»ی مشکل دار ? ستون مشکل خیلی برای من جذاب بود ?ما همیشه دلایل قانع کننده‌ای برای استفاده از این سؤالات «چرا» داریم، ولی این نکته را در ذهن داشته باشیم که :در صورتی که خواهان اکتشاف و ایجاد بینش هستید، طبیعتاً این‌ها سوالاتی نیستند که نسبت به پرسیدنشان اقدام کنیم.چرا این سؤالات کمکی نمی‌کنند؟فکر کنم تا این جای نوشته هممون به این نتیجه رسیدیم که اگر آگاهانه سوال نپرسیم و به دلیل اینکه می‌خوایم همه «چرایی» کارهاشون رو بدونن، مدام از این جنس سوالات استفاده کنیم، سؤالاتِ «چرا» به ابزارهایی به شدت قوی‌ برای ایجاد ناخرسندی در افراد ، و بی میلی بیشتر به عدم پیگیری آزادانه بحث تبدیل میشن.ترتیب اثرگذاری این سؤالات به صورت نزولی (از بالا به پایین) این شکلی میشه :۱. شما۲. جملات دستوری (باید، می‌توانید، باید و غیره)۳. جملات منفی (نباید، نمی‌توانید)۴. جملات با زمان گذشته (انجام شد)۵. کلمات قضاوتی (حتی، بد)۶. قیدهای زمانی (هنوز، اکنون)یه مثال با اثر منفی مضاعف بخونید : چرا هنوز این موضوع رو درک نکردید که سؤالات شما منشأ بروز مشکل هستند؟خودتون رو در جای مخاطب من فرض کنید و بگید چنین سوالی تا چه حدی خرسندی و رضایت شما برای شروع گفتگو با من رو جلب می‌کنه؟ ? نگارنده توصیه می‌کنه این فهرست ۶تایی رو به ذهن بسپارید، و یک هفته پرسش‌هاتون رو مانیتور کنید،پیش‌بینیم اینه متوجه می‌شید که سؤالات چرا یکی از اصلی‌ترین دلایلی هستند که مانع مشارکت بیشتر افراد در بحث‌ها می‌شن ، و در عین حال هیچ‌گونه بینش ارزشمندی رو هم تولید نمی‌کنند.از همه بدتر. سوالات تک‌کلمه‌ای....فرض کنید در میانه یک گفتگو هستید. سینا (یکی از اعضای تیم) می‌گه که ما در این اسپرینت به اندازه کافی به تست اهمیت ندادیم. شما فقط با یک سؤال تک عبارتی : چرا ؟ وارد بحث می‌شید. علیرغم اینکه شما هرگز جمله رو کامل نکردید، اما  سینا رو متهم به عدم اهمیت کافی به تست کردید. ذهن سینا بدون اینکه درگیر کشف مشکل و یا یادگیری‌‌ای بشه، به صورت خودکار سؤال تک کلمه‌ای شما را تکمیل می‌کنه : سینا چرا به اندازه کافی به تست اهمیت ندادید؟ ☹ دقت کردید؟ ذهن سینا هر طور دلش بخواد سوال تک‌کلمه‌ای شمارو کامل می‌کنه. بر اساس الگوریتم‌های ذهنی خودش.حالا با این وضعیت چکار میشه کرد؟ بجای چرا ، چه سوالی رو بپرسیم؟نمیدونم چقدر می‌تونه کمک کنه ولی می‌خوام سعی کنم برای یک مدتی اینطور عمل کنم:به جای حفظ کردن یک سری عبارت، هیچ‌گاه سوالی نپرسم که بعدش مخاطبانم وارد فضای راه‌حل بشن. بلکه افراد رو علاقه مند به مشارکت در گفتگو کنم و واقعا به این نتیجه رسیدم باید به صورت کلی از واژه « چرا » صرف نظر کنم.اینطور فهمیدم که تقریباً تمامی سؤالات چرا رو با سؤالات چه و چگونه میشه جایگزین کرد. جالبه همه هدف یکسانی رو برآورده می‌کنند ، بدون اینکه به سمت جهت خاصی جبهه گیری کنند.یه مثال :سؤال : &quot;چرا این مشکلات را در طول تست شناسایی نکردیم؟&quot; معادل اینه که روند تست ما ناکارآمد و معیوبه. ولی سؤال &quot;چگونه این نواقص وارد محصول شدند؟&quot;، معادل با اینه که تیم از علل ریشه‌ای بی اطلاعه و مجبور به شناسایی دلایلش میشه.من نتیجه کلی‌ای گرفتم از خوندن این نوشته و اونم اینه که هممون خوبه آگاه بشیم کِی داریم از سوالات « چرا » استفاده می‌کنیم. هر وقت بعد از سوالمون فضای راه‌حل برای مخاطب باز شد، گفتگو متوقف شد و یا توجیه شنیدید، به نظرم باید تجدیدنظر کنیم.اینطور نباشه که با پرسیدن سوال، انگاری در Google داریم سرچ می‌کنیم.  شاید بشه سوال جدیدی با «چگونه» و «چه» ساخت. مدام باید روش‌های جایگزین رو تست کنیم و نتیجه رو مشاهده کنیم و به خودمون فیدبک بدیم.به قول سهیل صمدزاده همیشه &quot;در کوره بمونیم &quot; و در نهایت یادم نره به اون چیزی که اتفاق افتاده تکیه کنم و از فرضیات فرار کنم.یادمون باشه ممکنه با یکی از سوالات از نظر خودمون ساده، یک انسان رو سرزنش و یا سرخورده کنیم...آگاه بمانیم در سوال پرسیدن....</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Sun, 09 Aug 2020 12:02:12 +0430</pubDate>
            </item>
                    <item>
                <title>RACI یا رئیسی؟</title>
                <link>https://virgool.io/IranAgile/raci-%DB%8C%D8%A7-%D8%B1%D8%A6%DB%8C%D8%B3%DB%8C-spw7gnelbu5v</link>
                <description>تاریخ مشخص و دقیقی برای انتشار ماتریکس تعیین مسئولیت RACI وجود ندارد ولی در اکثر منابع عنوان شده که این ابزار، به عنوان یکی از ابزارهای (GDPM (Goal Directed Project Management در اوایل سال 1970 میلادی طراحی و در سال ۱۹۸۴ منتشر شده است.هر چند شواهدی از انتشار آن در سال 1956 و در Journal of Personnel Management نیز وجود دارد.به نظر می‌رسد زمانی که مدیران کارخانه‌های صنعتی برای اولویت‌بندی کارهایشان، استفاده از ماتریس‌هایی با عناوین فرصت-تهدید ، SWOT، آیزنهاور و ... را شروع کردند، به خانه‌ای به نام &quot;فوری‌های کم اهمیت&quot; رسیدند، که مشاوران به delegate‌کردن آن کارها توصیه می‌کردند. ماتریس آیزنهاور اکثر مدیران در این وضعیت از خود می‌پرسند به چه کسی می‌توانم این کار را بسپارم؟ به چه کسی تفویض کنم؟ از سوی دیگر به دلایل متعددی مثل بی‌اعتمادی، سپردن کار به افراد دیگر خیلی آسان هم نبود. پس صریح‌ترین و سریع‌ترین راهکار، ساختن یک سیستم Command-and-Control بود. که به وسیله ابزار RACI به خوبی قابل پیاده‌سازی بود.ویکی‌پدیا RACI را اینطور معرفی می‌کند:ابزاری برای توصیف مشارکت نقش‌های مختلف در تکمیل Task ها و تحویل پروژه که در شفاف‌سازی و تعیین نقش‌ها و مسولیت‌های پروژه‌ها و فرآیندهای دپارتمانی کاربرد دارد.اما به نظر می‌رسد نیاز به داشتن چنین ابزاری زمانی پدید می‌آید که مدیران شرکت و یا استارتاپ به دلیل نبود شفافیت از یک سو و از سوی دیگر تعیین اهداف و Deadlineهایی حیاتی در توسعه محصول، سعی در ساده‌کردن احوالات افراد دارند. تاکید می‌کنم این ابزار برای مدیران رده‌بالا جذاب بوده و دلایل عمده محبوبیت آن امکان بررسی عملکرد انفرادی و ساده فهم بودن آن است.بر اساس این ماتریکس، نقش، توصیف کننده‌ی مجموعه‌ای از Taskهای مرتبط برای یک نفر است. پس در قبال هر پروژه و حتی Taskی مدیر و یا جمعی از مدیران تعیین خواهند کرد که هر کسی چه نقش داشته باشد. این نقش‌ها به چهار دسته تقسیم می‌شود:R : Responsibleکسی یا کسانی که تعدادی کار را تا اتمام آن انجام می‌دهند و به همه اطمینان می‌دهند همه چیز به درستی پیش می‌رود.مثال: زمانی که قصد راه‌اندازی یه کمپین مارکتینگ داریم، مدیر مارکتینگ Responsible آن کمپین است.A: Accountableکسی که در نهایت پاسخگوی ارایه درست و صحیح کار و یا پروژه است. این افراد حق وتو دارند و موانع روی مسیر را حذف می‌کنند. این افراد در طول پروژه نسبت به سرعت پروژه فیدبک می‌دهند.مثال: زمانی که قصد راه‌اندازی یه کمپین مارکتینگ داریم، مدیرعامل Accountable است.C: Consultedکسانی که اکثرا در یک موضوع خاص کارشناس و متخصص هستند و با آنها مشورت می‌شود.مثال :  زمانی که قصد راه‌اندازی یه کمپین مارکتینگ داریم، مشاوران copywriter یا designer ، Consulted هستند.I: Informedکسی که همیشه در جریان آخرین اطلاعات روند پروژه است و بیشتر مانند چشم، مراقبت می‌کنند اما اعمال فیدبک آنها خیلی ضروری نیست.مثال :  زمانی که قصد راه‌اندازی یه کمپین مارکتینگ داریم، مدیر فنی پروژه، Informed است.و اما سوال اینجاست این ابزار محبوب، در دنیای توسعه نرم‌افزار چقدر کاربرد دارد؟ سعی می‌کنم نظر خودم رو در چند عنوان بیان کنم:تفاوت دنیا : از نظر من زمانی که قصد انجام کاری را داریم ابتدا باید بدانیم در چه شرایط و دنیایی در حال تصمیم‌گیری هستیم، دنیای پروژه و دنیای توسعه محصول کاملا با هم متفاوت هستند، حتما فریم ورک Cynefin را می‌شناسید:تعریف کار در این دنیا ها متفاوت است، توسعه محصول در دنیای Complex صورت می‌گیرد و تعریف انجام کار، صرفا Done‌ کردن آن نیست. در این دنیا ارزشی که در نهایت خلق می‌شود تعیین کننده میزان تلاشی است که برای آن صورت گرفته است. در این دنیا یک تیم شکل گرفته از مهارت‌ها و تخصص‌های متفاوت به عنوان یک موجود واحد مورد خطاب قرار گرفته و در قبال خلق ارزش تلاش می‌کنند. فضای این تیم، فضای ندانستن است و همیشه در حال تمرین برای یادگیری هستند و اشتباه یکی از طبیعی‌ترین اتفاقات تیم است و تجویز از پیش‌تعیین شده‌ای وجود ندارد.ابزار RACI سعی در حل مشکلات به صورت خطی (Linear ) دارد، در دنیای Complex نمی‌توان با دید خطی سراغ حل آن‌ها رفت، ولی در دنیای Simple و یا حتی Complicated که دنیای واضحات است، صرفا به اتمام رساندن یک‌سری Task‌از پیش تعیین شده، ملاک موفقیت است. پس می‌توان با خطی کردن روند پروژه (مانند کارخانه رب‌سازی) و تفویض مسولیت‌ها با این ابزار سیستم مدیریتی درستی اعمال کرد. در دنیای پروژه، یک تاریخ به عنوان تاریخ اتمام پروژه تعیین می‌شود و اشتباه معنی ندارد. افراد به تنهایی بار مسئولیت را  بر می‌دارند.جداسازی  فکر کردن از انجام دادن : ابزار RACI در تلاش است تا حد امکان این دو را از هم جدا کند تا فضای کاری را ساده‌تر کند. تفکری که در کارخانه‌ها توسط تیلور رواج پیدا کرد و سعی کرد با تشویق‌های مالی Workers های بهتری تحت مدیریت مهندسین پرورش دهد.این ابزار در جهت خلق سیستم Command and Control بسیار خوب عمل می‌کنداشاعه finger pointing : ابزار RACI از آن جهت محبوب است که می‌توان در انتهای پروژه و در صورت عدم موفقیت مقصر را به راحتی شناسایی کرد، به همین دلیل همیشه از حل مسئله دنیای عدم قطعیت به صورت مشارکتی پرهیز می‌کند که نتیجه‌اش  اشاعه فرهنگ سرزنش و بهانه‌جویی است، در حالی که با روحیه تیم‌های ارزش‌محور زاویه اساسی دارند.پهنای باند: بکارگیری این ابزار در تیم توسعه محصول، باعث می‌شود پهنای باند موجود در تیم به شدت خدشه دار شود. با تفکیک مسولیت‌ها، این پهنای باند کم شده و عملا بستر مناسب انرژیک کل تیم از بین خواهد رفت. در دنیای امروز تفکیک تخصص‌ها به این سادگی امکان پذیر نیست و در عمل امکان دارد افرادی که نقش مشاور دارند، در اجرا بسیار موثرتر باشند و بالعکس.و اما خلاصه نظر من:هر گاه اصول زیر را زیر پا گذاشتیم سراغ ابزار RACI‌ در تیم‌های توسعه محصول می‌رویم :ذینفعان کسب و کار و توسعه دهنده ها می بایست به صورت روزانه در طول پروژه با هم کار کنندپروژه ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی کنید و به آنها اعتماد کنید تا کارها را انجام دهندنرم افزار قابل استفاده اصلی ترین معیار سنجش پیشرفت استبهترین معماری ها , نیازمندی ها و طراحی ها از تیم های خود سازمانده پدید آور می شوددر فواصل منظم , تیم بر چگونگی موثرتر شدن تامل و تفکر می نماید و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می نمایدوقتی این موراد نقض شد و سراغ ابزار RACI بریم، بعد از مدتی باید دنبال ادمین RACI بگردیم :Dبا تشکر از سهیل صمد‌زاده عزیز که فیدبک‌های خوبی به من داد تا بتوانم نظرم رو شفاف‌تر بیان کنم.</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Sat, 16 May 2020 10:28:14 +0430</pubDate>
            </item>
                    <item>
                <title>پومودورو، امکانی برای ارتقاء بهره‌وری در روز‌های دورکاری - قسمت اول</title>
                <link>https://virgool.io/@Navidnikpey/%D8%A7%D9%85%DA%A9%D8%A7%D9%86%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%B2%D9%85%D8%A7%D9%86-%D9%88-%D8%A8%D9%87%D8%B1%D9%87%D9%88%D8%B1%DB%8C-%D8%AF%D8%B1-%D8%B1%D9%88%D8%B2%D9%87%D8%A7%DB%8C-%D8%AF%D9%88%D8%B1%DA%A9%D8%A7%D8%B1%DB%8C-%D9%BE%D9%88%D9%85%D9%88%D8%AF%D9%88%D8%B1%D9%88-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-mkldflbjsbtq</link>
                <description>این روزها که که اکثر سازمان‌ها، راهکار #دورکاری را برای حفظ سلامتی کارکنان خود انتخاب کرده‌اند، مدیریت زمان شخصی در جهت بالابردن کارایی روزانه به چالشی عمومی تبدیل شده و به نظر می‌رسد این چالش به جنبه‌های دیگر زندگی شخصی هم ضربه خواهد زد.از آن سو، کیفیت انجام و اجرای کارهای سازمانی نیز تحت شعاع قرار خواهد گرفت.به همین دلیل، در این نوشته سعی می‌کنم تکنیکی که خودم نزدیک به یک سال است از آن استفاده می‌کنم را معرفی کنم تا شاید ( شاید ! ) امکانی مناسب برای افرادی باشد که با مشکل مدیریت زمان شخصی و کارایی در این روزهای سخت مواجهند.تکنیک پومودورو Pomodoroپومودورو توسط‌ استاد Francesco Cirillo در سال ۱۹۸۰ معرفی شد و یکی از تکنیک‌های محبوب چابک‌کاران است که از چند اصل و تمرین چابکی مانند Inspect-and-adopt ، Time-boxing و Estimation و ... استفاده می‌کند تا به مدیریت کارایی شخصی کمک کند. هدف اصلی این تکنیک استفاده ارزشمندتری از زمان است تا کارهای مدنظرمان را انجام دهیم و از همه مهم‌تر،  امکانی برای بهبود در کارایی و روش انجام کارها فراهم شود.استاد Francesco Cirilloاز مهم‌ترین مزایای استفاده از این تکنی می‌توان به موارد زیر اشاره کرد:- کاهش اضطراب- افزایش تمرکز به وسیله کم‌کردن تداخل‌ها- خودآگاهی بیشتر نسبت به تصمیم‌هایمان- تقویت و تثبیت انگیزه- تقویت عزم برای رسیدن به اهداف کوتاه‌مدت و میان‌مدت- ارزیابی و اصلاح فرآیند تخمین ;-)- امکان بهبود روش انجام کار و یا مطالعه- فراگیری مهارتی موثر برای به کارگیری در زمان بحرانروند اصلی تکنیک پومودور:۱- انتخاب Taskی که می‌خواهید انجام دهید۲- تنظیم پومودورو (تایمر) برای ۲۵ دقیقه  ۳- کار بر روی Task تا پایان زمان ۲۵ دقیقه ( صرفا تمرکز بر روی موضوع و جلوگیری از هر تداخلی)۴-  یک استراحت ۵ دقیقه‌ای۵- ثبت پومودورو طی شده ( اگر هنوز پومودورو باقی مانده برو به مرحله ۲ - بعد از چهارمین پومودورو برو ۶ ) ۶- بعد از هر ۴ پومودورو یک استراحت طولانی‌تر ( ۱۵ دقیقه )تداخل‌هادر زمان‌هایی که در منزل در حال دورکاری هستیم حتما تداخل‌ها ( interruptions ) سراغ ما می‌آیند، وقفه‌هایی که باعث حواس‌پرتی و عدم تمرکز می‌شوند. تداخل‌ها دو نوع هستند، تداخل‌هایی که منبع درونی (خودمان) دارند و تداخل‌هایی که منشا بیرونی دارند.بهترین روش برای مبارزه با هر وقفه‌های درونی و یا خارجی، تابلوکردن آنها ست. :-) بله. سعی کنید هر زمان وقفه‌ای سراغ شما آمد ( نوشیدن چای، چک کردن موبایل، بلند شدن و ... ) در کارت مربوط به Task، یک نشانه (مثلا ‘ ) بگذارید. همین. شاید در ابتدا معنی ندهد ولی کم‌کم و با مشاهده میزان تداخل‌های درونی خود، شروع به مدیریت آنها می‌کنید. برای من اینطور کار می‌کنه که هر بار که نشانه‌ای را در کارت ثبت می‌کنم، یک‌بار دیگر اهمیت و ارزش Task‌ را یادآوری می‌کنم و سریع تداخل ذهنی‌ام برطرف می‌شود.ولی اگر در حین پومودورو، یادتان افتاد که باید کار دیگری انجام دهید، سریع کارتی با عنوانی مشخص ولی با پسوند U- به نشانه Unplanned در لیست همان‌روز درج کنید و دیگر به آن فکر نکنید.شاید سوالی که برایتان پیش آمده باشد این است که این تکنیک، زمانی که تنها یک Task‌وجود دارد مفید است، ولی وقتی چندین Task روزانه داشته باشیم چطور؟بگذارید تجربه شخصی خودم رو از این شرایط توضیح بدم:قبل از هر چیزی باید تاکید کنم، کلید موفقیت این تکنیک، تابلو کردن همه چیز است. ( از اصطلاحات سهیل صمدزاده به سرقت رفته است :D ) سعی کنید روی بردی فیزیکی و یا نرم‌افزاری (من از ترلو استفاده می‌کنم) همه چیز شفاف جلوی چشمانتان باشد. همین کار باعث می‌شود بر همه اتفاقات احاطه داشته باشید. طبیعتا همیشه لیستی از کارهای انجام نشده داریم که قرار هست انجام بدیم و این لیست همیشه هم در حال تغییر است. در ابتدای هر روز و بنا به شرایط، چند Task‌ برای انجام دادن انتخاب می‌کنم، سپس شروع می‌کنم به اولویت‌بندی اونها، در همین حد که بتونم بفهمم Taskی که باید امروز و اول از همه انجام بدم، کودومه. برای این‌ کار از ماتریس اولویت استفاده می‌کنم که البته ذهنی می‌شه ترسیمش کرد و در موردش تصمیم گرفت.حالا می‌رسیم به بحث زیبای Estimation و تخمین زدن (در قسمت دوم بیشتر در موردش حرف می‌زنم). در روزهای اول با بهترین حدسم، شروع کردم به تخمین زدن Taskها. اینکه این Task قرار هست چند پومودورو زمان نیاز داشته باشه، اگر Taskی بین ۵ تا ۷ پومودورو تخمین زده شد شروع می‌کنم به شکستنش و اگر Taskی کمتر از یک پومودورو نیاز داشت، با Task‌ دیگری ادغامش می‌کنم.من این کار رو در ترلو به راحتی انجام می‌دم، هم می‌تونم تخمین رو ثبت کنم و هم با checklist تعداد پومودورهارو برای هر تسک مشخص کنم و هر وقت پومودورش تموم میشه، در کارتش تیکش رو می‌زنم.در شکل زیر کارت نوشتن این مطلب رو می‌بینید.سعی کردم کلیات تکنیک رو توضیح دادم و در قسمت بعدی به سوالاتی که پیش میاد و ازم می‌پرسید و البته کشف‌هایی که برای خودم داشتم بخصوص در مورد تخمین‌زدن و اصول چابکی  ( به خصوص Inspect-and-Adopt‌) در نظر گرفته شده در این تکنیک خواهم پرداخت. ارادتنوید</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Sun, 01 Mar 2020 17:17:04 +0330</pubDate>
            </item>
                    <item>
                <title>چطور مدرک PSM I رو گرفتم؟</title>
                <link>https://virgool.io/@Navidnikpey/%DA%86%D8%B7%D9%88%D8%B1-%D9%85%D8%AF%D8%B1%DA%A9-psm-i-%D8%B1%D9%88-%DA%AF%D8%B1%D9%81%D8%AA%D9%85-kupdh0eef5rk</link>
                <description>بعد از اینکه موفق شدم مدرک PSM I رو بگیرم، خیلی از دوستان در مورد مسیر و منابع مطالعاتی از من سوال می‌کردند، به همین دلیل ترجیح دادم در این پست این اطلاعاتی رو به اشتراک بگذارم، شاید کمک کوچکی به دوستان کرده باشم:در ابتدا باید بگم من این مسیر و با راهنمایی و هدایت آقای سید مهدی حسینی شروع کردم. از طریق یکی از دوستان مشترک با ایشون آشنا شدم. ازشون درخواست کردم منابع و مسیر رو برای این مدرک به من معرفی کنندو ایشون با توجه به مهارت، تخصص و تجربه‌شون برای اینکه به صورت خودآموز بتونم مطالعه کنم منابع خوبی رو بهم معرفی کردند.( البته بنده در یکی از دوره‌های ایشون که یک کمپ یک‌روزه بود شرکت کردم) منابعی که استفاده کردم رو به دو بخش تقسیم کردم، بخش اول منابع مطالعاتی برای آموزش و یادگیری اسکرام هست و بخش دوم منابع برای آمادگی امتحان PSM I. بخش اول :از نظر من، اصلی‌ترین منبع تنها و تنها Scrum Guide هست که واقعا خوندن روزانه اون رو به همه پیشنهاد می‌کنم. درک عمیق و کامل از مفاهیم Scrum Guide نقش اساسی و تعیین‌کننده‌ای در پاسخ به سوالات امتحان داره. نسخه آنلاین رو می‌تونید از این لینک و نسخه PDF رو از این لینک دریافت کنید. شاید باورتون نشه ولی نسخه فارسی هم داره که می‌تونید از اینجا دانلود کنید.منبع دیگه‌ای که خیلی تونست من رو کمک کنه Scrum Insights for Practitioners از آقای Hiren Doshi بود. این کتاب در عین حالی که بسیار مفصل‌تر راجع به اسکرام صحبت کرده، نمودارها و تصاویر پرمحتوایی داره که بسیار در درک عمیق‌تر مفاهیم کمکم کرد. این کتاب حتی برای آزمون PSPO هم مناسب هست. منبع سوم The Scrum Master Training Manual بود که برای mplaza هست و دو مولف داره که یکیشون یک ایرانی به نام  Nader K. Rad  هست. خیلی محتوای مختصر ولی مفید و دقیقی داره که برای مرور‌های هفتگی انتخاب مناسبیه. یکی از منابع مهمی دیگری که من در اختیار داشتم اسلاید‌های تدریس آقای حسینی بود که به دلیل اینکه مالکیتش برای ایشون هست نمی‌تونم به اشتراک بگذارم. ولی به شدت کاربردی بود برای من و باعث می‌شد خیلی از مفاهیمی که در Scrum Guide پراکنده از هم تعریف شده بودند ولی به هم مربوط هستند رو در یک یا دو اسلاید به صورت یکجا مرور کنم. بخش دوم:‌من می‌خواستم قبل از شرکت در امتحان، چندبار به صورت کاملا شبیه‌سازی شده امتحان رو انجام بدم و شرایط برام عادی بشه و با ساختار سوال‌ها آشنا بشم. جستجویی که کردم متوجه شدم چند منبع خوب در اینترنت هست که اکثرا پولی هستند و چندتا محدود رایگان، که من از دوتا شون استفاده کردم:یکی از معروف‌ترین سایت‌هایی که تعداد سوال خوبی هم داره Mplaza بود که ۲۷ یورو هزینش بود. چیزی که مهمه اینه که این سایت 455 نمونه سوال داره و بعد از ده بار امتحان دادن تقریبا سوالات دیگه تکراری میشن. کمک خوبی که این وب سایت برای من داشت این بود که اگر سوالی رو اشتباه می‌زدم به صورت کاملا دقیق و مفهومی جواب درست سوال رو با توضیح بهم می‌گفت. این هم نتیجه تست‌های من :منبع دیگری که من برای شبیه‌سازی امتحان ازش استفاده کردم وب سایت آقای  Mikhail Lapshin  بود. درسته که نمونه سوالات کمتری داشت ولی دو تا روش شبیه سازی Learning Mode و Real Mode داره. که روش LMش مزیتی که داره اینه که وقتی جواب سوالی رو اشتباه می‌زدم در لحظه توضیح کامل برام می‌اومد و لازم نبود منتظر بمونم تا آخر سوالات. البته این نکته رو هم باید بگم به تازگی آقای حسینی در وب‌سایتشون شبیه‌سازی PSM I رو راه‌اندازی کردند و فکر کنم اون هم منبع خوبی باشه. در مورد خود امتحان باید بگم تقریبا ۲۰ درصد سوالات رو قبلا دیده بودم و سوالات بیشتر جنبه عملیاتی داشتند. یعنی شرایطی رو توصیف می‌کرد و مثلا می‌گفت به عنوان یک اسکرام مستر در این شرایط بهترین عکس‌العمل چی هست!!</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Wed, 03 Jul 2019 14:19:51 +0430</pubDate>
            </item>
                    <item>
                <title>عزت کاری</title>
                <link>https://virgool.io/@Navidnikpey/%D8%B9%D8%B2%D8%AA-%DA%A9%D8%A7%D8%B1%DB%8C-un2kig0usetb</link>
                <description>طی این سال‌هایی که هم کارآموز بودم، هم کارمند و هم مدیر، یکی از مهم‌ترین دغدغه‌هام حفظ عزت خودم و بخشم در سازمان بوده و هست. همیشه از این ترسیدم که روزی این عزت خدشه‌دار نشه و خداروشکر تا الان همچین اتفاقی نیفتاده است. از طرف دیگر سعی کردم نکات یا نقاطی که امکان دارد از آنها عزت کاری دچار ضربه شود را نیز پیدا کنم. از نظر من مهم‌ترین نکته در حفظ این عزت توانمندی و شایسته بودن برای جایگاهی است که در آن مشغول کاریم. در صورتی که شایستگی لازم برای آن جایگاه در ما نباشد بالاخره روزی به شکلی عزتمان دچار ضعف خواهد شد. شایستگی‌ای که نه فقط به تایید مدیران بالاسری بلکه شایستگی‌ای درونی که خود از سر هزاران تجربه و اتفاق به کم یا زیاد بودن آن پی برده‌ایم .یکی دیگر از پاشنه آشیل‌های عزت کاری ایجاد ارتباط موثر با همکار یا کارمند است که این ارتباط می‌تواند علاوه بر پیشرفت تیمی و سازمانی، پیشرفت فردی را نیز به همراه داشته باشد. این ارتباط موثر بایستی در مسیر آرمان‌ها و اهداف شرکت بوده و حتی فراتر از آن در مسیری انسانی باشد. حفظ احترام، همدلی، هدایت پذیری و نکاتی از این دست مهم‌ترین نکات در ایجاد ارتباط موثر است. در این روزهای پیشرو سعی می‌کنم چند نکته دیگر نیز در این باره بیان کنم. </description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Sat, 04 Aug 2018 17:26:39 +0430</pubDate>
            </item>
                    <item>
                <title>چالش یک دقیقه‌ای...</title>
                <link>https://virgool.io/@Navidnikpey/%DA%86%D8%A7%D9%84%D8%B4-%DB%8C%DA%A9-%D8%AF%D9%82%DB%8C%D9%82%D9%87%D8%A7%DB%8C-mlukdojvbmlm</link>
                <description>چندی قبل چالش جالبی دیدم، هر یک از حاضرین در جلسه یک دقیقه وقت داشتند خودشان را معرفی کنند و سپس یک دقیقه وقت داشتند بگویند چه کاری در آن سازمان انجام می‌دهند. معرفی‌های جالبی می شنیدیم، و تمرکز اکثر حاضرین روی مختصر و مفید بودن محتوا بود. ولی اتفاقا در این چالش بخصوص، می بایست انقدر بر شخصیت و توانایی‌ها و کارهای روزانه خود مسلط می‌بودند که تمام طول یک دقیقه را صحبت می‌کردند. اصولا شخصی به لحاظ سازمانی، مفیدتر و سالم‌تر می‌بود که حتی اگر محتوایش مربوط به کار سازمانیش نیود، ولی بتواند کل یک دقیقه( و شاید بیشتر از آن را ) صحبت کند و به معرفی خود و توانایی‌هایش و کارهای روزانه‌اش بپردازد. بعد از تمام شدن شدن این چالش به این فکر می کردم که چقدر از کارمندانی که از کار خود ناراضی هستند می‌توانند با انجام این چالش به خود و سازمانشان کمک کنند. این چالش به شما می فهماند اساسا کجای کارید و چقدر هدفمند در حال صرف کردن وقت خود در طول روز هستید. امتحان کنید: شما یک دقیقه وقت دارید خودتان را معرفی کنید و یک دقیقه وقت دارید بگویید در طول روز چه کارهایی انجام می دهید.</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Sat, 20 Jan 2018 09:44:37 +0330</pubDate>
            </item>
                    <item>
                <title>ویژن یا چشم انداز کاری!!! چی هست؟</title>
                <link>https://virgool.io/@Navidnikpey/%D9%88%DB%8C%DA%98%D9%86-%DB%8C%D8%A7-%DA%86%D8%B4%D9%85-%D8%A7%D9%86%D8%AF%D8%A7%D8%B2-%DA%A9%D8%A7%D8%B1%DB%8C-%DA%86%DB%8C-%D9%87%D8%B3%D8%AA%D8%9F-e6biya2jkviu</link>
                <description>بنا به موقعیت شغلیم مصاحبه های کاری زیادی انجام میدم که اکثرا با کارشناسان فنی حوزه شبکه های کامپیوتریه. یکی از سوالاتی که همیشه برام پیش میاد اینه که چرا همه دارن از بیکاری می نالن ولی ما اکثرا با نیومدن سر مصاحبه جویای کار مواجهیم. بارها و بارها اتفاق افتاده شخصی پیگیر بوده برای حضور در مصاحبه و بعد با نیومدنش کلی سورپرایز شدیم ( البته الان دیگه برامون جذابیتی نداره  D: )ولی موردی دیگه ای که واقعا به نظر من ضعف اساسی جویندگان کار هست نداشتن یک چشم انداز از زندگی کاری آینده شون هست. تقریبا اکثر شرکت کنندگان در مصاحبه در جواب این سوال که چشم انداز کاریتون برای ده سال آینده چیه هنگ می کنن. یا جوابی ندارند و یا جواب های گنگ و نامفهموم میدن. بر اساس تجربه وقتی داریم در مورد چشم انداز یا ویژن کاریمون صحبت می کنیم تا حد توان نباید از کلمات توصیفی کیفی مثل خفن، بزرگ، مهم، معروف و . . . استفاده کنیم. بایستی کاملا قابل درک و اندازه گیری باشه. به عنوان مثال اینکه من میخوام تا ۱۰ سال آینده مدیر موفق یک شرکت بزرگ با یک ماشین خفن و کلی پول باشم ویژن نیست بله تخیله. کاملا مشخصه به دلیل اوضاع اقتصادی امروزه بحث مالی بخش عمده ای از ویژن تازه واردها به بازار کار رو شامل میشه. سعی کنیم با گردآوری اطلاعات درست و صحیح ویژن برای خودمون درست کنیم. سعی کنیم مهارت رو تصور کنیم و با اونها خودمون رو تعریف کنیم. اینکه ۱۰ سال دیگه چه کارهایی باید بلد باشیم چه تخصص هایی یاد بگیریم و درصد استفاده و تاثیر  اونها رو با توجه به رشد هر روزه مهارت ها محاسبه کنیم. و نکته آخر اینکه نمی دونم چرا همه دوست دارن ده سال آینده مدیر باشن؟ نمیدونم چرا ؟ شما میدونید؟</description>
                <category>نوید نیک پی</category>
                <author>نوید نیک پی</author>
                <pubDate>Sun, 15 Oct 2017 12:22:23 +0330</pubDate>
            </item>
            </channel>
</rss>