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

Тема не о чем. Эти дела кодера вообще не касаются. Это тема для РП и руководства фирмы. В конце концов сумма 50-60 тыс., если проект стоит несколько лимонов- копейки

(0) Не совсем понятно к кому обращен вопрос "что с этой проблемой делать?" - к исполнителю, руководителю проекта или заказчику.

Если речь про исполнителя, то его дело маленькое - заявить РП о просчете ДО того, как приступить к исполнению или как можно раньше, если работы уже начаты. Если РП принимает решение о том, что делать всё равно нужно, то он тем самым обязуется оплатить работу исполнителю (ну или они как-то обговаривают этот момент). Если нет - тут уже вопрос решается индивидуально в зависимости от того, сколько уже фактически потрачено на работу, которая сдана заказчику не будет (поэтому важно известить РП о косяке как можно раньше).

Если речь про РП - его задача включить талант продавца и бежать к заказчику с тем, чтобы пересогласовать заново стоимость проекта и новые сроки, графики и планы. Тут возможны несколько вариантов. Заказчик может отказаться от требуемого функционала вообще, если он не критичен или его можно как-то иначе реализовать. Заказчик может согласовать какой-то иной менее трудоёмкий способ решения, который уложится в оговоренное ранее время. Заказчик может встать в позу и отказать что-либо оплачивать сверх того, что прописано в договоре. В последнем случае, если никак не удаётся убедить заказчика, РП придётся принимать сложное решение - как не обидеть исполнителя и чтобы заказчик был доволен. Если проект состоит из множества этапов, то просчет "в минус" на одном из этапов можно нивелировать за счет просчетов "в плюс" на другом. Для этого трудозатраты рассчитывают всегда с хоть каким-нибудь запасом.

Если речь про заказчика, тут относительно просто. Заказчик либо может пойти навстречу РП и войти в положение, либо встать в позу и требовать строгого соблюдения бюджета и сроков. В последнем случае он будет в своём праве и с формальной точки зрения продавить его довольно сложно. В особенности если предпроектное исследование и планирование было оплачено отдельно и заранее.

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

(113) // Про походы к директору - спасибо, поржал, для директора это самый важный вопрос=)

Ну если из-за такого прое@а от РП регулярно разбегаются все Разрабы, то как-то и директору придется подписывать заявления или на перевод или на увольнение.

(109) > если исполнитель не общается с заказчиком,... он просто не сможет нормально выполнить задание.

Чушь. Исполнитель не должен вообще общаться с заказчиком. Для этого есть РП.
Максимум на этапе сдачи-приемки, где требуется какое-то обучение пользователей или сложная демонстрация результатов.

> в процессе выполнения появится столько вопросов, что замучаешься отвечать.

Вот пусть РП на них и отвечает. Он должен быть в теме. Только у него есть понимание - что и для чего нужно в проекте.

Как только Заказчик начинает напрямую общаться с Исполнителем проект превращается в полное *авно, где заказчик выворачивает идею проекта с ног на голову, начинает выдумывать какие-то свои требования. Не говоря уже о случаях, когда внедрение проекта связано с перестроением бизнес-процессов, а заказчик продолжает по инерции требовать реализовать старый бизнес-процесс потому что "мы так всегда делали" и "нам так надо!".
Потом после такого "общения" исполнителя с заказчиком приходит РП и понимает, что вся модель проекта начинает накрываться женским половым органом потому что заказчик с программистом занимаются расстановкой кнопочек на форме "как было раньше" и рисованием отчетов, которые делали последние 10 лет, не зная, что отдел-получатель этих отчетов складывает их в мусорное ведро.

(52) У меня вся схема расписана вроде на достаточном для однозначного понимания уровне. Какие могут быть еще вопросы?

(116) хрень какая то.
Если это вопрос компетенции разраба то по решению рп просто выплачивается 8 часов и все, если это проблема в коммуникации между рп и разработчиком, то здесь можно и позвать кого то разрулить вне конфликта

