У молодих компаній-розробників програмного забезпечення одна з найбільш важливих проблем, що встають на шляху розвитку, полягає в невисокому рівні лояльності (довіри) [потенційних] клієнтів. Загалом-то з часом, за умови якісної роботи, вона поступово усувається природним чином. Однак, яким способом можна прискорити вирішення цього питання? Один з варіантів - організація прозорого процесу розробки.
Нещодавно до нас у компанію «прийшов» клієнт, який відмовився від продовження співпраці з іншим підрядником. Причини стандартні. Розробники створювали продукт за принципом чорної скриньки: визначався список завдань, вони йшли все це робити, а потім разом викочували клієнту все, що вийшло. Звідси купа проблем, постійна недовіра клієнта, тому що він не розуміє, чим цей час займалася команда, чи дійсно стільки часу їм потрібно було, і якщо так, то чому в результаті клієнт все одно залишився незадоволений. Звідси результат: продукт вийшов не таким, яким його очікував побачити клієнт, зіпсовані відносини і репутація. Програшна ситуація для обох.
У нас вийшло виправити ситуацію за рахунок організації прозорого процесу розробки. При роботі з попереднім підрядником, замовнику доводилося багато часу витрачати на технічну складову проекту, займатися постійними перевірками розробників, замість того, щоб концентруватися на бізнесі. Зараз клієнт в будь-який момент часу розуміє на якому етапі знаходиться проект, має можливість коригувати хід робіт, дає нам швидкий зворотний зв'язок.
Ми вже досить давно виробили для себе найбільш вдалий варіант комбінації декількох гнучких методологій розробки ПЗ, який успішно застосовуємо (іноді він змінюється в деталях і підлаштовується під конкретний проект). Далі будуть описані основні складові нашого процесу, які, на мою думку, більше за інших впливають на швидкість встановлення довірчих відносин розробників з клієнтами.
Як додати прозорості?
На допомогу приходять гнучкі методології розробки. З мого досвіду, команди ніколи не дотримуються строго однієї методології, наприклад, Scrum або Kanban, найчастіше кожна команда просто адаптує під себе комбінації практик з різних методологій. Наприклад, ми використовуємо практично всі прийоми з екстремального програмування, крім, скажімо, Planning Poker. В результаті таких експериментів з адаптаціями методологій вибудовується процес, який найбільшою мірою підходить команді.
Ми зрозуміли слабкі місця процесу розробки попередньої команди і усунули їх шляхом введення в процес декількох важливих складових, які безпосередньо пов'язані із взаємодією з клієнтом. Ось найбільш важливі з них.
Часті релізи
Процес будувався приблизно наступним чином. Ми плануємо певний набір функціоналу, який потрібно виконати на поточному етапі. Обсяг робіт, наприклад, відповідає місяцю розробки, однак це не заважає нам випускати релізи продукту щотижня (за фактом - щодня), додаючи нові можливості поступово, а не одноразово. Таким чином, на місяць ми випускаємо 4 оновлення, замість одного. Це дає нам можливість отримувати зворотний зв'язок і реагувати на нього максимально швидко.
Continuous Integration
Безперервна інтеграція є невід'ємною частиною якісної розробки. Будь-які зміни повинні автоматично потрапляти на тестовий стенд у повністю зібраному вигляді, де їх повинен перевірити QA-інженер. В даному випадку на те є дві основні причини: зворотній зв'язок і клієнт. Максимально швидко зрозуміти, що щось пішло не так, як передбачалося, дуже важливо. Крім цього, коли клієнт може в будь-який момент часу мати доступ до самої останньої версії продукту (нехай не завжди 100% робочої), позитивно позначається на його лояльності в цілому.
Правильна дошка
Перш за все, дошка, на якій відображається процес розробки взагалі повинна бути:Але неправильний поділ дошки за статусами може мати негативний вплив на проект. Коли завдання «йде» по дошці не повинно виникати сумнівів, що саме відбувається із завданням і в якому воно статусі. Під цей проект у нас були визначені наступні колонки: Backlog — Todo — In work — Done — Testing — Resolved — Deploy. В іншому випадку, швидше за все, буде інший набір. Важливо щоб ці колонки відповідали природному ходу завдання і не були двозначними.
QA-інженер
До команди повинен бути підключений QA-інженер, що відповідає за якість продукту в цілому. Це не просто тестувальник, який «протикає» систему за описом завдання. Це людина, яка веде повністю всі сценарії використання системи, тестує нові завдання, проводить регресійне тестування. Його робота багато в чому визначає якість продукту, тому така людина обов'язково повинна бути залучена до роботи.
Standup Meeting
Стендап мітинги - про них всі знають, але реально не всі використовують. Ці міні-планерки тривалістю не більше 15 хвилин несуть величезну користь команді і проекту в цілому. Щоранку (або до обіду) зідзвонюємося в Skype з клієнтом і кожен член команди розповідає про те, що було зроблено за вчорашній день, які виникли проблеми, як вони вирішуються або вирішилися, а також підписується на те, що буде зроблено сьогодні. Така практика, крім усього іншого, поступово підвищує рівень довіри між клієнтом і командою. [У Kanban, до речі, стендапи проходять по-іншому]
Demo
Після закінчення кожної ітерації, потрібно демонструвати клієнту виконану роботу. Показувати потрібно все, що було зроблено або виправлено. Демонструвати, а не просто дати посилання на dev-сервер, де клієнт може сам все подивитися. Він і так подивиться сам, але після вашої демки. Важливо відразу ж отримати зворотний зв'язок, можливо, провести якісь обговорення. Демонстрація - дуже важлива складова. Приємно хвилююча. Бере участь вся команда, але безпосередньо демонструє хтось один: тимлід або QA-інженер.
Ув'язнення
У цій статті я перерахував кілька основних складових процесу розробки ПЗ, які дозволили нам вибудувати лояльні відносини з клієнтом, що має невдалий досвід співпраці з іншою командою. Звичайно, гнучкі методології пропонують набагато більше різних методів, багато з яких ми використовуємо, проте тут я навів саме ті, які, по-моєму, більше інших важливі для вибудовування прозорого процесу і довірчих відносин клієнтів з виконавцями.
Варто відзначити так само те, що для виконання подібних технік і підтримки високого темпу, команда розробників повинна бути досить високого рівня. Особливо це стосується практик екстремального програмування, основні тези якого спрямовані саме на інженерну складову.
Дякую за увагу. Сподіваюся, командам з ще не до кінця поставленими процесами, стаття виявиться корисною.
Посилання
Scrum и Kanban: витискаємо максимум, Х. Кніберг і М. Скарин.
Екстремальне програмування, К. Бек.
Ощадливе виробництво програмного забезпечення, М. Попендик і Т. Попендик.