Кілька тижнів тому я писав про підхід до ведення проектів, аби уникнути вигорання. Загалом цей підхід виглядає так: створюємо план дій, де розбиваємо завдання на дрібні кроки, притримуємось плану, пам’ятаємо про обмеження потенціалу — щоб його вистачило на увесь марафон.
Даний підхід адекватний, коли Ви знаєте, що робите і стикались принаймні з 80% задач, котрі попадають в проекті.
Проте що робити з тими 20%, які ще не відпрацьовані. Зазначу, що я не маю на увазі новий запит, або функцію з якою не стикались. Мова йде про такі речі як інтеграція нової платіжної системи в магазин, функції мультивалютності, систем чату для існуючих користувачів або налаштувань безпеки.
Тобто, говорячи про нову область, ми маємо на увазі щось більш глобальне, поведінку чого важче передбачити за рахунок взаємодії з іншими модулями проекту. Як тут бути:
- які терміни обіцяти?
- як рахувати потрачений час?
- який функціонал закладати в архітектуру?
Терміни на розробку
На будь-яку задачу з області нерозвіданого варто брати три дні. Не тиждень і не день, а саме три календарні дні. Першого дня розбираємо матчастину, тобто документацію по самій технології. Наступного дня інтегровуємо це безпосередньо в проект, не забуваючи, що оптимальна інтеграція — засобами api материнської системи. Третього дня вивчаємо взаємодію з іншими модулями:
- елементи безпеки — чи не стане наша надбудова діркою для хакерів;
- захист самих екстеншинів при подальшому оновленні основної системи. Актуально для розширень під популярні системи управління контентом;
- визначаємо вузькі місця для масштабування в майбутньому.
Вартість робіт
Доволі непросте питання. З одного боку ми витрачаємо умовні 3 дні (24 години) на те, щоб максимально ефективно інегрувати рішення — ми могли б взяти завдання, з якими стикались раніше і монетизувати потрачений на навчання час.
З іншого боку — справді ефективними для клієнта тут виходять останні 8 годин. І рідко хто з розробників не використовує здобуті навики (під час 1-2 теоретичних днів) в майбутньому.
Я притримуюсь наступної практики: клієнт оплачує лише останні 8 годин. Це за умови:
- якщо завдання не термінове і девелопер може спокійно розібратись в документації;
- здобуті навики теоретично можуть стати в нагоді в майбутньому — якщо це не екзотична cms, або якщо клієнт не наполягає, щоб окремі сегменти коду були захищені налаштуваннями приватності.
Архітектура основної частини та взаємодія
Ми вже говорили, що інтеграція нової технології має йти в рамках доступної аплікації системи. Це дозволяє бути більш гнучкими до оновлень системи в майбутньому.
Ідеальний варіант розробки — це коли ви можете пропиати всю взаємодію на новому екстеншині, який інтегровуєте. Тут мається на увазі, що не потрібно втручатись в код інших блоків, з якими взаємодіє Ваша надбудова.
Це також позбавляє головняку пов’язаного зі збереженням даних при оновленні загальної системи.
Проте в будь-якому випадку ми лишаємо клієнту 10 заповідей із зазначеними вузькими місцями для майбутніх поколінь та картою фукнціоналу.