Forwarded from فلسفه دیزاین
حاشیههایی شیرینتر از داستان
چند وقتیست که از کنفرانس اپل میگذرد. همان کنفرانسی که در آن iPhone X و برخی محصولات دیگرش را معرفی کرد.
مثل همیشه گمانهزنیهایی پیش از کنفرانس شده بود و همه کسانی که پیگیر بودند، میدانستند که باید منتظر چه چیزی باشند. خود اپل هم که انگار از این شایعات و حدسهای مردم لذت میبرد، با منتشر کردن عکسی از لوگوی کنفرانس، شرلوک درون مردم را قلقلک داد.
خلاصه کنفرانس برگزار شد و تغییراتی بزرگ و کوچک روی محصولات پیشین و نمونه جدید آنها معرفی شد. یکی از پرسروصداترین محصولات امسال اپل، iPhone X است. منظور من از سروصدا لزوما صحبتهای خوب درباره این دستگاه جدید نیست. این آیفون جدید، به سنسور تشخیص چهرهای (ساختاری مشابه دستگاههای Kinect) مجهز است که باعث شده طراحان اپل نتوانند صفحه نمایش دستگاه را بصورت لبه تا لبه (edge-to-edge) طراحی کنند. مردم در شبکههای اجتماعی، نام این قسمت را The Notch (به معنی فرورفتگی) نامیدند و شروع به ارائه ایدههای جالب، خندهدار و بعضا تحلیلهای مختلفی کردند.
مقاله امروز به بررسی حواشی و اتفاقات و صحبتهایی که درباره آیفون جدید در شبکههای اجتماعی شکل گرفت میپردازد و منابع و ایدههای خوبی را در طول مقاله معرفی میکند.
پیشنهاد میکنم این مقاله را از دست ندهید.
https://blog.prototypr.io/notch-crazy-iphone-x-mad-475f43d6ee26
(زمان حدودی مطالعه، ۱۰ دقیقه)
#بررسی #محصول #حواشی
@Dexign فلسفه دیزاین
ــــــــــــــــــ
چند وقتیست که از کنفرانس اپل میگذرد. همان کنفرانسی که در آن iPhone X و برخی محصولات دیگرش را معرفی کرد.
مثل همیشه گمانهزنیهایی پیش از کنفرانس شده بود و همه کسانی که پیگیر بودند، میدانستند که باید منتظر چه چیزی باشند. خود اپل هم که انگار از این شایعات و حدسهای مردم لذت میبرد، با منتشر کردن عکسی از لوگوی کنفرانس، شرلوک درون مردم را قلقلک داد.
خلاصه کنفرانس برگزار شد و تغییراتی بزرگ و کوچک روی محصولات پیشین و نمونه جدید آنها معرفی شد. یکی از پرسروصداترین محصولات امسال اپل، iPhone X است. منظور من از سروصدا لزوما صحبتهای خوب درباره این دستگاه جدید نیست. این آیفون جدید، به سنسور تشخیص چهرهای (ساختاری مشابه دستگاههای Kinect) مجهز است که باعث شده طراحان اپل نتوانند صفحه نمایش دستگاه را بصورت لبه تا لبه (edge-to-edge) طراحی کنند. مردم در شبکههای اجتماعی، نام این قسمت را The Notch (به معنی فرورفتگی) نامیدند و شروع به ارائه ایدههای جالب، خندهدار و بعضا تحلیلهای مختلفی کردند.
مقاله امروز به بررسی حواشی و اتفاقات و صحبتهایی که درباره آیفون جدید در شبکههای اجتماعی شکل گرفت میپردازد و منابع و ایدههای خوبی را در طول مقاله معرفی میکند.
پیشنهاد میکنم این مقاله را از دست ندهید.
https://blog.prototypr.io/notch-crazy-iphone-x-mad-475f43d6ee26
(زمان حدودی مطالعه، ۱۰ دقیقه)
#بررسی #محصول #حواشی
@Dexign فلسفه دیزاین
ــــــــــــــــــ
Medium
‘Notch’ crazy, iPhone X mad 📱🤡
What designers think of iPhone X
Forwarded from Iran Agile
🔴 واگذاری اختیارات به تیمهای خودسازمانده
معنی اين جمله که می گويد: « تيم های چابک خود سازمانده هستند» چيست؟ و اينکه اصطلاح درستی است؟ برخی از افراد می گويند تيم ها خود مديريت هستند. برای درک اينکه کدام يک از اين اصطلاحات مناسب تر است بياييد چهار سطح از خودمختاری را که تيم ها می توانند داشته باشند را در نظر بگيريد.
⏬ چهار شیوه توزيع اختیارت:
ريچارد هاکمن استاد دانشگاه هاروارد چهار سطح تخصيص اختيار و قدرت به تيم ها را مورد بررسی قرار داده است. بياييد نگاهی بياندازيم به چهار سطح واگذاری قدرت به تيم ها از منظر هاکمن با شروع از کمترين سطح.
1⃣ يک تيم با کمترين سطح اختيار توسط يک مدير هدايت می شود (Manager-led). اين گونه تيم ها برای انجام کارهای تخصيص يافته به آنها اختيار و قدرت دارند ولی بر روی فرآيندهايشان هيچ گونه قدرت و اختياری ندارند و فقط مدير بر اين فرآيندها مديريت دارد.
2⃣ سطح دوم از منظر هاکمن تيم های خود مديريت (self-managing) هستند. يعنی علاوه بر اختيار و قدرت در انجام وظايف می توانند فرآيندهايشان را نيز خود مديريت کنند. تيم خود مديريت می تواند تصميم بگيرد چگونه کار کند به عنوان مثال می تواند درباره استفاده و بکارگيری نگرش چابک تصميم گيری کند.
3⃣ با افزايش سطح اختيار ، با تيم های خود طراح (self-designing) مواجه می شويم. آنها می توانند کسانی که در تيم هستند را تعديل يا تغيير دهند. اين نوع از تيمها می توانند فردی را از تيم اخراج کنند، می توانند در مورد انتقال يا استخدام افراد ديگر در تيم و … تصميم گيری کنند. در برخی از موارد هم تيمهای خود طراح اختيار گزارش دادن به افراد مرتبط داخل تيم يا خارج تيم را دارند.
4⃣ آخرين نوع از تيم ها، و يکی از مختارترين آنها، تيم های خودمختار (self-governing) هستند. تيم های خودمختار علاوه بر ساير اختيارات، اختيار تغيير اهداف اصلی تيم را هم دارند. تيم های خودمختار می توانند تصميم بگيرند به جای يک محصول اندازه گيری صوتی يک بازی ويدئویی بسازند.
⏬ نوع تيم اختيارات
تيم های مدير محور فقط بر روی انجام وظايف محوله اختيار دارند.
تيم های خود مديريت يا خودسازمانده علاوه بر مورد بالا، اختيار تعيين چگونگی انجام شدن کار (فرآيندها) را نيز دارند.
تيم های خود طراح علاوه بر موارد بالا، در تعيين نفراتی که باید در تيم باشند و گاهی نيز بر روی گزارش دهی ها اختيار دارند
تيم های خودمختار حتی نسبت به تغيير اهداف اصلی تيم نيز مختار هستند
کجای اين سلسله مراتب برای خودسازماندهی مناسب است؟
در سلسله مراتب قدرت و اختيارات هاکمن، تيم های خودسازمانده (self-organizing) چابک در کلاس تيم های خود مديريت قرار می گيرند. تيم های خود سازمانده چابک کارهايشان را خود مديريت می کنند: کدام يک از افراد تيم بايد اين وظيفه را انجام دهد؟ و همچنين درباره چگونگی انجام آن کار هم خودشان مختار هستند: بايد با اسکرام شروع کنيم يا کانبان؟ اسپرينت ما بايد چقدر طول بکشد؟
تيم های چابک خود طراح و خودمختار نيستند، به عبارت ديگر تيم های خود سازمانده بر روی وظايف و فرآيندهايي که استفاده می کنند مختار هستند اما اختياری بر روی نفراتی که بايد در تيم باشند يا اهداف تيم ندارند.
تيم های چابک خود سازمانده هستند يا خود مديريت؟
هر کدام از اينها را می توانيد در نظر بگيريد. اما من اصطلاح خود سازمانده را به دو دليل ترجيح می دهم :
نخست اينکه، در اولين مقاله منتشر شده درباره چابک نويسندگان مقاله تاکوچی و نوناکا از اصطلاح خود سازمانده به عنوان يکی از شش ويژگی مورد نياز برای ايجاد يک فرآيند انعطاف پذير سريع نام برده اند.
دوم اينکه من ريشه های اصطلاح خود سازمانده را در نظريه آشوب يافتم که در فکرکردن درباره رفتار تيم مفيد است. گرد آمدن و ازدحام پرندگان در پرواز يک رفتار خود سازمانده است. يا يک کلونی مورچه، يک کندوی زنبور عسل و يا الگوی ماشين ها در بزرگراه. اين مثالها از خود سازماندهی در طبيعت، اغلب نمونه های مفيدی برای نشان دادن معنای خود سازماندهی تيم های چابک هستند.
مثلا من اغلب شهر سنجابهای زمینی را می بينم، مجموعه ای از تونل هايی که اين حيوانات کوچک آن را حفر کرده اند. اين موجودات تونل های خود را بر مبنای يک طرح جامع پيش بينی شده حفر نمی کنند. آنها حفر می کنند و اگر به صخره ای برخورد کردند اطراف آن را حفر می کنند. تيم کار خود را در يک جهت شروع میکند، اگر ثابت شود مسير نامعتبر است تيم در اطراف مانع تغیير مسير می دهد درست مانند سنجاب های زير زمينی.
https://goo.gl/6puZ9J
@iranagile
معنی اين جمله که می گويد: « تيم های چابک خود سازمانده هستند» چيست؟ و اينکه اصطلاح درستی است؟ برخی از افراد می گويند تيم ها خود مديريت هستند. برای درک اينکه کدام يک از اين اصطلاحات مناسب تر است بياييد چهار سطح از خودمختاری را که تيم ها می توانند داشته باشند را در نظر بگيريد.
⏬ چهار شیوه توزيع اختیارت:
ريچارد هاکمن استاد دانشگاه هاروارد چهار سطح تخصيص اختيار و قدرت به تيم ها را مورد بررسی قرار داده است. بياييد نگاهی بياندازيم به چهار سطح واگذاری قدرت به تيم ها از منظر هاکمن با شروع از کمترين سطح.
1⃣ يک تيم با کمترين سطح اختيار توسط يک مدير هدايت می شود (Manager-led). اين گونه تيم ها برای انجام کارهای تخصيص يافته به آنها اختيار و قدرت دارند ولی بر روی فرآيندهايشان هيچ گونه قدرت و اختياری ندارند و فقط مدير بر اين فرآيندها مديريت دارد.
2⃣ سطح دوم از منظر هاکمن تيم های خود مديريت (self-managing) هستند. يعنی علاوه بر اختيار و قدرت در انجام وظايف می توانند فرآيندهايشان را نيز خود مديريت کنند. تيم خود مديريت می تواند تصميم بگيرد چگونه کار کند به عنوان مثال می تواند درباره استفاده و بکارگيری نگرش چابک تصميم گيری کند.
3⃣ با افزايش سطح اختيار ، با تيم های خود طراح (self-designing) مواجه می شويم. آنها می توانند کسانی که در تيم هستند را تعديل يا تغيير دهند. اين نوع از تيمها می توانند فردی را از تيم اخراج کنند، می توانند در مورد انتقال يا استخدام افراد ديگر در تيم و … تصميم گيری کنند. در برخی از موارد هم تيمهای خود طراح اختيار گزارش دادن به افراد مرتبط داخل تيم يا خارج تيم را دارند.
4⃣ آخرين نوع از تيم ها، و يکی از مختارترين آنها، تيم های خودمختار (self-governing) هستند. تيم های خودمختار علاوه بر ساير اختيارات، اختيار تغيير اهداف اصلی تيم را هم دارند. تيم های خودمختار می توانند تصميم بگيرند به جای يک محصول اندازه گيری صوتی يک بازی ويدئویی بسازند.
⏬ نوع تيم اختيارات
تيم های مدير محور فقط بر روی انجام وظايف محوله اختيار دارند.
تيم های خود مديريت يا خودسازمانده علاوه بر مورد بالا، اختيار تعيين چگونگی انجام شدن کار (فرآيندها) را نيز دارند.
تيم های خود طراح علاوه بر موارد بالا، در تعيين نفراتی که باید در تيم باشند و گاهی نيز بر روی گزارش دهی ها اختيار دارند
تيم های خودمختار حتی نسبت به تغيير اهداف اصلی تيم نيز مختار هستند
کجای اين سلسله مراتب برای خودسازماندهی مناسب است؟
در سلسله مراتب قدرت و اختيارات هاکمن، تيم های خودسازمانده (self-organizing) چابک در کلاس تيم های خود مديريت قرار می گيرند. تيم های خود سازمانده چابک کارهايشان را خود مديريت می کنند: کدام يک از افراد تيم بايد اين وظيفه را انجام دهد؟ و همچنين درباره چگونگی انجام آن کار هم خودشان مختار هستند: بايد با اسکرام شروع کنيم يا کانبان؟ اسپرينت ما بايد چقدر طول بکشد؟
تيم های چابک خود طراح و خودمختار نيستند، به عبارت ديگر تيم های خود سازمانده بر روی وظايف و فرآيندهايي که استفاده می کنند مختار هستند اما اختياری بر روی نفراتی که بايد در تيم باشند يا اهداف تيم ندارند.
تيم های چابک خود سازمانده هستند يا خود مديريت؟
هر کدام از اينها را می توانيد در نظر بگيريد. اما من اصطلاح خود سازمانده را به دو دليل ترجيح می دهم :
نخست اينکه، در اولين مقاله منتشر شده درباره چابک نويسندگان مقاله تاکوچی و نوناکا از اصطلاح خود سازمانده به عنوان يکی از شش ويژگی مورد نياز برای ايجاد يک فرآيند انعطاف پذير سريع نام برده اند.
دوم اينکه من ريشه های اصطلاح خود سازمانده را در نظريه آشوب يافتم که در فکرکردن درباره رفتار تيم مفيد است. گرد آمدن و ازدحام پرندگان در پرواز يک رفتار خود سازمانده است. يا يک کلونی مورچه، يک کندوی زنبور عسل و يا الگوی ماشين ها در بزرگراه. اين مثالها از خود سازماندهی در طبيعت، اغلب نمونه های مفيدی برای نشان دادن معنای خود سازماندهی تيم های چابک هستند.
مثلا من اغلب شهر سنجابهای زمینی را می بينم، مجموعه ای از تونل هايی که اين حيوانات کوچک آن را حفر کرده اند. اين موجودات تونل های خود را بر مبنای يک طرح جامع پيش بينی شده حفر نمی کنند. آنها حفر می کنند و اگر به صخره ای برخورد کردند اطراف آن را حفر می کنند. تيم کار خود را در يک جهت شروع میکند، اگر ثابت شود مسير نامعتبر است تيم در اطراف مانع تغیير مسير می دهد درست مانند سنجاب های زير زمينی.
https://goo.gl/6puZ9J
@iranagile
فیسبوک علاوه بر توسعه React برای وب و موبایل قدم به حوزهی دیگری نیز نهاده است. با استفاده از React VR میتوان با استفاده از جاوا اسکریپت نرم افزارهای واقعیت مجازی تولیدی نمود.
https://facebook.github.io/react-vr
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/sjGB30gAX3w
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
https://facebook.github.io/react-vr
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/sjGB30gAX3w
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
امروزه در بسیاری از پروژهها از Web Sockets استفاده میشود. در این نوع ارتباط در کنار ایجاد ارتباطی از سرور به کلاینت که از آن برای ارسال پیامها استفاده میشود، ارتباطی از کلاینت به سرور نیز باز میشود که عموما مورد استفاده قرار نمیگیرد. ضمن اینکه با توجه به متفاوت بودن پروتکل Web Sockets با HTTP، بسیاری از مواردی که بر روی پروتکل HTTP تنظیم میکنیم (مانند CORS - Compression و ...) بر روی Web Sockets اعمال نمیشود. Server Sent Events در قیاس با Web Sockets گزینهای مناسبتر برای اکثریت پروژهها میباشد که کاملا بر اساس پروتکل HTTP ایجاد شده و سربار کمتری نیز دارد. لینک زیر حاوی توضیحی نسبتا مفصل از مزایایی است که Server Sent Events میتواند برای پروژه شما به ارمغان آورد.
https://docs.bit-framework.com/docs/design-backgrounds/server-sent-events-or-web-sockets.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/2nBc30ebM8o
#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)
کانال تلگرام:
@SoftwarePhilosophy
___
https://docs.bit-framework.com/docs/design-backgrounds/server-sent-events-or-web-sockets.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/2nBc30ebM8o
#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)
کانال تلگرام:
@SoftwarePhilosophy
___
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. استاندارد طراحی URL از لحاظ UX
#ux #webapi #architecture
https://t.iss.one/SoftwarePhilosophy/1030
۲. آشنایی با زبان Elm
#elm #javascript #haskel
https://t.iss.one/SoftwarePhilosophy/1032
https://t.iss.one/SoftwarePhilosophy/1033
۳. حاشیههایی شیرینتر از داستان (فلسفه دیزاین)
#design
https://t.iss.one/SoftwarePhilosophy/1034
۴. واگذاری اختیارات به تیمهای خودسازمانده (Iran Agile)
#agile
https://t.iss.one/SoftwarePhilosophy/1035
۵. استفاده از React VR و جاوا اسکریپت برای تولید نرم افزارهای واقعیت مجازی
#react #vr #javascript
https://t.iss.one/SoftwarePhilosophy/1036
۶. مزایای Server Sent Events برای پروژههای تحت وب
#dotnet #web
https://t.iss.one/SoftwarePhilosophy/1038
ـــــــــــ
@SoftwarePhilosophy
۱. استاندارد طراحی URL از لحاظ UX
#ux #webapi #architecture
https://t.iss.one/SoftwarePhilosophy/1030
۲. آشنایی با زبان Elm
#elm #javascript #haskel
https://t.iss.one/SoftwarePhilosophy/1032
https://t.iss.one/SoftwarePhilosophy/1033
۳. حاشیههایی شیرینتر از داستان (فلسفه دیزاین)
#design
https://t.iss.one/SoftwarePhilosophy/1034
۴. واگذاری اختیارات به تیمهای خودسازمانده (Iran Agile)
#agile
https://t.iss.one/SoftwarePhilosophy/1035
۵. استفاده از React VR و جاوا اسکریپت برای تولید نرم افزارهای واقعیت مجازی
#react #vr #javascript
https://t.iss.one/SoftwarePhilosophy/1036
۶. مزایای Server Sent Events برای پروژههای تحت وب
#dotnet #web
https://t.iss.one/SoftwarePhilosophy/1038
ـــــــــــ
@SoftwarePhilosophy
#پست_مجدد این پست تا به حال بیش از ۱۳۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
بررسی کدها و اجزای نرم افزار از نقطه نظر معماری و طراحی، یافتن وابستگی میان اجزای کد، پیدا کردن مشکلات در کد در زمان اجرا و خواندن کدهای دیگران یکی از مسایلی بوده که همیشه برنامه نویسان و طراحان سیستمها با آن روبرو هستند. یکی از قابلیتهای پنهان و بسیار قدرتمند Visual Studio که از نسخه ۲۰۱۵ ارائه شده است Code Map میباشد که با Visualize کردن باعث میشود کارهای گفته شده به سادگی بیشتر انجام پذیرد.
https://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B346
https://docs.microsoft.com/en-us/visualstudio/modeling/use-code-maps-to-debug-your-applications
https://msdn.microsoft.com/en-us/library/dd409453.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/Kjey30edWbn
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
https://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B346
https://docs.microsoft.com/en-us/visualstudio/modeling/use-code-maps-to-debug-your-applications
https://msdn.microsoft.com/en-us/library/dd409453.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/Kjey30edWbn
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
Channel 9
Understand Code with Code Maps
Code and debugger maps help you understand and navigate through code when troubleshooting and designing new functionality. Come and learn how code maps help you: understand the flow of code when debug
Forwarded from فلسفه دیزاین
معرفی مفهوم Interaction Flows
دیزاین شدن یک محصول، قدمهای اول برای شکلگیری و بدنیا آمدنش است. در مسیر شکلگیری آن افراد و تیمهای مختلفی همکاری میکنند که دیزاینر یا تیم دیزاین و همچنین توسعهدهنده یا تیم توسعه از جمله آنها هستند. نحوه تعامل تیمهای مختلف با یکدیگر و انتقال خروجیهای یک تیم به عنوان ورودی، به تیم دیگر همیشه محل بحث و البته ارائه پیشنهادهایی برای بهبود بوده است.
وقتی محصولی دیزاین میشود، تمامی بخشها و صفحات آن، تمامی روندها و حتی انیمیشنهای تعاملی آن در ذهن دیزاینر شکل میگیرد. گاهی این جزئیات -که اتفاقا ممکن است کار را از سطحی خوب به عالی ببرند- در روند انتقال دیزاینها به تیم توسعه، به خوبی تفهیم نشده و باعث اتلاف وقت زیادی برای هردو طرف میشوند.
ما پیشتر هم درباره این چالش صحبت کرده و ابزارهایی برای انتقال انیمیشنهای تعاملی معرفی کردهایم. امروز میخواهیم راهحل پیشنهادی خانم Havana Nguyen را درباره انتقال روندهای دیزاین بررسی کنیم.
ایشان پس از طرح مساله بالا، راهحلهای مختلف ارائه شده را بررسی کرده و با ترکیب مفاهیم Wireflow و بنیانهای ساخت Microinteractionها، یک Template جدید با نام IX Flows ارائه کردند.
این Template از دید من ترکیبیست از Storyboard و Functional Specification، و مفهومیست کارآمد برای مستندسازی یک دیزاین و انتقال تمام و کمال آن به تیم توسعه.
پیشنهاد میکنم همین حالا مقاله را بررسی کرده تا بتوانید آن را در محصولات خود به کار ببندید.
https://uxplanet.org/an-introduction-to-interaction-flows-a4f783402529
(زمان حدودی مطالعه، ۱۰ دقیقه)
#معرفی #متد #اینتراکشن
@Dexign فلسفه دیزاین
ـــــــــ
دیزاین شدن یک محصول، قدمهای اول برای شکلگیری و بدنیا آمدنش است. در مسیر شکلگیری آن افراد و تیمهای مختلفی همکاری میکنند که دیزاینر یا تیم دیزاین و همچنین توسعهدهنده یا تیم توسعه از جمله آنها هستند. نحوه تعامل تیمهای مختلف با یکدیگر و انتقال خروجیهای یک تیم به عنوان ورودی، به تیم دیگر همیشه محل بحث و البته ارائه پیشنهادهایی برای بهبود بوده است.
وقتی محصولی دیزاین میشود، تمامی بخشها و صفحات آن، تمامی روندها و حتی انیمیشنهای تعاملی آن در ذهن دیزاینر شکل میگیرد. گاهی این جزئیات -که اتفاقا ممکن است کار را از سطحی خوب به عالی ببرند- در روند انتقال دیزاینها به تیم توسعه، به خوبی تفهیم نشده و باعث اتلاف وقت زیادی برای هردو طرف میشوند.
ما پیشتر هم درباره این چالش صحبت کرده و ابزارهایی برای انتقال انیمیشنهای تعاملی معرفی کردهایم. امروز میخواهیم راهحل پیشنهادی خانم Havana Nguyen را درباره انتقال روندهای دیزاین بررسی کنیم.
ایشان پس از طرح مساله بالا، راهحلهای مختلف ارائه شده را بررسی کرده و با ترکیب مفاهیم Wireflow و بنیانهای ساخت Microinteractionها، یک Template جدید با نام IX Flows ارائه کردند.
این Template از دید من ترکیبیست از Storyboard و Functional Specification، و مفهومیست کارآمد برای مستندسازی یک دیزاین و انتقال تمام و کمال آن به تیم توسعه.
پیشنهاد میکنم همین حالا مقاله را بررسی کرده تا بتوانید آن را در محصولات خود به کار ببندید.
https://uxplanet.org/an-introduction-to-interaction-flows-a4f783402529
(زمان حدودی مطالعه، ۱۰ دقیقه)
#معرفی #متد #اینتراکشن
@Dexign فلسفه دیزاین
ـــــــــ
Medium
An Introduction to Interaction Flows
Could IX Flows be a key to smoother design/dev handoffs?
Forwarded from Iran Agile
🔴 مدیران را اخراج کنید!
خیلی از کارمندها بجای آنکه برای شرکت یا مشتریان کار کنند، برای روسای شان کار می کنند. کسب و کارها این روزها با لایه های متعدد مدیریتی پر شده اند، و کارمندها باید به فکر کارهای سیاسی و انجام کارهایی برای راضی کردن رییس شان باشند.
آخر روز، هدف های شرکت فراموش شده اند، و هر کس تنها روی انجام کارهایی که دستش است تمرکز می کند، بدون اینکه بداند این کار چطور در تصویر بزرگتر قرار می گیرد.
اگر شما هم با این وضع روبرو هستید، ساختار سلسله مراتبی سازمان تان دچار مشکل است.
ایلیا پوزین، موسس شرکت بازاریابی اینترنتی با حذف این مدل سلسه مراتبی، شرکتی ساخته که آدم ها عاشق کار کردن در آن باشند، و در هزینه ها هم صرفه جویی شود. ایلیا حرفی از اسکرام و اجایل نمی زند، و اساسا کارش در حوزه ی نرم افزار نیست. ولی اصولی که بیان می کند دقیقا مشابه همان چیزی است که آن را روح اسکرام می خوانند. برای همین فکر می کنم بد نباشد یک بار دیگر این اصول را از نگاه مدیری در خارج از حوزه نرم افزار بخوانیم:
ایجاد یک فرهنگ تیمی
کارمندان به تیم های سه تا پنج نفره تقسیم شده اند که در آنها کسی رییس نیست. همه عناوینی که شامل کلمات ارشد یا سرپرست بوده اند هم تغییر کرده اند. از آنجا که کسانی که توانایی رهبری دارند خودشان در تیم ظهور می کنند، نیازی به ایجاد یک ساختار سفت و سخت گزارش دهی نیست. ممکن است ابتدا کارکنان ارشد از این تغییر خوششان نیاید، ولی باید به آنها یادآوری کنید که تغییر در فرهنگ و عادات کاری نهایتا به افزایش کارایی و بالارفتن انگیزه ی کاری برای همه منجر می شود. اجازه دهید اعضای تیم عناوین خودشان را انتخاب کنند، و از آنها بخواهید ارزیابی عملکرد خویش را به عهده بگیرند، طوری که بتوانند بیاموزند و رشد کنند.
تعیین اهداف
کارهایی که افراد انجام می دهند باید به شکلی همگرا و با معنی باشند، نه اینکه آنها صرفا تعدادی فعالیت مجزا انجام دهند. برای هر تیم هدفی مشخص تعیین کنید که به راحتی در بازه های زمانی کوتاه (مثلا یکی دو هفته) قابل اندازه گیری باشد. اینطوری کارکنان می توانند ببینند که دقیقا برای رسیدن به چه دستاوردی تلاش می کنند. به این ترتیب می توانند بجای تمرکز روی “چگونه” روی “چرا” تمرکز کنند. با داشتن یک هدف و بازه های زمانی کوتاه، تیم ها می توانند عملکرد خود را اندازه بگیرند و از اشتباهات قبلی بیاموزند، و عملکرد خود را در بازه زمانی بعدی بهبود دهند. با تعیین فلسفه و هدف کار تیم، کارکنان دیگر حس نمی کنند که دارند فقط کارهایی را برای خوشحالی رییس شان انجام می دهند. تیم از اینکه صاحب هدف و مسئولیت است استقبال می کند. اگر نیاز به کمک داشتند، یک لایه ی پشتیبان دارند، ولی سلسله مراتبی وجود ندارد.
پشتیبانی کنید، نه دعوا
در ساختارهای سلسله مراتبی، وقتی مشکلی پیش می آید دعوا می شود. هر کس سعی می کند مشکل را به گردن دیگری بیاندازد. وقتی هم که مشکل حل می شود، هر کس تلاش می کند حل آن را به خودش نسبت دهد. در مدل من، نقش مدیران و روسا به حامیان تیم ها تغییر می کند. آنها برای تیم ها کار می کنند، و به تیم ها هر جایی که لازم داشته باشند کمک می کنند، بجای آنکه به افراد بگویند که چکار کنند یا چگونه کار را انجام دهند. با حذف سلسله مراتب، رضایت مشتری به هدف و اولویت تیم ها تبدیل می شود. وقتی مشکلی پیش بیاید هم همه مشترکا مسئول آن هستند و کسی نمی تواند تقصیر را به گردن دیگری بیاندازد. دیگر عناوین و واحدهای سازمانی آنها را از هم جدا نمی کند.
نگرانی برای پول را از بین ببرید
به طور پیش فرض، مزد و حقوق سلسله مراتبی است. وقتی ساختار سازمانی را مسطح می کنید، قرار نیست حقوق همه را هم مساوی پرداخت کنید، بلکه باید با کارکنان تان صحبت کنید. از آنها بپرسید برای آنکه راحت باشند باید چقدر درآمد ماهانه داشته باشند. به نظر خودشان حقوق منصفانه شان چقدر است. ما حقوق کسی را کم نکردیم، ولی حقوق بعضی ها را افزایش دادیم. سطوح پرداختی را به شکلی تعریف کنید که به عملکرد مربوط باشند، نه به عناوین شغلی یا ارشدیت. اگر کارکنان شما همیشه نگران پول نباشند، فرهنگ سازمانی شما رو به رشد خواهد رفت. یادتان باشد که می خواهید کارکنان تان برای رسیدن به هدف تیم کار کنند، نه برای دریافت چک حقوق.
https://goo.gl/2G14vC
@iranagile
خیلی از کارمندها بجای آنکه برای شرکت یا مشتریان کار کنند، برای روسای شان کار می کنند. کسب و کارها این روزها با لایه های متعدد مدیریتی پر شده اند، و کارمندها باید به فکر کارهای سیاسی و انجام کارهایی برای راضی کردن رییس شان باشند.
آخر روز، هدف های شرکت فراموش شده اند، و هر کس تنها روی انجام کارهایی که دستش است تمرکز می کند، بدون اینکه بداند این کار چطور در تصویر بزرگتر قرار می گیرد.
اگر شما هم با این وضع روبرو هستید، ساختار سلسله مراتبی سازمان تان دچار مشکل است.
ایلیا پوزین، موسس شرکت بازاریابی اینترنتی با حذف این مدل سلسه مراتبی، شرکتی ساخته که آدم ها عاشق کار کردن در آن باشند، و در هزینه ها هم صرفه جویی شود. ایلیا حرفی از اسکرام و اجایل نمی زند، و اساسا کارش در حوزه ی نرم افزار نیست. ولی اصولی که بیان می کند دقیقا مشابه همان چیزی است که آن را روح اسکرام می خوانند. برای همین فکر می کنم بد نباشد یک بار دیگر این اصول را از نگاه مدیری در خارج از حوزه نرم افزار بخوانیم:
ایجاد یک فرهنگ تیمی
کارمندان به تیم های سه تا پنج نفره تقسیم شده اند که در آنها کسی رییس نیست. همه عناوینی که شامل کلمات ارشد یا سرپرست بوده اند هم تغییر کرده اند. از آنجا که کسانی که توانایی رهبری دارند خودشان در تیم ظهور می کنند، نیازی به ایجاد یک ساختار سفت و سخت گزارش دهی نیست. ممکن است ابتدا کارکنان ارشد از این تغییر خوششان نیاید، ولی باید به آنها یادآوری کنید که تغییر در فرهنگ و عادات کاری نهایتا به افزایش کارایی و بالارفتن انگیزه ی کاری برای همه منجر می شود. اجازه دهید اعضای تیم عناوین خودشان را انتخاب کنند، و از آنها بخواهید ارزیابی عملکرد خویش را به عهده بگیرند، طوری که بتوانند بیاموزند و رشد کنند.
تعیین اهداف
کارهایی که افراد انجام می دهند باید به شکلی همگرا و با معنی باشند، نه اینکه آنها صرفا تعدادی فعالیت مجزا انجام دهند. برای هر تیم هدفی مشخص تعیین کنید که به راحتی در بازه های زمانی کوتاه (مثلا یکی دو هفته) قابل اندازه گیری باشد. اینطوری کارکنان می توانند ببینند که دقیقا برای رسیدن به چه دستاوردی تلاش می کنند. به این ترتیب می توانند بجای تمرکز روی “چگونه” روی “چرا” تمرکز کنند. با داشتن یک هدف و بازه های زمانی کوتاه، تیم ها می توانند عملکرد خود را اندازه بگیرند و از اشتباهات قبلی بیاموزند، و عملکرد خود را در بازه زمانی بعدی بهبود دهند. با تعیین فلسفه و هدف کار تیم، کارکنان دیگر حس نمی کنند که دارند فقط کارهایی را برای خوشحالی رییس شان انجام می دهند. تیم از اینکه صاحب هدف و مسئولیت است استقبال می کند. اگر نیاز به کمک داشتند، یک لایه ی پشتیبان دارند، ولی سلسله مراتبی وجود ندارد.
پشتیبانی کنید، نه دعوا
در ساختارهای سلسله مراتبی، وقتی مشکلی پیش می آید دعوا می شود. هر کس سعی می کند مشکل را به گردن دیگری بیاندازد. وقتی هم که مشکل حل می شود، هر کس تلاش می کند حل آن را به خودش نسبت دهد. در مدل من، نقش مدیران و روسا به حامیان تیم ها تغییر می کند. آنها برای تیم ها کار می کنند، و به تیم ها هر جایی که لازم داشته باشند کمک می کنند، بجای آنکه به افراد بگویند که چکار کنند یا چگونه کار را انجام دهند. با حذف سلسله مراتب، رضایت مشتری به هدف و اولویت تیم ها تبدیل می شود. وقتی مشکلی پیش بیاید هم همه مشترکا مسئول آن هستند و کسی نمی تواند تقصیر را به گردن دیگری بیاندازد. دیگر عناوین و واحدهای سازمانی آنها را از هم جدا نمی کند.
نگرانی برای پول را از بین ببرید
به طور پیش فرض، مزد و حقوق سلسله مراتبی است. وقتی ساختار سازمانی را مسطح می کنید، قرار نیست حقوق همه را هم مساوی پرداخت کنید، بلکه باید با کارکنان تان صحبت کنید. از آنها بپرسید برای آنکه راحت باشند باید چقدر درآمد ماهانه داشته باشند. به نظر خودشان حقوق منصفانه شان چقدر است. ما حقوق کسی را کم نکردیم، ولی حقوق بعضی ها را افزایش دادیم. سطوح پرداختی را به شکلی تعریف کنید که به عملکرد مربوط باشند، نه به عناوین شغلی یا ارشدیت. اگر کارکنان شما همیشه نگران پول نباشند، فرهنگ سازمانی شما رو به رشد خواهد رفت. یادتان باشد که می خواهید کارکنان تان برای رسیدن به هدف تیم کار کنند، نه برای دریافت چک حقوق.
https://goo.gl/2G14vC
@iranagile
#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
تاکنون اتصال به دستگاههای بلوتوث تنها از طریق native apps امکان پذیر بود. Web Bluetooth API این امکان را برای web browser ها نیز فراهم آورده است. کتابخانههایی برای کار با این API ها در Nodeو Angular و Polymer نیز پیادهسازی شده است. لینک زیر توضیحاتی در مورد این API ها و کاربری آن ارايه میدهد.
https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/6Gq530efr9v
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/6Gq530efr9v
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۱۳۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
از مسایل مهم در هر نرم افزار وب، علاوه بر زیرساختهای شبکه و سیستم عامل، ایمنسازی نرم افزار میباشد. NWebSec یک کتابخانه مبتنی بر .NET میباشد که قابل استفاده در ASP.NET و ASP.NET Core نیز بوده و با استفاده از Security Headers و سایر روشها به امنیت بیشتر نرم افزارها کمک میکند.
https://docs.nwebsec.com/en/latest/nwebsec/getting-started.html
https://www.dotnetnoob.com/2012/09/security-through-http-response-headers.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/umRg30ehqWV
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
https://docs.nwebsec.com/en/latest/nwebsec/getting-started.html
https://www.dotnetnoob.com/2012/09/security-through-http-response-headers.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/umRg30ehqWV
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
Dotnetnoob
Security through HTTP response headers
Security headers in an HTTP response There are many things to consider when securing a web application but a definite "quick win" is to ...
#پست_مجدد این پست تا به حال بیش از ۱۵۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
کارایی و سرعت EntityFramework از گذشته تا به امروز از معضلاتی است که در پروژهها با آن مواجه میشویم. همهی راحتی و سرعتی که در زمان توسعه نرم افزار با استفاده از EF CodeFirst به دست میآوریم کمابیش برای بهبود سرعت اجرای queryهای وحشتناکی که بعضا توسط EF تولید میشود صرف میکنیم. ابزارهایی از قبیل Rhino Entity Framework Profiler و LINQ Pad در این راه یاری رسان بودهاند.اما ZZZ Projects راه حل بهتری ارایه دادهاند. آنها کتابخانههایی روی EF ارايه دادهاند که امکان عملیات CRUD و Merge بصورت batch با سرعت بالا را فراهم میآورند. همچنین امکان به روز رسانی بدون بارگزاری موجودیتها از دیتابیس و ارسال چند Query بصورت batch به دیتابیس و بسیاری امکانات دیگر که در لینکهای زیر توضیحات آن آمده است.
https://www.zzzprojects.com/
https://entityframework-extensions.net/
https://entityframework-plus.net/
همچنین از دیگر محدودیت های EF Codefirst عدم امکان استفاده از SQL Function ها و Stored Procedure هایی با خروجیهای متفاوت است. لینک زیر کتابخانه EntityFramework.Functions را معرفی میکند که به کمک آن با این محدودیت EF Codefirst خداحافظی میکنید.
https://weblogs.asp.net/Dixin/EntityFramework.Functions
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/3nz630ejcU6
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
https://www.zzzprojects.com/
https://entityframework-extensions.net/
https://entityframework-plus.net/
همچنین از دیگر محدودیت های EF Codefirst عدم امکان استفاده از SQL Function ها و Stored Procedure هایی با خروجیهای متفاوت است. لینک زیر کتابخانه EntityFramework.Functions را معرفی میکند که به کمک آن با این محدودیت EF Codefirst خداحافظی میکنید.
https://weblogs.asp.net/Dixin/EntityFramework.Functions
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/3nz630ejcU6
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
Zzzprojects
ZZZ Projects
ZZZ Projects | Adding value to the .NET Community
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. آشنایی با Code Map در Visual Studio
#visualstudio
https://t.iss.one/SoftwarePhilosophy/1041
۲. معرفی مفهوم Interaction Flows (فلسفه دیزاین)
https://t.iss.one/SoftwarePhilosophy/1042
۳. مدیران را اخراج کنید! (Iran Agile)
https://t.iss.one/SoftwarePhilosophy/1043
۴. اتصال به دستگاههای بلوتوث از طریق web browser به وسلیه Web Bluetooth API
#web #bluetooth
https://t.iss.one/SoftwarePhilosophy/1045
۵. ایمنسازی نرم افزار در دات نت به وسیله کتابخانه NWebSec
#security #dotnet
https://t.iss.one/SoftwarePhilosophy/1047
۶. چند راه حل برای افزایش کارایی و سرعت EntityFramework
#dotnet #entityframework #performance
https://t.iss.one/SoftwarePhilosophy/1049
ـــــــــــ
@SoftwarePhilosophy
۱. آشنایی با Code Map در Visual Studio
#visualstudio
https://t.iss.one/SoftwarePhilosophy/1041
۲. معرفی مفهوم Interaction Flows (فلسفه دیزاین)
https://t.iss.one/SoftwarePhilosophy/1042
۳. مدیران را اخراج کنید! (Iran Agile)
https://t.iss.one/SoftwarePhilosophy/1043
۴. اتصال به دستگاههای بلوتوث از طریق web browser به وسلیه Web Bluetooth API
#web #bluetooth
https://t.iss.one/SoftwarePhilosophy/1045
۵. ایمنسازی نرم افزار در دات نت به وسیله کتابخانه NWebSec
#security #dotnet
https://t.iss.one/SoftwarePhilosophy/1047
۶. چند راه حل برای افزایش کارایی و سرعت EntityFramework
#dotnet #entityframework #performance
https://t.iss.one/SoftwarePhilosophy/1049
ـــــــــــ
@SoftwarePhilosophy
برنامهنویسان NASA یکی از چالشیترین کارهای برنامهنویسی در جهان را دارند. عمده برنامههایی که آنها مینویسند بسیار حساس و اصطلاحا Mission Critical هستند.
برنامههایی که در ناسا نوشته میشوند نباید هیچ خطایی داشته باشند. کوچکترین خطا در برنامه باعث نابود شدن کل پروژه میشود (برای مثال سقوط شاتل یا نرسیدن به مقصد).
به همین دلیل روشی که آنها طبق آن کد نویسی میکنند میتواند بسیار آموزنده باشد.
در لینک زیر ۱۰ قانون حیاتی که تیم برنامهنویسی «آزمایشگاه نیروی متحرکه جت» یا Jet Propolution Labratovary از آن استفاده میکنند آمده است.
با اینکه این قوانین عمدتا برای زبان C تدوین شدهاند ولی بیشتر آنها در همه زبانها کاربرد دارند و خواندن این قوانین میتواند بسیار آموزنده باشد.
در انتها جملهای که ناسا در مورد این قوانین نوشته جمله جالبی است: «قوانین مانند کمربند ایمنی ماشین هستند. در ابتدا ممکن است خیلی راحت نباشند، ولی استفاده از آنها پس از مدتی طوری غریزی میشود که استفاده نکردنشان غیر قابل تصور خواهد بود»
https://fossbytes.com/nasa-coding-programming-rules-critical/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/UkMY30gO6Si
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
برنامههایی که در ناسا نوشته میشوند نباید هیچ خطایی داشته باشند. کوچکترین خطا در برنامه باعث نابود شدن کل پروژه میشود (برای مثال سقوط شاتل یا نرسیدن به مقصد).
به همین دلیل روشی که آنها طبق آن کد نویسی میکنند میتواند بسیار آموزنده باشد.
در لینک زیر ۱۰ قانون حیاتی که تیم برنامهنویسی «آزمایشگاه نیروی متحرکه جت» یا Jet Propolution Labratovary از آن استفاده میکنند آمده است.
با اینکه این قوانین عمدتا برای زبان C تدوین شدهاند ولی بیشتر آنها در همه زبانها کاربرد دارند و خواندن این قوانین میتواند بسیار آموزنده باشد.
در انتها جملهای که ناسا در مورد این قوانین نوشته جمله جالبی است: «قوانین مانند کمربند ایمنی ماشین هستند. در ابتدا ممکن است خیلی راحت نباشند، ولی استفاده از آنها پس از مدتی طوری غریزی میشود که استفاده نکردنشان غیر قابل تصور خواهد بود»
https://fossbytes.com/nasa-coding-programming-rules-critical/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/UkMY30gO6Si
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Fossbytes
How To Code Like The Top Programmers At NASA — 10 Critical Rules
Do you know how top programmers write mission-critical code at NASA? To make such code clearer, safer, and easier to understand, NASA's Jet Propulsion Laboratory has laid 10 rules for developing software.
Forwarded from فلسفه دیزاین
آیا محصول شما در جیب جا میشود؟
میدانستید تعریف Mark Zuckerberg از Facebook چیست؟
«چیزی که شما میتواند اسم کسی را در آن جستجو کرده و کلی اطلاعات درباره آن فرد بفهمید.»
یا تعریف Travis Kalanick، از Uber (سرویسی که اسنپ مشابه آن است)؟
«شما دکمهای را فشار میدهید و ۵ دقیقه بعد یک مرسدس میاد و شما رو به هرکجا بخواهید میبره.»
در تعریف Mark Zuckerberg از سرویسی که بنیانگذار آن است، هیچ نشانی از «شبکه اجتماعی» یا دهها ویژگی منحصربفرد دیگر Facebook نیست.
آیا شما هم میتوانید تعریفی در این حد خلاصه و در یک جمله از محصول خود داشته باشید؟ بسیاری از ما اصرار داریم که تمامی ویژگیهای آن را در توضیح محصول بیاوریم و در نتیجه باعث سردرگمی دیگران میشویم.
در تمامی ارائههای شفاهی، توضیحات متنی و هر نوع توضیحی که هرجایی قرار است از محصول شما عنوان شود، باید بتوان بهینهترین آنها را ارائه داد که رسالت اصلی آن سرویس یا واضحترین ایده بنیانگذار آن را بیان کند.
مقاله امروز راهنماییست استراتژیک برای این بتوانید به این توضیح یک جملهای از محصول خود برسید.
این مقاله را از دست ندهید
https://medium.dave-bailey.com/the-magic-formula-to-describe-a-product-in-one-sentence-175ce38619c7
(زمان حدودی مطالعه، ۷ دقیقه)
#بررسی #استراتژی #محصول
@Dexign فلسفه دیزاین
ــــــ
میدانستید تعریف Mark Zuckerberg از Facebook چیست؟
«چیزی که شما میتواند اسم کسی را در آن جستجو کرده و کلی اطلاعات درباره آن فرد بفهمید.»
یا تعریف Travis Kalanick، از Uber (سرویسی که اسنپ مشابه آن است)؟
«شما دکمهای را فشار میدهید و ۵ دقیقه بعد یک مرسدس میاد و شما رو به هرکجا بخواهید میبره.»
در تعریف Mark Zuckerberg از سرویسی که بنیانگذار آن است، هیچ نشانی از «شبکه اجتماعی» یا دهها ویژگی منحصربفرد دیگر Facebook نیست.
آیا شما هم میتوانید تعریفی در این حد خلاصه و در یک جمله از محصول خود داشته باشید؟ بسیاری از ما اصرار داریم که تمامی ویژگیهای آن را در توضیح محصول بیاوریم و در نتیجه باعث سردرگمی دیگران میشویم.
در تمامی ارائههای شفاهی، توضیحات متنی و هر نوع توضیحی که هرجایی قرار است از محصول شما عنوان شود، باید بتوان بهینهترین آنها را ارائه داد که رسالت اصلی آن سرویس یا واضحترین ایده بنیانگذار آن را بیان کند.
مقاله امروز راهنماییست استراتژیک برای این بتوانید به این توضیح یک جملهای از محصول خود برسید.
این مقاله را از دست ندهید
https://medium.dave-bailey.com/the-magic-formula-to-describe-a-product-in-one-sentence-175ce38619c7
(زمان حدودی مطالعه، ۷ دقیقه)
#بررسی #استراتژی #محصول
@Dexign فلسفه دیزاین
ــــــ
Medium
The Art of Writing One-Sentence Product Descriptions
A look back at early interviews with Facebook and Uber CEOs illustrates an ingenious way to communicate hard-to-describe products.
Forwarded from Iran Agile
⭕ چکلیست دراکر برای ارزیابی سازمان
پیتر دراکر برای مدیران سازمانهای نوین و دانش-محور نام مهمی است. او کسی است که ده ها سال پیش، خیلی قبل از آنکه چیزی به عنوان فن آوری اطلاعات پا به عرصه وجود بگذارد، پیش بینی کرده بود که نسل آینده ی نیروی کار با تکیه بر اطلاعات ظهور خواهد کرد. یک سال از پایان جنگ جهانی دوم نگذشته بود که او در کتابش اصل عدم تمرکز و جنبه انسانی و اجتماعی سازمان ها را برجسته می کند. چیزهایی که شاید هنوز هم در ذهن بسیاری از مدیران ارشد سازمان ها مفاهیمی دور از ذهن و انقلابی به شمار می آیند.
نشریه Build اخیرا چک لیستی از مهمترین ویژگی های سازمان های مطلوب از دید دراکر منتشر کرده است.با مقایسه ی وضع جاری سازمان خود با این چک لیست، می توانید تصور کنید اگر پیتر دراکر پا به سازمان شما می گذاشت آن را چطور ارزیابی می کرد.
شرکت شما دراکر-گونه است اگر شما:
ماموریتی مشخص و قوی دارید و پاسخی قانع کننده به این سوال دشوار که: “ما در چه کسب و کاری هستیم؟”
همیشه به خاطر دارید که “همیشه فقط یک تعریف معتبر از هدف کسب و کار وجود دارد: ایجاد یک مشتری” در عین حال که می پذیرید “کیفیت یک محصول یا سرویس چیزی نیست که تامین کننده تویش می گذارد. بلکه چیزی است که مشتری از آن بیرون می آورد، و برایش حاضر است پول بدهد”.
مسئولیت و پاسخگویی را تا جایی که می شود در عمق سازمان به پایین می برید. به این استراتژی پایه ی ارتباطی عمل می کنید: به پایین گوش کن، با بالا صحبت کن.
این حقیقت را در آغوش می کشید که سازمان اشخاص را می سازد (یه به آنها کمک می کند که رشد کنند و یا آنها را از رشد باز می دارد) و بنابراین شما از هرچه می توانید برای کمک به رشد آنها دریغ نمی کنید.
نوآوری را (که یعنی تغییری که بعد جدیدی از کارایی را ایجاد می کند) به عنوان مسئولیت هر کسی در سازمان می دانید، نه فقط واحد تحقیق و توسعه.
به طور منظم چیزهایی را رها می کنید (محصولات، سیاست ها، روشها) که یا دیگر موثر نیستند و یا نسبت به فرصت های آینده، منابع زیادی را مصرف می کنند.
چیزهایی را که می شود اندازه گرفت اندازه می گیرید و چیزهایی را که نمی شود، زیر نظر دارید. این را هم قبول دارید که نیت خوب جایگزین نتایج و عملکرد نیست.
افق بلند مدت را در نظر دارید (نه فقط کوتاه مدت را) و به خاطر می سپارید که “تحلیلگران بازار سرمایه اعتقاد دارند شرکت ها پول می ساند، در حالی که شرکت ها کفش می سازند”.
با یک مجموعه ارزش های پایه زندگی می کنید، با این اعتقاد که سازمان به ارزش نیاز دارد، همانطور که بدن انسان به ویتامین نیاز دارد.
مسئولیت اجتماعی خود را به نمایش می گذارید، نه فقط با بخشیدن پول به خیریه ها، بلکه با درک اینکه سازمان نسبت به هر چیز و هر کسی که با آن در ارتباط است مسئول است.
@iranagile
https://goo.gl/v3iTxv
پیتر دراکر برای مدیران سازمانهای نوین و دانش-محور نام مهمی است. او کسی است که ده ها سال پیش، خیلی قبل از آنکه چیزی به عنوان فن آوری اطلاعات پا به عرصه وجود بگذارد، پیش بینی کرده بود که نسل آینده ی نیروی کار با تکیه بر اطلاعات ظهور خواهد کرد. یک سال از پایان جنگ جهانی دوم نگذشته بود که او در کتابش اصل عدم تمرکز و جنبه انسانی و اجتماعی سازمان ها را برجسته می کند. چیزهایی که شاید هنوز هم در ذهن بسیاری از مدیران ارشد سازمان ها مفاهیمی دور از ذهن و انقلابی به شمار می آیند.
نشریه Build اخیرا چک لیستی از مهمترین ویژگی های سازمان های مطلوب از دید دراکر منتشر کرده است.با مقایسه ی وضع جاری سازمان خود با این چک لیست، می توانید تصور کنید اگر پیتر دراکر پا به سازمان شما می گذاشت آن را چطور ارزیابی می کرد.
شرکت شما دراکر-گونه است اگر شما:
ماموریتی مشخص و قوی دارید و پاسخی قانع کننده به این سوال دشوار که: “ما در چه کسب و کاری هستیم؟”
همیشه به خاطر دارید که “همیشه فقط یک تعریف معتبر از هدف کسب و کار وجود دارد: ایجاد یک مشتری” در عین حال که می پذیرید “کیفیت یک محصول یا سرویس چیزی نیست که تامین کننده تویش می گذارد. بلکه چیزی است که مشتری از آن بیرون می آورد، و برایش حاضر است پول بدهد”.
مسئولیت و پاسخگویی را تا جایی که می شود در عمق سازمان به پایین می برید. به این استراتژی پایه ی ارتباطی عمل می کنید: به پایین گوش کن، با بالا صحبت کن.
این حقیقت را در آغوش می کشید که سازمان اشخاص را می سازد (یه به آنها کمک می کند که رشد کنند و یا آنها را از رشد باز می دارد) و بنابراین شما از هرچه می توانید برای کمک به رشد آنها دریغ نمی کنید.
نوآوری را (که یعنی تغییری که بعد جدیدی از کارایی را ایجاد می کند) به عنوان مسئولیت هر کسی در سازمان می دانید، نه فقط واحد تحقیق و توسعه.
به طور منظم چیزهایی را رها می کنید (محصولات، سیاست ها، روشها) که یا دیگر موثر نیستند و یا نسبت به فرصت های آینده، منابع زیادی را مصرف می کنند.
چیزهایی را که می شود اندازه گرفت اندازه می گیرید و چیزهایی را که نمی شود، زیر نظر دارید. این را هم قبول دارید که نیت خوب جایگزین نتایج و عملکرد نیست.
افق بلند مدت را در نظر دارید (نه فقط کوتاه مدت را) و به خاطر می سپارید که “تحلیلگران بازار سرمایه اعتقاد دارند شرکت ها پول می ساند، در حالی که شرکت ها کفش می سازند”.
با یک مجموعه ارزش های پایه زندگی می کنید، با این اعتقاد که سازمان به ارزش نیاز دارد، همانطور که بدن انسان به ویتامین نیاز دارد.
مسئولیت اجتماعی خود را به نمایش می گذارید، نه فقط با بخشیدن پول به خیریه ها، بلکه با درک اینکه سازمان نسبت به هر چیز و هر کسی که با آن در ارتباط است مسئول است.
@iranagile
https://goo.gl/v3iTxv
#پست_مجدد این پست تا به حال بیش از ۱۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.