نوشته های Mostafa Fallah - مصطفی فلاح

اضافه کردن Issue در Jira با استفاده از سرویسهای Rest

Mostafa Fallah - مصطفی فلاح — Sun, 23 Mar 2025 09:56:06 +0330

جیرا ، ابزار دوست داشتنی با امکانات بسیار قبلا پستی در خصوص دریافت داده ها (در خصوص دریافت ورک لاگ ها که، به عنوان میزان صرف وقت روی تسکها ثبت میشوند) نوشتم که از اینجا در دسترس هست. این پست اما در مورد این هست که بتونیم تسکهایی را بدون نیاز به ورود در پنل جیرا، ثبت کنیم. مزایای این روش :اضافه کردن تسک خارج از جیرا و عدم نیاز به داشتن دانش برای کار با پنل جیرااضافه کردن تسک ها از طریق برنامه های پشتیبانی مختلف، برای مثال بات های تلگرام یا ...اضافه کردن تسکها از طریق نرم افزارهای پشتیبانی اختصاصی خود سازمان (برای مثال در نرم افزار تیکتینگ سازمان میتوان این API را فراخوانی کرد)اضافه کردن تسکها توسط کاربرهایی غیر از ادمین پروژه و ادمین سیستممن این فراخوانی API رو با کمک یک برنامه Console ساده و با زبان C# پیاده سازی کردم و اسم این برنامه رو Jira Issue Uploader 😊گذاشتم و در گیت هاب قرار دادم تا در صورت نیاز بقیه هم بتونن استفاده کنن.البته میدونید که در جیرا، بخشی وجود داره که شما میتونید تسکها رو به صورت bulk و با کمک یک فایل CSV وارد کنید و این روش برای ثبت انبوهی از Issue ها استفاده میشه. کاری که در این برنامه آزمایشی میکنیم، مشابه Importer خود جیرا هست و تسکها رو از یک فایل CSV میخونیم و با کمک API زیر و به روش بسیار ساده در جیرا اضافه میکنیم. این کد در واقع نمونه ای از فراخوانی API هست که شما میتونید در باتهای مختلف یا برنامه های تیکتینگ و پشتیبانی خودتون استفاده کنیدالف ) لاگین در جیراclient.BaseAddress = new Uri(string.IsNullOrEmpty(JIRA_DOMAIN) ? "" : JIRA_DOMAIN);var authToken = Convert.ToBase64String(Encoding.ASCII.GetBytes($"{username}:{apiToken}"));client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", authToken);client.DefaultRequestHeaders.Add("Accept", "application/json");ب ) خواندن از یک فایل CSV using var reader = new StreamReader(filePath); using var csv = new CsvReader(reader, CultureInfo.InvariantCulture); return new List(csv.GetRecords());ج ) پر کردن Object مورد نیاز برای ارسال به سرویسvar issueData = new { fields = new { project = new { key = issue.ProjectKey }, summary = issue.IssueSummary, description = issue.Description, issuetype = new { name = issue.IssueType }, assignee = new { name = issue.Assignee }, } };د ) ثبت در جیرا با کمک API var jsonContent = new StringContent(JsonSerializer.Serialize(issueData), Encoding.UTF8, "application/json"); HttpResponseMessage response = await client.PostAsync("/rest/api/2/issue", jsonContent);

دریافت داده ها از Jira با استفاده از سرویسهای Rest

Mostafa Fallah - مصطفی فلاح — Fri, 21 Feb 2025 01:15:55 +0330

جیرا ، ابزار دوست داشتنی با امکانات بسیارجیرا یکی از جذاب ترین و کاربردی ترین ابزار مدیریت پروژه است که من بر اساس تجارب خودم، در هر شرکتی که فعالیت میکنم ، در کنار نرم افزارهای دیگه، ، اون رو پیشنهاد میدم. یکی از بهترین بخشهای جیرا، امکان ثبت لاگ ورک برای Issue های مختلف است. این ورک لاگ میتونه با ابزار های دیگه مثل Time Tracker و ... هم ترکیب بشه و افراد به راحتی میزان وقتی که روی هر Issue میزارن رو ثبت کنند. در پایان یک اسپرینت یا در پایان ماه، ما میتونیم لاگ ورک های ثبت شده افراد رو جمع آوری کنیم. با این تصور که روی هر Issue ممکن است بیش از یک لاگ ورک و حتی برای بیشتر از یک نفر، ثبت شده باشد. برای جمع آوری داده های ورک لاگ به منظور بالا، باید از پلاگینهای موجود در Market Place شرکت Atlassian استفاده کرد (که رایگان هم نیست و البته که خرید این پلاگینها هم دردسرهای خودش رو داره چون مسائل تحریمی و همچنین نسخه جیرا در این مورد خیلی مهمه) یا از ابزار جانبی دیگری بهره برد. یکی از اون ابزارهای جانبی استفاده از افزونه ای هست که در گوگل شیت برای این موضوع وجود داره. افزونه های این چنینی با دسترسی به داده های شما قابل استفاده خواهند بود که از لحاظ امنیتی میتونه خطر ساز بشه. پس راه حل چیه ؟ راه حل، استفاده از Rest API تعبیه شده در خود جیرا هست. من با استفاده از API های خود جیرا، خروجی ورک لاگ رو در زبان C# و در قالب یک کد بسیار ساده پروژه Console پیاده سازی کردم که اسم این برنامه JiraWorklog Fetcher 😄 گذاشتم و کد تولیدی این بخش رو در گیت هاب قرار دادم تا در صورت نیاز بقیه هم بتونن استفاده کنن. بخشهای اصلی این پروژه : الف ) لاگین در جیرا client.BaseAddress = new Uri(JIRA_DOMAIN); var authToken = Convert.ToBase64String(Encoding.ASCII.GetBytes($"{username}:{apiToken}")); client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", authToken);ب ) جستجوی Issue ها با استفاده از JQL ورودیstring requestBody = JsonSerializer.Serialize(new { jql = jql, fields = new[] { "key" }, maxResults = 200 }); var content = new StringContent(requestBody, Encoding.UTF8, "application/json"); HttpResponseMessage response = await client.PostAsync("/rest/api/2/search", content).ConfigureAwait(false);ج ) دریافت فیلد Assignee (شخصی که به تسک اساین شده است)var issueResponse = await client.GetAsync($"/rest/api/2/issue/{issueKey}?fields=assignee").ConfigureAwait(false);د ) دریافت ورک لاگ های هر تسک var worklogResponse = await client.GetAsync($"/rest/api/2/issue/{issueKey}/worklog").ConfigureAwait(false);ه ) دریافت عنوان تسک var summaryResponse = await client.GetAsync($"/rest/api/2/issue/{issueKey}?fields=summary").ConfigureAwait(false); در نهایت همه این مقادیر به صورت فایل CSV تولید میشود.

مساله Floating Numbers در زبانهای برنامه نویسی

Mostafa Fallah - مصطفی فلاح — Mon, 22 Feb 2021 01:07:58 +0330

