MS Project и моя "история болезни"

Jul 01, 2008 17:45


У меня иногда складывается такое ощущение, что люди, которые пишут книжки про MS Project, никогда этим Project'ом сами не пользовались. Ну, во всяком случае, для дела. А как еще объяснить отсутствие  сколь-нибудь внятного и последовательного изложения работы с проектом? Особенно меня повеселил эпиграф к книге «Project 2003. Bible»: «Материал книги Project 2003. Bible, а также представленные в ней примеры написаны простым языком, что позволит разобраться с программой любому пользователю Project». Подписан Адрианом Дженкинсом, команда Microsoft Project. Подобные заявления из уст разработчика всегда выглядят забавно)))

Вообще MS Project - приложение крайне тяжелое для восприятия и комплексного использования. Я, пожалуй, не знаю ни одной конторы, которая использует его как основное (и тем более единственное) программное средство управления проектами. Гораздо чаще (во всяком случае, в сфере разработки ПО) встречаются следующие варианты:

1. проекты ведутся вообще без помощи каких-либо программных средств. Ну вот так вот. На пальцах. Или на бумажках. В принципе, такой подход может быть оправдан, если речь идет о совсем уж маленьких локальных проектиках, на которых работают 1-2 человека и которые идут строго друг за другом (т.е. в портфеле проектов находится один проект). Ну да, автоматизация не должна быть избыточной, она должна развиваться только по необходимости, когда без нее уже никак. На вырост - бесполезно. Таково мое IMHO в данном вопросе. Этот вариант мы рассматривать не будем, поскольку и рассматривать-то там особо нечего и вообще не наш это случай.

2. используется комплекс программных средств. Ну то есть люди не гонятся за универсальностью и сведением ВСЕЙ проектной информации в единую информационную систему. Постановку задач и отслеживание статусов - в одном приложении (условно - task-manager), учет рабочего времени - в том же или другом (условно - time-tracker), планирование разработки - в третьем, бюджетирование - в четвертом (системы хранения версий, сборки релизов, документирования, базы знаний я тут даже не называю, речь не о них). Зачастую, для части этих задач используется банальный Excel. Ну а что? Банальный, зато удобный. Я вот до сих пор считаю его лучшим табличным редактором всех времен и народов (Джоэль, превед!). Те же табличные представления Project'а рядом не валялись. И не надо мне рассказывать про то, что Project вовсе не для этого предназначен. В конечном итоге все таблицы предназначены для структурирования данных, а принципы юзабилити никто не отменял.

Если же говорить о Project'е применительно к этому самому второму подходу, то его чаще всего (во всяком случае, насколько я могу судить) используют для базового планирования. А все почему? А потому что есть такой универсальный инструмент визуализации планов - график Ганта. Проджект строит его на раз, поэтому запары PM'а по сути сводятся к комбинаторике: как расставить задачи и распределить ресурсы так, чтобы эта скотина программа не ругалась и не обрывала заданные связи.

На этапе фиксации базового плана отношения большинства знакомых мне PM'ов с проджектом заканчиваются. (Я вот даже не поленилась прошерстить RSDN’овский форум PM’ов на предмет обсуждения инструментальных средств. 90% вопросов, касающихся проджекта, связаны именно с планированием и его нюансами: типами связей, расчетом критических путей, прогнозированием длительностей и т.п.) Ну ладно, некоторые еще промежуточные планы фиксируют, чтобы после завершения проекта пугать получившимися картинками других PM'ов и ведущих разработчиков (хотя на последних сие, как правило, особого впечатления не производит). Естественно, что попытки "разбора полетов" и анализа причин провала базового плана после этого выглядят весьма убого и особого смысла не имеют. Ежу понятно, что базовый план провалился, потому что его пришлось 4 раза пересматривать и фиксировать промежуточные планы, мягко говоря, отличающиеся от базового. И что из того? Орг.выводы-то какие?

