بایگانی

Posts Tagged ‘رهبری تیم’

درس های رهبری و موفقیت از زبان یک مربی بسکتبال

اکتبر 30, 2010 3 دیدگاه

جان وودن(John Wooden)  ملقب به مربی وودن (Coach Wooden)  یک بازیکن و مربی بسکتبال در سال های گذشته آمریکا بوده است. به عقیده  بسیاری از بسکتبالیست ها او بهترین مربی بسکتبال در طول تاریخ می باشد. البته نه به این خاطر که او خوب بسکتبال می دانست بلکه او یک رهبر و مربی به معنای واقعی کلمه بوده است. توانایی تیم سازی او زبان زد خاص و عام بود . بسیاری از بازیکنان مطرح لیگ NBA فقط به خاطر نام مربی وودن به تیم دبیرستانی او می آمدند. علت اینکه این مربی بسکتبال در دنیای خارج ازورزش نیز شناخته می شود به خاطر قدرت رهبری وی می باشد.

مربی وودن خالق هرم موفقیت بوده است . به عقیده خیلی از محققین این هرم بهترین شکل بصری می تواند از عوامل موفقیت باشد. مربی وودن 14 سال از عمر خود را صرف ساخت این هرم کرده است. هرمی مانند شکل زیر :

https://sirasad.files.wordpress.com/2010/10/pyramid_lg.jpg?w=592

شکل بالا شامل 3 جز اصلی می باشد. 1- تعریف دقیق از موفقیت 2-هرم موفقیت 3- 12 درس رهبری

اگر به کتابخانه های محل زندگی خودتان مراجعه کنید , شاهد این خواهید بود که صد ها و شاید هزاران کتاب با عناوینی مانند»چگونه در 2 ثانیه موفق شویم»  یا «چگونه 1 روزه میلیونر شویم» یا «همه را تحث نفوذ خود قرار دهید» و یا … بر روی قفسه ها موجود می باشند . شاید به طور فیزیکی هزاران کتاب از صد ها نویسنده موجود باشد ولی ذاتا همه آنها یکی هستند. به صراحت می توانم عرض کنم که : عکس بالا چکیده این هزاران کتاب می باشد. یعنی اگر ما بدنبال دست یابی به مفهوم موفقیت هستیم این یک شکل ما را کفایت می کند. به قول استاد گرامی آقای قمشه ای , انسان در عمر خود چند کتاب مفید را بخواند برای تمام عمر او کافی خواهد بود. https://sirasad.files.wordpress.com/2010/10/515r62yff7l-_sl500_aa300_.jpg?w=300این عکس از آنهایی است که باید طلا گرفته شود و به جای بعضی چیزها بر روی دیوار ها نصب شود.

اما اگر در درک شکل بالا با مشکل مواجه شدید , می توانم کتاب Coach Wooden’s Leadership Game Plan for Success را معرفی کنم.یک کتاب با حجم کم و متن انگلیسی روان و سرتاسر شکل و داستان و نکته.

در واقع این کتاب (به کوشش فکر کنم نیویرک تایمز) به صورت چیکده به یک شکل بصری گویا تبدیل شده است. هر چقدر که در این کتاب به جلو میروید شکل و هرم را بهتر متوجه خواهید شد.

مربی وودن علاوه بر این کتاب , کتاب های دیگری نیز دارد که خواندن آنها هم خالی از لطف نیست. البته این کتاب وی از طرف استفان کاوی (نویسنده کتاب معروف هفت عادت مردمان موثر) مورد تایید قرار گرفته است.

مربی وودن بعد از اخذ جایزه های متعدد در تیم های متعدد بسکتبال در سن 99 سالگی دار فانی را ودا گفت . روحش شاد.

یاشیاسیز

برنامه نویسی که مدیر پروژه شد

ژوئیه 26, 2010 24 دیدگاه

