"Что делать, если смежная команда нарушает договоренности?"
Как-то с одним лидом обсуждали этот вопрос.
Ситуация: Две команды работают над задачей. Одна делает сервис-продюсер. Другая делает сервис-консьюмер. Они согласовывают интеграционный контракт и на этапе тестирования QA радостно понимают, что консьюмер не умеет передавать часть обязательных параметров. Если это происходит в условиях горячих дедлайнов, то грустно всем очень.
Позиция лида - быстро подправить чтобы заработало и пойти дальше. На мой взгляд, это только снятие симптома. По моему опыту, если однажды сорвалась договоренность, это с вероятностью 99,9% повторится. Надо лечить саму проблему.
Самое важное - понять реальные причины. Их всегда несколько: одна - поверхностная, из-за которой поменяли контракт, вторая - глубинная, чего нам не хватает в диалоге, чтобы своевременно обсуждать изменения.
Первая выясняется довольно легко в любом формате: на проектном ретро, статусной встрече, 121. Пример причины: при разработке выяснились ограничения легаси или сделали оптимизацию. А вот почему сказать забыли надо обсуждать на 121. Вопрос тонкий, требует доверительной безопасной среды.
Алгоритм простой:
- Мое видение ситуации
- Видение ситуации собеседником
- Что мы можем сделать, чтобы так не повторялось в будущем
- Cанкции в случае нарушений
Например:
- Слушай, я точно помню, что мы с тобой все проговорили и записали в confluence. Изменения не появлялись, я не триггерилась.
- Да, блин, у меня параллельно было 3 проекта и пока писал тебе сообщение, отвлекли, потом вылетело из головы.
Давай попробуем включать в реестр рисков перегруз. Плюс раз в 3 дня статус по задаче в чат. Если новостей нет - пишем, что их нет. Кто пропустил - 2 недели фиксирует минутки встреч.
"What do you do if an adjacent team breaks agreements?"
Once I discussed this question with a lead.
Case: Two teams are working on a task. One team is developing the service producer, the other team is developing the service consumer. They agree on an integration contract. During testing, a QA realizes that the consumer cannot pass certain mandatory parameters. If this happens under tight deadlines, it becomes very frustrating for everyone involved.
The lead's position is to quickly fix it to make it work and take the following task. As for my opinion, this is just treating the symptom. Based on my experience, if an agreement is broken once, there is a 99.9% chance it will happen again. The root problem needs to be addressed.
The most important thing is to understand the real reasons behind it. There are always multiple reasons: one may be superficial, which leads to contract changes, and the other may be fundamental, indicating the lack of dialogue to discuss changes timely.
The superficial reason can be easily discussed in any format, such as a project retrospective, status meeting, or 121 discussion. Example reason: during development, legacy limitations were discovered or optimizations were made. However, why it was not communicated needs to be discussed in a safe and trusting environment.
The algorithm is simple:
- My view of the situation.
- The other person's view of the situation.
- A solution to prevent this from happening again
- Sanctions for failures
For example:
- I remember that we discussed and documented everything in Confluence. There haven't been any changes, so I wasn't triggered.
- I was juggling three projects at the same time, and while I was writing you that message, I got distracted, and then I completely forgot about it.
Let's try including overload risks in the risk register. Additionally, we can provide an update on the task in the chat every three days. If there are no updates, we will mention that there are none. Whoever misses it will have to record meeting minutes for two weeks.
#imho #negotiation
