نافرمانی هوشمندانه (کجا قوانین را زیر پا بگذاریم)

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

نافرمانی

(بیشتر…)

نجات پروژه در حال شکست (قسمت اول)

میتوان گفت تقریبا تمامی پروژه ها حین اجرا به مشکلات بسیاری بر می خورند که در اکثر موارد اگر این مشکلات به موقع درمان نشود منجر به شکست خواهد شد . در این نوشته شما به عنوان مدیر یک پروژه ی مشکل دار که تعدادی سرمایه گذار و تعدادی عضو تیم اجرایی دارد فرض می شوید و من راهکارهایی برای نجات پروژه تان از این وضعیت در این جا می نویسم که ممکن است تعدادی از آنها بسته به مشکل پروژه تان به شما کمک کند .

 

شناخت یک پروژه ی مشکل دار :

معمولی ترین نشانه ی یک پروژه ی مشکل دار اختلاف نظر در مورد اولویت انجام کارها بین سرمایه گذاران می باشد اما با هم بحث و گفتگویی در این مورد نمیکنند که منجر به حل مسئله شود . ممکن است شما برای پروژه سرمایه گذار نداشته باشید و این سرمایه اولیه را خودتان یا از مشتری دریافت کرده باشید . در هر صورت اختلاف نظر بین کارفرما و پیمانکار مدنظر است .

از دیگر نشانه های پروژه ی مشکل دار، عوض شدن دائم نظر مشتری ، رسیدن اعضای تیم به پایان مهلت انجام در حالی که با کارهای و اولویت های زیادی دست و پنجه نرم می کنند ، اعضای پروزه از وقتهای اضافی استفاده می کنند ، تمرکز اعضای تیم از بین رفته ، هیچ یک از اعضای تیم ، پروژه را مال خود نمی داند ، فقط مدیر عامل از پروژه و فعالیت ها و دستاوردهای ان ظاهرا راضی است و بقیه سرمایه گذاران آن چیزی که می خواهند را دریافت نمی کنند و پروژه تبدیل به حیوان خانگی مدیر می شود ، مشاجرات مداوم نشانه ی پروژه ی مشکل دار است ، جلسات طولانی بدون نتیجه گیری ، تحلیل و پیشرفت . این جلسات به شدت جلوی پیشرفت متمرکز پروژه را می گیرد . وقت گذاشتن زیاد روی مدیریت پروژه بجای انجام پروژه ، اختلاف زیاد بین خود سرمایه گذاران و دفاع از سلیقه های شخصی .

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

G & A (Firestone) H-19 helicopter

(بیشتر…)

دسته بندی روحیات افراد در تیم

اعضای هر تیمی فارغ از نوع فعالیت و مدتی که با هم کار می کنند دارای دسته بندی روحیات معینی هستند و بر اساس ترکیب این روحیات ، می توان آینده ی هر پروژه را پیش بینی کرد . در ادامه خصلت های احتمالی هر فرد عضو تیم را شرح می دهم . توجه کنید که منظور نقش افراد یا مسئولیت آنها نیست ، بلکه خصلت اخلاقی و کاری هر شخصی که ناخودآگاه بر روی پروژه تاثیر می گذارد .

1-      رهبر یا کارگردان : این فرد کار رهبری تیم را انجام می دهد ، معمولا چنین فردی فارغ از نقش و مسئولیتش میگوید: “من این نتیجه را دوست دارم ، اما باز هم می توانیم بهتر شویم و باید بهتر شویم ” یا اینکه : “چه فرصت خوبی ، بیایید واردش شویم”

2-      آنالیزور: کسی که نتایج را بر اساس واقعیت ها می بیند و اصلا به وعده و رویا و آینده ممکن است چه کاری انجام دهیم کاری ندارد ، بسیار منطقی فکر میکند و استدلالش نتایج بدست آمده از فعالیت های پیشین است .

آنالیزور

 

