Не бывает безнадежных проектов. Бывают плохие проектные менеджеры, к коим себя в случае этого проекта я могу отнести. Излишняя самоуверенность бывает вредна, а для успеха проекта очень часто нужно заботиться «о политике», а не только о технике. Статья написана сугубо по своим личным ошибкам, соответственно больше дискуссионная, чем информационная.
Довольно не легко писать о неудачах. Тем более с посылом что «неудач по вине заказчика» или «неудач по вине исполнителя» не бывает. Ответственность за реализацию проекта лежит только на руководителе проекта со стороны заказчика. В компании должен быть человек, на которого все будут показывать пальцем при вопросе «кто у вас занимается вопросом внедрения….?». Руководитель проекта со стороны исполнителя, конечно, тоже должен присутствовать, но нужно осознавать, что у этого человека достаточно простые цели – подписать акты и получить деньги. Если в большой компании вложили кучу денег в проект, то при удачном исходе у этого человека будет ещё цель получить «рефернс» по проекту, который он мог бы показывать другим заказчикам. Если исполнитель не удовлетворяет – нужно менять компанию исполнителя, если денег на проект недостаточно – нужно добиваться увеличения бюджета от спонсора проекта, или устанавливать ограничения проекта. Это всё я пишу к тому, что в моём случае я не пытаюсь написать «все мне мешали», а наоборот — прекрасно осознаю, что если бы принимал верные «политические» решения, то проект можно было бы спасти.
Началось всё достаточно банально – смена места работы. Небольшая торговая компания (5 крупных магазинов в Москве). Область бизнеса, с которой давно знаком. Всё вроде бы хорошо, только вот одна вещь смущала на собеседовании – заниматься придётся проектом, который уже находится в финальной стадии. Так вот, лучшее, что можно сказать в этой ситуации – никогда нельзя браться за руководство проектом, который находится «в финальной стадии». Я, конечно, не был настолько наивен, чтобы этого совсем не понимать, но был слишком самоуверен, потому как с навыками разработчика пока не расстался, а тот объём работы, который предстояло выполнить, мне не показался таким уж большим; в крайнем случае, при желании, можно и своими силами справиться. Логика тут простая: подключиться к разработке на 100% это равносильно 2-3 среднестатистическим разработчикам из франчайзи (думаю, ни для кого не стало откровением, каков средний уровень разработчика во франчайзи, я этим не пытаюсь как-либо «возвысить свои способности»). Теперь если меня совсем прижмёт, я могу работать до 16 часов в день, соответственно умножаем на 2. Получается уже неплохой объём ресурсов, вряд ли на данный проект выделяли намного больше. С учетом того, что все эти ресурсы действуют предельно согласованно и не тратят время на взаимодействие друг с другом, не нуждаются в управлении, задачах, контроле, чётких ТЗ, получается вполне эффективная команда. Но как показала практика — завалить можно любой проект. Абсолютно любой.
Итак, при выходе на работу начались сюрпризы. Корпоративная культура компании была очень странного характера, особенно для мелкой компании. Обращение между сотрудниками только на «вы», даже внутри отдела, и всё в этом стиле. Плюс жуткая текучка кадров. Как это влияет на проект? Да очень просто. Ни о какой «проектной команде» внутри уже не может быть и речи. К ежедневной отчетности я отнёсся спокойно – привык уже. Только привык, конечно, отчитываться по результатам, а не по действиям.
Далее самое интересное – компания франчайзи (очень крупная и всем известная) собиралась внедрять типовую УТ 11 (тогда ещё были первые релизы – только вышла) без доработок. На складе, как-никак, но человек 20 там работает, пользователей человек 10-15. Как не постеснялись это написать — не знаю. Кроме того, внедрять собирались не с начала года и без переноса данных – «скачком», как это любят называть. Это уже, конечно, немного напугало. Перспектива активного участия в разработке становилась почти неизбежной.
Первое желание, конечно, посмотреть план-график работ по проекту. А его просто не оказалось. Но это ещё не самое интересное. Не было даже единого перечня задач, предполагаемых ТЗ, предполагаемых работ, предполагаемых блоков работ. Из всей документации по проекту удалось обнаружить только несколько оплаченных счетов, где были какие-то работы и результат экспресс-обследования. В экспресс-обследовании, как ни странно, было отражено достаточно много интересного, поэтому «типовая УТ 11» уже никак не вязалась даже с ним. Далее я посмотрел счета, в которых значились такие занимательные пункты как «загрузка погоды из интернет» и т.п.
Следующим логичным вопросом было выяснить, каков же бюджет всего проекта. Но этот мой вопрос ответ от руководства был только «вопросы бюджета вас не касаются». Согласиться с этим без споров было ещё одной серьёзной моей ошибкой: вопросы бюджета проекта всегда касаются менеджера проекта.
Дальше началась работа. Наконец-то я взглянул в глаза людям, которые всё это сделали. Самое первое, что логично было сделать — остановить всю «разработку сложных аналитических отчетов», пока не будет работающей перегрузки из УТ 10.1 в УТ 11. На что не постеснялись мне рассказать, что переход будет «обновлением» УТ 10.1 в УТ 11. Ответил, что очень хотел бы на это посмотреть… Мою шутку поняли буквально. Недели полторы потребовалось на то, чтобы выяснить, что обновить действительно не получится. С перегрузкой ещё веселее получилось – наотрез отказались использовать конвертацию данных. Конечно «дело ваше – мне важен результат». Только вот я уже осознал, с кем имею дело – на всякий случай уточнить, что GUID нужно сохранить в этом случае (все, я думаю, понимают зачем, переход от базы к базе «скачком» в середине года это миф, даже если получится оперативный учет перевести, останется бухгалтерия). Рано или поздно конвертация появится. После этих нескольких показательных примеров РП и ТРП со стороны исполнителя я перестал доверять окончательно. Решения по большей части старался брать на себя. Но не всегда это оказывалось просто. Попробуйте, к примеру, объяснить директору, что такое GUID и зачем он мне нужен от исполнителя, особенно если там дружно заявляют «с GUID это ещё неделя сверху», оплачиваемая неделя.
Потом немного влился в работу и жизнь начала налаживаться: завели систему учета задач, хотя бы какую-то. Стал складываться перечень задач по проекту в первом приближении, началась конструктивная и плодотворная работа. Я втихую написал заготовки для конвертации из старой системы в новую и обратно. И всё бы ничего, только все сроки запуска уже прошли, требовалось форсировать старт, а то действительно вытягивание денег могло продолжаться довольно долго. В это время предпринимались попытки, правда безуспешные, расширить собственный штат разработчиков. Поэтому было ясно, что в критический момент запуска рассчитывать можно будет только на свои силы, которые сейчас имеются. Здравой идеей было провести предварительные испытания, на которых сотрудники первый раз в жизни увидели систему, после чего масштаб катастрофы стал ясен, и уже пришлось подключаться к разработке.
Как всегда, момент запуска настал неожиданно. Мой рабочий день в день запуска длился 12 часов, и далее он уже не сокращался… За 2 дня в спешке пришлось дописывать двусторонний обмен между двумя базами, настраивать оборудование, исправлять ошибки, выравнивать остатки; в общем — заниматься тем, чем обычно приходится заниматься. Только дело в том, что из этого времени приходилось ещё выкраивать время на споры с исполнителем, приёмку работ, попытки объяснить, что от них нужно, и почему это нужно «вчера», и ещё кучу времени тратить на то, чтобы объяснить руководству, что исполнитель занимается какими-то странными делами, но только не теми что нужно. Таким образом, некоторые рабочие дни продолжались по 16 часов, по 18.
На проекте начали работать фрилансеры. С трудом удалось найти хороших специалистов, которые за небольшие суммы денег проворачивали колоссальный объём работы, франчайзи и не снилось. Да, рискованно, да, не надёжно, но в ситуации, когда переживаешь, что в сутках только 24 часа – спасательный круг. Мой рабочий день снова стал приближаться к 8-часовому.
Спустя недели две–три работы, с трудом и кряхтением, но компания перешла на работу в УТ 11. Там, конечно, ещё осталась куча нерешенных вопросов, но они относились уже не к текущей работе, а скорее к взаимодействию с бухгалтерией (спасибо ещё раз большое 1С за разделение контрагентов на партнёров и контрагентов) и вопросам оптимизации работы. Начался разговор о запуске 1С: Розницы.
Наконец удалось добиться от руководства назначения встречи с руководством франчайзи, чтобы высказать им претензии, и возможно отказаться от их услуг (рабочие руки в виде фрилансеров уже были). На встречу приехали, видимо, профессиональные переговорщики и стали рассказывать, как они будут бороться с проблемой, сколько ресурсов они готовы выделить, и как незамедлительно они будут реагировать на наши обращения (забыли только упомянуть, сколько это будет стоить).
Я уже давно в чудеса не верю. Не бывает, чтобы всё было плохо и вдруг стало хорошо, но руководители видимо поверили и на всё согласились, после чего я передал все текущие задачи на откуп франчайзи, а пользователям раздал контакты ещё и их консультанта. От руководства через некоторое время получил фразу «Олег, мы же только пообщались, а ты всё решил».
Вызван был руководством, причём одним из руководителей компании, который вообще первый раз меня видел, попросил составить отчет о текущих и оставшихся задачах. Я обрадовался, что моими стараниями у меня эта информация хотя бы есть, что я уже достаточно близко представляю, какие работы ещё предстоят. Как оказалось, отчёт нужен был лишь для того чтобы сказать, что «в такой форме его руководству не подают».
Очевидно, во всех бедах виноват был я, в превышении бюджета (о размере которого я наконец-то узнал) виноват был тоже я, да и вообще не совсем понятно, чем я занимался. Мой непосредственный руководитель вдруг оказался срочно чем-то занят, а я, когда понял к чему дело клонится, перестал пытаться что-либо объяснить. Уволить меня, я думаю, не уволили бы. Но вряд ли имело смысл пытаться дальше что-либо делать.
(С) comol
Урок 1. Ответственность за реализацию проекта лежит только на руководителе проекта со стороны заказчика.
Довольно не легко писать о неудачах. Тем более с посылом что «неудач по вине заказчика» или «неудач по вине исполнителя» не бывает. Ответственность за реализацию проекта лежит только на руководителе проекта со стороны заказчика. В компании должен быть человек, на которого все будут показывать пальцем при вопросе «кто у вас занимается вопросом внедрения….?». Руководитель проекта со стороны исполнителя, конечно, тоже должен присутствовать, но нужно осознавать, что у этого человека достаточно простые цели – подписать акты и получить деньги. Если в большой компании вложили кучу денег в проект, то при удачном исходе у этого человека будет ещё цель получить «рефернс» по проекту, который он мог бы показывать другим заказчикам. Если исполнитель не удовлетворяет – нужно менять компанию исполнителя, если денег на проект недостаточно – нужно добиваться увеличения бюджета от спонсора проекта, или устанавливать ограничения проекта. Это всё я пишу к тому, что в моём случае я не пытаюсь написать «все мне мешали», а наоборот — прекрасно осознаю, что если бы принимал верные «политические» решения, то проект можно было бы спасти.
Урок 2. Никогда нельзя браться за руководство проектом, который находится на «финальной стадии».
Началось всё достаточно банально – смена места работы. Небольшая торговая компания (5 крупных магазинов в Москве). Область бизнеса, с которой давно знаком. Всё вроде бы хорошо, только вот одна вещь смущала на собеседовании – заниматься придётся проектом, который уже находится в финальной стадии. Так вот, лучшее, что можно сказать в этой ситуации – никогда нельзя браться за руководство проектом, который находится «в финальной стадии». Я, конечно, не был настолько наивен, чтобы этого совсем не понимать, но был слишком самоуверен, потому как с навыками разработчика пока не расстался, а тот объём работы, который предстояло выполнить, мне не показался таким уж большим; в крайнем случае, при желании, можно и своими силами справиться. Логика тут простая: подключиться к разработке на 100% это равносильно 2-3 среднестатистическим разработчикам из франчайзи (думаю, ни для кого не стало откровением, каков средний уровень разработчика во франчайзи, я этим не пытаюсь как-либо «возвысить свои способности»). Теперь если меня совсем прижмёт, я могу работать до 16 часов в день, соответственно умножаем на 2. Получается уже неплохой объём ресурсов, вряд ли на данный проект выделяли намного больше. С учетом того, что все эти ресурсы действуют предельно согласованно и не тратят время на взаимодействие друг с другом, не нуждаются в управлении, задачах, контроле, чётких ТЗ, получается вполне эффективная команда. Но как показала практика — завалить можно любой проект. Абсолютно любой.
Урок 3. Завалить можно любой проект. Абсолютно любой.
Итак, при выходе на работу начались сюрпризы. Корпоративная культура компании была очень странного характера, особенно для мелкой компании. Обращение между сотрудниками только на «вы», даже внутри отдела, и всё в этом стиле. Плюс жуткая текучка кадров. Как это влияет на проект? Да очень просто. Ни о какой «проектной команде» внутри уже не может быть и речи. К ежедневной отчетности я отнёсся спокойно – привык уже. Только привык, конечно, отчитываться по результатам, а не по действиям.
Далее самое интересное – компания франчайзи (очень крупная и всем известная) собиралась внедрять типовую УТ 11 (тогда ещё были первые релизы – только вышла) без доработок. На складе, как-никак, но человек 20 там работает, пользователей человек 10-15. Как не постеснялись это написать — не знаю. Кроме того, внедрять собирались не с начала года и без переноса данных – «скачком», как это любят называть. Это уже, конечно, немного напугало. Перспектива активного участия в разработке становилась почти неизбежной.
Урок 4. Перед тем как браться за существующий проект, нужно изучить план-график работ по нему, хотя бы для того чтобы убедиться, что таковой существует.
Первое желание, конечно, посмотреть план-график работ по проекту. А его просто не оказалось. Но это ещё не самое интересное. Не было даже единого перечня задач, предполагаемых ТЗ, предполагаемых работ, предполагаемых блоков работ. Из всей документации по проекту удалось обнаружить только несколько оплаченных счетов, где были какие-то работы и результат экспресс-обследования. В экспресс-обследовании, как ни странно, было отражено достаточно много интересного, поэтому «типовая УТ 11» уже никак не вязалась даже с ним. Далее я посмотрел счета, в которых значились такие занимательные пункты как «загрузка погоды из интернет» и т.п.
Урок 5. Вопросы бюджета проекта всегда касаются менеджера проекта.
Следующим логичным вопросом было выяснить, каков же бюджет всего проекта. Но этот мой вопрос ответ от руководства был только «вопросы бюджета вас не касаются». Согласиться с этим без споров было ещё одной серьёзной моей ошибкой: вопросы бюджета проекта всегда касаются менеджера проекта.
Урок 6. Руководить проектом со стороны исполнителя должны люди, компетентность которых сомнения не вызывает.
Дальше началась работа. Наконец-то я взглянул в глаза людям, которые всё это сделали. Самое первое, что логично было сделать — остановить всю «разработку сложных аналитических отчетов», пока не будет работающей перегрузки из УТ 10.1 в УТ 11. На что не постеснялись мне рассказать, что переход будет «обновлением» УТ 10.1 в УТ 11. Ответил, что очень хотел бы на это посмотреть… Мою шутку поняли буквально. Недели полторы потребовалось на то, чтобы выяснить, что обновить действительно не получится. С перегрузкой ещё веселее получилось – наотрез отказались использовать конвертацию данных. Конечно «дело ваше – мне важен результат». Только вот я уже осознал, с кем имею дело – на всякий случай уточнить, что GUID нужно сохранить в этом случае (все, я думаю, понимают зачем, переход от базы к базе «скачком» в середине года это миф, даже если получится оперативный учет перевести, останется бухгалтерия). Рано или поздно конвертация появится. После этих нескольких показательных примеров РП и ТРП со стороны исполнителя я перестал доверять окончательно. Решения по большей части старался брать на себя. Но не всегда это оказывалось просто. Попробуйте, к примеру, объяснить директору, что такое GUID и зачем он мне нужен от исполнителя, особенно если там дружно заявляют «с GUID это ещё неделя сверху», оплачиваемая неделя.
Потом немного влился в работу и жизнь начала налаживаться: завели систему учета задач, хотя бы какую-то. Стал складываться перечень задач по проекту в первом приближении, началась конструктивная и плодотворная работа. Я втихую написал заготовки для конвертации из старой системы в новую и обратно. И всё бы ничего, только все сроки запуска уже прошли, требовалось форсировать старт, а то действительно вытягивание денег могло продолжаться довольно долго. В это время предпринимались попытки, правда безуспешные, расширить собственный штат разработчиков. Поэтому было ясно, что в критический момент запуска рассчитывать можно будет только на свои силы, которые сейчас имеются. Здравой идеей было провести предварительные испытания, на которых сотрудники первый раз в жизни увидели систему, после чего масштаб катастрофы стал ясен, и уже пришлось подключаться к разработке.
Урок 7. Нельзя работать сверхурочно, если это не оговорено договором. Этого всё равно не оценят.
Как всегда, момент запуска настал неожиданно. Мой рабочий день в день запуска длился 12 часов, и далее он уже не сокращался… За 2 дня в спешке пришлось дописывать двусторонний обмен между двумя базами, настраивать оборудование, исправлять ошибки, выравнивать остатки; в общем — заниматься тем, чем обычно приходится заниматься. Только дело в том, что из этого времени приходилось ещё выкраивать время на споры с исполнителем, приёмку работ, попытки объяснить, что от них нужно, и почему это нужно «вчера», и ещё кучу времени тратить на то, чтобы объяснить руководству, что исполнитель занимается какими-то странными делами, но только не теми что нужно. Таким образом, некоторые рабочие дни продолжались по 16 часов, по 18.
На проекте начали работать фрилансеры. С трудом удалось найти хороших специалистов, которые за небольшие суммы денег проворачивали колоссальный объём работы, франчайзи и не снилось. Да, рискованно, да, не надёжно, но в ситуации, когда переживаешь, что в сутках только 24 часа – спасательный круг. Мой рабочий день снова стал приближаться к 8-часовому.
Спустя недели две–три работы, с трудом и кряхтением, но компания перешла на работу в УТ 11. Там, конечно, ещё осталась куча нерешенных вопросов, но они относились уже не к текущей работе, а скорее к взаимодействию с бухгалтерией (спасибо ещё раз большое 1С за разделение контрагентов на партнёров и контрагентов) и вопросам оптимизации работы. Начался разговор о запуске 1С: Розницы.
Урок 8. Нужно требовать от руководства письменного подтверждения указаний, которые кажутся абсурдными.
Наконец удалось добиться от руководства назначения встречи с руководством франчайзи, чтобы высказать им претензии, и возможно отказаться от их услуг (рабочие руки в виде фрилансеров уже были). На встречу приехали, видимо, профессиональные переговорщики и стали рассказывать, как они будут бороться с проблемой, сколько ресурсов они готовы выделить, и как незамедлительно они будут реагировать на наши обращения (забыли только упомянуть, сколько это будет стоить).
Я уже давно в чудеса не верю. Не бывает, чтобы всё было плохо и вдруг стало хорошо, но руководители видимо поверили и на всё согласились, после чего я передал все текущие задачи на откуп франчайзи, а пользователям раздал контакты ещё и их консультанта. От руководства через некоторое время получил фразу «Олег, мы же только пообщались, а ты всё решил».
Итог: настал час «расплаты за содеянное».
Вызван был руководством, причём одним из руководителей компании, который вообще первый раз меня видел, попросил составить отчет о текущих и оставшихся задачах. Я обрадовался, что моими стараниями у меня эта информация хотя бы есть, что я уже достаточно близко представляю, какие работы ещё предстоят. Как оказалось, отчёт нужен был лишь для того чтобы сказать, что «в такой форме его руководству не подают».
Очевидно, во всех бедах виноват был я, в превышении бюджета (о размере которого я наконец-то узнал) виноват был тоже я, да и вообще не совсем понятно, чем я занимался. Мой непосредственный руководитель вдруг оказался срочно чем-то занят, а я, когда понял к чему дело клонится, перестал пытаться что-либо объяснить. Уволить меня, я думаю, не уволили бы. Но вряд ли имело смысл пытаться дальше что-либо делать.
(С) comol
