Створення моделі співпраці

Визначена та структурована модель співпраці є надзвичайно важливою для ефективної роботи зведеної робочої групи. У цьому розділі ви дізнаєтеся про фактори, які можуть цьому сприяти, як-от визначені ролі та обов’язки, структурований бізнес-ритм, надійні канали комунікації й портал документації зі спеціальними можливостями.

Визначення ролей і обов’язків

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

Ваша робоча група повинна складатися принаймні із зазначеного нижче персоналу, який виконує певні ролі.

• Відповідальний за продукт – зазвичай це особа, яка відповідає за забезпечення успіху проектів. Ця особа також визначає чітку й конкретну мету або може спільно розробляти цю стратегію з робочою групою.
• Фахівець із доменів – це учасник робочої групи, який знається на бізнесі й розуміє та може сформулювати як задачу, так рішення. Завдяки простоті підходу, який передбачає Power Apps із низьким кодом, цей фахівець може максимально ефективно створити це рішення.
• Професійний розробник – це розробник, який отримує рішення від фахівця з доменів і застосовує до нього кодування, щоб надати йому за потреби необхідні функціональні можливості (і нічого більше).
• Адміністратор – цей учасник робочої групи полегшує інтеграцію та підтримку сценарію, а також займається внутрішніми адміністративними справами. Будь-яка додаткова підтримка щодо часу та досвіду, яка потрібна основній робочій групі, може надаватися на гнучкій основі, а не шляхом залучення постійного учасника робочої групи. Такий підхід забезпечує ефективну роботу зведеної робочої групи, а також надає доступ до додаткових ресурсів, які потрібні відповідальному за продукт для того, щоб робоча група могла досягти поставлених цілей.

Створення ритму бізнес-моделі

Синхронізація робочих процесів, пов’язаних із розробкою програм у зведеній робочій групі, може підвищити ефективність команди, органічно вбудовуючись до наведеної нижче структури.

• Визначте повторювану подію в календарі для синхронізації робочої групи. Для більшості робочих груп достатньо проводити наради раз на один або два тижні для інформування про стан справ. Проте не плануйте наради, лише для того, щоб їх провести, і намагайтеся уникати збільшення частоти нарад наприкінці термінів завершення проектів, оскільки такий підхід може бути неефективний.
• Дотримуйтеся узгодженого робочого часу. В ідеалі робоча група має знаходитися в одному місці, хоча зведені робочі групи також можуть ефективно працювати в різних країнах і часових поясах. Незалежно від режиму роботи, переконайтеся, що всі розуміють призначення та тривалість робочого часу, а також дотримуються цих меж.
• Створіть тижневий ритм. Тижневий ритм команди має охоплювати самостійну роботу, спільну взаємодію та, за потреби, ефективні наради. Ці наради повинні мати певну мету, наприклад:
  • Огляди областей – щоб об’єднати робочі групи щодо нових ініціатив.
  • Аналіз взаємодії з користувачами – щоб переглянути архітектуру й макети програм. Наради для планування інших нарад, наради замість електронних листів чи миттєвих повідомлень або наради без чітко визначених цілей – це вороги продуктивності.
• Працюйте ефективно. Робоча група повинна працювати узгоджено, щоб створювати найпрактичніші рішення. Узгодженість передбачає можливість повторного використання компонентів, створених іншими користувачами.
• Дотримуйтеся послідовного прогресу на шляху до досягнення мети. Для того, щоб робоча група могла досягти поставлених цілей й отримувати результат, важливо, щоб усі працювали спільно. Для зведених робочих груп, які працюють із Power Apps, дотримання цього прогресу передбачає записування та розуміння відгуків користувачів, визначення пріоритетів відстежування, а також створення та підтримка цілісної дорожньої картки всього проекту.
• Створіть матрицю підтримки. Матриця підтримки забезпечує структурований спосіб отримання необхідної підтримки для досягнення загальних цілей робочої групи. Під час розробки програм бізнес-технологи неминуче стикаються з тим, що в певний момент вони досягають ліміту своїх знань і здібностей. До кого вони мають звернутися на цьому етапі й як це зробити? Що слід робити зі звітом про помилки користувачів? У цій матриці повинно бути зазначено, як вони мають надіслати запит на підтримку, щоб залучити потрібну робочу групу до виправлення неполадок і вирішення проблеми, залежно від її рівня серйозності. Для кожного сценарію підтримки ця матриця пояснює шлях передачі заявки до відповідних служб та виправлення неполадок.

Визначення способу комунікації всередині робочої групи

Стандартизація комунікації всередині робочої групи є ще одним важливим компонентом для підтримки ефективної роботи. Усі учасники робочої групи мають знати способи зв’язку всередині робочої групи, особливо в асинхронних режимах у різних часових поясах. Ваша стратегія комунікації має враховувати наведені нижче області.

