Как да стартирате ИТ проект навреме: опитът на ръководител на проекти

Определяне на основните характеристики на продукта

Преди да започнете работа по даден проект и да поставите срокове за изпълнението му, препоръчвам да прочетете внимателно техническото задание и да подчертаете онези функции, без които продуктът не може да работи.

Например интегрирането на платежни системи в онлайн магазин. Създайте набор от такива функции и започнете разработката от тях. Допълнителна функционалност, която може да бъде изоставена в началния етап, се финализира след внедряването на основните функции.

Защо е необходимо това?

Могат да се случат различни непредвидени обстоятелства както от страна на клиента, така и от страна на екипа за разработка. Например, клиентът координира дизайна дълго време и графикът на разработката се измести. В този случай доставката на проекта навреме е изложена на риск.

За да се достави работещ продукт, който вече може да бъде пуснат на пазара, основните характеристики трябва да бъдат внедрени първо, а допълнителните могат да бъдат внедрени дори след стартирането. Тази стратегия е оптимална както за клиента, така и за екипа: проектът се доставя точно навреме, а допълнителната функционалност се финализира в оставащото време.

Нека ви дам пример от скорошна практика. Създадохме вътрешен проект – парсер от сайтове до определена дата. Беше необходимо да се разработи агрегатор, който с помощта на анализатор събира необходимата информация от четири сайта наведнъж. Но разработването им наведнъж за всички сайтове беше доста трудоемко и отнема много време — нямаше да спазим крайния срок.

Тогава решихме да отделим един сайт, най-важен за клиента, и да направим парсер само за него. Освен това разработихме цялата функционалност за обработка на данни, като взехме предвид бъдещите парсери и стартирахме агрегатора само с един сайт.

Получихме напълно работещ продукт, който вече може да се използва пълноценно. Въведохме останалите три парсера в работа постепенно: за две седмици внедрихме и въведохме втория, след това третия.

За да получим желаната функционалност, не се наложи да чакаме допълнително един или два месеца.

Оценка на времето за създаване на проекта

Един от най-трудните етапи на създаване на продукт е оценката на времето. За да завършите цялата работа в сроковете, е необходимо предварително да прецените правилно времето, необходимо за изпълнението им.

В моите проекти прилагам тристепенна система за прогнозиране на сроковете:

първо, разработчикът оценява задачата, измервайки я в часове работа;
след това се оценява от друг програмист, за да се избегне субективизъм;
в крайна сметка оценявам периода на работа, добавяйки още 20-30% към полученото време.

Защо да добавяте допълнително време за разработка?

Дори ако програмистът спазва крайните срокове и знам, че работата ще бъде доставена навреме, никога не трябва да изключвате възможни форсмажорни ситуации. Може да е всичко – от документация до спиране на тока в офиса. Допълнителното време намалява риска от закъснение на сроковете.

Ако няма отрицателни обстоятелства и работата е завършена по-рано, тогава клиентът развива положителен имидж на компанията и повишава лоялността към изпълнителя.

Контрол на екипа за разработка

Разпределям контрола на развойния екип, дизайнерите и други специалисти в зависимост от продължителността на проекта.

При проекти с кратък период на развитие :

Практикувам ежедневни разговори с членове на екипа буквално за три до пет минути.

Това е достатъчно, за да разберете ситуацията и да разберете на какъв етап е задачата. В допълнение, това е начин да поддържате комуникация и да разберете в какво състояние е служителят , тъй като никой не е отменил човешкия фактор на работа.

За проекти с по-дълги срокове за изпълнение :

повикванията се правят по-рядко. Достатъчно веднъж или два пъти седмично. Останалото се решава чрез кореспонденция.

Но това не премахва необходимостта по-често да се интересувате от напредъка на работата, състоянието на служителя. Ежедневното наблюдение е много важно, тъй като пряко влияе върху спазването на крайните срокове.

Ще дам пример от личен опит. На един от проектите разработчикът трябваше да изпълни задачата за осем часа, тоест за един работен ден. Работата не е завършена до крайния срок.

На въпросите ми защо се е случило това, разработчикът отговори, че не може да разбере документацията. Изпратих го при техническия ръководител, който му обясни неразбираемите моменти и разработчикът бързо реши проблема.

Този случай ме научи да се интересувам преди крайния срок дали всичко е ясно, дали има някакви затруднения. Тъй като не всеки разработчик е готов да сподели проблемите си поради ситуацията или чертите на характера.

Между другото, в този пример беше полезен друг принцип – полагане на допълнително време. Поради факта, че имахме наличност от часовници, спазихме срока и не подведохме клиента.

Също така се случва програмист, особено външен програмист, да не може да продължи да изпълнява задачите си поради различни обстоятелства. В този случай препоръчвам „да запазите в резерв“ поне един такъв специалист, който в случай на непреодолима сила ще може бързо да се присъедини към проекта.

Това е и начин за намаляване на риска от пропуснати срокове.

Диаграма на Гант

Този метод е оптимален, защото ясно показва на какъв етап се изпълняват задачите. Възможно е обаче не винаги да е подходящо: например за вече готови проекти понякога е просто нерентабилно да се изгради такава диаграма.

Разбивам проекта на определени задачи, след което поставям срокове и проследявам напредъка по задачите.

Пример за използване на диаграма на Гант в един от моите проекти

Преговори с клиента

За да не пропускам срокове и да предам проекта в определения срок, отделям отделно време от работното време за съгласуване и преговори с клиента.

Защо е важно?

Клиентите са различни. Някой бързо одобрява резултата, докато някой мисли по-дълго. Ако не отделите отделно време за преговори и одобрение, ще трябва да отделите време от работното време на специалиста. А това означава, че ще има по-малко време за изпълнение на задачите и рискът от надсрочване на срока е по-висок.

Ще дам абстрактен пример. Дизайнерът има 15 часа работа. Дизайнерът свърши работата за 13 часа и направи презентация за клиента за четири часа. Клиентът одобри оформленията за още осем часа.

Оказва се – 12 часа забавяне на срока. И това означава, че дизайнерът на оформлението ще започне работата си по-късно, програмистите ще се забавят. В резултат на това съществува риск от забавяне на крайния срок на проекта и нарушаване на сроковете.

Затова препоръчвам да отделите време отделно за преговори и дискусии с клиента, а не само за дизайнерите. Клиентът може да комуникира директно със специалиста, това е нормална практика. Но според мен трябва да има отделно време за одобрение на резултата.

Заключение

В заключение на статията ще подчертая три основни тези , които трябва да се спазват:

Отделете важното от маловажното. Няма смисъл да се внедрява вторична функционалност, ако основната не е готова. Така че има риск да не предоставим на клиента готов проект до края на срока.
Позволете допълнително време за разработка. Това ще служи като един вид „застраховка“ срещу непредвидени обстоятелства.
Управлявайте внимателно задачите. Опитайте различни техники и методи за проследяване на ситуацията, така че проектът да бъде доставен навреме.