По-перше, потрібно організувати чіткі правила взаємодії та узгодити процеси в робочій групі, щоб кожен знав над чим працюють його колеги, які виникають труднощі, де потрібна допомога і, найголовніше, як це все працює разом. В цьому вам можуть допомогти так звані скрам-зустрічі – щоденні стендапи, ретроспективи та грумінги беклогів.
По-друге необхідно узгодити зв’язок між робочою групою та замовником. Найчастіше, це комунікація між проджект-менеджером та відповідальною особою з боку замовника. Тут дуже важливо працювати в парі, розуміти реальні потреби та можливості клієнта, керувати його очікуваннями та тримати його в курсі. Саме цей аспект взаємодії може стати визначальним у подальших взаєминах.
–
Здається, ця проблема потребує особливої уваги.
Так і є. Ігнорування питання процесів взаємодії, як правило, призводить до проблем з комунікацією та відсутності порозуміння. Для того, щоб уникнути цього, власнику проекту необхідно:
а) визначити пріоритетність завдань;
б) розбити пул задач на спрінти, а складні та об’ємні задачі – на підзадачі;
в) визначити та детально описати юзер-кейси, архітектуру проекту, зовнішні інтеграції, а також усі нюанси, які можуть вплинути на належне виконання завдань та реалізацію проекту;
г) ознайомити робочу групу з бізнес-нюансами проекту: які проблеми він вирішує, які особливості його використання, хто буде користуватись його результатами та іншим.
–
Що ще може перешкодити ефективній роботі над проектом?
Зміна складу команди. Дуже складно вводити нових людей в курс справи, а ще складніше працювати над кодом, який хтось створював до тебе. В будь-якому разі, життя непередбачуване, тому важливо слідкувати за документацією проекту, стандартами написання коду та результатами переговорів. Впорядкована та чітко структурована інформація ще нікому не нанесла шкоди.
–
То ми підходимо до ще одного кошмару будь-якого власника продукту та його технічних партнерів – дедлайнів?
Саме так. При встановленні термінів будьте реалістичними, ретельно оцінюйте проект на початку співпраці. При встановленні коротких термінів, як правило, виникає бажання почати заробляти якомога швидше, а це може привести до руйнування всіх стандартів кодування та проектування роботи. До того ж, менший час означатиме меншу кількість функціоналу. Звичайно, існують моменти коли це доцільно, наприклад, проектування MVP чи тестуванні нових гіпотез, але, в будь-якому разі, необхідно це розуміти. Високонагружений маркетплейс неможливо реалізувати за три місяці, скільки б людей не працювало над цим.
–
Згоден, але що не так з надто довгими дедлайнами?
Занадто довгі строки часто підтримуються топ-менеджерами через надмірну функціональність проекту внаслідок перебільшення бюджетів. Таким чином, вони можуть запропонувати додати функціональні можливості Ali-Express або Amazon. Неможливо створити ідеальний продукт без фідбеку кінцевих користувачів. Можливо, доцільно замислитись над версійністю продукту, оскільки нові “фішки” це хороша ідея, але на момент їх реалізації вони вже можуть застаріти. Майте це на увазі під час прийняття рішення.
–
Чи завжди дедлайни встановлюють кінцеву дату релізу?
Ні, є ще багато речей, які також впливають на роботу команди. Спробуйте зберегти ритм. Іноді робочий процес досить хаотичний, в будь який момент може виникнути форс-мажор або національне свято. Тому слідкуйте за тим, щоб всі задачі формувались рівномірно. Не перевантажуйте людей і не залишайте їх без роботи взагалі. Також забезпечте своєчасне затвердження всіх поточних і майбутніх завдань, щоб уникнути застою.
–
Іноді кінцеві строки залежать від бюджету, чи не так?
Не завжди, але звісно, це важливий компонент будь-якого проекту. Тож давайте поговоримо про бюджети.
–
Якщо обирати між недофінансуванням та надмірним фінансуванням, що краще?
На мій погляд, обидва випадки погані. Занадто низький бюджет означатиме низьку кваліфікацію персоналу (не факт, але в більшості випадків), перевантаження обов’язками (коли програміст також виконує задачі QA, фронт-розробника і навіть менеджера продукту), а також швидку зміну кадрів, оскільки невеликий бюджет призводить до скорочення термінів і тиску на вашу команду.
–
Добре, та що може трапитись з великим бюджетом? Будь-яка компанія має бути щасливою отримати його.
Дивно, але ні. Великі бюджети спокушають використовувати більше ресурсів та реалізовувати більше функціоналу, ніж це дійсно потрібно. Це автоматично подовжує термін окупності бізнесу. Збільшення бюджету суттєво збільшить вартість проекту. Але ваша команда і ви повинні чітко зрозуміти, що це не означає, що якщо збільшити бюджет, ваш проект буде розвиватися швидше. Не завжди дедлайни залежать від бюджетів, існують також процеси на які неможливо вплинути.
–
Коли я готувався до інтерв’ю, то був впевнений що ми почнемо з технологій та мов програмування.
Це одне з основних питань. Але я вірю, що команда – це найголовніше, та й з цим проблем більше. Що стосується технологій, вони повинні відповідати:
- вашому завданню. Ви повинні мати чітке уявлення про подальший розвиток бізнесу та задачі, що можуть виникнути під час процесу трансформації та відповідно до цього підібрати технології;
- вашому бюджету. Головна мета – економічно ефективне інвестування та отримання прибутку якомога швидше. Отже, ми завжди повинні враховувати витрати на придбання, підтримку технологій, придбання ліцензій та оплату фахівцям, які можуть реалізувати проект.
- деякі внутрішні стандарти компанії. Наприклад, банки, зазвичай, мають певні особливості обробки даних та вимоги до безпеки персональних даних , що впливають на вибір технологій;
- серверні потужності. Інколи важко масштабувати проект за допомогою деяких технологій з урахуванням можливостей інфраструктури;
- підтримання технології у подальшому. Якщо у вас виникає спокуса використовувати певну популярну технологію, спробуйте спрогнозувати, чи буде вона надалі підтримуватися. У нашій практиці був випадок з Google Polymer. Команда почала працювати над проектом з цією технологією, але дуже скоро Google припинив його підтримувати, що завдало збитків і нам, і власнику продукту. Довелося переробляти проект за допомогою стандартних технологій;
- рівень компетенції вашого персоналу. Іноді зовнішнє залучення професіоналів є єдиним способом забезпечення належного виконання вашого проекту. Це той випадок, коли вам потрібні деякі рідкісні навички, які ви не можете знайти серед своїх співробітників.
–
Чудово! Дякую. Підсумуємо?
Я б радив звернути увагу на три основні моменти:
1) Команда повинна навчитися визначати пріоритети основних задач, функціональні можливості проекту та реалізувати їх відповідно до потреб бізнесу;
2) Дуже важливо правильно налагодити внутрішні процеси комунікації та взаємодії;
3) Одним з найважливіших пріоритетів у процесі веб-розробки є детальний аналіз і фрагментація завдань на менші.
Сподіваюсь мої відповіді будуть комусь корисні та вчасно врятують проект.
