Как прокачать руководителей проектов внедрения? Опыт Инфостарта

 

 

Мы с вами живем в эпоху перемен, когда все непредсказуемо меняется – мы вынуждены адаптироваться к этим изменениям, менять проектные технологии, менять подходы к выполнению работы и подходы к оценке проектов.

Расскажу про опыт Инфостарта – как прокачать руководителей проектов внедрения и научить их адаптировать разные подходы управления проектом к реальным рабочим ситуациям.

 

 

Думаю, что все обратили внимание, что секция у нас теперь называется «Управление проектом и продуктом».

Есть два подхода, которые немного иногда конфликтуют между собой – недаром я здесь вставила картинку боксерского поединка.

Например, я ни разу не видела, чтобы в одной компании был и развитый проектный офис, и развитый продуктовый офис.

• Проектный офис: Не знаю, с чем это связано, но те, у кого есть проектный офис – обычно люди четкие. У них четкие графики, четкий KPI, завязанный на какие-то цели. У них с точки зрения организации проекта все очень четко и дисциплинировано.

• Продуктовый офис: А те, у кого продуктовый офис – они, наоборот, люди более творческие, настроенные на какие-то глобальные бизнес-цели. Границы у них размытые, вместо четких графиков абстрактные дорожные карты развития. Почему-то получается так.

 

Эти подходы отличаются, в первую очередь, фокусом внимания.

Когда мы говорим про управление проектом, у нас:

• есть старт внедрения, когда мы начали внедрять продукт;

• у внедрения есть четкий план;

• и в конце – завершение, когда мы выдаем нашу информационную систему заказчику на блюдечке с голубой каемочкой, а дальше эксплуатация системы переходит в операционную деятельность

А когда мы говорим про управление продуктом, у нас фокус внимания на всем жизненном цикле. Мы понимаем, что внедрение не закончится, оно будет продолжаться на протяжении всего срока использования продукта. Это происходит из-за того, что у нас очень сильно изменяется бизнес-контекст и окружающая среда. Я думаю, последние несколько лет нас всех научили тому, что продукт теперь все время будет изменяться.

 

 

Какие же конкретные изменения проявляются на практике при изменении подхода?

Я наблюдаю сейчас некоторые тренды плавного перехода от проектного управления к продуктовому. Поэтому перечислю несколько признаков, которые я замечаю, в разных компаниях – и во внутренних проектах, во внешних.

• Первый признак – стирается граница между внедрением и сопровождением. Мы знаем, что ремонт, который начат, невозможно закончить, можно только прекратить. Так же и внедрение – система никогда не будет готова. Нужно понимать, что это будет так.

• Следующий момент – все чаще нам радикально сложно в начале проекта внедрения ответить на вопрос, сколько это займет времени и сколько это будет стоить. Потому что бизнес-заказчик не всегда может сам толком объяснить, что ему нужно – он это в процессе будет объяснять. И при продуктовом подходе в этих условиях нам работать немного проще, потому что там нормально что-то уточнять это в процессе. Поскольку жестких границ нет, мы всегда можем добавить еще по доп. соглашению какую-то итерацию, чтобы еще какую-то функциональность доделать.

• Очень часто на внешних проектах договор сразу заключается и на внедрение, на сопровождение. Это упрощает какие-то разборки, когда бизнес-заказчик боится подписывать акты, переживая, что после подписания актов исполнитель уйдет, и мы останемся с системой, которая не обладает какой-то очень важной и нужной нам функциональностью.

• Плюс, если мы понимаем, что команда исполнителя останется с нами и после внедрения, страхи бизнес-заказчика тоже уменьшаются. Поэтому есть тенденция, что одна и та же команда ведет и внедрение, и сопровождение – возможно, в немного уменьшенном составе.

• В последнее время ТОП-менеджмент все больше настроен на долгосрочную перспективу – не просто внедрить 1С:КА или 1С:ERP, потому что так сделали конкуренты, а уже появилось понимание, зачем это нужно.

• И от команды внедренцев тоже ждут консалтинга – объясните, что нам нужно, что мы выиграем, зачем это будет использоваться, какие будут бизнес-цели в итоге достигнуты.

 

 

На самом деле руководителю нужны и навыки управления проектом, и навыки управления продуктом.

Я на Инфостарте веду несколько курсов:

• Курс, ориентированный на управление проектом – «Продвинутый курс по классическим методам управления проектами», где мы разбираем документацию, как вести проект;

• «Практический курс Agile-лидера», где мы разбираем, как управлять продуктом и командой, которая с этим продуктом работает.

То и другое востребовано, то и другое актуально.

На этом месте мы, наконец, перемещаемся к конкретике моего доклада – как же прокачать руководителя проекта внедрения.

 

 

Про себя я подробно рассказывать не буду. Думаю, все меня более-менее знают.

Для этого слайда я подобрала фотографии, иллюстрирующие лозунг:

Помните, что руководителю проекта приходится решать разнородные задачи. И будьте к этому готовы!

 

 

Чем я хочу поделиться?

• Я на Инфостарте занимаюсь консалтингом и обучением руководителей проекта, и как минимум тысячу руководителей проектов автоматизации уже обучила. На какие-то грабли мы уже понаступали, и я думаю, этот опыт может оказаться полезным

• Поскольку эти курсы используются как корпоративный университет самого Инфостарта для наших руководителей проекта, я вижу, как их прохождение влияет на работу.

• Для тех, кто хочет прокачать уровень руководителей проектов у себя в компании, дам несколько советов, как выстроить обучение и организовать повышение компетенции.

 

Нужно ли обучать руководителей проектов или нанимать новых?

 

 

Первый вопрос, который возникает – стоит ли вообще руководителей проектов учить?

Представим себе, что вы – бизнес-руководитель или ИТ-руководитель. И вас не устраивает, как ваши руководители проектов ведут проекты. У них планы не соответствуют реальности или вообще нет планов, или все графики уезжают. Они все делают не так – у них заинтересованные стороны недовольны, заказчики недовольны.

Может быть, стоит просто отказаться от услуг этих руководителей проектов и сразу нанять правильных грамотных умных, которые будут делать то, что нужно?

Чтобы ответить на этот вопрос, я хочу сделать маленькое лирическое отступление.

 

 

У Джима Коллинза есть книга «От хорошего к великому», где он вместе с командой анализировал опыт компаний, которые сумели стать великими.

Обязательным условием попадания компании в выборку, которая анализировалась в книге, было не просто то, что она стала великой, а то, что она осталась великой и после смены руководителя. То есть там не просто появился один харизматичный лидер, после ухода которого всё развалилось, а был настоящий руководитель, сумевший выстроить процессы так, что компания продолжила быть великой и известной и после смены руководства.

Книга, конечно, спорная – тот же Нассим Талеб критикует Коллинза, что он совершает «ошибку выжившего» и путает местами везение с закономерностями. Но на самом деле некоторые тенденции и закономерности в этой книге увидеть можно, я ее рекомендую для анализа.

Для начала, выскажите, пожалуйста, вашу версию: как вы считаете, по результатам исследований Коллинза, кто в большей степени чаще всего приводил компании к успеху и помогал им стать великими?

• Люди, которые выросли с низов компании и доросли до позиции управленцев?

• Или, наоборот, приглашенные управленцы, которым объяснили контекст, поставили задачу, они были изначально компетентны как управленцы и смогли уже организовать работу так, чтобы компания стала великой?

 

 

В большинстве случаев оказалось, что лояльность к компании, понимание какого-то внутреннего бизнес-контекста оказалось более важным, чем внешние компетенции.

И как раз управленческим компетенциям научить людей оказалось возможно, а добиться того, чтобы внешние управленцы понимали контекст изнутри – это оказалось уже сложнее.

Поэтому ответ на мой вопрос – лучше самим учить руководителей, чем нанимать людей со стороны.

 

 

Иногда говорят – а вдруг мы обучим сотрудников, а они уйдут?

Но на мой взгляд, гораздо большая опасность – вдруг мы их не обучим, а они останутся. Лучше стремиться этой опасности избежать.

 

Пять ингредиентов успешного корпоративного обучения руководителей проектов, которые точно стоит применять

 

 

Часто попытки корпоративного обучения не эффективны.

• Люди жалуются, что сотрудники не замотивированы учиться.

• Потом эти знания оказываются не нужны, неприменимы.