مقدار جمع این دو عدد 0.3 نمیشود !این یه مساله قدیمی هست که خیلی از برنامه نویسها ممکنه باهاش مواجه شده باشند. قضیه این هست که نتایج عملیات محاسباتی اونها گاهی اشتباه میشه، مخصوصا وقتی از اعداد اعشاری در محاسباتشون استفاده میکنن و در این مواقع با خودشون میگن : یعنی چی؟ چرا شماره های من جمع نمی شه؟ مثلا : 0.1 + 0.2 ، ولی نتیجه این شده : 0.30000000000000004خب برای این که این مساله رو دقیقا متوجه بشیم، باید به سوالات زیر جواب بدیم :1 - چرا حاصل جمع اعداد من مانند 0.1 + 0.2 ، 0.3 نمیشود و در عوض من یک نتیجه عجیب مانند 0.3000000000000000004 دریافت می کنم؟زیرا کامپیوتر ها از فرمتی خاص (binary floating-point) استفاده می کنند که نمی تواند عددی مانند 0.1 ، 0.2 یا 0.3 را به طور دقیق ارائه کند. در واقع هنگامی که کد شما کامپایل یا تفسیر می شود ، مقدار "0.1" شما از قبل به نزدیکترین عدد در آن فرمت (مثلا 0.0999999) گرد شده ،که منجر به یک (خطای گرد شدن) حتی قبل از محاسبه می شود. فرمت Floating Point : از آنجا که حافظه کامپیوتر محدود است ، صرف نظر از اینکه از کسرهای باینری استفاده می کنید یا از کسر اعشاری ، نمی توانید اعداد را با دقت نامحدود ذخیره کنید: پس در واقع در بعضی مواقع باید بخشی از این عدد را حذف کنید.خطاهای گرد شدن : از آنجا که اعداد ممیز شناور (floating-point) دارای تعداد محدودی رقم هستند ، نمی توانند تمام اعداد واقعی را به طور دقیق نشان دهند: به عبارتی وقتی تعداد رقم بیشتری از حد مجاز قالب وجود داشته باشد، تعداد باقیمانده حذف می شود و در نتیجه عدد گرد می شود.2 - چرا کامپیوتر ها از چنین سیستم احمقانه ای استفاده می کنند؟احمقانه نیست ، فقط متفاوت است. متغیرهای اعشاری نمی توانند عددی مانند 1.3 را به درستی ارائه کنند، بنابراین شما باید مقدار را گرد کنید به مقداری مانند 0.33 ، و شما قطعا انتظار ندارید که حاصل جمع 0.33 + 0.33 + 0.33 + 0.33 ، 1 بشود !! توضیح تکمیلی اینکه، کامپیوترها از اعداد باینری استفاده می کنند زیرا در برخورد با آنها سریعتر عمل می کنند و از آنجایی که اعدادی که با آنها کار می کنید عموما گرد نیستند، خطای کوچک در رقم اعشاری هفدهم اصلاً مهم نیست.برای جلوگیری از این مشکل چه کاری می توانم انجام دهم؟این به نوع محاسبات شما بستگی دارد.اگر واقعاً برای جمع آوری دقیقاً به نتایج خود احتیاج دارید ، مخصوصاً وقتی با پول کار می کنید: از یک نوع داده اعشاری ویژه استفاده کنید. اگر فقط نمی خواهید همه آن اعشار اعشاری را ببینید: به سادگی هنگام نمایش نتیجه خود را به تعداد ثابت رقم اعشار گرد کنید.اگر هیچ نوع داده اعشاری در دسترس ندارید ، یک گزینه جایگزین کار با عدد صحیح است ، به عنوان مثال محاسبات پول را کاملاً در ریال انجام دهید. اچرا سایر محاسبات مانند 0.1 + 0.4 به درستی کار می کنند؟در این صورت ، نتیجه (0.5) را می توان دقیقاً به عنوان یک عدد ممیز شناور نشان داد و این امکان وجود دارد که خطاهای گرد شدن در عددهای ورودی یکدیگر را پوشش دهند - اما لزوماً نمی توان به آن اعتماد کرد (به عنوان مثال وقتی این دو ابتدا اعداد در نمایش های مختلف با اندازه متفاوت بخش شناور ذخیره می شوند ، ممکن است خطاهای گرد شدن یکدیگر را جبران نکنند).در موارد دیگر مانند 0.1 + 0.3 ، نتیجه در واقع 0.4 نیست ، اما به اندازه کافی به مقدار 0.4 نزدیک است. و در نتیجه بسیاری از زبانها به جای تبدیل نتیجه واقعی به نزدیکترین کسر اعشاری ،خود آن عدد را نمایش می دهند.منبع این مطلب سایت https://floating-point-gui.de هست که توی همین سایت برای زبانهای سی شارپ، جاوا اسکریپت و ... راه حلهایی برای این مساله گفته شده.

یک شیفتگی پرهیاهو و بی معنی، جنبش #NoEstimates

Mostafa Fallah - مصطفی فلاح — Wed, 14 Oct 2020 00:15:51 +0330

