Why Software Estimations Are Always Wrong

2023-10-12 01:00:15 00:14:22 [ • ] Estimation is just a fancy word for guessing we’re usually guessing about the problem that we need to solve how we’ll solve it how long it will take and so how much it will cost oh and if we’re really Advanced we may try guessing about how much money we will make from

The idea too so what is the point of an estimate really and why are they always wrong oh and while we’re exploring those ideas how can we do a better job of choosing what to work on next Hi I’m Dave fley welcome to my channel and if you haven’t been here before please do hit subscribe and if you enjoy the content today hit like as well we can estimate all sorts of things but they are by their nature always just predictions of the future and so just

Guesses and all are deeply prone to error we can’t really know how much money our killer idea will make or how long it will take us to build a software that’s new in some way if you at your aim is to create great software products this is always an incremental

Progression great product ideas in reality don’t spring fully formed from the mind of some genius they evolve over time in a series of steps and get better and better until they are great this stuff is really difficult to predict most in software when we discuss estimates what we’re really talking

About is estimates that help us to decide whether or not we should do something is this project or feature worth all of the effort fundamentally the question that we are attempting to answer is what should we work on next so if that’s the case how do you figure out

What to work on next the traditional response is often probably based on hippo the highest paid person’s opinion but hippos really make good products what we’d really like to find is the most value for the least work so how do we pick those easy high value

Things I have a simple tool that I’ve been using and recommending for some years now that I think really helps us to focus on this question sometimes though the winds don’t always come from where you expect I had a long-term client a big company doing complicated things I’ve been

Working with them for a couple of years and one of the people that I was enjoying working with quite a lot was their lead product owner he was a big lean thinking proponent within the firm but was struggling to help the product owners that worked for him to establish

A leaner approach to product ownership they were struggling with big overc complex estimations the feeling the need for certainty not feeling confident to make a choice unless they are detailed plans in place with estimations for the work and the cost of the work as well as detailed market research and guesses

About the value of the features being discussed we were discussing all this and how much work was involved and how to do better when I remembered something that I had learned from my friend Jeff Patton a kind of informal qualitative planning tool that works really nicely to visualize the planning problem my

Friend the product owner loved this subsequently its adoption made a huge difference in improving the planning process for his organization and helped the product owners to focus better and more easily on the features that really mattered to people and so ultimately delivered better value to their customers this approach helped them to

Prioritize things much more easily and with much less work by now I’m imagining you imagining some big complex tool but that’s not it it is really simple simple enough in fact that you can remember all of the details that you need to know to be able to use it next time you’re doing

Some planning let me pause there to thank our sponsors we’re fortunate to be sponsored by equal experts tricentis and transfit all of these companies offer products and services that are well aligned with the topics that we discuss on this channel every week so if you’re looking for excellence in continuous

Delivery and software engineering click on the links in the description below to both support our sponsors and for you to maybe learn some things that might be interesting to you mostly as a species we are rubbish at predicting the future so planning is always difficult and plans are always wrong though the good

Ones can also be useful so we need some tools to help us to do a better job than simply just guessing some kind of structured guessing maybe what is generally regarded as the gold standard for rational planning is probably something a bit more complicated than the thing that I’m going to end up

Recommending in this video it’s called CD3 cost of delay divided by duration fundamentally to make rational planning decisions in software we need to make some kind of cost benefit calculation and do a tradeoff how do we maximize the benefit to us for the minimal costs there are lots of organizations that

Don’t work this way these are really cargo cult kind of organizations they they only see the costs and so always organize their work to minimize them that’s certainly part of what we need to do but these organizations will often do rather silly things things like delaying work on valuable ideas because the plan

Says that they should be working on some lower value thing right now that’s because the benefit wasn’t included in the prioritization decision only the cost this is stupid however low the cost the next step up from this is to estimate the business value for each new feature and prioritize work to ensure

