Как заказчику правильно контролировать выполнение IT проекта

В этой статье я решил поговорить о том, как руководителю проекта или заказчику контролировать проект IT таким образом, чтобы он завершился успешно. Я расскажу о 5 важных вещах, от которых успех проекта зависит напрямую, а также о том, на что нередко обращают внимание, но на самом деле, на успешную реализацию это влияет незначительно.

1. Четкие сроки

Казалось бы, это правило очевидно. Но на самом деле, есть очень большая разница между двумя подходами:

1. Сроки определяются ориентировочно, по принципу «от и до».
2. Соки указываются на основе предварительных расчетов и оценки необходимого времени.

Лично я предпочитаю указывать сроки в рабочих днях. Причем, для каждой задачи срок указывается отдельно, по принципу:

«Название задачи» - от 20 до 30 рабочих дней.

Иногда при таких расчетах люди совершают ошибку, и указывают жестко определенную дату. С одной стороны, такая необходимость может возникнуть, с другой, в IT-проекте очень многое зависит от технологий. И, как в любом высокотехнологичном проекте, предусмотреть заранее все, невозможно. Именно по этой причине лучше предусмотреть какой-то лаг. Быстрее справится команда – прекрасно, нет – на непредвиденные случаи есть заложенный в проекте запас времени.

Нередко разработчики прибегают при планировании к гибкой методологии Agile. Но выглядит это следующим образом:

1. Проект разбивают на определенные этапы. 
2. Четкие сроки устанавливаются для первого этапа.
3. Начало и финал каждого последующего определяют по окончании предыдущего этапа. 

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

Проверка: верны ли расчеты

Для того чтобы проверить, правильно ли рассчитаны сроки, проще всего использовать метод подсчета, основанный на человеко-часах.

Так, при расчете проекта нужно отдельно оценить:

• Часы работы программиста;
• Часы работы консультанта;
• Часы работы руководителя проекта и т.д.

Работу каждого из участников проекта вы рассчитываете отдельно, основываясь на понимании, сколько времени в часах она может занять. 

Далее работу каждого из специалистов нужно пересчитать в рабочие дни. При этом учитывайте, сколько часов в день специалист будет уделять этому проекту. 

Так, если программисту требуется 30 человеко-часов, а работать он будет по 3-4 часа в день, то стоит заложить на его работу 10 рабочих дней.

Потом туда же можно заложить работу, например, консультанта, пересчитав ее аналогично. Но здесь очень важно понимать, что разные специалисты не всегда работают одновременно.

Допустим, что консультант также будет работать 3 часа в день, и ему нужно будет в итоге 3 рабочих дня. Но подключить его к проекту возможно будет не раньше, чем на 9-й день. Соответственно, сроки проекта сдвигаются. И уже получается, что на работу программиста и консультанта нужно не менее 12 дней. Аналогично выполняются расчеты для руководителя проекта и других специалистов.

Большим плюсом будет, если вы, как заказчик, получите такую расшифровку, по необходимости, сопровождаемую пояснениями. Это значит, что сроки действительно рассчитывались разумно. А если к этой расшифровке будут еще и прилагаться цены человеко-часов каждого специалиста, то такой расчет будет одновременно обоснованием цены и сроков работы, а также подтверждением, что планирование было выполнено грамотно и профессионально.

О том, как рассчитывается стоимость проекта, я уже писал в статье “Внедрение программного продукта. Особенности работы бизнес-консультанта”.

2. Использование графики

Здесь речь идет о том, что при планировании проекта должно быть, как можно меньше текста, как можно больше графики. В идеале, уже в самом начале стоит использовать какие-то прототипы, хотя на практике это не всегда возможно. 

Как минимум, нужно изобразить сам процесс в виде диаграммы, например, в формате BPMN или IDEF0. Причина такого подхода проста и основана на известной фразе: «Одна картинка стоит тысячи слов».

Чтобы понять, почему это важно, давайте представим ситуацию. В обсуждении и утверждении проекта участвует несколько человек. Текстовое описание проекта занимает 2-3 страницы. А графическая диаграмма показывает все этапы наглядно на одной странице. В каком из случаев вы быстрее получите обратную связь? Я думаю, в случае графической схемы.

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

Например, если схема слишком большая, значит, где-то детализация излишняя. Если слишком маленькая, скорей всего, какие-то этапы пропущены или не детализируются по каким-то другим причинам. 

Все это в будущем может привести к проблемам в реализации проекта. И схема показывает такие нюансы наглядно. В то время, как в тексте очень многие ошибки и нюансы легко спрятать за множеством слов.

Проверка использования графики

Этот этап не должен вызвать сложностей. Если к описанию проекта прилагаются диаграммы, например, в стандарте BPMN, IDEF0 или IDEF3, значит, все в порядке.

