Management

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.

Switzerland: the very name conjures up images of pristine alpine landscapes, picturesque villages, and a sense of tranquility that seems to permeate the very air you breathe. It's a country that's often synonymous with beauty, precision, and adventure. Whether you're a nature enthusiast, a history buff, or simply seeking to indulge in some of the finest chocolates and cheeses the world has to offer, Switzerland has something for everyone. So, if you're planning a trip to this enchanting land, here's a curated list of must-visit destinations and experiences that will make your journey truly unforgettable. 

RSS 2.0 specification was published in 2009 and hasn't moved from that point. The popularity and website adoption of this standard are dropping. People stop using it as it can't compete with social networks owned by big companies, and publishers stop using it is not rewarding. Let's review, analyze, and suggest a possible alternative to RSS. We will go from a concept to a working prototype.

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.

This text is a compilation of author’s experience, written to provide new juniour/middle teammates the basis to start developing computational intensive or/and ML based systems. It will take you about 5-10 minutes for reading.

Опросы – это не просто инструмент сбора мнений; они являются мостом между компаниями и их аудиторией, позволяя не только узнать мнение клиентов, но и вовлечь их в процесс создания и улучшения продуктов и услуг.

Сервис опросов Тестограф предоставляет широкие возможности для создания опросов, тестов и голосований, обладая функционалом, который позволяет не только собирать данные, но и анализировать их, делая выводы и принимая обоснованные решения на их основе.

Эта статья будет интересна широкому кругу читателей: от HR-менеджеров, стремящихся оптимизировать процесс подбора и оценки персонала, до маркетологов, ищущих пути повышения эффективности своих кампаний через глубокое понимание целевой аудитории. Она также окажется полезной для специалистов по UX/UI, стремящихся улучшить пользовательский опыт на основе реальных отзывов, и для организаторов голосований, желающих обеспечить прозрачность и достоверность результатов.

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.

Last week I was doing a seminar on SystemVerilog, ASIC and FPGA at ADA University in Baku, Azerbaijan. I will replicate the last two sessions of this seminar, on RISC-V CPU simulation and synthesis, at the Verilog Meetups on March 3 and March 10 at Hacker Dojo, Mountain View, California. For this reason I am combining the information about Azerbaijan and California seminars in a single post.

First, let's talk about ADA University.

This week, I was reflecting on a recent one-on-one chat with a manager in my division about keeping our backlogs clean and dealing with those tasks that just keep getting pushed back.

I jot down my thoughts and decided to share them with you. It's a common issue, right? Tasks hanging around, always getting postponed. Let's talk about the mess this creates in our backlogs and how to handle it the right way.

Check out my latest article where I dive into the art of backlog hygiene. Trust me, your team will thank you for it!

The meetup on January 14 at Hacker Dojo in Mountain View, California, went well, although not as planned - we spent almost all the time talking instead of doing hands-on exercises. The room we booked can fit 30 people and approximately 30 people did show up. The quality of participants was high: approximately half were familiar with hardware description languages and another half came from various software topics. 12 people filled out the questionnaire despite the fact that I forgot to bring 30 pens.

The discussion during and after the presentation was focused and very meaningful: microarchitecture and education, EDA infrastructure / build scripts, open-source ASIC design tools, the economics of ASIC design and manufacturing, high-level synthesis, transaction-level modeling, ASIC prototyping using FPGA boards, FPGA embedded in ASIC (Menta), new FPGA manufacturers (Gowin) and new design languages - Chisel and SpinalHDL.

Four persons came to me after the meeting to discuss their participation in working on open-source portable SystemVerilog examples, and another seven expressed this intention in the questionnaire. So we are meeting again in Hacker Dojo on Sunday, January 21, at 2 PM, this time not in the classroom area, but in the common shared area.

Generally, I am thinking of having regular meetings, probably on a weekly basis for a small team of developers of the educational materials and on a monthly basis for a wider audience, discussing various design and verification topics.

There were two correspondents of Slavic Sacramento who recorded the video of the presentation. They are going to make it available soon.