3-      Task master  یا نگران کارها : کسی که جلوی تلف شدن وقت می ایستد و نگران این است که کارها عقب نیفتد و به موقع هر کسی کار خود را انجام دهد ، این فرد ممکن است در تیم وجهه خوبی نداشته باشد و جلوی راحت طلبی اعضای تیم را بگیرد ، او کاملا نتیجه گراست و برای اتمام پروژه و رسیدن به هدف به هر قیمتی ، تلاش می کند و دائما سعی در محدود کردن حوزه ی پروژه دارد .

نگران انجام شده کارها

 

(بیشتر…)

مدیریت تیم (قسمت اول)

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

1) رسیدن به یک هدف 2) جایزه گرفتن 3)ایجاد حس ورود به یک جا یا یک گروه 4)حس فرصت 5)حس داشتن هدف

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

کار تیمی (بیشتر…)

بررسی agile بصورت جزئی تر (قسمت چهارم)

طبق پست های پیشین در مورد بررسی agile بصورت جزئی تر در ادامه به برنامه نویسی گروهی و نحوه ی تست برنامه می پردازیم .

برنامه نویسی گروهی
همانطور که گفته شد هیچ کسی در تیم مالکیت انحصاری کد نوشته شده ی خود را ندارد و هر کسی از تیم می تواند آن را برای بهتر شدن ویرایش کند . در برنامه نویسی گروهی می توان هر کسی یک قسمت از کدنویسی را به عهده بگیرد و با نرم افزارهای مدیریت نرم افزار مانند SVN و Git با هم روی سورس کار کنند ، یا دو نفر با یک کامپیوتر کار کنند . هر کدام از این دو نفر می توانند کیبورد را در اختیار بگیرد و کد نویسی کند و دیگری همراه با اون فکر کند که چه راهی بهتر است و کدام متود سریعتر و بهتر جواب می دهد ، هرگز فکر نکنید این روش وقت تلف کردن است یا دو نفر موازی یک کار انجام می دهند ، بلکه کیفیت و سرعت کد نویسی همچنین درصد خطا بسیار پایین می آیند ، در این روش 1+1>2 می باشد . باید توجه داشت که بهتر است بطور مداوم جای کدنویس (راننده) با نفر دیگر عوض شود .
کمک برنامه نویس وظیفه دارد هر خطی که نوشته می شود را در ذهنش چک کند که درست باشد و در مسیر متودهای گذشته باشد . هر دو نفر می بایست اخلاق دسته جمعی و کار گروهی را رعایت کنند ، جنسیت دو برنامه نویس نباید خللی در کار وارد کند و تیم به حاشیه برود ، هر دو برنامه نویس باید سخت کوش باشند و مسئولیت و وظیفه محول شده را از خودشان بدانند .
به هیچ وجه جَو سرزنش برای وجود باگ در تیم ایجاد نکنید ، تا هر کسی که شک در برنامه ای که نوشته بود پیدا کرد آن را به راحتی بیان کند نه این که اصطلاحا آن را به زیر قالی بفرستد .
اگر شک در برنامه ایجاد شده احتیاج به زمان زیادی برای اصلاح داشت Itration تمام شده و آدرس و محل مشکل را برای مرحله ی بعد یادداشت می کنیم . (به هیچ وجه وجود مشکل در کد نباید باعث به تعویق افتادن اتمام مرحله شود)

(بیشتر…)

بررسی agile بصورت جزئی تر (قسمت سوم)

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

دیتابیس

1) دیتابیس بصورت عمده ای و یک جا اول پروژه ساخته نمیشه ، بلکه بصورت تدریجی و افزایشی طی انجام پروژه ساخته میشه . هنگام انجام User-stories ها با توجه به نیاز دیتابیس طراحی یا ویرایش می شود

2) بهینه سازی و نرمالایز کردن دیتابیس هم به تدریج انجام می شود ، دلیل تدریجی بودن این کار این است که ابتدای پروژه اطلاعات کافی نداریم .

3) در صورتی که حین انجام پروژه به این نتیجه رسیدیم که جدولی که طراحی کرده بودیم باید حذف شود آن را نشانه گذاری میکنیم یا اول اسم آن ex می گذاریم ، شاید بعدا نیاز شد و یا استراتژی تغییر کرد