Незаменимых нет,)

(116) > если из-за такого прое@а от РП регулярно разбегаются все Разрабы.

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

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

(119) Такая же эскалация, как и при конфликте РП заказчика и рп исполнителя

Рекомендую книгу дедлайн, там описаны почти все самые распространенные психотипы рп

с их косяками и фишками

(119) (120) да просто такая хрень регулярно происходила в .... не буду говорить каких франчах. И я лично в это вляпывался и мои друзья об этом же говорили. Разработчики регулярно конфликтуют с РП в большей или меньшей степени.

Это обычная даже практика, когда РП режет часы своему Разрабу до тех пор, пока не создастся конфликт. А затем все вынуждены в этом конфликте принимать решения и в условиях, когда Разраб изолирован от Заказчика - а это бывает и полезно, и вредно для работы с Заказчиком. Чаще бывает вредно. Т.к. при наличии параллельного контакта Разраба с Заказчиком процесс уходит в негатив очень быстро.

Но смысл моих рассуждений в том, что Разраб один черт получает не столько, на сколько разводит Закачика РП, а ровно столько, сколько ему согласен "закрыть" в часах РП. И отсюда очень простой вывод, что оплата не на окладе, а на почасовке == зло для разработчика.

(0) "что с этой проблемой делать?"
Ну как обычно пишут всякие эйчары, писатели тернингов и прочие ничего не понимающие в том что говорят: развивать скилы коммуникаций, выходить на новый уровень, бла-бла-бла.
В итоге ты хоть так хоть эдак без бабла.
А можно свалить из этого цирка (франча) на фикси и греться на солнышке.

(0) Если руководитель ошибся с оценкой трудозатрат, то пусть сам и делает за 8 часов

(124) жизнь несправедлива, что поделать:)
(123) такие книжки надо в 20 читать, я читал в 30 и все свои косяки там нашел=)

(127) А я и читал ее в 24

вру в 22

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

(124) от франча зависит. у нас, например, незакрытые часы аналитику или программисту - это нонсенс.

(126) какая агрессивная политика

(132) За свои ошибки надо нести ответственность

(133) Иногда можно как говорится "сделать скидку", т.е. снизить требовательность / строгость / критику :)

(122) том де марко? читал

(134) Так уж  быть прощу начальнику, но чтобы это было в последний раз))

(136) На самом деле ничего смешного тут нет - подчиненный именно прощает начальнику его (начальника) косяки

(0) У нормального РП всегда есть резерв. Я процентов 15 закладываю на непредвиденные "расходы". Но тратить его бездумно нельзя. Для начала попробовать договориться с заказчиком на допоплату с обоснованием возросшего объема, который нельзя было оценить заранее. Если не согласится - попробовать другие задачи "проинтвентаризировать" - возможно можно сманеврировать. Если не удается - использовать резерв. Если и резерв прожрали - готовить банку вазелина.

(138) РП не может ничего "закладывать" (резервировать), т.к. у него нет компетенций какую-либо оценку в принципе давать

+(139) Т.е. он может лишь накинуть сверху ("заложить") от оценки, полученной от компетентного человека

(139) Поэтому у РП и должны быть эти компетенции.

(141) Про "должны" это конечно же не так, т.к. почти всегда это не так

(142) Значит, хреновый это РП.

(143) Не спорю. Но функции барьера, актирования, дипломата выполняет и уже хорошо )

+(144) Отсутствие компетенций по теме проекта можно и простить, если есть другие компетентные люди

(124) > оплата не на окладе, а на почасовке == зло для разработчика.

Есть два принципиально разных вида деятельности и вида разработки. Рассчитываются и оплачиваются они совершенно  по разному.
Первая - проектная. Система оплаты окладная + премия за закрытые проекты (этапы проектов).
Вторая - поддержка и сопровождение. Система оплаты почасовая.

Там, где пытаются подменять одно другим или как-либо смешивать, происходит бардак.

