درسی در بازاریابی نرم‌افزار: مناسب زمان رفتار کنید

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

چهار گروه

مردم در بخش شما از بازار به چهار گروه تقسیم می‌شوند:

  • پذیرندگان آغازین (Early Adopters) ریسک پذیرانی هستند که آزمودن چیزهای نو را به‌راستی دوست دارند.
  • واقع‌بینان (Pragmatists) کسانی هستند که ممکن است بخواهند فناوری نو را بکارگیرند اگر تنها راهی باشد که مشکلشان با آن حل می‌شود.
  • محافظه‌کاران (Conservatives) از فناوری نو خوششان نمی‌آید و تلاش می‌کنند از آن دوری کنند.
  • واماندگان یا دیرپذیران (Laggards) به خودشان می‌بالند که واپسین کسانی هستند که هر چیز نو را می‌آزمایند.

کتاب‌های بازاریابی معمولا این گروه‌ها را به شکل یک منحنی زنگوله ای نشان می‌دهند، چیزی شبیه این:

Bell Curve

منحنی زنگوله‌ای دو نکته مهم را نشان می‌دهد:

  • دو گروه میانی بیشتر مشتریان باقوه شما را شامل می‌شوند.
  • شما تنها به نوبت و از چپ به راست می‌توانید به این مشتریان دست پیدا کنید.

 
هرکدام از این چهار گروه رفتار ویژه خود را دارند که نشان دهنده هنگامی است که آن گروه محصول شما را خواهد خرید:

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

~~~

پرتگاه

برای اینکه موفق شوید به مرور باید محصول خود را به واقع‌بینان و محافظه‌کاران بفروشید، اما رفتار این دو گروه با رفتار آن دو گروه دیگر در دو سر منحنی زنگوله‌ای به کلی متفاوت است و به ویژه اینکه این دو گروه میانی روحیه‌ای پیرو‌-وار دارند. آنها دنباله‌رو هستند. آنها تنها زمانی می‌خرند که ببینند دیگران این کار را می‌کنند.
 
البته محافظه‌کاران مشکل چندانی ندارند. آنها واقع‌بینان را به دقت می‌نگرند. هنگامی‌که بیشتر واقع‌بینان از محصول شما خشنود باشند، آنها محصول شما را خواهند خرید. شما مجبور نیستید برای جذب محافظه‌کاران حرکت خاصی انجام دهید. زمانیکه واقع‌بینان شما را دوست داشته‌باشند آنگاه محافظه‌کاران به دنبال آنها خواهند آمد.
 
مشکل اصلی واقع‌بینان هستند. آنها دنباله‌رو هستند، اما دوست دارند تنها از همدیگر دنباله‌روی بکنند. اینکه آنها به‌سادگی منتظر گروه پیشین خود خواهند ماند که محصول شما را دوست بدارند فکری وسوسه کننده اما نادرست است. پذیرش پذیرندگان آغازین کافی نیست. این‌کار مانند آغاز رقص در یک جشن است، همه به همدیگر نگاه می‌کنند و منتظر می‌مانند تا کسی دیگر نخستین حرکت را بکند.
 
جفری مور (Geoffrey Moore) به خوبی این رفتار را در کتاب برجسته خود «گذر از پرتگاه» (Crossing the Chasm) شرح داده است. مور بیان می‌دارد که منحنی بازاریابی زنگوله‌ای کلاسیک نادرست است و درواقع باید بیشتر شبیه این شکل نمایش داده شود:

bell2_1.gif

این طرح نشانگر این واقعیت است که بین پذیرندگان آغازین و واقع‌بینان گذاری پیوسته یا منطقی وجود ندارد. بین پذیرندگان آغازین و واقع‌بینان یک پرتگاه (chasm)هست. برای اینکه محصول خود را با موفقیت به واقع بینان بفروشید باید از این پرتگاه گذر کنید.
 
اما اگر واقع‌بینان نمی‌خرند مگر زمانیکه همدیگر را در حال خریداری بینند، چگونه به آن‌سو برویم؟
 
کلید کار یافتن واقع‌بینی است که نیازمند و ناچار است، یا آنگونه که مور می‌گوید، واقع‌بین گرفتار. آنها مشکلی دارند و به شدت نیاز دارند که مشکلشان حل شود. در واقع، آنها آنچنان نیازمند راهکار هستند که می‌پذیرند از رده هم‌قطاران واقع‌بین خود جدا شده و نخستین کسی از گونه خود باشند که محصول شما را می‌آزماید.
 
