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

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

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

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

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

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

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

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

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

~~~

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

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

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

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

~~~

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

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

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

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

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

~~~

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مستندسازی

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

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

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

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

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

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

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

راز موفقیت

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

“دو واژه”

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

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

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

“یک واژه”

“آن چیست؟”

“تجربه”

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

“دو واژه”

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

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

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

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

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

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

branding definitions

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

یکی از معروف ترین بلاگ ها درباره کسب و کار باز متن 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) این بلاگ شوید.

منابعی برای آشنایی با کسب و کار بازمتن

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

۱٫ مقاله کلاسیکِ “کلیسا و بازار” نوشته ی اریک ریموند، که وی در آن نشان داده که بازمتن می تواند کسب و کاری جدی و درآمدزا باشد. ترجمه ای خوب از آن با قلم شیوای “نیما ابوطالبی” را می توانید از اینجا بگیرید.

۲٫ کتاب “کسب و کار و اقتصاد نرم‌افزارهای متن‌باز” که طرح ملی نرم‌افزارهای آزاد/متن‌باز آنرا به فارسی برگردانده را نیز از اینجا می توانید بگیرید.

۳٫ اگر به هر طریقی دسترسی دارید کتاب”Open Sources 2.0 “پر است از نوشته های خوب و هر فصل از آن را یک متخصص نوشته است. به ویژه فصل های ۶-۹ به تجاری سازی، مدل های کسب و کار و دیگر جنبه های مالی بازمتن پرداخته است.

۴٫ کتاب “Succeeding with Open Source: An Overview” نیز کتابی جالب و بر اساس تجربه های نویسنده آن است.

۵٫ کتاب “Perspectives on Free and Open Source Software” که مانند منبع ۳ هر فصل از آنرا یک متخصص نوشته است، این کتاب را کامل یا فصل به فصل می توانید از اینجا بارگیری کنید.

۶٫ بلاگ هایی را که در که در پست”بلاگ هایی برای پیدا کردن دید بهتر از بازمتن” نام برده ام پیگیری نمایید.

پ.ن: من در این بلاگ ” کسب و کار” را برابرنهادی برای “Business”بکار می برم.

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

یک پروژه بازمتن به همراه یک تیم بازاریابی. تصورش را بکنید.

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

به این خاطر است که من از صحبت با جان نیوتن لذت بردم، او یکی از موسسان و مدیر فنی شرکت Alfresco است، شرکتی که سیستم مدیریت محتوایِ(CMS) سازمانی باز متن می سازد. شرکت آنها در سال ۲۰۰۵ به وسیله جان نیوتن (از موسسان شرکت Documentum) و جان پاول (مدیر ارشد عملیاتی سابق شرکت Business Objects) برپا شد. این شرکت چیزی دارد که من به ندرت در جامعه بازمتن می بینم: روابط عمومی و دانش بازاریابی.

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

روشن است که آنها (Alfresco) می دانستند که چه نیاز دارند تا محصولی اساسی تولید کنند. Alfresco چشم اندازش نرم افزار مدیریت محتوایی بود که خواسته های سازمان ها را در بر داشت. در حالیکه بسیاری از نرم افزارهای مدیریت محتوای بازمتن در دسترس هستند، معمولا برای یک کار مشخص مثل ساخت وب سایت، ساخته شده اند. رقابت Alfresco با جوملا، دروپال یا پلون نیست بلکه با FileNet، OpenText و Documentum است. نیوتن می گوید بازمتن شرکت را قادر می سازد تا بستری مقرون به صرفه ارایه کند، %۸۰ آنچه مشتریان بکار می برند شامل مدیریت رکوردها، مدیریت تصویر، بستر مشارکتی و مخزن محتوا پیشتر نوشته شده است. احتمالا نیوتن از اینکه درباره ویژگی های محصولش با من سخن می گفت خیلی خوشحال بوده است و روشن است که کاربران سازمانی نیز از پیشینه درخشان موسسان شرکت مطمئن تر می شوند. اما آنچه توجه اصلی من را بر می انگیخت وضعیت خارق العاده شرکتی عادی بود که درباره سازمان ها سخن می گفت اما هنوز می خواست بازمتن باشد.

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

نیوتن در ادامه گفت: در عوض ” ما دریافتیم که فرصت در OEM (فروشندگان اصلی) و VAR (فروشندگان ارزش افزوده) وجود دارد.” افراد نرم افزار را بارگیری و امتحان می کنند. اما هر زمان که بخواهند نرم افزار بازمتن را در محیط سازمانی استفاده کنند، می توانند آنگاه برخی از سرویس ها را خریداری می کنند، سرویس هایی مثل حمایت فنی، خدمات نگهداری و پشتیبانی سریع و دسترسی درجا به ترمیم خطا. کُد %۱۰۰ بازمتن و براساس مجوز GPL است. (آنها تنها کسانی نیستند که این مدل کسب و کار را پذیرفته اند، نیوتن می گوید MySQL هم این مدل را به کار می برد.)

