Fortuna caeca est
Это была вторая попытка устроиться в 2ГИС. В первый раз прошёл скрининг и там оказалось, что для работы нужен английский, чтобы разговаривать с арабами. В этот раз вакансия была целиком русскоязычная и я решил попробовать ещё. Прошёл скрининг, был приглашён на техничку.
Техничка заняла где-то час, много расспрашивали про мой опыт, этими рассказами утомлять вас не буду, в статье рассмотрим только кейсы. Комментарии о том, где я был неправ и как бы вы решили тот или иной кейс, приветствуются.
Работу не получил, интервьюеры выбрали кандидата с «более релевантным опытом», стандартный ответ в таких случаях.
Нелюбимый аналитик
Представь себе, что у тебя в команде два аналитика. Тебя они полностью устраивают. Других аналитиков тебе дать не могут. Однако заказчику один аналитик прям очень нравится, второй не нравится вообще.
Почему не нравится? Аналитики разные по своей сущности. Одна такая твердая, уверенная в себе, постарше. Вторая немножко помягче, чуть-чуть помладше. Заказчик всеми силами прямо в ходе всяких дейликов, которые у тебя каждый день, всячески при всей команде дает понять, что второй аналитик не по вкусу. Пытается переложить задачи на первого аналитика, который нравится, всячески ставит под сомнение правильность предложенных решений вторым аналитиком. В общем, всяко-разно.
Аналитик у тебя расстраивается. После таких встреч приходит к тебе, плачет тебе в жилетку, говорит, ну блин, как же так, я же хорошая. Ты видишь, что адекватный человек работает нормально. Просто так пришел заказчик.
На одной из встреч заказчик при всех просит тебя устранить данного аналитика с проекта.
Значит, смотри, на этом история заканчивается. Значит, что ты будешь делать?
Во-первых, сразу говорю, что замены аналитику нет. Это на случай, если ты будешь рассматривать вариант замены аналитики.
Второй момент. Ты не можешь свалить все на единственного аналитика, потому что она треснет и тоже станет плохим аналитиком.
В-третьих, тебе нравится твой аналитик. То есть ты оцениваешь её адекватно.
В-четвертых, ты понимаешь, что это токсичный заказчик. Что будешь делать с собой, с аналитиком и с заказчиком?
Я не буду менять аналитика. У меня очень часто бывает ситуация, когда надо работать с теми людьми, которые есть. Это на многих проектах так. Очень часто недостаток ресурсов.
В чем здесь решение? Дело в том, что работа аналитика – это не только переговоры. И далеко не только переговоры. Вот в этом ключ. Потому что работа аналитика – это еще написание требований, анализ требований, оценка требований, всякие трассировки. То есть, в общем, работа, которая с заказчиком не требует взаимоотношений. Поэтому здесь решение очень простое. Мы договариваемся с этими аналитиками. То, что девушки, вот у нас сложилась такая ситуация. Вторую из вас заказчик не любит. Первая будет заниматься переговорами, встречами с заказчиком, общением, фиксацией. А вторая будет заниматься всей работой, которая общение с заказчиком не требует. Я уверен, что работы хватит на обеих, что они не треснут. Что мы здесь все корректно распределим.
Единственное, что здесь может быть, всякие психологические штуки. Что у второй поедет самооценка. Что заказчик не хочет со мной общаться. Но здесь есть и плюсы. Ей не придется терпеть от заказчика унижение, которое явно ее на переговорах третирует. То есть мне кажется, она скорее даже обрадуется. То, что у неё остается работа, она остается в штате компании, она остается на проекте. Она занимается важным полезным делом, и никто ее не будет третировать. Она просто будет работать на основании данных, которые на переговорах получает первый аналитик. Первый идет переговоры, второй аналитик анализирует. Вот, собственно, простое понятное решение.
Усложнение кейса про нелюбимого аналитика
Так, хорошо, смотри. Я усложню тебе чуть-чуть эту задачку. Смотри, представь себе, что аналитики идут в два разных стрима. То есть одна, допустим, там, ну не знаю, в общем, неважно, какие у них задачи, но это две разные задачи. И у каждой из них, то есть ты распределил их на эти стримы именно так, потому что у каждой из них есть скиллы и экспириенсы именно в своем стриме. Вот, тут нельзя таким образом перераспределить, что одна будет говорить, другая будет делать.
Хорошо, в этом случае начинается то, что я не люблю. То, что иногда надо делать, это называется психотерапия.
Когда мы собираемся с заказчиком и с аналитиком, который ему не нравится. И начинаем их терапевтировать. Мы просим, чтобы заказчик начал последовательно выдвигать претензии, что конкретно ему не нравится в этом втором аналитике. Конкретно по пунктам.
Вот 8 пунктов, которые ему не нравятся. Мы просим аналитика прокомментировать вот эти пункты. Расщепляем и говорим о каждом отдельно. Мы приходим при помощи разных методов, разных психологических приемов, к консенсусу по этим пунктам. И в общем, при помощи такой психотерапии пытаемся их, вот эти вот нестыковки, оттерапевтировать так, чтобы они пришли к консенсусу и начали друг друга устраивать.
Это очень сложно. У меня нет специфических навыков, чтобы это проводить. Но если у нас выхода нет, придется мне заниматься вот такой психотерапией и вот так пытаться оттерапевтировать.
Обсуждение аналитика с заказчиком
Владимир, скажи, а что ты будешь говорить заказчику? То есть заказчик тебе такой типа, Владимир, ну что у нас там по аналитику? Ну что там, давай мне нового. Я хочу нового аналитика. Нет, я против того, что ты там на одного все это дело свалишь. Но ты же все равно поделишься, как ты эти стримы будешь вести. А он на тебя давит, такой говорит, Владимир, нужен новый аналитик. Как ты с ним тут? Что? Я тебе прям такую красивую ситуацию привела. Мне прям сложно там было.
Ну да, мне тоже на самом деле сложно. Самое хорошее решение, самое лучшее оружие – это правда. Правду говорить легко и приятно, и правда не требует сооружения системы лжи, которая требует поддержки. Правда существует сама по себе. Можно сказать заказчику правду.
То, что у нас сейчас на рынке труда не очень хорошая ситуация, аналитиков мало. И у нас в компании другого аналитика для вас нет. Я понимаю ваши претензии, я понимаю, что она вам не нравится, но разрешите мне попробовать эту ситуацию выправить. Если была возможность разделить, чтобы один общался, другой анализировал, мы бы так сделали. Мы не можем это сделать, у нас разные стримы. Одного аналитика на два стрима оставить не могу, он лопнет.
Поэтому давайте все же попробуем. Мы сделаем попытку вот этой встречи психотерапевтической. Дайте мне шанс. Провести эту психотерапию. Если не получится, хорошо. Задействуем аутстаф, благо аутстафных компаний на рынке очень много, подберём замену снаружи.
Проекты в убыток
Давай еще поговорим про проекты в убыток, раз уж пошла такая у нас тема. Вот я слышу, что у тебя есть такой опыт в целом, да? Про проекты, которые в убыток ушли. Я правильно понимаю? Конечно. Хорошо. Ты какие-то плюсы вообще видишь в проектах в убыток?
Например, в Системных технологиях у нас были платные инвестиционные проекты. Я прошу прощения, что я лезу в очень старый опыт. Просто в Систехе я работал очень плотно, и это была одна из моих первых ответственных работ. Я там управлял тремя отделами и одним из основных продуктов компании. В общем, дело в том, что там у нас были доработки, которые частично спонсировались Систехом, частично их оплачивал один или несколько заказчиков. То есть были такие сложные бюджеты. По некоторым из этих проектов мы очень сильно выбивались из бюджета. То есть там заказчик оплачивал какую-то долю процентов 15. Все остальное было со стороны компании. Это делалось для того, чтобы улучшить наш продукт и этот продукт впоследствии лучше продавался. То есть вот эти инвестиционные проекты, которые делаются в убыток, они могут делаться для того, чтобы сделать коробочный продукт и хорошо его продавать. Такой вариант возможен.
Еще возможен вариант, когда мы работаем на репутацию. Это вот как раз, когда меня спрашивают про проектный треугольник, я говорю, что критерий успеха проекта, как попадание в треугольник, это только у неопытных PM. Опытный PM знает, что можно промазать далеко мимо проектного треугольника, при этом сохранить с заказчиком хорошие отношения, и он нам еще на миллиард закажет софта. Можно сделать убыточный проект, можно промазать на несколько десятков миллионов, но заказчик скажет, какие молодцы, какой мне софт хороший сделали, мы вам еще на миллиард закажем, и еще другим порекомендуем. То есть, в общем, убыточный проект это не всегда плохо.
Продакт не понимает полезности фичи
Вот бывали такие случаи, вот ты прожект. Вот бывали такие ситуации, когда тебе попадался кто-то из окружения, может быть это был продакт, с которым вы не совпадали по мнению.
Приведу тебе пример. Ну, либо там тугой какой-нибудь, знаешь, человек такой, ну ты вот, господи, всячески ему там все объяснял, а он вот гнет свою линию. Приведу тебе вот яркий пример. Смотри, представь себе, что у тебя есть классный заказчик, с которым ты уже много поработал, заказчик адекватный, лояльный, вообще все чудесно. Он поработал с твоим продуктом и говорит, Владимир, слушай, мы тут посмотрели, видим, что вот у вас есть, грубо говоря, некий бизнес-процесс, пусть это так назовем, или некоторая интеграция, не суть.
Что насчет вот такой фичи? Ведь и нам будет хорошо, и вы улучшите свою «коробку». Ты пишешь брифчик, приходишь к продакту, говоришь, слушай, вот, прилетел кейс от заказчика, это здраво. То есть это не какой-нибудь там единорог, и у нас по радугам помчали. А это вот реальный кейс, хороший. Продакт смотрит и говорит, нет. Ну, или лет через 10. Ну, понимаешь, сейчас более приоритетные задачи есть, и вообще, в общем, это как-то в роток наш не ложится, и вообще, как бы это самое, не будем.
Вот что ты, бывало ли у тебя такое, что ты будешь делать в этой ситуации? Как ты вообще относишься, когда кто-то не понимает реальную пользу, которую ты пытаешься донести?
Вот именно такой ситуации, наверное, у меня все-таки не было, поэтому мы рассмотрим гипотетически.
Я бы, во-первых, сначала втихаря собрал что-то вроде комиссии из самых адекватных и понимающих технических специалистов и аналитиков моей команды. У меня, как правило, есть аналитик, который работает с проектом дольше всех и который реально в продукте разбирается. В общем, я соберу комиссию, и я вместе с ними проговорю, что заказчик предлагает, эту фичу, которую они предложили. Мы обсудим, реально ли то, что говорит заказчик, реально ли это полезно продукту.
Если это полезно, я пишу письмо руководству повыше, главе IT-департамента или директору проектного офиса, или кому-то из начальства. В общем, я иду через голову продакта, понимаю, что могу спровоцировать конфликт с продактом, но иду через голову и говорю руководству, что да, вот так вот можем мы улучшить продукт, мы проговорили это с командой, это реально.
Заказчик говорит дельную вещь, помогите, пожалуйста, повлиять на продукта. Во всяком случае, после такой эскалации моя совесть будет чиста. Все, что я мог, я сделал.
Я уже пытался убедить, я так понял, этого продакта, я его не убедил. Я эскалировал, моя совесть чиста. Для продукта все, что я мог, сделал.
Если руководство надавит на продакта, и он скажет, делаем, мы сделаем продукт лучше. Если руководство скажет, разбирайтесь сами, значит, я сделал всё, что мог, я эскалировал, моя совесть чиста. Всё хорошо. В общем, мое решение эскалация. Комиссия, обсуждение, эскалация.
Это гипотетически, у меня не было такой ситуации. Я бы вот так действовал.
А давай поиграем в продолжение. Ты это сделал, начинает давить на продукта его руководитель, а продукт, соответственно, озлобился, например. Даже не озлобился, нет у нас таких продуктов, честно говоря, конечно. Это затронуло его чувства, и все мы люди, он, конечно, может быть, даже понял продуктовую ценность, согласился совсем даже внутренне, но обида никуда не ушла. И что ты тогда будешь делать?
Смотри, может быть, есть компании, в которых иначе, но во всех компаниях, в которых я работал с продактом, мы всегда были немного антагонисты. Потому что продакт больше про то, как сделать полезный продукт. А я, как проектный глава команды, я тоже за то, чтобы сделать полезный продукт, но у меня есть другая core цель. Мне ещё нужно, чтобы команда комфортно работала, иначе она разбежится, и разрабатывать будет некому.
То есть у меня все-таки чуть-чуть другая цель. Я больше за комфорт команды. Поэтому я практически во всех компаниях был с продактом немножко на ножах, и практически во всех командах продакт был изначально на меня немножко обижен, и у нас изначально были натянутые отношения. Я умею работать в условиях вот этих натянутых отношений, не переводить это в горячий конфликт, и делать так, чтобы эти отношения были хоть и натянутые, но продуктивные. В общем, мой ответ – продакт и так на меня обижен. И сильнее он на меня не обидится.
Продакт и прожект на ножах
Очень интересная тема. Ну, а смотри, вот я продукт. Мы с тобой немножко, как ты сказал, на ножах. Убеди меня, почему твоя позиция тоже важна, почему ты работаешь не против продукта, с учетом того, что ты оттягиваешь на другие процессы. Конкретно в этой ситуации… я пришла к тебе и сказала, Владимир, ну что это такое, почему мы с тобой все время на ножах? Пусть даже так, пусть я сама к тебе пришла с этим вопросом, что ну давай посмотрим реалистами. Получается, не ладим, у нас разное видение. Почему у тебя не мое видение? Это уже в отрыве от этого кейса. Просто отдельный вопрос. Да, уже в отрыве от этого кейса.
Я зацепляюсь за пункт, что ты говоришь, что ты больше за комфорт команды, а я продакт, и я только за продукт. И вот я продакт пришла к тебе и задаю вопрос, ну почему у нас с тобой постоянно какие-то контры? Мое личное видение, что получается, когда ты против продукта.
Я не против продукта. Моя главная задача в сочетании. Я должен делать так, чтобы твои цели, как продакта выполнялись, так, чтобы продукт был хорошим, так, чтобы он был полезен рынку. Но если я буду всё время на твоей стороне, если я не буду периодически говорить: «Мы не будем делать эту хрень», если мы периодически не будем ругаться, у меня разбежится команда.
Что такое разбежится команда?
Люди начнут реально увольняться. Они будут говорить, почему у нас постоянно меняются приоритеты, почему ты не учитываешь наши интересы, почему ты нас не защищаешь. Вот такие ситуации прямо были. Люди могут реально начать увольняться. И все-таки мне очень важно, чтобы люди не увольнялись, чтобы они работали долго, чтобы они пилили доработки, чтобы твои цели выполнялись. То есть на самом деле это всё в гармонии. Но эта гармония подразумевает антагонизм. То есть вот эти самые контры, они в самом определении, в самой сути отношений продукта-прожекта. То есть от этого деться вообще никуда нельзя. То есть я за продукт, но если я буду всегда 100 % за тебя, у меня команда разбежится, будет некому работать.
Можно, конечно, чисто гипотетически, я себе представляю ситуацию, когда прожект и продукт, когда прожект целиком на стороне продукта. Команда построена на текучке, где люди работают по 6 месяцев. Но продукт будет некачественным, потому что один накодил, второй перекодил, третий это лоскутное одеяло пытается поддерживать. Этот продукт не будет качественным, там будет много дефектов, он будет плохо работать. То есть такое сделать можно, но в итоге как раз парадокс, цели продукта не выполнятся. Это такая сложная философия, но с этой философией надо как-то существовать.
Компромисс
Очень интересно. Владимир, а смотри, представь ситуацию, что я продакт, у меня меняющиеся цели, ты прожект, есть команда, а ты со мной согласен. Ты понимаешь, почему меняются цели, может быть это полупроект из стартапа, может быть там 4 направления стартапности, может еще что-то. Есть аргументы, по которым ты со мной согласен. А команда действительно страдает от того, что приоритеты меняются. Вся разработка такая, это люди комфорта, они это любят. Что будешь делать с командой? Ты согласен с тем, что так шатаются приоритеты, ты за гибкость? Хорошо.
Делается очень простой компромисс, который, как правило, устраивает и команду, и продакта. Мы обмениваем фриз целей на какое-то разумное время на гарантию поставки инкремента. Очень хороший компромисс. Как правило, на него идёт и продакт, и команда. Продакт фризит цели, например, на 4 недели, команда гарантирует, что поставит качественный продукт в эти 4 недели. Исключений нет. Если мы не можем зафризить цели на 4 недели, у нас глубокие проблемы с целеполаганием в компании. То есть, это проблема. Если мы не можем зафризиться на какое-то время по целям, нужно опять привлекать руководство, потому что у нас более глубокая проблема, которая на уровне прожекта не решается.
В общем, мое решение – это вот такой компромисс, на него, как правило, идут.
Процессы
Так, а скажи, вот как раз затронем такую тему, вот ты больше про работу по регламенту, когда есть четко определенные бизнес-процессы? Или ты как-то по-другому на это смотришь?
А что, если бизнес-процессы в компании сырые?
Да вообще без проблем. На самом деле у меня реально выстроенные бизнес-процессы были в одной или в двух компаниях. Вот в компании Комус, по-моему, был такой «парадокс». Я пришел, мне говорят, а у нас расписаны процессы, у нас вот есть такая таблица, делай раз, делай два, делай три. Я был очень удивлен.
И, по-моему, в компании Самолёт были расписаны. И все. В остальных всегда процессы были сырые, всегда нужно было существовать в условиях определённого хаоса. И на самом деле я себя очень комфортно чувствую в хаосе. И более того, я умею этот хаос структурировать и эти регламенты потихонечку рожать.
Я против того, чтобы прийти в компанию и сразу взять и вообще все зарегламентировать. Так, уйти в себя на год и регламентировать всё, родив документ на 2000 страниц. Нет. Я за то, чтобы взять в условиях этого хаоса процесс, в котором больше всего проблем, больше всего конфликтов, больше всего непоняток. Вот этот процесс проработать, зарегламентировать и добиться, чтобы процесс стал идти по регламенту. Вот это можно сделать сразу, и это сразу принесет пользу. И чтобы команда эту пользу увидела, и команда, и руководство. Что вот, оказывается, регламенты можно писать, они работают, самое наше больное место вылечили. И тогда мы берем и лечим второе по болезненности место, потом третье. В общем, я умею существовать в условиях хаоса и вот так структурировать ситуацию.
Интеграции
Расскажи мне, пожалуйста, пример какой-нибудь интеграции. Насколько глубоко технически ты погружаешься в какие-то сложные, не знаю, может быть, девопсовские задачи, может быть, в интеграционные, в какие-то архитектурные моменты.
Бывает, что в названии позиции пиэма звучит слово technical. То есть, если прожект technical, то надо погружаться. Но мне кажется, более здоровая ситуация, когда прожект занимается все-таки больше управлением, а интеграцией занимается хороший, квалифицированный системный аналитик, который всю эту интеграцию распишет, который все это будет контролировать и все такое.
Что касается интеграций, они бывают двух видов. По крайней мере, я их разделяю на две вида:
- Интеграции со смежниками внутри нашей компании. Когда нужно интегрироваться с соседним продуктом, как, например, у меня было в Систехе.
- Интеграции внешние, когда нужно взять внешнюю компанию и подсоединиться к их продукту, как, например, было в Инвитро. По-моему, это было что-то связанное с рассылками. То ли MailChimp, то ли MailCamp. Что-то такое. В общем, что-то связанное с рассылками.
Как правило, в моих командах этим все-таки занимается самый умный системный аналитик. А я делаю так, чтобы этот системный аналитик мог привлекать специалистов из соседних команд или специалистов из команды внешников, с которыми мы интегрируемся, в случае стороннего продукта, чтобы у них там не было конфликтов. Я на этих встречах, как правило, присутствую. И эти встречи фасилитирую, чтобы они там не разругались вдрызг.
А думаешь, у них есть повод разругаться?
Может быть такое. Один говорит, вот это самое, здесь интегрируетесь так, а наш аналитик говорит, это глупость, надо вот так. Это, кстати, актуальная ситуация. Очень важно фасилитировать.
А как ты фасилитируешь? Как ты вообще их разотнимаешь?
Просить давать разумные аргументы. Не переходить на эмоции, просить не говорить слова «это глупость», а говорить «это глупость потому что…» Если вообще не получается, если одни говорят, что техническое решение А, Б, Ц, Д, Е, а другой говорит, не, это Г, Ф, Р, И, Ж, К, Л, М, Н, Б, можно позвать кого-то из ведущих технических экспертов компании. То есть тоже эскалация, но не на руководство компании, а позвать кого-то из технических экспертов, который придет и нам скажет, что на самом деле и ты не прав, и ты не прав, с ним нужно делать третий вариант интеграции. Они подумают, почешут затылки и скажут да, на самом деле, какой умный человек, надо делать по третьему. Задача ПМа все это дело контролировать, чтобы был привлечен нужный человек, чтобы эта встреча проходила в конструктивном ключе, чтобы не сложилась ситуация, когда они сказали, ты идиот, нет, ты идиот, ну и значит мы больше с тобой не будем общаться. Эта интеграция просто зависла, чтобы ей перестали заниматься. То есть нужно контролировать это дело.
Успешный проект
Вот успешный проект для тебя, это что? Когда заказчик удовлетворен, внутренний или внешний, это главный критерий? Ну, как бы, я неправильно сейчас попыталась сказать, согласна, счастливый заказчик наша цель, да?
Вот если расположить по какой-то шкале, по приоритетам, сроки, бюджет, довольный заказчик, что ты поставишь на первое место, на второе, на третье?
На самом деле, довольный заказчик – это всегда на первом месте. А сроки, бюджет или содержание зависят от. По-хорошему, надо спросить у заказчика в самом начале проекта, что для него важнее. Потому что может быть такое, как, например, Олимпийские игры. Ни одни Олимпийские игры за последние 40 лет не уложились в бюджет, и это ок. Но вот промазать мимо даты… Были случаи, когда Олимпийские игры переносились, но эти случаи было две или три в истории, промазать с датой Олимпийских игр – это страшный форс-мажор. То есть нельзя промазать с датой начала Олимпийских игр. А промазать по бюджету – нормально.
Понятно, интересно. Бывают проекты, когда содержание на первом месте, что заказчик уперся, как у меня было на одном проекте, я хочу программу телепередач, как у Beeline, чтобы у меня были дорожки телеканала, чтобы по этим дорожкам плыли кирпичи, и чтобы на этих кирпичах были картинки с изображением телепрограмм. Вот я хочу вот так, я вас расстреляю, если так не будет. Вы, пожалуйста, по бюджету мы можем двигаться, по срокам можем двигаться, но мы должны реализовать так, чтобы было как у Beeline, только с картинками и не тормозило. Пожалуйста, бывают такие проекты.
Факапы
Расскажи, были в твоей жизни факапы? Да, ну какой-нибудь, ну может у тебя их не было, такое вот, такие тоже есть.
Так не бывает, чтобы не было факапов. Хорошо расскажу, как я однажды профакапился. У меня был проект с компанией Servie, это такая фармкомпания, она делает разные лекарства, например, вальдоксан, очень хорошая штука для сна, структурирует сон вообще по полной программе.
Короче говоря, я делал систему удаленных визитов для фармпредставителей, но это тоже не важно. Важно то, что я почему-то решил, что она по тайм-матириалс. Я от заказчика принимал все правки. Почему бы не принять, у нас же тайм-матириал. А почему я решил, что у нас тайм-матириал? В этом заключается факап, я не спросил. Но, к счастью, в начале проекта, когда они еще немного всего накидали, мы чуть ли не столкнулись в коридоре с аккаунт-менеджером. У нас возник разговор, он говорит, ты что, какой тайм-матириал, это фиксованный проект. Ёшкин кот.
А скажи, извини, что я тебя перебиваю, у меня просто это прям интересно стало. А вот когда заключается договор с заказчиком, вот просто везде по-разному в всех компаниях, вот в зону ответственности PM входит знакомиться с договором?
В некоторых компаниях входит. Например, в Девелонике, более того, я удивлю, я в Девелонике составил договор с помощью юриста.
ПМ должен участвовать в подписании договора, просто на этом конкретном проекте договор подписали до меня, проект начал другой ПМ, этот ПМ уволился, меня поставили на этот проект. Это передача дел была. Я в договор не заглянул и у аккаунта не спросил, какой проект фиксованный или тайм-матириал. Почему-то решил, что раз у нас такие хорошие отношения, раз мы все такие современные, то у нас тайм-матириал.
Фикс прайс или тайм матириал
Что комфортнее, фикс прайс или тайм-матириал?
Большинство проектов, у меня были по фикс прайсу. По тайм матириал могу вспомнить только работу с Монделис. Который Крафт, который Милка, который вот это все, которые всякие шоколадки. Вот я с ними был по тайм матириал. По тайм матириал просто прикол в том, что тайм матириал до тех пор, пока факт не превышает план хотя бы на 30 %. Если больше чем за 30 % вылезли, как правило, начинается скандал, тайм матириал заканчивается. Приходится объяснять, почему мы выбрались и почему нужно платить больше. Наверное, все-таки ты знаешь, как-то фикс прайс мне привычнее. Комфортнее.
Добавить комментарий