https://sirasad.files.wordpress.com/2010/07/cartoon_planning.gif?w=300این جریان مدیر پروژه شدن برنامه نویس ها در ایران حکایتی بس طولانی دارد که در این پست قصد مختصر بررسی در این باب را دارم . قبل از شروع بحث موردنظر  لازم می بینم  نظر خودم را در مورد لزوم مدیر پروژه در پروژه های توسعه نرم افزار عرض کنم : به نظر بنده در 90% پروژه های توسعه نرم افزار در ایران نیازی به نقشی با نام مدیر پروژه نیست زیرا این پروژه  ها دارای خصوصیات یک پروژه واقعی نیستند که نیازی به مدیریت پروژه باشد : مثلا به مدیر پروژه بودجه اختصاص داده نمی شود که او بتواند Cost Management بکند یا بتواند نیروی کار مورد نیاز را استخدام بکند و یا … . به طوری کلی مدیر پروژه ای که در اینگونه پروژه ها فعالیت می کند دارای مجوز و اختیارات لازم نیست : یعنی عملا Iron Triangle پروژه در دستان او نیست . البته علاوه بر اینکه مالکان شرکت او را محدود کرده اند ,  او وظایف یک مدیر پروژه را نیز انجام نمی دهد . برای مثال یک شرکت آگهی زده است که :

به یک مدیر پروژه نرم افزاری  حاذق نیازمندیم با شرایط ذیل :

  • توانایی کامل طرح ریزی کامل پروژه
  • توانایی مدیریت
  • توانایی برنامه نویس با زبان #C

کاملا از شرایط درخواستی معلوم است کسی که قرار است این کارها را انجام بدهد اسمش مدیر پروژه نیست (البته با توجه به تعاریف انیستیتو PMI ) . در ایران انتظار میرود که مدیر پروژه کل پروژه را طرح ریزی و طراحی کند . یعنی او عملا کار تحلیل گر و طراح را انجام می دهد  . بلی بنده قبول دارم که مدیر پروژه باید توانایی طرح ریزی داشته باشد ولی نه تحلیل و طراحی محصول  در بعد فنی و تکنیکی مثلا استخراج Class Diagram ؟ ! بلکه او در سطح مدیریت  باید طرح ریزی نماید : Road Map پروژه را مشخص کند ,  ریسک های پروژه را معلوم بکند و … .

انتظار بعدی این است توانایی مدیریت داشته باشد : خوب خیلی خوب است ولی توانایی مدیریت یعنی اینکه تقسیم وظایف برعهده او خواهد بود . مدیریت منابع انسانی (HR) تقسیم وظایف نیست . (مثلا از او انتظار میرود که وظایف برنامه نویسان را در هر ساعت مشخص کند) .

توانایی برنامه نویسی که فکر نکنم نیازی به توضیحات اضافی باشد . یعنی او همانند یک برنامه نویس در کنار زیردستان خویش باید بتواند برنامه نویسی بکند .

قابل نتیجه گیری است : کسی که 4 سال برنامه نویسی کرده باشد بهتر و مستعد تر برای کار کردن در چنین محیطی نسبت به فردی است که مدرک PMP دارد و یا تحصیلاتی در زمینه مدیریت دارد. یعنی عملا در راس پروژه ها از برنامه نویس ها استفاده می کنیم . البته قابل ذکر است که این برنامه نویس ها که به جای مدیر پروژه قرار می گیرند حتما از تجربه و توانایی فنی بالایی برخوردار هستند ولی باز برنامه نویس هستند .

حکایت اینکه برنامه نویس مدیر پروژه می شود دقیقا مانند حکایت دندانپزشک شدن سلمونی ها در قدیم بود :

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

به نقل از نادر خرمی راد

http://images.travelpod.com/users/uncle_davros/the_world.1146204120.dhaka_-_019_street_dentist.jpgهم اکنون طبق گفته بالا ما مدیر پرژه نداریم بلکه سلمونی ها و یا برنامه نویس ها دارند اینکار رو برای ما انجام می دهند . منتهی تنها دلیلی که باعث می شود که یک برنامه نویس احساس مدیر پروژه بودن بکند چیزی نیست جز Halo Effect . یعنی طرف به عنوان برنامه نویس خیلی موفقه و به همین دلیل یک هاله نوری او را احاطه می کنه که می تواند به عنوان مدیر پروژه کار کند و بدین گونه می شود که برنامه نویس مدیر پروژه می شود .

اما و اما اخطار به مالکان شرکت ها : من قصد ندارم عرض بکنم که پروژه خود را به دست برنامه نویس ها ندهید ,  (بنده به عنوان برنامه نویس , مدیریت پروژه هم کرده ام ) ,  پروژه را به دست برنامه نویس های با تجربه بدهید و منتظر عواقب خوب و بد آن نیز باشید  مثلا امکان دارد عین سلمونی های قدیمی , دندون را طوری بکشد که پروژه درجا به دیار باقی بشتابد . یک مدیر پروژه واقعی می داند که در موقع شکست پروژه باید جوابگو باشد (ولی برنامه نویس چی ؟) یک مدیر پروژه می داند که باید در شرایط بحرانی چه کاری انجام دهد (برنامه نویس چی ؟) یک مدیر پروژه توانایی مدیریت منابع را دارا می باشد (یک برنامه  نویس چی ؟) و در کل کار و تخصص مدیر پروژه در حوزه مدیریت پروژه است ولی برنامه نویس در حوزه توسعه پروژه که در واقع سطح بندی متفاوتی دارند .

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