• В том же корпоративном университете Сбербанка руководители мне жаловались, что прохождение курсов включают в KPI, в итоге результаты тестов гуляют по сотрудникам, люди не смотрят материалы, проходят тесты, получают свои KPI и бонусы. А как бы все это вообще мимо.

Почему так происходит? Почему обучение часто не срабатывает?

 

 

Оказывается, есть целая наука об обучении взрослых разумных людей. Она называется андрагогика. Беда в том, что со взрослыми стандартное обучение за партой не работает.

Есть несколько принципов, которые сформулировал Малькольм Шеферд Ноулз, один из основоположников андрагогики.

 

 

Я могла бы сказать, что познакомилась с идеями Ноулза и после этого поняла, как нужно выстроить обучение. Но на самом деле, было наоборот – я выстроила обучение так, как мне показалось логичным, а потом познакомилась с идеями Ноулза и поняла: «О, так вот почему оно работает».

Зато теперь я могу говорить, что эти пять ингредиентов успешного корпоративного обучения руководителей проектов, которые точно стоит применять, придумала не я сама.

Давайте попробуем разобрать их подробнее.

 

Ингредиент №1. Ведущий – ученик

 

 

Первый компонент нашего рецепта заключается в том, что ведущая роль в обучении должна принадлежать тому, кто учится – не преподавателю, а именно ученику.

 

 

Если рассматривать пирамиду обучения, то лекции в ней должны составлять около 20 процентов. Поэтому и курсы, которые я веду, построены похожим образом.

Каждая тема, допустим:

• как запускать проект;

• как планировать проект;

• как управлять рисками;

• как управлять командой;

включает разные компоненты. И только небольшой кусочек – видеолекции и тесты – это то, что я выдаю вовне.

А все остальное делает сам ученик:

• Он делает индивидуальные задания на основе кейсов.

• Он отвечает и комментирует ответы коллег.

• Он встречается с командой и вместе с командой делает какой-то проект.

• Даже вебинары проходят не так, что я что-то вещаю, а люди внимают (так только видеолекции проходят, потому что по-другому они не могут проходить). На вебинарах люди рассказывают про свой опыт – я его комментирую, задают вопросы – я на них отвечаю и т.д.

 

 

Основой курса являются самоорганизующиеся команды, которые сами решают, как им работать.

Мы используем фреймворк eduScrum – это такой Scrum для обучения. Мне в нем нравится дополнительный этап, когда команда планирует, как она будет работать на курсе. Я советую его использовать всегда, не только в обучении.

В Scrum есть такое понятие, как Definition Of Done – определение готовности, а в eduScrum есть понятие Definition Of Fun – то, что делает совместную работу интересной:

• кому-то важна возможность разобрать свои кейсы;

• кому-то важно собрать много разных точек зрения;

• кому-то важно попробовать себя в роли лидера.

Вы уже знаете, что люди продуктивнее работают, когда им интересно. Это важный момент – люди, которым надоела их работа, даже если им хорошо платить, они не будут делать свою работу с душой.

 

 

На слайде показан пример командных договоренностей одной из команд на курсе.

После обучения люди берут эту практику к себе в работу – в начале проекта собирается команда и определяет, какие у них будут командные договоренности, как они будут работать.

Это тоже помогает им потом продуктивно работать.

 

 

Команда дает:

• Некоторый эффект совместного творчества.

• Дополнительную мотивацию. Например, когда люди приходят на курс, они настроены доучиться до конца. Они говорят: «Мы пришли учиться, мы заплатили, нам нужен сертификат, нам нужны знания». Но в процессе какие-то рабочие задачи обычно накатывают, и многим бывает трудно пройти программу обучения целиком. Практика показывает, что, когда человек ощущает ответственность перед командой, понимает, что его результат нужен, чтобы команда могла сдать проект или продукт и получить результат, он в большей степени, несмотря на какие-то отвлекающие факторы, дойдет в курсе до конца. Почему мы знаем, что в большей степени? Потому что до того, как мы ввели командные задания и работу по командам, люди чаще отваливались посередине. То есть команды реально помогают пройти обучение до конца.