جنبش No Estimateمطلب زیر، خلاصه ای از پست Maarten Dalmijn است که در Medium منتشر شده و نقدی بر جنبش #NoEstiames می باشد. من بر اساس تجربه شخصی با آقای مارتین موافق هستم و تخمین تسک و اسپرینت مهمترین بخش کار مدیریت پروژه هست (البته بعد از هنر کامیونیکیت)آنچه باید بدانید : اجایل (Agile) : بدون اینکه بدونیم اجایل چیست، این مطلب رو نمیتونیم بفهمیم. مطلب خلاصه و مفیدی اینجا هست.استوری پوینت (Story Point) : یک روش خرد جمعی برای تخمین ساعت هست که هر Point در واقع معادل مقدار ساعت کار روی یک موضوع مشخص می باشد. به عبارتی یک نسبت پایه برای یک موضوع در نظر گرفته می شود و برای آن 1 Point در نظر میگیریم. مثلا تولید یک صفحه CRUD،دو روز یا به عباریتی 15 ساعت طول میکشد. حال برای فرمی با 3 Crud که به صورت Tablular تولید می شود، مثلا 3 پواینت در نظر گرفته می شود. البته ما الزامی در این مدل تخمین زمانی نداریم و من هم در اینجا صرفا برای آشنا شدن با این عبارت توضیح دادم. در این روزها از جنبش #NoEstimates بیشتر از گذشته صحبت می شود و من می خواستم دلیل این جذابیت را بدانم، برای همین تیم من 3 ماه این مساله را مورد آزمایش قرار داد، ودر نهایت به این نتیجه رسیدم که چیزی که تیم NoEstimate میخواهند آن را باور کنیم در عمل به دست نمی آید. قبل از اینکه در مورد مزایا و معایب #NoEstimates بحث کنیم ، بیایید ابتدا در مورد استدلال جنبش بحث کنیم.دلایل جنبش برای عدم استفاده از تخمین زمانی :تخمین دقیق امکان پذیر نیست.برآوردها می توانند فشار غیر ضروری به تیم وارد کنند.برآورد زمانی یک اتلاف وقت است ، بنابراین بهتر است تا آنجا که ممکن است وقت کمتری برای آن صرف کنید.اینها دلایل جنبش NoEstimate هستند که البته من هم با آنها موافق هستم. برآورد شما در نهایت صرفا برآورد هست ولی مهمتر از اون، این هست که کار به چه صورتی انجام خواهد شد. این نکته هم درسته که تلاش برای رسیدن به تخمین اولیه و نرسیدن به ددلاین،منجر به فشار بیش از حد به تیم شما خواهد شد. نکته بعدی هم این هست که شما تا زمانی که پیاده سازی رو شروع نکنید، شناخت واقعی از حجم کار نخواهید داشت. و در نهایت ، تلاش برای انجام کار طی برآورد زمانی، در صورتی که این برآوردها اشتباه باشد، فشار روانی زیادی به تیم وارد میکنه و قطعا بخشی از کار حذف میشود و البته در طولانی مدت، منجر به پیشرفت کمتر به نسبت هزینه بیشتر می شود.اما !اما من فکر میکنم، این برآوردهای زمانی نیست که این این فشار را به تیم وارد میکند، بلکه روشی که برای تشخیص، ابلاغ و درک این برآورد ها استفاده شده، باعث ایجاد این مشکل می شود. منظورم این است که وقتی در حین کار واقعی، متوجه این میشویم که برآوردهای زمانی رو باید اصلاح کنیم، این کار باید حتما انجام بشه، یعنی برآوردهای زمانی اولیه باید مرتبا بر روی تایم لاین (بر اساس داده های جدید ) به روز رسانی بشود. اما چرا این کار انجام نمیشود ؟ چون تیم های اسکرام به تخمین ها و جدول زمانی اولیه متکی هستند و علت این موضوع هم فشار خارجی (مشتری یا مدیران بالاتر یا ... ) می باشد ! (پاسخ به دلیل شماره دو جنبش)و من قبول ندارم که راه حل این مساله کنار گذاشتن برآورد زمانی است و فکر میکنم نکته ای در این مساله پنهان شده است که اون نکته این هست :جنبش #NoEstimates خود در واقع نوعی برآورد زمانی است و به صورت خلاصه معنی #NoEstimates این است که شما برآورد رو انجام میدید اما به شکل متفاوتی .چرا #NoEstimates در واقع نوعی برآورد کردن است؟در واقع در کار با اسکرام، تخمین و برآورد زمانی یک مساله کاملا اجباری است. اگر در این مورد تردید دارید ، آنچه در راهنمای Scrum نوشته شده است را میتوانید ببینید :کلیه آیتمهای بک لاگ محصول دارای این ویژگی ها باید باشند : شرح، ترتیب ، برآورد و ارزش . Scrum Guide ، نوامبر 2017پس بک لاگهای محصول در Scrum باید برآورد داشته باشند. این برآورد یا باید مانند زمانی که از Story Points استفاده می کنیم صریح باشد یا یک برآورد ضمنی ، با بخش کردن آیتمهای کاری به بخش های کوچکتر (Slicing) ، در هر صورت در یک Sprint جای خواهند گرفت. به عبارتی مهم نیست که از چه روشی استفاده می کنید و تیم توسعه باید سوال زیر را پاسخ دهد: آیا ما اعتقاد داریم که در اسپرینت جای می گیرد؟ پاسخ به این سوال بدین معنی است که برآورد انجام شده است !با مقایسه کردن #NoEstimates با Story Points می توانم این را بگویم : برآورد با Story Points معمولاً به این معنی است که شما روی یک عدد از یک دنباله فیبوناچی با هم توافق می کنید:1 2 3 5 8 13 20 40 100وقتی #NoEstimates را انجام می دهید ، این توالی به دو عدد تقلیل می یابد:1: در یک بازه زمانی قابل اجرا قرار میگیرد ! 0: در Sprint نمی گنجد ! یعنی : یا در یک Sprint جا می گیرد یا جا نمیگیرد !وقتی تیم شما مدل برآورد زمانی اول را انجام می هد، طبق روال عادی، افراد تیم معمولاً مکالمه بیشتری دارند تا ببینند آیا می توان برای بهبود جریان و پیش بینی زمان انجام کار، کارها را کوچک تر کرد و این مکالمه هست که کمک میکند تا بتوان تصمیم بهتری گرفت حال آنکه، در #NoEstimates انجام این کار ضروری نیست زیرا اگر پاسخ 0 باشد (یعنی در اسپرینت قرار نمیگیرد) افراد تیم باید صحبت کنند تا ببیند چه کاری می توان برای کوچکتر کردن آن انجام داد. خلاصه این بخش این می شود که در Estimate افراد برای بهبود کار، مکالمه میکنند، ولی در NoEstimate، افراد برای کاری که در اسپرینت قرار نخواهد گرفت برای کوچکتر کردن صحبت میکنند.اگر با نتیجه گیری من موافق باشید که #NoEstimates هنوز نوعی تخمین است، سوالی که مطرح می شود این است که استفاده نکردن از Story Points و استفاده از #NoEstimates به جای آن چه تاثیری دارد؟با #NoEstimates میزان زمانی که شما برای تخمین می زنید کاهش چشمگیری نخواهد داشتدر تیم های اسکرام ما 2 ساعت در هر جلسه وقت صرف می کنیم. در طول این زمان ، 4 مرحله را دنبال می کنیم:موارد باقیمانده محصول را به عنوان یک تیم اسکرام با هم مینویسیم. صاحب محصول در مورد چرایی و چه چیزی توضیح می دهد و بحث می کند.ما در این جلسه در مورد چگونگی ساخت آن به صورت کلی بحث می کنیم.برای این موضوع کافی است تا ما از درک منطقی کارهایی که باید انجام دهیم مطمئن باشیم. ما با هم همکاری می کنیم تا دریابیم که چگونه می توان مورد Backlog را تقسیم کرد ، بنابراین در کمترین حالت ممکن قطعه قطعه می شود ، در حالی که محصول مورد نظر هم تولید می شود.اگر کارهای Backlog به اندازه کافی واضح باشد ، ما برآورد را انجام میدهیم و در غیر اینصورت برآوردی برای آن صورت نمیگیرد و قاعدتا کار هم انجام نمی شود.هنگامی که ما شروع به انجام #NoEstimates کردیم ، مرحله 4 را با این سوال ساده جایگزین کردیم: آیا در Sprint جای می گیرد؟ اگر بله ، پس آماده تحویل گرفتن است. درغیر اینصورت ، کار مورد نظر در Backlog رابه بخشهای کوچکتر تقسیم میکنیم. پاسخ به این سوال راحت تر است و قطعاً زمان کمتری نیز می برد.در حالتی که برآورد ما بدون Story Points انجام می شود، در حدود 10 دقیقه صرفه جویی می کنیم. این تقریباً به همان اندازه زمان برگزار نکردن Daily Scrum است. آیا این مقدار وقت اضافی که صرفه جویی خواهید کرد واقعا ارزش این همه هیاهوی اطراف #NoEstimates را دارد؟ما می توانیم توافق کنیم که شما با #NoEstimates کمی وقت صرفه جویی کنید ، اما چه چیزی را از دست می دهید و آیا این ارزش آن را دارد؟و #NoEstimates با نکات منفی همراه استوقتی از #NoEstimates استفاده می کنید ، اطلاعاتی را که هنگام استفاده از Story Points یا شکل دیگری از تخمین ارائه می شود از دست می دهید:در درک کارهایی که انجام می شوداطلاعات کمتری به دست می آورید.شما این ریسک را میپذیرید که بخشی از وابستگیهای اجزای پروژه را متوجه نشوید.نتیجه گیری :ارزشمندترین قسمت مکالمات برآورد، درباره خود برآورد زمانی نیست ، بلکه ایجاد درک مشترک بهتر است.برآورد یک بررسی عقلانی سریع است تا اطمینان حاصل شود که همه در یک درک یکسان از آنچه یک تسک به همراه دارد ، هستند. این اطلاعات هنگام استفاده از #NoEstimates از دست می رود. ضمنا لینک اولیه این مطلب از کانال خوب Iran Agile به دست اومده که در صورتی که علاقه مند به این موضوعات هستید مطالب خوبی رو پیشنهاد میکنه

