Як не перетворити розробку на пожежу: чому ми тримаємо зв'язок із замовником у режимі 24/7

Здавалося б, розробка сайту має мало спільного з рятуванням унікальних тропічних лісів Амазонки від лісових пожеж. Терміновість тут має умовний характер, а поспішати можна повільно. Але взагалі це не так. За 20 років роботи на ринку ми у WEZOM твердо усвідомили, що терміновість – це терміновість. Хоч на пожежі, хоч у розробці складного ІТ-продукту. Без оперативного та постійного зв'язку із замовником у розробці не обійтися.

Без замовника нічого не вийде

За даними дослідження Standish Group (SG), лише близько третини реалізованих за останні 5 років проектів в ІТ (31%) можуть вважатися цілком успішними. Успішний проект – той, який уклався в заявлені терміни, не вийшов за межі затвердженого бюджету та повністю задовольнив замовника.

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

Чому так відбувається? Аналітики тієї ж SG протягом багатьох років наполягають, що великі бюджети, передові технології та зіркові команди фахівців не гарантують успіху, якщо у розробку слабко залучено менеджмент з боку замовника. Ясне розуміння бізнес-цілей проекту і цілющі фідбек також важливі для розробки, як талант дизайнера і золоті руки програміста.

Замовники – теж люди

Здавалося б, замовник повинен всією душею вболівати за свій проект і постійно стежити за ним (адже він платить за нього гроші). Вихід здається очевидним – дати замовнику засоби контролю за процесом розробки: узгоджувати кожен етап, звітувати за кожним спринтом і з кожної нової фічі. Насправді все складніше.

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

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

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

Проблема часу

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

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

У роботі із закордонними замовниками це може накластися на проблему часових поясів. Скажімо, клієнт із США хоче поставити невідкладні питання у свій робочий час, а представник підрядника з цього боку Атлантики у цей час спить.

Комунікація без зручного для всіх тайм-менеджменту – чудовий спосіб провалити розробку. У пошуках найкращої моделі такого менеджменту ми свого часу набили безліч шишок.

Гасіння пожеж

Дуже рідко на проекті може виникнути паніка. Це маленьке стихійне лихо трапляється абсолютно непередбачувано. Іноді – з технічних причин (щось «упало» в самий невідповідний момент, знайдено критичний баг тощо). Але набагато частіше – через прогалини в комунікації.

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

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

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

Про технічні моменти й говорити не варто – якщо замовник уже почав використовувати ключові елементи нового проекту у своєму бізнесі, технічні проблеми часто загрожують йому прямими збитками.

Як ми з цим упоралися?

Як забезпечити залучення клієнта до проекту, вирішити проблему часу, вчасно «гасити пожежі» та справлятися з їхніми шкідливими наслідками? І чи бажано добитися цього без перевитрати ресурсів та нервів співробітників?

Методом спроб і помилок ми дійшли висновку, що найкращий спосіб – закріплювати за кожним замовником персонального менеджера. Він готовий закривати будь-які питання щодо проекту в режимі 24/7 та забезпечувати максимально швидкий зворотний зв'язок.

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

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

Тут важливо уникнути крайнощів – персональний менеджер не повинен стати «пляшковим шийкою» у контактах із замовником. Ми орієнтуємо всю команду на максимально швидкий зворотний зв'язок (день на день) і даємо клієнту якнайбільше засобів контролю. Проводимо щотижневі мітинги (наживо чи онлайн), де звітуємо про виконані завдання та повідомляємо подальші плани.

В рамках підходу SCRUM (про який ми розповіли нещодавно) наші розробники ведуть для замовника максимально прозору звітність щодо роботи над проектом. Для цього може використовуватися електронний документ, до якого заносяться етапи проекту, майбутні доопрацювання та строки їх виконання.

І це працює?

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

Багато залежить від професійності менеджерів (ми, наприклад, ними дуже пишаємось). Нарешті, важливим є сам принцип – готовність компанії стати для клієнта не просто «руками», а й повноцінним партнером, з головою поринути у специфіку його бізнесу.