Данный пост предназначен для начинающих руководителей проектов и руководителей проектов, впервые начинающих работать с государственными органами, собирающихся вести проекты сложнее сайта визитки и планирующих в дальнейшем работать с госорганом, для чего понадобится не только завершить проект, но и создать благоприятное впечатление. Проекты, в которых пилятся деньги за воздух, не рассматриваются в рамках данного поста.
Это небольшие выводы сделаны на небольшом личном опыте работы с госорганами, и не претендуют на истинность. В ближайшем будущем планирую переходить на работу в госорган, поэтому ждите ещё и поста о построении работы изнутри.
Постарайтесь по возможности не браться за имиджевые проекты, не приносящие прибыль вашему работодателю. В таких проектах компания участвует для наработки связей и получения будущих контрактов. Это чревато жестким урезанием ресурсов, и даже при первоначальной оценочной прибыли проекта в 0 любое изменение требований тянет за собой пересмотр всего и вся. А проект то выполняется в рамках Fixed Price. Другая сторона медали – положительное завершение такого проекта с правильно выстроенной моделью поведения с заказчиком приносит в первую очередь вам +100500 к репутации и уважение от заказчика. (Пример из жизни: PM с хорошей репутацией у крупной госорганизации в дальнейшем регулярно привлекался в качестве консультанта, что давало ему некислый профит в виде денег и профессиональных связей).
Подписаны договора, необходимо начинать работу. Первым вашим шагом должно быть подписание регламента взаимодействия. Данный документ должен описывать:
• составы рабочих групп с обеих сторон с указанием должности и роли в проекте;
• лица, имеющие право подписи документов, с указанием, какое лицо подписывает какой документ;
• правила организации совещаний, конференций и пр.;
• порядок доступа сотрудников Заказчика к внутренней документации и прочим ресурсам Исполнителя (например, заказчик может попросить доступ к версионному хранилищу исходного кода или баг-трекеру);
• сроки рассмотрения корреспонденции различной важности;
После подписания регламента взаимодействия можно начинать обследование и сбор требований, т.е. запуск аналитиков в работу. ТЗ и спецификации, подготовленные для проведения конкурса (если конечно их готовили не вы, или ваша компания;) дайте аналитикам, но опираться на них нельзя. Должно быть подготовлено новое ТЗ. И тут простое правило – чем детальней будет ТЗ, темчище будет жопа легче будет в дальнейшем ввести работу с Заказчиком. В моей небольшой практике был положительный опыт плохого(их) и хорошего аналитика. Один аналитик может участвовать в проекте на стороне заказчика (представлять это). Этот же человек должен работать над проектом с мыслью, что сдавать/внедрять/поддерживать этот проект будет он. Мотивацией для этого аналитика может служить зачисление в штат заказчика с небольшой зарплатой (при условии хороших отношений го органом), вероятность развития проекта, сопровождающаяся карьерным ростом (реальная возможность из аналитика в PM), получение неплохой начальной руководящей должности в госоргане (в случае, если проект ключевой для госоргана).
Также необходимо в компании Заказчике найти людей, действительно заинтересованных в реализации проекта. Чаще всего эти люди работают на должностях простых специалистов или в противоположность на должности руководителей управлений и департаментов. Начальники отделов – редко ваши цели. Заинтересованные люди – это люди, чей труд будет упрощаться и становится более эффективным. С большей долей вероятности вы одно такого человека найдете. Попросите ознакомить вас и вашу команду с историей информационной системы или заказа на неё. Заказы не появляются случайно, им предшествуют какие-либо нормативные документы, спущенные сверху. Поэтому вы поймете основные бизнес требования, которые необходимы государству, а не то, что предполагает человек, который может в этом совсем не разбираться.
Техническое задание, несмотря на текущие тенденции в области управления, планирования и разработки, должно максимально точно описывать будущую разработку. В случае, когда по регламенту подписывать техническое задание должен человек, который сознательно или несознательно требует включить или исключить информацию в написанном вами (компанией исполнителем) ТЗ, соглашайтесь. Отправьте первоначальное ТЗ официальной корреспонденцией, в измененном ТЗ в конце прикладываем лист истории версий, в котором указываем, по какой причине было изменено ТЗ.
Данный метод можно использовать и при согласовании ЧТЗ, если вы обладаете ресурсами для всего этого делопроизводства, и ваши методы разработки и управления проектом позволяют вам пользоваться данным методом.
Запомните, если вы не учли какой-либо пункт в ТЗ или написали весьма туманно, но данный пункт есть в спеке к договору при проведении конкурса, то Заказчик может любить вас по данному вопросу как хочет.
Также к ТЗ должен прикладываться план-график работ. Будет ли это диаграмма Ганта или просто таблица с пунктами и указанием начала и завершения работы – решать вам. Но желательно подписать диаграмму Ганта, чтобы в дальнейшем визуально объяснять Заказчику последствия изменений. Учтите, что план-график для заказчика и внутренний план график – это разные вещи. В план-графике для заказчика сроки должны быть минимум до окончания договора. Это позволит получить меньше запросов на изменение функционала, плюс иметь буфер времени для всех нештатных ситуаций и задержек. И запомните, когда отправляете Заказчику измененный план-график, смотрите, что вы отправляете, чтобы не возникало неприятных казусов.
Какой метод разработки использовать и как управлять проектом – ваше личное дело (или вашей компании). Больше хочу затронуть реакцию на изменение. В случае работы с госорганами нельзя думать только о качестве выполнения работы и реализации продукта. С точки зрения вашего работодателя вы должны выполнить все обязательства по договору и принести прибыль предприятию. И постарайтесь его оправдать, даже если вам придется для этого врать воровать, убивать. На любой официальный запрос на изменение функционала сразу отвечайте официальным письмом, что вы сиюминутно начнете рассматривать этот запрос. Даже если вы имеет буфер по времени и ресурсам, не принимайте заявку в работу. Соберите несколько заявок, если это возможно, и назначьте совещание рабочей группе (представьте, что вы мстите чиновникам за бюрократию). На совещании ваша политика сводится к следующему: вы, как руководитель проекта, видите что:
а) вот эту и эту заявку необходимо реализовать, и мы скрепя сердцем буем это делать во имя хороших отношений. Но пожалуйста, будьте к нам добрее. (В этом месте вешаем люлей доброму аналитику, по идее)
б) эту заявку необходимо отрабатывать, но мы не имеем ресурсов её реализовывать, поэтому давайте решать, что можно выкинуть из некритичного функционала, чтобы эти ресурсы и время высвободить
в) эту проблему в рамках данного проекта решить невозможно. Поэтому планируйте финансирование на доработку системы.
Постарайтесь не переусердствовать. Вы должны искать компромиссы в любых ситуациях. Потребуется побыть немножко психологом, чтобы заказчик остался удовлетворен работой и вами, но остаться в рамках бюджета.
И да, назад в прошлое. Вспомните первую версию ТЗ, которую зарезал красномордый толстопуз, если была таковая. В данном случае советую вам, приступая к проектированию/разработке, все же думать о том, что придется переделывать. Может сэкономить время, а может и нет. Но риски снизит.
Фаза внедрения только что разработанного решения будет состоять из развертывания решения, обучения и поддержки пользователей некоторый период.
Перед развертыванием озаботьтесь написанием качественной документации, её все равно потребуют при закрытии договора. Лучше использовать какой-нибудь автогенератор из wiki. Wiki только придется заполнять по госту. При долгосрочной работе маст хэв. По максимуму попытайтесь задействовать штатного системного администратора, чтобы потом меньше теребил. Сразу требуйте выделения ресурсов под тестовую площадку.
Обучение. Заранее отправьте письмо с оповещением о проведении обучения и пользовательскую документацию. В письме должно быть указанно требование к помещению, техническому оснащению. В план-графике работ (ТЗ) укажите, что на комплексное обучение выделен только один день. Это не позволит насиловать ваших внедренцев постоянными просьбами демонстрации. За некоторое время до этого проведите неофициальный показ для заинтересованных сотрудников, для того, чтобы при обучении они могли помогать в чем-то инструктору и пытались ограничить возмущения и хотелки обучающихся (в случае, если вы смогли заработать лояльность заинтересованных сотрудников).
Поддержка пользователей в принципе не имеет постоянных ключевых особенностей (либо я их пока не заметил).
И напоследок. Запомните, что вы работаете с гигантской бюрократической машиной. Для комфортной работы с этой машиной необходимо иметь кучу документов, потому что есть шанс закрыть проект в суде. Обкладывайте эту машину кучей бумаг для уменьшения своих рисков.
И будьте людьми, делайте продукт так, чтобы он действительно помогал вашему государству, потому что вы его гражанин.
Это небольшие выводы сделаны на небольшом личном опыте работы с госорганами, и не претендуют на истинность. В ближайшем будущем планирую переходить на работу в госорган, поэтому ждите ещё и поста о построении работы изнутри.
0. До начала работы
Постарайтесь по возможности не браться за имиджевые проекты, не приносящие прибыль вашему работодателю. В таких проектах компания участвует для наработки связей и получения будущих контрактов. Это чревато жестким урезанием ресурсов, и даже при первоначальной оценочной прибыли проекта в 0 любое изменение требований тянет за собой пересмотр всего и вся. А проект то выполняется в рамках Fixed Price. Другая сторона медали – положительное завершение такого проекта с правильно выстроенной моделью поведения с заказчиком приносит в первую очередь вам +100500 к репутации и уважение от заказчика. (Пример из жизни: PM с хорошей репутацией у крупной госорганизации в дальнейшем регулярно привлекался в качестве консультанта, что давало ему некислый профит в виде денег и профессиональных связей).
1. Начало работы
Подписаны договора, необходимо начинать работу. Первым вашим шагом должно быть подписание регламента взаимодействия. Данный документ должен описывать:
• составы рабочих групп с обеих сторон с указанием должности и роли в проекте;
• лица, имеющие право подписи документов, с указанием, какое лицо подписывает какой документ;
• правила организации совещаний, конференций и пр.;
• порядок доступа сотрудников Заказчика к внутренней документации и прочим ресурсам Исполнителя (например, заказчик может попросить доступ к версионному хранилищу исходного кода или баг-трекеру);
• сроки рассмотрения корреспонденции различной важности;
После подписания регламента взаимодействия можно начинать обследование и сбор требований, т.е. запуск аналитиков в работу. ТЗ и спецификации, подготовленные для проведения конкурса (если конечно их готовили не вы, или ваша компания;) дайте аналитикам, но опираться на них нельзя. Должно быть подготовлено новое ТЗ. И тут простое правило – чем детальней будет ТЗ, тем
Также необходимо в компании Заказчике найти людей, действительно заинтересованных в реализации проекта. Чаще всего эти люди работают на должностях простых специалистов или в противоположность на должности руководителей управлений и департаментов. Начальники отделов – редко ваши цели. Заинтересованные люди – это люди, чей труд будет упрощаться и становится более эффективным. С большей долей вероятности вы одно такого человека найдете. Попросите ознакомить вас и вашу команду с историей информационной системы или заказа на неё. Заказы не появляются случайно, им предшествуют какие-либо нормативные документы, спущенные сверху. Поэтому вы поймете основные бизнес требования, которые необходимы государству, а не то, что предполагает человек, который может в этом совсем не разбираться.
2. Подписание технического задания
Техническое задание, несмотря на текущие тенденции в области управления, планирования и разработки, должно максимально точно описывать будущую разработку. В случае, когда по регламенту подписывать техническое задание должен человек, который сознательно или несознательно требует включить или исключить информацию в написанном вами (компанией исполнителем) ТЗ, соглашайтесь. Отправьте первоначальное ТЗ официальной корреспонденцией, в измененном ТЗ в конце прикладываем лист истории версий, в котором указываем, по какой причине было изменено ТЗ.
Данный метод можно использовать и при согласовании ЧТЗ, если вы обладаете ресурсами для всего этого делопроизводства, и ваши методы разработки и управления проектом позволяют вам пользоваться данным методом.
Запомните, если вы не учли какой-либо пункт в ТЗ или написали весьма туманно, но данный пункт есть в спеке к договору при проведении конкурса, то Заказчик может любить вас по данному вопросу как хочет.
Также к ТЗ должен прикладываться план-график работ. Будет ли это диаграмма Ганта или просто таблица с пунктами и указанием начала и завершения работы – решать вам. Но желательно подписать диаграмму Ганта, чтобы в дальнейшем визуально объяснять Заказчику последствия изменений. Учтите, что план-график для заказчика и внутренний план график – это разные вещи. В план-графике для заказчика сроки должны быть минимум до окончания договора. Это позволит получить меньше запросов на изменение функционала, плюс иметь буфер времени для всех нештатных ситуаций и задержек. И запомните, когда отправляете Заказчику измененный план-график, смотрите, что вы отправляете, чтобы не возникало неприятных казусов.
3. Реализация проекта и реакция на изменения
Какой метод разработки использовать и как управлять проектом – ваше личное дело (или вашей компании). Больше хочу затронуть реакцию на изменение. В случае работы с госорганами нельзя думать только о качестве выполнения работы и реализации продукта. С точки зрения вашего работодателя вы должны выполнить все обязательства по договору и принести прибыль предприятию. И постарайтесь его оправдать, даже если вам придется для этого врать воровать, убивать. На любой официальный запрос на изменение функционала сразу отвечайте официальным письмом, что вы сиюминутно начнете рассматривать этот запрос. Даже если вы имеет буфер по времени и ресурсам, не принимайте заявку в работу. Соберите несколько заявок, если это возможно, и назначьте совещание рабочей группе (представьте, что вы мстите чиновникам за бюрократию). На совещании ваша политика сводится к следующему: вы, как руководитель проекта, видите что:
а) вот эту и эту заявку необходимо реализовать, и мы скрепя сердцем буем это делать во имя хороших отношений. Но пожалуйста, будьте к нам добрее. (В этом месте вешаем люлей доброму аналитику, по идее)
б) эту заявку необходимо отрабатывать, но мы не имеем ресурсов её реализовывать, поэтому давайте решать, что можно выкинуть из некритичного функционала, чтобы эти ресурсы и время высвободить
в) эту проблему в рамках данного проекта решить невозможно. Поэтому планируйте финансирование на доработку системы.
Постарайтесь не переусердствовать. Вы должны искать компромиссы в любых ситуациях. Потребуется побыть немножко психологом, чтобы заказчик остался удовлетворен работой и вами, но остаться в рамках бюджета.
И да, назад в прошлое. Вспомните первую версию ТЗ, которую зарезал красномордый толстопуз, если была таковая. В данном случае советую вам, приступая к проектированию/разработке, все же думать о том, что придется переделывать. Может сэкономить время, а может и нет. Но риски снизит.
4. Внедрение
Фаза внедрения только что разработанного решения будет состоять из развертывания решения, обучения и поддержки пользователей некоторый период.
Перед развертыванием озаботьтесь написанием качественной документации, её все равно потребуют при закрытии договора. Лучше использовать какой-нибудь автогенератор из wiki. Wiki только придется заполнять по госту. При долгосрочной работе маст хэв. По максимуму попытайтесь задействовать штатного системного администратора, чтобы потом меньше теребил. Сразу требуйте выделения ресурсов под тестовую площадку.
Обучение. Заранее отправьте письмо с оповещением о проведении обучения и пользовательскую документацию. В письме должно быть указанно требование к помещению, техническому оснащению. В план-графике работ (ТЗ) укажите, что на комплексное обучение выделен только один день. Это не позволит насиловать ваших внедренцев постоянными просьбами демонстрации. За некоторое время до этого проведите неофициальный показ для заинтересованных сотрудников, для того, чтобы при обучении они могли помогать в чем-то инструктору и пытались ограничить возмущения и хотелки обучающихся (в случае, если вы смогли заработать лояльность заинтересованных сотрудников).
Поддержка пользователей в принципе не имеет постоянных ключевых особенностей (либо я их пока не заметил).
И напоследок. Запомните, что вы работаете с гигантской бюрократической машиной. Для комфортной работы с этой машиной необходимо иметь кучу документов, потому что есть шанс закрыть проект в суде. Обкладывайте эту машину кучей бумаг для уменьшения своих рисков.
И будьте людьми, делайте продукт так, чтобы он действительно помогал вашему государству, потому что вы его гражанин.