That we always focus on the most valuable things most organizations don’t do a great job of this partly because this is a very difficult thing to do well how do you work out how valuable an idea will be if you haven’t even tried it yet at this point the common mistake

Is to assign the failure of this approach to bad planning and blame it on inaccuracy of in the estimates of either the cost or the benefit or both the most common response to this that I’ve seen is to up the level of planning effort with the assumption that this will improve the

Plan by increasing the Precision of the estimates for both costs and benefits but this is wrong in two ways this is mistaking accuracy for precision accurate estimates would be nice but can easily also be vague so vague to be useless it’s accurate to say that we

Will deliver in 10 years but not very helpful precise estimates are completely irrelevant Beyond a fairly crude level it’s precise to say we will deliver on Tuesday at 2:30 but irrelevant someone recently told me that their boss insisted on estimates to the nearest quarter of an hour what a crazy waste of

Time money and development effort that is in science this problem is solved by defining what they call error bars for any measurement we should understand the degree of uncertainty involved in the measurement or ES estimate and there is no point measuring or estimating things more precisely than that in software

Estimation the error bars are huge at the start of a project research says that it’s out by a factor of four four times your estimate which actually caus much estimation into question altogether hence the no estimates movement so working to increase Precision is completely the wrong thing to aim for

Another problem is how do we estimate the value of a feature traditional measures are value don’t usually Factor the costs in at all most development organizations can’t even tell you if a project paid for itself even after the project has finished let alone before it starts the mathematical model is simply wrong

However accurate or precise the estimates because we’re missing a whole important dimension in guessing the value time which feature should we build first this one that will cost 3 weeks but we’ll ultimately have a business value of 2 million or this one that will take five days and ultimately

Have a business value of 100,000 well obviously 2 million’s better than 100,000 so option one is better right well that depends on what ultimately a value means in those statements if ultimately for option one means 10 years and ultimately for option two means one month then after one year option one is

Worth 200,000 and option two is worth 1.2 million another kind of problem with all of this is what about option three that will take five days but has zero value for customers obviously this is a no-brainer we don’t want to do this one except what if this is a regulatory

Change and as is sometimes possible with such changes is what if there’s a fine every week that this change isn’t in place how do we calculate the value of that feature to prioritize stuff we’re missing several important things here and those things are what CD3 helps to

Solve instead of asking what is this feature worth the much better question is how much does it cost us not to have this feature per unit of time now we can see the real of going more slowly if you’d like to understand this better there’s a link to a more

Detailed explanation of CD3 in the description to this video the problem with CD3 though is that once again it still relies on us coming up with a guess for that cost of delay and it’s easy for us to fall into the Trap of being over accurate and over precise in

Our guesses great if you can calculate this not much help if you can’t do that that very well as I said predicting the future is difficult at heart I I’m a pragmatist and so in general I like Simple Solutions to things so let’s look at this simpler more pragmatic

Alternative it starts by asking yourself two questions about each feature that you think you’d like to deliver first how much do you think your users would value this feature do you think that they would think it was worth a beer their monthly salary a holiday their car

Or their house and then ask yourself how much is it going to cost to build it will it cost a beer a monthly salary a holiday my car or my house the things down here are obviously a complete no-brainer of course we want to work on things that users think are worth their

House but that will will only cost us a beer to produce so we always pick these things to do first things down here are stupid why on Earth would we spend a house worth of effort to produce something that’s only worth of beer to our users

So we are definitely not going to do these things at all everything in the middle we don’t understand well enough yet to decide what to do with them so our next step then is to figure out how we could learn more to help us to make a choice

Maybe this could be some kind of experiment in production to refine our view of the value our users will place on the idea maybe an AB test of some different variations of the idea to help us think about it from different angles a simple version of this feature that

Makes it a lot easier to make perhaps none of this stuff needs or should be very precise it’s all qualitative and approximate but qualitative and approximate is where error bars are for software estimation so another thing that helps is working in small steps even without deep accuracy and

