​​Для того, щоб людина, яка не занурена у проєкт, наприклад, менеджер Product Owner, змогла прочитати цей статус та все зрозуміти для себе. 👉🏻 У цій комунікації також потрібно вказати ризики в actionable формі. Наприклад, з чого складається ризик; що буде, якщо цей ризик реалізується, хто контролює його; точка прийняття рішення (коли будуть зроблені дії, або по яким критеріям ми зможемо його вважати закритим, і хто за це відповідає). Про персональне відношення, small talks, емоційний інтелект можна також багато сказати, але то має бути тема окремого випуску 😉 4️⃣ Швидкість та реакція на проблеми На проєкті раптово може виникнути щось таке, що може призвести до порушення наших обов’язків або принести ризики для споживачів систем, що ми розробляємо. У таких випадках ми намагаємось якнайшвидше вирішити проблему. ❗️ Не очікуємо, коли клієнт попросить розв’язати це питання. Усуваємо миттєво проблему та потім проводимо аналіз, чому це сталося. Це допоможе наступного разу запобігти повторенню. Згідно до ISO, в таких випадках необхідним є створення формальних документів Corrective and Preventive Actions (CAPA) 📝 Але навіть якщо проблема не вийшла на формальний рівень, ми все одно йдемо до замовника та говоримо про ситуацію та шляхи попередження схожих ситуацій у майбутньому, і вносимо їх у план дій. Замовники не носять рожеві окуляри та розуміють, що на проєкті можуть виникати проблеми. Але це круто, коли вони 100% впевнені, що їх з цим не залишать, допоможуть і зроблять усе, щоб запобігти новим таким випадкам 🚀⚡️ Це один із ключів до довгострокових відносин з клієнтом. 5️⃣ Sense of ownership Якщо замовник відчуває, що команда ставитися до його продукту, як до свого власного — то це найбільша мотивація продовжувати відносини 🙌🏻 Показати таке відношення можна тим, що команда пропонує ідеї щодо нового функціоналу, як реалізувати вимоги найбільш оптимальним шляхом. Фішка також у тому, що на таких проєктах й команда найчастіше досить стабільна, тому що такий внесок у кінцевий результат та успіх продукту дуже мотивує😊