"Участники проектной группы должны говорить на одном языке"

"Участники проектной группы должны говорить на одном языке", —считает менеджер проектов IT-департамента ОАО ПБК "Славутич" Петр Козлов. Благодаря правильно поставленным задачам на предприятии достаточно успешно проходит процесс автоматизации. При состав
Мы продолжаем сражаться с оккупантом на информационном фронте, предоставляя исключительно проверенную информацию и аналитику.
Война лишила нас возможности зарабатывать, просим Вашей поддержки.
Поддержать delo.ua

"Участники проектной группы должны говорить на одном языке", —считает менеджер проектов IT-департамента ОАО ПБК "Славутич" Петр Козлов. Благодаря правильно поставленным задачам на предприятии достаточно успешно проходит процесс автоматизации.

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

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

— Если бы составить техническое задание (ТЗ) было просто, то давно существовали бы книги, в которых все было бы расписано пошагово, и любой неподготовленный человек смог бы написать ТЗ без проблем. На самом деле это достаточно сложно, хотя действительно сейчас есть много хорошей литературы с рекомендациями, с чего следует начинать и что должно включать в себя техническое задание. Но если подходить к этому процессу формально и учитывать все рекомендации "книжных" специалистов в этой отрасли, то окончательный объем ТЗ может достигнуть размера трехтомного романа, в котором будет описано нечто общее и ничего конкретного. Главная проблема в составлении техзадания — это то, что человек мыслит образами, а выражается словами. И, как правило, его словарного запаса не всегда достаточно, чтобы выразить то, что он представляет. Да и понимание терминов и слов у многих различное, поэтому для создания ТЗ необходимо выработать некий общий язык, который будет доступен всем — и составителю, и заказчику и исполнителю (реализатору) самого задания.

— Как поступали вы — привлекали внешних специалистов или справлялись с поставленной задачей силами коллектива?

— Все зависело от масштаба проекта. Если требовались небольшие доработки существующей системы, мы решали эту задачу своими силами. Но если шла речь о создании новой информационной системы, то, конечно, привлекали компанию-разработчика, которая занималась созданием всей предпроектной документации и разработкой. Но в любом случае участвовать в исследовании области и составлении документации должны не только одни консультанты, поскольку они не всегда объективно оценивают все происходящие на предприятии процессы. Кроме того, они могут не учесть специфику, на которую следует обратить их внимание. Поэтому мы всегда создаем рабочую группу, в которую, кроме консультантов, входят сотрудники нашего IT-департамента и представители бизнес-подразделений (логистики, финансового и пр.).

— Перед тем как начинать работу с внешними специалистами, что вы обычно делаете сами, а что входит в задачи специалистов компании?

— Как правило, перед написанием официального документа — ТЗ, в котором будут определены все требования к создаваемой системе, мы составляем предварительный документ. В нем содержатся все требования к системе, но не в таком официальном формате, как в ТЗ. Этот документ составляется на основании пожеланий сотрудников: какой они видят создаваемую АСУ и какие функции они хотят автоматизировать.

Далее сотрудник нашего IT-департамента обрабатывает поданные заявки. Исходя из общего представления о компании и предложений работников, их требований к системе он формирует виденье создаваемого проекта. Если эта задача реализуется нашими программистами, они самостоятельно составляют ТЗ, согласовывают его с тем департаментом, для которого реализуется проект, и после окончательного утверждения отдают в разработку. Если же привлекаются субподрядчики, то предварительные документы по проекту передаются им, и в дальнейшем совместно создается ТЗ.

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

— В каких случаях вы привлекали внешних консультантов, и как вы оцениваете опыт общения с ними?

— У нас в компании процесс автоматизации длится непрерывно, и в связи с этим мы постоянно привлекаем внешних консультантов. Например, перед разработкой или внедрением новых модулей нашей ERP-системы "Монолит-SQL" проводится консалтинг. В качестве консалтинговой компании в этом случае выступает компания-разработчик. В основном это связано с тем, что мы покупаем не просто готовый продукт, а решение, которое, как правило, уже было внедрено на одном из предприятий нашего холдинга. Наши сотрудники в этом случае привлекаются к разработке ТЗ только в качестве согласующей стороны, а IT-специалисты участвуют в проекте уже на стадии внедрения. Но подобные случаи скорее исключение, нежели постоянная практика.

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

— Как долго вы разрабатываете ТЗ?

— Нет четкого правила, все зависит от объема проекта. Можно выделить два подхода — "японский" и "западный". При "японском" на создание ТЗ и проведение предварительных исследований уходит около 80% времени проекта и всего 20% отводится на его реализацию. А во втором случае наоборот: 20% — на создание ТЗ и 80% — на реализацию. Кому какой вариант подходит — каждый выбирает сам. Могу привести пример, когда в нашей компании запускался проект, охватывающий все бизнес-подразделения. Было составлено очень подробное техническое задание, но в результате реализация проекта затянулась. На мой взгляд, одной из причин стало то, что техническое задание было написано для системы в целом, без разбивки на логические части по сферам бизнеса. Если бы я начинал разработку технического задания для этого проекта снова, то разделил бы документ на несколько составляющих: основной документ, описывающий архитектуру системы (как будет работать система в целом и как отдельные модули взаимодействуют между собой), и документы, описывающие функциональность каждого модуля в отдельности. Это позволило бы отдельным департаментам еще до завершения работ по проекту получить работающие модули.