شما به روابطی بسیار ویژه با این واقع‌بینان گرفتار نیاز دارید. آنها همکاری با شرکت‌های کوچک نرم‌افزاری را دوست ندارند. ترجیح می‌دهند با شرکت‌های بزرگ و جا افتاده تر کار کنند.آنها با گزیدن محصول شما برای خرید به شما کمک می کنند که از پرتگاه گذر کنید. شما به واقع مستحق اینکه آنسو باشید نیستید و آنها این را می‌دانند.
 
بنابراین باید به‌گونه‌ای ویژه با آنها رفتار کنید. هرچه می‌خواهند به آنها بدهید، کمابیش مثل اینکه آنها برنامه‌ای سفارشی درخواست داده‌اند. ممکن است که نیاز باشد شما ویژگی‌های خاصی را تنها برای آنها پیاده‌سازی کنید. ممکن است مجبور شوید تخفیف زیادی به آنها بدهید. باید سایت آنها را ببینید و به‌شخصه با آنها دیدار کنید. شاید مجبور شوید محصولتان را برای آنها نصب کنید. به احتمال زیاد از دید مالی، این ضرری خالص خواهد بود. اشکالی ندارد. تا زمانیکه آنها خشنود نشده‌اند دست بر ندارید. سپس آنها را خشنود نگه دارید، تا جاییکه شرکت شما کم و بیش دایم در کنار شرکت آنها دیده شود.
 
از آنجا که گذر از پرتگاه سخت است، ممکن است وسوسه شوید که تنها در سمت چپ آن باقی بمانید (و از آن گذر نکنید). شاید پذیرندگان آغازین بازاری داشته‌باشند که به اندازه کافی برای محصول شما بزرگ باشد. متاسفم انا این جواب نخواهد داد. پذیرندگان آغازین چیزهای نو را دوست دارند و محصول شما هر روز کهنه‌تر می شود. اگر تلاش کنید که عمر محصول خود را برای پذیرندگان آغازین بسازید، خطر این را پذیرفته‌اید که شما را رها کنند و به سراغ کس دیگری بروند که مدعی داشتن محصولی با آخرین فناوری عالی است.در بلند مدت، ماندن در سمت چپ پرتگاه کاری ایمن و خردمندانه نیست.
 
~~~

چند نمونه

چند نمونه را ببینید (توجه کنید که این مقاله سال ۲۰۰۳ نوشته شده):

  • SourceOffSite از پرتگاه گذر کرده است. زندگی در آنسو خیلی خوب است. بیشتر شرکت های فرچون ۵۰۰ در فهرست مشتریان ما هستند. محصول بسیار سودده است.
  • اما SourceGear Vault هنوز پیش از پرتگاه است. ما نسخه ۱.۰ خود را بیرون داده‌ایم و پذیرندگان آغازین عاشقش هستند. ما در حل پایان کار نسخه ۱.۱ هستیم که شامل بهبودهایی است ولی این نسخه هم ما را گذر نخواهد داد. خوشبختانه دنیای SourceSafe پر از واقع‌بینان نزار است. همزمان که داریم روی نسخه ۲.۰ کار می‌کنیم در حال مذاکره با چندتایی از آنها هستیم.
  • ویندوز مایکروسافت بسیار آنسوتر از پرتگاه رفته است.
  • روشن است که CRM مایکروسافت هنوز در سرزمین پذیرندگان آغازین است. غول ردموند بسیار راحت‌تر از من و شما می‌تواند از پرتگاه گذر کند، اکا او هم مجبور است گذر کند. و درست مانند دیگران، بیشتر محصولات نو مایکروسافت تا نسخه ۳.۰ گذر نخواهد کرد.
  • برخی از دوستان من و دوست‌داران NET. با من مخالفند اما من هنوز NET. را پیش از پرتگاه می‌دانم. آیا NET 2.0 . به آنسوی پرتگاه خواهد رسید، یک نسخه زودتر از همیشه؟ شاید.
  • به‌قطع Java پس از پرتگاه است.
  • دستگاه پخش DVD آنسوی پرتگاه است. راستش پدر و مادرم تازگی یک دستگاه گرفته‌اند و این بازار آرام‌آرام دارد واماندگان را جذب می‌کند.☺
  • وبلاگ‌ها چطور؟ پیش یا پس از پرتگاه؟ با وجود رشد بسیار محبوبیت آنها در چند سال گذشته باید بگویم که وبلاگ‌ها هنوز پیش از پرتگاه هستند و هنوز بسیاری از توانایی‌های آنها باید شناخته شود.
  • دوربین دیجیتال در همین چندساله از پرتگاه گذر کرده است.
  • PDA ها از پرتگاه گذر کردند، آنگاه تعادل خود را از دست دادند و به درون افتادند.☺

~~~

مناسب زمان رفتار کنید