یاشیاسیز

ایجاد تیم های قدرتمند

ژوئیه 7, 2010 3 دیدگاه

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

https://i1.wp.com/ecx.images-amazon.com/images/I/41HGXP1C5ZL._SL500_AA300_.jpg

https://i2.wp.com/ecx.images-amazon.com/images/I/51sjDWgJXFL._.jpg

https://i1.wp.com/ecx.images-amazon.com/images/I/412y5AfggSL.__.jpg

https://i0.wp.com/ecx.images-amazon.com/images/I/51oOQhKSm5L.__.jpghttps://i1.wp.com/ecx.images-amazon.com/images/I/51qutgV40nL.__.jpg

یاشیاسیز

اسکرام فقط Scrum نیست

ژوئیه 4, 2010 3 دیدگاه

https://sirasad.files.wordpress.com/2010/07/head_scratching.jpg?w=422زمانیکه به اولین تجربه خودم در مورد اسکرام فکر می کنم ,  حسابی خنده ام می گیره . اسکرامی که من برای اولین بار یاد گرفتم و آن را درشرکت بر روی یک پروژه پیاده سازی کردم ,  اصلا اسکرام نبود . اسکرام ما کلا به یک Task Board من در آوردی ختم می شد . از جمله اشتباهاتی که در مورد اسکرام داشتم , می توانم به موراد زیر اشاره کنم :

  • Top-Down Management :  همانطور که می دانید یکی از اصول اصلی در Agile و اسکرام Self-Organize بودن نیروی کار(برنامه نویس) می باشد که ما به هیچ وجه چنین اجازه ای به نیروی کار نمی دادیم و شیوه Command-And-Control را با بدترین حالت ممکن به کار می بستیم .
  • طرح ریزی تیمی : به دلیل وجود مدیریت بالابه پایین ,  این مورد هم که امکان نداشت انجام شود . یعنی بنده همه چیز رو طرح ریزی می کردم و به تیم تزریق می کردم که در محیط های چابک بدینگونه عمل نمی شود .
  • تکرارهای کوتاه مدت : در اسکرام که حداکثر طول اسپرینت 4 هفته هست , ما اسپرینت 3 ماهه داشتیم .
  • بازبینی عملکرد : بازبینی عملکرد تیم پس از هر اسپرینت طی جلسه retrospective تقریبا امری است ضروری که ما ,  سال به سال چنین کاری رو انجام نمی دادیم .
  • همکاری با مشتری : همکاری ما خوب بود ولی مشکل ما  این بود : ما باید یک نفر را به عنوان Product Owner داشتیم در حالی که ما 400 نفر Product Owner داشتیم . خاله مدیر شرکت هم نظر می داد .
  • ارائه نرم افزار کارا : یکی از ارزش های اصلی Agile ارائه نرم افزار ارزشمند برای مشتری است به صورتی که نیازهای کسب و کار مشتری را برآورده کند ولی ما فقط در فکر سود و منفعت بیشتر برای شرکت بودیم و کاری نداشتیم که مشتری استفاده می کند یا نه .
  • با انگیزگی تیم : برای توسعه نرم افزار خوب در محیط Agile حتما نیاز به نیروی کار با انگیزه بود ولی در محیط ما چیزی که وجود نداشت انگیزه بود . اعتصاب های گوناگون ,  تاخیر در پرداخت حقوق , تورم ,  سهمیه شده بنزین و … از عوامل کاهنده انگیزه نیروی کار بود .
  • تست نرم افزار : یکی از کارهایی که هیچ وقت انجام نشد ,  نوشتن تست برای بخش های مختلف برنامه بود .
  • تولید کدهای خوب : بدلیل عدم وجود Automate Tests و تغییرات زیاد در طول پروسه توسعه نرم افزار ,  ما در نهایت دارای یک سری کد کثیف بودیم .
  • جوابگویی به تغییرات : یکی از مشکلات اساسی ما همین مورد بود . یا ما جواب نمی دادیم و اگر هم جواب می دادیم در دام Scope Creep می افتادیم . کدهای کثیف تولید می شد , برنامه قابلیت پشتیبانی را از دست می داد .
  • و …