• Ну, и возможность проявлять какой-то креатив тоже помогает. Например, на слайде показана презентация командного проекта – пожалуй, одна из самых креативных презентаций. Команда сообщила, что они называются «Четыре капитана», и рассказали, как они при помощи рома искали сокровища. Выглядит в такой немножко игровой форме. На самом деле, люди представляют результат проекта внедрения системы электронного документооборота в сфере трудовых отношений на базе 1С:ДО, и к их пакету документов не никаких претензий, вопросов нет – серьезный документ. Просто они смогли организовать свою работу в каком-то живом формате, и за счет этого усвоение материала оказалось лучше.

 

 

Ну, и по итогам формируется понимание – что нравится, чему научились, что получается.

 

Ингредиент №2. Цели ставит ученик

 

 

Второй ингредиент заключается в том, что важно отталкиваться от целей, которые ставит сам ученик.

 

Мы в начале курса собираем цели.

На слайде мне больше всего нравится цель «Обретение дзен в проектах» – я не уверена, что сама ее достигла.

 

 

В конце курса смотрим – достигли ли мы цели.

 

Отдельно люди проводят самооценку своих компетенций.

Здесь используется модель от PMI – какие компетенции в сфере людей, процессов и бизнес-окружения должны быть у руководителей проекта.

Почему самооценка? Потому что тестами мы можем фактически оценить только знания – знает ли человек виды рисков.

А то, насколько человек может реально запускать проекты, создавать команду, вовлекать заинтересованные стороны – это можно оценить только экспертно.

Люди оценивают сами, насколько у них развит тот или иной навык, и насколько он для них важен.

Естественно, это стоит дополнять либо оценкой 360, либо просто опросом коллег. Потому что, если вы считаете, что у вас хорошо с компетенцией, а коллеги считают наоборот, то это лишний повод задуматься – а как же обстоят дела на самом деле?

 

 

И, опять же, технологию тоже могут выбирать сами слушатели – кому какая актуальна. Потому что очень часто один и тот же проект можно внедрять по разным технологиям.

 

На последнем потоке курса лидирует «1С:Технология быстрого результата», поскольку она, с одной стороны, предлагает шаблоны документов, с другой стороны, там их не так много.

Кстати, для внутренних проектов тоже можно использовать и «Технологию корпоративного внедрения», и «Технологию быстрого результата».

 

 

Опять же, бывает, что для одного и того же типа внедрения – например, 1С ERP:

• Одна команда разрабатывала пакет документов по «1С:Технологии корпоративного внедрения», когда нужно подробное ТЗ с одной поставкой в конце.

• А другая команда рассмотрела вариант внедрения по 1С ТБР, с возможными поставками по кусочкам.

Можно и так, и так.

 

Ингредиент №3. Отталкиваемся от жизненного опыта ученика

 

Нам важно отталкиваться от жизненного опыта и профессиональных умений тех, кто учится.

 

Например, «Базовый курс по управлению ИТ-проектами» начинается с моего любимого задания-загадки.

• Я рассказываю людям, какие бывают подходы к управлению проектами – модель Кеневин, матрица Стейси. И дальше прошу людей описать какой-то проект из их опыта, не употребляя слов «Водопад» и «Agile» и так далее. Рассказать, как проект проходил, и какие были проблемы.

• Окружающие должны угадать, по какой модели проект управлялся, а по какой стоило управлять.

• Потом сами авторы вопросов выдают свою версию, я тоже комментирую.

• В итоге у участников появляется понимание, как подход к управлению проекта повышает шансы на его успех.

И отдельный момент – кросс-рецензирование:

• слушатели тоже комментируют ответы друг другу;

• это позволяет посмотреть на ситуацию со стороны;

• сравнить опыт разных людей;

• и получить больше обратной связи, чем если бы только преподаватель выдавал бы ответы;

• за счет кросс-рецензирования уменьшается нагрузка на преподавателя и на курс можно взять больше слушателей

 

Ингредиент №4. Применение на практике

 

 

Обучающемуся должно быть понятно, как применять знания на практике. Ну, для этого важно, чтобы в обучении использовались конкретные инструменты, которые дальше можно взять в работу.

 

 

Например, дорожная карта проекта – что и когда мы делаем.

 

 

Или очень интересный инструмент – оценка удовлетворенности. Допустим, вы в течение проекта поставляете промежуточные результаты, вы их демонстрируете заказчику и проверяете, насколько заказчику это нравится и насколько команде с этим комфортно работать.

• Здесь, например, видно, что, допустим, с первой по четвертую неделю работы команды и в двенадцатую неделю работы команды все было замечательно, все довольные.

