Новые фронтовые очерки: маленькие хитрости проектного менеджера
«…И опыт, сын ошибок трудных…»
А.С.Пушкин
При написании этого текста я не гналась за лаврами Джо Мараско («ИТ-проекты: Фронтовые очерки»).
Я не считаю себя популяризатором знаний об искусстве выживания в провальных проектах, как это уже много лет делает Андрей Орлов в своих «Записках автоматизатора».
В этом документе собраны некоторые мысли и приемы, которые помогли мне довести до поставленной цели 8 из 9 крупных ИТ-проектов, которыми я руководила.
Очерк 1. О конкретности «всеобщего счастья».
Вроде бы всем понятно, что если не ставить цели проекта, не формулировать его задачи, то получается «работа ради работы». Но вот о необходимости формулировать перед стартом проекта критерии его успешности зачастую забывают. Поэтому и получается попытка внедрения не ИТ-продукта, а «всеобщего счастья», как сформулировал генеральный директор одной из компаний, представляя меня как внедренца ERP-системы. Мне пришлось его поправить. Я сформулировала 2 понятия:
Критерий успешности проекта внедрения ERP-системы - решение всех задач проекта плюс достижение удовлетворённости пользователей.
Удовлетворённость пользователей - получение пользователями инструмента для повседневного выполнения служебных обязанностей в соответствии с ТЗ, разработанными на основании сформулированных потребностей на автоматизацию, проанализированных, уточненных и реализованных сотрудниками проектной группы, утверждённых ключевыми заказчиками и директором проекта.
Эти понятия я внесла в устав проекта, и в дальнейшем, во время работы, неоднократно указывала на эти 2 понятия, когда получала возмущенные вопросы «А почему это работает так?»; «Почему вот такой-то функциональности не предусмотрено?»; «А мне так неудобно».
Все подобные «неудовлетворенности» легко отсеивались, поскольку документы «Потребности на автоматизацию» были сформулированы предельно конкретно, с описанием пользовательских интерфейсов. Но сотрудникам приходилось объяснять, что их удовлетворенность - это реализация подписанного задания, а не капризов или привычек.
Очерк 2. «Любой каприз за Ваши деньги!»
Итак, проектная группа сформирована, Устав проекта, а также «Регламент взаимодействия проектной группы» и прочие необходимые документы подписаны. Работа началась. На этапе разработки (настройки, развертывания) программных модулей никаких вопросов или возражений от Заказчика обычно не поступает. Даже этап интеграционного тестирования обычно проходит более-менее мирно, поскольку пользователи пишут замечания, и надеются, что все замечания к этапу опытной эксплуатации будут устранены.
А вот дальше…
Рассмотрим простой пример.
(З) В системе данные одни, а в документах поставщика отличаются на копейку. Это ошибка.
В результате Исполнитель (внедренец) может произнести фразу «Скажите, как надо, мы сделаем». После этого он «пропал». Заказчик начинает придумывать «велосипед», сердиться, что получается «неправильный велосипед». Время тянется, работа стои'т. Как следствие, такому исполнителю предъявляют претензии в некомпетентности и неспособности решить задачи автоматизации. Отношения разрываются.
В таких случаях необходимо иметь уверенность в своих алгоритмах и решениях, настаивать на правильности своих моделей, методологии расчетов, представления данных. Если есть возможность, приводить реальные примеры из практики. Имеет смысл пользоваться «тяжелой артиллерией».
Например, на любом совещании или при разговоре с пользователями, принимающими решение, имеет смысл использовать установочные фразы типа:
Часть 2. Модельные туфли и ответственность?.
Часть 3. Инструкции и замечания.
Часть 4. Кто виноват? Иллюзии заказчика.
А.С.Пушкин
При написании этого текста я не гналась за лаврами Джо Мараско («ИТ-проекты: Фронтовые очерки»).
Я не считаю себя популяризатором знаний об искусстве выживания в провальных проектах, как это уже много лет делает Андрей Орлов в своих «Записках автоматизатора».
В этом документе собраны некоторые мысли и приемы, которые помогли мне довести до поставленной цели 8 из 9 крупных ИТ-проектов, которыми я руководила.
Очерк 1. О конкретности «всеобщего счастья».
Вроде бы всем понятно, что если не ставить цели проекта, не формулировать его задачи, то получается «работа ради работы». Но вот о необходимости формулировать перед стартом проекта критерии его успешности зачастую забывают. Поэтому и получается попытка внедрения не ИТ-продукта, а «всеобщего счастья», как сформулировал генеральный директор одной из компаний, представляя меня как внедренца ERP-системы. Мне пришлось его поправить. Я сформулировала 2 понятия:
Критерий успешности проекта внедрения ERP-системы - решение всех задач проекта плюс достижение удовлетворённости пользователей.
Удовлетворённость пользователей - получение пользователями инструмента для повседневного выполнения служебных обязанностей в соответствии с ТЗ, разработанными на основании сформулированных потребностей на автоматизацию, проанализированных, уточненных и реализованных сотрудниками проектной группы, утверждённых ключевыми заказчиками и директором проекта.
Эти понятия я внесла в устав проекта, и в дальнейшем, во время работы, неоднократно указывала на эти 2 понятия, когда получала возмущенные вопросы «А почему это работает так?»; «Почему вот такой-то функциональности не предусмотрено?»; «А мне так неудобно».
Все подобные «неудовлетворенности» легко отсеивались, поскольку документы «Потребности на автоматизацию» были сформулированы предельно конкретно, с описанием пользовательских интерфейсов. Но сотрудникам приходилось объяснять, что их удовлетворенность - это реализация подписанного задания, а не капризов или привычек.
Очерк 2. «Любой каприз за Ваши деньги!»
Итак, проектная группа сформирована, Устав проекта, а также «Регламент взаимодействия проектной группы» и прочие необходимые документы подписаны. Работа началась. На этапе разработки (настройки, развертывания) программных модулей никаких вопросов или возражений от Заказчика обычно не поступает. Даже этап интеграционного тестирования обычно проходит более-менее мирно, поскольку пользователи пишут замечания, и надеются, что все замечания к этапу опытной эксплуатации будут устранены.
А вот дальше…
Рассмотрим простой пример.
- (Заказчик) Почему данные округляются в меньшую сторону?
- (Исполнитель) У нас так написано в согласованных Вами требованиях.
- (З) Нам нужно, чтобы округлялось в бОльшую сторону.
- (И) Хорошо. Мы это сделаем. Давайте подпишем изменение требований.
- (З) Ничего не буду подписывать. Переделывайте, это ошибка.
(З) В системе данные одни, а в документах поставщика отличаются на копейку. Это ошибка.
- (И) Так Вы же сказали, что округлять надо в бОльшую сторону. Поэтому идет различие, т.к. у поставщика в системе округление в другую сторону.
- (З) Надо, чтобы было как у поставщика. Меняйте в меньшую сторону.
В результате Исполнитель (внедренец) может произнести фразу «Скажите, как надо, мы сделаем». После этого он «пропал». Заказчик начинает придумывать «велосипед», сердиться, что получается «неправильный велосипед». Время тянется, работа стои'т. Как следствие, такому исполнителю предъявляют претензии в некомпетентности и неспособности решить задачи автоматизации. Отношения разрываются.
В таких случаях необходимо иметь уверенность в своих алгоритмах и решениях, настаивать на правильности своих моделей, методологии расчетов, представления данных. Если есть возможность, приводить реальные примеры из практики. Имеет смысл пользоваться «тяжелой артиллерией».
Например, на любом совещании или при разговоре с пользователями, принимающими решение, имеет смысл использовать установочные фразы типа:
- «Как известно из мирового опыта (мировой практики)…» - собеседник обычно не спорит с «мировым опытом».
- «Мы внедрили <столько-то> проектов. Эта задача решалась так-то. Мы Вам даем устоявшийся алгоритм». Здесь важно не перегнуть палку. Поскольку проект внедрения большой системы длится не менее 1.5 - 2 лет, то Ваш собеседник может умножить количество проектов, названное Вами, на 1.5 или 2. В одной компании Ключевой заказчик на большом совещании сказал, что он выполнил 50 проектов. Я отметила, что «как правило, большие проекты длятся больше полутора лет. Значит Вам сейчас как минимум 90 лет». Заказчик «потерял лицо». Я получила подписанные Требования на разработку подсистемы.
Часть 2. Модельные туфли и ответственность?.
Часть 3. Инструкции и замечания.
Часть 4. Кто виноват? Иллюзии заказчика.