(139) >> РП не может ничего "закладывать" (резервировать), т.к. у него нет компетенций

В обсуждаемом в этой ветке примере РП и архитектор - это одно и то же лицо. А архитектор как раз и обладает компетенциями по оценке трудозатрат. Он то четко должен отличать отчет, который просто отчёт, от отчёта, который потребует создания или изменения регистров, документов (регистраторов) или любой другой значительной доработки конфигурации с соответствующими трудозатратами.

(139) Речь идет о резерве трудозатрат по проекту в целом, и не об оценке трудоемкости задач. Архитектор дает мне 100 часов. Я закладываю в проект 100 часов + 15 часов резерва. Заказчикам, ессно рисуется 115, т.к. они очень нервно реагируют на слово "резерв". Но если заказчик вменяемый, то оставляю резерв отдельной строкой. С отдельными отчетами об использовании этого резерва. Практика показывает, что первоначальные оценки всегда заниженными бывают. Если в целом  по проекту считать.

(148) Ясно, ситуация из (140). Я неправильно значит понял твое "Я ... закладываю" - подумал, что ты это делаешь когда и оценку самолично придумываешь )

(139) Лол

(147) Ничего архитектор не может оценивать, ибо не погружается в каждую лужу глубоко

(148) Тут еще нюанс что каждый спец всегда оценивает по своему, кто-то оценку занижает, кто-то завышает, кто-то попадает в срок

(151) Не придумывай

(152) Чаще всего заниженная. Одноэсники неисправимые оптимисты. Даже если предварительную оценку умножают на число пи. Они почему-то наивно полагают, что правильно поняли что хочет заказчик :)

(154) по моему опыту, оценка будет зависеть от квалификации + психотипа

(155) Ну если последнее предполагает, что число пи несколько заниженное, то да :)

(117) А что если почитать несколько предшествующих сообщений, где речь шла о том, что РП должен составить подробное ТЗ, иначе вопросы программиста сорвут все сроки?

P.S. Когда Исполнитель не общается с заказчиком - получается то же самое г, только в профиль, если не составить подробнейшее ТЗ, чтобы его нельзя было сделать неправильно. Потому что чтобы задать правильный вопрос - надо наполовину знать ответ, а без общения с заказчиком он ничего не знает. Ну или РП просто зашьется и не будет успевать отвечать и консультировать всех прогов.

(157) Самое плохое это когда РП сам не знает для чего надо то, что он отдает в работу исполнителю

(154) На 7 же надо умножать: семь раз отмерь...

(158) Вот для этого и нужна связь обоих с заказчиком: РП как модератора хотелок и исполнителя, который будет реализовывать хотелки в контексте того, что предполагается решить. Тогда он сможет задать правильный вопрос. И если РП не знает - так хоть исполнитель может поймет :) Плюс исполнитель может предложить такой вариант, который будет проще реализовать (РП ведь может и не был программистом, и не знает, какие возможности есть "из коробки", а какие повлекут очередной велосипед).

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

(161) Только на вакансию руководителя приходится 20 претендентов, а на вакансию разработчика 2

(7) Сегодня сказал делать отчет на 45 часов себе в убыток, а потом заключил с ними контракт на 45 млн.

(160) Собственно, все это не нужно, если РП правильный, а именно знает ответы на 4 вопроса: кто, что, когда и зачем.

+(164) Связь исполнителя с заказчиком нужна только тогда, когда РП с хлебушком. В иных случаях двойной контроль-переваривание хотелок заказчика (и РП, и исполнителем) кажется избыточным.

2(162) РП продажник хочет продать за 8, а назвался грибом - исполнитель взял работу - делай.
Сейчас практика пошла - разработчик - это тот, кто не хочет на себя ответственность брать, и попробуй докажи, что огород который он нагородил - это необходимо.