اگر اهل فن باشید حتما خواهید دانست که مشکل ما در دو سطح متفاوت قابل بحث می باشد . اول سطح اسکرام دوم سطح Agile . اولا مشکل ما این بود که اسکرام را کاملا بلد نبودیم ( در آن زمان منابع زیادی برای یادگیری وجود نداشت (چه انگلیسی و چه فارسی ) ) . ثانیا ربط اسکرام با Agile را درک نکرده بودیم . بی تعارف عرض کنم که ما اسکرام را یاد گرفته بودیم بدون اینکه بدانیم Agile چیست و  از آن استفاده می کردیم؟؟!

برای همین است که یکی از دغدغه های من در این وبلاگ و یا آموزش این است که Scrum فقط Scrum نیست . اگر Scrum در خدمت Agile نباشد معنی نخواهد داشت و پیشنهاد من این است که برگردیم به متد قبلی که قبلا کار میکردیم . پس در آموزش خود  سعی کنید که از Agile به سمت اسکرام حرکت کنید .

البته یادگیری اسکرام چیزی نیست ,  شاید در عرض 2 ساعت بتوانید کل اسکرام را یاد بگیرید . ولی درک و یادگیری Agile  ومهمتر از همه ,  پیاده سازی تفکر Agile کاری است بس مشکل که با خواندن 1 عدد کتاب یا چند مقاله  امکان پذیر نخواهد بود. پس اسکرام فقط اسکرام نیست و برای استفاده از آن باید Agile را هم درک کرده باشید .

یاشیاسیز

چابک سازی سازمان و چرا ها

مه 18, 2010 5 دیدگاه

https://sirasad.files.wordpress.com/2010/05/agile.jpg?w=592طی درخواست یکی از مدیران شرکت توسعه نرم افزار پ .س (اسم نبردم شاید علاقمند نباشند) در مورد امکان مشاوره و مربی گری Agile بنده برای آن شرکت , 3 سوال اساسی توسط ایشان مطرح گردید که در این پست قصد طرح و جواب دادن این سوالات را دارم  . به این دلیل که شاید دیگر مدیران و یا اشخاص که علاقمند به دانستن و آشنایی با این مسئله باشند این جواب به صورت سرگشاده ارائه گردید .

سوالات مطرح شده به قرار زیر می باشد :

  • یک سازمان چه پیش فرض ها و نیازمندی هایی برای Agile شدن نیازدارد؟
  • برنامه من برای Agile کردن سازمان چیست ؟
  • عواید و منافع این کار برای سازمان چه چیز می باشد و چگونه می توان آن را اندازه گرفت؟

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

https://sirasad.files.wordpress.com/2010/05/a305-distributed-agile-development.jpg?w=280خوب بیان این مسئله و جواب سوال , » برای اینکه Agile بشویم چه چیز می خواهد»  در واقع بسیار سخت و مشکل می باشد بدلیل اینکه شرایط از هر تیم به تیم دیگر متفاوت خواهد بود و نمی توان یک نسخه واحد پیچید . ولی می توان گفت که Agile شدن برای تیم ها سختی و راحتی خواهد داشت . یعنی اینکه یک تیم با شرایط راحت تر و کم هزینه تر خواهد توانست Agile شود و یک تیم سخت و پر هزینه تر Agile خواهد شد . پس می توان گفت همه تیم ها و سازمان ها  شاید  توانایی Agile شدن را خواهند داشت ولی با درجه سختی متفاوت .

خوب شاید سوال کنید که این درجه سختی را چگونه می توان تعیین کرد . این درجه سختی را نمی توان جز با بررسی و ارزیابی  سازمان و اعضای سازمان تعیین کرد . باید تمام سازمان مورد ارزیابی قرار گیرد و بعد از ارزیابی می توان گفت که سازمان در چه وضعی است . در ارزیابی مهمترین مسئله توانایی و زمان Agile شدن است .

برای درک مسئله بهتر است یک مثال زده شود . فرض کنید بنده در تلویزیون مسابقه دو (دوندگی) را می بینم و مشاهده می کنم که به فرد برنده 400 میلیون دلار جایزه می دهند . با توجه به جایزه خوب وسوسه می شوم فردا در دوی مارتن شرکت کنم ولی بدون آمادگی و ارزیابی توانایی ها و ظرفیت های خودم . زمان مسابقه چند صد متر ندویده خسته می شوم و خواهم ماند . در این حالت دو حالت خواهم داشت :1- خواهم توانست تا به خانه برگردم و از دیدن مسابقه در تلویزیون لذت ببرم  2- ایست قلبی می کنم  و خداحافظ.

