Expertise is delivered by Serhii Denysenko, СEO of the IT outsourcing company LENAL
There is no better person for explaining how to handle tough situations than ex-MHA officer, ex-lawyer and programmer in heart. Others could have wasted your time, but not him. His answers are short, precise and hit the point.
Serhii has been sharpening his skills on the IT market for 13 years by now. Together with his partners he founded LENAL in 2007. It is an IT company of full digital production cycle providing consulting and auditing services, web & mobile development, UI/UX design and post-realization support for digital projects.
Since then he’s had about 500 successfully executed projects. Among company’s clients there are such giants of Ukrainian retail as Epicentr-K (development of Tochld terminal system and 27.ua), Ecosoft, Belorussian doors and many more. LENAL is also widely-known as an official web-developer of BNP Paribas Group (UkrsibBank) in Ukraine.
We were lucky to catch Serhii for getting his expert opinion on problems businesses come across when developing a web project.
So, what are the main bottlenecks of creating a web product now?
The first stumbling block which in fact has to be rocking is your team. In our case it’s a scrum team and in our company it looks like that:
The Scrum master heads the process from our part and the Product owner – from a client’s part. This is just an example how it’s organized in our company. But teams differ from company to company so you must always look what specialists you have.
By now it makes sense.
In ideal world – yes. But in practice that’s where problems begin. And the first one is Vague hierarchy
First you need to organize in your company is strict interaction:
- within your team so that everybody knows what his colleagues are doing right now. As you may have a star team but poor involvement in common process will lead you to chaos.
- between your team and the Product owner’s team, preferably through the Product owner who will coordinate it all. As sometimes when your departments and his departments do different tasks it impedes the product’s testing and even releases as they are totally dis-coordinated. So, organize it well. Otherwise your whole work will be a total mess.
Sounds like a serious problem!
It is. As poor interaction usually results in Lack of communication and then misreporting. To avoid it you, the Product Owner, need to:
- Prioritize the tasks;
- Make a work breakdown structure so that the team could clearly see all sub-tasks. The scrum team must do the same, I insist on its paramount importance.
- Make the most detailed description of all tasks so any nuances that might influence proper tasks completion are covered;
- Both your team and the scrum team must know what your final goal is, what your final product will look like.
What else could impede the team-building over the project?
Staff rotation. Staff changes within the project. It’s one of the most difficult parts as re-make of all that has been done or integration of new ideas may cost you extra money and effort. So try avoiding it if possible. Otherwise meeting deadlines may become a problem. But you can cover your bases by building up smooth processes and back it up by supporting documentation. Never let your project depend on 1 expert!
Oh, we come up to one more nightmare of any Product Owner and his developers.
Deadlines. Right you are! When setting the deadlines try to be realistic. As both too short and too long are bad.
Too short deadlines usually originates from your wish to start earning the soonest possible. Still it tends to ruin all coding standards and projecting work, as you will have no time to really think it over. Less time will mean less functionality.
I agree but what’s wrong with too long deadlines?
Too long deadlines are often advocated by top-managers because of over-functionality of the project resulting from exaggerated budgets. Thus, they may suggest adding the functionality Ali-express or Amazon like. You mustn’t aim at an ideal project, just start releasing and see what you can improve. As new tricks are good but by the moment they are approved they can be out of date already. Keep it in mind while taking the decision.
Is your work always about meeting the deadlines?
No, there are more things that also impact your team’s work a lot try to keep the rhythm. Sometimes the workflow is quite chaotic: either a feast or a fast. So ensure that all tasks are distributed equally. Don’t overload people and don’t leave them without work at all. Also provide timely approval of all the current and future tasks to avoid stagnation.
Sometimes deadlines would depend on budget, no?
Not that much I should say. But it’s a really important component of any project. So, let’s talk about Budget.
Choosing between under-financing and over-financing the latter is a better case?
To my mind, both cases are bad. Too low budget equals to:
- Semi-qualified staff (not always, but mainly);
- Overlapping of responsibilities, for example a programmer functions as a programmer, QA, Front-end developer and even Product manager. Apocalyptical decision.
- Staff turnover which will definitely incur great losses if some key specialists suddenly leave the project in the middle. As small budget equals to shortening deadlines and exerting pressure upon your team;
Ok, I agree, but what’s wrong with the big budget? Any agency must be happy to get one?
Strange, but no.
- Over-funded budgets are tempted to use great number of excess resources. It automatically extends a payback period for business.
- Communicating problems are snowballing. It’s like in the question: “A woman needs 9 months to carry a baby. If we take 9 women, will the term decrease to 1 month?” The answer is no! As the person’s resources are still limited.
Enlarging the budget will substantially increase the project’s cost. But your team and you must clearly understand that it doesn’t mean that if you increase the budget your project will be developed faster.
Speaking of web products’ development I thought we’ll start with technologies at the very beginning.
Yes, that’s one of the basic matters. But I believe that people go first. As for Technologies.
They must correlate with:
- your task. You must have a clear grasp of further development of your business, what tasks may arise during transformation process and choose the technologies accordingly;
- your budget as your main goal is cost-effective investing and deriving profit the soonest possible. So, we must always take into account the cost of acquiring, maintaining and supporting of various technologies and paying to specialists who know them well. For example, we can use Oracle, the question is why would we need it, whether it’s really worthwhile. Any technology presupposes either some time for building up a correct architecture or some difficulty to find staff possessing rare skills;
- some inner standards of the company. For example, if it’s a bank it has some peculiarities of data processing which influences the technologies’ choice;
- server capacities. Sometimes it’s difficult to scale the project with some technologies taking into account the capability of infrastructure;
- support capacity it afterwards. Thus, if you have a temptation to use some hype technology, try to predict whether it will be supported afterwards. In our practice we dealt with the Google Polymer once. It was soon after its release. We gladly grabbed it for our project but very soon Google stopped supporting it which incurred losses both for us and Product Owner and we had to re-make the project using standard technologies. Of course it’s a rare case as often technologies have supporting communities and in such a way they’re being reformatted. What I mean is that just be very selective with the technologies you need for your projects.
- the level of competence of your staff. Sometimes outsourcing of professionals is the only way to ensure your project will be done properly. This is the case when you need some rare skills which you can’t find among your staff. In such case be ready to motivate the specialists you invite both by money and the idea to test their professionalism and gain the result which could contribute to their career portfolio.
Great! Any follow-up?
Right! I would summarize all the above with three main points:
1) Business and scrum team must learn to prioritize the main functionality of the project and organize testing various hypothesis at a reasonable price before scaling up demo version of the product;
2) They also must cooperate with each other on a win-to-win basis;
3) One of the top priorities in web development process is a detailed analysis and fragmentation of the tasks into smaller ones;
Hope all the above information will be helpful to make your web-development process smooth and easy-going.
Follow us at the official web-pages of LENAL. In case any additional questions arise contact us at email@example.com and our specialists will be glad to share their expert opinion with you.