(166) Вообще-то сначала поступает заказ, а потом его исполняют. Вариант когда сначала делают конфигурацию, а потом ее продают, разработчик выступает собственником и несет всю ответственность, и сам продает свою конфигурацию

(139) это вы не рп описали, а "эффективного менеджера" - сову с пикабу

(167) Поток сознания какой-то. В бред переходящий

(168) Я оперирую ролями, а не носителями оных (человеками). То что ты там что-то совмещаешь или видел таких кто совмещает несколько ролей суть самой роли не меняет.

(170) крупные проекты?

(169) Разжую. Этот перец мне заявил, разработчик наваяет, что ему только в голову придет, а руководителю проекту потом это приходится продавать заказчикам. Я же говорю что происходит наоборот, сначала заказчик говорит что ему хочется, а потом разработчик реализует его хотелки.

(172) Причем тут тп и проект?

(170) В жизни нет ролей, в жизни есть конкретный рп с конкретной командой, которую он строит под себя, в рамках мотивации компании

(151) > Ничего архитектор не может...

Ну конечно. В твоём мире программист - это альфа и омега, человек на котором свет клином сошелся и только он один способен понять что конкретно нужно заказчику, как именно это должно быть реализовано и сколько времени это займёт. А РП, архитекторы, методисты, консультанты, технические писатели, тестировщики - это всё люди - так себе - мимо проходили, пописать зашли.

(165) Здесь вопрос в качестве реализации и удовлетворенности клиента (что в будущем дает дополнительные продажи, т.к. наевшись обычных франчей, которые делают сферических коней в вакууме, и найдя такого, который понимает - клиент будет за него держаться). Когда и РП, и исполнитель знают, что делают - существенно снижается риск испорченного телефона, который зачастую приводит либо к убыткам, либо к неоплаченным работам, а также сорванным срокам, ну и клиент недоволен, само-собой.

(175) Что-то ты тупишь: сказано какую функцию он не выполняет. Это не означает, что он не выполняет никаких других функций.

(174) Все так. Главное противоположных психотипов наедине не оставлять)

(157) ТЗ должно быть составлено таким образом, чтобы исключить необходимость общения исполнителя с заказчиком и делать достаточным для решения любого возникающего вопроса общение  программиста с РП (автором ТЗ).

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

Любое общение программиста с заказчиком только вредит проекту. Если есть ТЗ, то необходимости в таком общении просто быть не должно. Это нонсенс. Иначе зачем вообще ТЗ нужно? Посадите программиста за стол с заказчиком и пусть он кодит под диктовку заказчика.  Только потом не удивляйтесь, что на выходе получается какой-то в хлам переписанный монстр, не способный работать без костылей и прямого пользовательского вмешательства в записи регистров, а отчеты получаются только через ручную допобработку выгрузок в excel.

В исключительных случаях программист может привлекаться в качестве технического консультанта на этапе составления ТЗ. Когда автору ТЗ (РП, архитектору, методисту) не хватает знания и опыта - как именно лучше реализовать ту или иную задачу.

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

(177) >> сказано какую функцию он не выполняет.

Только не надо эту функцию (оценку трудозатрат) передавать программисту.
Повторюсь: в нашем примере РП совмещает обязанности архитектора. Он оценивает трудозатраты и обладает для этого всеми компетенциями. Программиста он конечно тоже может к этому привлечь, но в каких-то исключительных или сильно сложных случаях.

(179) про ТЗ все понятно, а как методист может написать ТЗ, мне вообще кажется кроме программиста ТЗ написато никто не может, методолог тоже человек и то что, очевидно ему не очевидно программисту.

(182) У тебя какое-то извращенное понятие о программисте.
Программист вообще не должен писать ТЗ. У него несколько другие задачи.
Авторами ТЗ как раз и являются архитекторы и методологи. Люди работающие на стыке прикладной части, конкретной конфигурации и конкретной платформы.
Программистов могут привлекать (и регулярно это делают) в качестве технических экспертов для оценки и выбора конкретного решения в каких-то особенных случаях.

