Блог на Калин Василев

Едно от основните задължения на ръководител проекта е контролът върху бюджета. След като се планирали и оценили внимателно бюджета, сега вашето внимание трябва да е насочено към следене на цифрите, за да сте сигурни, че реалните разходи ще съответстват на предвидените в бюджета на проекта. Доста е трудно да се прогнозира с абсолютна точност какви ще са бъдещите разходи. Но основата цел и задача от която трябва да се ръководите е да задържите проекта и разходите по него в определеният предварително лимит. В противен случай рискувате да си довлечете на главата доста упреци и ще се наложи да дадете доста обяснения пред висшите ръководни кадри за допълнителните разходи.
Когато наблюдавате реалните разходи спрямо планираните, внимавайте за “подводни камъни” , които могат да объркат плановете ви и които ще увеличат несъмнено разходите ви.
Липсата на твърдо договорени цени с доставчици и подизпълнители и непланирани разходи за персонал, с които осигурявате спазването на графика (тук се включват и допълнителните изработени часове) са от основните елементи, които могат да ви донесат допълнително разходи. Непредвидените разходи за обучение, неочаквани разходи за допълнителна техника, софтуер, наличие на консултантски такси и т.н. са неща с които трябва да се съобразите, ако искате да не индексирате допълнителни, непредвидени разходи.
Повечето от тези разходи за проекта не са в състояние да се предвидят в началото на всеки проект. Затова винаги бъдете внимателни към истинските цифри, когато те започнат да “идват” към вас. Особено некомфортно ще се получи, ако отчетете големи разлики с това какво сте предвидили в бюджета и това какво реално ви трябва като финансов ресурс. Ако се стигне до това, внимателно анализирайте всяка една операция и открийте къде е причината за тях.
Но не винаги новините свързани с бюджета са лоши :) Когато сравнявате предварително определените разходи с реалните, може да отките някой окуражителни аспекти. Някои елементи, които допринасят за запазване на разходите под лимита са:
- капиталовите разходи са по-малки
- лихвените проценти са по-ниски
- персонала се редуцира
Несъмнено като ръководител на проект пред Вас ще стой основната задача за качеството на проекта. Това качество пряко влияе върху неговият успех. Последното нещо, от което се нуждаете е недоволен от крайните резултати клиент или друг заинтересован участник в проекта.
Тук ще си позволя да ви изброя няколко елемента, които ще ви помогнат да постигнете високи резултати:
1. Не претрупвайте проверките на качеството, само и само за да спазите крайният срок. Обикновено разходите за коригиране на един проблем са много по-големи, отколкото за ефективното му разрешаване.
2. Определете стандартите за качество във фазата на планирането. Задължително вземете предвид критериите за качество на фирмата – вътрешно-фирмените стандарти, изискванията на заинтересованите участници, обхвата на проекта и наличието на външни изисквания.
3. Отделете внимание на това как се доставят документите, каква информация дават проверките, списъците или анализите на отделните етапи от разработването на проекта.
4. Определете предварителни показатели на които трябва да отговаря проекта, за да се счита за успешен. Доставените и генерирани документи, които не отговарят на стандартите за качество, ги върнете за ревю от автора или може да ги оставите за преработка, но това само в зависимост от стойността и приоритета им.
Винаги уведомявайте и информирайте заинтересованите участници за развитието на проекта. Договорете се още във фазата на планирането кога и как да предоставяте докладите си.
Изградете добре работеща система за комуникация с всички заинтересовани страни. Като цяла възложителите на проекта искат постоянно да правят корекции по първоначално зададената задача, както и доклади за състоянието и развитието на проекта. Разберете какво очакват те от вас и ги информирайте периодично докъде е стигнала работата. Когато проекта набере скорост , консултирайте се с тях, за да видите какво смятат те за изпълнението на проекта и дали считат предоставената информация за достатъчна.
Придържането ви към критичния път ще ви бъде по-лек, ако на главата ви не “висят” недоволни клиенти, които искат непрекъснато нова и все по-нова информация.
Не забравяйте, че честността винаги е похвална, затова бъдете честни с тях. Не крийте проблемите и не ги омаловажавайте. В противен случай те лесно могат да се превърнат във ваш противник и да доведат до криза в проекта, отколкото ако на време сте уведомили заинтересованите участници. В случай, че са били информирани за целият жизнен път на проекта до момента, те биха могли да предложат помощта си за справяне с проблема.