مدیر پروژه هنرمند (بخش اول)

Mostafa Fallah - مصطفی فلاح — Sat, 22 Jun 2019 08:43:26 +0430

علاقه مندی به کتاب و کتابخونی در من، همون چیزیه که باعث میشه اطرافیانم بدونن بهترین هدیه برای من، کتاب هست و البته بعضی وقتها هم لطف میکنن و بدون دلیل سورپرایز میکنن. یکی از این سورپرایزها کتابی بود که 1 سال پیش به من هدیه شد به اسم مدیریت پروژه (۲۴ شیوه برای اداره کردن هر پروژه ای) از گری هیرکنز با ترجمه مامک بهارزاده. کتاب کوچک و خلاصه شده ای که به نظر نمیومد چیز خاصی داشته باشه ولی نکات مفیدی داشت که باعث شد من در حین خوندنش خاطرات خودم رو مرور کنم! خاطرات تلخ و شیرین و گاهی عبرت آموز از مدیریتِ پروژه هایی که داشتم. پس تصمیم گرفتم که در این پست و پستهای بعدی از همین سری، تعدادی نکته مفید از این کتاب را به صورت خلاصه و همراه با تجربیات خودم براتون بنویسم.مقدمهواقعیت این هست که مدیران پروژه های بزرگ هم وقتی پای حرفشون میشینید براتون میگن که پروژه های اولشون، واقعا چیز خوبی از آب در نیومده. در واقع مدیریت پروژه کار سخت و پرتنش و پر آشوبی هست که باید صبر داشته باشید، مایوس نشید و یاد بگیرید و ادامه بدهید! جالبه که بدونید مشکلات میان فردی و رفتاری، غالبا علت اصلی شکست پروژه ها هستند.تعریف اصلی این کتاب از مدیریت پروژه ، عبارتی هست که در زیر اومدهمدیریت پروژه هم یک علم هست و هم یک هنر بخش علمی آن شامل کاوش ها، کارها، استفاده از ابزار، تعریف کار، هماهنگی ها، مستندات سازی و سایر موارد است. اما بخش هنری آن، شامل پرورش قوه تشخیص و فراگیری چگونگی هدایت افراد است.عاشق جزئیات باشید وی اسیر نشوید. این چیزی بود که برای من، در سن 22 سالگی و مدیریت یک پروژه نسبتا بزرگ اتفاق افتاد و 2 سال طول کشید تا فهمیدم ، جزئیات بی اهمیت بود و کلیات چیزی بود که توجه میکردم و 24 سالگی دچار نوعی افسردگی و ناتوانی شده بودم. اما امروز میدونم که جزئیات همون چیزی هست که تصمیمات بیشمار من در حین مدیریت پروژه را دقیقتر و بهتر میکنه.نکته اول هنر مدیریت پروژه، تماماً به معنی انجام کارها از طریق دیگران است. به عبارتی شما باید نخست وزیر باشید و بتونید تقسیم کار رو انجام بدید.عبارت بالا بسیار ساده و شفاف بیان شده ولی آیا واقعا معنی این کار این است که کارها رو به دوش دیگران بگذارید؟ جواب قطعا خیر است. حالا بیاین ببینیم برای اینکه این هنر را داشته باشیم تا بهترین تقسیم کار رو انجام بدیم، چه چیزهایی باید بدونیم ؟ اول اینکه خودتون رو تقویت کنید ! 1 - تقویت ارتباط شفاهی : این مورد بسیار مهم و کلیدی است. تصور کنید مدیری هستید که وقتی میخاین شنونده باشید، یا حتی در مورد تسکی صحبت کنید، نتونید ارتباط شفاهی خوبی داشته باشید، نتونید خوب صحبت کنید؟ حوصله افراد تیم سر میره و قاعدتا شما مدیر موثری نخواهید بود.2 - تقویت ارتباط کتبی : تصور کنید مدیری هستید که یه نامه ساده احوالپرسی به هم تیمیتون یا یه پیام تشکر رو نتونید درست بفرستید. حتما میدونید که متون نوشتاری در ارتباط بسیار مستعد سوتفاهم هست، پس اگر واقعا در این زمینه قدرت لازم رو ندارید، یا شنونده هنوز با شخصیت شما خیلی آشنا نیست، از انجام این ارتباط (حداقل در روزهای اولیه) خودداری کنید.3 - یاد بگیریم چگونه مذاکره کنیم : قاعدتا در مواردی مثل خزش دامنه پروژه (این مطلب و این مطلب تیم کمپ خیلی خوبه) که توسط کارفرما یا حتی توسعه دهنده خوب و قوی، (که قصد داره کار جدیدی رو انجام بده تا تواناییش رو بیش از پیش به شما نشون بده)، شما باید مذاکره رو به نحوی پیش ببرید که هم توسعه دهنده شما سرخورده نشه، هم کارتون عقب نیفته و پروژه سر وقت برسه. چیزی که شما در واقع لازم دارید، مذاکره مذاکره و در نهایت مذاکره هست. شاید این قسمت مهمترین قسمت کار شما باشه.دوم اینکه موثر باشید1 - برای موثر بودن باید توانایی مدیریت پروژه خود را افزایش دهید، مثلا ابزارها رو بهتر بشناسید، روشها رو بدونید، نقاط ضعف ابزارها و روشها رو درک کنید و سعی کنید با تجربیاتتون این ابزارها رو مرور کنید. مثلا در پروژه ای در شرکت قبلی، اگر به جای تسکولو از جیرا استفاده کرده بودید چه عیبی داشت ؟ 2 - سعی کنید برای تیم یک سرپرست یا پیشکسوت باشید و برای اینکار باید مهارتهای میان فردی خودتون رو افزایش بدید. به عبارتی در شرایطی قرار خواهید گرفت که از تخصص لازم برای همه قسمتهای مختلف برخوردار نیستید. این به این معنی هست که شما باید بتونید با افرادی از جاهای مختلف ارتباط کافی داشته باشید. یک تجربه تلخ در همین باره، مربوط به زمانی بود که وارد شرکتی شده بودم که تیم قبلی نرم افزار با تیم شبکه به شدت دچار اختلاف و مشکل بودند و طبیعتا همون مشکلات به من هم منتقل شد! متاسفانه کاری از دست من بر نیومد و روزهای ابتدایی خیلی سختی داشتم. نهایتا برای حل اختلاف افراد مرتبط با تیم یک جلسه گروهی گذاشتم و ازشون خواستم به جای بحث کردن، به من کمک کنن و ممنون و مدیونشون هم هستم! با مدیر تیم شبکه خیلی هم رفیق شدیم. مشکل تقریبا حل شد و خیلی ازکارهای مربوط به شبکه رو حتی خود تیم شبکه برای ما انجام میداد، مثلا راه اندازی سرورهای Test bed به صورت کامل انجام میشد، نرم افزارها نصب میشد و بعد از اون ما Application رو نصب و استفاده میکردیم.سوم اینکه صادق باشیم و شکیبا !هرچقدر همیشه با تیم و مدیران بالاسری صادق بودم، ولی در شکیبایی ضعف زیاد داشتم. متاسفانه خاطرات تلخ و شیرین زیادی در مورد این دو موضوع وجود داره. وقتی که شما مدیر صادقی نباشید، بالاخره زمانی کارمندان و هم تیمی های شما متوجه خواهند شد و این حس شاید بدترین حس بین هم تیمی ها باشه. مطمئن باشید اگر صداقت داشته باشید و موضوعات رو صادقانه ولی با سیاست بیان کنید، نتیجه بهتری میگیرید. (توصیه میکنم این مطلب رو هم بخونید)به نظر من صبر و شکیبایی در واقع لباس یک مدیر پروژه هست و هرچقدر این موضوع بهتر و کاملتر باشه، قاعدتا مدیر بهتری خواهید بود. البته این به این معنی نیست که مثلا در مقابل کاری که قرار بوده برسه و نرسیده صبر و شکیبایی پیشه کنید! قاعدتا در این موارد باید بررسی کاملی از وضعیت کار انجام شده داشته باشید و به این موضوع رسیدگی کنید. در کنار این موضوع باید فرصت کافی برای رشد و ترقی نیروهاتون رو فراهم کنید. برنامه نویسها عموما نیروهایی هستند که با توجه به رشد روزافزون تکنولوژی ها، به شدت احساس فسیل شدن! بهشون دست میده و این حس، باور کنید که حس خیلی بدی هست و شاید بعد از حقوق و مزایا (و شرایط دریافتیش) مهمترین علت ترک شرکت و رفتن به محل کار جدید باشه !چهارم اینکه خودبرتر پنداری مدیر پروژه ممنوع !مدیر پروژه از سایر افراد تیم برتر نیست ! سعی کنید با همکاران خود دوست باشید و روابط تیمی و همکاری خود را توسعه بدهیدواقعیت این است که این تفکر یک دام برای مدیران پروژه است و عموما یک بحث فرهنگی. متاسفانه در برخی از شرکتهای ایرانی، این موضوع به شدت رایج است. این بزرگترین آفت برای حذف ارتباطات میان فردی است که در بالاتر از اهمیت آن گفتیم.------------------------------منبع پست های مدیر پروژه هنرمند،کتاب مدیریت پروژه (۲۴ شیوه برای اداره کردن هر پروژه ای) از گری هیرکنز با ترجمه مامک بهارزاده، است که من هر بار تعدادی از نکات اون رو برمیدارم و تجریبات خودم رو درباره اونها اضافه میکنم و اینجا میارم، با این امید که به درد بقیه همکارانم بخوره.