(183) ты давно вакансии на HH смотрел? в обязанности программиста входят знание БУ и УУ ) соглашусь во франчах квалификации программистов ниже там не требуют.

(183) Техническое задание и проектная документация наверно разные вещи, думаю ТЗ написать может любой, так же как и заказчик обрисовать что конкретно ему нужно, а вот проектную документацию методолог написать не сможет, там пообъектно что куда и откуда

(181) "в нашем примере РП совмещает обязанности архитектора" // Хз что за наш случай, не слежу за веткой.
В любом случае если архитектор поголовно каждую задачу оценивает, то это точно не архитектор.
Архитектора основная функция - гнать стадо кодеров и тимлидов в нужном направлении, а если впереди обрыв или дождик пошел то увести оттуда и зонтик раскрыть, опционально - солнышком приправить.

(185) Он как и большинство просто путает ТЗ и ТП (тех. проект). Вот ты не путаешь, но это 1 из 10 наверное только.

(179) У франчей нежизнеспособный монстр на костылях обычно получается и без общения исполнителя с заказчиком. Это типичный результат работы франча. Потому что идеальное ТЗ - это из страны, где единороги кушают радугу.

А насчет "Насколько ТЗ будет детально прописано может зависеть от конкретного исполнителя" - это беспечность. ТЗ должно быть достаточно для самого тупого человека, потому что в суде любая недосказанность в ТЗ, подписанном сторонами, будет оспариваться. Поэтому если делать ТЗ рамочным - надо сводить к минимуму риск непонимания. И РП, который интерпретирует задачу для исполнителя, в данном случае слабое звено. Если он понял неправильно задачу - все, тушите свет.

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

(183) например? вот нужно своять печатную форму к отчету, как будет выглядеть ТЗ от методолога? макет печатной формы? и короткая инфо? или он будет привлекать программиста, я вот думаю методолог это своеобразный эникейщик, который права пользователям раздает общается с клиентом, он же продажник иногда бывает..

(184) требования знания БУ и НУ - копипаста, почему то очень модная.
Если программисты принимают решения по методологии, а не специалисты отделов - это не программисты.

(190) по факту я до сих пор не знаю БУ и НУ - для этого в штате есть спецы по этому, я перекладываю это в код, не более

(180) Это не совсем правильно идеологически, но зато позволяет при правильной организации повысить качество продукта и уменьшить сроки. Это как с нормализацией данных.

(190) а кто круче программист или методолог? кому зарплату больше платят? программист работает с данными, он знает пообъектно все регистры, знает что куда откуда и почему, работает с данными способен проанализировать любую ошибку в системе, способен изобразить ТЗ и ПД, методолог думаю без знаний программиста тоже самое изобразить не сможет..

(191) т.е. работая программистом ты не постиг БУ и УУ, либо мало работаешь или профессия не та выбрана т.е. тебе тупо не интересно? работа ради работы? потому что платют много?

(192) Если принять как факт утверждение "в общем случае РП в роли одного физического человека никогда не может собрать информацию от заказчика с достаточной полнотой" (хотя критерий достаточности в (164) отлично работает), то отсюда вытекает, что роль РП должна быть размазана как минимум между двумя человеками. Тогда уже исполнение функций ими обоими уже не кажется неправильным. Но почему-то в такой постановке функция РП "собирать данные от бизнеса" никогда не видел чтоб преподносилась / не распределялась официально.

(193) Каждый хорош на своем месте.
ЗП сопоставимые.
При составлении ТЗ идёт парная работа.
Консультант говорит что и как должно быть с точки зрения учёта, а ппограммист( на самом деле ведущий и выше) говорит как это будет сделано на уровне кода, или что надо изменить в модели, что бы это было возможно реализовать.
Времена самоучек - спецов по всем вопросам прошли.

(196) Уровень ларьков я не рассматриаю

(196) если по ЗП одинаково то я лучше методологом чем программистов ковырять этот говно код.