UX testing is one of the most important parts of the UX design creation process for any software product. It helps to understand whether users are satisfied with the design and highlights its problematic areas that need to be fixed or improved. UX testing is an important part of the whole testing process - it helps to get beta-testers feedback to determine whether the product is comfortable for users and gives opportunity to improve problems and issues before moving on to the next stage of the development process. It also contributes to reducing the cost of development, as it is much cheaper to fix issues during the development process rather than after the release. Listed down below are 5 simple tips that can help perform UX testing in a proper and effective way.

In the past 5 years, I moved across 3 countries and 2 continents. It was not a short tourist travel or vacation, but a full immigrant experience with 1+ year experience minimum. I had to adapt to new cultures, new languages, new people, new food, new weather, new everything. One of the pains was to adopt new online services and information sources.

The problems I have faced were not obvious and interesting at the same time. I tried to analyze what was missing and required to make life easier.

Lose Your Sale) How to lose an IT project sale. 

My name is Paul Karol and I work as a director in a Russian IT company that mostly sells their products into the American Market. What we will discuss today was so costly for that company that I want to share this knowledge so that it doesn't happen to other Russian IT companies. 

Case Study

Today I want to tell you about a sale that almost was. I was Consulting for this one company and they were involved in selling software to the United States. This one particular client was in contact with the sales manager for 2 months.

Now this sales manager was very good at their job and they had a lot of charisma on the phone and in the text messages. However they specifically did not know something that cost them a large contract. 

1. In Russia it's respectful not to talk about your personal life because you feel that you're wasting someone's time if you do not know them well. 

2. In the United States once you have been talking with somebody for a couple of months you would start to consider them sort of a friend. 

The Russian IT sales manager had not been in contact with this client for about a week and this was unusual. 

They were worried. 

Then the text message came that said this. 

"I'm sorry Marina that I have not been in contact with you for some time. I took my family and kids to the Lakeside and we enjoyed some time by the beach." 

The Russian IT sales manager did not know how to think about this and they asked this question. 

" So, do you want to buy our product?" 

Launching a startup often means navigating through stringent constraints, particularly in the early stages where resources are limited. For technical founders, who usually possess deep expertise in certain technical domains, the inclination might be to hire a team of senior engineers—considering you often end up with only one expert in each domain, it might be risky to delegate entire segments to junior specialists.

This situation typically leads to a small team where each member is more skilled than the founder in their respective field. This raises an important question for the technical lead: what role should you play in this team? 

While the apparent answer might be task setting and quality control, prompting engineers to do what they love (coding), a less obvious but crucial role emerges. As a leader, your primary responsibility could be to prevent your team from engaging in unnecessary or potentially detrimental tasks, a concept known as "overengineering."

In this article, I will explore the critical role of a technical lead in steering a team away from overengineering and ensuring that their efforts align effectively with the startup's goals and resources.

The team developing a set of portable SystemVerilog examples decided to organize the first event in Silicon Valley on Sunday, January 14 from 2PM till 5PM at Hacker Dojo in Mountain View, CA. If the first event is successful we are going to make it recurrent. You can register for the event on Meetup or LinkedIn.

The current directions of the group:

Title:

After sale IT support for American and Western Companies 

Let’s have a case study. 

A Russian IT company sells software to a western country like say America. And you are working as an application developer on the support side. 

One day, there is a problem with the program, and the program has stopped working. 

You must contact the company now to inform them that the program is off-line. 

THE NEXT STEP YOU TAKE IS VERY IMPORTANT. 

The way, the two cultures operate in a situation like this are very different and it will have everything to do with how easy your job goes for you.

…………

Russia : “we have a problem”

“What is wrong?”

“I don’t know”

“When can it be fixed?”

“I don’t know”

……………

USA: “i’m just giving you a real quick call to let you know that there is a problem with the program. 

I’ve already put my team on it and we will have it up and running shortly. 

I will let you know more by 3 o’clock today what is going on”

It’s not important how long you think it will take you, but I will always tell them a few hours from the time that you informed them of a problem.