اهمیت روالهای عملیاتی استاندارد (SOP) در مدیریت پروژه

Mostafa Fallah - مصطفی فلاح — Sun, 02 Jun 2019 09:16:12 +0430

فاجعه بزرگ تصادف قطار - 1856حدودا 20 سال از اختراع تلفن گذشته بود که تصادف تکان دهنده دو قطار در آمریکا، ثابت کرد که چرا روالهای عملیاتی استاندارد ( SOP - Standard Operation Procedure) باید رعایت و اجرا شوند. ماجرا از این قرار بود که قطار فیلادلفیا 23 دقیقه دیرتر از موعد حرکت کرده بود و مهندس بی تجربه قطار، سرعت قطار را تا حد امکان بالا برده بود تا زمان تاخیر در حرکت را جبران کند. از طرف دیگر قطار دوم، بر روی همین خط به سمت فیلادلفیا و بر اساس برنامه زمانی مشخص شده حرکت میکرد. هردو قطار برنامه حرکت و توقف یکدیگر را میدانستند و بر اساس برنامه مشخص شده، قطارها به صورت سایدینگ از کنار یکدیگر عبور میکردند. این برنامه فقط زمانی قابل اجرا بود که قطار دوم از تاخیر قطار اول آگاه میشد. در نهایت قطارها با هم برخورد کردند و 50 نفر جان باختند و 100 نفر مجروح شدند.آنچه بیان شد، یک ماجرای واقعی است و البته یک نمونه دقیق برای سیستمهای حساسی است که روالهای عملیاتی یا در آنها تعریف نشده است یا وجود دارد ولی اجرا نمی شود. چگونه SOP های خودمان را بسازیم؟قانون طلایی SOP میگوید هر چیزی که نیاز است بیش از دو بار اجرا بشود، باید مستند سازی بشود1- چارت سازمانیاندازه سازمان شما مهم نیست، سعی کنید برای داشتن SOP های مشخص، چارت سازمانی مشخصی هم داشته باشید.در چارت مشخص کنید چه نقش هایی وجود دارد و هر کسی عهده دار چه نقشی است و دقیقا چه کاری انجام خواهد داد.2 - دستورالعملهای دقیقروالهای عملیاتی اغلب شامل متون زیاد و عجیب و بیهوده می شوند (دقیقا این یه جور جوک هست و یه انتقاد بزرگ به SOP) پس سعی کنید در این دام نیفتید! شما SOP رو برای این میسازید که همه بخونن (نه اینکه مثلا خوندن) و عمل کنن. برای اینکه به این هدف برسید، 2 تا نکته کلیدی رو باید رعایت کنیدالف ) مطمئن باشید که شخص دقیق و باتجربه ای که عضوی از سازمان شما است و در داخل سازمان مشغول به کار است را برای نوشتن روالهای عملیاتی در نظر گرفتید.ب ) مطمون باشید که موضوع زبان رو در نظر گرفتید برای مستنداتتون. به هر حال هر کسی که در سازمان شما هست باید بتونه این مستندات رو بخونه. این موضوع قطعا وقت گیر است ولی سعی کنید حداقل کلمات و عبارات کلیدی رو برای این موضوع در نظر بگیرید. شما در نهایت باید مطمئن باشید که رسیدن به نتایج باید نیازمند سیستم شما باشد نه افراد شما.3 - چک لیست هایی با نتایج قابل اندازه گیریدر نظر داشته باشید چک لیستها قدرت جادویی برای جلوگیری از اشتباهات را دارند. در واقع SOP ها نهایتا به چک لیست ختم خواهد شد. چک لیستهای خوب و دقیق باعث نتایج قابل اندازه گیری خواهند بود. برای مثال چک باکسی در لیست شما با این عنوان : ترویج دادن مقاله ، قطعا برای رسیدن به نتیجه مشخصی به شما کمک نخواهد کرد. ولی در صورتی که مثلا چک باکس شما با این عنوان باشد، موثرتر خواهد بود : ارسال مقاله به 5 نفر از مشتریان.معروفترین ابزارهای SOP آنلاین Process StreetSweet ProcessPipefyWunderlistمنبع : کتاب The Ultimate Guide To Project Management ×WorkFlowy منبع : کتاب The Ultimate Guide To Project Management

