Project management *

Creation of a UX design for a software product is an ongoing process: it doesn’t stop after the product is released. In order for an app or a website to always remain comfortable to use while corresponding to the constantly changing trends, its UX design must be improved from time to time, and in some cases even rethinked and radically changed. An outdated, old-fashioned design with unimproved bugs will definitely spoil user experience and lead to loss of audience. Design improvements include not only bug fixing and “brushing up” the facade of a product, but also constant research and implementation of new ideas that can contribute to its growth. Let’s discuss a few simple steps that can improve the UX design of any product. 

Sometimes it seems that jokes about management implementing Agile to do more with less aren't far from the truth. I've rarely seen development teams understand Agile as anything more than a set of ceremonies, most often associated with Scrum.

In my experience, attempts to optimize team performance often boil down to changing the internal processes within the team itself. Meanwhile, critical decisions are made outside the team, remaining in a waterfall model. This creates a disconnect: on one hand, company management strives for the flexibility of Agile, while on the other, they continue to follow rigid patterns, limiting the team and preventing it from fully realizing its potential.

Hi! My name is Slava. I am currently working as a leading Product and Senior Project Manager at Uzum Bank. One of the leading digital banks in Uzbekistan.

We are growing fast. Really fast. Speaking in numbers, our interest income has increased x10 over the past year (!).

And, as in any similar projects with rapid growth, we constantly lack qualified personnel. So I and my colleagues always have a lot of work to do.

I have two teams with completely different products, and I also manage some projects as a project manager. And I have my own small business – an online tea and coffee shop. And in conclusion, I am the father of two small children)

So, I hope this makes it clear to you that I have faced all the problems, such as working at night, lack of sleep, working in a noisy environment, calls with crying children in the background, calls during breakfast on the wheels, when I take a child to kindergarten (never do that!) etc. and so on and so forth XD

You can ask me: how do you manage to do everything?
The answer is simple: I don't XD

But. This forces me to build a system that helps me quickly switch between different types of tasks, focus quickly and complete them over and over again.

So, today I want to tell you about one of the things, that can completely ruin your day. And sometimes – whole week. It's called "context switching".

Modern product development demands more and more sophisticated designs. This in turn leads to the increased complexity of both demand and implementation. Business is flooding the architecture and development teams with the new and changed requirements. Development teams are struggling to understand what the business demand is and find the best product increment strategy. One of the widely adopted conversational methods is the Use-Cases. This guide is intended to shed light on the process of the requirements development and maturing.

In the software development industry, a lot of time and resources are spent on meetings. Many managers have calendars filled with meetings most of the time.

According to a study by Atlassian, the average worker spends up to 31 hours a month on unproductive meetings. That's about 8 hours a week, which is equivalent to a full work week for one employee out of a team of five people every month. If we convert this into working days, it means that on average four people are working, and one is constantly in meetings. This does not take into account additional time spent on informal discussions and ad-hoc meetings, which further reduce the time available for direct work on product creation. Thus, developers actually spend less than half of their working day on direct development, which is a worrying sign for any organization striving for innovation and efficiency.

Personally, I don't like meetings. I always try to minimize communication if an issue can be resolved without a face-to-face meeting. I apply this rule both at work and in life. For example, I prefer to refuel my car using an app, and I try to order food and other services without needing confirmation from an operator, and I did this even when such an approach was not so common. If I need to find a place, I will open a map in the app, instead of asking passers-by for directions.

My reluctance to waste time or be inefficient has resulted in our software development department carefully monitoring the time our developers spend on meetings. On average, a developer has only 2 hours and 15 minutes of mandatory meetings per week, including four 15-minute stand-ups, a 30-minute one-on-one meeting with a manager every two weeks, and 60 minutes for various meetings such as planning and demonstrations. The rest of the time, about 5 hours and 45 minutes, is spent on other activities in MS Teams, including chats and individual calls. Although we believe that this time should also be optimized, we focus mainly on key meetings to ensure that every minute spent is valuable.

