E
Ну он человек скромный, но менеджементу нужно же иметь совесть
Size: a a a
2019 June 13
SP
Это бизнес.
SP
Ну он человек скромный, но менеджементу нужно же иметь совесть
Вот нанял ты работника и он норм работал. Вы с ним договорились по деньгам. Будешь ли ты инициировать "повышение зп" без изменений других параметров сотрудничества? Я сомневаюсь. Ну или твой бизнес не долго будет существовать
AS
Правильный подход - платить ту зарплату, при которой к сотрудника не возникнет желания просить ее повышения. К просьбе о повышении зп, как правило, приходят не сразу, а в течении 1-2 месяцев размышлений, которые при этом плохо влияют на продуктивность сотрудника. Поэтому, платите хорошо и пересматривайте сами.
E
Вот нанял ты работника и он норм работал. Вы с ним договорились по деньгам. Будешь ли ты инициировать "повышение зп" без изменений других параметров сотрудничества? Я сомневаюсь. Ну или твой бизнес не долго будет существовать
Ну вот я бы на месте того типа, ушел бы, а не остался бы
И допустим мой бизнес потерял бы ключего человека на проекте, и потерял бы в разы больше, а мб и в десятки
И допустим мой бизнес потерял бы ключего человека на проекте, и потерял бы в разы больше, а мб и в десятки
IS
Ну вот я бы на месте того типа, ушел бы, а не остался бы
И допустим мой бизнес потерял бы ключего человека на проекте, и потерял бы в разы больше, а мб и в десятки
И допустим мой бизнес потерял бы ключего человека на проекте, и потерял бы в разы больше, а мб и в десятки
Ти в курсі що через зп чимало народу міняє роботу (принаймні у мене такі знайомі є) але бізнеси не розвалюються)
SP
Ну вот я бы на месте того типа, ушел бы, а не остался бы
И допустим мой бизнес потерял бы ключего человека на проекте, и потерял бы в разы больше, а мб и в десятки
И допустим мой бизнес потерял бы ключего человека на проекте, и потерял бы в разы больше, а мб и в десятки
Ключевых надо вовремя замечать и делать так что бы их небыло
IS
Правильный подход - платить ту зарплату, при которой к сотрудника не возникнет желания просить ее повышения. К просьбе о повышении зп, как правило, приходят не сразу, а в течении 1-2 месяцев размышлений, которые при этом плохо влияют на продуктивность сотрудника. Поэтому, платите хорошо и пересматривайте сами.
Це в ідеалі. Але так само добре писати код без багів. Всі так хочуть але мало у кого так виходить.
SP
Если в команде есть тот без кого никак - наймите людей которые будут перекрывать недостающие скилы
SP
Иначе и риски, и проблемы скейлинга и для команды в целом от этого хуже
AS
Це в ідеалі. Але так само добре писати код без багів. Всі так хочуть але мало у кого так виходить.
Это немного не о том, хоть и справедливо
IS
Просто є речі які трохи не сумісні. Працівники хочуть більшу зп. Бізнес хоче більше прибутку. А зп це розхід. Відповідно така каша)
ST
Профіт це різниця між прибутком і костами )
Але коли кандидат запитує про зп сильно нижчу ринкової для цієї посади (чи нижче прийнятої в компанії), то потрібно розуміти, що він скоро розчехлиться і ця інфа його демотивує.
Але коли кандидат запитує про зп сильно нижчу ринкової для цієї посади (чи нижче прийнятої в компанії), то потрібно розуміти, що він скоро розчехлиться і ця інфа його демотивує.
AV
Даёшь квоту 15-20% спринта на техдолги!
А разве у всех не так? Если в проекте такого нет то или этому проекту пол года отроду или его уже не спасти и с него надо валить.
SM
А разве у всех не так? Если в проекте такого нет то или этому проекту пол года отроду или его уже не спасти и с него надо валить.
Старому проекту было 9лет. Рефакторинг по праздникам
AV
Мы дошли да такой схемы когда беклога накопилось на 1.5 человека-года (в команде 10 разрабов), за 3 года разработки.
Но все же самое главное - это признать проблему (вести хотя бы беклог, а не просто говорить что все хреново).
Но все же самое главное - это признать проблему (вести хотя бы беклог, а не просто говорить что все хреново).
ST
Не раз зустрічав ситуацію, коли девелопери спочатку топили за тести і рефакторинг (так жеж модно), витрачали купу часу на покриття коду тестами, а через рік-два виявлялось, що ці тести ніхто не підтримує і вони не актуальні 😔
SP
Мы дошли да такой схемы когда беклога накопилось на 1.5 человека-года (в команде 10 разрабов), за 3 года разработки.
Но все же самое главное - это признать проблему (вести хотя бы беклог, а не просто говорить что все хреново).
Но все же самое главное - это признать проблему (вести хотя бы беклог, а не просто говорить что все хреново).
когда бэклог на 1.5 человекагода стоит воспользоваться плагином для джиры "танос" который рандомом удалит половину раз вы не в состояниии
SP
нет никакого смысла хранить тудушки которые не планиируются в работу в течении пару месяцев.
SP
что до тех долга - в бэклог ложить его не оч удобно. Не знаю как многие - мне лично просто нравится между сторям какие-то вещи фиксить. Для этого нужен какой-то учет проблем, страниички в конфлюенсе, синхронизация понимания "почему так не надо" в команде, можно раз в неделю устраивать группоое код ревью и разбор рандомных мест в коде