برای سازمان ها و شرکت های توسعه نرم افزار هم بدینگونه است . نمی توان با عجله و بدون ارزیابی توانایی سازمان و افراد شروع به چابک شدن کرد . مثلا فردا روز آقای مدیر از راه  می رسد و همه کارکنان رو جمع می کند و بعد از نطق در مورد فواید Agile می فرماید : «دوستان امروز می خواهیم Agile بشویم و سعی کنید تا امروز عصر کار را تمام کنید  ,  اینم مقالات وبلاگ دنیای چابک ,  زود بخونید تا شروع کنیم . هی ممد تو اسکرام مستر , خانم منشی به اون کاظمی (مشتری) زنگ بزن بیاد که اون Product owner ماست , دوستان زود باشید که سود ها و پول های کلان منتظر ما هستند و دیر بجنبیم از کف رفتند » .  و اینگونه خواهد بود که شاید بر خواهیم گشت به متد قبلی و یا ایست قلبی .

در مورد مثال دونده یک راه سومی هم وجود دارد و آن هم این است که من به موقع و در زمان مناسب در مارتن شرکت کنم . خوب عرض شد زمان مناسب ؟ زمان مناسب در این مثال این است که بنده به پیش یک مربی  دومیدانی بروم و او بنده را عرض یابی نماید و با توجه به توانایی جسمانی و روحانی بنده  ,  بنده را مورد آموزش و تمرین قرار دهد . زمانی که به توانایی لازم رسیدم می توانم در مارتن شرکت کنم . پس منتظر زمان مناسب خواهم بود .https://sirasad.files.wordpress.com/2010/05/tired_runner-758783.jpg?w=200

در مورد Agile هم باز بدینگونه است . اول سازمان باید مورد ارزیابی قرار بگیرد . باید (و دوباره باید) وضع و اوضاع فعلی سازمان استخراج و مستند سازی شود . به طور ساده باید فهمید که سازمان هم اکنون چگونه کار می کند و چگونه توسعه می دهد,  وضع ارتباطی آن با مشتری چگونه است اصلا چگونه مدیریت می شود و … . سپس با توجه به نقاط ضعف و کاستی های موجود , آموزش ها و توصیه های لازم باید اتخاذ شود .

شاید بپرسید شما که می خواهید Agile را پیاده سازی کنید چه کاری با وضع گذشته سازمان دارید ؟ درست است ما می خواهیم Agile را پیاده سازی کنیم ولی نه یک باره( تا سازمان سکته کند) . اصلاحا ما Agile را در کالبد تیم و پروسه قبلی تزریق خواهیم کرد و نه جایگزین . برای تزریق یک آمپول پنی سیلین باید آزمایش بدهید تا معلوم شود بدنتان حساسیت ندارد در صورت نداشتن حساسیت تزریق می شود در غیر اینصورت داروی جایگزین تجویز می شود .

ولی شاید توضیحات بالا تعدادی از مدیران را قانع نکند و آنها به دنبال فهمیدن و نام بردن چند عامل به صورت موردی می باشند .  خوب من می توانم چند مورد عمومی زیر را نام ببرم :

Agile می تواند در محیط ها و شرایط  زیر راحت ترو بهتر اعمال شود (و Agile کلا مناسب حال شرایط زیر می باشد) :

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

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

  • کمبود دانش Agile
  • تیم های بسیار بزرگ
  • توسعه به صورت توزیعی و گسترده به صورت فرا محلی
  • قراردادهای بسته (از نظر قیمتی و دامنه پروژه)
  • نیروی کار نابلد و یا نیروی کار تازه وارد و تازه تیم شده
  • حرکت به صورت سریع

موارد بالا شاید فقط تعدادی از موانع پیش روی تیم های و سازمان ها Agile هستند و برای اطلاعات بیشتر باید سازمان مورد بررسی قرار بگیرد .

برای جواب سوال شماره یک می توان به صورت خلاصه گفت که: شرایط زیادی می تواند در چابک شدن و یا نشدن سازمان دخیل باشد که به تعدادی از آنها در بالا اشاره شد ولی مهمترین اصل برای چابک شدن ارزیابی توانایی سازمان و تعیین زمان آمادگی برای چابک شدن می باشد .

