Якщо ви вже займались розробкою застосунків, то розумієте, скільки знань та досвіду треба, щоб перетворити ідею в продукт, який можна буде запустити на ринок. Ви знаєте, що існує front-end development (розробка інтерфейсу, тієї частини застосунку, з якою взаємодіє користувач) і back-end development (розробка програмно-адміністративної "внутрішньої" частини застосунку). Вам відомо, що процес розробки складається з декількох етапів, і на кожному з них ви повинні перевіряти та затверджувати вже виконану роботу. І, напевно, ви вже зіткнулись з тим, що фінальна версія продукту все одно матиме баги та потребуватиме подальшої роботи.
Усі етапи розробки застосунку вимагатимуть певного «управління» з вашого боку. Але чи знаєте ви, як ефективно співпрацювати з розробниками, особливо якщо мова йде про віддалену роботу?
У цьому пості ми поділимось порадами щодо того, як правильно побудувати роботу команди розробників, щоб процес створення застосунку був максимально ефективним.
-
Деталі
Ви повинні надати розробнику якомога більше деталей. Намалюйте, яким ви бачите застосунок. Вкажіть послідовність необхідних елементів. Чим більше інформації ви можете надати, тим більше шансів, що ви отримаєте саме те, що потрібно, і отримаєте це вчасно. Всі дані розробник зможе використати для створення макету, який ви повинні будете затвердити.
-
Комунікація
На самому початку роботи визначтесь з інструментами, які ви використовуватимете для комунікації. Складіть графік зустрічей за результатами роботи. Але пам'ятайте, що він має бути гнучким, адже без жодного сумніву виникатимуть проблеми, які потребуватимуть обговорення поза графіком, а будуть випадки, коли до запланованих зустрічей не буде досягнуто жодних результатів.
Що ще обов’язково має бути частиною вашої комунікативної стратегії?
- Поділіться своєю історією з розробниками: ваша команда повинна знати, хто ви, чим займаєтесь, яким є ваш бізнес та які цілі ви ставите перед собою. Чому так важливо розповісти якомога більше про ваш "бренд"? Позиціювання вашого бренду безпосередньо вплине на дизайн застосунку, вибір кольорів та розробку багатьох інших деталей.
- Перед обговоренням проєкту з розробниками добре підготуйтесь та обдумайте відповіді на всі можливі запитання. Детально поясніть, на який результат ви розраховуєте. Не сподівайтесь на щасливу випадковість. Що ще важливо пам'ятати. Ви самі повинні дуже добре розуміти, як має функціонувати застосунок, інакше ви не зможете зрозуміло пояснити іншим, чого від них чекаєте. Відсутність власного бачення також означатиме, що вам доведеться змінювати правила гри по ходу роботи - це додаткові фінансові та часові втрати. Розробники завжди хочуть виконати роботу якісно - від цього залежить їх репутація. Але вони не можуть читати ваші думки.
- Фідбек
Вашій команді розробників потрібен чесний фідбек на кожному з етапів роботи. Будьте максимально відкритими та відвертими. Якщо ви задоволені результатом, не соромтесь хвалити. Якщо робота скоріше вас розчарувала, будьте дипломатичними, але чесно поясніть, що саме вас не влаштовує.
Водночас важливо, щоб розробники також надавали вам фідбек, адже вони, напевно, також мають пропозиції щодо того, як зробити застосунок кращим. Зрештою, вони розуміються на своїй справі та мають достатньо досвіду, щоб передбачити, які функції потрібні, а від чого можна відмовитись.
І ще одна важлива порада. Під час перемовин з розробниками ви повинні поставити наступні запитання. Чи має ваша команда все необхідне, щоб працювати над проєктом? Чи працювали вони коли-небудь над схожими проєктами? Якщо так, з якими проблемами вони стикались та як подібних ситуацій можна уникнути в майбутньому?
-
Часові пояси
Якщо ваша команда розробників знаходиться в іншій частині світу, вам треба визначити, у який час всім буде зручно збиратись для обговорення проєкту. Якщо ви маєте 8 годин різниці у часі, 8 ранку у вашій країні - це 16 година для вашої команди. Підійдіть до цього питання з розумінням, аби нікому з команди не довелось прокидатись з першими півнями чи засиджуватись за опівніч.
-
Мікроменеджмент
Ви вирішили працювати з командою розробників, оскільки вони мають більше знань і досвіду, ніж ви. Ваша команда розуміє, в які моменти їм потрібен фідбек. Навіть якщо ви вже все для себе запланували, дозвольте розробникам робити їх роботу так, як їм зручно. Якщо ж ви щодня перевіряєте, що було виконано, та вимагаєте постійно тримати вас в курсі прогресу, можете бути впевнені, що робота просуватиметься повільніше. Просто запропонуйте ознайомитись з тим графіком, який ви склали, та попросіть повідомляти вас про завершення чергового етапу роботи.
-
Договір про нерозголошення
Одним з найбільших страхів для будь-якого підприємця є крадіжка їх "інтелектуальної власності". Так, розробник може взяти вашу ідею, створити посередній застосунок, а потім привласнити ідею та перетворити її на прибутковий бізнес.
По-перше, якщо ви уважно ставилися до вибору розробника (див. Частину 1), такий сценарій розвитку подій є малоймовірним. Розробники також повинні бути чесними зі своїми замовниками, якщо вони хочуть надовго залишитись у бізнесі.
Якщо ж думка про крадіжку ваших ідей все ж не дає спати вночі, підготуйте угоду про нерозголошення, адже розробнику може знадобитися доступ до конфіденційних даних (наприклад, бази даних клієнтів) або він працюватиме над кодом або алгоритмами для внутрішнього користування компанії. Якщо хоч один з пунктів вище стосується вашого бізнесу, напевно, угода про нерозголошення - це найкращий спосіб убезпечити себе.
Зверніться за юридичною консультацією, складіть угоду та підпишіть її перед тим, як передати вашу ідею в роботу та озвучити деталі проєкту. Мета полягає в тому, щоб ви отримали «право власності» на весь код та алгоритми, розроблені для вашого застосунку. Це означатиме, що розробник не зможе використовувати цей код у майбутньому.
-
Подальша підтримка
Це пункт має бути в будь-якій угоді з розробником чи командою розробників. Навіть Microsoft з часом виявляє баги та займається розробкою патчів. Не сподівайтесь, що ваш додаток буде ідеальним в момент запуску. Зазвичай, програма має хоч і незначні, але баги. Хороші розробники виправляють помилки в ході розробки (особливо, якщо говорити про динамічний підхід до розробки), але все одно повинні впевнитись в тому, що застосунок матиме технічну підтримку ще певний час після запуску. Це також має бути зазначено в угоді. Проте, якщо ви захочете внести якісь суттєві зміни, це потребуватиме додаткового фінансування.
-
Фінансування
Всі знають, що ми завжди отримуємо те, за що заплатили. Тому не будьте дріб'язковими, коли справа доходить до вибору команди розробників. Вони добре знають пропозиції, які є на ринку, та зазвичай проситимуть середню ринкову ціну. Ви можете спробувати торгуватись, але це якісно вплине на фінальний результат.
Висновок
Межа між управлінням і мікроменеджментом дуже тонка. Скористайтеся цими нашими порадами, щоб зробити співпрацю з розробниками продуктивнішою. Адже головними залишаються гарні стосунки в команді, і ваш внесок у встановлення та підтримання дружньої атмосфери є дуже важливим.