5 نکته برای انتخاب نرم افزار مدیریت پروژه

Mostafa Fallah - مصطفی فلاح — Wed, 01 May 2019 15:05:01 +0430

یکی از مهمترین دغدغه های مدیران پروژه، انتخاب نرم افزار مناسب برای مدیریت پروژه هایشان است. قاعدتا این نرم افزار باید قابلیت ثبت و مدیریت کارها (بر اساس شیوه های مدیریت پروژه)، مشخص کردن وضعیت پروژه در هر لحظه(مقدار کار انجام شده،باقیمانده و وضعیت ددلاین ها)، تولید گزارشهای مالی،نمودارهای مخصوص رشد و افت پروژه را داشته باشد. البته اگر شما مدیر پروژه ای هستید که پروژه هاتون متنوع هستند (از حیث نوع افراد درگیر، حجم کار و...) و این دغدغه رو ندارید، احتمالا با مشکلات زیادی مواجه خواهید شد. در کتاب The Ultimate Guide To Project Management، فصل 6، چند نکته در مورد انتخاب نرم افزار مدیریت پروژه ذکر شده که سعی کردم بر اساس تجربیات خودم اینجا بنویسم.1. تحقیق در مورد نرم افزاری که فیچرهای همکاری تیمی را داشته باشدبرای این موضوع اولین سوالی که باید از خودتون بپرسید، اینه که آیا نرم افزار مورد نظر، امکانات کافی برای همکاری و ارتباط بین اعضای تیم رو داره؟خب برای رسیدن به جواب این سوال، شما باید واقعا تجربه کار روی یک پروژه مشابه رو داشته باشید تا بدونید حجم مراودات چقدره و علاوه بر اون باید نرم افزارهایی رو بشناسید تا بتونید مقایسه کنید. قاعدتا در ابتدای کار، باید مقداری آشنایی با نرم افزارهای مدیریت پروژه یا مطالعاتی در همین زمینه داشته باشید. البته از دوستان باتجربه تر هم میتونید استفاده کنید.شاید این جمله پائول کاتنت (مدیر فنی Madkudu) جمله خوبی باشه که میگه : من با نرم افزارها و ابزارهای زیادی سر و کار دارم، اما واقعا فقط تعداد کمی از اونها هستند که مزیت های افزایشی شون، ارزش هزینه جایگزینی با یک تیم چند نفره رو داره.پس در مرحله اول شما باید نرم افزاری رو پیدا کنید که روابط فعلی تیمتون رو کاور کنه و بعد از اون، باید نرم افزاری باشه که روابط تیم رو ارتقا بده. مثلا برای تیمهای پراکنده، ترلو احتمالا میتونه جایگزین بدی نباشه. (Taskulu هم که نرم افزار ایرانی خوبیه و مشابه ترلو Web Based ساخته شده) . همینطور برای سازمانی که مثلا چند تیم پراکنده دارند، Jira میتونه گزینه خوبی باشه. 2 . محاسبه و کنترل هزینهاگر محدودیتی در مورد بودجه برای خرید یا استفاده از نرم افزار مدیریت پروژه ندارید،(Johan Leiu) مدیر محصول Wufoo :اگر انتخاب نرم افزار مدیریت پروژه شما به خاطر بودجه محدود نشده، خوب پس شما همون کاری که دوست دارید رو بکنید، مثلا نرم افزاری رو استفاده کنید که بخشی از جریان کاری شما رو اتوماتیک میکنه یا به طور کلی زندگیتون رو آسون میکنه.ولی اگر مثل اکثر شرکتها یا تیمها محدودیت بودجه دارید، اولین سوالی که باید از خودتون در این زمینه بپرسید اینه: مزایای بهره وری از این ابزار بیشتر از زمان و پولی است که برای آن صرف می کنیم ؟همچنین موضوع مهم دیگه اینه که در نهایت بعد از صرف هزینه برای راه اندازی، آیا هزینه های ما با استفاده از این نرم افزار کاهش پیدا میکنه؟ برای رسیدن به این جواب، شما واقعا باید یک مدیر پروژه خوب و دقیق باشید و به طور کامل با فضای پروژه آشنا باشید.و در نهایت این نکته که از تجربیات خود من هم هست، برای تکمیل این قسمت:وقتی در روزهای اول استفاده و جاانداختن یه نرم افزار مدیریت پروژه هستید، در ابتدای کار هزینه و زمان زیادی صرف راه اندازی و آشنایی همه با اون میشه. به عبارتی، این موضوع مهم هست که کِی و چه زمانی راه اندازی نرم افزار مدیریت پروژه رو انجام میدیم. پس لازمه که بدونیم قبل از راه اندازی یه نرم افزار مدیریت پروژه چقدر قراره هزینه کنیم؟ (برای درک بهتر این موضوع خوندن این مطلب توصیه میشه)3 . جایگزین ها رو امتحان کنید! و باز هم جایگزین جدید رو امتحان کنید و باز هم ...یک مدیرپروژه خوب، باید ابزارهای کارش رو بشناسه و باید بدونه که عموما نرم افزارهای خوب شامل چه امکاناتی میشن و چه قابلیت هایی دارن. به عبارتی نرم افزارهای جایگزین خودتون رو بشناسید و یادتون باشه که هر نرم افزاری قابلیتهایی داره که ممکنه نرم افزار دیگه ای نداشته باشه. (در فصل 7 این کتاب نمونه های واقعی در همین رابطه مثال زده شده که در حال آماده سازی اون در قالب یک پست جدید هستم).جمله ای از هیدر هندریکس، مدیر پروژه در ارتباط با همین موضوع:من به نرم افزارهایی که قابلیت استفاده از کلیه امکانات رو برای مدتی محدود به صورت Trial نمیدن اصلا اعتماد نمیکنم. من باید بتونم کند و کاو کافی از نرم افزار داشته باشم4. گرفتن فیدبک از تیماعضای تیم کسانی هستند که واقعا باید با نرم افزار شما ارتباط برقرار کنن. پس سعی کنید خیلی سریع از اونها فیدبک های لازم جهت استفاده از نرم افزار مورد نظر رو بگیرید.5 . طرح اجرایی خود را مطرح کنیدسعی کنید در ابتدا طرح خودتون برای راه اندازی نرم افزار مدیریت پروژه، در سازمان رو مطرح کنید. به یاد داشته باشید که شما تنها کسی که از این نرم افزار استفاده خواهد کرد نیستید، و همواره این سوال رو از خودتون بپرسید : چطوری میتونم به سایر افراد تیم کمک کنم که از این نرم افزار استفاده کنن؟بهترین کار برای راه اندازی، این است که یک طرح اجرایی داشته باشید و اون طرح رو قبل از اجرا با سایر هم تیمی هاتون به اشتراک بزارید و تصمیم مناسب اتخاذ کنیدمنبع : کتاب The Ultimate Guide To Project Management