زیاد شتاب نکنید. گذر زمان در این منحنی زنگوله‌ای معمولا با سالیان سنجیده می‌شود نه با هفته‌ها و ماه‌ها. این چهار گروه و گذر بین آنها نشانگر مراحل مختلف از عمر محصول شماست. هرکدام از این مراحل بسیار متفاوت هستند. اگر مناسب هرکدام از این مراحل عمر محصولتان رفتار کنید، کارها بسیار بهتر پیش خواهد رفت.
 
دختران نه‌ساله آرایش غلیظ نمی‌کنند. شصت و پنج ساله‌ها آغاز به دانشگاه رفتن نمی‌کنند. سی و دو ساله‌ها آنگونه که ده سال پیش می‌کردند تمام شب را بیدار نمی‌مانند.(البته روشن است برای هرکدام از این‌ها استثناهایی هم هست)☺
 
به همین شکل محصولات نیاز دارند که مناسب عمرشان رفتار کنند. گزیدن ویژگی‌ها(ی محصول) بخشی از بازاریابی است. هنگامی‌که تصمیم می‌گیرید چه ویژگی‌هایی در نسخه بعد گنجانده شوند باید مرحله کنونی از عمر محصولتان را در نظر داشته باشید. چند نمونه برای روشن‌تر شدن:

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

~~~

پی‌نوشت

از دوستداران جفری مور که فکر می‌کنند چیزها را زیادی ساده‌کرده‌ام پوزش می‌خواهم. من خوره‌ای هستم که تلاش می‌کند بازاریابی را برای دیگر خوره‌ها شرح دهد. پس دوراندیشی است اگر بیشتر از این موشکافی نکنم.☺
 
خوانندگانی که جزییات بسیار بیشتری می‌خواهند قویا کتاب‌های «گذر از پرتگاه» (Crossing the Chasm) و کتاب بعدیش «درون گردباد» (Inside the Tornado) که آنهم کتاب بسیارخوبی است را توصیه می‌کنم.
 
این نوشته برگردانی است از:

Sink, Eric. “Act Your Age

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

در شرکتتان برنامه‌ساز نیاز دارید، نه برنامه‌نویس

پیشتر در پستی درباره واژگان برنامه‌سازی و برنامه نویسی سخن گفتم.
اینک مقاله‌ای بسیار مفید برای کسانی‌که در فکر راه‌اندازی شرکتی نرم‌افزاری هستند به فارسی برگردانده‌ام. گرچه ازدید خودم ترجمه‌اش خوب در نیامد و نیاز به بازبینی و ویرایش دارد:

در شرکتتان برنامه‌ساز نیاز دارید، نه برنامه‌نویس

موقعیت بسیار مهم است. پند یک مدیر ممکن است بی‌ارزش یا بدتر باشند اگر مناسب وضعیت شما نباشد. تصمیمی درست برای شرکتی بزرگ ممکن است برای کوچک‌تر کشنده باشد. پیش از آنکه پیشنهاد‌های مدیریتی هرکسی از جمله من را بشنوید‍ ☺، مطمئن شوید که موقعیت خودتان را مدنظر دارید.
من یک شرکت نرم‌افزاری کوچک را می‌گردانم بدون هیچ کمک مالی بیرونی. شرکت ما (SourceGear) حدود ۶ سال سن و ۲۵ کارمند (در زمان نوشته شدن این مقاله: سال ۲۰۰۳) دارد.

در این مدت درس‌های بسیار جالبی فرا گرفته‌ام. یکی از چیزهایی که یادگرفته‌ام این است که شرکت‌های نرم‌افزاری کوچک نباید هیچ برنامه‌نویسی داشته باشند.

در این مقاله منظور از برنامه‌نویس (Programmer) فردی است که کاری جز نوشتن کُدهای نو و (اگر خوش‌شانس باشید) اشکال‌زدایی، نمی‌کند. او مشخصه‌ها(Specifications) را نمی‌نویسد. او تست‌کیس‌های خودکار را نمی‌نویسد. کمکی برای اینکه سیستم ساخت خودکار بروز باشد، نمی‌کند. به مشتریان کمک نمی‌کند تا مشکلات جدی‌شان را حل کنند. در نوشتن مستندات کمک نمی‌کند. او حتا کُد را هم نمی‌خواند. تنها کاری که او می‌کند نوشتن کد جدید است.

در شرکت‌های کوچک نرم‌افزاری شما یک چنین آدم‌هایی را نمی‌خواهید.

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

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

~~~

حدود (وظایف و اختیارات) در برابر انعطاف‌پذیری