Почему я так рекомендую именно эти стандарты?

Самое главное: если вы знаете, в каком стандарте выполнена диаграмма, вы легко проверите, насколько она правильно составлена. 

Нередко диаграммы составляют в произвольных графических редакторах по принципу “я художник, я так вижу”. В результате графика получается часто яркой, но еще чаще, запутанной и сложной для прочтения.

При выборе одного из стандартов, диаграмма будет легко читаться, соответствовать определенным правилам. Уже на этапе ее составления многие ошибки выявляются и исправляются. Также ее легко проверить, чтобы убедиться, что она не содержит ошибок.

Потому, повторюсь. При проверке нужно убедиться, что графические диаграммы имеются, и выполнены они согласно определенным стандартам: BPMN, IDEF0 или IDEF3. Что важно, стандарты должны применяться отдельно. Либо выбирается какой-то один, либо для разных диаграмм, описывающих разные этапы и детализацию работы, выбирают стандарт, наиболее подходящий для этого описания.

3. GAP анализ

Для того, чтобы планировать работу над проектом, необходим список задач. И GAP анализ поможет такой перечень составить.

Например, вы изучили ситуацию и составили описание «As Is», т.е. то, что имеется в данный момент. Вы понимаете, что именно вам нужно, и составляете описание «To Be», т.е. то, что вы хотите в результате получить. По возможности здесь я также рекомендую использовать графические модели, так как сравнивать их намного проще, чем текст.

И теперь вы можете увидеть, что есть в модели «To Be», но отсутствует в «As Is».

Например, у вас есть сайт и учетная система. Сейчас они работают отдельно друг от друга. В желаемом результате будет реализована интеграция.

Вы видите: в модели «As Is» интеграции нет, в модели «To Be» - есть. В список задач добавляется пункт «Выполнить интеграцию сайта и учетной системы». И так вы сравниваете пункт за пунктом, добавляя нужные задачи в список.

Вы не знаете, причем тут GAP анализ? Но ведь именно им вы и занимаетесь в такой ситуации. Сравниваете две модели и выполняете анализ разрывов.

Проверка GAP анализа

Документ, на основе которого согласовывается проект, может иметь разные названия, я предпочитаю “Предпроектное обследование”. Но как бы его ни назвали, структура должна быть примерно такой:

• В начале - поставленные задачи, выявленные проблемы.
• Далее - текстовое описание того, как должно быть.
• В конце - список задач, которые необходимо выполнить, чтобы из состояния “как есть”, получить описанное в документе “как должно быть”.

Например, этот список может выглядеть так:

1. Разработать модуль расчета заработной платы.
2. Разработать и внедрить интеграцию с сайтом.
3. Создать печатные формы документов и т.д.

Если список задач составлен корректно, значит, GAP анализ проведен.

4. Кто планирует, тот и руководит

Очень распространена ситуация, когда продажей IT-услуг занимаются менеджеры по продажам. Это нормально до того момента, когда начинается планирование проекта. Менеджер обещает выполнить все в определенные сроки, в соответствии с этим планируется проект, выделяется бюджет, начинается работа.

Но проблема в том, что ни один менеджер по продажам не знает всех нюансов, чаще всего, они продают систему, которую знают на 2 балла по 10-бальной шкале – название, основные возможности, какие-то преимущества и т.п. Для планирования проекта этих знаний явно недостаточно. Но какие-то обещания уже есть, договор подписан. И в итоге нередко возникают проблемы и недовольство сторон друг другом.

Если планированием занимается человек, который будет руководить проектом, ситуация иная. Конечно, руководитель проекта может не знать все нюансы кода на уровне программиста. Тем не менее, этот человек уже занимался подобными проектами на практике, и систему он знает, на уровне 6 баллов из 10, а нередко и выше.

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

Проверка соответствия

Этот пункт проверяется проще всего на уровне общения. Не поленитесь и лично проконтролируйте, кто вел переговоры, составлял план, указан в качестве руководителя проекта. Убедитесь, что имя во всех случаях или хотя бы в случае составления плана и руководства проектом совпадают.

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

5. Глубина планирования

Хорошее планирование включает в себя не только непосредственно проект, но также и ответ на вопрос «а что дальше?». Вы создали проект, включающий определенные доработки. Допустим, он будет успешно и своевременно выполнен. Но далее, скорей всего, понадобятся и другие доработки. И если менеджер или руководитель проекта при общении с заказчиком сумеет это донести и обсудить дальнейшие планы, это всегда плюс.

Выше я уже упоминал о методологии Agile. И хочу сразу сделать акцент, что речь идет совсем о других вещах. В Agdile сам проект делится на небольшие этапы, каждый из которых оценивается отдельно, и сроки выполнения по каждому определяются отдельно.