اما در مورد سوال دوم . سوال شده است که برنامه بنده برای انتقال سازمان ها به Agile چه می باشد؟

برنامه و طرح بنده برای ارائه و کمک به سازمان ها برای انتقال به Agile شامل موارد زیر می تواند باشد:

  • بررسی سازمان و تعیین وضعیت فعلی سازمان
  • آموزش و نهادینه سازی ارزش ها و اصول Agile
  • آموزش اسکرام
  • برگزاری کارگاههای آموزشی در مورد متد اسکرام و XP
  • برپایی و استارت Agile در سازمان
  • بررسی وضع و نظارت بر عملکرد
  • برگزاری جلسات بازبینی عملکرد و تعیین روش های بهبود وضعیت

در حالت کلی برنامه در 4 سطح قابل تعریف خواهد بود : 1- بررسی 2- آموزش 3- اجرا 4- بازبینی

اما این طرح به صورت 100% نیست زیرا تیم ها و شرایط فرق می کنند و باید موارد و طرح هایی بعد از انجام کاری هایی پیش بینی شوند . یعنی آموزش به صورت 100% نیست . شاید در هنگام اجرا نیاز به آموزش دوباره تیم باشد . شاید بعضی از اصول Agile را باید فراموش کرد و شاید … و اینها همه به شرایط سازمان و افراد بستگی دارند. بدلیل اینکه عکس العمل و رفتار افراد در مقابل تغییرات قابل پیش بینی نیست ,  باید برنامه هایی در مورد عکس العمل های نشان داده شده بعد از اجرای Agile  طرح ریزی کرد .

ولی در کل هدف ما ارائه و عمل به مفهوم زیر در هر سازمان Agile خواهد بود :

https://sirasad.files.wordpress.com/2010/05/agilegoal.jpg

از طریق انجام و عمل به مفاهیم و اصول اصلی Agile خواهیم توانست به استراتژی درون سازمانی برسیم . مثلا با عمل به اصل «قبول و پذیرایی از تغییرات » که یکی از اصول Agile می باشد و در برنامه ما هم خواهد بود خواهیم توانست به یکی از استراتژی های اصلی سازمان که «ابقاء مشتریان » می باشد دست بیابیم  , که تحقق هر استراتژی سازمان مصادف با نزدیکی به هدف سازمان می باشد ,  که هدف سازمان شامل سود و منافع بیشتر می باشد .

اما در مورد سوال سوم . پرسیده شده است : «عواید و منافع Agile شدن  برای سازمان چه چیز می باشد و چگونه می توان آن را اندازه گرفت؟»

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

https://sirasad.files.wordpress.com/2010/05/agilechart.jpg?w=592

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

دانشی که از نمودارهای بالا حاصل شد گواه این قضیه خواهد بود که نباید انتظار داشته باشیم در چند روز به بهره وری مناسب  و بالا برسیم  . حتی باید منتظر پایین آمدن بهره وری هم باشیم . در همین باب در کتاب پنج دشمن کار تیمی می خوانیم :» برای جوش خوردن درست استخوان شکسته یک انسان ,  شاید لازم باشد دوباره آن راشکست و دوباره به هم متصل کرد و این درد آور خواهد بود ولی لازم است » .

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

اگر سازمان بتواند دوران بحران را به سلامت بگذراند خواهد توانست به منافع خوبی دست بیابد : اعم از رضایت مشتری ,  سود بیشتر و … . برای باور بهتر این قضیه بهتر است دست به دامن آمار و ارقام شویم و مشاهده کنیم که کشورهای موفق و پیشرفته جهان با Agile به چه دستاوردهایی دست یافتده اند .

شرکت  VersionOne در سال 2007 آمارگیری در زمینه Agile انجام داد . در این آمارگیری 1500 نفر از 71 کشور مختلف حضور داشته اند . در این آمارگیری VersionOne خواسته تا بداند این 1500 نفر در شرکت هایشان که با Agile کار می کنند تا چه حد موفق بوده اند و نتیجه آمارگیری به صورت زیربوده است : (شاید قابل باور نباشد)

https://sirasad.files.wordpress.com/2010/05/agilebenefit.jpg

