Разом
Усім відомо, що терміни, названі програмістами, потрібно множити на два. Вузькі проджект-менеджери ще додають - «і брати значення наступного порядку». Тобто. Оцінюючи програмістом потрібного часу одну годину, у план пишемо два дні. Але для замовників (як зовнішніх, так і внутрішніх) така ситуація виглядає як мінімум дивною — виходить, що наші майже геніальні розробники, здатні вирішувати найскладніші завдання, не в змозі скласти два і два, і скласти навіть простого плану. Як таке виходить? Давайте розберемося, чому програмісти помиляються щодо оцінки термінів.
Час чистий та час брудний
Продуктивність
Окремим пунктом іде питання продуктивності. Оцінюючи програмісти зазвичай виходять із класного самопочуття, високої працездатності, і роблять знижок на несподіване «щось сьогодні калган не варить» і «так, понеділок день важкий. ». Але з реальності ці явища нікуди не подіються, і раптово на типове завдання йде вдвічі більше часу, ніж зазвичай.
Дослідження
Це, мабуть, найстрашніша для термінів справа. Виглядає воно так: програміст оцінює завдання о третій годині, напружено працює і закінчує лише за вісім. На запитання «Чому?!» пояснює, що у процесі виникло альтернативне і дуже перспективне рішення, і на його розгляд пішла купа часу. Але, на жаль, це рішення не підійшло, зрештою робити довелося так, як планувалося спочатку.
Що тут можна сказати? Дослідження варіантів – не лише зло, а й добро. Попри всю непередбачуваність цього процесу, може давати дуже цікаві, і навіть проривні рішення. Але може й не давати, звісно.
Окремим випадком дослідження є «паління мануалів». Виділяємо це у самостійний пункт, такяк при вивченні документації розробник часто відкриває для себе багато нового та цікавого; Несподівано з'ясовується, що останні оновлення дозволяють робити так, як раніше робити не можна було, тому по-хорошому варто все взагалі переписати заново. І, в особливо важких випадках, процес переписування знову починається без попереднього узгодження, з усіма витікаючими.
Складні системи
Обов'язково варто згадати специфіку планування робіт у складних системах. Тут оцінка часто розходиться з реальністю саме через складні взаємозв'язки елементів системи. Наприклад, ставиться просте завдання – змінити порядок сортування елементів у певному розділі. У системі для цього є штатний інструмент, і програміст оцінює роботу як дуже просту. Усіх діл — пріоритети розставити на п'ять хвилин роботи. Але, увійшовши розділ, він виявляє, що це елементи пов'язані коїться з іншими розділами і порядок їх сортування визначається їх пріоритетами, а великою кількістю властивостей за іншими розділах. І щоб вирішити це «просте» завдання, потрібно переписати половину логіки системи.
Виправлення помилок
Замовник зазвичай вважає, що хороший програміст — це програміст, який робить помилок. Зі свого боку і програмісти часто не планують часу на виправлення помилок, адже це автоматично означало б і «планування помилок». А хто ж заздалегідь планує, що він косячить?
Однак, поки код пишуть люди, помилки неминучі. Від простих друкарських помилок, до складних випадків неповної сумісності нових рішень зі старими. І чим складніша система, тим витонченішими можуть бути помилки, що виникають. Отже, час на їх виправлення цілком може перевищувати час, витрачений на власне розробку.
Складові та нетипові завдання
Плануватичас виконання складових чи нетипових завдань досить просто. Можна називати будь-який термін і точно знати, що він, напевно, буде помилковим, у той чи інший бік.
З нетиповими завданнями все зрозуміло: якщо подібне завдання ще не виконувалася, і з якого боку до нього підійти — поки неясно, то програмістська оцінка залежатиме лише від його рівня самовпевненості. Вважаючи себе генієм скаже, що зробить кілька днів (у його уявленні це граничний термін для найскладніших завдань), людина невпевнений той самий завдання попросить тижнів зо три, «щоб із запасом». При цьому без попереднього детального вивчення обидва не планують, а ворожать, і реальний термін може бути абсолютно будь-яким.
Більш-менш точна оцінка може бути дана після попереднього дослідження завдання, яке саме потребує часу. Тобто. при виникненні завдань нових, які не мають аналогів, потрібно не вимагати від програміста швидкої і точної оцінки термінів, а ставити попереднє завдання провести оцінку.
Складові завдання (що складаються з деякого числа пов'язаних підзавдань) теж часто плутають програмістів — з кожним із підзавдань можуть бути пов'язані будь-які варіанти втрати часу з наведених вище (або всі відразу), тому в сумі розбіжність реального терміну з прогнозом може досягати космічних масштабів.
Більш-менш наблизити оцінку складеного завдання до реальності можна, тільки якщо оцінити окремо кожну з підзадач, а підсумковий час розраховувати вже як їхню суму, з відповідними «добавками» як на кожне завдання, так і на їхнє підсумкове сполучення.
Оцінка під тиском
Наш список причин некоректної оцінки часу буде неповним без згадки про таке чудове явище як «Клієнтський тиск». Це ситуація, коли замовник(Внутрішній або зовнішній) так чи інакше впливає на оцінку. Наприклад, дає зрозуміти, що хоче почути оптимістичне «Завтра буде готове!», ну чи щось на кшталт цього.
У цій ситуації програміст має два варіанти дій. Перший — виявляти завзятість та відстоювати більш адекватну оцінку. Другий — свідомо назвати термін меншим за потрібне, розсудивши, що простіше потім пояснити, чому не встигаєш, чим зараз довго бадитися, засмучуючи клієнта і змушуючи його засумніватися у професіоналізмі виконавця. Тобто в цьому випадку неправильна оцінка дається не через помилку, а свідомо під впливом клієнтських очікувань.
Разом
Перше : програмістська оцінка без застосування спеціальних «поправочних коефіцієнтів» справді може виявитися дуже неточною.
Друге : у цьому немає злого наміру чи свідчень «тайм-неповноцінності» — звичайні особливості людської психології, а програмісти, таки, теж люди.
Третє : таки так, до початкової програмістської оцінки часу слід ставитися стримано, крім її висіченим у граніті зобов'язанням. Цю оцінку можна внести до плану, щоб отримати привід потім покапати програмісту на мізки (якщо вас цікавлять такі розваги), але насправді орієнтуватися на більший термін.
Автор розповідає про причини зриву термінів. А ми (редакція) можемо вам розповісти про те, наскільки актуальною є ця проблема. Згідно з дослідженнями CMS Magazine, ось уже кілька років проліт повз дедлайн відбувається майже в 40% випадків!
Бажаєте знизити ризики? Звертайтеся до перевірених студій. Наприклад, до учасників рейтингу веб-студій.
Відгадайте, скільки сайтів ми щорічно вивчаємо, щоб скласти цей рейтинг? Десятки тисяч. Причому розглядаються роботи понад чотиритисяч веб-студій Білорусі, України та, природно, України. І все для вас!