Пропустити навігацію EPAM

Віртуальні учасники команди: взаємодія зі штучним інтелектом на проєкті

Данїіл Безлюднов

Software Engineering Team Leader
Лайфхаки
  • Artificial Intelligence
  • Project Management

Ця стаття про роздуми Даніїла Безлюднова, Software Engineering Team Leader в EPAM та автора книги «Beyond Junior: 50 tips for software engineers» про те, як буде відбуватися взаємодія між учасниками команди якщо (або коли) до проєкту долучиться штучний програмний інженер. 

Що робити, якщо ви єдиний реальний учасник у команді із семи розробників?

Зі зростанням популярності штучного інтелекту (ШІ), впровадженням загального штучного інтелекту (ЗШІ) та вдосконаленням великої мовної моделі (ВММ), ми спостерігаємо, що багато компаній намагаються впровадити концепцію штучного (або віртуального) розробника. У цій статті Даніїл виклав деякі думки щодо зміни динаміки команди в разі приєднання штучного програмного інженера (ШПІ).

Безперервне навчання (Continuous learning)

Ця сфера однозначно поліпшиться, оскільки ШПІ є всезнаючим розробником. Він зможе надати вам будь-яку інформацію за кілька секунд. Однак, оскільки швидкість розробки в ШПІ набагато швидше, ніж у людей — ви не отримаєте користі спостерігаючи за тим, як працює ШПІ.

Психологічна безпека

ШПІ не обманює, не переслідує, не карає та не тисне. Він не має упереджень щодо статі, віку чи віросповідання. Це є гарною основою для професійних відносин.

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

Відсутність довіри може створити велику проблему для загальної динаміки команди, оскільки ШПІ ніколи не стане справжньою частиною команди до того часу, поки ви не зможете йому довіряти.

Але тут я маю риторичне питання — а чи можна повністю довіряти іншій людині?

Задоволення

Тут мова про довгострокову перспективу — задоволення від розробки програмних продуктів залишатиметься незмінним. Це питання адаптації людей до нового способу роботи.

Організація команди

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

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

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

Відносини в команді

Очевидно, що наразі неможливо мати нормальні людські відносини зі ВММ. Функція емоцій у ШІ наразі відсутня, і це точно не перша річ, яка буде впроваджена в майбутньому.

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

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

Ще одна проблема полягає в довгостроковій пам’яті. Більшість ШПІ в наш час показують гарні результати лише для десяти запитів у чаті. Лише деякі здатні зберігати до сотні запитів. Складнощі виникають у той момент, коли вам потрібно співвіднести свій запит № 3734 із запитом № 182, який ви відправляли рік тому. Проблема також полягає в дешевому, простому та швидкому механізмі самонавчання, який не потребує всієї води з річки Дніпро та особистого реактора АЕС для здобуття нових знань. Але зверніть увагу, що вам доведеться самостійно запам’ятати ту інформацію, для якої ви робили запит рік або два тому, бо сподіватися на ШПІ в цьому випадку не можна.

Доступність

У ШПІ немає проблем із часовим поясом. Немає також проблем із балансом між роботою та особистим життям. А ще немає електронних листів, відправлених у неробочий час. Та й захворіти, піти у відпустку або взяти вихідний він не може. Він не витрачає час на дорогу на роботу, не спить та не втомлюється.

Чого не скажеш про реальних людей.

Збір вимог

З одного боку ШПІ досить легко це зробити. Достатньо лише слухати, читати транскрипти, ставити питання, документувати вимоги та складати діаграми.

Але з іншого боку постають дві проблеми: політичні моменти та конфлікт інтересів. Ці теми не з тих, які люди хочуть передавати на розсуд ШПІ. Наразі із цим може впоратися лише реальна людина. Але це в будь-якому разі значно спрощує ці процеси.

Експертна оцінка

На мою думку, ця сфера є найпроблемнішою серед усіх.

Створення коду з окремих випадкових думок та ідей — дуже складна робота. Уже досить давно зрозуміло, що люди не хочуть використовувати програмне забезпечення, яке не пройшло етап оцінювання реальним фахівцем (наприклад, програмне забезпечення для літаків, безпілотних автомобілів, банків тощо). Це, знову ж таки, проблема довіри.

Це означає, що справжній розробник має відкрити додаток, який він раніше не бачив та зануритися в тисячі (якщо не мільйони) рядків коду. Уявляєте, наскільки це важко?

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

