Дрейфові задачі в програмуванні. Відділяємо мухи від котлет, щоб не засмерділось

Щоб оцінити час на розробку, а для фрілансера відповідно і вартість, потрібно осягнути задачу. Іноді, щоб назвати час, потрібно три дні…

Попереднього разу я намагався описати як я бачу ситуацію оцінки задач зі свого боку. Сьогодні трохи доповнення. Змоделюємо ситуацію:

Ви описали задачу, зробили 90% від об’єму і бачите, що у Вас залишилось ще 90%… Наступного разу Ви звісно перестрахуєтесь, візьмете час з запасом, а також серйозніше підійдете до аналізу. Проте як бути зараз.

Під час попереднього проекту зі мною кілька разів траплялись моменти, що додавали по 90% до вже існуючого об’єму… При чому я помітив, що блокери (назвемо це так) можна умовно розділити:

  • незнання технології — часто трапляється при роботі в новій області, я маю на увазі стандарти продуктивності, безпеки тощо;
  • неприцільне застосування навиків — якщо ми не знаємо правил середовища, або ці правила змінюються;
  • помилки архітектури.

Напевно вище написане потребує узагальнення та більш детального опису, оновлення буде трохи згодом. На разі останні кілька днів така диференціація допомагає в прискоренні — визначення природи проблеми суттєво зменшує об’єм правок.

Залишити відповідь