Колко съм горд от себе си, че приобщихме към блогърското братство един заклед не-блогър до момента. Говоря за моя колега и приятел – Михаил Кочанов. Колкото и да отрича и да не признава, той сам си кодна блог, хвърли пот и усилия да си го направи сам и почна да пише във него.
Браво, Мишо, радвам се, че отхвърли задръжките си, които таеше за блогърите и стана един от нас. Въпреки, че казваш, че не обичаш хората, които пишат по блогове…ти стана част от нас.
Радвам се за теб и че прие вярната стъпка в промоцирането си в Интернет. Да се надяваме, че скоро ще променя и мнението ти за SEO-то :)
За да се запознаете с Михаил Кочанов, може да посетите блога му на адрес – www.sietch.net.

Последно време интернет пространството се бълва от глупостите на една софтуерна компания, която е спечелила поръчката за създаване на сайта на детските градини в София. Става въпрос за прословутата Сирма груп.
Според официалното обръщение на фирмата, проблема със сайта е причинен от хакерски атаки. Между 9:00 ч. и 12:00 към сайта имало множество нерегламентирани заявки – около 90% от общо направените.
Всеки един от Вас е слушал за обяснението на Сирма за проблема…ето го и моето виждане, като човек занимаващ се с осигуряване на качеството на софтуерните разработки.

Първо да цитирам два абзаца от самото задание, с което е зададен проекта за изпълнение от Община София.

“Индустриални стандарти. При проектирането и изграждането на приложението да се използват и поддържат индустриалните стандарти и най-добрите практики, както и Интернет стандартите HTML, XML, HTTP, JDBC, SQLJ, JAVA(TM), Web Server Definition Language (WSDL), Universal Discovery Description and Integration (UDDI), и Simple Object Access Protocol (SOAP), BPEL, SOA”

“Тест процедури
Системата да мине през следните етапи на тестването:
- Прецизиране на Плана за тестване и Test case
- Тест за отделните елементи
- Тест на модулите
- Интеграционни тестове
- Тест за предварително приемане
- Тестване на пилотната система
- Тестване на системата
- Тестване при приемане на системата”

Да обърнем внимание на първия цитат, в който се упоменава на кои технологии да се наблегне при създаването на системата. Изискването по моето скромно знание е да се използват JAVA технологии.
Системата изработена от Сирма е чисто PHP, написано чрез помощта на Zend studio технология. Така показваше инфото на сървъра, което беше налично за преглед в деня на пускане на сървъра.
Малко да поразсъжваме…PHP е идеален език за програмиране на уеб сайтове и леки по натовареност портали. Сравнение между JAVA и PHP от гледна точка на сигурност не може и да става дума. Джавата е доста пъти по-сигурна и приложенията писани на нея издържат на голямо натоварване.
Тук е редно да си зададем само един въпрос: Защо след като от Възложителят е имало изискване да се използва JAVA технология за направата на системата от Сирма са предпочели PHP ?

Вярно става по-бързо, но и по-несигурно при натоварване. Аз не съм програмист, поне вече не :) , че да давам повече коментари за това. Има хора, които са по-кадърни и ще го направят.
Относно втория цитат за процесите на тестване. Няколко пъти представители от Сирма в телевизионен ефир споменават, че са провели тестове за натоварване (Load testing) на системата. Къде това е описано в документацията ? Къде става дума за тестове на натоварване?
Аз не виждам такова нещо. Това е недопустимо, една система да не мине през Load и Stress тестове, за да се изследва нейното състояние при екстремални условия. Разбира се, Сирма са извършили тези тестове…но на приказки. Никъде в документацията не присъстват тези род тестове…колкото и да я четох не можах да ги намеря. Задължително е било да проведат и performance тестове на сървъра, за да се определи при какво натоварване той ще гръмне.
Но не…от Сирма всички отдават на хакерски атаки. Много ви се моля…ние може да ядем зелена салата, ама не пасем трева! Това, че за Вас се поява идеалния вариант да се измъкнете от ситуацията като обвините, т.н. ХАКЕРИ. Искате да кажете, че всеки един гражданин на страната е хакер!
Още един ваш пропуск е липсата на добавена функционалност за уникалност на потребителите. След като очаквате такъв голям брой регистрации, защо беше нужно да позволявате повече от една регистрация на ЕГН. Това щеше да ви реши много проблеми и ненужна обработка на информацията.
Трябваше да предвидите такъв наплив и голям брой заявки, отправени към системата, защото за този сайт се говори от една седмица…очакваше се голям брой посещения. Но вие решихте да си измиете ръцете и всички тези заявки да ги отдадете на хакерска атака. За какво им е на хакерите да нападат сайт за регистрация на деца в детски градини ???
Изправете се гордо и признайте грешката си. Грешка, която ако признаете ще се приеме по-добре, отколкото целият ИТ бранш да ви се смее с тези “хакерски атаки”.

