استقصاء مرتبات المبرمجين في السوق المصري 2019

Posted on by
هذا الأستقصاء قمت به في منتصف ديسمبر عام 2018، وفيما يلي الأعتبارات الأوليه لهذا الأستقصاء
  1. تم الأستقصاء على الخبرات المختلفة لوظيفة المبرمج، وفي اعتقادي فإن معظم مرتبات بقية فريق العمل تتمحور حول المبرمج، اي انه يمكن ان تنسب مرتب اي وظيفة في فريق العمل الي نسبة من مرتب مبرمج مناظر له في الخبرة المهنية او في الأهمية الوظيفية (هذا اعتقاد مبني عن خبرة وظيفية شخصية وليس عن علم مدروس)
  2. تم تقسيم وظيفة المبرمج الي الدرجات التالية … بالطبع المسميات تختلف من شركة الي اخرى
    • مبرمج Entry level … وهو المبرمج حديث التخرج، لديه علم بلغة البرمجة المطلوبة لكن ليس لديه اي خبرة. في العادة يستغرق هذا المبرمج بين شهر الي 6 اشهر حتى يكون منتجا … والمدة تعتمد على درجة تعقيد المشاريع التي يعمل فيها وعلى استعداده للتعلم بسرعة
    • مبرمج Junior developer … وهو المبرمج الذي تجاوز المرحلة السابقة واصبح قادرا على تحمل مسؤولية مجموعة من المهام واصبح منتجا
    • مبرمج Junior plus … وهو المبرمج الذي اصبح لديه خبرة من سنة الي سنتين، وهناك تقدم ملحوظ في مستوى انتاجيته وتحمله لمسؤولية المهام الموكلة اليه
    • مبرمج Senior … وهو المبرمج الذي تجاوز على الأقل اربع سنوات خبرة (وفقا لانطباعاتي عن السوق المصري … مصطلح senior في السوق الأمريكي قد يعني 10 سنوات خبرة على الأقل) … ولديه حد ادنى من الخبرة الأدارية التي تمكنه من ادارة او دعم عدد 2 مبرمجين juniors تحت ادارته
    • مبرمج senior plus … وهو المبرمج الذي تجاوز على الأقل 6 او 7 سنوات خبرة… وقادر على ادارة فريق برمجي صغير من 5 مبرمجين مثلا ، ولديه مهارات ادارية جيدة جدا
    • مبرمج team leader … وهو المبرمج الذي تجاوز على الأقل 10 سنوات ، قادر على ادارة فريق الشركة فنيا، ووفقا لحجم الشركة وحجم فريقها فقد يكون هو المدير الفني CTO او من يرسم سياساتها الفنية والتقنية … ولديه مهارات ادارية متقدمة جدا
  3. تم وضع الأستقصاء على جروب خاص على الفيس بوك يضم اغلب الشركات المصرية المسجلة في قاعدة بيانات هيئة تنمية صناعة تكنولوجيات المعلومات المصرية … هذا الجروب يضم في اغلبه الشركات متناهية الصغر والصغيرة والمتوسطة وقليل جدا من الشركات الكبيرة … لذلك فأغلب المشاركين في الأستقصاء من اصحاب الشركات في السوق المصري.
  4. تم تعمد عدم وضع الأستقصاء على مجموعات (جروبات) المبرمجين على الفيس بوك حتى لايشارك في الأستقصاء الا صاحب عمل
  5. المرتبات في مصر متباينة جدا بشكل عام وفي قطاع البرمجيات بشكل خاص للأسباب الآتية (في نظري)
    • التقلبات السياسية من 2011 والي الآن
    • تحرير سعر صرف الدولار مقابل الجنيه (تعويم الجنيه) ، الأمر الذي اثر في معدلات التضخم بشكل كبير. كنتيجة لهذا، هناك شركات استطاعت ان ترفع مرتبات موظفيها بنسب مختلفة وهناك شركات لم تنجح في ذلك … وهو كان احد اهم الأسباب في تفاوت متوسطات المرتبات
    • هناك مبرمجين يعملون مع شركات اجنبية (امريكية او اوروبية) بمرتبات بالدولار، وفي معظم الأحيان تكون مرتباتهم احيانا ضعف او ثلاث اضعاف اعلى متوسط للمرتبات في الشركات المصرية
    • هناك شركات من دول خليجية فتحت مكاتب لها في مصر وتعطي مرتبات اعلى من المتوسط بقليل
      الأستقصاء -كما ذكرنا- تم حصره في الشركات المصرية الصغيرة والمتوسطة وهي المتواجدة على جروب الفيس بوك المذكور اعلاه
  6. انا لست خبير موارد بشرية ولم ادرس هذا العلم ولكني محتك به، لذلك ان كان من خطأ في طريقة كتابة الأستبيان فلتسامحونا فيه.
  7. شارك في الاستقصاء 49 شركة
  8. سعر الدولار حين اجراء الأستقصاء كان 17.8 جنيه مصري
  9. لم اشارك في الاستقصاء بصوتي