In this article, I will consider the approaches I use and the ideas that motivate me to minimize the costs associated with meetings.

Getting feedback on the design of a digital product from the other members of the development team, stakeholders and clients is an essential part of a UX designer’s job. Ideally, it provides constructive criticism of the design, helps improve the product and perfect it as much as possible to present the best result of work to the users. But getting feedback doesn’t always happen smoothly – when communication is not established properly or the goals of the process are defined incorrectly, things can go the wrong way. In fact, both asking for feedback and giving it requires following some unwritten rules in order to make this experience useful and comfortable for all parties. In this article we’d like to discuss two things: how to ask for feedback correctly and what to consider if you’re the one who’s giving it.

Today, many companies are transferring their development processes to Agile frameworks. In this article, I discuss how the concept of a Project and the position of classic Project Manager are transferred in accordance with the Agile paradigm.

- Continuous Improvement is also a Project, a meta-Project, a maintenance that usually lasts longer than the main development project.

- If you can fit into the Sprint boundaries with your development cycle, then the concept of Retrospective as it is formulated in SCRUM may also suit you. But if you are bigger and not oriented on CI/CD, then be ready to make a hybrid of SCRUM with classical Project Management – thanks God SCRUM is good embeddable (proven by SAFe) !

- What is left out in when we run retrospectives quarterly? – Plan and Check. The placeholder of classical SCRUM Retrospective is quite suitable for that purpose, surrounded, of course, by some additional groomings, providing required action plans and decompositions up to sprint-length steps.

Hello, my reading friends!

My previous post (rus) on Habr was about how the Business Continuity Management function started, as well as about its relations with other corporate functions. In fact, it was quite theoretical.

This time, I’d like to tell you about some practical vectors of procedures and tools implementation as regards to Business Continuity Management, or BCM, along with Operational Resilience, or OpRes. Plus some real initiatives that can follow the BCM & OpRes implementation in a company and the associated with it investigation of the corporate landscape and procedures.

Recently, The BCI, one of the leading institutes working in the field of organizational resilience and business continuity, issued its regular report BCI Operational Resilience Report 2023 in collaboration with Riskonnect, who work with risk management solutions.

One of the questions they asked the respondents was if there was a difference between organizational resilience and operational resilience. As the answers demonstrated, for most respondents (and in most companies) these terms were used as synonyms. Having studied the report, the colleagues brought up another matter – The BCI introduced the new term of "organizational resilience" in addition to "business continuity" and "operational resilience".

If we search Habr for "Business Continuity", "DRP", "BCP", or "BIA", we’ll find quite enough posts by my colleagues (I’ve met some of them face to face and worked with the others) about data system recovery, data system testing, fault-tolerant infrastructure, and some other things. Yet, hardly any of them explain where all of it has come from, how it is changing, where it is heading – and why.

I thought the time has come to change the situation for the better and answer some of the questions like where business continuity provisions and operational resilience has come from, how they are changing, and where this trend is heading and why. To share my thoughts about development of the industry and its current de-facto state in case of a mature (or not too mature) introduction level – some things I’ve stated for my own use.

This article is written in a how-to style. It is based on my personal experience and opinions, so it may omit some steps that are common in BPM practice but that I have not encountered in my work. The topic is broad, and each section deserves a separate article. Therefore, if you are interested in a specific topic, please comment, and I will prepare a more detailed description.

Regardless of how mature the product is, its owner will always be curious about how it performs, what the conversion rates are, and what areas for improvement there are. One of the most important tools that product owners should get access to at some point in time is an event tracking system.

As a product owner, it is common to face the question of whether to proceed with option A or option B. Or, which version of the screen should be implemented to achieve better results? Making such decisions can be challenging, especially when you are under tight deadlines with limited resources. Furthermore, such decisions are made based on personal judgment or copying the approach of a competitor, which can lead to suboptimal results.

The good news is that one can avoid such pitfalls by setting up a simple experiment environment that requires relatively low effort. In this article, we will describe how you can achieve this.