Стартирането на проекта е първата фаза в неговото изпълнение. Повечето ръководите приветстват това, защото е знак за че голяма част от документалната и същинска работа е приключила и вече започва изпълнението на проекта. Работи се в положителен аспект и нещата вървят напред.

След като вече сте започнали с изпълнението на проекта се уверете, че се придържате към критичния път, дори и на моменти да изглежда, че не е най-правилния. Запомнете, че критичният път представлява най-краткото разстояние между началната и крайна дата на всеки един проект. Също така не забравяйте, че той е гъвкав и дава доста възможности за съкращаване на това “разстояние”. Много ръководители, “стъпили” на критичния път се отнасят като единствения възможен изход, без да съобразяват че той може да подлежи на промяна.

Бъдете готови за възлагате и поемате отговорности! Планирайте предварително задачите или огранизирайте ресурсите си. За вас най-добрият възможен изход е да изберете най-ефективният начин за постигане на бизнес целите. Част от този процес можете да го извършите като съберете всички членове на екипа и разпределите отговорностите. Не трябва да ви притеснява и факта, че когато проекта стартира ще имате нужда да делигирате повече задачи на някои от членовете на екипа. Бъдете винаги гъвкави и готови да прехвърлите задълженията и част от работата на друг член от екипа. Но въпреки това, не забравяйте, че цялата отговорност за проекта е ваша.
Първо определете кои задачи искате да разпределите, като важно е да разберете и оцените какви умения и способности изисква всяка една от тях. След което намерете за всяка една задача, кой е най-точния изпълнител на задачата.
Като разпределите и дадете на всеки член задачка, то тогава се отдръпнете и оставете вашите хора да работят.
Следете развитието на проекта! Не съществува универсална система за мониторинг на проекта. Тези, които са отлични за големи проекти, могат доста да затормозят по-малките с документация, докато в обратния случай нямат да носят необходимата тежест.
В зависимост от размера и сложността на проекта можете да използвате система, разработена от самия вас. Чрез нея вие влагате своя опит и получени знания през времето.
Съсредоточете се върху най-важното! Не поемайте прекалено дълго дадена задача, която да заема вашето внимание (Майк Рам добре е написал какви грешки, могат да допуснат младите ръководител проекти, с не голям опит зад гърба си). Когато се окажете прекалено затрупани от детайли в проекта, лесно можете да се отклоните от критичния път. Затова трябва да си зададете следните въпроси:
- Какво е важно за проекта ?
- Каква фактически се опитваме да направим ?
- Кои част и етапи на проекта са най-важни, за да бъдат сложени под контрол ?
За да има полза от вашите действия, то вие трябва да получавате в достатъчно кратки срокове обратна връзка.
Оставете си “вратичка” за направата на корекции! Трябва да се отнасяте с нужното внимание към промените в данните или информацията. Бъдете нащрек за възникването на ранни проблеми и бъдете готов да предприемете коригиращи действия. Ако не го правите, то вие просто участвате като наблюдател на проекта, а не го управлявате. Но тук има и друг момент. Прекалената ви бърза намеса няма да позволи на членовете на екипа ви да поемат отговорност и решения при неговото решаване. Дайте им възможност да се справят самички.