4) بهتر است در صورت وجود نیروی انسانی کافی ، یک مدیر برای دیتابیس قرار دهیم تا تغییرات آن را ثبت و مستند سازی کند .

برنامه ریزی برای مرحله بعد

5) موقع برنامه ریزی همه ی اعضای تیم باید شرکت داشته باشند و پروژه را از خودشان بدانند

(بیشتر…)

بررسی Agile بصورت جزئی تر (قسمت دوم)

در ادامه نوشته ی پیشین راجع به بررسی Agile بصورت جزئی تر (قسمت اول) و راهکارهای عملی در مدیریت پروژه چابک ، در این نوشته به قسمت دوم نکات عملی این روش می پردازیم .
1) طراحی پروژه در Agile بصورت افزایشی و تدریجی است ، هیچ گونه طراحی صفر تا صد برای پروژه هایی که با روش چابک کار میکنند وجود ندارد ، در طراحی نرم افزار فقط قسمتهایی که لازم است در این مرحله تا جلسه ی بعدی ساخته شود طراحی می شود نه طراحی اولیه با جزئیات برای کل پروژه
2) چند نوع طراحی وجود دارد ، الف) طراحی عملکرد : مثلا سرعت سیستم باید چقدر باشد و از کجا بفهمیم سرعت افزایش پیدا کرده است. ب)طراحی مدلسازی: طراحی اینکه در هر مرحله چه کارهایی باید انجام شود و فلوچارت و دیاگرام مسیر انجام پروژه چگونه است. (می بایست از همه ی اعضایی که در این پروژه شرکت دارند راجع به فلوچارت بازخورد گرفت).

3638

(بیشتر…)

بررسی Agile بصورت جزئی تر (قسمت اول)

در مورد مدیریت پروژه ی به روش Agile با متدلوژی های مختلف مانند Scrum یا RUP , XP و … مطالب کلی زیادی وجود دارد اما در این نوشته قصد دارم نکات جزئی تر و تخصصی تر که کمتر در مورد آن بحث شده است همچنین تجربیات شخصی ای که داشته ام را بنویسم تا برای کسانی که آشنایی اولیه به این روش اجرای پروژه های نرم افزاری دارند مفیدتر باشد .
بصورت اجمالی agile را بصورت زیر تعریف می کنم :
Agile یک روش برای مدیریت پروژه است که دارای متدلوژی های مختلفی است اما در همه ی آنها موارد مشترکی از قبیل برنامه ریزی و طراحی تدریجی و افزایشی وجود دارد . شرکتهایی که با Agile کار می کنند چابک هستند و در هر لحظه می توانند چشم انداز و اهداف خود را اصلاح کنند و با توجه به وضعیت کسب و کار آنها را تغییر دهند ، محصولاتی که می سازند برای نیاز مشتری هایی است که از قبل مشخص شده اند. در این روش ابتدای بازه های زمانی از قبل مشخص شده که اصطلاحا به آنها Iteration گفته می شود ، جلسات درون تیمی انجام می شود و در آن تصمیم گرفته می شود که پروژه با چه سرعتی و در کدام جهت پیش رود . بعد از هر iteration یک نسخه از محصول نرم افزاری برای فیدبک به مشتریان و مدیران شرکت ارائه می شود و با توجه به نظرات، برنامه ی مرحله ی آینده ریخته می شود . به همین صورت پروژه به طور تدریجی و افزایشی به سمتی می رود که بهتر است و محصولی در نهایت ارائه می شود که اولا نیاز بازار است و ثانیا مورد تایید مشتریست .
با توجه به این توضیحات اولیه نکات جزئی و تخصصی تر را در این نوشته و قسمتهای بعدی که منتشر خواهد شد ذکر می کنم .

employee-run

(بیشتر…)

نکاتی که در سپردن کار به کارمندان باید توجه کرد

 

وقتی مدیریت یک تیم را به عهده دارید و کارها را بین اعضای تیم می خواهید تقسیم کنید برای اینکه کارها به خوبی تحویل داده شود و نتیجه بخش باشد باید به یک سری نکات توجه کنید که در این نوشته به آن می پردازیم .

 

سپردن کار

(بیشتر…)