والآن الي النتائج

اولا: مبرمج ال Entry level …

مبتدي.png

 

اكثر من نصف المشاركين ذكروا  مرتب اقل من 3000 جنيه مصري في الشهر اي اقل من 170$ تقريبا. والربع تقريبا اشاروا الي اجر اعلى من 3000 جنيه مصري، وهناك نسبة معتبرة 12.5% لاتعطي راتب لمن هم تحت التدريب

ثانيا: المبرمج ال Junior

junior

 

اكثر من ثلثي النتائج تقريبا (اللون الأحمر والأزرق مجتمعين) تشير لمرتب من 3000 الي 4000 جنيه مصري. وهناك نسبة مؤثرة تشير الي انه قد يصل الي 5000 جنيه اي مايعادل بحد اقصى 280$ امريكي

ثالثا: المبرمج الــ Junior plus

junior plus

قرابة النصف تقريبا تشير لمرتب من 5000 الي 6000 جنيه او 340$ تقريبا بحد اقصى … مع تفاوت ملحوظ في المرتب قد يتجاوز الــ 8000 جنيه مصري

رابعا: المبرمج الــ senior

senior

ثلث النتائج تقريبا تشير الي مرتب من 7000 الي 8000، اي حوالي 450$ شهريا … مع تفاوت ملحوظ قد يتجاوز الــ 10000جنيه مصري

خامسا: المبرمج senior plus

senior plus

قرابة الثلث تشير الي 12000 جنيه بحد اقصى اي 670$ تقريبا، مع تفاوت ملحوظ الي اعلى من 15000 جنيه

سادسا: الـــ team leader

team leader

هناك تفاوت واضح في هذه الشريحة بدءا من 15000 جنيه مصري اي حوالي 840$ الي اعلى من 21000 اي 1180$

 

Technology startups success determinants in Egypt

Posted on by

Technology startups success determinants in Egypt

Technology startups success determinants in Egypt

This blog is part of the study i recently published on my blog. you may download it from the following link.

As mentioned in the title, this blog targets the success and failure factors and determinants of technology startups in Egypt. Although, i see it is applicable to any developing country or in countries where you find bureaucracy and corruption.

The factors and determinants mentioned here are the factors we studied. some of them are major others are minors. Factors are defined from literature reviews and peers interviews.

Factors are defined into four groups:

  1. Factors related to the entrepreneur himself
  2. Factors related to the Ecosystem and its maturity
  3. Factors related to the market and its size and purchasing power
  4. Factors related to the government

How do we define success. Success in business usually defined in terms of profit, usually expressed as “increasing shareholders wealth”. In startups, and specially in a country such as Egypt, the definition could be more deeper.

Success is described by; the longer the entrepreneur can survive and prevent involuntary exit, the more successful he is.

Below are the definition of each factors studied, and in a coming blog, we will study the effect of each factor.

ُEntrepreneur Factors