Irrelevant Precision this model helps us to focus our minds on the things that really matter and to stop us wasting time and effort on things that don’t so I really like this simple slightly silly but extremely useful tool for planning one more thing before I go I’ve been

Describing this as Jeff Patton’s model for years now I was recently having a beer with Jeff and mentioned how much I liked it and how much I’d used it and I thanked him for for for introducing me to the idea at which point he looked at my picture and didn’t recognize it as

Anything he’d ever said so now I have no idea who I stole this from but it certainly wasn’t my idea and seemingly it wasn’t Jeff’s either thank you very much for watching thank you also to our patreon members if you enjoy our stuff you’re not already a patreon supporter

Please do consider supporting the channel and our work here by joining our patreon community if you do choose to support us at any level you can get an annual membership at a 15% discount thank you and Bye-bye

Software estimation is always wrong, so how can we do it better? Estimating software, or anything else, is always an exercise in guesswork and predicting the future, but for software, it is often even more difficult than for some other things because the very nature of software means that we are always working on something new, that we have done exactly the same before. The very common mistake then when the estimates are wrong is to aim to increase the precision of the estimate this is completely the wrong thing to do. So what should we do instead?

In this episode software engineer and author of best-selling books “Continuous Delivery” and “Modern Software Engineering”, Dave Farley, explores the vexing problem of estimation, why it is so problematic, and what we can do to increase the usefulness of our estimates. Dave also presents a simple model that can help you to estimate your ideas more accurately, by avoiding the trap of attempting to be too precise.

⭐ PATREON:

Join the Continuous Delivery community and access extra perks & content!

JOIN HERE and GET 15% OFF WHEN YOU SIGN UP FOR AN ANNUAL MEMBERSHIP ➡️ https://bit.ly/ContinuousDeliveryPatreon

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🔗 Check out their collection HERE: ➡️ https://bit.ly/3vTkWy3
🚨 DON’T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

🖇 LINKS:

Error Bars”, Wikipedia ➡️ https://en.wikipedia.org/wiki/Error_bar

“Why Bother Quantifying the Cost of Delay?” ➡️ https://blackswanfarming.com/why-bother-quantifying-the-cost-of-delay/

“How to Estimate Software Development Time” ➡️ https://youtu.be/v21jg8wb1eU

BOOKS:

📖 Rapid Development: Taming Wild Software Schedules, by Steve McConnell ➡️ https://amzn.to/38OKgtP

📖 Dave’s NEW BOOK “Modern Software Engineering” is available as paperback, or kindle here ➡️ https://amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 The original, award-winning “Continuous Delivery” book by Dave Farley and Jez Humble ➡️ https://amzn.to/2WxRYmx

📖 “Continuous Delivery Pipelines” by Dave Farley
Paperback ➡️ https://amzn.to/3gIULlA
ebook version ➡️ https://leanpub.com/cd-pipelines

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

CHANNEL SPONSORS:

Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ https://bit.ly/3ASy8n0

Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ https://bit.ly/TricentisCD

TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ https://transficc.com

#softwareengineer #software #developer #noestimates
Sobat Continuous Delivery, Info tentang #Software #Estimations #Wrong ini bisa dilihat dalam bentuk vidio yang berdurasi 00:14:22 detik.


Sekedar mengingatkan bahwa, cso.biz.id siap membantu dan melayani berbagai masalah dan berusaha memberikan solusi terbaik untuk anda,

Apabila Dirimu, penggemar setia Continuous Delivery memiliki MASALAH apapun itu, kamu bisa silahkan dikonsultasikan di website www.cso.biz.id ini guna mendapatkan Solusinya.

Selain itu, Apabila anda membutuhkan peluang untuk mendapatkan PENGHASILAN TAMBAHAN hingga puluhan juta Rupiah setiap bulannya, Sobat bisa bergabung dalam Forum komunitas cso bisnis indonesia ini. ini.