این تفاوت‌ به‌راستی مهم بین شرکت‌های کوچک و بزرگ است:

  • در شرکت کوچک بیشتر افراد نقش‌های مختلف دارند. امکان‌پذیر نیست که فردی داشته‌باشید که تنها روی یک زمینه تمرکز می‌کند. شرکت‌های کوچک افراد همه‌فن‌حریف‌ی را نیاز دارند که به شرکت اهمیت می‌دهند و برای هرکاری که به شرکت کمک کند، پیش‌قدم می شوند. حسابدار یا کتابدار هرکاری را سر-و-سامان می‌دهند. معمولا کسانی وجود دارند که همه کارها را انجام می‌دهند و سرشان همیشه شلوغ است و هیچ‌کس هم نمی‌داند که آنها چه می‌کنند. در اینجا مفهوم کلیدی انعطاف‌پذیری است.
  • شرکت شرکت‌های بزرگ متخصصان بیشتری دارند. دستمزدها با «حساب‌های دریافتنی» فرق‌ می‌کند که آن‌هم از «حساب‌های پرداختنی» جداست. معماران نرم‌افزار، طراحی می‌کنند. برنامه‌نویسان کُد می‌نویسند. مدیران فنی برنامه‌نویسان را مدیریت می‌کنند. مدیران پروژه (برنامه) ها مشخصه و زمانبندی را پیگیری می‌کنند. مدیران محصول جایگاه‌سازی و پیام‌رسانی می‌کنند. مبلغان، خوب، کسی به راستی نمی‌داند که آنها چه می‌کنند.☺ به هرحال هرکسی کاری مشخص و تعریف‌شده دارد. مفهوم کلیدی اینجا احترام به حدود (وظایف و اختیارات) است.

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

~~~

برنامه‌سازان

در شرکت کوچک نرم‌افزاری هر برنامه‌سازی پیش و بیش از هر چیز برنامه‌نویس است. بخش اصلی وقتش باید صرف نوشتن کُد و اشکال‌زدایی گردد. اما نیاز است که برنامه‌سازان در دیگر زمینه‌ها هم کمک کنند، زمینه‌هایی چون:

  • مستندات مشخصه‌ها
  • مدیریت پیکربندی
  • بازبینی کُد
  • تست کردن
  • تست‌های خودکار
  • مستندسازی
  • حل مشکلات جدی مشتریان

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

زمانیکه تیم برنامه‌نویسان شما به مرور برنامه‌ساز می‌شوند، شاید سلسله مراتب کاری شما تغییر کند. ممکن است که بهترین برنامه‌ساز شما همان کسی نباشد که مشکلات به‌راستی سخت را برطرف می‌سازد. یک برنامه‌نویس با استعداد فراوان می‌تواند برنامه‌سازی بسیار بد باشد.کُدنویسی بخشی لازم اما ناکافی برای برنامه‌ساز بودن است. همینگونه، افراد با استعداد کمتر در تیم شما هنوز می‌توانند خودشان را به عنوان برنامه‌سازانی عالی نشان دهند با مشارکتی که در بخش‌های غیرکُد نویسی محصول می‌کنند.

~~~

پرسشهای پُربسامد (متداول)

می‌توانیم برنامه‌نویسانِ خود را فقط به کُدنویسی بگماریم و برای همه دیگر کارها گروهی دیگر را بکاربگیریم؟

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

برنامه‌نویسان ما نمی‌دانند که چگونه همه این کارهای دیگر را انجام‌دهند؟

راستی؟ مطمئن هستم که دانشکده‌های کامپیوتر ابزارهای مدیریت زنجیره تامین (SCM) و مهارت‌های پشتیبانی فنی را درس می‌دهند، درست؟☺

گرچه دانشکده من این چیزها را یاد نمی‌داد. روشن است که برنامه‌نویسان شما نمی‌دانند که چگونه جنبه‌های جز-کُدنویسی ساخت محصول را انجام‌ دهند. به آنها آموزش دهید.

آموزش رسمی ممکن است نقشی ایفا کند، اما بهترین یادگیری از تجربه می‌آید. برنامه‌سازان شما باید پند شرکت نایکی (Nike) «انجامش بده» را بکار بندید. مطمئن شوید که آنها فرصت اشتباه داده‌اید. به آنها اجازه دهید از اشتباهاتشان یادگیرند.

برنامه‌نویسان ما نمی‌خواهند همه این کارها را انجام دهند

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

سرانجام با توجه به موقعیت خود می‌توانید تصمیم بگیرید که در این باره چه کنید. پیشنهاد من این است که هر برنامه‌نویسی در شرکت نرم‌افزاری کوچک نیاز دارد که در چیزی فراتر از کُدنویسی دخالت داشته باشد، البته تمام قاعده‌ها استثنا هم دارند.