Я говорю о том, что перед вами поставлены определенные задачи. На их основе составлен четкий план. И это – готовый проект, а не какая-то часть его реализации. Но практика показывает, что, если люди начинают заниматься доработками и автоматизацией какой-то деятельности, они на этом не останавливаются.

Например, при сотрудничестве с ветклиникой наша команда внедрила систему записи пациентов на прием, включающую контроль реального посещения. Это позволило лучше планировать рабочее время специалистов, повысило уровень сервиса. Но по завершению проекта логически уже «в перспективе» появилась новая задача – автоматизация расчета заработной платы. 

Если к вам приходят с предложением сделать «все, сразу и быстро», скорей всего, результаты окажутся далекими от ожидаемых. Также не лучшая история, если разработчики готовы внедрить определенный функционал и окончить сотрудничество. 

Потому что «завтра», когда вы поймете, что вам требуется еще больше, обязательно наступит. Любое предприятие развивается, со временем появляются новые потребности с точки зрения автоматизации работы. А это – новые модули, новые проекты и доработки. 

Идеально, если сами представители разработчиков об этом говорят заранее. Тогда заказчик видит определенные перспективы, может планировать бюджет с учетом будущих проектов по доработке системы. Но при этом каждый раз он получает план проекта с четкими сроками и бюджетом. Каждый проект завершается ожидаемым результатом. А запланированные на будущее виды доработок точно рассчитываются и реализуются тогда, когда это будет удобно заказчику.

Проверка глубины планирования

Чтобы убедиться, планирует ли подрядчик работу в будущем по окончанию текущего проекта, готов ли он заранее к следующим шагам, достаточно изучить “Предпроектное обследование”. Чаще всего в конце документа указывается подобная фраза:

“Данный проект рассчитан на срок от 6 до 12 календарных месяцев. В дальнейшем подразумевается разработка следующих модулей …”

Таким образом, если планы на будущее, будь то разработка новых модулей, внедрение дополнительных систем, обучение специалистов или обслуживание, должны быть зафиксированы документально, в “Обследовании” или даже договоре. 

В этом случае вы будете видеть, что люди готовы достаточно глубоко планировать ваш проект.

Что вас не убережет

В самом начале я обещал также рассказать о том моменте, который многим кажется важным, но на самом деле, от провала проекта именно этот подход не убережет. И это – «драконовские» условия сотрудничества.

Например, в условиях NDA включают штраф за каждое разглашение коммерческой информации 100 000 рублей. С учетом российского законодательства, которое в этой сфере очень слабо проработано, подобные пункты выглядят просто словами. Еще чаще встречаются штрафы за нарушение сроков вплоть до 100% возврата средств. 

В сфере малого и среднего бизнеса такие условия могут отпугнуть хороших разработчиков, так как при наличии выбора любой человек просто не будет работать с теми, кто заранее пытается угрожать штрафами или судами. Во всех остальных случаях практика показывает, что от провала проектов подобные угрозы никак не спасают.

Если речь идет о крупных корпорациях, например, о Газпроме, там нередко встречаются и подобные условия. Но не стоит забывать, что там и суммы контрактов очень большие, и команда юристов, что работают над документами, не зря получает соответствующие зарплаты. Но не будем о «небожителях», я пишу о малом и среднем бизнесе, так как все мои публикации основаны в том числе на личном опыте.

С одной стороны, от ошибок никто не застрахован. И проекты затягиваются по самым разным причинам, в том числе, из-за неверного планирования. Но что дальше? Подобные угрозы в контракте в итоге либо «забывают» и сами заказчики ради успеха проекта, пусть и не совсем в срок. Либо возникают конфликты. А в результате, даже если вы сумеете через суд вернуть все свои деньги, потраченное время вам никто не возместит.

Приведу пример из реальной жизни. Компания заключила договор на модернизацию сайта. Разработчики не справились с поставленной задачей. Представитель компании об этой истории рассказывает с гордостью: «Мы у них отсудили все деньги, они еще 2 года бесплатно дорабатывали и исправляли ошибки. Мы вообще эту веб-студию разорили». Все это, возможно, интересно с точки зрения эмоций. Но что в остатке? С момента принятия решения по модернизации сайта прошло более 2 лет, потрачено много времени, нервов, в том числе, на судебные разбирательства. А нового сайта так и нет.

Запомните: самый главный ресурс, который вам никто не сможет вернуть, это время.

Потому лучше потратить больше времени на поиски и выбор хорошего специалиста, чем страховаться при помощи «драконовских» мер. Помните, что вам нужно в первую очередь не то, как вы накажете, а что вы получите. Если исходить из этого принципа, вероятность успешных проектов значительно возрастет.