Punya Masalah Why Software Estimations Are Always Wrong ? ..!! DAPATKAN SOLUSINYA, KLIK DISINI

Begitulah sekilas tentang Why Software Estimations Are Always Wrong yang telah dilihat oleh 30001 penonton, semoga dapat bermanfaat untuk kita semua. © Continuous Delivery 862 | #Software #Estimations #Wrong

0 Reviews

38 thoughts on “Why Software Estimations Are Always Wrong”
  1. Even simple tasks can have massively wrong time estimates. I worked on something recently that I thought would take just a few hours and instead it took 3 days to do. Once I was actually building the system I noticed that the data I was working with had a number of mathematical properties that made the problem much harder to solve. Trying to do that analysis ahead of time to come up with an estimate would have been most of the time to solve the problem.

    At least in my case, nobody really cared that it took longer they just cared that it was as correct as we could reasonably make it.

  2. I feel like here you're striking mostly a balance between overly complicated estimations and market research. How can a product owner estimate what's the ratio between least work and most gain if they don't know which epics imply the least amount of work. They still need some T-Shirt sizes. What happens to the bold ideas that require substantial amount of work vs small ideas with small impacts with quick implementation times. How could you know which one is better without some wrong estimates on which you can base your computations on

  3. Once everyone in the business understands that there is risk in the estimates of value and costs, the next debate is always, whose risk is it. If the Devs underestimate, shouldn't they work overtime? Of course not, but then who is to blame. I can't work in a toxic culture like that anymore, where anything that goes wrong or not to plan has to be someones fault.

  4. Practically nothing that has to take on a formal decision to develop is going to end up costing just a beer, for the simple reason that the overhead of such a decision is way higher than the cost of a beer, not to mention the overhead for deployment and integration if your organization has too much red tape there.
    Also, the car, vacation and months salary are comparatively close, especially once you take variations into account, which are big enought that those 3 could be in any pertubated order between them, with cheap used cars easily being less than a months salary, and the cost of an extended weekend trip by car to visit some family is a lot smaller in cost compared to a 6 week summer vacation far away staying at hotels or on cruise ship.
    To fix it, I would probably remove the vacation one, specify for the car that it has to be a new decently good car, and then below a months salary add in the price of a computer. The use of a computer is really useful, because a lot of things might need someone to get a new computer for something, and if it would make sense for a customer to set up a computer in connection to the service you provide, you already know that they would evaluate it at least compared to the value of a computer, because they would pay that as an additional cost. It also handles the fact that most actual task fall much well short of a month of work and well above the price of a beer.

  5. If you had a magic crystal that could either let you complete projects as fast as possible, OR give you the foresight to know exactly how long the project would take, which would you choose? Assume the quality of the project is the same either way.

    You'd think the sensible choice would be to be fast, even if you didn't know when the project would be done. And yet companies seem to always, always wish for the second option.

  6. Wherever I worked the estimations where never to decide if we should work on something but to know around when they would be expected, i.e. do we manage to deliver it in Q1 or Q3?
    I think the problem was never deciding what has value to work on but that came top down (another discussion altogether I guess)

  7. Great tool, thanks for sharing! I wonder were stuff like refactoring would fall, sometimes is hard and the benefits might not be reflected directly to end users, but overall I think improving the DX ends up being a benefit for the end user because of less bugs and faster iteration.

  8. A lot of true statements about reliability of estimation (though I am not too fond of the solution, starting with me being insecure if my vacation or my monthly salary is more).

    Still it’s a fact: if this new fancy gadget you would really like to have would be offered without telling you how much it is or when you will get it while requiring you to start paying a monthly rate already … well, even Apple would struggle to make this a success.

    And still below there are many commments that show a tech-only perspective that is close to being naive. Folks making fun about expectations from business. How could a poor little developer possibly predict the future?

    What Techies often forget (or don’t know?) that business people have to predict the future constantly. In sales you will not only have to predict next years revenue (ye, that’s 12+ months in advance). Most likely you will have to do that on a quarterly base – if not monthly.

    The difference? They call it ‘goals’.

    And the tiny 4-letter word ‘goal’ is already a huge part of the solution. For sure every nerd out there has heard about Parkinson’s law. For the none-nerds here: it says that any work will fill the time it is given. While it’s not true for extreme (and stupid) examples (nobody builds a particle collider if he’s given 5 minutes), for something the size of typical software project it works often amazingly well. Actually it worked for Nasa’s Apollo program. They were even faster as Kennedy gave them 10 years to reach the moon.

    The combination of ‘goal’ and ‘Parkinson’s law’ turns the question from ‘how much does it take?(time or dollars)’ to ‘how much is it worth?’. With this goal (or estimation) in mind software engineers can start thinking how a solution could possibly fit in.

    With a good old agile approach of small user stories, that add a little bit of value with every step, early delivery and constant refinement you will almost certainly end up with something that makes users’ lives easier with regards to the original problem statement. Within time and budget.

    But what is it that should be constantly refined? Remember the golden triangle of cost, quality and scope? Well, you shouldn’t mess with quality (you absolutely should define the required level of quality up front. A prototype is something else than a productive flight control system). And changing time (=cost) is not only what we want to avoid as this is basically the topic of this post – changing time is also a real lack of fantasy. What is left, scope, however is the mightiest tool in the box – and constantly under-rated. For most projects the exact scope is not clear. Even if is has been been fully and waterfall-like defined to a detailed level, you can bet that it’s not the scope actually needed. For sure you know a variant of this comic strip about what the customer asked for and what he needed:

    https://lizhendersondata.files.wordpress.com/2016/02/why-projects-fail.jpg

    So change the scope! Use the newly gained insights of every iteration to move to the right thing that fits into your budget.

    Does it work always? Well, it’s not a silver bullet and “small increments the add value one-by-one” is much easier written in this post than done in reality. It’s easy to get stuck for days on a problem without recognizing that it’s maybe even not worth it. And there are technical challenges that are hard to overcome.

    Interestingly while many people don’t seem to see this approach in professional software development it is constantly and successfully applied in daily life. From buying the cheaper alternative if the branded variant is too expensive to planning vacation: The time is quite set, and you cannot spend more money than you have (well, some do). So you change the scope. Maybe it’s not the exotic island but just the campground at the closest lake. And during your stay you will refine your scope from daily dinners at the fancy restaurant to fast food when you realize that you spent too much in the first couple of days. For sure you will not expose your lack of creativity to your boss by calling him to explain that you need to stay a little bit longer as you did not manage yet all the day trips you planned. And still, with all this scope changes you will have a vacation that helps coping with your problem of being constantly overworked.

    With the right mindset of all contributors, creativity and the ability to step back as a team and see the larger picture, maybe not anything but at least a lot becomes possible. Without crazy cost and time explosions, without having to complain about why nobody understands that software development cannot be estimated. In that sense I am fully aligned with #noEstimates.

  9. Please explain how saying "this is a medium size" is any different from saying "this is a holiday's worth of work" is any different? It's still estimating… it's still a guess. It's all the same cake, just with different sprinkles.

  10. Estimations are only valid if you already did something very very similar. That said, from a owner of a software company POV now, they are needed, because money allocation depends on that. So we really need to know a low and a high bar for an expected release.

  11. I really like the ideas from How to measure anything. The key is error bars are not a problem, unless they affect the decision, and if they do their is a way to price the value of new information. So the learn more part is about buying information. Reinersten is also of a similar mind. Our optimization is around U shaped curves, so there is a large range where performance is good. Thus simple models and measures are normally good enough.

  12. I've worked on 2 projects in which I can estimate that 80% of the time was spent on estimations, deadline negotiation, explanations on why the deadlines were missed, re-estimation, and anxiety-coping activities to deal with the stress of missing those deadlines.

  13. I am using a simple tool that looks quite similar to WSJF, but not with the same purpose.
    I ask stakeholders to give me their perspective:
    – What benefits would we like to create?
    – What happens if we don't do this soon?
    – What risks can we predict?

    – What's the simplest way to achieve this?

    What typically happens is that the answer is, "We don't know."
    I then take it from there … Divide and conquer, Slice and dice, experiment, inspect and adapt.

    But as a side note, it's amazing how common the concept is, "Developer, I need you tell me EXACTLY how long this will take!" – "I don't know. Can you tell me more about what 'this' is?" – "I don't know."

  14. Where do you stand on Prototypes using tools like figma? Prototype that has tested really well with users and we have figured out the areas of value. How can we work out how long to build those areas and release? Client is asking when they can have the system? What can I tell them without any estimate?

  15. How do you deal in an interview when the job description clearly says:

    Provide accurate development estimates in support of feasibility assessments and planned development activities.

  16. I usually share your videos to my managers to show them the problems we have can be fixed or at least mitigated using CI/CT/CD.

    However, this time it is hard. In automotive industry we have too make sure that the car is moving/behaving in safe manner. So each feature is worth the same because it has to be done anyway. The order of task defined by the customer. But it also standard to plan based those inaccurate estimates and to escalate on multiple levels of HiPPOs if the plan does not hold. Then re-estimates are requested which are wasting even more time although the more accurate due to the narrowed cone of uncertainty… for the next delivery even more planning and tracking (aka interruptions) implemented just to make sure.

    Any suggestions?

  17. These are old, tired points that have been shouted for well over a decade. Rehashed videos like this one simply repeat them, and don’t even begin to address the many counterpoints that have been raised (e.g., google “the case against #NoEstimates”). As such, it’s little more than clickbait, looking for disgruntled developers to smash that Like button.

  18. I was in a project management training, where they told us two things:
    – we can estimate a general task by estimating the best scenario, the worst scenario and our gut feeling. (Most propable scenario.)
    – this will never work with software. 🙂

    My issue is that I understand that software estimation is futile, but we have contractors, we have budget plan, we have deadlines, etc… I can't say to the management that I have no idea about the launch date.
    What I can say is that I have only vague idea about the initial (MVP) functionality.

    Usually our initial expectations are very high, we want a software that can solve world hunger and word peace while explores the deep space,, and my job is to cut the not-so-important functions during the project to meet the deadline.
    For this, we need some kind of estimation. (Which we have to update weekly.)

    In the end, we will have a software that is ready for deadline, we can give it to the users, we can try it and it has some "Coming soon" screens.

  19. As always, a well reasoned and insightful video Mr Farley. I can see how I could use the matrix towards the end of the video in a B2C context. Do you have any advice for B2B contexts?

    I work in a sector where the products are (generally) free to end-users and our customers work for businesses looking to reach/retain those end-users.

  20. Reg changes where there is a defined fine are probably the only ones where you have an accurate business value – it's the cost avoidance of the fine!

  21. Yes, of course you try to focus on the highest business value for the customer first, ideally involving the customer to guide that – that's just common sense, but to suggest any kind of estimation of delivery is pointless is clickbait nonsense. There's a middle ground between years and hours, you know? Estimating to the nearest month of delivery has been fine with most of my customers. We are going to be asked 'how long is this going to take' – what they really mean is 'what is this going to cost us' because time is money. Good luck explaining to most customers that if they have to ask, they can't afford it! That's a great way to lose business. What you're suggesting might be fine for some projects, not for anything I've ever worked on. The customer always wants things time-boxed, at least to a certain level. The trick is to give them the highest business value within that box and to try to keep the technical debt to a minimum.

  22. In a hardware company, by the time you learn a feature is too expensive for software, you may have spent an enormous amount of time and money in other departments (e.g. Hardware engineering, research, manufacturing). Unfortunately, answering “what next” for software doesn’t solve this.

  23. I am not computer scientist (or engineer). In my electronics background the definitions of accuracy and precission are a little bit different. A measurement is precise if it is repeatable, but it does not need a lot of resolution. Anyway, I enjoyed the video, and your channel.

Tinggalkan Pendapat atau Komentar

Produk dan Layanan

ADITIA NUGRAHA AGEN BISNIS AKTIVITAS AGEN ASURANSI AKTIVITAS AGEN PERJALANAN WISATA AKTIVITAS AKUNTANSI, PEMBUKUAN DAN PEMERIKSA AKTIVITAS ARSITEKTUR AKTIVITAS BIRO PERJALANAN IBADAH UMROH DAN HAJI KHUSUS AKTIVITAS BIRO PERJALANAN LAINNYA AKTIVITAS DEBT COLLECTION AKTIVITAS DESAIN INDUSTRI LAINNYA AKTIVITAS DESAIN INTERIOR AKTIVITAS DESAIN KOMUNIKASI VISUAL/ DESAIN GRAFIS AKTIVITAS DESAIN KONTEN KREATIF LAINYA AKTIVITAS DESAIN PERALATAN RUMAH TANGGA DAN FURNITUR AKTIVITAS FOTOGRAFI AKTIVITAS HOSTING DAN YBDI AKTIVITAS JASA INFORMASI AKTIVITAS JASA PENUNJANG USAHA LAINNYA Aktivitas Jasa Perorangan Lainnya YTDL AKTIVITAS JASA SISTEM KEAMANAN AKTIVITAS KANTOR BERITA OLEH SWASTA AKTIVITAS KEBERSIHAN BANGUNAN DAN INDUSTRI LAINNYA AKTIVITAS KEHUMASAN AKTIVITAS KEINSINYURAN DAN KONSULTASI TEKNIS AKTIVITAS KONSULTAN HUKUM Aktivitas konsultan kekayaan intelektual AKTIVITAS KONSULTAN KEKAYAAN INTELEKTUAL AKTIVITAS KONSULTANSI PARIWISATA AKTIVITAS KONSULTANSI TRANSPORTASI Aktivitas Konsultasi Bisnis Dan Broker Bisnis Aktivitas Konsultasi Bisnis Dan Broker Bisnis AKTIVITAS KONSULTASI KEAMANAN INFORMASI AKTIVITAS KONSULTASI KOMPUTER DAN MANAJEMEN FASILITAS KOMPUTER LAINNYA AKTIVITAS KONSULTASI MANAJEMEN LAINNYA AKTIVITAS KONSULTASI PAJAK AKTIVITAS MANAJEMEN DANA LAINNYA AKTIVITAS PEMROGRAMAN KOMPUTER LAINNYA AKTIVITAS PENEMPATAN PEKERJA RUMAH TANGGA AKTIVITAS PENEMPATAN TENAGA KERJA DARING (JOB PORTAL) Aktivitas Penerbitan lainnya AKTIVITAS PENERJEMAH ATAU INTERPRETER Aktivitas Pengembangan Aplikasi Perdagangan Melalui Internet (E-Commerce) AKTIVITAS PENGEPAKAN Aktivitas Pengolahan Data AKTIVITAS PENUNJANG ASURANSI, DAN DANA PENSIUN LAINNYA AKTIVITAS PENUNJANG JASA KEUANGAN LAINNYA AKTIVITAS PENUNJANG PERDAGANGAN BERJANGKA KOMODITI LAINNYA AKTIVITAS PENYEDIA GABUNGAN JASA PENUNJANG FASILITAS AKTIVITAS PENYEDIAAN TENAGA KERJA WAKTU TERTENTU AKTIVITAS PENYELEKSIAN DAN PENEMPATAN TENAGA KERJA DALAM NEGERI AKTIVITAS PENYELEKSIAN DAN PENEMPATAN TENAGA KERJA LUAR NEGERI AKTIVITAS PENYELIDIKAN AKTIVITAS PENYEWAAN DAN SEWA GUNA USAHA TANPA HAK OPSI ALAT PESTA AKTIVITAS PENYEWAAN DAN SEWA GUNA USAHA TANPA HAK OPSI ALAT REKREASI DAN OLAHRAGA AKTIVITAS PENYEWAAN DAN SEWA GUNA USAHA TANPA HAK OPSI BARANG KEPERLUAN RUMAH TANGGA DAN PRIBADI AKTIVITAS PENYEWAAN DAN SEWA GUNA USAHA TANPA HAK OPSI MESIN PERTANIAN DAN PERALATANNYA AKTIVITAS PROFESIONAL, ILMIAH DAN TEKNIS AKTIVITAS TELEKOMUNIKASI AKTIVITAS TELEKOMUNIKASI TANPA KABEL ASURANSI JIWA KONVENSIONAL ASURANSI UMUM KONVENSIONAL DANA PENSIUN PEMBERI KERJA KONVENSIONAL DIAN RISQI GADIS DESA INDONESIA JAJAK PENDAPAT MASYARAKAT JASA INFORMASI PARIWISATA JASA JUAL KEMBALI JASA TELEKOMUNIKASI JASA KONTEN SMS PREMIUM JASA PENYELENGGARA EVENT KHUSUS (SPECIAL EVENT) JASA PENYELENGGARA PERTEMUAN, PERJALANAN INSENTIF, KONFERENSI DAN PAMERAN (MICE) JASA PRAMUWISATA JASA RESERVASI LAINNYA YBDI Jasa Reservasi Lainnya YBDI YTDL KEGIATAN PENUKARAN VALUTA ASING (MONEY CHANGER) LAYANAN PINJAM MEMINJAM UANG BERBASIS TEKNOLOGI INFORMASI (FINTECH P2P LENDING) KONVENSIONAL Manajer Investasi PEDAGANG BERJANGKA PELATIHAN KERJA BISNIS DAN MANAJEMEN PERUSAHAAN PELATIHAN KERJA PARIWISATA DAN PERHOTELAN SWASTA PELATIHAN KERJA PERTANIAN DAN PERIKANAN SWASTA PELATIHAN KERJA PERUSAHAAN LAINNYA PELATIHAN KERJA TEKNOLOGI INFORMASI DAN KOMUNIKASI PERUSAHAAN PENASIHAT INVESTASI BERBENTUK PERUSAHAAN Pendidikan Bimbingan Belajar Dan Konseling Swasta PENELITIAN DAN PENGEMBANGAN ILMU PENGETAHUAN SOSIAL PENELITIAN DAN PENGEMBANGAN SEJARAH/CAGAR BUDAYA PENELITIAN DAN PENGEMBANGAN SENI PENELITIAN PASAR PENERBITAN SURAT KABAR, JURNAL DAN BULETIN ATAU MAJALAH PENYEWAAN VENUE PENYELENGGARAAN AKTIFITAS MICE DAN EVENT KHUSUS PERANTARA MONETER LAINNYA PERDAGANGAN BESAR BERBAGAI MACAM BARANG Perdagangan eceran bukan di toko, kios, kaki lima dan los pasar PERGADAIAN KONVENSIONAL PERIKLANAN Portal Web Dan/Atau Platform Digital Dengan Tujuan Komersial Portal Web Dan/Atau Platform Digital Dengan Tujuan Komersial Portal Web Dan/Atau Platform Digital Dengan Tujuan Komersial RDP GROUP REAL ESTAT ATAS DASAR BALAS JASA (FEE) ATAU KONTRAK REAL ESTAT YANG DIMILIKI SENDIRI ATAU DISEWA

Holding company

Kontakscreen tag