Согласен. А если грамотно «продавать» необходимость обслуживания кода и уменьшение technical debt бизнесу, то и «его» будет интересовать твой код, т.к. он позволит снизить расходы на его поддержку в будущем, время на поиск и устранение проблем (уменьшенеи расходов), ускорить процесс разработки новых фич (опять же, выливается в уменьшенеи расходов), уменьшит риск отвала клиентов из-за нестабильности приложения и т.д.
У меня 12 лет программерского стажа. И я с вами не соглашусь в корне :)
ПМ не должен знать технических деталей. Вы (команда) — ответственная и автономная единица (до первых косяков). Если команда решает подзабить на план и порефакторить — то менеджер автономность будет убирать и будет микроменеджить девелоперов, «как пастух своих овец», извиняюсь за аналогию. Вам это надо?
Интересно, как обрадуется команда, если ПМ решить невыдать всей команде бонус, т.к. потратит его, например, на покупку растений в офис, где работают девелоперы. И когда люди начнут приходить с вопросами, он скажет (например): «Ребят, у вас теперь среда какая комфортная. Это важно для вашей будущей работы, что бы дышалось хорошо и это окупиться в будущем вашим здоровьем и настроением».
Вот интересно было бы послушать реакцию девелоперов :) И если эта реакция будет отличная от: «конечно, все верно, молодец ПМ!», то следует ли из этого делать вывод, что команда — необразованная и непонимает важности комфортной и разряженной рабочей среды для коллектива? :)
Суровая правда жизни, что программеры забивают на ПМа, считая, что уменьшение technical debt важнее, чем delivery. Поэтому и плодятся у нас говноотношения между менеджерами и девелоперами.
Последние несколько лет я работаю в командах с налаженной коммуникацией. Если нужно заложить время на улучшение кода или его изменение в пользу стабильности, масштабируемости и прочего, это обсуждается девелоперами еще до планирования этапа (внезапно возникла необходимость переписать полпроекта? харош...). На планировании это выносится на повестку с аргументированием, почему это важно (надеюсь, не будет вопроса «чтоооо? еще и аргументировать ему надо? да он необразованный, раз не понимает»… может быть, вы сами не образованы, если не можете аргументировать необходимость чего-то бизнесу?).
Я еще ниразу не встречал ситуации, когда менеджеру сообщалось бы: «нам нужно провести оптимизацию/рефакторинг, и это очень важно для проекта, т.к. нагрузка на продакшн сервере уже превысила 70%, и если мы не возьмем это в этап, на следующей неделе наш продукт ляжет и мы потеряем клиентов и деньги», и менеджер в ответ говорил бы: «нет, в этап берем только новые фичи» :)
Я еще ниразу не встречал ситуации (по крайней мере, с компетентными девелоперами), которые встретив препятствие вчера не сообщили бы о нем команде сегодня и если препятствие не устранено — менеджеру к концу дня, что бы он понимал риски по реализации той или иной задачи. И что бы менеджер после этого спросил с команды — «мне пофиг, почему задачи не выполнены»…
— Работа по вспомогательным классам для x, y и z была включена в этап? Если нет, то почему вы этим занимались в ущерб этапа?
— О том, что вместо работы над задачами, вам необходимо было делать что-то другое было ли сообщено кому-то (ПМ-у)? Если нет, то на что жалуемся, где закрытые задачи?
— Когда пришло понимание того, что задачи этапа не будут выполнены? Только в последний день этапа протяженностью в месяц? Да что за бред.
Действительно, описанный диалог довольно типичен у нас. Он бы не состоялся (точнее, состоялся бы подругому), если бы в команде была бы хорошая коммуникация.
Если вы меняете название директории vendor, которая является стандартом для php
А можно ссылочку на стандарт PHP для именования папки с зависимостями?
Если вы меняете название директории vendor, которая является стандартом для php, или node_modules для node — вы автоматически создаете сложности тем, кому этот проект нужно будет поддерживать. И совсем не важно, на каком фреймворке, или без него вы пишите.
Если рассуждать так, как вы, то фантазией разработчика, уставшего от надоедливых пользователей может быть переименование сущности User на Monkey, вы тоже это считаете вполне себе нормальным?
Я не могу понять, как я создаю сложности тем, кто будет поддерживать проект? Если принимается решение об именовании папки vendor каким-либо другим именем, наверняка для этого есть причина?
— Существующий проект. Наверняка. Если есть причина, то, скорее всего, все те, кто поддерживает проект — вкурсе изменения
— Новый проект. Если я начинаю поддерживать какой-то проект, в котором изначально было принято решение о другом имени для папки с зависимостями, то какие трудности это создает для меня? :)
Composer Vendor Directory пост
«One True Vendor» — не сильный аргумент, а стремление автора к consistency. Там говорится о том, что папка vendor — «задумано по дизайну». И приводится «хорошая причина для такого дизайна»:
Composer targets the PHP community. It aims to grow the library space. Libraries should be small, focused, flexible and avoid side-effects. The user should be in control.
Если папка будет отлична от vendor — ничего не идет вразрез с «хорошим дизайном» (отсылка к тексту параграфа One True Vendor).
«Autoloading» — не нашел сильных аргументов. Зато есть:
A composer-managed application should have exactly one single include statement. A require vendor/autoload.php in the front controller
Почему это не может быть «require vendor-dir/autoload.php» неясно.
«Single directory» — тоже все весело. Особенно порадовало:
Third, version control. No need to litter your gitignore with random garbage
Т.е. папку vendor, создавая новый проект, совсем не надо добавлять ее в .gitignore :)
Isolation — единственное «заключение» в нем это:
Enough of that. That's why composer is a dependency manager and not a package manager. It manages deps per-project, it isolates them. It disallows sharing the same package directory between projects
Как это связано с именованием папки зависимостей? Неясно. Зато — «мамой клянус!» («trust me, it's totally worth it») присутствует :)
Итог
Человек, написавший пост, явно устал от управления зависимостями с PEAR, особенно работая с несколькими проектами, которые зависят от разных библиотект. И он (человек) стремится к согласованности в именовании папки, что поощримо (я сам ЗА consistency в проектах). Но аргументов нет, есть только — «ппц, да это не круто именовать папку отлично от vendor».
Я тоже предпочитаю «vendor», hell0w0rd, тем более, что пока не приходилось иметь дизайн приложения, который требовал бы изменения дефолтной конфигурации. Но я не исключаю возможности такой необходимости.
И если все зависимости хранятся в одной папке, а не разбросаны по проекту — то по-сути все равно, какая эта папка (если уж дефолтное название изменено, возможно, есть на то причина).
Какой-то негатив тут разгорелся на тему PHP, в отдельных местах. Коллеги, вы чего?
Напрашиваются две мысли, после прочтения комментов:
Кстати вот интересный вопрос: разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает» или они уже пришли к заключению о том, что это член класса, «к которому нельзя снаружи обратиться»?
Также интересно, пришли ли отдельные C++ разработчики таки к заключению, что разные языки хороши для решения разных задач, а иногда разумно использовать стек из разных технологий, что бы построить то или иное решение? Или они все еще считают, что ты пишешь либо на PHP, либо на C++! Точка!
Словом… лучше уж пусть школьники пишут на PHP который будет умирать. Индустрии нужны люди которые пилят бложики.
Действительно, ведь крутые C++ программисты напишут бложик на C++, или вообще никогда не столкнуться с такой низкоуровневой задачей/просьбой.
Я неверно интерпретировал событие. Я думал, что мы включаем зимнее и летнее время (переключение), как было, скажем, 4 года назад. Т.е. в марте переведемся на летнее время.
Ан нет, оказывается, речь идет не о возврате механизма перехода (зима, лета), а о фиксированном времени (как в данный момент), только на 1 час меньше.
Получается, летом время в Финляндии, Эстонии,… разницы во времени с РФ не будет. По сути, летом это будет EEST (Eastern European Summer Time), грубо говоря :)
Хорошо, хоршо. Я понял это. Я всего лишь хотел поинтересоваться на тему ЧАСТИ картинки. Я ее выделил здесь:
Для меня важно знать временную разницу CET <-> MSK. Поэтому вопрос к вам и знатокам был: все ли верно указано на этой картинке, относительно разницы времени в Москве с европейским (ПАРИЖ, БЕРЛИН, РИМ). До и После. Выглядит, как неверно.
Скажите, а почему «сейчас», разница МСК со временем «Зимой» от CET (центральное европейское время)
Я оперирую терминами и цифрами картинки с Лента.ру, т.е. про разницу времени в Москве, со временем Central European Time. Вы же говорите про UTC (Coordinated Universal Time).
Скажите, а почему «сейчас», разница МСК со временем «Зимой» от CET (центральное европейское время): +3 часа?
До отмены перехода на зимнее/летнее время было: Зима (CET +2), Лето (CEST +2)
После отмены перехода стало (до 26 октября 2014): Зима (CET +3), Лето (CEST +2)
Как будет после 26 октября 2014? По логике, должен добавиться час и в Европе и в России, поэтому разница не должна быть больше, чем 2 часа. Как получилось — Зима (CET+2), Лето (CEST +1)?
Заботящемуся менеджеру лучше организовать грамотный knowledge sharing внутри команды. Чем закладывать денежный резерв на случай, если кто-то попросит денег :) ИМХО
Но опять же, мы говорим о важных вещах, но забываем конкретизировать ситуацию. Если это устоявшийся проект и идет его развитие — нет проблем заменить человека, даже ключевого.
Если проект в стадии разработки и готовится к релизу, тут будет сложнее решить, как поступить.
Оговорить можно что угодно, другое дело как это будет выполняться. И если работник желает сразу ограничить работодателя контрактом до мелочей — вряд ли это понравится работодателю брать на себя повышенные обязательства. Это же все при приеме делается, когда работнику выгодно свою лояльность показывать, а не щепитильность.
Оговаривание можно объяснить. Если работодатель обещает что-то в оффере, какая проблема включить это в контракт? Я не говорю о чем-то абстрактном. Что ж, если это не понравится работодателю — вряд ли стоит наниматься к нему. Не могу понять о каких повышенных обязательствах идет речь, извините. Если я лживый HR, красиво рассказывающий о том, сколько бонусов будет иметь сотрудник в этой компании — мне не понравится сотрудник, который хочет прописать эти обещания (т.к. я то знаю, что они не будут выполнены).
Опять же, прошу понять меня правильно. Я не говорю, что одно — правильно, а другое нет. Здесь присутствует мое рассуждение, основанное на собственном опыте и работе в разных компаниях и странах.
Просто, если я, как менеджер, обещаю и собираюсь индексировать будущему сотруднику (и я уже это делаю для текущих) зарплату каждый год, то мало того, что меня не будет напрягать запрос от кандидата, скорее всего, этот пункт уже будет включен в контракт или одно из его приложений.
Как минимум менеджер должен следить за рынком труда, видеть куда и на какие условия переходят люди.
Выгнать человека — ну да, это выход. А вот заплатить за лояльность и пользу компании, за отсутствие головняка с поиском и адаптацией нового сотрудника, риск того, что он не подойдет по каким-то причинам — с этим сложно.
Менеджер должен следить за рынком — согласен с вами. В идеале, менеджер должен участвовать в жизни команды, что бы знать текущие настроения :)
Но о какой лояльности идет речь, когда человек обнаружил новую компанию, платящую ЗП на 50% выше рыночных? Если в компании сотрудника держат только деньги, думаю, он будет работать у вас до того времени, пока он не найдет место, где ему предложат больше и вы не сможете перебить эту сумму.
И что стоит за отсутствие головняка и будет ли это отсутствие? Допустим, я повысил ЗП. Через полгода появляется новая компания. Теперь, вместе с этим человеком приходят еще 3, один из них ключевой. С тем же самым аргументом. Еще раз «отделываемся от головняка». И в третий раз закинул старик невод… интересно, чем все закончится для проекта.
P.S> Пишу столько текста, т.к. интересная тема. Приходилось работать в разных звеньях «рабочей иерархии». Поэтому рассуждаю не просто как работник или директор.
Может, до этого квалификация сотрудника не позволяла этого. В момент, когда сотрудник подошел с таким вопросом, менеджер понимает — ок, сотрудник готов (думает, что готов), хочет.
Я думаю многие вещи заложить на этапе найма. Понимаю, что у нас контракт — ничего не значит, но его можно использовать в качестве аргументов. Хм, может стоит написать пост на эту тему. С названием вроде «X вещей, которые необходимо оговорить (прописать в контракте) перед началом работы в компании»
Вместо предложения сделать еще что-то для фирмы и получить +5% предлагаю спросить у менеджера с какого я должен работать в его, а не в соседней компании за те же или большие деньги
Я бы задумался о желании иметь такого «стабильного» сотрудника в своей команде. Через месяц появится компания, у которой будет еще больше бюджет… что тогда? Опять тот же вопрос? Если человек решил уйти из-за денег, попытки что-то мгновенно изменить лишь отсрочат уход «до следующего случая».
В мелких же конторах и менеджеров нет как таковых, так что ваша мотивация это ваши проблемы.
И действительно, что такое мотивация. Когда я начинаю работать в компании, моя мотивация — это оффер/условия работы в компании, включая ЗП, бонусы и т.д.
Одно дело, когда мотивация падает потому, что не выполняются условия «контракта», проблемы в коллективе, не интересный проект, нет оговоренных тренингов, идеи и энтузиазм игнорируются, и т.д. — весомый аргумент.
Другое, если мотивация упала после появление конторы, платящей больше денег — не очень весомый аргумент.
Почему бы не оговорить индексацию ЗП в момент приема на работу? Например, можно попросить ежегодную индексацию на инфляцию, как минимум. Если это будет оговорено, но не выполнено — другой разговор.
Нужно ответить самому себе на вопрос, с кого менеджер должен увеличивать вам ЗП в 2 раза, если рыночная ЗП не изменилась на столько, а причиной является только то, что Вася в перешел в компанию «Самоделкино и Ко» и получает в 2 раза больше? Я думаю, в таком случае менеджеру нужно порадоваться за сотрудника и попросить его выйти мягко из проекта, как было написано в статье.
ПМ не должен знать технических деталей. Вы (команда) — ответственная и автономная единица (до первых косяков). Если команда решает подзабить на план и порефакторить — то менеджер автономность будет убирать и будет микроменеджить девелоперов, «как пастух своих овец», извиняюсь за аналогию. Вам это надо?
Интересно, как обрадуется команда, если ПМ решить невыдать всей команде бонус, т.к. потратит его, например, на покупку растений в офис, где работают девелоперы. И когда люди начнут приходить с вопросами, он скажет (например): «Ребят, у вас теперь среда какая комфортная. Это важно для вашей будущей работы, что бы дышалось хорошо и это окупиться в будущем вашим здоровьем и настроением».
Вот интересно было бы послушать реакцию девелоперов :) И если эта реакция будет отличная от: «конечно, все верно, молодец ПМ!», то следует ли из этого делать вывод, что команда — необразованная и непонимает важности комфортной и разряженной рабочей среды для коллектива? :)
Суровая правда жизни, что программеры забивают на ПМа, считая, что уменьшение technical debt важнее, чем delivery. Поэтому и плодятся у нас говноотношения между менеджерами и девелоперами.
Последние несколько лет я работаю в командах с налаженной коммуникацией. Если нужно заложить время на улучшение кода или его изменение в пользу стабильности, масштабируемости и прочего, это обсуждается девелоперами еще до планирования этапа (внезапно возникла необходимость переписать полпроекта? харош...). На планировании это выносится на повестку с аргументированием, почему это важно (надеюсь, не будет вопроса «чтоооо? еще и аргументировать ему надо? да он необразованный, раз не понимает»… может быть, вы сами не образованы, если не можете аргументировать необходимость чего-то бизнесу?).
Я еще ниразу не встречал ситуации, когда менеджеру сообщалось бы: «нам нужно провести оптимизацию/рефакторинг, и это очень важно для проекта, т.к. нагрузка на продакшн сервере уже превысила 70%, и если мы не возьмем это в этап, на следующей неделе наш продукт ляжет и мы потеряем клиентов и деньги», и менеджер в ответ говорил бы: «нет, в этап берем только новые фичи» :)
Я еще ниразу не встречал ситуации (по крайней мере, с компетентными девелоперами), которые встретив препятствие вчера не сообщили бы о нем команде сегодня и если препятствие не устранено — менеджеру к концу дня, что бы он понимал риски по реализации той или иной задачи. И что бы менеджер после этого спросил с команды — «мне пофиг, почему задачи не выполнены»…
— Работа по вспомогательным классам для x, y и z была включена в этап? Если нет, то почему вы этим занимались в ущерб этапа?
— О том, что вместо работы над задачами, вам необходимо было делать что-то другое было ли сообщено кому-то (ПМ-у)? Если нет, то на что жалуемся, где закрытые задачи?
— Когда пришло понимание того, что задачи этапа не будут выполнены? Только в последний день этапа протяженностью в месяц? Да что за бред.
Действительно, описанный диалог довольно типичен у нас. Он бы не состоялся (точнее, состоялся бы подругому), если бы в команде была бы хорошая коммуникация.
А можно ссылочку на стандарт PHP для именования папки с зависимостями?
Я не могу понять, как я создаю сложности тем, кто будет поддерживать проект? Если принимается решение об именовании папки vendor каким-либо другим именем, наверняка для этого есть причина?
— Существующий проект. Наверняка. Если есть причина, то, скорее всего, все те, кто поддерживает проект — вкурсе изменения
— Новый проект. Если я начинаю поддерживать какой-то проект, в котором изначально было принято решение о другом имени для папки с зависимостями, то какие трудности это создает для меня? :)
Composer Vendor Directory пост
«One True Vendor» — не сильный аргумент, а стремление автора к consistency. Там говорится о том, что папка vendor — «задумано по дизайну». И приводится «хорошая причина для такого дизайна»:
Если папка будет отлична от vendor — ничего не идет вразрез с «хорошим дизайном» (отсылка к тексту параграфа One True Vendor).
«Autoloading» — не нашел сильных аргументов. Зато есть:
Почему это не может быть «require vendor-dir/autoload.php» неясно.
«Single directory» — тоже все весело. Особенно порадовало:
Т.е. папку vendor, создавая новый проект, совсем не надо добавлять ее в .gitignore :)
Isolation — единственное «заключение» в нем это:
Как это связано с именованием папки зависимостей? Неясно. Зато — «мамой клянус!» («trust me, it's totally worth it») присутствует :)
Итог
Человек, написавший пост, явно устал от управления зависимостями с PEAR, особенно работая с несколькими проектами, которые зависят от разных библиотект. И он (человек) стремится к согласованности в именовании папки, что поощримо (я сам ЗА consistency в проектах). Но аргументов нет, есть только — «ппц, да это не круто именовать папку отлично от vendor».
Я тоже предпочитаю «vendor», hell0w0rd, тем более, что пока не приходилось иметь дизайн приложения, который требовал бы изменения дефолтной конфигурации. Но я не исключаю возможности такой необходимости.
И если все зависимости хранятся в одной папке, а не разбросаны по проекту — то по-сути все равно, какая эта папка (если уж дефолтное название изменено, возможно, есть на то причина).
Напрашиваются две мысли, после прочтения комментов:
Также интересно, пришли ли отдельные C++ разработчики таки к заключению, что разные языки хороши для решения разных задач, а иногда разумно использовать стек из разных технологий, что бы построить то или иное решение? Или они все еще считают, что ты пишешь либо на PHP, либо на C++! Точка!
Действительно, ведь крутые C++ программисты напишут бложик на C++, или вообще никогда не столкнуться с такой низкоуровневой задачей/просьбой.
Я неверно интерпретировал событие. Я думал, что мы включаем зимнее и летнее время (переключение), как было, скажем, 4 года назад. Т.е. в марте переведемся на летнее время.
Ан нет, оказывается, речь идет не о возврате механизма перехода (зима, лета), а о фиксированном времени (как в данный момент), только на 1 час меньше.
Получается, летом время в Финляндии, Эстонии,… разницы во времени с РФ не будет. По сути, летом это будет EEST (Eastern European Summer Time), грубо говоря :)
Для меня важно знать временную разницу CET <-> MSK. Поэтому вопрос к вам и знатокам был: все ли верно указано на этой картинке, относительно разницы времени в Москве с европейским (ПАРИЖ, БЕРЛИН, РИМ). До и После. Выглядит, как неверно.
Я оперирую терминами и цифрами картинки с Лента.ру, т.е. про разницу времени в Москве, со временем Central European Time. Вы же говорите про UTC (Coordinated Universal Time).
Амстердам: 15:25
Москва: 17:25 (+2)
Прошлой зимой (2013)
Амстердам: 14:25 — (-1 час от летнего «сейчас»)
Москва: 17:25 (+3) — не перевели стрелки час назад
Как у вас получилось сейчас +4?
До отмены перехода на зимнее/летнее время было: Зима (CET +2), Лето (CEST +2)
После отмены перехода стало (до 26 октября 2014): Зима (CET +3), Лето (CEST +2)
Как будет после 26 октября 2014? По логике, должен добавиться час и в Европе и в России, поэтому разница не должна быть больше, чем 2 часа. Как получилось — Зима (CET+2), Лето (CEST +1)?
Запутался :(
Я бы это выделил, если честно.
Автору благодарность за своевременный пост :)
Но опять же, мы говорим о важных вещах, но забываем конкретизировать ситуацию. Если это устоявшийся проект и идет его развитие — нет проблем заменить человека, даже ключевого.
Если проект в стадии разработки и готовится к релизу, тут будет сложнее решить, как поступить.
Оговаривание можно объяснить. Если работодатель обещает что-то в оффере, какая проблема включить это в контракт? Я не говорю о чем-то абстрактном. Что ж, если это не понравится работодателю — вряд ли стоит наниматься к нему. Не могу понять о каких повышенных обязательствах идет речь, извините. Если я лживый HR, красиво рассказывающий о том, сколько бонусов будет иметь сотрудник в этой компании — мне не понравится сотрудник, который хочет прописать эти обещания (т.к. я то знаю, что они не будут выполнены).
Опять же, прошу понять меня правильно. Я не говорю, что одно — правильно, а другое нет. Здесь присутствует мое рассуждение, основанное на собственном опыте и работе в разных компаниях и странах.
Просто, если я, как менеджер, обещаю и собираюсь индексировать будущему сотруднику (и я уже это делаю для текущих) зарплату каждый год, то мало того, что меня не будет напрягать запрос от кандидата, скорее всего, этот пункт уже будет включен в контракт или одно из его приложений.
Менеджер должен следить за рынком — согласен с вами. В идеале, менеджер должен участвовать в жизни команды, что бы знать текущие настроения :)
Но о какой лояльности идет речь, когда человек обнаружил новую компанию, платящую ЗП на 50% выше рыночных? Если в компании сотрудника держат только деньги, думаю, он будет работать у вас до того времени, пока он не найдет место, где ему предложат больше и вы не сможете перебить эту сумму.
И что стоит за отсутствие головняка и будет ли это отсутствие? Допустим, я повысил ЗП. Через полгода появляется новая компания. Теперь, вместе с этим человеком приходят еще 3, один из них ключевой. С тем же самым аргументом. Еще раз «отделываемся от головняка». И в третий раз закинул старик невод… интересно, чем все закончится для проекта.
P.S> Пишу столько текста, т.к. интересная тема. Приходилось работать в разных звеньях «рабочей иерархии». Поэтому рассуждаю не просто как работник или директор.
Я думаю многие вещи заложить на этапе найма. Понимаю, что у нас контракт — ничего не значит, но его можно использовать в качестве аргументов. Хм, может стоит написать пост на эту тему. С названием вроде «X вещей, которые необходимо оговорить (прописать в контракте) перед началом работы в компании»
Я бы задумался о желании иметь такого «стабильного» сотрудника в своей команде. Через месяц появится компания, у которой будет еще больше бюджет… что тогда? Опять тот же вопрос? Если человек решил уйти из-за денег, попытки что-то мгновенно изменить лишь отсрочат уход «до следующего случая».
И действительно, что такое мотивация. Когда я начинаю работать в компании, моя мотивация — это оффер/условия работы в компании, включая ЗП, бонусы и т.д.
Одно дело, когда мотивация падает потому, что не выполняются условия «контракта», проблемы в коллективе, не интересный проект, нет оговоренных тренингов, идеи и энтузиазм игнорируются, и т.д. — весомый аргумент.
Другое, если мотивация упала после появление конторы, платящей больше денег — не очень весомый аргумент.
Почему бы не оговорить индексацию ЗП в момент приема на работу? Например, можно попросить ежегодную индексацию на инфляцию, как минимум. Если это будет оговорено, но не выполнено — другой разговор.
Нужно ответить самому себе на вопрос, с кого менеджер должен увеличивать вам ЗП в 2 раза, если рыночная ЗП не изменилась на столько, а причиной является только то, что Вася в перешел в компанию «Самоделкино и Ко» и получает в 2 раза больше? Я думаю, в таком случае менеджеру нужно порадоваться за сотрудника и попросить его выйти мягко из проекта, как было написано в статье.
— Поцарапали машину гвоздем?
— Не беда, закрасим баллончиком BH-100 (Black Hole, — прим. кэп)
— Задел на парковке какой-то чудак на букву «м»
— Нет проблем, попроси баллончик BH-100 в ближайшем автосервисе
— Потерял дверь?
— Какая удача, что у тебя с собой кусок картона и баллончик BH-100
… ведь BH-100 сглаживает все углы и шероховатости на поверхности вашего авто