Leadership Skills: entrepreneur motivational attitude to motivate the employees to achieve the company vision and strategic objectives and goals.
Focus Strategy: entrepreneur motivational attitude to achieve focusing on a few target markets who are distinct groups with specialized needs (Focus strategy rather than diversification strategy).
Entrepreneur Qualifications: the effect of education, general experience and industry experience on all the business aspects.
Interdisciplinary of the founding team: the founding team diversity in experiences, education, culture and even nationality.
Business Skills: entrepreneur skills for recognizing opportunities and the entrepreneur’s willingness to take risk  and their orientation to make money.
Soft Skills: The characters and capabilities of attitude and behavior instead of knowledge or technical ability, Innovation, ambition, optimism, flexibility and adaptability.
Ethical Behavior: Ethical entrepreneur is committed to achieve business success, without contradicting with personal ethics and values, his/her humanity and honesty are motives against unethical business temptation.
Networking and Social Skills: The strong relationships with potential customers, business partners and government bodies.
Luck: The force that causes things, especially good things, to happen to entrepreneur by chance and not as a result of his own efforts or abilities.

Ecosystem factors

Availability of Incubators, Accelerators and Advisors: Availability of entities that provide know-how for the new business entrepreneurs, such incubators act as business accelerators for the ICT startups, also they provide advisors and consultants in various fields like legal and marketing advisors.
Availability of Financing Agencies: availability of Venture Capitals or Angel donors who have intentions to provide fund for small and medium enterprises
Non-Governmental Organizations Support: The efforts done by NGOs aiming for social and economic change which eventually helps the private business sector especially SMEs
Availability of Business Partners: All partners that provide entrepreneur with important activities necessary for his success.

Market Factors

Egyptian Market Opportunity: The presence of business need in the market to develop new products and services which are not fully supplied in the Egyptian market.
Egyptian Market Risk: The sum factors that make working in Egyptian market is risky
Customers’ availability: The potential for the market current customers to purchase the product/service to generate profit.
Demographic Factors: Unemployment, poverty, high dependency ratio, and illiteracy rates.
Government Support Program Efficiency: The measure of how efficient the government support programs to provide financial, technical and non-technical support for ICT companies.

Business Environment

Governmental Regulations: The governmental laws, rules and policies that affect the ICT industry either directly or indirectly.
Corruption: The misuse or the abuse of public office for private gain.
Military Service: The compulsory service in Egypt for males, from 14 months to 36 months based on the age and education level.
Infrastructure: The basic physical and organizational structures and facilities (e.g. power supplies, buildings, roads,) needed for the operations of ICT enterprises.
Political and Economic instability: The tendency of a government to collapse.
Internet Services: The availability of different internet technologies  which are efficient with reasonable prices, required for ICT companies in Egypt.
Legal Form: How the business entity is formed as per the local commercial law In Egypt
Legal Environment: The power of law enforcement represented in laws’ entities, procedures and environment that protect rights and provide justice for ICT small business in Egypt.
Availability of Qualified Employees: The ability to headhunt qualified and talented employees.

Exploring Factors Determine success of Small ICT Enterprises in Egypt

Posted on by

startup-success-845x321

For more than two months, I was working closely with my friend Dr.Ahmed Hussien on a thesis with the same title “Exploring Factors Determine success of Small ICT Enterprises in Egypt”.  If you are a follower of my blog, you may notice my passion of entrepreneurship and startup. I am very close to many startup communities worldwide (USA, EGYPT, KSA, Qatar, …. And more)

Chapter five in the study is the most important one. It includes results and recommendations. Recommendations included advises for Egyptian entrepreneurs, government, ITIDA, and the Egyptian startup eco-system. In addition, the end of chapter 4 includes full picture summary about each factor results, analysis, discussion and recommendations

The study has been done on several stages that included a review for startup community in many countries, interviews with startup owners, and experts from the eco-system.

In the few coming weeks, I will discuss each result separately on my blog. These discussions will be a base for future focused studies. We will depend on people comments and interactions as a base for these future studies, so please follow my blog to be able to see future studies and to interact with it

Download the study1426700201_folder_download

Lesson in a graph, Relation between product life cycle and Marketing message, Distribution, Price, and management style