I understand that you have no idea how deep the bug is and also whether it will affect any other systems.

But it is important to set a time window very close to when you inform them that you will bring them more information. 

This also works very well if you don’t know something that they ask you.

Question:

“What can we do to fix this problem?”

Answer: 

“I understand what you’re saying. I will look into it and get back to you in two hours.  By 1 PM today.”

in this case, it’s important that you: 

1. Take responsibility for yourself and your team.

   2. Communicate that you understand this responsibility.

   3. Gives strict timelines. (if it’s not possible, you can always say that there is a problem, but do it before the deadline.) 

    4. Use certain key language.

“ I understand you”

“ I understand what you were saying”

“ I wanted to inform you”

“ we are working on it right now”

This is one of the most important articles I’ve written. 

In this article, I’m going to dive deep into one of the largest differences between Russia and America pertaining to sales and marketing. 

1. You must use your name. 

2. You must have a personal approach. 

3. You must show that you are involved. 

4. You must show that you care about the needs and desires of the client. 

Recently, I was faced with an interesting problem. I was asked to call clients without making it personal. 

So let’s go back to when I was in America, living and working as a sales person. The company I work for, was very large, and had multiple branches around the Washington DC area. They had offices in three states. 

They put me through a sales training course. 

The biggest “take away” from the course….. 

You’re not selling the product/ 

you’re selling yourself. 

It's important to use your charisma and your genuine caring for the customer to win them over. Once they understand that you're actually trying to help them, then they will seriously consider the item you are telling them about. 

I also want to say, very clearly, that it's not a prideful approach. It should be a professional approach. You're responsible to tell the customer/ the client all the benefits of the item and how this item will help their business.

Everything above pertains to sales in America. So if you are approaching America as a sales manager this is how you should craft your approach. 

Now I've spoken to my colleague,

Kristina Pashnina and we have agreed upon some stark differences to the Russian sales climate. Here she will begin to tell you how the Russians see sales. 

As NFTs spread across the world, users spent millions of dollars to buy digital assets to prove their uniqueness. Many creators and artists showcase their beautiful products, such as artworks, music, etc., in the NFT marketplace. What if a creator can profit from their work even after selling it to another business? This is where royalty comes in; it is a recent addition to the NFT space. Owing NFT royalties can benefit artists and creators from succeeding sales to the business. 

Once NFT royalties became a hot topic and gained popularity among artists and creators. Later, arguments were evolved to remove royalties that had swayed other NFT creators. DeGods, the popular Solana's NFT project, has moved its royalty model to 0%. However, creating a royalty-based NFT marketplace attracts many creators around the world. In this article, we will delve into the development process of NFT marketplace royalties and how it benefits enthusiastic artists from secondary sales. 

My last article stirred up some definite comments and even questions about different things in business. I’m going to keep giving you as much information as I can so that you can continue to do business as IT professionals outside of Russia with other countries. 

How do you design a website that will be viewed in the west and appreciated by the people there?

What are the most important elements

for, America and other western markets?

Information shared below is exactly how I work with my IT professionals who are going to be participating in pre-sales to America. I tell them exactly this, and it helps prepare them to successfully sell the the United States companies.

As developers and IT companies, we must sell our software.

What can give you an edge in this very competitive market place?

Please, if you would allow me to let me explain why this is important and how this can make your company more successful. There’s a certain type of thinking that is conducive to working as a software developer. This is a very practical mindset, but it goes beyond that. If you have the mindset of direct thinking.

Here are examples:

I see the target a target and I don’t see obstacles

Вижу цель, не вижу препятствий

This is an example of the practical mindset, how is approaches the problem of development. It makes people who have this mindset, the best developers in the world.

Example of mindset:

Problem……………… find a solution………… No problem.

Notice how this looks exactly like a line of code?

This is well-known around the world in places where you would like to sell your software, the United States, Germany, Belgium, and the Middle East.

Countries where people have this mindset have the best developers.

now let’s talk about your competition:

Americans: during the center process, “find a solution” Americans are overly concerned about responsibility. This slows them down in the decision making process.