Англійська мова для менеджерів технічних програм: Крос-комунікація команди і мова ризику

Менеджери технічних програм (TPM) сидять на перетині багатьох інженерних команд, бізнес-зацікавлених сторін і зовнішніх залежностей. Їх головним завданням у комунікації є передання складної, взаємозалежної технічної роботи на ясній мові - і робити це як вгору до керівництва, так і горизонтально до колег. У цьому довіднику наведено словник, мову оновлення стану і фрази ескалації, які використовуються ефективними модулями TPM.

Основний словник ТПМ

** Залежність ** — частина роботи, яку одна команда або компонент залежить від іншої команди або компонента, щоб завершити перед продовженням. « Команда з платежу має жорстку залежність від нового формату токена автентифікації команди з ідентифікації; доки цей формат не буде надіслано, платежі не можна продовжувати з їх інтеграцією. »

** Блокування залежності ** — залежність, яка повністю зупиняє роботу доки її не буде вирішено. « У нас є блокуюча залежність від API стороннього постачальника даних — без оновлення його договору ми не зможемо розпочати роботу з інтеграції. »

Жирна залежність проти м’ якої залежності — жорстка залежність — це така, де робота буквально не може продовжуватися; м’ яка залежність — це така, де робота може продовжуватися, але потребує переробки, якщо залежність зміниться. « Контракт API — це жорстка залежність; специфікації проекту — м’ яка залежність — ми можемо розпочати розробку до того, як вони будуть завершені, але може знадобитися ітерація. »

Ризик — невідома подія або стан, який, якщо він відбудеться, має позитивний або негативний вплив на програму. Завжди виражається за допомогою ймовірності і впливу. « Існує ризик середньої ймовірності, що зовнішній постачальник не надає оновлення SDK до встановленої дати; впливом буде двотижнева затримка до дати, визначеної для інтеграції »

** Реєстр ризиків ** — документ, у якому наведено список визначених ризиків, їх ймовірність, вплив, власника і дії з їх зменшення. « Реєстр ризиків для цієї програми містить 12 відкритих пунктів; три з них мають високий пріоритет і потребують планів зменшення цього тижня. »

** Зменшення ризику ** — дія, яка виконується для зменшення ймовірності або впливу ризику. « Нашим заходом зменшення ризику затримки виробника є початок паралельної оцінки альтернативного SDK, щоб у нас був резерв, якщо вони пропустять дату »

** Непередбачувані події ** — план або ресурс, який зберігається у резерві для вирішення ризику, якщо він дійсно трапиться. « У нас є двотижневий буфер непередбачуваних подій, вбудований у план, для точного опису такого типу затримки. »

** Дія ** — важлива точка на часовій шкалі програми, зазвичай, це позначення завершення фази або результату. « Першою дією є підписання контракту API, заплановане на кінець цього спринту. »

** Критичний шлях ** — послідовність залежних завдань, яка визначає мінімальну загальну тривалість програми. Будь- яке затримання виконання завдання на критичному шляху призведе до затримки всієї програми. « Міграція бази даних знаходиться на критичному шляху; якщо затримка буде більше трьох днів, буде змінено дату завершення всієї програми »

** Слабкість / плаваюча ** — кількість часу, протягом якого завдання може бути відкладено без впливу на критичний шлях або дату завершення програми. « У збірці інтерфейсу є два тижні слабкості; вона не знаходиться на критичному шляху, отже, коротке затримання не стосується мене. »

** RACI ** — матриця призначення відповідальності. Відповідає за (робить роботу), відповідальний (власник результату), проконсультований (надає вхідні дані) і інформований (дотримується останніх дій). « Перед початком роботи, давайте вирівняємо RACI для перегляду відповідності — я хочу, щоб було ясно, хто відповідальний, а хто лише проконсультований. »

Мова оновлення стану програми

Оновлення стану повинні бути ясними, точними і орієнтованими на дії. Уникайте нечітких слів, таких як “добре розвивається” без доказів.

** Загальний стан програми: **

• ** Зелений ** — у процесі: « Поточний зелений колір програми; всі важливі події відбуваються у плановому порядку і немає відкритих блокувань »
• ** Amber ** — під загрозою: « Програма має жовтий статус цього тижня через затримку API виробника; у нас є план зменшення ризику, але ми ще не можемо підтвердити, що загальна дата завершення є безпечною »
• ** Червоний ** — значний ризик або затримка: « Програма червона. Задача критичного шляху прослизнула на два тижні; дата завершення більше неможлива без або descoping або додаткових ресурсів. ”

** Звіт про хід: **

• «На цей тиждень: три з п’яти етапів завершені; четвертий перебуває в процесі і на шляху до п’ятниці; п’ятий залежить від зовнішнього контракту API, який залишається відкритим»
• «Інтеграція платежів на два дні відстає від прогнозу через несподіване невідповідність схеми, виявлене під час тестування; команда працює над тим, щоб розв’язати це і очікує повернутися на шлях до четвертого»

** Позначення блокування: **

• «Мені потрібно підняти блокатор: команда ідентичності ще не надала оновлений формат токена, і команда платежів не може продовжувати без нього. Мені потрібно вирівняти пріоритети від обох команд до кінця дня»