آیا یافتن برنامه‌سازی که مهارت‌هایی اینچنین گوناگون دارد، سخت نیست؟

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

زمانیکه شدند، باید بسیار تلاش کنید که آنها را نگه‌دارید. هنگامیکه برنامه‌نویسی از شرکت جدا می شود یا در شرکتی بزرگ شغل مدیریتی می‌گیرد یا شرکت خو را برپا می‌کند.

چگونه برنامه‌سازان کُد بنویسند در حالیکه پیوسته با کارهای دیگر در کارشان وقفه می‌اندازند؟

بله، این مساله‌ای است. از این فرصت بهره می‌جویم تا از اصل اریک (خودم) در مدیریت نرم‌افزار یاد کنم:

نمی‌توانید مسایل را حذف کنید،
اما می‌توانید بده-بستانی انجام‌دهید
مسایلی که هم‌اکنون دارید را بدهید
در برابر آنها مسایلی را که ترجیح می‌دهید، بستانید.

برنامه‌سازان وقت آزاد بیشتری نیاز دارند وگرنه هیچ کُدی نخواهند نوشت. خوب این مساله‌ای است که ترجیح دارد برمسایلی که برایتان پیش خواهد آمد هنگامی‌که با افرادی با چشم‌انداز باریکِ «تنها کُد» سروکار پیدا می‌کنید. تلاش کنید زمان خود را ساماندهی کنید. برای نمونه در یک روز همزمان کُدنویسی و پشتیبانی فنی را انجام‌ ندهید.

پس شما می‌گویید که برنامه‌سازان ما مجبورند همه دیگر کارها را انجم دهند؟

خیر. بهتر این است که برنامه‌سازان هنوز بیشتر(اما نه همه) وقتشان را صرف نوشتن کُد کنند. اگر بودجه شما اجازه می‌دهد دسته‌های گوناگونی از متخصصان هستند که می‌توانید بکار بگیرید:

پشتیبانی فنی «سطح یک»

بیشتر کار پشتیبانی فنی شامل پاسخگویی پیاپی به پرسشهای یکسان است.احتمالا اینکار بهترین کاربری از وقت یک برنامه‌ساز نیست. برنامه‌ساز را در پشتیبانی فنی «سطح دو» درگیر کنید؛ تشخیص و حل مشکلات سخت و پیچیده مشتریان. اما اینکه یک یا دو متخصص برای رسیدگی به کارهای ساده‌تر داشته باشید، ایده خوبی است. برای اینکار دنبال فردی بگردید که مهارت‌های ارتباطی خوبی دارد و پیش‌زمینه‌ای هم در مسایل فنی.

تستِ دستی، بازبینی اشکال‌زدایی و …

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

مستندسازی

برنامه‌سازانتان را مجبور کنید که مشخصه‌ها یا پیش‌نویس نخست محتوا را بنویسند، اما آماده‌سازی و ویرایش نهایی و ویرایش مستندات شما کاری است که برای کسیکه می‌تواند بنویسد مناسب است.

مدیر سیستم (System Administration)

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

این نوشته برگردانی است از:

Sink, Eric. “Small ISVs: You need Developers, not Programmers

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

Balatarinاین نوشته را به بالاترین بفرستید:

راز موفقیت

“قربان! راز موفقیت شما چیست؟”

“دو واژه”

“خوب، آن دو واژه چه هستند؟”

“تصمیم‌های درست”

“حال شما چگونه تصمیم‌های درست می‌گیرید؟”

“یک واژه”

“آن چیست؟”

“تجربه”

“شما چگونه تجربه می‌اندوزید؟”

“دو واژه”

“آنها چه هستند قربان؟”

“تصمیم‌های نادرست”

اصل این نوشته را از از اینجا آورده‌ام

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

نظریه بازی‌ها – راه برنده شدن

داشتم در آرشیوم از ماهنامه خوب شبکه جستجو می‌کردم، در شماره ۳۹ به مقاله‌ نظریه بازی‌ها – راه برنده شدن که درآمد و تاریخچه‌ای بر نظریه بازی‌ها است برخوردم، پس از جستجو دریافتم که خوشبختانه این مقاله در سایت مجله موجود است: برای دیدن صفحه به اینجا و برای گرفتن متن کامل مقاله (PDF) به اینجا نگاه کنید.

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

درس‌هایی در نظریه بازی‌ها و طراحی مکانیسم

آنچه درپی می‌‌آید فهرستی از پیوند‌ها به صفحه‌های وب درس‌های ارایه شده در دانشکده‌های کامپیوتر معتبرترین دانشگاه‌های جهان درباره “نظریه بازی‌ها” و “طراحی مکانیسم” است:

۱٫ Asu E. Ozdaglar’s Game Theory with Engineering Applications
۲٫ David C. Parkes’s Computational Mechanism Design
۳٫ Noam Nisan’s Course on CS, Game Theory, and Economics
۴٫ Christos Papadimitriou’s Course on Algorithmic Aspects of Game Theory
۵٫ Joan Feigenbaum’s Course on Economics and Computation
۶٫ Jeff MacKie-Mason’s Course on Information Economics
۷٫ Amy Greenwald’s Course on Agent-Based Economics
۸٫ Yoav Shoham’s Multi-Agent Systems Course
۹٫ Subhash Suri’s Course on Computation and Market Mechanisms
۱۰٫ Tuomas Sandholm’s Course on Foundations of Electronic Marketplaces
۱۱٫ Peter Cole’s and Al Roth’s Market Design Course
۱۲٫ Kate Larson’s Electronic Market Design Course

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

جدول تکاملی نام‌تجاری

این جدول بسیار جالب را ببینید، به مانند جدول “جدول تناوبی عناصر” درست شده و واژگان بنیادین بازاریابی و کسب و کار در آن شرح‌داده شده. موس را بر روی هر عنصر بگیرید تا توضیح را ببینید.

branding definitions

نظریه‌ی الگوریتمی بازی‌ها

یکی از گرایش‌های نو در کامپیوتر “نظریه‌ی الگوریتمی بازی‌ها” یا Algorithmic Game Theory است. این گرایش که به تازگی طرفداران زیادی هم پیدا کرده یکی از فصل های مشترک کامپیوتر و اقتصاد است و همانگونه که از نامش بر می‌‌آید به جنبه‌های الگوریتمی نظریه‌ بازی‌ها، مکانیسم‌های طراحی شبکه، اقتصاد و طراحی مکانیسم‌ها می‌پردازد و یکی از پرکاربردترین زمینه‌های کامپیوتر است.

برایم جالب بود که یکی از کسانی که در این زمینه کار می‌کند یک ایرانی است: سید وهاب میررکنی مهندسی کامپیوتر خود را از شریف گرفته و دکترا و فوق‌دکترایش را از MIT، وی همچنین برای مایکروسافت و IBM کارکرده است.

هر روز که می‌گذرد جنبه‌های مشترک بیشتری بین کامپیوتر و اقتصاد می‌یابم، برای نمونه “فون نویمان” که ما کامپیوتری‌ها او را از بنیان‌گذاران و نظریه‌پردازان کامپیوتر‌های امروزی می‌دانیم و هنوز هم معماری‌ کامپیوتر‌هایی را که بکار می‌بریم “معماری فون‌ نویمانی” می گوییم، از پایه‌گذاران نظریه بازی‌ها است.

راستی کسانی که می‌خواهند با نظریه بازی‌ها آشنا شوند، نخست فیلم “ذهن زیبا” (A Beautiful Mind) که به فارسی هم دوبله شده است را ببینند، این فیلم بسیار زیبا شرح زندگی “جان نش” ریاضی دان بزرگ است که به خاطر کارهای درخشانش در نظریه بازی‌ها، جایزه نوبل اقتصاد سال ۹۴ را برد. نظریه‌ای بسیار جالب است که در اقتصاد،علوم سیاسی و استراتژیک، مذاکره، مدیریت و کامپیوتر کاربرد فراوان دارد و اگر اشتباه نکنم تا به حال جابزه نوبل را نصیب ۷ نفر کرده است، از جمله امسال که جایزه نوبل به خاطر “طراحی مکانیسم‌ها” -یکی از شاخه‌های نظریه‌ی بازی‌ها- نصیب ۳ نفر گردید. (پست “چه کسانی اقتصاد را دوست دارند و چه کسانی ندارند!!؟؟” را ببینید.)

تمام کسانی که بر روی “نظریه‌ی الگوریتمی بازی‌ها” کار می‌کنند کامپیوتری هستند و زمینه خوبی برای کار و پژوهش به ویژه در کارشناسی‌ارشد و دکترا است.

به تازگی (یک ماه پیش) کتابی با همین نام “Algorithmic Game Theory ” توسط انتشارات دانشگاه کمبریج چاپ شده که نسخه‌ای از آن از اینجا قابل دریافت است و برای کسانی که می‌خواهند در این باره بیشتر بدانند، بسیار عالی است.

همینطور اگر خواستید درباره چهار نویسنده (ویراستار) کتاب، زمینه‌های پژوهشی و درس‌هایی که ارایه می‌کنند بیشتر بدانید:

Vijay V. Vazirani
Tim Roughgarden
Éva Tardos
Noam Nisan

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

فایر‌فاکس + پارسی: ارمغانی از آسمان

من فایرفاکس را بسیار دوست دارم، مدت‌ها پیش از آنکه نسخه ۱٫۰ آن بیرون بیاید آن را نصب کردم و درجا دلبسته آن شدم. حتا نامش را دوست دارم و هنگامیکه نامش در دبیان و پیرو آن در پارسیکس تغییر کرد بسیار ناراحت شدم.

از دیگر اخلاق من این است که به شدت از نرم‌افزارهای فارسی شده دوری می‌کنم. وقتی نخستین بار درباره افزونه یا همان “ترجمه فارسی فایرفاکس” خواندم، با تردید و از روی کنجکاوی آنرا نصب کردم. اما چیز دیگری بود، از آن لذت بردم و بکار بردن آن‌را توصیه می‌کنم:

۱٫ نخست اینکه این کار علمی و رسمی صورت‌گرفته بود و افزونه از سایت رسمی بنیاد موزیلا دریافت می‌شد و آنها این افزونه را آزموده و تایید کرده بودند.

۲٫ نصب بسیار بسیار آسان بود، تنها کافی بود تا روی دکمه “Install Now ” کلیک کنی تا برنامه نصب گردد. (در نسخه های پیشین نصب Quick Locale Switcher هم لازم بود- البته به همان سادگی- اما در نسخه ۲٫۰٫۰٫۸ این کار هم لازم نیست) آموزش نصب را اینجا می‌توانید ببینید.

۳٫ این کار را شیر مردی به نام “بهرام مراوندی” به تنهایی انجام داده بود، مهندسی ایرانی که برون از ایران کار می‌کند و این کار را از روی علاقه انجام داده بود. (راستی براساس آخرین اطلاعات آقای مراوندی اصفهانی است)

۴٫ از دیگر مزایای این ترجمه این بود که با بروزشدن‌های فایرفاکس بروزمی شد.

این پروژه ادامه پیدا کرد تا امروز که گسترش پیدا کرده و افزونه های دیگری نیز پارسی شده و می‌شود.