12 فیچر جدید در Microsoft Visual Studio 2019

Mostafa Fallah - مصطفی فلاح — Mon, 15 Apr 2019 17:30:07 +0430

,چند روز پیش نسخه جدید ویژوال استودیو 2019 اومد و قاعدتا همه منتظرن ببین امکانات جدید اون چیه. من سعی کردم به صورت خلاصه و کوتاه، بعضی از این فیچرها رو بگم براتون.1. اینستالر Installer جدید و قویافزایش سرعت نصب و همچنین راحتی و سهولت انتخاب فیچرها، از قابلیتهای خوب این نسخه هست.2. صفحه اولصفحه اول ویژوال استودیو 2019، بسیار ساده و سریع و جذاب و البته کاملا متفاوت شدهبطوریکه شما میتونید از لیست پروژه های Recent خود یکی را انتخاب و باز کنید. در سمت چپ، شما یکی از 4 گزینه زیر رو میتونید انتخاب کنید :از ریپازیتوری، پروژتون رو Clone کنیدپروژه ایجاد شده قدیمی که تا الان باز نکردید رو باز کنیدفولدری رو باز کنید تا بتونید پروژه رو انتخاب کنیدیک پروژه جدید بسازید3. ایجاد پروژهصفحه ایجاد پروژه مصفحه ایجاد پروژه همونطور که توی عکس هم میبینید، قابلیت انتخاب زبان، پلتفرم و نوع پروژه رو اضافه کرده و به عبارتی با یه فیلتر خیلی ساده، خیلی سریع شما میتونید پروژه ورانتخاب کنید.4. لایو شیر Live Shareاین امکان رو مایکروسافت مدتی پیش، در Visual Studio Code قرار داده بود و الان این امکان رو به صورت کامل در Visual Studio 2019 قرار داده. این گزینه در بالا سمت راست صفحه اصلی قرار داره و شما میتونید با کمک این گزینه، کدتون رو برای بقیه به اشتراک بزارید به طوریکه همزمان کد رو تغییر بدید. البته بدیهی است که شما باید به حساب کاربری مایکروسافت خودتون وارد بشید.(تنظیمی در قسمت Option->Live Share هست که میتونید نوع حساب کاربری رو تغییر بدید و مثلا از حساب GIT وارد بشید). حالا کافی هست لایو شیر رو فعال کنید تا لینکی به شما داده بشه تا این لینک رو در اختیار بقیه قرار بدید و بقیه هم استفاده کنن.در صورتی که بخاین به لایو شیر یک نفر دیگه وصل بشید باید از منوی File > Join Collaboration Session به لینک اتصالی که ایجاد شده متصل بشید.5. جستجوی بهتردر این نسخه، مایکروسافت بالاخره یه جستجوی کامل و کافی رو در اختیار کاربرها قرار داد تا با استفاده از اون به منوها ، آپشن ها و به طور کلی همه و همه اجزای ویژوال استودیو دسترسی داشته باشند. کافی هست فقط تایپ کنید تا براتون لیست نمایش داده بشه6. جستجوی بهتر در کدبا استفاده از گزینه Current Block، در جستجو، این امکان به کاربر داده میشود تا جستجو در بلاک موجود انجام شود. 7. کلین کردن کد Code Clean Upدر این نسخه از ویژوال استودیو امکان کلین کردن کد با استفاده از گزینه ای با آیکن جارو فراهم شده است. البته با زدن منوی کنار این گزینه، میتوان Configuration کلین کردن را انجام داد. کارهای از قبیل ذدر این نسخه از ویژوال استودیو امکان کلین کردن کد با استفاده از گزینه ای با آیکن جارو فراهم شده است. البته با زدن منوی کنار این گزینه، میتوان Configuration کلین کردن را انجام داد. کارهای از قبیل حذف خطوط اضافه یا مرتب کردن Using ها و ... تعبیه شده است.8. افزایش قدرت و امکانات دیباگردر این نسخه، امکان جستجو در پنجره های Autos، Watch و ... اضافه شده است که البته با کمک Search Deeper امکان جستجو در حین دیباگ برای یافتن آیتم های سطوح پایین تر اشیا فراهم شده است. در قسمت تنظیمات میتوان عمق سطح جستجو برای این بخش را مشخص کرد که به صورت پیشفرض 3 است.9. مدیریت بهتر Pull Request هادر این نسخه بطور کامل امکان مدیریت قوی Pull Request ها رو داریم. مشاهده کدها و همینطور بررسی کلیه Pull Request ها در قسمت Team Explorer یکی از این امکانات هست. برای دسترسی به این قسمت نیاز هست که اکستنشن Pull Requests for Visual Studio رو نصب کنیم.10 . ریفکتورینگ بهترامکانات زیاد و خوبی برای ریفکتورینگ در این نسخه در نظر گرفته شده. با استفاده از حباب زردرنگ سمت چپ، میتونید پیشنهادات خوب و متنوع برای ریفکتورینگ کدها رو ببینید. 11 . اینتلی کد بهتر IntelliCodeبا استفاده از اکستنشن Visual Studio IntelliCode که محصول مایکروسافت لب هست، میتونیم از هوشمندی بیشتر این فیچر استفاده کنیم. مایکروسافت ادعا کرده است، این قسمت با استفاده از بیش از 2000 پروژه گیت هاب، این هوشمندی را تقویت کرده است.12. کلیپ بورد هیستوریمدتی پیش نگه داری تاریخچه Clipboard در ویندوز 10 (در آپدیت جولای 2018) فعال شد. اما الان در ویژوال استودیو ما امکان نگه داری تاریخچه کلیپ بورد رو داریم و شما به ترتیب ذخیره کردن در Clipboard به اونها دسترسی خواهید داشت. با زدن کلید های CTRL Shift V . همچنین از طریق منوی Edit -> Show Clip Board