Posted on by

Relation between product life cycle and Marketing message, Distribution, Price, and management style

Lesson in a graph: Classical 4P’s and its components

Image | Posted on by

classical 4Ps

Software Project Management, The mission impossible, Part.3, The secret sauce…

Posted on by

kinopoisk.ru

First of all, no one can say “I have the perfect solution”. We are not dealing with a mathematical equation where we can have an exact solution. Rather, we deal with human brains, we interprets thoughts. It is a human interaction that can possibly carry different meanings and hence different results. That is why we just provide you some best practices and learned lessons.

Actually, all agile frameworks and methodologies are somehow best practices and learned lessons. It only gives you guidance and let you choose your way freely. Here i will share with you some of my best practices and learned lessons in requirements negotiations.

  1. Before you contract, just document the customer vision and high level objectives not the detailed requirements. we said in part.1 and part.2 that customer will always change the requirements and ask for new requirements, this is an axiom that we have to consider.
    As a development team, we usually like to have as much documented requirements as we can before we contract. We do that because.
    – We think that this will reduce future conflicts with the customer. Actually it will not 😦
    – We need to have more accurate estimation for project budget and schedule as early as we can.
    – This will help in building a robust solution architecture.
    It is good to have all of that, but documenting requirements early, will not result in that 😦
    From my experiences, i found that it is better to draw a frame for the project scope. what is inside that frame is accepted, and what is outside is not. The frame is defined by project vision, objectives, functional areas, system stakeholders and some high level user stories.
    “The vision and scope template of Microsoft frame work is a good reference”
  2. Raise customer awareness of software development challenges, but after contracting.
    It is not wise when you first meet your prospect to tell him about the tough and challenging nature of software development. He will most probably search for another company.
    After you contract with your customer, start raise his awareness about the nature of software projects but easily and slowly. Don’t give it to him in one shot. Be smart.
  3. Always Negotiate. Although in the vision document you defined a frame for the project scope, but still you will face many situations where you conflict with the customer about a requirement, wither it is inside the frame our outside it.
    When you face such situations, always think of the Trade-off triangle and negotiate based on it.
    – You have to make a trade with your customer about the new requirements. Ask for money or time.
    – Accept some requirements that are easy to implement without any trades, but after you negotiate it. Let the customer feel that he won the negotiations with you, and that you sacrificed for him.
    – In some cases when the customer is insisting on a requirement that is hard to implement, remind him with the situations when you sacrificed for him. This will make the negotiations easy for you.
    – Help the customer focus on high priority requirements and keep reminding him with project objectives…

Trade-off triangle

Good Luck

Software project management, the mission impossible, Part.2, Challenging situation

Posted on by

tom-cruise-wait-who-s-coming-back-for-mission-impossible-5-now

In part.1 we described the situation as building a plane in the air, and mentioned some of the challenges we always face. Here we going to discuss some of these challenges in details:

Requirements are not clear.

Always happening, customer usually has a problem and usually does not know the root cause of it. In best cases customer can has a vision with defined objectives. When you meet customer stakeholders, everyone of them has a different story to tell, everyone has a different expectation. And you are trying hard to listen to all of them to form your own vision, or a common vision that can meet most of stakeholder’s requirements.

Requirements always changing.

Remember when we said in part.1 that:

” The best ever written requirement document represents only 80% of customer vision”

When you form your vision that you think is the most close to everybody’s vision and then start to develop the requirements, customer will continually gives you feedback  and ask for enhancements.

This is normal, Customer can’t judge the system without seeing it at work.

As a development team we have to consider that and accept it as a fact an axiom in software development domain. Resisting it will result in project failure.

Project is out of budget and time.

This is a logical result of requirements being changed all the time. Although the customer himself never stops asking for new requirements, but after a while he gets bored of the project, and sometimes he loses his enthusiasm and motivation and may cancel the contract.

Happened to me many times 🙂

No time for test.

If the project reached that situation, where requirements are not managed anymore, and project is out of schedule and budget, and customer is complaining, Development team usually sacrifices wit the testing time to deliver and get paid…

