[Управление продуктом] Why it's important to allow developers to solve the problem instead of giving them implementation tasks
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
In his book «INSPIRED: How to Create Tech Products Customers Love,» Marty Cagan mentioned that successful teams put the following principles at the forefront when working with feature stories:
- Risks are analyzed in advance, not at the end.
- Products are defined and designed collaboratively, not sequentially.
- The team works on solving the problem, not on implementation.
The first two are more or less clear. Any well-educated manager knows that risks should be identified and assessed in the upfront. Besides that, many modern teams work or try to behave themselves on Agile's principles. But there are not so many companies in the world that follow the third principle.
Let us see what we can do.
Usually, when a task (story, issue, or whatever you call it there) comes to the designers, and even more to the developers, no one bothers to explain to them what kind of problem we are trying to solve and why they need to implement this feature.
Accordingly, the developers turn from equal team members to workers on the conveyor belt doing very dull job. Of course, this approach works in many companies, but how many resources are going wasted…
To solve this problem, I use the so-called «Why/Problem» section. This section is a single paragraph that describes the situation, the client's pain or trouble, and how it is supposed to be solved. So far, without a technical description, only in general words.
For example, we have a significant bounce rate because of many clients who do not want to spend time to start another account. So we need to implement the guest order feature.
Remember, if you can't describe the problem in two or three sentences, you either don't understand it or a huge problem that needs to be solved iteratively by eating the elephant in parts. As Alber Einstein told: «If you can't explain it simply, you don't understand it well enough». But this is a topic for another post.
When it comes to grooming, the first thing we discuss is why we are here and decide what and how we will solve the problem. As soon as the developers understand why we want to implement this or that feature, we will get employees who are implementing wishes and colleagues who help us achieve goals and advise us on how to do better. And how much better the technical implementation will be!
In the example we have discussed above, it may turn out that it is challenging to make a «guest-order» due to historical reasons. And the developers will offer you to implement authorization via Google and Facebook, which will be faster, but will help solve the pain of a client with another account on a millionth site. Two birds with one stone: both the problem was solved, and money saved.
Another important reason to tell us what prompted us to create this or that task is the fact that developers do not like to make changes. And they will reject it in every possible way because they know: «Don't touch what works.» And believe me, they have a good reason (tech debt, if it isn't newborn). The moment you tell the team why we need it, they will either suggest a better way or be brave enough to make a change because there is no other way.
Also, when we explain the developers the reasons we care about a particular feature, we improve the team's mood and allow programmers to feel like they are the first-class citizens in the process of solving real problems, rather than employees doing the same stuff daily.
Last but not least, «The more you explain a topic, the better you understand it.»
Do you tell the developers the problem or work with them by giving specific instructions on what to do?
Image source: www.business2community.com/marketing/why-you-need-to-start-with-why-as-you-develop-your-marketing-plan-02261139
===========
Источник:
habr.com
===========
Похожие новости:
- [Usability, Интерфейсы, Управление продуктом] 20 психологических уловок в дизайне продуктов (перевод)
- [Управление сообществом, Интернет-маркетинг, Медийная реклама, Управление продуктом, Брендинг] Заказать отзывы и не пожалеть об этом
- [Развитие стартапа, Управление продуктом, Управление продажами, Дизайн] 10 лет Designmodo: взлеты, падения, уроки и вдохновение
- [Информационная безопасность, Совершенный код, Управление продуктом] Уязвимости в коде. Как отличить опасную брешь от незначительной ошибки?
- [Дизайн мобильных приложений, Аналитика мобильных приложений, Управление продуктом, Дизайн] Какие бывают метрики. Дизайнер и метрики, 2 часть
- [Интернет-маркетинг, Развитие стартапа, Управление продуктом, Облачные сервисы, Дизайн] [Подборка] 6 no-code инструментов для быстрого запуска продуктов и автоматизации процессов
- [Управление разработкой, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Создание программного продукта и управление его развитием. Позиционирование продукта
- [Управление разработкой, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Создание программного продукта и управление его развитием. От реализации идей — к проверке гипотез
- [Анализ и проектирование систем, CAD/CAM, Визуализация данных, Управление продуктом] CATIA: из истории одного проекта
- [Дизайн мобильных приложений, Agile, Управление продуктом, Интернет вещей, Будущее здесь] Как мы хакнули умные подушки и запустили приложение для умной спальни «Асконы»
Теги для поиска: #_upravlenie_produktom (Управление продуктом), #_product_management, #_product_development, #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:17
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 In his book «INSPIRED: How to Create Tech Products Customers Love,» Marty Cagan mentioned that successful teams put the following principles at the forefront when working with feature stories:
The first two are more or less clear. Any well-educated manager knows that risks should be identified and assessed in the upfront. Besides that, many modern teams work or try to behave themselves on Agile's principles. But there are not so many companies in the world that follow the third principle. Let us see what we can do. Usually, when a task (story, issue, or whatever you call it there) comes to the designers, and even more to the developers, no one bothers to explain to them what kind of problem we are trying to solve and why they need to implement this feature. Accordingly, the developers turn from equal team members to workers on the conveyor belt doing very dull job. Of course, this approach works in many companies, but how many resources are going wasted… To solve this problem, I use the so-called «Why/Problem» section. This section is a single paragraph that describes the situation, the client's pain or trouble, and how it is supposed to be solved. So far, without a technical description, only in general words. For example, we have a significant bounce rate because of many clients who do not want to spend time to start another account. So we need to implement the guest order feature.
Remember, if you can't describe the problem in two or three sentences, you either don't understand it or a huge problem that needs to be solved iteratively by eating the elephant in parts. As Alber Einstein told: «If you can't explain it simply, you don't understand it well enough». But this is a topic for another post. When it comes to grooming, the first thing we discuss is why we are here and decide what and how we will solve the problem. As soon as the developers understand why we want to implement this or that feature, we will get employees who are implementing wishes and colleagues who help us achieve goals and advise us on how to do better. And how much better the technical implementation will be! In the example we have discussed above, it may turn out that it is challenging to make a «guest-order» due to historical reasons. And the developers will offer you to implement authorization via Google and Facebook, which will be faster, but will help solve the pain of a client with another account on a millionth site. Two birds with one stone: both the problem was solved, and money saved.
Another important reason to tell us what prompted us to create this or that task is the fact that developers do not like to make changes. And they will reject it in every possible way because they know: «Don't touch what works.» And believe me, they have a good reason (tech debt, if it isn't newborn). The moment you tell the team why we need it, they will either suggest a better way or be brave enough to make a change because there is no other way. Also, when we explain the developers the reasons we care about a particular feature, we improve the team's mood and allow programmers to feel like they are the first-class citizens in the process of solving real problems, rather than employees doing the same stuff daily. Last but not least, «The more you explain a topic, the better you understand it.» Do you tell the developers the problem or work with them by giving specific instructions on what to do? Image source: www.business2community.com/marketing/why-you-need-to-start-with-why-as-you-develop-your-marketing-plan-02261139 =========== Источник: habr.com =========== Похожие новости:
Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:17
Часовой пояс: UTC + 5