هر یک از ستون ها یک شاخص بسیار مهم برای یک شرکت توسعه نرم افزار می باشد . مثلا شرکت ها اذعان داشته اند که بعد استفاده از Agile  توانسته اند 90%  به بهروری خود بیفزایند که بسیار گام خوبی می باشد یا 66% در هزینه ها کاهش داشته اند که بسیار عالی است . البته این اعداد در بهترین حالت ها و در کشورهای متمدن جهان با فرهنگی بالا در زمینه توسعه نرم افزار جمع آوری شده است و در ایران هم می توان به متوسط  این اعداد دست یافت (فردا روز یقه ما رو نگیرید که چرا ما به 90% بهروری بیشتر نرسیدیم ) .

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

البته برای هر یک از سوالات می توان چندین سمینار ارائه کرد و یا  کتاب نوشت ولی در این نوشتار امیدوارم توانسته باشم به سوالات مطرح شده  اندکی جواب بدهم .

یاشیاسیز

کار تیمی و آفت های آن

کارهای تیمی بدلیل وجود افراد مختلف با اعقاید و سلیقه های مختلف بعضا به یکی از چالش های اصلی سازمان مبدل می شود . کار تیمی در بسیاری از شرکت های ایرانی تقریبا مانند تحقق یک رویا است . کار تیمی در شرکت های ایرانی بدین صورت انجام می گیرد که یک نفر اصل کار و اهم کار را انجام می دهد و بقیه اعضای تیم (سیاهی لشکرها) ریزه کاری و خورده کاری ها را انجام می دهند . یعنی تیم هایی که وجود دارند اکثرا یک نفر محور هستند . به عبارت دیگر می توان گفت تیم همان یک نفر است و یک نفر همان تیم است . البته گذشته این آفت های دیگری برای تیم ها وجود دارد که :

برای پوشش و پرداخت به این مشکل , تصمیم به معرفی کتاب خوبی در باب کار تیمی و آفت های آن گرفتم .

https://sirasad.files.wordpress.com/2010/05/41ym2vz0x1l-_ss500_.jpg?w=500عنوان کتاب : The Five Dysfunctions of a Team

نویسنده : Patrick Lencioni

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

این کتاب به تمام گروه ها و افرادی که به صورت تیمی کار می کنند توصیه می شود بخصوص به تیم های Agile که بیشتر با یکدیگر سروکار دارند . از همه مهمتر مدیران پروژه و Scrum Master ها باید این کتاب را بخوانند .
خوشبختانه این کتاب به فارسی هم ترجمه شده است و در بازار یافت می شود . این کتاب در ایران با نام «پنج دشمن کار تیمی » شناخته می شود و توسط برادر گرامی آقای » فضل اله امینی » ترجمه شده است .

https://sirasad.files.wordpress.com/2010/05/5disfuctions-of-a-team.jpg?w=474

نام کتاب: پنج دشمن کار تیمی

ناشر: سازمان فرهنگی فرا

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

دریافت فایل خلاصه کتاب

یاشیاسیز

دسته‌ها:Project Management برچسب‌ها: ,

رهبری تیم و خصوصیات یک رهبر خوب

آوریل 15, 2010 7 دیدگاه

https://sirasad.files.wordpress.com/2010/04/dragon-boat-race.jpg?w=592در طی نوشته های قبلی در مود مدیریت پروژه به چندین وظیفه یک مدیر پروژه اشاره کردم که در این پست می خواهم در مورد خصوصیت رهبری یک مدیر پروژه صحبت نمایم . یک رهبر می تواند صرفا یک مدیر پروژه نباشد ولی هر مدیر پروژه باید رهبر هم باشد . این موضوع را از این حیث عرض کردم که  در بعضی از پروژه ها توسعه نرم افزار در ایران  شاهد این هستیم که نفری به عنوان یک مدیر پروژه وجود ندارد . در مواردی هم که وجود دارد , وی تنها کاری که انجام نمی دهد مدیریت پروژه است پس قابل ذکر است رهبر تیم یا Leader می تواند در تیم های توسعه نرم افزارخوب جواب بدهد و کافی باشد . این رهبر همانند سرمربی تیم های فوتبال عمل می کند و کار وی چینش بازیکنان و ارائه خط مشی بازی است.

