Как правило, менеджмент наиболее восприимчив к новым идеям во время «кризиса» — горят сроки, или бюджет, или вообще происходит что-то неприятное.
Например, команда затягивает сроки. У менеджеров сам собой возникает вопрос — почему? Оказывается, потому что пара человек уволились, а остальные как-то не сильно спешат работать после недели черной работы. В этот момент как нельзя лучше можно рассказать, что причиной всему — сверхурочные, и давайте ка делать их поменьше.
К сожалению, пока не наступит «кризис» (т.е. пока петух жареный не клюнет в одно место), в большой компании действительно сложно продвигать новые идеи.
Надо действовать аккуратно и последовательно. Если ткнуть менеджера (а тем более топ-менеджера) в ошибку лицом — он займет оборонительную позицию в разговоре и не согласится с Вами, даже если будет чувствовать, что Вы правы. Поэтому давить напрямую не стоит.
Другое дело, если зайти в кабинет к ПМу со словами: «Я знаю, как тебе сэкономить деньги в проекте. Мы уменьшим ротацию кадров!» — вы поймаете его внимание. Далее рассказывайте, как отказ от сверхурочных поможет понизить текучесть кадров и сохранить бабки в бюджете. Ну и далее, по статье. Это помогает.
Тут вступает в силу ещё один фактор, который часто игнорируется нашими менеджерами — лучше взять одного опытного человека с зарплатой в 2N (а зачастую — и в 1,5N), нежели двух, с зарплатой в N и значительно меньшим опытом. К сожалению, на такой шаг «высшее руководство» согласно идти далеко не всегда.
Увы, сам сталкивался с такой позицией руководства — очень печально. Сначала хотя взять людей подешевле, надеясь, что 2 junior'a заменят middle-developer'a, а потом сроки трещат по швам, и команда по-геройски вытаскивает проект… и делать реально не в экономии — а в психологическом факторе. Неопытные руководители боятся нанимать дорогих и опытных разработчиков
У нас в компании пару лет назад сверхурочная работа была повсюду. Затем, мы стали показывать подобные статьи топ-менеджерам, разъяснять, что к чему — и свели «авралы» практически на нет. Совсем избавиться не удалось — но теперь работа на выходных или поздним вечером в будни является исключением.
Возможно, потому, что ваша схема производства в 3 раза дороже, чем в среднем по рынку. А значит, ваши продукты (или выполнение заказа) дороже, чем у конкурентов. В 3 раза — это существенно. Тот, что платит деньги, такое явно заметит. Вот поэтому и возникают сомнения в достоверности рассказанного.
Вот Вы пишите, что умеете писать ТЗ, точно знаете, чего хотите, и, как следует из вашего сообщения, тратите в 3 раза больше, чем остальные заказчики на рынке. Зачем Вам какой-то конкурс?.. Найдите разработчика, с которым сработаетесь, обеспечьте взаимовыгодное сотрудничество — и ваши проекты также будут получаться в срок, без каких-то дополнительных конкурсов.
Правильно ли я понял: если некоторый объем работы (например, эскиз страницы) стоит на рынке N рублей, то «победитель» (тот, кто первым сдал работу) забирает сумму 2N, а «проигравший» — в 2 раза меньше победителя, т.е. N рублей. Тогда весь блок работ стоит в 3 раза больше, чем на рынке…
Если ваши проекты реально позволяют столько платить — я рад и за вас, и за ваших разработчиков. Если не секрет — что за проекты такие?
Я и не предлагаю отказаться от почты. Как правильно заметили выше, стратегические моменты (договор, ТЗ, акты) нужно передавать по почте. Аналогично, факт приемки отдельной версии или всей работы должен быть правильно зафиксирован.
Другое дело, что иногда случается перекос, когда даже самые обыденные вопросы решаются по почте. Например, если разработчик проверяет почту, скажем, 3 раза в день (потому что постоянно проверять — отвлекаться от кодинга, после каждого письма снова включаться в работу...), то за день обсуждение пройдет с десяток итераций, а сам разговор закончится за пару дней. В ИМ можно было бы справиться минут, скажем, за 10-15. Поэтому если Заказчик заинтересован в оперативном результате — стоит по возможности использовать ИМ.
Про обучение. Например, корпоративные и гос стандарты, ТЗ и иные формы ограничений в проекте. По умолчанию, поступают так: сваливают в кучу N документов, которые могут быть написаны непрофессиональным языком (генеральный заказчик способен на причуды), выдают разработчику, а потом на приемке ожидают, что будет сделано быстро и правильно. Вот в таком случае не помешала бы разъяснительная работа.
Ну я так считаю: и в коммуникациях с клиентами, и в коммуникациях с разработчиками надо проявлять эмпатию: способность поставить себя на место собеседника. В этом смысле, действительно, отношения с клиентом и отношения с разработчиком должны быть похожи.
Например, команда затягивает сроки. У менеджеров сам собой возникает вопрос — почему? Оказывается, потому что пара человек уволились, а остальные как-то не сильно спешат работать после недели черной работы. В этот момент как нельзя лучше можно рассказать, что причиной всему — сверхурочные, и давайте ка делать их поменьше.
К сожалению, пока не наступит «кризис» (т.е. пока петух жареный не клюнет в одно место), в большой компании действительно сложно продвигать новые идеи.
Другое дело, если зайти в кабинет к ПМу со словами: «Я знаю, как тебе сэкономить деньги в проекте. Мы уменьшим ротацию кадров!» — вы поймаете его внимание. Далее рассказывайте, как отказ от сверхурочных поможет понизить текучесть кадров и сохранить бабки в бюджете. Ну и далее, по статье. Это помогает.
Увы, сам сталкивался с такой позицией руководства — очень печально. Сначала хотя взять людей подешевле, надеясь, что 2 junior'a заменят middle-developer'a, а потом сроки трещат по швам, и команда по-геройски вытаскивает проект… и делать реально не в экономии — а в психологическом факторе. Неопытные руководители боятся нанимать дорогих и опытных разработчиков
У нас в компании пару лет назад сверхурочная работа была повсюду. Затем, мы стали показывать подобные статьи топ-менеджерам, разъяснять, что к чему — и свели «авралы» практически на нет. Совсем избавиться не удалось — но теперь работа на выходных или поздним вечером в будни является исключением.
Так что подобные статьи нужны и очень полезны.
Вот Вы пишите, что умеете писать ТЗ, точно знаете, чего хотите, и, как следует из вашего сообщения, тратите в 3 раза больше, чем остальные заказчики на рынке. Зачем Вам какой-то конкурс?.. Найдите разработчика, с которым сработаетесь, обеспечьте взаимовыгодное сотрудничество — и ваши проекты также будут получаться в срок, без каких-то дополнительных конкурсов.
Если ваши проекты реально позволяют столько платить — я рад и за вас, и за ваших разработчиков. Если не секрет — что за проекты такие?
Другое дело, что иногда случается перекос, когда даже самые обыденные вопросы решаются по почте. Например, если разработчик проверяет почту, скажем, 3 раза в день (потому что постоянно проверять — отвлекаться от кодинга, после каждого письма снова включаться в работу...), то за день обсуждение пройдет с десяток итераций, а сам разговор закончится за пару дней. В ИМ можно было бы справиться минут, скажем, за 10-15. Поэтому если Заказчик заинтересован в оперативном результате — стоит по возможности использовать ИМ.