4 فیچر جدید Gmail در تولد 15 سالگی

Mostafa Fallah - مصطفی فلاح — Wed, 10 Apr 2019 11:15:45 +0430

آنچه گذشتاول آوریل 2019، سرویس ایمیل Google (جی میل Gmail) ، وارد پانزده سالگی شد. این سرویس سال 2004 معرفی شد و بخش خیلی زیادی از مشکلات و محدودیتهایی که برای میل باکس ها در اون دوره زمانی بود رو رفع کرد. اولین موضوع بحث فضا بود. در حالی که رقبا با دادن فضای 2 مگابایت (بله 2 مگابایت) یا 4 و 6 مگابایتی رقابت میکردند، گوگل اعلام کرد به زودی سرویس میل 1 گیگابایت رو برای کاربران راه اندازی میکنه. این مطلب چیزی شبیه به یه شوخی بود، ولی گوگل اینکارو کرد. بعدا در ادامه مقدار فضا رو بر اساس استفاده کاربرا داینامیک کرد و بعد از اون هم این سرویس رو به سرویس دیگه که Google Drive بود متصل کرد و در حال حاضر فضای 15 گیگابایتی مشترک با سایر سرویس ها رو به صورت رایگان در اختیار کاربرها قرار میده. (البته با پرداخت پول سالیانه میتونید به راحتی این فضا را افزایش بدید)موضوع بعدی، امکانات کم و ساده و پیش پا افتاده در سرویس های میل بود. عموما سرویسهای میل چیز خاصی رو ارائه نمیکردند و سرویس ساده ای داشتند که به نوعی کاربر خودش باید حواسش به خیلی چیزها میبود. ولی گوگل این قبیل مسائل رو با استفاده از Labs والبته ساختار جدید خودش حل کرد. Labs بخشی از سرویس میل گوگل بود که دولوپرها امکاناتی رو برای Gmail ایجاد میکردند و کاربر میتونست استفاده کنه. شاید باورتون نشه ولی حدود 2 سال نسخه Gmail که ما استفاده میکردیم، بتا بود! گوگل در تولد 15 سالگیش، 4 تا امکان جدید رو اضافه کرده که این 4 سرویس عبارتند از :1 - افزایش هوشمندی و دقت Composer در نسخه جدید Gmail، کاربر علاوه بر افزایش دقت متون Auto Complete (متون از پیش آماده که بر اساس کلمات قبل شده تایپی شما، آماده می شود و شما با زدن کلید TAB میتوانید آنها رو در متن خود قرار بدهید)، این امکان آمده است که با زدن کلمات خاصی، متون خاصی نیز نوشته می شود.به عنوان مثال، در صورتی که تمایل دارید برای تیم خود یک پیام تبریک دوستانه بفرستید، با زدن کلمه Hey Team، گوگل با استفاده از هوش مصنوعی خودش، این پیام رو بهتر و کاملتر میکنه.2 - ساپورت 4 زبان جدید در Composer هوشمند در نسخه جدید Gmail، کلیه امکانات Composer هوشمند جیمیل، در هنگام ارسال نامه، برای زبانهای اسپانیایی، فرانسوی، ایتالیایی و پرتغالی نیز در نظر گرفته شده است. 3 - تنظیم زمان تحویل نامه!شما از این به بعد میتونید، قبل از اینکه نامه رو ارسال کنید، مشخص کنید که چه تاریخی به دست کاربر برسه. (البته فیچر دیگه ای هم هست که میتونید مشخص کنید که ایمیل چه تاریخی اکسپایر بشه که بهش میگن confidential mode یا حالت محرمانه و با این فیچر زمان تحویل نامه متفاوته). این ایمیلها (ایمیلهای برنامه ریزی شده) بدون هیچ مداخله دستی به طور خودکار به دست کاربر میرسه.4 - اینباکس عملیاتی در نسخه جدید Gmail، شما میتوانید بخشی از کارها رو بدون خارج شدن از میل باکس انجام بدید. مثلا شما میتونید به یک کامنتی از Google Drive که داخل میل باکس شما اومده، پاسخ بدید. ( برای کامنت هایی که روی فایلهای گوگل درایو توسط سایر کاربرا نوشته میشه، ایمیل نوتیفیکیشن برای کاربر ایجاد کننده ارسال میشه) یا جلسه ای رو ست کنید. اینطوری کاربر تمرکزش رو از روی کارش به خاطر باز کردن یه تب جدید از دست نمیده. به نظر میرسه این فیچر، در آینده خیلی توسعه داده بشه و خیلی هم به درد کاربرا بخوره.

سلام ویرگول، سلام دوباره نوشتن

Mostafa Fallah - مصطفی فلاح — Thu, 04 Apr 2019 14:50:16 +0430

از کجا شروع کردم؟سال 1380، از طریق یکی از دوستام که دانشگاه تهران درس میخوند با یک نشریه دانشجویی اصفهانی آشنا شدم و قرار شد مطلبی در مورد وبلاگ براشون تهیه کنم. سعی کردم وبلاگهای ایرانی رو پیدا کنم، با سلمان جریری و حسین درخشان از همین طریق آشنا شدم. یادمه تا سال بعدش نهایتا 800 تا وبلاگ فارسی بیشتر وجود نداشت.(با استفاده از بلاگر و با سختی زیاد اون رو فارسی سازی میکردن)اون موقع من برنامه نویس جونیور (با 19 سال سن) در یک شرکت ایرانی-استرالیایی بودم. از نظر همکارام، وقت گذاشتن روی این مقاله کار بسیار بیهوده و حتی فراتر ازاون، وبلاگ نویسی کار خنده داری بود. مطلب رو تهیه کردم ولی چیزهایی که فهمیدم این بود که هدف وبلاگ در اون زمان، بیشتر درددل، خاطره نویسی و البته قرار و دورهمی و اینها بود. من اولین بلاگم رو در بلاگر ساختم ولی با کلی مشقت!چطور ادامه دادم؟بعدا سرویسهای ایرانی هم اومد و من وبلاگ دوم رو در پرشین بلاگ ساختم ولی هیچ کدوم چیزی که من میخواستم نبود. من یه وبلاگ روی دامنه خودم میخواستم با کنترل محتوا توسط خودم که البته رسیدن به این موضوع 7 سال طول کشید. سال 1387 وبلاگ خودم روی دامنه خودم رو راه انداختم و هنوزم آپ است. از این به بعد؟2 سال پیش با ویرگول از طریق این پست عالی آشنا شدم. مطمئن نبودم که این سرویس سرپا میمونه یا نه ولی موند. خیلی هم خوب موند. دوست دارم در ویرگول نوشتن رو به صورت هدفمند ادامه بدم. هرچند هنوز وبلاگم میمونه برای لینک بیشتر شدن با اینجا.