در زیر لیستی از خصوصیات یک رهبر واقعی و خوب آمده است :

  • چشم ها را به سوی Big Picture می دوزد : زمانی که تیم با یک مسئله دشوار روبرو می شود ,  معمولا اعضای تیم ناخواسته از مسیر اصلی پروژه خارج می شوند بدلیل اینکه تمام حواس ویا بااصطلاح فوکوس تیم بر روی مسئله و یا مشکل جاری میرود. به عبارت دیگر مشکلی که وجود دارد این است که مشکل در حیطه خود مشکل حل می شود و نه نسبت به اهداف  کلی پروژه که مشتری انتظار دارد  . در این جا است که رهبر باید تیم را طوری هدایت نماید که تیم دوباره مشکل را بر اساس Big Picture و در راستای اهداف پروژه حل نماید . پس یکی از وظایف رهبر تیم ,  هدایت تیم زیر سایه Big Picture است.
  • نگه داری همبستگی تیمی : زمانی که پروژه با مشکل حادی مواجه می شود , مثلا در عرضه محصول تاخیر چند ماهه به وجود می آید و بدلیل فشار از طرف مشتری و مدیران شرکت ,  این فشار باعث می شود که همبستگی تیمی که در شروع پروژه به وجود آمده بود کم کم از بین برود . اعضای تیم به یکدیگر بد بین خواهند شد . همه دنبال تقصیر کار خواهند بود  و اگر اجازه بدهیم همدیگر را ترور خواهند کرد .  در ترکی یک مثل داریم که می گوید : «یر برک اولاندا ,  اوکوز اوکوز دن اینجییر »   معنی لفظی این مثل این می شود که شما فرض کنید دو تا گاو که در حال شخم زدن یک زمین زراعی می باشند اگر زمین مزرعه سخت و سفت باشد این گاوها از همدیگر ناراحت خواهند شد و هر یک دیگری را مقصر خواهند دانست . در اینجا است که رهبر تیم باید بتواند چنین شرایطی را کنترل و مدیریت نماید و سعی نماید که همبستگی تیمی خدشه دار نشود .
  • اولین فدایی هستند : اگر در پروژه لازم باشد که تیم سختی بکشد باید رهبر تیم اولین کسی باشد که این سختی را تحمل می نماید . اگر لازم باشد اضافه کاری بشود باید رهبر تیم بهترین کار خود را در این اضافه کاری انجام دهد . اگر لازم باشد در روز تعطیل مثلا جمعه ها ملت به سرکار بیایند باید رهبر تیم از همه زودتر بیاید  و از همه دیرتر برود .
  • توانایی آرامش : یک رهبر باید بتواند به مشکلات در آرامش و بدون هیچ وحشتی فکر نماید تا بتواند بهترین تصمیمات را بگیرد . اگر رهبر تیم وحشت زده شود صدرصد این وحشت را به اعضای تیم انتقال خواهد داد و پروژه به ناکجاآباد خواهد کشید . این مسئله عین این است که تیم فوتبال ما 2 گل خورده است و دقیقه 60 بازی است و مدیر باشگاه می گوید اگر بازی را ببازید همه شما را اخراج خواهم کرد  . مربی اگر بتواند آرامش خود را حفظ نماید پس خواهد توانست تصمیمات عاقلانه ای را بگیرد در غیر اینصورت کل تیم را مضطرب خواهد کرد و تیم 5 تا گل دیگر خواهد خورد.
  • انگیزه بخشی : یکی دیگر از وظایف رهبر تیم توانایی انگیزه بخشی به اعضای تیم می باشد که در این مورد در پست قبلی به صورت مفصل صحبت کردیم .
  • خلق پیروزی های کوچک : در پروژه های توسعه نرم افزار خروجی همانند فتح قله اورست می باشد . زمانیکه پروژه Deploy شد و مشکلی خاصی در عرضه محصول به مشتری نبود همه اعضای تیم در حال پرواز می باشند و انگار در جنگ جهانی پیروز شده اند و در حال برگشت به خانه هستند . در متدولوژی هایی مانند RUP یا Waterfall این خروجی بعد چندین ماه و یا سال به وجود می آید که باعث دلمردگی و فرسودگی افراد و اعضای تیم می شود ولی اگر تیم به سبک Agile کار نماید ,  بدلیل اینکه خروجی مثلا هر 3 هفته یک بار به وجود می آید پس هر 3 هفته شاهد یک پیروزی خواهیم بود . معمولا به یمن و شادباش این پیروزی بعد از هر Sprint به همه اعضای تیم 2 , 3 روزی مرخصی داده می شود تا بتوانند طمع خوش پیروزی را بچشند .

مواردی که برشمرده شد از وظایف و خصوصیات یک رهبر موفق در تیم های توسعه نرم افزار می باشد . امیدوارم رهبران خوبی برای تیم های خود باشید .

یاشیاسیز