• А в шестой неделе у двоих стиснутые зубы – явно им было непросто.

• На восьмой неделе даже у троих стиснутые зубы.

Если проанализировать, что происходило на проекте в эту итерацию, то можем понять, в чем дело. На практике, конечно, к этим личикам нужны обычно комментарии, что именно так, что именно не так.

 

 

Отдельный мой любимый инструмент – Lean Requirements Workshop. Про него я проводила отдельный доклад.

По-русски, Lean Requirements Workshop – мастерская по сбору требований.

Это когда разработчики и бизнес-заказчики садятся вместе и вместе обсуждают языком пользователей, языком бизнес-заказчиков, что вообще нужно сделать и как это реализовать.

По итогам получается ощущение единой команды. Не противопоставление – мы заказчики, и вы вообще ничего не понимаете. А некоторая общая команда. Так работать гораздо продуктивнее.

 

Ингредиент №5. Совместная деятельность педагог+ученик

 

И последний важный ингредиент – совместная деятельность педагога и ученика. Обучение должно быть результатом совместной деятельности.

Например, когда мне задают сложный вопрос, я вместо того, чтобы давать свою версию, я предлагаю самим ученикам этот вопрос и обсудить.

 

 

Здесь, например, результаты мозгового штурма на нашем курсе.

Подняли проблему: «Что делать, если заказчик постепенно теряет интерес к проекту». И высказали разные идеи, разные предложения, что можно в такой ситуации сделать. Выбрали самые интересные из них.

Таким образом, коллективный разум учеников на самом деле больше выдал задавшему вопрос, чем если бы я просто поделилась только своим опытом.

 

 

Ну и выбирать, какие инструменты использовать, тоже могут сами ученики.

На этом скриншоте по «1С:Технологии быстрого результата» команда определяет, какие документы им понадобятся.

Кстати, в проектной команде тоже возможна ситуация, когда команда проекта или команда управления проектом сама понимает, какие документы им необходимы, потому что очень часто это не регламентируется корпоративными правилами.

 

 

Здесь аналогично – только по PMI (PMBOK) выбирают документы.

Меня, например, удивило, что «Реестр извлеченных уроков» не вошел в список документов, которые используются. Но это тоже выбор команды.

 

На этом слайде вывела еще раз все принципы, которые мы разобрали.

Главный момент – чтобы у ваших руководителей проекта и у вас, как у руководителей проекта, была мотивация что-то делать, добиваться результата, и это позволит свернуть горы.

 

Вопросы

 

Вы говорили, что взрослых нужно обучать не так, как детей – им нужно отдавать ведущую роль в обучении. В какой момент проходит процесс перехода от парты к роли ведущего в обучении? Это возраст или какая-то зрелость? По каким критериям можно понять этот переход?

Понятно, что границы всегда размыты. Общая идея – когда человек в позиции: «Я не знаю, чего я хочу, я пришел как студент в институт» – это позиция ученика.

Когда человек работает, выполняет какие-то задачи, хочет повышать квалификацию в рамках тех задач, которые он выполняет – это позиция взрослого.

На самом деле, можно и в 50 лет пойти в институт, а можно в 18 лет уже понимать, что я хочу, в чем я повышаю квалификацию.

Граница в этом месте – я повышаю квалификацию в тех вопросах, которые решаю на рабочем месте.

Вы говорили, что наиболее эффективно проводить обучение в группах. Есть ли смысл проводить индивидуальное обучение в заочной форме, когда мы нашим молодым специалистам даем в курсе определенный набор лекций, который они проходят и нам уже досдают? Или все-таки нам нужно собирать в кучу этих молодых специалистов и совместно с ними проводить?

Понятно, что у нас всегда есть желание, есть возможности, и есть контекст, что мы можем, что получается. И желания не всегда совпадают с возможностями.

Но, если возможности есть, я рекомендую включать в обучение, в том числе, какие-то командные групповые задания, когда люди либо по рабочим группам, по которым они работают, либо, наоборот, по каким-то разделенным, вместе работают над задачами. Это, по моему опыту, заметно повышает продуктивность обучения.

Есть ли смысл вообще студентов, которые учатся в институте, учить проектному управлению?

Я считаю, что основам проектного управления стоит учить вообще всех.

