Обща сума
Всеки знае, че сроковете, дадени от програмистите, трябва да се умножат по две. Хитрите мениджъри на проекти също добавят - "и вземете стойността на следващата поръчка". Тези. когато програмистът оцени необходимото време на един час, ние записваме два дни в плана. Но за клиентите (както външни, така и вътрешни) тази ситуация изглежда поне странна - оказва се, че нашите почти блестящи разработчици, които са в състояние да решават най-сложните задачи, не са в състояние да добавят две и две и да съставят дори прост план. как става това Нека да видим защо програмистите правят грешки при изчисляването на крайните срокове.
Времето е чисто и времето е мръсно
производителност
Отделен момент е въпросът за изпълнението. Когато оценяват, програмистите обикновено изхождат от отлично здраве, висока ефективност и не правят резерви за неочакваното „нещо не е сготвено днес“ и „да, понеделник е труден ден. ". Но тези явления не изчезват от реалността и ВНЕЗАПНО една типична задача отнема два пъти повече време от обикновено.
Проучване
Това е може би най-ужасното нещо за времето. Изглежда така: програмистът оценява задачата на три часа, работи усилено и завършва едва след осем. На въпроса "Защо?!" обяснява, че в процеса се появи алтернативно и много обещаващо решение, за което отне много време, за да се обмисли. Но, за съжаление, това решение не се вписа, в крайна сметка трябваше да го направя, както първоначално беше планирано.
Какво може да се каже тук? Проучването на опции е не само зло, но и добро. Въпреки цялата непредвидимост на този процес, той може да даде много интересни и дори пробивни решения. Но може и да не е, разбира се.
Специален случай на изследването са "наръчниците за пушене". Нека отделим това в отделен параграф, така чекак при изучаване на документация разработчикът често открива много нови и интересни неща; внезапно се оказва, че последните актуализации ви позволяват да правите неща, които не сте могли да правите преди, така че в добър смисъл си струва да пренапишете всичко напълно. И в особено трудни случаи процесът на пренаписване започва отново без предварително споразумение, с всички последствия.
Комплексни системи
Не забравяйте да споменете спецификата на планирането на работата в сложни системи. Тук оценката често се разминава с реалността именно поради сложната взаимовръзка на елементите на системата. Например, задава се проста задача - да се промени редът на сортиране на елементите в определен раздел. Системата има стандартен инструмент за това, а програмистът оценява работата като много проста. Целият бизнес - приоритет, за пет минути работа. Но когато влезе в дадена секция, той установява, че всички елементи там са свързани с други секции и техният ред на сортиране се определя не от техните приоритети, а от голям брой свойства в други секции. И за да решите тази "проста" задача, трябва да пренапишете половината от логиката на системата.
Корекция на грешка
Клиентът обикновено вярва, че добрият програмист е програмистът, който не прави грешки. От своя страна програмистите често не планират време за коригиране на грешки, защото това автоматично би означавало „планиране за грешки“. И кой планира предварително, че ще коси?
Въпреки това, докато хората пишат код, грешките са неизбежни. От прости печатни грешки до сложни случаи на непълна съвместимост на нови решения със стари. И колкото по-сложна е системата, толкова по-сложни могат да бъдат получените грешки. Това означава, че времето за коригирането им може доста да надвиши времето, изразходвано за действителното разработване.
Съставни и нестандартни задачи
Планирамвремето за изпълнение на сложни или нетипични задачи е доста просто. Можете да посочите всеки термин и да знаете със сигурност, че той със сигурност ще бъде грешен в една или друга посока.
Снетипичните задачи всичко е ясно: ако подобна задача все още не е изпълнена и от коя страна да се подходи към нея, все още не е ясно, тогава оценката на програмиста ще зависи само от неговото ниво на самочувствие. Човек, който се смята за гений, ще каже, че ще го направи за няколко дни (в съзнанието му това е крайният срок за най-трудните задачи), човек, който не е сигурен за същата задача, ще поиска три седмици, „така че с марж“. В същото време, без предварително подробно проучване, и двамата не планират, а гадаят, а реалният срок може да се окаже абсолютно всичко.
Повече или по-малко точна оценка може да се даде след предварително проучване на проблема, което само по себе си отнема време. Тези. когато възникнат нови задачи, "нямащи аналози", е необходимо не да се изисква от програмиста бърза и точна оценка на сроковете, а да се постави предварителна задача "да се извърши оценка".
Композитните задачи (състоящи се от редица свързани подзадачи) също често объркват програмистите - всяка от подзадачите може да бъде свързана с някоя от горните опции за загуба на време (или всички наведнъж), така че пълното несъответствие между реалното време и прогнозата може да достигне космически мащаби.
Възможно е повече или по-малко да се доближи оценката на съставна задача до реалността само ако всяка от подзадачите се оценява отделно и общото време вече се изчислява като тяхната сума, със съответните „добавки“ както за всяка задача, така и за окончателното им свързване.
номинално налягане
Нашият списък с причини за неправилна оценка на времето би бил непълен, ако не споменем такова прекрасно явление като „Клиентски натиск“. Това е ситуацията, когато клиентът(вътрешен или външен) по един или друг начин влияе върху оценката. Например, той дава да се разбере, че иска да чуе оптимистичното „Утре ще бъде готово!“, Е, или нещо подобно.
В тази ситуация програмистът има две възможности. Първото е да упорстваш и да защитиш по-адекватна оценка. Второто е умишлено да посочите термина по-малко от необходимото, като се мотивирате, че е по-лесно да обясните по-късно защо нямате време, отколкото да си блъскате главите дълго време, разстройвайки клиента и го карайки да се съмнява в професионализма на изпълнителя. Тоест в случая се дава неправилна оценка не поради грешка, а умишлено, под влияние на очакванията на клиента.
Общо
Първо : Оценката на програмист без специални "коригиращи фактори" може наистина да бъде много неточна.
Второ : в това няма никакво злонамерено намерение или доказателство за "непълноценност на времето" - обичайните черти на човешката психология, а програмистите в крайна сметка също са хора.
Трето : да, първоначалната оценка на времето на програмиста трябва да се третира сдържано, без да се счита за ангажимент, издълбан в гранит. Тази оценка може да бъде включена в плана, за да получите причина да копаете в мозъка на програмиста по-късно (ако се интересувате от такова забавление), но всъщност се фокусирайте върху по-дълъг период.
Авторът говори за причините за неспазването на сроковете. И ние (редакторите) можем да ви кажем колко актуален е този проблем. Според проучване на CMS Magazine от няколко години насам крайните срокове са пропуснати в почти 40% от случаите!
Искате да намалите риска? Обърнете се към проверени студия. Например на участниците в рейтинга на уеб студията.
Познайте колко сайта изучаваме всяка година, за да съставим този рейтинг? Десетки хиляди. Освен това се разглеждат повече от четири произведенияхиляди уеб студия в Беларус, Украйна и, разбира се, България. И всичко за вас!