Background

As a product manager with over a decade of experience, I'm always looking for new ways to enhance my skills and help other product managers advance in their careers. One area that many companies focus on during the job interview process is analytical and creative problem-solving. And as product managers, we encounter these types of challenges on a daily basis. It's important to stay sharp and continuously develop our problem-solving abilities. That's why I made it a habit to practice a logic puzzle every day. But I also wondered if there was a common approach to solving these puzzles. That's when I discovered TRIZ – the Theory of Inventive Problem Solving. In this article, I'll provide an overview of what TRIZ is and how it can be applied in product management. Then, I'll apply TRIZ principles to solve a series of logical puzzles, showcasing the power and effectiveness of this methodology. So whether you're an experienced product manager looking to enhance your skills or someone who enjoys a good brain teaser, read on to discover the power of TRIZ!

If you find TRIZ to be a useful tool for problem-solving and innovation, there are many resources available to help you delve deeper into the methodology. The TRIZ Journal, for example, offers enough information on TRIZ, including case studies, articles, and other resources. You can also find books and online courses that provide a more in-depth look at TRIZ and how it can be applied in different industries and contexts. So if you're interested in learning more, there are plenty of opportunities to expand your knowledge and apply TRIZ to your work.

This is the first post in a series on Business Process Management (BPM). Having worked as a business analyst and product manager in various companies ranging from middle-sized startups to big corporations, I have observed differences in approaches to business process management - from almost complete disregard to excessive attention. So, I decided to share my views on the topic, why I think BPM is important, especially when a company grows fast and switches from the startup stage to a grown company, and what approach I think might work for a company of average size without involving too much time and resources.

Product Backlog Refinement. Is it worth the effort or a simple waste of your team's time? Vladimir Zolotopupov, Head of Analytics for Innotech's Automation Department, shares his team's experience and describes how they handle the PBR process.

When you have an IT, which supports all aspects of your organization automated performance and you have a firm confidence that IT executes well, there is always a chance that something could go wrong in technology or in related IT processes. Depending on complexity of IT environment varieties of risks scenarios could arise. This article as a summary of different faithworthy sources aims to help you in getting high level understanding on what could go wrong and how you can predict it in a more conscious way.

My name is Maxim Tornov and I have been working in various IT areas for a long period of time. Since then, for over 14 years I am working in the area of IT/IS risk management with focus on in IT/IS audits, internal control implementation and assessment.

I am sure that at the present the topic of Information Technologies risk management became more vital. Organization’s efficiency in IT risk management directly affects the achievement of various organization’s goals, goals which have dependency on IT, those goals may include reliability and efficiency of business processes, the organization's compliance with regulatory requirements, the integrity of financial reporting, and many others.

I sincerely hope that this material will be useful to you and may give you some new ideas that you can contribute to the benefit of your personal development and the development of your organization's risk management culture.

Tools to improve and control code quality can be a key success factor in a complex software project implementation. Static analyzers belong to such tools. Nowadays, you can find various static analyzers: from free open-source to cross-functional commercial solutions. On the one hand, it's great – you can choose from many options. On the other hand – you have to perform advanced research to find the right tool for your team.

Hello everyone! Welcome to the second part of the PVS-Studio Team's Kanban Board story. This time we'll talk about YouTrack. You'll learn why we chose and implemented this task tracker and what challenges we encountered. We don't want to advertise or criticize YouTrack. Nevertheless, our team thinks JetBrains has done (and keeps doing) a great job.

Content marketing is an endless endurance race. You can’t put a cap on business growth, even if you’re a tech industry giant. A single success is not enough — every time you reach the finish line, it moves further away. Retaining your existing customers is no walk in the park either. When you go silent, you are actively ignoring your audience. There’s no way around it — you need to pump out content.

However, doing that day in and day out requires a lot of stamina. So let’s look at why we get tired in the first place, and figure out how to avoid it. [Previous article: The true cost of free labour].