Немає ідеального розміру для циклу зворотного зв’язку
Чим більше я писав цю публікацію, тим більше здавалося, що я повинен написати якийсь тип TL;DR для певних людей, які це читають. Отже, щоб заощадити час, ось це:
Я пишу це для тих, хто тільки починає займатися самозайнятістю, керувати проектами або взагалі має менше досвіду, ніж ті, хто запитує: «Навіщо ви це пишете?» Зрештою, більшість із нас дізнаються про це в якийсь момент цього промисловості, але якщо ми зможемо допомогти один одному скоротити це швидше, ніж пізніше, ми всі виграємо.
Якщо ви все ще зацікавлені після прочитання примітки вище, я припускаю, що ви прагнете покращити цей аспект спілкування. Це добре, тому що я теж 😏, і використання невеликої петлі зворотного зв’язку є одним із способів, у який я знайшов це зробити.
Кожна галузь має свій власний жаргон, і багато хто з нас сміється над ним, але всі ми продовжуємо використовувати його в професійному середовищі. Нам так смішно.
У будь-якому випадку, у нашій галузі одна з фраз, яку ми часто використовуємо, включаючи мене, — це «петля зворотного зв’язку». Вперше я зустрів цю фразу стосовно зворотного зв’язку від підсилювачів. Це не мало нічого спільного з програмним забезпеченням. Тим не менш, у тому, що ми робимо, ми зазвичай використовуємо це для позначення:
- надсилання запиту, коментаря або загальної інформації клієнту,
- отримання відповіді від замовника щодо зазначеної інформації.
А для тих, хто не звик до цієї ідеї (оскільки є ті, хто робить випуски «великого вибуху», про які я розповім за хвилину), цикли зворотного зв’язку зазвичай вважаються малими чи великими.
Чим довше я працюю в програмному забезпеченні, тим більше я завжди прагну до невеликої петлі зворотного зв’язку, незважаючи ні на що.
Ідеальна петля зворотного зв’язку
Невелика петля зворотного зв’язку означає, що між компанією та клієнтом відбувається часте спілкування (тому, природно, велика петля зворотного зв’язку – це коли спілкування відбувається рідше).
Якщо ви збираєтеся використовувати жаргон, принаймні подумайте про це якось весело, чи не так?
Але ви знаєте той жаргон, який я згадав на початку статті? У звичайному перетворенні я б просто сказав:
Що стосується роботи над проектом, я віддаю перевагу частішому спілкуванню.
І причина, чому я віддаю перевагу цьому і навіть за замовчуванням, полягає в тому, що коли справа доходить до створення рішення, незалежно від розміру, для когось іншого, завжди є рухомі частини, які слід враховувати.
Коли в проекті є кілька частин, є кілька місць, де щось може знадобитися налаштувати чи змінити (або це може вплинути на загальну систему), і правильне введення цього на ранній стадії, а не пізніше, економить багато часу (і, отже, грошей) і стрес для більшості залучених сторін.
І що?
Але навіщо писати про це? Для мене причина в тому, що чим довше я керую невеликим магазином, тим більше я чую від клієнтів про проблеми, пов’язані з відсутністю чіткості, комунікації та управління проектами в попередніх проектах.
облом. Я не хочу виконувати таку операцію. Отже, це легко виправити, чи не так?
Крім того, індустрія розробки наповнена людьми, які приймають вимоги проекту, припускають, що вони розуміють усе, що потрібно, а потім повертаються лише для того, щоб створити щось, що не тільки не відповідає меті, але лише виглядає дещо схожим на те, що задумав клієнт.
Це не обов’язково помилка програмістів, але все це «[пропущення] цілі» можна виправити, якщо ми просто будемо спілкуватися з тими, з ким ми працюємо трохи частіше.
Не думайте, що ви знаєте, чого вони хочуть.
Натомість ставте запитання, уточнюйте вимоги, працюйте над функцією, а потім презентуйте клієнту в проміжному середовищі. Вони дізнаються, чи ви побудували те, що вони просили. Якщо так, то переходьте до наступної функції. Якщо ні, є ще над чим працювати. Робота таким чином спрощує велику кількість точок напруги, які виникають у проектах.
І так, задавати багато питань може стати втомливим і навіть дратуючим. Велика справа. З самого початку згадайте, що ви збираєтеся поставити багато запитань, щоб повністю зрозуміти проблему, перш ніж намагатися її вирішити. Наведіть причину, чому ви робите те, що ви робите. Це, як правило, добре окупається.
Випуски Big Bang
Раніше в дописі я згадував «випуски великого вибуху», і це загалом стосується ідеї, коли клієнт надає вам вимоги, ви повертаєтесь до роботи над цим тижнями поспіль, а потім повертаєтесь і говорите: «Гей, я Готово – подивіться!» тільки щоб дізнатися, що це далеко.
Якби я контекстуалізував це в рамках типу циклу зворотного зв’язку, я б сказав, що такого немає. Він навіть не великий, тому що відгуків не вимагали. Це просто:
- Ось вимоги до проекту,
- Я закінчив з проектом.
Часто це призводить до того, що розробники неправильно розуміють вимоги, клієнти не знають про прогрес, а загальний проект йде нанівець. Простіше кажучи, не робіть цього таким чином.
Ідеальний розмір?
Я не знаю, який ідеальний розмір циклу зворотного зв’язку. Деякі клієнти, з якими я працював, мають щоденну реєстрацію, є десь щотижневі реєстрації, а є деякі, які сказали «просто заповніть це та дайте мені знати, коли закінчите».
Щотижневі реєстрації, коміти, релізи тощо є моїми улюбленими, але це через розмір проекту та розмір команди, з якою я працюю. Щодня теж непогано, залежно від завдання.
Я ніколи не виконую стиль великого вибуху, навіть якщо клієнт каже, що це нормально. Я все ще люблю мати контрольно-пропускні пункти для власного здорового глузду. Тож будь-який тип циклу зворотного зв’язку найкраще підходить для вас, вашої команди та вашого клієнта буде ідеальним розміром.