• Канали. Які канали повинна використовувати робоча група для основної та вторинної комунікації? У чому переваги та недоліки кожного з них? Зараз, коли існує безліч можливостей на вибір, просте використання електронної пошти може бути не найкращим рішенням, і варіанти, як-от Microsoft Teams, можуть забезпечити покращену точність і можливість відстеження, а також підвищений рівень відгуку.
• Типи сповіщень. Як повідомити робочу групу про оновлення або події, про які їм потрібно знати, щоб діяти?
• Частота та обсяг повідомлень. Як часто інформувати робочу групу? За допомогою щоденної комунікації можна надавати корисний короткий підсумок того, що відбулося за день, але для деяких повідомлень може бути необхідна швидка реакція. Більшість інформаційних працівників перевантажено такими електронними листами. Забезпечте рівновагу між частотою та обсягом, щоб учасників робочої групи не було завалено повідомленнями стосовно проекту.
• Автоматизація. Як автоматизувати процес комунікації? Стандартизовані шаблони електронних листів, боти та оповіщення про події можуть бути корисними, але їх потрібно використовувати відповідально, щоб не позбавити учасників робочої групи можливості відповідати на них через перевантаження.
• Гарні комунікативні навички. Не кожен учасник робочої групи має однаковий рівень комунікативних навичок, але кожен може вдосконалюватися. Прості способи, як-от вибір правильної теми для електронного листа, значно сприяють належній реакції робочої групи на це повідомлення. Використовуйте простий і ефективний стиль у всіх повідомленнях. Якщо йдеться про дії, які повинні виконати учасники робочої групи, висловлюйтеся конкретно й зазначте ці дії в рядку теми.

Прикладом застосування ефективних комунікативних навичок може бути ситуація, коли потрібно змінити визначення таблиці в Dataverse, наприклад додати кількох полів. Коли ви надсилаєте повідомлення про заплановані зміни, робоча група має розуміти, що в разі, якщо вони не нададуть відповідь протягом обґрунтованого часу, то ця відсутність відповіді означатиме їхню згоду. Стандартизовані та логічні процеси комунікації допомагають підвищити ефективність і отримати очікувані результати.

Публікація порталу документації

Документація – це не просто додаткова складова будь-якого проекту, вона необхідна для комунікації, співпраці, підтримки та поточної діяльності. Код із примітками – це гарний код, а створення навчальної документації з докладними поясненнями є невід’ємною частиною етапів розгортання й навчання будь-якого зведеного проекту.

• Каталог програм. Каталог програм – це матриця або таблиця, яка підсумовує та узгоджує всі програми в межах відповідальності певної робочої групи. Каталог містить усіх відповідних відповідальних осіб із розділу «Ролі та обов’язки». Ключова функція полягає в тому, що робоча група повинна точно знати, хто за що відповідає, що спрощує процес звернення до потрібного учасника робочої групи для отримання конкретних відповідей.
• Технічні питання. Ваша робоча група має підтримувати репозиторій поширених (або навіть не надто поширених) технічних запитань щодо роботи програми. Ці питання мають бути обґрунтованими, а відповіді добре написаними та зрозумілими.
• Практичні поради. Практичні поради – це чіткі й зрозумілі набори процедур, які надають прості відповіді на поширені запитання щодо налаштування та роботи. Зазвичай вони дають відповідь на певне запитання, наприклад «З чого почати створення нової програми?»
• Ознайомлення. Ознайомлювальні інструкції – це виключно внутрішні документи, призначені для допомоги новим учасникам робочої групи. Ця документація містить відомості, як-от запити на доступ, приєднання до списків розсилки електронної пошти, налаштування оповіщень та підписка на них тощо.

Рекомендації

Наведені нижче рекомендації допомагають у визначенні меж ефективної роботи й підходів до неї у зведених робочих групах.

Звітність

Хоча зведені робочі групи під керівництвом розробників забезпечують швидку розробку та розгортання програм, украй важливо, щоб ця робота була відкрита й проводилася в співпраці з IT-відділом. Розробники мають звітувати ІТ відділу, щоб запобігти виникненню проблем, пов’язаних із збільшенням тіньових IT-систем.

Отже ІТ-відділ має отримувати оповіщення, щойно розробник починає створювати програму. Таке сповіщення полегшує процес розробки, оскільки ІТ-відділ може надавати належну підтримку розробнику та зведеній робочій групі, допомагаючи їм створювати програми з чудовою архітектурою, надійно захищені й керовані.

Автоматизація

Належно впроваджена автоматизація може значно підвищити продуктивність. Прикладом успішного розгортання рішення є автоматизація всіх необхідних перевірок під час розгортання кількох рішень. Нижче наведено перелік автоматичних перевірок.

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

Рішення «Засіб перевірки PR» демонструє приклад ефективного впровадження цієї автоматизації.

Надсилання скарги

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

• Відстежувати та оцінювати роботу програм. Лише через те, що одна особа вважає щось корисним або гарною ідеєю, не означає, що всі інші теж це оцінять. Робочі групи мають відстежувати зручність використання програм і оцінювати їхні функціональні можливості для того, щоб усі нові розробки були корисними й функціонували належним чином.
• Заохочувати розумне судження. Іншими словами, не створюйте програми тільки тому, що ви це можете, – створюйте їх лише для вирішення певної бізнес-потреби.

Наступний крок. Створення системи керування для спільної розробки