به‌تازگی سایتی جدا (http://www.mozillafirefox.ir) برای پروژه فایر فارسی راه‌اندازی شده است، سایتی شکیل به همراه راهنماها و آموزش هایی کاربردی به فارسی. که آقای مراوندی به تنهایی آن را راه اندازی کرده و نگهداری می کند.

این سایت دارای بخشهای مختلف از جمله برنامه‌نویسی، بلاگ، افزونه‌ها و راهنما است. صفحه‌اصلی آخرین اخبار مرتبط با فایرفاکس و پروژه را دربردارد.http://www.mozillafirefox.ir/

راهنمای آن عالی است و همه چیز را برای تبدیل یک فرد به یک کاربر حرفه‌ای داراست، از مدیریت کوکی‌ها گرفته تا فهرست کلیدهای میان‌بر فایرفاکس.

در بخش افزونه‌ها به جز “ترجمه فارسی فایرفاکس” افزونه‌های دیگری فهرست شده‌اند، به آنها پیوند داده شده و شرحی کوتاه هم آورده شده از جمله این افزونه‌ها: برنامه‌های فارسی فایرفاکس، سالنامه ایرانی، جی‌میل راست به چپ، پشتیبان‌گیری فایرفاکس هستند.

بلاگ خوبی هم دارد که خودم در Google Reader عضو شدم تا با آن هماهنگ باشم.

بخش برنامه نویسی هم به کار کسانی می‌آید که می‌خواهند برای فایرفاکس برنامه‌نویسی کنند و بخش زیبایی است.

اما این تصویری که در کنار می‌بینید، نواری است که در کنار سایت قرار دارد و حاوی پیوند به مهمترین نوشته‌های سایت است (دست‌کم از دید من): “برنامه نویسی اولین افزونه”: در ۳ قسمت، راهنمایی است برای نوشتن افزونه‌های دلخواه برای فایر فاکس، “شرح کامل about:config” راهنمای کامل شخصی‌سازی و پیکربندی دلخواه آن ووو…. حتما سایت را ببنید و آنرا پیگیری نمایید.

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

پ.ن: در پست “چرا دانشجویان ایرانی باید در پروژه های آزاد/بازمتن مشارکت کنند!؟” به دانشجویان توصیه کردم که به دلایلی- که آنجا آورده ام- درپروژه‌های آزاد/بازمتن مشارکت کنند. یکی از پروژه‌های مفید و کاربردی که دانش برنامه‌نویسی زیادی هم لازم ندارد، این پروژه است: بشتابید.

برنامه‌سازی- برنامه‌نویسی

تلاش می‌کنم از این پس به‌جای “توسعه” در برابر Developing برابرنهاد “برنامه‌سازی” را بکاربرم. و “برنامه‌نویسی” را برای Programming. در نتیجه “برنامه‌نویس” برای Programmer و برنامه‌ساز برای Developer.

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

آنگاه می‌توان به‌جای “محیط مجتمع توسعه” برای IDE، “محیط مجتمع برنامه‌سازی” یا زیباتر از آن “محیط یکپارچه برنامه‌سازی” را بکاربرد که مفهوم را کامل می رساند. راستش این “محیط مجتمع توسعه”هیچ حسی در من ایجاد نمی‌کند. حتا می‌توان با کمی گذشت دربرابر زیباسازی “ بستر یکپارچه برنامه‌سازی را بکار برد. واژه بستر یکی از پیشنهاد‌های داریوش‌ آشوری است.

واژه دیگری که مرا بسیار می‌آزارد و دو مجله (که بدبختانه هر دو هم محبوب من هستند) آنرا گسترش داده‌اند “سکو” در برابر Platform است، در حالیکه ما از سال‌ها پیشتر واژه “بستر” را برایش بکارمی‌بردیم و فرهنگستان هم آن‌را پیشنهاد کرده بود، که هم زیباتر است و از آن مهم‌تر بارمعنایی کامل تری دارد، سکو همیشه مرا یاد ایستگاه قطار می‌اندازد.

پ.ن: گفتم حالا که آنها را گفتم این را نیز یگویم: از دیگر واژگان بسیارپرکاربردی که بیشتر جاها نادرست نوشته می‌شود “فناوری” است که نادرست “فن آوری” یا “فنآوری” نوشته می‌شود. این واژه برابرنهادی است برای Technology ور در فارسی ترکیبی است از فن + وری است، آن الف هم که آن میان آمده صورت ساز یا formative (از اصطلاحات زبانشناسی) است، نمونه‌های دیگری نیز از این دست در فارسی داریم: جنگ + ور–> جنگاور، دل + ور–> دلاور، پس + مدرن –> پسامدرن.

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

مدیران عامل شرکت های آزاد/باز‌متن: آشنایی، تجربه‌ها و توصیه‌ها

یکی از معروف ترین بلاگ ها درباره کسب و کار باز متن The Open Road است که در پست “بلاگ هایی برای پیدا کردن دید بهتر از بازمتن” هم از آن نام بردم، این بلاگ را Matt Asay یکی از بهترین تحلیل گران کسب و کارهای آزاد/بازمتن می نویسد که خود در شرکت بازمتن Alfresco هم کار می کند. دراین بلاگ او یک سری نوشته دارد با نام “مدیر عامل باز متن” که اکنون به شماره ۲۲ رسیده است و در این نوشته ها او درباره موفق ترین مدیران عامل شرکت های آزاد/بازمتن، شرکتشان و توصیه‌های آنها می‌نویسد، پیشتر در مقاله “۱۲ مدل کسب و کار بازمتن” مدل کسب‌ و کار برخی از این شرکت ها را بیان کرده‌ام. خواندن این نوشته ها را به کسانی که در فکر برپایی شرکتی آزاد/بازمتن هستند و یا یک چنین شرکتی را اداره می‌کنند اکیدا توصیه می‌کنم.

اینجا نام هر فرد، سپس شرکتی که وی مدیر عامل آن است آورده شده:

The Open Source CEO Series:

۱٫ Dave Rosenberg, MuleSource
۲٫ Javier Soltero, Hyperic
۳٫ Marten Mickos, MySQL
۴٫ John Powell, Alfresco
۵٫ Fabrizio Capobianco, Funambol
۶٫ Boris Kraft, Magnolia
۷٫ Kelly Herrell, Vyatta
۸٫ Satish Dharmaraj, Zimbra
۹٫ Ranga Rangachari, Groundwork
۱۰٫ Dries Buytaert, Drupal
۱۱٫ John Roberts, SugarCRM
۱۲٫ Toby Oliver, Path Intelligence
۱۳٫ Danny Windham, Digium
۱۴٫ Bill Karpovich, Zenoss
۱۵٫ Mark Brewer, Covalent
۱۶٫ Gianugo Rabellino, Sourcesense
۱۷٫ Bob Walters, Untangle
۱۸٫ Paul Doscher, JasperSoft
۱۹٫ Pete Childers, Zmanda
۲۰٫ Rod Johnson, Interface 21
۲۱٫ Harold Goldberg, Zend Technologies
۲۲٫ Eero Teerikorpi, Continuent

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.