Як третій внесок у серії статей про програмування Моб, що документують наш досвід, випробування та найкращі практики, я хочу висвітлити дуже важливі взаємозв’язки між розробкою програмного забезпечення та управління продуктами.
Коли ми почали мобінг, ми почали запитувати, як інші команди будуть взаємодіяти з натовпом. UX-дизайн, управління продуктами, управління персоналом, якість, операції мають усі точки дотику, які потрібно оцінити. Управління продуктами є ключовим щоденним учасником Моб, а також бажаним воротарем для розгортання на виробництві. Але ми зрозуміли, що деякі ключові орендарі програмування моб впливають на традиційну поведінку управління продуктами. 1) Давайте розпочнемо завдання спільно, як команда, яка не потребує тижнів обдумування вимог. 2) Члени групи з управління продуктами є членами натовпу, хоча вони можуть не сидіти з натовпом цілий день. Вони відповідають за участь у щоденних ретро-програмах та відповідають на запитання як власник товару протягом дня.
Спочатку дозволяє вирішити проблему спільного початку. З одного боку, є вагомий аргумент, що якщо менеджер продукту задокументує бачення функції і навіть знущається над нею, перш ніж займатися розробкою, це стане більш ефективним і менш потенційним для неправильного шляху, як тільки ми почнемо впровадження. З іншого боку, можна стверджувати, що команда (Product + Engineering = Mob), починаючи з чистого аркуша замість заздалегідь продуманих уявлень, буде більш ефективною, оскільки ітерація вимог перевіряється разом із найменшою кількістю коду, який пишеться для виконання основна мета.
Уявіть собі типовий сценарій, коли вимоги пишуться заздалегідь, користувальницький досвід повністю висміюється до того, як інженерія готова до початку. Це, мабуть, не дуже важко уявити, оскільки саме так працює 99% програмних проектів. При такому виконанні програмна інженерія повинна переглянути вимоги, почати задавати питання, вимоги неминуче змінюються внаслідок цього зворотного зв’язку, і часто буває гра в телефонну інтерпретацію запитуваного. Часто вимоги до часу розроблялися для функцій, які врешті-решт змінюються до того, як функція навіть працює над командою інженера програмного забезпечення. Навіть більше того, багато вимог будуть повністю відкинуті в кінці цього раунду оцінки. Зрештою, це не звучить м’яко та ефективно. Це, безумовно, не відповідає орендарям Agile Manifesto, не кажучи вже про принципів програмування натовпу.
У початковій культурі ми залучаємо наших розробників та власників продуктів (можливо, навіть засновника) до столу за допомогою дошки, щоб почати функцію. Команда навчається разом. Команда визначає разом короткі перші кроки, які в майбутньому можна вдосконалити. Ми повинні запитати себе, чому ми відступаємо від початкової культури, коли зростаємо та досягаємо успіху. Ідея команди є дуже важливою та важливою для того, щоб бути командою, а не серією елеваторів, що вимагають складних процесів для полегшення передачі знань між передачами та, зрештою, CYA.
З кожним мобом ми призначили члена команди менеджера по продуктам, будь то на певну функцію або на більш тривалий термін, як спеціальний член команди. Менеджер продукту відповідає за допомогу в першій ідеї функції, будучи власником продукту, щоб відповісти на запитання і врешті-решт визначити, коли функція виконана і може бути відправлена на виробництво. Менеджер продукту може не сидіти з інженерами цілий день, але вони реєструються та мають пульс команди розробників, щоб передбачити, коли вставити себе.
Ми запускаємо нову функцію або вдосконалення під час наради, щоб колективно пройти ідею як натовп інженерів, управління продуктами та навіть виконавче управління, що фіксує в режимі реального часу те, що ми хочемо досягти. Ми залишаємо цю зустріч з дошкою вимог та дизайнерських ідей, щоб виконати все на одній сторінці. Навіть для більших змін архітектури ми розпочали цей шлях, але потім додали огляди дизайну всіма однолітками.
Як і багато організацій, наша команда в даний час має ресурси для користувацького досвіду в команді управління продуктами. Оскільки це є загальним явищем, це також може бути причиною загальної початкової проблеми при запуску програмування моб. По-перше, критично важливо не розглядати його як дві або більше команд, а єдину мафію, яка працює разом, незалежно від остаточної структури звітності. По-друге, ми дійшли висновку, що проектування інтерфейсу починається з того самого моменту, і його не слід починати заздалегідь. Початок спільної роботи в команді є набагато більшим, ніж будь-яке уявлення про те, що наявність повністю розробленої концепції інтерфейсу користується якоюсь мірою більш ефективною. Поки робота починається разом, тепер може бути паралельна робота однієї доріжки у розробці з використанням елементарних узгоджених елементів сторінки, а інша доріжка починає повторювати красиву концепцію дизайну інтерфейсу. Ці паралельні доріжки продовжують збиратись разом протягом проекту в ітераціях інтерфейсу користувача. Це дозволило мати швидкі, швидкі та прості тестовані функції.
Концепція спільної роботи над завданням не може бути достатньо висвітлена. Важко відмовитися від ідеї оптимізації для особистості як більш ефективної, але довіряти доказам. Початок спільної команди приносить команді визнання того, що їх думки мають значення, що виявляє повагу, і врешті-решт це зумовлює рівень власності кожного члена команди, якого я раніше не спостерігав. Інженери-програмісти – творчі люди, які покращать процес проектування, коли їм нададуть шанс.
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/mob-without-product-management-matt-ferguson/.
Matt Ferguson люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 