Дальше опять возможны варианты. Опять-таки большинство из известных мне PM'ов предпринимали попытки перевести весь проектный учет на Project. Ну как же, ведь система специально для этого предназначена, когда ее щупаешь, создается устойчивое ощущение мощи и огромных возможностей, сила бренда опять-таки давит на мозг. А если человек обладает хоть каплей врожденного перфекционизма, то ваще вилы он практически обречен. Я лично (с одобрения, а иной раз и активной поддержки коллег) пыталась раз 6. Честно. Вот сейчас у меня очередной рецидив. С подачи московского партнера по бизнесу, чтоб ему щас икнулось, а вместе с ним всем разработчикам проджекта и всем их родственникам по седьмого колена включительно. Ну а раз имеет место рецидив, то приходится влезать в отслеживание хода проекта в MS Project. Вот тут мы и натыкаемся на разного рода сложности:

1. настройка параметров расчета. Чтобы не огрести по полной программе косяков на стадии отслеживания, придется довольно долго «фтыкать» в параметры расчета. Иначе мы сильно рискуем, введя некоторое количество фактических данных, а затем переключив представление (ну хотя бы вернувшись к тому же графику Ганта), обнаружить там полный раздрай и тихий ужас. А чтобы понять, как вообще получилось так, что сроки конца и начала задач уехали черт-те куда, трудозатраты приняли какие-то невообразимые значения и вообще «караул, где мой первоначальный проект?!», придется опять-таки долго «фтыкать» в те же параметры расчетов. Либо похерить «этот ужас», поднять вчерашнюю версию проекта из бэкапа и попытаться снова (и так несколько раз по кругу)))).

При бездумном включении всевозможных флажков (ну типа чтобы оно все по максимуму само считалось и двигалось), мы обязательно получим описанную выше картину. Потому что вот кто-нибудь видел на практике пятую нормальную форму БД? Вот то-то же, и абсолютной целостности и бесконфликтности проектной информации еще никто не видел. И, казалось бы, при теоретическом размышлении все в проджекте грамотно и логично. Но реализация настолько тяжела и интуитивно непонятна, что хоть плачь. И книжки не сильно помогают, поскольку см. первый абзац сего креатива. В итоге приходится либо действовать методом научного тыка, либо лезть с «дурацкими вопросами» на RSDN или в аську (а лучше сразу в Skype) к более опытному PM’у.

2. удобство работы с данными. Про таблицы в проджекте я уже ругалась. Ну не по уму они сделаны. Вот, например, форма представления «использование задач», точнее ее календарная часть справа, там где, например, трудозатраты по дням забиваются. В плане внешнего вида таблица из серии «вырви глаз». Было бы гораздо приятнее, если бы фактические и базовые строчки подсвечивались по-разному и еще границы между задачами были обозначены (жирным, например). Я все понимаю, можно при вводе фактических базовые вообще отключать, можно выводить табличную часть по отдельно выбранной задаче, можно вообще формы для ввода данных настроить. Но вот лично мне удобнее работать с табличным представлением и наблюдать всю картину целиком по всей выбранной ветке работ. И сопоставлять сразу фактические данные с базовыми. И не ломать при этом глаза. В конце концов, тварь я дрожащая или право имею?

3. основная и в большей степени философская, чем практическая, проблема PM’а - трудозатраты самого PM’а. Да, проджект - это во многом стандарт де-факто; да, в плане единства проектных данных он, наверное, не имеет альтернатив; да, он позволяет отслеживать такие тенденции, которые менее универсальным продуктам не снились. Да, за все это ему, наверное, можно простить то, что многие вещи реализованы в нем на порядок более криво, чем в узкоспециализированных приложениях. Но рабочего времени PM’а он отжирает очень много.

4. ну и плюс ко всему, все-таки тотальной автоматизации пока не получается… Данные приходится дублировать. Я вот не могу себе представить, что мы заставим своих программистов, например, вбивать рабочие часы непосредственно в проджект. Мы ж не звери, в конце концов)) То есть если уж совсем впадать в перфекционизм, то надо либо поднимать вопрос об интеграции, либо как-то пытаться ввести в работу веб-интерфейс. Народ на RSDN говорит, что веб-интерфейс у проджекта неплохой, и часть проблем с тяжеловесностью и сложностью работы с данными снимает (не знаю, сама не видела). Но все это опять-таки упирается в трудозатраты и, соответственно, пока больше относится к области научной фантастики. Поживем - увидим.

Работа, ИТ

Previous post Next post
Up