Руководитель проектов 1с с чего начать
«1С-Рарус» - это группа компаний федерального масштаба, лидер сети 1С:Франчайзинг по рейтингу партнеров Фирмы 1С. 2700 сотрудников, и 150 000 клиентов за 27 лет работы на рынке.
Мы ищем Руководителя проектов на внедрение информационных систем 1С:Предприятие: 1С:ERP, 1С:КА, реже - БП, УТ, ЗУП.
Ваша задача - успешное завершение проектов: когда Заказчик доволен и готов дать отзыв, акты закрыты и оплачены, сроки и стоимость соблюдены.
В чем заключаеться работа:
- Участие в оценке проектов, управление предпроектным обследованием
- Коммуникации с Заказчиком, управление ожиданиями, работа с возражениями
- Ведение проектной документации и участие в составлении технической документации
- Контроль проекта, управление стоимостью, сроками, содержанием
- Презентация результатов Заказчику, сдача этапов проекта, закрытие проекта
Что ожидаем от вас:
- Опыт руководства проектами внедрения 1С:Предприятия, желательно отзывы клиентов о внедрениях с вашим участием
- Опыт ведения проектной документации, примеры документации проектов под вашим управлением
- Умение снимать требования, оценивать трудозатраты и сроки внедрения
- Знание основных предметных областей внедрений, знание конфигураций 1С:Предприятие и понимание их архитектуры
Мы предлагаем:
- Значимые и интересные проекты в ваше портфолио
- Участие в топовых ИТ-рейтингах
- Привлечение интересных проектов благодаря топовой позиции на рынке, 1С-Рарус - занимает первое место в рейтинге партнеров
- Возможность работы по нашей методологии проектного управления, основанной на лучших практиках PMBoK
- Ресурсный центр федерального масштаба для привлечения специалистов на проекты - у нас более 2700 сотрудников по всей территории РФ
- Обучение и сертификацию за счет компании, курсы и тренинги, семинары и мастер-классы
- Официальное трудоустройство, социальный пакет. 100% белая зарплата: оклад + бонусы по закрытию этапов проектов и после завершения проекта в целом
- Комбинированный формат работы (удаленный/на площадке Заказчика/в офисе компании м.Тимирязевская)
- Спортивные секции, корпоративные скидки в фитнес-клуб и в Skyeng, регулярные корпоративные мероприятия
(0) У вас стремно работать. Дима Казачков рассказывал, что от вас все программисты разбежались, когда он им зарплату после перехода на удаленку понизил.
1С:Технология Корпоративного внедрения 2.0. – это свод знаний по управлению проектами на базе 1С:Предприятие на среднем и корпоративном сегментах рынка, в основе которого лежит обобщенный опыт партнерских компаний и фирмы "1С" по разработке и внедрению корпоративных ИС. 1С:ТКВ 2.0 также гармонизирована с международными и отечественными стандартами по управлению проектами.
Онлайн курс "Управление проектами на основе 1С:ТКВ 2.0" позволит участникам ответить на вопросы о том, что такое 1С:ТКВ 2.0 и для чего она предназначена, в каких случаях ее использование эффективно и целесообразно, что необходимо учитывать при применении 1С:ТКВ 2.0 в конкретном проекте.
Цели онлайн курса:
- сформировать понимание у участников курса о назначении и ограничениях 1С:ТКВ 2.0;
- обучить участников курса общим подходам к выполнению проектов создания и внедрения информационных систем на базе 1С:Предприятие 8 с применением 1С:ТКВ 2.0;
- повысить компетенции участников в области планирования, организации и контроля реализации проектов создания и внедрения информационных систем.
Онлайн
-
Цена для партнеров:
- Цена для физ.лиц:
14400 руб. - Цена для юр.лиц:
14400 руб.
14400.00 руб. -->
В рамках курса рассматриваются темы организации предметных работ проекта (содержания проекта) и темы организации процессов управления проектом. В рамках данного курса не планируется рассмотрение таких специализированных тем, как "Управление разработкой", "Инструменты и методы описания бизнес-процессов", "Построение системно-технологической архитектуры".
Онлайн курс будет полезен слушателям, работающим или планирующим работать в проектах создания и внедрения средних, крупных и корпоративных информационных систем коммерческого сектора:
- Руководителям проектов
- Специалистам фирм-франчайзи, выполняющих функции руководителей проектов в проектах внедрения
- Руководителям фирм-франчайзи – для получения целостного понимания 1С:ТКВ 2.0, ее назначении и особенностей применения
- Аккаунт-менеджерам – для выстраивания эффективной работы с заказчиком на стадии продажи проекта и правильного взаимодействия с проектной командой
Онлайн курс включает в себя – 6 вебинаров, 4 домашних заданий, их проверку преподавателем и выдачу обратной связи участникам по результатам каждого домашнего задания.
В случае успешного окончания курса (участие во всех вебинарах и выполнение домашних заданий) выдается свидетельство установленного образца.
Тема 1.Введение в 1С:ТКВ 2.0.
- Назначение, область применения
- Состав
- Система понятий
Тема 2. Жизненный цикл проекта.
Тема 3. Продажа проекта, работа с потенциальными рисками на этапе продажи.
- Цели и задачи фазы, особенности и специфика, пакеты работ и выходная продукция фазы, рассмотрение шаблонов и примеров проектных документов фазы.
Домашнее задание: Разработка дорожной карты проекта.
Сдача домашнего задания "Разработка дорожной карты проекта"
Тема 4. Договоры.
- Что должно быть в договоре.
- Ограничения и допущения в договорах.
Тема 5. Организационная структура проекта.
- Схема организационной структуры проекта.
- Проектные группы управления и исполнения проекта.
- Проектные роли и обязанности.
Тема 6. (первая часть) Инициация проекта.
- Цели и задачи фазы, особенности и специфика, пакеты работ и выходная продукция фазы, рассмотрение шаблонов и примеров проектных документов фазы.
- Разработка организационной структуры проекта.
- Подготовка тезисов для батла "Устав проекта".
Сдача домашнего задания "Разработка организационной структуры проекта"
Тема 6. (вторая часть) Инициация проекта.
Тема 7. Формирование (уточнение) требований к ИС.
- По каждой теме рассматриваются цели и задачи фазы, особенности и специфика, пакеты работ и выходная продукция фазы, рассмотрение шаблонов и примеров проектных документов фазы.
Тема 8. Проектирование ИС.
Тема 9. Разработка ИС.
- По каждой теме рассматриваются цели и задачи фазы, особенности и специфика, пакеты работ и выходная продукция фазы, рассмотрение шаблонов и примеров проектных документов фазы.
Домашнее задание: Планирование перечня и содержания документов фазы проектирования ИС.
Сдача домашнего задания "Планирование перечня и содержания документов фазы проектирования ИС"
Тема 10. Подготовка к вводу ИС в ОЭ/ОПЭ.
Тема 11. Проведение ОЭ/ОПЭ.
Тема 12. Подготовка к вводу ИС в ПЭ.
Тема 13. Проведение ПЭ.
- По каждой теме рассматриваются цели и задачи фазы, особенности и специфика, пакеты работ и выходная продукция фазы, рассмотрение шаблонов и примеров проектных документов фазы.
Тема 14. Регулярные мероприятия управления проектами.
- Работы и выходная продукция.
- Подходы и инструменты планирования и сбора фактических данных об исполнении.
- Метод освоенного объема.
- Статус-отчеты.
Домашнее задание: Прогноз финансовых показателей проекта
Сдача домашнего задания "Прогноз финансовых показателей проекта"
Тема 15. Завершение проекта.
Тема 16. Работы по обеспечению производительности ИС.
- Цели и задачи фазы.
- Особенности и специфика организации работ.
- Пакеты работ и выходная продукция фазы.
Тема 17. Работы по обеспечению безопасности информации.
- Цели и задачи фазы.
- Условные уровни требований по обеспечению безопасности информации.
- Особенности и специфика организации работ.
Тема 18. Авторский надзор фирмы "1С".
- Цели и задачи.
- Форма организации работ.
- Пакеты работ и выходная продукция.
Заключение.
Рекомендуем до посещения курса ознакомиться с терминологией и основными требованиями руководства PMBOK, т.к. курс ориентирован на слушателей, которые обладают знаниями, необходимыми для понимания деятельности, связанной с выполнением процессов управления проектами.
По случаю того, что меня уже неделю как можно поздравить с получением статуса 1С:Руководитель корпоративных проектов, решила сказать несколько слов про то, как по моим представлениям, выглядит путь роста и развития руководителя проектов 1С. Подробнее про это я планирую поговорить на бесплатном вебинаре “Путь джедая в управлении проектами 1С”, в четверг в 17:00 МСК.
Сертификация 1С:Руководитель корпоративных проектов, вслед за тестированием 1С:Управление проектами и знакомством с шаблонами от 1С из Профкейса, в очередной раз укрепила меня в понимании, что 1С не ставит себе целью проверить умение проекты внедрения реализовывать. А проверяет формальное соответствие технологии - процедуре. Это не хорошо и не плохо, это данность. В конце концов, 1С тоже можно понять - им важно быть уверенным, что вы все делаете формально соблюдая технологию. А тот факт, что вы всё делаете фактически хорошо - пусть заказчик и ваше руководство проверяют. Они в этом куда более заинтересованы. На этом месте мне вспомнился один из тезисов Владимира Тарасова, руководителя “Таллиннской школы менеджеров”. Тарасов много рассуждает, что в нашей профессиональной карьере, также как и на жизненном пути, определяющее значение имеют два умения, и нужно уметь их идентифицировать, и различать. А именно “умение быть” - то есть реально делать работу хорошо. И “умение казаться” - то есть производить впечатление хорошей работы. Какое из умений важнее? Вообще-то, “умение быть” - ибо важен в первую очередь результат. Но без “умения казаться” ваша хорошая работа рискует остаться незамеченной, и поддержку без него тоже получить непросто. А что произойдет, если ваше “умение казаться” существенно опережает ваше “умение быть”? Вы имеете все шансы произвести хорошее впечатление и пустить пыль в глаза. Но ваш головокружительный успех будет недолгим и, скорее всего, в длительной перспективе вызовет не менее головокружительное падение, если вы не дополните свое красивое “умение казаться” менее зрелищным, но более необходимым “умением быть”.
Итак, какое же резюме? Важны оба умения, и зазор между “быть” и “казаться” должен быть небольшим. Так вот, как показывает мой опыт, сложные и красивые документы и статусы, подтверждают в первую очередь именно “умение казаться”. И в моей жизни, увы, мне неоднократно приходилось видеть в организация красивые и грамотно написанные регламенты и отчеты, имеющие к действительности весьма смутное отношение.
Поэтому сегодня я хочу поговорить именно про развитие “умения быть”. То есть, как надо проектами управлять, чтобы продукты внедрялись, заказчики оставались довольными, команда была не взмыленной, функционал был именно тем, какой нужен. А не чтобы бумажки были красивыми. Вот про это “умение быть” руководителем проекта и пойдет здесь речь. Сразу оговорюсь, очевидно, что предлагаемый мною маршрут не является единственно верным и единственно возможным. И осуществим он только в условиях поддержки организации, а не так, как вот в этом комиксе.
И вообще, всё нижеизложенное - только мое скромное мнение. Дополняйте своими точками зрения.
Итак, как может расти руководитель проекта, и как будет выглядеть его тернистый путь профессионального развития?
Младший-джедай, подающий надежды
Как рассказал нам однажды Лев Новоженов на встрече с юными журналистами - человек, пришедший на телевидение, сначала должен несколько лет “мыть туалеты”, а потом уже предлагать идеи и, тем более, принимать решения. Потому что иначе подавляющее большинство его идей и предложений будут страшно далеки от реальности. Вот также и человек пришедший в управление 1С-проектами подкованный теоретическими знаниями, даже высококлассными, плохо подходит на эту роль. Гораздо правильнее и перспективнее сначала поработать в команде в роли бизнес-аналитика, разработчика, и т. п. И когда вы хорошо представляете внутреннее содержание проекта, технологию, бизнес-процессы и т. п., вы будете готовы к следующему шагу.
Какие навыки самые главные для РП-ученика-джедая?
- Знание прикладных решений
- Умение работать в команде
- Продвинутые навыки в своей сфере (аналитика/разработка - смотря из кого данный руководитель проекта пытается вырасти)
- Базовые навыки в смежных сферах (аналитика/разработка/администрирование)
Идеальная биография ученика-джедая предполагает получение опыта в двух вариантах: во-первых, работу в команде, где все работает достаточно четко и слаженно. Почему полезно начинать работу в крупных франчах с отлаженным бизнес-процессом (даже при довольно скромных условиях) - тогда четкая работа по технологии воспринимается как должное. А во-вторых, посмотреть, какие бывают проблемы и сложности - что увы, не всё бывает так гладко, как хотелось бы.
Падаван
Когда на ученика, подающего надежды, обращает внимание кто-то из рыцарей-джедаев (скорее всего, это спонсор проектов, принимающий решение об их запуске), он получает возможность расти и развиваться именно как руководитель проекта (разумеется, если он к этому готов и ему это нужно - по моему опыту, многие ИТ-специалисты относятся к руководящим должностям как к обременительной обязанности или неизбежному злу). Как я уже писала выше, хорошо бы вступать на этот путь уже обладая достаточным количеством технических навыков. И дальше постепенно набивать свои шишки - в идеале, в условиях поддержки более опытных наставников.
Какие навыки самые главные для РП-падавана?
- Всё то, что важно для ученика-джедая - никуда не делось
- Представление о том, какие бывают подходы к управлению проектами (чем проект отличается от техподдержки)
- Знакомство с технологией управления проектами (хотя бы одной, желательно - принятой в компании, если она есть)
- Базовое умение руководить людьми (умение завоевывать авторитет, умение делегировать задачи, контролировать)
- Умение договариваться - с бизнес-заказчиками, командой, руководством
- Умение управлять проектом в созданных для этого условиях
- Умение учиться и перенимать опыт. Одним из критериев, что падаван готов к переходу на следующий уровень, на мой взгляд, будет переход из стадии “Начинающего энтузиаста”, который уверен, что есть крутые методы, которые позволят всех победить в стадию “Утратившего иллюзии ученика”, который понимает, что легко и просто не бывает, и нет предела совершенству.
Рыцарь-Джедай
Начну с анекдота.
Встречаются двое коллег:
– Как твои успехи в управлении проектами?
– Я уже провалил три проекта!
– О, значит ты уже опытный руководитель проектов.
Известен факт, что инвесторы, выбирающие, в какой стартап вложить денег, смотрят в первую очередь не на проект, а на человека, его создающего. И самый перспективный стартапер - не тот, у кого это первая идея. Потому что он еще “не мыл туалеты” на телевидении. И не тот, у которого весь прошлый опыт усеян розами. Потому что он уверен в своей гениальности, и не имел шансов поучиться на ошибках. Но и не тот, кто завалил все проекты, за которые взялся.
У Роберта Шекли есть рассказ, в котором главный герой нанимает частного детектива, который спешит обрадовать нанимателя, что ему страшно повезло. Ведь он - частный сыщик высшей категории с самым высококлассным образованием. Но по независящим обстоятельствам, все 348 дел, которые он вел, были провалены. И совершенно очевидно, что эта череда нелепых случайностей должна, наконец, закончиться, и дело будет выиграно даже, если он ничего не будет предпринимать…
(сюжет дан в моем пересказе по памяти, если кто помнит первоисточник - поправьте).
Итак, идеальный стартапер с точки зрения грамотного инвестора - это тот, у которого был опыт успешных проектов (то есть его идеи представляют интерес для рынка), и опыт проваленных проектов (то есть он уже понимает, что не безгрешен).
Вот примерно так и выглядит хороший руководитель проектов. Он не совершает “систематической ошибки выжившего”, считая, что все его идеи верны по определению, и критически подходит к применению технологий, понимая что красивых планов, регламентов и документов категорически недостаточно для успешной реализации проектов.
Какие навыки самые главные для Рыцаря-Джедая?
- Умение применять (как минимум одну) технологию управления проектами в руководстве проектами, и уметь с ее помощью реализовывать проекты в срок, в рамках бюджета и к удовлетворению заказчика
- Опыт руководства, во-первых успешным проектом, во-вторых, проектом проваленным или столкнувшимся со сложностями
- Умение формировать и мотивировать команду
- Умение разрешать конфликтные ситуации с заказчиком
- Умение учиться на ошибках и совершенствовать свои компетенции от проекта к проекту
- Умение работать с большинством главных инструментов управления проектами:
- Устав - документ, закрепляющий договоренности с ключевыми участниками
- План проекта - создавать план, следовать плану, отслеживать отклонения и вносить необходимые коррективы
- Матрица ответственности - инструмент для определения, кто за какие задачи отвечает
- Ретроспектива - инструмент для сбора обратной связи и пополнения базы извлеченных уроков
- Отчеты по ходу работ - как известно, управлять мы можем только тем, что мы можем измерить
Мастер-Джедай
Чтобы стать мастером-джедаем мало достичь высокого мастерства, нужно суметь передать его дальше. Как известно, мастером-джедаем можно было стать, подготовив из падавана рыцаря-джедая. Вот и в управлении проектами похожая картинка - здесь важно не просто освоить технологию, которую вы применяете, а важно уметь передавать ее дальше, развивая управление проектами в компании.Магистр-Джедай
Магистр Джедай - это член совета джедаев. То есть это не просто тот, кто руководит проектами, спущенными сверху, а тот, кто способен принимать решение, какие именно ИТ-проекты нужно запускать. В проектном управлении, как известно, есть два уровня “do the thing right” - “делай вещи правильно” - про умение хорошо управлять проектами.
И уровень “do the right things” - “делай правильные вещи” - про умение хорошо выбирать, какие проекты стоит запускать. Потому что если продукт успешно внедрен, но не дал требуемого бизнес-эффекта - неуместно обвинять в этом руководителя проекта, это не его забота. А забота того, кто принимал стратегические решения - включить именно эти проекты в портфель проектов.
Гранд-мастер ордена Джедаев
Мифический персонаж, обладающий абсолютными знаниями в управлении проектами. В природе, насколько мне известно, не существует.Summary
Еще раз, краткое резюме основных тезисов:- Умение делать работу важнее умения красиво ее описывать. (“Быть” важнее, чем “казаться”). Но последнее тоже важно.
- Хорошие руководители проектов получаются из компетентных членов команд
- Стоит представлять не только свою сферу компетенций, но и смежные сферы
- Работа с командой важнее и сложнее работы с документами
- Поддержка организации крайне важна для успешного руководства проектами
- Опыт неудач и проблем столь же важен для развития, как и опыт успехов
- Нет предела совершенству.
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
Здравствуйте! Публикуем авторскую статью Дмитрия Котлова — сертифицированного 1С-специалиста, руководителя проектов, эксперта по технологическим вопросам. Также Дмитрий является автором и руководителем нового профессионального курса OTUS «Программист 1С», с программой которого мы приглашаем вас познакомиться.
Привет! В своей статье я расскажу о том, какие специалисты нужны для внедрения 1С, какие задачи они выполняют, какие компетенции нужны для качественного выполнения проекта. Отдельно и подробнее поговорим про требования к программистам.
Для начала перечислим позиции специалистов:
- Руководитель проекта
- Архитектор
- Консультант
- Программист
- Специалист по качеству (по тестированию)
Чем занимаются перечисленные специалисты?
Руководитель проекта
В зависимости от конкретной компании обязанности следующие:
- Составление плана проекта и контроль его реализации, могут быть различные планы: по срокам, по качеству, по финансам(бюджет)
- Взаимодействие с заказчиком по плану планам проекта
- Участие в продаже проекта
- Взаимодействие с командой проекта на предмет выполнения проекта и решения административных вопросов
- Координация выполнения работы и их приёмки
- Выбор оптимальных конфигураций 1С для решения задач клиента
Архитектор
В зависимости от конкретной компании обязанности следующие:
- Разработка и описание архитектуры 1С
- Участие в пресейлах
- Техническое руководство проектом
- Контроль качества разработки
- Выявление и управление техническими рисками проекта
- Оценка объёма работ
- Участие в разработке ТЗ, ЧТЗ, ТП, требований к архитектуре
- Организация процесса разработки
- Анализ качества продукта
Консультант
В зависимости от конкретной компании обязанности следующие:
- Консультирование по функционалу
- Участие в пресейлах
- Определение бизнес-требований, планирование подхода к работе с требованиями
- Выявлять, анализировать и документировать требования
- Доводить требования до заинтересованных лиц, управлять проверкой требований
- Обеспечивать расстановку приоритетов требований
- Ставить задачи программистам и принимать результат выполнения
- Проведение обучения
- Проведение приёмо-сдаточных испытаний, демонстрация продукта заказчику
- Сдача и согласование документации с заказчиком
Программист
В зависимости от конкретной компании обязанности следующие:
- Обновление информационных баз
- Реализация доработок в соответствии со стандартами разработки
- Участие в совещаниях
Специалист по качеству (по тестированию)
В зависимости от конкретной компании обязанности следующие:
Довольно часто этот функционал пересекается в одной позиции. Например, если в компании один программист 1С, не принято привлекать подрядчиков для выполнения проектов, тогда весь данный функционал ложиться на одного человека либо распределяется между ним и другими подразделениями, в рамках которых происходит внедрение продукта.
Далее подробнее разберём позицию «Программист»
Начнём с того, какие уровни программистов бывают. В каждой компании уровни программистов могут подразумевать разный уровень знаний и умений, зависящих от задач, которые будут стоять перед разработчиками.
Программист-стажёр — вакансия, как правило, подразумевает нулевой опыт работы с 1С, возможность интенсивно обучаться. Чаще всего такие вакансии есть в компаниях-партнёрах 1С.
- Установка программного обеспечения
- Обучение клиентов
- Участие в тестировании
- Участие в качестве ассистента во внедрении
- Программирование
- Прохождение обучения
- Сдача тестов и экзаменов на сертификацию
- Желание развиваться
- Общительность
- Инициативность
- Умение излагать свои мысли, грамотная речь
- Желателен опыт с 1С
- Желательно знание бухгалтерского учёта
Программист 1С – позиция подразумевает определённый опыт работы и отсутствие необходимости обучать специалиста программированию, т.е. на неё ведётся поиск людей, которые уже умеют программировать и могут самостоятельно решать задачи.
- Доработка конфигураций
- Разработка конфигураций под задачи компании
- Написание новых отчётов, обработок
- Интеграция 1С со внешними системами
- Обновление доработанных конфигураций
Ведущий программист 1С – специалисты, которые способны не только самостоятельно решать задачи, но и руководить другими программистами, а также подсказывать им оптимальные пути решения задач, осуществлять факторинг кода.
- Разработка нового функционала
- Подготовка сборок и релизов по выполненным задачам
- Настройка сервера 1С Предприятие
- Декомпозиция, распределение и постановка задач разработчикам
- Обновление не типовых конфигураций
- Оптимизация производительности 1С
- Разработка обменов данными между 1С и внешним ПО
Итак, в статье я описал наиболее часто встречающиеся обязанности и требования. Бывает и специфика, например, если по факту в компании отсутствуют аналитики, то зачастую программисты исполняют их обязанности.
Также, если вам интересно развиваться в данной сфере, не пропустите прямую трансляцию мастер-класса «Разбор стандартов и методик разработки на платформе 1С». Я расскажу о стандартах и методиках разработки 1С и покажу, зачем они нужны. А также вы сможете самостоятельно привести код в соответствии со стандартами и методиками 1С!
Выше я уже начала подводить итоги онлайн-воркшопа “Путь джедая”, прошедшего в конце мая на Инфостарте в преддверии старта Комплексного курса по управлению ИТ-проектами. Мы уже разобрали без чего не стоит вообще идти в РП, и чего нужно уметь, чтобы считаться опытным руководителем проектов.Мастер-джедай. Какие компетенции нужны ведущему руководителю проектов?
Уметь работать с командой проекта - причем на этом этапе я бы даже добавила “виртуозно”:- добывать ресурсы,
- проводить изменения в команде в ходе проекта,
- нанимать людей.
Про ресурсы я рассказывала в прошлой публикации, а вот про два последних пункта хочу поговорить немного подробнее.Умение проводить изменения в команде в ходе проекта
Как я уже писала раньше, некоторое время назад я сдавала экзамен Professional Scrum Master (PSM I), проверяющий умение работать по правилам фреймворка Scrum. Формат экзамена следующий - за 60 минут надо ответить на 80 вопросов на английском. Проверять себя, сверяться с первоисточниками, гуглить и т. п. формально не запрещено, но в таком формате успеть мало реально - ты либо знаешь “правила игры по Scrum”, либо нет. Так вот, один из вопросов, который мне запомнился в этом тесте был про то, можно ли изменять состав команды, и в частности добавлять в нее новых членов в ходе проекта?
Правильным ответом вовсе не будет “нет, ни в коем случае”. Ибо мы с вами живем в реальном мире, имеем дело с живыми людьми и неожиданно всплывающими обстоятельствами. Кто бы мне год назад рассказал, что сегодня, когда я пишу эту статью, в июне 2020 года, наш мир будет выглядеть так, как он выглядит сейчас - я бы решила, что это сюжет плохого фантастического фильма - кстати, одна популярный канадский кинокритик опубликовала рецензию на COVID-19, где наглядно показала нелогичность сценария и нереалистичность сюжета… Так вот, независимо от наших намерений делать проект постоянной командой, команда меняться будет. Что здесь важно иметь в виду (кроме того, что стоит постараться минимизировать эти изменения)?
Здесь я вспомню, во-первых, правильный ответ на вопрос теста на Scrum-мастера, упомянутого мною выше: “Изменять состав команды можно при необходимости, но имейте в виду, что это вызовет кратковременное уменьшение продуктивности”.
Во-вторых. вспомню так называемый Второй закон Брукса: “Если проект не укладывается в сроки, добавление рабочей силы задержит его еще больше”.
Почему же так происходит? Ответ более менее понятен. Приходится вводить новых людей в курс дела, объяснять вещи всем уже очевидные, это займет ресурсы старых, ухудшится взаимопонимание в команде, и так далее.На этом месте можно вспомнить стадии развития, которые проходит каждая команда (на русском их называют по-разному, но мне нравится вот такой перевод):
- формирование (команда существует только номинально),
- штормовое возмущение (идут ранговые разборки, борьба за власть и притирки),
- нормализация (договоренности о том, как выстраивать работу),
- выполнение (наконец-то)
- и расформирование (нас сейчас не очень заботит, до этого этапа еще дожить надо).
И беда в том, что при любых изменениях в команде группа, уже стабилизировавшаяся к этому моменту на продуктивном выполнении, откатывается на первые стадии и заново выстраивает там отношения.
В чем проблема - понятно. Теперь давайте подумаем, что можно сделать, чтобы неизбежные изменения в команде прошли как можно менее болезненно? Могу порекомендовать следующие меры:
- Максимально уменьшаем зависимость от того, что называется “bus factor” (автобусный фактор) - сколько человек из команды должно попасть под автобус, чтобы проект остановился? Стремимся к тому, чтобы информация была записана, а не хранилась в голове, чтобы на критичных участках могло работать несколько человек, а не один незаменимый, чтобы технологии передавались друг другу, а не оставались только у одного профессионала.
- Предпринимаем осознанные усилия по тому, чтобы при включении нового человека помочь команде в новом составе максимально быстро и безболезненно пройти первые стадии развития группы, в частности:
- Формирование - познакомить всех со всеми, организовать общение в неформальной обстановке и обсуждение, кто чем может быть полезен
- Возмущение - замечать назревающие конфликты между участниками и помогать их разруливать всем вместе (не гасить, пользуясь властью, а именно - вместе разруливать)
- Стабилизация - иметь записанные правила игры. Например, мы иногда использовали такой документ, как “Устав команды”, где в явной форме озвучены договоренности о принципах работы. Еще полезен такой документ, как “Матрица ответственности” (уже упомянутая мною в прошлой статье), где указывается, кто какими вопросами занимается и за какие задачи отвечает.
Умение нанимать людей
Про то, как определять потенциал людей уже в ходе найма - недавно наткнулась на интересный текст про набор , хочу процитировать:
Я отбирал своих сотрудников сам. Рассказав, как много придется у нас работать, как мало мы за это будем платить и какие высокие требования предъявляем, я предлагал маленький тест. Набор из двадцати семи кубиков, никак не скрепленных между собой. Игрушка для детей 2–4 лет. Из него можно сложить большой куб с гранями три на три так, чтобы все грани были одного цвета. Например, красного. Или желтого. Или синего. Показывал его потенциальному сотруднику … рассыпал кубики и отходил в сторону. Люди работают так же, как играют. Через пятнадцать-двадцать минут я понимал все.
… Человек, который собирает кубик того же цвета, который был изначально, более осторожен. Тот, кто выбирает другой цвет, — склонен к инновациям. И то и другое — нужные качества, но в разных ситуациях.
… Интересно наблюдать и за процессом. Кто-то сразу приступает к сборке и просто берет кубик с подходящими гранями. Кто-то сначала анализирует, отделяет кубики с тремя гранями нужного цвета для углов, с двумя для ребер и уже потом начинает строить. Когда-то давно, когда знакомый психолог подсунул мне эту задачку, я сам начал первым способом, а потом, после неудачи, перешел ко второму. Знакомо, правда? Сперва попробуем по наитию, вдруг «прокатит». Не прокатило? Тогда читаем инструкцию.
Все качества, проявленные в этой незамысловатой игре, нужны и полезны. Где-то надо вдумчиво анализировать, где-то быстро пробовать. Где-то нужна осторожность, а где-то бесшабашность, потому что если делать только то, что умеешь, ничему новому не научишься. Руководителю просто надо знать, какое дело кому поручить.
(фрагмент текста от экс-руководителя компьютерной сети КЕЙ Олега Вайнберга)Это я не к тому, чтобы всем закупиться кубиками Никитина и проверять на них сотрудников. А к тому, что по поведению человека на грамотно проведенном собеседовании, на тестовом задании, на первом проекте в рамках испытательного срока и т. п. можно многое про понять про его потенциал. Ну и осознать, насколько стоит с ним связываться.
Как можно развивать этот навык?- Различные курсы, тренинги и литература по HR
- На Инфостарте, в частности, проходит курс "Оперативное управление персоналом", его ведущую Елену Дуюн искренне рекомендую - сама у нее училась.
Развивать людей в команде
В частности, быть наставником, уметь вдохновлять и хвалить членов команды. (кстати, навык “эффективно наказывать”, который я, если честно “вбросила” для оживления дискуссии был признан вредным - и да, соглашусь с этим - “кнут” хотя и может помочь “на короткой дистанции”, в перспективе обычно в большей степени демотивирует, чем поддерживает)
А поговорить я немного хочу про умение хвалить и вдохновлять
На самом деле, это гораздо важнее (а для многих - и сложнее) чем технические навыки. И для того, чтобы вдохновлять нам опять пригодится тот самый эмоциональный интеллект, про который я говорила в прошлой статье, только уже на следующем этапе - понять, что человека мотивирует, и создать максимально подходящие условия для реализации того, что людям необходимо.
А умение замечать позитивные шаги и говорить об этом - в российской практике мало принятое, и тоже помогающее создать рабочую команду.Как можно проверить, что руководитель умеет вдохновлять свою команду?
Один из способов оценки, который был предложен в ходе дискуссии - независимый опрос сотрудников, средняя оценка удовлетворенности/"счастья" у членов команды, наличие у команды понимания цели и желания дальнейших действий, в том числе идти командой на другие проекты (мотивацию на совместную работу трудно создать, но легко поломать). Здесь, конечно, далеко не все зависит от РП, но многое (если он действительно лидер в команде).
Как можно развивать этот навык?
- На Курсах по управлению ИТ-проектами мы затрагиваем эту тему, как минимум разбираем виды мотивации, способы выдать эффективную обратную связь, методы развития команды и т. п.
- А дальше - здесь будут полезны ресурсы и инструменты, имеющие отношение к практической психологии, к бизнес-психологии.
Уметь отказываться от провального проекта
Честно скажу, на мой взгляд, это важно уметь не только ведущему РП, а начинающему РП особенно - ибо на них часто пытаются вешать заведомо "провальные" истории. Выпускники моих курсов знают мой любимый афоризм “Ты сильный, ты справишься - нет, я умный, я даже не возьмусь” - и мы начинаем разбирать в какой ситуации нужно бежать сверкая пятками уже в начале базового курса).
Проводить бизнес-анализ. Эти навыки упоминаются и раньше, но для опытного РП они признаются действительно необходимыми.
Как можно проверить, что бизнес-анализ от РП корректен? Участники воркшопа озвучили следующие критерии:
1. РП может описать бизнес-процессы "Как есть", и это описание понятно всем участникам проекта, причем владелец БП должен подтвердить корректность описания. Нередко проектная команда ждет от бизнес-заказчика, что они сами опишут процессы, и выдадут их в разработку с разъяснениями, что надо делать.
2. РП способен увидеть узкие места в процессах и простым понятным языком аргументированно донести до всех, почему именно эти места узкие.
3. В начале работы (да-да, именно в начале, а не перед сдачей результата бизнес-заказчику. ) стоит составлять таблицу с критериями, чего хочется получить при перестройке бизнес-процессов (минимизировать действия не несущие ценности клиенту, упорядочить хаотичный порядок согласования документооборота и т. п.). В таком случае в конце можно сверить результат с критериями и понять, соответствует ли он заявленным требованиям.Работать на уровне “программы” и “портфеля” проектов
Что имеется в виду?
Согласовывать проекты со стратегией компании (для этого, честно скажем, надо, чтобы стратегия у компании была, причем желательно была измеримой - тогда можно использовать какие-либо метрики).
Считать рентабельность проекта. Здесь можно много копий сломать на тему, а можно ли вообще рентабельность проекта посчитать. (в первую очередь - ROI (возврат инвестиций), метод освоенного объема и план-фактный анализ по итогам проекта), защищать проекты.По мнению участников дискуссии, признаком профессионализма здесь может считаться умение по итогам первичного анализа убедить заказчика согласиться на проект (вместе с суммой и всеми условиями). Для этого нужно, во-первых, уметь хорошо все просчитать, а во-вторых, владеть еще и умением управлять ожиданиями заказчика.
Быть честным с заказчиком
На тему умения “быть честным с заказчиком” много копий уже сломано и еще сломано будет. Не буду здесь спорить с тезисом, что “вешать лапшу на уши заказчику может быть выгоднее!”, а просто призову всех читателей этой статьи быть в первую очередь честными с самим собой. Тогда жить и работать становится куда приятнее. И напомню старый добрый тезис, что увеличение прозрачности способствует усилению доверия, и, как результат, более слаженной работе сторон. И если вы хотите, чтобы вам больше доверяли - хорошо бы, чтобы у вас не получалось как в истории, которую описал Григорий Орлов в своей книге “Джедайские техники конструктивного общения”:
- Как нам повысить уровень доверия в отношениях с заказчиком? — было видно, что слушательницу серьезно волнует эта проблема.
— А что сейчас не так с уровнем доверия?
— Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам…
— А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.
— Понимаете… Мы ему джуниор-инженеров продаем как синьор-инженеров… И нам не хотелось бы, чтобы он обнаружил этот факт.
Вместо заключения
Комментировать эти вопросы здесь не буду, так что за ответами приходите на Комплексный курс по управлению ИТ-проектами - ближайший набор закрывается уже на этой неделе. Не обещаю, что ответы достанутся вам на блюдечке с голубой каемочкой, но будем их вместе искать.Читайте также: