Summary
Notes
Transcript
So by the end of discovery for the client and for ourselves, we need to understand the number of components. We need to understand what the components are, what the variations of the components are and the plan of what happens to those components in cycle. So we're not expecting anyone to build them or anything like that. We're just doing the planning and the mapping. And then just to reiterate, because the design system is so heavily connected to this work, I already said to the client that this design system will not be completed in discovery. The design system takes a minimum of six weeks.
However, to show early progress in discovery, we will be showing you what a design system will be set, like how it will look in Figma. And by the end of discovery, you'll have 20% of the components with more percentage being added by each week. One question.
No worries, I was just going to basically finalise it with, obviously because we won't have all of the components ready for the design system, the first sprint internally, they'll use the 20% and then ideally the sprint after we'll use whatever's ready and then ideally by sprint three, everything else is ready. So, On the call this morning, Martin, you weren't present, but the team said that they were concerned that by the end of the discovery, which is we should be playing back the component mapping on the 23rd of June, which is three weeks tomorrow, the team were concerned that they might not be able to deliver it. So we're on a call just to talk about that current risk.
confident that we can deliver the component mapping in three weeks.
So based on the extraction that we've done, With the source code, there are around 100 components with around 400 variants.
So if we were to do I know. So if we were to do a like to like mapping or one on one mapping, that would mean a huge volume of components.
So right now, based on that detail, what they have shared, We held on. Android components. based on the sheet what they've given. Okay, so that's-So right now this isn't a page.
So the contract, sorry, one second, where is the, the contract said that it's a migration of 83 core components with 10 conditioning subcomponents and a migration of 12 templates. So how many components did they confirm on Slack?
We're trying to do quite a bit, but I want to just first understand how many components that the client has. So the client basically said on the contract, there's 84 components and there's 10 sub components. They've sent us a list. Just remind me on how many is on this list? 100. 100. Okay, what is in the actual source code?
In actual source code, there are 250, like something more.
There are too many, but I didn't ask each and every company. There are too many, more than 100 only. because they have legacy code also. So, I didn't go deep down to the source. Let me see if I can find right now.
I get you, I get you, but there's two forms of us doing it. That is, we get Mikko, Sneha and Varun doing a bunch of detective work with the source code and so on, orWe talk to the client and maybe sit down with someone, I don't know who their CMS editors are or who their design agency is. We should get together with them.
That's kind of my point, Meg. So if I please, I'm not trying to put words in Mikkel's mouth, but it seems to be like, okay, there's a list here. He says around 100. He talks about the source code. He knows that there are some decommission. So what we should tell to the client is that exactly that there's a round list. but Ideally, we would talk to your CMS editors or somebody who is day in, day out in the CMS to assess this list with them and maybe even have a look ourselves behind the scenes to how this is set up, right?
Sorry, but I explained this to George in the past as well, and I'll say it again. We've done like-for-like migrations before, but they never are actually like-for-like migrations because we changed the entire architecture. So I've not looked at this design system in detail. I've not looked at the source code. I've not looked at anything. And I can tell you from today that if you let Sneha work on this, you will not end up with a hundred components.
You can reduce this to about 60 probably. And that's what we will end up doing. Because they will wonder if the textures work differently. That's part one. So the site needs to be the same, but everything underneath that will not be structured the same way. But that's part one. This part two is around either it's a like-for-like migration, but the underneath doesn't look the same. And B, what this requires is, that's what I'm saying, I don't have the context of talking to the client, but once you talk to the client, what we need to understand is they want something that looks and feels the same, but probably that is as easy or more easy to use. So aligning with them and their CMS people will be useful.
So right now we don't know which are legacy components which are being used right now which are not being used right now so that we don't know as of now right now because right now we only have source code we don't have CMS proper CMS access also that you can see.
It's not about CMS access, Megan. It's about understanding the CMS. We scholars are already being scheduled. We are already going to have a schedule. And this CMS access, I got today morning. and Varun got last Friday or something. So we, and this is there right now, but we don't have anything apart from this. If I go to project, there is empty. I don't see anything. So I don't know how this has been working.
So before that, even getting to CMS better and better if client can give us this detail that, okay, these are the final component. Okay, fine. We'll work on this rather than just scratching around 250 components.
Confluence is not updated. Few of the components fields are not updated over here, which are there in the source code. So that also mismatches that.
I'll tell you exactly what you've said. Sorry Sneha, but the conclusion is exactly what you said, right? It's going back to the client and saying, "You've told us this is the source of truth. We look through it, we look through the source code, we look through the website, and it's not aligned. We can build from your source of truth, but that's not going to deliver to what you're asking us to deliver.
Okay, and--Another thing we can do, which is easy, that takes component name from here, and field name from the source code.
Which because the field name source code, why I'm saying that? Because it's the live site. So if this component has been used, the fields which have been used in this component are already there in the source code and most probably this has not been updated in the conference, which is fine, but then we have to do both the things. Component name from here, fields from the source code.
What I think you should do is, I think you should 100% early highlight the conflicts, but still do the exercise because the client is going to look for your expertise.
Now, if their confluence is out of date, if I was the client's shoes, they're probably going to say, of course, the code sauce is going to be the most up to date. So here's what we do. These are two actions. We first put a message on the Slack channel and basically explain, we're working on the component list. Obviously, part of... So what I would do is I would say, hey, client, here's the audit that we're working on. This is the template that you're going to see. As you can see from this template, we're going to be mapping your current components to obviously the new world. We're sharing early visibility that we found some discrepancies.
So first 20 we could do, we could like take screenshots, verify it because this needs human verification. Like Claude is not able to like do that type of consolidation and mapping. So this is something that we'd have to do manually. And that's where the effort would go. come up with an overview, right? We could come up with a list that's more or less correct, but there will be changes as we move on with the sprints. Um...
And that is also added in the conference. And template we can verify right now is because we are not able to Like CMS access is there, but local solution I'm not able to run because they need to give like If you need to walk through us how this CMS works actually. and how we can get the template to view.
It's a great question. Sounds to me, I don't know how, I might have to review your process and what you promised to the client by when. of what we promised to land by one. But what we also need is a priority of these components that we're agreeing or a framework for how we're going to put them together, right? There will be, we said 20% by the end of discovery. Most likely, there's a 20% of components that carry 80% of the presence on the website.
Those components will house most of the content. or importance, like the navigation will be in 100% of the pages just on the footer. And then those will align with what are your key journeys, which is probably the top experiences. So let's align what are the top templates, what are the components that repeat the most across the top template. And then there is an idea of what are the critical interactions from journeys and what components are there in those.
So critical interactions might not be so visited by traffic or whatever, but if they're visited, they shouldn't break, I don't know, decencies, forms, compliance-driven stuff. If we have that, we have the mapping of most things and then we can explain to the client after that, that there is a long tail of components that as Neha says, we will keep defining as we're building this.
Yeah, so Megan, if you see right now, Claude has done this much thing that what component will we keep inside code and what will integrate. Thinking that this is anchor ID. Anchor ID we don't need in Sitecore. It's just a field. So it is added as a field. This component, atomic card, we don't need as a component. It has been merged with card, it can go with this component. We don't need a separate component. So actually it has given us the brief idea.
I don't just want to go, just before we talk about, I just wanted to check, have you guys tried doing like an export? Because there is an ability in Adobe to do that. You can export it. You can pull all the components.
That's what I'm going to do. I have also done, but right now, today morning, we got up. entirely new component which has 20-25 components has been updated like 20 years been like we had old list what we got from the conference, but that was not our source of food. Whatever you got in the, yeah, this has been updated now. And this is final right now.
So I will again run it. with the source code and the confluence and I'll give you the report what we are expecting right now. So which I can do by today evening and tomorrow morning, I can ask them that this is what we found out. what we are expecting to give them that source code has this many fields, confluence has this many field, Now you tell us how should we proceed like. Is that fine?
that this is what we think we should do and that this is what we think we should do and Yeah.
But I don't... I don't think it's about what we can do. I think this is about the contract and the estimate, right? So we need to basically, they told we have a set amount of components to migrate from the contract. If they've got more than that, then I imagine that increases the estimate. So we need to be clear. honestly here's what I would do right it's only day one of kickoff right the project is only just officially kicked off I would basically raise the visibility to the client and not let them do anything and rather than speculating I'd actually do the order like actually sit down in a and maybe time box it to Thursday and come together with an outcome for the client hey this is what we've done we looked at your references that we're already aware of let's have a chat because they're not expecting this already and the early visibility is enough to say this is coming but I just don't feel like we've we've done enough of the actual exercise yet like ideally you need to do the actual exercise, right?
You need to actually work out the list yourself because the exercise is to prove what is right or wrong. A client gave us a list of components seven months ago. I imagine by then they've added more on. So it's our job to confirm what is the final list today and then debate that with them. So I think it's more than acceptable from a project management point of view to raise a raid log to know that we've already found some discrepancies.
They don't understand enough about site core. So is it fair to ask you guys to raise it as an early visibility that I can do on behalf of project management and for you guys to continue for a few more days to work on the audit and then we revisit?
Okay and just the one thing I'd say about the components like don't get hung up too much about the discrepancies. I appreciate that they might seem like they might derail you off the task but during this process there is going to be discrepancies. No in an ideal world are we ever going to get a list from a client that is the actual list because they obviously gave us a list and then contracts happen and then things change.
So on the design side, I've already started working on foundations, right?
So I'm somewhere around 60-70% of foundations completed on my side. I would continue to do like 30% more this week and then finish the whole foundational setup. And I'm hoping that this week when we have the list, I could start on the first 20 components that do the major lifting, right? So 80% of the work, the heavy lifters, I would pick that up and I'll start working on those. Hello?
Can you hear me? Sorry, what I was trying to say was that on design side, I've finished around 70 to 60 to 70% of foundations.
And I'll keep working on it alongside the audit and the component list. Once I have the component list, I'll be working on the first 20 components that's doing the major heavy lifting. And that's the design side.
I, So I think that there is two micro exercises in between you doing that and us and beginning doing the components, which is a mini sense check or prioritization of justifying why you're going to start with one component or another and aligning with Mikkel and the rest to say, okay, these are not only useful because they carry a lot of content, but they're useful for Mikkel and team to set up the CMS or whatever.
I get that, but that's one parameter that shouldn't drive the entirety of your decision. So one parameter should be how many times is it used, but another one is how you solicit for us to set up whatever. How we solicit it for Miko. Yeah. in place or how critical it is to the experience, even if it is not used that much. I'm assuming there'll be three or four pieces of criteria. define why you're choosing one component over another and define your first list.
So it's just maybe a slide or something that fits in an email, but it's a micro exercise that we need to do. Um, And the... Second one I was saying is looking at it, maybe I'm wrong, because you've been looking at it properly, but I am quite convinced that there is more than 100, but there probably shouldn't be more than 100. So it's an analysis of consolidation, which two components are there out there that actually should be one.
Yeah, that's part of what we are trying to achieve through the consolidated list on our side between me and Mikul.
So the first one would be to find out the discrepancies and then the second one would be to consolidate based on those discrepancies.
So just to confirm then from the call that basically the contract was 83, the confidence is 100, the source code is 200 plus. We're raising to the client an early notice of risk that the audit will result in the difference. This is a heads up that it's coming that they will need to review. Priority is Meekall and Suneha to finish documenting the differences. before we do the mapping. And then in the component audit review meeting that we have, we need to confirm the final number.
Do you think it's fair to say, as between a client and horizontal, that by Friday this week, we will confirm the final number for mapping? Is that doable? Not just the number? Yes.
It's the automation and the hybrid approach, Meg.
So it still needs a manual intervention. It still needs us to have a look at it. So it's this hybrid approach. That's basically I would say taking some more effort than usual. If everything could be automated, It'll be great, but it does need like monitoring It's making a lot of mistakes.
Otherwise, We will end up. We should not like, and in this case we should not blindly follow cloud, whatever it's in.
I just want to be really, really clear on something, okay? AI is secondary here. The priority right now is we have three solid weeks, right? The client is not expecting to see this mapping until the week of the 22nd, okay? So as a team, ideally, we do not want to wait until the week of the 22nd to confirm the number. At least when we're happy with the number, we should confirm to the client the number as quickly as we can.
actual mapping and like going through ins and outs you've got three weeks to come prepared with that all we need to confirm right now is what is the final number that you're using to model that exercise on if there's any risks which you guys are already vocalizing so we can share that with the client and then we've literally got more than three weeks guys we've literally got over three weeks tomorrow to actually present back an excel that basically has information for the client to digest so let's just tackle the main priority is let's get the number down and then you guys have got time to do the audit The other thing that I would say is that Now, because it's a like, this is what I said to Meikle before, in my head, and I think the client thinks like this as well, it's a like-for-like migration.
So I'm pretty sure the client knows that as long as their site looks the same on the front end, they're going to be fine with it. We just need to basically tell them that the back end is going to be different. And if for some reason, by the time we enter discovery, if we don't have a clue, if we don't know yet how every single component will look in the back end, don't stress that does not mean we need to not enter out of discovery it doesn't mean we need to extend discovery we will just re-pivot the plan and basically tell the client that 20% of your components that are in sprint one this is what this the front end's not going to change this is what it's going to look in the back end sprint two will give you the rest sprint three we're going to look the rest we can always pivot the plan do you see where I'm going with this Yeah.
And just to be super clear, to enter out of discovery, the definition of entering out of discovery, right, is that we've confirmed the current as is, right?
So we know how many components there is and what we're migrating, right? And then the other thing we committed to is that in design is just to get enough components that the client is happy with of how it's going to work and our internal team have enough to develop. We're not expecting every single component, like for like of how it's going to look in the backend. or it maps to a design system we don't need to do that to enter out of discovery Okay.
The template, can you just reshare it? May I've lost it in the Slack. Let me upload it to the client's Confluence because it's only on ours. And let me explain it to them on the weekly status, exactly what they're going to get and flag this risk. And then in the meantime, you guys can continue to work on the discrepancy. And then also think about the demo that we're going to have in it, what we're going to build on Cloud.
few weeks right they don't need every component maps they just need three components mapped in the back end this is how Sitecore works and we'll be very very clear with them that you might not see every component until UAT but it's the best we can do so we can explain that to them. Yes. um but what we sorry just to confirm it i keep saying every component what we need to not miss is the found that is the setup but i'm going to use the word setup as a client they must understand how a design system works right they must understand they must leave discovery knowing how the design system is set up 100 right they need to fully understand that that's how it's going to work then when it comes to site core they don't need to understand exactly how everything's going to be built until it's built but they need to understand the fundamentals of how what's going to be different for them right what's going to be different for publishing a component what might they have got on adobe but they're not getting on site core as long as we give them the basics and the differences then we don't have to explain every single component if we don't have it Okay, cool.
These would be your high impact 80% of the work is being done by these 20 components or these 20%. That's what I wanted to do with this and That's where we're going actually and one more thing which Meg is missing out on Martin is that we have been receiving input every day, new input. And this does not... It does not, we are not accounting for this new input. Every time we feed something into clod which is new it re-evaluates everything it also has to update everything it's done so far So that's why we need to have a full stop at all the input and then we churn out the output.
because If we keep changing things, it's gonna give us like a lot of discrepancies like how we're talking about, right? So we need to have Like one day where we've received everything we needed or at least majority. And that's when we create output. Output's not the problem, it's creating the right accurate input.
In terms of improvements and prioritization We spoke with the client, we had the first meeting, the onboarding, and there it was decided that the improvements are mostly going to be from the point of view of standardization.
and WCAG compliance exercise. So any improvement or any changes?
in stage one and then phase two would be when I don't know, hopefully we get a continuous...