Ескаляційна мова

Ескалація є нормальною частиною управління програмою, а не ознакою невдачі. Використовуйте ясну, фактичну мову, яка фокусується на необхідних рішеннях.

Подняти риск:

• «Я підвищую цей ризик, тому що він перейшов від середньої до високої ймовірності, а варіанти зменшення, доступні мені на рівні програми, недостатні. Мені потрібно рішення старшого зацікавленого боку про те, чи відкрити функцію X або прийняти розширену хронологію»

** Ескаляція залежності: **

• «Залежність від API команди B була видатною протягом трьох тижнів; на програмному рівні я мав дві розмови без розв’язання. Я ескалаціюю до [ім’я], щоб запитати про рішення щодо пріоритету»

** Ескаляція конфлікту ресурсів: **

• «Дві програми конкурують за тих же двох інженерів протягом одного двотижневого вікна; Я не можу розв’язати цей конфлікт на програмному рівні. Мені потрібно рішення про пріоритети від керівництва»

Выстраивание эскалации:

• «Я не прошу вас вирішити це за мене — я прошу рішення по [конкретному запитанні]. Можливі варіанти: A, B або C; я рекомендую B, але мені потрібно ваше схвалення, щоб продовжити»

Приклади речень стану програми

1. «Програма на цьому тижні бурштинова: робота над інфраструктурою критичного шляху йде в правильному напрямку, але інтеграція постачальника має високий ризик, що може змусити загальну дату завершення на один-два тижні, якщо вона матеріалізується»

2. «Ми маємо сильну залежність від команди безпеки, яка завершує свій тест проникнення, перш ніж ми можемо відкрити бета-версію — ця залежність знаходиться на критичному шляху і в даний час запланована на тиждень 12-го»

3. «Реєстр ризиків має один новий елемент високого пріоритету, доданий цього тижня: сторонній провайдер автентифікації оголосив про зміну API; ми повідомили про це команду ідентичності і чекаємо їх оцінки»

4. «Я хочу пояснити RACI для підписання відповідності: інженерія відповідає за підготовку пакету доказів, юридична відповідальність за остаточне схвалення, а CISO консультується, але не приймає рішення»

5. «Я ескалаціюю конфлікт ресурсів між Програмою Альфа і Програмою Бета, тому що обидві мають тих самих двох інженерів на критичному шляху під час одного спринту; мені потрібно рішення про пріоритетність від інженерного директора до кінця тижня»

Національна мова: мова, що використовується для спілкування між ненаціональними групами

Основні принципи міжкомандного спілкування - ясність, стислість і контекст - залишаються найважливішими незалежно від вашої рідної мови. Однак, тонкощі в англійській фразування часто можуть спонукати розробників перейти до більш формального професійного середовища. Це не просто про використання правильних слів; це про розуміння * як * ці слова зазвичай використовуються, особливо коли справа доходить до технічних дискусій і управління ризиками. Здається простим речення може нести значно різну вагу в залежності від тону і доставки. Наприклад, заява «Це пошкоджено» старшому інженеру під час перегляду коду може бути сприйнята як обвинувачення, тоді як «Я виявив проблему, що заважає функціональності працювати так, як очікувалося» негайно оформляє її як можливість спільного вирішення проблеми. Аналогічно, опис ризику як «високий» вимагає кваліфікації - «Висока ймовірність і значний вплив, якщо не вирішено», є набагато більш дієвим, ніж просто сказати «високий»

Одна особливо поширена область плутанини виникає з використання умовної мови. Багато мов сильно покладаються на прямі висловлювання, в той час як англійська часто використовує такі фрази, як «потрібен», «може» або «може», щоб виразити можливості, а не певності. У реєстрі ризиків, послідовне використання «виникнуть», де «можуть виникнути» є більш точним, створює непотрібне тривога і може призвести до надмірного інженерного вирішення стратегій зменшення ризику. Інша часта проблема виникає при обговоренні залежностей - властива складність відображення відносин між завданнями часто призводить до нечітких описів. Замість того, щоб сказати « Це залежить від бази даних », що не є достатньо точним, краще було б сказати « Це завдання вимагає успішного завершення перенесення схеми бази даних, як це описано у квитку # 1234. » Такий рівень деталізації негайно роз’ яснює очікування і уникнення потенційних непорозумінь.

Нарешті, пам’ ятайте, що активний голос зазвичай є перевагою в технічній документації і комунікації. Пасивні конструкції, такі як «Вага була виправлена», можуть затемнити відповідальність і зробити неясним, хто вчинив. Активне формулювання — «Я виправив помилку» або «Команда вирішила проблему» — сприяє підзвітності і прозорості. Навіть здавалося б невеликі зміни у структурі речення можуть суттєво змінити сприйняття авторитету і професійності вашого повідомлення. Виховання звички перегляду вашого тексту з точки зору людини, для якої англійська мова є рідною, або пошуку відгуків від колег, які знайомі з технічним жаргоном, є безцінним для вдосконалення ваших навичок спілкування і зростання довіри у вашій команді.