Чому оцінка веб-проектів є настільки складною?

13.01.2017
Чому оцінка веб-проектів є настільки складною?
Автор:

Одне з найбільш спірних аспектів у розробці сайтів, яке може загнати в глухий кут і про яке часто мають неправильне уявлення — це оцінювання. Тим не менш, цей етап важливий, і в одному з блогпостів ми розповідали, як наша команда оцінює Drupal-проекти. Проте, багато людей, особливо не програмістів, не здогадується, що просити команду розробників оцінити проект і відповісти на питання «Скільки часу він займе?» і «Скільки це буде коштувати?» рівносильне проханню передбачити майбутнє. Правду можна дізнатися тільки після того, як все відбудеться. З маленькою чи великою похибкою, оцінки завжди неправильні. Коли вони правильні, це випадковість. Сьогодні ми назвемо труднощі, з якими програмісти стикаються при оцінці, щоб вияснити, що саме робить цей етап роботи над проектом настільки неоднозначним і складним.

Забагато оптимізму

Більшість програмістів, як правило, схильні до занадто оптимістичних прогнозів. Вони або переоцінюють свою продуктивність або ж недооцінюють складність завдання. Це особливо актуально для нових розробників, які надто впевнені в своїх силах. Якомога точніші оцінювання вимагають великого досвіду, практики і знання системи і завдання. Крім того, деякі компанії віддають пріоритет своєчасності, а не якості. Ця стратегія не завжди може давати задовільні результати, тому що, як кажуть в народі, поспішиш — людей насмішиш. Хорошою порадою буде обіцяти менше, а надавати більше.

Поправки в ході роботи

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

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

Склад команди

Програмісти відрізняються за продуктивністю. Ситуація краща, коли вони оцінюють власну роботу, ніж коли хтось робить оцінку для них.

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

Існує термін «людино-місяць» — тривалість робочого часу однієї людини за місяць. Він використовується для вимірювання об’єму роботи для виконання конкретного завдання. Вважається, що одиниця роботи пропорційна числу людей, які працюють, та помножена на час, коли вони працюють. Фредерік Брук у своїй книзі «Міфічний людино-місяць» спростував це співвідношення, спираючись на власний досвід і спостереження про те, що призводить до затримки більшості програмних проектів. Брук стверджує, що додавання трудових ресурсів до проекту, який відстає від графіка, робить його навіть більш запізнілим. Причиною є час, необхідний для нових програмістів, щоб вловити основну суть і вникнути глибше в проект і, таким чином, збільшення часу спілкування всередині команди.

Непередбачувані труднощі

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

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

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

Помилки і баги

Навіть найкращі та найдосвідченіші розробники не можуть передбачити всіх перешкод і помилок, які траплятимуться. Тому, належна оцінка повинна враховувати високу ймовірність їх виникнення і мати певний запас часу для виправлення багів. У нашій команді є QA інженери, тобто спеціалісти з гарантії якості, які займаються тестуванням сайтів, аби впевнитися, що кінцевий продукт відповідає усім вимогам.

Механічні завдання проти творчих

Механічні і рутинні завдання часто можуть бути автоматизовані до певної міри. Вони більш передбачувані. Якщо програмісти вже мали деяку практику з попередніми подібними завданнями, оцінити їх порівняно не важко.

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

Чому оцінка все ж таки потрібна?

Важливо оцінити значення кожної деталі, незалежно наскільки вона дріб’язкова. Якщо всі потребують зусиль в рівній мірі, тоді просто створити перелік, не беручи до уваги послідовність, і приступати до роботи. Проте, насправді, елементи проекту варіюються в залежності від різної кількості необхідних зусиль і часу. Таким чином, оцінювання їх приблизної вартості дозволяє зробити аналіз витрат і доходів, визначити економічну доцільність і пріоритети.

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

Висновок

Поки програмісти не є ворожками, їхні оцінки — це здогадки і припущення. Отож, розумно визнати факт, що оцінки завжди помилкові, і не покладатися на них повністю, і не панікувати, якщо вони не справджуються на 100%. Відповідати оцінкам і вкладатися у терміни — ще не показник компетентності розробників і не вагомий критерій для судження і висновкування. Більше того, слідування початковому плану може поліпшити оцінки, але також може і призвести до посередніх невисоких результатів, оскільки це вбиває творчий потенціал і прагнення до досконалості. Повторну роботу слід заохочувати, щоб зробити речі кращими, але досить важко знайти баланс між доробкою в контексті поточного проекту і створення нової, яка буде реалізована пізніше. Це шанс відкрити для себе нові виміри, розглянути під іншим кутом.

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

4 votes, Рейтинг: 3.5

Також по темі

1

Час для нової порції корисної інформації з проект-менеджменту від нашого експерта Іванни aka Vania ;) Ми вже дізнавалися більше про...

2

Компанії зі світовим ім’ям поганого не впровадять :) А наш проект-менеджер Іванна aka Vania пише лише про те, що дійсно цього варте. Отже, продовжуємо дізнаватися із серії її блогів про...

3

Декілька років назад Agile — це було нове слово в управлінні проектами. На сьогодні ж цією методологією користуються безліч компаній, для яких Agile - невід’ємна частина робочого процесу. Сьогодні...

4

Знову надаємо слово нашому проект-менеджеру Іванні (aka Vania). В попередній статті вона ділилася ідеями щодо...

5

Ретпроспектива є однією з складових Agile-методології, важливим елементом спринта та спрямована на поліпшення процесу. В сьогоднішній статті ми наведем кілька корисних порад щодо її проведення...

Subscribe to our blog updates