Виправлення помилок

Відомо, що ШПІ може виправляти помилки лише за їхнім описом. Чи може він виправляти їх правильно? Дуже ймовірно, що так. Чи може він також виправити всі пов’язані помилки? Можливо, що теж так (як і справжня людина). А чи не призведе це до появи десяти нових помилок? Можливо, що ні (як і у справжньої людини).

CI/CD (Continuous Integration/Continuous Deployment)

У наш час цей процес уже майже або повністю автоматизований. Якщо коротко, то ви можете відправити запит «розгорни останню версію в готовому продукті» й він сам зрозуміє, що потрібно зробити.

Робочі зустрічі

Потреби в зустрічах не буде, тому можна буде обмежитися листуванням. Іноді це може бути навіть не самостійно написані запити, а автоматично оброблені протоколи зустрічі. Круто! З цього погляду, для людини буде трохи складніше залишатися в курсі, ніж для ШПІ. Однак, це точно зменшить потребу в зустрічах, але збільшить час, який ви будете витрачати на написання листів.

Розглянемо ще конкретні типи зустрічей.

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

Щоденні зустрічі (Daily meetings) — їх не потрібно синхронізувати зі ШПІ, проте, можливо, знадобиться надавати ШПІ інформації з реального світу, яку він не здобув автоматично. З огляду на поточну ситуацію з віддаленою роботою та розподіленими командами, такої інформації може й не бути зовсім. Тож у разі необхідності, ви зможете отримати звіт для ШПІ про стан того, що відбувалося вчора, за декілька секунд.

Ретроспектива (Retrospective) — тут цікаво. Усі ШПІ не досить швидкі. Вони не можуть запропонувати вдосконалення продукту, якщо ви не запитаєте про це. Тому спочатку хтось реальний має зробити запит, а потім ШПІ допоможе вам у брейнстормінгу. Ретроспективи будуть проходити швидше, оскільки ШПІ може надати десятки думок та пропозицій.

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

Делегування

ШПІ не реальний (ми не говоримо про роботів… поки що). Це означає, що ми технічно делегуємо йому всю роботу… або ні.

Висновки

Не варто боятися співпраці зі ШПІ та однозначно варто спробувати. Знайдіть найкращий спосіб взаємодії з ним та очікуйте багато змін у груповій динаміці з віртуальним колегою/колегами в команді.

Підписатися на новини

Чудово! Ми вже готуємо добірку актуальних новин для вас :)

Вибачте, щось пішло не так. Будь ласка, спробуйте ще раз.

* Обов'язкові поля

*Будь ласка, заповніть обов’язкові поля

Вакансії EPAM Ukraine у Київ | Львів | Харків | Дніпро | Вінниця | Івано-Франківськ | Одеса | Чернівці | Хмельницький | Рівне | Ужгород | Тернопіль | Луцьк за напрямком Java | JavaScript | .NET | DevOps | Experience Design | Software Testing | Business Analysis | Python| Big Data | Mobile | Solution Architect | Ruby on Rails у містах за напрямком Java вакансії Київ | Java вакансії Харків | Java вакансії Львів | Java вакансії Вінниця | Java вакансії Одеса | Java вакансії Івано-Франківськ | Java вакансії Чернівці | Java вакансії Хмельницький | Java вакансії Рівне | Java вакансії Ужгород | Java вакансії Тернопіль | Java вакансії Луцьк | JavaScript вакансії Київ | JavaScript вакансії Харків | JavaScript вакансії Львів | JavaScript вакансії Вінниця | JavaScript вакансії Одеса | JavaScript вакансії Івано-Франківськ | JavaScript вакансії Чернівці | JavaScript вакансії Хмельницький | JavaScript вакансії Рівне | JavaScript вакансії Ужгород | JavaScript вакансії Тернопіль | JavaScript вакансії Луцьк | DevOps вакансії Київ | DevOps вакансії Харків | DevOps вакансії Львів | DevOps вакансії Вінниця | DevOps вакансії Одеса | DevOps вакансії Івано-Франківськ | DevOps вакансії Чернівці | DevOps вакансії Хмельницький | DevOps вакансії Рівне | DevOps вакансії Ужгород | DevOps вакансії Тернопіль | DevOps вакансії Луцьк