Я однажды видела некий тренинг по проектному управлению для детей дошкольного и младшего школьного возраста. На научной выставке был стенд. Это выглядит смешно, но это правда реально так и было, хотя этих слов там не было.

Был стенд, на котором предлагалось:

• сконструировать какой-то корабль, который будет плавать, преодолевать пороги – было смоделировано место для корабля;

• нужно было составить проект, определить требуемые ресурсы;

• получить эти ресурсы;

• построить модель;

• протестировать модель;

• и выпустить в промышленную эксплуатацию.

По сути, идея была в том, что ты сначала составляешь план проекта, потом его реализуешь и потом – обязательно тестируешь. Эти навыки полезно приобретать в любом возрасте, хотя, конечно, применительно к рабочим задачам это будет усваиваться лучше и эффект будет выше.

На одном из слайдов были показаны компетенции для выполнения проектов по 1С:ERP в терминологии PMI. Так вот, компетенции планирования, определения ресурсов, составления сетевого расписания – их можно освоить в любом возрасте. А все, что про управление конфликтами – только на практике.

Мы же в контексте внедрения информационной системы, обсуждаем все это – в каком возрасте появится у человека вообще осознанность для того, чтобы управлять внедрением информационной системы?

Понимание, как управлять проектом, как работать с проектом, полезно не только для руководителя проекта, а для проектной команды целиком.

Если люди понимают, как это вообще должно выглядеть, и с таким пониманием приходят в команду, это лучше, чем когда такого понимания нет. Поэтому джунам, рядовым аналитикам, рядовым разработчикам тоже полезно понимать, как это работает.

А когда мы влезаем в Agile, там это еще более полезно, потому что там на всей команде лежит ответственность.

Вопрос в том, что у нас реально сложная отрасль. У нас специалисты должны обладать знаниями отраслевой специфики, знаниями управления проектов, пониманием, как работает наша платформа. В каком возрасте это все можно освоить – начинать же нужно с чего-то малого, да? Как бы вы рекомендовали – сначала идти в аналитики, а потом в РП? В программисты, а потом в РП? Или сначала в программисты, потом в аналитики, потом в РП? Или можно сразу в РП по вашему мнению, но при этом, возможно, с какими-то рисками? Какой путь по вашему мнению будет оптимальным?

Я бы сказала, что успешные пути складываются по-разному, но самая распространенная схема – сначала аналитик, потом РП.

Все-таки правильно, чтобы РП знал предметную область – к вопросу про Джима Коллинза. Совсем управленец, который вне контекста, будет не так эффективен.

Прецеденты бывают, когда он в связке с техническим спецом, но это скорее от безвыходности ситуации. Конечно, лучше сначала понять, как работает предметная область из рядовой позиции, а потом уже идти в руководители проекта. Но когда у человека есть хоть какие-то навыки разработчика или хоть какие-то навыки аналитика – это лучше, чем когда совсем никаких нет. Когда у аналитика немного навыков разработчика, а у разработчика немного навыков аналитика – они хотя бы понимать друг друга будут лучше.

Как все-таки избежать этого эффекта наблюдателя – когда начинают какой-то параметр оценивать, и все это сваливается в работу на этот параметр. Ну и точно так же, как и в оценке коллег – как только коллеги узнают, что другие коллеги оценивают их для руководителя, соответственно, начинается работа на публику, на этих коллег. Как этот эффект избежать?

Я вам могу сказать направление, к которым стоит двигаться, но, к сожалению, какого-то простого и легкого сценария, как этого добиться, я не расскажу.

Направление такое – когда мы ориентируемся на ценности, а не на KPI, чтобы людям было важно сделать проект, чтобы он был нужен, чтобы успешная реализация проекта была нужна для достижения личных целей. Человек понимал, что ему нужны эти знания, да, ему нужны эти компетенции, он хочет, чтобы этот проект был успешным.

Когда человек действительно хочет именно результата, он гораздо больше будет вкладываться на результат, чем когда он хочет просто соответствовать каким-то KPI.

Почему я тоже говорю про Definition Of Fun, про личные цели, про мотивацию? Потому что мы стараемся, чтобы человеку самому это было нужно. Если нам удается этого добиться, все работает гораздо лучше. Примерно так.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции  Infostart Event 2022 Saint Petersburg.