You can imaging what would happen next.

Time is spent on Junk.

An academic study in 2003 mentioned that

“53% of project requirements usually be cancelled as stakeholders found that these requirements are not of much value for the project, or the situation itself has been changed where they don’t need these requirements anymore”

“64% of requirements built are not used, and in best cases they use once a year”

On the personal level, i once had a project where we were developing a campus management system for a college. we build more than 120 reports according to the customer requirements. After we finished, and while we were monitoring the system at work, we found that only 10 reports are being used periodically, and more than 50 reports have never been used all over 6 years.

So,,, what shall we do ?!

In the next blog, i will follow with you best practices and learned lessons.

follow the blog to get it on time.

Software Project management, The mission impossible. Part.1 Building a plane in the Air.

Posted on by

Tom_Cruise_Mission_Impossible_Stunt_article_story_large

If project management is difficult, then software project management is more difficult. Actually, it is exceptional. Software development teams are usually trying to figure out a situation, analyze problems in this situation, listen to stakeholders, try to figure out stakeholders vision and thoughts about the optimum way to deal with that situation. Development team should translate outcomes of all these inputs into a running software program that works properly and solves problems.

Software development team deals with a customer vision. A vision that is not even clear and well defined. Customer only realizes that he has a problem, but in most cases, he does not know where exactly the problem is. As a result, customer always updates his requirements with time.

Software development team tries to figure out this vague vision and document it. Then works on developing a solution using technologies that keep changing every day!.

The customer environment and infrastructure is also hybrid, different running operating systems with different software solutions that are based on different database engines. And it is required that the developed system works in harmony with this hybrid environment.

And in most times, the customer has limited time and limited budget….

EDS once had a commercial that exactly explain this situation…

Yea,  Software development team are actually building a plan in the Air!

Think about it:

  • Vision with vague requirements.
  • Requirements keep changing.
  • Tools we use to build the solution keeps developing.
  • Solution need to be built while customer is running.
  • Solution need to be installed in a hybrid environments.
  • limited time and budget.

In order to succeed in software project management, you have to deal with these mentioned issues as facts and axioms, do not ever try to resist them, deal with them … Good luck

in part.2 of this article we will discuss samples of situations a software team would face with customers.

Facing Customers learned lessons, Words that customer hates

Posted on by

Angry-Customers

In software development projects, one of the most hated sentence by customers is when you say to him “This is a new requirement” … when we say this sentence -as a project manager or business analyst- we usually wait for an unexpected behavior from the customer 🙂

Actually both hate it, the customer and the development company. Customer hate it because it -definitely- means extra cost and time !.
The development team hate it for the following reasons:

  1. Project manager knows that he will get into a lot of arguments, debates, and negotiations with the customer and the development team lead about the new requirements.
  2. Team leader will check if this requirement needs a major or minor changes in the system architecture. Major changes mean higher cost and also some team depression.

There is a rule in software engineering saying that

“The best ever written requirement document represents only 80% of the customer vision”

I strongly believe in this rule and i consider it one of the axioms in software development, and one of the major reasons why agile development methodologies are introduced.

Development team has to deal with this rule as a fact. Customer always asks for new requirements. This is normal, and it happens all the time. Team should think how to deal with it rather than resisting it. Team should have tactics and best practices to deal with it.

One of the management tactics i followed over years, is to manage the customer expectations and psychology. I want the customer to get used to this sentence, not to hate it. Customer should be aware that we develop his ideas and thoughts, we help him get these thoughts and ideas into real life. As a result, each time he sees part of his ideas come real, he will have comments, feedback, changes and enhancements.

Also we will let him know that not all changes require extra cost and time, but in all cases, we should fill a new requirement form. We want the customer to get used to this document and this sentence too. So when you come at a time and ask him for extra money or time, you have something to negotiate with, as you did him a lot of enhancement without any trade-off.

act like rich people

Sales, Marketing, and Strategy !

Image | Posted on by

strategy-marketing-innovation_615x358