بخاطر جامعه محور بودن، آنها از تمانی مزیت های فرایندهای ساخت نرم افزار بازمتن استفاده کردند. از آنجا که Alfresco نرم افزارهای بازمتن بسیاری را در ساختش بکار برده، پروژه به سرعت اجرا شد. در شش ماه، نخستین نسخه بتا برای آزمایش آماده بود. سامانه ی تولید تا انتهای ۲۰۰۵ کامل شده بود. گرچه آنها انتظار داشتند یک جامعه ی برنامه نویسان را از نو بسازند، “گروهی از افراد ناراضی وجود داشتند که بخشی از اکوسیستم نرم افزارهای مدیریت محتوای سازمانی بودند ولی با آنها آنگونه که شایسته شان بود برخورد نشده بود”. این افراد دوست داشتند که در یک پروژه بازمتن مشارکت کنند پروژه ای که مشارکت شان در آن، چیزی واقعا متفاوت بسازد.

اگرچه Alfresco دانش بازاریابی بالایی دارد- یک متخصص روابط عمومی با من تماس گرفت و پیشنهاد برگزاری این نشست را داد- چرخه معمولی فروش آن با فرآیند سازمانی استاندارد کاملا متفاوت است. بنابه گفته نیوتن، این شرکت دنبال فروش مستقیم به سازمان ها نیست. کسی در سازمان مشتری ( معمولا فرد فنی که کارش مدیریت محتوا است) نرم افزار را آنلاین می یابد، آنقدر آنرا امتحان می کند تا به این برسد که مناسب نیازهایشان است، آنگاه با مدیرش تماس می گیرد. همینکه که مشتری تلفن را بر دارد، یعنی نرم افزار به فروش رفته. مشتریان سازمانی بزرگتر (البته آنها مشتریان واقعا بزرگی دارند، که بابت آنها به خود می بالند) ممکن است نیاز به جلسه داشته باشند. تجربه آنها می گوید چرخه فروششان از نخستین تماس ۴۰-۵۰ روز است در مقابل چرخه ۹-۱۲ ماهه فروشندگان معمولی نرم افزارهای سازمانی. نیوتن هزینه فروش نرم افزارهای بازمتن شان را %۲۰ بودجه فروشندگان نرم افزارهای اختصاصی، برآورد می کند. او می گوید”ما می توانیم با سود یکسان، نرم افزار را ارزان تر بفروشیم” و “هنگامیکه همه هزینه ها کم باشد، گزینه های نزدیک و در دسترس صنعت را فرو می پاشانند.”

نیوتن می گوید: “بازاریابی بهترین راه برای این کار است- اما فروش نه”. این درسی است که دیگر عرضه کنندگان نرم افزارهای سازمانی و کسانی که از آنها خرید می کنند باید از آنها یاد بگیرند.

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

Schindlerو Esther. “An Open-Source Project with a Marketing Team. Imagine That.”

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

بلاگ هایی برای پیدا کردن دید بهتر از بازمتن

اینجا فهرست بلاگ ها و سایت های انگلیسی است، خواندن این بلاگ ها دید و بینش بهتر از بازمتن به وجود خواهد آورد:

پ.ن: این فهرست را از جایی گرفته ام و خودم همه آنها را پیگیری نمی کنم .
راستی به مورد ۶ بیشتر دقت کنید

اندکی صبر سحر نزدیک است

دوست عزیزی برای پست پیشین من نظری گذاشته که مرا برا آن داشت تا نوشته ای نو بنویسم. اول بخشی از نظر این دوست عزیز:

“همه ی مدل ها جواب میدن اما نه در ایران. در ایران حتی نمی توان از نرم افزار تجاری درآمد کسب کرد چه برسه به نرم افزار آزاد.”

می پذیرم که در ایران کسب و کار کمی سخت تر است (هر کسب و کاری جز دلالی) اما بهتر است کمی جدی تر به فرآیند شکل گیری و مدیریت شرکت های نرم افزاری در ایران نگاه کنیم. من در مورد مسایل فنی نرم افزار صحبت نمی کنم و فرضم این است که همه کسانی که شرکت نرم افزاری راه اندازی می کنند، نرم افزار نویسانی ماهر و حرفه ای هستند!؟ (بگذریم که بیشتر ما با روش (متدولوژی) های نو طراحی و تولید نرم افزار آشنایی نداریم):

متاسفانه بیشتر ما شرکت برپا می کنیم، چون کار دیگری نداریم بکنیم.
در کشورهای دیگر فرد یا افرادی که ایده ای دارند و می خواهند کسب و کاری برپاکنند، در آغاز طرح کسب و کار (Business Plan) آنرا تهیه می کنند. خوب در اینجا چه درصدی از شرکت های نرم افزاری و وبی نوپا این کار را می کنند؟