(196) мне сложно судить, а роль РП какая? если есть методолог который задачу программисту ставит?

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

(195) Руководитель должен быть один, иначе не взлетит. А вот входные данные собирать можно с разных точек, чтобы в итоге как можно полнее понимать, что делается, зачем и чем это полезно заказчику.

Программист, например, может предложить альтернативное (более простое или с использованием типовых механизмов) решение, зачастую при этом даже более юзабельное и понятное, потому что он знает КАК он это будет делать, и сколько велосипедов надо будет изобрести для реализации "как сказал заказчик". Т.е., фактически он выступает в роли технического эксперта, но совмещение этой роли с ролью программиста дает синергетический эффект, поэтому лучше когда это один человек.

(201) "Руководитель должен быть один, иначе не взлетит" // Я поэтому и написал только про одну "функция РП ... распределялась" :) Ну вот не видел почему-то чтоб вверялось такое исполнителю официально. Неформально исполнитель конечно (каждый в меру своего психотипа и чувства прекрасного) скорее всего будет эту функцию нести.

(200) Методолог все-таки ближе к бизнес-аналитику. На прикладную функциональность конкретного ПО ему должно быть пох. Это уже консультант по ПО перекладывает методологию на это ПО.

+(203) И поэтому да - исполнитель (разраб) в паре с консом обычно работает. С методологом ему общаться не приходится.

(0) Если всё как ты говоришь, то РП должен иметь яйца и вывернуть карман.

(1) Если прогер опытный и видит что не так оценили, шлет всех сразу далеко, пока ему не дадут ответ кто будет платить. Обычно за это ему ничего не бывает. А если бывает, то у этой фирмы опытные программисты быстро исчезают.
Ну а если не опытный, то скажут что ты еще просто ничего не умеешь и расскажут сказку о том как у него все будет хорошо. Правда не опытный на 45 часовой задаче, на месяц застрянет.
Как вариант, завышают затраты на всех заказах, что бы было откуда компенсировать промахи.

(35) как минимизировать

Дробите работы на этапы так, как удобно вам и как согласится заказчик. Хоть по 40 часов ))

И выделяйте отдельно разработку ТЗ по этапу.

То есть, даете оценку на ТЗ, согласуете. Оценку на остальное в рамках этапа - даете предварительную.
Сделали ТЗ, его согласовали. Дальше, переоценили остальную часть. Пошли согласовывать оценку у заказчика.
Согласовали - пошли кодить.

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

И т.д. )

(0)вариантов куча: 1. расстрелять 2. уволить 3. лишиь премии 4. поругать перед подчиненными
все бываает, а можно простить и понать

(208) За п.4. нужно увольнять за профнепригодность того, кто такое предлагает.

(209) плюсану

(0) Кто угодно может ошибиться с оценкой трудозатрат.
Что делать зависит от того, что хочется получить.
Для более точной оценки задач
- можно делать оценку группой людей голосованием (Как правило руководитель и исполнители). В скраме это называется "poker planning".
- задачи нужно разбивать на подзадачи что бы 1 задача не занимала больше 2-4 дней (зависит от типа задача).
- выставлять эстимейты после начала выполнения, когда ясен фронт работ.
Для минимизации рисков
- как можно раньше сообщить о неверных плановых сроках. Заказчику подробно рассказать как рассуждал и ошибся и обосновать новые сроки.

(208) Выставлять ошибку на общественное порицание - последнее дело.
Накосячил - ну ладно выеби, но за закрытыми дверьми. Это дело 2х - подчинённого и руководителя, но никак не всей толпы.

(196) Вот полностью согласен.
И на практике такая связка дает результат. Бизнес аналитик или методолог, называйте как угодно, собирает инфу, консультируется с ведущими программист или группой, или отделом ИТ аудита, и в итоге рождается ТЗ. ТЗ в зависимости от сложности попадает или ведущим или просто кодерам.