متاسفانه بیشتر افراد فکر می کنند داشتن دانش فنی برای برپایی کافی است، پیش تر هم گفته ام این تنها یک سوم نیاز است. چند مهندس کامپیوتر تازه از دانشگاه آمده می شناسید که دانشی هرچند اندک از مدیریت دارند؟
دانش مالی و حسابداری که از شام شب برای چنین فرد/افرادی واجب تر است چطور؟
آیا افرادی که می خواهند شرکتی برپا کنند بازاریابی می دانند و بازار را می شناسند، اگر نه پس برچه اساسی محصولات خود را تولید می کنند!!!!؟؟؟؟

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

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

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

مدل کسب و کار بازمتن ۱۲

فهرست ۱۲ مدل اپن سورس به همراه شرکت (موسسه)هایی که این مدل ها را بکار می برند آورده شده است:
۱. نرم افزار رایگان است اما ما برای پایایی و ماندگاری به اعانه (Donation) و کمک مالی (subsidy) نیاز دارد: بنیاد نرم افزاری آپاچی، ObjectWeb ،Eclipse
۲. نرم افزار رایگان است اما ما تبلیغ و جایگاه (مثل نوار ابزار) می فروشیم: موزیلا
۳. نرم افزار رایگان است اما اگر می خواهید آنرا در یک نرم افزار بسته متن (closed source) بکار برید، بهتر است که پولش را بپردازی: Trolltech, DB4Objects, Funambol, MySQL
۴. نرم افزار رایگان است اما خدمات رایگان نیستند: Covalent
۵. نرم افزار رایگان است اما پشتیبانی و نظارت مداوم و دسترسی به فایل های اجرایی (باینری)رایگان نیستند: RedHat
۶. نرم افزار رایگان است اما برخی ویژگی های سازمانی (حرفه ایِ شرکتی) رایگان نیستند: SugarCRM, Zimbra, JasperSoft
۷. نرم افزار رایگان است اما ما بر اساس آن مجصولی بسته متن تولید می کنیم. EnterpriseDB, GreenPlum
۸. نرم افزار رایگان است اما سخت افزار (ی که با آن ارایه می شود) نیست. Asterisk/Digium و SUN
۹. نرم افزار رایگان است اما ما هرچیز دیگری روی این سیاره را می فروشیم، از جمله نرم افزارهای بسته متن: IBM
۱۰. نرم افزار رایگان است اما این کار اصلی ما نیست: Ruby on Rails و اشخاصی که در پروژه ها همکاری می کنند
۱۱ . نرم افزار رایگان است زیرا ما آنرا دور انداخته ایم و دیگر به آن نیاز نداریم
۱۲. نرم افزار رایگان است زیرا ما ترافیک (بازدید) وب را می خواهیم: Google GWT, Yahoo YUI

پ.ن: این مطلب از مقاله Marten Mickos مدیر عامل MySQL گرفته ام لینکش دیگر (دست کم برای من) کار نمی کند ولی من آنرا از اینجا گرفته ام. ولی چون خودم بصورت فراگیر مدتی است دارم روی آن کار می کنم، اگر دوستی منابع بیشتری خواست می توانم در اختیارش قرار دهم.

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

محاسبه فضای کاری

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

برای کسانی که می خواهند شرکت نرم افراری برپا کنند، مساله ای وجود دارد و آن محاسبه فضای مورد نیاز است. مدتی پیش مطلبی در سایت جوِل اسپالسکی دیدم، آنرا اینجا می آورم:

– دفتر (اتاق)ها :کارکنان تمام وقت بین ۶٫۵ تا ۹ متر مربع برای هرنفر. اگر کارآموز بکار می گیرید ۱۳٫۵ متر برای هر سه نفر کافی است.
– قسمت منشی و انتظار: ۲۲٫۵ متر
– قفسه های کتاب و کتابخانه: ۷ تا ۹ متر
– اتاق وسایل و انبار: ۹ تا ۱۸ متر
– قفسه و جای سرور ها: ۶ متر
– غذا خوری: ۲٫۷ متر به ازای هر نفر
– آشپزخانه: ۱۸ متر
– اتاق نشت/ جلسه: ۲۲٫۵ متر
– دستشویی و حمام :۲-۳ عدد به اضافه حمام

هنگامیکه همه اینها را جمع بندی کردید. %۳۰ به اضافه کنید. (راهرو ها، حال و فضای رفت و آمد و …)
اگر می توانید جا را برای ۵ سال اجاره کنید و پیش بینی رشد تا آن هنگان را هم بکنید.
این را هم میدانم که این برآورد کمی زیاد است و ما عادت به گرفتن دفتر کار به این بزرگی (و پولش را هم) نداریم. ولی به هر حال نیروهای انسانی در شرکت های نرم افزاری مهمترین فاکتور هستند.

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